図面 (/)

技術 ジョブ管理システム、ジョブ管理方法及びジョブ管理プログラム

出願人 みずほ情報総研株式会社株式会社みずほ銀行
発明者 楠田圭浅海直之大仲浩司松橋史晃水戸裕士藤本真紀子
出願日 2018年3月13日 (2年0ヶ月経過) 出願番号 2018-045483
公開日 2019年9月19日 (6ヶ月経過) 公開番号 2019-159789
状態 不明
技術分野
  • -
主要キーワード 下流システム 上流システム 先後関係 属性データ領域 実行所要 排除処理 実行済みフラグ バッチ処理システム
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2019年9月19日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (10)

課題

上流システムから受信したファイルを用いて、下流システムにおいて、世代順を考慮したジョブの実行を支援するためのジョブ管理システムジョブ管理方法及びジョブ管理プログラムを提供する。

解決手段

第1サーバ10から取得したファイルを用いて、第2サーバ20のジョブ実行環境におけるジョブ実行を管理する制御部21を備える。そして、制御部21が、スケジュールルールに基づいて実行される業務処理ジョブに必要なファイルの受信状況を判定し、前記上流システムから前記ファイルを受信していない場合、先行ジョブ実行状況に基づく保留設定と、上流システムからのファイルの受信状況に基づく保留設定とを含めた保留解除受付ジョブ、保留解除受付ジョブの実行に基づいて実行される業務処理ジョブ、業務処理ジョブの実行に基づいて、後続ジョブの保留設定を解除するための保留解除ジョブからなる一世代の復旧ジョブネットを生成する。

概要

背景

企業における業務管理のために複数のバッチジョブを連続して実行させる場合がある。この場合、各ジョブ先後関係を考慮する必要があり、このような先後関係を示したジョブネットワークジョブネット)によりジョブの実行を管理している。このようなジョブネットにおいて障害が発生することもある。そこで、ジョブネットを使用したバッチ処理システムにおける障害復旧処理のための技術が検討されている(例えば、特許文献1を参照。)。この文献に記載された技術においては、必要な再実行ジョブを決定する再実行ジョブ決定手段、ジョブ再実行の為のジョブ再実行手段、実行ジョブ制御文が格納されている実行JCLライブラリ、ジョブ内で処理されたファイル情報を格納するアクセス履歴ファイル、再実行が必要なジョブ名が格納されている再実行ジョブ管理ファイルを設ける。

また、企業システムにおいては、複数のシステム連携させて構築する場合がある。例えば、銀行においては、対顧客用勘定系システム市場系システム(上流システム)に対して、取引状況や企業状況を管理するための情報系システム下流システム)を設ける場合がある。この場合には、下流システムは、上流システムから取引に関するファイル上流ファイル)を取得し、このファイルを加工するための各種情報処理のためのジョブネットを実行する。

概要

上流システムから受信したファイルを用いて、下流システムにおいて、世代順を考慮したジョブの実行を支援するためのジョブ管理システムジョブ管理方法及びジョブ管理プログラムを提供する。第1サーバ10から取得したファイルを用いて、第2サーバ20のジョブ実行環境におけるジョブ実行を管理する制御部21を備える。そして、制御部21が、スケジュールルールに基づいて実行される業務処理ジョブに必要なファイルの受信状況を判定し、前記上流システムから前記ファイルを受信していない場合、先行ジョブ実行状況に基づく保留設定と、上流システムからのファイルの受信状況に基づく保留設定とを含めた保留解除受付ジョブ、保留解除受付ジョブの実行に基づいて実行される業務処理ジョブ、業務処理ジョブの実行に基づいて、後続ジョブの保留設定を解除するための保留解除ジョブからなる一世代の復旧用ジョブネットを生成する。

目的

特開2001−229033号公報






上流システムは、所定の処理サイクル(例えば、日次)で、下流システムに上流ファイルを提供する

効果

実績

技術文献被引用数
- 件
牽制数
- 件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

該当するデータがありません

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

上流システムから取得したファイルを用いて、下流システムジョブ実行環境におけるジョブ実行を管理する制御部を備えたジョブ管理システムであって、前記制御部が、スケジュールルールに基づいて実行される業務処理ジョブに必要なファイルの受信状況を判定し、前記上流システムから前記ファイルを受信していない場合、先行ジョブ実行状況に基づく保留設定と、上流システムからのファイルの受信状況に基づく保留設定とを含めた保留解除受付ジョブと、前記保留解除受付ジョブの実行に基づいて実行される業務処理ジョブと、前記業務処理ジョブの実行に基づいて、後続ジョブの保留設定を解除するための保留解除ジョブとからなる一世代の復旧ジョブネットを生成することを特徴とするジョブ管理システム。

請求項2

前記上流システムから前記ファイルを受信していない場合、まだ実行されていない復旧用ジョブネットの世代数を算出し、前記世代数が上限数に達していないことを条件に、前記世代数に1を加算した復旧用ジョブネットを生成することを特徴とする請求項1に記載のジョブ管理システム。

請求項3

前記上流システムからファイルを受信した場合、前記ファイルに関連付けられた業務処理ジョブの実行条件を取得し、前記実行条件に基づいて、前記業務処理ジョブを含む復旧用ジョブネットを実行することを特徴とする請求項1又は2に記載のジョブ管理システム。

請求項4

前記上流システムからのファイルの受信スケジュールに対して、受信したファイルの遅延状況に基づいて、前記ファイルに関連付けられた業務処理ジョブを含む復旧用ジョブネットの実行要否を判定することを特徴とする請求項1〜3の何れか一項に記載のジョブ管理システム。

請求項5

前記保留解除ジョブの実行に基づいて実行可能となった復旧用ジョブネットを特定し、ジョブ実行環境のリソースに空きがある場合に、前記復旧用ジョブネットの業務処理ジョブの優先順位に基づいて、前記復旧用ジョブネットの実行を指示することを特徴とする請求項1〜4の何れか一項に記載のジョブ管理システム。

請求項6

前記保留解除ジョブの実行に基づいて実行可能となった復旧用ジョブネットの実行状況を取得し、復旧用ジョブネットの実行リソースの状況を取得し、前記復旧用ジョブネットの業務処理ジョブの完了時限に応じて、リソース配分を変更することを特徴とする請求項1〜5の何れか一項に記載のジョブ管理システム。

請求項7

前記上流システムからの複数のファイルを受信した場合に、前記上流システムにおいて生成されるべきファイルの世代順に並び替えて、復旧用ジョブネットを実行することを特徴とする請求項1〜6の何れか一項に記載のジョブ管理システム。

請求項8

前記業務処理ジョブにおいて、障害の発生前に受信したファイルを用いて出力された第1の出力結果と、前記障害の復旧後に受信したファイルを用いて出力された第2の出力結果との差分を算出し、前記障害の期間に応じた許容範囲を特定し、前記差分と前記許容範囲とに基づいてアラームを出力することを特徴とする請求項1〜7の何れか一項に記載のジョブ管理システム。

請求項9

上流システムから取得したファイルを用いて、下流システムのジョブ実行環境におけるジョブ実行を管理する制御部を備えたジョブ管理システムを用いて、ジョブ実行を管理する方法であって、前記制御部が、スケジュールルールに基づいて実行される業務処理ジョブに必要なファイルの受信状況を判定し、前記上流システムから前記ファイルを受信していない場合、先行ジョブの実行状況に基づく保留設定と、上流システムからのファイルの受信状況に基づく保留設定とを含めた保留解除受付ジョブと、前記保留解除受付ジョブの実行に基づいて実行される業務処理ジョブと、前記業務処理ジョブの実行に基づいて、後続ジョブの保留設定を解除するための保留解除ジョブとからなる一世代の復旧用ジョブネットを生成することを特徴とするジョブ管理方法

請求項10

上流システムから取得したファイルを用いて、下流システムのジョブ実行環境におけるジョブ実行を管理する制御部を備えたジョブ管理システムを用いて、ジョブ実行を管理するためのプログラムであって、前記制御部を、スケジュールルールに基づいて実行される業務処理ジョブに必要なファイルの受信状況を判定し、前記上流システムから前記ファイルを受信していない場合、先行ジョブの実行状況に基づく保留設定と、上流システムからのファイルの受信状況に基づく保留設定とを含めた保留解除受付ジョブと、前記保留解除受付ジョブの実行に基づいて実行される業務処理ジョブと、前記業務処理ジョブの実行に基づいて、後続ジョブの保留設定を解除するための保留解除ジョブとからなる一世代の復旧用ジョブネットを生成する手段として機能させることを特徴とするジョブ管理プログラム

技術分野

0001

本発明は、上流システムからファイルを受信した下流システムにおいて、世代順を考慮したジョブの実行を支援するためのジョブ管理システムジョブ管理方法及びジョブ管理プログラムに関する。

背景技術

0002

企業における業務管理のために複数のバッチジョブを連続して実行させる場合がある。この場合、各ジョブの先後関係を考慮する必要があり、このような先後関係を示したジョブネットワークジョブネット)によりジョブの実行を管理している。このようなジョブネットにおいて障害が発生することもある。そこで、ジョブネットを使用したバッチ処理システムにおける障害復旧処理のための技術が検討されている(例えば、特許文献1を参照。)。この文献に記載された技術においては、必要な再実行ジョブを決定する再実行ジョブ決定手段、ジョブ再実行の為のジョブ再実行手段、実行ジョブ制御文が格納されている実行JCLライブラリ、ジョブ内で処理されたファイル情報を格納するアクセス履歴ファイル、再実行が必要なジョブ名が格納されている再実行ジョブ管理ファイルを設ける。

0003

また、企業システムにおいては、複数のシステム連携させて構築する場合がある。例えば、銀行においては、対顧客用勘定系システム市場系システム(上流システム)に対して、取引状況や企業状況を管理するための情報系システム(下流システム)を設ける場合がある。この場合には、下流システムは、上流システムから取引に関するファイル(上流ファイル)を取得し、このファイルを加工するための各種情報処理のためのジョブネットを実行する。

先行技術

0004

特開2001−229033号公報

発明が解決しようとする課題

0005

上流システムは、所定の処理サイクル(例えば、日次)で、下流システムに上流ファイルを提供する。この上流ファイルは、処理サイクルを実行した基準日(日付)毎に世代管理される。ここで、下流システムにおいては、基準日が遅い後続世代の上流ファイルを扱う後続ジョブが、基準日が早い先行世代(先行基準日)の上流ファイルを扱う先行ジョブ追い越して実行されないように世代順を考慮する必要がある。一方、障害発生により、上流ファイルの提供が予定時刻よりも遅延することがある。このような上流ファイルの遅延に対応して、下流システムにおいてジョブの復旧を行なったのでは、上流ファイルの受信タイミングを考慮する必要があり、復旧に手間がかかっていた。

課題を解決するための手段

0006

上記課題を解決するために、ジョブ管理システムは、上流システムから取得したファイルを用いて、下流システムのジョブ実行環境におけるジョブ実行を管理する制御部を備える。そして、前記制御部が、スケジュールルールに基づいて実行される業務処理ジョブに必要なファイルの受信状況を判定し、前記上流システムから前記ファイルを受信していない場合、先行ジョブの実行状況に基づく保留設定と、上流システムからのファイルの受信状況に基づく保留設定とを含めた保留解除受付ジョブと、前記保留解除受付ジョブの実行に基づいて実行される業務処理ジョブと、前記業務処理ジョブの実行に基づいて、後続ジョブの保留設定を解除するための保留解除ジョブとからなる一世代の復旧用ジョブネットを生成する。

発明の効果

0007

本発明によれば、下流システムにおいて、上流システムから受信したファイルを用いて、世代順を考慮したジョブの実行を支援することができる。

図面の簡単な説明

0008

本実施形態のシステム概略図。
本実施形態のルートジョブネットの説明図。
本実施形態の世代順を考慮したルートジョブネットの説明図。
本実施形態の処理手順の説明図であって、(a)はジョブ生成管理処理、(b)はジョブ実行管理処理の説明図。
本実施形態のルートジョブネットの処理状態の説明図であって、(a)はn日、(b)は(n+1)日、(c)は(n+2)日、(d)は(n+3)日、(e)は(n+6)日の処理状態の説明図。
他の実施形態の処理手順の説明図であって、(a)はジョブ実行管理処理、(b)はルートジョブネットの処理状態の説明図。
他の実施形態の処理手順の説明図。
他の実施形態の処理手順の説明図。
他の実施形態の処理手順の説明図。

実施例

0009

以下、図1図5を用いて、ジョブ管理システムの一実施形態を説明する。
図1に示すように、本実施形態では、ネットワークを介して接続された第1サーバ10及び第2サーバ20を用いる。

0010

この第2サーバ20には、クライアント端末30が接続される。クライアント端末30は、第2サーバ20を管理する担当者が用いるコンピュータ端末や、第2サーバ20における業務処理結果を出力するコンピュータ端末である。クライアント端末30は、ディスプレイ等の出力部、キーボード及びポインティングデバイス等の入力部を備えている。

0011

第1サーバ10は、上流システムであり、例えば、顧客の口座を管理する勘定系や、取引市場において顧客取引を管理する市場系等の対顧系システムを想定する。本実施形態では、勘定系や市場系の処理に基づいて生成された情報(上流ファイル)を第2サーバ20に提供する。

0012

第2サーバ20は、第1サーバ10の下流システムであり、第1サーバ10から取得した上流ファイルに基づいて、会計処理報告書作成処理等の情報処理(業務処理)を行なう情報系(内部系)のコンピュータシステムである。この第2サーバ20は、制御部21、ジョブネット定義記憶部22、ジョブ定義記憶部23、スケジュール定義記憶部24、ステータス情報記憶部25を備えている。

0013

制御部21は、制御手段(CPU、RAM、ROM等)を備え、後述する処理(ジョブ生成段階、ジョブ管理段階、ジョブ実行段階等の各処理)を行なう。そのためのジョブ管理プログラムを実行することにより、制御部21は、ジョブ生成部211、ジョブ管理部212、ジョブ実行部213として機能する。

0014

ジョブ生成部211は、第2サーバ20において実行されるジョブを生成する処理を実行する。本実施形態では、第1サーバ10において障害が発生し、取引情報の提供が受信スケジュールよりも遅延した場合に、ジョブ生成部211は、この遅延に対応したジョブネットワーク(復旧用ジョブネット)を生成する。

0015

ジョブ管理部212は、登録された各種ジョブ、ジョブネットの実行を管理する処理を実行する。
ジョブ実行部213は、ジョブ実行環境(リソース)において、ジョブ管理部212によって制御された各ジョブを実行する。このジョブ実行部213は、ジョブ識別子毎に登録されている。

0016

ジョブネット定義記憶部22には、ジョブネットを構成するジョブについてのジョブネット定義データが記録される。このジョブネット定義記憶部22には、各ジョブネットを構成する先行ジョブ、後続ジョブを特定するためのデータが記録される。

0017

図2に示すように、本実施形態では、第1サーバ10(上流システム)に障害が発生し、第2サーバ20(下流システム)において上流ファイルの受信が、受信スケジュールよりも遅延した場合、復旧のためのルートジョブネット500(復旧用ジョブネット)を生成する。

0018

このルートジョブネット500は、第1ジョブネットJ1〜第3ジョブネットJ3により構成される。
第1ジョブネットJ1は、保留解除を受け付ける保留解除受付用ネストジョブネットワークであり、第1サーバ10からの基準日の上流ファイルの受信を待機する保留ダミージョブJ11や、先行ジョブの実行完了を待機する保留用ダミージョブJ12を含む。保留用ダミージョブJ11は、第1サーバ10から、所定のファイル識別子の上流ファイルを受信した場合に実行される。保留用ダミージョブJ12は、先行ジョブが実行完了した場合に実行される。

0019

第2ジョブネットJ2は、第1サーバ10からの上流ファイルを用いた情報処理(例えば、会計処理や報告書の作成処理等の業務処理)を実行するジョブネットワークである。
保留解除用の第3ジョブネットJ3は、後続のルートジョブネットの保留を解除させる多重起動管理用のネストジョブネットワークであり、保留解除ジョブJ31を含む。

0020

図3に示すように、第1サーバ10の障害発生時から、ジョブ実行スケジュール周期に基づいて、上流ファイルが遅延した回数分のルートジョブネット501〜507が生成される。例えば、実行サイクルが1日毎(日次)の場合、障害発生日(n日)から、順次、処理サイクルの世代毎に、ルートジョブネット501〜507が生成される。本実施形態では、最大7日(上限数)分のルートジョブネットを生成する場合を想定する。

0021

図1に示すジョブ定義記憶部23には、各ジョブの実行を管理するためのジョブ定義データが記録される。このジョブ定義データには、定義及び属性に関するデータが記録される。
定義データ領域には、ジョブ識別子、実行ファイル名、パラメータ入力ファイル識別子等に関するデータが記録される。ジョブ識別子は、各ジョブを特定するための識別子である。実行ファイル名は、このジョブとして実行されるスクリプトファイルを特定するための識別子である。パラメータは、実行結果の出力先を特定するための識別子である。入力ファイル識別子は、このジョブにおいて入力されるファイルを特定するための識別子である。

0022

属性データ領域には、保留要否を特定するためのフラグが含まれる。本実施形態では、第1ジョブネットJ1の保留用ダミージョブJ11,J12には「保留要」フラグが設定される。一方、第3ジョブネットJ3の保留解除ジョブJ31には、「保留不要」フラグが設定される。

0023

スケジュール定義記憶部24には、ジョブを実行するスケジュールデータが記録される。スケジュールルールにより、ジョブネットの生成タイミングが決定される。このスケジュールルールデータには、ジョブ識別子、開始日開始時刻、処理サイクルに関するデータが記録される。

0024

ジョブ識別子データ領域には、ジョブ(ルートジョブネット、ネストジョブネットを含む)を特定するための識別子に関するデータが記録される。
開始日データ領域には、ジョブ実行のスケジュールを開始する年月日に関するデータが記録される。

0025

開始時刻データ領域には、ジョブを実行する時刻に関するデータが記録される。この開始時刻により、上流ファイルの受信スケジュールが定められる。
処理サイクルデータ領域には、ジョブの実行について、サイクル実行の要否、周期、単位に関するデータが記録される。サイクル実行の要否は、周期的なジョブ実行の要否を特定するためのフラグである。周期は、ジョブを実行する間隔を特定するための数値である。例えば、最大7日の遅延に対応するために「1〜6日」を設定する。単位は、周期を構成する要素(例えば、暦日単位、運用日単位、休業日単位等)である。

0026

ステータス情報記憶部25には、ジョブの実行結果に関するステータスデータが記録される。このステータスデータには、ジョブ識別子、世代、状況、開始日時、終了日時に関するデータが記録される。
ジョブ識別子データ領域には、ジョブ(ルートジョブネット、ネストジョブネットを含む)を特定するための識別子に関するデータが記録される。

0027

世代データ領域には、処理サイクルにおける世代(例えば、n日分)を特定するための識別子に関するデータが記録される。
状況データ領域には、このジョブの実行状況を特定するための識別子に関するデータが記録される。
開始日時、終了日時の各データ領域には、このジョブの開始及び終了の年月日及び時刻に関するデータが記録される。

0028

(ジョブ生成管理処理)
次に、図4(a)を用いて、ジョブ生成管理処理を説明する。ここでは、第1サーバ10の障害等により、第2サーバ20において、上流ファイルの受信が、受信スケジュールよりも遅延している場合を想定する。

0029

まず、第2サーバ20の制御部21は、ジョブネット生成の要否判定処理を実行する(ステップS1−1)。具体的には、制御部21のジョブ生成部211は、システムタイマから現在日時を取得し、スケジュール定義記憶部24のスケジュールルールデータに記録された開始時刻を経過した業務処理用ジョブネットのジョブ識別子を特定する。ここで、業務処理用ジョブネットを実行するために必要な条件(上流ファイルの受信、先行ジョブネット実行済み)を満足していない場合には、ジョブネット生成が必要と判定する。なお、ジョブネット生成が必要でないと判定した場合には、ジョブ生成管理処理を終了する。

0030

ジョブネット生成が必要と判定した場合、第2サーバ20の制御部21は、上限日数分を生成済かどうかについての判定処理を実行する(ステップS1−2)。具体的には、制御部21のジョブ生成部211は、ジョブ生成時期が到来したジョブ識別子が設定された過去世代のルートジョブネットを、ジョブネット定義記憶部22において確認する。そして、上限日数(上限数)分の過去世代のルートジョブネット(復旧用ジョブネット)が登録されている場合には、上限日数分を生成済みと判定する。

0031

上限日数分を生成済でないと判定した場合(ステップS1−2において「NO」の場合)、第2サーバ20の制御部21は、先行ジョブに繋げたジョブ生成処理を実行する(ステップS1−3)。具体的には、制御部21のジョブ生成部211は、受信していない基準日の上流ファイルを待機する保留用ダミージョブJ11を含めた第1ジョブネットJ1を生成する。この第1ジョブネットJ1には、先行世代(先行基準日)の先行ジョブの第3ジョブネットJ3により多重起動管理される保留用ダミージョブJ12を含める。そして、第1ジョブネットJ1に繋げた第2ジョブネットJ2、第3ジョブネットJ3からなるルートジョブネットを生成し、ジョブネット定義記憶部22に登録する。

0032

一方、上限日数分を生成済と判定した場合(ステップS1−2において「YES」の場合)、第2サーバ20の制御部21は、先行ジョブに繋げたジョブ生成処理(ステップS1−3)をスキップして、ジョブ生成管理処理を終了する。

0033

(ジョブ実行管理処理)
次に、図4(b)を用いて、ジョブ実行管理処理を説明する。この処理は、ステータス情報記憶部25のステータスデータが変更された場合に、ルートジョブネット500について実行する。また、各ルートジョブネット500について、定期的に実行するようにしてもよい。
ここでは、第2サーバ20の制御部21は、受信ファイル保留解除かどうかについての判定処理を実行する(ステップS2−1)。具体的には、第1サーバ10から、所定基準日の上流ファイルを受信した場合、ジョブ実行部213は、ファイル識別子に対応した保留用ダミージョブJ11を実行し、ステータス情報記憶部25において、ジョブ識別子に関連付けて、状況データ領域に実行済みフラグを記録する。この場合、制御部21のジョブ管理部212は、ステータス情報記憶部25において、保留用ダミージョブJ11の状況を確認する。保留用ダミージョブJ11の実行済みフラグが記録されている場合には、受信ファイル保留解除と判定する。

0034

受信ファイル保留解除と判定した場合(ステップS2−1において「YES」の場合)、第2サーバ20の制御部21は、多重起動保留解除かどうかについての判定処理を実行する(ステップS2−2)。具体的には、ジョブ実行部213は、保留解除ジョブJ31を実行した場合、多重起動管理の保留用ダミージョブJ12を実行し、ステータス情報記憶部25において、ジョブ識別子に関連付けて、状況データ領域に実行済みフラグを記録する。この場合、制御部21のジョブ管理部212は、ステータス情報記憶部25において、保留用ダミージョブJ12が実行されているかどうかを確認する。多重起動管理用の保留用ダミージョブJ12が実行終了している場合には、多重起動保留解除と判定する。

0035

多重起動保留解除と判定した場合(ステップS2−2において「YES」の場合)、第2サーバ20の制御部21は、ジョブ実行処理を実行する(ステップS2−3)。具体的には、制御部21のジョブ管理部212は、ジョブ定義記憶部23に記録されたジョブのジョブ実行部213により、業務処理用の第2ジョブネットJ2の実行を指示する。そして、第2ジョブネットJ2の実行後に第3ジョブネットJ3を実行する。そして、ジョブ実行部213は、第2ジョブネットJ2によって生成された業務処理結果情報をクライアント端末30に出力する。

0036

受信ファイル保留解除でないと判定した場合、又は多重起動保留解除でないと判定した場合(ステップS2−1,S2−2において「NO」の場合)、サーバの制御部21は、ジョブ実行処理(ステップS2−3)をスキップしてジョブ実行管理処理を終了する。

0037

図5(a)に示すように、「n日」に、第1サーバ10に障害が発生し、上流ファイルを受信できない場合、ルートジョブネット501を生成する。
図5(b)に示すように、「(n+1)日」においても復旧しない場合、ルートジョブネット501に繋げたルートジョブネット502を生成する。

0038

そして、図5(c)に示すように、「(n+2)日」に復旧した場合、順次、各基準日の上流ファイルを受信する。この場合、障害が発生したn日〜(n+2)日分の上流ファイルを順番に受信すると限らず、n日分よりも(n+1)日分の上流ファイルを先に受信する場合もある。このため、世代順を維持するために、(n+2)日分のルートジョブネット503を生成する。

0039

図5(d)に示すように、「(n+3)日」において、(n+3)日分の上流ファイルを受信した場合にも、n日分、(n+2)日分の上流ファイルを受信していない場合、(n+3)日分のルートジョブネット504を生成する。

0040

図5(e)に示すように、「(n+6)日」において、n日分、(n+2)日分の上流ファイルを受信した場合、ルートジョブネット501〜504を順次、実行する。まだ、(n+4)日分のように、受信していない上流ファイルが残っている場合には、(n+5)日分のルートジョブネット506に繋げた基準日(n+6)日分のルートジョブネット507を生成する。

0041

以上、本実施形態によれば、以下のような効果を得ることができる。
(1)本実施形態によれば、第1サーバ10の障害等により、上流ファイルの受信が遅延している場合、先行のルートジョブネットに繋げたルートジョブネット500を生成する。これにより、ジョブの追い越し実行を抑制し、世代順のジョブ実行を維持しながら、業務処理ジョブを実行することができる。

0042

(2)本実施形態によれば、ルートジョブネット500の第1ジョブネットJ1は、第1サーバ10からの上流ファイルの受信を待機する保留用ダミージョブJ11や、先行ジョブの実行完了を待機する保留用ダミージョブJ12を含む。これにより、障害復旧時に、複数世代の上流ファイルを受信したり、世代順では異なる順番で受信したりした場合にも、世代順を維持しながら、業務処理ジョブを実行し、第2サーバ20のリカバリを行なうことができる。

0043

本実施形態は、以下のように変更して実施することができる。本実施形態及び以下の変更例は、技術的に矛盾しない範囲で互いに組み合わせて実施することができる。
・上記実施形態では、受信ファイル及び多重起動について保留解除されている場合には、業務処理用の第2ジョブネットJ2を実行する。これに加えて、障害発生時に、ジョブ実行の要否を判定するようにしてもよい。この場合、ジョブネット定義記憶部22に、ジョブ識別子に関連付けて、障害時実行条件を記録しておく。この障害時実行条件は、障害発生時にジョブの実行要否を判定する条件である。例えば、世代順に繋げた複数のルートジョブネットにおいて、最新世代のルートジョブネットを実行する場合には、過去世代のルートジョブネットは、実行せずに実行済扱いとする。

0044

図6(a)を用いて、ジョブ実行管理処理を説明する。
第2サーバ20の制御部21は、ステップS2−1,S2−2と同様に、保留解除かどうかについての判定処理(ステップS3−1)、多重起動保留解除かどうかについての判定処理(ステップS3−2)を実行する。

0045

ここで、受信ファイル保留解除でないと判定した場合、又は多重起動保留解除でないと判定した場合(ステップS3−1,S3−2において「NO」の場合)、第2サーバ20の制御部21は、ジョブ実行管理処理を終了する。
一方、受信ファイル保留解除かつ多重起動保留解除と判定した場合(ステップS3−1,S3−2において「YES」の場合)、第2サーバ20の制御部21は、実行対象かどうかについての判定処理を実行する(ステップS3−3)。具体的には、制御部21のジョブ管理部212は、ジョブ定義記憶部23において、実行条件を満たすかどうかを確認する。

0046

実行条件に基づいて実行対象と判定した場合(ステップS3−3において「YES」の場合)、第2サーバ20の制御部21は、ステップS2−3と同様に、ジョブ実行処理を実行する(ステップS3−4)。

0047

一方、実行対象でないと判定した場合(ステップS3−3において「NO」の場合)、第2サーバ20の制御部21は、実行済み登録処理を実行する(ステップS3−5)。具体的には、制御部21のジョブ管理部212は、実行対象でないルートジョブネットについては、ジョブ実行することなく、ステータス情報記憶部25に実行済みを記録する。

0048

例えば、図6(b)に示すように、基準日n日〜(n+2)日分の上流ファイルを第1サーバ10から同時期に取得した場合を想定する。この場合、n日〜(n+2)日分のルートジョブネット511〜513が実行可能となる。ここで、実行条件として「最新世代のみ実行」が設定されている場合には、n日、(n+1)日分のルートジョブネット511,512を実行済みに設定する。そして、(n+2)日のルートジョブネット513について保留解除されて、業務処理用の第2ジョブネットJ2を実行する。

0049

なお、実行条件は、「最新世代のみ実行」に限定されるものではない。例えば、遅延状況と実行時限との関係に基づいて、実行要否を判定するようにしてもよい。この場合には、ジョブネット定義記憶部22の実行条件として、実行時限を設定しておく。そして、実行時限に達していないルートジョブネットについては実行し、実行時限を経過したルートジョブネットについては実行済みとして取り扱う。これにより、遅れが小さいジョブを実行し、遅れが大きいジョブの実行をスキップすることができる。

0050

・上記実施形態では、受信ファイル及び多重起動について保留解除されている場合には、業務処理用の第2ジョブネットJ2を実行する。これに代えて、他のルートジョブネットとの関係に基づいて、実行する第2ジョブネットJ2を選択するようにしてもよい。この場合、ジョブネット定義記憶部22のジョブネット定義データに、ジョブ識別子に関連付けて障害時優先順位を記録しておく。更に、ステータス情報記憶部25において、保留解除されたジョブのジョブ識別子に関連付けてステータスデータの状況データ領域に実行可能フラグを記録する。

0051

図7を用いて、ジョブ実行管理処理を説明する。
ここでも、第2サーバ20の制御部21は、ステップS2−1,S2−2と同様に、受信ファイル保留解除かどうかについての判定処理(ステップS4−1)、多重起動保留解除かどうかについての判定処理(ステップS4−2)を実行する。

0052

ここで、受信ファイル保留解除でないと判定した場合、又は多重起動保留解除でないと判定した場合(ステップS4−1,S4−2において「NO」の場合)、第2サーバ20の制御部21は、ジョブ実行管理処理を終了する。
一方、受信ファイル保留解除かつ多重起動保留解除と判定した場合(ステップS4−1,S4−2において「YES」の場合)、第2サーバ20の制御部21は、実行可能ジョブの登録処理を実行する(ステップS4−3)。具体的には、制御部21のジョブ管理部212は、ステータス情報記憶部25に、ジョブ識別子に関連付けて、状況データ領域に実行可能フラグを記録する。

0053

そして、リソース管理処理を実行する。
ここでは、第2サーバ20の制御部21は、リソース確認処理を実行する(ステップS5−1)。具体的には、制御部21のジョブ管理部212は、ジョブ実行環境において使用可能なリソース状況を取得する。

0054

次に、第2サーバ20の制御部21は、リソースに空きがあるかどうかについての判定処理を実行する(ステップS5−2)。具体的には、制御部21のジョブ管理部212は、ジョブ実行環境において使用可能なリソースがある場合には、リソースに空きがあると判定する。

0055

リソースに空きがあると判定した場合(ステップS5−2において「YES」の場合)、第2サーバ20の制御部21は、実行待ちジョブ確認処理を実行する(ステップS5−3)。具体的には、制御部21のジョブ管理部212は、ステータス情報記憶部25において、実行可能フラグが記録されたジョブを検索する。

0056

次に、第2サーバ20の制御部21は、実行待ちジョブがあるかどうかについての判定処理を実行する(ステップS5−4)。具体的には、制御部21のジョブ管理部212は、ステータス情報記憶部25において、実行可能フラグが記録されたジョブを特定した場合には、実行待ちジョブがあると判定する。

0057

実行待ちジョブがあると判定した場合(ステップS5−4において「YES」の場合)、第2サーバ20の制御部21は、最優先ジョブ特定処理を実行する(ステップS5−5)。具体的には、制御部21のジョブ管理部212は、ジョブ定義記憶部23から、実行待ちジョブの障害時優先順位を取得する。そして、ジョブ管理部212は、障害時優先順位が最も高いジョブを特定する。

0058

次に、第2サーバ20の制御部21は、ジョブ実行処理を実行する(ステップS5−6)。具体的には、制御部21のジョブ管理部212は、特定した障害時優先順位が最も高いジョブを実行する。そして、リソース確認処理(ステップS5−1)に戻る。

0059

一方、リソースに空きがないと判定した場合や、実行待ちジョブがないと判定した場合(ステップS5−2,S5−4において「NO」の場合)、第2サーバ20の制御部21は、リソース確認処理(ステップS5−1)に戻る。
これにより、ジョブの優先度を考慮して、ジョブを実行することができる。

0060

・上記実施形態では、受信ファイル及び多重起動について保留解除されている場合には、業務処理用の第2ジョブネットJ2を実行する。これに加えて、リソースを調整するようにしてもよい。この場合、ジョブ定義記憶部23には、ジョブ識別子に関連付けて完了時限に関するデータを記録しておく。更に、ジョブ実行環境には、稼動系リソースと待機系リソースとを準備しておく。稼動系リソースは、ジョブ実行のために常時使用可能なリソースである。待機系リソースは、必要に応じてジョブ実行に割り当て可能な予備のリソースである。

0061

図8を用いて、リソース監視処理を説明する。
ここでは、第2サーバ20の制御部21は、リソース状況確認処理を実行する(ステップS6−1)。具体的には、制御部21のジョブ管理部212は、ジョブ実行環境において使用可能なリソース状況を取得する。

0062

次に、第2サーバ20の制御部21は、完了時限に間に合うかどうかについての判定処理を実行する(ステップS6−2)。具体的には、制御部21のジョブ管理部212は、リソース状況に基づいて、保留解除されたジョブの実行所要時間を算出する。例えば、単位リソース量において、単位データ量のジョブを実行した場合の単位所要時間を用いて、現在使用可能なリソース量、このジョブにおけるデータ量から実行所要時間を算出する。そして、ジョブ管理部212は、ジョブ定義記憶部23から、保留解除された各ジョブの完了時限を特定する。現在時刻に実行所要時間を加算した時刻が完了時限よりも前の場合には、完了時限に間に合うと判定する。

0063

完了時限に間に合うと判定した場合(ステップS6−2において「YES」の場合)、第2サーバ20の制御部21は、追加リソースがあるかどうかについての判定処理を実行する(ステップS6−3)。具体的には、制御部21のジョブ管理部212は、通常リソースに対して、追加された待機系リソースがある場合には追加リソースがあると判定する。

0064

ここで、追加リソースがないと判定した場合(ステップS6−3において「NO」の場合)、第2サーバ20の制御部21は、リソース状況確認処理(ステップS6−1)に戻る。
一方、追加リソースがあると判定した場合(ステップS6−3において「YES」の場合)、第2サーバ20の制御部21は、不必要な追加分の排除処理を実行する(ステップS6−4)。具体的には、制御部21のジョブ管理部212は、完了時限に間に合わせるための必要リソースを算出する。次に、ジョブ管理部212は、必要リソースを越えて追加された待機系リソースの割り当てを中止する。そして、リソース状況確認処理(ステップS6−1)に戻る。

0065

完了時限に間に合わないと判定した場合(ステップS6−2において「NO」の場合)、第2サーバ20の制御部21は、リソース必要量算出処理を実行する(ステップS6−5)。具体的には、制御部21のジョブ管理部212は、完了時限に間に合わせるための必要リソース量を算出する。

0066

次に、第2サーバ20の制御部21は、不足分の追加処理を実行する(ステップS6−6)。具体的には、制御部21のジョブ管理部212は、必要リソース量から、現在の割当リソースを差し引いて、不足分を算出する。次に、ジョブ管理部212は、不足分について、待機系リソースの割当依頼する。そして、リソース状況確認処理(ステップS6−1)に戻る。
これにより、完了時限を考慮して、必要なリソースを割り当てることができる。また、不必要な過大なリソースの割当を抑制することができる。

0067

・上記実施形態では、第2サーバ20の制御部21は、受信ファイル保留解除かどうかについての判定処理を実行する(ステップS2−1)。ここで、第1サーバ10から、同時期に複数のファイルを受信した場合、上流ファイルの種類に応じて、ジョブ実行部213に提供するようにしてもよい。この場合には、ファイル識別子に基づいて、世代順にファイルを特定する。例えば、上流ファイルの基準日が古い順番に並べ替える。そして、ルートジョブネットの世代順に、受信した上流ファイルをジョブ実行部213に提供する。これにより、ジョブの実行順番を考慮して、効率的に上流ファイルを提供することができる。

0068

・上記実施形態では、第2サーバ20の制御部21は、ジョブ実行処理を実行する(ステップS2−3)。この場合、ジョブ管理部212は、業務処理用の第2ジョブネットJ2によって生成された業務処理結果情報をクライアント端末30に出力する。ここで、出力された情報の確認処理を実行するようにしてもよい。この場合、第2サーバ20に通常出力記憶部を設ける。この通常出力記憶部には、障害が発生していない通常時に、業務処理用の第2ジョブネットJ2によって出力された業務処理結果情報をジョブ識別子に関連付けて記録しておく。

0069

図9を用いて、出力確認処理を説明する。この処理は、復旧時に、第2ジョブネットJ2の実行後に行なわれる。
ここでは、第2サーバ20の制御部21は、通常処理結果の取得処理を実行する(ステップS7−1)。具体的には、制御部21のジョブ管理部212は、障害発生前の業務処理結果情報を、通常出力記憶部から取得する。

0070

次に、第2サーバ20の制御部21は、復旧後処理結果の取得処理を実行する(ステップS7−2)。具体的には、制御部21のジョブ管理部212は、業務処理用の第2ジョブネットJ2によって生成された業務処理結果情報を取得する。

0071

次に、第2サーバ20の制御部21は、比較して差分の算出処理を実行する(ステップS7−3)。具体的には、制御部21のジョブ管理部212は、障害発生前の業務処理結果情報と、復旧後に取得した業務処理結果情報とを比較して、差分を算出する。

0072

次に、第2サーバ20の制御部21は、遅延期間変動幅予測処理を実行する(ステップS7−4)。具体的には、制御部21のジョブ管理部212は、障害による遅延期間の長さに応じて、業務処理結果情報の変動幅を算出する。ここでは、遅延期間が長い程、大きな変動幅を算出する変動幅算出情報関数やテーブル)を用いる。

0073

次に、第2サーバ20の制御部21は、許容範囲内かどうかについての判定処理を実行する(ステップS7−5)。具体的には、制御部21のジョブ管理部212は、算出した差分と変動幅とを比較する。差分が変動幅内に含まれる場合には、許容範囲内と判定する。

0074

許容範囲内でないと判定した場合(ステップS7−5において「NO」の場合)、第2サーバ20の制御部21は、アラーム処理を実行する(ステップS7−6)。具体的には、制御部21のジョブ管理部212は、クライアント端末30にアラームメッセージを出力する。この場合、担当者が、復旧後に取得した業務処理結果情報を確認し、必要に応じて業務処理結果情報の補正を行なう。

0075

一方、許容範囲内と判定した場合(ステップS7−5において「YES」の場合)、第2サーバ20の制御部21は、アラーム処理(ステップS7−6)をスキップして出力確認処理を終了する。

0076

10…第1サーバ、20…第2サーバ、21…制御部、211…ジョブ生成部、212…ジョブ管理部、213…ジョブ実行部、22…ジョブネット定義記憶部、23…ジョブ定義記憶部、24…スケジュール定義記憶部、25…ステータス情報記憶部、30…クライアント端末、500〜513…ルートジョブネット、J1…第1ジョブネット、J11,J12…保留用ダミージョブ、J2…第2ジョブネット、J3…第3ジョブネット、J31…保留解除ジョブ。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

該当するデータがありません

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

該当するデータがありません

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

この 技術と関連性が強い技術

該当するデータがありません

この 技術と関連性が強い法人

該当するデータがありません

この 技術と関連性が強い人物

該当するデータがありません

この 技術と関連する社会課題

該当するデータがありません

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ