Oracle WorkFlow 工作流 中篇

简介: 1、关于邮件发送原理的研究:the email sending process in EBS isn’t transparent and intuitive. It involves several steps from different EBS areas...

1、关于邮件发送原理的研究:

the email sending process in EBS isn’t transparent and intuitive. It involves several steps from different EBS areas and utilizes multiple Oracle technology components like:(Notification Mailer的实现是如下组件协作的结果)

  • Workflow Notification module
  • Generic Service Management Framework (GSM)
  • Business Event System (Subscriptions, Deferred processing)
  • Workflow Directory and users setup
  • Vacation rules or routing rules
  • Oracle Advance Queues



如上图三个步骤(蓝色部分),涉及三个地方数据的存储:2个高级队列( Advanced Queues (in red))和1个表 (green).

注意: AQ并不是传统的关系表. An additional care should be taken while accessing these tables (we will talk about this later). 


邮件发送进程包括如下步骤:

1. EBS user sends email – EBS使用标准的API实现邮件发送,这个Email的API是用过plsql包 WF_NOTIFICATION来实现的,这个WF_NOTIFICATION包后续会讲到。

1.1. Provides application data – 首先用户session插入业务数据 (比如接收者,信息类型,信息内容) 到 WF_NOTIFICATIONS 表 (不要和上面提的 PL/SQL 包弄混了,这里是表);

1.2. Defers processing Generates event –当一个用户或者进程离开ebs去做发送邮件的工作时,是 通过一个 Business Events System (BES)来做. 会话通过WF_EVENT PL/SQL package 发一个事件 “oracle.apps.wf.notification.send” 。每一个延迟的事件都被放入到下面这两个高级队列中的一个: WF_DEFERRED or WF_JAVA_DEFERRED 来进行接下来的工作。所有的邮件发送事件都会通过WF_DEFERRED队列.


2. Deferred Agent Listener – 是一个处理所有ebs事件的进程。It executes all deferred events calling subscriptions’ functions defined for each business event.(它通过调用每个事务事件订阅的功能运行所有的延期事件 ) There are several more things to explain about Agent Listeners and subscription processing (e.g. there are several differed agents, subscriptions groups etc.) This is one more subject for further articles.

2.1. Reads event and starts subscriptions processing – Strictly speaking there is no any enabled subscription for the “oracle.apps.wf.notification.send” event (submitted during the first step). This event is a part of “oracle.apps.wf.notification.send.group” event group. The Deferred Agent executes subscriptions for that group rather than for the stand alone event. At this stage the Agent knows that it should process the notification with given notification id (it is a part of the event data passed via the event).

2.2. Reads application data(读取) – in order to generate the email/notification the Agent reads business data from the WF_NOTIFICATIONS table and a few related tables and during the next step builds up the email’s text in XML format.

2.3. Generates data for outbound interface(为输出接口生成数据) – This is the last step executed by the Deferred Agent Listener. It generates XML representation of email to be sent and together with other important bits of information posts it to the Notification Mailer outbound queueWF_NOTIFICATION_OUT.



3. Notification Mailer – As you see it was a long journey even before we started to talk about the Notification Mailer. There are a lot of things which may go wrong and this is why it is important to know the whole flow of the events to troubleshoot the mail sending functionality in EBS. We’ve come to the last processing step before the message leaves EBS boundaries.

3.1. Reads message – the Notification Mailer dequeues(出列) messages fromWF_NOTIFICATION_OUT queue on regular basis. In fact this is the only place where it looks for the new messages to be sent. This means if a notification doesn’t has a corresponding event ready for dequeuing in the WF_NOTIFICATION_OUT queue it will never be send. As soon as a new message arrives Notification Mailer dequeues it and gets prepared for sending;

3.2. Sends email via SMTP – This is the step when the message leaves EBS. The Notification Mailer sends the email using text retrieved from the advanced queue during previous step;

3.3. Updates status – as the last step in the notification sending process the Notification Mailer updates a MAIL_STATUS column in WF_NOTIFICATION table.(最后一步,Notification Mailer会更新WF_NOTIFICATION表的MAIL_STATUS列)


This article gives us rather good basis for further discussion of how to troubleshoot the notifications/emails sending process in Oracle e-Business Suite. Now we are aware of the complete email sending flow and ready for the detailed discussion on how to troubleshoot it. Just to wrap up this very first article I would like to mention that the notification sending process didn’t change a lot since the moment when a Java based Notification Mailer has been introduced (~11.5.7 if I recall correctly) and it is still there in R12.1.1 version. That means that everything we discussed and will discuss is applicable to all current EBS versions.


根据如下例子我们分析问题:

1、EBS user sends email (第一行) –  notification message 在 2009.06.29 14:07:15放入表, 并且enqueued to WF_DEFERRED queue a second later. MAIL_STATUS is set to “MAIL”.  STATE in the deferred queue is “READY” ,信息准备好被出队列.


2、Deferred Agent Listener (第二行) – the deferred agent processed the message. It dequeued the message at 14:08:27 (1 minute 11 seconds after the EBS user initiated the sending process). The state of the message in deferred queue is “PROCESSED”. The message is enqueued in WF_NOTIFICATION_OUT queue and is ready to be processed by the next process.


3、Notification Mailer (第三行) – Notification Mailer dequeued the message at 14:09:03 (1 minute 48 seconds after it was submitted for sending) and sent it out via configured SMTP process. The MAIL_STATUS field is updated to indicate the sending fact.


As you see the method described gives us detailed information on where the notification message is and what components we should focus our troubleshooting efforts on in case of any problems.

Let’s summarize what we have described in this article. The very first troubleshooting activity the Apps DBA should do in case of reported missing emails from EBS is to send the test email (noticing its ID). If it doesn’t arrive in 5-10 minutes we run described SQL using the notification id in order to find where the notification got stuck. Depending on the observation you focus your attention on the particular EBS component for further troubleshooting.

I hope you find this information useful and will use it in the Notification Mailer troubleshooting process. I am sure that your feedback will inspire me for further articles. Please do not hesitate to leave any feedback, questions or share any issue you had/have related to the topic. I will be more than happy to assist.


相关文章
|
XML Oracle 关系型数据库
Oracle WorkFlow 工作流 上篇
文章整理自黄建华的《信息技术最佳实践 ORACLE核心应用技术 工作流管理 Workflow实例详解》 Workflow是EBS的基础架构技术之一,系统中大部分流程性的通知和审批控制、账户按规则自动生成都是通过Workflow实现的;R11i之后,模块间的协调,有一小部分也是通过Workflow的BusinessEvent完成的。
1672 0
|
Web App开发 XML Oracle
BPEL_Oracle BPEL新一代工作流介绍(概念)
2014-11-02 Created By BaoXinjian 一、摘要 随着EAI向着SOA方向发展,如何利用Web Service完成系统整合日益成为企业IT系统集成的焦点。而BPEL作为工业标准,能够快速、可视化的将各个离散的WS整合成一个个端到端的Flows! 这样企业完成系统集成需要两个标准化的步骤: 1.
1416 0
|
SQL Oracle 关系型数据库
oracle workflow 详解
原文地址:http://hutianci.iteye.com/blog/1023363 1概述... 21.1工作流的概念... 21.2工作流的目的... 21.
1204 0
|
2月前
|
存储 Oracle 关系型数据库
Oracle数据库的应用场景有哪些?
【10月更文挑战第15天】Oracle数据库的应用场景有哪些?
192 64
|
11天前
|
存储 Oracle 关系型数据库
数据库数据恢复—ORACLE常见故障的数据恢复方案
Oracle数据库常见故障表现: 1、ORACLE数据库无法启动或无法正常工作。 2、ORACLE ASM存储破坏。 3、ORACLE数据文件丢失。 4、ORACLE数据文件部分损坏。 5、ORACLE DUMP文件损坏。
47 11
|
24天前
|
Oracle 关系型数据库 数据库
Oracle数据恢复—Oracle数据库文件有坏快损坏的数据恢复案例
一台Oracle数据库打开报错,报错信息: “system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。管理员联系我们数据恢复中心寻求帮助,并提供了Oracle_Home目录的所有文件。用户方要求恢复zxfg用户下的数据。 由于数据库没有备份,无法通过备份去恢复数据库。
|
1月前
|
存储 Oracle 关系型数据库
oracle数据恢复—Oracle数据库文件大小变为0kb的数据恢复案例
存储掉盘超过上限,lun无法识别。管理员重组存储的位图信息并导出lun,发现linux操作系统上部署的oracle数据库中有上百个数据文件的大小变为0kb。数据库的大小缩水了80%以上。 取出&并分析oracle数据库的控制文件。重组存储位图信息,重新导出控制文件中记录的数据文件,发现这些文件的大小依然为0kb。
|
17天前
|
存储 Oracle 关系型数据库
服务器数据恢复—华为S5300存储Oracle数据库恢复案例
服务器存储数据恢复环境: 华为S5300存储中有12块FC硬盘,其中11块硬盘作为数据盘组建了一组RAID5阵列,剩下的1块硬盘作为热备盘使用。基于RAID的LUN分配给linux操作系统使用,存放的数据主要是Oracle数据库。 服务器存储故障: RAID5阵列中1块硬盘出现故障离线,热备盘自动激活开始同步数据,在同步数据的过程中又一块硬盘离线,RAID5阵列瘫痪,上层LUN无法使用。
|
1月前
|
SQL Oracle 关系型数据库
Oracle数据库优化方法
【10月更文挑战第25天】Oracle数据库优化方法
49 7
|
1月前
|
Oracle 关系型数据库 数据库
oracle数据库技巧
【10月更文挑战第25天】oracle数据库技巧
31 6