標準的なマイグレーション手順

マイグレーション手順

IDE製品であるPowerBuilderは、マイグレーション作業をする上でオートマイグレーション機能を必ず使用します。

現行アプリケーションのPowerBuilderのソースファイル(ファイルシステム上のファイル単位。以下、本ページ内ではpblファイルと省略)を、新しいAppeon PowerBuilder IDEで読み込むと、オートマイグレーション機能が実行され新しいAppeon PowerBuilder IDE上でオブジェクトの編集が行えるよう新バージョンのpblファイルへと再生成を行います。

しかし…

  • PowerBuilder 10以降
    • 文字列操作関数名が変更(例:Len⇒LenA)されたが、DataWindow内に存在する文字列操作関数名は自動的に修正されずに同じ関数名のまま
  • PowerBuilder 2017以降
    • MidA関数などマルチバイト文字を扱う機能の仕様変更

はそのままで再生成されるため、新バージョンのアプリケーションでは動作が変わってしまいます。このような仕様や名称が変更された関数や機能(非互換)があり、すべてを自動で行えるわけではありません。このため以下の手順でマイグレーション作業を行います。

  • 非互換箇所を事前に抽出する
  • オートマイグレーション機能で新バージョンのpblファイルへ再生成を行う
  • 新しいAppeon PowerBuilder IDEを利用して非互換修正を行う
  • 現行バージョンのアプリケーションと新バージョンのアプリケーションで同じ動作になることを確認(比較テスト)する

現行バージョンのアプリケーションの動作を再現することで、新バージョンのアプリケーションを現行バージョンのアプリケーションと同じように利用できるようにします。

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

図:PowerBuilderアプリケーションのマイグレーションの流れ


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

以下にPowerBuilderアプリケーションの標準的なマイグレーションプロセスと内容を紹介します。

 

STEP1 – 非互換修正箇所を抽出

廃止/仕様変更となった関数や機能(非互換)の確認

バージョンが上がり、廃止(例:PrintHeaderイベント)や仕様が変更(例:MidA関数)されたイベント/関数がいくつかあります。また、名称が変更された関数(例:Len⇒LenA)や機能もあります。これらの「非互換」をそのままにした場合、現行バージョンのアプリケーションと新バージョンのアプリケーションの動作が変わってしまいますので、マニュアルを基にどのような関数や機能が廃止、変更されているかを確認します。

修正箇所の抽出

上記で確認した廃止/仕様が変更された関数や機能が、現行pblファイル内のどの箇所にあるかを探します。pblファイルをエクスポートしたうえでテキストエディタを使用して検索したり、PowerBuilder IDEの機能を利用して関数名などを検索し、使用されている個数や使用箇所を押さえておきます。

非互換の一覧(調査結果)を作成

抽出した修正箇所がどのpblファイルのどのオブジェクトにあるのか、さらにどのイベントや関数に記述されているのかを整理して、わかりやすく一覧にします。


 

STEP2 – オートマイグレーション

現行バージョンのpblファイルをバックアップ

オートマイグレーション中にpblファイルが破損するケースや、非互換修正中に手順違いがあり改めて現行バージョンのpblファイルからマイグレーションを再実施するケースもあるため、必ず現行バージョンのpblファイルをバックアップします。

現行バージョンのpblファイルを新しいAppeon PowerBuilder IDEで開く

新しいAppeon PowerBuilder IDEで現行バージョンのアプリケーションオブジェクトを開くと「オートマイグレーション」機能が実行され、新しいAppeon PowerBuilder IDE上でオブジェクトの編集が可能になるようオブジェクトが自動で再生成されます。再生成が行われる際に廃止された関数(例:MidCなどのxxxC関数)などがエラーや警告として出力されるためファイルに保存します。

オートマイグレーションの方法は、Sybase PowerBuilder 7以前のバージョンとSybase PowerBuilder 8以降のバージョンで作業方法が異なります。詳細については、マイグレーション手順書の27ページに記載がありますのでご確認ください。


 

STEP3 – 非互換箇所やエラーの修正

新バージョン用のDBとテーブルを作成

新しいAppeon PowerBuilder IDEで新バージョンのpblファイル内のDataWindowなどのオブジェクトを修正して保存するとDBに接続してテーブルチェックが行われます。このチェックで警告が表示されないように、事前に新バージョン用のDBとテーブルを作成します。

非互換箇所の修正

新バージョンのpblファイルに対してSTEP1で抽出した非互換修正箇所を手作業で修正します。修正する際に修正箇所の再確認が必要となるケースを想定して非互換修正箇所の一覧表を作成しておくことで問題点を洗い出しやすくします。修正箇所一覧では、具体的なオブジェクト内の行番号なども記述します。

警告やエラーの修正

新バージョンのpblファイルに対してSTEP2で発生したLeftW関数など関数名がxxxWの廃止予定による警告やMidC関数など関数名がxxxCの廃止されるエラー手作業で修正します。ここでも非互換修正箇所の一覧表に修正箇所を記載します。

ソースコードの比較

現行バージョンと新バージョンのpblファイルをエクスポートしたソースコードに対して、差分比較ツールを使用して現新バージョンのソースコードを読み込み修正箇所に誤りが無いかソースコードの比較を行います。


 

STEP4 – テスト準備

テスト環境を準備

現行バージョンと新バージョンのアプリケーションを使用して動作確認を行うため、現行バージョンのアプリケーションが動作している環境(クライアントPCのOSやDBなど)と、新バージョンのアプリケーションを動作させる予定の環境(クライアントPCのOSやDBなど)のテスト環境を準備します。テストに使用するデータは本番データに近い内容のデータを準備することで、テストの精度を高めることができます。

テスト仕様書を作成

現行バージョンと新バージョンのアプリケーションで比較する機能(Window、帳票、バッチ処理)単位でテスト仕様書を作成します。テスト仕様書には、画面レイアウトや入力エリア文字数、DataWindow画面表示行数、更新処理(新規、編集、削除)後の再表示などをテスト項目として作成します。

Exeの作成

STEP3による非互換箇所やエラー、警告の修正が完了した新バージョンのpblファイルに対してExeを作成します。


 

STEP5 – 比較テスト

比較テスト

現行バージョンと新バージョンのアプリケーションを動作させ同じ結果が得られるか比較テストを実施します。比較テストの際には、画面エビデンス・帳票エビデンス・ファイル出力のエビデンスを取得し比較判定を実施します。

OS非互換修正

現行アプリケーションと新アプリケーションで動作環境が異なる場合に、Windows OSを変更することで最大桁数のデータを入力した場合などでOS変更による入力/表示エリアに差異が発生するケースがあるため比較テスト時に確認を行い、差異が発生している場合は修正します。

データ並び順修正

現行アプリケーションと新アプリケーションで動作環境が異なる場合に、DBのバージョンを変更することでデータの並び順に差異が発生するケースがあるため比較テスト時に確認を行い、差異が発生している場合は修正します。

動作差異や障害対応

比較テスト中に動作差異(例:レイアウト差異や未知の非互換)や障害(例:入力値条件によるアプリケーションエラー)が発生した場合は、障害管理表にどのような条件でどのような差異や障害が発生したかを記述し現行バージョンと新バージョンどちらのアプリケーションに問題があるか原因を調査します。現行バージョンのアプリケーションに問題がある場合は対処方法を検討し、新バージョンのアプリケーションに問題がある場合は全ソースコードを対象に類似の該当箇所が無いかを調査したうえで修正します。


 

以上が標準的なマイグレーションプロセスとなりますが、当サイトではマイグレーション作業中の注意点マイグレーション手順書も公開しておりますので併せてご確認ください。

マイグレなんでも相談室を期間限定で開設しましたので、当ページを含めご相談ごとがありましたらお気軽にお問い合わせください。

 

マイグレなんでも相談室の申込み

(期間限定:2020年7月20~9月30日)


PowerBuilder マイグレーション