По данным техподдержки, за первый квартал 2023 года в среднем поступало по 3-4 заявки в месяц в рамках региона. Подавляющая часть неисправностей вызвана изменениями в структуре сообщений по видам сведений и изменениями в справочниках ЕСНСИ. Т.к. данные источники изменений неподконтрольны разработчику решения, приходится адаптировать решение (силами организации, обслуживающей по контракту).
Разработкой продукта занималась средних размеров scrum-команда. Путь от задумки до работающего решения занял около 5 месяцев, дальнейшая работа касалась в основном реализации поддержки новых услуг.
К факторам, которые упрощали нашу задачу, стоит отнести сильные стороны движка Workflow Core (довольно невысокий порог вхождения, поддержка параллельного выполнения шагов, механизма событий, встраиваемость в решение), а также наличие у команды опыта в решении интеграционных задач через СМЭВ на других проектах. Некоторые слабые стороны движка (отсутствие визуализации состояния процессов, сложность внесения изменений в существующие бизнес-процессы) и где-то неаккуратное его использование — замедляли работу.
В остальном какие-то дополнительные особенности сверх того, что описано в этой и предыдущих статьях цикла, отметить сложно без конкретизации того, что Вас интересует.
В дополнение к комментарию mayorovp: движок поддерживает варианты описания бизнес-процессов в JSON и YAML, однако удобного средства настройки, как например, для Camunda, в Workflow Core нет.
Если Вы имеете в виду Workflow Core, то это отдельная разработка, не относящаяся к фреймворку .NET: github.com/danielgerlag/workflow-core. Если подразумеваете какой-то другой компонент, то уточните, какой именно?
Из текста не понял, формат «вложения» хоть как-нибудь стандартизирован или туда можно напихать все что угодно.
Во вложении размещается файл «application.xml» со всеми данными из формы, которую заполнил пользователь (+ опись вложений). Структура документа, расположенного в файле «application.xml», может (и должна) быть проверена по XSD-схеме, которая и определяет модель вида сведений. Но это делается, как Вы верно заметили, уже по ту и/или другую сторону СМЭВа, что может добавить хлопот.
ИМХО конверт тут не нужен от слова совсем.
СМЭВ-конверт в случае универсального вида сведений включает данные, которые позволяют идентифицировать оказываемую услугу и ведомство (каждой услуге и ведомству соответствуют некоторые числовые коды). Поскольку структура конверта максимально проста и универсальна, это позволяет зарегистрировать взаимодействие по универсальному виду сведений однократно, а затем вводить произвольное количество услуг в его рамках и согласовывать их уже по упрощённой процедуре.
Дело в том, что года два назад мы затеяли переход на .NET Core и Linux, и на тот момент подходящего решения от «КриптоПро» не было. Зато была Java CSP, которую, к слову, мы использовали и ранее в составе упомянутого сервиса в других проектах. Собственно, потому и решили остаться на проверенном варианте, слегка дополнив его реализацию.
Решение получилось разноплановое: обработка сообщений реализована на .Net Core с помощью модели классов, полученной по XSD-схемам СМЭВа. Это касается как непосредственно конверта СМЭВ, так и блоков бизнес-данных.
Подпись и проверка выполняются по запросу основного решения параллельно работающим сервисом. Этот сервис реализован уже на Java и в своей работе опирается на библиотеку «КриптоПро», которая, в том числе, обеспечивает нормализацию результирующих сообщений перед отправкой.
Таким образом, как верно заметил casta001, наш «адаптер» встал в стройные ряды изделий ручной работы )
По данным техподдержки, за первый квартал 2023 года в среднем поступало по 3-4 заявки в месяц в рамках региона. Подавляющая часть неисправностей вызвана изменениями в структуре сообщений по видам сведений и изменениями в справочниках ЕСНСИ. Т.к. данные источники изменений неподконтрольны разработчику решения, приходится адаптировать решение (силами организации, обслуживающей по контракту).
Прошу прощения за задержку, изображения переехали и теперь доступны для просмотра.
К факторам, которые упрощали нашу задачу, стоит отнести сильные стороны движка Workflow Core (довольно невысокий порог вхождения, поддержка параллельного выполнения шагов, механизма событий, встраиваемость в решение), а также наличие у команды опыта в решении интеграционных задач через СМЭВ на других проектах. Некоторые слабые стороны движка (отсутствие визуализации состояния процессов, сложность внесения изменений в существующие бизнес-процессы) и где-то неаккуратное его использование — замедляли работу.
В остальном какие-то дополнительные особенности сверх того, что описано в этой и предыдущих статьях цикла, отметить сложно без конкретизации того, что Вас интересует.
Во вложении размещается файл «application.xml» со всеми данными из формы, которую заполнил пользователь (+ опись вложений). Структура документа, расположенного в файле «application.xml», может (и должна) быть проверена по XSD-схеме, которая и определяет модель вида сведений. Но это делается, как Вы верно заметили, уже по ту и/или другую сторону СМЭВа, что может добавить хлопот.
СМЭВ-конверт в случае универсального вида сведений включает данные, которые позволяют идентифицировать оказываемую услугу и ведомство (каждой услуге и ведомству соответствуют некоторые числовые коды). Поскольку структура конверта максимально проста и универсальна, это позволяет зарегистрировать взаимодействие по универсальному виду сведений однократно, а затем вводить произвольное количество услуг в его рамках и согласовывать их уже по упрощённой процедуре.
Подпись и проверка выполняются по запросу основного решения параллельно работающим сервисом. Этот сервис реализован уже на Java и в своей работе опирается на библиотеку «КриптоПро», которая, в том числе, обеспечивает нормализацию результирующих сообщений перед отправкой.
Таким образом, как верно заметил casta001, наш «адаптер» встал в стройные ряды изделий ручной работы )