Skip to content

DemoScenariesRus_GettingStarted_PrivEth

Jump to bottom
Paul edited this page Feb 15, 2020 · 15 revisions

Сценарий Getting Started

Сценарий демонстрирует распространение сделки по узлам и переключение статуса сделки.

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

Используется предустановленный смарт-контракт с типом сделки FirstDeal (без карты переходов).

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

  1. На узле PrivEth-1 создается сделка с атрибутами DocNumber, DocDate, DocSumma
  2. На узле PrivEth-1 переключаем статус сделки в Status1
  3. Убеждаемся в приходе сделки на узлы PrivEth-1, PrivEth-2, а также в отсутствии сделки на узле PrivEth-3
  4. На узле PrivEth-2 переключаем статус сделки в Status2, добавляем атрибут PaymentDate и изменяем атрибут DocSumma
  5. Убеждаемся в приходе изменения сделки на узлы PrivEth-1, PrivEth-2
  6. На узле PrivEth-1 переключаем статус сделки в Closed
  7. Убеждаемся в приходе изменения сделки на узлы PrivEth-1, PrivEth-2, а также в том, что на узле PrivEth-3 сделки по-прежнему нет

Так как распространение сделки и изменение ее состояния требует некоторого времени, то перед шагами 2, 4, 6, 8 рекомендуется выждать 30 секунд.

ВНИМАНИЕ! В примерах вызовов подставлен идентификатор пробной сделки - Вам надо подставлять вместо него идентификатор, полученный при создании сделки на шаге 1.

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

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

  • Получение идентификатора сделки
  • Проверка отсутствия сделки на других узлах (этот шаг носит чисто демонстрационный характер, дабы убедится, что сделки нигде "заранее" нет и ее репликация произойдет только после создания)
  • Собственно создание сделки

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

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

Пример вызова:

curl -X GET "http://democlient1.kekker.com/api/uid" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZqbTMz"

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

"4675ae9b-a90b-4d56-bff2-7d2a981edf01"

Проверка отсутствия сделки

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

Пример вызова:

curl -X GET "http://democlient2.kekker.com/api/deals/4675ae9b-a90b-4d56-bff2-7d2a981edf01" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZqbTMz"

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

{"ErrorMessage":"Deal not found"}

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

Используется вызов POST-метода /api/deals/. В качестве данных запроса указывается json-спецификация сделки, в нашем случае: { "dealUid": "[UID]", "kind": "DemoDeal1", "parties": [ { "key": "CLIENT1", "role": "Role1" }, { "key": "ClIENT2", "role": "Role2" } ], "parameters": [ { "key": "DocNumber", "value": "1" }, { "key": "DocDate", "value": "11.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 S2Vra2VyVXNlcjp6RGZqbTMz" -d "{ \"dealUid\": \"4675ae9b-a90b-4d56-bff2-7d2a981edf01\", \"kind\": \"DemoDeal1\", \"parties\": [ { \"key\": \"CLIENT1\", \"role\": \"Role1\" } ,{ \"key\": \"CLIENT2\", \"role\": \"Role2\" } ], \"parameters\": [ { \"key\": \"DocNumber\", \"value\": \"1\" },{ \"key\": \"DocDate\", \"value\": \"11.02.2020\" },{ \"key\": \"DocSumma\", \"value\": \"10000\" } ], \"parentDealUid\": null}"

Если всё хорошо - ответ пустой.

2. На узле PrivEth-1 переключаем статус сделки в Status1

Используется вызов POST-метода /api/deals/setstatus. В качестве данных запроса указывается json-спецификация сделки, в нашем случае: { "dealUid": "[UID]", "status": "Status1__", "remark": "Status changed to Status1 by CLIENT1", "parameters": [] }

Пример вызова:

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" -d "{ \"dealUid\":\"4675ae9b-a90b-4d56-bff2-7d2a981edf01\", \"status\":\"Status1__\", \"remark\":\"Status changed to Status1 by CLIENT1\", \"parameters\": []}"

Если всё хорошо - ответ пустой.

3. Убеждаемся в приходе сделки на узлы PrivEth-1, PrivEth-2, а также в отсутствии сделки на узле PrivEth-3

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

Пример вызовов (отличие в URL узла):

curl -X GET "http://democlient1.kekker.com/api/deals/4675ae9b-a90b-4d56-bff2-7d2a981edf01" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZqbTMz"

curl -X GET "http://democlient2.kekker.com/api/deals/4675ae9b-a90b-4d56-bff2-7d2a981edf01" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZqbTMz"

curl -X GET "http://democlient3.kekker.com/api/deals/4675ae9b-a90b-4d56-bff2-7d2a981edf01" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZqbTMz"

Пример ответа на узлах PrivEth-1, PrivEth-2 (полная расшифровка ответа дается в ..., в данном случае нас интересуют поля kind, status и коллекция parameters):

{"id":8,"uid":"4675ae9b-a90b-4d56-bff2-7d2a981edf01","kind":"DemoDeal1","status":"Status1__","remark":"Status changed to Status1 by CLIENT1","parameters":[{"key":"DocNumber","value":"1"},{"key":"DocDate","value":"11.02.2020"},{"key":"DocSumma","value":"10000"}],"parties":[{"key":"CLIENT1","role":"Role1"},{"key":"CLIENT2","role":"Role2"}],"files":[],"history":[{"status":"$Unathorised","party":{"key":"CLIENT1","role":"Role1"}},{"status":"$Initiated","party":{"key":"CLIENT1","role":"Role1"}},{"status":"Status1__","party":{"key":"CLIENT1","role":"Role1"}}],"statusMap":[{"status":"*","statusNext":"Status1__","role":"Role1"},{"status":"Status1__.1","statusNext":"Status2__","role":"Role2"},{"status":"Status1__.2","statusNext":"Status3__","role":"Role2"}]}

На узле PrivEth-3 ответ должен быть:

{"ErrorMessage":"Deal not found"}

4. На узле PrivEth-2 переключаем статус сделки в Status2, добавляем атрибут PaymentDate и изменяем атрибут DocSumma

Используется вызов POST-метода /api/deals/setstatus. В качестве данных запроса указывается json-спецификация сделки, в нашем случае: { "dealUid": "[UID]", "status": "Status2__", "remark": "Status changed to Status2 by CLIENT2", "parameters": [ { "key": "DocSumma", "value": "20022" }, { "key": "PaymentDate", "value": "15.03.2020" } ], }

Пример вызова:

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" -d "{ \"dealUid\":\"4675ae9b-a90b-4d56-bff2-7d2a981edf01\", \"status\":\"Status2__\", \"remark\":\"Status changed to Status2 by CLIENT2\", \"parameters\": [{\"key\":\"DocSumma\",\"value\":"20022"}, {\"key\":\"PaymentDate\",\"value\":\"15.03.2020\"}]}"

Если всё хорошо - ответ пустой.

5. Убеждаемся в приходе изменения сделки на узлы PrivEth-1, PrivEth-2

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

Пример вызовов (отличие в URL узла):

curl -X GET "http://democlient1.kekker.com/api/deals/4675ae9b-a90b-4d56-bff2-7d2a981edf01" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZqbTMz"

curl -X GET "http://democlient2.kekker.com/api/deals/4675ae9b-a90b-4d56-bff2-7d2a981edf01" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZqbTMz"

Пример ответа (обращаем внимание на изменение поля status и коллекции parameters и history):

{"id":8,"uid":"4675ae9b-a90b-4d56-bff2-7d2a981edf01","kind":"DemoDeal1","status":"Status2__","remark":"Status changed to Status2 by CLIENT2","parameters":[{"key":"DocNumber","value":"1"},{"key":"DocDate","value":"11.02.2020"},{"key":"DocSumma","value":"20022"},{"key":"PaymentDate","value":"15.03.2020"}],"parties":[{"key":"CLIENT1","role":"Role1"},{"key":"CLIENT2","role":"Role2"}],"files":[],"history":[{"status":"$Unathorised","party":{"key":"CLIENT1","role":"Role1"}},{"status":"$Initiated","party":{"key":"CLIENT1","role":"Role1"}},{"status":"Status1__","party":{"key":"CLIENT1","role":"Role1"}},{"status":"Status2__","party":{"key":"CLIENT2","role":"Role2"}}],"statusMap":[{"status":"*","statusNext":"Status1__","role":"Role1"},{"status":"Status1__.1","statusNext":"Status2__","role":"Role2"},{"status":"Status1__.2","statusNext":"Status3__","role":"Role2"}]}

6. На узле PrivEth-1 переключаем статус сделки в Closed

Используется вызов POST-метода /api/deals/setstatus. В качестве данных запроса указывается json-спецификация сделки, в нашем случае: { "dealUid": "[UID]", "status": "Closed___", "remark": "Deal closed by CLIENT1", "parameters": [] }

Пример вызова:

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" -d "{ \"dealUid\":\"4675ae9b-a90b-4d56-bff2-7d2a981edf01\", \"status\":\"Closed___\", \"remark\":\"Deal closed by CLIENT1\", \"parameters\": []}"

Если всё хорошо - ответ пустой.

7. Убеждаемся в приходе изменения сделки на узлы PrivEth-1, PrivEth-2, а также в том, что на узле PrivEth-3 сделки по-прежнему нет

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

Пример вызовов (отличие в URL узла):

curl -X GET "http://democlient1.kekker.com/api/deals/4675ae9b-a90b-4d56-bff2-7d2a981edf01" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZqbTMz"

curl -X GET "http://democlient2.kekker.com/api/deals/4675ae9b-a90b-4d56-bff2-7d2a981edf01" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZqbTMz"

curl -X GET "http://democlient3.kekker.com/api/deals/4675ae9b-a90b-4d56-bff2-7d2a981edf01" -H "accept: text/plain" -H "Authorization: Basic S2Vra2VyVXNlcjp6RGZqbTMz"

Пример ответа на узлах PrivEth-1, PrivEth-2 (обращаем внимание на изменение поля status и коллекцию history):

???

На узле PrivEth-3 ответ должен быть:

{"ErrorMessage":"Deal not found"}

Clone this wiki locally