JA
English
Deutsch
Español
Français
Italiano
Português
Nederlands
Polski
Bahasa Indonesia
Русский
Українська
العربية
עברית
한국어本番環境向けカスタムコネクタでDynamics 365データを活用する
By Mirko Peters ·
Power PlatformとDynamics 365の連携を次のレベルへ引き上げるための、詳細ガイドへようこそ。特定のカスタムテーブルの取得、複雑な計算フィールドの処理、精密なOData クエリの実行を標準コンポーネントで行おうとして行き詰まったことがあるなら、あなただけではありません。標準ツールは迅速なアプリ開発に優れていますが、エンタープライズのアーキテクチャでは、きめ細かな制御、堅牢なエラー処理、そして強固なセキュリティ対策が求められることが多くあります。この包括的な記事では、カスタムコネクタがPower PlatformとDataverse Web APIの間のギャップをどのように埋め、データ環境を完全に掌握できるようにするかを解説します。
Automatically translated with AI from the original post. Read the English original
Power Platform と Dynamics 365 の連携を一段引き上げるための詳細ガイドへようこそ。標準のコンポーネントを使って特定のカスタムテーブルを取得したり、複雑な計算フィールドを実行したり、正確な OData クエリを発行しようとして行き詰まったことがあるなら、あなただけではありません。標準ツールはアプリを迅速に開発するうえで非常に優れていますが、エンタープライズのアーキテクチャでは、きめ細かな制御、堅牢なエラー処理、そして確実なセキュリティ上のガードレールが求められることがよくあります。この包括的な記事では、カスタムコネクタが Power Platform と Dataverse Web API の間のギャップをどのように埋めるのか、そしてデータの全体像を完全に掌握できるようにする方法を解説します。
この記事は、ポッドキャストのエピソードで取り上げた内容を文章で詳しくまとめたものです。音声による解説を聞き、細かなニュアンスや実際の導入事例を知りたい場合は、関連エピソードをぜひご覧ください: Expose Dynamics 365 APIs with Power Platform Custom Connectors。
キャッチコピー
標準コネクタでは足りないときも、自動化は諦める必要はありません。
学べること
- 標準のDynamics 365コネクタで不足している機能を見極める方法
- 必要なDynamics/Dataverse Web APIエンドポイントを見つける実践的な手順
- 安全なカスタムコネクタの構築（Azure AD経由のOAuth2、スコープ、サービスプリンシパル）
- 本番運用のパターン: フィルタリング、ページング、スロットリング、再試行、スキーマの変化への対応
- ガバナンス: DLP、RBAC、所有者、バージョン管理、監視、監査
問題を一文で言うと
標準コネクタでは、カスタムテーブル、計算フィールド、柔軟なフィルターを公開しきれないことがあります。カスタムコネクタを使えば、エンタープライズ向けの保護を備えたうえで、APIを完全に制御できます。
参照ブループリント（エンドツーエンド）
1) 発見
- 不足している要件（カスタムテーブル、列、高度なフィルター、アクション）を洗い出す。
- Dataverse Web API のメタデータ、ソリューション エクスプローラー、または API Inspector/Postman を使って、エンドポイントと論理名を確認する。
- サンプルのペイロードを使って、OData の $filter、$select、$expand クエリを検証する。
2) 保護
- Azure AD アプリの登録（シングルテナント、OAuth2）を作成する。
- Graph/Dataverse のアプリ ロールは必要最小限を付与し、ユーザー委任とサービス プリンシパルのどちらを使うかを決める。
- カスタムコネクタ用のリダイレクト URL を構成し、シークレットのローテーションを計画する。
3) 構築
- Power Platform で カスタムコネクタ（OpenAPI から作成、またはゼロから作成）を作成する。
- ホスト、基本パス、認証、アクション（GET/POST/PATCH）を定義し、クエリとボディのスキーマも含める。
- ポリシーを追加する: 指数バックオフによる再試行、ページング、既定ヘッダーの設定、タイムアウト。
4) ガバナンス
- 所有者を割り当て、環境（開発/テスト/本番）を設定し、DLP ポリシーの分類を行う。
- RBAC/セキュリティ グループで利用を制限し、スコープとデータ領域を文書化する。
- バージョン管理（v1、v2…）、変更履歴、廃止のスケジュールを定める。
5) 運用
- フロー実行とコネクタのテレメトリを監視し、4xx/5xx の急増や実行時間の長期化に対してアラートを設定する。
- サーキットブレーカーを追加し、429 のスロットリングに対してはキューに入れた再実行を行う。利用状況も追跡する。
- アクセス許可、シークレット、API の変更を四半期ごとにレビューする。
API 検出のクイックガイド
- 論理名を確認する: ソリューション内で、テーブルと列の 論理名（例:
new_pricetierlevelid）を確認する。 - Postman で クエリをテストする:
GET .../api/data/v9.2/new_warrantyclaims?$select=...&$filter=modifiedon ge {timestamp}- ルックアップには
$expandを使い、$countとページング（@odata.nextLink）を組み合わせる。
- 計算フィールドとロールアップ フィールド: 実体化されていてフィルター可能かを確認する。そうでなければ、サーバー側（FetchXML）または後続の処理で計算する。
- アクション/関数: CRUD では不十分な場合に、バインド/アンバインドのアクション（例:
CalculatePrice）を呼び出す。
セキュリティとプライバシーの保護
- OAuth2（Azure AD）を使い、API キーは使用しない。
- 最小特権: アプリ ロールは特定のテーブルと操作に限定し、バックグラウンド ジョブにはサービス プリンシパルを優先する。
- ユーザー帰属: 業務上、人の監査証跡が必要な場合は委任されたアクセス許可を使用します。
- DLP: コネクタをBusinessに分類し、個人向けサービスへの境界をまたぐフローはブロックします。
- データの最小化: 必要な列だけを
$selectで指定します。下流で個人情報（PII）をマスクし、該当する場合は環境のRLSを適用します。
本番環境のパターン（そのままコピーして使えるもの）
429/5xxに対する指数バックオフ
- 初期待機時間は2〜5秒とし、上限（例: 60秒）まで倍増させます。最大再試行回数は5〜7回とし、相関IDをログに記録します。
ページング
@odata.nextLinkに従います。可能な場合はサーバー側でページをまとめて集計します。上限の範囲内でページサイズを設定します（例:$top=5000）。
差分読み込み
modifiedon ge {lastRunUtc}でフィルターします。最後に成功したウォーターマークを保存し、クロックのずれに対処します。
冪等性
- 重複を避けるため、アップサート（
If-Matchまたは代替キーを使ったPATCH）を使用します。ソースIDを保存します。
スキーマの変化への対応
- 不足または追加されたフィールドを検出します。未知のフィールドは警告のみで処理を継続し、移行中はv1/v2のコネクタを並行して維持します。
ユースケースの例（カスタムコネクタでどのように解決するか）
- カスタムテーブルの同期（WarrantyClaims）
- アクション:
GET /new_warrantyclaims?$select=claimid,status,amount&$filter=modifiedon ge {ts} - フロー: 繰り返し → 申請を取得 → 各項目に対して実行 → Dataverse/ERPにアップサート
- 「VIPアカウント」の高度なフィルター
- アクション:
GET /accounts?$filter=new_vipstatus eq true and statuscode eq 1 - フロー: スケジュールでトリガー → VIPかつアクティブなアカウントのみ処理 → CSMに通知
- サーバーアクションの呼び出し（再計算）
- アクション: パラメーター（期間、セグメント）を指定して
POST /CalculateRevenue（非バインド）を実行します。 - フロー: オンデマンドまたはランブックから → アクションを呼び出す → 結果をレポート用テーブルに保存
監視と信頼性
- ダッシュボード: 成功率、平均レイテンシ、再試行回数、主なエラーコード、アクションごとのスループットを表示します。
- アラート: 継続的な429、認証失敗、P95を超えるレイテンシ、スキーマの不一致を対象とします。
- ログ: リプレイに備えて、テレメトリにリクエストID、パーティションキー、ウォーターマークを含めます。
- 回復性: 繰り返し失敗した場合のキューへの退避経路（例: Dataverseテーブル/Azure Queue）を用意します。
ガバナンスとライフサイクル
- オーナーの登録（アプリとコネクタ）、目的、データ領域、利用者を文書化します。
- 昇格ワークフロー: 本番（PRD）へは承認済みの成果物のみを昇格します。環境ごとのシークレットは接続参照で管理します。
- レビューの周期: 四半期ごとにアクセスレビュー、シークレットのローテーション、APIの非推奨チェックを行います。
- 廃止: 非推奨としてマークし、新しい接続をブロックし、移行後にサンセットします。
10ステップのクイックスタート（週単位の計画）
- 標準コネクタの不足点（テーブル、フィールド、フィルター、アクション）を洗い出します。
- Postmanで Web APIのエンドポイントとクエリを確認します。
- Azure ADアプリを登録し、委任かアプリのみかを決定します。
- カスタムコネクタを開発環境で作成し、アクションとスキーマを定義します。
- ポリシーを追加します: 再試行、ページング、ヘッダー、タイムアウト。
- 環境ごとに接続参照を作成します。
- パイロットフローを展開し、データ量、フィルター、冪等性を検証します。
- 監視とアラートを追加し、ランブックを文書化します。
- テスト環境と本番環境へ昇格させ、DLP/RBACで保護します。
- v1のドキュメントを公開し、v2を計画します（既知の制限、ロードマップ）。
よくある落とし穴（と対処法）
- 429によるスロットリング → バックオフとバッチ処理を実装し、スケジュールを分散させます。
- 権限の過剰付与 → 最小権限のアプリロールを使用し、ドメインごとにコネクタを分割します。
- シークレットの直接記述 → サービスプリンシパルとマネージドシークレットを使用し、四半期ごとにローテーションします。
- コネクタの乱立 → 中央カタログ、オーナー、バージョン管理ポリシーを整備します。
- スキーマの破損 → 開発環境でコントラクトテストを実施し、API変更時はv1/v2を並行実行します。
よくある質問
Q: カスタム/ISVテーブルにアクセスできますか？
A: はい。Web API経由で論理名を使用してください。適切なスキーマを持つアクションをコネクタに追加します。
Q: 委任かアプリのみか？
A: バックエンドやスケジュールジョブにはアプリのみを使用します。ユーザー単位の監査や制御が必要な場合は委任を使用します。
Q: DLPへの準拠はどう維持しますか？
A: Businessに分類し、境界をまたぐコネクタをブロックして、セキュリティグループ単位で利用を制限し、エクスポートをログに記録します。
Q: 大規模運用時のパフォーマンスはどうですか？
A: 読み取りをバッチ化し、差分クエリを使用し、429に対してはバックオフを行い、並列処理は慎重に行います。$topとフィルターを監視して調整します。
まとめ
Power Platform でカスタムコネクタを使いこなすと、開発者やアーキテクトは汎用的なソリューションの制約を回避し、Dynamics 365 Web API の強力な機能に直接アクセスできるようになります。検出、セキュリティ、ガバナンス、運用の回復性に関する体系立てた設計図に従うことで、組織のセキュリティ基準を損なうことなく、無理なく拡張できる自動化パイプラインを構築できます。既製のブロックからカスタム API へ移行するには、認証、スロットリング、ライフサイクル管理について慎重な計画が必要であることを忘れないでください。それでも、ビジネスデータを完全に自分の手で制御できるというメリットは大きいものです。
実際のシナリオをより深く掘り下げ、専門家の議論を聞き、次の Power Platform 実装を大きな成功に導く実践的なヒントを見つけるために、関連するポッドキャストの内容もぜひお聴きください。こちらからどうぞ: Expose Dynamics 365 APIs with Power Platform Custom Connectors。