Anwendungen, Hosts und Cloud-Dienste zentral zeitgesteuert starten: SyncCronA verbindet Zeitpläne mit den passenden Ausführungszielen. Für APIs, Jobs, Skripte, Container und Functions — mit einem gemeinsamen Blick auf ihre Ausführung.
Stell dir einen Abrechnungsdienst vor, der jeden Morgen Rechnungen erzeugen soll. Du legst fest, was er ausführen kann und wann es passieren soll. SyncCronA startet den registrierten Handler zum geplanten Zeitpunkt und hält den Lauf fest.
Wenn wiederkehrende Aufgaben über mehrere Anwendungen oder Instanzen verteilt sind und du Zeitpläne, Fehler und Ergebnisse zentral nachvollziehen willst. Besonders hilfreich wird das beim Skalieren: Ein Dienst läuft mehrfach, die Aufgabe soll aber nur gezielt angestoßen werden.
Für den ersten Integrationsweg registrierst du den SyncCronA Application Agent in deinem .NET-Dienst und benennst einen vorhandenen Handler. Du konfigurierst die Verbindung zur zentralen Instanz und legst dort den Zeitplan fest. Der Handler bleibt in deiner Anwendung.
Der MVP 0.1.0 konzentriert sich auf den .NET Application Agent. Das Gesamtkonzept ist technologieoffen: Host Agent und Connectoren sollen später Skripte, Container, APIs, Messaging und Cloud Functions einbinden. Diese Wege sind noch nicht Teil des MVP.
Dein Dienst registriert den Handler GenerateInvoices. SyncCronA verwaltet einen Zeitplan mit Zeitzone. Zur geplanten Zeit erzeugt es eine Execution und wählt eine geeignete, erreichbare Instanz des Dienstes. Die Anwendung führt ihren Handler aus und meldet den Status zurück.
SyncCronA befindet sich im Aufbau. Die Seite beschreibt den dokumentierten MVP und die weitere Produktvision; sie ist noch keine Installationsanleitung für einen verfügbaren Dienst.
Cronjobs auf Servern, Timer in Cloud Functions und Scheduler in Anwendungen: Wiederkehrende Aufgaben verteilen sich über die gesamte Infrastruktur. SyncCronA soll ihre Zeitsteuerung an einem Ort zusammenführen.
Wartungsskripte, Datenabgleiche und Batch-Jobs werden in unterschiedlichen Werkzeugen geplant. Änderungen und Zuständigkeiten bleiben unübersichtlich.
Cron, Intervalle, Zeitzonen und Sommerzeit werden immer wieder separat gelöst — vom einzelnen Host bis zum Cloud-Dienst.
Was sollte laufen, welches Ziel wurde erreicht und welches Ergebnis kam zurück? Ohne zentrale Historie fehlen die Verbindungen.
SyncCronA soll zeitgesteuerte Aufgaben dort starten, wo sie gebraucht werden: in Anwendungen, auf Hosts und über Cloud-Services. Agents und Connectoren verbinden diese Ziele mit der zentralen Planung.
HTTP-Aufrufe und interne Dienste zeitgesteuert anstoßen. Die Businesslogik bleibt am Ziel.
Nachrichten an Queues und Topics übergeben, um nachgelagerte Verarbeitung zu starten.
Functions über passende Connectoren auslösen, ohne die Zeitsteuerung in jeder Function separat zu pflegen.
Ein Host Agent soll lokale Skripte, Binaries, Container und Kubernetes-Workloads starten — auch in getrennten Netzwerken über eine ausgehende, abgesicherte Verbindung.
Diese Beispiele beschreiben geplante Integrationen. Die erfolgreiche Zustellung eines Auftrags bestätigt noch nicht seine fachliche Ausführung; dafür ist eine Rückmeldung des Zielsystems erforderlich.
Version 0.1.0 konzentriert sich auf verteilte .NET-Anwendungen: registrierte Handler, zentrale Schedules und die Auswahl einer gesunden Instanz. Dieser erste Anwendungsfall legt die Grundlage für die allgemeine Zeitsteuerung über Hosts und Cloud-Dienste.
Scheduling und Ausführung sind getrennt. Ein Zeitplan beschreibt die Regeln. Eine Execution steht für einen konkreten Lauf — mit eigener Identität und eigenem Status.
Die Konfiguration benötigt eine HTTPS-Adresse der Control Plane, eine ApplicationId und ein BootstrapSecret. Die Handler bleiben in deiner Anwendung; SyncCronA überträgt keinen beliebigen Code.
Der Application Agent meldet Anwendung, Instanzen und verfügbare Handler. Heartbeats zeigen die Erreichbarkeit.
Ein Zeitpunkt, Intervall, Cron-Schedule oder manueller Aufruf erzeugt eine eindeutige Execution.
AnyHealthyInstance wählt eine geeignete, gesunde Instanz aus und fordert den registrierten Handler an.
Started, Running, Success oder Failed werden zentral zurückgemeldet und mit Dauer und Fehlerdetails gespeichert.
Hangfire, Quartz.NET und Kubernetes CronJobs lösen reale Scheduling-Probleme. SyncCronA wird interessant, wenn Zeitpläne, Zielauswahl und Ausführungshistorie über laufende Anwendungsinstanzen hinweg an einem Ort liegen sollen. Für einen einzelnen Dienst oder einen reinen Containerjob ist ein etabliertes Werkzeug oft der kürzere Weg.
Passt, wenn Jobs und Worker in deiner .NET-Landschaft bleiben und du Queue, wiederkehrende Jobs und Verarbeitung mit persistentem Storage zusammen betreiben willst.
Stark für: .NET-JobverarbeitungPasst, wenn deine Anwendung umfangreiche Trigger und Zeitregeln benötigt. Mit persistentem Job Store unterstützt Quartz.NET auch Scheduler-Clustering.
Stark für: Scheduling im .NET-SystemPasst, wenn die Aufgabe als eigener Kubernetes Job und Pod laufen soll und ihre Planung im Cluster bleiben kann.
Stark für: containerisierte Batch-JobsDer erste vorgesehene Pfad plant zentral und adressiert einen vorab registrierten Handler in einer geeigneten .NET-Anwendungsinstanz. Weitere Hosts und Cloud-Ziele sind Teil der Vision.
Stark für: zentral gesteuerte, verteilte AnwendungenZum Vergleich: Hangfire: mehrere Server · Quartz.NET Clustering · Kubernetes CronJob
SyncCronA trennt die Entscheidung wann und wo von der Fachlogik was. Im dokumentierten MVP bleibt die Logik in deiner .NET-Anwendung; die zentrale Control Plane verwaltet den Zeitplan, den einzelnen Lauf und seinen Status.
Der Application Agent meldet Handler und Heartbeats und hält einen mit Client-Zertifikat gesicherten gRPC-Stream über HTTPS zur Control Plane. Über denselben Kommunikationspfad kommen Aufträge und Statusmeldungen zurück.
Der dokumentierte Ausbau nutzt einen einzelnen Core; offene Agent-Verbindungen liegen in dessen Prozessspeicher. Host Agent, Cloud-Connectoren und ein hochverfügbarer Core sind noch keine zugesicherten Funktionen des MVP.
Bei mehreren Anwendungsinstanzen soll ein geplanter Termin eine eindeutige Execution erzeugen und eine geeignete Instanz auswählen. Das schützt die Planung vor Doppelungen. Ob die fachliche Arbeit bei jedem denkbaren Ausfall exakt einmal geschieht, ist eine andere Frage.
Für geplante Läufe ist die Kombination aus Schedule und geplantem Zeitpunkt eindeutig. Jede Execution trägt eine eigene ID, über die Status und Logs zusammengehören.
Ein Handler läuft bei einem Verbindungsabbruch weiter. Der Agent liefert unbestätigte Statusmeldungen nach dem Reconnect nach und unterdrückt denselben Auftrag innerhalb seines laufenden Prozesses.
Nach einem Agent-Prozessabsturz können Meldungen und Duplikaterkennung verloren sein. Eine bereits zugeordnete Execution wird bei unklarem Versand nicht automatisch neu verteilt und kann ohne Endergebnis bleiben.
Nutze die Execution-ID zur Idempotenz in deiner Fachlogik und plane den Umgang mit unklaren oder fehlgeschlagenen Läufen ein. Automatische Retries, dauerhafte Outbox und Timeout-Reconciliation sind als spätere Schritte beschrieben; für 0.1.0 wird keine Exactly-once-Ausführung versprochen.
Der MVP beweist diesen Weg zunächst mit .NET-Handlern. Die Auswahl einer Instanz löst dabei das konkrete Problem mehrfach gestarteter Aufgaben in autoskalierenden Anwendungen.
Absolute Zeitpunkte, Intervalle und Cron-Schedules mit expliziter Behandlung von Zeitzonen und Sommerzeit.
Self-Registration und Heartbeats schaffen die Grundlage für die Auswahl einer gesunden Anwendungsinstanz.
Die ExecutionId verbindet Start, Statusmeldungen und Ergebnis. Schedule-Konfiguration und Ausführungshistorie bleiben getrennt.
Status, Dauer und Fehlerdetails machen Ausführungen nachvollziehbar. Strukturierte Logs lassen sich einer Execution zuordnen.
Der .NET Application Agent verbindet sich mit SyncCronA. Registrierte Handler führen die Businesslogik innerhalb der Anwendung aus.
Authentifizierung für Benutzer und Agents sowie grundlegender Schutz gegen doppelte Schedule-Auslösung gehören zum MVP-Scope.
Beispielhafte Handler für Entwickler- und Plattformteams mit verteilten .NET-Anwendungen.
Der BillingService läuft auf mehreren Instanzen. Eine geeignete Instanz erhält die Execution für den Tageslauf.
GenerateInvoicesEin registrierter Cleanup-Handler verarbeitet nächtliche Wartungsaufgaben. Status und Laufzeit bleiben nachvollziehbar.
CleanupHandlerEin manueller Aufruf erzeugt ebenfalls eine Execution — mit derselben Instanzauswahl und Ergebnisrückmeldung.
Execute nowEin gemeinsamer Blick auf wiederkehrende Aufgaben — in Anwendungen, auf Servern und über Cloud-Dienste hinweg.
Wiederkehrende Aufgaben zentral planen, statt Cron-Konfiguration und Zeitlogik in jedem Dienst oder Skript erneut zu pflegen.
Perspektivisch Functions, APIs, Container und Host-Aufgaben über dieselbe Zeitsteuerung ansprechen — auch in hybriden Umgebungen.
Zeitpläne, Ausführungsstatus und Historie an einem Ort zusammenführen, statt sie über einzelne Systeme zu verteilen.
Rechnungen, Bereinigungen und regelmäßige Verarbeitung planbar machen und ihren Verlauf nachvollziehen.
Die Projektdokumentation beschreibt einen fokussierten Einstieg. Weitere Ausführungsziele folgen dem langfristigen Konzept und sind keine Zusage für Version 0.1.0.
Der vollständige Kernfluss vom registrierten Handler bis zur zentralen Ausführungshistorie.
Agents und Connectoren sollen die zentrale Steuerung über weitere Laufzeitumgebungen hinweg ermöglichen.
Du registrierst einen ausführbaren Handler in deiner Anwendung und verwaltest seinen Zeitplan zentral. Wenn der Zeitpunkt erreicht ist, erzeugt SyncCronA eine Execution, wählt ein geeignetes Ziel aus und erfasst den gemeldeten Status. Ein Beispiel ist der tägliche Rechnungslauf.
Der erste Integrationsweg ist der .NET Application Agent: Im Dienst registrierst du den Agent und einen benannten Handler. Zusätzlich konfigurierst du die Verbindung zur Control Plane. Für Host- und Cloud-Ziele sind eigene Anbindungen geplant.
Für den MVP 0.1.0 ist .NET der erste unterstützte Anwendungsweg. Die Plattformvision umfasst auch Hosts, APIs, Container und Cloud-Dienste; die entsprechenden Runner und Connectoren sind noch geplant.
Wenn mehrere wiederkehrende Aufgaben oder Dienste eine zentrale Planung und nachvollziehbare Ausführungen brauchen. Ein konkreter Fall sind autoskalierende Anwendungen: Der Dienst läuft mehrfach, eine geplante Aufgabe soll aber gezielt auf einer geeigneten Instanz gestartet werden.
SyncCronA ist als zentrale Zeitsteuerung für Anwendungen, Hosts und Cloud-Dienste konzipiert. Die Instanzauswahl ist der erste konkrete Anwendungsfall im MVP 0.1.0. Host Agent, Runner und Cloud-Connectoren sind geplante Erweiterungen desselben Modells.
Der Produktkern ist Trigger → Execution → Target → Result. Komplexe Prozessgraphen mit Verzweigungen und Abhängigkeiten gehören nicht zum MVP. Die fachliche Prozesslogik bleibt in den Zielanwendungen.
Das Konzept setzt auf eine eindeutige ExecutionId, Schutz gegen doppelte Auslösung und idempotente Verarbeitung. Eine allgemeine Exactly-once-Garantie in verteilten Systemen wird für 0.1.0 ausdrücklich nicht gegeben.
Für zukünftige Broker- und Connector-Ziele muss zwischen Zustellung und fachlichem Erfolg unterschieden werden. Für Ende-zu-Ende-Transparenz benötigt das Ziel ein Rückmeldeprotokoll mit ExecutionId.
SyncCronA befindet sich im Aufbau. Diese Seite beschreibt den dokumentierten MVP-Scope und das langfristige Konzept, keinen verifizierten Release-Stand. Für den aktuellen Entwicklungsstand und einen Austausch nutze bitte den Kontakt.
Ob Wartung auf einem Host, regelmäßige API-Aufrufe, Cloud-Jobs oder Aufgaben in deiner Anwendung: Teile deinen Anwendungsfall und gestalte die nächsten Schritte von SyncCronA mit.
Kontakt aufnehmen