kaliop/ezworkflowenginebundle

Kaliop eZ-Workflow-Engine Bundle

资助包维护!
tanoconsulting

安装次数: 3,034

依赖项: 0

建议者: 0

安全: 0

星标: 6

关注者: 5

分支: 3

公开问题: 3

类型:symfony-bundle

2.1.0 2022-11-22 12:05 UTC

This package is auto-updated.

Last update: 2024-08-29 04:37:04 UTC


README

eZPublish5 / eZPlatform 1 和 2 的工作流引擎。

10 行配置即可实现工作流

示例工作流定义

-
    type: workflow
    signal: LocationService\HideLocationSignal
    run_as: admin

-
    type: content
    mode: update
    new_remote_id: pippo
    match:
        content_id: workflow:signal:content_id

简单来说,这意味着:当任何内容被隐藏时,将其 'remote_id' 的值设置为 'pippo'。

更多“真实生活”工作流的例子

入门指南

  1. 使用 Composer 安装包,在您的应用程序 Kernel 中启用 EzWorkflowEngineBundle(如果您之前没有安装 eZMigrationBundle,您也应该启用 EzMigrationBundle - Composer 会自动为您下载它,但不会启用它)

  2. 使用专用命令在您想要的任何包中创建工作流定义

     php bin/console kaliop:workflows:generate myBundle
    
  3. 编辑工作流定义

    • 将 'signal' 元素的值更改为现有的 eZPublish 信号名称(请参阅 https://doc.ez.no/display/EZP/Signals+reference
    • 向工作流添加所需的步骤(请参阅 kaliop 迁移包的文档以获取可能的步骤定义)
  4. 检查工作流是否列为可用

     php bin/console kaliop:workflows:debug
    
  5. 连接到管理界面,执行所需的内容修改操作。(注意:如果您正在使用 Legacy Admin 界面,您可能需要进行额外的工作。请阅读下面的专用章节)

  6. 检查您定义的工作流是否已执行

     php bin/console kaliop:workflows:status
    

    此外,如果您已为 Symfony 启用 'debug' 级别记录,您会发现在 eZPublish 信号发出时,工作流引擎会将关于其操作的信息添加到日志中 1 或 2 行。

  7. 设置一个 cron 作业,它会每隔 5 分钟执行以下操作,以启动任何挂起的工作流

     php bin/console kaliop:workflows:resume -n
    
  8. 设置一个 cron 作业,它会每天执行以下操作,以清理数据库中的工作流表

     php bin/console kaliop:workflows:cleanup
    
  9. 一旦您的 workflows 经过调试和测试,别忘了将工作流定义文件作为源代码的一部分提交 ;-)

常见问题解答

问:我如何找到当前工作流正在处理的内容/位置?

答:工作流引擎会将触发工作流的信号中找到的参数作为引用。例如:workflow:signal:content_id。一旦您有了内容或位置 ID,您可以使用 'content/load' 和 'location/load' 步骤获取整个内容,并将其其他属性的新引用设置为,例如

    -
        type: content
        mode: load
        match:
            content_id: workflow:signal:content_id
        references:
            -
                identifier: the_object_name
                attribute: name

问:我如何使工作流仅对某些特定内容执行操作?

答:使用具有 'unless' 条件的工作流/取消步骤

问:除了迁移包中找到的步骤之外,还有哪些特定于工作流的步骤?

答:是的。请参阅 文档

问:我如何调试工作流?

答:默认情况下,工作流执行步骤和触发器以 DEBUG 级别详细记录在 Symfony 日志中。如果您想要一个仅针对工作流事件的单独日志文件,您可以在 config.yml 中添加类似以下内容

    monolog:
        handlers:
            workflow_log:
                type: stream
                path: "%kernel.logs_dir%/%kernel.environment%.workflow.log"
                level: debug
                channels: [ ez_workflow ]

问题:我能否暂停工作流并在稍后重新启动它?

回答:可以,就像处理迁移一样(请参阅迁移bundle中的文档以获取详细信息)。注意:当工作流重新启动时,它最初具有的所有参考值都将恢复,但是它们所引用的内容可能在同时之间已经改变。

问题:工作流引擎在运行工作流时是否发出Symfony事件?

回答:是的。目前,会发出以下事件

  • ez_workflow.before_execution
  • ez_workflow.step_executed
  • ez_workflow.workflow_aborted
  • ez_workflow.workflow_suspended

问题:工作流引擎能否用于需要用户交互的场景(例如内容审核?)

回答:目前还不能,也许永远都不会有“足够好”的方式。主要原因是因为所有的eZPublish信号都是在动作发生后触发的。因此,很难在内容已经发布后将其保持在“待审核”状态。第二个原因是目前没有方法允许与现有工作流的GUI交互(但这可以通过专用步骤轻松解决)

问题:我能否通过GUI管理工作流和触发器,就像我在eZPublish 4中做的那样?

回答:不可以,但您有命令行工具可以帮助调试和故障排除

问题:为什么您将工作流定义存储在配置文件中而不是使用数据库?

回答:这使得在不同开发/测试/生产环境中以及持续集成场景下保持一致的工作流定义变得更加容易

问题:工作流定义是否被缓存?

回答:是的。为了提高执行速度,该bundle缓存了附加到每个信号的解析工作流定义。这意味着,如果您在非dev模式下运行Symfony,您将需要在每次修改现有工作流的定义或添加/删除工作流(例如使用cache:clear命令)时清除Symfony缓存。

与旧版管理界面的集成

默认情况下,在旧版管理界面中执行编辑操作不会触发您在yml文件中定义的工作流的执行。但是,通过一些配置工作,可以做到这一点

  • 在settings.ini.override.php中启用扩展ezworkflowenginebridge
  • 清除缓存
  • 在管理界面中,创建自定义旧版工作流并将其与触发器连接起来,具体操作请参阅readme中的文档

运行测试

该bundle使用PHPUnit运行功能测试。

在工作的eZPublish / eZPlatform安装中运行测试

要运行测试

export KERNEL_DIR=app (or 'ezpublish' for ezpublish 5.4/cp setups)
export SYMFONY_ENV=behat (or whatever your environment is)

bin/phpunit --stderr -c vendor/kaliop/ezworkflowenginebundle/phpunit.xml.dist

注意这些测试不会模拟与数据库的交互,但会在其中创建/修改/删除许多类型的数据。因此,运行测试可能会留下陈旧/损坏的数据。建议使用专门的eZPublish安装或至少一个专门的数据库来运行测试套件。

为该bundle设置专门的测试环境

运行该bundle的测试的一个更安全的选择是设置一个类似GitHub Actions上测试套件运行的专用环境。优点是您可以开始使用任何版本的eZPublish;另一方面,您将更有信心添加或修改的任何测试都会在GitHub上通过。缺点是您将需要Docker和Docker-compose,并且您将使用的环境将与标准的eZPublish设置大不相同!此外,构建环境将需要大量的磁盘空间和时间。

设置专用测试环境并在此环境中运行测试的步骤

git clone --depth 1 https://github.com/tanoconsulting/euts.git teststack
# if you have a github auth token, it is a good idea to copy it now to teststack/docker/data/.composer/auth.json

# this config sets up a test environment with eZPlatform 2.5 running on php 7.4 / ubuntu jammy
export TESTSTACK_CONFIG_FILE=Tests/environment/.euts.2.5.env

./teststack/teststack build
./teststack/teststack runtests
./teststack/teststack stop

您也可以运行单个测试用例

./teststack/teststack runtests ./Tests/phpunit/01_CommandsTest.php

注意:首次运行时可能需要一些时间,但后续运行将更快。注意:请确保有足够的磁盘空间。

如果您想手动运行命令,例如symfony控制台

./teststack/teststack console cache:clear

或者轻松进入数据库shell提示符

./teststack/teststack dbconsole

或者进入运行测试的Docker容器的命令行shell提示符

./teststack/teststack shell

Docker容器中的测试使用在文件Tests/environment/.euts.2.5.env中指定的debian/php/mysql/eZPlatform内核版本运行,该版本由环境变量TESTSTACK_CONFIG_FILE指定。如果没有设置该环境变量的值,将查找名为.euts.env的文件。如果不存在此类文件,将使用一些默认值,您可以在./teststack/README.md文档中查看它们是什么。如果您想针对不同的eZ/php/debian版本进行测试,请自由

  • 创建.euts.env文件(如果尚不存在)
  • 添加任何所需的变量(请参阅文件teststack/.euts.env.example作为指导)
  • 重新构建测试堆栈
  • 以常规方式运行测试

您甚至可以通过使用不同的env文件并行保留多个测试堆栈,例如

  • 创建一个名为.euts.env.local的文件,并向其中添加任何所需的env变量,以唯一的COMPOSE_PROJECT_NAME开始
  • 通过./teststack/teststack. -e .euts.env.local build构建新的测试堆栈
  • 通过:./teststack/teststack -e .euts.env.local runtests运行测试

License Latest Stable Version Total Downloads

Build Status Scrutinizer Code Quality Code Coverage