Oracle Workflow 终篇
Posted on October 8, 2009 - Filed Under Workflow | Leave a Comment
众所周知，在EBS历代版本中，Workflow的应用（包括业务事件）非常广泛。我觉得它最有价值的地方就在于，它采用的是PL/SQL语言开发。 Oracle Workflow内置于数据库中，拥有独立版本，也有EBS内置版本，通常用的都是EBS内置版本。所谓的内置，其实也只是除了工作流引擎之外的一套管理界面和工具。所以从版本上讲，Workflow版本是单独来讲，和EBS毫无关系。目前，EBS 11i和R12使用的Workflow版本都是一样的，最新版本是2.6.4。并且，该版本不会再有升级。如果EBS有R13版，如果R13还有Workflow，那它的版本依旧是2.6.4。当然，每个EBS版本都对此进行了少量改进，R12的Workflow增强了Web Services1相关功能(仅仅是相关功能)。 现在，公开可下载的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了。 仅针对2.6.3版本及以上才有，因为2.6.2及以下版本没有相关的API。见Note. 363025.1 [↩]
为什么要学工作流？
Posted on June 1, 2009 - Filed Under Workflow | 2 Comments
很多人经常面对一种场面，就是在查找某环节的问题时，惊奇的发现自己又得面对工作流。虽然有点排斥，但是，您必须面对它，无处可避。本文所言的工作流通常是指Oracle Workflow，这是数据库内置的组件，在EBS系统中它被发扬光大了。不论哪个版本，工作流都是一个核心的组件，在11i系列认证中，它甚至作为独立的一块内容。 当您的团队开始谈论BPM时，您可能会想起BPEL。是的，在R12中，有一种更独特的流程管理技术被推荐给用户，但是Workflow依旧处于一个非常关键的位置。我之前曾罗列过11i中的几个标准的工作流，它们在控制业务流程方面起到了有效的作用。如果光看到这些，您可能把工作流等同于审批流程了，事实上这是非常片面的理解。现在，请打开你的浏览器（我是指11i中的），进入采购超级用户（或者其它职责），选择“流程”，如下图： 直接将流程和操作有机集成了。这也是一种工作流的应用。当然，也许您早知道这个功能并开始使用了。我也认同，把一些需要控制点的业务流程放在浏览器中，是一种不错的主意。这个和单据等审批流程类似，可以控制各个功能的执行时机。这些流程和审批层次一样，都是需要IT部门预先分析、设计并定义好的，但是如果用户，他可能刚入职，也可能子公司给他分配了新的角色，作为集团总部的您如何管理子公司各用户权限的分配呢？点击Web页面右上角的首选项，看到如下的内容： 如文字所示，“请求访问”就是用于自行申请权限（职责）的。回忆之前介绍用户层级管理时提到的，Provision Services和Self-Service and Approvals同样也用到了工作流。
业务事件(Business Event) Tips
Posted on March 12, 2009 - Filed Under Workflow | Leave a Comment
之前的一篇文章《业务事件之Java Rule Function》简单介绍了Java Rule Function的使用。在Oracle Workflow 2.6.x体系中，针对Function Activity的External Java也是非常有用的，同样的，也提供了接口以供编写应用程序。这两种方式，对于在应用层和异构系统交互或者处理其他一些PL/SQL无法完成的事务时，是绝对的利器。 在利用业务事件做实际应用时，根据经验，需要注意下面几点： 不要对JDBC Connection做close或release之类的操作。 Java Deferred Agent Listener一旦起来后，如果某个Java Rule Funtion中做了关闭数据库链接的操作，则会导致相应的队列(wf_java_deferred)中数据无法被处理，你甚至无法再单独重启该listener。 当然，你依然可以通过重启 Workflow Agent Listener Service 来使Java Deferred Agent Listener重新运作。 分步诊断 只有了解业务事件的整体架构后，才能更有效的找到问题真实症结所在。这里主要有三部分需要留意： 数据首先是被插入queue，此时可以使用预置文件FND: Debug Log Enabled和FND: Debug Log Level打开日志记录。Workflow用的是标准的FND_LOG包来记录日志的。 在调用Java程序时，系统首先去检查缓存，如果缓存中已经存在该对象，则不再从硬盘中读取。因而如果Java程序被调用过又有更新的话，需要重启应用才能生效。如果不重启，一些异常信息可能并不完整，比如NoClassDefFoundError，可能并不提供未找到的类名。 针对Java Deferred Agent Listener有单独的日志记录，需要进workflow manager中设置log level。诊断完毕后千万记得重新将log level设置回原先的值。Java程序中的log也会记录到这里。 标准的Log代码： private void log(String s, int i) { AppsLog appslog = [...]
ORA-00600: kwqidrdq: loop
Posted on February 12, 2009 - Filed Under Database, Workflow | Leave a Comment
在新克隆的应用环境中启用Workflow Deferred Agent Listener总是错误，错误信息为： [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: [...]
业务事件之Java Rule Function
Posted on February 3, 2009 - Filed Under Workflow | 2 Comments
工作流中一个非常有用的组件是业务事件(Business Event)，它可以和异构系统进行互通消息。自Oracle Application Suite 11.5.10后，业务事件就支持Java程序了。如果不考虑使用数据库的功能（透明网关、Web Services）等，对于Oracle EBS而言，业务事件就是最优先的选择了。 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 [...]
工作流之强制同步处理模式
Posted on January 13, 2009 - Filed Under Workflow | Leave a Comment
往往，对于工作流的强制同步(Forced Synchronous)处理模式，可以仅仅当做一段SQL代码来理解，事实上它也仅在一个SESSION内执行结束。对于某些逻辑处理，工作流图形化的设计方式非常容易理解，并且容易维护和扩展，多数情况下比PL/SQL代码更容易维护——我们的代码质量总是太差，除了程序员没人看得懂。 相对于普通的工作流(同步、异步）来说，它主要的区别就是响应及时。它不会保存任何工作流信息，这也就意味着无法在监控页面查询到工作流状态。工作流会将所有运行状态和变量存在工作流相关的表中，当使用强制同步处理模式时，所有变量仅在内存里保存（实际上是一些RECORD类型的变量），当SESSION结束自动清除。 额外的一些限制有： 不能使用通知活动。 仅存在于单个Session中，不能Commit。 无法使用错误处理流程。 On Revisit仅允许LOOP属性。 不能使用主从活动。 不能并行处理。 不能使用各类延迟处理的活动，比如Defer、Wait。 不能使用工作流后台处理引擎。 不能记录到工作流表。 仅允许少量的API调用。 (更详细的说明，可以参考工作流API文档) 使用强制同步处理模式的方法是设置ITEM_TYPE为#SYNC，或者wf_engine.eng_synch。如果在不启动DEBUG跟踪的前提下试图诊断工作流，则可以通过指定一个唯一的ITEM_TYPE来进行操作，即返回到普通的同步模式。 对于复杂权限的判断、帐户的生成，或其他存在多个逻辑判断的情形，使用工作流比在代码中控制要清晰很多，和设计文档中的流程图几乎一致。
