schedules/
Ein echter, handgeschriebener ColdBox-Scheduler, unverändert durchgereicht.
schedules/
schedules/Scheduler.bx - falls vorhanden - ist eine echte, handgeschriebene ColdBox-Scheduler-Klasse, die unverändert in den Build durchgereicht wird (eine reine Dateikopie nach config/Scheduler.bx, keine Generierung, keine Übersetzung):
// schedules/Scheduler.bx
class extends="coldbox.system.web.tasks.ColdBoxScheduler" {
function configure() {
task( "nightly" )
.call( () => getInstance( "SupportBot" ).run( "cleanup" ) )
.everyDayAt( "00:00" )
.withNoOverlaps()
}
}
Am Inhalt dieser Datei ist nichts BX-Agents-Spezifisches - es ist ColdBoxs eigene Scheduler-DSL, vollständig: .cron( "0 9 * * 1-5" ), .everyWeekOn(), .startOn()/.endOn()/.between(), .when(), .withNoOverlaps(), before()/after()/onSuccess()/onFailure()-Hooks, Zeitzonen - alles, was ColdBoxs ScheduledTask unterstützt, schränkt dieses Projekt weder ein noch interpretiert es um. (Eine frühere Version dieser Konvention war eine { cron, action }-Datenform, hier in ColdBoxs Frequenzmethoden-DSL übersetzt - diese Übersetzung deckte nur eine schmale Teilmenge von Cron ab und warf alles andere weg, was die echte Scheduler-API bietet, sie ist also weg. Wer ein altes Projekt migriert, siehe unten.)
Einen Agenten abrufen
Jeder Agent im Baum des Projekts - das eigene Agent.bx des Root-Projekts und jeder subagents/*-Eintrag, wie tief auch immer verschachtelt - wird in der generierten config/WireBox.bx unter seinem eigenen deklarierten name registriert (dem name, den sein Agent.bx über super.init() gesetzt hat, oder einem per configure() deklarierten name, der ihn überschreibt). Ein Schedule erreicht welchen Agenten auch immer es will mit einem einfachen getInstance( "TheAgentName" ) - keine BX-Agents-spezifische Lookup, nur WireBox, genau wie die getInstance()-Aufrufe an anderer Stelle in einer ColdBox-App.
// subagents/researcher/Agent.bx
class extends="bxModules.bxai.models.runnables.AiAgent" {
function init() {
super.init(
name : "ResearchBot",
model : aiModel( provider: "openai", params: { model: "gpt-5" } )
)
return this
}
}
// schedules/Scheduler.bx
task( "weekly-digest" )
.call( () => getInstance( "ResearchBot" ).run( "summarize this week's findings" ) )
.everyWeekOn( 1, "08:00" )
Weil name jetzt auch ein WireBox-Bindungsschlüssel ist, muss er über das gesamte Projekt hinweg eindeutig sein - build schlägt bei der Validierung fehl, falls zwei Agenten (Root oder Subagent, in beliebiger Tiefe) sich einen Namen teilen, einschließlich zweier, die beide unset lassen und still auf "BxAi" zurückfallen. Siehe subagents/ für die Unterscheidung zwischen dem Ordnernamen eines Subagenten (genutzt, um subAgents: [...] zu verdrahten) und seinem eigenen deklarierten name (hier genutzt).
Validierung
buildsucht nur nach genau einer Datei:schedules/Scheduler.bx. Alles andere inschedules/(einschließlich alter{ cron, action }-Dateien von vor der Änderung dieser Konvention) wird ignoriert -buildgibt eine Warnung aus, fallsschedules/existiert, aber keinScheduler.bxenthält, sodass ein still gestoppter Schedule wenigstens sichtbar ist.- Darüber hinaus ist
schedules/Scheduler.bxechter Code - dasselbe "wir können das ohne einen echten ColdBox-Boot nicht sinnvoll validieren"-Terrain wie bei jeder anderen BoxLang-Klasse. Ein Syntaxfehler oder ein falschergetInstance()-Name tauchen erst auf, wenn die generierte App tatsächlich bootet (serve), nicht zurbuild-Validierungszeit.
Migration von der alten { cron, action }-Konvention
Zuvor war jede Datei unter schedules/ ein eigener { cron: "0 0 * * *", action: "cleanup" }-Eintrag, übersetzt in einen ColdBox-Frequenzmethoden-Aufruf gegen die einzelne Root-Bindung "GeneratedAgent". Zur Migration: diese Dateien löschen, ein schedules/Scheduler.bx hinzufügen, das coldbox.system.web.tasks.ColdBoxScheduler erweitert, und für jeden alten Eintrag ein task( name ).call( () => getInstance( "TheAgentName" ).run( "action text" ) ) hinzufügen, mit welcher echten ColdBox-Frequenzmethode oder welchem .cron()-Aufruf auch immer zum alten Cron-Ausdruck passt.