Я работаю над системой, которая должна инициировать и отслеживать потоки Corda. Пользовательский интерфейс системы реализован в виде одностраничного веб-приложения, а его серверная часть основана на архитектуре без сервера (AWS Lambda или Azure Облачные функции). Это фактически исключает использование Observables или Websockets, так как внутренний код (функция без сервера) не будет работать достаточно долго, чтобы получать обновление через соединение RP C. Мне нужен другой способ отслеживания потоков таким образом, чтобы обеспечить более или менее своевременную обратную связь с пользователем, просматривающим веб-приложение.
Чтобы добиться этого, я хочу использовать стандартный шаблон REST для длительного Срочные транзакции. Вкратце, поток будет запущен запросом POST и вернет 202 Accepted code с заголовком Location, указывающим на URL ресурса потока. Поток будет идентифицирован его StateMachineRunId, закодированным в URL, поэтому код пользовательского интерфейса может делать GET-запрос время от времени, чтобы увидеть, где находится запрос. Не требуется предоставлять обновления в режиме реального времени, поэтому опрос представляется жизнеспособной стратегией. Задача состоит в том, чтобы надежно построить разумный ответ на запрос опроса.
Пока поток работает, это не проблема, я могу просто позвонить stateMachinesSnapshot и получить сведения о рабочем потоке на основе его UUID. Вопрос в том, что делать с законченными потоками. Для потоков, которые выполнили свой курс и произвели одну или несколько транзакций, можно получить отображение от UUID потока на транзакцию ha sh через stateMachineRecordedTransactionMappingSnapshot. Проблема в том, что это сопоставление становится все больше и больше с каждой записанной транзакцией, а в высокопроизводительной системе это замедляет все - хотя я не проверял его на производительность, просто догадка.
Еще один проблема с отображением транзакции состоит в том, что если потоку не удалось создать какую-либо постоянную транзакцию, либо по проекту, либо по ошибке, UUID больше не будет разрешаться ни к чему, и код пользовательского интерфейса получит ошибку 404 Not Found. Я предполагаю, что это может быть интерпретировано контекстуально и предоставлена соответствующая обратная связь, но это кажется громоздким.
В идеале я ищу способ прочной и масштабируемой связи уникального идентификатора экземпляра потока либо с его текущим состоянием, либо с результаты и условия прекращения. Интересно, есть ли что-то в RP C или самом Corda API, которое могло бы сделать это проще?