ワークフローのベストプラクティスDescription ワークフローのベストプラクティス | ヒントと注意点 避けるべきこと ワークフローを構築する際に避けるべきことのリストを次に示します。 ワークフローのバージョンは絶対に削除しないでください。代わりに、ワークフローバージョンを非アクティブに設定します。 [タスクの作成] アクティビティまたは [スクリプトの実行] アクティビティを使用する場合は、ワークフローバージョンで使用されている [テーブル] と同じテーブルにレコードを作成しないでください。これを行うと、無限ループが発生します。いずれのワークフローアクティビティでも gs.sleep を使用しないでください。gs.sleep ではセッションが解放されず、ワークフローはスレッドを保持します。インスタンスは他のジョブのワーカースレッドを使い果たします。gs.sleep の代わりに [ワークフロータイマー] アクティビティを使用してください。 REST v2 にはターゲットサーバーからの応答を待機するタイマーが内部にあり、これによりスレッドが占有されます。ワークフローアクティビティ内で「current.update()」を使用しないでください。特に、sysapproval_group テーブルでは [承認グループ] アクティビティから、sysapproval_approver テーブルでは [承認ユーザー] アクティビティから update() を呼び出さないようにしてください。ワークフローエンジンは、ビジネスルール < 1000 の前からビジネスルール >= 1000 までの間に実行されます。変更を保存するために update() を実行する必要はありません。 ステージフィールドを使用してワークフローを駆動しないでください。ワークフローがステージフィールドを設定します。[分岐] アクティビティを使いすぎないようにしてください。ワークフローの公開には時間がかかる場合があります。ワークフローは実行中に中断する場合があります。複数の並行承認者を待機している場合は、代わりに [承認コーディネーター] アクティビティを使用します。アクティビティのグループをサブフローに移動できる場合は、代わりにアクティビティをサブフローに分割してください。 [承認コーディネーター] アクティビティ内に複数の [手動承認] アクティビティを配置することはできません。 ワークフローアクティビティの定義、ワークフロー関連のビジネスルール、「Workflow*」スクリプトインクルードにカスタマイズを追加しないでください。ワークフローと承認機能を駆動するのはこれらのファイルです。これらのファイルに対しては継続的な更新が行われています。どうしてもカスタマイズする必要がある場合は、新しいパッチがインスタンスに適用されるたびにカスタマイズを再確認してください。[ロールバック] アクティビティは、既に実行されたアクティビティにのみ移行する必要があります。[ロールバック] アクティビティは、承認アクティビティのステータスを「未要求」に、タスクアクティビティのステータスを「オープン」または「処理待ち」に更新するだけです。ファイルの削除やメールの送信のような外部システム操作を実行するアクティビティ、または値の設定やスクリプトの実行アクティビティによる変更はロールバックされません。[ロールバック] による移行はシンプルに保ち、[If] アクティビティにはロールバックしないようにしてください。 オーケストレーションのためにパラレルフローランチャーアクティビティ (PFL) を使用する場合は、[タスクの作成] を使用し、このタスクに別のワークフローを添付することを検討してください。例えば、オンボーディングアクティビティを実装する場合は、PFL を使って各種スクリプトを実行するとワーカースレッドが占有されてしまうため、代わりに複数の [タスクの作成] アクティビティを使用し、それぞれのタスクに専用のワークフローを使うことを検討してください。 ワークフロー SC 変数でカタログアイテム変数を再宣言しないでください。これは RITM レコードと SCTASK レコードに重複した変数名が表示される原因になります。ワークフロー SC 変数を使用すると、ワークフローの実行中に新しい変数を RITM に返すことができます。ユースケースの例：サービス遂行ステージで、資産の取得後に資産タグが生成されます。この資産タグはカタログ変数の一部ではありませんが、ワークフロー SC 変数経由で RITM に送信できます。 含めるべきこと ワークフローを構築する際に含めるべきことのリストを次に示します。 ワークフローアクティビティ内からレコードの取得やアクセスを行う場合は、以下のガイドラインに従って、ワーカージョブが長時間実行されないようにします。 null の結果や存在しないレコードを考慮に入れてチェックを追加します。1 レコードのみが想定される場合は、「while (gr.next())」ではなく「if (gr.next())」を使用します。「while」ループが必要な場合は、ループを抜けるのにかかる時間の上限を追加することを検討してください。 ワークフローが開始されたらすぐに、変数の値やその他のデータをワークフロースクラッチパッドに保存します。コンテキストがしばらくアイドル状態になり、変数が失われる場合があるためです。ワークフローコンテキストを再利用する場合は、最大アクティビティ数に注意してください。可能な場合はいつでも、既存のコンテキストは再利用せず、ワークフローの新しいインスタンスを開始してください。 ワークフローの設計に多数のアクティビティと移行 (30 件以上) が含まれる場合は、アクティビティをサブフローに分割することを検討してください。繰り返されるアクティビティもサブフローに移動することを検討してください。 手動承認を追加できるのは、[承認コーディネーター] アクティビティ内の [手動承認] アクティビティが実行中の場合のみです。これらの承認をワークフローアクティビティで取得するには、 「glide.manual.approval.pickup_on_update」プロパティを「true」に設定し、親レコードの更新またはワークフローコンテキストへのブロードキャストイベントが発生する必要があります。例： new Workflow().broadcastEvent(wfContext.sys_id, 'update'); 詳細については、PRB1115684 を参照してください。 [承認グループ] アクティビティは、異なるグループが承認を検討する必要がある場合に使用されます。グループ内の全員の承認が必要な場合は、代わりに [承認ユーザー] を使用する必要があります。OOB ステージフィールドを持たないテーブルでは、「ワークフロー」タイプのカスタムフィールドにワークフローのステージ値を格納できます。ワークフローバージョンのプロパティの下で、[ステージ] タブが表示されるのは、テーブルに「ワークフロー」タイプフィールドが含まれている場合のみです。 [生成] アクティビティは、それぞれのアクティビティが実行される前に、タスクと承認を事前に生成します。[生成] アクティビティは、実行前にタスクと承認を変更する必要がある場合、または予期される承認やステップをユーザーに示す場合にのみ使用します。それ以外の場合は、[タスク] および [承認] アクティビティの実行時にタスクと承認が作成されます。 役に立つナレッジ記事 ワークフローに関連する役立つ記事のリストを次に示します。 ワークフロータイマースケジューラージョブをワークフローコンテキストに一致させて実行中のスクリプトを見つける方法ワークフロータイマーの利用方法データやセットアップによる問題ではありませんか？タイマーが必要です。スクリプトとエンジンの実行順序ワークフローのリソース