Error: Delivery xxxx cannot be Ship Confirmed
Posted on December 9, 2009 - Filed Under E-Business Suite | Leave a Comment
一切正常操作，但是在做发运确认时，依旧提示如下错误： 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 [...]
no valid responsibilities available
Posted on November 17, 2009 - Filed Under E-Business Suite | Leave a Comment
案例：用户的职责中存在一个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，让用户重新登录吧。
XML Gateway职位需要掌握哪些知识？
Posted on October 31, 2009 - Filed Under E-Business Suite | Leave a Comment
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产品的用户，也没几家乐意和其他企业进行此类方式的数据交互。不过，用于企业内部异构系统的集成倒是不错的选择，因为它实用，是一种基于应用层的相对简单的集成方案。 相关工具： Apache Axis: 基于Java的SOAP客户端 Suds: 基于Python soapUI: Java编写的专用集成环境，功能强大
关于系统集成二三事
Posted on October 26, 2009 - Filed Under E-Business Suite | Leave a Comment
本文的标题其实也可以改为：我为什么学习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相关领域。
Oracle Application Express Listener
Posted on October 22, 2009 - Filed Under APEX | Leave a Comment
在今日之前，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″ [...]
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 [↩]
