マイグレーション作業の注意点
「備えあれば憂いなし」
何事にも準備を怠らねば、不安がなくなる?であれば良いですが、マイグレーション作業も無事に完了できたとしても振り返れば、反省する問題はいくつもあるのでは?
ここでは、あらかじめ知っていれば対処する工数をずいぶん減らせるような知識や方法など、ちょっとした注意点をいくつかご紹介します。
非互換調査方法のヒント
PowerBuilderに限らず非互換調査を行う場合、対象となるイベント名/関数名などを正規表現検索やgrep検索で抽出する作業が必要となります。
もちろん、PowerBuilder IDEでも十分に調査可能ですが、効率を重視するのであれば使い慣れた(普段お使いの)テキストエディタの検索機能を利用すると非互換部分を抜け漏れなく正確に抽出できます。PowerBuilderで開発されたアプリケーションのソースファイル(pbl)はバイナリファイルなので、ソースファイルをエクスポートしてテキストファイルとして出力することで、あいまい検索やgrep検索ができます。
手作業で対応する非互換
非互換の修正ボリュームは現行アプリケーションを作成したPowerBuilderバージョンによって異なりますが、オートマイグレーション機能では対応できない手作業で修正する代表的な非互換について説明します。
非互換情報① : 文字列操作関数の見直し
※SAP PowerBuilder 12.6以前のバージョンからAppeon PowerBuilderへマイグレーションする場合
PowerBuilder 2017以降では、以下の付表の関数を使用してマルチバイト文字を扱う場合、マイグレーション作業の前と後では一部動作が変更されてしまい、実行結果に差異が発生します。そのため、次の修正方法を選択する必要があります。
- 文字をバイト数で扱わないよう修正する
- マイグレーション前と同等の処理を行う関数を作成し、手作業で関数を置き換える
文字列操作関数 | PowerBuilder 12.6まで | PowerBuilder 2017以降 |
---|---|---|
MidA(“Aいa”, 3, 2) | い | 「a |
RightA(“Aいa”, 2) | a | 「a |
FillA(“Aいa”, 6) | AいaA | 空文字(“”) |
PosA(“東京”, “結”) | 0 | 2 |
非互換情報② : Unicodeへの変更
※Sybase PowerBuilder 9以前のバージョンからAppeon PowerBuilderへマイグレーションする場合
PowerBuilder 10からは使用する文字コードがSJISからUnicodeへ変更されています。
これまでは入力可能な文字の長さや文字列の切り出しなど、文字列を操作する関数はバイト数で扱われていましたが、PowerBuilder 10以降では文字数で扱われるようになりました。 また、コントロールの最大入力値プロパティも同じくバイト数から文字数になっています。
例えば最大入力値が「10」で指定されている場合、全角10文字を入力すると20バイトとなり、CHAR(10)で定義されたカラムに値を保存するとDB更新エラーが発生します。
そのため、データ入力時やデータ更新時に入力された文字のバイト数が最大入力値を超えていないかチェックを行う必要があります。加えてLen,Mid,Posなどの文字列を操作する関数の戻り値/引数共にバイト数扱いでしたが、Unicodeへの変更により文字数に変更されましたので、マイグレーション前と同等の動作となるか必ず確認してください。
非互換情報③ : コントロールサイズの調整
※Windows 7 以前からWindows 8 以降へマイグレーションする場合
PowerBuilderで開発されたアプリケーションは動作するWindows OSに依存します。
そのため、マイグレーション作業の前と後で動作させるWindows OSを変更すると
- スタティックテキスト
- シングルラインエディット
- DataWindow内のカラム(エディットマスク)など
上記の文字表示/入力系のコントロールサイズがわずかに変わることがあり、表示文字の欠損や指定した最大文字数が入力できなくなる可能性があります。
また、DataWindowの表示領域に表示される行数そのものの数が変わることがあります。そのため、マイグレーション作業の前と後でWindows OSのバージョンを変更する場合は画面レイアウトチェックや入力チェックを行い、動作差異があった場合はコントロールサイズの修正を必ず実施してください。
非互換情報④ : FileRead,FileWrite関数の動作変更
※SAP PowerBuilder 12.5以前のバージョンからAppeon PowerBuilderへマイグレーションする場合
FileRead関数を使ってファイル内のデータを読み込んだ時に、読み込むデータ内にマルチバイト文字が含まれていると、文字化けや最後までデータが読み込めないなど、正しくデータが読み込まれません。また、FileRead/FileWrite関数に関しては下位互換のために残されている関数なので、こうした不具合が残っていても今後修正されることは一切ありません。そのため、新たに用意されたFileReadEx/FileWriteEx関数へ置き換えを行います。また、戻り値の変数がInteger型からLong型へ変更されるため、この部分もあわせて修正してください。
非互換情報⑤ : 廃止された関数
※SAP PowerBuilder 12.6以前のバージョンからAppeon PowerBuilderへマイグレーションする場合
以下の文字列を操作するための関数はAppeon PowerBuilderにて廃止されました。そのため、A付きの関数に変更する必要があります。
- FillC → FillA
- LeftC → LeftA
- MidC → MidA
- RightC → RightA
非互換情報に関してはPowerBuilderで開発されたアプリケーションの作成バージョンや仕様/機能によって異なります。上記以外にもSAP PowerBuilder、InfoMaker 12.6(日本語版)からの変更点をまとめた資料やPowerBuilder、InfoMakerの動作差異をまとめた資料を参考に調査/修正を行い、対応してください。
また非互換以外の注意点として、既知の不具合の影響からアプリケーションの作りによってマイグレーション前後で動作に差異が発生する可能性もあります。既知の不具合についてはバグ情報で随時情報を更新しているので、発生バージョンや発生条件、回避策もあわせてご確認ください。
効率的な現新比較テスト
現新比較テストでは以下の環境をぞれぞれ用意することをご検討ください。
- ステージング環境
- Windows OSのバージョンやDBのバージョンなど、マイグレーション作業前の現行アプリケーションが稼働している本番に近しい疑似環境
- テスト環境
- Windows OSのバージョンやDBのバージョンなど、マイグレーション作業後のアプリケーションが稼働する予定の近しい疑似環境
また、データに関しては本番環境のDBとステージング環境/テスト環境のDBを同期させるか、もしくは本番環境のデータをステージング環境/テスト環境にインポートするなど、可能な限りデータの状態を本番環境に合わせることがベストです。そうすることでテストデータでは検知できない本番運用後に発生し得る問題を未然に防ぎ、安定稼働の実現に近づけます。なお、テストが進んでいくとデータ状態に差異が生まれてくることもありますので、ステージング環境/テスト環境のデータを合わせるためのデータロードスクリプトを作成しておくとテストを円滑に行えます。
上記の環境を用意するにはユーザーのご協力やリソース、労力が少なからず必要となりますが、それを補ってあまりある恩恵は計り知れませんのでぜひご検討ください。
現新比較テスト時の不具合
「テスト段階になって初めて想定外の事象が発生」することはシステム構築の宿命で、マイグレーション作業においても同様です。前述した環境(ステージング環境/テスト環境)の構築方法は、こうした問題や不具合が発生することを想定した検証方法です。
現新比較テスト時に問題や不具合が発生した場合、ステージング環境の現行アプリケーションとテスト環境のマイグレーション作業後のアプリケーションの動作を比較することで、現行アプリケーションのコーディングミスに起因した不具合が顕在化した問題なのかマイグレーション作業時のミスによる問題なのかいち早く切り分けられ、調査時間の短縮が見込めます。
問題発生時のオペレーションを現行アプリケーションとマイグレーション作業後のアプリケーションに対して行い、同事象が確認できれば既存アプリケーション不具合の可能性が考えられます。また、マイグレーション作業後のアプリケーションのみで事象が確認できた場合は、マイグレーション作業時のミスによる問題も考慮して対応する必要があります。
この方法の最大のメリットは、以下の2つであり、アプリケーションの品質を向上させることが可能です。
- 発生した事象が既存の問題の場合
マイグレーション作業を止めることなく、平行して修正タイミングや修正方法を検討することができる
- 発生した事象が新規の問題の場合
該当箇所を突き止め横展開することで、同種の問題や不具合に対応することができる
新規の開発ボリュームを抑えつつ短期間に移行することができ、既存資産を最大限に活用することにより、現行アプリケーション内で実装されている既存のビジネスロジックを踏襲できるため、仕様の再現精度も現行アプリケーションと同等に保つことが可能なマイグレーションをぜひご検討ください。