複数のサブオーケストレーションを持つメインオーケストレーションがあります。すべてのルート オーケストレーションはトランザクション タイプ: なしであるため、すべてのサブも同じ性質です。これで、すべての例外がメイン オーケストレーションの親スコープでキャッチされ、ログ記録などのいくつかの手順が実行されます。オーケストレーションは、App SQL からのメッセージでアクティブ化されます。そのため、例外が発生するたびに、Web サービスに接続できないなどの断続的な原因が考えられます。後で手動で再トリガーします。
オーチを自己修復するように変更することを検討しています。たとえば、例外キャッチブロックから、問題が断続的であるという条件に基づいてメッセージを再初期化します。app issue-null 参照のようなものです。orch が機能しないため、メッセージを再送信したくありません。
補償と呼ばれる概念がありますが、これはトランザクション ベースの orch- 1 つでも失敗した場合はステップを実行し、他のステップを実行します (代替アクションまたはクリーンアップを実行します)。
私が持っている唯一のアイデアは、例外のキーワードに基づいてルックアップを行い、メッセージを再送信することを決定することです. しかし、誰かにこれに異議を唱えるか、より良いアプローチを提案してもらいたい