標準的なマイグレーション手順
IDE製品であるPowerBuilderは、マイグレーション作業をする上でオートマイグレーション機能を必ず使用します。
現行アプリケーションのPowerBuilderのソースファイル（ファイルシステム上のファイル単位。以下、本ページ内ではpblファイルと省略）を新しいAppeon PowerBuilder IDEで読み込むとオートマイグレーション機能が実行され、IDE上でオブジェクトの編集が行える新バージョンのpblファイルへと再生成されます。
しかし…
- PowerBuilder 10以降
- DataWindow内に存在する文字列操作関数の変更（例：Len⇒LenA）
- PowerBuilder 2017以降
- マルチバイト文字を扱う文字列操作関数の仕様変更（例：MidA / RightA）
などは考慮せず機械的に再生成されるため、新バージョンのアプリケーションでは動作が変わってしまいます。このため、上記のような仕様や名称が変更された関数や機能（非互換）は手動で対応する必要があり、以下の手順でマイグレーション作業を行います。
- 非互換箇所を事前に抽出
- オートマイグレーション機能で新バージョンのpblファイルへ再生成を実施
- 新しいAppeon PowerBuilder IDEを利用して非互換修正
- 現行バージョンのアプリケーションと新バージョンのアプリケーションで同じ動作になることを確認（比較テスト）
現行バージョンのアプリケーションの動作を再現することで、新バージョンのアプリケーションを現行バージョンのアプリケーションと同じように利用できるようにします。
図：PowerBuilderアプリケーションのマイグレーションの流れ
マイグレーション標準プロセス
PowerBuilderアプリケーションの標準的なマイグレーションプロセスと内容を紹介します。
STEP1 – 非互換修正箇所を抽出
廃止／仕様変更となった関数や機能（非互換）の確認
バージョンが上がり、廃止（例：PrintHeaderイベント）や仕様が変更（例：MidA関数）されたイベント／関数がいくつかあります。また、名称が変更された関数（例：Len⇒LenA）や機能もあります。これらの「非互換」をそのままにした場合、現行バージョンのアプリケーションと新バージョンのアプリケーションの動作が変わってしまいますので、マニュアルを基にどのような関数や機能が廃止、変更されているかを確認します。
修正箇所の抽出
上記で確認した廃止／仕様が変更された関数や機能が、現行pblファイル内のどの箇所にあるかを探します。pblファイルをエクスポートしたうえでテキストエディタを使用して検索したり、PowerBuilder IDEの機能を利用して関数名などを検索し、使用されている個数や使用箇所を必ずメモしておきます。
非互換の一覧（調査結果）を作成
抽出した修正箇所がどのpblファイルのどのオブジェクトにあるのか、さらにどのイベントや関数に記述されているのかを整理してわかりやすく一覧にします。
STEP2 – オートマイグレーション
現行バージョンのpblファイルをバックアップ
オートマイグレーション中にpblファイルが破損するケースや、非互換修正中に手順違いが発生するケースなど、マイグレーションを初めから再実施せざるを得ない事態を考慮し、必ず現行バージョンのpblファイルをバックアップします。
現行バージョンのpblファイルを新しいAppeon PowerBuilder IDEで開く
新しいAppeon PowerBuilder IDEで現行バージョンのアプリケーションオブジェクトを開くと「オートマイグレーション」機能が実行され、IDE上で編集可能なオブジェクトが自動で再生成されます。再生成処理の終了後、廃止された関数（例：MidCなどのxxxC関数）などがエラーや警告として出力されるため、ファイルに保存します。
オートマイグレーションの方法は、Sybase PowerBuilder 7以前のバージョンとSybase PowerBuilder 8以降のバージョンで作業方法が異なります。詳細については、マイグレーション手順書の29ページに記載がありますのでご確認ください。
STEP3 – 非互換箇所やエラーの修正
新バージョン用のDBとテーブルを作成
新しいAppeon PowerBuilder IDEで新バージョンのpblファイル内のDataWindowなどのオブジェクトを修正して保存すると、DBに接続してテーブルチェックが行われます。このチェックで警告が表示されないように、事前に新バージョン用のDBとテーブルを作成します。
また、アプリケーションと併せてデータベースマイグレーションを検討する場合、このタイミングで準備をします。データベースマイグレーションについては、テクニカルブログに PowerBuilder のパイプライン機能を利用して異なるデータベース間でデータを移行する記事がありますので、こちらもご覧ください。
非互換箇所の修正
新バージョンのpblファイルに対して、STEP1で抽出した非互換修正箇所を手作業で修正します。修正する際、修正箇所の再確認が必要となるケースを想定して非互換修正箇所の一覧表を作成しておくことで、問題点を洗い出しやすくします。修正箇所一覧では具体的なオブジェクト内の行番号なども記述します。
警告やエラーの修正
新バージョンのpblファイルに対して、STEP2で発生した警告やエラーに対する修正を行います。たとえばLeftW関数のように関数名の末尾に “W” が付く関数は廃止予定であり、MidC関数のように末尾に “C” が付く関数は廃止されていますので、これらの警告やエラーを手作業で修正します。ここでも非互換修正箇所の一覧表に修正箇所を記載します。
ソースコードの比較
現行バージョンと新バージョンのpblファイルをエクスポートしたソースコードを差分比較ツールで読み込み、修正箇所に誤りが無いか確認します。
STEP4 – テスト準備
テスト環境を準備
現行バージョンと新バージョンのアプリケーションを実行して動作確認を行うため、クライアントPCのOSやDBなど、現行バージョンのアプリケーションが動作している環境と新バージョンのアプリケーションを動作させる予定の環境をテスト環境として準備します。テストに使用するデータは本番データに近い内容のデータを準備することで、テストの精度を高めることができます。
テスト仕様書を作成
現行バージョンと新バージョンのアプリケーションで、比較する機能（Window、帳票、バッチ処理）単位でテスト仕様書を作成します。テスト仕様書には、画面レイアウトや入力エリア文字数、DataWindow画面表示行数、更新処理（新規、編集、削除）後の再表示などをテスト項目として作成します。
Exeの作成
STEP3での修正が完了した新バージョンのpblファイルからExeを作成します。
STEP5 – 比較テスト
比較テスト
STEP4で作成したテスト仕様書をもとに現行バージョンと新バージョンのアプリケーションを動作させ、同じ結果が得られるか比較テストを実施します。比較テストでは、画面エビデンス・帳票エビデンス・ファイル出力のエビデンスを取得し、比較判定を実施します。
OS非互換修正
現行アプリケーションと新アプリケーションが稼働するWindows OSに変更があった場合、テスト実施に最大桁数のデータを入力すると入力／表示エリアに差異が発生するケースがあります。現行アプリケーションと新アプリケーションを実行し、ウィンドウ単位で画面を表示させた際に表示される各テキストで文字切れが発生していないか、入力エリアに文字を入力しフォーカスを移動した場合に入力された値に文字切れが発生していないか確認を行い、差異が発生している場合は都度修正を行います。
データ並び順修正
現行アプリケーションと新アプリケーションで利用しているDBのバージョンに変更があった場合、テスト実施にデータの並び順に差異が発生するケースがあります。一覧表を含むウィンドウ単位で画面を表示させデータを一覧表示させた際にデータの並び順に差異がないか、一覧表の帳票を出力した際の並び順に差異がないか確認を行い、差異が発生している場合は都度修正を行います。
動作差異や障害対応
テスト実施にアプリケーションを実行して見た目や動作の比較をしていく中で、レイアウトの差異や未知の非互換などの「動作差異」、入力値条件によるアプリケーションエラーなどの「障害」が発生した場合、障害管理表にどのような条件下でどのような差異や障害が発生したかを記述し、現行バージョンと新バージョンどちらのアプリケーションに問題があるか原因を調査します。現行バージョンのアプリケーションに問題がある場合、対処方法を検討し、新バージョンのアプリケーションに問題がある場合、全ソースコードを対象に類似の該当箇所が無いかを調査したうえで修正します。
以上が標準的なマイグレーションプロセスとなりますが、当サイトではマイグレーション作業中の注意点やマイグレーション手順書も公開しておりますので併せてご確認ください。
