Die Art  Art und Weise, wie TMF Resourcen Ressourcen erweitert werden, ist abhängig vom Einzelfall.Die bis jetzt behandelten Einzelfälle werden als Pattern hier beschrieben:

Regel (zunächst für TMF 622)

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?

Hinweise: 

• POCharacteristic wird derzeit ( 12.08.2024 ) für den Payload der ZWM-LE verwendet, siehe Zwischenmeldung zur Auftragsrealisierung versenden

Fragen:

• welche möglichen keys hat die ZWM-LE
• Könnte der Payload der ZWM-LE auch in einer Klasse "AdditionalOrderInformation" abgebildet werden?

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

...

1. Informationen entsprechen
2. In der TMF 622 sind derzeit keine characteristics definiert. Ohne Rücksprache mit dem TMF soll die API nicht in dieser grundlegende Form erweitert werden. Eine Erweiterung wird seitens FIT gewünscht und wurde im BFA-Projekt adressiert. Die weitere Verwendung in FIT ist noch offen (als Standard oder für individuelle Erweiterungen Buyer-Seller).
3. Anders als bei der TroubleTicket-API, die für verschiedene fachliche UseCases verwendet wird, wird die ProductOrder-API ausschließlich in einem fachlichen Kontext verwendet. Deshalb wurde der Standard möglichst wenig verändert und die ergänzenden Informationen wurden in einer entsprechenden Klasse (AdditionalOrderInformation) in die ProductOrder integriert.
4. Ein weiterer Grund für die Verwendung der AdditionalOrderInformtation besteht darin, dass Felder, die möglicherweise längerfristig entfallen können, nicht in der ProductOrder abgebildet werden sollen. Eine Abbildung in characteristics ist nicht möglich, solange diese nicht zur Verfügung stehen.
5. Strongly Typed Felder sind ausdrucksstärker, als die Abbildung von zusätzlichen Feldern mit Hilfe von Characteristics. Außerdem sind Strongly Typed Felder  einfacher zu verstehen und interpretieren bzw. in der OAS sofort zu erkennen, was bei Characteristics nicht ohne Query einer Datenbank-Tabelle oder sonstiger Persistenz möglich ist.