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 werden:

Product

siehe AR16_Produktabbildung Strongly Typed vs. Char/CharValue Pattern

ProductOrder

Es gibt für die ProductOrder keine Specification.

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 auf 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

Sonstiges

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.

Nach Aussage von Florin Tene, City Fibre, UK stand zunächst für Schemaänderungen bei TMF nur das Characteristics Pattern zur Verfügung.

Da dieses fehleranfällig ist und weil es viel missbraucht wurde, wurde später die Vererbung bei TMF eingeführt.

...

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 den gewünschten Informationen entsprechen
2. In der TMF 622 sind derzeit keine characteristics für die ProductOrder 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. Die ProductOrder-API wird 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.