Die Art und Weise, wie TMF Resourcen erweitert werden, ist abhängig vom Einzelfall.

Die bis jetzt behandelten Einzelfälle werden als Pattern hier beschrieben:

Regel

Folgende Regeln gelten für die Abbildung von Feldern entweder als Characteristics oder als Strongly-Typed-Property:

1. Im TMF Standard enthaltene Felder sollen verwendet werden, wenn sie semantisch der gewünschten Informationm entsprechen
2. Als Chracteristic werden abgebildet
   1. Felder, die ausschließlich zur Abwärtskompatibilität mit bestehenden APIs (WITA, S/PRI und WBCI) benötigt werden
      1. Beispiel: LineId wird so lange benötigt, bis alle Seller die product.id verwenden
   2. Felder, die ausschließlich für einen bestimmte Seller benötigt werden
      1. Beispiel: Vormieterdaten für die DTAG
3. Als Strongly-Typed-Property werden abgebildet:
   1. Felder, die strukturell für FIT Standard-Anwendungsfälle benötigt werden
      1. Beispiele: 
         1. Technologie des Hausanschlusses für FTTC oder zukünftig für andere Hybrid-Produkte
         2. HardwareId ( und deren Typ, z.B. Mac-DSL, ONT-SN) zur Identifikation der Line (z.B. DSL-Mac für DTAG-VDSL, ONT-SN für PON-Produkte)
   2. Felder zur Steuerung des Ablaufes:
      1. Beispiel: Expressentstörung

Hinweise

Während alle Felder einer Resource im Swagger unmittelbar erkannt werden können, sind Felder, die über das Characteristics-Pattern abgebildet sind, nur ersichtlich, wenn die entsprechende Resource (im Fall des Trouble Tickets "CharcteristicSpecification") abgefragt wird.

Wenn für eine Managed Resource das Characteristic / Specification Pattern eingesetzt wird, darf eine Characteristic nur verwendet werden, wenn der Name der Characteristic in der CharacteristicSpecification persistiert ist.

Die FIT API definiert die zulässigen Characteristic (Beispiel: Product Test Specification Model)

Verwendung des Characteristic/Specification Patterns in der FIT API

Product

siehe AR16_Produktabbildung Strongly Typed vs. Char/CharValue Pattern

ProductOrder

Es gibt für die ProductOrder keine Specification.

Daher wird die ProductOrderCharacteristicSpecification neu eingeführt.

Daher wurde entschieden, Ändernugen, also hinzugefügte oder gelöschte Felder, direkt in der Resource vorzunehmen, ohne Subtypen.

Warum wird für die PO kein FIT-eigener Subtyp verwendet?

Trouble Ticket

TMF621 Trouble Ticket Management API enthält folgende Klassen:

• TroubleTicketSpecification
• CharacteristicSpecification
• CharacteristicValueSpecification

Somit ist eine Erweiterung per Characteristic.Pattern oder Abbildung in der Resource Trouble Ticket oder einer Subklasse möglich.

Da das Trouble Ticket auch für andere Use Cases, als für Entstörung verwendet wird (z.B. Clearing), werden neue Felder für die Entstörung in einen Subtypen von Trouble Ticket geschrieben.

Als Guideline wurde festgehalten, wie folgt vorzugehen:

1. Lässt sich das neue Feld über bestehende Felder oder Referenzen bereits abbilden? Beispiele
   1. Können die verschiedene Arten der Expressentstörung über das Feld priority abgebildet werden? Nein, die Semantik von priority ist, dass es vom LE gesetzt wird, anhand der severity → Abbildung als neue Property
   2. Optionale Serviceleistung: Wird in der PO als POI abgebildet, da es eine Produktposition dazu gibt. Kann im Troubel Ticket ohne Schema-Anpassung als RelatedEntity abgebildet werden
2. Abbildung als Characteristic:
   1. wenn ein Feld aus Gründen der Datenmigration mitgenommen wird. Beispiel: FrageId aus dem Fragenkatalog
   2. wenn ein Feld als reiner Payload übertragen wird. Beispiel: Lage der TAE
3. Abbildung als neue Property: Wenn das Feld zur Steuerung verwendet wird. Beispiel: Expressentstörung

ProductOrderTest

analog TroubleTicket

Agreement

analog TroubleTicket