非同期サービス
非同期サービスは、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> に従います。
操作の種類
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"
中断状態にある上位システム ジョブの数 (数別)
このクエリを使用して、一時停止中状態の AsyncOperation テーブル内のすべてのジョブの数を抽出します 。 このクエリは次に役立ちます。
- 待機中のジョブの量と性質を理解します。
- ホールドアップが発生している場所を特定します。
- システムのパフォーマンスとスループットを向上させるためにそれらに対処する方法について情報に基づいた決定を下します。
このクエリは count 降順で順序付けされていません。 代わりに Web API で FetchXml を使用することもできます。 FetchXml を使用してデータのクエリを実行する
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"
結果で何を探すべきかは次のとおりです。
一時停止ジョブの定量化: このクエリは、 一時停止 (
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"
結果で何を探すべきかは次のとおりです。
ワークフロー固有のジョブ:
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"
結果で何を探すべきかは次のとおりです。
リソースを待機している準備完了ジョブのフィルター: 準備完了 と リソースを待機中 にあるジョブに対して
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
結果で何を探すべきかは次のとおりです。
データストレージへの影響: スペースを節約するためにファイル ストレージを使用する際にレコードを削除する必要がある場合があるため、これを知っておくと役立ちます。 数値が大きい場合は、これらの 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
結果で何を探すべきかは次のとおりです。
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"
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"
結果で何を探すべきかは次のとおりです。
- レコード数:
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 分かかります。 個人データは収集されません (プライバシー ステートメント)。