Всем привет! На связи Александр Никифоров, архитектор приложений в ЦК СЭД ДОМ.РФ. Сегодня расскажу о том, какую роль low-code играет в интеграционных задачах и почему команда СЭД все-таки решила обходиться без этого инструмента. Кстати, ранее я писал про нашу систему электронного документооборота, почитать можно здесь и здесь.
Минутка терминологии:
low-code — метод разработки, при котором к программированию «вручную» прибегают минимально. Вместо кода для моделирования приложений используются визуальные конструкторы, а для решения типовых задач — готовые скрипты.
А теперь — к сути!
Начнем с того, как обычно реализуются интеграционные задачи в СДУ «Приоритет» на платформе Docsvision. Для интеграции используется сервис «Интеграционный Интерфейс» от Digital Design, который с одной стороны подключается к серверу приложений, а с другой — предоставляет SOAP-сервис.
Перечень реализованных методов выглядит примерно так:
Сам сервис заточен под первые реализации МЭДО, т.е. основан на схемах http://www.infpres.com/IEDMS. Он также интегрирован с платформенным low-code функционалом, таким как поисковые папки и представления.
Любая СЭД априори должна иметь инструменты фильтрации и отображения информации без SQL-кода. Платформа Docsvision не исключение: в ней такие инструменты есть, и они весьма удобны.
Систему использует широкий круг специалистов: разработчики, инженеры поддержки и внедрения, аналитики, а в некоторых случаях — даже бизнес. Главные преимущества: отсутствие требований к компетенциям в SQL и поддержка метода «тыка».
Технически атрибутивный поиск представляет собой XML, который впоследствии конвертируется в SQL-запрос средствами платформы.
Полученный код вполне себе качественный и безопасный, придираться к возможности оптимизации пока не будем.
Теперь, когда инженер накликал атрибутивный запрос, повесил его на виртуальную папку, самое время подключить его к интеграционному интерфейсу.
Для этого мы выбираем в интерфейсе нужную папку с атрибутивным запросом, при необходимости добавляем входящие параметры.
Казалось бы, что может быть проще?
Как я уже говорил, интеграционный интерфейс основан на схеме IEDMS (МЭДО), основные сущности типа Document (Document2) не соответствуют сущностям СЭД, поэтому некоторые данные документа получить стандартными методами невозможно. И тут нам снова приходит на помощь платформенный low-code, а именно представления.
Сложность создания, как и функциональность, вырастает в разы, но это все еще low-code.
Представление цепляется на папку и аналогично публикуется на интеграционном интерфейсе, различие лишь в вызываемом для получения данных представления методе.
Снимаю шляпу перед разработчиками, которые потратили тысячи, а может и десятки тысяч
человеко-часов для создания таких функциональных и стабильных инструментов.
Почему же тогда нужно решительно отказаться от подобной красоты?
Начнем издалека. СЭД варится в своей атмосфере: тут иные мотивации, другие нравы произрастают. Полгода на ТЗ, полгода на заключение контракта, а потом через год ставим релиз, превозмогая вылезающие ошибки. Так можно описать средний жизненный цикл крупной потребности между ее появлением и реализацией в продуктивной среде.
Накопилось много ошибок? Не беда! Исправим все в одном большом релизе в конце года. Подход солидный, степенный, не предполагающий лишней суеты и спешки.
Но на практике чаще все-таки приходится работать с людьми, которые предпочитают неторопливому подходу стремительные забеги. В таких случаях встречи по вопросам интеграции выглядят примерно так:
Бизнес: Всем привет! Вот есть потребность интегрировать СЭД с системой АБВГД, экономим тысячи человеко-часов. Вот БТ. Когда сможем начать?
ЦК АБВГД: В принципе, задача ясна. Можем взять в анализ прямо сейчас, а разработку начнем через 10 дней в следующем спринте.
ЦК СЭД: Аааа…Эээээ… Передадим подрядчику на оценку и недели через две вернемся со сроками. Возможно. А начать сможем месяца через два. Но это не точно. Если денег по договору хватит.
В худшем случае бизнес отчаивается получить ответ от СЭД в приемлемые сроки и решается реализовать функционал не в целевой системе, а где-то в другом месте. Бизнес-процессы от такой импровизации получаются на загляденье растрепанными и фрагментированными, собрать их обратно в кучу — практически неподъемная задача.
Очевидный выход из ситуации — «домашняя» команда разработки, которая сможет стремительно набрасываться и раскусывать интеграционные орешки, благо функционал позволяет. Но на практике при использовании low-code в таком ключе возникает масса вопросов:
Возможно ли синхронизировать работу команд, если в одной перекат в прод осуществляется нажатием кнопки, а в другой — многочасовым накликиванием интерфейса?
Как получить гарантию, что на тесте и на продуктиве развернуто одно и то же?
Как собрать в одном месте все изменения и совместно с ними работать?
Как быстро вернуться к предыдущей версии?
А что будет, если в тестовой среде потребуется актуализировать БД? Как тогда сохранить наработки?
Ответы на эти вопросы найдены давно: про DevOps только ленивый не слышал. Но места для low-code в CI/CD пайплайнах нет. Как не суждено летать тому, кто рожден ползать, так и не стать кодом тому, что создано для нажимания кнопочек в интерфейсе.
Методом ExecuteReport интеграционный интерфейс позволяет вызывать хранимые процедуры в БД через сервер приложений. Это и стало нашим спасением. Развертывание процедур — простая задача для CI/CD платформ. Добавление свойств в карточки СЭД также решается через CI/CD. Единственная нерешенная пока еще проблема — отображение созданного свойства в разметке веб-клиента, но для интеграционных задач это не критично.
Так чем же плох low-code?
Инструментарий, совместимый с CI/CD и предназначенный для внутренних команд разработки, — насущная потребность для систем электронного документооборота в наше время. А вот low-code, даже самый базовый, принципиально несовместим с концепцией «Всё как код». Именно поэтому нам и пришлось с ним попрощаться.
Замечания? Предложения? Пишите в комментариях, с удовольствием обсудим.
UPD: кстати, подробнее о CI/CD и СЭД расскажем в отдельной статье. На связи!