在向新版本Oracle电子商务套件（EBS）迁移的过程中，处理定制代码是最大的挑战之一。在规划整个升级工作的时候，项目进度和预算中一个重要的变因就是理解产品相关定制工作的数量和类型。

从EBS 11i升级到EBS R12是一项艰巨的工作，需要专门的团队，还需要设计良好的策略，包括大量测试和问题排查时间都应该充分考虑进来，升级项目还应该由行政领导支持并且坚持到底不妥协。按照定制规划并完成分析工作可以预防令人头疼的升级过程中的培训、测试和问题排查过程。

从严格意义上讲，定制涉及到修改标准的EBS功能。定制代码开发起来可能代价很大，而维护过程代价更昂贵。然而，在本文中，我想讨论定制代码和Oracle不支持或不提供的相关对象，比如：

• 报表，接口，功能扩展，定制支持和工作流。
• 警告，个性化展现，文件夹和定制库（自定义pll）。
• 可以增强EBS功能的第三方组件和软件包。

将EBS定制代码最小化

尝试消除尽可能多的定制代码。研究产品更新的版本看是否有些新功能可以取代自己开发的代码。

判断一下哪些定制代码还在使用，淘汰那些不再需要的定制代码。设置查询或者监视并发请求，看看报表甚至接口是否还在使用。如果可能的话，这些工作应该花几个月完成，以进行全面的了解。

从EBS 11.5.10升级到R12可以淘汰掉20%的定制报表。一些定制报表支持分阶段部署，但现在不再需要它们了，因为新版本已经提供了。一些报表是用户需要额外信息时做的，新用户通常会这么做，对于已经使用软件很多年的老用户，已经找到了其它方法来满足业务需求。

迁移过时的定制代码以便支持EBS R12是一种资源浪费。跨国企业可能都看到了R12中本地化功能的改进，这些功能也可以帮助他们消除一些定制代码。

只在必要时做迁移

如果你已经复制了标准Oracle报表副本并修改了很多，那么最好的做法是从新发布版本上再复制一份相关对象副本，再做一遍这些修改。不要花大量时间来实现让过时的11i报表能在R12上运行这件事。

对于工作流相关的功能，该建议同样成立。从该软件最新版本中选择最干净普通的版本，并重新应用所做的挑战和变化，你可以节约大量时间和工作量。这么做也会节约测试周期内问题解决的时间。

如果用户社区为表单设置了文件夹功能，那么这些文件夹都需要重建。最佳做法是在所有模块删除所有文件夹。在R12中文件夹可以重建，甚至可以在数据库实例之间做迁移，这么做非常节省工作量。如果你没有在所有EBS模块上组织文件夹，用户在初始测试阶段就会遇到与表单文件夹有关的一些问题，这些在更新版本的软件中都没有异议了，因为表单已经更新改变了、甚至底层表结构也变了。

虽然许多标准的开发接口和API在迁移到EBS R12的过程中通常不会有重大变更，但是重命名接口、增加更多参数还是有可能的。尽管主要接口可能不会有重大变化，你也应该测试新增的查询、或者校验、或者给你的特定网站增加了更多的数据转换，因为其它支持的表可能有变化了。

你应该重新测试事件和定期提醒，因为底层表可能在升级过程中有变化了。事件提醒在升级过程中通常是禁用的，所以你可能需要在测试前先把它们重新启用。

表单相关棘手的定制代码

有关Oracle表单的定制非常麻烦，因为它们可能是除了数据库触发器之外最容易蔓延的功能了。如果你的商业流程需要修改表单，那就尽可能用个性化来替代表单。如果你确实需要定制表单，那就尽量看看是否那些表单有可能在未来新的普通版本中提供。一些EBS模块有不少全新的表单。

你应该能使用OA基于框架的表单替换一些旧表单。如果你仍然需要定制，那就争取获得专家的帮助。许多问题可以通过OA框架表单的非行业标准变化引入。

关于相关话题，我不提倡利用旧的定制菜单，因为这些菜单有可能会指向过时的表单和功能。我们应该从Oracle刚交付的最新菜单开始工作，在此基础上做修改，这样会帮助你减少测试阶段出现的问题。

最后，考虑你可能已经获得授权的第三方产品。你可能会愿意多花额外财力来获得以前没提供（或没购买）的功能。比如，包括第三方表单和标签软件，支票打印软件，发票打印和交付解决方案等等。

Oracle EBS客户在他们迁移过程中，如果充分考虑了自主开发的定制代码，并且在升级的分析阶段针对定制化内容作了准备工作，那么就可以节省大量时间、金钱，并避免很多烦恼。