BizTalk Server から Azure Logic Apps への移行アプローチ
このガイドでは、移行ソリューションの成功に役立てていただけるように、移行戦略とリソース、および計画時の考慮事項とベスト プラクティスについて説明します。
注意
移行の概要と、実際の移行のための Azure のサービスを選ぶ方法のガイドについては、次のドキュメントを参照してください。
戦略のオプション
次のセクションでは、さまざまな移行戦略と、その利点と欠点について説明します。
ビッグバン
"ビッグバン" つまり "ダイレクト チェンジオーバー" というアプローチでは、十分な計画が必要であり、組織が Azure Logic Apps に慣れていない場合や、大規模なシステムまたはソリューションを移行する場合には推奨されません。 組織が新しいテクノロジ スタックを実装するときは、通常、その結果として新しい学びがあります。 投資が早すぎたり多すぎたりすると、多大な再作業のリスクなしで教訓を活かして調整するという機会が得られなくなります。
このアプローチでは、価値が得られるまでの時間が長くなる可能性もあります。 一部の移行アクティビティを既に完了しているけれども、他の保留中または進行中の作業が理由でまだ実稼働にリリースできていない場合は、移行済みの成果物は組織にとっての価値を生み出していません。
このアプローチは、小規模で複雑性の低い BizTalk ワークロード、BizTalk 環境を理解している領域の専門家 (SME)、現在使用している BizTalk 機能と Azure Logic Apps 間の直接マッピングがある場合にのみ検討することをお勧めします。 また、Azure Logic Apps の経験があれば、このアプローチに従うことでリスクを大幅に軽減できます。
反復またはウェーブ ベース (推奨)
このアプローチでは、組織が得られる価値は漸増的ですが、他の方法の場合に比べて早く実現できる可能性があります。 プロジェクト チームは振り返りを使用して、テクノロジ スタックについて早期に学習できます。 たとえば、既存の BizTalk インターフェイスまたはプロジェクトを運用環境にデプロイしてから、そのソリューションのニーズについて (これには管理、スケーラビリティ、オペレーション、監視が含まれます) 学習します。 この知識を得た後にスプリントを計画して、既存の機能を最適化する、あるいは将来の作業で使用できる新しいパターンを導入することができます。
どのアプローチを取るかに関わらず、Azure Logic Apps または Azure 全般への移行を計画している場合は、BizTalk Server のソリューションをリファクタリングしてサーバーレスまたはクラウドネイティブのソリューションにしてからサーバー インフラストラクチャの使用を停止することを十分に検討してください。 この選択は、組織がビジネスを変革して完全にクラウド化したい場合の優れた戦略の 1 つです。
BizTalk Server と Azure Logic Apps のアーキテクチャは異なります。 ソリューションをさらに最新化するには、Azure 統合サービスを使用して、お客様の主要な統合ニーズに対応する Azure Logic Apps の機能を拡張できます。
投資収益率 (ROI) を高めるために、BizTalk の移行では、できる限り Azure Logic Apps (Standard) のコア ネイティブ機能を使用し、必要に応じて他の Azure 統合サービスを使用して拡張することをお勧めします。 この組み合わせにより、次のような追加のシナリオが可能になります。
- ハイブリッド デプロイによる Azure Logic Apps (Standard) を使用したクラウド ネイティブ ハイブリッド機能
- Azure Logic Apps (Standard) のステートフルまたはステートレス ワークフロー機能
- ネイティブの組み込み (アプリ内) メインフレームおよびミッドレンジと Azure Logic Apps (Standard) のコネクタとの統合
- Azure Service Bus を使用した pub/sub メッセージング
- Azure API Management の高度な SOAP 機能
BizTalk 移行プロジェクトを実現する
このようなプロジェクトを完了するには、反復的またはウェーブベースのアプローチに従い、スクラム プロセスを使用することをお勧めします。 スクラムにはスプリント前のアクティビティに関するスプリント ゼロ (スプリント 0) の概念は含まれていませんが、最初のスプリントはチームの調整と技術的な検出に重点を置くことをお勧めします。 スプリント 0 の後は、複数の移行スプリントを実行し、実用最小限の製品 (MVP) に向けて機能をリリースすることに重点を置きます。
スプリント 0
このスプリント中に、ウェーブ計画を使用して BizTalk Server 環境の検出を実行することをお勧めします。 プロジェクトの規模と深さを理解することは成功のために不可欠です。 次の一覧には、スプリント 0 中に対処すべき特定の領域が含まれています。
| 領域 | 説明 |
|---|---|
| 探索 | すべてのインターフェイスとアプリケーションに関するデータをキャプチャします。これで、移行が必要なインターフェイスとアプリケーションの数を知ることができます。 また、各インターフェイスまたはプロセスに複雑さを割り当てる必要もあります。 このカタログ作成プロセスでは、作業に優先順位を付けるために次の情報を収集します。 - 使用中のアダプター - 使用中の BizTalk Server の機能 (ビジネス アクティビティの監視、ビジネス ルール エンジン、EDI など) - カスタム コード (式、マップ、パイプライン コンポーネントなど) - メッセージのスループット - メッセージのサイズ - 依存関係 - アプリケーションとシステムの依存関係 |
| アーキテクチャの設計 | 移行の中心となる大まかなアーキテクチャを作成します。 この設計には、大まかな機能および非機能のニーズに対応する要素を含めます。 |
| 実用最小限の製品 (MVP) の定義 | 最初のウェーブ機能を定義します。 言い換えると、最初のウェーブを完了した後にサポートが必要なプロセスです。 |
| 初期移行バックログ | 最初のウェーブの機能と作業項目を技術的に詳細に定義します。 |
検出ツール
移行を検出するために、Microsoft のオープンソース プロジェクトである Azure Integration Migrator コマンドライン ツール (BizTalk Migration ツールとも呼ばれます) を使用できます。 このツールは段階的なアプローチを使用しており、ソリューションをクラウドに移行するための有益な分析情報と戦略を明らかにするのに役立ちます。 移行ツールは検出とレポート生成のみに使用することをお勧めします。 この分野のソリューションを提供するパートナーの他の製品を使用して検出を行うことも検討できます。
BizTalk Server 要素を含むインベントリを生成する別の方法として、Mark Brimble が開発した The BizTalk Documenter を使用できます。 このツールは、サポート対象は BizTalk Server 2016 のみと記載されていますが、BizTalk Server 2020 でも動作します。
アーキテクチャの設計
Azure Logic Apps には、BizTalk Server の資産を再利用できる機能がありますが、より新しい機能の利点を活用するには、最新のアーキテクチャ設計が必要です。 機能の観点からは、できる限りビジネス ロジックを使用します。 製品の最新化の観点からは、できる限り Azure 統合サービスを使用します。 品質と分野横断的な懸念事項がある場合は、Azure Well-Architected フレームワークを使用することをお勧めします。
このフレームワークでは、BizTalk の移行はミッションクリティカル ワークロードです。 この用語は、プラットフォーム上で高可用性を必要とするアプリケーション リソースのコレクションを指します。つまり、常に使用可能であり、機能し、障害に対する回復性を備えている必要があります。
BizTalk 移行のアーキテクチャ設計を完了するには、「Azure でのミッション クリティカルなワークロードの設計手法」に従ってください。 初期のアーキテクチャとトポロジについては、Azure アーキテクチャ センターの「Azure での基本的なエンタープライズ統合」で説明されているリファレンス アーキテクチャを確認して使用してください。
初期環境を設定するには、Azure 統合サービス ランディング ゾーン アクセラレータを使用します。これは、一般的なエンタープライズ ランディング ゾーン設計を使用した統合プラットフォームの構築とデプロイを目的としています。
実用最小限のプロジェクト (MVP) の定義
MVP は、お客様が使用できる十分な機能を備えた製品バージョンです。 このバージョンは、お客様のフィードバックを収集して作業を継続する製品の可能性と将来性を示しています。 BizTalk 移行の場合、MVP の定義には、機能の実用化に向けて進み、初期統合ワークロードを満たすために必要なイテレーション、ウェーブ、またはスプリントのグループが反映されます。
MVP の定義には次のビジネスの結果を含めることをお勧めします。これは、スクラム用語では "エピック" と表現されます。
ビジネスの結果 (エピック)
- 達成したい主な目標は何ですか?
- この MVP で対応する必要がある機能または特徴は何ですか?
- どのようなビジネス プロセス フローがありますか? この質問は、BizTalk Server でサポートされている既存のプロセスを最適化する機会となります。
- どのようなビジネスの決定事項がありますか? (MVP に影響を与えるビジネスの結果、リソースの可用性など)
MVP には、以下のスコープ内のプロセスを含めることをお勧めします。これらは、スクラム用語では "機能" と表現されます。
スコープ内のプロセス (機能)
| 機能 | 説明 |
|---|---|
| 高度なシステム機能 | 検出ツールを使用してこの情報を抽出し、機能の観点から説明を表現できます。 |
| アクターまたはペルソナ | この情報を使用して、MVP がサポートするシナリオの影響を受ける個人を特定します。 |
| オーケストレーション | この情報は、検出ツールを使用して抽出できます。 |
| データ エンティティとメッセージ | これらの要素により、BizTalk Server 環境によって交換されるデータにさらに改善を加えることができるかどうかを理解できます。 |
| データ マッピング | 現在、一般的には JSON が利用されています。 ただし、BizTalk Server は XML を使用します。 新しいプラットフォームのデータ形式と変換のニーズを決定するには、このときが絶好の機会です。 |
| ビジネス ルール | このようなデータ中心の規則により、そのアプローチを再考したり、Azure Logic Apps の機能を採用して再利用したりする機会が生まれます。 |
| データのプライバシーに関する考慮事項 | プライバシーを最優先にする必要があります。 デプロイ環境は変わる可能性があるので、お客様が Azure Logic Apps (Standard) のハイブリッド デプロイ モデルを選択しない限り、各ウェーブでこの領域に対処する必要があります。 |
| 規制に関する考慮事項 | お客様がクラウドベースのワークロードを持っていない場合、この側面がより重要になります。 |
| 設計によるセキュリティ保護 | セキュリティを念頭に置いて各機能を設計する必要があります。 |
| 共存のために提案される機能 | 各ウェーブをリリースするときには、ある程度の共存があります。 このハイブリッド アーキテクチャを既存のサービス レベル インジケーター (SLI) およびサービス レベル目標 (SLO) に合わせる必要があります。 |
| 機能以外の考慮事項 | ビジネス プロセスには、さまざまな機能以外の要件が存在する場合があります。 すべてをリアル タイムで実行する必要はありません。 逆に、すべてがバッチ プロセスであるとは限りません。 |
| ビジネス メトリック | 移行作業の進行状況を示す省略可能な機会。 |
また、MVP の作業スコープを形成するさまざまなスコープ外の変数を特定して一覧表示することもできます。次に例を示します。
- リソースの空き時間
- リスク
- ドキュメント
- 市場投入期間
初期バックログ
"初期バックログ" は一連のユーザー ストーリーであり、これを機能にグループ化して、MVP のスコープ内のプロセスを構築します。 言い換えれば、MVP は、エピック、機能、ユーザー ストーリーというスクラム項目によって表されます。 理想的には、各エピックに BizTalk アプリケーションまたは BizTalk プロジェクトのグループを含めます。 1 つの BizTalk アプリケーションまたは BizTalk プロジェクトを機能に関連付けるという単純な規則を使用できます。
たとえば、お客様が銀行ローンを要求するために使用する "LoanRequests" というオーケストレーションを備えた BizTalk Server プロジェクトがあるとします。 そこで、次のような機能とユーザー ストーリーが提案されています。
機能: ローン処理
ユーザー ストーリー: "顧客としてローン申請を送信して、自分のセキュリティで保護された口座に銀行が資金を追加できるようにしたい。"
このユーザー ストーリーは、現在 BizTalk Server の実装として存在している可能性があり、Azure Logic Apps と Azure 統合サービスを使用して実装するには、次のタスクがあります。
- BizTalk の再利用可能な成果物を収集します。
- Azure Logic Apps を使用してローン要求ワークフローを作成します。
- Azure Service Bus または IBM MQ を使用して非同期メッセージングを構成します。
- Azure Logic Apps ワークフローを使用して、JSON を XML データにマップします。
- 必要に応じてメッセージング パターンに合わせて Azure 統合サービスをカスタマイズします。
次のダイアグラムは、ユーザー ストーリーをさらに細分化したエピック、機能、ユーザー ストーリー、タスクの推奨期間を示しています。 実装の決定はこれらの期間に影響しますが、Azure Logic Apps の既存の BizTalk 成果物を使用していることを前提としています。 できる限り事前構築済みのワークフロー テンプレートを使用して、Standard ワークフローを作成します。
移行ウェーブ (スプリント)
チームがスプリント 0 を完了すると、構築すべき MVP が明確にわかるはずです。 "ウェーブ" は一連のスプリントです。 初期バックログには、可能な限り次のダイアグラムに示すような作業項目を含めるようにします。
ウェーブ中に、チームは移行、テスト、運用環境へのリリースに向けてアクティビティを完了します。 それぞれのウェーブで何が行われるかを詳しく見てみましょう。
移行
各ウェーブでは、移行は同意されたユーザー ストーリーに焦点を当てます。 最初のウェーブでは、チームは初期バックログに焦点を当てます。 テクノロジの決定には、「機能の比較 - BizTalk Server から Azure Logic Apps に移行する理由」で説明されている BizTalk Server の機能マッピングの情報を参考にする必要があります。
次のダイアグラムは、移行ウェーブ中に発生するはずのイベントを示しています。
| Step | 説明 |
|---|---|
| 1 | 既存の BizTalk アプリとインターフェイスを確認します。 スプリント 0 で導入されていますが、このアクティビティは各ウェーブの開始時に行うようにします。 お客様は BizTalk 環境に変更を加え続ける可能性があります。 リソース: - BizTalk 移行ツール - BizTalk Documenter ツール |
| 2 | 初期移行環境を設定します。 Azure 統合サービス ランディング ゾーン アクセラレータを使用できます。これは、一般的なエンタープライズ ランディング ゾーン設計である統合プラットフォームを構築およびデプロイするためのクラウド デプロイ フレームワークです。 ワークロード所有者は、提供されているアーキテクチャ ガイダンスと BizTalk 移行リソースを使用することで、目標とする技術状態を確実に達成できます。 アーキテクチャの例については、移行環境の例を参照してください。 |
| 3 | Azure portal または Azure Logic Apps (Standard) 拡張機能をインストールした Visual Studio Code を使用して、シングルテナント Azure Logic Apps で実行される Standard ロジック アプリ ワークフローを作成してテストします。 Visual Studio Code を使用すると、任意のソース管理システムを使用してロジック アプリ プロジェクトをローカルで開発、テスト、保存できます。 詳しくは、次のドキュメントをご覧ください。 - Azure portal を使用してサンプルの Standard ロジック アプリ ワークフローを作成する - Visual Studio Code を使用してサンプルの Standard ロジック アプリ ワークフローを作成する ロジック アプリの例と接続を示すダイアグラムについては、移行環境の例を参照してください。 |
| 4 | Standard ロジック アプリのワークフローをさまざまな環境やプラットフォームに簡単かつ一貫してデプロイすることによる恩恵を最大限を受けるには、ビルドとデプロイのプロセスも自動化する必要があります。 Visual Studio Code の Azure Logic Apps (Standard) 拡張機能には、Azure DevOps を使用して自動化されたビルドとデプロイのプロセスを作成および維持するためのツールが用意されています。 詳細については、「Azure DevOps を使用して Standard ロジック アプリ ワークフローのビルドとデプロイを自動化する」を参照してください。 |
| 5 | 更新中やメンテナンス中であっても、常に利用可能で応答性の高いミッション クリティカルな Standard ロジック アプリをデプロイするには、デプロイ スロットを作成して使用することで、ダウンタイムなしのデプロイを実現します。 ダウンタイムなしとは、アプリの新バージョンをデプロイする場合に、エンドユーザーが中断やダウンタイムを経験しないことを意味します。 詳細については、「Azure Logic Apps でダウンタイムなしのデプロイを可能にするデプロイ スロットを設定する」を参照してください。 |
次のダイアグラムは、API、サービス、ハイブリッド ソリューション、オンプレミス リソースと通信するワークフローを調整する Standard ロジック アプリを使用した初期移行環境の例を示しています。
テスト
各 "ウェーブ" には独自のテスト アクティビティがあり、各ユーザー ストーリーに埋め込まれています。 シフトレフト テストを使用する場合は、必ず次のタスクを完了してください。
テストを自動化します。
Azure Logic Apps (Standard) には、自動テストを実行する機能が含まれています。 次のリストに、GitHub 上で自由に利用できるその他の情報とリソースを示します。
Logic Apps Standard での自動テスト (Azure Logic Apps チームから)
Azure Logic Apps (Standard) で、自動テストは実行が難しいものではなくなりました。その基になるアーキテクチャは Azure Functions ランタイムをベースとしており、Azure Functions を実行できる場所ならどこでも実行できるからです。 ローカルで、または CI/CD パイプラインで実行されるワークフローのテストを作成できます。 詳細については、Azure Logic Apps テスト フレームワークのサンプル プロジェクトを参照してください。
このテスト フレームワークには以下の機能が含まれています。
- Azure Logic Apps でのエンド ツー エンド機能の自動テストを作成します。
- 粒度の高い検証をワークフローの実行とアクションのレベルで実行します。
- テストを Git リポジトリにチェックインし、ローカルまたは CI/CD パイプライン内で実行します。
- HTTP アクションと Azure コネクタのモック テストが可能です。
- 実稼働とは異なる設定値を使用するようにテストを構成します。
統合プレイブック: Logic Apps Standard テスト (Microsoft MVP Michael Stephenson 氏から)
この統合プレイブック テスト フレームワークは、Microsoft 提供のテスト フレームワークに基づくものであり、次に示す追加のシナリオがサポートされます。
- Standard ロジック アプリのワークフローに接続します。
- ワークフローをテストからトリガーできるようにするためのコールバック URL を取得します。
- ワークフロー実行の結果を確認します。
- ワークフローの実行履歴から操作の入力と出力を確認します。
- ロジック アプリ開発者が使用している自動テスト フレームワークに接続します。
- ロジック アプリの振る舞い駆動開発 (BDD) をサポートする SpecFlow に接続します。
どのオートメーション アプローチやリソースを使用するかに関わらず、反復可能で一貫性のある自動化された統合テストを実行できるようになります。
静的な結果を使用するモック応答テストを設定します。
自動テストを設定したかどうかにかかわらず、Azure Logic Apps の静的な結果機能を使用して、アクション レベルでのモック応答を一時的に設定できます。 この機能を使用すると、呼び出したいシステムの動作をエミュレートできます。 これで、初期テストの一部を分離して実行できるので、基幹業務システム内に作成する必要のあるデータの量を減らすことができます。
サイド バイ サイド テストを実行します。
理想的には、この時点で BizTalk Server 環境のベースライン統合テストが作成済みであり、Azure Logic Apps の自動テストが確立済みです。 これで、テストをサイド バイ サイドで実行できるので、同じデータ セットを使用してインターフェイスを確認して、全体的なテスト精度を向上させることができます。
運用環境へのリリース
チームが作業を完了し、ユーザー ストーリーの "完了の定義" を満たしたら、次のタスクを検討します。
運用環境へのリリースに関するコミュニケーション計画を作成します。
"カットオーバー" 計画を作成します。
カットオーバー計画の内容は、現在のプラットフォームから新しいプラットフォームに切り替えるために必要なタスクとアクティビティの詳細であり、これにはチームが実行する予定のステップが含まれます。 次の考慮事項をカットオーバー計画に含めてください。
- 前提条件となる手順
- 予行演習
- People
- スケジュール見積もり
- 古いプラットフォームでのインターフェイスの無効化
- 新しいプラットフォームでのインターフェイスの有効化
- 検証テスト
ロールバック計画を決定します。
検証テストを実行します。
運用または実稼働のサポートを計画します。
運用環境へのリリースに関する "実行するかしないか" の条件を選択します。
チームの成功を祝います。
振り返りを開催します。
BizTalk 移行のベスト プラクティス
ベスト プラクティスは組織によって異なるかもしれませんが、一貫性を促進するための意識的な取り組みを検討してください。このことは "車輪を再発明する" という不要な作業と、類似の共通コンポーネントの冗長性を減らすのに役立ちます。 再利用が可能になるように手助けすれば、あなたの組織はより速くインターフェイスを構築できるようになり、そのサポートも容易になります。 市場投入までの時間はデジタル変革の重要なイネーブラーであるため、最優先事項の 1 つは開発者とサポート チームにとって不要な摩擦を減らすことです。
独自のベスト プラクティスを確立するときは、次のガイダンスに合わせることを検討してください。
Azure リソースの全般的な名前付け規則
適切な名前付け規則を設定し、リソース グループから各リソースの種類に至るまで、すべての Azure リソースに一貫して適用してください。 見つけやすさと、サポートのしやすさのための強固な基礎を作るために、適切な名前付け規則によって目的を伝えます。 名前付け規則の最も重要なポイントは、規則があることと、組織がそれを理解していることです。 どの組織にも微妙な違いがあり、それを考慮に入れる必要があります。
この慣行に関するガイダンスについては、次の Microsoft の推奨事項とリソースを確認してください。
- Azure リソースの省略形の例
- Azure Naming Tool によって Azure 準拠の名前が生成されるため、名前の標準化に役立ち、名前付けプロセスを自動化できます。
Azure Logic Apps リソースの名前付け規則
ロジック アプリとワークフローのための設計は、重要な出発点となります。なぜなら、開発者が一意の名前を作成するための柔軟性はこの領域によって決まるからです。
ロジック アプリのリソース名
従量課金 (Consumption) と Standard のロジック アプリ リソースを区別するために、次の例に示すような異なる省略形を使用できます。
- 従量課金: LACon
- Standard: LAStd
組織の観点からは、設計する名前付けパターンの中に事業単位、部署、アプリケーション、および必要に応じてデプロイ環境 (たとえば DEV、UAT、PROD) を含めることができます。次に例を示します。
LAStd-<*business-unit-name*>-<*department-name* or *application-name*>-<*environment-name*>
あなたはある Standard ロジック アプリを開発中であり、これによってコーポレート サービスという事業単位の中の人事 (HR) という部署のワークフローを実装するとします。 このロジック アプリ リソースに LAStd-CorporateServices-HR-DEV といった名前を付け、一貫性を保つために必要に応じてパスカル ケース表記を使用します。
ロジック アプリのワークフロー名
1 つの従量課金ロジック アプリ リソースは常に 1 つのワークフローにのみマップされるため、必要な名前は 1 つだけです。 1 つの Standard ロジック アプリ リソースには複数のワークフローを含めることができるため、名前付け規則はメンバー ワークフローにも適用できるように設計します。 これらのワークフローについては、プロセス名に基づく名前付け規則を検討します。次に例を示します。
Process-<*process-name*>
これで、たとえば従業員オンボーディングのタスク (従業員レコードの作成など) を実装するワークフローがある場合に、このワークフローの名前は Process-EmployeeOnboarding などとなります。
ワークフローの名前付け規則の設計に関するその他の考慮事項を次に示します。
- 1 つ以上のワークフロー間の関係を強調する必要があるワークフローについては親子パターンに従います。
- ワークフローがメッセージを発行する側か、使用する側かを考慮します。
ワークフロー操作の名前
ワークフローにトリガーまたはアクションを追加すると、デザイナーによって、その操作の既定の汎用名が自動的に割り当てられます。 ただし、操作名はワークフロー内で一意である必要があるため、デザイナーによって後続の操作インスタンスに連番のサフィックスが追加されますが、その結果として読みやすさが低下し、開発者の元の意図を解読することも困難になります。
意味のある、わかりやすい操作名にするには、既定のテキストの後に短いタスク記述子を追加し、パスカル ケース表記を使用して一貫性を保ちます。 たとえば、JSON の解析 (Parse JSON) というアクションには、Parse JSON-ChangeEmployeeRecord などの名前を使用します。 このアプローチやその他の類似の方法ならば、このアクションが JSON の解析であることと、そのアクションの具体的な目的をずっと覚えておくことができます。 そのため、このアクションの出力を後で、ダウンストリームのワークフロー アクションで使用する必要がある場合に、その出力をより簡単に識別して見つけることができます。
注意
組織内で式が多用されている場合は、空白 (' ') の使用を助長しない名前付け規則を検討してください。 Azure Logic Apps の式言語では、空白がアンダースコア ('_') で置き換えられるため、作成作業が複雑になる可能性があります。 最初から空白を回避していれば、式を作成するときの摩擦を減らすことができます。 代わりに、ダッシュつまりハイフン ('-') を使用すれば読みやすくなり、式の作成にも影響しません。
ダウンストリームの依存関係 (操作の出力を使用するときに作られます) に関して、後で発生する可能性のある再作業や問題を回避するには、操作をワークフローに追加したらすぐにその名前を変更します。 通常は、操作の名前を変更するとダウンストリームのアクションが自動的に更新されます。 ただし、名前変更を実行する前に作成したカスタム式の名前が Azure Logic Apps によって自動的に変更されることはありません。
接続名
ワークフローの中に接続を作成すると、基になる接続リソースに sql や office365 のような汎用名が自動的に付けられます。 操作名と同様に、接続名も一意である必要があります。 同じ種類の後続の接続には連番のサフィックスが付けられて、たとえば sql-1、sql-2 などとなります。 このような名前ではコンテキストがわからないため、ワークフローへの接続を区別してマップすることは非常に困難です。特に、ソリューション空間を知らず、ワークフローを保守する必要がある開発者にとってはそうです。
そのため、意味のある、かつ一貫性のある接続名は、次の理由で重要です。
- 読みやすさ
- 知識の移転とサポートの容易さ
- ガバナンス
ここでも、名前付け規則があることが重要ですが、形式はあまり重要ではありません。 たとえば、次のパターンをガイドラインとして使用できます。
CN-<*connector-name*>-<*logic-app-or-workflow-name*>
具体的な例として、OrderQueue ロジック アプリ ワークフロー内の Service Bus 接続の名前を CN-ServiceBus-OrderQueue という新しい名前に変更できます。 詳細については、Turbo360 (旧称 Serverless360) のブログ記事「ロジック アプリのベスト プラクティス、ヒント、テクニック: #11 コネクタの名前付け規則」を参照してください。
スコープと "実行条件" のオプションを使用して例外を処理する
スコープを使用すると、複数のアクションをグループ化して Try-Catch-Finally 動作を実装することができます。 デザイナーでは、スコープの内容を折りたたんだり展開したりして、開発者の生産性を向上させることができます。
このパターンを実装するときは、スコープ アクションと内部のアクションをいつ実行するかを、先行のアクションの実行状態 (成功、失敗、スキップ、タイムアウトのいずれか) に基づいて指定することもできます。 この動作を設定するには、スコープ アクションの実行条件 (runAfter) のオプションを使用します。
- 成功しました
- 失敗しました
- スキップされました
- タイムアウトしました
共有サービスを統合する
統合ソリューションを構築するときは、共通タスクのための共有サービスを作成して使用することを検討してください。 あなたのプロジェクト チームとその他の人が使用できるように、チームで共有サービスのコレクションを構築して公開することができます。 全員の生産性と統一性が向上し、組織のソリューションにガバナンスを適用できるようになります。 次の各セクションで、共有サービスの導入を検討することをお勧めする領域のいくつかについて説明します。
| 共有サービス | 理由 |
|---|---|
| 一元化されたログ記録 | 開発者がコードをインストルメント化して適切なログ記録を行う方法に関する共通パターンを提供します。 これで、インターフェイスの正常性とサポート可能性を判断するのに役立つ診断ビューを設定できるようになります。 |
| ビジネス追跡とビジネス アクティビティ監視 | ビジネスの領域専門家がビジネス トランザクションの状態をよりよく理解するとともにセルフサービス分析クエリを実行できるように、データをキャプチャして公開します。 |
| 構成データ | アプリケーションを環境間でより簡単に移動できるように、アプリケーション構成のデータをコードから分離します。 構成データへのアクセスに関しては、統一されて一貫性があり、簡単に複製可能なアプローチを用意してください。プロジェクト チームがデプロイに向けたアプリケーション構成に時間を費やすのではなく、ビジネスの問題の解決に集中できるようにするためです。 このとおりでない場合は、各プロジェクトが独自の方法でこの分離を行ったときに、スケール メリットを得られなくなります。 |
| カスタム コネクタ | Azure Logic Apps の事前構築済みコネクタがない内部システム用にカスタム コネクタを作成して、プロジェクト チームとその他の人々のためにシンプルにします。 |
| 共通データセットまたはデータ フィード | 共通のデータセットやフィードを、プロジェクト チームが使用できるように API またはコネクタとして公開し、"車輪の再発明" を回避します。 どの組織にも、エンタープライズ環境内でのシステム統合に必要な共通のデータ セットがあります。 |
次のステップ
ここでは、BizTalk Server のワークロードを Azure Logic Apps に移行する際に使用できる移行アプローチとベスト プラクティスについて詳しく説明しました。 このガイドに関する詳細なフィードバックを送るには、次のフォームをお使いください。