Nagłówek sprawy CaseHeader
W artykule opisano obiekt będący kluczowym elementem żądań w komunikacji z bazą danych za pośrednictwem usług SOAP i REST. Nagłówek CaseHeader jest niezbędny do realizacji zadań aktualizacji spraw w bazie danych, wpiera identyfikację i aktualizację definicji typu sprawy. Obiekt ten zawiera predefiniowane pola encji Case, które są wykorzystywane do identyfikacji sprawy, jej statusu oraz innych istotnych informacji. W artykule przedstawiono również przykłady konstrukcji nagłówka sprawy w różnych formatach (XML i JSON) oraz omówiono znaczenie poszczególnych pól.
Definicja obiektu CaseHeader
| Warstwy, w których użyty | Business |
| Rodzaj | Obiekt biznesowy |
| Interfejs Java | IMrcCaseHeader, IMrcObject, ICaseHeader |
| className/type | MrcCaseHeader |
| Implementacja Java | pro.ibpm.mercury.business.data.api.MrcCaseHeader |
| Implementacja DTO | pro.ibpm.mercury.business.data.api.CaseHeader |
| Definicja XML | hgdb-mrc-object-3.0.xsd |
Nagłówek sprawy. Obiekt biznesowy reprezentujący predefiniowane (stałe) pola encji Case oraz pola optymalizujące identyfikację typu sprawy. Jest podstawą do weryfikacji unikalności sprawy oraz identyfikacji obiektu uniwersalnego MRC jako obiektu opisującego sprawę (zobacz Case jako uniwersalne obiekty MRC).
Lista i znaczenie poszczególnych pól/parametrów
| Parametrów | Opis | Typ/Atrybut "type" | Wymagany | Dozwolone wartości |
|---|---|---|---|---|
| caseId | Reprezentacja predefiniowanego pola encji Case. Identyfikator sprawy | Long/Integer | Nie/Tak1 | |
| bpmProcessId | Reprezentacja predefiniowanego pola encji Case. Identyfikator instancji procesu BPM, z którą powiązana jest sprawa. | Long/Integer | Nie | |
| inventoryCode | Reprezentacja predefiniowanego pola encji Case. Wygenerowany/unikalny kod sprawy | String/String | Nie | |
| groupId | Reprezentacja predefiniowanego pola encji Case. Identyfikator grupy spraw. | Long/Integer | Nie/Tak1 | Identyfikator istniejącej grupy |
| typeId | Reprezentacja predefiniowanego pola encji Case. Identyfikator typu | Long/Integer | Nie/Tak1 | Identyfikator istniejącej wersji typu sprawy |
| typeCode | Kod typu sprawy | String/String | Tak | |
| endDate | Reprezentacja predefiniowanego pola encji Case. Data załatwienia/zakończenia sprawy z punktu widzenia procesu BPM | CaseDate/Date | Nie | |
| dueDate | Reprezentacja predefiniowanego pola encji Case. Planowana data załatwienia/zakończenia sprawy z punktu widzenia procesu BPM | CaseDate/Date | Nie | |
| status | Reprezentacja predefiniowanego pola encji Case. Aktualny status sprawy. Statusy spraw wywodzą się z procesowego charakteru obiektu sprawy i mają powiązanie z tym czy ustawione jest pole bpmProcessId: N - oznacza, że sprawa została przetworzona przez proces o zadanym id, obecnie również oznacza to, że może zostać ona wykorzystana przez inny proces: A - oznacza, że sprawa jest przetwarzana przez proces o zadanym id, ale w świecie słowników to może oznaczać również dane możliwe do wykorzystania (gdy bpmProcessId nie jest ustawione)O - oznacza, że wykonanie instancji procesu o zdanym id zostało "odłożone" na późniejZ - oznacza przerwanie/anulowanie powiązanego procesu, oznacza to również sprawę, której nie powinno się wykorzystywać w procesach, nie wolno jej edytować (próba zmiany zakończy się wyjątkiem). Najczęściej status Z ustawiony jest gdy nastąpi zmiana typu sprawy. Stara, nie możliwa do zmiany wersja sprawy. | String/String | Nie/Tak1 | A(Aktywna)N(Zakończona)O(Odłożona)Z(Przerwana) |
| piervousVersionId | Reprezentacja predefiniowanego pola encji Case. Podczas zmiany typu sprawy następuje automatyczne utworzenie nowej sprawy (nowej wersji sprawy). Sprawa w poprzednim typie zostaje przerwana (jej status otrzymuje flagę Z) a nowa sprawa jest oznaczana jako aktywna (flaga A). Pole zawiera wartość identyfikatora sprawy zamkniętej, będącą pierwowzorem obecnej. Pole uzupełniane automatycznie lub ręcznie - zobacz artykuł Wersje spraw | Long/Integer | Nie | |
| rootVersionId | Reprezentacja predefiniowanego pola encji Case. Pole zawiera wskazanie na sprawę, która jest wersją główną sprawy (pierwotną). Pole uzupełniane automatycznie lub ręcznie - zobacz artykuł Wersje spraw | Long/Integer | Nie | |
| priceValue | Reprezentacja predefiniowanego pola encji Case. Wartość sprawy, cena | Double/Decimal | Nie | |
| priceValueCode | Reprezentacja predefiniowanego pola encji Case. 3-literowy kod waluty, w której wyrażona została wartość sprawy. | String/String | Nie | Przykłady kdów: PLN, EUR itp. |
| priceExchangeDate | Reprezentacja predefiniowanego pola encji Case. Data kursu wartości, wykorzystywana do przeliczenia wartości ceny, gdy kod waluty jest inny niż systemowy. | CaseDate/Date | Nie | |
| storeCount | Reprezentacja predefiniowanego pola encji Case. Liczba spraw będących na stanie magazynu (nie przypisanych do żadnego użytkownika). Przypisanie użytkownika odbywa się za pośrednictwem encji GroupCase. | Integer/Integer | Nie | |
| storeId | Reprezentacja predefiniowanego pola encji Case. Identyfikator rodzimego magazynu sprawy. Założenie sprawy wymaga by była ona przypisana do magazynu. | Long/Integer | Nie/Tak1 | |
| createDate | Reprezentacja predefiniowanego pola encji Case. Data utworzenia sprawy | CaseDate/Date | Nie | |
| createdBy | Reprezentacja predefiniowanego pola encji Case. Nazwa użytkownika tworzącego | String/String | Nie | |
| lastModifyDate | Reprezentacja predefiniowanego pola encji Case. Data modyfikacji danych sprawy | CaseDate/Date | Nie | |
| lastModifiedBy | Reprezentacja predefiniowanego pola encji Case.Nazwa użytkownika modyfikującego | String/String | Nie | |
| modifyComment | Reprezentacja predefiniowanego pola encji Case. Ostatni komentarz zmiany danych sprawy. Pole uzupełniane automatycznie na podstawie danych kontekstowych (comment) przesłanych podczas aktualizacji/dodawania sprawy. | String/String | Nie | |
| createdByRoleName | Reprezentacja predefiniowanego pola encji Case. Nazwa roli jaką pełnił użytkownik podczas operacji dodawania sprawy. Pole uzupełniane automatycznie na podstawie danych kontekstowych (currentRole) przesłanych podczas dodawania sprawy. | String/String | Nie | |
| lastModifiedByRoleName | Reprezentacja predefiniowanego pola encji Case. Nazwa roli jaką pełnił użytkownik podczas operacji aktualizacji sprawy. Pole uzupełniane automatycznie na podstawie danych kontekstowych (currentRole) przesłanych podczas aktualizacji sprawy. | String/String | Nie | |
| subCaseReferenceId | Jeżeli obiekt występuje jako sprawa zależna (element sprawy nadrzędnej) to pole zawiera identyfikator referencji definiującej tę zależność (to powiązanie). | Long/Integer | Nie | |
| className | Nazwa klasy/typu obiektu złożonego, który jest reprezentowany przez sprawę. Nazwa wersji typu sprawy. | String/String | Nie | |
| version | Systemowy numer ostatniej zmiany/wersja sprawy | String/String | Nie | |
| dirty | Flaga sterująca z informacją czy przesłana sprawa, podczas akcji modyfikacji ma być aktualizowana. Ważne dla spraw złożonych by np. nie aktualizować spraw zależnych podczas aktualizacji parametrów sprawy nadrzędnej i odwrotnie, gdy chcemy aktualizować parametry sprawy podrzędnej pomijając rejestrację zmian w sprawie nadrzędnej. | Boolean/Boolean | Tak | true lub false |
| pkPropertyName | Nazwa parametru sprawy będącego wartością unikalną. | String/String | Nie | |
| headerMetadata | Obiekt CaseHeader dziedziczy pewne pola po obiekcie MrcObject (zobacz Uniwersalne obiekty MRC). Dodatkowe informacje związane z przesyłanym obiektem takie jak np. status. | MrcObjectMetadata | Nie |
Any właściwie wyjaśnić znaczenie obiektu CaseHeader (i jego pól) postaramy się przedstawić i opisać konkretne przykłady.
Podstawowe przykłady wykorzystania
Poniżej przedstawione zostaną przykłady definiowania nagłówka sprawy w usługach biznesowych. Przypomnijmy sobie analizowany w artykule Sprawa vs. obiekt, obiekt biznesowy systemu IBM BPM. Definicja przykładowego obiektu biznesowego TestMrcObject:
Przygotowanie danych w systemie, bez definicji pola klucza głównego sprawy
Zdefiniujmy nagłówek sprawy dla akcji wstawiania do systemu. Zbudujmy obiekt CaseHeader dla przykładowej sprawy według następujących wytycznych:
- ⬜
caseId– puste, nie znamy jeszcze identyfikatora sprawy - ✅️ – jeżeli znamy identyfikator instancji procesu to ustawiamy np. 1234
- ⬜
inventoryCode– puste, wartość zostanie wygenerowana (pod warunkiem istnienia generatora kodów w systemie) - ✅️
groupId– jeżeli znamy identyfikator grupy, do której ma być przypisana obecna sprawa to ustawiamy - ⬜
typeId– nie znamy identyfikatora typu sprawy – zostawiamy puste - ✅️
typeCode– znamy kod typu – to nazwa obiektu biznesowego (najczęściej), chyba, że uznamy inaczej. Przyjmujemy wartość ‘TestMrcObject’ - ⬜
endDate– ustawiamy odpowiednią wartość (może być pusta) - ⬜
dueDate- ustawiamy odpowiednią wartość (może być pusta) - ✅️
status– ustawiamy wartośćA– sprawa ma być aktywna - ⬜
piervousVersionId– pusty, wartość zostanie ustawiona automatycznie, jeżeli zajdzie taka potrzeba - ⬜
rootVersionId- pusty, wartość zostanie ustawiona automatycznie, jeżeli zajdzie taka potrzeba - ⬜
priceValue- ustawiamy odpowiednią wartość (może być 0) lub zostawiamy pustą - ⬜
priceValueCode– ustawiamy odpowiednią wartość (może być pusta) – wtedy zostanie przyjęty kod systemowy. - ⬜
priceExchangeRate- ustawiamy odpowiednią wartość różną od 0 (może być 1) - ✅️
storeCount- ustawiamy odpowiednią wartość różną od 0 (może być 1) - ✅️
storeId– jeżeli znamy magazyn sprawy, do którego ma być przypisana obecna sprawa to ustawiamy - ⬜ pola
createDate,createdBy,lastModifyDate,lastModifiedBy,modifyComment,createdByRoleName,lastModifiedByRoleNamesą polami aktualizowanymi automatycznie na podstawie obiektuContext - ⬜
subCaseReferenceId– sprawaTestMrcObjectjest sprawą nadrzędną - nie ustawiamy! - ✅️
className– nie znamy identyfikatora typu sprawy – nazwa klasy (nazwa obiektu) będzie podstawą do identyfikacji typu (ewentualnie utworzenia nowego o danej nazwie). Obiekt biznesowy nazywa sięTestMrcObjectzatem taką wartość wprowadzamy. - ✅️
objectID– ustawiamy zewnętrzny identyfikator wersji typu obiektu, na podstawie którego zostanie utworzona określona wersja typu sprawy. Możliwe, że go nie znamy, ale zawsze możemy go sobie w jakiś sposób zdefiniować np.TestMrcObject.1– ważne, że gdy będziemy się posługiwać tym obiektem, o takiej definicji to należy zawsze używać tej samej wartości – wesprze/przyspieszy to identyfikację typu sprawy przez system Mercury. W systemie IBM BPM możemy ten identyfikator wyciągnąć na podstawie definicji klasy obiektu biznesowego. Załóżmy, że jest to wartość5a2eed95-5975-42ff-8c4a-1527f38266fbi taką ustawimy - ✅️
rootVersionContextID– ustawiamy zewnętrzny identyfikator kontekstu, który ma zainicjalizować daną wersję typu sprawy. Możliwe, że go nie znamy, ale zawsze możemy go sobie w jakiś sposób zdefiniować np.App.1– ważne, że gdy będziemy się posługiwać tym obiektem w danej aplikacji zawsze używać tej samej wartości – wesprze/przyspieszy to identyfikację typu sprawy przez system Mercury. W systemie IBM BPM możemy wykorzystać identyfikator snapshot’a (obraz stanu) aplikacji procesowej z której pochodzi obiekt biznesowy. Załóżmy, że jest to wartość2064.895ead8d-6fab-4eb8-b54b-b94cd07bb548T. - ⬜
version– przy pierwszym wstawieniu zostawiamy puste. - ✅️
dirty– przy operacji modyfikacji (dodawania) obiektu flaga powinna być ustawiona na „true” - ⬜
pkPropertyName– zostawmy puste. Następny przykład pokaże cel użycia tego pola.
Konstrukcja nagłówka sprawy reprezentowanej jako typ ANY
Nagłówek sprawy jest wykorzystywany w metodach wymagających różnych formatów. W przypadku metod biznesowych SOAP obsługujących argumenty dowolnego typu (ANY XML), rekomenduje się by każdy TAG przesłanego obiektu miał ustawiony atrybut type z nazwą typu pola (to ułatwia identyfikację typu pola). W tym przypadku wartości są z góry ustalone (zobacz tabelka z listą pól, oraz odpowiednie opisy metod). Zdefiniowane wcześniej wartości dadzą nam następujący przykładowy XML jaki należy użyć podczas pierwszego wstawiania. W przypadku usług REST, gdzie nie ma możliwości przesyłania typu pola, wartości będą takie same, ale bez tej informacji:
- XML dla usługi wstawiania SOAP
- JSON dla usługi wstawiania REST
<mrcCaseHeader type="MrcCaseHeader" xmlns="http://business.dto.ws.hgdb.io/mrcObject"
xsi:schemaLocation="http://business.dto.ws.hgdb.io/mrcObject http://hgdb.io/xsd/dto/hgdb-mrc-object-3.0.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<bpmProcessId type="Integer">1234</bpmProcessId>
<groupId type="Integer">1001</groupId>
<typeCode type="String">TestMrcObject</typeCode>
<status type="String">A</status>
<storeCount type="Integer">1</storeCount>
<storeId type="Integer">1001</storeId>
<className type="String">TestMrcObject</className>
<objectID type="String">5a2eed95-5975-42ff-8c4a-1527f38266fb</objectID>
<rootVersionContextID type="String">2064.895ead8d-6fab-4eb8-b54b-b94cd07bb548T</rootVersionContextID>
<dirty type="Boolean">true</dirty>
</mrcCaseHeader>
{
"bpmProcessId": 1234,
"groupId": 1001,
"typeCode": "TestMrcObject",
"status": "A",
"storeCount": 1,
"storeId": 1001,
"className": "TestMrcObject",
"objectID": "5a2eed95-5975-42ff-8c4a-1527f38266fb",
"rootVersionContextID": "2064.895ead8d-6fab-4eb8-b54b-b94cd07bb548T",
"dirty": true
}
Po wykonaniu żądania wstawienia sprawy za pomocą usługi SOAP (XML), w odpowiedzi usługi, otrzymamy uzupełniony nagłówek świeżo utworzonej sprawy (przypisany jest do pola o nazwie mrcCaseHeader sprawy):
Na czerwono zostały zaznaczone wartości, które zostały automatycznie uzupełnione po zakończonej sukcesem operacji zapisu sprawy. Jak widzimy, został uzupełniony identyfikator sprawy (pole caseId) oraz został ustawiony identyfikator zidentyfikowanej wersji typu sprawy. Tak skonstruowany nagłówek należy używać w usługach aktualizacji sprawy. Należy pamiętać by ustawić wartość pola dirty na true aby aktualizacja doszła do skutku. Modyfikujemy również nagłówek w przypadku gdy chcemy zmienić inne predefiniowane pola sprawy.
Problem pola typu Date. Ważnym jest by pola daty przesyłane były w odpowiednim formacie. Domyślnym formatem jest yyyy/MM/dd HH:mm:ss.SS z, ale można go zmienić poprzez odpowiednie ustawienie pola formats w obiekcie kontekstu (zobacz opis obiektu Context). Jeżeli data przesyłana jest w określonym formacie to powinien być ustawiony atrybut isEncoded="false"
<createDate isEncoded="false" type="Date">2017/06/03 00:44:12.958 CEST</createDate>
Jeżeli ustawimy isEncoded="true" datę należy przesłać jako liczba milisekund (https://currentmillis.com/):
<createDate isEncoded="true" type="Date">1498031451441</createDate>
Przygotowanie danych w systemie, z definicją pola klucza głównego sprawy
Przykładem może być integracja z systemem, który posiada zbiór danych i ustalony model relacyjny, posiada własne pole jednoznacznie identyfikujące sprawę. Mercury DB ma własny unikalny identyfikator, jest to wartość pola nagłówka caseId. Nie chcemy by dane były duplikowane po stronie bazy spraw. Chcemy by w Mercury DB również dane pole było cechą unikalności. Utwórzmy nagłówek sprawy takiej sprawy o nazwie TestUser:
- ⬜
caseId– puste, nie znamy jeszcze i niestety nie będziemy mogli go wykorzystać - ⬜
bpmProcessId– puste, akcja nie ma żadnego związku z procesem BPM - ⬜
inventoryCode– puste, wartość zostanie wygenerowana (pod warunkiem istnienia generatora kodów w systemie) - ⬜
groupId– jeżeli znamy identyfikatora grupy – zostawiamy puste - ⬜
typeId– nie znamy identyfikatora typu sprawy – zostawiamy puste - ✅️
typeCode– znamy kod typu – to nazwa obiektu biznesowego (najczęściej), chyba, że uznamy inaczej. Przyjmujemy wartość ‘TestUser’ - ⬜
endDate– ustawiamy odpowiednią wartość (może być pusta) - ⬜
dueDate- ustawiamy odpowiednią wartość (może być pusta) - ✅️
status– ustawiamy wartość „A” – sprawa ma być aktywna - ⬜
piervousVersionId– pusty, wartość zostanie ustawiona automatycznie, jeżeli zajdzie taka potrzeba - ⬜
priceValue- ustawiamy odpowiednią wartość (może być 0) lub zostawiamy pustą - ⬜
priceValueCode– ustawiamy odpowiednią wartość (może być pusta) – wtedy zostanie przyjęty kod systemowy. - ⬜
priceExchangeRate- ustawiamy odpowiednią wartość różną od 0 (może być 1) - ✅️
storeCount- ustawiamy odpowiednią wartość różną od 0 (może być 1) - ⬜
storeId– jeżeli znamy magazyn sprawy, do którego ma być przypisana obecna sprawa to ustawiamy - ⬜ pola
createDate,createdBy,lastModifyDate,lastModifiedBy,modifyComment,createdByRoleName,lastModifiedByRoleNamesą polami aktualizowanymi automatycznie na podstawie obiektuContext - ⬜
subCaseReferenceId– sprawaTestUserw tym przypadku jest sprawą samodzielną - nie ustawiamy! - ✅️
className– nie znamy identyfikatora typu sprawy – nazwa klasy (nazwa obiektu) będzie podstawą do identyfikacji typu (ewentualnie utworzenia nowego o danej nazwie). Obiekt biznesowy nazywa sięTestUserzatem taką wartość wprowadzamy. - ✅️
objectID– ustawiamy zewnętrzny identyfikator wersji typu obiektu, na podstawie którego zostanie utworzona określona wersja typu sprawy. Możliwe, że go nie znamy, ale zawsze możemy go sobie w jakiś sposób zdefiniować np.TestUser.1– ważne, że gdy będziemy się posługiwać tym obiektem, o takiej definicji to należy zawsze używać tej samej wartości – wesprze/przyspieszy to identyfikację typu sprawy przez system Mercury. - ✅️
rootVersionContextID– ustawiamy zewnętrzny identyfikator kontekstu, który ma zainicjalizować daną wersję typu sprawy. Możliwe, że go nie znamy, ale zawsze możemy go sobie w jakiś sposób zdefiniować np.App.1– ważne, że gdy będziemy się posługiwać tym obiektem w danej aplikacji zawsze używać tej samej wartości – wesprze/przyspieszy to identyfikację typu sprawy przez system Mercury. - ⬜
version– przy pierwszym wstawieniu zostawiamy puste. - ✅️
dirty– przy operacji modyfikacji (dodawania) obiektu flaga powinna być ustawiona natrue - ✅️
pkPropertyName– sprawa typuTestUserposiada swoje własne, unikalne pole o nazwieid– przypiszmy tę wartość temu polu. Możemy definiować klucz złożony reprezentowany przez formułę listy parametrów oddzielanych operatorem konkatenacji||np.pole1||pole2
Konstrukcja nagłówka sprawy reprezentowanej jako typ ANY
Zdefiniowane wcześniej wartości dadzą nam następujący przykładowy nagłówek, jaki należy użyć podczas pierwszego wstawiania:
- XML dla usługi wstawiania SOAP
- JSON dla usługi wstawiania REST
<mrcCaseHeader type="MrcCaseHeader" xmlns="http://business.dto.ws.hgdb.io/mrcObject"
xsi:schemaLocation="http://business.dto.ws.hgdb.io/mrcObject http://hgdb.io/xsd/dto/hgdb-mrc-object-3.0.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<typeCode type="String">TestUser</typeCode>
<status type="String">A</status>
<storeCount type="Integer">1</storeCount>
<className type="String">TestUser</className>
<objectID type="String">TestUser.1</objectID>
<rootVersionContextID type="String">App.1</rootVersionContextID>
<dirty type="Boolean">true</dirty>
<pkPropertyName type="String">id</pkPropertyName>
</mrcCaseHeader>
{
"typeCode": "TestUser",
"status": "A",
"storeCount": 1,
"className": "TestUser",
"objectID": "TestUser.1",
"rootVersionContextID": "App.1",
"dirty": true,
"pkPropertyName": "id"
}
Po wykonaniu żądania wstawienia sprawy za pomocą usługi SOAP (XML), w odpowiedzi usługi, otrzymamy uzupełniony nagłówek świeżo utworzonej sprawy (przypisany jest do pola o nazwie mrcCaseHeader sprawy):
Na czerwono zostały zaznaczone wartości, które zostały automatycznie uzupełnione po zakończonej sukcesem operacji zapisu sprawy. Nie podaliśmy również identyfikatora grupy (groupId) – grupa została przydzielona automatycznie.
Wszystkie dodane pola w kolejnych akcjach aktualizacji możemy pominąć używając statycznego nagłówka, który zdefiniowaliśmy podczas pierwszego wstawiania. Zwracam jednak uwagę na to, że system Mercury DB zidentyfikował typ sprawy i nadał mu identyfikator, który znajdziemy w polu typeId. Magazyn został również przydzielony automatycznie – zobacz pole storeId. Są to bardzo ważne parametry sprawy i podanie ich wartości podczas dodawania i aktualizowania kolejnych spraw przyspieszają akcję zapisu. Rekomenduje się by w tym przypadku wartości te ustawić na sztywno, dla każdej kolejnej akcji zapisu sprawy.
System Mercury DB spróbuje zidentyfikować istniejącą sprawę danego typu na podstawie wartości pola o nazwie id i jeżeli mu się uda, to zaktualizuje dane, nie stworzy duplikatu.
Podsumowanie
Na podstawie przykładów widzimy, że nagłówek sprawy stanowi istotny element identyfikacji istniejącej sprawy w systemie Mercury DB.
Jego odpowiednie parametry nie tylko wskazują na istniejącą w bazie sprawę, ale również wspierają proces identyfikacji typu sprawy. Na zdefiniowanie wersji typu sprawy wpływa nie tylko lista załączonych do sprawy pól. Na zmianę wersji wpływają zmiany następujących pól nagłówka:
typeCode– zmiana kodu typuclassName– zmiana nazwy wersji typuobjectID– zmiana zewnętrznego identyfikatora wersji typu obiektu, na podstawie którego zostanie utworzona określona wersja typu sprawyrootVersionContextID– zmiana zewnętrznego identyfikatora kontekstu, który ma zainicjalizować daną wersję typu sprawypkPropertyName– zmiana unikalnego pola
Analizując przykłady i mając świadomość istotności nagłówka w identyfikacji wersji typu sprawy rekomenduje się by zespoły deweloperskie budujące integracje z różnymi systemami komunikowały się w zakresie wspólnych rozwiązań. Przy założeniu scenariusza, w którym powstały w systemie obiekt biznesowy o nazwie TestMrcObject zawiera obiekt o nazwie TestUser oraz powstaje integracja innego „systemu zewnętrznego” z bazą Mercury DB, to zespół deweloperów powinien dodać do „swojego” nagłówka sprawy typu TestUser pole pkPropertyName z wartością id, a lista pól powinna być zgodna z obiektem pochodzącym z „systemu zewnętrznego”.