JP2007164535A - 業務統合方法、業務統合装置、業務統合システムおよび業務統合プログラム - Google Patents

Abstract

【課題】複数のユーザが利用する共同利用型システムにおいて、ＥＡＩツールに対する定義変更の手間を低減し、システム運用負荷をより軽減する。
【解決手段】業務統合装置５は、業務システム３を利用する複数のユーザシステム１毎にデータの宛先が設定された宛先制御テーブルと、処理部とを有し、処理部は、業務システム各々からデータを受信する受信ステップと、受信ステップで受信した受信データの発生元のユーザシステムを特定し、特定したユーザシステムに対応する宛先を宛先制御テーブルから取得する取得ステップと、取得した宛先を受信データに設定した宛先設定データを生成する生成ステップと、宛先設定データに設定された宛先を参照し、受信データを少なくとも１つの業務システムに配信する配信ステップと、を行う。
【選択図】図１

Description

本発明は、複数の業務システムを統合する業務統合技術に関し、特に、複数の業務システム間でデータを連携させる技術に関する。

企業における情報システムには、一般的に、各業務に応じて勘定系システム、販売系システムなど複数の業務システムが存在する。ＥＡＩ（enterprise application integration）は、企業内で使用される複数の業務システムを連携させ、システム統合を行うための技術である。なお、ＥＡＩについては、例えば、非特許文献１および非特許文献２に記載されている。
八木晃二、藤岡賢治、"ハイブリットＥＡＩモデルの技術的検討"、［online］、2001年11月、野村総合研究所、システムマンスリー、［平成１７年１０月２０日検索］、インターネット＜ＵＲＬ：http://www.nri.co.jp/opinion/it_solution/2001/pdf/IT20011102.pdf＞ 角田勝、常峰誠、小林賢治、"ＥＡＩに関する基盤技術評価"、［online］、2002年、野村総合研究所、技術創発、［平成１７年１０月２０日検索］、インターネット＜ＵＲＬ： http://www.nri.co.jp/opinion/g_souhatsu/pdf/gs20020103.pdf＞

さて、複数のユーザが共同で利用する共同利用型システムにおいて、ＥＡＩを実現するＥＡＩツール（ミドルウェア）を用いる場合、以下の問題がある。すなわち、ユーザ毎にデータの接続先（連携先）の業務システムが異なる場合、ＥＡＩツールに対してユーザ毎にルーティング情報を定義する必要がある。また、ユーザの追加・削除あるいはユーザシステム側での変更が発生する度に、ＥＡＩツールに対してルーティング情報等の変更作業が発生する。

このようなＥＡＩツールに対する変更作業は、システム管理者の作業負荷が大きく、またシステム管理者の作業ミスなどによる人為的障害を誘発するおそれがある。

本発明は上記事情に鑑みてなされたものであり、本発明の目的は、複数のユーザが利用する共同利用型システムにおいて、ＥＡＩツールに対する定義変更の手間を低減し、システム運用負荷をより軽減することにある。

上記課題を解決するために、本発明では、例えば、複数の業務システムを統合する業務統合装置が行う業務統合方法であって、業務統合装置は、業務システムを利用する複数のユーザシステム毎にデータの宛先が設定された宛先制御テーブルと、処理部と、を有する。そして、処理部は、業務システム各々からデータを受信する受信ステップと、受信ステップで受信した受信データの発生元のユーザシステムを特定し、特定したユーザシステムに対応する宛先を宛先制御テーブルから取得する取得ステップと、取得した宛先を受信データに設定した宛先設定データを生成する生成ステップと、宛先設定データに設定された宛先を参照し、受信データを少なくとも１つの業務システムに配信する配信ステップと、を行う。

本発明では、複数のユーザが利用する共同利用型システムにおいて、ＥＡＩツールに対する定義変更の手間を低減し、システム運用負荷をより軽減することができる。

以下、本発明の実施の形態について説明する。

図１は、本発明の一実施形態が適用された業務統合システムの構成図である。本実施形態では、複数のユーザシステム１が、業務統合システムを共同利用するものとする。

業務統合システムは、複数の業務システム３とＥＡＩサーバ５とを有し、業務システム３各々とＥＡＩサーバ５とはＬＡＮなどのネットワーク９により接続されている。業務システム３は、各ユーザシステム１で発生した各種のデータを受け付け、ＥＡＩサーバ５に送信する。ＥＡＩサーバ５は、各業務システム３のデータを連携し、業務システム３を統合する。

業務システム３は、インターネットなどのネットワーク８により、複数のユーザシステム１と接続されている。本実施形態のユーザシステム１は、例えば、各種銀行、証券会社等の金融機関のシステムであるものとする。ユーザシステム１のユーザ端末１１は、ユーザが入力した取引データ（債券、株式、投信、為替など）を受け付け、受け付けた取引データを所定の業務システム３に送信する。なお、ユーザシステム１は、ＭＱ（message queueing）サーバ１２を用いて、ＭＱサーバ用の業務システム３に取引データを送信することとしてもよい。ＭＱサーバ１２は、メッセージキューイング方式により取引データを送信する。

図示する業務システム３各々は、業務処理部３１と、ＭＱ通信部３２と、を有する。業務処理部３１は、ユーザシステム１から受け付けた取引データの決済、レポート作成などの業務処理を行う。そして、業務処理部３１は、自業務システム以外の他業務システムに連携するデータを、ＭＱ通信部３２の送信キュー（不図示）に書き込む。

ＭＱ通信部３２は、図示しない送信キューおよび受信キューを有し、メッセージキューイング方式によりデータを送受信する。すなわち、ＭＱ通信部３２は、送信キューに書き込まれたデータを、メッセージキューイング方式によりＥＡＩサーバ５に送信する。また、ＭＱ通信部３２は、ＥＡＩサーバ５からのデータを、メッセージキューイング方式により受信キューに受信する。

ＥＡＩサーバ５は、データ配信部５１と、承認部５２と、照会部５３と、データ修正部５４と、ＭＱ通信部５５と、テーブル管理部５６と、宛先制御テーブル５７と、承認用データベース（以下、「承認用ＤＢ」）５８と、保存用データベース（以下、「保存用ＤＢ」）５９と、を有する。

データ配信部５１は、宛先制御テーブル５７を参照し、各業務システム３から受信したデータを、他の業務システム３に配信する。承認部５２は、承認用ＤＢ５８に記憶された承認対象データに対する承認指示を、ユーザ端末１１から受け付ける。照会部５３は、ユーザ端末１１の要求を受け付けて、保存用ＤＢ５９に記憶されたデータの処理状況（ステータス）をユーザ端末１１に提示する。データ修正部５４は、ユーザ端末１１から入力されたエラー修正指示を受け付けて、エラーデータを修正する。

ＭＱ通信部５５は、図示しない送信キューおよび受信キューを有し、メッセージキューイング方式によりデータを送受信する。すなわち、ＭＱ通信部５５は、送信キューに書き込まれたデータを、メッセージキューイング方式により各業務システム３に送信する。また、ＭＱ通信部５５は、各業務システム３からのデータを、メッセージキューイング方式により受信キューに受信する。テーブル管理部５６は、宛先制御テーブル５７を管理（メンテナンス）する。

宛先制御テーブル５７は、業務システム３から受信したデータの宛先（ルーティング情報）が設定されたテーブルである。なお、宛先制御テーブル５７については、後述する。承認用ＤＢ５８には、ユーザシステム１の管理者の承認が必要な承認対象データが記憶される。保存用ＤＢ５９には、各業務システム３から受信したデータおよび当該データの処理状況が記憶される。

上記説明したユーザ端末１１、ＭＱサーバ１２、業務システム３、および、ＥＡＩサーバ５は、いずれも、例えば図２に示すようなＣＰＵ９０１と、メモリ９０２と、ＨＤＤ等の外部記憶装置９０３と、キーボードやマウスなどの入力装置９０４と、ディスプレイやプリンタなどの出力装置９０５と、ネットワークと接続するための通信制御装置９０６と、を備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵ９０１がメモリ９０２上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。

例えば、業務システム３およびＥＡＩサーバ５の各機能は、業務システム３用のプログラムの場合は業務システム３のＣＰＵ９０１が、そして、ＥＡＩサーバ５用のプログラムの場合はＥＡＩサーバ５のＣＰＵ９０１が、それぞれ実行することにより実現される。なお、入力装置９０４および出力装置９０５については、各装置が必要に応じて備えるものとする。

次に、宛先制御テーブル５７について説明する。

図３は、宛先制御テーブル５７の一例を示す図である。図示する宛先制御テーブル５７は、ユーザＩＤ（会社コード）５７１と、トランザクションコード５７２と、配信先業務システム５７３と、上限金額５７４と、適用開始日５７５と、適用終了日５７６と、を有する。ユーザＩＤ５７１は、ユーザシステム１（例えば、金融機関などのシステム）を識別するための識別情報である。トランザクションコード５７２は、データの処理種別を示すコードである。配信先業務システム５７３には、業務システム名または業務システムコードが設定される。

上限金額５７４には、ユーザシステム１の管理者の承認を必要とする承認対象データか否かを判別するための金額が設定される。すなわち、ＥＡＩサーバ５は、取引金額が上限金額５７４を超えるデータについては、管理者の承認指示を受け付けた後に配信する。適用開始日５７５および適用終了日５７６には、当該レコードの適用を開始する年月日、および、適用を終了する年月日が設定される。宛先制御テーブル５７に適用開始日５７５を備えることにより、業務統合システムの利用を開始する新規ユーザのレコードを、実際の利用開始日より前に、あらかじめ宛先制御テーブル５７に登録することができる。また、宛先制御テーブル５７に適用終了日５７６を備えることにより、業務統合システムの利用を終了するユーザのレコードを、利用終了日当日に宛先制御テーブル５７から削除することなく、事前に更新することができる。

なお、テーブル管理部５６が、業務統合システムのシステム管理者の指示を受け付けて、宛先制御テーブル５７のレコードの追加、削除または変更などの更新処理を行う。

次に、ＥＡＩサーバ５が、各業務システム３から受信したデータを、所定の業務システム３に配信する配信処理について説明する。

図４は、ＥＡＩサーバ５の配信処理を模式的に示した図である。図示する例では、３つの業務システム３がＥＡＩサーバ５に接続されているものとする。各業務システム３の業務処理部３１は、所定の業務処理により生成したデータを、ＭＱ通信部３２の送信キュー３２１に書き込む。そして、ＭＱ通信部３２は、送信キュー３２１に書き込まれたデータを、ＥＡＩサーバ５の当該業務システム３に対応する受信キュー５５１に、メッセージキューイング方式により送信する（Ｓ１１）。

そして、ＥＡＩサーバ５のＭＱ通信部５５は、業務システム３が送信したデータを、当該業務システム３に対応する受信キュー５５１に受信する。そして、データ配信部５１は、各受信キュー５５１のデータを取り出す（Ｓ１２）。そして、データ配信部５１は、宛先制御テーブル５７を参照して、各受信キュー５５１から取り出したデータの配信先業務システム３を特定する。そして、データ配信部５１は、特定した配信先業務システムの送信キュー５５２に、Ｓ１２で取り出したデータを書き込む（Ｓ１３）。そして、ＭＱ通信部５５は、各送信キュー５５２に書き込まれたデータを、対応する業務システム３の受信キュー３２２に、メッセージキューイング方式により送信する（Ｓ１４）。

次に、ＥＡＩサーバ５の配信処理（図４：Ｓ１２〜Ｓ１４）について、さらに詳述する。

図５は、ＥＡＩサーバ５の配信処理のフローチャートである。また、図６は、後述する各データのデータフォーマットの一例を示したものである。

まず、図４で説明したように、各業務システム３が送信したデータが、ＥＡＩサーバ５のそれぞれの受信キュー５５１に受信される。そして、ＥＡＩサーバ５のデータ配信部５１は、受信キュー５５１のデータ（受信データ）を取り出す（Ｓ２１）。

図６（ａ）は、受信データのデータフォーマットの一例である。図示する受信データは、業務ヘッダ６１と、複数の業務データ項目を有する業務データ６２と、を有する。業務ヘッダ６１には、当該受信データの発生元であるユーザシステム１のユーザＩＤと、トランザクションコードとが含まれる。なお、業務システム３の送信キュー３２１に書き込まれるデータ（図４：Ｓ１１）は、図６（ａ）の受信データと同様である。

そして、ＥＡＩサーバ５のデータ配信部５１は、宛先制御テーブル５７を参照し、受信データの配信先を取得する（Ｓ２２）。すなわち、データ配信部５１は、受信データの業務ヘッダ６１に設定されたユーザＩＤおよびトランザクションコードを検索キーとして、宛先制御テーブル５７から対応する配信先業務システム（業務システム名、業務システムコードなど）を取得する。なお、データ配信部５１は、業務ヘッダ６１のユーザＩＤおよびトランザクションコードに対応する配信先業務システムが複数存在する場合、対応する全ての配信先業務システムを取得する。そして、データ配信部５１は、受信データに宛先情報を設定（付加）した宛先設定データを生成する（Ｓ２３）。

図６（ｂ）は、宛先設定データのデータフォーマットの一例を示す図である。宛先設定データは、業務ヘッダ６１と、宛先情報６３と、業務データ６２とを有する。図示する宛先情報６３には、ＥＡＩサーバ５に接続された全ての業務システム３の配信フラグが設定されている。データ配信部５１は、宛先制御テーブル５７から取得した業務システムに対応する配信フラグを例えば「１」に設定し、それ以外の業務システムの配信フラグには「０」または「スペース」を設定する。なお、業務システムと配信フラグとは、あらかじめ対応付けられているものとする。例えば、業務システムＡには配信フラグ１が、また、業務システムＢには配信フラグ２が、それぞれ対応付けられているものとする。

そして、データ配信部５１は、宛先設定データが、承認対象データが否かを判別する（Ｓ２４）。本実施形態では、例えば、所定の取引金額を超えるデータについては、承認対象データであると判別する。データ配信部５１は、宛先設定データの業務ヘッダに設定されたユーザＩＤおよびトランザクションコードを検索キーとして、宛先制御テーブル５７から対応する上限金額を取得する。そして、データ配信部５１は、宛先設定データの所定の業務データ項目に設定された取引金額と、取得した上限金額とを比較する。そして、取引金額が上限金額を超える場合、データ配信部５１は、承認対象データであると判別すする（Ｓ２４：ＹＥＳ）。一方、取引金額が上限金額と等しいか、または上限金額より小さい場合、データ配信部５１は、承認対象データではないと判別する。

なお、取引金額以外に、業務ヘッダに設定されたトランザクションコードを用いて承認対象データか否かを判別することとしてもよい。すなわち、データ配信部５１は、トランザクションコードが例えば「取消処理」など所定のコードの場合、承認対象データであると判別することとしてもよい。

また、データ配信部５１は、業務ヘッダに設定されたユーザＩＤと、所定の業務データ項目に設定された顧客コードとを用いて承認対象データか否かを判別することとしてもよい。すなわち、データ配信部５１は、新規に口座を開設した顧客コードとユーザＩＤとが設定された新規顧客リスト（不図示）を参照し、承認対象データであるか否かを判別することとしてもよい。

承認対象データでない場合（Ｓ２４：ＮＯ）、Ｓ２７に進む。一方、承認対象データの場合（Ｓ２４：ＹＥＳ）、データ配信部５１は、宛先設定データを承認用ＤＢ５８に記憶する（Ｓ２５）。そして、ユーザシステム１の管理者は、ユーザ端末１１を用いて承認用ＤＢ５８を参照し、当該承認用ＤＢ５８に記憶された自ユーザシステム１の宛先設定データを承認する。ＥＡＩサーバ５の承認部５２は、ユーザ端末１１の承認指示を受け付けると、承認された宛先設定データをデータ配信部５１に送出する（Ｓ２６）。

そして、データ配信部５１は、宛先設定データの宛先情報を参照し、送信フラグに「１」が設定されている配信先業務システムを特定する。そして、データ配信部５１は、宛先設定データから宛先情報を削除した受信データ（図６（ａ）参照）を複製し、複製した受信データを配信先業務システムの各送信キューにそれぞれ書き込む（Ｓ２７）。なお、データ配信部５１は、受信データを各送信キューに書き込む際に、配信先業務システムの仕様に応じて、受信データのデータフォーマットを変換することとしてもよい。そして、ＭＱ通信部５５は、各送信キューに書き込まれた受信データを、対応する業務システム３の受信キューに、メッセージキューイング方式により送信する（Ｓ２８）。

次に、ＥＡＩサーバ５の照会処理について説明する。

ＥＡＩサーバ５のデータ配信部５１は、各受信キューから受信データを取り出す際に（図５：Ｓ２１）、当該受信データを保存用ＤＢ５９に蓄積する。そして、データ配信部５１は、所定のタイミングで、保存用ＤＢ５９に蓄積された受信データの処理状況（ステータス）を設定する。

例えば、データ配信部５１は、承認用ＤＢ５８に宛先設定データを記憶した後（図５：Ｓ２５）、保存用ＤＢ５９に蓄積された対応する受信データの処理状況を「承認待ち」に更新する。また、データ配信部５１は、所定の業務システム３に受信データを配信した後（図５：Ｓ２８）、保存用ＤＢ５９に蓄積された対応する受信データの処理状況を「業務システムに送信済み」に更新する。

そして、照会部５３は、ユーザシステム１のユーザ端末１１からの照会要求を受け付けて、保存用ＤＢ５９から所望の受信データの処理状況を取得し、要求元のユーザ端末１１に送信する。これにより、ユーザシステム１の管理者は、ＥＡＩサーバ５にアクセスすることで、いずれかの業務システム３に送信した全てのデータの処理状況を把握することができる。

次に、ＥＡＩサーバ５のエラー修正処理について説明する。

ＥＡＩサーバ５が配信したデータにエラーが存在する場合、配信先の業務システム３は、エラーメッセージをＥＡＩサーバ５に送信する。ＥＡＩサーバ５のデータ修正部５４は、エラーメッセージを受け付けると、保存用ＤＢ５９に蓄積された対応する受信データの処理状況を「エラー」に更新する。そして、データ修正部５４は、ユーザ端末１１からのエラー訂正要求を受け付けて、処理状況が「エラー」の受信データを保存用ＤＢ５９から抽出し、要求元のユーザ端末１１に出力する。そして、データ修正部５４は、ユーザ端末１１の指示を受け付けて、受信データを修正する。そして、データ修正部５４は、修正後の受信データを、データ配信部５１に送出する。これにより、データ配信部５１は、図５の配信処理を行い、再度、受信データを所定の業務システム３に配信する。これにより、ＥＡＩサーバ５は、エラー修正後の受信データを、業務システム３に再送することができる。

本実施形態のＥＡＩサーバ５は、ユーザおよびトランザクションコード毎にデータの宛先が設定された宛先制御テーブル５７を有する。これにより、ユーザ毎にデータの配信先が異なる場合であっても、複数のデータ配信部５１を備える必要がない。また、データ配信部５１に対してユーザ毎にデータの宛先情報を定義する必要がない。すなわち、宛先制御テーブル５７を変更するだけでユーザの追加・削除あるいは配信先の変更に柔軟に対応できるため、システム運用負荷をより軽減することができる。

また、本実施形態のＥＡＩサーバ５は、承認対象データか否かを判別し、承認対象データについては承認用ＤＢ５８に一旦、保存する。これにより、ユーザシステム１からの承認指示を受け付けたタイミングで、承認対象データを各業務システム３に配信することができる。

なお、本発明は上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。例えば、上記実施形態では、複数のユーザが共同利用する業務統合システムを例に説明した。しかしながら、本発明を企業内で利用する業務統合システムに適用することとしてもよい。すなわち、債券、株式、投信、為替など金融商品毎に、データの配信先が異なる場合がある。この場合、ＥＡＩサーバ５は、金融商品毎にデータの宛先を設定した宛先制御テーブルを備える。これによりＥＡＩサーバ５は、金融商品毎にデータを柔軟に配信することができる。

本発明の一実施形態が適用された業務統合システムの構成図である。 各装置のハードウェア構成例を示す図である。 宛先制御テーブルの一例を示す図である。 ＥＡＩサーバの配信処理を模式的に示した図である。 ＥＡＩサーバの配信処理のフローチャートである。 データフォーマットの一例を示す図である。

符号の説明

１：ユーザシステム、１１：ユーザ端末、１２：ＭＱサーバ、３：業務システム、３１業務処理部、３２：ＭＱ通信部、５：ＥＡＩサーバ、５１：データ配信部、５２：承認部、５３：照会部、５４：データ修正部、５５：ＭＱ通信部、５６：テーブル管理部、５７：宛先制御テーブル、５８：承認用ＤＢ、５９：保存用ＤＢ、８：ネットワーク、９：ネットワーク

Claims (5)

1. 複数の業務システムを統合する業務統合装置が行う業務統合方法であって、
   前記業務統合装置は、
   前記業務システムを利用する複数のユーザシステム毎にデータの宛先が設定された宛先制御テーブルと、処理部と、を有し、
   前記処理部は、
   前記業務システム各々からデータを受信する受信ステップと、
   前記受信ステップで受信した受信データの発生元のユーザシステムを特定し、特定したユーザシステムに対応する宛先を前記宛先制御テーブルから取得する取得ステップと、
   前記取得した宛先を前記受信データに設定した宛先設定データを生成する生成ステップと、
   前記宛先設定データに設定された宛先を参照し、前記受信データを少なくとも１つの業務システムに配信する配信ステップと、を行うこと
   を特徴とする業務統合方法。
2. 請求項１記載の業務統合方法であって、
   前記業務統合装置は、
   前記ユーザシステムの承認が必要なデータを記憶する承認用記憶部を、さらに有し、
   前記処理部は、
   前記宛先設定データが前記ユーザシステムの承認が必要か否かを判別し、承認が必要な場合、前記承認用記憶部に当該宛先設定データを記憶する判別ステップと、
   前記承認用記憶部に記憶された宛先設定データに対する承認指示を受け付ける承認受付ステップと、をさらに行い、
   前記配信ステップは、前記承認指示を受け付けた宛先設定データを前記承認用記憶部から読み出し、当該宛先設定データに設定された宛先を参照して前記受信データを少なくとも１つの業務システムに配信すること
   を特徴とする業務統合方法。
3. 複数の業務システムを統合する業務統合装置であって、
   前記業務システムを利用する複数のユーザシステム毎に、データの宛先が設定された宛先制御テーブルと、
   前記業務システム各々からデータを受信する受信手段と、
   前記受信手段が受信した受信データの発生元のユーザシステムを特定し、特定したユーザシステムに対応する宛先を前記宛先制御テーブルから取得する取得手段と、
   前記取得した宛先を前記受信データに設定した宛先設定データを生成する生成手段と、
   前記宛先設定データに設定された宛先を参照し、前記受信データを少なくとも１つの業務システムに配信する配信手段と、を有すること
   を特徴とする業務統合装置。
4. 複数の業務システムと、当該複数の業務システムを統合する業務統合装置と、を有する業務統合システムであって、
   前記業務システム各々は、
   複数のユーザシステムで発生したデータを、前記業務統合装置に送信する送信手段と、
   前記業務統合装置から配信されたデータを受信する受信手段と、を有し、
   前記業務統合装置は、
   前記ユーザシステム毎に、データの宛先が設定された宛先制御テーブルと、
   前記業務システム各々が送信したデータを受信する受信手段と、
   前記受信手段が受信した受信データの発生元のユーザシステムを特定し、特定したユーザシステムに対応する宛先を前記宛先制御テーブルから取得する取得手段と、
   前記取得した宛先を前記受信データに設定した宛先設定データを生成する生成手段と、
   前記宛先設定データに設定された宛先を参照し、前記受信データを少なくとも１つの業務システムに配信する配信手段と、を有すること
   を特徴とする業務統合システム。
5. 複数の業務システムを統合する業務統合装置が実行する業務統合プログラムであって、
   前記業務統合装置は、
   前記業務システムを利用する複数のユーザシステム毎にデータの宛先が設定された宛先制御テーブルと、処理部と、を有し、
   前記処理部に、
   前記業務システム各々からデータを受信する受信ステップと、
   前記受信ステップで受信した受信データの発生元のユーザシステムを特定し、特定したユーザシステムに対応する宛先を前記宛先制御テーブルから取得する取得ステップと、
   前記取得した宛先を前記受信データに設定した宛先設定データを生成する生成ステップと、
   前記宛先設定データに設定された宛先を参照し、前記受信データを少なくとも１つの業務システムに配信する配信ステップと、を実行させること
   を特徴とする業務統合プログラム。
   

Images