Oracle Workflow内置于数据库中，拥有独立版本，也有EBS内置版本，通常用的都是EBS内置版本。所谓的内置，其实也只是除了工作流引擎之外的一套管理界面和工具。所以从版本上讲，Workflow版本是单独来讲，和EBS毫无关系。目前，EBS 11i和R12使用的Workflow版本都是一样的，最新版本是2.6.4。并且，该版本不会再有升级。如果EBS有R13版，如果R13还有Workflow，那它的版本依旧是2.6.4。当然，每个EBS版本都对此进行了少量改进，R12的Workflow增强了Web Services¹相关功能(仅仅是相关功能)。

现在，公开可下载的Workflow是2.6.3，2.6.4版本的Workflow包含在RDBMS 10.2中。在新的应用中，Oracle推荐用BPEL，这是一套基于Java的工作流引擎，运行在Oracle SOA Suite上，但不是免费的。

如果你对PL/SQL情有独钟，或者认为它已经足够强大并且足够简单，可以继续使用Oracle Workflow 2.6版本，不过它已不再内置于新的数据库中，11g开始就没有了。

一款同样基于PL/SQL的工作流PL/FLOW，有兴趣的可以一看。如果不在乎是否免费，则完全可以转向BPEL。如果是一名Oracle ERP实施顾问，也可以开始深入学习BPEL了。

1. 仅针对2.6.3版本及以上才有，因为2.6.2及以下版本没有相关的API。见Note. 363025.1

当您的团队开始谈论BPM时，您可能会想起BPEL。是的，在R12中，有一种更独特的流程管理技术被推荐给用户，但是Workflow依旧处于一个非常关键的位置。我之前曾罗列过11i中的几个标准的工作流，它们在控制业务流程方面起到了有效的作用。如果光看到这些，您可能把工作流等同于审批流程了，事实上这是非常片面的理解。现在，请打开你的浏览器（我是指11i中的），进入采购超级用户（或者其它职责），选择“流程”，如下图：

直接将流程和操作有机集成了。这也是一种工作流的应用。当然，也许您早知道这个功能并开始使用了。我也认同，把一些需要控制点的业务流程放在浏览器中，是一种不错的主意。这个和单据等审批流程类似，可以控制各个功能的执行时机。这些流程和审批层次一样，都是需要IT部门预先分析、设计并定义好的，但是如果用户，他可能刚入职，也可能子公司给他分配了新的角色，作为集团总部的您如何管理子公司各用户权限的分配呢？点击Web页面右上角的首选项，看到如下的内容：

如文字所示，“请求访问”就是用于自行申请权限（职责）的。回忆之前介绍用户层级管理时提到的，Provision Services和Self-Service and Approvals同样也用到了工作流。

以上都是除了审批之外的非典型工作流应用。只要您的业务中存在规则（rule-based），那么就可以使用工作流。还有很多地方可以发现工作流的应用，这里不一一举例了。大致划分的话，可以发现下面几个领域会用到工作流：

1. 审批。比如采购订单审批，另有一些场合会使用AME。
2. 任何有规则，需要控制流程的场所。比如进行复杂数据处理时，利用工作流非常直观的设计界面来设计处理流程，而不是塞到一段冗长的PL/SQL代码中。
3. 业务事件。比如某些删除或更新操作可能需要通知其他系统，这时可以考虑订阅该事件，并实施特殊的逻辑。
4. 异构系统的同步。可以将工作流和业务事件组合使用，在处理异构系统的数据同步时非常有用。比如您可能需要某个关键点触发一条手机短信。
5. 发邮件。工作流的邮件功能已经非常强大，可以发HTML格式的邮件，也可以发附件。
6. 投票。

如果您有心去统计，会发现11i中工作流的影子遍布在每个角落。工作流并不难懂，掌握了它，对理解11i内部工作机制有非常大的帮助。

在利用业务事件做实际应用时，根据经验，需要注意下面几点：

不要对JDBC Connection做close或release之类的操作。

Java Deferred Agent Listener一旦起来后，如果某个Java Rule Funtion中做了关闭数据库链接的操作，则会导致相应的队列(wf_java_deferred)中数据无法被处理，你甚至无法再单独重启该listener。

当然，你依然可以通过重启 Workflow Agent Listener Service 来使Java Deferred Agent Listener重新运作。

分步诊断

只有了解业务事件的整体架构后，才能更有效的找到问题真实症结所在。这里主要有三部分需要留意：

1. 数据首先是被插入queue，此时可以使用预置文件FND: Debug Log Enabled和FND: Debug Log Level打开日志记录。Workflow用的是标准的FND_LOG包来记录日志的。
2. 在调用Java程序时，系统首先去检查缓存，如果缓存中已经存在该对象，则不再从硬盘中读取。因而如果Java程序被调用过又有更新的话，需要重启应用才能生效。如果不重启，一些异常信息可能并不完整，比如NoClassDefFoundError，可能并不提供未找到的类名。
3. 针对Java Deferred Agent Listener有单独的日志记录，需要进workflow manager中设置log level。诊断完毕后千万记得重新将log level设置回原先的值。Java程序中的log也会记录到这里。

标准的Log代码：

private void log(String s, int i) {
	AppsLog appslog = (AppsLog) wfCtx.getLog();
	if (appslog.isEnabled(i))
		appslog.write(this, s, i);
}

Event参数传递

虽然subscription也可以传递参数，但是它的参数格式很别扭：var1=val1 var2=val2，多个参数以空格间隔，组成一个字符串传递过来。还要自己写程序来解析，比较麻烦。而且关键是，这些参数是静态定义的，无法在raise event时动态创建。所以Java中一般使用event中传递过来的参数。

在Oracle EBS系统中，DB和应用使用两套不同的JVM。如果在DB层写Java Procedure，若是需要第三方库，则要通过loadjava来导入DB。而应用层则相对简单，直接上传到$JAVA_TOP相应目录下即可。一般来讲，此类处理异构系统之间的程序，是不会放在DB层来实现的。

此外，在定义Subscription时，若没有特殊需求，将Rule Data设置为Key会比Message更有效。

[Feb 12, 2009 3:34:45 PM CST]:1234424085866:Thread[inboundThreadGroup1,5,inboundThreadGroup]:0:-1:test.domain.com.cn:10.0.0.2:-1:-1:ERROR:[SVC-GSM-WFALSNRSVC-12681-10002 : oracle.apps.fnd.wf.bes.AgentListenerProcessor.read()]:Could not executeUpdate() on { CALL   WF_EVENT.LISTEN  (  p_agent_name => :1, p_wait => :2, p_correlation => :3, p_deq_condition => null, p_message_count => :4, p_max_error_count => :5  )} -> java.sql.SQLException: ORA-00600: internal error code, arguments: [kwqidrdq: loop], [0], [0], [0], [0], [], [], []
ORA-06512: at "APPS.WF_EVENT", line 1560
ORA-06512: at line 1

检查Alert，日志显示:

Thu Feb 12 16:09:55 2009
Errors in file /u08/code/dev/proddb/9.2.0/admin/DEV_test/udump/dev_ora_9675.trc:
ORA-00600: internal error code, arguments: [kwqidrdq: loop], [0], [0], [0], [0], [], [], []

通过pfiles查看9675进程，是oracleDEV，确定不是第三方程序引起的。这个错误的产生通常和AQ相关，而WF_DEFERRED正是基于AQ的，这样问题范围就缩小了。

解决步骤如下：

1. 用sysdba权限登录，停用AQ Time Managers：

alter system set aq_tm_processes = 0

2. 检查相应的QUEUE_TABLE：

SELECT * FROM applsys.aq$_wf_deferred_i i
 WHERE NOT EXISTS
 (SELECT t.msgid FROM applsys.wf_deferred t WHERE i.msgid = t.msgid);

SELECT * FROM applsys.aq$_wf_deferred_h h
 WHERE NOT EXISTS
 (SELECT t.msgid FROM applsys.wf_deferred t WHERE h.msgid = t.msgid);

SELECT * FROM applsys.aq$_wf_deferred_t ti
 WHERE NOT EXISTS
 (SELECT t.msgid FROM applsys.wf_deferred t WHERE ti.msgid = t.msgid);

如果存在记录，则删除之。

3. 重启AQ Time Managers：

alter system set aq_tm_processes = 1

问题解决。还有一种更简单的方式，就是重建QUEUE_TABLE，不过这需要在不丢失数据的前提下。

Ref Metalink: 1070715.6

Metalink上找不到相应的开发文档，Oracle Workflow Developer’s Guide 中提到过，但是很简略。和PL/SQL写rule function一样，使用Java也需要注意规范，必须使用该接口：

public interface SubscriptionInterface
{
    void onBusinessEvent(Subscription eo, BusinessEvent event, WorkflowContext ctx)
    throws BusinessEventException;
}

这三个参数作用：
eo 用于获取Subscription相关信息，比如phase或参数。
event BE对象，如event name, event key等。
ctx 工作流相关上下文，比如数据库链接句柄、日志对象等。

下面是一个简单的例子：

package oracle.apps.cux.sms;

import oracle.apps.fnd.wf.bes.BusinessEvent;
import oracle.apps.fnd.wf.bes.BusinessEventException;
import oracle.apps.fnd.wf.bes.SubscriptionInterface;
import oracle.apps.fnd.wf.bes.server.Subscription;
import oracle.apps.fnd.wf.common.WorkflowContext;

public class CuxSmsTransporter implements SubscriptionInterface {
	public void onBusinessEvent(Subscription eo, BusinessEvent event,
			WorkflowContext ctx) throws BusinessEventException {
		System.out.println("Hello Subscription!");
	}
}

具体的配置过程可以直接参考文档，创建业务事件、订阅，将class文件放入相应目录中即可。
需要留意的是，class文件要和应用的jvm版本一致，否则会导致如下错误：

[Feb 3, 2009 3:59:18 PM CST]:1233647958026:Thread[inboundThreadGroup1,5,inboundThreadGroup]:0:-1:erptest.orafans.com:10.0.0.2:-1:-1:ERROR:[fnd.wf.bes.EventDispatcher.executeSubscription()]:Could not instantiate Subscription -> java.lang.UnsupportedClassVersionError: oracle/apps/cux/sms/CuxSmsTransporter (Unsupported major.minor version 50.0)


由于系统缓存的问题，第一次调用后有修改，可能需要重启应用。

相对于普通的工作流(同步、异步）来说，它主要的区别就是响应及时。它不会保存任何工作流信息，这也就意味着无法在监控页面查询到工作流状态。工作流会将所有运行状态和变量存在工作流相关的表中，当使用强制同步处理模式时，所有变量仅在内存里保存（实际上是一些RECORD类型的变量），当SESSION结束自动清除。

额外的一些限制有：

1. 不能使用通知活动。
2. 仅存在于单个Session中，不能Commit。
3. 无法使用错误处理流程。
4. On Revisit仅允许LOOP属性。
5. 不能使用主从活动。
6. 不能并行处理。
7. 不能使用各类延迟处理的活动，比如Defer、Wait。
8. 不能使用工作流后台处理引擎。
9. 不能记录到工作流表。
10. 仅允许少量的API调用。

(更详细的说明，可以参考工作流API文档)

使用强制同步处理模式的方法是设置ITEM_TYPE为#SYNC，或者wf_engine.eng_synch。如果在不启动DEBUG跟踪的前提下试图诊断工作流，则可以通过指定一个唯一的ITEM_TYPE来进行操作，即返回到普通的同步模式。

对于复杂权限的判断、帐户的生成，或其他存在多个逻辑判断的情形，使用工作流比在代码中控制要清晰很多，和设计文档中的流程图几乎一致。

1406: Workflow definition contains unsupported feature, cannot be uploaded to this database.
1603: Unsupported type EVENT in attribute XMLTRANSFORM/NEWDOCUMENT
1603: Unsupported type EVENT in attribute XMLTRANSFORM/EVENT
1603: Unsupported type EXTJAVA in function WFSTD/XMLTRANSFORM
1603: Unsupported type EVENT in attribute XMLGETTAGVALUE/EVENT
1603: Unsupported type EXTJAVA in function WFSTD/XMLGETTAGVALUE
1603: Unsupported type EVENT in attribute XMLCOMPARETEXT/EVENT
1603: Unsupported type EXTJAVA in function WFSTD/XMLCOMPARETEXT
1603: Unsupported type EVENT in attribute XMLCOMPARENUMBER/EVENT
1603: Unsupported type EXTJAVA in function WFSTD/XMLCOMPARENUMBER
1603: Unsupported type EVENT in attribute XMLCOMPAREDATE/EVENT
1603: Unsupported type EXTJAVA in function WFSTD/XMLCOMPAREDATE
1603: Unsupported type EVENT in attribute SETEVENTPROPERTY/EVENT
1603: Unsupported type EVENT in attribute GETEVENTPROPERTY/EVENT
1603: Unsupported type EVENT in attribute COMPAREEVENTPROPERTY/EVENT

这些Function和Attribute都来自于WFSTD，也就是不应该发生的错误。因为之前出现过配置问题，所以第一反应还是检查配置，无果。

于是想到了检查一下标准Definition清单，看看究竟是否支持EVENT和EXTJAVA。进入Diagnostics Tools，执行Workflow Definition Details检查，提示系统Workflow版本为2.5.0，不支持此操作，怪哉。

SELECT * FROM wf_resources wr WHERE wr.NAME LIKE 'WF_VERSION'

显示果然是2.5.0，而实际的版本应当是2.6.0。手工修改之(为什么变成2.5.0，原因未知，但是应该不是正常情况下所能产生的，所以放心修改)。重新检查Diagnostics报告，发现上述错误信息中的Function都是被支持的。于是重新上载工作流定义，正常，问题解决。

看来Oracle仅仅是通过版本号来检查某特性是否被支持，而不是根据单独的特性来判断。

一点经验：Diagnostics Tools是个好东西啊，如果我早点用这个，能节省好多时间

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

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

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

流程设计优化：

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

数据库性能优化：

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

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

新的文件是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。