Task Resource vs. PATCH
Prinzipiell wird für die Änderung an einem laufendem Vorgang die Verwendung von Task Resource vs. PATCH an der Resource präferiert.
Eine Task Resource hat prinzipiell die Zielsetzung einen definierten Vorgang ("Task") auf eine referenzierte "Resource" auszuführen
Abschluss einer Task ResourcePATCH
Task Resource bauen alle auf ein gemeinsames einfaches Lifecycle Model auf (siehe CancelProductOrder /wiki/spaces/tfit/pages/233282064). Dieses Lifecycle Model definiert einen Ergebnis-Zustand = done ( ... request has been assessed and result is available).
...
Um ein konsistentes Handling der Task Resourcen zu erlauben (offene Task Resource = offener Task an der Resource), wird die Variante 2) als Richtline gesetzt
Modelierung einer Task Resource
Task Resources werden nach einem vordefiniertem Pattern gebildet. Die Bildung einer Task Resource in zwei Schritten zu betrachten:
...
Generische Struktur einer Task Resource welche zur Verwaltung und Abbildung einer Task dient. Diese Struktur ist als TaskEntity im Model vordefiniert und eine Task Resource soll als Spezialisierung der TaskEntity mit Bezug auf die betroffene Managed Resource und Begründung als Message angelegt werden
Beispiel: CloseProductOrder/wiki/spaces/tfit/pages/233282055 ist eine TaskEntity mit Bezug auf eine Product Order (ProductOrderRef) und closeReason: Message
...
a) auf Ebene einer first level Property der Managed Resource (z.B. requestedCompletionDate and der ProductOrder): die Inputinformation soll als Property der Task Resource definiert werden. Der Name der Property der Task Resource soll einen eindeutigen Bezug auf die Property der Managed Resource schaffen
b) auf Ebene eines first level Objektes / Property der Managed Resource (z.B. Note an einem TroubleTicket): die Inputinformation soll als Objekt / Property der Task Resource definiert werden. Der Name des Objektes und der Properties an der Task Resource soll einen eindeutigen Bezug auf das Objekt / Properties der Managed Resource schaffen
c) auf tieferen Ebenen der Managed Resource (z.B. Termin an einem ProductOrderItem): die Inputinformation soll als Objekt / Property mit Bezug auf die gezielte Ebene der Task Resource definiert werden. Der Name des Objektes und der Properties an der Task Resource soll einen eindeutigen Bezug auf das Objekt / Properties der Managed Resource schaffen
d) Zusätzlich kann auch noch, wenn notwendig, die auszuführende Task and der task Resource definiert werden (z.B. add, modify delete eines ProductOrderItems): der Taskparameter soll auf der Ebene der Inputinformation definert werden
Beispiel a) & c): RescheduleProductOrder /wiki/spaces/tfit/pages/233282069
Beispiel b) : AddProductOrderInformation /wiki/spaces/tfit/pages/233282060
Beispiel c) & d): AmendProductOrder /wiki/spaces/tfit/pages/233282074