Fans Or Not

在用Workflow Builder绘制工作流的时候，说简单点就是做两件事：定义Activity(活动)和Transition(移动)。Activity可以是复杂的逻辑运算，也可以是简单的判断、通知和反馈。对于需要回应的活动（比如审批意见），因为各种因素可能令响应者并未在预想的时间内做出反馈，这时就需要制定超时策略，否则，随着时间的推移，系统中将存在大量的遗留数据，这些数据很可能无法被清理。

例子：如果一天内未审批，则视为拒绝：

如果活动超时，工作流会标识该活动为超时状态。如果是通知，并且要求回应，则会发送一封取消通知的邮件给执行者(Performer)。对于是否接收取消通知邮件，取决于个人首选项是否选择接收电子邮件。如果是EBS内置版本，则可以在全局设置中禁止发送取消通知邮件。

如果活动定义了超时属性但是没有Timeout这个Transition流向下面的活动，则系统会根据该活动或父流程的相关定义来触发错误流程。对于超时处理，必须启动工作流后台流程，一个建议的频率是1到24小时。

对于Oracle工作流的优化方式主要分两大类，一类是流程设计上的优化，一类是数据库性能的优化。

流程设计优化：

1. 仔细选择同步处理和异步处理模式。
   如果选择同步处理模式，则在提交后系统立即进行工作流处理，在流程结束前，前端程序将一直处于等待状态。如果选择异步处理模式，程序提交工作流后控制权立即返回，工作流后台引擎会根据设定的频率在后台进行处理。另外一种很少用到的处理模式是强制同步，系统不将数据插入数据库，直接用一个SQL，并且在一个Session中处理完毕。
2. 尽量减少项目属性（通常用于存储全局变量）。当工作流启动时，系统会将这些属性全部拷贝一份，因而这会直接印影响工作流启动速度。另外，这些属性最好引用或保存静态变量，而不要去引用存放在数据库中的值。
3. 尽量减少消息属性。如果需要在消息中存放不同的变量，也建议用最少的消息属性来实现，比如用Document来动态生成消息内容。
4. 减少子流程，因为这需要消耗额外的DML操作和状态信息拷贝。
5. 延迟活动。这是缩短响应时间最简单有效的办法之一，让一些需要较多处理时间的活动在后台交给工作流引擎处理，主流程则继续。

数据库性能优化：

1. 分区。这通常在安装阶段即可进行，当然，在后期也可以进行。操作步骤可参考之前的文章《给工作流大表分区》。
2. 清理过期数据。清理过期的运行时数据和WF_CONTROL数据，减少数据表大小。

最简单的优化方式，自然是在DB进行优化，比如定期清理。但是从设计角度考虑，同步、异步和延迟处理的配合使用，是更为得体的方式。各种方式，因时而异，因人而异。

如果打过了Patch 348000 (ORACLE APPLICATIONS RELEASE 11.5.10.2 MAINTENANCE PACK)，那么工作流管理员指南(115wfag.pdf)里的对于关键表分区的介绍就过时了。进去看wfupartb.sql，你可以看到它提示已经被新的程序所取代。

新的文件是wfpart.sql，在 $FND_TOP/patch/115/sql 路径下。参考SQL文件头的使用说明执行，会在utl_file_dir目录（需要手工指定一个目录）下生成wfpart.sql，这才是具体的分区创建语句。不过需要留意的是，默认生成的wfpart.sql有个BUG（参见Note:329738.1），创建WF_ITEM_ACTIVITY_STATUSES_N4这个索引时会报错并自动终止退出，因此需要先手工修改wfpart.sql，加上以下Index创建语句：

create index WF_ITEM_ACTIVITY_STATUSES_N4
 on WF_ITEM_ACTIVITY_STATUSES (ASSIGNED_USER,ITEM_TYPE)
 pctfree 10
 initrans 10
 tablespace [your_table_space]
 storage (initial 40K next 1048576
 freelists 32 freelist groups 4
 pctincrease 0 )
 logging;

注意：需要注释掉原来的Alter语句：

alter index WFN_WF_ITEM_ACTIVITY_STATUSES_ rename to WF_ITEM_ACTIVITY_STATUSES_N4

由于执行的都是DDL语句，因此一旦出错将无法自动回滚，在执行前需要备份关键表，分别为：

1. WF_ITEM_ACTIVITY_STATUSES
2. WF_ITEM_ACTIVITY_STATUSES_H
3. WF_ITEM_ATTRIBUTE_VALUES
4. WF_ITEMS

如果是在等到感觉到性能问题了再来进行分区，等待的过程将相当漫长……如果想要撤销分区，则以同样方式执行wfunpart.sql。