1. 概述
1.1. 总体说明
财务集成解决方案是通过中间件以发布-订阅模型来实现数据的传递。财务相关数据从Oracle E-Business Suite财务模块中发布出来，然后Oracle Retail通过它自己的中间件架构-Oracle Retail Integration Solution(RIS)来订阅这些消息。在外向事务流中，RIS生成财务中间表，然后利用它们通过标准财务接口功能向Oracle GL和AP模块导入数据。
对于不同的企业模块，目前的应用还无法使Oracle Retil从一个单一的SOB（set of books )中区分出财务数据，集成的第一步，是定义一个新的SOB标识CHART_OF_ACCOUNTS_ID，这使得Oracle Retail能够识别集成SOB以从Oracle中抽取和发布财务相关的数据。Oracle Retail GL Setup表（FIF_GL_SETUP）根据它来实现集成。
2. 系统架构
2.1. 整体结构
与所建议的一样，集成的解决方案是通过中间件来实现的。EBS系统用BPEL提供web服务，Oracle Retail系统使用RIB来提供web服务。
Oracle BPEL Process Manager是运行在Oracle应用服务器上的基于JAVA的解决方案。Oracle BPEL PM使用数据库适配器（DB Adapter）与EBS中的数据源连接。
RIB同样也是基于JAVA的解决方案，它运行在SeeBeyond eGate上。RIB是一个异步的消息通道，它可以订阅BPEL创建和发布的消息，然后把消息的payload数据元素插入到RMS数据库中。Oracle Retail的应用程序通过Java Message Service（JMS）适配器与RIB连接。
集成的模型执行图
模型的三个主要组成部分：
- l 运行在10g上的Oracle E-Business Suite 11.5.10 CU2
- l Oracle BPEL为Oracle E-Business Suite 10.1.2提供中间件集成。
- l Oracle Retail 11.0.5
外向数据流：BPEL和RIB中间件用于在两个系统之间建立连接和传输数据。从EBS财务模块导出的数据通过网络交换平台（NET change basis）传给RIB。然后在Oracle Retail中进行处理并更新相关的数据库表。
内向数据流：经过总结处理后的财务信息又从Oracle Retail传到财务中间表中。然后这些数据经过BPEL处理、提取数据并通过财务公开接口导入到GL和AP中。
2.2. Oracle 外向处理流
从EBS到Retail
在BPEL中支持下面EBS财务模块的外向相关数据流
外向事务处理流
1. Oracle E-Business财务模块GL总帐code combinations（会计科目）、供应商、汇率、运费组和支付组的数据被传到网络交换平台上。所有的记录添加或修改都将在预先设置好的平台上进行。
2. BPEL提取这些记录并执行数据转换，生成与RIB兼容的XML记录格式。
3. XML消息被发布到RIB，然后RIB订阅适配器尝试根据消息的topic和action（更新，修改，删除）来更新相关的业务数据对象。如果成功了，则从JMS中删除这条消息。否则，消息将会被写到RIB Error Hospital中，以便手动查看或自动重发布到适配器。
2.3. Oracle 内向处理流
从Retail到EBS
下面Oracle E-Business财务模块的内向事务数据流在整个BPEL中得到全面支持。
内向事务处理流
1. 当前Oracle Retail业务处理提取相关数据到标准的财务集成中间表中。这些表是：
- l 匹配采购订单收据（新建发票）
- l 借贷凭证
- l 存货变动（库存帐）
- l 销售审计（销售日记帐）
2. BPEL流直接读取财务中间表，抽取详细信息和执行数据转换处理并传送到标准GL或AP开放接口。
3. 一旦传送到标准开放接口，正常导入和错误管理过程将在Oracle EBS财务中进行。
3. 集成的性能分析
3.1. 集成的性能分析
说明
性能是系统集成所要考虑的主要问题。Retail吞吐量大，符合解决方案需要支持高吞吐量的要求。在从Oracle E-Business Suite财务模块向外导出相关数据时，吞吐量不是值得担心的问题。
然而，在进行内向事务处理时，性能将面临严峻的考验。Oracle Retail 应用程序通过正常的业务流程填写标准财务中间表，这些流程是已经经过优化处理的。
在BPEL上进行的压力测试产生了下列性能基准：
导入销售审计事务的BPEL流程性能测试得到以下的结果：BPEL PM每小时可以导入350万条记录。测试是基于Linux4CUP，5GB内存的服务器上的10.1.2 Patch 2 version of BPEL PM。
4. 数据交互
4.1. 从Payment Terms/Freight Terms/Vendors/COA/Exchange 到 RMS
说明
这些数据通过BPEL Process Manager提取并以XML消息的形式发布到RIB上的JMS Topic中，然后RIB使用API从JMS Topic中提取数据并将数据插入到RMS系统中。BPEL PM有与系统错误场景相应的错误处理程序，同时RIB的API已经有内建的错误处理程序，它会将错误信息写入到RIB的Error Hosptial中。
BPEL PM有与系统错误场景相对应的错误处理逻辑，与此同时，RIB APIs也有自己内置的错误处理逻辑，这些错误将被写到RIB Hospital中。
4.2. Stock Ledger,Invoice and Sacles To GL
说明
Oracle Retail把与Oracle Retail销售审计系统（ReSA）和库存帐系统中与GL事务处理有关的数据传送到STG_FIF_GL_DATE中间表。Oracle把这些GL数据从Oracle Retail的中间表中取出，执行适当的转换然后导入Oracle E-Business Suite中的GL_INTERFACE表里。这个过程是由BPEL PM使用DB适配器（DB Adapters）来管理的。
对于Oracle Retail如何参与这个处理过程的信息，可以参考最新的Oracle Retail Invoice Matching (ReIM) Operations Guide和Operations Guide Addendum。
BPEL PM有与系统错误场景相对应的错误处理逻辑。如果有错误发生，系统将向指定的具有系统管理员角色的人发送一个通知。通知中包含了遇到错误的BPEL流程的相关信息，系统管理员在BPEL管理平台上检查错误并重新处理数据。
4.3. ReIM Approved Payments to AP
说明
完整的发票匹配过程是在ReIM中通过将支付建议（payable recommendations）导入Oracle AP中来完成的。ReIM匹配商品收据和商品发票，执行自动和手工的匹配和差异解决过程。匹配过的发票被发往中间表接口，总量，付款日期，供应商，Oracle站点ID，GL COA（帐户结果）信息和支付组。其它应付文件，包括借方记录，贷方记录和贷项清单也通过ReIM中间表（IM_AP_STAGE_HEAD和IM_AP_STAGE_DETAIL）连接到Oracle应付模块。关于Oracle Retail如何参与这个过程的信息，可以参考最新的Oracle Retail Invoice Matching (ReIM) Operations Guide 和Operations Guide Addendum
某些ReIM的事务没有被发送到Oracle应付帐户里，而是通过IM_FINANCIAL_STAGE表发送到Oracle EBS的总帐中。Oracle Retail财务中间表IM_FINANCIALS_STAGE保存着从ReIM传送过来的GL事务，它是BPEL导入到Oracle的主要中转点。为了支持数据转换和导入Oracle应付帐户标准接口，应付事务被写到一组新的Oracle Retail头信息/明细信息中间表（IM_AP_STAGE_HEAD和IM_AP_STAGE_DETAIL），以便Oracle BPEL进行处理。
业务流程
4.4. ReIM Journal Entries to GL
说明
从Oracle Retail 发票匹配流程传过来的GL事务被存放在财务中间表IM_FINCIALS_STAGE中。事务被处理后存放到GL+INTERFACE表中，这个表是用于实现通过日记帐将日记帐分录导入到Oracle EBS系统总帐的。
被取消的未匹配的商品收据和预付匹配发票被写到中间表，这些事务会影响总帐，但不需要为他们创建支付或连接其它支付。
Oracle Retail应用程序中的财务中间表不会被自动清除，可以认为Oracle财务模块对这些表有“管家”的责任。数据库适配器（datebase adapter）采用 ‘物理删除’优化选择的策略，智能地为那些记录选择数据库表并在处理完后删除。
5. Oracle Retail Integration Bus (RIB)
5.1. 订阅适配器
工作原理
订阅适配器的职责是对于给定的业务实体，保证其消息以正确的顺序被执行。比如，对一个给定的采购订单，“创建采购订单”消息应该在更新或删除消息之前执行。另外，所有的更新必须以正确的顺序进行，以保证两个系统数据的同步。但不同的业务实体之间的消息没有这样的约束。如果没有错误发生，消息会以先进先出（FIFO）的顺序执行。如果一个业务实体的消息在处理过程中出错了，其它业务实体的消息处理不会受到影响，而且出错的业务实体的所有其它消息将会被保存在Error Hospital中。
如果一个消息在处理过程中出错，则将执行以下两步：
1. 订阅适配器在内部记录出错事件并回滚所有与该消息有关的数据库操作。
2. JMS服务器重新向适配器发送消息，由于它还没有被成功执行过，适配器认出这个消息是有问题的（病的），并将它迁入到Error Hospital数据库中。
订阅适配器会经常检查RIB的hosptial数据库，看在hospital中是否有跟当前消息作用相同实体的消息。如果有，适配器就立即把当前消息也放到hosptial中。这是为了保证对于一个给定的业务实体，它的所有消息都以正确的顺序执行。由于没有人工干预，在没有后序的消息作用于该业务实体之前，RIB将一直为业务实体执行“病的”消息。
一个消息被迁入Error Hosptial后，一个hosprital重发适配器/e*Way/Daemon将重发消息到JMS以重新尝试执行。前提是错误是短时间的-记录被锁定或有外部信赖未得到满足。消息重试的次数是可以设定的。
基于PL/SQL接口的订阅流程
5.2. Error Hosptial
相关的表
下面的数据库表是用于存储Error Hosptial中的消息的：
- l RIB_MESSAGE：包含message payload，所有single-field信封信息和用<id>标记创建的连接字符串，它同时包含一个唯一的hosptial ID在hosptial中标识这个记录
- l RIB_MESSAGE_FAILURE：包含每次消息执行时产生的所有失败信息
- l RIB_MESSAGE_ROUTING_INFO：包含所有消息信封中出现的routing元素信息。
- l RIB_MESSAGE_HOSPTAL_REF：包含所有消息信封中出现的hospital 相关信息
另外，序列RIB_MESSAGE_SEQ用于保持与Error Hospital中的每条信息相关联的唯一的“Hospital ID”。
6. BPEL的错误处理
6.1. 错误处理
工作原理
BPEL提供了高度的错误处理能力。通过安装通知服务，你可以配置系统管理员邮件地址，BPEL流程出错时会向这个邮件地址发送通知。每个BPEL流程都有唯一的流程实例，它被传给系统管理员以便进行纠错工作。从BPEL管理平台的“流”标签，管理员可以选择为流程实例执行手动恢复。“实例”标签显示了整个流程的列表。
