Kernprozesse

Der Umfang der funktionalen Architektur ist von den zu unterstützenden Prozesse vorgegeben. Die High Level Prozess-Analyse ist im Scope Bereich zu finden: siehe Business Szenarien maps Open API

High Level Prinzipien

Datenzentrische Prozesse

Das Konzept der datenzentrische Prozesse ermöglicht dynamische, flexible Abläufe auf Basis klar definierter und abgegrenzter Verantwortungsbereiche (API Domäne).

Beispielhafte Darstellung:

Folgende Eigenschaften sind hervorzuheben:

Jede API Domäne hat, bezogen auf das Datenmodell, einen definierten Verantwortungsrahmen an verwalteten Daten (API Resources).
Der Bezug auf Daten (API Resources) aus anderen Domänen ist, als Beziehung definiert und somit ohne Datenredundanz realisiert.
Die Fähigkeiten an den Datenbereichen ist in den jeweiligen API Domänen gekapselt
Alle relevanten Ergebnisse sind an den API Resources dokumentiert und somit auch ohne Kenntnis der vorherigen Arbeitsschritte nachvollziehbar (stateless)

Status und Lifecycle

Daten in den API Domänen unterstützen langläufige Prozesse und haben somit einen Lifecycle.
Zu jedem Zeitpunkt im Lifecycle ist der Zustand der API Resource in der Zustandseigenschaft (state) festgehalten und somit nachvollziehbar
Alle mögliche Zustandsübergange werden im Lifecycle Model der API Resources definiert

Beispiel Trouble Ticket Lifecycle (TMF621):

Normalisierte Lifecycle, sind zusätzlich zum Open API Datenmodell, ein wichtiges Werkzeug der API Standardisierung, da diese die Client relevanten Stände und Übergänge der gekapselte Business Logik fest definiert.

Langläufige Prozesse

Lifecycle der API Resources bzw. Prozesse welche auf diese Daten aufbauen sind typischerweise langläufig. Der Auftraggeber (Client) kann diese Prozesse, mit dem Anlegen einer API Resource, anstoßen (zB. Auftrag anlegen). Während der Ausführung des Prozesses, im Rahmen des Lifecycle der API Resource, sind auch weitere Interaktionen zwischen Auftraggeber (Client) und Leistungserbringer (Provider) zu unterstützen:

Leistungserbringer (Provider) → Auftraggeber (Client): Leistungserbringer (Provider) dokumentiert alle relevante Ereignisse an der API Resource und meldet diese an den Auftraggeber (Client)
Auftraggeber (Client) → Leistungserbringer (Provider): Der Auftraggeber (Client) kann auf den laufenden Prozess, anhand vordefinierter Task Resources, einwirken

Meldungen

Meldungen werden für folgende Ereignistypen generiert:

Anlegen und Löschen einer API Resource (CreateEvent & DeleteEvent)
Zustandsänderung der API Resource (StateChangeEvent)
Inhaltliche Änderung einer API Resource Eigenschaften (AttributeValueChangeEvent)
Anfrage an den Client zur weiteren Verarbeitung (InformationrequiredEvent). Typischerweise antwortet der Client hier anhand einer Task Resource

Um robuste Prozesse zu implementieren, werden alle Ereignisse an der API Resource dokumentiert. Somit kann sich der Auftraggeber mit einem Aufruf der API Resource (GET) auch ohne Kenntnis der Historie, synchronisieren

Meldungen werden vom Leistungserbringer an einen definierten Endpunkt des Auftraggebers versendet (POST Event)

Bemerkung: Für das erste FIT Release werden die Listener der Auftraggeber fest vordefiniert. Somit ist keine Anmeldung (POST Hub) notwendig.

Task Resources

Um die möglichen Eingriffe des Auftraggebers auf laufenden Prozess des Leistungserbringers, in einem kontrollierten Rahmen zu ermöglichen, werden fest definierte Task Resources unterstützt.

Eine Task Resource qualifiziert genau einen Task welche der Auftraggeber an der API Resource ausführen möchte, wie zB. CancelProductOrder um einen Auftrag zu stornieren. Diese Task Resource muss vom Auftraggeber angelegt werden, um den Task anzustoßen.

source

High Level Information Model

Party (AG): Endkundeninformationen sind für Bereitstellungen und Entstörungen notwendig (zB. Technikertermine). Diese können als Werte mitgeliefert werden. API ist somit für die Prozess-Unterstützung nicht zwingend notwendig.
Party (LE): Kunden und Vertragsinformationen sind für Bereitstellungen und Entstörungen notwendig, eine Referenz ist aber in der Regel ausreichend (fachlicher Schlüssel oder Resource.id). API ist somit für die Prozess-Unterstützung nicht zwingend notwendig.
Agreement: siehe oben
Product Catalog: Für dieses FIT Release wurde entschieden die notwendigen Produktstrukturen, als Schema in den APIs zu definieren. Die vorab abgestimmten Produktangebote können dann als Referenzen mit den Aufträgen mitgeliefert werden. Somit ist eine aktive Abfrage des Produktkataloges nicht zwingend notwendig. Die FIT API Spezifikationen unterstützen aber den katalogbasierten Ansatz und dieser kann, ohne weitere Anpassung der APIs eingeführt werden.
Service: Die Referenz des Services ist notwendig um den Service-Test und die Service-Aktivierung anstoßen zu können, Einen aktive Abfrage des Service Bestandes ist aber nicht im Rahmen der analysierten Prozesse notwendig,
Resource: Referenzen auf Resources wie HomeId, ONT, Leistungsübergabepunkt können Aufträge notwendig sein. Falls eine einfache Referenz nicht ausreichend ist, können Informationen auch als Werte mitgeliefert werden. Ausnahme = Leistungsübergabepunkt (ServiceAccessPoint) welcher im Rahmen der Verfügbarkeit

3. Funktionale Architektur