文章整理自黄建华的《信息技术最佳实践 ORACLE核心应用技术 工作流管理 Workflow实例详解》
Workflow是EBS的基础架构技术之一，系统中大部分流程性的通知和审批控制、账户按规则自动生成都是通过Workflow实现的；R11i之后，模块间的协调，有一小部分也是通过Workflow的BusinessEvent完成的。
Workflow满足的四个重要商业需求：
1、 发送通知
Workflow可以发送两种类型的通知：消息性通知，如“你的申请被审批了”，不需要接收者做出任何响应；回应式通知，如“GL日记账需要你的审批”，接收者需要做出相应的Response，工作流才能继续前进。
通知除了在系统中可以查看、处理外，也可以通过Mail查看、处理；可以本人处理，也可以转交他人处理。
2、 流程定义
Workflow正如它的字面含义，其专注于“工作流”的定义，用Workflow将如下“活动”组织成一个个业务蓝图，将是非常直观和容易的：基于PL/SQL的任何处理、基于AQ的通知、关联流程的等待与启动、瓶颈节点的超时处理。
如果能够将企业业务科学的分解至合理的粒度—— 子流程，那么不同业务在IT上的实现，就是将这些子流程有机的组合在一起。比如，销售订单工作流中的每一个子流程，是Oracle对销售业务分析后分解出的最佳粒度，不同企业可选择既有的流程组合，亦可重新组装。
3、 系统自动化
信息系统的自动化，是离不开信息流的，所以Workflow是天然的自动化工具，上面的流程定义，实际上亦可看作流程自动化，Worflow的极致就是Automation。
4、 系统间集成
如果把企业运作看作“当发生某个A事件时，需要我们作出一个或者一连串响应”，那么就可以理解，Oracle为什么将Workflow的“业务事件系统”置于系统间集成的地位——包括与业务伙伴的集成。
比如，S系统产生了一笔出库，需要在D系统完成订单的发运和开票，我们有很多种方案来实现，如果用“业务事件系统”，那么S系统只要向D系统发送一个消息说“我做了一笔出库”，D系统将自动触发“订单的发运和开票”操作。
因为消息的发送，实际上是基于OracleAQ这个现成、可靠的系统，S和D系统不需要时时连线；因为消息的处理是由“业务事件系统”根据“订阅关系”自动调度的，D系统也不需要不断的问S系统，你有没有数据。
下面继续列举的，是利用Workflow的特性，进行的信息系统开发应用。
5、 并行处理
如果有10000张订单需要同时处理，那么最好考虑并发，否则性能将糟糕透顶。在EBS环境下有3种选择，一是不推荐使用的Job，二是推荐使用的并发请求，三是Workflow，尤其适用于处理过程中可能需要稍作停顿，等待某种干预的时候。
6、 异步执行
同步执行，意味着，如果一个耗时的处理不完成，程序将停止响应，尤其是UI界面，如果长时间“不许动”，绝对导致使用者的反感。
如果这个耗时的动作，和用户目前的操作关系不大，可以放到后台慢慢去运行，那么就可以获得非常好的“系统响应时间”，在EBS中可以通过提交一个并发请求或者启动一个工作流来实现这种异步执行。
下表按模块列举了EBS中的部分工作流：
下面的SQL可以查当前系统中所有的工作流：
SELECT b.NAME,t.display_name, t.description
FROM wf_item_types b,wf_item_types_tl t
WHERE b.NAME = t.NAME
AND t.LANGUAGE = 'ZHS'
ORDER BY 1
2、工作流邮件通知
根据415499.1，邮件发送过程如下：
A. Workflow process initiatesa request for a notification.
B. Request for a notificationis enqueued onto the WF_DEFERRED queue.
C. 'Notification Mailer AgentListener' picks up the message from the WF_DEFERRED queue for processing.
D. The notification request is processed andthe notification XML has been generated and enqueued to the WF_NOTIFICATION_OUTqueue.
E. The notification mailerdequeues the XML notification for dispatch.
F. The notification mailertransforms the XML into a MIME message and dispatches the message through theSMTP server.
G. The message is dispatchedto the SMTP server for delivery to the recipient(s).
H. The SMTP Server forwardsthe message on to the wider network (LAN, WAN or Internet)
I. The message is deliveredto the users email server.
J. The user receives theemail.
3、目录服务：
Workflow的核心功能之一就是消息（Notification），要发消息，当然要有接收人，这个接收人可能是一个user、一个employee、一个Responsibility、一个客户、一个职位等等。
在EBS中这些接收人分散在各个模块的各个表中，而Workflow Engine仅承认WF_表中的接收人。
Oracle目录服务的作用就是把这些分散的资料按照统一的格式集中起来，存在WF_LOCAL系列的表中，并以来源字段区分。这样我们在程序中如果要找某一个接收人，仅从WF_LOCAL系列的表中查询即可（实际应用中，是调用一个标准API从WF_ROLES视图取数），不需要记住所有的源表。
接收人分用户和角色，角色包含一个或多个用户，对应的视图为wf_users/wf_roles/wf_user_roles。如果消息的接收人为职责，那么这个职责下的所有用户都会收到消息。这个好理解，不多说。
下面以EBS的登录user为例。
1. 原来存储的表为：fnd_user，假定这里面有个用户User_Name为huajhua，User_ID为1001
2. 对应一个按照目录服务格式要求的视图：wf_fnd_usr_roles
3. WF Bulk Synchronize Local Tables请求会把wf_fnd_usr_roles的数据同步到wf_local_roles中，orig_system字段标志为fnd_usr
4. 如果以后我们要发通知给huajhua，那么通过API可以获得该用户：WF_DIRECTORY.GETROLENAME(‘FND_USR’, 1001,x_name,x_displayname)
值得一提的是如果User和Employee关联了，那么orig_system将是PER。举几个例子：
更详细的说明请看Oracle Workflow Administrator's Guide。
所以，总的来说，Workflow的目录服务就是收集用户和角色信息，以统一的格式提供给Workflow消息系统使用。包括：
1. 一套本地表：WF_LOCALXXX
2. 一套实际使用的视图：WF_USERS/WF_ROLES/WF_USER_ROELS
3. 一套各来源视图：WF_<Orig_System>_ROLES
4. 一个批量同步请求集：Synchronize Workflow LOCAL tables（增量同步需要安装Patch，请看Notes171703.1）
5. 一套API：WF_DIRECTORY
