De Workflow API (voorheen bekend als TASK API) is een REST API die de OpenAPI specificaties volgt. De API kan worden gebruikt voor taken binnen zowel de module Order fulfilment als de module Service & incidenten, maar maakt onderscheid tussen inTask en outTask (links die verwijzen naar de Swagger UI).
De API maakt gebruik van het Equitri protocol om alle systemen synchroon te houden. Dit betekent dat er voor elke update een Indicatie is, gevolgd door een Fetch en afgesloten met een Sync. Dit betreft zowel updates die de organisatie aanbiedt aan Gridsz als updates die Gridsz aanbiedt aan de organisatie.
Hieronder vind je meer details en een visuele uitleg:
Om deze API te kunnen gebruiken, moet de organisatie een geconfigureerd Systeem en token hebben. Geef hiervoor de volgende gegevens op in een support - of configureer dit zelf in het beheerportaal als je sitebeheerder bent:
- Cluster - geeft aan voor welke clusters (netwerken) dit systeem kan worden gebruikt
- SystemID - de unieke ID per organisatie om het systeem te herkennen
- Eindpunt - het eindpunt waar alle API-aanroepen naartoe moeten gaan
- Token - het token dat door de organisatie is verstrekt (dit wordt door Gridsz gebruikt wanneer het systeemeindpunt wordt aangeroepen)
- Standaard eindpunt
Houd er bovendien rekening mee dat de API achter IP-whitelisting zit. Neem contact op met Gridsz support om IP-adressen te laten whitelisten, per omgeving.
inTask API
De InTask API is bedoeld voor organisaties die taken willen aanmaken. Dit kunnen Active Operators zijn die installatieorders aanmaken, Network Owners die POP-Incidenten aanmaken, enzovoort.
Release-opmerkingen
| Versie | Verschijningsdatum | Opmerkingen |
|---|---|---|
| 1.27.4 | 13-11-2025 | Het veld sendImpactNotification wordt toegevoegd onder incidentInfo. - Dit optionele booleaanse veld geeft aan of IMPACT_NOTIFICATION tasktypes mogen worden aangemaakt door Gridsz. - Standaard, als serviceAffecting = false dan is sendImpactNotification = false, en vice versa voor true. |
| 1.27.3 | 02-10-2025 | Het object linkedTasks heeft nu drie extra velden: subStatus, addressCode, reasons [array]. - Deze extra gegevens zijn bedoeld om extra inzicht te geven in de status van gerelateerde taken. |
| 1.27.2 | 02-10-2025 | Het veld networkType heeft nu een standaardwaarde van "FIBER". - Dit is alleen van toepassing op nieuwe taken die worden aangemaakt, waarbij de waarde aanvankelijk wordt ingesteld bij het aanmaken - Bestaande taken worden hierdoor niet beïnvloed en behouden hun huidige networkType (zelfs als het null is). |
| 1.27.1 | 03-04-2025 | Wijzigingen aangebracht in de linkedTasks op root-niveau. - Het taskType-veld wordt nu gevalideerd volgens Enum-waarden - De volgende velden toegevoegd: mainStatus, gepland, orgId De linkedTasks worden nu ook proactief gebruikt door Gridsz, door automatisch taken te koppelen die aan elkaar gerelateerd zijn, maar niet afkomstig zijn van dezelfde order/ticket Bijvoorbeeld: in het geval dat een INSTALL wordt aangemaakt op een adres dat al een open FTU_CHANGE-taak heeft. Door deze taken te koppelen en een aantal belangrijke gegevens te tonen, zoals de status, kunnen betrokken partijen een goed overzicht krijgen. |
| 1.27.0 | 20-03-2025 | Gridsz kan nu Multi Fiber orders support . - Dit betekent dat het mogelijk is om meerdere vezels behorende bij één verbinding in één order te leveren Bijvoorbeeld door een INSTALL order aan te maken en zowel Fiber 1 als Fiber 2 aan te vragen - Om dit support hebben we de volgende nieuwe objecten aan de API toegevoegd: PoPMultiInfo / HASMultiInfo / ConnectionMultiInfo Deze velden worden alleen gevuld als de Neteigenaar of Actieve Operators een multi-vezelverbinding op hun order aanvragen, door meerdere vezels aan te leveren Dit betekent dat voor een grote meerderheid van Gridsz en -systemen deze velden nooit gevuld zullen worden! |
| 1.26.9 | 06-03-2025 | Het veld externalCorrelationId is toegevoegd aan het hoofdniveau. - Dit veld kan worden ingevuld bij het maken van een nieuwe bestelling - Het veld kan niet worden bijgewerkt - Het is een optioneel veld om op te geven - Het veld kan worden ingevuld door de aanvrager om een taak uit hun interne systeem te correleren aan de Gridsz . |
outTask API
De OutTask API is bedoeld voor organisaties die taken ontvangen die ze moeten uitvoeren. Dit kan gaan om Aannemers die patchverzoeken ontvangen, NOC's die netwerkincidenten verder onderzoeken, enzovoort.
Release-opmerkingen
| Versie | Verschijningsdatum | Opmerkingen |
|---|---|---|
| 1.25.3 | 02-10-2025 | Het object linkedTasks heeft nu drie extra velden: subStatus, addressCode, reasons [array]. - Deze extra gegevens zijn bedoeld om extra inzicht te geven in de status van gerelateerde taken. |
| 1.25.2 | 26-06-2025 | Het veld externalCorrelationId is toegevoegd aan het hoofdniveau - Dit veld kan alleen worden ingevuld door de partij die de bestelling aanmaakt (InTask) - Het veld kan niet worden bijgewerkt - Het is een optioneel veld om op te geven - Het veld kan worden ingevuld door de aanvrager om een taak uit hun interne systeem te correleren aan de Gridsz . |
| 1.25.1 | 03-04-2025 | Wijzigingen aangebracht in de linkedTasks op root-niveau. - Het taskType-veld wordt nu gevalideerd volgens Enum-waarden - De volgende velden toegevoegd: mainStatus, gepland, orgId De linkedTasks worden nu ook proactief gebruikt door Gridsz, door automatisch taken te koppelen die aan elkaar gerelateerd zijn, maar niet afkomstig zijn van dezelfde order/ticket Bijvoorbeeld: in het geval dat een INSTALL wordt aangemaakt op een adres dat al een open FTU_CHANGE-taak heeft. Door deze taken te koppelen en een aantal belangrijke gegevens te tonen, zoals de status, kunnen betrokken partijen een goed overzicht krijgen. |
| 1.25.0 | 20-03-2025 | Een isPrivate Boolean toegevoegd aan Labels - Standaard is een label niet privé. |
| 1.24.0 | 06-03-2025 | Gridsz kan nu Multi Fiber orders support . - Dit betekent dat het mogelijk is om meerdere vezels te ontvangen die behoren tot één verbinding in één taak Bijvoorbeeld, het ontvangen van zowel vezel 1 als vezel 2 voor een FTU_CONSTRUCT Opmerking: de PATCH gebaseerde taken zullen altijd betrekking hebben op 1 vezel per keer, wat betekent dat het mogelijk is om twee PATCH_INSTALL's in één taakset te hebben - Om dit support , hebben we de volgende nieuwe objecten toegevoegd aan de API: PoPMultiInfo / HASMultiInfo / ConnectionMultiInfo Deze velden worden alleen gevuld als de Netwerkeigenaar of Actieve Operators een multi-vezelverbinding op hun order aanvragen, door meerdere vezels te leveren Dit betekent dat voor een grote meerderheid van Gridsz en systemen deze velden nooit gevuld zullen worden! |