В SILA Union автоматизацию можно строить напрямую через API. Но если писать на Java или Groovy, есть более удобный вариант — библиотека bpm-script-lib. Она даёт объектную модель репозитория: TreeRepository, Model, ObjectElement, Edge, AttributesManager и другие классы для работы с моделями, объектами, связями и атрибутами. Библиотеку можно подключить к обычному Maven-проекту и разрабатывать скрипты во внешней IDE.

Maven-репозиторий SILA Union: https://nexus.silaunion.ru/repository/maven-public

Параметры подключения зависимости: groupId: ru.nextconsulting.bpm artifactId: bpm-script-lib version: должна совпадать с версией установленной SILA Union

Например, для версии 1.11.7.1 готовый jar лежит здесь: https://nexus.silaunion.ru/repository/maven-releases/ru/nextconsulting/bpm/bpm-script-lib/1.11.7.1/bpm-script-lib-1.11.7.1.jar

Совпадение версий здесь важно — это отдельно оговорено в документации библиотеки.

Зачем вообще использовать библиотеку, если есть API? Главное преимущество для меня — разработка становится похожа на обычную работу с Java-кодом.

Вместо ручного формирования URL, JSON и разбора ответов я работаю с типами платформы.

Например: TreeRepository — репозиторий Model — модель ObjectElement — экземпляр объекта на диаграмме Edge — связь AttributesManager — работа с атрибутами

IDE знает эти классы, показывает доступные методы и параметры. Появляется автодополнение, навигация по коду и контроль типов. Часть ошибок можно увидеть ещё до запуска скрипта.

Особенно хорошо разница видна на работе со связями. Через объектную модель у ObjectElement можно получить исходящие связи через getExitEdges(), перейти к целевым элементам и продолжить работать уже с объектами модели.

При прямой работе через API ту же задачу приходится раскладывать вручную: получить модель, выбрать связи, отфильтровать нужные EdgeInstance, собрать идентификаторы целевых элементов и затем получить определения объектов. В документации SILA Union даже приведены оба варианта, и реализация через API получается заметно сложнее.

При этом API никуда не исчезает. Через тот же контекст можно получить, например, UsersApi или GroupsApi через context.getApi(…) и вызвать нужные методы платформы. То есть библиотека не отрезает разработчика от API, а добавляет поверх него удобный типизированный слой.

Поэтому мой рабочий принцип такой: Если автоматизация работает с моделью внутри SILA Union — сначала смотрю на bpm-script-lib. Если интегрируется внешняя система — тогда уже напрямую на API.

Именно в таком подходе SILA Union для меня перестаёт быть просто инструментом для рисования архитектурных схем.

Архитектурный репозиторий становится программно доступной моделью данных, которую можно автоматически проверять, преобразовывать и анализировать.

А дальше возникает ещё более интересный вопрос: что получится, если к этому программному слою добавить ИИ?

#SILAUnion #Архитектура #КорпоративнаяАрхитектура #Автоматизация #API #Java #Groovy #АрхитектурныйРепозиторий