在应用中，应当避免执行一些长时间运行的操作，毕竟对于一个OLTP环境，快速响应才是重心。在某些情况下，可能无法使用批处理的方案，需要在用户界面做操作，但是某些特殊环节可以后台运行。这时候，在设计功能时就应当考虑异步处理机制，尤其是要用好批处理和后台处理等方式。
对于后台处理方式，EBS中大致有这么几种方式可选：
- 并发请求
并发请求几乎可以实现任何耗时的运算，也是在EBS环境中常用的后台处理方式。比如很多地方都允许设置处理方式，如联机处理、后台处理等。根据系统性能和响应要求自行组合逻辑块。这种方式的优点是实现简单，管理方便，缺点是受限于并发管理器的配置。此外，大多数企业里的并发程序都运行在数据库服务器上，如果涉及到异构系统的数据传递需要考虑到安全方面的问题。 - 工作流 (Oracle Workflow)
如果是逻辑判断比较清晰又比较复杂的话，这是不错的候选方案，实施顾问也可以非常清晰的看到各个流程走向。这个方式的优点是可以将运算逻辑模块化，缺点是偏长于逻辑判断，而不适用于大数据量运算。 - 业务事件 (Business Event)
业务事件依托于Oracle Workflow，允许客户自行订阅并执行客户化代码。业务事件底层用到了AQ，可以将消息从数据库层传递到应用层。这也是我最欣赏的一块内容。EBS内置了很多标准的事件，比如付款、BOM更新、资产转移等。这种方式的优点是代码都在应用层执行，管理方式简单，缺点是标准的业务事件数量太少了。 - DBMS_JOB
这其实算是一种非标准的方式，但是对于客户化应用比较合适。有时候，使用并发请求和业务事件都太过麻烦，但是通过JOB可以非常迅速的剥离执行逻辑，对用户而言，这可以算是比较标准的后台处理方式。这种方式的优点是简单方便，缺点是适用范围有限，适合在数据库层的运算。 - 管道 (PIPE)
Oracle数据库管道技术在EBS系统中，我目前只发现MRP运算时有用到。它在应付多程序间通讯方面有优势，一个极端的应用是你可以在操作系统shell中实时看到某并发请求的运行情况。它的实现逻辑简单来讲，就是一个会话将消息发送的缓冲区，另一个会话从消息缓冲区读取消息。这种方式的优点是通讯方便，缺点是可能需要自行设计多会话间的消息封装机制，并且仅适用于小数据量传递。 - 高级队列(AQ)
EBS中很多异步处理机制都利用了AQ，这相对而言太过于“底层”了，很少在二次开发领域有用到的。在大型的客户化应用中用的较多。
简单来看，对于后台处理方式就以上这么几种了。EBS R12中内置了SOA，可以通过外部平台进行运算，但是我不认为这是EBS系统范畴了。
个人比较推荐的是使用JOB，这在我的经验中是最简单有效的，不过前提是需要自行设计一套错误处理机制。如果涉及异构系统，我优先考虑业务事件。
