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

1. Das Ergebnis der Bewertung ist vorhanden, aber, falls positiv, ist die Task ist aber noch nicht zwingend abgeschlossen, oder als

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

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

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