分割払いPOC:概念実証の次のステップ
このチュートリアルで作成したデモダッシュボードとシミュレーションスクリプトは、意図的に大まかなものです。 そのパターンを証明するために存在しているのです。 概念実証から実稼動型App Builder開発までの実用的な道筋を説明します。
ステップ 1 - デモダッシュボードをExperience Cloud UI拡張機能に置き換える
demo-dashboard web アクションは、Node.js関数内の文字列からHTMLを提供します。 動作しますが、制作パターンではありません。
適切な置き換えは、commerce-checkout-starter-kitのcommerce-backend-ui-1拡張機能です。Adobe管理UI SDKを介してCommerce管理シェルに埋め込まれたReact アプリケーションです。 生成プロンプトについては、分割支払いPOC: Experience Cloud UI拡張機能AI プロンプト を参照してください。
変更内容:
- オペレーターは、Commerce管理シェル(共有シークレットではなくIMS認証)を介してログインします
- 注文リストでは、IMS トークンのコンテキストが使用されます。デモの秘密鍵は必要ありません
- 受け入れ/拒否アクションは、オペレーターのIMS IDにスコープされます
- UIは、Commerce管理者が既に知っているURLのCommerce管理者に埋め込まれています
同じままの状態:
payment-acceptとpayment-decline個のApp Builder アクションは変更されません- Commerce REST エンドポイントは変更されません
- PHP モジュールは変更されません
ステップ 2 – 実際のERPの接続
このPoCの承認/拒否フローは、人間がボタンをクリックすることによって実行されます。 ERP、CRM、決済代行会社などの主要なツールを使用して。
統合パターン:
- ERP システムが現金をキャプチャし、
POST /payment-accept(App Builder web アクション URL)を{ orderId: <entity_id> }で呼び出します - App Builderは呼び出し(ベアラートークンまたはAPI キー –
payment-acceptに認証ミドルウェアを追加)を検証します - App BuilderはCommerce REST
cash-receivedを呼び出します - Commerceの請求書と注文の出荷
PHPの変更は必要ありません。 REST サーフェスは既にそこにあります。 App Builderのアクションには、ダッシュボードボタンではなく安全な呼び出し元が必要です。
ERP呼び出し元の認証オプション:
- Adobe I/O Runtimeは、IMS トークンの
require-adobe-auth: trueをサポートしています(ERPでIMS トークンを取得できる場合) - Adobe以外のシステムの場合:
payment-acceptアクションにシンプルなAPI キーのチェックを追加します(アクションのenvに保存されている秘密鍵に対してヘッダーをチェックします)
ステップ 3 - API メッシュをブローカーレイヤーとして追加
現在、App BuilderはCommerce RESTをOAuth 1.0a資格情報で直接呼び出しています。 大規模なデプロイメントの場合、Adobe API Meshは、App BuilderとCommerceの間に管理されたゲートウェイレイヤーを提供します。
特典:
- 一元的な資格情報管理:API MeshはCommerceの資格情報を保持し、App BuilderはAPI Meshを呼び出します
- 変換をリクエスト — App Builder アクションを変更せずにApp Builder ペイロードをCommerce REST シェイプにマッピングします
- レートの制限とキャッシュ – 大量のイベントトラフィックからCommerceを守ります
パターン:
createCommerceClient(params, logger)呼び出しをAPI Mesh エンドポイントへの呼び出しに置き換えます- API Meshは、CommerceへのOAuth署名を処理します
ステップ 4 - PHP フットプリントを削減する
現在のPHP モジュールは、処理中に残す必要がある5つの処理を処理します(分割支払いPOC: アーキテクチャとデザインの決定を参照)。 Adobe CommerceのAPI サーフェスが成熟するにつれ、これらの一部が可動になる場合があります。
将来的に移動可能:
- ストアクレジット REST APIは進化しています。今後のバージョンでは、注文後または非アクティブなカートへのクレジットの適用をサポートする場合があります
- より多くのCommerce操作が非同期セーフになるにつれて、しきい値ガードを事前に注文されたAPI Mesh リゾルバーに移動できる場合があります
移動可能でない(アーキテクチャの制約):
- CommerceがAPI ファーストの拡張ポイントを介してクリーンフックを公開しない限り、
placeOrder()より前の見積もり操作には常にインプロセス コードが必要です - REST エンドポイント (
/V1/split-payment/*)は、この機能に固有です。Commerce内部サービスを呼び出すため、Commerceに存在します
ステップ 5 - App Builderにさらにワークフローを追加する
現在のPOCでは、注文の配置をリッスンしてから、受け入れ/拒否を有効にするという1つの操作が行われます。 自然な拡張:
承認する前に不正行為のスコアリング:payment-orchestratorで、現金保留を記録した後、オーケストレーション結果が最終的と見なされる前に、詐欺スコアリング APIを呼び出します。 スコアがしきい値を超えている場合は、オペレーターのアクションを待つのではなく、自動辞退します。
通知メール:payment-acceptが成功したら、現金の支払いが確定したことを通知する電子メール(Adobe Campaign、SendGrid、または任意のHTTPS API経由)をトリガーします。
ロイヤルティポイント特典:
現金が確認されたら、ロイヤルティ APIを呼び出してポイントを獲得します。 これは純粋なApp Builderであり、PHPは必要ありません。
タイムアウト処理:
スケジュールされたApp Builder アクション(app.config.yamlのcronを使用)を追加して、X日より古いsplit_cash_status = 'pending'件の注文をスキャンし、自動的に拒否します。
ステップ 6 – 実稼動環境へのデプロイ
PoCはStage ワークスペース用に設定されています。 本番環境への移行:
# Switch to production workspace
aio app use
# Select Production workspace
# Update .env for production
# (same credentials, but production Commerce base URL)
# Deploy
aio app deploy
実稼動準備のチェックリスト:
- [ ]
DEMO_UI_SECRETセット (またはデモ ダッシュボードはExperience Cloud UIに置き換えられました) - [ 実稼動環境の]
LOG_LEVEL=warnまたはerror(debugではありません) - [ ]
PAYMENT_THRESHOLDはCommerceの実稼動設定と一致します - [
.envの] Commerce統合資格情報は、専用の実稼動統合用です(ステージング用ではありません) - [ ] Fastly IPの許可リストに加えるがApp Builder実稼動エグレス IPで更新されました(Commerce Cloud)
- [ 実稼動ワークスペースで]個のI/O イベント登録が確認されました
アーキテクチャ進化図
PoC (this tutorial)
┌─────────────────────────────────────────────────┐
│ Commerce App Builder │
│ ┌─────────────┐ ┌──────────────────┐ │
│ │ PHP Module │◄────────│ payment-orchestr │ │
│ │ REST API │────────►│ payment-accept │ │
│ │ Checkout UI│ │ payment-decline │ │
│ └─────────────┘ │ demo-dashboard │ │
└─────────────────────────────────────────────────┘
Phase 2: Experience Cloud UI
┌─────────────────────────────────────────────────┐
│ Commerce App Builder │
│ ┌─────────────┐ ┌──────────────────┐ │
│ │ PHP Module │◄────────│ payment-orchestr │ │
│ │ REST API │────────►│ payment-accept │ │
│ │ Checkout UI│ │ payment-decline │ │
│ │ │ │ Admin UI ext. │ │
│ └─────────────┘ └──────────────────┘ │
└─────────────────────────────────────────────────┘
Phase 3: Real ERP + API Mesh
┌──────────────────────────────────────────────────────────┐
│ ERP ──► App Builder ──► API Mesh ──► Commerce │
│ (orchestrator) (gateway) (PHP module │
│ (accept) REST surface) │
└──────────────────────────────────────────────────────────┘
主な参考資料
関連する分割支払POC リソース
- 分割支払いPOCの構築:App BuilderとAI ツール
- 分割払いPOCの作成:App Builderの完全デモ
- 分割払いPOC:アーキテクチャとデザインの決定
- 分割払いPOC:前提条件と環境の設定
- 分割支払POC:環境変数リファレンス
- 分割支払いPOC: Commerce モジュール AI プロンプト
- 分割支払いPOC: App Builder orchestrator AI プロンプト
- 分割支払いPOC: Experience Cloud UI拡張機能AI プロンプト
- 分割払いPOC:テストと検証ガイド
- 分割払いPOC:概念実証の次のステップ
- 分割支払いPOC:作成者向けチュートリアルクイックリファレンス