非同期サービス

[アーティクル]
08/05/2024

非同期サービスは、Microsoft Dataverse のメインのコア操作から独立して長時間の操作を実行します。この方法で長時間の操作を実行することで、システム全体のパフォーマンスとスケーラビリティが向上します。非同期サービスの機能として、非同期の登録プラグイン、ワークフロー、大容量メール、一括インポート、キャンペーン活動の伝達などの非同期の操作を実行するための管理された先入先出 (FIFO) キューがあります。これらの操作は非同期サービスに登録され、サービスによってキューが処理されるときに定期的に実行されます。

イベントが発生し、すべての同期拡張機能が処理された後、Dataverse は非同期エクステンションのコンテキストをシリアル化し、システムジョブ (AsyncOperation) テーブルとしてデータベースに保存します。システムジョブは非同期操作の実行を定義および追跡します。リソースが利用可能になると、Dataverse はシステムジョブを処理し、定義する操作を実行します。 Dataverse は、イベント実行パイプラインで再度拡張で定義された任意のデータ操作を処理しますが、今回は同期操作として処理されます。

実行順序および依存関係

CreatedOn 日付を使用するキューとして、システムジョブは評価されます。実行を遅らせる条件がない場合、リソースが利用可能になるとすぐに実行されます。異なるタイプの操作には異なるリソースが必要となるため、CreatedOn 日付で設定された順序でいつも実行されるわけではありません。

システムジョブは別のシステムジョブに依存するため、他のシステムジョブが完了した後にのみ開始されます。 DependencyToken 列の値は、システムジョブが作成されたときにこの依存関係を確立します。 DependencyToken 値が null の場合、システムジョブには依存関係がありません。依存しているシステムジョブには同じ DependencyToken 値があり、作成された順序で実行されます。システムジョブが延期された場合、それ以降のすべての依存システムジョブは延期されたシステムジョブが実行されるまで待機し続けます。

注意

依存関係システムのシステムジョブはシステムによって作成されるため、この依存関係システムは非同期で実行するように登録されたプラグインでは使用できません。

システムジョブの管理

次の操作を実行して、AsyncOperation テーブルを使用してシステムジョブを管理できます。

システムジョブの取得
システムジョブの削除
システムジョブ状態の管理
システムジョブの延期

注意

コードでのシステムジョブの作成はサポートされていません。 AsyncOperation テーブルでは、書き込み可能な複数のカラムと create 操作がサポートされていますが、update では以下のカラムのみがサポートされています :

システムジョブの取得

設定 > システム > システムジョブ の順に移動してアプリケーションのシステムジョブを表示でき、モデル駆動型アプリで高度な検索を使用して検索もできます。

コードを使用すると、他のテーブルと同じようにシステムジョブを取得できます。次の表は、システムのジョブを理解する上で重要な列の一覧です:

列	説明設定
`AsyncOperationId`	システムジョブを表す一意識別子です。
`CompletedOn`	システムジョブが完了した日時です。
`CreatedBy`	システムジョブを作成したユーザーを表す一意識別子です。
`CreatedOn`	システムジョブが作成された日時です。
`Data`	システムジョブに関連付けられている構造化されていないデータです。
`DependencyToken`	同じ依存関係トークンを持つすべての操作の実行がシリアル化されます。実行順序および依存関係について
`Depth`	最初の呼び出し以降の SDK 呼び出しの数です。
`ErrorCode`	取り消したシステムジョブから返されたエラーコードです。
`ExecutionTimeSpan`	システムジョブの実行にかかった時間です。
`FriendlyMessage`	システムジョブによって提供されるメッセージです。
`IsWaitingForEvent`	システムジョブがイベントの待機中であることを示します。
`Message`	システムジョブに関連するメッセージです。
`MessageName`	このシステムジョブを開始したメッセージの名前です。
`ModifiedBy`	システムジョブを最後に修正したユーザーを表す一意の識別子です。
`ModifiedOn`	システムジョブが最後に修正された日時です。
`Name`	システムジョブの名前です。
`OperationType`	システムジョブの種類です。操作の種類について
`OwnerId`	システムジョブを所有するユーザーまたはチームを表す一意識別子。
`OwningBusinessUnit`	システムジョブを所有する部署を表す一意の識別子です。
`OwningExtensionId`	システムジョブが関連付けられている所有する拡張を表す一意識別子です。
`OwningTeam`	レコードを所有するチームを表す一意識別子です。
`OwningUser`	レコードを所有するユーザーを表す一意識別子です。
`PostponeUntil`	システムジョブの実行時期を、指定された日時の後のみに制限するかどうかを表します。システムジョブを延期する方法について
`PrimaryEntityType`	システムジョブが主に関連付けられているテーブルの種類です。
`RecurrencePattern`	システムジョブの定期的なアイテムのパターンです。定期的な開始時刻とパターンについて
`RecurrenceStartTime`	定期的なアイテムのパターンの開始時間 (UTC) です。定期的な開始時刻とパターンについて
`RegardingObjectId`	システムジョブが関連付けられているオブジェクトを表す一意の識別子です。
`RetryCount`	システムジョブの再試行回数です。
`Sequence`	操作が提出された順序です。
`StartedOn`	システムジョブが開始された日時です。
`StateCode`	システムジョブの状態です。システムジョブ状態の管理について
`StatusCode`	システムジョブの状態の理由です。システムジョブ状態の管理について
`UTCConversionTimeZoneCode`	レコード作成時に使用していたタイムゾーンコードです。
`WorkflowStageName`	ワークフロー段階の名前です。

例

システムジョブデータを取得する次の例を使用できます。

次の Web API クエリを使用して、上記の表の列を取得します。 [Web APIを使用してデータをクエリする方法を学ぶ](webapi/query/overview.md

GET <organization URL>/api/data/v9.2/asyncoperations?$top=1000
&$select=
asyncoperationid,
completedon,
createdon,
data,
dependencytoken,
depth,
errorcode,
executiontimespan,
friendlymessage,
iswaitingforevent,
message,
messagename,
modifiedon,
name,
operationtype,
_ownerid_value,
postponeuntil,
primaryentitytype,
recurrencepattern,
recurrencestarttime,
_regardingobjectid_value,
retrycount,
sequence,
startedon,
statecode,
utcconversiontimezonecode,
workflowstagename
&$expand=
createdby($select=fullname),
modifiedby($select=fullname),
owningbusinessunit($select=name),
owningextensionid($select=name),
owningteam($select=name),
owninguser($select=fullname)

注意

Web API では、システムジョブをサポートするテーブルごとに単一値のナビゲーションプロパティがあります。このナビゲーションプロパティの名前は、パターン regardingobjectid_<table logical name> に従います。

上記の表の列を取得するには、以下 FetchXML を使用します。 FetchXml を使用してデータのクエリを実行する

<fetch top='1000'>
  <entity name='asyncoperation' >
    <attribute name='asyncoperationid' />
    <attribute name='completedon' />
    <attribute name='createdby' />
    <attribute name='createdon' />
    <attribute name='data' />
    <attribute name='dependencytoken' />
    <attribute name='depth' />
    <attribute name='errorcode' />
    <attribute name='executiontimespan' />
    <attribute name='friendlymessage' />
    <attribute name='iswaitingforevent' />
    <attribute name='message' />
    <attribute name='messagename' />
    <attribute name='modifiedby' />
    <attribute name='modifiedon' />
    <attribute name='name' />
    <attribute name='operationtype' />
    <attribute name='ownerid' />
    <attribute name='owningbusinessunit' />
    <attribute name='owningextensionid' />
    <attribute name='owningteam' />
    <attribute name='owninguser' />
    <attribute name='postponeuntil' />
    <attribute name='primaryentitytype' />
    <attribute name='recurrencepattern' />
    <attribute name='recurrencestarttime' />
    <attribute name='regardingobjectid' />
    <attribute name='retrycount' />
    <attribute name='sequence' />
    <attribute name='startedon' />
    <attribute name='statecode' />
    <attribute name='utcconversiontimezonecode' />
    <attribute name='workflowstagename' />
  </entity>
</fetch>

注意

システムジョブをサポートするすべてのテーブルは、RegardingObjectId ルックアップカラムを介して AsyncOperation テーブルとの多対一の関係がリストアップされています。この関係の名前は、パターン <table schema name>_AsyncOperations に従います。****

SQL を使用して Dataverse 表形式データストリーム (TDS) エンドポイントを使用した AsyncOperation テーブルのクエリを実行できます。

SELECT TOP (1000) asyncoperationid
      ,completedon
      ,createdon
      ,data
      ,dependencytoken
      ,depth
      ,errorcode
      ,executiontimespan
      ,friendlymessage
      ,iswaitingforevent
      ,message
      ,messagename
      ,modifiedon
      ,name
      ,operationtype
      ,operationtypename
      ,ownerid
      ,postponeuntil
      ,recurrencepattern
      ,recurrencestarttime
      ,regardingobjectid
      ,regardingobjectidname
      ,retrycount
      ,sequence
      ,startedon
      ,statecode
      ,utcconversiontimezonecode
      ,workflowstagename
  FROM asyncoperation

操作の種類

OperationType 列には、システムジョブのカテゴリが記載されています。 Dataverse は多くのこれらの種類を開始して、メンテナンスタスクを実行します。

注意

プラットフォームによりで生成されるシステムジョブで、操作のキャンセル、一時停止、または再開を実行することはできません。

これらのプラットフォーム生成ジョブの種類の一部は、次の表に含まれています。

OperationType 値	OperationType ラベル
9	SQM データ収集
16	組織統計の収集
18	組織の記憶域サイズの計算
19	組織のデータベース統計の収集
20	組織規模統計の収集
22	組織の最大記憶域サイズの計算
24	統計の更新間隔
25	組織のフルテキストカタログインデックス
27	契約の状態の更新
31	記憶域制限の通知

完全なリストについては、OperationType の選択/オプションを参照してください

定期実行の開始時刻とパターン

定期実行のシステムジョブには、開始時期および頻度に関する情報が必要です。これらの値は、AsyncOperationテーブル、RecurrenceStartTime および RecurrencePattern 列に保存されます。

AsyncOperation レコードをコードで直接作成するわけではないので、データを照会する際には、これらの値を解釈する必要があります。これらのプロパティ値は新しいシステムジョブを作成するメッセージを使用して、間接的に設定します。 BulkDelete および BulkDeleteDuplicates メッセージの両方には、対応する Web API アクションまたは .NET 用 SDK 要求クラスのパラメータまたはプロパティが含まれます。詳細: BulkDetectDuplicatesRequest クラス、BulkDetectDuplicates アクション、 BulkDeleteRequest クラス、そして一括削除アクション

RecurrenceStartTime は、単にシステムジョブがいつ開始されるべきかを示す日時の値です。それが設定されていない場合、システムジョブはすぐに開始すると想定されます。

RecurrencePattern 列には、定期的に発生するシステムジョブの頻度に関する情報が格納されています。このプラットフォームは、新しい asyncoperation レコードが作成されたときにこの値を設定する時があります。この値を設定してパターンを変更することができます。

この列の値は、 RFC2445 インターネット標準 (Internet Calendaring and Scheduling Core Object Specification) の一部を使用しています。

以下の表で、例を示します。

定期的なパターン	ジョブ実行の頻度
`FREQ=MONTHLY;`	1 か月に 1 回
`FREQ=WEEKLY;`	1 週間に 1 回
`FREQ=DAILY;`	1 日に 1 回
`FREQ=DAILY;INTERVAL=3;`	3 日ごと
`FREQ=HOURLY;`	1 時間に 1 回

INTERVAL 値が設定されていない場合、1 として解釈されます。

診断クエリ

このセクションのクエリを使用して、問題の診断に役立ててください。

状態、ステータス、タイプ別のジョブ

このクエリを使用して、さまざまな種類のジョブの分布と頻度を把握します。結果により、どのジョブが問題を引き起こしているかがわかる場合があります。

このクエリは count 降順で順序付けされていません。代わりに Web API で FetchXml を使用することもできます。 FetchXml を使用してデータのクエリを実行する

GET [Organization URI]/api/data/v9.2/asyncoperations?$apply=groupby((statecode,statuscode,operationtype),aggregate($count as count))
Accept: application/json  
OData-MaxVersion: 4.0  
OData-Version: 4.0
Prefer: odata.include-annotations="OData.Community.Display.V1.FormattedValue"

Web APIを使用してデータをクエリする方法を学ぶ

<fetch aggregate='true'>
  <entity name='asyncoperation'>
    <attribute name='statecode'
      alias='statecode'
      groupby='true' />
    <attribute name='statuscode'
      alias='statuscode'
      groupby='true' />
    <attribute name='operationtype'
      alias='operationtype'
      groupby='true' />
    <attribute name='asyncoperationid'
      alias='count'
      aggregate='count' />
    <order alias='count'
      descending='true' />
  </entity>
</fetch>

FetchXml を使用してデータのクエリを実行する

SELECT statecode,
      statuscode,
      operationtype,
      Count(*) AS count
FROM  asyncoperation
GROUP BY  statecode,
      statuscode,
      operationtype
ORDER BY Count DESC

Dataverse 表形式データストリーム (TDS) エンドポイントを使用して SQL を使用してデータをクエリする

中断状態にある上位システムジョブの数 (数別)

このクエリを使用して、一時停止中状態の AsyncOperation テーブル内のすべてのジョブの数を抽出します。このクエリは次に役立ちます。

待機中のジョブの量と性質を理解します。
ホールドアップが発生している場所を特定します。
システムのパフォーマンスとスループットを向上させるためにそれらに対処する方法について情報に基づいた決定を下します。

GET [Organization URI]/api/data/v9.2/asyncoperations?$apply=filter((statecode eq 1))/groupby((statecode,statuscode,operationtype),aggregate($count as count))
Accept: application/json  
OData-MaxVersion: 4.0  
OData-Version: 4.0
Prefer: odata.include-annotations="OData.Community.Display.V1.FormattedValue"

Web APIを使用してデータをクエリする方法を学ぶ

<fetch aggregate='true'>
  <entity name='asyncoperation'>
    <attribute name='statecode'
      alias='statecode'
      groupby='true' />
    <attribute name='statuscode'
      alias='statuscode'
      groupby='true' />
    <attribute name='operationtype'
      alias='operationtype'
      groupby='true' />
    <attribute name='asyncoperationid'
      alias='count'
      aggregate='count' />
    <filter>
      <condition attribute='statecode'
        operator='eq'
        value='1' />
    </filter>
    <order alias='count'
      descending='true' />
  </entity>
</fetch>

FetchXml を使用してデータのクエリを実行する

SELECT statecode,
      statuscode,
      operationtype,
      Count(*) AS count
FROM  asyncoperation
WHERE statecode = 1
GROUP BY  statecode,
      statuscode,
      operationtype
ORDER BY Count DESC

Dataverse 表形式データストリーム (TDS) エンドポイントを使用して SQL を使用してデータをクエリする

結果で何を探すべきかは次のとおりです。

一時停止ジョブの定量化: このクエリは、 一時停止 (statecode = 1) になっているジョブを具体的にターゲットとします。結果では、そのようなすべてのジョブの数が、statuscode と operationtype によって分類されて表示されます。
操作タイプの内訳: グループ化された 一時停止 ジョブ operationtypeの数。このタイプの操作は 一時停止 状態で最も一般的であることを示しています。
潜在的なボトルネックの特定: 長期間にわたる 一時停止 ジョブの数が多い場合は、リソースの制限、他のプロセスへの依存関係、またはシステムの設定ミスが原因である可能性があります。
容量とリソースの管理: 特定のジョブが常に 一時停止 状態にある場合は、これらのジョブを効率的に処理するために必要なリソースがシステムに不足していることを示している可能性があります。
システムヘルスチェック: 一時停止 状態のジョブは、ヘルスインジケーターとして機能します。正常なシステムでは、理想的には 一時停止 状態のジョブが最小限であるか、少なくとも 一時停止 状態からアクティブな処理への急速なターンオーバーが見られる必要があります。
ワークフローの効率: 結果により、ワークフローの効率が明らかになります。特定の operationtype に 一時停止 ジョブの数が多い場合は、そのワークフロー内で非効率であるか、最適化が必要であることを示している可能性があります。

ワークフロー件数

このクエリは、ワークフローの operationtype 値でフィルタリングされた、ワークフロー関連ジョブの詳細な内訳を提供します。クエリ結果を使用して、ワークフロージョブの包括的なビューを取得し、システムリソースをより効果的に管理し、ワークフローがスムーズかつ効率的に実行されていることを確認します。

GET [Organization URI]/api/data/v9.2/asyncoperations?$apply=filter((operationtype eq 10))/groupby((statecode,statuscode,operationtype),aggregate($count as count))
Accept: application/json  
OData-MaxVersion: 4.0  
OData-Version: 4.0
Prefer: odata.include-annotations="OData.Community.Display.V1.FormattedValue"

Web APIを使用してデータをクエリする方法を学ぶ

<fetch aggregate='true'>
  <entity name='asyncoperation'>
    <attribute name='statecode'
      alias='statecode'
      groupby='true' />
    <attribute name='statuscode'
      alias='statuscode'
      groupby='true' />
    <attribute name='operationtype'
      alias='operationtype'
      groupby='true' />
    <attribute name='asyncoperationid'
      alias='count'
      aggregate='count' />
    <filter>
      <condition attribute='operationtype'
        operator='eq'
        value='10' />
    </filter>
    <order alias='count'
      descending='true' />
  </entity>
</fetch>

FetchXml を使用してデータのクエリを実行する

SELECT statecode,
      statuscode,
      operationtype,
      Count(*) AS count
FROM  asyncoperation
WHERE operationtype = 10
GROUP BY  statecode,
      statuscode,
      operationtype
ORDER BY Count DESC

Dataverse 表形式データストリーム (TDS) エンドポイントを使用して SQL を使用してデータをクエリする

結果で何を探すべきかは次のとおりです。

ワークフロー固有のジョブ: operationtype = 10 フィルターは、結果をワークフロージョブに制限します。ワークフローに関連するジョブの数とその現在のステータスを確認できます。このサンプルクエリを他の種類の操作に適用することもできます。操作の種類に関する詳細
ジョブ状態の分布: statecode は、ワークフロージョブ 準備完了、一時停止、 ロック、または完了かどうかなど、ワークフロージョブの現在の状態を示します。
ステータスコード分析: statuscode により、ジョブの現在の状態の背後にある理由について具体的な洞察が得られます。たとえば、ジョブが リソースを待機中、 待機中、 進行中、 一時停止中、 キャンセル中、成功、失敗、または キャンセル かを示すことができます。
各カテゴリの数: statecode と statuscode の各組み合わせのジョブの合計数。これは、ワークフロー操作の最も一般的な結果を特定するのに役立ちます。
一般的な結果の特定: カウントの降順に並べられた結果を使用して、ワークフロー処理で最も頻繁に発生する結果やボトルネックを特定できます。
トラブルシューティングと最適化: 失敗状態または 一時停止 状態のカウントが多い場合、領域が強調表示される可能性があります。ワークフローが失敗したり滞ったりしている場合は、トラブルシューティングやプロセスの最適化が必要であることを示しています。
パフォーマンスメトリクス: どのワークフローが最も一般的か、またワークフローがさまざまな状態にどのように分散されているかを理解すると、ワークフロー管理システムのパフォーマンスと信頼性を評価するのに役立ちます。
キャパシティプランニング: 進行中 または 待機中 ワークフローの数が一貫して多い場合は、次のことが考えられます。負荷を処理するためにより多くのリソースが必要である、またはワークフロー実行環境を最適化する必要がある。
ワークフロー管理: クエリ結果は、どのワークフローを優先するかを決定したり、最適化または非アクティブ化/無効化できるワークフローを特定したりするなど、管理者がワークフローをより効果的に管理するためのガイドとなります。
システムヘルスチェック: 全体的な結果は、ワークフローシステムのヘルスチェックとして機能し、システムが最適に実行されているかどうか、または注意が必要な領域があるかどうかを示します。

システムリソースが利用可能になるのを待っているジョブ

このクエリを使用して、特定の準備状態にあるものの、システムリソースが利用できないために実行が保留されているジョブの詳細な分析を AsyncOperation テーブルから取得します。このクエリにより、速度の低下に寄与する要因を特定し、効率性とバックログのより適切な処理に関する意思決定を行うことができます。

GET [Organization URI]/api/data/v9.2/asyncoperations?$apply=filter((statecode eq 0 and statuscode eq 0))/groupby((statecode,statuscode,operationtype),aggregate($count as count))
Accept: application/json  
OData-MaxVersion: 4.0  
OData-Version: 4.0
Prefer: odata.include-annotations="OData.Community.Display.V1.FormattedValue"

Web APIを使用してデータをクエリする方法を学ぶ

<fetch aggregate='true'>
  <entity name='asyncoperation'>
    <attribute name='statecode'
      alias='statecode'
      groupby='true' />
    <attribute name='statuscode'
      alias='statuscode'
      groupby='true' />
    <attribute name='operationtype'
      alias='operationtype'
      groupby='true' />
    <attribute name='asyncoperationid'
      alias='count'
      aggregate='count' />
    <filter>
      <condition attribute='statecode'
        operator='eq'
        value='0' />
      <condition attribute='statuscode'
        operator='eq'
        value='0' />
    </filter>
    <order alias='count'
      descending='true' />
  </entity>
</fetch>

FetchXml を使用してデータのクエリを実行する

SELECT statecode,
      statuscode,
      operationtype,
      Count(*) AS count
FROM  asyncoperation
WHERE statecode = 0 AND statuscode = 0
GROUP BY  statecode,
      statuscode,
     operationtype
ORDER BY Count DESC

Dataverse 表形式データストリーム (TDS) エンドポイントを使用して SQL を使用してデータをクエリする

結果で何を探すべきかは次のとおりです。

リソースを待機している準備完了ジョブのフィルター: 準備完了 と リソースを待機中 にあるジョブに対して statecode = 0 と statuscode = 0 フィルターで結果を制限します。この組み合わせは、キューに入れられ、実行の準備ができているが保留中のジョブを示します。
ジョブスケジュールの最適化: ジョブの準備状況と待機時間のパターンを特定すると、ジョブのスケジュール設定が改善され、システム負荷のよりバランスのとれた分散につながる可能性があります。
根本的な問題の特定: 場合によっては、リソースを待機しているジョブは単にリソースの問題ではなく、デッドロックや非効率なリソースロックメカニズムなどの根本的な問題を示している可能性があります。

ファイルストレージのクエリ

テーブルのデータ列のサイズに応じて、その列のデータはファイルストレージに保存される場合があります。 AsyncOperation DataBlobId 列がファイルストレージを使用する場合に値が入ります。スペースを節約するには、これらのレコードを特定して削除することをお勧めします。これらのレコードを検出するには、次のクエリを使用します

AsyncOperation file storage datablobid count

このクエリを使用して、datablobid 列が nullではない AsyncOperation テーブルのレコード数をカウントします。

GET [Organization URI]/api/data/v9.2/asyncoperations?$apply=filter((datablobid ne null))/aggregate($count as FileStorageCount)
Accept: application/json  
OData-MaxVersion: 4.0  
OData-Version: 4.0

Web APIを使用してデータをクエリする方法を学ぶ

<fetch aggregate='true'>
  <entity name='asyncoperation'>
    <attribute name='asyncoperationid'
      alias='FileStorageCount'
      aggregate='count' />
    <filter>
      <condition attribute='datablobid'
        operator='not-null' />
    </filter>
  </entity>
</fetch>

FetchXml を使用してデータのクエリを実行する

SELECT count(*) AS FileStorageCount 
FROM asyncoperation  
WHERE  datablobid IS NOT NULL

Dataverse 表形式データストリーム (TDS) エンドポイントを使用して SQL を使用してデータをクエリする

結果で何を探すべきかは次のとおりです。

データストレージへの影響: スペースを節約するためにファイルストレージを使用する際にレコードを削除する必要がある場合があるため、これを知っておくと役立ちます。数値が大きい場合は、これらの BLOB によって使用されているスペースがかなり大きいことを示唆している可能性があり、これはデータベースサイズ管理にとって重要になる可能性があります。
システムパフォーマンスの考慮事項: FileStorageCount が予想外に高い場合は、一括削除やクリーンアップなどのさらなるアクションを実行することをお勧めします。

AsyncOperations が BLOBストレージにありません

このクエリを使用して、datablobid フィールドが NULLである AsyncOperation テーブルのレコード数をカウントします。

GET [Organization URI]/api/data/v9.2/asyncoperations?$apply=filter((datablobid eq null))/aggregate($count as DBCount)
Accept: application/json  
OData-MaxVersion: 4.0  
OData-Version: 4.0

Web APIを使用してデータをクエリする方法を学ぶ

<fetch aggregate='true'>
  <entity name='asyncoperation'>
    <attribute name='asyncoperationid'
      alias='DBCount'
      aggregate='count' />
    <filter>
      <condition attribute='datablobid'
        operator='null' />
    </filter>
  </entity>
</fetch>

FetchXml を使用してデータのクエリを実行する

SELECT count(*)  AS DBCount  
FROM asyncoperation 
WHERE datablobid IS NULL

Dataverse 表形式データストリーム (TDS) エンドポイントを使用して SQL を使用してデータをクエリする

結果で何を探すべきかは次のとおりです。

Blob Storage 以外の非同期操作を理解する: DBCount 結果は、関連付けられたデータ BLOB を持たない非同期操作の量を示します。これは、BLOB を考慮していないときのストレージステータスを示します。
非効率の特定 意図した場合を除き、ここでの数値が高い場合は、クリーンアップをスケジュールして一括削除を実行する必要があることを示唆している可能性があります。 BLOB ストレージのカウントが低く、ここでのカウントが高い場合、これはプライマリボリューム投稿者に帰属します。

ファイルストレージを使用してジョブの名前を検索する

このクエリの結果には、ジョブの種類、ジョブの名前、およびファイルストレージを消費しているテーブル上にこのジョブが存在する回数が表示されます。これを使用して、ファイルの使用に最も大きな影響を与える特定のジョブ名を特定し、その名前を持つレコードの一括削除ジョブを作成します。

これにより、ファイルの使用に最も大きな影響を与える特定のジョブ名を識別できるようになります。その結果、顧客はその名前をターゲットにして、その特定のジョブの一括削除プロセスを開始できます。

このクエリは jobs 列の降順で順序付けされていません。代わりに Web API で FetchXml を使用することもできます。 FetchXml を使用してデータのクエリを実行する

GET [Organization URI]/api/data/v9.2/asyncoperations?$apply=filter((datablobid ne null))/groupby((operationtype,name,friendlymessage),aggregate($count as jobs))
Accept: application/json  
OData-MaxVersion: 4.0  
OData-Version: 4.0
Prefer: odata.include-annotations="OData.Community.Display.V1.FormattedValue"

Web APIを使用してデータをクエリする方法を学ぶ

<fetch aggregate='true'>
  <entity name='asyncoperation'>
    <attribute name='asyncoperationid'
      aggregate='count'
      alias='jobs' />
    <attribute name='operationtype'
      groupby='true'
      alias='operationtype' />
    <attribute name='name'
      groupby='true'
      alias='name' />
    <attribute name='friendlymessage'
      groupby='true'
      alias='friendlymessage' />
    <filter>
      <condition attribute='datablobid'
        operator='not-null' />
    </filter>
    <order alias='jobs'
      descending='true' />
  </entity>
</fetch>

FetchXml を使用してデータのクエリを実行する

SELECT operationtypename
      ,name
      ,friendlymessage
      ,count(*) AS Jobs  
FROM asyncoperation
WHERE datablobid IS NOT NULL 
GROUP BY operationtypename, name, friendlymessage
ORDER BY Jobs DESC

Dataverse 表形式データストリーム (TDS) エンドポイントを使用して SQL を使用してデータをクエリする

AsyncOperation ファイルサイズとレコード数

このクエリを使用して、状態、ステータス、所有する拡張子ごとにシステムジョブの合計ファイルサイズとレコード数を取得します。

この例では、エンコードされた FetchXml を使用して、Web API を使用してクエリを送信します。 FetchXml を使用してデータのクエリを実行する

GET [Organization URI]/api/data/v9.2/asyncoperations?fetchXml=%3Cfetch%20aggregate%3D%27true%27%3E%20%3Centity%20name%3D%27asyncoperation%27%3E%20%3Cattribute%20name%3D%27owningextensionid%27%20alias%3D%27owningextension%27%20groupby%3D%27true%27%20%2F%3E%20%3Cattribute%20name%3D%27statecode%27%20alias%3D%27statecode%27%20groupby%3D%27true%27%20%2F%3E%20%3Cattribute%20name%3D%27statuscode%27%20alias%3D%27statuscode%27%20groupby%3D%27true%27%20%2F%3E%20%3Cattribute%20name%3D%27operationtype%27%20alias%3D%27operationtype%27%20groupby%3D%27true%27%20%2F%3E%20%3Clink-entity%20name%3D%27fileattachment%27%20to%3D%27datablobid%27%20from%3D%27fileattachmentid%27%20alias%3D%27fileattachment%27%20link-type%3D%27inner%27%3E%20%3Cattribute%20name%3D%27filesizeinbytes%27%20alias%3D%27TotalSize%27%20aggregate%3D%27sum%27%20%2F%3E%20%3Cattribute%20name%3D%27filesizeinbytes%27%20alias%3D%27RecordCount%27%20aggregate%3D%27count%27%20%2F%3E%20%3Cfilter%3E%20%3Ccondition%20attribute%3D%27objectidtypecode%27%20operator%3D%27eq%27%20value%3D%274700%27%20%2F%3E%20%3C%2Ffilter%3E%20%3Corder%20alias%3D%27TotalSize%27%20descending%3D%27true%27%20%2F%3E%20%3C%2Flink-entity%3E%20%3C%2Fentity%3E%20%3C%2Ffetch%3E
Accept: application/json  
OData-MaxVersion: 4.0  
OData-Version: 4.0
Prefer: odata.include-annotations="OData.Community.Display.V1.FormattedValue"

Web APIを使用してデータをクエリする方法を学ぶ

<fetch aggregate='true'>
  <entity name='asyncoperation'>
    <attribute name='owningextensionid'
      alias='owningextension'
      groupby='true' />
    <attribute name='statecode'
      alias='statecode'
      groupby='true' />
    <attribute name='statuscode'
      alias='statuscode'
      groupby='true' />
    <attribute name='operationtype'
      alias='operationtype'
      groupby='true' />
    <link-entity name='fileattachment'
      to='datablobid'
      from='fileattachmentid'
      alias='fileattachment'
      link-type='inner'>
      <attribute name='filesizeinbytes'
        alias='TotalSize'
        aggregate='sum' />
      <attribute name='filesizeinbytes'
        alias='RecordCount'
        aggregate='count' />
      <filter>
        <condition attribute='objectidtypecode'
          operator='eq'
          value='4700' />
      </filter>
      <order alias='TotalSize'
        descending='true' />
    </link-entity>
  </entity>
</fetch>

FetchXml を使用してデータのクエリを実行する

SELECT count(*) as RecordCount
   ,sum(filesizeinbytes) as TotalSize
   ,owningextensionid
   ,owningextensionidname
   ,statecode
   ,statuscode
   ,operationtype from fileattachment
 join asyncoperation on fileattachment.fileattachmentid =  asyncoperation.datablobid
 where fileattachment.objectidtypecode = 4700
 group by  owningextensionid, owningextensionidname, statecode, statuscode, operationtype
 order by TotalSize desc

Dataverse 表形式データストリーム (TDS) エンドポイントを使用して SQL を使用してデータをクエリする

結果で何を探すべきかは次のとおりです。

レコード数: RecordCount は、システムジョブレコードのグループごとに返されるレコードの数を示します。これにより、実行される非同期操作の量と、どのタイプが最も一般的かを把握できます。
合計ファイルサイズ: TotalSize は、これらの操作で処理されるデータの量を示します。これは、システムのパフォーマンスに影響を与える可能性のある異常に大きいファイルがあるかどうかを特定するのに役立ちます。
所有エンティティによるグループ化: owningextensionid、 owningextensionidname、 statecode、 statuscode、および operationtype によるクエリは結果。これらのグループ分けを確認して、どの拡張機能が最も多くのアクティビティを生成しているのか、また、優勢な特定の操作タイプがあるかどうかを特定します。
操作の状態とステータス: グループに statecode と statuscode を含めると、保留中、進行中、または完了しているこれらの操作の現在の状態とステータスを判断するのに役立ちます。
TotalSize による並べ替え: 結果は TotalSize によって降順に並べられるため、ストレージを最も多く消費している操作が強調表示される上位の結果に注目してください。これは、最適化またはクリーンアップの対象となる可能性のある領域を特定するために重要になる可能性があります。

システムジョブの削除

システムジョブの削除は、必要な権限を持っている場合は、他のテーブルと同様にアプリケーションやコード上で行うことができます。

注意

非同期プラグインを登録する場合、成功した操作を自動的に削除するオプションがあります。そのオプションを使用することをお勧めします。プラグインを記述する方法について

一般的な方法は、成功したジョブを削除する定期的な一括削除ジョブを作成することです。大容量の特定の対象データを一括削除で削除する方法について

システムジョブ状態の管理

システムジョブの状態は、操作が完了するまで何度か変更されます。以下は使用可能な状態およびステータス値を表す StateCode および StatusCode オプションです。

StateCode 値	StateCode ラベル	StatusCode 値	StatusCode ラベル
`0`	準備完了	`0`	リソースの待機中
`1`	中止	`10`	待機中
`2`	Locked	`20`	処理中
`2`	Locked	`21`	一時停止の処理中
`2`	Locked	`22`	取り消し中
`3`	完了	`30`	成功
`3`	完了	`31`	失敗
`3`	完了	`32`	キャンセル

設定 > システム > システムジョブの順に移動して、およびその他の操作メニューで利用可能なコマンドを使用して、アプリケーションのシステムジョブの状態を表示できます。

アプリケーションのシステムジョブに対して使用可能なアクションコマンド。

注意

この UI 経由で実行できる任意のアクションは、コードを使用して実行することもできます。プラットフォームによりで生成されるシステムジョブで、操作のキャンセル、一時停止、または再開を実行することはできません。操作の種類について

ビューを管理するオプションと共に、システムジョブを管理するための次のオプションが利用できます。

回答内容	内容
Delete キー	コントロール ID およびカスタムアクションの場所でビルドします。システムジョブを削除します
一括削除	その他の操作メニューを使用しています。条件を定義するウィザードを開き、一致するシステムジョブを削除する新しい一括削除システムジョブを作成します。
キャンセル	その他の操作メニューを使用しています。システムジョブをキャンセルします。
[再開]	その他の操作メニューを使用しています。一時停止したシステムジョブを再開します。
[後で再起動]	その他の操作メニューを使用しています。システムジョブのスケジュール変更
[一時停止]	その他の操作メニューを使用しています。システムジョブを一時停止します。

要求された操作が実行されるかどうかは、システムジョブの状態によって異なります。たとえば、すでに完了した、またはまだ開始していないジョブを一時停止することはできません。次のテーブルは、各変更の条件と、変更が選択されたときに何が起こるかを示しています。

回答内容	有効な StateCode 値	変更
Delete	指定なし	システムジョブを削除します
キャンセル	`0` (準備完了) `1` (中断) `2` (ロック)	`StateCode` が `3` (完了済み) に変更され、`StatusCode` が `32` (キャンセル済み) に変更されました
再開	`1` (中断)	StateCode が `0` (準備完了) に変更されました
後で再起動	`0` (準備完了) `2` (ロック)	ジョブの延期ダイアログでは、ユーザーは日時の値に関してシステムジョブを延期するよう求められます。システムジョブを延期する方法について
一時停止	`2` (ロック)	StateCode が `1` (中断) に変更されました

システムジョブの延期

PostPoneUntil カラムには、システムジョブの状態が 1 (一時停止) から 0 (準備完了) に変更する日時の値が含まれています。 PostPoneUntil、StateCode、StatusCode 列は、更新がサポートされている AsyncOperation テーブル列のみです。

参照

プラグインを記述する
 ビジネスプロセスを拡張するためのプラグインの作成

注意

ドキュメントの言語設定についてお聞かせください。簡単な調査を行います。 (この調査は英語です)

この調査には約 7 分かかります。個人データは収集されません (プライバシーステートメント)。

次の方法で共有

非同期サービス

実行順序および依存関係

システムジョブの管理

システムジョブの取得

例

操作の種類

定期実行の開始時刻とパターン

診断クエリ

状態、ステータス、タイプ別のジョブ

中断状態にある上位システムジョブの数 (数別)

ワークフロー件数

システムリソースが利用可能になるのを待っているジョブ

ファイルストレージのクエリ

AsyncOperation file storage datablobid count

AsyncOperations が BLOBストレージにありません

ファイルストレージを使用してジョブの名前を検索する

AsyncOperation ファイルサイズとレコード数

システムジョブの削除

システムジョブ状態の管理

システムジョブの延期

参照

その他のリソース

次の方法で共有

非同期サービス

実行順序および依存関係

システム ジョブの管理

システム ジョブの取得

例

操作の種類

定期実行の開始時刻とパターン

診断クエリ

状態、ステータス、タイプ別のジョブ

中断状態にある上位システム ジョブの数 (数別)

ワークフロー件数

システムリソースが利用可能になるのを待っているジョブ

ファイル ストレージのクエリ

AsyncOperation file storage datablobid count

AsyncOperations が BLOBス トレージにありません

ファイルストレージを使用してジョブの名前を検索する

AsyncOperation ファイルサイズとレコード数

システム ジョブの削除

システム ジョブ状態の管理

システム ジョブの延期

参照

その他のリソース

システムジョブの管理

システムジョブの取得

中断状態にある上位システムジョブの数 (数別)

ファイルストレージのクエリ

AsyncOperations が BLOBストレージにありません

システムジョブの削除

システムジョブ状態の管理

システムジョブの延期