ライフサイクルイベントのベストプラクティスとパフォーマンスの期待 - Support and Troubleshooting

ライフサイクルイベントのベストプラクティスとパフォーマンスの期待 .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } このドキュメントでは、独自のテストとお客様との作業経験に基づいて、ライフサイクルイベントを作成するときにパフォーマンスを最適化し、実行時の問題を回避するためのベストプラクティスを共有します。すべての考慮事項をカバーすることを意図したものではなく、実装ガイダンスの唯一の情報源として扱うべきではありません。

ライフサイクルイベントの一般的なベストプラクティス 徹底的なテストを行わずに進行中のケースがある場合は、本番環境でライフサイクルイベントを変更しないでください。 構成を変更すると、ワークフロー内のどの段階にあるかによっては、進行中のケースに予期しない結果が生じる可能性があります。本番環境で変更が必要で、進行中のケースがある場合は、次のことをお勧めします。 既存の LE ケースをクローンして本番化し、テストして、問題がないかどうかを確認します。 ライフサイクルイベントをクローンし、新しいライフサイクルイベントで新しいケースを作成する。 注意 :このアプローチでは、オーバーヘッド/メンテナンスが増えます (たとえば、顧客は新しい LE タイプを指すように HR サービスを更新または作成する必要がある場合があります)。また、顧客が既存/進行中のケースに新しい構成変更を適用することを希望する場合、これは顧客のユースケースを満たしていません。 トリガー済みのライフサイクルイベントケースの対象者を変更したり 対象者のいないライフサイクルイベントケースを作成したりしないでください。これにより、ワークフローに問題が発生する可能性があります。

アクティビティセットをより即座にトリガーするように評価間隔を変更しようとする場合は注意が必要です - アクティビティセットをより即座にトリガーするには、 条件付きビジネスルール を使用することをお勧めします。これが発生した場合は、[ケースを再開] ボタンを使用して処理を再実行し、キャンセルされたアクティビティを再処理できます。以下は、顧客が並列処理スレッドが消費されると予想できるタイミングを示す最大アクティビティ数に基づく計算の表です。

取り消しとキャンセル いつ使用しますか?取り消すは、既に開始されているプロセスを撤回する必要がある場合に使用する必要があります。たとえば、既にオンボーディングプロセスを開始しているが、組織に参加しないことにした新規雇用者がいる場合は、そのライフサイクルイベントケースを取り消すことができます。これにより、ライフサイクルイベント用に構成したロールバックプロセスがトリガーされ、結果として適切なアクティビティがトリガーされる (またはトリガーされないようにする) ようになります。トリガーするカウンタープロセスが必要ない場合は、ケースをキャンセルできます。

resume を使用するタイミング: ケースの「再開」には次の 2 つの用途があります。 LE アクティビティセットでエラーが発生したか、キャンセルされた場合。エラーを修正してから、ケースを再開する必要があります。 変更を適用してワークフローを再開するために、アクティビティセットを手動でエラー処理しないでください 。これにより、古いコンテキストが計算リソースを使用してアクティブな状態のままになっているときに、ワークフローコンテキストがぶら下がっています。 重要:ケースの作業メモを参照して、ケースでエラーが発生した理由を確認することもできます。 ケースを一時停止し、それを「再開」する準備ができている場合。一時停止/再開機能を使用するタイミングの詳細については、 ドキュメントを参照してください。

ライフサイクルイベントのトリガーに使用されている HR サービスでライフサイクルイベントタイプを指定するときは注意が必要です。 タイプには、同じライフサイクルイベント内のアクティビティによって呼び出される同じライフサイクルイベントタイプを含めることはできません。これにより無限ループが発生します。ライフサイクルイベントタイプは、選択したライフサイクルイベントをトリガーするために使用されます。ライフサイクルイベントから HR ケースを作成しようとしている場合は、通常の HR サービスを使用する必要があります。

ライフサイクルイベントでのパフォーマンスのベストプラクティス

トラブルシューティングのベストプラクティスに関する FAQ こちらを参照してください

TLDR:基盤となるワークフローが複雑であるほど、[ライフサイクルイベント要求] ページ (hrm_ticket_page) での従業員とマネージャーのアクティビティのロード時間が遅くなります。

注意:このドキュメントは、新しいジャーニーデザイナー UI には関連しておらず、要求ページ(hrm_ticket_page)にのみ関連します。ジャーニーページのパフォーマンスが向上します。ジャーニーデザイナーについて詳しく知りたい方 ライフサイクルイベントの従業員エクスペリエンスを移行して新しいジャーニーデザイナーを活用する方法について詳しくは、この コミュニティの投稿 および参照された移行ガイドを参照してください。

アクティビティセットに含めるアクティビティの最大数はいくつですか?

パフォーマンスはアクティビティの数とアクティビティの複雑さの関数であるため、答えは 1 つではありません。アクティビティセットの一部かアクティビティコンテナーかにかかわらず、一度に 10 個以下のアクティビティをトリガーすることをお勧めします。一度にトリガーする回数が多いほど、パフォーマンスは低下します。アクティビティが複雑でない場合は、これを超えてもかまいません。次の要因は、さらにパフォーマンスに影響を与える可能性があります。

従業員が HR サービスをトリガーするタスク (カタログ要求など) を完了しています。要求が複雑であればあるほど、パフォーマンスは低下します。 複数のアクティビティセットを一度にトリガーする (バックグラウンド呼び出しが多いほど、パフォーマンスは低下します)

お客様の例:

顧客 1: 顧客には 5 つのアクティビティセットにわたる 42 のアクティビティがあります

ケースの作成: 90 〜 120 秒 従業員のアクティビティロード時間: 1 つのアクティビティの完了から次のアクティビティのリロードまで 7 〜 10 秒 パフォーマンス測定基準 このドキュメントでは、次の UI について説明します。 要求ページ (特にライフサイクルイベント用) 注意:要求 UI は、ジャーニーデザイナー (Tokyo+) で利用可能な新しいジャーニーページよりもパフォーマンスが遅くなります。

[要求] ページのライフサイクルケースのパフォーマンスメトリクス: 以下は、ライフサイクルイベントに関連するパフォーマンスの期待値です。次のリリースで改善と更新を行いました:

従業員センター Core 27.1.1 ストアリリース Utah ファミリー:デスクトップとモバイルの [要求] ページでレコード監視の複雑さを軽減することでパフォーマンスが向上 バンクーバーファミリー:今後の調査に基づいて、引き続きパフォーマンスの改善を行っていきます。 注意:これらの更新により、[要求] ページのパフォーマンスが向上します。

[要求] ページのライフサイクルケースのパフォーマンスメトリクス: パフォーマンスメトリクスを実行して、あるアクティビティが完了して次のアクティビティがロードされるまでにかかる時間を把握しました。

観察事項: 「電子署名」、「完了としてマーク」、およびラーニングタイプのアクティビティは、次のアクティビティのロードに 4〜10 秒かかります。 後続のケースまたは要求を送信するアクティビティには、10 秒から 15 秒と長くかかります。 例:IT 要求、注文ガイドの送信、レコードプロデューサーの送信 (完全なプロファイル情報により、レコードプロデューサーが送信され、ケースが作成されてクローズされます) アクティビティセット内の最後のアクティビティが完了すると、次のアクティビティのロードが開始されるため、ロード時間が遅くなります (下のデータを参照)

パフォーマンスデータ – デモデータ

これらの結果では、新規雇用オンボーディングのデモデータを使用しています。

注:完了までの時間は秒単位です。

パフォーマンスデータ – アクティビティセット内の 50 のアクティビティ

これらの結果は、「完了としてマーク」および「ビデオを見る」タイプのアクティビティ [NH1] [NH2] [LC3] を使用して、複雑さの少ないタスクタイプ(ボリュームが大きい場合でも)ロード時間が短いことを示しています。