Die Workflow API (früher bekannt als TASK API) ist eine REST API, die den OpenAPI-Spezifikationen folgt. Die API kann für Aufgaben sowohl im Modul Auftragsabwicklung als auch im Modul Service & Incidents verwendet werden, unterscheidet jedoch zwischen inTask und outTask (Links verweisen auf die Swagger UI).
Die API nutzt das Equitri-Protokoll, um alle Systeme synchron zu halten. Das bedeutet, dass auf jede Aktualisierung zunächst eine „Indication“ folgt, dann ein „Fetch“ und schließlich ein „Sync“. Dies gilt sowohl für Aktualisierungen, die die Organisation an Gridsz übermittelt, Gridsz Aktualisierungen, die Gridsz an die Organisation Gridsz . Weitere Details und eine visuelle Erläuterung finden Sie auf der Seite zum Equitri-Protokoll.
Um diese API nutzen zu können, muss die Organisation mindestens über eine System-ID und einen Endpunkt verfügen. Geben Sie dazu bitte die folgenden Angaben in einem support an – oder nehmen Sie die Konfiguration alternativ selbst im Admin-Portal vor, falls Sie Site-Administrator sind:
- Cluster – gibt an, für welche Cluster (Netzwerke) dieses System verwendet werden kann
- SystemID – die eindeutige ID pro Organisation zur Erkennung des Systems
- Endpoint – der Endpunkt, an den alle API-Aufrufe gerichtet werden müssen
- Token – der von der Organisation bereitgestellte Token (dieser wird von Gridsz verwendet, wenn der System-Endpoint aufgerufen wird)
- Standard-Endpunkt
Beachten Sie außerdem, dass die API durch IP-Whitelisting geschützt ist. Kontaktieren Sie den Gridsz support, um IP-Adressen pro Umgebung auf die Whitelist setzen zu lassen.
InTask API
Die InTask API ist für Organisationen gedacht, die Aufgaben erstellen möchten. Dies kann aktive Betreiber betreffen, die Installationsaufträge erstellen, Netzwerkeigentümer, die POP-Störungen erstellen, und so weiter.
Versionshinweise
| Version | Veröffentlichungsdatum | Hinweise |
|---|---|---|
| 1.36.0 | 23.07.2026 | Mit der Einführung eines neuen API-Endpunkts wird „calculateRoutingRules“ hinzugefügt. Gridsz anhand der bereitgestellten Eingaben die Partei zurück, an die die Aufgaben weitergeleitet werden (dadurch wird kein Auftrag erstellt; es dient lediglich dazu, das Ergebnis der Weiterleitung proaktiv zu ermitteln, bevor ein Auftrag erstellt wird). Das Feld „isPrivate“ wurde aus den Labels entfernt. Dies ist lediglich eine Aktualisierung der Dokumentation, da das Feld in der InTask-API für Labels nie implementiert wurde. Das Feld steht weiterhin in der OutTask-API zur Verfügung (unverändert). |
| 1.35.0 | 05.06.2026 | Die maximale Länge des Feldes „Mose.Shared.Models.ActiveOperatorTask.deadlines.name“ von 3–99 auf 3–50 ändern und das Attribut „required“ aus „ActiveOperatorTaskSync.MainStatus“ entfernen, um es an das aktuelle Verhalten anzupassen |
| 1.34.0 | 06.05.2026 | Das neue Feld „SolutionParty“ wurde für die Felder „FTU_CHANGE“ und „DAMAGE_REPORT“ hinzugefügt (bereits verfügbar für „INCIDENT“, „QUOTE“ und „NETWORK_DISCREPANCY“) |
| 1.33.0 | 30.04.2026 | Neues Feld „requestorIsExecutor“ hinzugefügt – wird verwendet, wenn der Anforderer (AO) die Aufgabe an sich selbst weiterleiten muss |
| 1.32.0 | 13.03.2026 | Produktions-URL auf api.task.gridsz.com aktualisieren |
| 1.30.0 | 22-01-2026 | Kontaktdaten dem Root-Objekt hinzufügen |
| 1.29.0 | 22-01-2026 | Das Feld assignedSolutionParty wurde auf der Stammebene von taskFetch (GET) hinzugefügt. – Dieses Feld gibt an, welcher Partei die Aufgabe(n) zur Erledigung dieses Auftrags/Tickets zugewiesen ist/sind. – Dieses Feld wird ausschließlich von Gridsz ausgefüllt. – Der Wert kann von Gridsz aktualisiert werden, falls der Auftrag/das Ticket neu zugewiesen wird. Für den ActiveEquipmentEndpoint und den ActiveEquipmentEndpointMulti ist das Feld 'row' nicht mehr erforderlich. – Da die Zeile oft nicht zur Ausführung der Arbeit benötigt wird, wurde die Validierung gelockert. – Zusätzlich ist das Feld nun auf 'nullable' gesetzt. |
| 1.28.1 | 08-01-2026 | Für das Kontaktpersonenschema sind die Felder lastName und phoneNumber nicht mehr erforderlich. – Dies unterstützt eine breitere Palette von Kontaktszenarien, in denen vollständige persönliche Daten nicht verfügbar oder notwendig sind. – Es gibt nun kein Pflichtfeld mehr für die Kontaktperson – jedes Feld kann bei Relevanz und Verfügbarkeit bereitgestellt und aktualisiert werden. Das Objekt networkDiscrepancyInfo wird zu taskInfo hinzugefügt. – Dadurch kann der neue Aufgabentyp NETWORK_DISCREPANCY erstellt werden – der eine (potenzielle) Differenz zwischen Administration und physischer Realität aufzeigt. Ein neuer Endpunkt mit dem Tag taskSearch wird hinzugefügt. – Dieser Endpunkt kann verwendet werden, um Aufgaben anhand einer bestimmten Adresse oder Verbindung zu finden. Weitere kleinere Änderungen, die bereits live sind: Ein neuer Endpunkt für OAuth2 unter dem Tag authorization wird hinzugefügt. – Gridsz führt OAuth2 schrittweise für alle Gridsz APIs ein – dies wird später im großen Umfang kommuniziert. – Wichtig: Bestehende Bearer-Tokens bleiben bis zum Ablauf gültig. Das Zeichen $ wird nun für den AddressCode akzeptiert. Bugfix: Gridsz wird nun die reasons[]-Daten beim Status PROVIDED korrekt ausfüllen. |
| 1.27.4 | 13-11-2025 | Das Feld sendImpactNotification wird unter incidentInfo hinzugefügt. – Dieses optionale boolesche Feld gibt an, ob IMPACT_NOTIFICATION-Aufgabentypen von Gridsz erstellt werden dürfen. – Standardmäßig gilt: Wenn serviceAffecting = false, dann sendImpactNotification = false, und umgekehrt für true. |
| 1.27.3 | 02-10-2025 | Das Objekt linkedTasks verfügt nun über drei zusätzliche Felder: subStatus, addressCode, reasons [Array]. – Diese zusätzlichen Daten sollen weitere Einblicke in den Status verknüpfter Aufgaben geben. |
| 1.27.2 | 02-10-2025 | Das Feld networkType hat nun den Standardwert “FIBER“. – Dies gilt nur für neu erstellte Aufgaben, bei denen der Wert initial bei der Erstellung gesetzt wird. – Bestehende Aufgaben sind davon nicht betroffen und behalten ihren aktuellen networkType bei (auch wenn dieser null ist). |
| 1.27.1 | 03-04-2025 | Änderungen an den linkedTasks auf Root-Ebene vorgenommen. – Das taskType-Feld wird nun gemäß den Enum-Werten validiert. – Folgende Felder wurden hinzugefügt: mainStatus, planned, orgId Die linkedTasks werden nun auch proaktiv von Gridsz genutzt, indem Aufgaben, die miteinander in Beziehung stehen, aber nicht aus demselben Auftrag / Ticket stammen, automatisch verknüpft werden. Zum Beispiel: Wenn eine INSTALL-Aufgabe für eine Adresse erstellt wird, die bereits eine offene FTU_CHANGE-Aufgabe hat. Durch die Verknüpfung dieser Aufgaben und die Anzeige wichtiger Daten, wie des Status, erhalten die beteiligten Parteien einen guten Überblick. |
| 1.27.0 | 20-03-2025 | Gridsz kann nun Multi-Faser-Bestellungen unterstützen. – Das bedeutet, es ist möglich, mehrere Fasern, die zu einer einzigen Verbindung gehören, in einem Auftrag bereitzustellen. Zum Beispiel die Erstellung eines INSTALL-Auftrags und die Anforderung von sowohl Faser 1 als auch Faser 2. – Um dies zu unterstützen, haben wir die folgenden neuen Objekte zur API hinzugefügt: PoPMultiInfo / HASMultiInfo / ConnectionMultiInfo Diese Felder werden nur gefüllt, wenn der Netzwerkeigentümer oder aktive Betreiber eine Multi-Faser-Verbindung in ihrem Auftrag anfordert, indem mehrere Fasern bereitgestellt werden. Dies bedeutet, dass für die überwiegende Mehrheit der Gridsz-Benutzer und -Systeme diese Felder niemals gefüllt werden! |
| 1.26.9 | 06-03-2025 | Das Feld externalCorrelationId wurde auf Root-Ebene hinzugefügt. – Dieses Feld kann bei der Erstellung eines neuen Auftrags angegeben werden. – Das Feld kann nicht aktualisiert werden. – Es ist ein optionales Feld zur Angabe. – Das Feld kann vom Anforderer ausgefüllt werden, um eine Aufgabe aus seinem internen System mit der Gridsz-Aufgabe zu korrelieren. |
OutTask API
Die OutTask API ist für Organisationen gedacht, die Aufgaben erhalten, die sie ausführen müssen. Dies kann Auftragnehmer betreffen, die Patch-Anfragen erhalten, NOCs, die Netzwerkstörungen weiter untersuchen, und so weiter.
Versionshinweise
| Version | Veröffentlichungsdatum | Hinweise |
|---|---|---|
| 1.35.0 | 05.06.2026 | Die maximale Länge des Feldes „Mose.Shared.Models.ActiveOperatorTask.deadlines.name“ von 3–99 auf 3–50 ändern und das Attribut „required“ aus „ActiveOperatorTaskSync.MainStatus“ entfernen, um es an das aktuelle Verhalten anzupassen |
| 1.34.0 | 05.05.2026 | Ändere „taskInfo → hasInfo → afterConnect → (deliveredFTUType und deliveredConnectionStatus)“ von „Erforderlich“ in „Optional“ |
| 1.33.0 | 02-04-2026 | Das Feld outTaskCount dem Taskset hinzufügen |
| 1.31.0 | 05-03-2026 | – POP-Informationen zu Task-Info hinzufügen – Produktions-URL auf api.task.gridsz.com aktualisieren |
| 1.29.0 | 05-02-2026 | – Kontaktdaten dem Root-Objekt hinzufügen – Koordinaten zu afterConnect hinzufügen |
| 1.28.0 | 22-01-2026 | Für den ActiveEquipmentEndpoint und den ActiveEquipmentEndpointMulti ist das Feld 'row' nicht mehr erforderlich. – Da die Zeile oft nicht zur Ausführung der Arbeit benötigt wird, wurde die Validierung gelockert. – Zusätzlich ist das Feld nun auf 'nullable' gesetzt. |
| 1.27.0 | 08-01-2025 | Für das Kontaktpersonenschema sind die Felder lastName und phoneNumber nicht mehr erforderlich – Dies unterstützt eine breitere Palette von Kontaktszenarien, in denen vollständige persönliche Daten nicht verfügbar oder notwendig sind – Es gibt nun kein Pflichtfeld mehr für die Kontaktperson – jedes Feld kann bei Relevanz und Verfügbarkeit bereitgestellt und aktualisiert werden Das Objekt networkDiscrepancyInfo wird zu taskInfo hinzugefügt – Dadurch kann der neue Aufgabentyp NETWORK_INCONSISTENCY empfangen werden – der eine (potenzielle) Diskrepanz zwischen der Administration und der physischen Realität aufzeigt. Das Feld coaxPathDescription wird zum TechnicalPath hinzugefügt – Dieses Feld wird von Gridsz für COAX-Aufgaben basierend auf den verfügbaren Daten in Availability gefüllt Weitere kleinere Änderungen, die bereits live sind: Ein neuer Endpunkt für OAuth2 wird unter dem Tag authorization hinzugefügt – Gridsz führt OAuth2 schrittweise für alle Gridsz APIs ein – dies wird später umfassend kommuniziert – Wichtig: Bestehende Bearer-Tokens bleiben bis zum Ablauf gültig Das Zeichen $ wird nun für den AddressCode akzeptiert |
| 1.25.3 | 02-10-2025 | Das Objekt linkedTasks verfügt nun über drei zusätzliche Felder: subStatus, addressCode, reasons [Array]. – Diese zusätzlichen Daten sollen weitere Einblicke in den Status verknüpfter Aufgaben geben. |
| 1.25.2 | 26-06-2025 | Das Feld externalCorrelationId wurde auf Root-Ebene hinzugefügt – Dieses Feld kann nur von der Partei bereitgestellt werden, die den Auftrag erstellt (InTask). – Das Feld kann nicht aktualisiert werden. – Es ist ein optionales Feld zur Angabe. – Das Feld kann vom Anforderer ausgefüllt werden, um eine Aufgabe aus seinem internen System mit der Gridsz-Aufgabe zu korrelieren. |
| 1.25.1 | 03-04-2025 | Änderungen an den linkedTasks auf Root-Ebene vorgenommen. – Das taskType-Feld wird nun gemäß den Enum-Werten validiert. – Folgende Felder wurden hinzugefügt: mainStatus, planned, orgId Die linkedTasks werden nun auch proaktiv von Gridsz genutzt, indem Aufgaben, die miteinander in Beziehung stehen, aber nicht aus demselben Auftrag / Ticket stammen, automatisch verknüpft werden. Zum Beispiel: Wenn eine INSTALL-Aufgabe für eine Adresse erstellt wird, die bereits eine offene FTU_CHANGE-Aufgabe hat. Durch die Verknüpfung dieser Aufgaben und die Anzeige wichtiger Daten, wie des Status, erhalten die beteiligten Parteien einen guten Überblick. |
| 1.25.0 | 20-03-2025 | Ein isPrivate Boolean wurde zu Labels hinzugefügt – Standardmäßig ist ein Label nicht privat. |
| 1.24.0 | 06-03-2025 | Gridsz kann nun Multi-Faser-Aufträge unterstützen. – Das bedeutet, es ist möglich, mehrere Fasern, die zu einer einzigen Verbindung gehören, in einer Aufgabe zu empfangen. Zum Beispiel den Empfang von Faser 1 und Faser 2 für eine FTU_CONSTRUCT-Aufgabe. Hinweis: PATCH-basierte Aufgaben betreffen immer nur eine Faser gleichzeitig, was bedeutet, dass es möglich ist, zwei PATCH_INSTALLs in einem Taskset zu haben. – Um dies zu unterstützen, haben wir die folgenden neuen Objekte zur API hinzugefügt: PoPMultiInfo / HASMultiInfo / ConnectionMultiInfo Diese Felder werden nur gefüllt, wenn der Netzwerkeigentümer oder aktive Betreiber eine Multi-Faser-Verbindung in ihrem Auftrag anfordert, indem mehrere Fasern bereitgestellt werden. Dies bedeutet, dass für die überwiegende Mehrheit der Gridsz-Benutzer und -Systeme diese Felder niemals gefüllt werden! |