WebAPI連携システムへのマイグレーション

Web システムへのマイグレーションでは、PowerServer を使用した Web システムのメリットについていろいろとご紹介しました。 PowerServer を使用することで、PowerBuilder のスキルを利用して Web システム化が可能なため、これまで海外を含め数多くの PowerBuilder ユーザーの導入実績がある製品となっています。しかしながら PowerSever を利用した Web システムの場合、前述したとおり PowerBuilder のスキルが必須条件となるため PowerBuilder 技術者をアサインするのが困難でなかなか導入まで至らなかったというケースもありました。

今回は、Appeon 社より新たに提供された新しい C# の IDE 、SnapDevelop を利用して DB アクセス部分を分離し 3 階層化する WebAPI 連携システムについてご紹介いたします。この新しい C# IDE を利用することで、PowerBuilder の DataWindow やバックエンドのビジネスロジック部分の一部を C# 化することが可能になり、 C# 技術者のリソースを利用して PowerBuilder を利用した 3 層構造のシステムを構築できるようになります。

はじめに PowerBuilder と SnapDevelop を利用した 3 層構造のシステムについて説明します。

従来の PowerBuilder アプリケーションは、アプリケーション (クライアント) が直接データベース (サーバー) に接続する２層構造 (クライアントサーバーシステム) で構成されていました。この構成はシンプルですが、アプリケーションのレスポンスがクライアント PC の性能に左右されることや、小さな修正でもアプリケーションを再配布しなければいけないなど、性能や運用上の課題が多いです。

今回ご紹介する構成は、このアプリケーションとデータベースの間に中継サーバー (API サーバー) を追加し、ここにアプリケーション内のデータベースアクセス処理やビジネスロジックを Web API として配置する 3 層構造のシステムです。

PowerBuilder アプリケーションも SnapDevelop を利用すれば、データベースアクセス処理やビジネスロジックをソースコードから分離して簡単に Web API を作成することができます。

アプリケーションは分離した部分を PowerBuilder で Web API コールに変更するだけです。

ユーザーインターフェイスはそのままですが、PowerBuilder 2019 から登場した UI テーマ機能を使えば、設定するだけでモダンな外観に変更させることができます。

PowerBuilder と SnapDevelop を使えば、既存のアプリケーションを簡単に 3 層構造のシステムにできるので、新規に開発するよりコストや開発期間を節約することができます。

システム構成の概要

下の図は、今回ご紹介するシステム構成がアプリケーションと WebAPI をどのように組み合わせて実現しているのかを示しています。

図で分かるように、開発環境ではユーザーインターフェイス部分、ビジネスロジック、データアクセスなどに分離して、バックエンドの処理を WebAPI 化しています。 UI の部分は今まで同様に PowerBuilder のソースコードをそのまま利用します。

ユーザーインターフェイスは、今まで通り PowerBuilder アプリケーションとしてコンパイルし、各クライアント端末へ配布する必要があります。バックエンドの部分は Appeon 社の新しい C# IDE SnapDevelop を使用して WebAPI へマイグレーションし、API サーバーへ配布します。

API サーバー環境を構築する必要がありますが、データベース接続を API サーバーで一元管理することにより、各クライアント端末へインストールするデータベースクライアントなどのソフトが減りますので、プログラム配布作業またはクライアント側の管理作業がかなり軽減されます。また、各クライアント端末へアプリケーションの配布は引き続き必要ですが、画面、帳票またはそれらを制御するロジックのみとなりますので、最小構成で配布できるようになります。

さらにクライアント側の構成をシンプルにすることで、障害が発生したときに調査する範囲および内容も減り、運用管理の負担も軽減されます。

セキュリティの面でも、今まではデータベースサーバーへアプリケーションが配布された多数のクライアントから直接アクセスする必要がありましたが、この構成であれば API サーバーだけに限定できるため、データベースを隠ぺい化でき、不正アクセスやデータ漏洩などを防ぐ対策にもなるのです。

メリットやデメリット

今回ご紹介の方法では、WebAPI へのマイグレーションを各種のプラグインのツールを活用して簡単に生成可能です。ただし、WebAPI を呼び出すように修正する作業は PowerBuilder アプリケーション側に発生するため、手作業で修正する必要があります。大規模なシステムをマイグレーションする場合は、この作業工数が相応に膨らみます。また、変更が全面的に実施されるため、事前に十分な検証が必要となります。

既存ソースコードを利用して Web API 化するメリットとデメリットについて、以下にまとめました。

メリット

• ユーザーインターフェースは変わらない (ユーザーの再教育不要)
• PowerScript を C# へ簡単に変換できる (開発作業の軽減)
• クライアント端末へのデータベースクライアント設定が不要になる (運用コストの削減)
• Web API のロジックを修正すれば全てのアプリケーションへ反映できる (運用コストの削減)
• Web API 化したビジネスロジックを他のアプリケーションでも利用できる (ロジックの再利用)
• データベースへのアクセスを Web API サーバーからだけに制限できる (セキュリティ向上)
• ネットワーク上のプロトコルを HTTP / HTTPS だけに制限できる (セキュリティ向上)

デメリット

• 現在のアプリケーションから Web API 化する処理を検討/分離する作業が必要になる
• 現在のアプリケーションの Web API 化した処理の実行を Web API コールに変更する必要がある

マイグレーションの準備

まず準備として以下の３つの作業が必要となります。

• API 用サーバーの購入
• SQL / ビジネスロジックの分離検討
• PowerBuilder エディションのアップグレード

WebAPI 用サーバーの購入

新規に購入する WebAPI サーバのスペックですが、システムの規模、利用するクライアントの台数またはシステムの利用頻度に左右されます。現行の DB サーバーの台数を加味して、同じ台数を用意するか、負荷を分散またはサーバーダウンの障害を考慮して最低 2 台の構成をお勧めします。また、3 層構造にしたことで WebAPI サーバーへの負荷状況が不透明なため、実際に利用している端末の台数、および将来増設される台数も想定して、サーバーのスペックを決める必要があります。別途テストツールが必要ですが、必要に応じて負荷テストを実施してサーバーのサイジングを検討ください。

SQL / ビジネスロジックの分離検討

DataWindow 、動的 SQL を含めデータベースへのアクセス箇所をもれなく洗い出してリスト化します。ビジネスロジックについては、どの部分を分離して WebAPI 化するかは、十分に検討する必要があります。すべてのバックエンド処理をサーバーに移してしまうとサーバーの負荷やネットワークトラフィックの増加によりレスポンスが悪化する、ということもあるのでサーバーのスペックや処理内容などのバランスを考慮して検討する必要があります。

PowerBuilder エディションのアップグレード

今回ご紹介の構成では、PowerServer 以外のすべての機能を利用するため、Appeon PowerBuilder CloudPro のバンドルが必要です。

Appeon PowerBuilder CloudPro バンドルには以下のパッケージが含まれています。

Standard または Professional をご利用の場合は CloudPro へエディションをアップグレードするか、新規に購入する必要があります。ご注意ください。

詳細に関しては Appeon PowerBuilder CloudPro をご参照ください。

マイグレーションのプロセス

PowerBuilder 資産を利用して WebAPI を使用したシステムへマイグレーションするには、環境の準備、マイグレーション作業、マイグレーション後の検証など主に下記の 5 つのステップが必要です。

STEP 1

最初に API サーバーは、マイクロソフトが提供しているオープンソースのフレームワーク. NET Core をサポートしている環境をご準備下さい。. NET Core はクロスプラットフォームに対応しており、Windows 、MacOS 、Linux をサポートしているため、WebAPI を動作させるサーバー環境は Windows 以外でも稼働させることが可能です。

またサーバースペックはシステムの規模、クライアントの接続台数を考慮して検討する必要があります。

STEP 2

どの部分のロジックを WebAPI 化するか検討します。データベースへのアクセス部分はもちろんのこと、その他のロジックも WebAPI 化できるものがないかをリスト化します。さらに漏れがないよう作業の範囲を明確にします。

WebAPI はシンプルな https 通信プロトコルにより実現されていますので、リクエストをして結果を json 形式で受け取ります。単純なビジネスロジックに向きます。

以下に WebAPI 化するポイントとなるものを示します。

• DataWindow の CRUD 処理
• 埋め込み SQL
• 関数などの NVO (ノンビジュアルオブジェクト)

STEP 3

WebAPI 化する範囲の確定後、SnapDevelop を利用して DataWindow や PowerScript を WebAPI に自動変換します。変換率は、現時点では 75 %以上となっています。

変換後、WebAPI のテストも SnapDevelop の標準機能で実施可能です。テストする URL の自動生成が可能で、しかもビジュアルにデータテーブルカラムの属性を表示してくれるので、どんなデータを入力すればいいのか一目で分かります。

開発環境でのテストは SnapDevelop IDE 上で実行してテストできます。

実行環境については IIS サーバーなどへ配布しますが、SnapDevelop で提供されている機能で Docker イメージを構築可能です。構築された Docker イメージは任意の Docker サーバー環境に配布するだけで実行環境が構築できます。

STEP 4

WebAPI の自動生成およびテストが完了しましたら、このステップでは PowerBuilder からマイグレーションしたデータベースへのアクセス処理またはビジネスロジックを WebAPI で呼び出す処理に修正します。アプリケーション起動時の初期化処理でデータベースへの接続処理が不要となり、DataWindow 、埋め込み SQL によるデータ操作、およびビジネスロジックなどを WebAPI で呼び出すものに修正します。

STEP 5

最後のステップは総合的に、検証を行うものとなります。従来の PowerBuilder アプリケーションでは直接データベースにアクセスしていましたが、今回は API サーバーを経由したアクセスになるため、パフォーマンスが低下する可能性があります。システム全体を通じてサーバー負荷やネットワークのトラフィック状況によりチューニングの必要性も考慮し、これを機会に改めてソースコードのリファクタリングを実施することをお勧めします。

まとめ

以上、PowerBuilder と新しい SnapDevelop を利用した 3 層構造のシステムについて、ご紹介しました。３層構造という新しい構成になりますが、PowerBuilder の資産を活かしながらバックエンドを C# 化できること、またフロントの UI については使い慣れた画面をそのまま利用できるため今までと同じ画面と操作性を担保できる大きなメリットがあります。

また、この構成ではプレゼンテーション層とアプリケーション層を分離したことで、将来システム全体を Web へマイグレーションする際に PowerBuilder で開発されている UI の部分を Web システムへマイグレーションするだけで済みます。開発コストを軽減しつつ社内の開発メンバーだけで段階的にチャレンジしてみてはいかがでしょうか？

---