前言:
归纳总结是个好习惯,我们都值得拥有.
每一个业务的开发需求,都是一次归纳的契机.
根据业务特定的需求分析,是否可以概括出一个通用需求?
特定业务需求是否完全包含在这个通用需求中呢?
是否可以根据这个通用需求概括出一个通用处理模型?
该模型是否可以解决这一类的业务需求?
怎么用特定的语言(ABAP)开发这个模型?
怎么给业务最大的自由度去使用这个配置使用这个模型?
如果你是一个业务人员,带着这些问题去和你的开发沟通.(你毛病呀,半天就可以写完的程序,你想整一周?)
如果你是一个开发人员,带着这些问题去和需求提出者沟通(你找事呀,按我的需求做就完事了,要不你来写功能说明书?)
或者,你也会碰到志同道合的. 嗯,这个提议不错, 咱们一起来完善一下这个设计.
尝试更多的去理解业务,去归纳业务,用开发的思想去重建功能设计.
接口框架(通过PI/PO)-PI/PO:SAP接口中间件,后文通常PO
接口是每个项目必须的开发,并且随着外围系统分化SAP的一些周边功能,会增加更多的接口开发需求.
接口开发的特性需要区分同步/异步,出站/入站来说明
同步接口:在调用的同时,返回结果.适用于业务集成度高,或者仅仅界面化设计的外围系统(不保存数据),同步接口因为处理过程相对简单,不在本文讨论范畴
异步接口:推送数据,获取一个推送成功的标记.(适用于业务集成度不高,有完整数据记录的外围系统)
出站接口: 源数据存在与SAP中, 从SAP发出到外围系统
入站接口: 源数据存在与外围系统,发往SAP系统.
异步接口的共性归纳:
需要记录每次调用信息
需要能够查询每次调用的明细内容
需要额外记录传递的单号,以便执行单据的核对
异步出站接口程序的共性归纳:
标记传输的数据
记录传输的日志(调用PO的结果)
获取PO的反馈(PO调用对方端口后的反馈信息)
异步入站的接口程序的共性归纳:
记录获取的数据
执行获取的数据产生单据
报错的单据重新执行处理
备注:上述归纳仅仅是对接口的一个初步笼统粗浅的分析
基于上述共性的归纳,形成如下的接口框架:
主数据/业务单据保存时的接口匹配(可配置的下传过滤)
下传程序代码生成器(通过配置生成下传程序)
上传接口应用IDOC实现数据的记录,处理,错误再处理
集中的调用日志监控 ZIFLOG(可以查看PO消息内容, 获取PO响应,集成RFC调用内容查看等)
集中的IDOC处理监控 ZIFIDOC(IDOC报错信息汇总,内容显示,产生的单据显示,重处理,状态调整,报错信息知识库功能等)
接口核对机制 ZIF_COMPARE
接口框架尝试整合接口的开发/监控/数据核对等环节,给出更便利的方式去整体把控接口开发的各个环节,在一些项目上的应用证明了它的价值.
SAP开发框架系列是我对开篇前言中问题的解答,这个系列提供的是一种思维方式,有些涉及到的代码/工具,会在后续文章中陆续发布.
