Siebel 策略在只应执行一次时执行了两次
我的问题是策略运行了两次，而不是一次。
当机会字段[状态]更改为“关闭”时，该策略将运行。该策略执行工作流，但当我更改该字段时，策略会运行两次，并在 2-15 秒的延迟间隔内执行工作流两次（为该机会创建活动）。
我搜索了该字段中是否有另一个策略正在运行，并且我已确认该策略运行了两次（完全相同的策略）。我尝试在工作流程中进行查询和决策点，以“验证”是否创建了一项活动并且该活动有效，但前提是该策略的运行延迟大于 9 秒。如果工作时间小于该值，则工作流将运行两次。
我该如何解决这个问题？
My problem is that a policy is running twice, instead of once.
The policy runs when a oportunity field [status] is changed to "close". The policy executes a workflow, but when I change that field, the policy runs twice executing the workflow two times (that creates an activity for that opportunity) in a delay interval of 2-15 seconds.
I searched to see if there's another policy running in that field and I have confirmed that the policy is running twice (exactly the same policy). I tried making a query and a decision point in the workflow to "validate" if there is one activity created and it works, but only if the policy runs in a delay of >9 seconds. If it works in less than that, the workflow runs twice.
How can I resolve this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
工作流策略用于管理数据库触发器。触发器在 s_escl_req 表中创建一条记录，因此看看这里会发生什么。然后：
如果要进行更详细的调试，请查看 SIEBEL_ROOT\siebsrvr\trigger.sql 文件以查看表和字段是否出现两次。如果是这种情况，您可能希望使某些保单过期。
PS：解决这个问题的正确方法是在metalink上搜索...
Workflow policies are used to manage database triggers. The trigger creates a record in the s_escl_req table, so see what happens here. Then:
If you want to debug in more details, review the SIEBEL_ROOT\siebsrvr\trigger.sql file to see if your table and field apprears twice. If that is the case, you might want to expire some policies.
PS: The correct way to solve this is to search on metalink...
这就是我要做的：
使用数据库实用程序检查机会表（我认为是 S_OPTY）上的数据库触发器，并查看是否意外有两个触发器；工作流程规则的行 ID 应该在其中。如果是这种情况，请按照前面的答案所述删除并重新生成触发器。
如果不是，请查看 S_ESCL_REQ（发送立即触发器）和 S_ESCL_STATE（发送延迟触发器）中发生的情况，并查找 BT_ROW_ID 与 S_OPTY 记录的 ROW_ID 匹配的记录。这将有助于进一步调查。回发！
Here's what I would do:
Check the database triggers on the Opportunity table (S_OPTY I think) with a database utility and see if there are two triggers there by accident; the Row Id of the Workflow Policy should be in there. If this is the case, drop and regenerate triggers as stated by a previous answer.
If not, see what happens in both S_ESCL_REQ (where immediate triggers are sent) and S_ESCL_STATE (where delayed triggers are sent) and look for records where BT_ROW_ID matches the ROW_ID of the S_OPTY record. This will help with further investigation. Post back!