Skip to content

DemoScenariesEng_AdvancedLevel_PrivEth

Jump to bottom
Puzanira edited this page Feb 18, 2020 · 4 revisions

Advanced Level Scenario

This scenario is executed in the Private Ethereum (PrivEth) cluster.

In addition to the functionality of the Getting Started scenario, it demonstrates:

  • file transfer
  • status update control according to the status map
  • deal status monitoring

Deal participants:

  • Client1 (Role1) - PrivEth-1 node
  • Client2 (Role2) - PrivEth-2 node
  • Client3 (Role3) - PrivEth-3 node

Before running the scenario it is recommended to create test files Status-1-1.dat, Status-2-1.dat, Status-2-2.dat on the local computer. Although there are no technical limitations on file size, it is recommended to use files up to 100 Kb to speed up the demo scenario.

A pre-installed smart contract with the AdvancedDeal deal type is used, with the next status map:

  • New -> Status-1 -> Role1
  • Status-1 -> Status-2 -> Role2
  • Status-2 -> Status-3 -> Role3
  • Status-3 -> Closed -> Role1,Role3

The scenario consists of the consistent execution of the following steps:

  1. Client1 creates a deal with attributes DocNumber, DocDate, DocSumma
  2. Client1 switches the deal status to Status-1 with Status-1.dat file attached.
  3. Make sure that the changes of deals and files come to Client1, Client2, Client3 nodes.
  4. Client2 switches the deal status to Status-2 with Status-2-1.dat and Status-2-2.dat files attached
  5. Make sure that the changes of deals and files come to Client1, Client2, Client3 nodes.
  6. Client2 tries to switch the deal status to Status-4 (status that does not exist in the status map)
  7. Make sure that there are no changes in the deal on the nodes Client1, Client2, Client3.
  8. Client2 tries to switch the deal status to Status-3 (inconsistency of the status map role model).
  9. Make sure that there are no changes in the deal on the nodes Client1, Client2, Client3.
  10. Client3 switches the deal status to Status-3
  11. Make sure that the change of the deal comes to Client1, Client, Client3 nodes.
  12. Client1 or Client3 switches the deal status to Closed
  13. Make sure that the change of the deal comes to Client1, Client2, Client3 nodes.

ATTENTION! In queries in the CHANNEL, UID and AUTHORIZATION header, you must use the personal identifiers you received during registration. This will not interfere with simultaneous work of several users, and will facilitate the work of the Technical Support Service if you have any questions. Demo personal identifier (not valid) is used in request examples.

1. Client1 creates a deal with attributes DocNumber, DocDate, DocSumma

The creation of the deal consists of the following steps:

  • Getting the deal identifier
  • Deal creation itself

Getting a deal identifier

GET method call /api/uid is used. The method returns GUID, which can be used once to create a deal.

Example call Example answer
curl -X GET "http://democlient1.kekker.com/api/uid" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZXXXXX" -H "channel: Demo" "963f75e3-43b9-4aa6-a6cf-7c1d59bXXXXX"

Deal creation

POST method call /api/deals/ is used. The json-specification of the deal is specified as the request data, in our case:

{ 
   "dealUid":"[UID]",
   "kind":"AdvancedDeal",
   "parties":[ { "key":"CLIENT1", "role":"Role1" },
               { "key":"ClIENT2", "role":"Role2" },
               { "key":"ClIENT3", "role":"Role3" }
             ],
   "parameters":[ { "key":"DocNumber", "value":"Advanced-1" },
                  { "key":"DocDate", "value":"15.02.2020" },
                  { "key":"DocSumma", "value":"10000" }
                ],
   "parentDealUid": null
}
Example call Example answer
curl -X POST "http://democlient1.kekker.com/api/deals" -H "accept: text/plain" -H "Content-Type: application/json-patch+json" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZXXXXX" -H "channel: Demo" -d "{ \"dealUid\": \"963f75e3-43b9-4aa6-a6cf-7c1d59bXXXXX\", \"kind\": \"AdvancedDeal\", \"parties\": [ { \"key\": \"CLIENT1\", \"role\": \"Role1\" }, { \"key\": \"CLIENT2\", \"role\": \"Role2\" }, { \"key\": \"CLIENT3\", \"role\": \"Role3\" } ], \"parameters\": [ { \"key\": \"DocNumber\", \"value\": \"Advanced-1\" }, { \"key\": \"DocDate\", \"value\": \"15.02.2020\" },{ \"key\": \"DocSumma\", \"value\": \"10000\" } ], \"parentDealUid\": null}" Empty if no errors

2. Client1 switches the deal status to Status-1 within the Status-1.dat file attachment.

Changing the state of the deal generally consists of the following steps:

  • Uploading files attached to a deal
  • The actual change in the state of the deal

Uploading files attached to a deal

POST method call /api/deals/files is used. The following data are transmitted as fields in the request:

 - DealUid= [UID]
 - FileKind = Status-1-1
 - FormFile = @<path-to-file>;type=text/plain
Example call Example answer
curl -X POST "http://democlient1.kekker.com/api/deals/files" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZXXXXX" -H "channel: Demo" -H "Content-Type: multipart/form-data" -F "DealUid=963f75e3-43b9-4aa6-a6cf-7c1d59bXXXXX" -F "FileKind=Status-1-1" -F "formFile=@C:/Kekker/Status-1-1.dat;type=text/plain" Empty if no errors

The actual change in the state of the deal

POST method call /api/deals/setstatus is used. The json-specification of the new deal state is specified as the request data, in our case:

{
    "dealUid": "[UID]", 
    "status": "Status-1_", 
    "remark": "Status changed to Status-1 by CLIENT1", 
    "parameters": [] 
}
Example call Example answer
curl -X POST "http://democlient1.kekker.com/api/deals/setstatus" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZXXXXX" -H "Content-Type: application/json-patch+json" -H "channel: Demo" -d "{ \"dealUid\":\"963f75e3-43b9-4aa6-a6cf-7c1d59bXXXXX\", \"status\":\"Status-1_\", \"remark\":\"Status changed to Status-1 by CLIENT1\", \"parameters\": []}" Empty if no errors

3. Make sure that the changes of deals and files come to Client1, Client2, Client3 nodes.

Receiving information on the modified deals generally consists of the following steps:

  • Monitoring of deal events
  • Retrieving the deal data
  • Marking the event processed
  • Uploading files related to the deal

Monitoring of deal events

GET method call /api/events/new is used. The request may have a set of filters, in our case: take=10, eventTypes=StatusChanged (events of deal changes by 10 pieces).

Example call (for Client2) Example answer (special interest on the fields **\"eventUid\"** (event identifier) and **\"dealUid\"** (deal identifier) )
curl -X GET "http://democlient2.kekker.com/api/events/new?take=10&eventTypes=StatusChanged" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZXXXXX" -H "channel: Demo" If you run this scenario after the Getting Started one, the answer will also contain events from the FirstDeal demo deal. 
[{ 
    "actor": {"key":"CLIENT1","role":"Role1"},
    "version": 2,
    "state": "Status-1_",
    "files": [{ "fileUid":"4a16ba7f-a545-40c2-8191-7aXXXXX", 
                "filePath": "C:\\KekkerWork\\12\\IPFS:QmfWLy31kzEPbzRbrys3qGJ34YmFsotuh3yFE8t6hXXXXX.dat", 
                "fileKind":"Status-1-1","state":"Status-1_", 
                "version":2 }],
    "eventName": "StatusChanged", 
    "eventUid":"491bf13d-68f5-4017-8a13-df64b12XXXXX", 
    "dealUid":"963f75e3-43b9-4aa6-a6cf-7c1d59bXXXXX",
    "timestamp":"2020-02-16T08:20:14.17","active":true
}]

Retrieving the deal data

GET method call /api/deals/{UID} is used. Where {UID} is the deal identifier.

Example call (for Client2) Example answer
curl -X GET "http://democlient2.kekker.com/api/deals/963f75e3-43b9-4aa6-a6cf-7c1d59bXXXXX" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZXXXXX" -H "channel: Demo" 
{
    "uid": "963f75e3-43b9-4aa6-a6cf-7c1d59bXXXXX",
    "kind": "AdvancedDeal",
    "status": "Status-1_",
    "remark": "Status changed to Status-1 by CLIENT1",
    "parameters": [{ "key":"DocNumber", "value":"Advanced-1" }, 
                   { "key":"DocDate", "value":"15.02.2020" }, 
                   { "key":"DocSumma", "value":"10000" }],
    "parties": [{ "key":"CLIENT1", "role":"Role1" },
                { "key":"CLIENT2", "role":"Role2" },
                { "key":"CLIENT3", "role":"Role3" }],
    "files":[{ "fileUid": "4a16ba7f-a545-40c2-8191-7a805fcXXXXX",
               "filePath": "C:\\KekkerWork\\12\\IPFS:QmfWLy31kzEPbzRbrys3qGJ34YmFsotuh3yFE8t6hXXXXX.dat",
               "fileKind": "Status-1-1", 
               "state": "Status-1_", 
               "version": 2 }],
    "history":[{ "status": "Status-1_",
                 "party": { "key":"CLIENT1","role":"Role1" },
                 "remark": "Status changed to Status-1 by CLIENT1","version":2 }],
    "statusMap": [{ "status":"*", "statusNext": "Status-1_", "role":"Role1" },
                  { "status": "Status-1_.1", "statusNext": "Status-2_", "role": "Role2" },
                  { "status": "Status-2_.1", "statusNext": "Status-3_", "role": "Role3" },
                  { "status": "Status-3_.1", "statusNext": "Closed___", "role": "Role1" }, 
                  { "status": "Status-3_.2", "statusNext": "Closed___", "role": "Role1" }]
}

Marking the event processed

POST method call /api/events/{UID}/ack is used. Where {UID} is an event identifier (not deal identifier!)

Example call (for Client2) Example answer
curl -X POST "http://democlient2.kekker.com/api/events/491bf13d-68f5-4017-8a13-df64b12XXXXX/ack" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZXXXXX" -H "channel: Demo" -H "content-length: 0" Empty if no errors

After all the events in the queue have been processed - request /api/events/new will give an empty result.

Uploading files related to the deal

If there are any files attached to the deal - the description of the deal will contain a non-empty collection of "files". The file can be accessed either by the path specified for it in the filePath field (if the business application has direct access to the file space of the platform node), or by downloading it using the GET /api/deals/{UID}/files/{FileUID}, where {UID} - deal identifier, and {FileUID} - file identifier from the field fileUid.

Example call (for Client2) Example answer
curl -X GET "http://democlient2.kekker.com/api/deals/963f75e3-43b9-4aa6-a6cf-7c1d59bXXXXX/files/4a16ba7f-a545-40c2-8191-7a805fcXXXXX" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZXXXXX" -H "channel: Demo" Status-1-1.dat
Test file for demo scenario Advanced Level

4. Client2 switches the deal status to Status-2 with Status-2-1.dat and Status-2-2.dat files attached

We do the same procedure as step [2], except that before changing the deal status we sequentially upload two files instead of one.

Example call (for Client2) Example answer
curl -X POST "http://democlient2.kekker.com/api/deals/files" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZXXXXX" -H "channel: Demo" -H "Content-Type: multipart/form-data" -F "DealUid=963f75e3-43b9-4aa6-a6cf-7c1d59bXXXXX" -F "FileKind=Status-2-1" -F "formFile=@C:/Kekker/Status-2-1.dat;type=text/plain" Empty if no errors
curl -X POST "http://democlient2.kekker.com/api/deals/files" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZXXXXX" -H "channel: Demo" -H "Content-Type: multipart/form-data" -F "DealUid=963f75e3-43b9-4aa6-a6cf-7c1d59bXXXXX" -F "FileKind=Status-2-2" -F "formFile=@C:/Kekker/Status-2-2.dat;type=text/plain" Empty if no errors
curl -X POST "http://democlient2.kekker.com/api/deals/setstatus" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZXXXXX" -H "Content-Type: application/json-patch+json" -H "channel: Demo" -d "{ \"dealUid\":\"963f75e3-43b9-4aa6-a6cf-7c1d59bXXXXX\", \"status\":\"Status-2_\", \"remark\":\"Status changed to Status-2 by CLIENT2\", \"parameters\": []}" Empty if no errors

5. Make sure that the changes of deals and files come to Client1, Client2, Client3 nodes.

We proceed in the same way as step [3], paying attention to changes in the "status" and "remark" fields as well as the "history" and "file" collections.

It should be noted that each file is bound not only to some status, but also to a specific step of the deal's history, defined by the attribute "version".

6. Client2 tries to switch the deal status to Status-4 (status that does not exist in the status map)

This and the next step demonstrates the action of blocking mechanisms that prohibit changing the status of a deal violating the status map assigned to the deal.

The status map is contained in the description of the deal in the "statusMap" collection. It consists of a set of entries declaring from which status (field "status") the switching is allowed (field "statusNext") and which role (field role) the participant of the deal should have to make this action. If the attempt is made to switch to an unauthorized status or by participant without required rights it will be rejected.

The mechanism has two levels of action:

  • the first level is performed by platform applications that control the setStatus operation and generate the corresponding message when trying to set an incorrect status
  • the second layer is implemented directly in the smart-contract of the deal and it blocks changes attempts at the level of technical transactions of the DLT platform.

Let's try to switch the deal status to Status-4, which is not included in the deal status map.

Example call (for Client2) Example answer
curl -X POST "http://democlient2.kekker.com/api/deals/setstatus" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZXXXXX" -H "Content-Type: application/json-patch+json" -H "channel: Demo" -d "{ \"dealUid\":\"963f75e3-43b9-4aa6-a6cf-7c1d59bXXXXX\", \"status\":\"Status-4_\", \"remark\":\"Status changed to Status-4 by CLIENT2\", \"parameters\": []}" 
{
  "ErrorMessage": "Status \"Status-4_\" not accepted for DealKind \"AdvancedDeal\"
}

7. Make sure that there are no changes in the transaction on the nodes Client1, Client2, Client3.

To make sure that no changes to the deal have occurred, you can monitor the deal events for some time or request its status, as described in step [3].

8. Client2 tries to switch the deal status to Status-3 (inconsistency of the deal card role model).

Let's try to switch a deal status to Status-3, which is valid for this deal state, but the Client2 participant role is not allowed to do it.

Example call (for Client2) Example answer
curl -X POST "http://democlient2.kekker.com/api/deals/setstatus" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZXXXXX" -H "Content-Type: application/json-patch+json" -H "channel: Demo" -d "{ \"dealUid\":\"963f75e3-43b9-4aa6-a6cf-7c1d59bXXXXX\", \"status\":\"Status-3_\", \"remark\":\"Status changed to Status-4 by CLIENT2\", \"parameters\": []}" Empty answer

9. Make sure that there are no changes in the transaction on the nodes Client1, Client2, Client3.

To make sure that no changes to the deal have occurred, you can monitor the deal events for some time or request its status, as described in step [3].

10. Client3 switches the deal status to Status-3

POST method call /api/deals/setstatus is used. The json-specification of the new deal state, in our case, is specified as the request data:

{ 
    "dealUid": "[UID]", 
    "status": "Status-3_", 
    "remark": "Status changed to Status-3 by CLIENT3", 
    "parameters": [] 
}
Example call (for Client2) Example answer
curl -X POST "http://democlient3.kekker.com/api/deals/setstatus" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZXXXXX" -H "Content-Type: application/json-patch+json" -H "channel: Demo" -d "{ \"dealUid\":\"963f75e3-43b9-4aa6-a6cf-7c1d59XXXXX\", \"status\":\"Status-3_\", \"remark\":\"Status changed to Status-3 by CLIENT3\", \"parameters\": []}" Empty if no errors

11. Make sure that the change of the deal comes to Client1, Client, Client3 nodes.

Similar to step [3], we get the change event and the state of the deal.

Example call for an event Example answer
curl -X GET "http://democlient2.kekker.com/api/events/new?take=10&eventTypes=StatusChanged" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZXXXXX" -H "channel: Demo" 
[{
    "actor": { "key":"CLIENT3", "role":"Role3" }, 
    "version": 4,
    "state": "Status-3_", 
    "files": [],
    "eventName": "StatusChanged",
    "eventUid": "f2e9da22-fc37-4978-b67a-88de8bdXXXXX",
    "dealUid": "963f75e3-43b9-4aa6-a6cf-7c1d59bXXXXX",
    "timestamp": "2020-02-17T21:14:07.017","active":true
}]
Example call for deal status Example answer
curl -X GET "http://democlient2.kekker.com/api/deals/963f75e3-43b9-4aa6-a6cf-7c1d59bXXXXX" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZXXXXX" -H "channel: Demo" 
{ 
    "uid": "963f75e3-43b9-4aa6-a6cf-7c1d59bXXXXX",
    "kind": "AdvancedDeal",
    "status": "Status-3_",
    "remark": "Status changed to Status-3 by CLIENT3",
    "parameters": [{ "key":"DocNumber", "value":"Advanced-1" },
                   { "key":"DocDate", "value":"15.02.2020" },
                   { "key": "DocSumma", "value": "10000" }],
    "parties": [{ "key": "CLIENT1", "role": "Role1" },
                { "key": "CLIENT2", "role": "Role2" },
                { "key": "CLIENT3", "role": "Role3" }],
    "files": [{ "fileUid": "4a16ba7f-a545-40c2-8191-7a805fcXXXXX", 
                "filePath": "C:\\KekkerWork\\12\\IPFS:QmfWLy31kzEPbzRbrys3qGJ34YmFsotuh3yFE8t6hXXXXX.dat", 
                "fileKind": "Status-1-1",
                "state": "Status-1_",
                "version":2 },
               { "fileUid": "2d227f15-ed32-4897-b3db-14d7feeXXXXX",
                 "filePath": "C:\\KekkerWork\\0c92523c7ffe4ead80cf3b4e767XXXXX_Status-2-1.dat",
                 "fileKind": "Status-2-1",
                 "state": "Status-2_",
                 "version": 3 },
               { "fileUid": "9b36dd95-2469-4d5d-b731-413500cXXXXX",
                 "filePath": "C:\\KekkerWork\\13803fe2f92143749bf2f75a7a8XXXXX_Status-2-2.dat",
                 "fileKind": "Status-2-2",
                 "state": "Status-2_",
                 "version": 3 },
               { "fileUid": "4a16ba7f-a545-40c2-8191-7a805fcXXXXX",
                 "filePath": "C:\\KekkerWork\\12\\IPFS:QmfWLy31kzEPbzRbrys3qGJ34YmFsotuh3yFE8t6hXXXXX.dat",
                 "fileKind": "Status-1-1",
                 "state": "Status-1_",
                 "version":2 }],
    "history": [{ "status": "Status-1_", 
                  "party": {"key": "CLIENT1", "role": "Role1" },
                  "remark": "Status changed to Status-1 by CLIENT1",
                  "version": 2 },
                { "status": "Status-2_",
                  "party": { "key": "CLIENT2", "role": "Role2" },
                  "remark": "Status changed to Status-2 by CLIENT2",
                  "version": 3 },
                { "status": "Status-3_",
                  "party": {"key": "CLIENT3", "role": "Role3" },
                  "remark": "Status changed to Status-3 by CLIENT3",
                  "version": 4 }], 
    "statusMap": [{ "status": "*", "statusNext": "Status-1_", "role": "Role1" },
                  { "status": "Status-1_.1", "statusNext": "Status-2_", "role": "Role2" },
                  { "status": "Status-2_.1", "statusNext": "Status-3_", "role": "Role3" },
                  { "status": "Status-3_.1", "statusNext": "Closed___", "role": "Role1" },
                  { "status": "Status-3_.2", "statusNext": "Closed___", "role": "Role1" }]
}

12. Client1 or Client3 switches the deal status to Closed

POST method call /api/deals/setstatus is used. The json-specification of the new state of the deal is specified as the request data, in our case depending on the participant switching it:

  • to be switched by Client1:
{
  "dealUid": "[UID]",
  "status": "Closed___",
  "remark": "Deal closed by CLIENT1",
  "parameters": []
}
  • to be switched by Client3:
{
  "dealUid": "[UID]",
  "status": "Closed___",
  "remark": "Deal closed by CLIENT3",
  "parameters": []
}
Example call for Client2 Example answer
curl -X POST "http://democlient1.kekker.com/api/deals/setstatus" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZXXXXX" -H "Content-Type: application/json-patch+json" -H "channel: Demo" -d "{ \"dealUid\":\"963f75e3-43b9-4aa6-a6cf-7c1d59XXXXXa\", \"status\":\"Closed___\", \"remark\":\"Deal closed by CLIENT1\", \"parameters\": []}" Empty answer
Example call for Client3 Example answer
curl -X POST "http://democlient3.kekker.com/api/deals/setstatus" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZXXXXX" -H "Content-Type: application/json-patch+json" -H "channel: Demo" -d "{ \"dealUid\":\"963f75e3-43b9-4aa6-a6cf-7c1d59bXXXXX\", \"status\":\"Closed___\", \"remark\":\"Deal closed by CLIENT3\", \"parameters\": []}" Empty answer

13. Make sure that the change of the deal comes to Client1, Client2, Client3 nodes.

Similar to step [3], we get the change event and the state of the deal.

Example call for an event Example answer
curl -X GET "http://democlient2.kekker.com/api/events/new?take=10&eventTypes=StatusChanged" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZXXXXX" -H "channel: Demo" 
[{
     "actor": { "key":"CLIENT1", "role": "Role1" },
     "version": 5, 
     "state": "Closed___",
     "files": [],
     "eventName": "StatusChanged",
     "eventUid": "aa2f88a6-281b-49e7-803f-fb95c10XXXXX",
     "dealUid": "963f75e3-43b9-4aa6-a6cf-7c1d59bXXXXX",
     "timestamp": "2020-02-17T21:29:27.017",
     "active":true
}]
Example call for deal status Example answer
curl -X GET "http://democlient2.kekker.com/api/deals/963f75e3-43b9-4aa6-a6cf-7c1d59bXXXXX" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZXXXXX" -H "channel: Demo" 
{
  "uid": "963f75e3-43b9-4aa6-a6cf-7c1d59bXXXXX",
  "kind": "AdvancedDeal",
  "status": "Closed___",
  "remark": "Deal closed by CLIENT1",
  "parameters": [{ "key": "DocNumber", "value": "Advanced-1" },
    { "key": "DocDate", "value": "15.02.2020" },
    { "key": "DocSumma", "value": "10000" }],
  "parties": [{ "key": "CLIENT1", "role": "Role1" },
    { "key": "CLIENT2", "role": "Role2" },
    { "key": "CLIENT3", "role": "Role3" }],
  "files": [{ "fileUid": "4a16ba7f-a545-40c2-8191-7a805fcXXXXX",
      "filePath": "C:\\KekkerWork\\12\\IPFS:QmfWLy31kzEPbzRbrys3qGJ34YmFsotuh3yFE8t6hXXXXX.dat",
      "fileKind": "Status-1-1",
      "state": "Status-1_",
      "version": 2 },
    { "fileUid": "2d227f15-ed32-4897-b3db-14d7feeXXXXX",
      "filePath": "C:\\KekkerWork\\0c92523c7ffe4ead80cf3b4e767XXXXX_Status-2-1.dat",
      "fileKind": "Status-2-1",
      "state": "Status-2_",
      "version": 3 },
    { "fileUid": "9b36dd95-2469-4d5d-b731-413500cXXXXX",
      "filePath": "C:\\KekkerWork\\13803fe2f92143749bf2f75a7a8XXXXX_Status-2-2.dat",
      "fileKind": "Status-2-2",
      "state": "Status-2_",
      "version": 3 },
    { "fileUid": "4a16ba7f-a545-40c2-8191-7a805fcXXXXX",
      "filePath": "C:\\KekkerWork\\12\\IPFS:QmfWLy31kzEPbzRbrys3qGJ34YmFsotuh3yFE8t6hXXXXX.dat",
      "fileKind": "Status-1-1",
      "state": "Status-1_",
      "version": 2 }],
  "history": [{ "status": "Status-1_",
      "party": { "key": "CLIENT1", "role": "Role1" },
      "remark": "Status changed to Status-1 by CLIENT1",
      "version": 2 },
    { "status": "Status-2_",
      "party": { "key": "CLIENT2", "role": "Role2" },
      "remark": "Status changed to Status-2 by CLIENT2",
      "version": 3 },
    { "status": "Status-3_",
      "party": { "key": "CLIENT3", "role": "Role3" },
      "remark": "Status changed to Status-3 by CLIENT3",
      "version": 4 },
    { "status": "Closed___",
      "party": { "key": "CLIENT1", "role": "Role1" },
      "remark": "Deal closed by CLIENT1",
      "version": 5 }],
  "statusMap": [{ "status": "*", "statusNext": "Status-1_", "role": "Role1" },
    { "status": "Status-1_.1", "statusNext": "Status-2_", "role": "Role2" },
    { "status": "Status-2_.1", "statusNext": "Status-3_", "role": "Role3" },
    { "status": "Status-3_.1", "statusNext": "Closed___", "role": "Role1" },
    { "status": "Status-3_.2", "statusNext": "Closed___", "role": "Role1" }]
}

Clone this wiki locally