はじめに
当社はかねてより、超高速開発のソリューションとしてローコード開発基盤「OutSystems」の導入支援およびアプリケーション開発に力を入れてきました。
これまでに、OutSystems以外のローコード開発基盤として「Mendix」と「Power Platform」を取り上げ、開発基盤としての機能や操作感を、OutSystemsと比較しました。
記事「ローコード開発基盤OutSystemsとMendixを比べてみた」
記事「ローコード開発基盤OutSystemsとPower Platformを比べてみた」
今回はその第３弾として、キヤノンＩＴソリューションズ株式会社が製造・販売している「Web Performer」について紹介していきたいと思います。
Web Performerとは
Web Performerとは2005年よりキヤノンＩＴソリューションズ株式会社が提供する国産の超高速開発／ローコード開発プラットフォームです。
開発者が
- スキーマ情報として「データモデル（DM）」
- 画面情報として「入出力（IO）」
- 必要に応じて業務フローとして「ビジネスプロセス（BP）」
を設計情報として定義することにより開発者のスキルに左右されることなく、バグや属人性が排除され、安定したWebアプリケーションを開発をすることが可能です。
なお、Web Performerには他に関連サービスが３つあります。本記事では触れませんが、ご紹介のみさせていただきます。
- Web Performer WF、Web Performer WF+
- 業務の自動化を目的とし、帳票フォームやワークフローの作成
- Web Performer Cloud
- 2020年1月31日より販売開始。Web PerformerをAmazon Web Services上に搭載したクラウドプラットフォーム
OutSystemsとWeb Performerを比較
本記事では、「データモデリング」「ユーザインタフェース」「ロジック」「デプロイ」の４項目について、OutSystemsとWeb Performerを比較していきます。
Web Performerの詳しい使用方法を知りたい方は、Web Performerによる開発に関する記事を別に公開していますので、そちらをご覧ください。
１．データモデリング
データベースのテーブルやビューは、データモデルとして定義します。
アプリケーションで使用するテーブル設計情報（主キー、桁数、データタイプ、外部キー等）を定義します。データモデルにて親子関係を設定する場合には、子側の項目に対して関連するデータモデルと項目をそれぞれ「データモデルコード」・「データモデル項目コード」（図１の右２列）として設定します。
また、テーブルに対する検索／更新／排他制御操作もデータモデルの一部として定義します。
独立コミットはテーブル操作定義毎に、「独立コミット」を「あり」にすることで設定可能です。独立コミットとは、対象のデータモデル操作を別トランザクションで実行し、独立してコミットすることを意味します。他トランザクションとの待ち時間を小さくしたい場合などに使用します。
また、スキーマ情報からデータモデルを自動生成することが可能です。対象となるデータベースとテーブルを指定することで、テーブルに対応するデータモデルを一括作成できます。
反対にデータモデルをWeb Performer上で先に定義し、データモデル定義から対象のデータベースにテーブルを作成することも可能です。図５のようにDDLのタイプ・データモデル・データベースを選択することで、図６のようにDDLを自動生成します。画面から「DDL実行」をすることでWeb Performer上からテーブル作成が行えます。
実際に図６で作成されたDDLが下記になります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
#NAME? -- -- 表 - データモデル[employee_qualification:社員資格対応テーブル] -- -- -- 項目[emp_id:emp_id] -- 項目[qua_id:qua_id] -- 項目[qualified_at:qualified_at] -- 項目[expired_at:expired_at] -- 項目[tmstamp:tmstamp] -- create table employee_qualification ( emp_id qua_id qualified_at expired_at tmstamp ) ; -- -- 制約 - データモデル[employee_qualification:社員資格対応テーブル] -- alter table employee_qualification add primary key ( emp_id , qua_id , qualified_at ); alter table employee_qualification add constraint FK2_EMPLOYEE_Q foreign key ( qua_id ) references qualifications ( qua_id ) ; alter table employee_qualification add constraint FK3_EMPLOYEE_Q foreign key ( emp_id ) references employees ( emp_id ) on delete cascade; \q |
OutSystems との比較
OutSystemsとWeb Performerは共に項目名や桁数、主キー等を手動で設定します。また、OutSystemsはExcelのテーブルフォーマットを取り込むことでテーブル自動作成を行い、Web Performerはデータモデル定義を元にテーブル自動作成を行います。
テーブル作成・削除・変更を行う際に、OutSystemsはDDL操作を意識することなく実施可能です。対して、Web Performerはスキーマ情報が変更された場合には、データモデルに反映する必要があります。
２．ユーザインターフェース
Web Performerにおけるユーザインターフェースは入出力として設定します。
作成するアプリケーションの画面や画面遷移情報、入力項目、ビジネスプロセス（後述します）を呼び出すアクション（ボタンやリンク）等を定義します。
図７はレイアウト設定画面です。画面の項目は、右に表示されている入出力パレットより項目を選択しドラッグ＆ドロップで簡単に配置が可能です。図上部の社員ID～添付ファイルのような詳細表示と図下部のような一覧表示が行えます。一覧表示には通常の一覧に加え、Excelのような形式・操作性で一覧データを表示する「データグリッド」が設定可能です。
図８は、入出力の全体設定を行う画面です。上から３番目の「入出力タイプ」を変更することで、図７のようなWeb画面（IO）の定義からメニュー（MENU）、ダイアログ機能（DIALOG）、データ取込（EXPORT）・出力（IMPORT）、モバイル（MOBILE）画面等を切り替えて定義を行います。
OutSystems との比較
OutSystemsはデータモデルをきちんと作ることでデータの３階層（親子孫）以上のデータを扱うことが可能となります。
対してWeb Perfomerは、データの３階層以上の表示は得意ではありません。２階層（親子）関係にあるデータであれば、子データを同一の入出力内に表示することが可能です。
３階層以上を表示する場合、
- 孫データはダイアログ機能で表示する
- スクラッチ（Java）でデータ取得部分をコーディングする
- 擬似的な親データモデルを作成し、３階層以上のデータを横並びに子データとして扱う
などの対応が必要となります。
また、OutSystemsは画面がグリッド形式でレスポンシブ対応をしていますが、Web Performerはピクセル単位での指定となります。Web Performerもモバイル用の画面を作成することも可能であり、jQuery Mobileのモバイル部品を使用しモバイルに最適化されたアプリケーションを構成します。しかし、PC用の画面ほど自由に設定をすることはできません。
３．ロジックの設計
Web Performerにおけるロジックはビジネスプロセスとして定義します。
データモデルで定義したテーブル操作などをどのような順序で実行するか定義します。定義方法は、Web Performerで準備されている制御コード（例：FOREACH｜繰り返し処理、IF｜分岐処理）によって必要な処理を行単位で定義していきます。
ビジネスプロセスでは、他にも
- データモデルで定義したテーブル操作呼び出し（CALL）
- 他のビジネスプロセス呼び出し（EXEC）
- Javaで作成した処理呼び出し（INVOKE）
- ストアドプロシージャ呼び出し（PROCEDURE）
- Webサービス呼び出し（WSEXEC）
などが行えます。
また、ビジネスプロセス自体に「独立コミット」設定を行い、別トランザクションで実行し独立してコミットできます。ビジネスプロセスから独立コミットが設定されたビジネスプロセスを呼び出した場合、そのビジネスプロセスの処理が終了した時点でコミットが行われます。使用例として、採番処理が該当するかと思います。
ビジネスプロセスは、基本的に行単位で定義しますが、Web Performerで準備されているビジネスプロセス部品をビジネスロジックのテンプレートとしてドラッグ＆ドロップすることでも定義できます。例えば、FOREACHの繰り返し処理内部で行うIFの分岐（図９の５～１２行目）等は、テンプレート利用することで１から定義せずに済みます。また、ビジネスプロセスの断片を部品化しテンプレートとして保管・使用することも可能です。
モバイル用に作成した画面もPC用に作成したビジネスプロセスを共通利用することができるので、モバイル用に別途ビジネスプロセスを用意する必要はありません。
OutSystems との比較
ロジックの定義ではOutSystemsとは異なり行単位で設定をします。フローチャート形式で定義するOutSystemsとは視覚的に大きな差がありますが、どちらも複雑なロジックを作成することができます。
４．デプロイ
Web Performerには自動でデプロイを行う機能は有していません。ビルドツールである「Ant」を利用したアプリケーションの生成までが基本的な対象範囲となります。生成されるアプリケーションはピュアなJavaアプリケーションなので、今まで通りのデプロイを行う必要があります。但し、AWS Elastic Beanstalk環境に対しては直接ツールから実施することができ、デプロイしたアプリケーションの状態等もツールを通して確認することができます。また、サーバ実行用コマンドラインが提供されているため、既存のDevOps環境が存在する場合、アプリケーション生成・デプロイ等もサーバにおいてコマンド処理が可能です。
OutSystems との比較
OutSystemsは開発ツール上から簡単にアプリのデプロイを行える機能が搭載されている点が大きな差となっています。Web Performerは自動デプロイの条件に合致しない場合、従来通りのデプロイを行います。自動デプロイを実現するには他ツールと組み合わせることが必要です。
終わりに
OutSystemsとWeb Performerをざっくり比較してきましたが、最後に改めてOutSystemsとWeb Performerの比較結果を表にまとめます。
| 工程 | 共通点 | Web Performerに特有な機能、またはOutSystemsとの相違点 |
|---|---|---|
| データモデリング |
・文字列型、数値型、論理型等の基本的なデータ型を備えている |
・テーブル作成・削除・変更を行う際に、DDLを意識する必要がある |
| UI設計 | ・Widgetを組み合わせてUIを視覚的に設計する ・予め基礎的なWidgetが配置されたテンプレートを用いて画面の作成を行うことができる |
・データの３階層（親子孫）以上の表示は得意ではない |
| ロジック設計 | ・複雑なロジックを行うことができる | ・プログラムの処理を行単位で定義する |
| デプロイ |
・なし |
・デプロイを自動で行う場合、AWS Elastic Beanstalkの利用、又は、サーバ実行用コマンドラインを利用する必要がある |
筆者の主観では、プラットフォームとして提供しているOutSystemsに対し、Web Performerはあくまで開発を高速化するツールであると感じました。
システムを一新する場合には、OutSystemsを選択することによって開発から保守までを一本で統一することが可能となります。対してWeb Performerは開発を高速化することに重きを置いているため、稼働環境やデータベースの選定は従来通り行う必要があります。そのため、Web Performerは、開発単体のローコード化をして既存の環境と合わせて使いたい場合に適しているかと思います。例えば、社外向けのシステムに注力したいので、マスタデータ管理等の社内システムを時間を掛けずに作成・保守したいケースには、Web Performerは理にかなっているかもしれません。
ローコード開発ツールは提供範囲にも違いがあります。取り入れる場合は、どこまでをローコード化したいのか明確にし、どの製品が良いか熟慮することをおすすめします。もしどのローコード開発ツールが自社に合うか悩まれる際は、どうぞこちらからお気軽にtdiへお声がけください。
執筆者プロフィール
- tdi 次世代システム開発部
- 超高速開発ツールを使用したプロジェクトに参画しエンジニアとして開発に従事しています。個人的に、JavaScript(React)を利用した開発を進行中。
