在庫ステータスチェックの開発とパフォーマンスに関する考慮事項

在庫の精度は非常に重要な考慮事項です。 バックオーダーや在庫切れのしきい値の設定など、このリスクを可能な限り低くするのに役立つネイティブ機能がいくつかあります。 これらのトピックは両方とも、で読むことができます Experience League を参照してください。

Adobe Commerce ストアに対してリアルタイムの在庫ステータスチェックがリクエストされるプロジェクトやユースケースがあります。 このチュートリアルでは、開発およびパフォーマンスに関する考慮事項を含め、この会話を処理するためのインサイトを提供します。

このリクエストが絶対に必要かどうかを検証する

可能な限り多くの情報を使用して会話に参加する準備をします。 最も重要なことは、このプロジェクトでネイティブな機能が受け入れられないことを確認することです。 このリクエストの理由を調べ、Adobe Commerceのネイティブ機能がこのリクエストを満たすことができないことを検証します。

もう 1 つの考慮事項は、この機能の開発、テスト、保守にかかるコストです。 関係者の中には必要だと考える人がいるからといって、それが必要だというわけではありません。 Adobe Commerceのコア機能の外で在庫検証を行うと、関連コストが発生します。 これらのコストには、技術的負債、さらなるテストと検証、アーキテクチャの使用方法に関するドキュメントとサポートドキュメントが含まれます。

許容可能な在庫更新頻度の決定

在庫チェックとその実行方法を 3 つのアプローチで検討します。 それぞれにメリットと制限があります。 また、複雑さが増し、より多くのテストが必要になり、エラー処理に関する考慮が必要になります。 カスタムルートを使用することに決定した場合、追加の責任と考慮事項があることに注意してください。 例えば、フォールバックプロセス、監視、テスト、開発チームへのトラブルシューティングのフォールバックが含まれます。 含めるべき良い項目は、新しいサポートドキュメント、トレーニング、監視で、開発チームが機能全体をサポートできるようにすることです。 もう 1 つの副作用として、開発チームがプロセスを完全に所有し、コア Adobe Commerce アプリケーションが提供するネイティブ機能を利用しなくなったことが挙げられます。 Adobeサポートは、このレベルのカスタマイズに対応できません。

1 つ目のアプローチは、ネイティブ機能を使用することです。 ネイティブ機能を使用することで、リスクを最小限に抑えることができ、多くのメリットがあります。 このアプローチを採用すると、Adobe Commerceが提供する既存のすべてのドキュメントとチュートリアルを利用して、この機能を使用できます。 在庫管理には多くの側面があるので、アプリケーションに付属しているものを使用することが最初に考慮する必要があります。 ただし、注文時にコマースで見つかったデータが完全には正確でない可能性があるユースケースがあります。 同期が取れなくなる可能性がある例としては、Adobe Commerce アプリケーションの外部で売上高を注文管理システムに直接転送できる場合があります。 正確な在庫レベルがAdobe Commerceに確実に表示されるようにするには、Adobe Commerce情報をできる限り正確に保つために何らかの統合が必要になるからです。 売り過ぎが許容できない場合は、在庫切れのしきい値を追加すると、ゼロになる前に商品の販売を停止するのに適した方法です。 Adobe Commerceのネイティブ同期機能は、1 日あたり最大 1 回です。 これは一部のユースケースでは十分ですが、他のユースケースでは十分に頻繁でない可能性があります。 読んでください スケジュールされた読み込みと書き出し を参照してください。

2 番目のアプローチは次のとおりです。 near real-time. ほぼリアルタイムで、引き続きネイティブ機能を使用します。 ただし、これには、コマースに頻繁にフィードを送信してスケジュールに従って在庫を更新する統合を提供するための追加の作業も含まれます。 例：1 時間ごと。 このオプションは、統合がどのように機能するかについて考慮する必要がありますが、「bulk api」を使用し、一部のミドルウェアでデータを変換してコマースにプッシュすることは優れたアプローチです。 Adobeの App Builder または同様のプラットフォームを使用して作業を一括で行い、より頻繁にAdobe Commerceに情報をプッシュすることを検討してください。

3 番目のアプローチは、リスクと責任が最も多く、最も複雑なアプローチは、外部 API またはデータソースに対するリアルタイムのライブインベントリチェックです。 外部システムに対してリアルタイムの在庫チェックを行うことはリスクが高く、考慮する必要があるその他の要素がいくつかあります。 その他に評価する必要があるものは、次の通りです。

ネイティブ以外の在庫管理を検討する際の考慮事項

カスタマイズは、できるだけ単純にします。
在庫の組織がどの程度平らであるか、それは単に 1SKU と利用可能な在庫の合計量であるか、または考慮する必要がある他の属性があります。

SKU や合計使用可能数量など、在庫情報が非常にフラットな場合、ほぼリアルタイムのオプションが展開されます。 ほぼリアルタイムという概念は、ソースからインベントリを収集し、ストレージ・エンジンにデータを入力して要求に対応するバックグラウンド操作があることを意味します。 これには、Redis、Mongo、その他の非リレーショナルデータベースなどを使用できます。 これらのオプションは非常に高速で、キーと値のペアに最適なので便利です。 データが少し複雑な場合は、コマースアプリケーションの内部または外部で関係データベースを使用する必要が生じる可能性が高くなります。 これをコマースデータベースからオフロードすることにより、コアコマースアプリケーションをこれらのトランザクションから分離します。 もう 1 つの利点は、コマースアプリケーション、CPU、RAM などから I/O を節約できることです。 Adobe Commerce アプリケーションサーバーのリソースを使用する代わりに、新しい API を利用してオフサイトストレージからデータを取り込みます。 データ変換を支援するミドルウェアが必要になる可能性があります。 次に、呼び出し元のアプリケーションが期待どおりに結果を取得できることを確認します。 API メッシュでAdobeの App Builder を使用すると、データを変換して、正しい形式で返すことができます。

複数のインベントリソースがある場合は、API メッシュでAdobeの App Builder を使用することも最適なオプションです。

実行ロジックをプロセス外の場所に移動

Adobe Developer App Builder は、カスタムエクスペリエンスを統合および作成してAdobeソリューションを拡張するための統一サードパーティ拡張フレームワークを提供します。 Adobe Commerceは、Adobe Developer App Builder を使用できます。 これは、通常コアアプリケーションで発生し、オフサイトに移動される一部の機能を拡張する場合の優れたユースケースです。 Commerce アプリケーションから機能を削除することで、Commerce アプリケーションのモジュールの数と複雑さが軽減されます。 さらに、インプロセスのカスタマイズの数が少なくなるので、アップグレードやメンテナンスの複雑さが軽減されます。

これを実現する方法のインスピレーションとして、Adobeのチームは、インスピレーションの優れた源となり、実用的なコードサンプルを提供できるいくつかのドキュメントを作成しました。 買い物客が買い物かごに製品を追加すると、サードパーティの在庫管理システムが品目の在庫があるかどうかを確認します。 追加する場合は、製品を追加できるようにします。 それ以外の場合は、エラーメッセージを表示します。 コードサンプルおよび詳細については、次を参照してください。 Webhook のユースケース.

在庫チェックを行うタイミング

在庫がまだ残っているかどうかを確認するタイミングは、最終的にビジネスの関係者、ソフトウェアアーキテクト、他の主要な関係者からのいくつかの入力になります。 例えば、買い物かごに項目を追加する場合や、チェックアウトワークフローに入る場合などです。 その他のイベントは、不要な場合に、バックエンドシステムに負荷を追加するだけです。 目標は、最も重要な場合にのみ在庫の問題を検出することです。 その他のチェックもいいかもしれませんが、在庫ステータスチェックの全体的な目標に影響を与える可能性がある場合は、慎重に考慮し、ビジネスの関係者または他の人が、バックエンドシステムに追加の負荷がかかる潜在的なリスクを認識している場合にのみ許可する必要があります。

在庫ソースのリサーチ

外部在庫ソースの包括的な調査が必要です。 評価する必要がある項目は、使用可能な API オプション、GraphQLのサポート、予想される応答時間です。 在庫ソースの接続帯域幅が限られている場合、またはリアルタイムリクエストでの使用を意図していない場合、使用の機能は除外され、アーキテクトはほぼリアルタイムで検討する必要があります。 API リクエストの時間が定義済みのパラメーターを超える場合、これを実行可能なオプションから除外します。 例えば、API 応答は 1 回のリクエストに対して 200 MS® ですが、中程度の負荷では 500～900 MS® に上昇します。 負荷が増えると状況は悪化し、ライブインベントリ呼び出しが使用可能でなくなる可能性が低くなります。

単純なリクエストで api 応答時間をテストするだけでなく、ライブ web サイトで期待されるトラフィックに類似した大量の api 応答時間をテストしてください。 実際のシナリオをシミュレートするには、コマースのすべての領域を同時にテストすることを忘れないでください。 製品ページでライブ在庫呼び出しが発生すると想定される場合、買い物かごを表示および編集する際とチェックアウト時に、負荷テストでは、実際の顧客の行動と店舗の期待をシミュレートするために、これらすべてを同時にシミュレートする必要があります。

フォールバックオプション

インベントリソースがダウンし、モニタリングが使用可能な場合は、Adobe Commerceのネイティブ機能を使用することをお勧めします。 ただし、適切に監視することで、顧客体験を動的に変化させ、リアルタイムの在庫チェックの損失を反映させることができます。 これは、オーバーセルを避けるために、販売やイベントが早期にキャンセルされるか、表示から削除されることを意味する場合があります。 何らかの理由で在庫ソースがダウンした場合の対処方法についての期待を考慮し、店主と話し合う必要があります。これにより、不幸な状況で引き継がれる自動プロセスを誰もが認識できるようになります。

まとめ

リアルタイムの在庫チェックを行う決定は重要です。 Web サイトの所有者、開発チーム、その他のユーザーが十分な教育を受け、すべての利益と潜在的な落とし穴を認識していることを、開発者のリードまたはアーキテクトに任せます。 理由とフォールバックプロセスをカバーする思慮深いプランを提供することが、成功の鍵です。

ライブインベントリチェックは実行できますが、QA サイクル中のテストと検証に関する調査と思考が必要です。 負荷テストとエンドツーエンドの自動テストを確実に行うことで、潜在的なすべての問題が把握され、トリアージが実行されるようになります。

外部システムへの呼び出しが失敗した傾向を監視が検出した場合、または応答時間が許容できるしきい値を超えた場合に実行するアクションを検討することで、サイトをオンライン状態に保ち、顧客に対する刺激を最小限に抑えることができます。 フォールバックオプションは、外部の在庫チェックをオフにしてネイティブ機能を使用するのと同じくらい簡単なことも、プロモーションを無効にして、エスカレートする問題を開発チームに通知したり、または利用可能な場合は 2 番目または 3 番目のバックエンドシステムへのリクエストを再ルーティングしたりするのと同じくらい高度なこともあります。 どの統合にもある時点で問題が発生するので、フォールバックメカニズムがどのように適用されるかは、実際の実装として考える必要があります。 自動化された内容や手動による操作が必要な内容については、明確に文書化する必要があります。