Эта статья — набор интересных и нестандартных решений, использованных при работе с продуктом от Software AG. Я включил в нее информацию, которую сумел вспомнить и найти в своих репозиториях и старых постах для блога. Надеюсь, что эти труды не напрасны и кому‑нибудь пригодятся. В своей предыдущей статье я рассказывал о том, кто и почему использует ARIS в 2022 году. В продолжение этой темы, спустя год (а куда торопиться?) хотелось бы написать об опыте разработок для ARIS, особенностях работы внутренней базы данных и других вещах, скрытых от глаз рядовых пользователей. Не думаю, что статья будет интересна широкому кругу читателей, но тем специалистам, которые разрабатывают скрипты и администрируют ARIS, возможно будет полезна. Изначально я планировал сделать несколько отдельных тематических публикаций, но в процессе их написания решил, что все темы достаточно небольшие и не будет практического смысла публиковать буквально 2–3 абзаца по каждой из них — это не формат Хабра. Поэтому я объединил их в один пост, который Вы сейчас читаете. Сразу оговорюсь, что здесь не будет места суперсовременным и модным подходам и фреймворкам: ARIS застыл хотя и не далеко в прошлом, но всё же надо сделать поправку на то, что это продукт из старого времени и вообще «энтерпрайз». Особенно это касается его серверной и клиентской версий, которые распространены на рынке намного шире нового облачного решения от Software AG. Хотя по правде говоря, именно старую версию и можно «допиливать». В новой версии на облаке едва ли получится сделать что‑то похожее. ARIS часто интегрируют с другими системами компании: какими? — у кого на что хватит фантазии. В этих интеграциях ARIS, как правило, выступает системой‑приемником информации, потому что в большинстве случаев использования он является неким хранилищем процессов и нормативно‑справочной информации, и загрузить туда что‑нибудь уже существующее и накопленное за долгие годы работы организации — первое, что обычно приходит в голову. Проблемы начинаются там, где загружаемой информации становится слишком много. Дело в том, что в объектной модели ARIS взаимодействие с базой осуществляется через собственные методы (API). Возможность использовать SQL отсутствует даже напрямую через СУБД, т.к. многие данные хранятся в таблицах в сериализованном виде. Поэтому единственным способом загрузить большой объем информации остаются скрипты ARIS и встроенные методы работы с данными. К счастью, в скриптах есть несколько режимов работы с базой: Немного слов о каждом режиме: SAVE_AUTO (установлен по умолчанию) - это усредненный режим, который держит в буфере некоторое количество сохранений и затем пачкой пишет в БД. Вызывается стандартным образом: ArisData.Save() либо ArisData.Save(Constants.SAVE_AUTO) - вернет настройки сохранения по умолчанию и сохранит данные. SAVE_ONDEMAND - это полностью ручной режим, когда все изменения накапливаются в сессии клиента, исполняющего скрипт, а затем массово применяются к БД. Вызывается в 2 этапа: сначала база переводится в режим сохранения по запросу ArisData.Save(Constants.SAVE_ONDEMAND), а затем при необходимости записать в базу накопившиеся изменения вызывается ArisData.Save(Constants.SAVE_NOW). SAVE_IMMEDIATELY - режим, при котором каждое сохранение записывается в БД в тот же момент, когда осуществляется вызов соответствующей команды создания/удаления/изменение какого-либо объекта из кода скрипта. То есть сначала необходимо вызвать: ArisData.Save(Constants.SAVE_IMMEDIATELY). После этого все строки кода, изменяющие данные в базе, будут в тот же момент применяться к данным в БД. Для иллюстрации работы различных режимов я написал скрипт, который делает следующее: создает 1000 групп (каталогов) в корневом каталоге базы; создает 1000 моделей в корневом каталоге базы; создает 1000 определений объектов в корневом каталоге базы; создает 1000 экземпляров объектов на одной из моделей; очищает базу (удаляет из нее все созданные объекты. Код скрипта здесь, если кто-нибудь захочет воспроизвести этот тест. Результаты работы в виде таблицы (тесты проводились на локальной машине, так что абсолютные показатели скорости работы не особо интересны, только относительные): Режим  1000 групп 1000 моделей 1000 определений 1000 экземпляров Очистка базы Общее время Разница SAVE_AUTO 00:42,848 00:00,733 00:00,322 01:35,659 01:42,450 04:02,013 100% SAVE_ONDEMAND 00:00,536 00:01,394 00:00,119 00:38,568 00:39,868 01:25,031 ~-65% SAVE_IMMEDIATELY 00:30,684 00:37,403 00:40,661 01:32,435 03:57,794 07:18,978 ~+81% В таблице наглядно видно, что сохранение пачками на 65% быстрее режима по умолчанию. Сохранение же каждого элемента отдельно наоборот увеличивает время выполнения на 81%. Помимо скорости работы у режима SAVE_ONDEMAND есть еще одно недокументированное преимущество: в этом режиме можно манипулировать моделями, получать отфильтрованные модели, что-то добавлять и удалять, генерировать изображения таких измененных моделей, при этом не внося данные в базу. Это бывает очень полезно, например, когда надо вывести какую-то сложную модель, разгрузив ее от лишней информации или, наоборот, внеся какие-то изменения, которые не предполагается сохранять. Пример: Все изменения сохраняются только в той сессии, в которой исполняется скрипт, и если в коде скрипта отсутствует команда ArisData.Save(Constants.SAVE_NOW), то эти изменения не будут внесены в базу. Если кто-нибудь захочет поэкспериментировать, то код скрипта с примером базы здесь. Тем, кто занимается разработкой скриптов ARIS, хорошо известно, что все версии продукта, начиная с 7.1, написаны на Java и исполняются в соответствующей среде. Скрипты же позволяют манипулировать данными на языке JavaScript, однако, все методы и классы ARIS — это те же Java‑библиотеки. Поэтому ничто не мешает написать свой модуль или использовать сторонний, загрузив его в соответствующую папку на сервере, либо на локальный сервер. На сервер — потому что все скрипты категории Отчеты (Reports), манипулирующие данными, исполняются на сервере в отличие от макросов, выполняющихся на стороне клиента. Стоит упомянуть некоторые частности, поскольку те, кто пишет скрипты для ARIS зачастую немного далеки от Java (как и я когда-то): если ARIS версии 7.2, то он функционирует в среде Java 1.6. Это значит, что те Java-модули, которые Вы напишите или хотите использовать должны соответствовать этой версии. И их зависимости тоже. если ARIS версии 9.8, то он функционирует в среде Java 1.8. Далее - аналогично предыдущему пункту. если ARIS 10 - аналогично 9.8 (но не могу быть уверен, т.к. нет доступа к этой версии). Кроме того, стоит помнить, что если вы используете зависимости, то jar-файлы этих зависимостей тоже должны попасть в библиотеку на сервере либо должны быть явно включены в ваш модуль. Рассмотрим простой пример. Напишем Java класс из двух статичных методов для получения JSON строки из URL и превращения ее в объект. Теперь необходимо собрать jar-файл и положить его на сервер ARIS. Я собрал один файл с зависимостями (см. проект на github), хотя если планируется добавлять много модулей на сервер, то лучше загружать отдельно собственные модули и отдельно jar-файлы используемых зависимостей. Это поможет в дальнейшем избежать конфликтов. Проблемы могут быть разного порядка: от кривой работы библиотек до невозможности запуска сервера. Затем, перезапустив сервер, можно вызывать загруженный модуль из кода скрипта. Например, так: * в примере умышленно использован протокол http. Если обращаться к https, то получим вот такую ошибку, которую, конечно, можно пофиксить, но это за рамками данной статьи. Куда класть скомпилированные Java-библиотеки и зависимости на сервере / локальном сервере: ARIS 7.2: (пример для локального сервера): [каталог установки]\LocalServer\lib ARIS 9.8: (пример для локального сервера): [каталог установки] \ LOCALSERVER\bin\work\work_abs_local\base\webapps\abs\WEB-INF\lib ARIS 10: (аналогично 9.8). Вот собственно и все. Можно загружать Java-библиотеки и использовать их в своих скриптах. Главное не забывать о соответствии версий Java и ARIS. Одним из основных назначений скриптов в ARIS являются манипуляции с данными и выдача отчетов и готовых документов в различных форматах (docx, xlsx, pdf и т. д.). Собственно скрипты и называются в ARIS отчетами - Reports. Отчеты имеют свою встроенную библиотеку для вывода данных. Она использует под собой POI библиотеку. В те времена, когда я занимался разработкой под этот продукт, встроенная библиотека сильно отставала даже от базовых функций, доступных в офисных редакторах, и сгенерировать более‑менее сложный документ было нерешаемой задачей. Но поскольку многие продолжают пользоваться устаревшими версиями ARISа — проблема вполне вероятно может быть очень даже актуальной. Посмотрев как формируются и выдаются отчеты, я обнаружил, что POI по сути является оберткой-реализацией для ooxml-схем, скомпилированных из стандартов ECMA-376. Встроенная же библиотека для работы с отчетами урезала и без того урезанную POI. Поэтому я решил отказаться и от встроенной библиотеки, и от POI, а взять за основу ooxml библиотеку, собранную на основе стандартов и писать обертку для нее. Вообще я не люблю работу ради работы, поэтому сначала попытался найти какую-нибудь лазейку и просто добавить те функции вывода, которых мне не хватало (а не хватало мне сносок в конце страницы/документа и добавления встроенных файлов). Но попытки были тщетны, потому что встроенная библиотека генерировала отчеты, используя свои классы, а не POI. POI же не годился по двум причинам: там еще не были реализованы функции, которые были нужны мне и вдобавок он формировал файл, который ARIS отказывался воспринимать как результат, потому что работал только со своими обертками. В итоге пришлось писать собственную библиотеку. Загрузив в ARIS (как описано в предыдущем разделе этого поста) ooxml-schemas.jar, я приступил к работе. Результат получился вот такой, потому что библиотеку я решил сделать прямо в ARIS'е на Javascript, а не на Java. Вероятно, сама библиотека получилась немного громоздкой, но свои функции на тот момент она выполняла и количество кода, которое нужно было написать для вывода отчета в документ, не изменилось по сравнению со стандартными средствами. *Прошу прощения за код без отступов, это просто демонстрация работы методов.  Кроме работы с docx документами, можно было реализовать генерацию и xlsx, и pptx, но моего энтузиазма в тот момент хватило только на отчеты в формате Word :) На этом я бы хотел закончить свой рассказ про «костыли и велосипеды» для ARIS'а. Надеюсь, что не утомил подробностями. Возможно кто‑то воспользуется наработками и применит их в своих скриптах. Спасибо, что дочитали.  Разработчик / Системный аналитик