1. サーバ側からのJOB監視機能及び遅延監視機能の追加　(2006.06)

1. 本システムは、一つ以上のＪＥＳ（JobExclusiveService）と呼ばれる常駐処理と、画面
   I/FとしてJSP形式のWeb用モジュールの形で実装されます。
   (Rev2.0からはjavaアプリケーションの環境設定用アプリケーションも付属いたします)
   ＪＥＳはクラスディレクトリと呼ばれるftpにてアクセス可能なディレクトリに本システムが
   定める形式の起動要求ファイルが書込まれるとその指示に従って処理(.bat,.exe等)
   の起動を行います。
   尚、本システム配下で動作させる為に、バッチファイルやexeファイル内に特別なモジュール
   を組み込む必要はありません。
   クラスディレクトリとＪＥＳの関係は通常１：１ですが、クラスディレクトリはftpサーバ
   の実装されているマシンであればJESとは別マシン上に配置しても構いません。
   また一つのクラスディレクトリに対して別マシン上に実装した複数のＪＥＳをアクセスさせる
   構成にすればバッチ処理用サーバの負荷分散も可能です。



2. ＪＥＳ単位に、同時実行可能な最大バッチ処理数を定めておけます。
   これは、基本的にはトラフィックを制御する為の機能であり、最大処理数分処理が走行されて
   いる状態でいずれかの処理が正常/異常のいかんを問わず終了した時、他に要求されている
   処理があれば基本的に要求された順にて順次実行されます。



3. ＪＥＳ単位に、同一JOBIDを持つ処理は同時実行されないように制御されます。
   これは資源競合の回避や処理の順序性確保の為の機能であり、ある再処理が必須なJOBが
   異常終了した場合でも本システムの機能にて再処理ないしはキャンセルが行われるまでは
   、後続の同一JOBIDを持つ処理が実行される事はありません。
   (但し、再処理不要属性のJOBであればこの制御はなされず、異常でも終了した段階で後続
   の同一JOBIDを持つ処理が実行されます)
   尚、JOBIDは通常は起動コマンド中のファイル名とみなされます(TEST01.batを起動する
   ならJOBIDはTEST01)が、コマンド名とは全く別の値を指定して起動する事も可能ですので、
   異なる処理同士でも同一JOBIDを使用すれば同時実行されることはなくなります。
   また同じコマンドでも異なるJOBIDを
   使用すれば並列実行が可能です。



4. 本システムから起動された処理それぞれに対して、他処理とは競合しない専用のかつ
   異常終了後の再処理時には再利用出来るワークディレクトリが提供されます。
   このディレクトリを使用する事で(ディレクトリ名は処理に対して本システムの定める
   制御変数にて引き渡されます)、他処理との競合を意識することなくワークファイルを
   作成したり各種状態を再処理時に引き継ぐ事が出来ますので、再処理開始ポイントの
   自動制御等も可能になります。
   (因に複数ステップからなる処理のステップリランを可能にするスクリプトモジュール例
   を本システムの関連ツールライブラリとして御提供しています)尚、本ディレクトリは
   少なくとも当該処理が正常終了するまで保持されますが、指定により本システムが
   保持している処理実行履歴を削除するまで保持し続ける事も可能ですので、別処理に
   ワークファイルの内容を引き継いだり、テスト期間やシステムリリース当初に中間ファイル
   の内容も含めて状況を保存しておくといった事も出来ます。



5. 処理の起動要求は通常以下の方式で行います。
   
   
   • 本システムの提供する用ツール(_AzbRJコマンド)を用いる方法。
     基本的には起動したい処理のコマンド(又はJOB定義名)、や各種JOB属性を本ツールに対する
     引数や制御変数にて指定する方式となりますが、予め専用メンテ画面にてJOB定義情報を登録
     しておけばより簡易な指定のみで使用することも出来ます。
     このツールを使用すると起動した処理の終了を待機する事も指定により可能です。
     この時、起動した処理が正常/異常に関わらず終了した時点まで待機するか、正常終了するまで
     待機するか選択可能です。
     一般には特に待機する必要はないケースが多いと思われますが、例えばJOBネットワーク管理を
     行う他ミドルソフトにおいて後者のモードで本ツールを介して処理を起動すれば、その処理が
     異常終了しても本システムにおいて再処理完了するまで他ミドルソフトにとっては処理実行中
     といった状態のまま待機しますので、そういったミドルソフトと本システムとの間で
     「起動管理は他ミドル、実行,再処理管理は本システム」といった機能分担が図れます。
     また逆に、前者のモードを使用し本システムとしては再処理不要として処理起動すれば
     起動管理を行うミドルソフト側からの再処理や処理ステータスに応じた処理分岐が可能です。
     これは、ファイル転送管理ソフト等で後続JOBの正常終了をもって転送の正常終了とみなす
     といった運用を行いたい場合に適しています。
     尚、この専用ツールを使用すると別マシン上からでもBapsの実装されたマシン上の処理起動や
     終了待機を行う事が出来ます。
   
   
   
   • 本システムの提供するJOB起動画面を用いる方法。(Rev3.0新規機能)
     予めJOB情報メンテ画面にてJOB定義情報を登録しておくことにより、専用のWeb画面からの
     バッチ処理起動が可能になります。
     さらにJOB起動情報メンテ画面にて引数情報を定義しておけぱ、JOB起動画面上で処理に引継ぎ
     たい引数を指定した上での処理起動が可能です。
     また、ユーザーID/パスワードによる起動可否チェックを行う事も出来ます。
     本機能を使用するとエンドユーザー側からサーバ上のバッチ処理を起動するような運用を簡易
     に実現可能です。


6. 処理の起動要求に関しては、上記の他に本システムで定めた形式の起動要求ファイルを
   クラスディレクトリに直接書込む事でも可能です。WebAPや各種ｃ／ｓソフト,Officeツール等
   から処理を起動したい場合はこの方法が使用出来ます。ファイルを書込むだけですので
   VBA等で簡単に実装可能なロジックで実現出来ますが、必要ならJava,VB等言語に応じた
   APIとしての提供を検討いたしますので御相談下さい。
   また、弊社製の別製品でありますAziunAcceptorからの起動も可能です。
   ACOS-4からの起動は上記AziunAcceptorを介する方法の他、別途用意した専用のツール
   を使用す方法も選択可能です。後者の場合はe.で御紹介した専用ツールと同様の引数等を
   指定したコマンドラインイメージを、SYSIN内に記述する事での起動となります。



7. 本システムから起動する処理は基本的にはWindow表示等がないバッチアプリケーション
   である事が望ましいですが、Windows環境におけるＪＥＳの通常の設定では「Localsystem」で
   ログインされた状態で、かつ「コンソールとの対話を許可する」モードで作動します。
   本システムから起動された処理にもその属性が適用されますので、仮に何らかのダイアログ
   を表示するような処理を起動しても、サーバにログインすれば対処が可能となります。
   尚、常にあるユーザがログインした状態でサーバの運用を行う場合は、そのユーザー配下で
   ＪＥＳが作動するよう設定することも可能です。



8. 上記処理実行状況検索用のログ情報は、通常環境設定時に定義した日数分保持されますが、
   専用のJOB履歴削除ツール(_AzbJobdelコマンド)にて削除する事も可能です。
   叉、Rev3.0からは削除する前にJOB履歴保存ツール(_Azblogsaveコマンド)にてcsv形式の
   履歴情報とそこにリンクした各処理のログ情報をエクスポートする事が可能になりました。



9. 処理の異常発生時には本システムの定める特定のスクリプトを実行する機能がありますので
   そこにイベントログへの書き出しやe-mailの送信といった処理を記述することで、運用環境
   にあわせた各種障害通知を行う事が可能です。
   叉、Rev3.0からは予め定義したしきい値を超過して実行中のままとなっている処理に関しても
   通知対象とするオプション機能が使用可能です。

先頭に戻る