外部接口需求_如何写一份合格的SAP功能开发说明书接口篇

作者：kerwinG(网名)

声明：本文章仅代表原作者观点，仅用于SAP软件的应用与学习，不代表SAP公司和本微信公众号。注：文中所示截图来源SAP软件，相应著作权归SAP所有。

导读   系统接口，实际上就是实现系统间数据传输的功能，是企业信息系统间非常常见的功能。   本篇，就简单和大家聊聊接口的功能开发说明书，对业务顾问来说，应该如何分析接口、如何合理表述，从而能保证需求被有效传递。   本篇所分享的内容，更多从技术理解和思路方法上，分享一点内容，并不会固定于某种格式，其实如果对接口技术有比较深刻的理解，无论什么格式，都能够完成一份开发能理解，且能有效交付的功能开发说明书。   如有不合理之处，还请大家指正。希望分享内容对大家有一些作用。 正文   在实际工作中，数据接口从业务要求到技术实现，再到数据流向等不同维度上去区分，会有各种各样的接口方式。   比如，按照，外部系统从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.接口技术实现   系统接口的实现方式，这里就不做进一步的解释了，大家可以参考之前文章进行理解。 常见的系统间接口方式(01)-远程函数调用 常见的系统间接口方式(02)- 中间件的数据接口模式 常见的系统间接口方式(03)- 文件传输的系统接口模式 4.总结 当我们能够对结合系统接口的设计逻辑，对用户的接口业务需求进行合理分析，并按照上述的核心内容形成相应文档，基本上就能将自己的思路有效地传递给开发，以及相应的接口系统。   多数项目中，也有专门的文档：接口协议(interface contract)，用于管理接口设计中，主要和外部系统相关的部分，这类文档主要包含了：接口的基本架构，数据流向，以及系统间的字段对应关系等。

分享是一种精神