PowerBuilder資産を有効活用したWeb API連携システム化

TOP
マイグレーション
PowerBuilder資産を有効活用したWeb API連携システム化

PowerBuilder資産を有効活用したWeb API連携システム化

2021/01/05

IT業界では2020年時点で約37万人、2030年には約79万人の技術者が不足すると予測されています。人材不足なうえ、短納期を求められるケースもあり、システム開発分野では労働時間が長時間化する傾向があるようです。(注:2016年6月10日経産省発表「IT人材の最新動向と将来推計に関する調査結果」より)

PowerBuilderでのアプリケーション開発も例外ではなく、特に技術者不足の面から、例えば「PowerBuilderの開発経験はないが稼働しているPowerBuilder資産を活かしたい」、「PowerBuilderの開発に特化していたが、技術者のアサインが難しいので別言語も検討したい」といったご相談や、その他に企業ビジネスプラットフォーム拡大から「PowerBuilderで構築された基幹システムのWeb化やモバイル化を進めたい」といった嬉しいご相談を受ける機会がここ1～2年多くなりました。

前回のWebAPI連携システムへのマイグレーションでは、PowerBuilderとSnapDevelopを用いた3層構造システムへのマイグレーションについてご紹介しましたが、実はPowerBuilder IDEを使用することなく、今あるPowerBuilder資産を流用しつつ、フロントエンドは他言語や別のIDEで開発できる機能がPowerBuilder 2019から実装されます。

PowerBuilderの資産を活用してWeb APIを開発するためには、もちろんPowerBuilder CloudProエディションが必要となります。その中でフロントエンド開発でPowerBuilder IDEを必要としない場合、RapidSharp Bundleというサブスクリプションがありますのでこれを使います。RapidSharp Bundleは、以下の構成になります。

SnapDevelop
- REST APIを迅速に開発できるC#統合開発環境
.NET DataStore
- 非ビジュアルDataWindow機能をサポートするC#機能セット
DataWindow Converter
- PowerBuilderのDataWindowオブジェクトからC#データオブジェクトとモデルを生成するコンバーター
PowerScript Migrator
- PowerBuilderのビジネスロジックを素早くC#へコード変換するツール

このようにRapidSharp BundleはPowerBuilderマイグレーションツールが含まれた製品で、PowerBuilder資産をC#へマイグレーションしWeb APIとして活用することが可能です。

そこで今回は、バックエンドはRapidSharp Bundleで提供する製品でPowerBuilder資産のビジネスロジックやデータアクセス処理をWeb API化し、フロントエンドはVisual StudioやEclipse、Xcode、Android Studioで開発する構成をご紹介します。

システム構成の概要

下の図はRapidSharp Bundleの製品を使った場合、アプリケーションとWeb APIをどのように組み合わせてシステムを実現するか？を表わしたものです。

サーバー環境に関しては前回のWebAPI連携システムへのマイグレーションで解説した内容と同じです。アプリケーションに備わる機能をRapidSharp Bundleに含まれる製品ですべてWeb API化する必要はありません。PowerBuilderアプリケーションソースコードのビジネスロジック、データアクセスが分離されていれば比較的容易にWeb APIを開発することができます。つまり費用や期間、ソース解析などのコストやリスクを抑えてAPIサーバーへ配布できるメリットが前回と同じく実現できるのです。

なおWebAPI連携システムへのマイグレーションとの大きな違いは、アプリケーションのフロントエンドを実行環境やアプリケーション形態にあった言語で新規構築することです。例えばWindowsのネイティブアプリケーションであればC++やC#(もちろん、PowerBuilderでもOK！)、WebアプリケーションであればJavaやPHP、モバイルアプリケーションであればObjective CやJavaなどです。

メリットやデメリット

今回ご紹介する方法は、バックエンドはRapidSharp BundleでPowerBuilder資産を有効活用してWeb API化し、フロントエンドを自社やパートナー含め技術者が扱える開発言語で対応する方法です。既存の技術者が作業に注力しながら分担してアプリケーション構築を進められ、高品質なWebアプリケーションが開発できます。

またこのシステム構成に変更することで必然的にソースコードが簡略化され、メンテナンス性が向上し、テストもバックエンド/フロントエンドと範囲を絞ることもできるので、技術者にとって大きなメリットがあります。一方でフロントエンドの新規開発やWeb API化の検討や分離など、作業として考慮する工数は必要となります。

メリット/デメリットに関しては以下の通りです。

メリット

PowerScriptをC#へ比較的容易に変換/移行できる(開発作業の軽減)
OSやデバイスを限定しないアプリケーションが開発できる(業務支援力アップ)
C#化すれば以降のバックエンドソースメンテナンスは他のC# IDEで行える(社内外リソースの活用)
任意のWeb APIのロジックを修正するだけで、全てのアプリケーションに反映できる(運用コストの削減)
Web API化したビジネスロジックを他のアプリケーションでも利用できる(ロジックの再利用)
ネットワーク上のプロトコルをHTTP/HTTPSだけに制限できる(セキュリティ向上)

デメリット

フロントエンドを新規に開発する必要がある
現在のアプリケーションからWeb API化する処理を検討/分離する作業工数が必要になる
現在のアプリケーションのWeb API化した処理の実行をWeb APIコールに変更する必要がある

マイグレーションの準備

マイグレーションを行うにあたり以下4つの準備が必要です。前回のWebAPI連携システムへのマイグレーションと重複する部分もありますが、次の各項目についてご説明します。

Web API用サーバーの購入
SQL/ビジネスロジックの分離検討
RapidSharpサブスクリプション購入
UI開発を行う言語の技術者確保/育成

Web API用サーバーの購入

Web APIサーバーはオンプレミスでも良いですがクラウドサーバーを利用すれば、OSやセキュリティアップデート、ハードウェアの交換といったサーバーメンテナンスはクラウドサーバー事業者が行ってくれるため、インフラ側の管理/運用の負担を軽減することができます。また、必要なときに必要な分だけCPUやメモリ、ディスク容量などのスケールアップ/ダウンも比較的容易にできるので、対象アプリケーションが増えることによるトラフィック増加などの事象が発生してもサーバーを再構築する必要はありません。なおクラウド事業者によっては複数の国、地域にデータセンター(リージョン)があり、フェイルオーバーで別の仮想ホストで自動復旧させるといったサーバー障害による影響を最小限に抑えることも可能なので、自社のセキュリティポリシーと併せてご検討ください。

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

現在ご利用されているバージョンのPowerBuilderでソースコードを解析し、必要に応じてSQLやビジネスロジックの分離を行います。DataWindow・動的SQLを含めたデータベースアクセス処理のリスト化、ビジネスロジックは共通処理として汎用的に利用できる部分を分離し、Web API化することをご検討ください。 Web APIサーバーのスペックや処理内容などレスポンスも考慮する必要があります。

RapidSharpサブスクリプション購入

今回ご紹介した構成ではRapidSharp Bundleサブスクリプションを購入する必要があります。ただし、PowerBuilder 7以前で作成されたDataWindowやビジネスロジックはC#自動変換ができないため、一旦PowerBuilder 8以降へマイグレーションする必要があります。PowerBuilder 8以降へのマイグレーションなどPowerBuilder IDEを利用する場合はRapidSharp Bundleのすべての機能に加え、PowerBuilder IDEも含まれるPowerBuilder Bundle CloudProエディションがございますのでこちらの購入をご検討ください。

UI開発を行う言語の技術者確保/育成

フロントエンドの開発に必要な開発言語を扱える技術者が必要になります。技術者の保有スキルや稼働状況から自社の技術者を一定期間以上確保する・育成するといった中長期的なプランも必要です。また開発ボリュームや目的に応じて社外からの技術者派遣調整が必要となります。特に、画面やレイアウトのデザイン・画面遷移に関してはUI/UXに強いベンダーへアウトソーシングし、そのノウハウを吸収しながら処理の実装は可能な限り内製で行うなど新しい経験値を増やす良い機会となります。こうした現実的なリソース状況やUI開発工程を考慮した上で将来の成長を見据えた開発体制を是非ご検討ください。

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

マイグレーションの手順として以下の5つのプロセスが考えられます。

STEP 1

マイクロソフトが提供しているオープンソースのフレームワーク「.NET Core」をサポートしている環境でAPIサーバーを構築します。

「.NET Core」はクロスプラットフォームに対応されておりWindows、MacOS、LinuxもサポートされているのでWeb APIが動作するサーバーはOSに縛られることなく稼働させることが可能です。

STEP 2

WebAPI連携システムへのマイグレーションのSTEP 2で解説した手順と同じです。

STEP 3

Web API化するロジックが決まったら、SnapDevelopを利用してDataWindowやPowerScriptをWeb APIに自動変換します。変換率は現時点で75%以上となっていますが若干の修正が発生することもあります。

変換後、Web APIのテストもSnapDevelopの標準機能で行えます。テスト対象となるWeb APIのURLが自動生成でき、かつデータテーブルカラム属性が表示されるのでテストデータ形式が直感的に分かります。

開発環境でのテストはSnapDevelop IDE上で行い実行環境はIISサーバーなどへ配布が必要となりますが、SnapDevelopで提供されている機能でDockerイメージを構築することも可能です。構築されたDockerイメージは任意のDockerサーバー環境に配布するだけなので簡単に実行環境が構築できます。

STEP 4

フロントエンドとなるアプリケーションを新規構築します。データベースアクセスやビジネスロジックが整理されWeb API化されていれば、基本的にはWeb APIコール処理と結果取得処理、必要となる入出力項目、表示/出力形式などの処理実装やデザインにともなった画面を作成します。

STEP 5

最後に総合的なアプリの動作確認をします。 Web API化したデータベースアクセスやビジネスロジックはAPIサーバーへのリクエストにより実行されるので、サーバー負荷やネットワークトラフィックなど、システム全体のパフォーマンスに注意してください。

パフォーマンスが悪い場合は、ボトルネックになっている箇所を特定して回線速度の改善やSQLチューニングまで幅広い視野で適切な対応を検討することをお勧めします。

まとめ

近年、国をあげての「働き方改革」そして今年は全世界的に影響を与えている「新型コロナ」といった外的要因から「色々な端末でどこにいてもスムーズに業務を遂行したい」という渇望は、日増しに高まって来ています。大きな環境変化に自社システム改修の内容も優先順位も投資額も大きく変わり、求められる納期も切羽詰ったものも出てきたと考えます。もちろん、その中でPowerBuilderやPowerServerも重要な解決策の一つでありますが、C#やJava、モバイルアプリなど社内の技術者をもっと活用したいというニーズは、厳然としてあります。つまりは今あるソフトウエア資産と今、活躍できるエンジニア達といった現状のリソースを有効に活用して企業ビジネスの変革スピードに伴ったシステム構築の効率化が喫緊の経営課題だと考えます。

PowerBuilderは、約30年の歴史あるIDEです。このIDEをプラットホームとして、さまざまなアプリケーション・パッケージが開発され、いまなお販売・稼働しているお客様がたくさんおられます。それだけに、業界・業務に非常に適したビジネスロジックを組み込んできたノウハウ蓄積の歴史と資産があります。環境の変化にも「自社ビジネスの競争優位性を維持するビジネスロジック」の価値を残しつつ、他言語を活用し実現するハイブリッド化を当たり前のように実施していかねばなりません。

フロントエンドの新規開発は必要にはなりますが、PowerBuilder資産を有効活用して利用用途が広がるRapidSharpを使ったマイグレーションも一つの現実的な解決策検討候補として認識しておく必要があるのではないでしょうか。

<< 前のページへ

マイグレーショントップ