適用対象: Azure Logic Apps (Standard)
前の Discovery ステージでは、統合プロジェクトの設計、成果物、コンポーネント、依存関係に関する具体的な情報が得られますが、インベントリを実行可能な移行ロードマップに変えるという重要な課題に直面しています。 成果物とコンポーネントを Azure Logic Apps (Standard) で同等にマップする方法、再設計が必要な部分、および変換プロセスを開始する前にこれらのアクティビティに要する作業量に関する情報が必要です。
計画ステージでは、Visual Studio CodeのAzure Logic Apps移行エージェントはカタログ化された成果物を使用し、各論理フロー グループの詳細な移行計画を生成します。 この移行計画には、ターゲットアーキテクチャ、ワークフロー定義、必要なAzureコンポーネント、アクションマッピング、アーティファクトの判定、移行ギャップ、統合パターンが含まれます。 この知識があれば、予測可能性を高め、リスクの低い明確な計画を立て、コンバージョン ステージに進むことができます。
この記事では、Azure Logic Apps移行エージェントが計画段階で移行計画を作成する方法について説明します。 その後、この移行計画を使用して、変換プロセスを開始する前に、ソース成果物を Azure Logic Apps (Standard) にマップし、再設計のギャップを特定し、作業量を見積もることができます。
ステージ アクションの計画
Azure Logic Apps移行エージェントで、Analyze Source Design アクティビティを完了すると、Plan Logic App Design アクティビティが使用可能になります。 このアクティビティを選択すると、@migration-planner GitHub Copilot エージェントによって、フロー グループごとに次の情報が生成されます。
| セクション名 | 説明 |
|---|---|
| アーキテクチャ | 提案されたソリューションのデザイナー ビュー、コード ビュー、およびアーキテクチャ図。 |
| 追加Azure コンポーネント | 提案された設計に必要な明示的なAzureのコンポーネント変換と暗黙的なコンポーネント変換。 |
| 操作マッピング | ソース プラットフォーム コンポーネントから、Azure Logic Apps (Standard) での同等のコンポーネントへの 1 対 1 のマッピング。 例えば： - BizTalk FILE 受信ポートは、標準ワークフローの ファイル システム トリガーにマップされます。 - BizTalk HTTP 送信ポートは、標準ワークフローの HTTP アクションにマップされます。 詳細については、「 操作マッピング」を参照してください。 |
| 成果物の処理 | 変換とアップロード先を必要とする成果物。 |
| 移行のギャップ | Standard ワークフローに直接相当するものがない機能またはコンポーネントと、推奨される回避策。 たとえば、BizTalk カスタム パイプライン コンポーネントでは、標準ワークフローで.NETローカル関数が必要な場合があります。 詳細については、「移行の ギャップ」を参照してください。 |
| 統合パターン | 統合フローで検出されたパターン。 |
| まとめ | 提案されたワークフローの概要。 |
次の例は、生成された移行計画のサンプルを示しています。
次のセクションでは、特定の移行計画領域の詳細について説明します。
操作マッピング
[操作マッピング] セクションでは、各ソース コンポーネントが Standard ワークフロー内の同等のコンポーネントにどのようにマップされるかについて説明します。次に例を示します。
| ソース コンポーネント | 同等の標準ワークフロー | 操作の種類 | マッピングの種類 | 注記 |
|---|---|---|---|---|
| 受信ポート (FILE) | ファイル システム トリガー「ファイルが追加または変更されたとき」 | 組み込み | ランタイム ネイティブ | Azure Logic Apps ランタイムと同じプロセスで実行される built-in バージョンを選択します。
shared バージョンはマルチテナント Azureで実行されます。 詳細については次を参照してください: - ファイル システムの組み込みコネクタ リファレンス |
| 送信ポート (HTTP) | HTTP アクション | 組み込み | ランタイム ネイティブ | 詳細については、「Azure Logic Apps から外部の HTTP または HTTPS エンドポイントを呼び出す」を参照してください。 |
| オーケストレーションシェイプ (変換) | XML 変換という名前の XML 操作アクション | 組み込み | ランタイム ネイティブ | 詳細については、「Azure Logic Apps の |
| カスタム パイプライン コンポーネント |
Azure Functions 関数 または .NETローカル関数 |
組み込み | カスタム | コードの移行が必要です。 詳細については次を参照してください: - Azure Logic AppsからAzure Functionsを呼び出します |
移行のギャップ
特定されたギャップごとに、プランには次の情報が含まれます。
| 品目 | 説明 |
|---|---|
| ギャップの説明 | ソース コンポーネントの機能と、直接同等のものが存在しない理由。 |
| 推奨される解決方法 | .NETローカル関数、Azure Functions関数、カスタム コネクタの使用など、推奨される回避策。 |
| 作業量への影響 | ギャップが移行作業の見積もりにどのように影響するか。 |
プランを確認して調整する
移行エージェントが移行計画を生成したら、ロードマップと推奨事項を理解できるように、計画を慎重に確認します。 コンバージョン ステージに進む前に、シナリオに必要な更新を行います。 プランの精度は、変換出力の品質に大きく影響します。
プランの理解を深め、更新する必要があるかどうかを判断するには、次のタスクにVisual Studio CodeのCopilot チャットを使用して、@migration-planner GitHub Copilot エージェントと対話します。
- 特定のマッピングについて質問します。
- ギャップ解決のための代替アプローチを要求します。
- 変換に進む前に、プランの変更を要求します。
計画を承認・最終化した後、コンバージョンステージではこれらの計画結果を用いて、依存関係や任意の労力見積もりを含む順序付けられたコンバージョンタスクプランを作成します。
関連するコンテンツ
- 統合プラットフォームからAzure Logic Appsへの移行自動化
- Quickstart: Azure Logic Apps Migration Agent を使用して統合プロジェクトを移行します