オーケストレーション計画でのビジネスプロセスの変更

新規または置換ビジネスプロセスのモデル化方法の選択

上記のパターンで新規または置換ビジネスプロセスが導入された場合、そのビジネスプロセスをステップグループとしてモデル化するかステップとしてモデル化するかを決定します。選択した内容によって、後でどの程度簡単に変更できるかが決まります。

履行ステップ定義グループとして

Salesforce 内で完全に実行されるビジネスプロセスを履行ステップ定義グループ (ステップグループとも呼ばれる) としてモデル化します。ステップグループには、プロセスの順序付きステップが保持されます。より大きなビジネスプロセスは 1 つのステップグループに対応付ける必要はありません。複数のステップグループでそれぞれフラグメントを表すことができます。オーケストレーション計画のステップグループとステップの定義についての詳細は、「オーケストレーション計画コンポーネントの定義」を参照してください。

ステップとして

下流または外部履行システムをコールアウトステップなどのステップグループ内の 1 つのステップとしてコールするビジネスプロセスをモデル化します。

履行シナリオでは、注文に対して実行されるステップグループに商品がリンクされます。最初からライフサイクルフェーズ別にステップをグループ化します。まず、商品間で共通のステップを特定し、次に商品固有のロジックのみを個別のステップグループに分け、可能な場合はシナリオレベルで条件を適用します。この構造により、リファクタリングすることなくロジックパスを後から簡単に追加できます。

ビジネスプロセスの複数の設定の管理

多くの場合、ロールアウトフェーズでは、同じビジネスプロセスの複数の設定を一定期間共存させる必要があります。古い設定と新しい設定を一緒に実行する必要がある期間に適した共存モデルを選択します。

長期的な共存

耐久性のある条件で転送される並列シナリオを無期限に保持します。このモデルは、異なる商品または地域など、両方のバリエーションを保持する場合に使用します。

古い設定の注文が完了するまで共存

条件で新規注文の古い設定を抑制し、実行中の注文を期限切れにします。古い設定を参照するすべての注文が完了したら、古いステップグループ、ステップ、またはシナリオを破棄します。動的収益オーケストレーターでは、ステップグループ、ステップ、またはシナリオがまだ不完全なままである間にこの削除がブロックされます。処理中の注文が破損するリスクがあるため、メタデータの上書きでブロックをスキップするように強制しないでください。注文がすべて完了した抑制されたステップと廃止されたシナリオを定期的に確認し、削除します。多くの条件がある計画では、特に大規模注文の場合、処理遅延が増加し、プラットフォームの制限に近づく可能性があります。具体的な制限については、「動的収益オーケストレーターの制限」を参照してください。

中断後に新しい設定が古い設定を上書きする

日付ベースの条件を使用して、カットオフ前の注文では古い設定を使用し、カットオフ以降の注文では新しい設定を使用します。このモデルでは、ロジックが混在することなく、時間ベースのクリーンな移行が提供されます。

オーケストレーションの変更でコードを使用するケース

ほとんどのオーケストレーション計画の変更は、カスタムコードではなく、設定 (シナリオ、ステップ定義、条件、ステップ連動関係の変更) を使用して処理できます。設定変更は、条件を使用して制御し、既存のロジックと並行して実行できるため、段階的なロールアウト全体にリリースする方が安全です。Apex やフローなどのカスタムコードは、条件では表現できないロジックが変更で必要な場合にのみ使用します。

同じステップ定義を維持しながら、Apex やフローなどの基礎となるロジックを変更するのは、入力契約と出力契約が同じである場合にのみ安全です。パラメーターまたは必須のペイロードプロパティを変更すると、実行ステップが失敗する可能性があります。

注文の状態別のエンティティレベルの変更の影響

上記のパターンと共存モデルは、履行シナリオ、ステップ定義、条件、ステップ連動関係の 4 つのエンティティの 1 つ以上を編集することで機能します。次の表に、新規注文、実行注文、追加注文に対する各エンティティレベルの変更の影響をすべて示します。これにより、実行している特定の変更の結果を確認できます。