购购乐电子商务平台总集成设计说明书.doc

购够乐电子商务平台

总集成设计说明书

2023年7月

更改记录
日期
修改
类型
修改描述
修改人
版本

*修改类型分为 A – 新建 M – 修改 D – 删除

目 录
1. 引言 4
1.1 编写目的 4
2. 项目简介 5
2.1 项目背景 5
2.2 项目目的 5
2.3 业务需求描述 5
3. 系统集成方案设计 7
3.1 设计原则 7
3.2 总体建设框架 8
3.3 集成方式选择 12
3.3.1 数据级整合 13
3.3.2 用户界面级整合 14
3.3.3 应用程序级整合 14
3.3.4 方法级整合 14
3.4 集成技术选择 15
3.4.1 ETL技术（数据级整合） 15
3.4.2 数据库共享技术（数据级整合） 15
3.4.3 Web Service（应用程序级整合） 15
3.4.4 JavaBean组件技术（应用程序级整合） 16
3.5 具体集成方案设计 16
4. 结语 17
4.1 结语 17

1. 引言
1.1 编写目的
本文档的编写目的，是为项目管理人员充足理解本项目的系统设计方案而设立的。它描述了作为电子商务的主控制平台架构设计、方案拟定、风险评估等。本文档将作为后期系统开发和测试的重要依据。
本文档的预期读者为主管项目相关人员（决策者和管理者）。

2. 项目简介
2.1 项目背景

2.2 项目目的
本系统的建设目的是运用计算机和网络等先进技术，建成一个符合安全保密规定、体系结构合理、系统功能完整，符合购够乐平台工作特点的“电子商务应用支撑平台和信息资源整合工作”。在此基础上建设完毕“数据对接管理、内容协调管理、每日分发管理、资源分类管理、系统验证管理”，完毕现有各个系统之间互联互通，形成现有项目一体化，实现购够乐电子商务平台核心业务100％的信息化支撑。
2.3 业务需求描述
购够乐集成系统重要工作任务是将前端客服人员与库管员、物流配送人员及财务人员做无缝对接，剔除纸质办公人工成本，做到数据及时统一，容错机制极高，互相之间完善工作模式等。
购够乐电子商务平台整合项目重要面向以下系统：
Ø 前端业务系统
Ø 库管系统
Ø 物流配送系统
Ø 财务系统/SAP
具体的业务需求如下：
(1) 前台业务系统与库管系统间交互的需求

(2) 库管系统与物流配送系统交互的需求

(3) 库管系统与财务系统交互的需求

(4) 物流配送系统与财务系统交互的需求

(5) 前台业务系统与财务系统互联互通的需求

图表 21总体业务需求
3. 系统集成方案设计
3.1 设计原则
购够乐整合项目的设计需要遵从以下原则：
安全保密性原则
系统应能提供网络层的安全手段防止外部的非法入侵及内部操作人员的越级操作；系统在硬件、网络、数据库和数据、应用操作权限和身份认证方面，加载全面的安全措施。
可靠性原则
系统能有效的避免单点失败，在设备选择和互联时提供充足的冗余备份，由于是不同系统不同平台不同语言之间的系统级操作，切实保证各系统间的联合事务稳定性。
经济实用原则
以现行需求为基础，充足考虑发展的需要来拟定系统规模。功能模块子系统以插件的方式扩展。系统应突出实用，要让系统的投资与实际需求相符合。
可管理性原则
系统设备易于管理、维护，操作简朴，便于配置，在安全性、数据流量、性能等方面能得到很好的监视和控制，可以进行远程管理和故障诊断。
先进性原则
系统的结构设计、配置、管理方式在经济实用的同时，尽量采用先进技术，延长系统的生命周期。
开放兼容性原则
系统开放性好、标准化限度高，可以保证以往系统建设的投资，以及后续建设项目的兼容性。
可扩展性原则
系统设备不仅满足当前需要，并在扩充模块后满足可预见将来需要；保证系统平台建设完毕后在向新技术升级时能保护现有投资。
先易后难、阶段实行的原则
最大限度的减少投资风险，提高系统运用率。
保护现有投资原则
充足运用已有设备和系统， 实现已有数据的运用和保护以及工作人员知识的运用。
技术成熟性原则
在系统的软硬件方面，充足考虑采用国内外通用的，成熟的软硬件产品进行开发，保证系统功能的高效稳定。
技术统一性原则
整体系统的软件平台均采用J2EE软件平台进行设计，实现软件平台的同一性。
3.2 总体建设框架
框架建设涉及两种主线限制，一种是四个原有业务系统可以修改源程序，互相之间对外提供客户接口进行对接。假如原有业务系统可以做到这点，附加中间数据仓库中转系统，为业务系统间提供对接和整理内容服务，跟踪订单状态，就可以将几个系统间无缝整合；一种是原有业务系统间无法对外提供任何API或客户接口,这种情况数据级整合是唯一的选择，这一种存在数据外漏给中转系统及中转系统的权利过大的风险，这种方式需要采用严格的加密措施和验证措施，并且采用应用分层手段来避免安全隐患。
根据购够乐实际需求和建设特点，购够乐综合控制平台建设内容从业务上包含了前端业务系统、库管系统、物流配送系统、财务系统/SAP四大业务应用系统；从技术上四大业务系统中有可以提取出的通用模块或者组件，涉及统一用户管理、集成服务、报表服务、消息服务等，需要建设统一的应用支撑平台；从信息资源上需要对各种业务数据、互换数据进行信息资源整合；从管理上需要建设配套的标准规范体系、安全保障体系和维护支持体系。
总之，无论购够乐业务系统现状如何，主角都是订单状态。我们的方案是以订单状态为中心，订单在不同的状态下拥有不同的功能操作，不同的操作为订单附加相关属性且修改订单状态。
购够乐综合控制平台建设的总体建设框架如下：

图表 31 总体建设框架

图表 32 总体建设流程图

总体设计说明：
购够乐平台原有四个系统，现在将新建一个综合控制系统。假如现役系统没有维护人员，不能对外提供API用户接口的话，那么对库存系统，配送系统，财务系统包装外衣应用，外衣应用仅仅针对性开发系统间交互需要的接口服务。外衣应用的作用是，既不影响原有系统的使用，又可以顺利与其他系统进行接口对接。外衣应用之间的交互必须通过综合控制系统这个门户来交互。
整个过程控制如下：
1. 综控系统无论以何种方式（数据推送或数据对接）从前端业务系统获取订单信息
2. 综控系统与库存系统外衣应用进行交互获取库存信息
3. 综控系统根据库存系统反馈向配送系统外衣应用交付订单，修改订单状态
4. 配送系统外衣应用反馈给综控系统配送情况，修改订单状态
5. 综控系统根据配送系统外衣应用进行库存操作及修改订单状态和附加配送信息
6. 综控系统根据订单状态与财务系统外衣应用进行交互，财务结算，修改订单状态
3.3 集成方式选择
目前购够乐原有应用系统分布在不同平台上的，用不同的语言开发，系统集成工作难度非常大。原有应用系统整合面临的问题是不同的应用系统使用的技术是多种多样的，要实现在这些基于不同的软件技术构建的系统之间进行数据的交互，信息的互换必须解决两方面的问题：第一，数据格式的一致性。第二，相应用进行整合。
与原有信息系统集成方案将采用基于应用支撑平台的EAI (Enterprise Application Integration即公司应用集成)方式来实现。
EAI有四种集成方式：数据级整合、用户界面级整合、应用程序级整合、方法级整合。

3.3.1 数据级整合
数据集成解决数据的共享问题，使数据得到更广泛的应用，特别是数据的综合应用。在此基础上，随着应用的进一步发展，还可以建立面向主题的数据仓库应用等。数据的规范化和标准化是数据集成的基础。考虑到各相关单位之间采用技术的差异性，以及平台的异构性，将XML作为统一的数据报文格式。
数据集成的目的是形成统一的数据视图。最为重要的一点是数据模型在逻辑上必须统一，而在物理上可以分布存储，通过周期性地同步各数据库的数据来实现数据的一致性。对各数据库提供统一入口，对所有的应用而言，只需通过相同的数据模型访问数据库，而无需关心各个物理数据库的模型和结构的不同。
要对非XML数据与XML数据进行重新转换与格式化，这就规定数据集成（中间件）对XML数据格式有很好的支持。数据集成为应用提供统一的数据访问格式，所有应用系统通过数据集成进行数据互换。数据集成实现数据格式的转换，使本地数据方便的转换为目的格式，进行数据互换。
使用数据级整合，可以整合应用程序使用的后端数据库。数据级整合可以基于推或拉技术。用基于推技术，一个应用程序可用SQL调用（通过数据库链接或存储过程）在另一个应用程序上的数据库表。基于推数据级整合将数据推动另一个应用程序的数据库中。相反，基于拉数据级整合运用了触发和轮询。触发捕获数据的改变并将辨认信息写入表接口。适配器可以轮询整合应用程序的表接口并取回相关数据。当一个应用程序规定被动告知另一个应用程序数据变化时，可以使用基于拉数据级整合。
当整合应用程序不提供任何API或客户接口时可使用数据级整合，并且应密切关注操作如何影响应用程序的数据模型。对于缺少API的应用程序，数据级整合是唯一的选择。
在数据级整合中，从依赖系统传播的变化绕过整合应用程序，因此所有插入、更新和删除都能对整合应用程序访问的数据进行操作。开发常用数据库网关或触发和存储过程实现数据级整合。
3.3.2 用户界面级整合
用户界面级整合将整合逻辑连结到用户接口代码。用户界面级整合是基于脚本或代理。基于脚本的用户界面级整合将整合代码嵌入到用户界面组件事件中，通常使用客户机/服务器应用程序。例如，当单击添加用户屏幕的提交按钮时，数据被送到应用程序的数据库和一个JMS。基于代理的用户界面级整合通过整合应用程序接口将数据从传统系统传递到终端。
当不能简朴直接访问数据库时或当商业逻辑嵌入在用户接口中时，使用用户界面级整合。大型机和客户机/服务器应用程序为用户界面级整合提供了典型的候选。大型机一般不能方便访问数据存储并且通常不能提供公共API。对于这部分，许多客户机/服务器应用程序将商业逻辑嵌入到客户端。在这些情况中，用户界面级整合提供了访问和维护数据完整的唯一途径。
在多数情况，用户界面级整合是最后的手段。添加逻辑脚本去快速捕获客户机/服务器应用程序中的事件，随着作为整合级维护的增长及变化的发生而变得困难。在其它情况，用户界面变化可以打破整合触发和逻辑。此外，用户界面的维护和整合代码的维护永久地紧密连接在一起。
3.3.3 应用程序级整合
整合应用程序的最佳途径也许是使用整合应用程序综合框架和API。应用程序接口调用业务逻辑去保护数据的完整性。一般使用应用程序级整合是由于它对于整合应用程序是透明的并且能保护应用程序的数据完整。
3.3.4 方法级整合
方法级整合是一种不常使用的应用程序级整合的超集，将多种应用程序的公共操作聚到一个单独的前端整合应用程序中。当每个整合应用程序提供一套相似的API或函数方法时，使用方法级整合。
方法级整合规定整合应用程序支持一个RPC（远端程序调用）或分布式组件技术。所有和整合应用程序互相影响的应用程序都通过前端应用程序解决。
方法级整合的重要缺陷是应用程序与前端组件的结合过于紧密。整合应用程序API的改变会打破前端应用程序组件和依赖它们的应用程序。由于方法级整合是一个比应用程序级整合更复杂的形态，用中间件进行应用程序级整合更故意义。
3.4 集成技术选择
原有应用系统整合可选用的技术很多，重要有ETL、集成中间件、文献系统、Web Service、数据库、大数据文献等多种技术，既可以单独使用某种技术，也可以根据具体情况综合采用。
3.4.1 ETL技术（数据级整合）
业务应用之间在一些特定的业务情况下也许会使用其他应用系统的数据，并且实时性规定不强。此时即可运用ETL工具，按照一定期间周期实现数据的抽取、转换和加载，保证两个系统之间的数据是同步的。
使用场景：原有信息系统和新建信息系统的数据同步。
3.4.2 数据库共享技术（数据级整合）
应用系统之间也许会互相请求互换数据库中部分表的数据，或者部分时间段的数据。数据库共享技术通过共享数据表、共享视图、共享中间表等方式解决这种情况。
使用场景：应用系统可以定制开发，并且系统间部署关系比较紧密。
3.4.3 Web Service（应用程序级整合）
应用系统在某些场景下，不只是规定进行数据信息的互换，还规定互相请求对方的业务操作，并且对同步性规定比较高，这种情况可在应用系统的开发过程中互相规约操作接口，通过Web Service方式直接进行调用。
使用场景：业务应用之间需要互相进行同步性较高的业务操作。

3.4.4 JavaBean组件技术（应用程序级整合）
JavaBean 是一种JAVA语言写成的可重用组件。用户使用JavaBean将功能、解决、值、数据库访问和其他任何可以用java代码发明的对象进行打包，并且其他的应用系统可以通过内部的JSP页面、Servlet、其他JavaBean、applet程序或者应用来使用这些对象。用户可以认为JavaBean提供了一种随时随地的复制和粘贴的功能，而不用关心任何改变。
使用场景：应用系统之间业务接口的直接调用。
3.5 具体集成方案设计

4. 结语
4.1 结语
在编写本设计文档的过程中，设计人员参考了相关的文献资料，依据业务需求调研的实际情况进行了设计和编写。
本文档作为总集成设计说明，具体集成方案设计尚未编写，需要进一步沟通协调方可给出。