work-flow-flowable-ui: Интеграция официальных Rest-пакетов Flowable (flowable-modeler, flowable-idm, flowable-task, flowable-admin, flowable-rest), бэкенд на Spring Boot, фронтенд на Nginx, раздельное развёртывание интерфейса и сервера, обработка локализации конструктора форм, предоставление онлайн-демонстрации.

Примечание: через класс StencilSetResource можно перевести процесс-дизайнер (на самом деле нет необходимости переписывать класс, достаточно перевести содержимое файла stencilset_bpmn.json, переписывание предназначено для будущей совместимости с интернационализацией).

ApplicationConfiguration

@Configuration
@EnableConfigurationProperties({FlowableIdmAppProperties.class, FlowableModelerAppProperties.class, FlowableAdminAppProperties.class})
@ComponentScan(
    basePackages = {
        "org.flowable.ui.admin.repository",
        "org.flowable.ui.admin.service",
        "org.flowable.ui.task.model.component",
        "org.flowable.ui.task.service.runtime",
        "org.flowable.ui.task.service.debugger",
        "org.flowable.ui.idm.conf",
        "org.flowable.ui.idm.security",
        "org.flowable.ui.idm.service",
        "org.flowable.ui.modeler.repository",
        "org.flowable.ui.modeler.service",
        "org.flowable.ui.common.filter",
        "org.flowable.ui.common.service",
        "org.flowable.ui.common.repository",
        "org.flowable.ui.common.security",
        "org.flowable.ui.common.tenant"
    },
    excludeFilters = {
        @ComponentScan.Filter(type = FilterType.ASSIGNABLE_TYPE, value = org.flowable.ui.idm.conf.ApplicationConfiguration.class)
    }
)

Примечание: с помощью аннотации @ComponentScan сканируются необходимые пакеты и их интерфейсы.

DatabaseConfiguration

/**
 * Переписать класс DatabaseConfiguration в flowable-ui-xxx-conf, включая DatabaseConfiguration в flowable-ui-modeler-conf и flowable-ui-admin-conf.
 */
@Configuration
@EnableTransactionManagement
public class DatabaseConfiguration {
    private static final Logger LOGGER = LoggerFactory.getLogger(DatabaseConfiguration.class);
    @Bean
    public Liquibase modelerLiquibase(DataSource dataSource) {
        Liquibase liquibase = null;
        try {
            DatabaseConnection connection = new JdbcConnection(dataSource.getConnection());
            Database database = DatabaseFactory.getInstance().findCorrectDatabaseImplementation(connection);
            database.setDatabaseChangeLogTableName("ACT_DE_" + database.getDatabaseChangeLogTableName());
            database.setDatabaseChangeLogLockTableName("ACT_DE_" + database.getDatabaseChangeLogLockTableName());
            liquibase = new Liquibase("META-INF/liquibase/flowable-modeler-app-db-changelog.xml", new ClassLoaderResourceAccessor(), database);
            liquibase.update("flowable");
            return liquibase;
        } catch (Exception e) {
            throw new InternalServerErrorException("Error creating liquibase database", e);
        } finally {
            closeDatabase(liquibase);
        }
    }
    @Bean
    public Liquibase adminLiquibase(DataSource dataSource) {
        LOGGER.debug("Configuring Liquibase");
        Liquibase liquibase = null;
        try {
            DatabaseConnection connection = new JdbcConnection(dataSource.getConnection());
            Database database = DatabaseFactory.getInstance().findCorrectDatabaseImplementation(connection);
            database.setDatabaseChangeLogTableName("ACT_ADM_" + database.getDatabaseChangeLogTableName());
            database.setDatabaseChangeLogLockTableName("ACT_ADM_" + database.getDatabaseChangeLogLockTableName());
            liquibase = new Liquibase("META-INF/liquibase/flowable-admin-app-db-changelog.xml", new ClassLoaderResourceAccessor(), database);
            liquibase.update("flowable");
            return liquibase;
        } catch (Exception e) {
            throw new InternalServerErrorException("Error creating liquibase database");
        } finally {
            closeDatabase(liquibase);
        }
    }
    private void closeDatabase(Liquibase liquibase) {
        if (liquibase != null) {
            Database database = liquibase.getDatabase();
            if (database != null) {
                try {
                    database.close();
                } catch (DatabaseException e) {
                    LOGGER.warn("Error closing database", e);
                }
            }
        }
    }
}

Примечание: создание модели хранения таблиц для Modeler и конфигурационных таблиц для сервиса Admin.

TaskUserCacheImpl Задача приводит к тому, что при обращении к modeler в качестве корневого пути запроса используется путь запроса для проекта на стороне сервера. При обращении к idm, admin или task необходимо добавить путь idm/. В результате возникают проблемы с путями запросов при обращении к интерфейсам на стороне сервера, независимо от того, используются ли относительные или абсолютные пути. На решение этой проблемы уходит много времени. Ниже будет рассказано о новом способе интеграции страниц.

Проблемы с версиями Flowable и SpringBoot

В flowable-ui-modeler-conf класс конфигурации AppDispatcherServletConfiguration реализует интерфейс WebMvcRegistrations. В SpringBoot 1.x класс WebMvcRegistrations находится в пакете web модуля spring-boot-autoconfigure, а в SpringBoot 2.x он перемещён в пакет web.servlet. Поэтому при использовании класса по умолчанию версия SpringBoot должна быть 2.x.

Конфликты пакетов официальной версии Flowable

Поскольку интеграция основана на flowable-modeler, flowable-idm, flowable-task и flowable-admin, то для серверной части также требуются соответствующие четыре пакета. Поэтому были интегрированы пакеты flowable-ui-modeler-conf, flowable-ui-idm-conf, flowable-ui-task-conf и flowable-ui-admin-conf. Однако из-за наличия собственных классов автоматической конфигурации в этих четырёх пакетах и их связи с бизнес-логикой в modeler и admin, а также из-за существования нескольких классов с одинаковыми именами Spring Bean, контекст Spring инициализируется неудачно из-за конфликтов имён Bean. Некоторые из конфигураций по умолчанию не могут быть удалены, поэтому окончательное решение заключается в удалении всех исходных конфигураций по умолчанию и использовании @ComponentScan для исключения конфликтующих классов.

Проблема с правами доступа при входе

Пакеты flowable-ui-modeler-conf, flowable-ui-idm-conf, flowable-ui-task-conf и flowable-ui-admin-conf содержат классы SecurityConfiguration, которые представляют собой конфигурацию безопасности. Однако во время интеграции ожидается, что вход в систему будет осуществляться через idm, а собственная проверка безопасности других модулей не требуется. Но на самом деле из-за существующей проверки безопасности и стандартных перехватчиков в других модулях проверка безопасности idm не проходит. Решение аналогично предыдущему: путём сканирования пакетов исключаются конфликтующие пакеты, либо реализуется собственная конфигурация.

Интеграция страниц

Первоначально интеграция страниц была выполнена путём интеграции в проект на стороне сервера с возможностью вызова интегрированного конструктора процессов при разработке собственных страниц. Однако из-за проблем с другими модулями страниц интеграция была временно приостановлена, и было решено использовать Nginx для развёртывания клиентской части, что соответствует архитектуре разделения между клиентом и сервером.

Конфигурация Nginx

server {
        listen 8081;
        server_name flowable_ui;
        location / {
            root /user/local/nginx/flowable-ui;
            index index.html index.htm;
        }
        location /flowable_idm {
            proxy_pass http://localhost:8080/flowable;
            proxy_cookie_path  /flowable  /flowable_idm;
        }
        location /flowable_task {
            proxy_pass http://localhost:8080/flowable;
            proxy_cookie_path  /flowable  /flowable_task;
        }
        location /flowable_admin {
            proxy_pass http://localhost:8080/flowable;
            proxy_cookie_path  /flowable  /flowable_admin;
        }
        location /flowable_modeler {
            proxy_pass http://localhost:8080/flowable;
            proxy_cookie_path  /flowable  /flowable_modeler;
        }
}

Примечание: можно использовать Nginx для разделения обработки статических и динамических ресурсов, но в процессе попытки возникли проблемы, и пришлось использовать более простой подход.

Затем в каталоге flowable-ui создаются каталоги modeler, idm, task и admin. Содержимое flowable-xxx/WEB-INF/classes/static из файлов flowable-modeler.war, flowable-idm.war, flowable-task.war и flowable-admin.war копируется в соответствующие каталоги. Теперь можно получить доступ к соответствующим страницам через http://localhost:8086/modeler... Однако из-за совпадения путей для статических и динамических ресурсов запросы не перенаправляются на серверную часть, поэтому необходимо различать запросы для статических и динамических ресурсов. Это требует изменения исходного кода официальных страниц и добавления префикса к унифицированным путям запросов.

flowable-ui

Унифицированные пути запросов изменены:

В файле modeler/scripts/app-cfg.js значение contextRoot изменено на flowable_modeler для различения от статических ресурсов.

'use strict';
var FLOWABLE = FLOWABLE || {};
var pathname = window.location.pathname.replace(/^(\/[^\/]*)(\/.*)?$/, '$1').replace(/\/$/, '');
FLOWABLE.CONFIG = {
    'onPremise' : true,
    'contextRoot' : "/flowable_modeler",
    'webContextRoot' : pathname,
    'datesLocalization' : false
};

В файле idm/scripts/app-cfg.js значение contextRoot изменено на flowable_idm для различения от статических ресурсов.

'use strict';
var FLOWABLE = FLOWABLE || {};
var pathname = window.location.pathname.replace(/^(\/[^\/]*)(\/.*)?$/, '$1').replace(/\/$/, '');
FLOWABLE.CONFIG = {
    'onPremise' : true,
    'contextRoot' : "/flowable_idm",
    'webContextRoot' : pathne,
    'datesLocalization' : false
};

В файле task/scripts/app-cfg.js значение contextRoot изменено на flowable_task для различения от статических ресурсов.

'use strict';
var FLOWABLE = FLOWABLE || {};
var pathname = window.location.pathname.replace(/^(\/[^\/]*)(\/.*)?$/, '$1').replace(/\/$/, '');
FLOWABLE.CONFIG = {
    'onPremise' : true,
    'contextRoot' : "/flowable_task",
    'webContextRoot' : pathname,
    'datesLocalization' : false
};

Для admin используется другой подход, поэтому в файле admin/scripts/config.js добавлено аналогичное изменение.

FlowableAdmin.webContextRoot = '/flowable_admin';

Затем с помощью инструмента разработки всем REST-запросам добавлен префикс FlowableAdmin.webContextRoot.

Например:

url: '/app/

Заменено на:

url: FlowableAdmin.webContextRoot + '/app/

Другие URL, не соответствующие этому формату, могут быть изменены вручную. Выполните класс запуска SpringBoot для бэкенда, запустите бэкенд-сервис.

Запустите Nginx.

В этот момент можно получить доступ к четырём операционным страницам, предоставленным Flowable, через следующие четыре ссылки. Однако при первом посещении вы будете перенаправлены на страницу входа, поскольку вы не вошли в систему. При первом запуске бэкенд-приложения будут инициализированы два аккаунта, которые можно запросить по таблице ACT_ID_USER.

http://localhost:8081/idm/

http://localhost:8081/modeler/

Подписывайтесь на мой официальный аккаунт WeChat: FramePower. Я буду периодически публиковать накопленные технические знания. Добро пожаловать ко мне всем, кто интересуется технологиями и хочет учиться вместе!

Изображение 1 официального аккаунта WeChat

OSCHINA-MIRROR/work-flow-flowable-ui

Проблемы с версиями Flowable и SpringBoot

Конфликты пакетов официальной версии Flowable

Проблема с правами доступа при входе

Интеграция страниц

Комментарии ( 0 )

Введение

Обновления

Участники

Недавние действия

OSCHINA-MIRROR/work-flow-flowable-ui .gitee-modal { min-width: 500px !important; } .gitee-modal .close { right: 0.6rem !important; }

Проблемы с версиями Flowable и SpringBoot

Конфликты пакетов официальной версии Flowable

Проблема с правами доступа при входе

Интеграция страниц

Комментарии ( 0 )

Введение

Обновления

Участники

Недавние действия

OSCHINA-MIRROR/work-flow-flowable-ui