新しいプロバイダーの作成

[アーティクル]
04/12/2024

新しいプロバイダーを作成するには、次の手順を使用します。また、既存のプロバイダーに追加する場合にも、この手順を使うことができます。

プロバイダーアーキテクチャの定義

プロバイダを作成する前に、プロバイダに何をさせたいのか、何に使用したいのかを理解しておくことは重要です。プロバイダーは複数のコンポーネントを持っていますが、すべてのコンポーネントが必要なわけではありません。

次のテーブルを使用して必要なコンポーネントを決定します。

条件	必要なコンポーネント
プロバイダを作成するサービスには、Power Automate にコネクタがありません。詳細については、すべての Power Automate コネクタの一覧を参照してください。	顧客コネクタを作成するか、ジェネリックコネクタを使用します。
プロバイダは、外部サービスと Microsoft Dataverse の間でデータを交換します。	プロバイダーはプロバイダー変換が必要です。変換ごとにプロバイダー変換コンポーネントを追加します。
プロバイダーは、オーケストレーションデザイナーからロジックを実行します。	各アクションを表す個別の Power Automate フローを作成します。
プロバイダーは、外部サービスからのメッセージを処理する必要があります。	Power Automate メッセージハンドラーフローを作成します。
プロバイダーは定期的な感覚で外部サービスからメッセージを取り込みます。	Power Automate メッセージプラーフローを作成します。
プロバイダーは、Intelligent Order Management で現在定義されていないビジネスイベントを発生させます。	新しいビジネスイベント定義を作成し、既存のイベントを追加します。

ソリューションをよく理解した上で、プロバイダーの実装に進みます。

プロバイダーソリューションの作成

プロバイダーソリューションを作成するには、このセクションの次のタスクを完了する必要があります。

カスタムプロバイダーを設定します。
プロバイダー定義を追加します。
コンポーネントをソリューションに追加します。

カスタムプロバイダーの設定

Power Apps でプロバイダーのコンポーネントを含むソリューションを作成します。 Power Apps で新しいソリューションを作成するには、Power Apps でソリューションを作成する。の手順に従ってください

プロバイダー定義の追加

プロバイダー定義には、プロバイダーに関する詳細が含まれています。この定義により、プロバイダーがプロバイダーカタログにどのように表示されるかを決定します。

作成したプロバイダーソリューションで、新規を選択します。
IOM プロバイダー定義 を選択します。
以下の詳細を追加します :
1. 表示名 : プロバイダーにつける名前で、例えば、"テストプロバイダー" などです。
2. 論理名 : プロバイダー用のエクスポートキーです。
3. 説明 : プロバイダーが何をするのかを説明するテキストです。
保存を選択します。
ロゴを追加する場合は、画像をアップロードします。
プロバイダー定義がソリューションに表示されることを検証します。コンポーネントタイプである IOM プロバイダー定義がレコードと共に表示されるはずです。表示されない場合は、既存の追加を選択し、先ほど作成したレコードを選択してください。
プロバイダーが、プロバイダーカタログに表示されることを検証します。有効フィールドではいに設定すると、プロバイダー定義がプロバイダーカタログに表示されます。 Intelligent Order Management を開きます。 プロバイダー > カタログに移動します。プロバイダー定義が表示されることを検証します。

ソリューションにコンポーネントを追加する

プロバイダー定義を作成した後、プロバイダーコンポーネントをソリューションに追加します。

ソリューションに移動します。
既存の追加を選択します。
Intelligent Order Management コンポーネントタイプを選択し、先ほど作成したレコードを選択します。

プロバイダー変換の作成

プロバイダーに変換が必要な場合は、ソリューションにプロバイダー変換コンポーネントを追加する必要があります。複数の変換を作成する必要があるかもしれません。

プロバイダーソリューションで、新規を選択します。
IOM プロバイダー定義変換を選択します。
以下の詳細を追加します :
1. 表示名 : プロバイダー変換の名前で、例えば、"販売注文の変換" などです。
2. 論理名 : プロバイダーの一意識別子です。この値は、データのインポートキーおよびエクスポートキーになります。これは、発行元の接頭辞から始まる必要があります。たとえば、Microsoft では発行元の接頭辞である msdyn_ を使用しています。論理名の例として、msdyn_flexe_fulfillmentorderproduct_orderline、および msdyn_flexe_fulfillmentorder_order があります。
3. ソースタイプ : このフィールドは、受信したデータのタイプを示します。次の 2 つのオプションがあります : JsonDocument または Dataverse エンティティです。データが Dataverse に既にある場合は、Dataverse エンティティを選択します。そうでない場合は JsonDocument を選択してください。この情報は、変換を検索するために定義した Power Automate 要素で使用されます。
4. ソースオブジェクト名 : 変換するデータの名前です。 Dataverse レコードを変換する場合は、ソースオブジェクト名が Dataverse テーブルと同じ名前であることを確認してください。
5. 送信先オブジェクト名 : 変換するレコードの送信先です。
6. 変換: 入力データの変換に使用される Power Query Online MQuery です。 Power Query および MQuery については、Power Query とは? およびPower Query 式の言語を参照を参照してください。次は、外部のオーダーサービスから Intelligent Order Management の販売注文に変換する MQuery の例です。

shared TransformSourceData =

let

orderItems = Source\[OrderItems\],

orderheader =

Record.FromTable

(

Table.SelectRows

(

Record.ToTable

(

\[

ordernumber = Record.FieldOrDefault(Source, "SellerOrderId", Text.From(Source\[OrderServiceOrderId\])),

name = ordernumber,

msdyn\_ExternalOrderId = Text.From(Source\[OrderServiceOrderId\]),

\#"customerid\_account@odata.bind" = "/accounts(" & Text.From(Source\[accountid\]) & ")",

\#"pricelevelid@odata.bind" = "/pricelevels(" & Text.From(Source\[pricelevelid\]) & ")",

totalamount = if Record.HasFields(Source, "OrderTotal") then Decimal.From(Record.FieldOrDefault(Source\[OrderTotal\], "Amount")) else null,

shipto\_name = if Record.HasFields(Source, "ShippingAddress") then Record.FieldOrDefault(Source\[ShippingAddress\], "Name") else null,

shipto\_contactname = shipto\_name,

shipto\_line1 = if Record.HasFields(Source, "ShippingAddress") then Record.FieldOrDefault(Source\[ShippingAddress\], "AddressLine1") else null,

shipto\_line2 = if Record.HasFields(Source, "ShippingAddress") then Record.FieldOrDefault(Source\[ShippingAddress\], "AddressLine2") else null,

shipto\_line3 = if Record.HasFields(Source, "ShippingAddress") then Record.FieldOrDefault(Source\[ShippingAddress\], "AddressLine3") else null,

shipto\_city = if Record.HasFields(Source, "ShippingAddress") then Record.FieldOrDefault(Source\[ShippingAddress\], "City") else null,

shipto\_stateorprovince = if Record.HasFields(Source, "ShippingAddress") then Record.FieldOrDefault(Source\[ShippingAddress\], "StateOrRegion") else null,

shipto\_country = if Record.HasFields(Source, "ShippingAddress") then Record.FieldOrDefault(Source\[ShippingAddress\], "CountryCode") else null,

shipto\_postalcode = if Record.HasFields(Source, "ShippingAddress") then Record.FieldOrDefault(Source\[ShippingAddress\], "PostalCode") else null,

shipto\_telephone = if Record.HasFields(Source, "ShippingAddress") then Record.FieldOrDefault(Source\[ShippingAddress\], "Phone") else null,

overriddencreatedon = Record.FieldOrDefault(Source, "PurchaseDate")

\]

), each \[Value\] \<\> null

)

),

orderlines = List.Transform(orderItems, each

Record.FromTable

(

Table.SelectRows

(

Record.ToTable

(

\[

isproductoverridden = true,

ispriceoverridden = true,

productdescription = \[OrderItemId\] & "-" & Record.FieldOrDefault(\_, "SellerSKU") & "-" & Record.FieldOrDefault(\_, "Title"),

quantity = \[QuantityOrdered\],

quantityshipped = Record.FieldOrDefault(\_, "QuantityShipped"),

priceperunit = if Record.HasFields(\_, "ItemPrice") then Decimal.From(Record.FieldOrDefault(\[ItemPrice\], "Amount")) else null,

manualdiscountamount = if Record.HasFields(\_, "PromotionDiscount") then Decimal.From(Record.FieldOrDefault(\[PromotionDiscount\], "Amount")) else null,

tax = if Record.HasFields(\_, "ItemTax") then Decimal.From(Record.FieldOrDefault(\[ItemTax\], "Amount")) else null,

shipto\_name = Record.FieldOrDefault(orderheader, "shipto\_name"),

shipto\_contactname = Record.FieldOrDefault(orderheader, "shipto\_contactname"),

shipto\_line1 = Record.FieldOrDefault(orderheader, "shipto\_line1"),

shipto\_line2 = Record.FieldOrDefault(orderheader, "shipto\_line2"),

shipto\_line3 = Record.FieldOrDefault(orderheader, "shipto\_line3"),

shipto\_city = Record.FieldOrDefault(orderheader, "shipto\_city"),

shipto\_stateorprovince = Record.FieldOrDefault(orderheader, "shipto\_stateorprovince"),

shipto\_country = Record.FieldOrDefault(orderheader, "shipto\_country"),

shipto\_postalcode = Record.FieldOrDefault(orderheader, "shipto\_postalcode"),

shipto\_telephone = Record.FieldOrDefault(orderheader, "shipto\_telephone"),

overriddencreatedon = Record.FieldOrDefault(orderheader, "overriddencreatedon")

\]

), each \[Value\] \<\> null

)

)

),

salesorder = Record.AddField(orderheader, "order\_details", orderlines)

in Text.FromBinary(Json.FromValue(salesorder));

保存を選択します。
変換コンポーネントが正しく表示されていることを検証します。 IOM プロバイダー定義変換のコンポーネントタイプが変換名と共に表示されるはずです。表示されない場合は、既存の追加を選択し、先ほど作成した変換を選択してください。

ビジネスイベント定義の追加

プロバイダーが新しいビジネスイベントを作成または使用する場合は、IOM プロバイダー定義ビジネスイベント定義コンポーネントをソリューションに追加する必要があります。 Intelligent Order Management にまだ表示されていないビジネスイベントを追加するだけです。

作成したいビジネスイベントが Intelligent Order Management にまだない場合は、独自に作成することができます。

新規を選択します。
IOM プロバイダー定義ビジネスイベント定義を選択します。
以下の詳細を追加します :
1. 名前 : ビジネスイベントの名前です。
2. プロバイダー : このビジネス定義を作成するプロバイダーです。
3. 関連するエンティティ : イベントの作成時に変更または影響を受ける Intelligent Order Management の Dataverse エンティティです。
4. 関連する状態値 : ビジネスイベントが発生した際に関連するエンティティの状態を更新する場合は、このフィールドに状態値を含めます。
5. 関連する状態値 : ビジネスイベントが発生した際に関連するエンティティの状態を更新する場合は、このフィールドに状態値を含めます。
保存を選択します。
IOM プロバイダービジネスイベント定義レコードが表示されているかを検証するため、ソリューションを確認してください。ソリューションにレコードが表示されない場合は、既存の追加を選択し、先ほど作成したレコードを選択します。

コネクタの追加

Power Automate で利用できないコネクタをプロバイダーが必要とする場合は、独自のコネクターを作成する必要があります。詳細については、すべての Power Automate コネクタの一覧を参照してください。

独自の Power Automate コネクタを作成するには、カスタムコネクタの概要の手順に従ってください。

カスタムコネクタを作成した後、それをコンポーネントとしてプロバイダーソリューションに追加します。

プロバイダーソリューションに移動します。
既存の追加を選択します。
作成したコネクタを選択します。

Power Automate フローのタイプ

オーケストレーションデザイナーで実行されるすべてのアクションは、Power Automate フローによって表されます。 Power Automate で特定の情報を取得したり、特定のアクションを実行する場合は、それらのアクションのためにフローを作成する必要があります。 Power Automate の詳細については、Power Automate の紹介を参照してください。

フローをプロバイダー定義ロジック定義コンポーネントとしてプロバイダーに追加します。

フロー作成プロセスを開始する前に、Intelligent Order Management で使用するフローのタイプを確認します。

プロバイダーメッセージハンドラー

これらのフローは、外部サービスからのメッセージを受信して処理し、適切なビジネスイベントを発生させて Intelligent Order Management のオーケストレーションに通知します。これらのフローは外部サービスによってトリガーされます。

次は、Power Automate フローのメッセージハンドラータイプを作成するための構造の例です。

Power Automate トリガーを定義します。これは通常、Webhook トリガー (推奨)、コネクタトリガー、または Dataverse 挿入トリガーである HTTP エンドポイントです。トリガーは、外部サービスが Intelligent Order Management に送信するデータを持っている場合に発生します。

HTTP トリガーで使用する JSON スキーマを、次に定義します。

{
    "type": "object",
    "properties": {
        "text": {
            "title": "ProviderActionExecutionEventId",
            "type": "string",
            "x-ms-dynamically-added": true,
            "description": "Please enter your input",
            "x-ms-content-hint": "TEXT"
        },
        "text_1": {
            "title": "EntityRecordId",
            "type": "string",
            "x-ms-dynamically-added": true,
            "description": "Please enter your input",
            "x-ms-content-hint": "TEXT"
        }
    },
    "required": [
        "text",
        "text_1"
    ]
}

メッセージ処理を初期化します。このタスクには 2 つの手順が含まれます。
1. メッセージの処理の追跡に使用される実行結果を初期化します。
2. Intelligent Order Management でプロバイダーメッセージを確認することで、処理状態の追跡、再試行、表示が可能になります。これは、Intelligent Order Management が導入している Power Automate のアクションです。このアクションを IOM でのプロバイダーメッセージ要求確認と呼びます。このアクションには、次の必須パラメーターがあります。
  1. PowerAutomateWorkflowId: メッセージハンドラー定義上の WorkflowId です。 workflow()['tags'] を使った構成関数でこれを取得できます。
  2. PowerAutomateRunId: メッセージを受信し、パイプラインで処理を再試行し、実行ログをリンクできる Power Automate 実行の一意識別子です。 workflow()['run']?['name'] を使った構成関数でこれを取得できます。
  3. ProviderMessageExternalRequestId: 送信されたメッセージの識別子です。識別子がない場合は、GUID が生成できます。この識別子はパイプラインで使用して、送信者が重複メッセージを送信するのを防ぐのに使用されます。この識別子はソースペイロードに依存します。例: concat(triggerOutputs()?['body']?['type']?['name'], '_', triggerOutputs()?['body']?['id'])。

プロバイダーメッセージ要求確認画面のスクリーンショット。

以前に定義したプロバイダー変換は、入力データを取得して変換します。 Intelligent Order Management は、変換を実行する IOM プロバイダー変換器と呼ばれるすぐに使用可能な子フローを提供します。イベントまたはメッセージを処理するために、次の詳細情報を追加します :
1. プロバイダー名 : メッセージハンドラーにリンクされているプロバイダー名です。この値は、プロバイダー変換と同じ名前である必要があります。
2. ソースオブジェクト名 : 変換を実行するソースルックアップキーの値です。この値は、プロバイダー変換で定義されたソースオブジェクト名と同じである必要があります。
3. 送信先オブジェクト名 : 変換を実行する送信先ルックアップキーの値です。この値は、プロバイダー変換で定義された値と同じである必要があります。
4. ペイロード : JSON ペイロードの変換時に提供されます。 Power Automate では、パラメーターをシリアル化された文字列として渡す必要があります。 ペイロードまたはレコード ID の値を提供しますが、両方は提供できません。
5. レコード ID: Dataverse レコードの変換時に提供されます。 ペイロードまたはレコード ID の値を提供しますが、両方は提供できません。
HTTP 要求または Dataverse コネクタの挿入アクションを使用して、Dataverse にデータを挿入できます。複数の挿入を実行し、パフォーマンスを改善するには、要求がトランザクションバッチに入るように、挿入を変更セットにまとめます。
フローでビジネスイベントを発生させたい場合は、ビジネスイベントの発生子フローを使用できます。以下の詳細を追加します。
1. BusinessEventName: 発生するイベントの名前です。
2. EntityRecordId: 作成されたばかりのレコードの ID で、イベントに関連付けられています。
プロバイダーメッセージ要求状態の更新アクションを使用してメッセージの処理状態を更新し、処理の実行結果を保存します。以下の詳細を追加します。
1. ProviderMessageRequestExecutionId: メッセージ処理の進行状況を追跡するために作成されたレコードの出力 ID です。
2. IsProexecerMessageRequestExecutionSuccess: 正常に処理されたかどうかを示すブール値です。

プロバイダーメッセージプラー

プロバイダーメッセージプラーは、定期的に定義された間隔で外部サービスからメッセージをプルする Power Automate フローです。

メモ

メッセージハンドラーは、メッセージプラーフローの前提条件となるものです。

次は、Power Automate フローのメッセージプラータイプを作成するための構造の例です。

トリガーをスケジュールするには、繰り返しワークフローを使用します。
Dataverse からチェックポイントを取得します。チェックポイントは外部プロバイダーから正常に取り込まれたメッセージを追跡します。以下の詳細を追加します。
1. アクション名 : チェックポイントの名前です。
2. WorkflowId: この情報を取得するために、次のような構成関数を設定します: workflow()['tags']['xrmWorkflowId']。
メッセージを取り込むために外部プロバイダーへの HTTP 転記要求を作成します。以下の詳細を追加します。
1. メソッド : このフィールドで POST と設定します。
2. URL: 外部プロバイダーエンドポイントです。
3. 本文: JSON 要求は、以下の式で構成されている必要があります: if(empty(outputs('Get_Checkpoint')?['body/Checkpoint']), 0, int(outputs('Get_Checkpoint')?['body/Checkpoint']))。
手順 3 で取り込んだメッセージを解析します。以下の詳細を追加します。
1. コンテンツ : 手順 3 から取得された本文です。
2. スキーマ : 手順 3 で取得された本文の構造です。
手順 4 の各メッセージを介してメッセージがループするようメッセージを処理します。
前の手順の各メッセージを解析します。次の情報を追加します。
1. コンテンツ : プロセスメッセージの現在の品目です。
2. スキーマ : JSON 形式の 1 つのメッセージです。
前提条件で設定した、関連付けられているプロバイダーメッセージハンドラーを呼び出します。次の情報を追加します。
1. 子フロー : プロバイダーメッセージハンドラーを選択します。
2. メッセージ : 手順 6 の解析されたメッセージです。
チェックポイントを Dataverse に保存します。次の情報を追加します。
1. チェックポイント : これは任意の文字列値 (最大 100) になります。この例では、これが最後に処理されたメッセージの ID です。
2. WorkflowId: この ID を取得するために、workflow()['tags']['xrmWorkflowId'] に設定された構成関数を追加します。

プロバイダーアクション

プロバイダーアクションフローは、オーケストレーションデザイナーから呼び出されます。通常これらのフローは、Intelligent Order Management から外部サービスを呼び出します。

プロバイダーメッセージハンドラーとプロバイダーアクションの主な違いは、メッセージハンドラーはオーケストレーションデザイナーに通知できても、オーケストレーションデザイナーのアクションタイルによってはトリガーされないのに対し、プロバイダーアクションはトリガーできるという点です。

プロバイダーアクション Power Automate フロー構造例を次に示します。

HTTP トリガーから開始します。次の情報は、オーケストレーションサービスによって実行時に渡されます。本文には次の JSON スキーマが使用されます。

{
    "type": "object",
    "properties": {
        "text": {
            "title": "ProviderActionExecutionEventId",
            "type": "string",
            "x-ms-dynamically-added": true,
            "description": "Please enter your input",
            "x-ms-content-hint": "TEXT"
        },
        "text_1": {
            "title": "EntityRecordId",
            "type": "string",
            "x-ms-dynamically-added": true,
            "description": "Please enter your input",
            "x-ms-content-hint": "TEXT"
        }
    },
    "required": [
        "text",
        "text_1"
    ]
}

アクション処理を初期化します。
1. 実行結果および他のすべての処理変数を初期化します。
2. プロバイダーアクションの実行開始 Dataverse を使用して、アクションの実行の開始を承認します。これにより、Intelligent Order Management 内の処理状態をパイプラインで追跡、再試行、および表示することが可能になります。次の情報を追加します。
  1. ProviderActionExecutionEventId: この値は、手順 1 で入力パラメータとしてアクションに渡されました。
  2. PowerAutomateRunID: Power Automate アクションの一意の実行です。これにより、パイプラインで実行ログをリンクできます。この情報を取得するには、フィールドを Power Automate の式、worflow()['run']?['name'] に設定します。
アクションを実行します。
1. 必要に応じて、Power Query Online を使用したメッセージ変換子フローを使用してレコードを変換します。
  1. プロバイダー名 : アクションにリンクさせるプロバイダー名です。この名前は、プロバイダー定義と同じ名前である必要があります。
  2. ソースオブジェクト名 : 実行する変換のソース名です。この名前は、Power Automate 変換で定義されたソースオブジェクトと同じである必要があります。
  3. 送信先オブジェクト名 : 変換を実行する送信先ルックアップキーの値です。この名前は、プロバイダー変換で定義された値と同じである必要があります。
  4. ペイロード : 受信した JSON ペイロードの変換時に提供されます。 Power Automate では、パラメーターをシリアル化された文字列として渡す必要があります。 ペイロードまたはレコード ID の値を追加しますが、両方は追加できません。
  5. レコード ID:発信した Dataverse レコードの変換時に提供されます。 ペイロードまたはレコード ID の値を追加しますが、両方は追加できません。
2. 定義したすべてのカスタムアクションを実行します。これらは、使用している Power Automate コネクタに存在するアクションです。
3. アクション固有のビジネスイベントを発生させます。 ビジネスイベントの発生子フローを使用します。次の情報を追加します。
  1. BusinessEventName: 発生させたいイベントの名前です。
  2. EntityRecordId: イベントに関連付けられたレコードの ID です。
アクションの実行を完了して結果を保存します。結果はオーケストレーションデザイナーによって処理されます。次の情報を追加します。
1. ExecutionResult: 正常に処理されたかどうかを示すブール値です。
2. ExecutionDetails: テストやデバッグを目的としたオプションのログの詳細です。
3. ProviderActionExecutionEventId: この値は、手順 1 で定義された入力パラメータとしてアクションに渡されました。

子フロー

子フローとは、他の Power Automate フローで参照されるサブフローのことです。複数の領域で繰り返す手順がある場合は、子フローを定義しておくと便利です。子フローは、似たような手順をまとめるための便宜上のものであり、特定のテンプレートや推奨されるプロセスはありません。

プロバイダーの子フローは、他のプロバイダーの子フローを呼び出すことはできません。

クラウドフローの作成

作成するフローのタイプを理解したなら、クラウドフロー作成の準備が整ったことになります。これを行うには、次の手順に従います。

Power Apps 環境で既定のソリューションを開きます。

重要

これらのソリューションをプロバイダーソリューションに追加しないで下さい。

新規を選択し、クラウドフローを選択します。
Power Automate フローを構築します。前のセクションを参照してテンプレートを使用します。
フローを保存するには、次のセクションを参照してください。

Power Automate 定義を保存します

フローを作成した後、それをプロバイダー定義ロジック定義コンポーネントとして保存する必要があります。このコンポーネントタイプは、プロバイダーが有効化する際に展開するアクションを Intelligent Order Management に提供します。

フローを保存できるようにする前に、次の前提条件が満たされている必要があります。

Power Automate ロジック定義を保存するには、OData 要求を発行する必要があります。そのためには、PostMan または同様のサービスのアカウントが必要です。
GET および POST 要求を発行するには、Dataverse 環境に対してアクセストークンを生成する必要があります。
- 有効なサブスクリプションを持つ Azure アカウントを設定します。有効なアカウントを持っていない場合は、Azure Web サイトでアカウントを設定する必要があります。
- PowerShell がインストールされている必要があります。詳細については PowerShell のインストールを参照してください。
- PowerShell で次のコマンドを入力してアクセストークンを取得します: az login --allow-no-subscriptions account get-access-token --resource=https://YourDataverseTenantURL.api.crm.dynamics.com/ --query=accessToken --output=tsv | Set-Clipboard。

Power Automate 定義を保存するには、次の操作を行います。

保存したい Power Automate フローのワークフロー ID を検索します。次のどちらかを実行します。
1. Power Automate アクションを使用してワークフロー ID を検索します。
  1. Power Automate フローの最後に、workflow() 式で構成アクションを作成します。
  2. Power Automate を実行します。
  3. 実行結果の xrmWorkflowId プロパティにはワークフロー ID が含まれます。
  4. このアクションが再び実行されないように、フローから削除します。
2. オプションとして、GET OData 要求を発行することができます。
  1. ワークフロー ID を保存するフローに移動します。 URL 内の一意識別子を検索します。これは、../フロー/URL 内、の後に表示される ID です。
  2. ワークフローメタデータを取得するために OData 要求を発行します。以下は、GET 要求の例です。
    GET {Env url}/api/data/v9.1/workflows?$filter=workflowidunique eq '{Unique Workflow Id from the Power Automate U}'&$select=workflowid,workflowidunique
  3. 返された workflowid プロパティを保存します。
プロバイダー定義 ID を検索します。
1. フローの保存先となるプロバイダー定義を選択します。
2. URL からプロバイダー定義 ID をコピーします。これは URL の一部です。../id= {番号例}/.
保存している Power Automate のタイプのオプション設定値をメモします。
1. 子フロー : 192350002
2. プロバイダーアクション : 192350001
3. プロバイダーメッセージハンドラー : 192350000
4. プロバイダーメッセージプラー : 192350003
Power Automate 定義を保存するために POST 要求を発行します。以下は、要求の例です。

    POST: {Env url}/api/data/v9.1/msdyn\_SaveProviderDefinitionLogicDefinition  
    Body:  
    {

"ProviderDefinitionId": "{ProviderId previously found}",

"WorkflowId": "{Power Automate WorkflowId previously found}",

"LogicalName": "{Export prefix \_ Power Automate Export Name}",

"LogicType": {Logic Type},

"MaxRetryAttempts": {Max number of attempts},

"TimeoutMinutes": {Timeout number ex: 5}

}

プロバイダー定義ロジック定義コンポーネントが追加されたことを検証します。これを行うには、次の手順に従います。
1. プロバイダーソリューションに移動します。
2. 作成したプロバイダー定義ロジック定義が追加されたことを検証します。追加されていない場合は、既存の追加を選択し、作成したコンポーネントを追加します。

接続参照の保存

プロバイダーが顧客の Power Automate コネクタを使用している場合は、次の手順を実行して、Power Automate ソリューションに接続参照を保存する必要があります。

GET 要求を発行して接続参照 ID を取得します。例:

GET {Env url}/api/data/v9.2/connectionreferences

さらにフィルター処理する場合は、接続参照名でフィルター処理できます。例:

    {Env url}/api/data/v9.2/connectionreferences?$[connectionreferences?$filter=connectionreferencedisplayname](https://orgdb90e3a2.api.crm10.dynamics.com/api/data/v9.2/connectionreferences?$filter=connectionreferencedisplayname) eq 'Provider Example'&$select=connectionreferencelogicalname,connectionreferencedisplayname,connectionreferenceid,connectorid

Power Automate クライアントデータを検索して、正しい接続参照 ID が取得されたことを検証します。
1. 先に保存したプロバイダー定義ロジック定義コンポーネントに移動します。
2. クライアントデータを確認して connectionReferenceReferenceRefalName が表示されていることを検証します。
プロバイダー定義 ID を検索します。これは、Power Automate ロジック定義を保存するために手順 2 で使用した値と同じです。
転記要求を発行して接続参照を保存します。例:

POST {Env url}/api/data/v9.1/msdyn\_SaveProviderDefinitionConnectionReference  
    Body:  
    {

"ProviderDefinitionId": "{ProviderId previously found}",

"ConnectionReferenceId": "{Connection reference id previously found}"

}

プロバイダー定義ロジック定義コンポーネントが追加されたことを検証します。
1. プロバイダーソリューションに移動します。
2. 作成したプロバイダー定義ロジック定義参照コンポーネントが追加されたことを検証します。追加されていない場合は、既存の追加を選択し、先ほど作成したコンポーネントを追加します。

別の環境でプロバイダー定義を使用する場合、またはソリューションを共有する場合は、プロバイダーソリューションをエクスポートできます。詳細については、ソリューションのエクスポートを参照してください。

次の方法で共有

新しいプロバイダーの作成

プロバイダーアーキテクチャの定義

プロバイダーソリューションの作成

カスタムプロバイダーの設定

プロバイダー定義の追加

ソリューションにコンポーネントを追加する

プロバイダー変換の作成

ビジネスイベント定義の追加

コネクタの追加

Power Automate フローのタイプ

プロバイダーメッセージハンドラー

プロバイダーメッセージプラー

プロバイダーアクション

子フロー

クラウドフローの作成

Power Automate 定義を保存します

接続参照の保存

フィードバック

その他のリソース

次の方法で共有

新しいプロバイダーの作成

プロバイダー アーキテクチャの定義

プロバイダー ソリューションの作成

カスタム プロバイダーの設定

プロバイダー定義の追加

ソリューションにコンポーネントを追加する

プロバイダー変換の作成

ビジネス イベント定義の追加

コネクタの追加

Power Automate フローのタイプ

プロバイダー メッセージ ハンドラー

プロバイダー メッセージ プラー

プロバイダー アクション

子フロー

クラウド フローの作成

Power Automate 定義を保存します

接続参照の保存

プロバイダーの共有

フィードバック

その他のリソース

プロバイダーアーキテクチャの定義

プロバイダーソリューションの作成

カスタムプロバイダーの設定

ビジネスイベント定義の追加

プロバイダーメッセージハンドラー

プロバイダーメッセージプラー

プロバイダーアクション

クラウドフローの作成