Met de workflowfunctionaliteit van de module Orderverwerking kunnen de volgende soorten taken worden aangemaakt:
- Installeer
- Beëindig
- Verbindingsincident
- Netwerkincident
- Telco migreren
- Migreren
- ONT installeren
InTask en OutTask
Gridsz gebruikt de termen InTask en OutTask om de inkomende en uitgaande taken te onderscheiden.
Een InTask is een opdracht aangemaakt door de actieve operator. Deze opdracht wordt via de GRIDSZ API en portal geleverd aan een Opdrachtnemer partij. Afhankelijk van het type InTask dat is aangemaakt, wordt de taak toegewezen aan de partij die door de passieve operator is aangewezen om het werk uit te voeren. Een InTask kan een SLA-overeenkomst hebben die zichtbaar is op de GUI. Elke InTask heeft zijn eigen identieke DHID-nummer, verbindings-ID en zoekcode. Deze identieke identificatienummers zijn gelijkwaardig voor de InTask en de OutTask.
Een OutTask is een takenverzameling die door Gridsz wordt gemaakt op basis van een InTask-opdracht zoals ontvangen door de actieve operator. De OutTask verschijnt in het portaal en de API van de ontvangende partij. Elke OutTask bevat details die nodig zijn voor de uitvoerder om het werk uit te voeren en toont metadata van de opdracht, zoals de status van de opgenomen taken, de SLA-status, de aanmaak- en laatst bijgewerkte datum, prioriteit en contactgegevens van de klant indien van toepassing.
Installeer
De Install taskset bevat altijd een standaard taak van een Patch_Install voor de PoP, en mogelijk een FTU_Construct of FTU_Reconstruct voor in het huis van de eindgebruiker.
Het type FTU dat geplaatst moet worden is een vrije tekst die rechtstreeks door de Operator wordt opgegeven. Gridsz gaat ervan uit dat de aannemer op de hoogte is van de types FTU die kunnen worden aangevraagd.
In bepaalde situaties is er al een FTU bij de eindgebruiker thuis, waarin alleen een patch_install taak zal worden toegewezen aan de aannemer. Het is ook mogelijk dat de verstrekte FTU door de actieve operator verschilt van de huidige FTU bij de eindgebruiker thuis, waarbij een FTU_Reconstruct taak zal worden toegewezen aan de aannemer.
Voor de installatie van een verbinding is altijd een patch nodig. De aannemer wordt gevraagd om een patch te plaatsen tussen het opgegeven passieve eindpunt en het opgegeven actieve eindpunt. Hierbij wordt het passieve eindpunt gevuld door Gridsz, terwijl de actieve operator het actieve eindpunt levert.
Afhankelijk van het PoP-type kan de actieve apparatuur een poort zijn op actieve apparatuur of een poort op een patchpaneel.
Beëindig
Een Terminate TaskSet kan alleen worden aangemaakt op adressen die eerder met succes zijn afgeleverd via een Install TaskSet. Als een actieve operator dus een Beëindig opdracht aanmaakt op een adres dat niet verbonden is, wordt de Beëindig opdracht geweigerd.
De Actieve Operator moet ook het Actieve Eindpunt geven op een Beëindig order, waarop het adres op dat moment is aangesloten, om ervoor te zorgen dat de contractor het meest recente Actieve Eindpunt ontvangt om zijn werk uit te voeren.
Op basis van de standaardconfiguratie van een Terminate TaskSet wordt alleen een PATCH_REMOVE OutTask aangemaakt voor de Contractors om uit te voeren. Dit betekent dat er geen FTU-gerelateerde taak is.
Verbindingsincident
Een verbindingsincident betekent dat een enkele verbinding down is. In dit geval krijgt de gespecificeerde aannemer het incidentticket toegewezen om het probleem te onderzoeken en waar mogelijk op te lossen. Verbindingsincidenten zijn altijd een Prio 4. Met dit type taak krijgt de aannemer een verzoek om een enkel incident op een verbinding op te lossen.
De toegewezen aannemer kan onderzoek doen naar het incident en het probleem oplossen. Om het incident op te lossen moet de aannemer een redencode geven aan de taak:
DLV-01: Probleem gevonden in Active Operator Domain
DLV-02: Probleem gevonden in Customer Domain
DLV-03: Probleem gevonden in het ondergrondse passieve domein
DLV-04: Probleem gevonden in PoP Passive Domain
DLV-05: Geen probleem gevonden (na onderzoek ok)
DLV-99: overig + toelichting
Netwerkincident
Een netwerkincident betreft een fout die invloed heeft op meerdere afzonderlijke verbindingen. Dit betekent dat één incident invloed heeft op ten minste N verbindingen. Waarbij N verschillend kan zijn per Active Operator. Standaardwaarde voor N = 48. Bijvoorbeeld een complete PoP is down of een hoofdkabel van de backbone is doorgesneden. Met dit taaktype ontvangt de aannemer een verzoek om een netwerkstoring op te lossen (dit kan ook een storing in de stadsring zijn).
De toegewezen aannemer kan onderzoek doen naar het incident en het probleem oplossen. Om het incident op te lossen moet de aannemer een redencode geven aan de taak:
DLV-01: Probleem gevonden in Active Operator Domain
DLV-02: Probleem gevonden in Customer Domain
DLV-03: Probleem gevonden in het ondergrondse passieve domein
DLV-04: Probleem gevonden in PoP Passive Domain
DLV-05: Geen probleem gevonden (na onderzoek ok)
DLV-99: overig + toelichting
Telco migreren
Het taaktype Migreren is om een eindgebruiker te migreren van de ene Active Operator naar de andere, ook bekend als een Telco Migratie.
De taak Migreren lijkt erg op de taak Patch installeren, maar er is een belangrijk verschil. Bij het plaatsen van een patch moet de opdrachtnemer aannemen dat de gespecificeerde passieve positie (ODF-lade en positie) nog steeds bezet is door de patch van de donoroperator. Als zodanig wordt de taak het verwijderen van de donoroperator-patch en het installeren van de ontvangende operator-patch zoals gespecificeerd in de Taakset.
Afhankelijk van het feit of het dezelfde aangevraagde vezel is, zal het ofwel een PATCH_MIGRATE of een PATCH_INSTALL en een PATCH_REMOVE zijn. Er kan ook een FTU_RECONSTRUCT zijn als de gewenste FTU verschilt van de huidige FTU op het adres. Alle andere vezels die in gebruik zijn, worden ook gedepatcht, wat resulteert in een PATCH_REMOVE.
Bij een Telco-migratie moet de donor Active Operator altijd worden geïnformeerd over de migratie. Ongeacht of het een PATCH_MIGRATE is of een afzonderlijke PATCH_INSTALL en PATCH_REMOVE.
Voordat een migratietaak wordt geaccepteerd, doorloopt deze een Clean order check. Binnen dit proces worden ook specifiek de vereisten voor de migratie gecontroleerd. Zo wordt gecontroleerd of de passieve poort in gebruik is. Als deze controle mislukt, wordt de migratieopdracht geweigerd. Daarnaast wordt, net als bij alle andere soorten taken, een migratieorder geweigerd als er al een taak actief is op het gevraagde adres.
Verder moet bij alle Migratiegevallen de Wensdatum ook worden gebruikt als de Plandatum. Dit betekent dat de Opdrachtnemer de opgegeven Wensdatum op alle POP gerelateerde TASKS moet zetten. Een uitzondering hierop zijn adressen met twee aangesloten fibers, waarbij de niet aangesloten fiber desgewenst later ingepland kan worden, maar over het algemeen wel gelijktijdig zal plaatsvinden.
Indien aanwezig kan de FTU_RECONSTRUCT worden uitgevoerd vanaf een andere datum dan is opgegeven in de Wishdate. Bovendien is er geen harde eis of de FTU_RECONSTRUCT voor of na de patchmigratie moet worden uitgevoerd.
In zeldzame gevallen waarbij de Fiber is gemigreerd, maar de PATCH_REMOVE op de niet langer gebruikte Fiber is mislukt, wordt de migratieopdracht nog steeds als succesvol beschouwd. De mislukte PATCH_REMOVE wordt gezien als een afzonderlijk incident.
| Titel | Gebruikersverhaal | Opmerkingen |
|---|---|---|
| Snel omschakelen | De eindklant moet zo snel mogelijk worden losgekoppeld | Alle voorbereidingstaken moeten van tevoren succesvol zijn afgerond |
| Uitvoeringsdatum | De ontkoppeling en herverbinding moeten precies op het geplande tijdstip plaatsvinden | De wensdatum wordt gebruikt als exacte planningsdatum |
| Slechts 1 vezel actief | Als AO wil ik exclusieve toegang hebben tot de HAS. Na MIGRATE moet alleen mijn 1 vezel verbonden zijn met de HAS. | AO huurt beide vezels in de kabel naar de HAS. |
| Geen andere taken | Als een MIGRATE wordt opgedragen en er is een andere InTask actief op de verbinding, dan wordt de taak geweigerd. | Kan later worden verbeterd tot lease grof |
| AEE moet veranderen | WANNEER een eindklant overstapt van zijn huidige SP naar een nieuwe SP EN de nieuwe SP gebruikt de AO EN die AO blijft dezelfde AEE gebruiken voor de verbinding DAN mag de AO geen TELCO_MIGRATE-taak sturen EN als hij dat toch doet, moet g.Task die foutieve TELCO_MIGRATE-taak weigeren. | AEE en vorige AEE mogen niet hetzelfde zijn. De AO zou de verbinding met de eindklant kunnen verbreken omdat hij een donorbericht van Task krijgt waarin staat dat de verbinding bezet is. |
Migreren
De PORT_MIGRATE TASK is het migreren van een verbinding voor een ISP naar een andere Active Equipment Endpoint poort in de PoP. Bij deze migratie blijven de Active Operator en Service Provider dezelfde. De aangesloten vezel wordt verplaatst van de ene poort naar de andere en of van de ene module naar de andere. De ISP blijft hetzelfde bij een Port Migrate, dus er wordt geen indicatie van een migratie op voorhand gegeven aan de actieve ISP.
PORT_MIGRATE is een TASK die een wijziging vraagt in de actieve PORT en/of MODULE van de Active AO waarbij een nieuwe Patch moet worden aangemaakt. De details van het actieve eindpunt worden bijgewerkt door de AO bij het aanmaken van een PORT_MIGRATE taak, door deze informatie in te vullen in de Active endpoint velden.
De nieuwe poort- en/of modulegegevens worden bijgewerkt naar AC zodra de taak is ingesteld op de status DELIVERD.
ONT installeren
Het taaktype ONT_INSTALL wordt gegenereerd voor een aannemer om een ONT te installeren in het huis van een eindgebruiker. Er is geen specifiek taaktype voor de activering van de ONT. Gridsz gaat ervan uit dat de aannemer op de hoogte is van het te gebruiken ONT-type. Als er verdere instructies nodig zijn, kunnen deze door de AO/ISP in de commentaarsectie worden geplaatst.
Het taaktype ONT install is een optioneel OutTask-type voor de Install-opdracht. Wanneer de ISP/AO een nieuwe Install-taak maakt voor een specifiek adres, kunnen ze de optie selecteren om een ONT_Install-taak te maken in deze volgorde.
Wanneer een installatieopdracht wordt gemaakt, controleert Gridsz de gegevens in AC om de juiste outtask types voor te bereiden. Een installatieopdracht bevat altijd een Patch_install. Als er geen FTU aanwezig is, zal een installatieopdracht ook een FTU_construct aanmaken.
Als er al een FTU aanwezig is, maar het "te zijn" FTU-type verschilt van het huidige FTU-type, zal de outtask set een FTU_Replacement bevatten, in plaats van een FTU_construct.
Om de status van een ONT_INSTALL taak bij te werken, moet het plaatje verplicht worden ingevuld.
Schematisch zijn dit de twee scenario's:
| Scenario | Acties |
| ONT_Installeren Nee |
De taak Nieuwe installatie maakt
Als er geen FTU aanwezig is, wordt er een nieuwe installatietaak gemaakt:
Als er een verkeerde FTU aanwezig is, zal de nieuwe installatietaak het volgende creëren
De Installatietaak volgt de normale statusstroom |
| ONT_Installeren Ja |
De taak Nieuwe installatie maakt
Als er geen FTU aanwezig is, wordt er een nieuwe installatietaak gemaakt:
Als er een verkeerde FTU aanwezig is, wordt er een nieuwe installatietaak aangemaakt:
|