|
随着SAP R／3(system application and products in data processing这款主流的ERP企业管理软件平台)成为国内越来越多大企业ERP应用的首选，很多企业都面临着同样一个问题，即如何让新的ERP平台和一些老的，或是新增加的子系统／子平台默契配合。在保证既有功能的前提下，提高系统和系统间信息传递的效率。从而保证和提高企业的生产竞争力。在这样的背景之下，ERP系统接口的应用、开发、甚至规范，会起到积极的作用。好的接口会使得系统之间能真正做到“无缝”连接，有效的整合各系统间的数据，以达到资源共享和协同工作的目的。本文的目的在于通过对SAP接口技术的介绍和实例的验证，普及和推广以规范这一接口技术为核心的一体化信息集成架构。
1 SAP接口技术
SAP组建数量庞大，各系统(ECC，BW和Portal)之间需要即时通信。对于用户来说，最佳的感受就是在同一系统中进行。为此，SAP从诞生之日开始，就提供了众多的API应用编程接口和接口工具，以方便SAP二次开发和爱好者进行研究。RFC，ALEP IDocs是SAP公司早期为SAP R／3R4．6C版本所提供的接口机制，目前应用最为广泛。在R4．0以后的版本中，又添加了技术上先进的BAPI，DCOM以及Web Service技术。下面对这些接口方式以及其它可用的整合方式进行介绍。
1．1 SAPRFC技术
RFC(Remote Function Call，远程功能调用)是SAP系统和其他(SAP或非SAP)系统问的一个重要而常用的双向接口技术，也被视为SAP与外部通信的基本协议。其他更高级的SAP接口和通信技术，如后续的BAPI和ALE等都是基于RFC实现的。简单地说，RFC过程就是系统调用当前系统外的程序模块，从而实现某个功能，而且调用系统和被调用系统中，至少有一个必须是SAP ABAP系统。这种远程功能调用，也可在同一系统内部进行(如本地SAP系统内的远程调用)：但通常情况下，调用程序和被调用程序处于不同系统。SAP系统RFC应用的原理很简单，有一些类似于三层构架的C／S系统，第三方的客户程序通过接口调用SAP内部的标准或自定义函数，获得函数返回的数据进行处理后显示或打印。根据通信方向和通信类型，共有3种RFC通信：
1)两个独立的SAP系统之间：
2)SAP系统作为调用系统，与外部远程系统(非SAPABAP系统)通信；
3)外部系统作为调用系统，与SAP系统通信。
优点：SAP的RFC调用是其接口技术中最简单和易用的一种方式，该方式开发比较简便，特别适合于外部报表开发。缺点：但对于大数据量的查询效率相对较低。如果有大数据量开发需要很多使用IDOC和BAPI接口开发技术，RFC接口方案开发量小，实施简单，很快就能满足客户需求，如在外部系统打印报表，或外部系统获取SAP简单的数据信息进行加工处理等。但这种方案只能满足客户简单的需求。
1．2 ALE／IDOC技术
ALE是Application Link and Enabling的缩写，是SAP专门为SAP与SAP之间所设计的整合中间件。IDocs是中介文本(Intermediate DOCument)的缩写，是SAP提供的系统整合专用的数据／消息格式，可用于EDI、ALE或导出导入(XML，ASCII)文件等。当然也可ALE在SAP 3．0版本开始就作为SAP整个应用体系的一部分，为分布式数据交换提供了可靠安全的通讯机制。ALE的设计，原本作为两个SAP流程之间的一种消息传递服务(Messaging Service)，使SAP与SAP的业务流程之间企业数据能够有效的交换．为两个独立的SAP之问提供了的系统整合服务。不过，随着应用的发展，ALE／IDocs接口机制也已成为与其它非SAP系统的标准的整合方式。ALE的设计结构可以分为3层，即应用层、数据／消息分配层和通讯层。通讯层是SAP整合机制的基础，它利用远程功能呼叫RFC(Remote Function Call)凋用SAP系统的功能模块。
数据／消息分配层，主要提供3个关键服务：按数据分配模型决定数据接收者、消息的过滤和转换、数据／消息的压缩，以提高传递效率。应用层直接与SAP系统接口，生成或从其它系统接收含有路由信息的消息文本IDocs，包括消息接收者的姓名、要求发送的类型以及对消息进行处理的规则。ALE设计结构，如图1所示： （图片）
图1 ALE设计结构 ALE的机制代替了原来的SAP所提供的批数据通讯BDC(Batch Data Communication)方式。顾名思义，BDC为系统之间提供了简单的数据批处理服务，还不能作为一种中间件技术，它没有提供系统之间进行无缝整合所要求的纠错功能、系统管理和其它安全措施。总的说来，应用SAP的ALE机制进行SAP与SAP或非SAP系统整合有以下几个好处：ALE技术不受SAP版本升级的影响，它提供了版本向后兼容性。ALE定义于SAP应用层，与SAP的逻辑层相对独立，整个ALE中间件独立于发送和接收系统。ALE消息设计逻辑保证消息的“一次且只有一次”的消息传递。ALE采用“存储．发送”技术确保消息即使系统发生故障或接收方没有准备接收时，也可以达到目的地。这样就保证接收方不至于收到重复消息。ALE也提供了IDocs管理功能。主要有文本缩减、文本版本控制以及文本数据过滤。3种控制机制使得SAP开发人员可以根据实际需要，对IDocs文本在运行中进行动态处理。ALE提供了系统管理功能，允许对ALE系统进行启动／复位／恢复等系统操作，为开发人员提供了进一步的管理控制。IDoc几乎可以传带任何SAP应用的数据，是。种“外围”定义格式，与SAP的应用数据定义不直接相关。IDocs已经广泛应用于早期的SAP．EDI的数据交换，因而它的设计有点类似于EDI的标准，即EDIFACT标准。IDocs是以字符基础的，因而是可读的。它有3种纪录类型，即：
1) 控制纪录．含文本信息，如IDoc类型，发送／接收方信息以及文本标识。
2) 数据纪录．含管理和实际数据部分。
3) 状态纪录一用来追踪文本传递各点的状态，如状态码、系统时间、错误标识等。
1．3 BAPI技术
BAPI是Business Application Programming Interface的缩写，是SAP为3．0版本以上提供的基_r企业目标(Business Object)技术的接u应用界面。SAP在3．0版本以上采用了Object．oriented技术，逻辑定义了SAP R／3系统的所有功能目标，并且将所有的目标(Objects)和BAPIS存储于企业目标库BOR(Business Objects Repository)。SAP R／3企业目标的目标类型(Object Type)相当于目标设计语言中类(Class)的概念。利用BAPI，开发人员可以实现对BOR进行实时访问，从而实现应用系统(SAP．SAP)之间在数据／逻辑层上的有效整合。SAP R／3的企业目标库BOR(Business Objects Re．pository)中封装了R／3的功能对象。通过BAPI(Business Application Programming Interface)可以访问BOR。BAPI是R／3平台专用的开发接口，但是从系统整合的角度看，BAPI主要是支持SAP应用．SAP应用之间的整合，SAP应用．非SAP应用之间的整合需要其他的技术，其中R／3DCOM接口应用比较广泛。
1．4 SAP．DCOM
SAP于1998首次提供SAP．DCOM接El，以满足各种桌面应用开发的要求。利用DCOM连接端口，开发人员可以利用VB，C++，以DCOM目标方式访问SAP数据。在Web应用上，可以用VB Script， JavaScript以DHTML方式页面访问，也可以用ASP访问数据。另外，利用DCOM也可以间接访问SAP的企业目标库BOR。上面提到的BAPI是SAP系统上专用的，在实际应用上不如DCOM来得广泛。DCOM端口主要有两个技术模块组成，一个是管理模块，另一个模块生成SAP BO的DCOM代理组件(Proxy Components)，生成的DCOM组件存放于C++。
R／3的DCOM接口主要用于Windows平台的应用程序访问R／3。R3 DCOM可以除了可以访问BAPI外，还可以远程调用R／3上的ABAP程序(需要DCOM Connector 4．6D以后的版本支持)。R／3 DCOM更适合于小型的R／3外挂程序，或者与基于Windows的小型应用集成。对于大型R／3EAI，必然要考虑中间件产品了。
1．5 Web Service接口技术
Web Service是独立的，模块化的，自描述的应用功能模块或服务。它基于XML标准格式，通过使用标准的因特网协议，这些应用功能模块可以被描述、查找、使用或调用。因此每一个Web Service部封装了一序列可以使用的功能集。例如，供应商的价格查询、核查库存系统的特定的物料、查找特定的电话号码、或者核对信用卡、转帐、付款等。从表面上看，web Service就是一个应用程序，它向外界暴露出一个能够通过Web调用的API。从深层次上看，Web Service是一种新的Web应用程序分支，它是自包含、自描述、模块化的应用，可以在网络中被描述、发布、查找以及通过网络来调用。Web Service是一种基于Web的中间件技术。用户通过把应用程序的一部分包装成Web服务的形式，将自己的应用程序功能提供给别人，实现应用程序之间的接口。
2 基于SAP接口技术的中间件：E2E Bridge平台
2．1 E2E Bridge平台的简介
E2E Bridge是一种系统集成解决方案。它的设计是基于国际对象管理集团(OMG)模型驱动架构(MDA)原理。目前大多数的公司都面临着系统集成的困扰，其中有的是为了满足业务或流程上的需求，有的则是为了更好地服务于分布式系统。E2E Bridge提供了一种方案，它是利用面向服务的概念进行集成需求建模。之后就能够便捷地直接执行这个模型了。这种end to end的建模过程是在UML(统一建模语言)下完成的，它由use case(使用个案)、data structure(数据结构)、processes(流程)、business logic(业务逻辑)和architecture deployment configuration(架构分布配置)构建而成。理论上，我们可以使用任何一种支持标准建模交换格式XMI(XML Metadata Interchange)的UML编辑器。XMI文件包含了所有构建服务所需的信息。这些内容之后将被部署和执行在E2E运行环境——E2E服务器中。说明和介绍UML中的某个服务，可以提供一个合理的内部运作的高层文档以及后台运作的情况的描述。因为，UML可以直接映射出所有服务包含的数据流(data flow)、事件处理器(event handler)和操作(operations)，所以，你的文档必须做到实时更新。
2．2 E2E Bridge结构
除了构建服务操作的模型，E2E实施的模型驱动集成方法还强调构建服务架构。这是通过定义结构化的服务组件和明确它们的在UML模型中部署配置来完成的。关键这能保证SOA(Statement of Applicability适用性声明)和EDA(Electronic Design Automation电子设计自动化)的维护性和管理性。图中展示了E2E Bridge平台的高层架构，如图2所示：（图片）
图2 E2E Bridge平台的高层架构 它包含了E2E服务器运行环境和插件。插件指的是可被运行环境加载和管理的任何组件。有两种重要的插件类型即前台服务和后台适配器。前台服务可以和应用不同协议，诸如：SOAP，SAP RFC或者HTTP(s)的客户端通信。后台适配器可以帮助接入不同类型的数据库、遗留系统，当然还有网络服务。运行环境也同时支持一些基础的功能，比如过程控制流，处理事件和执行行动脚本。
3 SAP接口技术在移动终端的应用分析
3．1需求分析
项目对象是一家从事餐饮设备现场维修的售后服务部门。部门业务已经在SAP上运行，但在项目实施前，仍有一系列的问题困扰着管理团队和服务工程师。
1) 由于售后维修地点分布在全国各地，所以对管理层很难做到对服务工程师的现场服务，以及对分配在服务工程师手中的零部件库存，进行实时有效的管理。
2) 由于服务区域地域跨度大，幅员辽阔。所以通常工程师手中完成的工单需要花费3周以上的时间，才能传回本部SAP系统内。
3．2系统设计目标
IT设计人员认为，可以通过移动终端的解决方案来保证SAP与移动终端的实时交互。这样就可以有效提高管理效率．优化服务流程以及提高库存准确度。通过项目的实施，可以同时帮助现场服务工程师以及他们的管理团队：
1)对于工程师而言：
a) 可以在手持移动终端PDA上实现日程管理
b)可以在手持移动终端PDA上查询实时的客户信息，零备件库存数量以及维修设备主数据。
c) 可以在手持移动终端PDA上看到实时分配的维修请求，服务工单以及历史维修记录。
d) 可以在手持移动终端PDA上创建服务工单，报价单并实时上传。
2) 对于管理层而言：
a) 可以监督管理服务工程师的维修日程安排和服务工单状态。
b) 可以在SAP中得到精确的库存管理信息。
c)可以得到实时的工程师KPI(Key Performance Indicator)报表。
3．3与SAP整合的系统架构
移动终端的开发是在EchoPlus平台上进行并完成的。通过E2E Bridge这个接口中间件，有效地整合了应用的前台通信和后台数据库。手持移动设备PDA通过无线的GPRS或者3G技术。可以做到和EchoPlus平台的实时同步，并最终将数据实现与SAP的交互。
4总结
接口技术是系统整合技术中的难点。尤其对于SAP这样庞大的集成性软件来讲，由于内在的复杂性和软件公司的商业保护目的。很少能找到公开的详细技术资料，即使有，也一般掌握在几家大的工业软件商手中。再加上本人的学术水平和实际经验的限制，所以本文仅仅提供和论述了一些SAP主流的接口技术和一款由此基础上开发的接口中间件和成功实施的商业案例。借此机会与大家共享，希望今后在此基础上有进一步的研究和提高。
6/12/2014
|
