私が受けた公式のアドバイスは、Azure Logic Apps と Azure Function Apps を相互に組み合わせて使用し、ロジック アプリでオーケストレーションを行い、Function Apps でワークフロー機能を提供することです。
channel9 のこのビデオでは、それについて詳しく説明しています...
https://channel9.msdn.com/Events/Ignite/Microsoft-Ignite-Orlando-2017/BRK3179
...私が見つけた問題は、Logic Apps エンジンはオーケストレーション エンジンであり、拡張できないため、ソリューションを完成させることができないということです。究極のソリューションは、ワークフローごとに関数を呼び出すビジネス プロセス用の Azure Logic App のようなものになると思います。実行する必要があります。
私は独自のワークフロー エンジンを構築し、Azure 関数内でホストしており、MS からのガイダンスはありません... 彼らの最良のアドバイスは、「プレミア フィールド エンジニア プログラムと年間 50,000 ポンドの契約を結んで、彼らに来てもらい、あなたとそれを構築します。」
私たちの場合、フロー/ビジネス プロセスはクライアントによって定義されるため、ビジネス ロジックがどのように実行されるか (たとえば、関数内にコードの固定ブロックを記述することによって) をハード コーディングしたり、関数をワークフローのように扱ったりすることはできません。アクティビティ (ここでは WF と考えてください) は MS のベスト プラクティスに従うことになりますが、フローが非常に複雑であるため、その方法でフローを実行するコストは、実行ごとに実際の費用がかかることがわかりました。
これが、関数内でフロー全体を実行するという結論に至った方法です。あなたの場合、関数から WF フローを実行して、私たちが持っているのと同じソリューションを実現できます。
これがすべて失敗するのは、関数に関する MS のガイダンスでは、関数は小さな作業 (アクティビティに最適) を実行するための高速で短期間の REST 呼び出しである必要があるため、フロー全体を埋め込むと何が起こるかわかりません。この時点で、年間5万ポンドの契約を結ばない限り、私が知る限り、基本的に「自分で」提供するサポートの範囲外で実行してください。
私の考えは...試してみて、制限をテストし、それらをコードに入れて、関数フレームワークが壊れないようにすることです。
これに照らして、私はフィードバック コミュニティを通じて、MS が関数をロジック アプリに埋め込み可能にすることを提案しました。これにより、オーバーヘッドと別のフロー エンジンを実装する必要性を直接取り除くことができます。
https://feedback.azure.com/forums/34192--general-feedback/suggestions/36979045-workflow-solution
...これが承認されれば、フローを呼び出すロジック アプリとしてビジネス プロセスを設計することができます。フローは他のロジック アプリとして構築され、完全なソリューションを完全に MS インフラストラクチャ上に "すぐに" スタックすることができます。ループを使用して、ロジック アプリが何かを実行できない場合にこれらすべてを適合させます。