转：SAP INTERFACE

转自：http://blog.chinaunix.net/u2/86757/showart_1669671.html

 

SAP Interface：

ALE/IDocs是SAP公司为SAP R/3 R4.6C版本所提供的接口机制，目前应用最为广泛。

在 R4.0以后的版本中，又添加了技术上先进的BAPI。

 

1、ALE/IDocs：

 

ALE 是Application Link and Enabling的缩写，是SAP专门为SAP与SAP之间所设计的整合中间件。

ALE在SAP 3.0版本开始就作为SAP整个应用体系的一部分，为分布式数据交换提供了可靠安全的通讯机制。

ALE的设计，原本作为两个SAP流程之间的一种消息传递服务(Messaging Service) ，使SAP与SAP的业务流程之间企业数据能够有效的交换，为两个独立的SAP之间提供了的系统整合服务。

IDocs是中介文本 (Intermediate DOCument) 的缩写，是SAP提供的系统整合专用的数据/消息格式。

 

2、ALE/IDocs的消息发送接收过程

 

ALE的设计结构可以分为三层：应用层、数据消息分配层、应用层。

 

通讯层：SAP整合机制的基础，它利用远程功能呼叫RFC(Remote Function Call) 调用SAP系统的功能模块。

 

数据/消息分配层：

提供三个关键服务：按数据分配模型决定数据接收者；

                           消息的过滤和转换；
                           数据/消息的压缩，以提高传递效率。

 

应用层：直接与SAP系统接口，生成或从其它系统接收含有路由信息的消息文本IDocs，包括消息接收者的姓名，要求发送的类型以及对消息进行处理的规则。

 

3、ALE与BDC

ALE的机制代替了原来的SAP所提供的批数据通讯BDC(Batch Data Communication) 方式。

顾名思义，BDC为系统之间提供了简单的数据批处理服务，还不能作为一种中间件技术，它没有提供系统之间进行无缝整合所要求的纠错功能、系统管理和其它安全措施。

 

4、应用SAP的ALE机制进行SAP与SAP或非SAP系统整合有以下几个好处：

。ALE技术不受SAP版本升级的影响，它提供了版本向后兼容性。

。ALE定义于SAP应用层，与SAP的逻辑层相对独立，整个ALE中间件独立于发送和接收系统。

。ALE消息设计逻辑保证消息的“一次且只有一次”的消息传递。

。ALE采用“存储-发送”技术确保消息即使系统发生故障或接收方没有准备接收时也可以达到目的地，

   这样就保证接收方不至于收到重复消息。

。ALE也提供了IDocs管理功能。

   主要有文本缩减、文本版本控制以及文本数据过滤。

   三种控制机制使得SAP开发人员可以根据实际需要对IDocs文本在运行中进行动态处理。

。ALE提供了系统管理功能，允许对ALE系统进行启动/复位/恢复等系统操作，为开发人员提供了进一步的管理控制。

。IDocs 几乎可以传带任何SAP应用的数据，是一种“外围”定义格式，与SAP的应用数据定义不直接相关。

。IDocs已经广泛应用于早期的SAP-EDI的数据交换，因而它的设计有点类似于EDI的标准，即EDIFACT标准。

。IDocs是以字符基础的，因而是可读的。

   它有三种纪录类型，即：控制纪录-含文本信息，如IDoc类型，发送/接收方信息以及文本标识。

                                    数据纪录-含管理和实际数据部分。

                                    状态纪录-用来追踪文本传递各点的状态，如状态码，系统时间，错误标识等。

 

4、ALE/IDocs在系统整合过程中消息的实际传递过程：

一个发送过程由：事件触发，文本生成，数据打包以及交由传输媒介传递这四个步骤组成

      应用系统事件触发：

     系统目标(Objects) 的状态变化，用户自主活动或其它数据库特定变化等可以启动数据表的触发程序，从而进行数据传递的初始化工作，如数据准备。

    * 生成主IDoc文本(Master)

       按标准格式生成主IDoc文件，包含所有可以传递数据(不分接收者)

    * 生成通讯Idoc

       从主IDoc中生成只与特定接收者有关的文本，通讯文本是主文本的子数据集(Subset)

    * Idoc 发送

       利用异步通讯方式将一定版本的IDoc传递到接收方。

 

接收过程：

接收过程始于SAP系统从外部收到IDoc文本。接收过程的优点在于，接收方既可以是SAP系统，也可以是第三方系统，这也是SAP与第三方进行有效整合的基础。接收过程由以下三个步骤组成：

    * 存储Idoc-将文本存储于数据库，并进行语法校验

    * 邮件处理程序读取Idoc--一个专门设计的IDoc处理程序读取IDoc并产生SAP或其它系统所需的系统消息。多个程序可以同时运行。

    * 生成系统文本--处理程序进一步生成系统文本供系统使用，并将结果信息存于Idoc d的状态纪录中。

 

5、BAPI简介

     BAPI 是Business Application Programming Interface的缩写，是SAP为3.0版本以上提供的基于企业目标(Business Object) 技术的接口应用界面。SAP在3.0版本以上采用了Object-oriented技术，逻辑定义了SAP R/3系统的所有功能目标，并且将所有的目标(Objects) 和BAPIs存储于企业目标库BOR(Business Objects Repository). SAP R/3 企业目标的目标类型(Object Type) 相当于目标设计语言中类(Class) 的概念，其定义结构由以下几部分组成：

    *

        基本数据--所有目标类的通用属性，如目标标识和默认方法(Method) 。

    *

        接口界面--目标的方法(Method)， 事件(Event), 特征(Attributes) 。

    *

        键(Key Fields)--供BOR中目标检索使用

    *

        方法(Methods)-- 对目标进行所要求的各种操作。

    *

        特征(Attibutes)-- 描述目标特征。

    *

        事件(Events)-- 触发以改变目标状态

 

6、应用SAP-DCOM接口介绍：

SAP 于1998首次提供SAP-DCOM接口，以满足各种桌面应用开发的要求。利用DCOM连接端口，开发人员可以利用VB， C++，以DCOM目标方式访问SAP数据。在Web应用上，可以用VBScript, javascript 以DHTML方式页面访问，也可以用ASP访问数据。

另外，利用DCOM也可以间接访问SAP的企业目标库BOR。上面提到的BAPI是SAP系统上专用的，在实际应用上不如DCOM来得广泛。DCOM端口主要有两个技术模块组成：

                                                   一个是管理模块

                                                   另一个模块生成SAP BO的DCOM 代理组件(Proxy Components)。

生成的DCOM组件存放于C++。代理组件有以下属性：

          *

             Client-要访问的R/3客户系统

          *

             UserID-R/3用户

          *

             Password-用户密码

          *

             Language-系统语言

          *

             Destination-预先定义的目标名称

      另外，每个组件具有以下方法：

          *

            PutSeesionInfo()—设定系统一次调用的目标参数

          *

            AdviceRfcGuiSink()—用于需要SAPGUI或dubugging的场合。

          *

            CommitWork()-用于数据更新，无implicit commit的场合。

          *

            InitKeys()-DCOM目标键初始化

          *

            DimAs()-返回Microsoft ADO(Advanced Data Object) 纪录集(支持游标控制)。

          *

            其它从R/3 BO定义中继承的方法