服务ECA规则

一条ECA（事件event-条件condition-动作action）规则是一种特殊的规则，基于事件有条件地执行动作。对于服务ECA（SECA）规则，事件是执行服务的各个阶段，这些为所有服务调用触发。

服务ECA天生是为了触发业务流程和扩展现有的不想或不能修改的服务的功能的。服务ECA不应该被泛用于源自其他实体的数据的维护，对于那些，实体ECA规则是更好的工具。

这是一个来自Mantle业务构件中的AccountingInvoice.secas.xml文件的一条SECA规则的例子，它调用一个服务来在装运后为订单创建发票：

<seca service="update#mantle.shipment.Shipment" when="post-service">
    <condition><expression>statusChanged &amp;&amp; statusId == 'ShipPacked' &amp;&amp; !(oldStatusId in ['ShipShipped', 'ShipDelivered'])</expression></condition>
    <actions>
        <entity-find-one entity-name="mantle.shipment.Shipment" value-field="shipment"/>
        <set field="shipmentTypeEnum" from="shipment.'ShipmentType#moqui.basic.Enumeration'"/>
        <if condition="shipmentTypeEnum?.enumId == 'ShpTpOutgoing' || shipmentTypeEnum?.parentEnumId == 'ShpTpOutgoing'">
            <service-call name="mantle.account.InvoiceServices.create#SalesShipmentInvoices" in-map="[shipmentId:shipmentId]"/>
       </if>
    </actions>
</seca>

seca元素上的必须属性是带服务名的service，和表示在服务调用内的什么阶段的when。这两个属性一起组成触发SECA规则的事件。这也有一个run-on-error属性，默认为false，如果设置为true，即使服务调用中有错误发生，也会触发此SECA规则。

when属性的选项有:

• pre-auth: 在身份鉴定和鉴权前、但是在使用authUsername、authPassword参数和特定用户登录后运行；对与身份鉴定或鉴权相关的任何自定义行为有用。
• pre-validate: 在输入参数被校验前运行；有用于在校验和数据类型转换前添加或修改参数。
• pre-service: 在服务被运行前运行；在运行服务前要完成的事情的最好的地方。
• post-service: 就在服务运行后运行；在服务运行后完成并且不依赖于事务的事情的最好的地方。
• post-commit: 在提交后运行，不管提交实际完成没有（依赖于服务设置和在用的TX等）。在实际提交时运行，用tx-commit选项。
• tx-commit: 服务运行的事务被成功提交时运行。在服务运行之后获取其数据，所以会有服务的输出/结果以及输入参数。
• tx-rollback: 在服务运行的事务被回滚时运行。在服务运行之后获取其数据，所以会有服务的输出/结果以及输入参数。

动作运行时，上下文将是服务所运行的上下文，为了方便使用入参，还加上服务的入参。如果when是在服务自身被运行之前，将有个叫parameters的上下文字段，里面有输入参数的Map，你可以在ECA动作中按需修改。如果when是在服务自身被运行之后，parameters字段将包含输入参数，还有一个results字段将包含输出参数（结果），也能被修改。

condition元素和用在XML动作中的一样，可以包含表达式和比较元素，按需和or、and、not元素组合。

actions元素和服务定义、页面、表单等等其中的actions元素一样。它包含一个XML Actions脚本。更多信息请查看 XML Action概览 章节。