对于Oracle初学者，我一直推荐其阅读官方文档，但总是得到因为这样那样的理由而没去读的反馈。他们宁可花费近百元去书店买一本名不见经传的书籍，也不愿意免费阅读最权威的文档。起初我以为是语言问题，后来发现不是。哪怕英语水平非常不错的人，也宁可去书店淘上一本。那么，只好归结为个性喜好问题了 
对于Oracle E-Business Suite的文档，11i的我全部浏览过了，R12只是部分去阅读过，基本上只是偶尔增加一两章和少量修改。当然，对于近一半文档我也确实仅仅只是“浏览”，毕竟实际工作中不可能对所有模块都深入接触。这部分文档主要还是针对功能层面的，比较适合系统管理员和实施人员阅读。对于开发人员，看的更多的通常是一些专项的技术文档了，尤其汉得流出来的大量文档，也培养了不少甲方开发人员啊。
近期也在阅读一些书籍，主要关注两方面：深入某专题领域的，或是适合初学者的。前者为了自己，后者主要是看看有没有合适的书籍方便新员工的培训。此外，我认为实施顾问了解产品的技术架构，也是非常有益的。深入下去，沉淀一段时期后再来梳理业务问题，或许会对当初的方案有更多的了解和想法。我觉得《Oracle E-Business Suite Development & Extensibility Handbook》(豆瓣链接)就是这样一本非常不错的书。
目录：
- Introduction to Oracle E-Business Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
- E-Business Suite Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
- Application Object Library (AOL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
- Multiple Organizations Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
- Development of Concurrent Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
- Forms in Oracle Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
- Reports Development and Customization in Oracle Apps . . . . . . . . . . . . . . 157
- BI Publisher in Oracle Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
- OA Framework: Concepts, Development, and Extensions . . . . . . . . . . . . . . 211
- Custom Look and Feel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
- Oracle Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
- Oracle XML Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
- Moving AOL Objects Between Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
- Integration Between E-Business Suite and SOA . . . . . . . . . . . . . . . . . . . . . . 425
- SQL Performance Coding Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
基本上已经讲清楚了EBS的整体架构和二次开发相关技术。通览全书，从作者角度看，或许OAF是一种重心，这也是当前EBS二次开发领域比较重要的一块。不过我觉得，OAF开发从投入产出来看其实并不是很划算，开发效率没Form高，页面效果没其他应用Web 2.0技术的产品好，如APEX。其次，Custom Look and Feel 也是比较新鲜的一个主题，官方文档中几乎没有涉及。
书中的内容，光从知识性角度看，有2/3是在EBS官方文档中有了的。尤其是涉及一些基础架构的东西，还不如阅读文档比较通畅明了。Workflow 和 XML Gateway 简直有充数之嫌，实在太过粗糙了。FNDLOAD的介绍或许还没有我之前博客中介绍的详细。SOA这一块也简单了点，其实从个人角度看，或许可以把Workflow字数移到这边来多讲一些比较好，毕竟，Workflow在R12中的应用比重虽然依然非常巨大，但是对二次开发而言，比重很轻，而且这毕竟也是一种趋势。
不管如何，从二次开发角度来看，这是一本非常不错的书籍。市场上太多的书不是侧重于Apps DBA，就是侧重于功能和实施，对于二次开发，这本书介绍了几乎所有在实际工作中常见的开发技术，是值得推荐的。
目前，EBS系统中存在多种日志记录方式，有用于PL/SQL的，有用于Java的，有OAF等开发框架自带的，也有Forms Server之类服务器专用的诊断方式。通常来讲，所有二次开发，为了统一规范和便于管理，应当将将客户化系统中日志记录和Oracle EBS中的日志记录进行整合，用统一的方式进行日志记录和诊断。
Oracle EBS调试日志级别
系统中将调试日志级别分为6个级别，分别是：
| Type |
Level |
Description |
| UNEXPECTED |
6 |
未知异常 |
| ERROR |
5 |
错误 |
| EXCEPTION |
4 |
异常 |
| EVENT |
3 |
事件 |
| PROCEDURE |
2 |
过程 |
| STATEMENT |
1 |
语句，该级别最低，记录的日志信息也最详细。 |
该级别通过配置文件 FND：调试日志级别 控制。
调试日志模块
日志必须指定当前所执行的程序，也就是所谓的模块。模块用于区分不用程序产生的日志，比如我的一套用于将EBS事件通过手机短消息发送出去的整套程序统一定义成日志模块：oracle.apps.cux.msg.transport。如此，不论是简单的PL/SQL、Form或并发程序产生的短信内容，都可以作为一个整体进行日志记录。模块名可以自行定义，该定义需要有意义，并能和其他程序明确区分。该特性由配置文件 FND：调试日志模块 控制。
不需要修改代码，诊断时可以根据需要随时启用或关闭调试日志，由配置文件 FND：启用调试日志 控制。
调用示例
先在程序中创建过程，如：
PROCEDURE trace(x_level IN NUMBER,
x_message IN VARCHAR2) IS
BEGIN
IF (x_level >= fnd_log.g_current_runtime_level) THEN
IF (fnd_log.test(x_level, 'oracle.apps.cux.msg.transport')) THEN
fnd_log.STRING(log_level => x_level,
module => 'oracle.apps.cux.msg.transport',
message => x_message);
END IF;
END IF;
EXCEPTION
WHEN OTHERS THEN
NULL;
END trace;
然后用以下方式调用：
trace(fnd_log.level_procedure, 'Enter get_num');
日志查看
SELECT *
FROM fnd_log_messages f
WHERE f.user_id = 1113
AND f.log_sequence > 492519740
ORDER BY f.log_sequence;
对于普通的二次开发（一些较大的平台可能需要有自己的诊断方式），建议使用通过的方式记录日志，否则，如果各行其是，或者随手就自己设计一套日志记录方式的，当开发数量到达一定规模时，会让管理工作变得复杂。
题外：
这是早期时给团队中二次开发制订的相关规范的一部分，记在Confluence上。近日考虑撤出该平台，在角落里翻出来的一篇。另外，知识库的建设真是一项即简单又麻烦的工作……
尽管你可能经常碰到一些看上去很糟糕的DBA，尽管你可能觉得DBA的工作其实蛮简单，甚至有时候根本不知道他们的工作有什么意义，但是无可否认的是，在这个行业中，Oracle DBA的薪水还是可以排得上号的。在中国，高级DBA可以获得10~15万的年薪，而对于某些特别出色的专家而言，年薪20~30万的也不乏其人。
Oracle 发布了全球2009年度DBA薪水统计报告，基本上可以看出，DBA依然是一份越老越吃香的职业：
在国内不乏有一些人认为，认证的获取无关紧要，关键是看实际工作能力和经验。Oracle 就专门做了这么一番统计：
暂且不论该统计数据从何而来，但是那些未取得认证的人看过后是否有一种异样的冲动？其实，把认证和工作能力等同起来讨论本身就是毫无意义的，就好比去说一个博士比一个本科生人品更好一样。在中国，估计没有哪个专职DBA未获得认证的，剩下的，可能以兼职居多。
在该报告中，可以按地区（没有中国），按公司规模，甚至按认证数目来进行统计。总而言之，对于职业发展毫无目标的人，这是一个不错的参考。
一切正常操作，但是在做发运确认时，依旧提示如下错误：
Error: Delivery [xxxx] cannot be Ship Confirmed.
For more information click the details button.
点击查看错误明细：
Error: In delivery [xxxx] , the total shipped quantity for order number [xxxxx] exceeds the tolerance.The source system for this order is Project Contracts. The maximum shipped quantity allowed for the line [xxxxxx] within this delivery is 30.
Actions suggested to resolve the issue:
1) If delivery lines are pending with over pick flag checked and source line [xxxxxx], please pick confirm them. (Not for Third Party Warehouse)
2) Reduce the shipped quantity for the delivery lines with source line [xxxxxx] to bring within over ship tolerance.
Metalink 943179.1 提到过该现象，是由于发运数量超出Ship Tolerance Above (STA)造成的。这是常规原因，但它并没有涵盖所有的问题。进入Shipping Transactions Lines查ship_tolerance_above值为空，也就是说，默认上限为行上的Requested QTY，而在本案例中，发运数量为30，比需求数量30.409370703164要小。
乍看之下，似乎没有问题，但是事实上这是一个比较基本的，也是普遍的问题。在Oracle ERP中，各个模块和功能对于数字精度的处理方式都是不同的，有些地方最大到小数点后5位，有的地方可以到9位，甚至于，有些功能在应用patch升级后，直接将小数位精度调高（有时候会因为数字不匹配而导致功能异常）。所以在任何时候，都必须对精度问题保持警惕。
在这个案例中，将需求数量调整为30或者30.1（也可以采取四舍五入的简单办法，关键是精度），重新Ship Confirm，一切回归正常。
由于各模块集成度较高，建议在任何可能的情况下，控制数值精度在小数点后5位以内，这是最简单解决此类异常的有效办法。
案例：用户的职责中存在一个form，从Web页面登录后点击form，出来错误信息：“对不起，不存在可用的有效责任”，英文信息为：“Sorry, no valid responsibilities available”。如果cgi模式下，从其他职责切换过去则正常。
检查职责定义发现Responsibility Key（责任关键字）值是中文——这是很糟糕的习惯，任何key-like的存在都不应该出现ASCII（如英文字母、数字、下划线等）之外的字符。Oracle数据库虽然支持索引字段使用中文，甚至字段名都可以用中文，但是对于EBS这种大型应用而言，使用中文便存在风险。在此案例中，职责Responsibility Key用中文貌似正常，但是职责信息需要被同步到其他地方，而同步程序，你不能保证它会正常工作。
这其实是一个常见问题。解决办法也很简单，正常途径是新建职责（使用英文责任关键字），然后替换下用户的职责即可。非正常途径如下：
- 在数据表(FND_RESPONSIBILITY)中将RESPONSIBILITY_KEY修改为英文字符。
- 执行并发请求Sync responsibility role data into the WF table(使责任职责数据与 WF 表同步)
- 清理缓存。路径：Functional Administrator -> Core Services -> Caching Framework -> Global Configuration -> Clear All Cache
P.S: 关于清理缓存的知识请参考《清理 Oracle EBS 的缓存》。
OK，让用户重新登录吧。
Oracle XML Gateway(XML网关)作为EBS的一个重要组件，主要用于和其他信息系统——应用到应用、业务到业务(A2A, B2B)——的集成，它基于OAG标准，可以与各行业的信息系统进行集成。
那么对于一个XML Gateway工作岗位，应当具备掌握哪些知识或技能呢？
- Oracle 数据库，尤其是AQ。XML网关大量利用AQ和EBS其他组件进行交互。
- XML/DTD。所有消息都是XML格式，事实上，XML支持所有基于DTD的XML标准。IBM有个XML国际认证内容非常充实，里面对XML的各类知识介绍的非常详细。
- Web Services。需要掌握Web Services相关知识，比如WSDL、SOAP等。对于实施顾问，建议掌握XMLSpy和soapUI等工具的使用。
- Oracle Workflow。XML网关可以和工作流、业务事件无缝集成，基本上，标准功能的所有出站消息都是通过预定义的业务事件触发的。Workflow组件（也有独立版本）已经不再升级了，但是数年内依然会有大量应用。
- 至少掌握Java、Python等一门可用于网络编程的语言(要模拟HTTP Post)。对于进站消息，除非交易方也是EBS系统，不然在测试时，需要写点小程序来测试。当然也可以用ECXOTAInbound来测试应用，但是无法完整模拟第三方应用。
市场上各种集成方案非常多，如果使用Oracle XML Gateway，在实际应用上，Oracle Workflow(包含业务事件)是整个工作的重心。在EBS标准功能中就已经预定义了很多业务事件，只要配置好交易类型和交易方相关参数，便可以开始启用。如果需要客户化内容，则可以自行创建该业务事件的订阅来实现。
相对于EDI标准，XML消息更多的是基于事件，实时，设计为单事务处理的。
对于所谓的“交易方”的应用，我不知道有多少家企业会真正用这个产品。在我的经验中，首先，EBS中的业务事件对于大批量数据（比如1k笔/秒)的处理，在可靠性上存在问题。再次，XML Gateway和EBS中的业务事件集成度非常高，对它的可靠性很难评估，而在实际业务中，虽然多数情况下确实都属于“单笔”数据，但是总会偶尔出现大批量的情况。
在中国中，相对数量上，使用Oracle XML Gateway的企业还是非常少的。一来是相关行业的信息化程度不高，更多的是处于电子邮件、传真等手工作业阶段，当然，最主要还是因为Oracle ERP产品用户群不够庞大；二来，估计用EBS产品的用户，也没几家乐意和其他企业进行此类方式的数据交互。不过，用于企业内部异构系统的集成倒是不错的选择，因为它实用，是一种基于应用层的相对简单的集成方案。
相关工具：
