ワークフローエンジンの概要Issue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #7057C7; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: ; width: auto; height: auto; } } ワークフローエンジンの概要 Glide レコード内のワークフローを理解します。 Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #7057C7; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: ; width: auto; height: auto; } } Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #7057C7; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: ; width: auto; height: auto; } } ServiceNow のワークフローエンジン ワークフローエンジンは、Glide エンジンの一部を実行します。ワークフロープロセスを使用してアプリケーションを設計したり、既存のアプリケーションを拡張したりするには、Glide レコードトランザクションの一部としてワークフローエンジンがどこにあるかを理解することが重要です。 このラボでは、Glide トランザクションについて紹介し、そのトランザクションにおけるワークフローエンジンの位置と役割に焦点を当てます。 ワークフローエンジンは、各プロセスポイントの終了時に現在のレコードを更新することを常に保証します。 Glide エンジンはデータドライブであるため、一部のデータの状態の変化を知らせる イベント に反応します。 Glide イベントは、挿入、 更新、 削除 またはキャンセル キャンセルです。これらのイベントは、さまざまな方法でエンジンに発射されます。以下に例を示します。 UI アクション : ユーザーが 送信 ボタンをクリックすると、 insert イベントが Glide エンジンに起動>。ユーザーが [更新] ボタンをクリックすると、 update イベントが Glide エンジンに起動>。ユーザーが [削除] ボタンをクリックすると>、 削除 イベントが Glide エンジンに発生します。ユーザーが [トランザクションをキャンセル] アイコン ->をクリックすると、 キャンセル イベントが Glide エンジンに発生します。 スクリプト内: GlideRecord を>初期化する insert イベントを初期化するスクリプトが Glide エンジンに起動されます。 GlideRecord gr = new GlideRecord (‘incident’); gr.initialize(); gr.insert();current -> delete イベントを削除するビジネスルールが Glide エンジンに発生します。 GlideRecord gr = new GlideRecord (‘incident’); gr.get(‘specify_sys_id’); gr.delete(); これらの各イベントが Glide エンジンに発射されると、一連の変換とプロセスが開始されます。1 つのイベント = 1 つの Glide トランザクション。これらの各イベントが Glide エンジンに送信されると、一連の変換とプロセスが開始されます。 ワークフローは、 デフォルトワークフロー としてデータ変換レイヤーの一部であり、 保留ワークフロー として後処理の一部です。いずれの場合も、ワークフローエンジンは、フィールド正規化やデータポリシーなどの他のエンジンとともに、2つのビジネスルールセットの間に挟まれています。 ビジネスルールの順序値は、サンドイッチされたエンジンの周りで実行される順序を決定します。順序が 1000 未満のビジネスルールは、Workflow を含む他のエンジンよりも先に実行されます。1000 以上の順序のビジネスルールは、Workflow を含む他のエンジンの後に実行されます。 ビジネスルールとワークフローはどちらも、データが格納される前 (変換) またはデータが格納された後 (ポストプロセッサ) に実行されるように構成できます。 データが保存される前に実行されるようにビジネスルールを設定するには、フォームの 前 チェックボックスをオンにします。 デフォルトでは、データが保存される前にワークフローが実行されます。 データが保存された後に実行されるようにビジネスルールを設定するには、フォームの 後 チェックボックスをオンにします。 データが保存された後に実行されるようにワークフローを設定するには、ワークフローのプロパティフォームの ビジネスルールの後に実行 ボックスをオンにします。 注:これらのそれぞれについて、具体的に少しだけ見ていきます。 トランザクションのグラフィックに詳細を追加すると、次のようになります。 ワークフローデザイナーとして、Glide トランザクションの各参加者のタイミングを理解することが重要です。 データベース操作の後に実行される 保留ワークフローは、現在のレコードへの変更を確実に保持し、保持が同じデータベーストランザクションの一部 ない ようにします。覚えておいてください One event = One Glide Transaction.保留ワークフローが呼び出されたときにデータはすでに保存されているため、ワークフローエンジンは2番目の更新イベントを強制します。ただし、この更新イベントは独立したネストされたトランザクションを開始し、元のイベントから 1000 以上の注文後のビジネスルールが発生する前に完了します。 注意: デフォルトのワークフローはデータベースイベントの一部として実行され、 Deferred Workflow はcurrent、 ワークフローアクティビティスクリプトフィールド内の任意の場所でcurrent.update(;を呼び出す必要はありません)の独自のネストされた更新を実行するため。 update() を呼び出すたびに、独立した update イベントが作成されることに注意してください。独立したイベントとして、アプリケーションのパフォーマンスに影響を与える不要なネストされた更新が発生します。 1 つのイベント = 1 つの Glide トランザクション アプリケーション内のワークフローデザイナーは、アプリケーション内にも存在するビジネスルールとエンジン、およびそれぞれがプロセスを推進するデータにどのような影響を与える可能性があるかを認識することが重要です。 ワークフローデザイナーは、データがいつどのように変換されるか、どのプロセスプレーヤーによって変換されるかを予測できる必要があります。アプリケーションの複雑さに応じて、他のノードまたはスレッドがそのデータにいつアクセスできるかを知ることも同様に重要です。 注意:ほとんどのビジネスプロセスは、 デフォルトワークフローで非常に適切に機能します。ワークフローを 保留ワークフロー に設定する場合は、現在のレコードで 2 つの更新のタイミングに注意してください。 Glide 移行の後処理フェーズで 保留ワークフロー が Glide レコードにアサインされていない場合、デフォルトでは現在のレコードは 更新されませんGlide トランザクションの後処理フェーズの最適な使用法は、データの変更を継続するのではなく、データの変更に対応することです。