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). Dieses Lifecycle Model definiert einen Ergebnis-Zustand = done ( ... request has been assessed and result is available).
Dieser Ergebnis-Zustand kann interpretiert werden als
Das Ergebnis der Bewertung ist vorhanden, aber, falls positiv, ist die Task ist aber noch nicht zwingend abgeschlossen, oder als
Das Ergebnis der Bewertung ist vorhanden, und, falls positiv, ist die Task auch zwingend abgeschlossen
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 ist eine TaskEntity mit Bezug auf eine Product Order (ProductOrderRef) und closeReason: Message
Die Task Resource muss über diese Grundstruktur hinaus, auch noch die Informationen mitliefern, welche zur Ausführung der Task und der Dokumentation der Ergebnisse in der Managed Resource notwendig sind. Hier ist zu differenzieren auf welcher Ebene der Managed Resource, die Task resource einwirkt:
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
Beispiel b) : AddProductOrderInformation
Beispiel c) & d): AmendProductOrder