电商平台与ERP系统集成的设计与实现

  • 格式:doc
  • 大小:28.00 KB
  • 文档页数:3

电商平台与ERP系统集成的设计与实现

首先分析了电商平台的电子商务系统和 ERP 系统的流量模型的差异,阐述了在电子商务系统设计一个本地的库存缓存机制的必要性。随后给出了该库存缓存系统的具体设计,包括数据模型、缓存初始化、缓存失效、缓存更新、缓存同步等管理机制的设计。

标签: 电子商务系统;ERP 系统;建模

由于电子商务系统与 ERP 系统都是非常复杂和庞大的应用系统,两者都具有非常丰富的业务流程、复杂的系统架构和服务接口。在很多情况下,这两个系统都是分别独立部署和运行的,各自拥有不同的技术栈和编程模型,甚至两者在系统平台、技术平台和编程语言上是完全异构的。因此它们之间的集成面临着许多问题和挑战:系统连接、通信协议转换、数据格式和数据模型的转换;服务的同步调用与异步调用;由于系统扩容、弹性伸缩方面的考虑,双方系统的部署拓扑结构也不是一成不变的,服务端点的位置也可能会发生变化,因此要考慮在服务提供方服务端点发生变化的时候,服务消费方仍然确保能够透明的找到服务端点;某些业务场景需要服务请求根据消息内容或消息上下文路由到不同的服务端点,如何做到对服务消费者和服务提供者双方都透明的基于具体消息内容的动态路由。

为了解决这些问题,本文应用 SOA 的思想和 ESB 技术,设计了面向服务的集成架构。

1 电子商务系统与 ERP 系统集成服务建模

在电子商务与 ERP 系统集成设计中,在设计思想上首先要考虑服务的建模问题,需要将各个系统之间交互的过程进行服务化,即服务封装,包括系统对外依赖的服务调用接口和系统对外提供的服务暴露接口。一般将系统对外调用的服务称为出站服务,将系统对外提供的服务称为入站服务。根据本文前面阐述的电商平台与 ERP 系统集成的业务需要,电子商务系统和 ERP 系统封装了以下服务。

2 商品相关交互流程设计

商品相关的流程设计主要考虑电子商务系统查询后台 ERP 系统提供的商品信息的效率问题。这就要求设计上消息转换要高效、服务响应要实时同步。商品规则有其数据一致性要求,需要通过设计在商品查询的不同阶段维护促销数据的一致性。因此,在此流程设计和实现时,需要重点考虑相关数据的实时性效率和完整性问题。

(1)当购物者在电子商务系统的网上商店在线购物时,通过搜索引擎,查找关键词进行商品检索。商品引擎会给出适用于当前客户关键词的商品信息。并

且按照给定的排序规则生成商品列表。(2)商品搜索引擎首先会将符合用户搜索条件的本地缓存的商品反馈给用户。(3)在给出本地缓存商品信息的同时,把相关的关键词通过 ESB 的中介服务,发送到后台 ERP 系统,ERP 系统通过 Get

product 消息,进行信息检索,生成商品信息列表。并且通过 Get product Page 服务,把信息列表也发送给前台电子商务系统。实现商品列表的信息展示。(4)当用户点击某商品查看商品详细信息时,电子商务系统会通过 ESB和 JMS 队列进行的方式,要求 ERP 系统返回该商品的详细信息。JMS 队列中的这些 XML

消息,经过 ESB 的中介服务,转换成电子商务系统接收的专有消息格式。(5)为响应上述这些消息请求,将调用电子商务系统的相应服务,例如商品价格请求由价格引擎服务处理,优惠券的验证请求和促销规则详情的获取请求由促销引擎的服务处理,订单整体价格和优惠及费用计算请求由电子商务系统的订单计算服务处理。

3 会员信息交互流程设计

会员信息主要是通过电子商务系统来完成登记的,后台 ERP 主要是通过

ESB 和JMS 队列方式调用该信息。(1)首先,购物者在前台电子商务系统注册为会员,填写用户名、收货地址、联系电话等信息,完成会员信息的录入。(2)其次,电子商务系统通过 post member 服务,把会员信息通过中间件提交到后台 ERP 系统中。在该过程中,此时电子商务系统发出 post member 请求,经过

ESB 中介后将其映射到 ERP 系统的 Get member information,并且把反馈的数据获得结果,实时返回电子商务系统。(3)如果针对会员信息请求的服务由 ERP

系统发起,则 ERP 系统通过Get member information 发送获取会员信息的请求,ESB 中间件后将其映射到电子商务系统中的 post member 服务中,获取会员的基本信息。

4 库存缓存机制的设计与实现

4.1 库存响应问题分析。

电商平台的前端电子商务系统与后端 ERP 管理系统的用户访问流量模型存在着较大的差异。电商平台的电子商务系统面向的往往是庞大的在线用户量,高度的并发访问量,而且用户流量在一天中也有明显的峰值。特别是在节假日、大的促销活动举行时,网上商店一般会涌入大量的购物者。虽然很多的购物者只是浏览商品、查找商品、比较商品,但是仍然对系统构成庞大的压力。因此要求对系统有着良好的设计以保证在大用户量的情况下提供满足 SLA(Service Level

Agreement)的服务。而后端 ERP 系统在流量模型方面却不同。数据统计表明,B2C 电子商务的订单转化率一般不到 5%,也就是说 100 个访问网上商店的用户最终可能只有不到 5 个人会真正下单购买。从这个漏斗模型看,后端 ERP 系统支持的用户量只是前端电子商务系统的几十分之一。但后端 ERP 系统也有自己的计算特点,如长流程服务(如订单排程、配送处理),通常采用异步处理和批量处理,在响应时间方面往往也比前端系统的要求要低。

从以上可以看出电子商务系统和 ERP 系统的流量模型是完全不同的,因此

要求在对这两个系统进行集成时需要有一定的机制来缓冲和适配这种差异性。在库存方面,由于一般网上商店的商品详情页面要求定性甚至定量显示该商品的库存可用性,而商品详情页的用户访问量又是非常大。如果电子商务系统的高频、高并发、海量的库存查询服务每次都直接调 ERP 系统服务和 API,ERP系统很可能就会支撑不住出现宕机情况、或者出现响应缓慢以致严重影响其他业务功能的正常运行。因此在电子商务系统中设计一个库存缓存机制是非常有必要的。

4.2 库存缓存的数据存储模型设计。

在本文前面提到在电子商务系统和 ERP 系统集成的上下文中,库存是由ERP 系统来统一管理的,所以 ERP 系统中存有库存数据的主拷贝。电子商务系统只缓存了一部分库存数据,目的是在商品浏览和添加购物车时检查库存环节以便优先使用本地缓存的库存信息,避免或减少对 ERP 系统库存查询的实时调用。缓存机制的设计主要考虑电子商务系统中缓存的存储、缓存的初始化、更新和同步流程的设计、以及库存相关的服务和 API 的设计。

缓存的数据模型设计主要是解决缓存信息放在哪里的问题,一般有两种选择:保存在数据库中(这样持久化会更好)或者保存在内存中(这样具备更好的查询性能)。本文涉及的系统因为需要支持不同客户类型的需要,所以数据库和内存两种存储方式都支持,用户可以根据配置选择两者中的一种。但无论哪种缓存方式,都要解决缓存哪些库存信息问题。

4.3 库存緩存同步。

缓存同步是由外部库存系统根据一些预先定义的事件和条件,周期性或事件驱动的主动同步行为。ERP 系统实时库存监控系统可以根据库存的变化情况,实时同步库存到电子商务系统。库存缓存的同步可以是少量和增量的同步,通过调用 Sync Inventory Availability 服务实现。在待同步的库存条目比较多时,通过配置 RTAM,使其在需要同步库存缓存时,自动生成 CSV 文件并上传到电子商务系统,从而触发库存缓存的批量和全量同步。从下面 ERP 系统向电子商务系统同步库存的 ESB 中介流程编排图中可以看出根据 Monitor Option Filter 更新库存的服务请求被路由到两个不同的路径,上面路径是触发 Sync Inventory

Availability 的增量更新,下面的路径是生成 CSV文件的批量更新。

参考文献

[1] 朱佳钦. SHYD 公司系统集成业务营销策略研究[D]. 华东理工大学,

2016

[2] 聂良涛. 面向实体选线设计的铁路线路 BIM 与地理环境建模方法与应用[D]. 西南交通大学, 2015