セッション管理

IEのプロセスとAlaskaの関係

Webアプリケーションの処理構造

Webアプリケーションの処理構造

一般に CGI は HTML をブラウザに排出すると同時に LR-終了 するような処理構造を
取っています。これは多くのクライアント(ブラウザ) からの要求に応えるために本来、
Web適用業務としての基本的な処理のルールです。
従ってある適用業務の初期画面を出力すると、CGI は同時に終了し、
次に明細画面が入力されたときには、改めて最初から変数値を取得したりの処理を
最初から始めなければなりません。( このような処理構造を ステートレス と呼びます。)

セッション管理 - WEB適用業務と5250適用業務の違い

これに対して 5250適用業務では、ご存知のように EXFMT 命令コードで次のユーザーからの入力をプログラムが待機していますので、画面が表示されている場合でも適用業務プログラムが終了しているわけではなく、従って変数値等のあらゆる情報も保持されたままになっています。
( このような処理構造を ステートフル と呼びます。)

初めて Web適用業務を見る5250適用業務の開発経験者は HTMLインターフェースを見るとWebサーバー側でCGI が EXFMT のように次の入力を待機しているかのような錯覚に陥ることがありますが、
CGI はHTML 画面を印刷出力のように出力してしまえば直ちに
LR-終了 する、単なるバッチ・プログラムであることを良く理解しておいてください。

Web アプリケーションにおけるセッション管理

Web アプリケーションにおけるセッション管理

簡単な Webアプリであれば前に処理しておいて次の処理で必要となるデータは HTML の中に
hidden という非表示の文字列として保管しておいて、次の処理ではこれらを読み取って処理を
継続させることができます。しかし適用業務の構造によっては、

  • 大量のデータを保持しておきたい。
  • QTEMP に一時的なデータ保存を行いたい。
  • COMMIT-ROLLBAK を利用したい。

という必要性が発生する場合があります。
このようなときには 5250適用業務と同じように、あたかも EXFMT のように処理が連続しているかのような擬似環境が必要となります。
ところが Web実行環境ではさらに次のような問題があります。

  • CGI は、HTTPサーバー配下にある複数の子スレッド・ジョブで実行されるが毎回、
    同じ子スレッド・ジョブで実行されるとは限らない。
    どの子スレッド・ジョブで実行されるかは不定であるため QTEMP を利用することはできない。
  • ブラウザと HTTPサーバーとの通信は 1分間、操作がないとブラウザが通信を切断してしまう。

特に前者の現実を考えると QTEMP と COMMIT の利用は不可能に思えてしまいます。
そこで一般の Webアプリケーションでは、データだけをユニークな識別を使ってどこかに保存しておいてから
後で復元するという苦肉の策が講じられています。
しかしこの場合でもデータの保管／復元は可能となますが QTEMP や COMMIT と使用することはできません。
さらに次のような歴史的な難問が控えています。

  • ユーザーがブラウザの「戻るボタン」を押すと画面遷移とデータやCGIとの整合性が崩れてしまう。
  • ユーザーがブラウザの「Ｘボタン」を押すとセッション・データが永続的にゴミとして残ってしまう。
  • ユーザーがブラウザの「更新ボタン」を押しても同じである。

JavaBeans や他社製品でも「セッション管理ができます!」と高らかに唄っていたはずがこれらの問題があるため
今ではすっかり強調することがなくなったのは、このような問題が顕在化してきたためです。
次はあるユーザーでのセッション・ファイルの残骸の様子です。 

      ｵﾌﾞｼﾞｪｸﾄ     タイプ    属性                サイズ    テキスト
      IWR01       *FILE     PF                   1363968   セッション管理ファイル
      IWR01L1     *FILE     LF                    188416   セッション管理ファイル
      IWR02       *FILE     PF                 600920064   セッション変数ファイル
      IWR02L1     *FILE     LF                   7372800   セッション変数ファイル
      IWR02L2     *FILE     LF                  32555008   セッション変数ファイル

この製品ではセッション・データを物理ファイルに保管するという手段をとっているためにこのような
莫大なゴミが重ねられてやがては DISK を圧迫してパフォーマンスも日々低下することは目に見えています。
これは製品開発メーカーの技術の問題でもあると言えるかも知れません。

RPG# のセッション管理による解決

RPG# のセッション管理による解決

それでは RPG# ではユーザーが希望するセッション管理は、どのように解決されているのでしょうか ?
RPG# によるセッション管理は、とてもシンプルでやさしいものです。

Wizard画面 - セッションを維持する

あなたは eStudio の Wizard で生成するときに

「 セッションを維持する 」

としてチェックを入れるだけです。これでセッション管理は完了です。
セッション管理のための特別なプロシージャーを呼び出したりする必要は全くありません。
この指示によって生成される HTML には次の HTML 文が一行、追加されます。 

<input type="hidden" name="AURORA_EGN" value="######">

このわずかな一行に、実行した子スレッド・ジョブのジョブ番号が非表示として保存されます。
HTTP サーバー: ALASKA は、このジョブ番号があるブラウザからの要求を受け取ると
必ず元の同じジョブ番号の子スレッド・ジョブに要求を戻します。
つまりこのわずかな一行によって必ず同じジョブでの処理が継続されて実行されることになります。
さらにセッション管理が指示されたときには、CGI は終了することなく次のユーザーからの入力を
待機し続けます。
次はその様子を表している WRKACTJOB の画面です。 

                              現行                                         
         OPT  ｻﾌﾞｼｽﾃﾑ/ｼﾞｮﾌﾞ  ﾕｰｻﾞｰ       ﾀｲﾌﾟ  CPU %   機能            状況
         __   ENTPRSSVR      QSYS        SBS      .0                   DEQW
         __     ALASKA       QTMHHTTP    BCH      .0  PGM-ALASKA_V5    TIMW
         __     AURORA_EGN   QTMHHTTP    BCI      .0  PGM-AURORA_EGN   TIMW
         __     AURORA_EGN   QTMHHTTP    BCI      .0  PGM-AURORA_EGN   TIMW
         __     AURORA_EGN   QTMHHTTP    BCI      .0  PGM-AURORA_EGN   TIMW
         __     AURORA_EGN   QTMHHTTP    BCI      .0  PGM-AURORA_EGN   TIMW
         __     AURORA_EGN   QTMHHTTP    BCI      .0  PGM-AURORA_EGN   TIMW
         __     AURORA_EGN   QTMHHTTP    BCI      .0  PGM-AURORA_EGN   TIMW

ユーザー : PGMR としてセッション管理が指定された Webアプリは次のユーザーからの要求を待機し、
たとえ 1分経過後に通信が切断されたとしてもタイマー・ジョブが起動されてユーザーの Webアプリは
一定時間のタイマーのあいだは、待機し続けます。この動作は 5250適用業務の EXFMT と同じです。

  • 大量のデータを保持しておきたい。
  • QTEMP に一時的なデータ保存を行いたい。
  • COMMIT-ROLLBAK を利用したい。

従って、上記のユーザーの要求も問題なく叶えられ、どこかにセッション・データを保存しておく必要すらありません。
つまりユーザーのセッション保持のこれらの要求を満足するだけでなく、セッション管理ファイルの残骸が大量に残る
という前述の製品のような深刻な問題も全く発生することはありません。

戻るボタンやＸボタンの問題の解決

戻るボタンやＸボタンの問題の解決

RPG# では「戻るボタン」や「Ｘボタン」の問題はどのように解決されるのでしょうか ?
RPG# で「セッションを維持する」を指示して HTML を生成すると最後に次のようなJavaScript 記述も
追加されます。 

<script type="text/javascript" src="/AS400-NET.USR/JS/ARR_JOBCTL.JS"></script>

この ARR_JOBCTL.JS という名前の JavaScript は、「戻るボタン」や「Ｘボタン」の問題を解決します。
「戻るボタン」を押すと、その操作は HTTPサーバー: ALASKA に確実に伝えられてRPG# は、実行スタックを
以前の状態に強制的に戻します。
いわば RPG の ROLLBK に良く似た状態の復元であり、これによって明細画面として待機していた処理は
初期画面の処理に引き戻されます。これは UNIX でのスタック復元技術が使用されています。

「Ｘボタン」を押したときも終了通知が確実に ALASKA に伝えられて Webアプリは浮いたままになることなく
確実に終了します。この技術は㈱オフィスクアトロが Microsoft社の支援を受けて半年間を要して開発した
「仮想対話式環境」と呼ばれる技術です。

戻るボタンやＸボタンの問題の解決

ステートレスなセッション管理

さらに RPG# では Webアプリが待機していなくてもセッション・データを保持することができます。

「 セッションを維持する 」

Wizard画面 - セッションを維持する

にチェックを入れるのではなく、ユーザーが独自に HTML に 

<input type="hidden" name=SESSION value="################################">

のようにして 32桁の文字列を埋め込むための HTML タグを用意しておいてから 

SET_SESSION (セッション・データの保存) と GET_SESSION (セッション・データの復元)

というプロシージャーを使って、セッション・データの保管と復元を行うことができます。
SET_SESSION を実行すると RPG# はセッション・データを独自に作成して、その識別子を上記の
SESSION という値に埋め込みます。
この 32桁の値は実際には 16桁の HEXコード であり、System i では GUID ( General Universal
Unique Identification ) と呼ばれる OS400 API が生成する一意的な重複のないコードです。
つまりブラウザ上で複数の画面(セッション) を起動したり多くのユーザーが同時に入力したとしても
決して重複することはありません。
参考までに先の製品ではファイルによって識別子を生成しているために多くのユーザーからの
アクセスがあるとデッド・ロックを起こしてしまうので担当者が 24時間、交代で監視しているという
例まであります。
さて、RPG# ではセッション・データはライブラリー: QRPLOBJ のユーザー待ち行列として保管されます。
ライブラリー : QRPLOBJ とはシステム的に用意された System i のゴミ箱のような特殊ライブラリーであり
次の IPL では OS400 によって QRPLOBJ の中身は必ずクリーン・アップされます。

このことにより、次の利点を得ることができます。

  • セッション・データは OS によってIPL クリーン・アップ されるので残骸は残らない。
  • ユーザー待ち行列であるので最速のパフォーマンスを得ることができる。
  • 通信が切断された後でもセッションの保持が可能である。

このようにユーザーを面倒から解放し、パフォーマンスに優れ、それでいてユーザーの希望を
叶えるものでなくては製品としてリリースすることはできません。

[ TOP ]