使用WBI SAP Adapter 实现IDoc的同步处理（转）

龍子

　　1. 应用背景
　　某汽车制造企业（以下称为厂商A）与其仓储系统提供商（以下称为厂商B）需要进行数据交换。汽车厂商A使用SAP系统作ERP管理，所有数据都要进入SAP进行处理，仓储系统提供商使用的是自有的系统。目前数据交换的办法是，由B自己开发程序将数据输出为标准的IDoc文件，然后通过远程文件传输系统传输到A，A自己利用SAP JCo (Java Connector) 调用EDI接口把文件输入到SAP系统中。这些IDoc文件以时间戳来排序，要求严格按照时序来进入SAP系统，即必须在上一个处理完成之后再进行下一个。原因在于提货数据依赖于入库数据，必须先入库，才能提货，否则会出错。
　　为了解决传输稳定性和时序问题，首先引进了MQ。通过MQ作为排队和传输通道，A和B各开发发送和接收客户端，很好的保证了消息的可靠传输和时序问题。但这种实现方式，存在的问题是需要厂商自己开发维护程序，一旦IDoc消息有改动，必须修改两端的程序，两个应用被紧耦合在一起。所以考虑使用Message Broker和SAP Adapter 来实现该功能。
　　Message Broker利用MQ作为传输机制，同时可以对消息进行解析和转换。这样B厂商的发送端程序不需要做改动，只要在Message Broker中将IDoc 消息转换为Adapter 需要的BO 消息。对于 SAP Adapter 来说，要求的始终都是BO消息，不必理会发送端到底送出的是什么消息。
　　本文重点介绍在这样场景下SAP adapter的使用和配置而不涉及Message Broker。

回页首
　　2. SAP Adapter简介
　　SAP Adapter 是WBI Adapter家族中的一员，其架构如下图所示：
　　

　　SAP Adapter是Broker和SAP应用系统之间进行通讯的桥梁，使数据可以在SAP系统和Integration Broker 之间双向交换。
　　在使用Message Broker作为broker的情况下，SAP Adapter 和Broker之间通过JMS方式来进行通讯，即使用消息队列。Broker和Adapter使用业务对象（Business Object简称为BO）这种WBI框架内定义的消息格式作为数据交换的标准格式，每一种类型BO都由相应的XML schema文件来定义。Broker将BO消息放入Request 队列，Adapter监听该队列并通过SAP系统处理得到的消息，根据配置决定是否返回给Broker处理结果（同样也是通过消息队列）。SAP Adapter还可以监听SAP系统中的事件，并把该事件转换为BO消息通过队列传递给Broker。
　　SAP Adapter 通过SAP JCo (SAP Java Connector)提供的API来与SAP 进行通信，通过调用SAP的各种RFC（Remote Function Call）接口来实现不同的功能模块。SAP Adapter提供了5种模块可供选择：
　　SAP Adapter 通过SAP JCo (SAP Java Connector)提供的API来与SAP 进行通信，通过调用SAP的各种RFC（Remote Function Call）接口来实现不同的功能模块。SAP Adapter提供了5种模块可供选择：

• ALE--通过SAP的ALE 功能，实现Adapter和SAP系统之间IDoc的双向传输。本质上是一个面向批量数据处理，只支持异步的模块。
  
• BAPI--提供对各种BAPI包括RFC的同步调用，只支持从Adapter到SAP系统的调用。
  
• HDR--提供对SAP系统表数据的直接访问。
  
• RFCServer--Adapter可以作为一个RFC Server，在SAP系统中可以用ABAP来远程同步调用Adapter支持的RFC，从而可以支持由SAP系统发起的需要外部程序响应的情况。
  
• Extension--用ABAP在SAP中对应实现了Adapter的各个接口，可以定义自己的事件类型，支持双向通讯。但需要在SAP部署定制的ABAP程序。
  

回页首
　　3. SAP Adapter 的配置
　　在配置SAP Adapter前，首先要确定使用哪几个模块（SAP Adapter可以支持同时使用多种模块！），在本文的应用背景下，可以考虑ALE，BAPI和Extension三种模块。ALE Outbound （从Adapter到SAP）是通过调用SAP的两个RFC函数：IDOC_INBOUND_ASYNCHRONOUS（4.X 版本的IDoc）或IDOC_INBOUND_PROCESS（3.x版本的IDoc）来实现的。由于这两个函数没有返回值，所以ALE模块本质上只支持异步操作，显然不适合应用的要求。Extension 模块能实现同步调用，但是需要在SAP系统中作定制和一定的开发，比较繁琐。BAPI模块可以调用各种RFC，同时保证同步调用，我们只要找到相应的同步处理IDoc的RFC函数即可，而SAP确实提供了这样的接口：IDOC_INBOUND_SYNCHRONOUS(3.x IDoc)和IDOC_INBOUND_SINGLE(4.x IDoc)。因此，这里选用了BAPI模块。
　　选用BAPI模块还有额外的好处：第一，如果使用ALE模块，SAP Adapter需要为每种IDoc的类型来生成BO Schema，也就是说，每增加不同的IDoc类型，则需要重新生成BO Schema。而直接使用BAPI模块，调用的函数可以处理任何类型的IDoc ，所以只需要一次配置，特别是在Ｂ厂商提供的是标准的IDoc文件的情况下，IDoc文件和SAP 提供接口之间的对应关系比特定的IDoc类型之间的关系简单，这样使得Broker的解析工作变得更加简单。第二，BAPI模块只支持从Adapter到SAP系统的单向操作，所以它的配置是最简单的。
　　要使Adapter 工作，需要作两件事：
　　1.生成BO的定义。
　　BO是Adapter所需要的消息格式，由XML Schema来定义。SAP Adapter提供了一个称为ODA（Object Discovery Agent）的工具，用户无需手工编写Schema，只要通过BO 设计器来访问ODA，按照向导来选择对应的原数据如IDoc类型、RFC函数名等，ODA会自动根据系统内的定义生成相应的BO Schema。
　　ODA和BO 设计器是通过Client/Server方式来协同工作的。首先要启动ODA，下图为ODA 启动后的情况：
　　

　　然后使用BO 设计器连接到ODA，跟随向导来一步步生成BO。下图为BO 生成向导中的一屏，在这里用户可以选择需要生成BO的元数据。在BAPI的情况下，需要选的数据是一个RFC接口的定义，可以在RFC根节点下通过名字来查找名为IDOC_INBOUND_SYNCHRONOUS以及IDOC_INBOUND_SINGLE。如下图，找到后选中这两个节点，完成下面的步骤即可生成相应的BO schema文件。
　　

　　生成后的BO可以在BO 设计器中查看和编辑，如下图所示：
　　

　　以上BO定义中的各条属性对应了IDOC_INBOUND_SINGLE接口中的各个参数，而IDoc文件中的数据都可以映射到这些参数，这样IDoc文件中的数据就被转换成RFC调用中的参数传递给了SAP系统进行处理。这里的对应非常直接，所以转换并不是一项非常困难的工作。
　　2.配置Adapte。Adapter运行时需要指定相应的配置文件。通过适配器配置工具可以生成配置文件。
　　在本文的应用中，需要保证消息处理的时序性，所以只能通过单线程操作。相应的需要将Adapter配置为单线程：
　　从消息队列里取消息时，使用单线程，则配置jms.NumConcurrentRequests = 1:
　　

　　以单线程将IDoc送到SAP并处理，即以单线程调用相应的RFC，则配置MaxNumberOfConnections=1：
　　

　　SAP Adapter可以支持多种BO 定义，只要它们都加到配置文件中：
　　

　　生成配置文件和BO定义后，我们就可以启动Adapter了。启动后的Adapter控制台如下所示
　　


回页首
　　4. 测试
　　启动Adapter后，通过程序向Request 队列按顺序发送4000条从对应IDoc生成的BO 消息。Adapter成功的处理了所有的消息，无遗漏，无错误。由于单线程操作，处理速度稳定在2 message/ sec 左右。在每次处理中，远程调用花费时间200ms左右，其他BO转换花费300毫秒左右。

回页首
　　5. 小结
　　使用Adapter代替自己开发程序有很多好处。首先，不必维护复杂的代码， 只需要维护一个配置文件和几个BO schema文件，而且都有图像化的工具来辅助。其次，具有多种可配置的属性，比如如果将来不需要保证时序，而要求提高性能，那么只要改动配置文件使Adapter多线程工作即可。第三，适应性和扩展性好，如果将来需求有变化，比如要调用新的RFC函数，那么只要重新生成BO schema即可，要变成双向通讯，只要在配置中添加ALE等模块即可。
　　总之，使用SAP Adapter是可以实现IDoc的同步交换的，并且比手工编码实现有更好的扩展性。虽然就事论事，第一节提到的应用场景用手工编码的方式更简单。但是在日新月异的今天，未雨绸缪，使用Adapter 可以更好的适应不断变化的企业流程和不断丰富的需求。