【温故知新】第6回「統合WebサービスサーバーIWSの構造とログ確認方法について」

統合Webサービスサーバー（IWS）とは？

IWSはIBM i OSに標準導入されるアプリケーションサーバー（以下APサーバー）の名称です。かつてはWebSphere Application Serverベース版やExpress版をベースにIBM i にポーティングしたものでした（プロファイルやConfigファイルなどが他OSのWebSpehre Application Serverと共通フォーマットです）。最近ではWebSphere Libertyベースになっています。
IWSには別名（過去呼ばれていた名前）がいくつかあります。統合APサーバー、統合Webアプリケーションサーバー、LWI（Light Weight Integration Server)などです。いずれにおいてもIWSの実態はWebSphere Application ServerベースのAPサーバーです。このAPサーバー上で動作するJavaアプリケーションが外部からhttp/httpsでSOAP/RESTのリクエストを受け取り、Toolbox for JavaのPCMLクラスを使用してIBM i 上の機能・プログラムを呼び出し・処理する一連の機能をIWSと呼びます。(図１)

近年の拡張では、バックエンドのプログラムを用意せずに、Db2 for i に対するSQL文を直接統合APサーバー上に登録しRESTサービスから実行するパターンも可能となりました。（図1の一番上のケース）このメリットはIBM i 上にロジックを実行するRPG,COBOL,Java等のプログラムが不要で、IBM i をサービスプロバイダーに出来る点です。

▲図1.

※上図ではRESTしか記載がありませんが、IWSはSOAPも応答可能です。

IWSからバックエンドのRPG,COBOL,Java等を呼び出す流れ

REST API -> IWS -> RPG,Db2ほか実行時の関連ジョブのフロー概要の構成を図2に示します。（認証系などが別途必要になる場合がありますが省略しています）

▲図2.

各ステップでの挙動やログは上記の①～③についてログ出力・確認できます。①は一般的なHTTPサーバー（Apache）と同様なのでスキップして、RESTなどAPI実行に関連する②，③について説明したいと思います。

IWSログ出力設定について

設定はNavigator for i -> Web Administration for i の画面から行います。
IWSのログ設定
デフォルトでは統合APサーバーにデプロイされたREST/SOAPサービスインターフェースのログは取得されない、になっているので設定を変更します。

手順(1)

まず、下記のWeb Admiinstration for i で全てのアプリケーションサーバーを表示します。続けて、ログ確認したいAPサーバー名（＝WRKACTJOBのジョブ名=インスタンス名）を選択し、下部の 詳細の管理 ボタンを押します。例では GOMA5500 というサーバー名です。

手順(2)

次にウィンドウ左側のメニューから 配置済みサービスの管理を選択します。下記の画面が表示されます。

上図では、REST APIで実行されるサービスが合計6つ、SOAP呼び出しが1つ、登録済みです。IWSのデフォルトではこれらのサービスのログ取得はしないため、ログ出力させたいサービスの設定をログ取得に変更が必要です。以下ではORDER_ADD4_TEST というサービスの設定を変更します。
画面左側のメニューから ログ をクリックします。

下記のログの画面で、 Webサービス タブを開きます。画面下部に登録済（デプロイ済み）のサービスが登録されているので、ログ出力が必要なサービスの Select欄にチェック をいれます。
例では ORDER_ADD4-2とORDER_ADD_TEST にチェックを入れました。この設定で図2の②のログが取得されるようになります。
また画面上、前後してしまいますが上段にツールボックス・トレース　という個所がありますが、これは、Toolbox for Javaのコンポーネントのログ取得の指定です。今回左記のPCMLを利用していますので、下図と同様　トレースの分離　に変更します（デフォルト値は無効）このように設定すると、図2の③のログが取得されるようになります。
チェック後、 適用 ボタンを押します。

※なお、図2の④はIBM i OS標準機能を利用しており、PCMLから（REST APIでコールされたサービスから）IBM i 内部でプログラムバッチコールが実行されます。このときのジョブ名は QUSRWRK/QZRCSRVSになります。

手順(3)

この後、テストを実施するわけですが、以降の説明のために登録済みの（ログ確認したい）サービス名をクリックしてデプロイ時の設定を確認します。
画面左側のメニューから Webサービスの箇所の配置済みサービスの管理 をクリックします。 下図が表示されるので、確認したいデプロイ済みサービス（例ではORDER_ADD4_TEST） をクリックします。続けて下段のプロパティボタンを押します。

下図のようにデプロイした際の設定が確認できます。
一般タブ：　ベース・リソースURL : この後ブラウザーから入力してこのサービスを呼び出す基本のURLがこれになります。

セキュリティタブ：今回のテストでは　当ページのユーザーIDをデフォルト*SERVERから GOMA2 に変更しています。このユーザーIDを変更することによって、後に実行した際にGOMA2というユーザーIDが実行したログだけを対象に調べることが出来るようになります。デフォルト*SERVERの場合、実行ユーザー名はQWSERVICE となります。
最下部の キャンセル　ボタンを押して確認を終了します。

確認を完了したらキャンセルボタンを押します。

テスト実行

サーバー起動時に生成されるログファイルの確認

それではREST APIを実行してテストを行います。テスト開始前にすでに存在しているログファイルは以下のようになっています。

ログファイルはIWSサーバー毎に、
/www/GOMA5500/wlp/usr/servers/GOMA5500/logs/　のようなディレクトリーに格納されます。
代表的なものを以下に説明します。

Lwipid.txt : LWI = IWSサーバージョブのプロセスIDを記録します。
5250,Navigator for i でIWSのサーバージョブのジョブログを表示すると下記のように同じPIDが記録されていることが分かります。

QIBM_i_jt400.log　：　Toolbox for Javaバージョン、javaバージョン等と実行ログ

下図のように実行されているToolbox for JavaのバージョンやJAVAバージョンなどが記録されます。Toolbox for Javaを使用したアプリケーションの実行ログも取得されます。

Messages.log　APサーバー起動時のログ

IWS APサーバー起動時のログが記録されます。下図のようにWebSphere Application Server 23.0.0.12 （WebSphere Libertyのバージョン番号）が確認できます。また、IWSのインストールディレクトリーやJAVAバージョンも記録されています。ログの下部を見ると、デプロイしたアプリケーションがロードされたログも表示されています。（複数のORDER_ADDxxxの行）この辺の動作はIBM i 以外のOSで動作するWebSphere Application Serverと共通です。

jobname.txt　IWSサーバーのジョブIDを記録

下図のようにIWSサーバージョブID（ジョブ名/ユーザー名/ジョブ番号）が記録されます。同じ情報はWRKACTJOBコマンド等から該当ジョブのジョブログで確認できます。

RESTコールのテスト

それではREST APIでIWSのサービスを呼び出しテストを実施します。今回はIWSの設定ページで確認した、ベース・リソースURL に呼出しするILE RPGに渡すパラメーター（今回はQEOLの得意先マスターTOKMSPの顧客番号 01010 を渡します）を追加して以下のように指定します。このURLは実行するプログラムによって変わりますので参考としてご覧ください。
ブラウザーから下記URLを入力してエンターキーを押します。

   http://ibmi75:5532/web/services/ORDER_ADD4_TEST/01010
  

実はこのサービスは意図的に誤りを作ってあり、エラーで正常実行できないようにしてあります。

テスト実行：エラー発生のケース

実行結果は以下のように、単にブラウザーにブランクページが表示されてしまいます。
※以下の分析結果の先取りになってしまいますが、実行条件によっては、REST API実行時のエラーコード405等が表示される場合もあります。

このままでは問題判別が難しいので、上記で説明したログファイルを確認することになります。図2を再掲します。

エラーログの分析はNavigator for iが効率が良い

ここからは，③④の各ログを確認していくのですが、5250のWRKACTJOB画面等からの分析は大変非効率になります。理由はPCMLほかで呼び出されるジョブの数が非常に多くなるためです。分析対象のジョブをジョブ名やユーザー名等でフィルターしながら探す方が5250で一行ずつ調べるより効率は良いです。現在において、デバッグや問題判別はNavigator for i を強く推奨いたします。 下記のようにNavigator for iでフィルターを駆使して分析を効率化します。今回の例ではまず、ジョブ名で④のジョブQZRCSRVSをフィルターします。さらに現行ユーザーでGOMA2をフィルターしてもOKです。複数のGOMA2ジョブが存在する場合は、上記でしらべたジョブ番号（jobname.txt）と合致するジョブ番号を探します。
対象のジョブが特定できたらジョブ名を右クリックしてジョブログを表示します。

下図がジョブログを表示した状態です。5250と異なり最上部が最新となります。途中のエラーはジョブ記述でRPT01(*DEVDが存在しない）を指定しているもので無視できます。 最上部で呼出しするILE RPGのライブラリーリストを正常に追加できていることから、PCML経由での呼出しは成功しているように思われます。
そこで分析対象を③PCMLに移動してみます。

Toolbox for Java : PCMLの呼び出しログを確認

Toolbox for Java : PCMLのログはQIBM_i_jt400.logに出力されます。
上記ログを確認すると、IWSのサービス画面で指定しているユーザー名などが確認でき、Toolbox for javaからは正常にPCMLコールできているように思われます。
そこで、さらに移動して②のIWSのログを確認してみます。

IWSのREST API実行ログを確認する

上で解説した、messages.log　を調べると、HTTPリクエスト実行時エラー405 (Method Not Allowed）が出ていました。
このエラーはクライアントからのリクエストに含まれる操作（今回はPOST）が許可されないことを表しています。

実はIWSにサービス登録する際、意図的に使用メソッドをGET -> POSTと間違えて登録したことが原因でした。（下図）

IWSのエラーログから上記エラーを見つけた場合、すでに登録済みのサービスを修正することはできず、別名追加、またはいったん削除してサービス再登録が必要です。
今回は事前に別名（ORDER_ADD4-2）というサービス名で登録していますのでこれを呼び出します。

http://ibmi75:5532/web/services/ORDER_ADD4-2/01010
IWSのRESTサービスの実行ログを確認する　正常ケース
結果、正常に実行されたことを示すレスポンスコード 200 がログされていることを確認できました。
実際のケースではこの後ILE RPGが正しく実行されたかの確認もしますが、今回は既存で正常動作していたプログラムを流用しているためそのチェックは省略しています。

以上

筆者