Skip to content

DemoScenariesEng_AdvancedLevel_PrivEth

Jump to bottom
Puzanira edited this page Feb 17, 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 transaction type is used, with the next transition 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 deal card)
  7. Make sure that there are no changes in the transaction on the nodes Client1, Client2, Client3.
  8. Client2 tries to switch the deal status to Status-3 (inconsistency of the deal card role model).
  9. Make sure that there are no changes in the transaction 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 header, you must use the personal identifier 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 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 S2Vra2VyVXNlcjp6RGZqbTMz" -H "channel: Demo" "963f75e3-43b9-4aa6-a6cf-7c1d59b600da"

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 S2Vra2VyVXNlcjp6RGZqbTMz" -H "channel: Demo" -d "{ \"dealUid\": \"963f75e3-43b9-4aa6-a6cf-7c1d59b600da\", \"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 S2Vra2VyVXNlcjp6RGZqbTMz" -H "channel: Demo" -H "Content-Type: multipart/form-data" -F "DealUid=963f75e3-43b9-4aa6-a6cf-7c1d59b600da" -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 S2Vra2VyVXNlcjp6RGZqbTMz" -H "Content-Type: application/json-patch+json" -H "channel: Demo" -d "{ \"dealUid\":\"963f75e3-43b9-4aa6-a6cf-7c1d59b600da\", \"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 S2Vra2VyVXNlcjp6RGZqbTMz" -H "channel: Demo" If you run this scenario after the Getting Started one, the answer will also contain events from the FirstDeal demo transaction. [{"actor":{"key":"CLIENT1","role":"Role1"},"version":2,"state":"Status-1_","files":[{"fileUid":"4a16ba7f-a545-40c2-8191-7a805fc6ba31","filePath":"C:\\KekkerWork\\12\\IPFS:QmfWLy31kzEPbzRbrys3qGJ34YmFsotuh3yFE8t6hu5XwP.dat","fileKind":"Status-1-1","state":"Status-1_","version":2}],"eventName":"StatusChanged",**"eventUid":"491bf13d-68f5-4017-8a13-df64b12d0132","dealUid":"963f75e3-43b9-4aa6-a6cf-7c1d59b600da"**,"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-7c1d59b600da" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZqbTMz" -H "channel: Demo" {"uid":"963f75e3-43b9-4aa6-a6cf-7c1d59b600da","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-7a805fc6ba31","filePath":"C:\\KekkerWork\\12\\IPFS:QmfWLy31kzEPbzRbrys3qGJ34YmFsotuh3yFE8t6hu5XwP.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-df64b12d0132/ack" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZqbTMz" -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-7c1d59b600da/files/4a16ba7f-a545-40c2-8191-7a805fc6ba31" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZqbTMz" -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 Example answer
curl -X POST "http://democlient2.kekker.com/api/deals/files" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZqbTMz" -H "channel: Demo" -H "Content-Type: multipart/form-data" -F "DealUid=963f75e3-43b9-4aa6-a6cf-7c1d59b600da" -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 S2Vra2VyVXNlcjp6RGZqbTMz" -H "channel: Demo" -H "Content-Type: multipart/form-data" -F "DealUid=963f75e3-43b9-4aa6-a6cf-7c1d59b600da" -F "FileKind=Status-2-2" -F "formFile=@C:/Kekker/Status-2-2.dat;type=text/plain"
curl -X POST "http://democlient2.kekker.com/api/deals/setstatus" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZqbTMz" -H "Content-Type: application/json-patch+json" -H "channel: Demo" -d "{ \"dealUid\":\"963f75e3-43b9-4aa6-a6cf-7c1d59b600da\", \"status\":\"Status-2_\", \"remark\":\"Status changed to Status-2 by CLIENT2\", \"parameters\": []}"

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 deal card)

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

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

9. Make sure that there are no changes in the transaction 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.

Clone this wiki locally