一切正常操作，但是在做发运确认时，依旧提示如下错误：
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产品的用户，也没几家乐意和其他企业进行此类方式的数据交互。不过，用于企业内部异构系统的集成倒是不错的选择，因为它实用，是一种基于应用层的相对简单的集成方案。
相关工具：
本文的标题其实也可以改为：我为什么学习XML Gateway(陋习啊，每接触一个领域，总要问一遍为什么要学)。异构系统越来越多，原先的方式和思路解决现在的问题越来越捉襟见肘了，怎么办？在这一 点上，我走了一些弯路，当然，很多原因都是因为经验在作祟。有时候，不想放弃自己所擅长的，结果便迎来自己所不擅长的。
先从自己的经历谈起。在工作经历上，我最早的投入领域是Oracle Database(那时还是8i)，之后陆续研究过9i、10g(这也是我的OCP认证版本)、11g。
之后转投Oracle ERP，功能和开发都做，早期接触的是分销模块和二次开发，这段时间算是对EBS 11i从功能到技术有了个相对完整的了解。而后陆续扩展到各个功能模块，从我实施顾问的经历来看，工作性质其实都差不多，只是内容不同而已。技术方面，除 常规的二次开发工具和方式（如Report/Form/OAF/DBI等）之外，也研究过各类可能更实用的工具，比如Groovy、Perl、 Python等语言在EBS二次开发方面的使用。当然，最后发现它们其实并不适合推广，仅供少数特殊情况下使用。对于企业应用而言，这种特殊应用带来的学 习成本是比较高的。
接下来的一个阶段的学习成本是比较高的。对于EBS 11i领域的资格认证方面还存在Workflow专项领域的OCE认证，R12中取消了，因为Workflow已经逐渐被另一套产品(BPEL)所取代， 当然，若完全取代可能要等到R13或更以后了。当时对Workflow从应用到功能，从开发到后台引擎，从各组件到性能优化，都花了不少精力，最后索性通 过OCE认证考试来验证自己的掌握程度。对于EBS应用本身而言，基于PL/SQL的Workflow已经足够好了，但是从另外一个角度来看，它脱离了 EBS几乎毫无用处。而BEPL，可以作为独立的应用（基于SOA Suite），甚至可以用到BPM等领域，当然，它是不再是免费的了。
随着信息化的推进，渐渐地发现试图将所有应用都纳入到EBS平台中去是一件不甚高明的决定。OAF框架是最先被我否决的，它开发成本相对较高，关键 是在当今的时代里，它能实现的功能和界面都太过粗糙和简陋了，而且性能也一向是让人诟病的地方。Form平台开发简单，容易上手，功能也足够强大，但是需 要Java Applet的支持，对于内部员工倒无妨，对于外部人员，这是有点夸张的方式。对于简单的Web App开发平台，我选择了APEX。这是Oracle内部也在使用的，同时，也是非常有前途的快速开发平台，只需要掌握简单的HTML和SQL知识即可快 速上手。最近，对于即将到来的4.0版本，也推出了专用的APEX Listener，这对建立企业级应用，同时和其他系统的集成带来了非常大的帮助。尤为可贵的是，APEX支持Web Services。
在我的相关经历中，对于EBS和异构系统的数据集成方面，做过以下几种尝试：
- 数据库层的集成。通过透明网关、DBLINK和其他系统集成，这是最简单、有效的方式，但是这只适用于企业内部系统之间。对于不支持透明网关，或者干脆是其他企业的系统，还是得从应用层寻求解决之道。
- 使用Java、Python等语言，在应用层自行设计实现方式。这种方式，从EBS应用领域来看，适合对外发布数据，无法做到双向传递，除非再加一层应用。如果选用这种方式，相当于开发一套专门的应用了。
- 在DB层使用Web Services，考虑到系统架构和数据库安全，这也是被否决的。
- 也曾考虑过使用独立的应用(比如APEX)做中转，但是这种产品基本上通过Web Services实现，于是想到了下面的方式。
- 使用XML Gateway。一直未层考虑该功能是因为国内环境不够成熟，当然，这也和公司所在行业有关，从供应商到业主，根本无法考虑和对方的数据传输问题，很多地 方，还是手工方式。在内部系统未考虑，则是因为自己的应用，都是自己熟悉的，甚至是自己设计的，系统集成是早就被考虑的因素之一。
从开发角度看，XML Gateway相对于数据库层面的集成方式有点麻烦，但是却比其他方式简单许多。在架构上，要求把数据库和应用区分开来，并且将这应用公布于异构系统面 前。对于ERP系统而言，这是有难度的。不过这个问题很好解决，企业内部的异构系统不存在问题，如果对于外部应用，必须考虑增加一层了。
此外，还有一点值得考虑的是，XML Gateway事实上也包含了Web Services/JMS等方式的数据通讯实现。延伸出去，还有通过Oracle Exchange的WebMethod等等。由于XML Gateway可以和工作流、业务事件紧密集成，这就为内部开发（二次开发）带来非常大的便利。
想要不增加成本的扩大应用领域，就要充分挖掘已有的功能，当然，代价是自己动手去做。尤其在国内，没有一家网络公司或者软件公司可以帮你解决问题，很多时候，即便花钱，还是要自己动手的。当然，我所说的是指和EBS相关领域。
在今日之前，APEX应用可以通过两种方式访问（架构），即：
- Oracle HTTP Server/mod_plsql
- XDB HTTP protocol server/embedded PL/SQL gateway
今天，Oracle发布了Oracle Application Express Listener，这是很早以前就预告要在APEX下一版本(4.x)提供的主要新特性之一。通过APEX Listener，Web层增加了对以下平台的支持：
- Oracle WebLogic
- Tomcat
- OC4J
尽管11g内置了PL/SQL gateway可以当做一个逻辑上独立的Web Server来用，Oracle的技术顾问认为在应用规模不大的环境下，该方式比DB + Web Server的两层架构性能更佳，但是在我个人的测试下，发现并非如此。对于正式环境，我强烈建议使用独立的Web Server。
下面是一个Tomcat的配置指导：
- Download Tomcat
Download
- Unpack Tomcat
- Edit the Tomcat configuration file to increase the maximum header size (the default is 4k). Edit ….\apache-tomcat-6.0.18\conf\server.xml
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
maxHttpHeaderSize="32676"
redirectPort="8443" />
If you need to change the port from the default 8080, this would be done at the same time:
<Connector port="8888" protocol="HTTP/1.1"
connectionTimeout="20000"
maxHttpHeaderSize="32676"
redirectPort="8443" />
More information is available in the Apache Tomcat Configuration Reference.
- Extract the apex.war file from the apex_listener.zip (available for download on the APEX Listener Download Page) to …\apache-tomcat-6.0.18\webapps
- Start apache-tomcat-6.0.18\bin\startup.bat
- Visit http://localhost:8080/apex/Config
- Recursively copy the apex/images directory to ../apache-tomcat-6.0.18/webapps/ROOT/i
更多资料可访问网址：http://www.oracle.com/technology/products/database/application_express/index.html
P.S: 该产品目前还只是Early Adopter，非常非常前期的测试版，存在很多BUG。对于中文用户，如果页面中需要返回中文文字的消息，则可能会导致该消息乱码。在功能页面上，会返回类似
Error print success message checksum content error: ……
的错误。
众所周知，在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 Services相关功能(仅仅是相关功能)。
现在，公开可下载的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了。
