Fans Or Not

Oracle ERP领域主要有三套产品：Oracle EBS，Fusion Applications，JDE，其中似乎已经明确的是，未来将只有Fusion Applications，原因可以参考去年的一篇文章。 从Oracle EBS 11.5.10开始就引入了OAF，该框架的业务逻辑基本上都是使用Java来开发，EBS 12中OAF得到了加强和完善。尽管如此，我们知道在EBS中绝大部分逻辑还是依靠PL/SQL来实现的，不论是Form、Reports还是Workflow，都是真正的Native PL/SQL。Fusion Applications中的开发框架是ADF，也是通过Java来开发。 有人统计过两个平台的PL/SQL包数量： — Oracle EBS 12.1.3 — SELECT COUNT(*) FROM DBA_OBJECTS WHERE OBJECT_TYPE = ‘PACKAGE BODY’ and owner not in (‘SYS’,'SYSTEM’); COUNT(*) ———————- 47929 — Oracle Fusion 11.1.1.5.1 — SELECT COUNT(*) FROM DBA_OBJECTS WHERE OBJECT_TYPE = ‘PACKAGE BODY’ AND OWNER NOT IN (‘SYS’,'SYSTEM’); COUNT(*) ———————- [...]

对于EBS的新版本——尤其是patch——跟进总是慢那么一拍两拍，因为这个可以理解的原因，竟然让我对12.1 RUP3的一个很小但很实用的新特性到现在才发现：利用BIP来自动发送并发请求输出。 有些场合下，因为报表安全性设置的缘故，往往不允许不同部门的人查看对方的并发请求，但是某些报表，却又没必要每个人都去跑一次，希望有一个统一的文件服务器来存放报表归档。另外一些场合，则是希望报表自动运行后将结果email给对方——曾经，为了这么一个简单的需求，我特意写了plsqlmailer这个工具。 自动发送包含以下功能： IP打印机 Email — 需要配置匿名smtp server 网络传真 FTP 发送的内容是并发请求的out文件，如本例的发送内容是o6023340.out 。

我最近关注的相关领域无疑就是Oracle Fusion Applications了。作为EBS R12之后的下一代业务套件，你也即将关注 最早的消息可能来自OOW Keynotes中Larry的信号了，从数据库机，到云，到Salesforce，到Fusion Apps……紧接着是Oracle Press中的同步公告，明确昭告了下一代业务套件的圣子降临。 之前谈论Fusion往往是指Fusion Middleware，而即将来临的将是Fussion Applications。它的主要亮点在于采用了面向服务架构(SOA)，构建在100%标准中间件之上。Fussion Apps是以任务为中心的应用，集成协作方面具有先天优势。从技术上讲，主要包括以下范围： SOA Suite Identity Management ADF Web Center Oracle Application Server Oracle Database Essbase Bi Publisher OBIEE Content Management Collaboration Enterprise Manager 作为新的业务套件，它的第一个版本将包括以下模块： Financials (财务) HCM (人力资源管理) CRM (客户关系管理) SCM (供应链管理) Project Portfolio Management (项目组合管理) Procurement (采购) GRC (Governance, Risk, and Compliance) Fusion Apps主要针对的客户群包括Oracle [...]

最新的EBS文档12.1.3中增加了《Oracle E-Business Suite Desktop Integration Framework Developer’s Guide》，终于结束了WebADI没有官方开发指南的局面。 Oracle EBS中数据的上传下载一直是一个比较头疼的问题，尤其是在处理用户自行批量上传数据方面，虽然可以通过二次开发实现，但从开发工作量和便捷性方面看都是一种相对别扭的方案。11i中就表现出和Office系列集成态度的WebADI是值得推荐的方案，尽管当年功能的薄弱和开发工具(?)的低能，但依旧被广泛应用。R12中这一块得到了非常大的改进，比如很多曾经用WebADI集成器来进行开发配置的功能都有了Web版本。这也算成形了吧。 虽然改进的方面有很多，个人来看下面这几块改进是非常有帮助的： 集成器的定义，可以直接Web方式定义，并且各个模块(接口、布局、Uploader等)区分清晰。 接口类型分为三种：Table/API-procedure/API-function，尤其对于错误返回机制作了改进。 接口各字段属性验证，这个虽然可以在代码中实现，关键是此处可以直接在表单层面进行控制了。 LOV定义，11i中需要通过修改底表数据来实现，而今只需要定义Component即可。 Importer功能，可以使用同步/异步方式提交并发请求，也可以直接使用PL/SQL API。 参数定义功能增强，11i有个很无语的bug，修改参数定义会出现莫名的问题。 当然，最大的改进还是WebADI的模块化设计，这使得开发和维护非常简单、有效率。 文档还分出一个小章节来描述使用FNDLOAD移植WebADI，虽然早就被大家摸索出来了(回忆N年前那段黑暗中探索的快乐时光~)，但是对于这种清晰的官方描述还是值得肯定的。

花了大概一周时间完成了一套11i系统(到12.1.1)的升级，之所以耗费如此多时间，简单归纳了一下大致有以下原因： 历史遗留的配置问题（比如用中文做关键词），此类问题导致数据转换错误。 客户化（索引，物化视图等）导致升级错误。 测试机性能差，耗时颇巨。期间多次由于内存的原因，导致java程序出错。 很多R12本身的升级过程中的bug需要处理。 部分业务数据升级时出错，可能是旧数据完整性被破坏所致。 一些前期工作跳过没错，这本来可以缩短升级过程的一部分排错时间。 其他的一些可在升级之前就预先解决的问题。 整体上说，机器的性能问题很关键，有些步骤运行动辄数个小时，有些是升级程序有优化余地而事先没有发现，这些一般都在metalink上有了解决办法。对于升级，很多人第一反应就是克隆环境升级，然后导入最新数据并进行主备切换，其实这种方案对于多数企业而言很难，因为升级过程中会修改大量的表结构，甚至很多应用级别的调整，我很怀疑有哪家公司能够做到对Oracle EBS的数据结构了解的如此洞彻明晰，至少国内没有。这是我第一次对11i进行升级，积累了一些经验，在此分享。 升级前的准备 升级前的准备包括三方面，一个是应用本身的准备工作，这个在升级手册里已经详细说明；另一个就是对服务器性能做一个充分的评估，确保整个升级过程不会跳到deadline之外；还有一个，就是将所有能提前做的工作都做好，比如invalid objects，韩语分词补丁，OLAP升级等等，这些在数据库升级阶段不是必须的，但是EBS升级时却是无法直接忽略的步骤，此外可靠的网络连接也很重要，patching过程中断线后虽然可以继续，但是光启动就要花不少时间。 升级过程中的注意事项 这里依旧按照升级步骤来进行说明。 Disable AOL Audit Trail (conditional) 关闭所有审计功能，包括标准功能提供的，以及客户自行在DB级别上添加的。 Shut down application tier listeners and concurrent managers (required) Migrate database to at least Oracle10g Release 2 (conditional) 这一步之前已经做了，考虑到停机时间，分两步走是比较合适的方案。 Update init.ora with upgrade parameters (required) 同上，升级数据库时已经基本做好了。 Disable custom triggers, constraints, and indexes (conditional) 注意：最好将所有直接关联到标准表的客户化索引和Materialized [...]