SAP接口设计的扩展性考虑
2013-07-10 17:36
381 查看
由于现在的系统和SAP的接口出现了几次变更,因此需要对系统进行设计改造。由于系统中和SAP交互的接口不止一处,而且也是在不同的时间段进行开发,并由不同的人员来完成的,因此我在维护升级的过程中,发现了以前设计的
可借鉴之处和缺点。
首先是财务对账接口的修改,由于需要在SAP中查看报表中多增加几个字段,本来应该是很容易搞定的事情,但是我查看了下接口的代码和配置文件发现,这个居然要更改接口的代码。本来可以通过配置搞定的事情一下就变复杂了。
接口代码还是用VS2003开发的,因为以前是使用的.net中自带的SAP .NET Connector 2.0进行开发的,还得在VS2003中进行修改,但是现在已经是2013年了,想安装下VS2003还真不容易,只好找了个虚拟机来进行安装开发环境,安装完毕后再进行开发。经过一番折腾总算大工告成。也通过了测试,并在后面验证完毕后顺利上线。在修改接口的过程中对设计进行了反思,找出了几个值得修改的地方。首先对于从SAP中取数,尽量将SAP能够提供的并且考虑以后可能用到的数据都取过来,比如SAP提供的一个表有30个字段,但是我们只用18个,先不管,全部取过来,根据实际需求将需要用到的数据字段写在配置文件中,这样下次比如需要增加字段,如果现有接口可以满足需求,直接放开即可,在配置文件中增加字段即可满足需求,也不用进行代码方面的修改。
同时将需要进行交互的功能模块独立的分开,并且对于这些独立交互的模块用配置项配置是否进行传输交互,如果以后那一天那些数据模块不需要进行交互了,直接将配置更改下就可以了。比如新旧产品数据关联关系不需要再进行同步更新了,那就这个独立的通过模块设置改变下即可。也不用动代码了。
如此一来系统的灵活性就大大提高了。
可借鉴之处和缺点。
首先是财务对账接口的修改,由于需要在SAP中查看报表中多增加几个字段,本来应该是很容易搞定的事情,但是我查看了下接口的代码和配置文件发现,这个居然要更改接口的代码。本来可以通过配置搞定的事情一下就变复杂了。
接口代码还是用VS2003开发的,因为以前是使用的.net中自带的SAP .NET Connector 2.0进行开发的,还得在VS2003中进行修改,但是现在已经是2013年了,想安装下VS2003还真不容易,只好找了个虚拟机来进行安装开发环境,安装完毕后再进行开发。经过一番折腾总算大工告成。也通过了测试,并在后面验证完毕后顺利上线。在修改接口的过程中对设计进行了反思,找出了几个值得修改的地方。首先对于从SAP中取数,尽量将SAP能够提供的并且考虑以后可能用到的数据都取过来,比如SAP提供的一个表有30个字段,但是我们只用18个,先不管,全部取过来,根据实际需求将需要用到的数据字段写在配置文件中,这样下次比如需要增加字段,如果现有接口可以满足需求,直接放开即可,在配置文件中增加字段即可满足需求,也不用进行代码方面的修改。
同时将需要进行交互的功能模块独立的分开,并且对于这些独立交互的模块用配置项配置是否进行传输交互,如果以后那一天那些数据模块不需要进行交互了,直接将配置更改下就可以了。比如新旧产品数据关联关系不需要再进行同步更新了,那就这个独立的通过模块设置改变下即可。也不用动代码了。
如此一来系统的灵活性就大大提高了。
相关文章推荐
- SAP接口设计的扩展性考虑
- 组件接口(API)设计指南[1]-要考虑的问题
- 工作流实施中FlowPortal.net对于表单设计易用性和可扩展性的考虑
- 很多时候在考虑设计而不是考虑编码的时候, 接口才真正清晰,明朗的把它的原理展现给你。
- 抽象类及接口在设计时考虑的如何选择问题
- 接口设计:以数据为中心,从需求和变化的角度考虑
- 【Yom框架】漫谈个人框架的设计之二:新的IRepository接口+搜索和排序解耦(+基于Castle实现)
- 浅谈 Java 8 接口默认方法和静态方法的设计
- 组件接口(API)设计指南-目录
- 面向对象设计中抽象类与接口的区别
- 用户接口设计三 队列
- Python基础-接口与归一化设计、抽象类、继承顺序、子类调用父类,多态与多态性
- 如何设计接口
- 要如何判断应该是设计类、子类、抽象类或接口
- 【软件架构】软件架构设计需要考虑的几点
- 串行接口SPI接口应用设计
- RESTful设计原则和样例(开发前后台接口)
- 在SAP中设计自动刷新的报表代码 (又一例)
- 设计引导--一个鸭子游戏引发的设计理念(多态,继承,抽象,接口,策略者模式)
- C语言的设计模式-接口隔离