JP2018124598A - サービス支援システム、サービス支援方法及びサービス支援プログラム - Google Patents

Abstract

【課題】複数の環境により構成されたシステムにおいて、効率的にサービスを行なうためのサービス支援システム、サービス支援方法及びサービス支援プログラムを提供する。【解決手段】サービス支援システムは、第１システム環境で構成された共通システム２０及び第２システム環境で構成されたプロダクト層３０を含む。プロダクト層３０が、共通システム２０から要求電文を取得し、コンポジットコントロール３２に対する要求電文を取得した場合には、コンポジットコントロール３２に関連付けられた商品サービスコントロール３１を順次、呼び出してサービス処理を実行し、実行結果を共通システム２０に返信し、個別の商品サービスコントロール３１に対する要求電文を取得した場合には、商品サービスコントロール３１を呼び出してサービス処理を実行し、実行結果を共通システム２０に返信する。【選択図】図１

Description

本発明は、複数の環境により構成されたシステムにおいて、サービスを行なうためのサービス支援システム、サービス支援方法及びサービス支援プログラムに関する。

コンピュータシステムにおいて、複数のプロセスを連携させて、一つの業務処理を行なうことがある（例えば、特許文献１参照。）。この文献に記載のシステムにおいては、送信した電文に対して「通信エラー」の戻り電文を受信した場合、制御部は迂回回数を加算し、迂回回数が基準値を超えていない間、再送信する。このようなシステムは、複数の商品サービスを連携させて、顧客との間で行なわれる取引サービス等に用いられる。

そこで、複数のプロセスを連携して依頼処理を実行する場合に、タイムアウトを早期に検知するためのタイムアウト監視システムも検討されている（例えば、特許文献２を参照。）。この文献に記載された技術においては、プロセス装置のタイマ監視部は、取引要求を特定し、取引要求に応じてタイマ値を特定する。このプロセス装置は、タイマ値を含めた電文を後続の各プロセス装置に送信するとともに、タイマ監視部は、イベント監視処理を実行する。タイマ監視部は、正常完了又はタイムアウトを判定し、タイムアウトと判定した場合には、タイムアウト報告処理を実行する。

特開２００９−２３７７８９号公報 特開２０１２−１３８０１５号公報

ところで、サービス支援システムが、複数のシステム環境から構成されている場合がある。このように、異なる複数のシステム環境における業務システムを連携させる場合には、システム環境に応じた電文変換（例えば、文字コード変換等）を行なう必要があり、要求電文や応答電文の送信時のオーバーヘッドが大きくなることがある。このようなシステムにおいては、システム負荷が大きくなり、迅速な対応が困難になる可能性がある。

本発明は、上記課題を解決するためになされたものであり、その目的は、複数の環境により構成されたシステムにおいて、効率的にサービスを行なうためのサービス支援システム、サービス支援方法及びサービス支援プログラムを提供することにある。

・上記課題を解決するサービス支援システムでは、第１システム環境で構成された第１システム及び第２システム環境で構成された第２システムを含む。そして、前記第２システムにおいて、複数のサービス機能部と、複数のサービス機能部を呼び出すコンポジット部とを設け、前記第２システムが、前記第１システムから要求電文を取得し、前記コンポジット部に対する要求電文を取得した場合には、前記コンポジット部に関連付けられたサービス機能部を順次、呼び出してサービス処理を実行し、実行結果を前記第１システムに返信し、個別のサービス機能部に対する要求電文を取得した場合には、前記サービス機能部を呼び出してサービス処理を実行し、実行結果を前記第１システムに返信する。これにより、複数のサービスをコンポジット化することにより、システム環境が異なる複数のシステムにおいて、効率的にサービスを提供することができる。

・上記サービス支援システムにおいて、コンポジット部に対する要求電文を取得した場合、要求電文に関連するデータベースの排他制御を実行し、前記要求電文に関わるサービス処理においては、サービス処理を許容し、前記要求電文に関わるすべてのサービス処理の終了後に前記排他制御を終了することが好ましい。これにより、同じコンポジットサービスに関連する個別サービスは排他制御されることなく、データ更新を行なうことができる。

・上記サービス支援システムにおいて、前記第１システム環境と前記第２システム環境とは、オペレーションシステムが異なることが好ましい。これにより、オペレーションシステムが異なる場合にも、効率的にサービスを提供することができる。

・上記サービス支援システムにおいて、前記第１システム環境と前記第２システム環境とは、文字コード体系が異なることが好ましい。これにより、文字コードが異なる場合にも、効率的にサービスを提供することができる。

本発明によれば、複数の環境により構成されたシステムにおいて、効率的にサービスを行なうことができる。

本実施形態のシステム概略図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図であって、（ａ）は単独サービス、（ｂ）はコンポジットサービスの説明図。 他の実施形態の処理手順の説明図。

以下、本発明を具体化した実施形態を図１〜図５に従って説明する。本実施形態では、金融機関における各商品を管理する複数の業務システム（商品管理システム）を接続するサービス支援システムを説明する。このサービス支援システムは、ハブ＆スポーク方式で構築されており、ハブシステムに繋がる業務システムがスポークシステムとして機能する。ハブシステムは、電文のあて先への振り分けやトランザクション処理の制御等を行なう。本実施形態では、ハブシステムは、企業の基幹業務システムなどに用いられる汎用コンピュータシステム（メインフレーム）中心の基幹系システム（第１システム環境）であり、業務システムは、オープン系システム（第２システム環境）で構成する場合を想定する。このため、ハブシステムは、異なるシステム環境（ＯＳ、文字コード等）に応じたプロトコルの変換を行なう。

図１を用いて、サービス支援システムの概要を説明する。サービス支援システムは、チャネル層１０、第１システムとしての共通システム２０、第２システムとしてのプロダクト層３０から構成される。

チャネル層１０は、店舗端末や現金自動預払機（ＡＴＭ）、インターネットバンキングサーバ等、顧客との取引を受け付けるシステムである。
共通システム２０は、顧客との取引において共通的に行なわれる処理（共通業務）を管理するコンピュータシステムである。この共通システム２０は、メインフレームにより構成され、共通業務としては、例えば、行内勘定、顧客番号、手数料等の管理を行なう。この共通システム２０は、後述するプロダクト層３０の各サービス（商品サービスやコンポジットサービス）を呼び出すためのフロー定義テーブルを保持している。このフロー定義テーブルにおいては、取引種別に対応して、呼び出すサービスが登録されている。

プロダクト層３０は、金融機関が提供する各商品（融資、外国為替、信託、定期性預金等）を、それぞれ管理するコンピュータシステムである。このプロダクト層３０は、オープン環境システムからなる商品サービスコントロール３１により構成される。一つの商品（例えば、外国為替）のためには、複数の商品サービス（例えば、画面入力、外貨計算、チェック、データベース書込等）を利用する。このため、一つの商品サービスコントロール３１においては、各商品のための商品サービスＡ（例えば、外貨計算）を管理する。また、他の商品サービスコントロール３１においては、商品サービスＢ（例えば、データベース書込）を管理する。

また、一つの取引が、複数の商品に関連する場合がある。この場合には、チャネル層１０から取得した一つの取引要求電文に対して、複数の商品サービスコントロール３１を用いる。このように複数の商品サービスを利用するコンポジットサービスのために、プロダクト層３０には、コンポジットコントロール３２を設けておく。このコンポジットコントロール３２は、サービス支援プログラムを実行することにより起動されて、各商品サービスを呼び出す。この場合、予め定められた順番で各商品サービスを呼び出して、複数の商品サービスを連携させる。

本実施形態では、チャネル層１０から取引要求電文を取得した共通システム２０が、プロダクト層３０のサービスを呼び出す場合を想定する。ここで、個別の商品サービスを呼び出す場合には、プロダクト層３０において、目的の商品サービスコントロール３１に対して要求電文を送信する。この場合には、共通システム２０は、プロダクト層３０において利用可能なプロトコルを用いて要求電文を送信する。

一方、プロダクト層３０において、コンポジットサービスを利用する場合には、共通システム２０は、このコンポジットコントロール３２に要求電文を送信する。この場合、共通システム２０は、コンポジットコントロール３２に対して、プロダクト層３０において利用可能なプロトコルを用いて要求電文を送信する。このコンポジットコントロール３２は、コンポジットサービスにおいて利用する各商品サービス及びサービス実行順番を記憶している。例えば、商品サービスＡ〜Ｃを取りまとめたコンポジットコントロール３２は、同じプロダクト層３０のシステム環境において、各商品サービスＡ〜Ｃの商品サービスコントロール３１を、予め記憶された順番で呼び出す。

更に、プロダクト層３０には、各商品サービスを実現するためのデータを記憶するデータベース装置３５を備える。データベース装置３５は、複数の商品サービスコントロール３１が同じデータを同時に利用することがないように、ある商品サービスコントロール３１がデータを利用している間、別の商品サービスコントロール３１による同じデータの利用を制限する排他制御を行なう。

次に、図２を用いて、第１システム環境で構成された共通システム２０が、第２システム環境で構成されたプロダクト層３０の商品サービスを利用して、取引サービスを実行する場合を説明する。

まず、共通システム２０は、要求電文の送信処理を実行する（ステップＳ１−１）。具体的には、顧客との間で取引が行なわれた場合、チャネル層１０から共通システム２０に取引要求電文が送信される。チャネル層１０から取引要求電文を受信した共通システム２０は、取引要求電文の取引内容に基づいて、処理の要求電文をプロダクト層３０に送信する。この場合、共通システム２０は、取引要求電文の取引種別に基づいて、フロー定義テーブルを用いて、呼び出すサービスを特定する。そして、このサービスのサービス識別子を要求電文に設定する。

そして、プロダクト層３０は、共通システム２０からの要求電文の取得処理を実行する（ステップＳ１−２）。この場合、コンポジットサービス又は単独の商品サービスによって処理が異なる。

「単独サービス」が呼び出された場合、プロダクト層３０は、商品サービス処理を実行する（ステップＳ１−３）。そして、この商品サービスコントロール３１は、商品サービス番号を用いて、商品サービス要求に応じた処理を実行する。

商品サービス処理を完了した場合、プロダクト層３０の商品サービスコントロール３１は、応答電文の返送処理を実行する（ステップＳ１−８）。具体的には、商品サービスコントロール３１は、商品サービス要求電文に対応する応答電文を共通システム２０に返信する。この応答電文には、商品サービスの処理結果を含める。

一方、「コンポジット」が呼び出された場合、プロダクト層３０のコンポジットコントロール３２は、商品サービスの特定処理を実行する（ステップＳ１−４）。コンポジットコントロール３２は、コンポジットサービスを構成する商品サービスを特定する。

次に、プロダクト層３０のコンポジットコントロール３２は、商品サービスの呼出処理を実行する（ステップＳ１−５）。具体的には、コンポジットコントロール３２は、特定した商品サービスコントロール３１に対して、コンポジット番号を用いて、商品サービス要求を行なう。

この場合、商品サービスコントロール３１は、商品サービス処理を実行する（ステップＳ１−６）。この商品サービスコントロール３１は、コンポジット番号を用いて、商品サービス要求に応じた処理を実行する。この場合、コンポジットコントロール３２は、終了した商品サービスを仮記録する。

そして、プロダクト層３０のコンポジットコントロール３２は、すべてのサービスを終了したかどうかについての判定処理を実行する（ステップＳ１−７）。具体的には、コンポジットコントロール３２は、コンポジットサービスを構成するすべての商品サービスについての処理を終了したかどうかを判定する。

すべての商品サービスを終了していないと判定した場合（ステップＳ１−７において「ＮＯ」の場合）、プロダクト層３０のコンポジットコントロール３２は、未処理の商品サービスの呼出処理を実行する（ステップＳ１−５）。

一方、すべてのサービスを終了したと判定した場合（ステップＳ１−７において「ＹＥＳ」の場合）、プロダクト層３０のコンポジットコントロール３２は、応答電文の返送処理を実行する（ステップＳ１−８）。

そして、共通システム２０は、応答電文の取得処理を実行する（ステップＳ１−９）。具体的には、共通システム２０は、プロダクト層３０から、処理結果が含まれる応答電文を取得する。この場合、チャネル層１０から取得した取引サービス要求電文に対応する商品サービスを終了したかどうかを判定する。未処理の商品サービスが残っている場合には、共通システム２０は、プロダクト層３０に対して、未処理のサービス要求電文を送信する。一方、すべての商品サービスを終了した場合には、共通システム２０は、チャネル層１０に対して、取引サービスの応答電文を返信する。

次に、図３を用いて、コンポジットサービスを利用する場合の処理を詳述する。
まず、コンポジットコントロール３２は、前処理を実行する（ステップＳ２−１）。この前処理においては、商品サービス情報チェック、サービス閉塞チェック、明細閉塞チェック、取引ステータスチェック、排他制御、ジャーナル設定の各処理を実行する。

商品サービス情報チェックは、コンポジットサービスを構成する商品サービスを確認する処理である。
サービス閉塞チェックは、特定した商品サービスの稼働状況を確認する処理である。例えば、サービス提供時間外やシステムのメンテナンスによりサービス提供が停止されていないかどうかを確認する。

明細閉塞チェックは、取引サービス要求電文の対象（例えば、口座）の状況を確認する処理である。
取引ステータスチェックは、取引の状況を確認する処理である。
排他制御は、サービスに用いるデータベース装置３５の記憶エリアについての排他制御を行なう処理である。
ジャーナル設定は、サービス提供履歴を記録する領域を確保する処理である。

そして、コンポジットコントロール３２は、主処理を実行する（ステップＳ２−２）。ここでは、コンポジットサービスに必要な商品サービスと、各商品サービスの処理順序を特定する。

次に、コンポジットコントロール３２は、呼出処理を実行する（ステップＳ２−３）。ここでは、コンポジットコントロール３２は、コンポジットサービスにおいて、予め定められた各商品サービスコントロール３１を呼び出す。

この場合、商品サービスコントロール３１は、前処理を実行する（ステップＳ３−１）。この前処理においては、商品サービス情報チェック、コンポジット番号取得、コンテキスト情報登録、ジャーナル設定の各処理を実行する。

商品サービス情報チェックは、処理対象の商品サービスを確認する処理である。
コンポジット番号取得は、コンポジットコントロール３２から取得した要求電文に含まれるコンポジット番号を取得する処理である。
コンテキスト情報登録は、商品サービスに用いる引数等のコンテキスト情報を仮記憶する処理である。
ジャーナル設定は、サービス提供履歴を記録する領域を確保する処理である。

そして、商品サービスコントロール３１は、主処理を実行する（ステップＳ３−２）。ここでは、商品サービスコントロール３１は、商品サービス処理を実行する。

次に、商品サービスコントロール３１は、呼出処理を実行する（ステップＳ３−３）。具体的には、商品サービスコントロール３１は、要求電文に基づいてデータベース装置３５を更新する。この場合、商品サービスコントロール３１は、コンポジットコントロール３２から取得したコンポジット番号を用いて、データベース装置３５にアクセスする。

そして、商品サービスコントロール３１は、後処理を実行する（ステップＳ３−４）。この後処理においては、ジャーナル情報登録、コンテキストサブ情報クリアの各処理を実行する。

ジャーナル情報登録は、サービス提供履歴を記録する処理である。
コンテキストサブ情報クリアは、コンポジットサービスに用いたコンテキスト情報を削除する処理である。

次に、すべての商品サービスを終了した場合、コンポジットコントロール３２は、後処理を実行する（ステップＳ２−４）。この後処理においては、楽観的排他制御、コンテキスト情報クリアの各処理を実行する。
楽観的排他制御は、自身の排他制御が継続している場合には、データ更新を可能にする制御を行なう処理である。
コンテキスト情報クリアは、商品サービスに用いたコンテキスト情報を削除する処理である。

次に、図４を用いて、データベース装置３５における排他制御を説明する。
図４（ａ）は、単独の商品サービスにおける処理の説明図である。
ここでは、商品サービスコントロール３１において、商品サービスの前処理（ステップＳ４−１）が実行された場合、データベース装置３５は、この商品サービスのために、ロック処理を実行する（ステップＳ４−２）。この場合、データベース装置３５は、サービス要求に記録されている商品サービス番号を用いて排他制御を行なう。そして、この商品サービス番号以外の商品サービスコントロール３１やコンポジットコントロール３２のアクセスを排除する。一方、同じ商品サービス番号の商品サービスコントロール３１によるアクセス（ステップＳ４−３）の場合、データベース装置３５は、データ更新を許容する。

そして、商品サービスコントロール３１において、商品サービスの後処理（ステップＳ４−４）が実行された場合、データベース装置３５は、ロック解除処理を実行する（ステップＳ４−５）。

一方、図４（ｂ）は、コンポジットサービスにおける処理の説明図である。
コンポジットコントロール３２において、前処理（ステップＳ５−１）が実行された場合、データベース装置３５は、このコンポジットサービスのために、ロック処理を実行する（ステップＳ５−２）。この場合、データベース装置３５は、サービス要求に記録されているコンポジット番号を用いて排他制御を行なう。そして、このコンポジット番号以外の商品サービスコントロール３１やコンポジットコントロール３２によるアクセスの排他制御を行なう。

そして、コンポジットコントロール３２において、一つの商品サービスを呼び出した場合（ステップＳ５−３）、データベース装置３５は、このコンポジットコントロール３２から呼び出された各商品サービスコントロール３１のデータ更新を許容する。この場合、商品サービスコントロール３１は、コンポジット番号を用いて、データベース装置３５にアクセスする。そして、データベース装置３５は、同じコンポジット番号を用いる商品サービスコントロール３１からのアクセスによるデータ更新を許容する。

そして、コンポジットコントロール３２において、他の商品サービスを呼び出した場合（ステップＳ５−４）も、データベース装置３５は、同じコンポジットコントロール３２から呼び出された商品サービスコントロール３１のデータ更新を許容する。この場合も、商品サービスコントロール３１は、コンポジット番号を用いて、データベース装置３５にアクセスする。そして、他の商品サービスコントロール３１からのアクセスであっても、データベース装置３５は、ロック時と同じコンポジット番号を用いる限り、データ更新を許容する。

そして、すべての商品サービスを終了した場合、コンポジットコントロール３２は後処理を実行する（ステップＳ５−５）。この場合、データベース装置３５は、ロック解除処理を実行する（ステップＳ５−６）

以上、本実施形態によれば、以下に示す効果を得ることができる。
（１）本実施形態では、コンポジットサービスを利用する場合には、共通システム２０は、コンポジットコントロール３２に要求電文を送信する。この場合、共通システム２０は、コンポジットコントロール３２に対して、プロダクト層３０において利用可能なプロトコルを用いて要求電文を送信する。ここで、共通システム２０におけるシステム環境と、プロダクト層３０におけるシステム環境とが異なる場合、共通システム２０がプロダクト層３０の複数の商品サービスを個別に呼び出すことになると、環境の違いによる処理負荷が大きくなる。そこで、本実施形態のように、コンポジットサービスを利用することにより、複数の商品サービスをまとめて、効率的に処理を行なうことができる。

（２）本実施形態では、コンポジットコントロール３２は、前処理を実行する（ステップＳ２−１）。この前処理においては、商品サービス情報チェック、サービス閉塞チェック、明細閉塞チェック、取引ステータスチェック、排他制御、ジャーナル設定の各処理を実行する。これにより、複数の商品サービスを利用する場合の環境を整えることができる。

（３）本実施形態では、コンポジットコントロール３２において、前処理（ステップＳ５−１）が実行された場合、データベース装置３５は、このコンポジットサービスのために、ロック処理を実行する（ステップＳ５−２）。そして、コンポジットコントロール３２において、一つの商品サービスを呼び出した場合（ステップＳ５−３，Ｓ５−４）、データベース装置３５は、このコンポジットコントロール３２から呼び出された各商品サービスコントロール３１のデータ更新を許容する。これにより、共通のコンポジットサービスに含まれる複数の商品サービスは、排他制御されることなく、データベース更新を行なうことができる。

なお、上記実施形態は、以下の態様に変更してもよい。
・上記実施形態では、サービス支援システムは、ハブ＆スポーク方式で構築された共通システム２０、プロダクト層３０から構成される。サービス支援システムは、複数のシステム環境により構成されたシステムであれば、前述の形態に限定されるものではない。そして、本発明は、高速レスポンス及び安定性、安全性を求められるオンラインシステムにも適用できる。

・上記実施形態では、コンポジットサービスにおいて、複数の商品サービスを呼び出すように構成した。ここで、コンポジットサービスが、他のコンポジットサービスを呼び出すようにしてもよい。更に、一つの取引サービスにおいて、複数のコンポジットサービスを呼び出すようにしてもよい。

・上記実施形態では、複数の商品サービスを利用するコンポジットサービスのために、コンポジットコントロール３２を設ける。ここで、サービスの設計支援装置を用いて、コンポジットサービスの実装要否を判定するようにしてもよい。この設計支援装置には、過去の取引履歴を記録した取引履歴情報記憶部に接続される。

図５を用いて、設計支援装置における設計処理を説明する。
まず、設計支援装置は、サービス履歴の取得処理を実行する（ステップＳ６−１）。具体的には、設計支援装置は、設計対象の取引サービスの指定画面をディスプレイに出力する。ここで、担当者は、設計対象の取引サービスを指定画面に入力する。この場合、設計支援装置は、取引履歴情報記憶部から、設計対象の取引サービスの利用履歴を取得する。

次に、設計支援装置は、サービス処理負荷予測処理を実行する（ステップＳ６−２）。具体的には、設計支援装置は、取引サービスを実現するために必要な商品サービスを特定する。そして、設計支援装置は、共通システム２０から、プロダクト層３０の商品サービスを個別に呼び出した場合の負荷を計算する。この場合には、共通システム２０から、プロダクト層３０に要求電文を送信する場合のオーバーヘッドを加えてサービス処理負荷を算出する。

次に、設計支援装置は、実装候補の特定処理を実行する（ステップＳ６−３）。具体的には、設計支援装置は、複数の商品サービスを組み合わせた実装候補を特定する。例えば、取引サービスが、商品サービスＡ，Ｂ，Ｃから構成される場合には、以下の実装候補が生成される。

・コンポジットサービス（Ａ，Ｂ，Ｃ）：すべての商品サービスをコンポジット化。
・コンポジットサービス（Ａ，Ｂ）及び商品サービスＣ：商品サービスＡ，Ｂをコンポジット化。
・商品サービスＡ及びコンポジットサービス（Ｂ，Ｃ）：商品サービスＢ，Ｃをコンポジット化。
・商品サービスＡ，商品サービスＢ，商品サービスＣ：コンポジット化しない。

次に、設計支援装置は、実装候補毎に以下の処理を繰り返す。
既存コンポジットを利用可能かどうかについての判定処理を実行する（ステップＳ６−４）。具体的には、設計支援装置は、既存コンポジットを検索して、処理対象の実装候補に含まれるコンポジットサービスが記録されているかどうかを判定する。

既存コンポジットを利用可能と判定した場合（ステップＳ６−４において「ＹＥＳ」の場合）、設計支援装置は、既存コンポジット以外の商品サービスの特定処理を実行する（ステップＳ６−５）。具体的には、設計支援装置は、取引サービスに含まれる商品サービスから、コンポジットサービスに含まれる商品サービスを差し引いた残りの商品サービスを特定する。なお、既存コンポジットを利用不可と判定した場合（ステップＳ６−４において「ＮＯ」の場合）、設計支援装置は、既存コンポジット以外の商品サービスの特定処理（ステップＳ６−５）をスキップする。

次に、設計支援装置は、オーバーヘッドの算出処理を実行する（ステップＳ６−６）。具体的には、設計支援装置は、共通システム２０からプロダクト層３０に要求電文を送信する場合の負荷を算出する。この場合、個別の商品サービスやコンポジットサービスを呼び出すために必要な要求電文を特定し、この要求電文において必要なオーバーヘッドを算出する。

次に、設計支援装置は、パフォーマンス算出処理を実行する（ステップＳ６−７）。具体的には、設計支援装置は、算出したオーバーヘッドに基づいて、システム負荷や遅延時間を算出する。
設計支援装置は、すべての実装候補について終了するまで繰り返す。

そして、設計支援装置は、評価結果の出力処理を実行する（ステップＳ６−８）。具体的には、設計支援装置は、実装候補毎に、算出したパフォーマンスを関連付けたテーブルを出力する。
これにより、取引履歴を考慮して、コンポジットサービスの要否を判定することができる。

更に、すべての取引サービスにおいて用いられる商品サービスの組み合わせを考慮して、コンポジットサービスの要否を判定するようにしてもよい。この場合には、複数の取引種別の取引サービスにおいて、共通して用いられる複数の商品サービスを特定する。そして、これらの商品サービスにより、コンポジットサービスを構築する。

１０…チャネル層、２０…共通システム、３０…プロダクト層、３１…商品サービスコントロール、３２…コンポジットコントロール、３５…データベース装置。

Claims (6)

1. 第１システム環境で構成された第１システム及び第２システム環境で構成された第２システムを含むサービス支援システムであって、
   前記第２システムにおいて、複数のサービス機能部と、複数のサービス機能部を呼び出すコンポジット部とを設け、
   前記第２システムが、
   前記第１システムから要求電文を取得し、
   前記コンポジット部に対する要求電文を取得した場合には、前記コンポジット部に関連付けられたサービス機能部を順次、呼び出してサービス処理を実行し、実行結果を前記第１システムに返信し、
   個別のサービス機能部に対する要求電文を取得した場合には、前記サービス機能部を呼び出してサービス処理を実行し、実行結果を前記第１システムに返信することを特徴とするサービス支援システム。
2. 前記コンポジット部に対する要求電文を取得した場合、要求電文に関連するデータベースの排他制御を実行し、
   前記要求電文に関わるサービス処理においては、サービス処理を許容し、
   前記要求電文に関わるすべてのサービス処理の終了後に前記排他制御を終了することを特徴とする請求項１に記載のサービス支援システム。
3. 前記第１システム環境と前記第２システム環境とは、オペレーションシステムが異なることを特徴とする請求項１又は２に記載のサービス支援システム。
4. 前記第１システム環境と前記第２システム環境とは、文字コード体系が異なることを特徴とする請求項１〜３のいずれか一項に記載のサービス支援システム。
5. 第１システム環境で構成された第１システム及び第２システム環境で構成された第２システムを含むサービス支援システムを用いて、サービスを支援する方法であって、
   前記第２システムにおいて、複数のサービス機能部と、複数のサービス機能部を呼び出すコンポジット部とを設け、
   前記第２システムが、
   前記第１システムから要求電文を取得し、
   前記コンポジット部に対する要求電文を取得した場合には、前記コンポジット部に関連付けられたサービス機能部を順次、呼び出してサービス処理を実行し、実行結果を前記第１システムに返信し、
   個別のサービス機能部に対する要求電文を取得した場合には、前記サービス機能部を呼び出してサービス処理を実行し、実行結果を前記第１システムに返信することを特徴とするサービス支援方法。
6. 第１システム環境で構成された第１システム及び第２システム環境で構成された第２システムを含むサービス支援システムを用いて、サービスを支援するためのプログラムであって、
   前記第２システムにおいて、複数のサービス機能部と、複数のサービス機能部を呼び出すコンポジット部とを設け、
   前記第２システムを、
   前記第１システムから要求電文を取得し、
   前記コンポジット部に対する要求電文を取得した場合には、前記コンポジット部に関連付けられたサービス機能部を順次、呼び出してサービス処理を実行し、実行結果を前記第１システムに返信し、
   個別のサービス機能部に対する要求電文を取得した場合には、前記サービス機能部を呼び出してサービス処理を実行し、実行結果を前記第１システムに返信する手段として機能させることを特徴とするサービス支援プログラム。

Images