JP1/AJS3を使っていると、決められた時刻ではなく、ファイルの到着や他システムの処理完了を待ってから次へ進めたい場面があります。
私がJP1/AJS3を使っていたときも、
- データファイルが届いた
- 別のシステムからイベントを受信した
- 指定した時間が経過した
といったことを契機に、次の処理を動かしていました。
その際に使っていたのが、ファイル監視ジョブ、JP1イベント受信監視ジョブ、実行間隔制御ジョブです。
この記事では、この3種類について、私が実際にどのような場面で使っていたのかを紹介します。
JP1/AJS3ではイベントを契機に処理を動かせる
JP1/AJS3では、イベントジョブを使って特定の事象を監視できます。
日立製作所の公式マニュアルでは、起動条件にイベントジョブを設定し、
- ファイルの変化を監視する
- 特定のJP1イベントを受信する
- 指定した時間の経過を待つ
といった条件を契機に、ジョブネットを実行できることが説明されています。
私が実務で使っていたのも、このような「何かを待ってから処理を進める」仕組みでした。
ファイル監視ジョブでデータファイルの到着を待っていた
ファイル監視ジョブは、データファイルが届いたことを契機に後続処理を動かす用途で使っていました。
私が扱っていた構成では、起動条件のCONDITION側にファイル監視を入れ、監視のトリガーとして使うことがありました。
また、処理の途中にファイル監視ジョブを配置することもありました。
例えば、
データファイルを待つ
↓
ファイルが来る
↓
次の処理を実行する
という流れです。
ここでいうファイル監視と、PCジョブの中で実際にファイルを作成・更新・削除したり、DBを更新したりする処理は、別のものとして扱っていました。
ファイルが来なかったときの扱いは処理によって変えていた
ファイル監視では、「ファイルが来たとき」だけでなく、「来なかったとき」をどうするかも処理によって変えていました。
毎日動く処理でも、元になるデータがない日はファイル自体が来ないものがありました。
また、随時連携で、いつファイルが来るか決まっていないものもありました。
こうした処理では、ファイルが来なかったことだけを理由にエラーにはしていませんでした。
一方で、
「毎日この時間までにはファイルが来る」
という前提の処理もあります。
そのような場合には、決められた時間を過ぎてもファイルが来なければ、エラー用のジョブネットが動くようにしていました。
そこからエラー通知を出し、メールを送信する処理につなげていました。
私の場合は、ファイル未着をエラーにするかどうかは重要度ではなく、そのファイルがどのような前提で届くものかによって変えていました。
なお、未着をエラーにするかどうかとは別に、エラー時の連絡方法も処理によって異なりました。重要度が低い処理でもメールで通知することがあり、急ぎのものでは電話で連絡する場合もありました。
JP1イベント受信監視ジョブは別ベンダーとの連携でも使っていた
JP1イベント受信監視ジョブは、別ベンダーや自サーバー以外の処理と連携する場面でも使っていました。
例えば、相手側の処理が終わったらJP1イベントを送ってもらい、
相手側の処理が完了
↓
JP1イベントを送信
↓
こちらでイベントを受信
↓
次の処理を実行
という流れにしていました。
日立製作所の公式マニュアルにも、他ホストから送られたJP1イベントをJP1イベント受信監視ジョブで受け取り、後続ジョブを実行する構成例があります。
私が担当していた環境でも、別のサーバーやベンダー側の処理完了をイベントで受け取り、その後の処理へつなげていました。
実行間隔制御ジョブは30分おきの処理や待ち時間に使っていた
実行間隔制御ジョブも使っていました。
私が扱っていた構成では、CONDITION側に実行間隔制御ジョブを入れ、30分おきに繰り返し動かす処理にすることがありました。
また、ジョブネットの途中に実行間隔制御ジョブを入れ、
処理A
↓
一定時間待つ
↓
処理B
というように、次の処理までの待ち時間を作る用途でも使っていました。
日立製作所の公式マニュアルでも、実行間隔制御ジョブを使って時間の経過を監視する構成や、起動条件側で一定間隔の実行に使う考え方が説明されています。
私の場合は、同じ実行間隔制御ジョブを、起動条件側で使う場合と処理途中で使う場合がありました。
予定していた時間を過ぎてイベントやデータが来ることもあった
予定時刻を過ぎた場合の扱いは、処理によって異なっていました。
時刻を過ぎた時点でエラーとして扱うものもあれば、その後にイベントやデータが届いた場合に個別に対応することもありました。
遅れて届いたデータを翌日の処理時に一緒に連携する場合もあれば、急ぎの処理では相手側から連絡を受け、こちらで即時起動することもありました。
また、JP1イベントの情報を受け取る必要がある場合には、こちら側を動かしたうえで、送信元からイベントをもう一度送ってもらうこともありました。
一方で、固定時刻で動く処理だからといって、こちら側だけが先に進むことは基本的にありませんでした。
私が扱っていた処理では、実行前の条件としてデータが届いていることや、イベントを受信していることを確認する構成が多かったためです。
そのため私にとってイベントジョブの利点は、単純に「固定時刻より安全」ということではなく、実際のデータ到着や相手側の処理完了を契機として処理をつなげやすいことでした。
想定外の時間にイベントが来ても動かないようにしていた
一方で、イベントを受け取ったら処理が動くという仕組みには怖さもありました。
想定していない時間にファイルやイベントが来た場合でも、そのまま処理が開始される構成にはしたくありませんでした。
そのため、私が担当していた環境では、イベントを監視する時間帯を意図的に制御していました。
特定の時間帯だけ監視できる状態にし、それ以外の時間帯では、「未登録」または「開始時刻待ち」の状態にして処理が動かないようにしていました。
未登録と開始時刻待ちでは、詳細な設定方法は異なります。
私が意識していたのは、「イベントが発生したからといって、いつでも処理を開始させない」という点でした。
まとめ：イベントを待つ処理では来なかった場合や監視時間も考えていた
私がJP1/AJS3を使っていたときは、固定時刻だけで処理を動かすのではなく、イベントジョブを使って処理をつなげていました。
ファイル監視ジョブではデータファイルの到着を待ち、JP1イベント受信監視ジョブでは別ベンダーなどからの完了通知を受け取ってから次の処理を動かしていました。
実行間隔制御ジョブは、30分おきの繰り返し処理や、ジョブの途中に待ち時間を作る用途で使っていました。
また、ファイルが来ない場合には、処理の前提によって未着をエラーにしないこともあれば、一定時刻を過ぎるとエラー用ジョブネットから通知・メール送信へ進めることもありました。
予定していた時間を過ぎてデータやイベントが届いた場合も、翌日の処理で連携する、即時起動する、必要に応じて再送を依頼するなど、処理に合わせて対応していました。
イベントを受け取る時間帯についても、想定外の時間に処理が開始されないよう意図的に制御していました。
私の経験では、イベントジョブを使うときは、「イベントが来たらどう動くか」だけでなく、「来なかった場合」と「いつ受け付けるか」まで含めて考えることが重要でした。
