Die Workflow-Funktionalität des Moduls Auftragsabwicklung ermöglicht die Erstellung der folgenden Aufgabentypen:
- Installieren Sie
- Beenden Sie
- Verbindung Vorfall
- Netzwerk-Vorfall
- Telco Migrate
- Hafenmigration
- ONT-Installation
InTask und OutTask
Gridsz verwendet die Begriffe InTask und OutTask, um die eingehenden und ausgehenden Aufgaben zu unterscheiden.
Ein InTask ist ein vom aktiven Betreiber erstellter Auftrag. Dieser Auftrag wird über die GRIDSZ API und das Portal an einen Auftragnehmer übermittelt. Je nach Art der erstellten InTask wird die Aufgabe der Partei zugewiesen, die vom passiven Betreiber mit der Ausführung der Arbeit beauftragt wurde. Eine InTask kann eine SLA-Vereinbarung haben, die in der GUI sichtbar ist. Jede InTask hat eine eigene identische DHID-Nummer, Verbindungs-ID und Suchcode. Diese identischen Identifikationsnummern sind für die InTask und die OutTask gleich.
Ein OutTask ist ein Aufgabensatz, der von Gridsz auf der Grundlage eines InTask-Auftrags erstellt wird, den der aktive Betreiber erhalten hat. Die OutTask erscheint im Portal und in der API der empfangenden Partei. Jede OutTask enthält Details, die der Auftragnehmer für die Ausführung der Arbeit benötigt, und zeigt Metadaten des Auftrags, wie den Status der enthaltenen Aufgaben, den SLA-Status, das Erstellungs- und das letzte Aktualisierungsdatum, die Priorität und ggf. die Kontaktdaten des Kunden.
Installieren Sie
Das Taskset Install enthält immer eine Standardaufgabe Patch_Install für den PoP und möglicherweise FTU_Construct oder FTU_Reconstruct für im Haus des Endbenutzers.
Der Typ des zu platzierenden FTU ist ein freier Text, der direkt vom Betreiber angegeben wird. Gridsz geht davon aus, dass der Auftragnehmer die Arten von FTU, die angefordert werden können, kennt.
In bestimmten Situationen gibt es bereits ein FTU beim Endbenutzer, bei dem dem Auftragnehmer nur eine Aufgabe patch_install zugewiesen wird. Es ist auch möglich, dass die vom aktiven Betreiber bereitgestellte FTU von der aktuellen FTU beim Endbenutzer abweicht, so dass dem Auftragnehmer eine Aufgabe FTU_Reconstruct zugewiesen wird.
Bei der Installation einer Verbindung ist immer ein Patch erforderlich. Der Auftragnehmer wird gebeten, einen Patch zwischen dem angegebenen passiven Endpunkt und dem angegebenen aktiven Endpunkt zu platzieren. Dabei wird der passive Endpunkt von Gridsz gefüllt, während der aktive Endpunkt vom aktiven Betreiber bereitgestellt wird.
Je nach PoP-Typ kann das aktive Gerät ein Port an einem aktiven Gerät oder ein Port an einem Patchpanel sein.
Beenden Sie
Ein Terminate TaskSet kann nur für Adressen erstellt werden, die zuvor erfolgreich über ein Install TaskSet zugestellt wurden. Wenn also ein aktiver Operator einen Terminate-Auftrag für eine Adresse erstellt, die nicht verbunden ist, wird der Terminate-Auftrag verweigert.
Der aktive Betreiber muss auch bei einem Terminate-Auftrag den aktiven Endpunkt angeben, mit dem die Adresse derzeit verbunden ist, um sicherzustellen, dass der Auftragnehmer den neuesten aktiven Endpunkt erhält, um seine Arbeit durchzuführen.
Basierend auf der Standardkonfiguration eines Terminate TaskSet wird nur ein PATCH_REMOVE OutTask für die Auftragnehmer zur Ausführung erstellt. Dies bedeutet, dass es keine FTU-bezogene Aufgabe gibt.
Verbindung Vorfall
Ein Verbindungszwischenfall bedeutet, dass eine einzelne Verbindung ausgefallen ist. In diesem Fall erhält der angegebene Auftragnehmer das Incident-Ticket, um das Problem zu untersuchen und nach Möglichkeit zu lösen. Verbindungsvorfälle sind immer eine Prio 4. Bei diesem Aufgabentyp erhält der Auftragnehmer den Auftrag, eine einzelne Störung an einer Verbindung zu beheben.
Der beauftragte Auftragnehmer kann den Vorfall untersuchen und das Problem beheben. Um den Vorfall zu beheben, muss der Auftragnehmer einen Grundcode für die Aufgabe angeben:
DLV-01: Problem in der Active Operator Domain gefunden
DLV-02: Problem in der Customer Domain gefunden
DLV-03: Problem in der passiven Domäne "Underground" gefunden
DLV-04: Problem im passiven Bereich des PoP gefunden
DLV-05: Kein Problem gefunden (nach Untersuchung ok)
DLV-99: Sonstiges + Klärung
Netzwerk-Vorfall
Eine Netzwerkstörung betrifft eine Störung, die mehrere Einzelverbindungen betrifft. Diese Störung bedeutet, dass eine Störung Auswirkungen auf mindestens N Verbindungen hat. Wobei N pro Active Operator unterschiedlich sein kann. Standardwert für N = 48. Zum Beispiel ist ein kompletter PoP ausgefallen oder ein Hauptkabel des Backbones wurde durchtrennt. Bei diesem Aufgabentyp erhält der Auftragnehmer einen Auftrag zur Behebung eines Netzausfalls (dies könnte auch ein Ausfall im City-Ring sein).
Der beauftragte Auftragnehmer kann den Vorfall untersuchen und das Problem beheben. Um den Vorfall zu beheben, muss der Auftragnehmer einen Grundcode für die Aufgabe angeben:
DLV-01: Problem in der Active Operator Domain gefunden
DLV-02: Problem in der Customer Domain gefunden
DLV-03: Problem in der passiven Domäne "Underground" gefunden
DLV-04: Problem im passiven Bereich des PoP gefunden
DLV-05: Kein Problem gefunden (nach Untersuchung ok)
DLV-99: Sonstiges + Klärung
Telco Migrate
Der Aufgabentyp Migrieren dient dazu, einen Endbenutzer von einem aktiven Betreiber zu einem anderen zu migrieren, auch bekannt als Telco-Migration.
Die Migrationsaufgabe ist der Patch-Installation sehr ähnlich, doch gibt es einen wichtigen Unterschied. Beim Einfügen eines Patches muss der Auftragnehmer davon ausgehen, dass die angegebene passive Position (ODF-Schublade und -Position) noch vom Patch des abgebenden Betreibers belegt ist. Die Aufgabe besteht also darin, den Patch des abgebenden Betreibers zu entfernen und den Patch des empfangenden Betreibers wie im TaskSet angegeben zu installieren.
Je nachdem, ob es sich um dieselbe angeforderte Faser handelt, ist es entweder ein PATCH_MIGRATE oder ein PATCH_INSTALL und ein PATCH_REMOVE. Potenziell kann es auch zu einem FTU_RECONSTRUCT kommen, wenn die gewünschte FTU nicht mit der aktuellen FTU an der Adresse übereinstimmt. Jede andere verwendete Faser wird ebenfalls de-patched, was zu einem PATCH_REMOVE führt.
Bei einer Telco-Migration muss der abgebende Active Operator immer über die Migration informiert werden. Unabhängig davon, ob es sich um eine PATCH_MIGRATE oder eine separate PATCH_INSTALL und PATCH_REMOVE handelt.
Bevor ein Migrationsauftrag angenommen wird, durchläuft er eine Prüfung auf eine saubere Reihenfolge. Im Rahmen dieses Prozesses werden auch die Migrationsanforderungen geprüft. So wird geprüft, ob der Passive Port verwendet wird. Falls diese Prüfung fehlschlägt, wird der Migrationsauftrag abgelehnt. Wie bei allen Aufgabentypen wird auch ein Migrationsauftrag verweigert, wenn auf der angeforderten Adresse bereits eine Aufgabe aktiv ist.
Außerdem sollte in allen Migrationsfällen das Wunschdatum auch als Plandatum verwendet werden. Das bedeutet, dass der Auftragnehmer das angegebene Wunschdatum auf alle POP-bezogenen AUFGABEN setzen muss. Eine Ausnahme bilden Adressen mit zwei angeschlossenen Fasern, bei denen die nicht geschenkte Faser auf Wunsch später geplant werden kann, aber in der Regel zum gleichen Zeitpunkt übereinstimmen wird.
Falls vorhanden, kann der FTU_RECONSTRUCT ab einem anderen Datum als dem im Wunschdatum angegebenen ausgeführt werden. Außerdem gibt es keine feste Vorgabe, ob die FTU_RECONSTRUCT vor oder nach der Patch-Migration abgeschlossen werden muss.
In seltenen Fällen, in denen die Glasfaser migriert wird, aber der PATCH_REMOVE auf der nicht mehr verwendeten Glasfaser fehlschlägt, wird der Migrationsauftrag dennoch als erfolgreich angesehen. Der fehlgeschlagene PATCH_REMOVE wird als separater Vorfall gewertet.
| Titel | Anwenderbericht | Anmerkungen |
|---|---|---|
| Schneller Wechsel | Der Endkunde sollte so schnell wie möglich vom Netz getrennt werden. | Alle Vorbereitungsaufgaben müssen vorher erfolgreich abgeschlossen werden |
| Datum der Ausführung | Das Trennen und Wiederverbinden muss genau zum geplanten Zeitpunkt erfolgen. | Wunschdatum wird als genaues Plandatum verwendet |
| Nur 1 Faser aktiv | Als AO möchte ich exklusiven Zugang zum HAS haben. Nach MIGRATE sollte nur meine 1 Faser mit dem HAS verbunden sein. | AO vermietet beide Fasern im Kabel an das HAS. |
| Keine anderen Aufgaben | Wenn ein MIGRATE bestellt wird und eine andere InTask auf der Verbindung aktiv ist, wird die Aufgabe verweigert. | Kann später verbessert werden, um grob geleast zu werden |
| AEE muss sich ändern | WENN ein Endkunde von seinem derzeitigen SP zu einem neuen SP wechselt UND der neue SP die AO verwendet UND diese AO weiterhin dieselbe AEE für die Verbindung verwendet, DANN sollte die AO keine TELCO_MIGRATE-Aufgabe senden UND wenn die AO es trotzdem tut, muss g.Task diese fehlerhafte TELCO_MIGRATE-Aufgabe zurückweisen | Die AEE und die vorherige AEE dürfen nicht identisch sein. Die AO könnte die Verbindung zum Endkunden unterbrechen, da sie von Task eine Spendermeldung erhält, dass die Verbindung belegt ist. |
Hafenmigration
Der PORT_MIGRATE TASK dient dazu, eine Verbindung für einen ISP zu einem anderen Active Equipment Endpoint Port im PoP zu migrieren. Bei dieser Migration bleiben der aktive Operator und der Service Provider gleich. Die angeschlossene Faser wird von einem Port zu einem anderen und/oder von einem Modul zu einem anderen verschoben. Der ISP bleibt bei einer Portmigration derselbe, so dass der aktive ISP keinen Hinweis auf eine Migration erhält.
PORT_MIGRATE ist eine AUFGABE, die eine Änderung des aktiven PORTs und/oder MODULEs des aktiven AO anfordert, wobei ein neuer Patch erstellt werden muss. Die Details des aktiven Endpunkts werden von der AO beim Erstellen einer PORT_MIGRATE-Aufgabe aktualisiert, indem diese Informationen in die Felder des aktiven Endpunkts eingetragen werden.
Die neuen Anschluss- und/oder Moduldaten werden auf AC aktualisiert, sobald die Aufgabe auf den Status DELIVERD gesetzt wird.
ONT-Installation
Der Aufgabentyp ONT_INSTALL wird für einen Auftragnehmer generiert, der einen ONT im Haus eines Endbenutzers installiert. Es gibt keinen spezifischen Aufgabentyp für die Aktivierung des ONTs. Gridsz geht davon aus, dass dem Auftragnehmer der zu verwendende ONT-Typ bekannt ist. Falls weitere Anweisungen erforderlich sind, können diese vom AO/ISP im Kommentarbereich angegeben werden.
Der Aufgabentyp ONT-Install ist ein optionaler OutTask-Typ für den Install-Auftrag. Wenn der ISP/AO eine neue Installationsaufgabe für eine bestimmte Adresse erstellt, kann er die Option wählen, eine ONT_Install-Aufgabe in diesem Auftrag zu erstellen.
Wenn ein Installationsauftrag erstellt wird, prüft Gridsz die Daten in AC, um die richtigen Aufgabentypen vorzubereiten. Ein Installationsauftrag enthält immer einen Patch_install. Wenn keine FTU vorhanden ist, wird bei einem Installationsauftrag auch ein FTU_construct erstellt.
Wenn bereits ein FTU vorhanden ist, aber der "zukünftige" FTU-Typ nicht mit dem aktuellen FTU-Typ übereinstimmt, enthält das Outtask-Set einen FTU_Replacement anstelle eines FTU_construct.
Um den Status einer ONT_INSTALL Aufgabe zu aktualisieren, muss das Feld ausgefüllt werden.
Schematisch gesehen sind dies die beiden Szenarien:
| Szenario | Aktionen |
| ONT_Install Nein |
Die Aufgabe Neue Installation erstellt
Wenn keine FTU vorhanden ist, wird eine neue Installationsaufgabe erstellt:
Wenn eine falsche FTU vorhanden ist, wird eine neue Installationsaufgabe erstellt
Die Installationsaufgabe folgt dem normalen Statusfluss |
| ONT_Installation Ja |
Die Aufgabe Neue Installation erstellt
Wenn keine FTU vorhanden ist, wird eine neue Installationsaufgabe erstellt:
Wenn eine falsche FTU vorhanden ist, wird eine neue Installationsaufgabe erstellt:
|