（01）-远程函数调用

所谓系统接口，实际上就是不同系统间的数据交换方式。

对于一个企业来说，肯定不是一个系统就能够支持所有业务的运转，几乎所有企业都会使用多个系统，比如较为常见的ERP/MES等。

当企业有多个系统支持其业务时，不同系统间的数据交互就不可避免了。比如，MES作为生产执行系统，在MES中所执行的原材料投料、产成品入库出库等，必然会将相应的数据传输至ERP系统，保证ERP系统中同时进行原材料、成品的货物移动等。

除了企业的内部系统会发生数据交互外，还可能存在不同企业间的系统数据交互。比如，企业可能会将未来的物料需求预测，传输给其下游供应商，供应商接到预测后，会进行生产备货等等。当然，还有很多企业其需要与银行有很多系统接口，比如自动付款等相关业务。

基于企业中的系统接口，我们将主要分享常见的三类系统接口方式，以帮助大家能够理解其工作原理。

三类常见的接口方式，包括：

1.系统间采用远程函数调用（RFC）的方式进行数据交互；

2.系统间采用中间数据库的方式进行数据交互；

3.系统间采用传输文件的方式进行数据交互；

本篇，我们先介绍“远程函数调用（RFC）”的工作原理。

正文

远程函数调用（Remote Function Call）：实际上就是一个系统提供可供其他系统调用的函数，当其他系统传输正确的参数并调用相应函数，则可以在该系统中执行相应的系统功能。这就是最为常见的，使用远程函数调用的系统接口方式。

系统间数据交互的目的，就是一个系统中的功能执行结果，以数据的形式被被传输到另外一个系统，并在利用此结果数据，在另外这个系统中执行相应的系统功能。

远程函数调用（RFC）这种接口模式，就是数据会直接传输相应系统，并在此系统中直接执行系统功能。

我们可以形象的理解为，被调用的系统A，将其系统的账号和密码交给了外部系统B，外部系统B在必要时，会登陆到A系统中，用系统B中的正确参数，也就是数据，去执行A系统中的系统功能。如下图所示。

看到这里，其实，对于很多初级业务顾问来说，理解上可能还有一定困难。那么，我们就模拟一个最简单的业务场景，用以分析“远程函数调用”的工作原理。

假定，某企业的采购员使用SAP系统做业务，而其部门经理会使用另一个审批系统，比如常见的自动办公OA系统，实现对采购员的业务的审批操作。

那么此模拟场景下，其可能出现的实际业务如下：

1.采购员在SAP系统中，创建一个张采购订单，并成功保存，其采购订单号为“123”；

2.采购员在审批系统（OA）中，使用发起审批功能，填入采购订单号“123”，确认发起审批。此时，OA系统中会显示SAP系统中单号“123”的相关信息，包括物料编号、物料名称、采购数量、价格等；

3.当采购员发起审批后，部门经理就能在OA系统中，看到此审批流程，并看到采购订单号“123”，以及所有此次采购业务的信息；

4. 此时，部门经理会在OA系统中执行审批通过，OA系统在SAP系统对订单号“123”完成审批后，会给部门经理显示“批准通过执行成功”；

请问在以上业务中，系统间的接口工作机制是什么样的？

首先，有采购数据的抽取接口，执行逻辑如下：

OA系统会给SAP传输“订单号”这一参数，同时调用SAP系统中的采购数据获取函数，SAP系统会将采购订单的相应信息反馈给审批系统；

其次，有采购订单的审批接口，执行逻辑如下：

当部门经理执行审批通过后，审批系统会将“订单号”和“审批通过”这两个参数，传输给SAP系统，并调用SAP系统中的审批函数批准此单号，并将审批成功的结果反馈给审批系统。

具体逻辑如下图所示：

这里我们可以思考以下，OA系统为什么一定要在接到SAP系统将审批成功的结果后，才给部门经理显示审批成功？

OA系统为什么不直接在部门经理执行审批功能后，就直接显示审批成功？OA系统的审批参数已经发出去了，何必要等SAP的反馈呢？

其实，这里就是我们在设计系统接口时，要注意的关键点。多个系统接口的协作，不同于单个系统的功能执行。

以上述业务为例，在单个系统中，如果审批程序执行不成功，系统会立刻根据程序执行结果，告诉你程序执行不成功。可能的原因是，业务单据被锁定，或者相关后台表被锁定等。

在多个系统的协作时，A系统把参数传输给B系统，并调用B系统中的函数，如果此时A系统，直接给使用者显示执行成功，就有可能造成B系统实际的功能并未执行成功，而A系统却告诉使用者已经成功了。

如上述业务场景，OA系统虽然把审批通过的参数传输给了SAP系统，并调用SAP所提供的函数接口，SAP系统很有可能会因为单据锁定等原因，程序无法执行成功，但OA系统如果此时认为审批成功，就会出现问题了。

基于上述内容，我们已经了解了“远程调用函数（RFC）”接口的基本工作原理。

其实，除了SAP系统，几乎所有系统都对会外提供类似“远程调用函数（RFC）”的接口方式。

当然，基于上述介绍，我们也就理解了为什么这种函数，会被称为“远程调用函数（RFC）”了。

因为这类函数主要用以其他外部系统进行调用，外部系统的调用，也叫远程调用，所以我们常称可以供外部调用的函数为：“远程调用函数（RFC）”。当然，这类函数除了可以被外部系统调用，自己系统也可以调用。

这里我们在介绍以下BAPI的概念。在SAP系统中，有很多已经封装好的，可以直接使用的远程调用函数，SAP称其为“BAPI（business application programming interface）”具体可以参考，其他两篇公众号文章。

对于很多非SAP技术相关的朋友，都很了解API，而BAPI无非就是多了个business，就是SAP为其业务定义的API。

远程函数调用这种接口方式，常用于业务简单，接口系统较少、接口业务点对点的业务类型。

但实际业务中，支持企业业务运转的系统，可能会有数个、数十个，甚至数百个。

如果所有系统接口都用远程调用的方式是肯定行不通的。

（02）-中间件的数据接口模式

中间件的数据接口模式，也会被称为中间数据库的数据交互模式，或者叫数据平台的数据交互，总的来说，就是在各个业务系统间，建立一个独立的数据库，保证系统间的数据交互，或者叫数据接口。

为什么要使用中间数据库的接口模式？

对于很多企业来说，经常需要多个业务系统支持。如果采用系统间相互的函数调用模式，会导致接口过多，难以管理。基于此情况，多数企业会选择采用中间数据库，以满足多个系统间的数据流转。

企业很多时候不愿意大规模采用RFC调用的接口模式，常基于且不限于以下几个原因：

1.很明显，基于上图中只有5个系统，但其接口的复杂性已经较高了。对于企业来说类似上图中的接口模式，是不易管理的。而且，实际业务中，少有规模的企业，都存在多个系统，并且各个系统之间接口业务不一样。在类似此种情况下，当企业的接口较多时，如果均采用点对点的相互调用接口，对接口以后的维护成本会很大。随着业务发展，很有可能最后谁也不知道某个接口的是否被使用，或者某个接口到底如何被使用。

2.点对点的RFC调用接口，必须要求接口两端的功能均可用，这就有可能会影响业务的及时性。比如，常见的生产管理系统，一般其业务及时性要求很高，生产上发生一笔业务，通过RFC调用传输给ERP，但是ERP系统可能因为财务账期、其他程序锁表等，导致RFC接口无法立刻被调用成功。但生产管理系统又不可能一直等待ERP系统的执行，这样就会出现难以调和的矛盾。

3.其实，很多时候，基于数据安全、信息安全等多方面的考虑，很多系统并不愿意给其他调用自己系统功能的权限，这样也就限制了RFC接口模式的使用。

基于上述弊端，企业为了降低系统接口统一管理的难度，以及接口后期的维护成本，结合从安全及业务及时性等角度的综合考虑，一般会采取建立中间数据库的接口方式。

那么，中间数据库接口模式的工作机制是什么？

如果两个业务系统，采用建立中间数据库的模式进行数据交互，其工作原理可以简单理解为：

首先，会部署一个专门的数据库或者数据系统，也有称为数据平台等，实际上，就是个专门用于存储系统间交互数据的数据库。

业务系统不会直接将要传输的数据，传输给其他业务系统，而是会传输给这个中间的数据库，要使用数据的业务系统，会主动去中间数据库取自己需要的数据。

如下图所示，A系统会将数据写入至中间数据库，B系统会取中间数据库去取需要的数据，反之亦然。

采取中间数据库接口的方式，在实际使用中，一般是存在多个系统之间有数据交互的业务情况，如下图所示。

基于下图，我们对比之前多系统接口采取RFC方式的图例，我们很容易看出来，采取中间数据库接口的交互方式，其接口更加容易管理，且交互方式更加安全。

当然，采用中间数据库的接口方式，其弊端也比较明显，可能会导致一些常见问题，比如：

1. 数据接受的系统，不能够及时处理数据，不能够在第一时间验证数据的业务及系统层面的准确性。

很有可能出现，传输数据的系统将数据写入中间数据库，但是，需要接受数据的系统，在中间数据库读取数据时，发现数据有问题，并无法正常使用。

此种情况，作为接收数据的系统，很难在第一时间对数据进行管控和校验。

比如，我曾在项目中遇到过一个情况，某企业针对SAP系统与MES系统的所有接口，采取了中间数据库的接口模式。当发生原材料领用的业务时，首先，MES系统出库过账，进而将数据传输给中间数据库，SAP系统会取中间数据库的数据，完成过账。但是，实际执行中，某物料的库存只有10个，MES系统中的程序计算错误，显示库存有12个，用户执行领用12个，且在MES系统中领用成功。此时，当领用12个的数据传输给SAP，由于SAP中的库存数量只有10个，无法针对领用量12进行过账，最终出现问题。

基于这一案例，如果我们采取的是RFC的接口模式，一旦领用数量大于库存数量，在SAP端就无法过账，直接就反馈给MES了，但是，采用中间数据的接口方式，其校验就会比较滞后，容易产生问题。

2.接受数据的系统，什么时候去数据库取数据；

其实，基于列举的第一个问题，我们不难看出，中间数据库的接口模式，对于数据接收方的系统来说，有一个问题：应该在什么时候去取数据？

因为基于上述工作机制，数据发送方的系统在给中间数据库写入数据时，数据接收方的系统并不知道。

所以，我们常见的处理方式就是定义自动的系统后台Job，也有的系统会称为后台timer。

简言之，我们就会在系统中定义一个程序，每个一段时间自动去中间数据库取一次。根据业务的及时性要求不同，我们可以定义不同的时间段，比如每十分钟取一次，或者每小时取一次，或者每天取一次等。

采取自动后台Job的方式，可能带来的问题，也比较明显：数据发出方的系统，在某天只写入了三次数据，如果数据接收方定义每小时取一次，那么，实际取数据的次数是24次，对于系统服务器来说，为了3次数据，却需要执行24次程序，这就有些占用服务器资源了。

对于一些业务较多、系统交互较多的企业，排程系统后台Job就变成了一项非常重要的工作。这要基于业务要求本身，系统程序大小等因素，去决定job的执行频率及执行顺序。

比如，实际情况中，很多取数程序的本身必须有先后顺序，必须得先取某数据，才能取其他数据；有的程序太大、所取数据太多，就不能排在工作时间去取数，因为其很有可能占用过多服务器资源，导致其他业务难以顺利执行，所以，一般此类Job，会被安排在凌晨执行，等等。

3.鸡蛋被放在了一个篮子里。

基于中间数据库的接口模式，我们很容易就能看出来，如果过于集中地使用中间数据库或者数据平台等，意味着我们把核心数据都放在了一个数据库中。如果这个数据库出现问题，就有可能大面积影响相关系统的正常运转。基于这种情况，如果采取中间数据库的方式，其系统安全策略及相关灾备系统等的措施，就非常重要了。

4.非企业本身的外部系统，如果需要与企业自己的系统进行数据交互，那么，基于安全层面的考虑，不会建议外部企业的系统直接访问内部数据库。

那么，如果外部系统与企业内部系统有数据交互需求的话，应该采用哪种方式呢？

（03）- 文件传输的系统接口模式

我们在上一篇内容中，简单介绍了中间数据库的交互模式。

其中，我们提到：如果其他外部公司要与自己企业内部的系统有数据接口，且为了保证安全，不给外部公司访问我们自己数据库的权限，在这种情况下，我们应该以何种方式做系统的数据交互接口呢？

本篇，我们简单介绍一下：利用文件传输进行数据交互的接口模式。

正文

一、基本工作原理

文件传输的数据交互接口模式，顾名思义，其数据的交互是以文件为载体的，可以理解为：数据发送方的系统将数据写入到一个文件上，再将文件传输给数据接受的方系统；数据接收方系统将读取文件中所承载的数据，并根据数据执行相应的系统功能，从而实现系统间数据交互的目的。

这种交互会有效地避免系统之间的函数调用，以及系统之间需要相互访问数据库等，为各个系统的独立安全，从接口架构设计的层面，提供了保障。

这种模式，我们可以简单且形象地理解为：小明同学在上课时间给班里的小白同学递纸条。其中，小明和小白分别是不同的业务系统，而纸条就是这里的文件了。

文件传输接口中，常使用的文件格式有哪些？

常见接口的系统传输文件，主要有：SAP系统中标准的IDOC文件，XML文件、Json文件、EDI文件，有的企业有时候也会直接使用：Excel文件、TXT文件等等。

当我们确定了系统间的文件格式，接下来需要确认文件中业务字段的生成和解析规则，同时，定义每一个字段的长度、数据类型等等。

 

二、文件传输接口的常用系统架构设计

1.业务系统--业务系统

如下图所示，系统A将业务数据按照约定规则生成数据文件，存储在自己的服务器上。之后，将文件传输给系统B，系统B在接到系统A的文件后，先将文件存储至自己的服务器上，再针对数据进行解析与使用。

2.业务系统--文件存储服务器--业务系统

如下图所示，有时候为了保证文件传输接口的统一管理，会专门在业务系统间设置一个专门的服务器，用于文件的存取。

当然下图只展示了两个系统的文件交互，其实，有些时候，在文件存储系统中，会根据不同的业务情况，以及系统交互情况，对所有文件通过文件夹管理起来，这样就能支持多系统、多业务的文件传输接口。

3.业务系统--文件存储系统----文件存储系统--业务系统

前文中，我们专门提到不同企业间的系统接口方案，是可以基于文件传输接口进行设计的，此种方式能够很好地保证各自企业系统及服务器独立安全。

4.文件传输协议：

文件的传输，必然有很多传输规定方式和技术通信规则。不同业务系统间，如果有接口业务，文件传输协议的选择，是接口建立的基础。有了相同的传输协议，才能有共同的接口规则。

我们简单从应用层列举一下传输协议的使用目的：

文件的加密方式需要被定义：

比如，为了保证数据安全，所传输的文件需要加密，那么双方业务系统在生成和解析文件时，就得具备相同的加密方式；

文件的交互机制需要被定义：

比如，需要定义具体的交互方式，保证的数据文件不会丢失或重复等。

假定，当系统A将文件发送给系统B，为保证系统间的文件交互不会丢失或重复等，

常见的处理方式：当系统A把文件发出后，系统B接到此文件后，会给系统A一个回执消息，当系统A接受到此消息，就认为系统B已经成功接到文件，将不在发送文件了，否则会持续多次尝试发送文件等。

当然，还有的接口就设置的比较简单，当系统A文件发出后，系统A就默认系统B已经成功接收到文件，并不在做发送，或者直接理解为系统A只发送一次文件；在这种情况下，一旦系统B发现并未收到A的数据，会给系统A发起重新发送的申请等。

类似以上这类，文件接口交互中的传输握手协议等方式，都可以所选择的传输协议，进行不同程度上的定义和选择。

除此之外，还有很多通信技术层面的协议规定，都可以根据传输协议的选择而定。

我们常见的传输协议有：FTP/FTPS/OFTP/OFTP2.0/AS2/SFTP等等

通信协议的采用与连接方式有关等。

三、EDI技术的应用简述

EDI（Electronic Data Interchange）数据交互标准的应用，是文件传输接口广泛应用的典型代表。

电子数据交换(EDI) 是结构化的数据通过一定标准的报文格式，从一个应用系统到另一个应用系统的电子化的交换，电子数据交换将人为干预降到最小化。一个EDI系统通过内部系统给贸易伙伴系统发送数据只需几秒钟的时间。

为了保证企业间的数据交互规则统一，所以在欧洲、美国等地区，均有统一的基于EDI技术的商用标准。

目前，EDI解决方案在整车企业以及其供应链企业中，在很多贸易行业、运输行业、银行等行业中已得到广泛使用。

为支持不同企业的EDI技术应用，市面上已经有很多公司有其自己的产品和解决方案，而且也有很多专业的EDI顾问及相关技术人员，保证EDI技术支持下的文件传输接口方案的广泛应用。