DemoScenariesRus_AdvancedLevel_PrivEth

Сценарий Advanced Level

Данный сценарий проводится в кластере Private Ethereum (PrivEth).

Дополнительно к функционалу сценария Getting Started данный сценарий демонстрирует:

передачу файлов
контроль изменения статуса сделки в соответствии с картой статусов
мониторинг изменения состояния сделок

Участники сделки:

Client1 (роль Role1) - узел PrivEth-1
Client2 (роль Role2) - узел PrivEth-2
Client3 (роль Role3) - узел PrivEth-3

Перед исполнением сценария рекомендуется создать на локальном компьютере тестовые файлы Status-1-1.dat, Status-2-1.dat, Status-2-2.dat. Хотя технические ограничения на размер файлов отсутствуют, для ускорения прохождения демо-сценария рекомендуется использовать файлы размером до 100 Kb.

Используется предустановленный смарт-контракт с типом сделки AdvancedDeal, со следующей картой переходов:

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

Сценарий заключается в последовательном исполнении следующих шагов:

Client1 создает сделку с атрибутами DocNumber, DocDate, DocSumma
Client1 переключает статус сделки в Status-1 с приложением файла Status-1-1.dat
Убеждаемся в приходе изменения сделки и файлов на узлы Client1, Client2, Client3
Client2 переключает статус сделки в Status-2 с приложением файлов Status-2-1.dat и Status-2-2.dat
Убеждаемся в приходе изменения сделки и файлов на узлы Client1, Client2, Client3
Client2 пытается переключить статус сделки в Status-4 (статус, несуществующий в карте сделки)
Убеждаемся в отсутствии изменений в сделке на узлах Client1, Client2, Client3
Client2 пытается переключить статус сделки в Status-3 (несоответствие ролевой модели карты сделки)
Убеждаемся в отсутствии изменений в сделке на узлах Client1, Client2, Client3
Client3 переключает статус сделки в Status-3
Убеждаемся в приходе изменения сделки на узлы Client1, Client, Client3
Client1 или Client3 переключает статус сделки в Closed
Убеждаемся в приходе изменения сделки на узлы Client1, Client2, Client3

ВНИМАНИЕ! В запросах в заголовках CHANNEL, UID и AUTHORIZATION необходимо использовать полученный Вами при регистрации персональный идентификатор. Это позволит не мешать одновременной работе нескольких пользователей, а также облегчит работу службы Технической поддержки при возникновении у Вас каких-либо вопросов. В примерах запросов используется персональный идентификатор Demo (не валидный).

1. `Client1` создает сделку с атрибутами `DocNumber, DocDate, DocSumma`

Создание сделки состоит из следующих шагов:

Получение идентификатора сделки
Собственно создание сделки

Получение идентификатора сделки

Используется вызов GET-метода /api/uid. Метод возвращает GUID, который может быть однократно использован для создания сделки.

Пример вызова	Пример ответа
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"

Создание сделки

Используется вызов POST-метода /api/deals/. В качестве данных запроса указывается json-спецификация сделки, в нашем случае:

{ 
   "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
}

Пример вызова	Пример ответа
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}"	Если всё хорошо - ответ пустой.

2. `Client1` переключает статус сделки в `Status-1` с приложением файла `Status-1-1.dat`

Изменение состояния сделки в общем случае состоит из следующих шагов:

Загрузка файлов, прикрепляемых к новому статусу сделки
Собственно изменение состояния сделки

Загрузка файлов, прикрепляемых к сделке

Используется вызов POST-метода /api/deals/files. В качестве полей в запросе передаются следующие данные:

 - DealUid= [UID]
 - FileKind = Status-1-1
 - FormFile = @<path-to-file>;type=text/plain

Пример вызова	Пример ответа
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"	Если всё хорошо - ответ пустой.

Собственно изменение состояния сделки

Используется вызов POST-метода /api/deals/setstatus. В качестве данных запроса указывается json-спецификация нового состояния сделки, в нашем случае:

{
    "dealUid": "[UID]", 
    "status": "Status-1_", 
    "remark": "Status changed to Status-1 by CLIENT1", 
    "parameters": [] 
}

Пример вызова	Пример ответа
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\": []}"	Если всё хорошо - ответ пустой.

3. Убеждаемся в приходе изменения сделки и файлов на узлы `Client1, Client2, Client3`

Получение информации по измененным сделкам в общем случае состоит из следующих шагов:

Мониторинг событий по сделкам
Извлечение данных сделки
Отметка обработанного события
Выгрузка файлов, связанных со сделкой

Мониторинг событий по сделкам

Используется вызов GET-метода /api/events/new. У запроса может задан набор фильтров, в нашем случае: take=10, eventTypes=StatusChanged (события изменения сделок по 10 штук)

Пример вызова (для клиента Client2)	Пример ответа (обращаем внимание на "eventUid" (идентификатор события) и "dealUid" (идентификатор сделки))
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"	Если Вы исполняете данный сценарий после сценария Getting Started, то ответ будет содержать также события по демо-сделке FirstDeal: [{ "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 }]

Извлечение данных сделки

Используется вызов GET-метода /api/deals/{UID}. Где {UID} - идентификатор сделки

Пример запроса (для клиента Client2)

Пример ответа

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" }]
}

Отметка обработанного события

Используется вызов POST-метода /api/events/{UID}/ack. Где {UID} - идентификатор события (не сделки!)

Пример запроса (для клиента Client2)	Пример ответа
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"	Если всё хорошо - ответ пустой.

После того как все события в очереди обработаны - запрос /api/events/new выдаст пустой результат.

Выгрузка файлов, связанных со сделкой

Если к сделки привязаны какие-либо файлы - в описании сделки будет присутствовать непустая коллекция "files". Доступ к файлу может быть получен либо по указанному для него в поле filePath пути (если бизнес-приложение имеет прямой доступ к файловому пространству узла платформы), либо путем скачивания с использованием метода GET /api/deals/{UID}/files/{FileUID}, где {UID} - идентификатор сделки, а {FileUID} - идентификатор файла из поля fileUid.

Пример запроса файла (для узла 2)	Пример ответа
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` переключает статус сделки в `Status-2` с приложением файлов `Status-2-1.dat` и `Status-2-2.dat`

Действуем аналогично шагу [2], только перед изменением статуса сделки вместо одного файла последовательно загружаем два.

Пример запросов	Пример ответов
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"	Если всё хорошо - все ответы должны быть пустыми.
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"	Если всё хорошо - все ответы должны быть пустыми.
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\": []}"	Если всё хорошо - все ответы должны быть пустыми.

5. Убеждаемся в приходе изменения сделки и файлов на узлы `Client1, Client2, Client3`

Действуем аналогично шагу [3], обращая внимание на изменение полей "status" и "remark", а также коллекций "history" и "file".

При этом следует отметить, что каждый файл привязан не только к некоторому статусу, но и к конкретному шагу истории изменения сделки, определяемому атрибутом "version".

6. `Client2` пытается переключить статус сделки в `Status-4` (статус, несуществующий в карте сделки)

На этом и следующем шаге демонстрируется действие блокировочных механизмов, запрещающих изменение статуса сделки с нарушением присвоенной сделке карты изменения состояний.

Карта изменения состояний содержится в описании сделки в коллекции "statusMap". Карта состоит из набора записей, декларирующих из какого статуса (поле "status") в какой (поле "statusNext") допустимо переключение и какой ролью (поле "role") должен обладать участник сделки,имеющий право данное переключение сделать. При попытке переключить в неразрешенный статус или участником без надлежащей роли будет отклонена.

Механизм имеет два уровня действий:

первый уровень осуществляется приложениями платформы, контролирующими операцию setStatus и выдающими соответствующее сообщение при попытке установить некорректный статус
второй уровень реализован непосредственно в смарт-контракте сделки и блокирует попытки изменения на уровне технических транзакций DLT-платформы.

Попробуем перевести сделку в статус Status-4, отсутствующий в карте изменения статусов сделки.

Пример запроса	Пример ответа
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. Убеждаемся в отсутствии изменений в сделке на узлах `Client1, Client2, Client3`

Чтобы убедится, что изменения сделки не произошло, можно некоторое время осуществлять мониторинг событий сделки или запрашивать ее состояние, как это описано в шаге [3].

8. `Client2` пытается переключить статус сделки в `Status-3` (несоответствие ролевой модели карты сделки)

Попробуем перевести сделку в статус Status-3, который допустим для данного состояния сделки, но роль участника Client2 не позволяет это сделать.

Пример запроса	Пример ответа
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\": []}"	В данном случае ответ будет пустым.

9. Убеждаемся в отсутствии изменений в сделке на узлах `Client1, Client2, Client3`

Чтобы убедится, что изменения сделки не произошло, можно некоторое время осуществлять мониторинг событий сделки или запрашивать ее состояние, как это описано в шаге [3].

10. `Client3` переключает статус сделки в `Status-3`

Используется вызов POST-метода /api/deals/setstatus. В качестве данных запроса указывается json-спецификация нового состояния сделки, в нашем случае:

{ 
    "dealUid": "[UID]", 
    "status": "Status-3_", 
    "remark": "Status changed to Status-3 by CLIENT3", 
    "parameters": [] 
}

Пример запроса	Пример ответа
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\": []}"	Если всё хорошо - ответ должен быть пустым.

11. Убеждаемся в приходе изменения сделки на узлы `Client1, Client, Client3`

Аналогично шагу [3] получаем событие изменения и состояние сделки.

Пример запроса событий

Пример ответа

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
}]

Пример запроса состояния сделки

Пример ответа

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` или `Client3` переключает статус сделки в `Closed`

Используется вызов POST-метода /api/deals/setstatus. В качестве данных запроса указывается json-спецификация нового состояния сделки, в нашем случае в зависимости от участника, осуществляющего переключение это:

для переключения участником Client1:

{
  "dealUid": "[UID]",
  "status": "Closed___",
  "remark": "Deal closed by CLIENT1",
  "parameters": []
}

для переключения участником Client3:

{
  "dealUid": "[UID]",
  "status": "Closed___",
  "remark": "Deal closed by CLIENT3",
  "parameters": []
}

Пример запроса состояния сделки для Client1	Пример ответа
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\": []}"	Если всё хорошо - ответ должен быть пустым.
Пример запроса состояния сделки для Client3	Пример ответа
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\": []}"	Если всё хорошо - ответ должен быть пустым.

13. Убеждаемся в приходе изменения сделки на узлы `Client1, Client2, Client3`

Аналогично шагу [3] получаем событие изменения и состояние сделки.

Пример запроса событий

Пример ответа

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
}]

Пример запроса состояния сделки

Пример ответа

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" }]
}

Uh oh!

DemoScenariesRus_AdvancedLevel_PrivEth

Сценарий Advanced Level

Дополнительно к функционалу сценария Getting Started данный сценарий демонстрирует:

Участники сделки:

Используется предустановленный смарт-контракт с типом сделки AdvancedDeal, со следующей картой переходов:

Сценарий заключается в последовательном исполнении следующих шагов:

1. Client1 создает сделку с атрибутами DocNumber, DocDate, DocSumma

Создание сделки состоит из следующих шагов:

Получение идентификатора сделки

Создание сделки

2. Client1 переключает статус сделки в Status-1 с приложением файла Status-1-1.dat

Изменение состояния сделки в общем случае состоит из следующих шагов:

Загрузка файлов, прикрепляемых к сделке

Собственно изменение состояния сделки

3. Убеждаемся в приходе изменения сделки и файлов на узлы Client1, Client2, Client3

Получение информации по измененным сделкам в общем случае состоит из следующих шагов:

Мониторинг событий по сделкам

Извлечение данных сделки

Отметка обработанного события

Выгрузка файлов, связанных со сделкой

4. Client2 переключает статус сделки в Status-2 с приложением файлов Status-2-1.dat и Status-2-2.dat

5. Убеждаемся в приходе изменения сделки и файлов на узлы Client1, Client2, Client3

6. Client2 пытается переключить статус сделки в Status-4 (статус, несуществующий в карте сделки)

Механизм имеет два уровня действий:

7. Убеждаемся в отсутствии изменений в сделке на узлах Client1, Client2, Client3

8. Client2 пытается переключить статус сделки в Status-3 (несоответствие ролевой модели карты сделки)

9. Убеждаемся в отсутствии изменений в сделке на узлах Client1, Client2, Client3

10. Client3 переключает статус сделки в Status-3

11. Убеждаемся в приходе изменения сделки на узлы Client1, Client, Client3

12. Client1 или Client3 переключает статус сделки в Closed

13. Убеждаемся в приходе изменения сделки на узлы Client1, Client2, Client3

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Clone this wiki locally

1. `Client1` создает сделку с атрибутами `DocNumber, DocDate, DocSumma`

2. `Client1` переключает статус сделки в `Status-1` с приложением файла `Status-1-1.dat`

3. Убеждаемся в приходе изменения сделки и файлов на узлы `Client1, Client2, Client3`

4. `Client2` переключает статус сделки в `Status-2` с приложением файлов `Status-2-1.dat` и `Status-2-2.dat`

5. Убеждаемся в приходе изменения сделки и файлов на узлы `Client1, Client2, Client3`

6. `Client2` пытается переключить статус сделки в `Status-4` (статус, несуществующий в карте сделки)

7. Убеждаемся в отсутствии изменений в сделке на узлах `Client1, Client2, Client3`

8. `Client2` пытается переключить статус сделки в `Status-3` (несоответствие ролевой модели карты сделки)

9. Убеждаемся в отсутствии изменений в сделке на узлах `Client1, Client2, Client3`

10. `Client3` переключает статус сделки в `Status-3`

11. Убеждаемся в приходе изменения сделки на узлы `Client1, Client, Client3`

12. `Client1` или `Client3` переключает статус сделки в `Closed`

13. Убеждаемся в приходе изменения сделки на узлы `Client1, Client2, Client3`