IBM Business Process Manager 連載 : 事例に学ぶパフォーマンスの向上 第 4 回 SPARK UI Toolkit 活用による画面描画の高速化
概要 第 3 回画面描画の高速化 では CoachView の数に起因するパフォーマンス問題について その原因と改善策を解説しました 本ドキュメントでは SPARK UI Toolkit を用いて CoachView の描画コストを削減する具体的な実装アプローチについて説明します (Toolkit の種類と SPARK UI Toolkit の位置づけについては前回の記事を参照下さい ) IBM BPM8.5.7 の CF2017.06 で Salient Process SPARK UI toolkit をベースとした BPM UI toolkit が提供されました 詳細はこちらを参照してください https://www.ibm.com/support/knowledgecenter/en/ssftn5_8.5.7/com.ibm.wbpm.main.doc/topics/cbpm_ whatsnew-cf2017.06.html このドキュメントは Salient Process SPARK UI toolkit を利用して開発した事例をベースに記述しています Page 2
事象と事例 ヒューマン サービスを URL 公開し 以下のような画面を呼び出す際 その初期表示に時間がかかる可能性があります 画面構成は 共通メニューとメインの入力画面から成る 入力画面は複数のタブで構成されており それぞれのタブが 100 個程度項目を持っている 画面遷移時の処理として DB アクセスが必要 ( 数十回の SQL Select が必要 ) メニュー 稟議申請 購買申請 社員番号 申請日 最終更新日 A03301 2017/06/19 2017/06/23 申請者姓山田 申請者名太郎 Tab1 Tab2 Tab3 所属コード X15J3 新規 E-mail aaa@yyy.com 例外申請 共通メニュー CCC DDD Type XXX Button1 Button2 YYYYY ZZZZZ Column2 Column3 Column4 CellContent21 CellContent31 CellContent41 CellContent22 CellContent32 CellContent42 CellContent23 CellContent33 CellContent43 : : : CellContent29 CellContent39 CellContent49 メインの入力画面 Button3 Button4 Page 3
問題の背景 1. 初期データ取得画面遷移時の処理で DB アクセスが必要な場合 その SQL 量が増えるに従ってサービス実行に費やす時間がかかるため 結果的に Coach 画面表示に遷移するまでの時間がかかるようになります 2. Coach 画面表示画面表示完了まで ( 読み込み開始から画面表示が行われた瞬間まで ) には主に以下のようなステップが存在します 前号 第 3 回画面描画の高速化 で紹介した通り 画面の描画コストはCoachView1つあたりのコストとCoachViewの数に依存するため 画面項目数が増えるにしたがって特にレンダリング時間に影響が出ます Onload イベント発生までページ読み込み開始時点から 読み込み完了までの時間 JavaScript 実行 パース時間同期実行の JavaScript HTML および CSS のパース実行時間 レンダリング時間ブラウザが実行する画面描画そのもの 1. 初期データ取得 2. Coach 画面表示 画面表示完了 SQL 実行 リクエスト送信 受信 JavaScript 実行 パース時間 レンダリング時間 Page 4 Onload イベント発生
SPARK UI Toolkit による実装アプローチ 以降では SPARK UI Toolkit を用いた具体的な実装アプローチ Good Practice について説明します (1) SPARK UI Control の活用 Modal Section や初期表示しない Tab Section は Deferred Section を用いて Lazy-load Table 内で編集不要の column は Simple HTML を使用編集不要の Table は Service Data Table を使用 (2) 並列処理 Navigation Event と Deferred Section を用いてメインの入力画面の描画と SQL を並列で実行する (3) 画面の分離共通メニューは全画面で共通の為 メインの入力画面を別ヒューマン サービスとして定義初期画面への遷移時にはメインの入力画面のみを iframe で表示する Page 5
参考 SPARK UI Toolkit とは SPARK UI Toolkit で提供される CoachView は Dojo や AngularJS などの他のフレームワークを使用しておらず シンプルな HTML/CSS で記述されているため パフォーマンスが優れています 超軽量で独立したライブラリの提供 HTML5/CSS3 ベース 90 以上のコントロール部品を提供 (Enterprise 版 ) Salient Process サポート Web サイト https://support.salientprocess.com/ IBM BPM8.5.7 の CF2017.06 より BPM UI toolkit として製品に統合されています 詳細は P2 のリンクご参照下さい Page 6
(1) SPARK UI Control の活用 - Deferred Section Deferred Section を用いて遅延ロード (Lazy-load) させることにより 適切なタイミングで読み込みを実施します 特に 初期表示する必要のない Tab Section と Modal Section に適用することで 初期表示の体感速度を早める効果が得られます 構成オプションプロパティ説明選択 使用例 Lazy-load automatically Delay for auto-loading 指定した時間後に自動で遅延ロードするかの設定 ロードまでの待ち時間 ( ミリ秒 ) Event On lazy-loaded event Lazy-load 完了後のイベント処理 On/Off 5,000 Page 7
(1) SPARK UI Control の活用 - Table Table 内の編集不要 /Coach View が不要な column には Coach View ではなく Simple HTML を使用することで 表全体の表示待ち時間の改善が見込めます Columns オプションにて列毎のレンダリングオプションが選択可能 Coach View ( 常時編集可 ) render As 編集可否表示速度 Coach View 常時編集可 Seamless Coach View と同等 Seamless Coach View セルをクリックして編集 Coach View と同等 Simple HTML 編集不可 Coach View/Seamless Coach View よ り高速 Custom ( 定義による ) ( 定義による ) Seamless Coach View ( セルをクリックして編集可 ) Simple HTML ( 編集不可 ) Page 8
(1) SPARK UI Control の活用 - Table また Table の行の構築の間に同期処理を止める期間を設けることで 行の描画開始を早める効果が期待できます 特に Table に height を設定して height を超えてスクロールしないと表示されない行が存在する場合 この設定が有効です (1 度の同期処理で処理する行数 =Async Batch Size を height 分 + アルファ にする ) Performance オプションにて Async Loading と Async Batch Size が設定可能 Async Loading データを複数回に分けてロード 表示することで表示開始の待ち時間を減少大量行のテーブル表示時の体感を改善可能 Async Batch Size Async Loading 時に一度にロードする行数表示開始待ち時間 表示完了待ち時間を最適化する行数を設定する Page 9
(1) SPARK UI Control の活用 - Service Data Table Table 全体が Coach View 不要な場合は Service Data Table を使用することでパフォーマンス改善が見込めます (Service Data Table では Table に表示するデータを BO で保持する必要が無くなるため ) Behavior オプションにて Data Service が設定可能 Data Service Service Data Table で使用するデータを提供する Ajax サービスを定義 Page 10
(2) 並列処理 ヒューマン サービス内では 最初の Coach 表示までの時間をなるべく速くすることが重要です Navigation Event と Deferred Section を用いて メインの入力画面の描画と SQL を並列で実行することで 初期画面表示までのユーザーの体感速度が向上します Navigation Event を用いて SQL によるデータ取得を UI の初期処理をブロックすることなく非同期に行う Deferred Section を併用し SQL で取得したデータ項目をメイン入力画面に遅延ロード Navigation Event の 構成 > Events > Onload event に以下を指定 me.fire();${deferred_section1}.lazyload(100); メインの入力画面 Page 11
(3) 画面の分離 共通メニューは全画面で共通の為 メインの入力画面を別ヒューマン サービスとして定義し 初期画面への遷移時にはメインの入力画面のみを iframe で表示し 必要な画面のみをロードするような構成とします ヒューマン サービス 1 メニュー稟議申請購買申請 CCC DDD 社員番号 申請日 最終更新日 A03301 2017/06/19 2017/06/23 申請者姓山田 申請者名太郎 所属コード X15J3 新規 E-mail aaa@yyy.com 例外申請 ヒューマン サービス 2 Tab1 Tab2 Tab3 Type XXX Button1 Button2 YYYYY ZZZZZ Column2 Column3 Column4 CellContent21 CellContent31 CellContent41 CellContent22 CellContent32 CellContent42 iframe CellContent23 CellContent33 CellContent43 : : : CellContent29 CellContent39 CellContent49 Button3 Button4 Page 12
パフォーマンス改善例 前述の実装を適用することで 以下のような改善効果が期待できます <Before> 画面表示完了 SQL 実行 リクエスト送信 受信 JavaScript 実行 パース時間 レンダリング時間 Onload イベント発生 <After> Page 13 リクエスト送信 受信 Onload イベント発生 (2) 遅延ロード開始 JavaScript 実行 パース時間 (1)-a SQL 実行 JavaScript 実行 パース時間 レンダリング時間 画面表示完了 (1)-b レンダリング時間 遅延ロード分の表示完了 (1)-b 効果 (1)SPARK UI Control の活用 a. Deferred Section の遅延ロードにより 初期画面表示までのユーザーの体感速度向上 b. Table のオプション Service Data Table 利用による CoachView レンダリング時間の短縮 (2) 並列処理データ取得を UI の初期処理をブロックすることなく非同期に実行し ユーザーの待ち時間削減 (3) 画面の分離画面の分離により 必要な画面のみロードし SQL 実行以外の時間を全体的に短縮
まとめ BPM の画面描画を高速化するためには CoachView の描画コストを減らすアプローチが有効です CoachView の描画コストを減らすには 軽量な SPARK UI Toolkit の CoachView を採用することで一定のパフォーマンス効果が期待できます SPARK UI Toolkit は カスタム CoachView を開発せずに UI パフォーマンスを最適化する部品やオプションが標準で用意されています Page 14
参考 [Redbooks] Deliver Modern UI for IBM BPM with the Coach Framework and Other Approaches https://www.redbooks.ibm.com/redbooks.nsf/redpieceabstracts/sg248355.html SPARK UI Toolkit - Salient Process https://salientprocess.com/spark-ui-toolkit/ What's new in IBM Business Process Manager V8.5.7 cumulative fix 2017.06 https://www.ibm.com/support/knowledgecenter/en/ssftn5_8.5.7/com.ibm.wbpm.main.doc/topics/cbpm_whatsnew-cf2017.06.html Page 15