Zum Ende des Banners springen
Zum Anfang des Banners springen

AR_Entwurf_Erweiterungen von TMF Resourcen

Zum Ende der Metadaten springen
Zum Anfang der Metadaten

Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.

Unterschiede anzeigen Seitenhistorie anzeigen

« Vorherige Version anzeigen Version 6 Nächste Version anzeigen »

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

(Frage) 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

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.

Die Verwendung von Characteristics sei als deprecated anzusehen.

  • Keine Stichwörter