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完成的。
1636 0
|
Web App开发 XML Oracle
BPEL_Oracle BPEL新一代工作流介绍(概念)
2014-11-02 Created By BaoXinjian 一、摘要 随着EAI向着SOA方向发展,如何利用Web Service完成系统整合日益成为企业IT系统集成的焦点。而BPEL作为工业标准,能够快速、可视化的将各个离散的WS整合成一个个端到端的Flows! 这样企业完成系统集成需要两个标准化的步骤: 1.
1386 0
|
SQL Oracle 关系型数据库
oracle workflow 详解
原文地址:http://hutianci.iteye.com/blog/1023363 1概述... 21.1工作流的概念... 21.2工作流的目的... 21.
1172 0
|
27天前
|
存储 自然语言处理 Oracle
Oracle数据库字符集概述及修改方式
【8月更文挑战第15天】Oracle 数据库字符集定义了数据的编码方案,决定可存储的字符类型及其表示方式。主要作用包括数据存储、检索及跨系统传输时的正确表示。常见字符集如 AL32UTF8 支持多语言,而 WE8MSWIN1252 主用于西欧语言。修改字符集风险高,可能导致数据问题,需事先备份并评估兼容性。可通过 ALTER DATABASE 语句直接修改或采用导出-导入数据的方式进行。完成后应验证数据完整性。此操作复杂,须谨慎处理。
|
24天前
|
数据采集 Oracle 关系型数据库
实时计算 Flink版产品使用问题之怎么实现从Oracle数据库读取多个表并将数据写入到Iceberg表
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
11天前
|
存储 Oracle 关系型数据库
Oracle同一台服务器创建多个数据库
【8月更文挑战第30天】在 Oracle 中,可在同一服务器上创建多个数据库。首先确保已安装 Oracle 软件并具有足够资源,然后使用 DBCA 工具按步骤创建,包括选择模板、配置存储及字符集等。重复此过程可创建多个数据库,需确保名称、SID 和存储位置唯一。创建后,可通过 Oracle Enterprise Manager 进行管理,注意服务器资源分配与规划。
26 10
|
19天前
|
存储 Oracle 关系型数据库
分享几个Oracle数据库日常维护中常见的问题
分享几个Oracle数据库日常维护中常见的问题
68 1
|
1月前
|
SQL Oracle 关系型数据库
"揭秘!一键解锁Oracle日志清理魔法,让海量归档日志无处遁形,守护数据库健康,告别磁盘空间告急噩梦!"
【8月更文挑战第9天】随着Oracle数据库在企业应用中的普及,归档日志管理对保持数据库健康至关重要。归档日志记录所有更改,对数据恢复极为重要,但也可能迅速占用大量磁盘空间影响性能。利用Oracle提供的RMAN工具,可通过编写Shell脚本来自动清理归档日志。脚本包括设置环境变量、连接数据库、检查和删除指定时间前的日志,并记录执行情况。通过Cron作业定时运行脚本,可有效管理日志文件,确保数据库稳定运行。
62 7
|
1月前
|
Oracle 关系型数据库 MySQL
Mysql和Oracle数据库死锁查看以及解决
【8月更文挑战第11天】本文介绍了解决MySQL与Oracle数据库死锁的方法。MySQL可通过`SHOW ENGINE INNODB STATUS`查看死锁详情,并自动回滚一个事务解除死锁;也可手动KILL事务。Oracle则通过查询V$LOCK与V$SESSION视图定位死锁,并用`ALTER SYSTEM KILL SESSION`命令终止相关会话。预防措施包括遵循ACID原则、优化索引及拆分大型事务。
|
1月前
|
监控 Oracle 关系型数据库
"深度剖析:Oracle SGA大小调整策略——从组件解析到动态优化,打造高效数据库性能"
【8月更文挑战第9天】在Oracle数据库性能优化中,系统全局区(SGA)的大小调整至关重要。SGA作为一组共享内存区域,直接影响数据库处理能力和响应速度。本文通过问答形式介绍SGA调整策略:包括SGA的组成(如数据缓冲区、共享池等),如何根据负载与物理内存确定初始大小,手动调整SGA的方法(如使用`ALTER SYSTEM`命令),以及利用自动内存管理(AMM)特性实现智能调整。调整过程中需注意监控与测试,确保稳定性和性能。
85 2

推荐镜像

更多