如何写一份合格的SAP功能开发说明书--接口篇

原文链接：https://mp.weixin.qq.com/s/5gTO0MB5_pCrSCIy5vNMsg

大家可以关注我个人公众号，所有分享内容，会在公众号第一时间推送，且阅读排版更好。

愿大家的学习，轻松且愉快。

如果大家觉得有用，希望转发关注，谢谢

 

导读

 

系统接口，实际上就是实现系统间数据传输的常见功能，是企业信息系统间非常常见的功能。

 

本篇简单和大家聊聊接口的功能开发说明书，对业务顾问来说，应该如何合理表述，从而能保证需求被有效传递。

 

本篇所分享的内容，更多从技术理解和思路方法上，分享一点内容，并不会固定于某种格式，其实如果对接口技术有比较深刻的理解，无论什么格式，都能够完成一份开发能理解，且能有效交付的功能开发说明书。

 

希望对大家有所启发。

 

正文

 

在实际工作中，数据接口从业务要求到技术实现，再到数据流向等不同维度上去区分，会有各种各样的接口方式。

 

比如，按照，外部系统从SAP中提取数据，或者SAP系统给外部系统主动推送数据，或者SAP从其他外部系统获取数据后进行处理等等。

 

再比如，数据传输方式，可能是调用远程函数，文件传输，或者，采用中间数据库等方式进行的。

 

当然，如果按照业务上的功能实现来说，也有各种各样的功能要求，不同的数据传输触发点等。

 

基于各种各样的接口，作为业务顾问，我们在接到数据接口传输的需求后，要有能力设计合理的数据交互，进而满足业务需求。

 

1.接口结构设计

 

作为业务顾问，我们必须有能力根据对用户业务需求的分析，设计出接口的基本结构，为接口的实现做准备。

对于很多新手顾问来说，之所以经常难以完成对接口的设计，主要是缺少以接口实现的思维去分析业务需求的能力。

 

接下来，我们就结合一个简单的实例，从接口的数据流向、触发和处理这三个方面，去展示如何进行接口的分析。

 

业务举例：

 

假定，企业希望在SAP系统中做采购订单，在相应订单到货后，能够在企业的一个专用收货系统中收货，在此系统中完成收货后，SAP系统相应的采购订单，也将自动收货，避免用户需要出现两个系统都要收货的重复操作。

 

1.1.数据流向

 

根据业务需求，我们做一个初步分析：

 

a.参考采购订单的收货，是在外部的专用收货系统进行的，可是当SAP系统中采购订单被创建完成后，这个收货系统是没有采购订单的，所以，我们能首先确认的是：采购订单的信息，需要被传输到收货系统，这样，这个收货系统才能在到货后，有可参考的采购订单信息；

 

b.当到货后，在收货系统进行收货操作，并要SAP系统执行相应的收货动作，所以我们能确定：收货系统中的收货信息，需要传输到SAP系统中，进而SAP系统能够参考相应信息进行收货。

 

基于上述的简单分析，我们能够得出一个简单的数据流向：

 

 

仅仅这样的数据流向，是否能够满足实际业务需要？

 

采购订单信息从SAP系统，被传输到收货系统，我们如何保证数据被传输到了收货系统？假定，我们从SAP端做了传输操作以后，但因为各种各样的问题，收货系统没有收到数据，这样就造成了，SAP端有这个采购订单，收货系统没有这个采购订单的问题？

 

如何解决这个问题？总不能整天让采购部的操作员传输后，还得让收货部门的人检查一下数据到没到？

 

同样的问题，也会出现在收货操作上，收货系统收货了，但是SAP没有接到数据，没法收货，这样也会造成差异。

 

这种隐藏需求是用户不会专门给顾问去提的。但是作为业务顾问，必须要有能力注意到这些隐藏需求，或者要注意到这些通用的问题。

 

所以，我们在设计数据流向时，或者叫设计数据交互时，一定要注意：数据接收系统在接收到系统后，需要给数据发出系统反馈已接收的信息，数据发出系统在接收到反馈信息后，可以将已接收的反馈信息，及时地显示在发出系统中，进而相关发出数据的操作人员，也就能知道自己发出的数据已经被成功接收了。

 

结合这个需求，我们的数据交互就大致如下了：

 

当然，实际业务情况，就得根据不同情况而定。

上述这一部分，就可以理解为一个简单的接口架构（interface landscape）。

在接口的功能说明书中，接口架构，或者叫接口设计结构等，是非常重要的一部分，它能够清晰地说明接口的数据流向。

 

1.2.数据触发

当我们设计好了接口的数据流向基本结构，对于从SAP系统发出的数据，我们得分析具体的数据触发点，或者理解为接口数据会在哪一个操作中产生。

 

对于数据触发，一般来说可以简单地分为：自动触发和手动触发。

a.自动触发

 

当我们在SAP系统中完成某项操作时，系统将自动触发接口功能，将相应的数据从接口传输出去。

 

比如，结合之前的业务举例，采购订单需要被传输到收货系统，我们就可以设计自动触发。

 

假定，采购订单的流程是：ME21N创建采购订单，ME29N一级领导审批采购订单，ME29N二级领导审批采购订单。经过二级部门领导审批后，此采购订单会被发送给供应商。

 

如果我们要设置自动数据的触发点，很明显，我们需要设置在二级部门领导审批的位置，也就是要在二级部门领导使用ME29N审批时，设置增强点，当ME29N审批通过采购订单时，触发增强程序，将相应采购订单信息传输出去。

 

这里，就需要业务顾问按照写增强逻辑的方式，在功能开发说明书中，表达清楚数据传输触发的功能了。

 

 

b.手动触发

 

 

这类触发，是我们可以专门设置某一个功能，用户可以选定自己要发出去的数据，比如，当我们需要把一些物料、供应商、客户、成本中心等主数据，有选择地传输出去，我们就可以设计一个功能，选择需要的数据，用户可以执行传输等操作。

 

这个功能在功能开发说明书的表述，可以按照报表的方式，表达清楚筛选条件，以及数据展示界面，以及传输按钮的设计等。

 

还以上述业务举例，当二级领导ME29N审批后，我们不做自动传输，而是由采购员在手动触发的程序中，每天统一选择被审批通过的采购订单，点击传输执行操作，进而进行数据的传输。这种设计也是可能存在的。

 

 

实际项目中，多数需求为：上述两种传输方式均存在的需求。

 

结合上述举例，用户肯定希望自动化的程度高一点，当领导审批通过后系统自动传输数据。

 

但是，如果数据传输不成功，用户就需要重新再传输一遍，但采购订单已经被审批过了，原则上不能要求领导撤销后再审批一遍。

 

这时，就需要设计系统功能，能够支持用户将没有成功传输的数据再传输一遍。

 

如果用户进一步要求，或者需要更完善的功能设计时，我们可以设置SAP的后台作业。

 

在前面接口数据流向设计中，当数据传输出去以后，在没有收到对方系统的反馈时，认为数据没有被成功传输。

 

因此，我们完全可以在SAP系统中设置后台作业，让每天凌晨某个时间点，系统自动将已经发出的，但没有接到对方信息反馈信息的数据，通过手动触发的程序，再发送一遍。

 

一般设计到这种情况，几乎能够满足所有接口数据传输的触发情况了。

 

 

1.3.数据处理

 

当SAP作为数据的接收方系统时，我们就需要考虑对于接收数据的处理。

 

一般常见的处理方式：直接处理和先存储再处理。

 

a.直接处理

 

有时候，我们对系统间的数据一致性要求非常严格，比如在出库业务中，扫描枪扫描货物出库，扫描系统将数据传输给SAP，一般会要求SAP系统根据传输的数据，做了成功过账出库后，并将出库信息反馈给扫描系统后，才允许扫描系统这笔出库完成，实际货物可以出库，否则，如果SAP没有反馈出库成功，扫描系统也不能认为出库成功。

 

在这种情况下，就意味着，SAP系统提供相应的可调用函数，扫描系统调用SAP系统提供的函数，执行出库过账等操作。

 

如果接口这样设计，作为业务顾问，就需要写清楚调用函数的业务参数，并由SAP开发人员开发好相应函数给对方系统，用以发生业务时的调用。

 

结合我们之前的举例，我们采购订单收货的接口，SAP就是数据的接收方，如果为了保证数据的绝对一致，也可以设置此方式。

 

 

b.先存储，再处理

 

 

有时候为了保证系统的处理业务的及时性，和系统一定程度上的独立性，当我们不希望数据的发出方系统，不收系统接收方数据的影响时，会建议数据接收方系统，先将受到的数据存起来即可，后续系统的接收方自行处理。

 

还是以之前的业务举例，当收货系统做了收货以后，将数据传输给SAP，SAP系统可以先将数据存储在自建表中，之后按照顺序逐一进行收货的操作。

 

这种先存储再处理的方式，可以直接将数据存储在自定义表中，如果接口是文件传输的模式，可以直接存储中间文件。

 

如果是这种方式，我们在写功能开发说明书的时候，就需要设计相应的自定义表，以及相应的程序读取自定义表中的数据，进行相应的系统操作。这个功能可能是ALV报表格式+调用业务处理的函数（BDC程序）等的执行。

 

还要注意，这种接口数据的处理方式，需要小心数据的不一致性，比如，当外部系统做了出库，传输相应数据给SAP，SAP系统只是存了起来，还没有做出库的操作，但外部系统默认已经出库成功，并且已经按照之后的业务流程进行了，此时，当SAP利用传输的数据出库时，发现数据有问题，无法出库，这个时候就会出现同一笔业务，在不同系统中的业务状态不一致，数据不一致等问题。

 

 

2.接口数据设计

 

接口数据的设计，其实我们可以理解为哪些数据需要通过接口被传输出去。

比如，上述举例中，采购订单的传输，假定在收货系统中扫描收货时，需要校验这批货物的供应商ID，物料编号，供货数量，以及送货日期，是否与原采购订单上的信息一致，如果一致才能收货。

 

如果是这种情况，这个采购订单信息的传输接口至少包含：采购订单号、行项目号、供应商号、物料号、采购数量、到货日期等基本信息。

 

在接口数据设计的信息中，我们需要将每个要传输的字段类型、长度、字段说明等信息罗列清楚。

下图只是一个简单举例，实际业务中，说明的内容要非常详细。

 

如果是中间文件的接口方式，我们需要清楚地说明文件格式，文件中每个字段的具体作用等。从而确保信息能够被有效地传递给开发人员，开发人员就能够根据文档信息生成相应格式的数据文件，或者根据相应格式解析对方系统传输过来的数据文件。

 

3.接口技术实现

 

系统接口的实现，这里就不做进一步的解释了，大家可以参考以下内容。

 

 

当我们能够对结合系统接口的设计逻辑，对用户的接口业务需求进行合理分析，并按照上述的核心内容形成相应文档，基本上就能将自己的思路有效地传递给开发，以及相应的接口系统。

 

多数项目中，也有专门的文档：接口协议（interface contract），用于管理接口设计中，主要和外部系统相关的部分，这类文档主要包含了：接口的基本架构，数据流向，以及系统间的字段对应关系等。