これまでの軌跡

  1. トップページ
  2.  >
  3. これまでの軌跡 一覧
  4.  >
  5. これまでの軌跡

IBM i (AS/400) データ待ち行列 (DataQueue) によるVBとRPG連携

DataQueue による VB と RPG 連携(2)

前回ご覧頂いた「IBM i (AS/400) 脱5250エミュレーター」からの続きとなります。 まだご覧になっていない方は是非「IBM i (AS/400) 脱5250エミュレーター」と合わせてご覧ください。


データ待ち行列(DTAQ)

同期通信がだめであれば、非同期通信ではどうか?「 データを IBM i (AS/400) に渡す事さえできればデータベースへの登録を RPG で行う事ができる。RPGの実行はバッチで行い VB 側はデータを IBM i (AS/400) に渡すだけとすればパフォーマンスは一気に改善されるのでは?」。これが実現できれば、IBM i (AS/400) 側からの応答を待たずにPC 側で後続の処理を開始することができます。完全な問題解決とは言えませんが、体感スピードは劇的に向上するはずです。

問題はその実装方法ですが、IBM i (AS/400) にはプログラム同士がデータを受け渡すための仕組みとしてデータ待ち行列(DataQueue) というオブジェクトがあります。"Client Access"(現在の "System i Access") には、IBM i (AS/400) 上のデータ待ち行列オブジェクトを操作できる API があり、これを使用すればVBプログラムからこのオブジェクトにアクセス可能です。DataQueue にデータを渡す事ができれば、後の処理はIBM i (AS/400) 上のプログラムに任せ、PC側は並行して次の処理を開始できます。そこで、このAPIを使用してDTAQ へデータを投入するVBプログラムと、IBM i (AS/400) 側でDTAQから受け取ったデータをデータベースへ登録するRPGプログラムを作成しました。早速お客様に見ていただくと「パフォーマンスについては問題なし」との回答を頂きました。これで「データの登録」について一件落着となりました。(図2-1を参照)「データの更新および削除」についても、パフォーマンス重視の要望を最優先とし、登録機能と同様の構成としました。

ついに DataQueue(*DTAQ) 登場
インプットチェックがネックに

パフォーマンスの問題については、単にデータのエントリー時の問題だけでなく、マスター参照時の通信でも発生していました。最初の案では、マスター参照も DB2/400のデータをリアルタイムに検索していたため、PC側でコードを入力するたびにユーザーの待ち時間が発生したのです。この問題を解決するために、VBプログラムからIBM i (AS/400) へのアクセス方法の検討を再度行いました。当時の Visual Basic のバージョンは 5.0。お蔵入りした APPC CPI-C 以外には ODBC APIを直接使用するか、コーディングを簡単にしてくれる RDO を使用した ODBC 経由のデータ取得しかありません。双方を比較した場合、パフォーマンスレベルはほとんど変わらなかったため、データの取得には RDO を使用する事にしました。しかしこの方法でもPCからIBM i (AS/400) にマスター参照するたびに通信が発生してしまうことには変わりありません。APPC CPI-C のEVOKEほど時間がかかることはありませんでしたが、それでも担当者のキーボード入力のスピードには追い付かないのです。色々とコーディング等で工夫をしてみましたが結局解決には至りませんでした。

ここでまた発想の転換が必要になります。お客様の要望のひとつであるデータベースの一元管理を厳密に実現するにはリアルタイム・アクセスが必須です。しかし、マスターデータの更新頻度は今回のデータではそうあるものではないことが判明しました。「更新頻度が少ないのであれば、毎回リアルタイムで DB2/400にアクセスする必要はないのではないか?」。そこで、以下の構成および手順を採用することにしました。(図2-2を参照)

  1. MDB(Access)形式でマスターテーブルをWindowsサーバー上に作成
  2. 管理者がマスターテーブル(DB2/400)の保守を VB で行った後、Windowsサーバーの MDB(Access)とデータを同期
  3. 各クライアントはアプリケーション起動時に Windowsサーバーにある最新の MDBファイルをローカルにコピー
  4. VB からの MDB 参照は最速のDAOを使用してローカルのMDBにアクセス
マスターデータの同期

またトランザクションデータを変更/削除する際は対象となるデータを取得および照会する必要がありますが、 RDO 経由でIBM i (AS/400) と直接通信することに決定致しました。ここは常に最新のデータを参照しなければならず、若干の待ち時間があってもDB2/400データをリアルタイムに参照しなければならないのです。

こうして、全体の構成が完成しました。VBとIBM i (AS/400) との通信およびデータアクセス手段にこのような複数の仕組みで対応し、お客様の要望を実現することができたのです。手前みそですが、今回の仕組みはハイブリッドと言えるかもしれません。


トランザクションデータの登録/変更/削除についてはお客様に納得いただきました。最大の難関はクリアできたため、いよいよ全体のアーキテクチャを決定します。その中でも我々の今に繋がる様々な手法が...
次回の公開をご期待ください。