WebPerformer V2.5 で SPA 画面からビジネスプロセスを呼び出す

はじめに

こんにちは。エヌデーデー関口です。
前回の記事では、WebPerformer V2.5 の新機能「UI エディタ」を利用して、SPA に対応した Web アプリケーションの画面デザインについてご紹介しました。
今回は SPA に対応した Web アプリケーションから従来の WebPerformer で作成したビジネスプロセス(BP)を呼び出して処理をさせるということについてご紹介します。

想定される読者

  • WebPerformer V2.5 での開発は未経験
  • WebPerformer で IO、DM、BP などのオブジェクトを理解している

作成するアプリケーション

今回の例では、簡単な TODO アプリを作成します。そして、従来の入出力(IO)、新しい SPA 対応画面(UI)で作った場合を比較しながら進めます。

データモデル(DM)作成

まず、TODO という名前の DM を用意します。この DM には、ID、内容、期限という項目を含むものとします。

また、DM 操作は STORE 処理のみを準備します。
下図の STORE 処理(STR001)は、レコードを新規登録する際に ID をカウントアップしながら登録するという処理になります。

ビジネスプロセス(BP)作成

次に SAVE_TODO という名前の BP を作成します。こちらを IO と UI の両方で利用する予定です。
こちらも複雑な処理はいれず、画面で受け取った値(IN 操作)を元に DM 操作を呼び出し、その結果を画面に返すという内容になっています。
余談ですが、V2.3 からは BP 編集画面では各行に制御コードのアイコン表示や、コメント行の追加(これが欲しかった!)、プロジェクトで共有できるスニペットをビジネスプロセス テンプレートとして登録出来るなど開発者にとって便利な機能が追加されていたりします。

入出力(IO)で画面作成

それでは画面を作成しますが、まずは従来の WebPerformer で利用されてきた入出力(IO)で画面の作成を行ってみます。

一覧画面

一覧画面では、TODO の一覧を表示するほか、登録画面へ遷移する追加ボタンと、各行の編集画面に遷移するための編集ボタンを追加しています。

実際にアプリにしたときの画面は次の通りです。

詳細画面

詳細画面では入力項目をテーブルに保存するための保存ボタンを追加しており、このボタンから先ほど作成した BP を呼び出すように定義しています。

それから、呼び出し元画面(TODO リスト)から指示された ID のデータを表示するための対象条件も指定します。

実際にアプリにしたときの画面は次の通りです。

SPA 画面(UI)で画面作成

IO で作った TOOD のアプリケーションと同じような機能を SPA で作ってみましょう。

一覧画面

レイアウト作成

UI を利用した一覧画面のレイアウトです。一覧形式を表示するためには、左ペインから「グループ」の部品を選択します。今回は「ページ付き一覧」を利用しました。

データバインド

UI で作成した画面にデータを紐付けます。編集画面の左下にある「アクション」を押すと下図のような画面になります。

左上の白いエリアをクリックしてみると、アクション一覧というダイアログが表示されます。
これは UI で利用した部品に対して操作を行ったときにどのようなアクションを実施するのかを切り替えるために利用します。
初期状態では、画面を初期表示した際にどのようなアクションを実施するかが選択されています。

編集画面に戻り、左ペインを全て開いてみましょう。様々な処理や分岐が選べることがわかります。

ここで一覧に表示するべきデータを取得するため、「対象条件データ処理」を中央のフローにドラッグ&ドロップしましょう。

右ペインで「対象条件データ処理」の内容を記入していきます。

  • DM 設定:取得する DM をドロップダウンから選択します。
  • 抽出条件式:IO で定義する対象条件と同じ記述の仕方が出来ます。
  • 変数名:抽出したデータをこのアクションフローの中で扱うときの変数名を定義します。DM で抽出した結果は、{変数名}.data という属性に配列として格納されています。
  • 出力データバインド設定:アクションの処理が終わったときに、UI の部品やセッションにどの様な値を入れるのかという設定になります。

なお、一覧形式の UI の部品のバインドは、一覧の中の部品名とバインドしたい配列の中の属性名が同じであれば、自動的にバインドしてくれるという特徴があります。
今回の画面では UI の部品名と、DM の項目名が一致しているので、todoList.data という DM の取得結果をそのまま UI の list という一覧部品に当てはめるだけでよい訳です。

DMの対象条件取得結果の例

"todoList" : { // todoList はアクションのSTEP上で定義した変数名
  "data" : [ // data の中に取得したレコードの配列が入っている → UI にコピーされる
    // id, text, end_date はDMの項目名
    {"id" : "xxxx", "text" : "あいうえお", "end_date" : "2021-01-01"},
    {"id" : "yyyy", "text" : "かきくけこ", "end_date" : "2021-01-01"},
    {"id" : "zzzz", "text" : "さしすせそ", "end_date" : "2021-01-01"}
  ],
  "page" : {
    "total" : 2,
    "offset" : 0,
    "limit" : 20,
    "start" : 1,
    "end" : 2
  },
  "message" : "xxxxxxx",
  "error" : false,
  "errorMessage" : ""
}

上記の JSON 形式が DM 取得の結果として得られたとします。
今回の画面上の設定では、todoList.data の下の配列がそのまま UI に設定した list という一覧形式オブジェクトの配列にコピーされて、下のような状態になります。

UI 側に反映された状態の例

"list" : [ // list はUI上の部品名。todoList.data の中身がコピーされてくる。
  // id, text, end_date はUI上の部品名と一致している
  {"id" : "xxxx", "text" : "あいうえお", "end_date" : "2021-01-01"},
  {"id" : "yyyy", "text" : "かきくけこ", "end_date" : "2021-01-01"},
  {"id" : "zzzz", "text" : "さしすせそ", "end_date" : "2021-01-01"}
]

そして、UI 上でそれぞれの項目の名称も一致してるため、加工せずに画面上に表示されるのです。
なお、項目名が不一致である場合は、DM で値を取得した後、スクリプトという STEP で JSON の形式を加工して、UI の部品と名称を合わせてからバインドするという手順になります。

画面遷移

レイアウトに戻って、追加ボタン、編集ボタンの動きを編集します。
追加ボタンのプロパティでは、従来の IO の画面と同じように次画面を指定します。
また、次の画面(今回であれば詳細)に引き渡すパラメータは従来の IO のようにキーとなる項目を渡すということも出来ますし、一覧の一行全体の値を渡すということも出来ます。
それぞれ次のような動作になります。(項目名は今回の画面を例にしています)

  • キー項目を渡す場合(次画面パラメーターに id を登録)
    1. 詳細ボタンを押すと、該当行の id の値が次の画面に引き渡されます。
    2. 遷移した画面のアクション「初期画面」で、受け取った値から DM を検索します。
    3. DM 検索した結果を画面上の項目に設定します。
  • 一行全体を渡す場合(次画面パラメーターに list を登録)
    1. 詳細ボタンを押すと、該当行の id, text, end_date の値が次の画面に引き渡されます。
    2. 遷移した画面のアクション「初期画面」で、受け取った値を画面上の項目に設定します。

このように、列の値全体を渡す場合はデータベースへの問合せが減るので画面描画も素早くなるという効果があります。
その代わり、データベースの内容が頻繁に変わるようなアプリケーションである場合は、最新状態を取得できないというデメリットもあります。
アプリケーションの特性によって使い分けした方が良いでしょう。
今回は列全体を次画面パラメーターに設定します。

詳細画面

レイアウト作成

詳細画面のレイアウトはシンプルに入出力項目とボタンだけの配置です。

保存ボタンのアクション(BP 呼び出し)

さて、いよいよ本題の BP 呼び出しです。
アクション編集画面に移動して、アクション一覧ダイアログを開き、保存ボタンを選択してください。

その後、左ペインから「DM バインディング」と「BP データ処理」の順番で選択してフロー上に配置します。

次に右ペインの「入力データバインド設定」を下図のように設定します。
左側の変数名は、このアクション内で使用する変数名で、それに対して画面の部品の名前を代入するということを意味しています。(変数名であることをわかりやすくするために、var_hogehoge という名称にしています)
なお、UI の部品名をそのまま変数のようには利用できないので注意してください。

次に DM バインディングの STEP をクリックしてプロパティを編集します。
BP の IN として渡す DM コードを指定して、それぞれの項目に何の値を代入するかを設定します。
ここでも、先述したように代入元の配列の属性名と DM の項目名が一致していれば自動的にバインドしてくれます。
今回は名称が異なるため図のように項目一つずつに変数を代入をしています。
最後に出力ということろで、DM 形式に値を詰め込んだ結果を変数として名前(bindResult)をつけて次の処理で利用できるようにします。

次は BP データ処理の STEP のプロパティを編集します。
実行設定の値というところで、先に設定した DM 形式の変数(bindResult)を BP の IN として利用するということを宣言します。
加工式(BP または組込 BP)には、先ほど作成しておいた SAVE_TODO という BP を設定します。

画面へのメッセージ

保存ボタンを押したときに確認メッセージを表示したり、保存処理が成功(あるいは失敗)したときに画面にメッセージを出す設定をします。
確認メッセージは、ボタンのプロパティ「確認メッセージ」にテキストを登録しておきます。

処理終了後のメッセージは、アクション編集画面の上部にある「!」ボタンを押して設定します。
なお、今回の説明では省略しますが、失敗メッセージは「例外スロー」という STEP を利用した場合に表示されますので、処理の結果で成功失敗を判断する分岐をして「例外スロー」を経由させるフローを作成しましょう。

IO と UI の動作比較

これで IO、UI のそれぞれのバージョンでアプリが作成できました。
動きを比較してみましょう。左がUIを使って作成した画面、右がIOを使って作成した画面です。

このように見た目は違うのですが、同じ BP や DM を利用して処理が作れます。

まとめ

このように、SPA に対応した UI で画面を使う場合でも従来の BP や DM はそのまま利用できるということが理解できたかと思います。

たとえば、承認画面などを従来の IO で作っていた画面があり PC 画面での操作には問題なかったもの、ユーザーから外出先でスマートフォンを利用して手軽に処理したいというようなニーズがでてきた場合、DM や BP は IO 版で作成したものを使いつつ、画面だけは UI を利用してスマートフォンに対応させるということも可能だということです。

表示できる情報や、処理の複雑さを加味して、UI へ一部機能を移行するということも検討してみてはどうでしょうか。

次回も UI を使った別の機能や利点などをご紹介したいと思います。