库存状态检查开发和性能注意事项

库存的准确性是一个非常重要的考虑因素。 有一些本机功能可以帮助确保这种风险尽可能低，例如延期交割和设置缺货阈值。 这两个主题都可以在Experience League上阅读，以进一步说明。

在某些项目和用例中，需要对Adobe Commerce应用商店进行实时库存状态检查。 本教程将深入分析如何根据开发和性能考虑因素来处理此对话。

验证此请求是否绝对必要

准备使用尽可能多的信息参与对话。 最重要的是验证此项目是否可接受本机功能。 查找此请求背后的推理，以验证Adobe Commerce的本机功能是否无法满足此请求。

另一个考虑因素是开发、测试和维护此功能的成本。 仅仅因为某些利益相关者认为它是必要的，并不意味着它就是要求。 在Adobe Commerce核心功能之外进行库存验证会产生相关成本。 这些成本来自技术债务、更多测试和验证，以及其架构的使用文档和支持文档。

确定可接受的库存更新节奏

尝试考虑清单检查以及如何通过3种方法完成检查。 每一种方法都有好处和限制。 它们也会增加复杂性，并且需要针对错误处理进行更多的测试和思考。 请记住，当您决定采用自定义路由时，会添加一些责任和注意事项。 一些示例包括回退流程、监控、测试和疑难解答都属于开发团队。 要包括的一些有用项目是新的支持文档、培训和监控，以确保开发团队可以支持整个功能。 另一个副作用是开发团队完全拥有该流程，并且不再利用核心Adobe Commerce应用程序提供的本机功能。 Adobe支持无法协助进行此级别的自定义。

第一种方法是使用本机功能。 使用本机功能带来的风险最小，并且有许多好处。 如果采用这种方法，即表示您可以依赖Adobe Commerce为该功能的使用提供的所有现有文档和教程。 库存管理有许多方面，因此使用应用程序附带的内容应该是首要考虑的问题。 但是，在某些情况下，在订购时商业中找到的数据可能并不完全准确。 例如，如果允许直接在Adobe Commerce应用程序之外的订单管理系统中进行销售，则可能会出现不同步的情况。 一个原因是，要确保在Adobe Commerce中表示准确的库存水平，需要某种集成，以使Adobe Commerce信息尽可能接近准确。 如果不能接受过度销售，则添加缺货阈值是在达到零之前阻止物料销售的好方法。 Adobe Commerce的本机同步功能每天最多为1次。 这对于某些用例已经足够，但是对于其他用例来说可能不太频繁。 有关详细信息，请阅读计划的导入和导出。

第二种方法是near real-time。 近乎实时仍使用本机功能。 但是，这需要进行一些额外工作，以提供集成，该集成会经常向商业馈送以按计划更新其清单。 例如，每小时。 对于集成如何工作，此选项需要一些思考，但使用“批量api”并拥有一些中间件来执行数据转换并将其推送到商业是一种很好的方法。 请查看使用AdobeApp Builder或类似平台来完成大量工作，并以更频繁的节奏将信息推送到Adobe Commerce。

第三种方法，也是风险最大、责任最复杂的方法，是对外部API或数据源的实时实时清单检查。 对外部系统进行实时库存检查存在风险，并且还有其他几个需要考虑的因素。 以下是需要评估的一小部分其他内容：

考虑非本机库存管理时的注意事项

尽可能保持自定义项不复杂。
库存的组织有多平坦，是否只有1个SKU和可用库存的总量，或者还有其他属性需要考虑。

如果库存信息相当平坦（例如sku和总可用数量），则近乎实时的选项会被展开。 “近实时”概念是指有一个从源收集库存，然后填充用于响应请求的存储引擎的后台操作。 为此，您可以使用Redis、Mongo或其他非关系数据库。 这些选项很好，因为它们非常快，非常适用于键/值对。 如果数据更复杂，则可能需要在商务应用程序内部或外部使用关系数据库。 通过从商务数据库卸载此项，可以将核心商务应用程序与这些事务隔离。 另一组好处是使商务应用程序、CPU、RAM和其他方面的I/O不再使用。 不使用来自Adobe Commerce应用程序服务器的资源，而是利用新的API从站点外存储中提取数据。 这可能需要一个中间件来帮助转换任何数据。 然后，确保调用应用程序可以获得预期的结果。 通过使用带API网格的AdobeApp Builder，可以转换数据并返回格式正确的数据。

在有多个库存来源时，将AdobeApp Builder与API网格结合使用也是一个很好的选择。

将执行逻辑移动到进程外位置

Adobe Developer App Builder提供了一个统一的第三方可扩展性框架，用于集成和创建自定义体验以扩展Adobe解决方案。 Adobe Commerce可以使用Adobe Developer App Builder。 这是一个非常好的用例，可用于扩展一些通常在核心应用程序中出现的功能并将其移动到异地。 通过从Commerce应用程序中删除功能，这减少了Commerce应用程序的模块数量和复杂性。 反过来，流程中自定义项数量减少会降低升级和维护的复杂性。

为了获取如何实现此目标的灵感，Adobe团队已创建了一些文档，这些文档可以成为灵感的绝佳来源并提供工作代码示例。 当购物者将产品添加到购物车时，第三方库存管理系统检查该商品是否有库存。 如果是，则允许添加产品。 否则，显示错误消息。 有关代码示例和详细信息，请转到Webhook用例。

何时进行清单检查

何时检查库存是否仍然可用，最终将取决于业务利益相关者、软件架构师以及其他关键利益相关者的意见。 某些适当的时间可能包括在将项目添加到购物车时以及进入结帐工作流时。 任何其他事件都只会在不需要时将负载添加到后端系统。 请记住，我们的目标是只有在库存问题最为重要时才能发现问题。 其他检查可能很好，但如果它们可能会影响库存状态检查的总体目标，则应该仔细考虑这些检查，并且仅当业务利益相关者或其他人意识到后端系统可能会出现额外负载时才允许这些检查。

研究库存来源

需要对外部库存来源进行全面调查。 应评估的项目包括：可用的API选项、对GraphQL的支持以及预期的响应时间。 如果库存源的连接带宽有限或者从未打算在实时请求中使用，则排除使用能力，因此架构师需要考虑采用近乎实时的方式。 如果API请求次数超过定义的参数，它也会将此从一个可行的选项中排除。 例如，api响应为200MS®，即一次请求一次，但在中等负载下会升至500到900MS®。 随着负载增加，情况可能会变得更糟，并且会禁用实时库存调用。

请务必使用简单的请求以及与实时网站上预期流量相似的大量数据来测试API响应时间。 切记同时测试商务中的所有区域以模拟真实世界的场景。 如果预期是在产品页面上发生实时库存调用，则在查看和编辑购物车以及结账期间，负载测试需要同时模拟所有这些情况，以模拟真实的客户行为和商店的预期。

回退选项

如果清单源已关闭并且监视可用，则建议使用Adobe Commerce的本机功能。 但是，通过适当的监控，客户体验可以动态变化以反映实时库存检查的丢失。 这可能意味着为了避免过度销售，提前取消销售或取消活动，或者从展示中移除销售或活动。 当存货来源因任何原因停止运作时，预期将采取什么行动需要与店主考虑和讨论，以便每个人都知道在这种不幸情况下会接管任何自动流程。

结论

实时检查库存的决定很重要。 确保网站所有者、开发团队和其他人接受全面教育，并了解所有收益和潜在隐患取决于开发人员主管或架构师。 通过提供周到的计划（包括原因和回退流程）是获得成功的关键。

实时清单检查可以完成，但需要在QA周期期间围绕测试和验证进行研究和思考。 确保负载测试和端到端自动化测试有助于确保捕获并分类所有潜在问题。

通过考虑在监测检测到外部系统呼叫失败趋势或响应时间超过可接受阈值时要执行的操作，站点可以保持在线状态并为客户提供最小程度的刺激。 回退选项可以非常简单，只需关闭外部库存检查并使用本机功能，也可以非常高级，如禁用促销活动、将不断升级的问题通知开发团队，甚至可能将请求重新路由到第二个或第三个后端系统（如果可用）。 由于每个集成在某个时间点都存在问题，因此如何实施回退机制应只作为实际实施来考虑。 任何自动化或需要手动操作的内容都应明确记录。