Die Workflow-Funktionalität des Auftragsabwicklungsmoduls ermöglicht die Erstellung der folgenden Aufgabentypen:

• Installation
• Deaktivierung
• Verbindungsstörung
• Netzwerkstörung
• Telco-Migration
• Port-Migration
• ONT-Installation

InTask und OutTask

Gridsz verwendet die Begriffe InTask und OutTask zur Unterscheidung von eingehenden und ausgehenden Aufgaben.

Eine InTask ist ein Auftrag, der vom aktiven Betreiber erstellt wird. 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 zur Ausführung der Arbeiten bestimmt wurde. Eine InTask kann eine SLA-Vereinbarung haben, die auf der Benutzeroberfläche sichtbar ist. Jede InTask hat eine eigene identische DHID-Nummer, Verbindungs-ID und einen Suchcode. Diese identischen Identifikationsnummern sind für die InTask und die OutTask gleichwertig.

Eine OutTask ist ein Aufgabenpaket, das von Gridsz basierend auf einem vom aktiven Betreiber empfangenen InTask-Auftrag erstellt wird. Die OutTask wird im Portal und in der API der empfangenden Partei angezeigt. Jede OutTask enthält Details, die der Auftragnehmer zur Ausführung der Arbeiten benötigt, und zeigt Metadaten des Auftrags an, wie den Status der enthaltenen Aufgaben, den SLA-Status, das Erstellungs- und letzte Aktualisierungsdatum, die Priorität und gegebenenfalls die Kontaktdaten des Kunden.

Installation

Der Installations-Aufgabensatz enthält immer eine Standardaufgabe einer Patch_Install für den PoP, und potenziell eine FTU_Construct oder FTU_Reconstruct für im Haus des Endnutzers.

Der zu platzierende FTU-Typ ist ein Freitext, der direkt vom Betreiber angegeben wird. Gridsz geht davon aus, dass der Auftragnehmer die anfragbaren FTU-Typen kennt.

In bestimmten Situationen ist bereits eine FTU im Haus des Endnutzers vorhanden, wobei dem Auftragnehmer nur eine Patch_Install-Aufgabe zugewiesen wird. Es ist auch möglich, dass die vom aktiven Betreiber bereitgestellte FTU von der aktuellen FTU im Haus des Endnutzers abweicht, wobei dem Auftragnehmer eine FTU_Reconstruct-Aufgabe zugewiesen wird.

Für die 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 ausgefüllt, während der aktive Betreiber den aktiven Endpunkt bereitstellt.

Je nach PoP-Typ kann das aktive Equipment ein Port an aktiver Ausrüstung oder ein Port an einem Patchpanel sein.

Deaktivierung

Ein Deaktivierungs-Aufgabensatz kann nur für Adressen erstellt werden, die zuvor erfolgreich über einen Installations-Aufgabensatz bereitgestellt wurden. Wenn ein aktiver Betreiber einen Deaktivierungsauftrag für eine nicht verbundene Adresse erstellt, wird dieser abgelehnt.

Der aktive Betreiber muss bei einem Deaktivierungsauftrag auch den aktiven Endpunkt angeben, an dem die Adresse aktuell verbunden ist, um sicherzustellen, dass der Auftragnehmer den aktuellsten aktiven Endpunkt erhält, um seine Arbeit auszuführen.

Basierend auf der Standardkonfiguration eines Deaktivierungs-Aufgabensatzes wird nur eine PATCH_REMOVE OutTask für die Auftragnehmer zur Ausführung erstellt. Dies bedeutet, dass es keine FTU-bezogene Aufgabe gibt.

Verbindungsstörung

Eine Verbindungsstörung bedeutet, dass eine einzelne Verbindung ausgefallen ist. In diesem Fall wird dem spezifizierten Auftragnehmer das Störungsticket zugewiesen, um das Problem zu untersuchen und, wo möglich, zu beheben. Verbindungsstörungen haben immer Priorität 4. Mit diesem Aufgabentyp erhält der Auftragnehmer eine Anfrage zur Behebung einer einzelnen Störung an einer Verbindung.

Der beauftragte Auftragnehmer kann den Vorfall untersuchen und das Problem beheben. Zur Behebung des Vorfalls muss der Auftragnehmer einen Ursachencode für die Aufgabe angeben:

DLV-01: Problem in der Domäne des aktiven Betreibers gefunden
DLV-02: Problem in der Kundendomäne gefunden
DLV-03: Problem in der passiven Untergrunddomäne gefunden
DLV-04: Problem in der passiven PoP-Domäne gefunden
DLV-05: Kein Problem gefunden (nach Untersuchung in Ordnung)
DLV-99: Sonstiges + Erläuterung

Netzwerkstörung

Ein Netzwerkausfall bezieht sich auf eine Störung, die mehrere einzelne Verbindungen beeinträchtigt. Dieser Vorfall bedeutet, dass ein Ereignis mindestens N Verbindungen beeinflusst, wobei N pro aktivem Betreiber variieren kann. Der Standardwert für N beträgt 48. Beispiele hierfür sind der Ausfall eines kompletten PoP oder die Durchtrennung eines Hauptkabels im Backbone. Bei diesem Aufgabentyp erhält der Auftragnehmer eine Anfrage zur Behebung eines Netzwerkausfalls (dies könnte auch ein Ausfall im Stadtring sein).

Der beauftragte Auftragnehmer kann den Vorfall untersuchen und das Problem beheben. Zur Behebung des Vorfalls muss der Auftragnehmer einen Ursachencode für die Aufgabe angeben:

DLV-01: Problem in der Domäne des aktiven Betreibers gefunden
DLV-02: Problem in der Kundendomäne gefunden
DLV-03: Problem in der passiven Untergrunddomäne gefunden
DLV-04: Problem in der passiven PoP-Domäne gefunden
DLV-05: Kein Problem gefunden (nach Untersuchung in Ordnung)
DLV-99: Sonstiges + Erläuterung

Telco-Migration

Der Aufgabentyp „Migration“ dient dazu, einen Endnutzer von einem aktiven Betreiber zu einem anderen zu migrieren, auch bekannt als Telco-Migration.

Die Migrationsaufgabe ähnelt stark der Patch-Installation, weist jedoch einen wichtigen Unterschied auf. Beim Einsetzen eines Patches muss der Auftragnehmer davon ausgehen, dass die angegebene passive Position (ODF-Schublade und -Position) noch durch den Patch des abgebenden Betreibers belegt ist. Die Aufgabe besteht somit darin, den Patch des abgebenden Betreibers zu entfernen und den Patch des empfangenden Betreibers gemäß dem TaskSet zu installieren.

Je nachdem, ob es sich um dieselbe angeforderte Faser handelt, wird es entweder eine PATCH_MIGRATE oder eine PATCH_INSTALL und eine PATCH_REMOVE sein. Potenziell kann es auch eine FTU_RECONSTRUCT geben, wenn die gewünschte FTU von der aktuellen FTU an der Adresse abweicht. Jede andere in Gebrauch befindliche Faser wird ebenfalls entpatcht, was zu einer PATCH_REMOVE führt.

Bei einer Telco-Migration muss der abgebende aktive Betreiber der Migration immer informiert werden, unabhängig davon, ob es sich um eine PATCH_MIGRATE oder eine separate PATCH_INSTALL und PATCH_REMOVE handelt.

Bevor eine Migrationsaufgabe akzeptiert wird, durchläuft sie eine „Clean Order“-Prüfung. Im Rahmen dieses Prozesses werden auch spezifische Migrationsanforderungen geprüft, insbesondere ob der passive Port in Gebrauch ist. Schlägt diese Prüfung fehl, wird der Migrationsauftrag abgelehnt. Darüber hinaus wird, wie bei allen Aufgabentypen, ein Migrationsauftrag abgelehnt, wenn bereits eine Aufgabe für die angeforderte Adresse aktiv ist.

Des Weiteren sollte bei allen Migrationsfällen das Wunschdatum auch als Plandatum verwendet werden. Dies bedeutet, dass der Auftragnehmer das angegebene Wunschdatum für alle POP-bezogenen Aufgaben eintragen muss. Eine Ausnahme bilden Adressen mit zwei angeschlossenen Fasern, bei denen die nicht-abgegebene Faser auf Wunsch zu einem späteren Zeitpunkt geplant werden kann, jedoch in der Regel gleichzeitig erfolgt.

Falls vorhanden, kann die FTU_RECONSTRUCT zu einem anderen Datum als dem im Wunschdatum angegebenen ausgeführt werden. Zudem gibt es keine strikte Anforderung, ob die FTU_RECONSTRUCT vor oder nach der Patch-Migration abgeschlossen sein muss.

In seltenen Fällen, in denen die Faser migriert wurde, aber die PATCH_REMOVE an der nicht mehr verwendeten Faser fehlgeschlagen ist, wird der Migrationsauftrag dennoch als erfolgreich betrachtet. Die fehlgeschlagene PATCH_REMOVE wird als separater Vorfall behandelt.

Port-Migration

Die PORT_MIGRATE-Aufgabe dient dazu, eine Verbindung für einen ISP zu einem anderen Active Equipment Endpoint Port im PoP zu migrieren. Innerhalb dieser Migration bleiben der Active Operator und der Service Provider unverändert. Die angeschlossene Faser wird von einem Port zu einem anderen und/oder von einem Modul zu einem anderen verschoben. Der ISP bleibt bei einer Port-Migration derselbe, daher wird dem aktiven ISP im Voraus keine Migrationsanzeige bereitgestellt.

Die PORT_MIGRATE ist eine Aufgabe, die eine Änderung des aktiven PORTS und/oder MODULS des Active AO anfordert, wobei ein neuer Patch erstellt werden muss. Die Details des aktiven Endpunkts werden vom AO bei der Erstellung einer PORT_MIGRATE-Aufgabe aktualisiert, indem diese Informationen in die Felder des aktiven Endpunkts eingetragen werden.

Die neuen Port- und/oder Moduldaten werden in AC aktualisiert, sobald die Aufgabe den Status DELIVERD erreicht hat.

ONT-Installation

Der Aufgabentyp ONT_INSTALL wird für einen Auftragnehmer generiert, um eine ONT im Haus eines Endbenutzers zu installieren. Es gibt keinen spezifischen Aufgabentyp für die Aktivierung der ONT. Gridsz geht davon aus, dass der Auftragnehmer den zu verwendenden ONT-Typ kennt. Falls weitere Anweisungen erforderlich sind, können diese vom AO/ISP im Kommentarbereich platziert werden.

Der Aufgabentyp ONT_Install ist ein optionaler OutTask-Typ für den Installationsauftrag. 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 korrekten Outtask-Typen vorzubereiten. Ein Installationsauftrag enthält immer eine Patch_Install. Wenn keine FTU vorhanden ist, wird ein Installationsauftrag auch eine FTU_Construct erstellen.

Wenn bereits eine FTU vorhanden ist, aber der „zu installierende“ FTU-Typ vom aktuellen FTU-Typ abweicht, enthält der Outtask-Satz eine FTU_Replacement anstelle einer FTU_Construct.

Um den Status einer ONT_INSTALL-Aufgabe zu aktualisieren, muss das Plandatum zwingend ausgefüllt werden.

Schematisch sind dies die beiden Szenarien: