内容


向客户提供一致和准确的可用性信息

部署 Promising and Inventory Hub

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分:

敬请期待该系列的后续内容。

此内容是该系列的一部分:

敬请期待该系列的后续内容。

概述

Promising and Inventory Hub 让您的组织可以提供单一数据源(single source of truth),让您可以对客户做出准确的承诺。客户将零售商视为一个品牌。客户期望获得跨所有零售渠道的无缝集成,包括网站、实体店、移动商店和呼叫中心。因为单个客户的购物体验可以覆盖多个渠道,无论客户与哪个渠道和接触点进行互动,您的组织都可以为可用性查询提供一致的答案,这一点非常重要。传统上,已将承诺和库存功能部署为订单管理系统的一部分。随着零售商收购额外的业务和整体数量的提高,单一的部署模型可能无法满足业务和 IT 需求。零售商需要跨多个渠道和新收购的业务共享库存,扩大自己的市场存在,并提供多种履行选项,同时最大限度地减少存放在仓库的库存。

部署模型

大部分订单管理部署是单实例部署,如所示。在此部署中,在单一实例中一起部署订单管理和 Promising and Inventory Hub。订单数据和库存数据都驻留在同一个数据库。在这种部署中,中间层应用服务器集群可以横向扩展。如果增加集群的大小,则可以处理更多的集群。然而,如果数量大幅增加,数据库可能会成为一个瓶颈。基于碎片的部署可以减少瓶颈。

图 1. 单实例部署
图片显示了只有一个实例的部署

在基于碎片的部署中(如所示),订单可以驻留在多个数据库实例(也称为碎片)中,但客户可以在单个部署实例中访问它们。根据订货的企业,订单被拆分成不同的碎片。例如,WEB 企业的订单可能被拆分成一个 WEB 碎 片,但 RETAIL 企业的订单可能被拆分成一个 RETAIL 碎片。驻留在不同碎片中的多个企业可以共享配置数据,因为所有配置数据在一个给定的部署中都有一个专用的公共碎片。在此示例中,配置数据驻留在一个名称为 CONFIG 的单独碎片中,该碎片由两个企业共享:RETAIL 和 WEB。

图 2. 基于碎片的部署
图片显示了一个共享部署
图片显示了一个共享部署

目前对基于碎片的部署有一个限制,库存信息与订单数据必须驻留在同一个实例中。如果两个企业需要共享库存,他们必须驻留在同一个碎片中。部署一个单独的 Promising and Inventory Hub 可以解决这一限制。

部署一个单独的 Promising and Inventory Hub 的其他优点包括:

  • 升级的独立性 – 您可以从在其上部署了订单中心的实例运行在不同版本的 Sterling Selling and Fulfillment Suite 上的 Promising and Inventory Hub 实例。不过,对 Sterling Selling and Fulfillment Suite 的兼容性也有一定的限制。
  • 更易于调整大小 – 您可以更准确地调整 Promising and Inventory Hub 硬件要求的大小,因为它不需要执行订单处理,所以不会在数据库中存储订单。
  • 单一来源的可用性 – 您可以从 Promising and Inventory Hub 向使用旧式或其他订单管理系统的其他业务渠道暴露服务。暴露此类服务对 Sterling order hub 没有任何影响,因为它运行在一个单独的实例中。
  • 减少库存锁定 – 在单实例部署中,在每个订单事务的过程中,库存项目记录都被锁定。订单的持续时间取决于众多因素,比如订单的大小、由于集成到外部系统而产生的延迟,等等。当使用 Promising and Inventory Hub 部署时,来自订单管理系统实例的订单事务调用 Promising and Inventory Hub 中的库存 API。只在库存 API 处理的过程中保持库存锁。当库存 API 完成时,库存锁被释放。

Promising and Inventory Hub 架构视图

您可以从订单管理和其他相关系统独立地部署 Promising and Inventory Hub,如所示。

图 3. 独立的 Promising and Inventory Hub
图片显示了一个独立的 Promising and Inventory Hub
图片显示了一个独立的 Promising and Inventory Hub

Promising and Inventory Hub 具有以下职责:

  • 维护所有业务单元或渠道的供需数据
  • 为所有可用性计算提供服务
  • 维护所有的采购和调度配置规则
  • 向 e-Storefronts 发布可用性信息

然而,Promising and Inventory Hub 无需责任维护任何订单。

Order Hub 具有以下职责:

  • 维护订单
  • 调度和发布订单
  • 为所有可用性查询调用 Promising and Inventory Hub
  • 为所有库存更新调用 Promising and Inventory Hub

e-Storefronts 具有以下职责:

  • 接受来自 Promising and Inventory Hub 的可用性信息
  • 在进行预留的时候调用 Promising and Inventory Hub

当您使用 Promising and Inventory Hub 的可用性和库存服务时,无论哪个系统查询可用性,您的所有渠道都可以共享相同的库存。有一些明确定义和记录的 API 提供了可以满足不同客户请求的履行选项,如:

  • “我可以明天在我家附近的一家商店提货吗?”
  • “为什么该产品要两个星期后才有货?”
  • “有多少延迟出货的需求是在促销过程中产生的?”

供应可用性的仓库更新被加载到 Promising and Inventory Hub 中。因为不存在订单信息,所有需求都被建模为库存预留(inventory reservation)。在承诺查询过程中,可用性的计算方法如下:

  • 从供应减去需求(来自预留)。
  • 应用采购和调度约束。
  • 应用优化,向客户提供最佳的履行选项,或提供多种履行选项让客户可以从中选择。

实现详细信息

安装

Promising and Inventory Hub 是一个 Sterling Order Management 实例。一般来说,一个客户安装两个 Sterling Order Management 实例。一个实例被用作 Order Hub,用于创建和履行订单。另一个实例被用作 Promising and Inventory Hub,用于维护库存和可用性配置。这两个实例的安装是完全相同的。请按照产品安装指南进行安装。

或者,您可以只安装一个 Sterling Order Management 实例,并使用它作为 Promising and Inventory Hub,而不安装另一个用于订单管理的实例。如果希望部署 Promising and Inventory Hub 不会改变或影响您的订单处理流程,那么此选项可能更有吸引力。

集成

在安装两个订单管理系统实例后,您必须配置系统之间的集成。集成主要由两部分组成:

  • 可用性检查
  • 供需更新

可用性检查

当订单被调度和发布时,系统会检查可用性,并确定订单的最佳承诺(出货节点、出货日期)。Schedule and Release 代理在订单管理实例上运行,并同步调用 YFSGetExternalAvailabilityUE。用户在 Promising and Inventory Hub 上退出调用 reserveAvailableInventory API。reserveAvailableInventory API 负责制定所有采购决策,并创建预留(reservation),以确保这个承诺被封锁,其他订单不能够消费已承诺的供应。同样,在 createOrder API 的调用过程中,如果存在订单行预留,那么订单管理将会调用 Promising and Inventory Hub,并在 Promising and Inventory Hub 上建立相应的预留。

在 Order Hub 上的其他 API 可能包括查询 API,比如 getPossibleSchedules 或 getFullfilmentOptionsForLine。这些 API 也调用 YFSGetExternalAvailabilityUE。不过,在 Promising and Inventory Hub 上,调用被映射到 findInventory API,因为不需要更新预留。为了在 Promising and Inventory Hub 上区分两个 API 调用,可对用户出口所输入的 XML 使用 IsIntendToUpdate 属性。该属性根据条件调用 reserveAvailableInventory API 或 findInventory API。同步执行所有可用性检查。

供需更新

随着订单流经相应的渠道,在修改订单时,订单状态的变更会产生供需更新。在 Order Hub 中,应在状态库存类型下维护状态和供需类型之间的映射。导致订单状态变化的所有 API 将会触发以下事件:

  • EXTERNAL_DEMAND_CHANGE
  • EXTERNAL_SUPPLY_CHANGE

使用 reserveItemInventory API,在 Promising and Inventory Hub 上修改需求。在 Promising and Inventory Hub 上,可使用 adjustIventory API 来减少供应(例如,在发货确认时)。为了保持数据的完整性,当某个操作在 Order Hub 上调整供需时,在 Promising and Inventory Hub 上也必须在事务边界中作出相应的调整。您可以编写一个自定义 API,在单个事务边界中处理这些请求。或者,您也可以只实现 EXTERNAL_DEMAND_CHANGE 事件。利用此事件,由于发货确认所导致的需求变更将 ConfirmShipment 属性设置为 Yes。当 ConfirmShipment 属性是 Yes 时,您可以减少需求和相应的供应。

订单管理中心可以执行同步或异步的供需更新调用。 总结了订单管理中心和 Promising and Inventory Hub 之间所需的集成:

图 4. 两个中心之间的集成
图片总结了在订单管理中心和 Promising and Inventory Hub 之间所需的集成
图片总结了在订单管理中心和 Promising and Inventory Hub 之间所需的集成

管理工作负载的集成选项

所有承诺 API 都可以调用 YFSGetExternalAvailabilityUE 并触发一个 EXTERNAL_DEMAND_CHANGE 事件。在大多数实现中,可以避免一些调用,以减少对 Promising and Inventory Hub 的整体负载。

减少负载的一种方法是将所有订单保留为订单创建服务的一部分。当订单来自多个渠道时,首先使用 reserveAvailableInventory API 在 Promising and Inventory Hub 上保留它们。在订单被保留后,就不需要在调度或发布流程中检查可用性。您必须实现 YFSGetExternalAvailabilityUE,基于对用户出口的输入 XML <Reservations> 元素中传递的订单行预留,返回可用的承诺要求。

当承诺只考虑 ONHAND 库存,并且没有使用采购订单时,您并不需要在调度和发布过程中更新需求。仅当订单中没有订单行预留时,ScheduleOrder API 才会转到 Promising and Inventory Hub。不过,这种场景是个例外,因为大多数订单都有订单行预留。利用简化的集成,Order Management Hub 可以在以下位置调用 Promising and Inventory Hub:

  • 在原始保留过程中,创建订单服务的位置
  • 在发布过程中(这是可选的),将需求类型从 promised (已承诺)更改为 allocated(已分配)
  • 在发货确认过程中,可减少需求和供应

这种方法有其局限性,但它可以在许多客户实现中使用。

异常处理

在传统的安装中,所有的订单更新和库存更新都是作为相同的事务边界的一部分而执行的。其结果是,整个 API 成功完成,或被回滚。举例来说,在数据库中创建了需求,但没有创建订单,这种场景是不可能存在的。

在分布式部署中,即使订单更新没有成功完成,需求也有可能被更新,反之亦然。 显示了在一个 Schedule 事务过程中发生的交互。类似的交互在其他 API 调用中也会发生,比如 createOrder API。

在中,数字 1-8 表示 API 执行过程中可能会失败的关键位置。在每个事务或 API 调用结束时,系统都会发出一个提交,此时所有变更都被提交到数据库或 JMS 队列。

  • 如果失败出现在调用 Promising and Inventory Hub 之前(在 #1 点之前),那么整个 API 都被回滚。在 Promising and Inventory Hub 上没有执行任​​何处理。
  • 如果失败出现在 Promising and Inventory Hub 上的 reserveAvailableInventory API 执行过程中(在 中的 #2 和 #3 点之间),那么在该服务器上的数据被回滚。因为调用是同步的,所在订单管理中心的 API 调用也将被回滚。
  • 如果失败发生在订单管理中心上的 reserveAvailableInventory API 执行过程中(在 中的 #2 和 #3 点之间),那么订单 API 将被回滚,但 Promising API 将会成功。因此,Promising Server 上存在需求,但相应的订单不存在。处理此类需求的一个选项是在保留过程中向 Promising and Inventory Hub 传递一个到期日期。每个预留都使用一个过期时间(例如,1 小时)来创建。除非对该预留的后续更新发生在这段时间内,否则库清除会删除该需求。此选项要求系统在订单更新(#5 点)的过程中触发另一个事件。作为此事件的一部分,到期日期被更改为一个很大的日期,以便预留永不过期。
  • 如果失败发生在订单更新过程中,在完成 ReserveAvailableInventory 调用之后(在 中的 #3 和 #5 点之间),那么所有订单变更都将被回滚,但承诺变更被提交。使用与上述解决方案类似的解决方案来纠正库存。
  • 在订单更新(在 API 执行中到达 #5 点)之后,系统会触发 ON_DEMAND_CHANGE 事件,并将消息发布到队列中。在订单管理端的 API 执行结束时(在 中的 #8 点),在数据库和队列上发生提交。从队列异步读取消息,并且已经创建的预留的到期日期被调整为很大的日期。如果提交失败,订单变更将被回滚,这类似于以前的失败。
  • 如果失败发生在 reserveItemInventory API 调用过程中(在 中的 #6 和 #7 点之间),那么 Promising and Inventory Hub 上的消息不会被处理,并且被留在队列中。假设会持久性地保存队列,那么集成服务器在所配置的时间间隔后会再次读取消息,并尝试重新处理它。不过,这些失败不会影响订单处理,因为在 Promising and Inventory Hub 端的消息是异步处理的。
图 5. 在 Schedule 事务过程中的交互
图片显示了在一个 Schedule 事务过程中发生的交互
图片显示了在一个 Schedule 事务过程中发生的交互

配置和主数据

承诺、调度和库存的所有配置,如采购规则、调度规则以及可承诺(ATP)规则,都在 Promising and Inventory Hub 中进行定义。有关订单的配置(如订单管道、付款配置等)是在订单管理实例中定义的。您必须确保公共配置数据(如组织或发货节点)在订单管理系统和 Promising and Inventory Hub 中保持同步。此外,根据不同的实现,您可能需要确保主数据被复制。复制的数据包括:

  • 项目,如果项目属性用于承诺或库存
  • 客户,如果已定义客户调度偏好

使用 Configuration Deployment Tool 从一个实例中提取要复制到另一个实例的数据。

配置性能和可用性

Promising and Inventory Hub 对于一个或多个渠道来说是一个重要的资源。为了保护中心的可用性,确保您的解决方案架构可以满足以下要求:

  • 性能和可扩展性
  • 高可用性

性能和可扩展性

传统订单管理系统部署的性能建议和最佳实践也适用于 Promising and Inventory Hub。此外,在您开发自己的部署架构时,请考虑以下这些建议:

  • 为每个渠道创建不同的应用程序集群,这样就可以按其来源隔离工作负载。此配置可以实现更容易的监控、管理和调优。例如,您可以为来自 Web 渠道的所有承诺和库存事务创建一个集群,为来自订单管理应用程序的事务创建另一个集群,并为其他目的创建更多的集群。
  • 确保有足够的计算资源,可以在高峰期间处理来自所有渠道的事务。
  • 由于集成架构,可能会有大量需求更新消息要在订单管理中心和 Promising and Inventory Hub 之间移动。需求消息被异步地放入 JMS Queue。单个 JMS Queue 可能无法处理如此大量的消息。为了避免这种可扩展性问题,您可以不使用单一的队列,而是定义多个队列,并采用循环逻辑或随机地分发消息。订单中心将需求信息放入多个队列,而 Promising and Inventory Hub 从所有队列中检索消息。

故障转移和高可用性

您可以使用传统的方法来确保 Promising and Inventory Hub 的可用性。这些方法包括,使用​​ DB2 高可用性灾难恢复(HADR)的主动/被动式备用数据库,以及使用 DB2 pureScale® 或 IBM PureData Systems® 的主动/主动式冗余。同样,您也可以使用集群和水平缩放来保护代理服务器和应用服务器。

限制

基于 Sterling Selling and Fulfillment Suite 9.2 版本,订单管理和 Promising and Inventory Hubs 的分布式部署有一些限制。

  • 目前不支持所提供的服务和交付服务。
  • 目前不支持 Item-Based Allocation Agent。
  • 您可以在分布式部署中使用 Sterling Warehouse Management System。库存必须与订单和出货在一起,这样 Warehouse Management System 才能正常工作。
  • 配置和主数据 部分中所述,在订单管理实例和 Promising and Inventory Hub 实例之间需要复制某些数据。只有两个实例都在同一版本的 Order Management 上运行的时候,才支持使用 Configuration Deployment Tool 进行复制。
  • 不能在 Promising and Inventory Hub 上维护需求详细信息。
  • 纯库存 API(如 getSupplyDetails API)在订单管理中心上不能正常工作。因此,必须从 Promising and Inventory Hub 访问 Order Management 控制台中的库存屏幕。
  • 目前,没有任何工具可以从订单管理中心导出库存,并将其导入到 Promising and Inventory Hub。您必须创建一个自定义的解决方案,将现有的订单管理部署迁移到本文所述的分布式部署中。
  • 当某个节点发生缺货时,会触发库存节点控制,这要求执行一个单独的集成,在本文中并没有对此进行介绍。

结束语

Promising and Inventory Hub 为所有库存和可用性计算提供了单一数据源。无论使用什么样的互动平台,它都使得组织能够向其客户做出准确的承诺。Promising and Inventory Hub 还使得组织能够更迅速地响应业务需求,帮助他们的 IT 部门扩展其解决方案,支持比传统的单实例部署更多的数量。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=1000967
ArticleTitle=向客户提供一致和准确的可用性信息
publish-date=03192015