(57)【要約】【課題】インスタンスＩＤの記載位置の指定方法に変更が生じた場合に影響範囲を局所化でき、かつ、不正な参照ＵＲＬや不正なインスタンスＩＤを検知できるデータ交換方法等を提供する。【解決手段】本発明のデータ交換方法においては、業務データからインスタンスＩＤを取り出す処理をストレージシステムが行う。そして業務プロセス制御システムは、インスタンスＩＤのパス情報を管理し、当該パス情報と業務システムから受け取った参照ＵＲＬに基づいてストレージシステムに問い合わせ、インスタンスＩＤを取得する。さらに、ストレージシステムは、参照ＵＲＬに基づいて業務データを取得できない場合等は業務プロセス制御システムに対してエラーを返し、業務プロセス制御システムは業務プロセス制御を終了する。さらに、業務プロセス制御システムは、取得したインスタンスＩＤが不正である場合も、業務プロセス制御を終了する。【選択図】図１
2009187174.tif 000002
【特許請求の範囲】
【請求項１】
業務を特定する第１の識別子を含む業務データを作成する複数の業務システム、
前記業務の処理単位である複数のアクティビティの実行順序を定義した業務プロセス定義情報に従って業務システムの呼び出し順序を制御し、
前記業務データの構造を示すスキーマ情報及び前記業務データの中での第１の識別子の位置を示すパス情報を、前記アクティビティを特定する第２の識別子に関連付けて記憶した第１のデータベースを備える業務プロセス制御システム、及び、
前記業務データを、前記業務データの所在位置を示す参照情報に関連付けて記憶する第２のデータベースを備えるストレージシステム
を用いて業務プロセス制御を実行するデータ交換方法であって、
前記ストレージシステムは、前記業務システムから前記業務データを受信すると、前記参照情報を前記業務システムに対して送信し、
前記業務システムは、前記業務プロセス制御システムに対して前記参照情報を含むアクティビティの開始要求を送信し、
前記業務プロセス制御システムは、
前記受信した開始要求に基づいて第２の識別子を取得し、
当該取得した第２の識別子に基づいて前記第１のデータベースを検索して前記スキーマ情報及び前記パス情報を取得し、
前記参照情報、前記スキーマ情報及び前記パス情報を前記ストレージシステムに対し送信し、
前記ストレージシステムは、
前記参照情報に基づいて前記第２のデータベースを検索して前記業務データを取得し、
前記スキーマ情報及び前記パス情報に基づいて前記業務データの構造を解析して前記業務データの中から第１の識別子を抽出し、当該抽出した第１の識別子を前記業務プロセス制御システムに対し送信し、
前記業務プロセス制御システムは、受信した第１の識別子を用いて前記業務プロセス制御を実行する
ことを特徴するデータ交換方法。
【請求項２】
業務を特定する第１の識別子を含む業務データを作成する複数の業務システム、
前記業務の処理単位である複数のアクティビティの実行順序を定義した業務プロセス定義情報に従って業務システムの呼び出し順序を制御し、
前記アクティビティが受信するメッセージを特定する第３の識別子及び前記業務データの中での第１の識別子の位置を示すパス情報を、前記アクティビティを特定する第２の識別子に関連付けて記憶した第１のデータベースを備える業務プロセス制御システム、及び、
前記業務データを前記業務データの所在位置を示す参照情報に関連付けて記憶する第２のデータベース及び前記業務データの構造を示すスキーマ情報を前記第３の識別子に関連付けて記憶する第３のデータベースを備えるストレージシステム
を用いて業務プロセス制御を実行するデータ交換方法であって、
前記ストレージシステムは、前記業務システムから前記業務データを受信すると、前記参照情報を前記業務システムに対して送信し、
前記業務システムは、前記業務プロセス制御システムに対して前記参照情報を含むアクティビティの開始要求を送信し、
前記業務プロセス制御システムは、
前記受信した開始要求に基づいて第２の識別子を取得し、
当該取得した第２の識別子に基づいて第１のデータベースを検索し前記第３の識別子及び前記パス情報を取得し、
前記参照情報、前記第３の識別子及び前記パス情報を前記ストレージシステムに対し送信し、
前記ストレージシステムは、
前記参照情報に基づいて第２のデータベースを検索して前記業務データを取得し、
前記第３の識別子に基づいて第３のデータベースを検索してスキーマ情報を取得し、
前記スキーマ情報及び前記パス情報に基づいて前記業務データの構造を解析して前記業務データの中から第１の識別子を抽出し、当該抽出した第１の識別子を前記業務プロセス制御システムに対し送信し、
前記業務プロセス制御システムは、受信した第１の識別子を用いて前記業務プロセス制御を実行する
ことを特徴するデータ交換方法。
【請求項３】
前記ストレージシステムは、
前記第２のデータベースの検索の際に、前記参照情報に基づいて前記業務データを取得できない場合は業務プロセス制御システムに対してエラーメッセージを送信し、
前記業務プロセス制御システムは、
前記エラーメッセージを受信した場合、又は前記受信した第１の識別子が既に開始されている業務を特定する第１の識別子と一致しない場合には前記業務プロセス制御を終了すること
を特徴とする請求項１又は請求項２に記載のデータ交換方法。
【請求項４】
前記第２の識別子は、前記アクティビティの開始要求が送信される際の送信元を示す情報、宛先を示す情報及び受信ポートを示す情報の何れかに基づいて取得されること
を特徴とする請求項１乃至請求項３の何れかに記載のデータ交換方法。
【請求項５】
業務を特定する第１の識別子を含む業務データを作成する複数の業務システム、及び
前記業務データを、前記業務データの所在位置を示す参照情報に関連付けて記憶するストレージシステムと連携し、業務の処理単位である複数のアクティビティの実行順序を定義した業務プロセス定義情報に従って業務システムの呼び出し順序を制御する業務プロセス制御システムであって、
前記業務プロセス制御システムは、
前記業務データの構造を示すスキーマ情報及び前記業務データの中での第１の識別子の位置を示すパス情報を、アクティビティを特定する第２の識別子に関連付けて記憶した第１のデータベースを備えた記憶部と、
前記ストレージシステムが前記業務システムから受信した業務データに付与した参照情報を含むアクティビティの開始要求を業務システムから受信すると、
前記受信した開始要求に基づいて第２の識別子を取得し、
当該取得した第２の識別子に基づいて前記第１のデータベースを検索して前記スキーマ情報及び前記パス情報を取得し、
前記参照情報、前記スキーマ情報及び前記パス情報を前記ストレージシステムに対し送信し、
前記ストレージシステムが前記参照情報、前記スキーマ情報及び前記パス情報に基づいて前記業務データから抽出した第１の識別子を前記ストレージシステムから受信し、
前記受信した第１の識別子を用いて前記業務プロセス制御を実行する制御部
を有することを特徴する業務プロセス制御システム。
【請求項６】
業務を特定する第１の識別子を含む業務データを作成する複数の業務システム、及び
前記業務データを前記業務データの所在位置を示す参照情報に関連付けて記憶し、前記業務データの構造を示すスキーマ情報を前記第３の識別子に関連付けて記憶するストレージシステムと連携し、業務の処理単位である複数のアクティビティの実行順序を定義した業務プロセス定義情報に従って業務システムの呼び出し順序を制御する業務プロセス制御システムであって、
前記業務プロセス制御システムは、
アクティビティを特定する第２の識別子に関連付けて、前記アクティビティが受信するメッセージを特定する第３の識別子及び前記業務データの中での第１の識別子の位置を示すパス情報を記憶した第１のデータベースを備えた記憶部と
前記ストレージシステムが前記業務システムから受信した業務データに付与した参照情報を含むアクティビティの開始要求を業務システムから受信すると、
前記受信した開始要求に基づいて第２の識別子を取得し、
当該取得した第２の識別子に基づいて前記第１のデータベースを検索して前記第３の識別子及び前記パス情報を取得し、
前記参照情報、前記第３の識別子及び前記パス情報を前記ストレージシステムに対し送信し、
前記ストレージシステムが前記参照情報、前記第３の識別子に基づいて取得した前記スキーマ情報、及び前記パス情報に基づいて前記業務データから抽出した第１の識別子を前記ストレージシステムから受信し、
受信した第１の識別子を用いて前記業務プロセス制御を実行する制御部
を有することを特徴する業務プロセス制御システム。
【請求項７】
前記制御部は、
前記ストレージシステムが前記参照情報に基づいて前記業務データを取得できない場合、又は前記ストレージシステムから受信した第１の識別子が既に開始されている業務を特定する第１の識別子と一致しない場合には前記業務プロセス制御を終了すること
を特徴とする請求項５又は請求項６に記載の業務プロセス制御システム。
【請求項８】
業務を特定する第１の識別子を含む業務データを作成する複数の業務システム、及び
業務の処理単位である複数のアクティビティの実行順序を定義した業務プロセス定義情報に従って業務システムの呼び出し順序を制御し、
前記業務データの構造を示すスキーマ情報及び前記業務データの中での第１の識別子の位置を示すパス情報を、アクティビティを特定する第２の識別子に関連付けて記憶する業務プロセス制御システムと連携するストレージシステムであって、
前記ストレージシステムは、
前記業務データを、前記業務データの所在位置を示す参照情報に関連付けて記憶する第２のデータベースを備えた記憶部と、
前記業務システムから前記業務データを受信すると、前記参照情報を前記業務システムに対して送信し、
前記参照情報、前記スキーマ情報及び前記パス情報を業務プロセス制御システムから受信すると、前記参照情報に基づいて前記第２のデータベースを検索して前記業務データを取得し、
前記スキーマ情報及び前記パス情報に基づいて前記業務データの構造を解析して前記業務データの中から前記第１の識別子を抽出し、当該抽出した第１の識別子を前記業務プロセス制御システムに対し送信する制御部
を有することを特徴するストレージシステム。
【請求項９】
業務を特定する第１の識別子を含む業務データを作成する複数の業務システム、及び
前記業務の処理単位である複数のアクティビティの実行順序を定義した業務プロセス定義情報に従って業務システムの呼び出し順序を制御し、
前記アクティビティが受信するメッセージを特定する第３の識別子及び前記業務データの中での第１の識別子の位置を示すパス情報を、アクティビティを特定する第２の識別子に関連付けて記憶する業務プロセス制御システムと連携するストレージシステムであって
前記ストレージシステムは、
前記業務データを前記業務データの所在位置を示す参照情報に関連付けて記憶する第２のデータベース及び前記業務データの構造を示すスキーマ情報を前記第３の識別子に関連付けて記憶する第３のデータベースを備えた記憶部と、
前記業務システムから前記業務データを受信すると、前記参照情報を前記業務システムに対して送信し、
前記参照情報、第３の識別子及び前記パス情報を業務プロセス制御システムから受信すると、前記参照情報に基づいて前記第２のデータベースを検索して前記業務データを取得し、
前記第３の識別子に基づいて前記第３のデータベースを検索しスキーマ情報を取得し、
前記スキーマ情報及び前記パス情報に基づいて前記業務データの構造を解析して前記業務データの中から第１の識別子を抽出し、当該抽出した第１の識別子を前記業務プロセス制御システムに対し送信する制御部
を有することを特徴するストレージシステム。
【請求項１０】
前記制御部は、
前記第２のデータベースの検索の際に、前記参照情報に基づいて前記業務データを取得できない場合は業務プロセス制御システムに対してエラーメッセージを送信する
ことを特徴とする請求項８又は請求項９に記載のストレージシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ交換方法、業務プロセス制御システム及びストレージシステムに関する。
【背景技術】
【０００２】
近年、システム及びソフトウエア部品を業務機能単位に作成し、これらの機能を、一連の業務処理の流れを定義した業務プロセス（ＢＰ：Ｂｕｓｉｎｅｓｓ  Ｐｒｏｃｅｓｓ）により統合する技術が知られている。このようなシステムの設計方法はサービス指向アーキテクチャ（ＳＯＡ：Ｓｅｒｖｉｃｅ−Ｏｒｉｅｎｔｅｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）と呼ばれる。ＳＯＡを適用するミドルウエア製品としてはＥＳＢ（Ｅｎｔｅｒｐｒｉｓｅ  Ｓｅｒｖｉｃｅ  Ｂｕｓ）が存在し、ＥＳＢは、ネットワークを介して接続された複数の業務システムを、業務プロセスの定義に従って呼び出し、データを処理する。
例えば、特許文献１には、業務プロセスに定義される業務処理の流れから並列処理部分を抽出して、並列処理可能なプログラムを生成する技術が開示されている。
【０００３】
業務プロセス制御システム（以下ＥＳＢと同義）で扱うデータは、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）形式であることが多く、業務プロセス制御システムは、各業務システムから受け取ったＸＭＬデータの内容を解析する。当該解析を効率的に行うために、業務システムが扱う大容量のデータのうちから、業務プロセスの制御に必要な情報のみを取り出すデータ交換方法の技術として例えば以下のようなものがある。
すなわち、第一に、業務システムで処理されたデータを、インターネットを介して外部のストレージシステムにアップロードする。第二に、そのデータへアクセスするための参照情報（以下、「参照ＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｅｒ）」という）と、業務プロセスの制御に必要な情報（業務を特定する情報であり、以下「インスタンスＩＤ」という）を業務システムから業務プロセス制御システムに引き渡す。第三に、業務プロセス制御システムは、インスタンスＩＤをもとに次の業務システムを呼び出す。第四に、呼び出された業務システムは、参照ＵＲＬをもとにストレージシステムからデータをダウンロードする。
例えば、特許文献２は、このようなストレージシステムにおいて、認証サーバによって認証された端末装置のみがストレージサーバにアクセスできる技術を開示している。
【特許文献１】特開２００１−９２６４７号公報（段落０００８〜００１０、図３）
【特許文献２】特開２００４−５０３７号公報（段落００１０、図１）
【発明の開示】
【発明が解決しようとする課題】
【０００４】
従来のデータ交換方法では、業務プロセス制御システムは業務システムからインスタンスＩＤを受け取り業務を識別している。そのため、業務システムは、業務システムが扱う大容量データの中からインスタンスＩＤを取り出す処理を実装する必要がある。
しかしながら、インスタンスＩＤの記載位置の指定方法に変更が生じた場合、業務システム側でシステムの変更が必要になり、呼び出される業務システムの数が増加するにつれてその影響は大きくなる。さらに、業務プロセス制御システムは、不正な参照ＵＲＬや不正なインスタンスＩＤを受け取ってもこれらを検知できない。
【０００５】
本発明は、前記した従来技術の問題点を解決し、インスタンスＩＤの記載位置の指定方法に変更が生じた場合に影響範囲を局所化でき、かつ、不正な参照ＵＲＬや不正なインスタンスＩＤを検知できるデータ交換方法等を提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明のデータ交換方法においては、業務システムの業務データからインスタンスＩＤを取り出す処理をストレージシステムが行う。そして業務プロセス制御システムは、インスタンスＩＤのパス情報を管理し、当該パス情報と業務システムから受け取った参照ＵＲＬに基づいてストレージシステムに問い合わせ、インスタンスＩＤを取得する。
さらに、ストレージシステムは、参照ＵＲＬに基づいて業務データを取得できない場合は業務プロセス制御システムに対してエラーを返し、業務プロセス制御システムは業務プロセス制御を終了する。さらに、業務プロセス制御システムは、取得したインスタンスＩＤが不正である場合も、業務プロセス制御を終了する。
【発明の効果】
【０００７】
本発明によれば、インスタンスＩＤの記載位置の指定方法に変更が生じた場合に影響範囲を局所化でき、かつ、不正な参照ＵＲＬや不正なインスタンスＩＤを検知できるデータ交換方法等を提供することが可能になる。
【発明を実施するための最良の形態】
【０００８】
以下、本発明を実施するための最良の形態について図面等を参照しつつ詳細に説明する。当該形態には、基本となる第１の実施形態と、それに部分的変更を加えた第２の実施形態がある。
【０００９】
（第１の実施形態）
図１は、第１の実施形態に係る全体構成図である。
業務プロセス制御システム１、ストレージシステム２及び複数の業務システム３がネットワーク４を介して相互に接続されている。ネットワーク４は、インターネット、イントラネット、有線ＬＡＮ、無線ＬＡＮ等であってよく、データのやり取りを行うために使用されるものである。
【００１０】
（業務プロセス制御システム１）
業務プロセス制御システム１は、相互にバスで接続された、中央制御装置（制御部）１０、入力装置１１、出力装置１２、主記憶装置（記憶部）１３、補助記憶装置（記憶部）１４及び通信インタフェース（ＩＦ）１５を有する。
補助記憶装置１４には、パス情報データベース１８ａ及びプロセス定義情報データベース１９が格納されている。パス情報データベースについては、第１の実施形態と第２の実施形態とでその内容が異なる（詳細後記）ので別の符号１８ａ、及び１８ｂを付して区別する。受信処理部１６及びプロセス制御部１７はプログラムである。受信処理部１６は、受信制御機能及びインスタンスＩＤ問合せ機能を有し、プロセス制御部１７は、プロセス定義機能、プロセス制御機能及び送信制御機能を有する。以下、「○○部は」又は「○○部の◎◎機能は」と主体を記した場合は、中央制御装置１０が必要に応じ補助記憶装置１４から各プログラムを読み出した上で主記憶装置１３にロードし、各機能（後記）を実行するものとする（後記するストレージシステム２でも同様）。業務プロセス制御システム１は一般的なサーバ計算機、パーソナルコンピュータ等であってよい。
なお、「第1のデータベース」には、パス情報データベース１８ａ及び１８ｂが相当する。
【００１１】
（ストレージシステム２）
ストレージシステム２は、相互にバスで接続された、中央制御装置（制御部）２０、入力装置２１、出力装置２２、主記憶装置（記憶部）２３、補助記憶装置（記憶部）２４及び通信インタフェース（ＩＦ）２５を有する。
補助記憶装置２４には、登録データ管理情報データベース２６が格納されている。データ管理部２７はプログラムである。データ管理部２７は、アップロード機能、ダウンロード機能及びインスタンスＩＤ取得機能を有する。ストレージシステム２は一般的なサーバ計算機、パーソナルコンピュータ等であってよい。
なお、「第２のデータベース」には、登録データ管理情報データベース２６が相当する。また、業務プロセス制御システム１とストレージシステム２は同一のサーバ計算機等内に構成することもできる。
【００１２】
（業務システム３）
業務システム３は、相互にバスで接続された、中央制御装置、入力装置、出力装置、主記憶装置、補助記憶装置及び通信インタフェース（ＩＦ）（いずれも図示せず）を有する。業務システム３は一般的なサーバ計算機、パーソナルコンピュータ等であってよい。
【００１３】
（業務プロセス定義画面５０）
図２は、第１の実施形態に係る業務プロセス定義画面５０の一例を示す図である。業務プロセス定義画面５０は、プロセス制御部１７のプロセス定義機能により制御され、業務プロセス制御システム１の出力装置１２に表示される。ユーザは、入力装置１１を介して当該画面に対して情報を入力する（詳細後記）。
業務プロセス定義画面５０は、３つの領域５１、５２、５３を有する。
領域５１には、業務プロセス名が入力される。
領域５２には、領域５３に記述するためのアイコン群が配置される。アイコン群は、開始アイコン５４、終了アイコン５５、アクティビティアイコン５６（業務の処理単位である「アクティビティ」を表す）及びシーケンスフローアイコン５７を有する。例えば、アクティビティアイコン５６をマウス等の入力装置１１でクリックして選択した上で、領域５３のある位置をクリックすると、その位置に選択されたアイコンが配置される。メニューバーにある「登録ボタン」をクリックすると、領域５１、５３に記述された業務プロセスの情報をプロセス定義情報データベース１９として補助記憶装置１４に記憶する。
【００１４】
図２の符号７０は、受発注業務プロセスを示す一例である。アクティビティアイコンが４つ横１列に並んで配置されており、その左側に開始アイコンが、右側に終了アイコンが１つずつ配置されている。それらの間には、それらを接続するようにシーケンスフローアイコンが配置されている。
そして、「受発注」という業務プロセス名を有する業務は、業務の処理単位として「発注伝票受信」、「出荷伝票作成」、「出荷伝票送信」及び「受領伝票受信」の各アクティビティを有し、これらのアクティビティが当該順に実行されることを受発注業務プロセス７０は示している。
【００１５】
ユーザが領域５３上のアクティビティアイコンを入力装置１１を介して選択するのを受け付けると、プロセス制御部１７のプロセス定義機能は、画面上にアクティビティ定義画面６０を表示する。
アクティビティアイコン７１に対応するアクティビティ定義画面６０の上半分（二重線より上）において、ユーザは、「サービス要求受信」及び「サービス呼び出し」の２種類の選択肢のうちからアクティビティ種別６１を選択し、続いて、アクティビティ名６２を示す文字列を入力する。
アクティビティ定義画面６０の下半分には、選択されたアクティビティ種別によって異なるものが表示される。例えば、アクティビティアイコン７１に対応するアクティビティ定義画面６０の上半分で、アクティビティ種別として「サービス要求受信」を選択するとその下半分には、インスタンス生成の有無及び同期通信の該否を選択するラジオボタンが表示される。一方、アクティビティアイコン７２に対応するアクティビティ定義画面６０の上半分で、アクティビティ種別として「サービス呼び出し」を選択するとその下半分には、同期通信の該否を選択するラジオボタンが表示される。ユーザはこれらの表示画面に対して入力を行った後、業務プロセス定義画面５０の「登録ボタン」をクリックすると、アクティビティ定義画面６０にて入力された情報が、プロセス定義情報データベース１９として補助記憶装置１４に記憶される。アクティビティアイコン７３及びアクティビティアイコン７４についても同様にアクティビティ定義を行う。
なお、「業務プロセス定義情報」には、業務プロセス定義画面５０及びアクティビティ定義画面６０において入力された情報が該当する。
【００１６】
なお、“サービス要求受信”と“同期”の組み合わせが選択された場合は、当該アクティビティは、まずメッセージを受信し、後に応答メッセージを返信することを示す。
“サービス呼び出し”と“同期”の組み合わせが選択された場合は、当該アクティビティは、まずメッセージを送信し、後に応答メッセージを受信することを示す。
“サービス要求受信”と“非同期”の組み合わせが選択された場合は、当該アクティビティは、まずメッセージを受信するが、後に応答メッセージを返信しないことを示す。
“サービス呼び出し”と“非同期”の組み合わせが選択された場合は、当該アクティビティは、まずメッセージを送信するが、後に応答メッセージを受信しないことを示す。
また、アクティビティ定義画面６０において「インスタンス生成“Ｙｅｓ”」を選択することは、当該アクティビティが、業務プロセス制御システム１に対して、業務をインスタンス化すること、すなわち、インスタンスＩＤに関連付けて当該業務を制御することを開始させることを意味する。「インスタンス生成“Ｎｏ”」を選択することは、当該アクティビティが、既にインスタンス化された業務の継続処理であることを業務プロセス制御システム１に対して認識させることを意味する。
【００１７】
図３は、第１の実施形態に係る業務プロセス制御システム１と業務システム３の関連を、受発注業務プロセス７０を例にＢＰＭＮ（Ｂｕｓｉｎｅｓｓ  Ｐｒｏｃｅｓｓ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）により定義した概念図である。前記した通り、受発注業務プロセス７０は、業務プロセス制御システム１のプロセス定義情報データベース１９に保存されている。
図３において、符号８１は発注業務システム、符号８２は出荷業務システム、符号８３は受領業務システム、符号８４〜９１はメッセージフローである。発注業務システム８１、出荷業務システム８２及び受領業務システム８３は、前記した業務システム３に対応している。メッセージフロー８４〜９１はシステム間でのメッセージの送受信の流れを表している。
以下の説明では、符号７１及び７４は、アクティビティ種別として「サービス要求受信」が選択されたアクティビティアイコン、符号７２及び７３は、アクティビティ種別として「サービス呼び出し」が選択されたアクティビティアイコンであるとする。
【００１８】
まず、受発注業務プロセス７０は、発注業務システム８１がサービス呼び出しにより、アクティビティアイコン７１が示すアクティビティ（発注伝票受信）を呼び出すことで開始される。
受発注業務プロセス７０は、アクティビティアイコン７１が示すアクティビティ（発注伝票受信）にて発注業務システム８１からのサービス要求を受付け（８４）、応答を返信（８５）した後にアクティビティアイコン７２が示すアクティビティ（出荷伝票作成）に遷移する。
次に、アクティビティアイコン７２が示すアクティビティ（出荷伝票作成）にて出荷業務システム８２を呼び出し(８６)、応答を受信(８７)した後にアクティビティアイコン７３が示すアクティビティ(出荷伝票送信)に遷移する。
次に、アクティビティアイコン７３が示すアクティビティ(出荷伝票送信)にて受領業務システム８３を呼び出し(８８)、応答を受信（８９）した後にアクティビティアイコン７４が示すアクティビティ(受領伝票受信)に遷移する。
最後に、アクティビティアイコン７４が示すアクティビティ（受領伝票受信）にて受領業務システム８３からの要求を受付け（９０）、応答を返信（９１）した後に受発注業務プロセス７０は終了する。
【００１９】
（業務データ１０１）
図４は、第１の実施形態に係る業務データの一例を示す図である。
業務データ１０１は、業務システム３が当該業務を行うために作成するデータであり、ストレージシステム２に格納される。
業務データ１０１は、ＸＭＬ形式の「発注伝票」であり、要素「発注」１０２をルート要素（ＸＭＬ宣言＜？ＸＭＬ・・・＞に続く最初の要素）としたデータ構造となっている。
この例では、要素「取引番号」１０３は、受発注業務プロセス７０に係る業務を一意に特定する識別子であるインスタンスＩＤを格納する要素であり、要素「取引番号」１０３の内容には、インスタンスＩＤ１０４の値（ここでは“１０２２０３５７８１”）が指定されるものとする。
また、要素「取引明細」１０５は繰り返し出現する要素であり、実際の業務データにおいては、この繰り返し部分が存在するためにデータのサイズが大きくなる。ここでは、ＸＭＬ形式の「発注伝票」を例に業務データ１０１を説明したが、インスタンスＩＤ１０４が含まれ、後記するパス情報（図７参照）によりインスタンスＩＤ１０４を検索できるデータ構造であればよく、ＣＳＶ（Ｃｏｍｍａ−Ｓｅｐａｒａｔｅｄ  Ｖａｌｕｅｓ）形式、固定長形式等であってもよい。
なお、「第1の識別子」には、インスタンスＩＤが相当する。
【００２０】
図５は、第１の実施形態に係る業務データの他の一例を示す図である。
図４の業務データ１０１が、発注業務システム８１が作成した「発注伝票」であるのに対し、図５の業務データ１１１は、出荷業務システム８２が作成した「出荷伝票」である。そしてこの「出荷伝票」は、業務プロセス制御システム１からのメッセージ（後記するメッセージ３１１）を受けた出荷業務システム８２が、「発注伝票」の内容に基づいて作成する。
業務データ１１１もまた、ＸＭＬ形式で作成されており、要素「出荷」１１２をルート要素としたデータ構造となっている。
要素「取引番号」１１３は、受発注業務プロセス７０に係る業務を一意に特定する識別子であるインスタンスＩＤ１１４を格納する要素であり、要素「取引番号」１１３の内容には、図４のインスタンスＩＤ１０４の値と同一のインスタンスＩＤ１１４の値が指定されるものとする。
また、要素「取引明細」１１５も繰り返し出現する要素であり、この繰り返し部分が存在するためにデータのサイズが大きくなる。
【００２１】
（登録データ管理情報データベース２６）
図６は、第１の実施形態に係る登録データ管理情報データベース２６の一例を示す図である。
登録データ管理情報データベース２６は、ストレージシステム２の補助記憶装置２４に格納され、登録データ（ストレージシステム２に登録され、参照ＵＲＬが付与された業務データ）に関連付けて、その参照ＵＲＬを記憶したデータベースである。
図６においては、登録時刻欄２０１に記憶された登録時刻に関連付けて、登録データ欄２０２には登録データが、参照ＵＲＬ欄２０３には参照ＵＲＬが記憶されている。
登録時刻欄２０１の登録時刻は、業務データを登録した時刻である。
登録データ欄２０２の登録データは、登録データそのものである。
参照ＵＲＬ欄２０３の参照ＵＲＬは、登録データが存在するネットワーク上の位置を示すアドレスであり、業務システム３がネットワーク４を介して登録データをダウンロードするために使用される。参照ＵＲＬは、ストレージシステム２のデータ管理部２７のアップロード機能により、登録データ管理情報データベース２６内で一意となるように採番される。
なお、「参照情報」には、参照ＵＲＬが相当する。
ちなみに、図６の第１行目のレコードは、以下のことがらを示している。すなわち、登録時刻が「２０ＸＸ０１２３１５２６４００」に登録された登録データは「＜？ｘｍｌ  ｖｅｒｓｉｏｎ＝“１．０”  ｅｎｃｏｄｉｎｇ＝“ＵＴＦ−８”？＞＜発注＞・・・＜／発注＞」であり、参照ＵＲＬは「ｈｔｔｐ：／／ｗｗｗ．ｘｍｌｅｄｉｓｅｒｖｉｃｅ．＊＊／ｄａｔａ／２０ＸＸ０１２３１５２６４００．ｘｍｌ」であるということである。登録データ管理情報データベース２６のレコードは、ストレージシステム２に登録された業務データの数だけ存在する。
図６に示す例では、登録データ欄２０２に登録データをテキスト形式で格納しているが、元の業務データへ可逆変換できればよく、Ｂａｓｅ６４形式に変換したデータ等を格納してもよい。
【００２２】
（パス情報データベース１８ａ）
図７は、第１の実施形態に係るパス情報データベース１８ａの一例を示す図である。
パス情報データベース１８ａは、業務プロセス制御システム１の補助記憶装置１４に格納され、業務プロセス制御システム１がインスタンスＩＤ１０４を取得するためにストレージシステム２にアクセスする際、ストレージシステム２に対し受け渡すパス情報（後記）及びスキーマ情報（後記）を記憶したデータベースである。
図７においては、アクティビティ識別子欄２１１に記憶されたアクティビティ識別子に関連付けて、スキーマ情報欄２１２にはスキーマ情報が、パス情報欄２１３にはパス情報がそれぞれ記憶されている。
【００２３】
アクティビティ識別子欄２１１のアクティビティ識別子は、受発注業務プロセス７０のアクティビティアイコン７１〜７４が示すアクティビティのうち、アクティビティ種別として「サービス要求受信」が選択されたアクティビティを一意に特定する情報である。
アクティビティ識別子は、アクティビティを呼び出すメッセージに関連付けられて（例えば、メッセージの送信元を示す情報、メッセージの宛先を示す情報、メッセージの受信ポートを示す情報等に関連付けて）業務プロセス制御システム１の補助記憶装置１４に記憶されており、業務プロセス制御システム１は、処理中のアクティビティに係るアクティビティ識別子を認識しうるものとする。
スキーマ情報欄２１２のスキーマ情報は、図６の参照ＵＲＬに基づいて参照される登録データのデータ構造を定義した情報である。スキーマ情報は、ストレージシステム２が解釈し、登録データの構造を検証できる情報であればよく、ＸＭＬ  Ｓｃｈｅｍａ、ＤＴＤ等であってもよい。
パス情報欄２１３のパス情報は、スキーマ情報で定義されたデータ構造における、インスタンスＩＤとして使用する値（１０４）の位置を示す情報である。パス情報は、ストレージシステム２が解釈し、登録データ内にあるインスタンスＩＤ１０４の記載された位置が分かる情報であればよく、ＸＰａｔｈ等であってもよい。
インスタンスＩＤの記載位置の指定方法に変更があった場合は、当該パス情報を変更する。そうすることによって、システムのメンテナンスを各業務システム３に及ぼすことなく、業務プロセス制御システム１に集中することができる。
パス情報データベース１８ａのレコードは、アクティビティ種別として「サービス要求受信」が選択されたアクティビティの数だけ存在する。
ちなみに、図７に示す例において、アクティビティ識別子「発注伝票受信処理」を検索キーとしてパス情報データベース１８ａを検索した場合は、スキーマ情報「＜？ｘｍｌ  ｖｅｒｓｉｏｎ＝“１．０”  ｅｎｃｏｄｉｎｇ＝“ＵＴＦ−８”？＞＜ｘｓｄ：ｓｃｈｅｍａ  ・・・＞・・・＜／ｘｓｄ：ｓｃｈｅｍａ＞」とパス情報「／／発注／取引／取引番号／ｔｅｘｔ（）」を取得できる（図４参照）。
なお、「第2の識別子」にはアクティビティ識別子が相当する。
【００２４】
（処理手順）
図８は、第１の実施形態に係る、業務プロセス制御システム１、ストレージシステム２及び業務システム３が実行する処理手順を示したシーケンス図である。以下では、受発注業務プロセス７０を例にして、まず、処理手順の全体的概要を説明した後、ストレージシステム２及び業務プロセス制御システム１の各活性区間の補足説明を行う。
【００２５】
（１：処理手順の全体的概要）
図８の実線で表した符号３０１、３０３、３０５、３０６、３０９、３１１、３１２、３１５は同期メッセージ（応答を要するメッセージ）、破線で表した符号３０２、３０７、３１０、３１３、３１６、３１７は同期メッセージに対応するリターン（応答メッセージ）である。符号３０１には符号３０２が、符号３０３には符号３１０が、符号３０６には符号３０７が、符号３１１には符号３１７が、符号３１２には符号３１３が、符号３１５には符号３１６が、それぞれ対応している。また、符号３０５には符号３０５自身が、符号３０９には符号３０９自身が対応している（後記する再帰呼び出し）。
【００２６】
符号３０４、３０８は、実行する場合、実行しない場合に分かれる処理手順を示すフレーム、符号３５１〜３５５は活性区間（詳細後記）、符号３９１はアクティビティアイコン７１が示すアクティビティ（発注伝票受信）の開始を示すノート（注釈）、符号３９２はアクティビティアイコン７１が示すアクティビティの終了を示すノート、符号３９３はアクティビティアイコン７２が示すアクティビティ（出荷伝票作成）の開始を示すノート、符号３９４はアクティビティアイコン７２が示すアクティビティの終了を示すノートである。
【００２７】
（１−１）まず、発注業務システム８１は、ストレージシステム２へ、メッセージ３０１（アップロード要求）を送信する。このメッセージ３０１の引数（図８では括弧内に記載。以下同じ。）には、業務データ１０１を指定する（メッセージ３０１）。
【００２８】
（１−２）ストレージシステム２は、メッセージ３０１を受信する。次に、ストレージシステム２は、業務データ１０１へアクセスするための参照ＵＲＬを生成し、登録時刻に関連付けて、業務データ１０１及び参照ＵＲＬを登録データ管理情報データベース２６に記憶する。さらに、ストレージシステム２は、メッセージ３０１の戻り値として参照ＵＲＬをリターンする（リターン３０２）。なお、前記の通り登録データ管理情報データベース２６に登録された業務データ１０１は登録データである。活性区間３５１については補足説明を後記する。
【００２９】
（１−３）続いて、発注業務システム８１は、リターン３０２を受信し、参照ＵＲＬを取得する。次に、発注業務システム８１は、業務プロセス制御システム１へ、メッセージ３０３（発注伝票受信要求）を送信する。このメッセージ３０３の引数には、参照ＵＲＬを指定する（メッセージ３０３）。
なお、「アクティビティの開始要求」には、当該メッセージ３０３が相当する。
【００３０】
（１−４）業務プロセス制御システム１は、メッセージ３０３を受信し、参照ＵＲＬを取得する。
このメッセージ３０３の受信により、アクティビティアイコン７１（発注伝票受信）の処理を開始する（ノート３９１）。
【００３１】
（１−５）前記（１−４）にて受信したメッセージ３０３の要求が、アクティビティ種別が「サービス要求受信」であるアクティビティに対する処理要求であり、かつ業務プロセス制御システム１が引数として付されている参照ＵＲＬ欄２０３の参照ＵＲＬの取得に成功した場合は、業務プロセス制御システム１はフレーム３０４の処理手順を実行する。それ以外の場合は、フレーム３０４の処理手順は実行しない。
【００３２】
（１−６）フレーム３０４の処理手順を実行する場合、業務プロセス制御システム１は、まず、メッセージ３０３に基づいて（例えば、メッセージ３０３の送信元を示す情報、送信先を示す情報又は受信ポートを示す情報等に基づいて）業務プロセス制御システム１の補助記憶装置１４を検索し、アクティビティ識別子を取得する。次に、パス情報取得メソッドを実行し、スキーマ情報、パス情報を取得する。このメソッドの引数には、アクティビティ識別子を指定する（メッセージ３０５）。
図８において、「○○＝◎◎（    ）」との記載は、「（  ）内の文字列等を引数として◎◎というメソッドを実行した結果として○○という情報を得る」ことを示すものとする（メッセージ３０９においても同様）。活性区間３５２については補足説明を後記する。
【００３３】
（１−７）続いて、業務プロセス制御システム１は、ストレージシステム２へ、メッセージ３０６（インスタンスＩＤ取得要求）を送信する。このメッセージ３０６の引数には、参照ＵＲＬ、前記（１−６）にて取得したスキーマ情報、パス情報を指定する（メッセージ３０６）。
【００３４】
（１−８）ストレージシステム２は、メッセージ３０６を受信し、参照ＵＲＬ、スキーマ情報、パス情報を取得する。
次に、ストレージシステム２は、参照ＵＲＬを検索キーとして登録データ管理情報データベース２６を検索して登録データを取得し、登録データのデータ構造をスキーマ情報によって検証し、インスタンスＩＤ１０４をパス情報によって取得する。
参照ＵＲＬによって登録データを取得できない場合、データ構造に不正がある場合、又はインスタンスＩＤ１０４を取得できない場合は、エラーメッセージを返す。
インスタンスＩＤ１０４の取得に成功した場合は、メッセージ３０６の戻り値としてインスタンスＩＤ１０４をリターンする（リターン３０７）。
これらにより、不正な参照ＵＲＬや不正なデータ構造、不正なインスタンスＩＤを検知したことを、業務プロセス制御システム１へ通知することができる。活性区間３５３については補足説明を後記する。
【００３５】
（１−９）業務プロセス制御システム１は、リターン３０７を受信し、インスタンスＩＤ１０４を取得する。
【００３６】
（１−１０）業務プロセス制御システム１は、インスタンスＩＤ１０４の取得に成功した場合は、フレーム３０８の処理手順を実行する。それ以外の場合は、フレーム３０８の処理手順は実行しない。
（１−１１）業務プロセス制御システム１は、インスタンスＩＤ識別メソッドを実行し、インスタンスＩＤ１０４の正当性（詳細後記）を検証する。このメソッドの引数には、インスタンスＩＤ１０４を指定する（メッセージ３０９）。
（１−１２）続いて、業務プロセス制御システム１は、インスタンスＩＤ１０４の検証の結果を取得する。活性区間３５４については補足説明を後記する。
【００３７】
（１−１３）業務プロセス制御システム１は、インスタンスＩＤ１０４の検証結果が不正である場合は、メッセージ３０３の戻り値として異常終了の結果をリターンする。異常終了の結果をリターンする場合は、業務プロセス制御システム１は、次のアクティビティを開始するメッセージ（後記するメッセージ３１１）を送信しない。
インスタンスＩＤ１０４の検証の結果が正常である場合、又は、インスタンスＩＤ１０４の検証を行っていない場合、メッセージ３０３の戻り値として正常終了の結果をリターンする（リターン３１０）。
【００３８】
このように、発注業務システム８１は、インスタンスＩＤ１０４を通知することなく参照ＵＲＬのみを業務プロセス制御システム１に通知すればよく、インスタンスＩＤ１０４の記載位置の指定方法が変更されても影響を受けないため、インスタンスＩＤ１０４の記載位置の指定方法に変更が生じた場合でも、影響範囲を局所化することができる。そのため、システムの改変が容易になる。
【００３９】
（１−１４）リターン３１０の後に、業務プロセス制御システム１は、取得したインスタンスＩＤ１０４を使用して業務プロセス制御を実行する。この業務プロセスの制御方法は、取得したインスタンスＩＤ１０４を使用した制御方法であればよく、実行中の業務プロセスに関連付けられたインスタンスＩＤ群を、インスタンスＩＤ１０４で検索することにより業務プロセスを引き当てて制御する方法等であってよい。そして、このリターン３１０により、アクティビティアイコン７１が示すアクティビティ（発注伝票受信）の処理が終了する（ノート３９２）。
また同時に、アクティビティアイコン７２が示すアクティビティ（出荷伝票作成）の処理を開始する（ノート３９３）。
【００４０】
（１−１５）続いて、業務プロセス制御システム１は、出荷業務システム８２へ、メッセージ３１１（出荷伝票作成）を送信する。このメッセージ３１１の引数には、参照ＵＲＬを指定する（メッセージ３１１）。
【００４１】
（１−１６）出荷業務システム８２は、メッセージ３１１を受信し、参照ＵＲＬを取得する。次に、出荷業務システム８２は、ストレージシステム２へ、メッセージ３１２（ダウンロード要求）を送信する。このメッセージ３１２の引数には、参照ＵＲＬを指定する（メッセージ３１２）。
【００４２】
（１−１７）ストレージシステム２は、メッセージ３１２を受信し、参照ＵＲＬを取得する。次に、ストレージシステム２は、参照ＵＲＬに基づいて、登録データ管理情報データベース２６（図６）の登録データ欄２０２に記憶されている登録データ（業務データ１０１）を取得し、メッセージ３１２の戻り値として業務データ１０１をリターンする（リターン３１３）。活性区間３５５については補足説明を後記する。
【００４３】
（１−１８）出荷業務システム８２は、リターン３１３を受信し、業務データ１０１を取得する。次に、出荷業務システム８２は、業務データ１０１に基づいて出荷業務を実施し、業務データ１１１を作成する。この出荷業務の入力情報には、業務データ１０１を指定する（メッセージ３１４）。
【００４４】
（１−１９）続いて、出荷業務システム８２は、ストレージシステム２へ、メッセージ３１５（アップロード要求）を送信する。このメッセージ３１５の引数には、前記（１−１８）にて作成した業務データ１１１を指定する（メッセージ３１５）。
【００４５】
（１−２０）ストレージシステム２は、メッセージ３１５を受信し、業務データ１１１を登録データ管理情報データベース２６に格納する。次に、ストレージシステム２は、参照ＵＲＬ（業務データ１０１ではなく業務データ１１１の位置を示すＵＲＬ）を作成し、メッセージ３１５の戻り値として参照ＵＲＬをリターンする（リターン３１６）。
【００４６】
（１−２１）出荷業務システム８２は、リターン３１６を受信し、参照ＵＲＬを取得する。次に、出荷業務システム８２は、メッセージ３１１の戻り値として、参照ＵＲＬをリターンする（リターン３１７）。
【００４７】
（１−２２）業務プロセス制御システム１は、リターン３１７を受信し、参照ＵＲＬを取得する。
このリターン３１７により、アクティビティアイコン７２（出荷伝票作成）の処理が終了する（ノート３９４）。
受発注業務プロセス７０はその後も続くが、その後の部分の説明は省略する。
【００４８】
（２：活性区間３５１（アップロード処理）の補足説明）
図８の活性区間３５１は、ストレージシステム２がアップロード要求（メッセージ３０１）を受信したときの処理である。
（２−１）データ管理部２７のアップロード機能は、メッセージ３０１を受信し、業務データ１０１を取得する。
アップロード要求（メッセージ３０１）は、業務システム３がネットワークを介して送信し、ストレージシステム２のアップロード機能を呼び出せればよく、ＷＷＷソフトウエア、メールソフトウェア等を利用した呼び出しであってもよい。
（２−２）データ管理部２７のアップロード機能は、業務データ１０１を登録データ管理情報データベース２６に格納する。
（２−３）データ管理部２７のアップロード機能は、参照ＵＲＬを作成し、メッセージ３０１の戻り値として参照ＵＲＬをリターンする（リターン３０２）。同時に、登録時刻に関連付けて、登録データと参照ＵＲＬを登録データ管理情報データベース２６に記憶する。
【００４９】
（３：活性区間３５２（パス情報取得処理）の補足説明）
図８の活性区間３５２は、業務プロセス制御システム１がパス情報取得要求（メッセージ３０５）を受信したときの処理である。ここで、メッセージ３０５は、業務プロセス制御システム１が自分自身のメソッドを呼び出す再帰呼び出しである。
（３−１）受信処理部１６の受信制御機能は、受信処理部１６のインスタンスＩＤ問合せ機能が送信したメッセージ３０５を受信し、メッセージ３０３の宛先たるＵＲＬに関連付けられて記憶されているアクティビティ識別子を取得する。
（３−２）受信処理部１６の受信制御機能は、アクティビティ識別子を検索キーとしてパス情報データベース１８ａを検索し、スキーマ情報、パス情報を取得する。
（３−３）受信処理部１６の受信制御機能は、メッセージ３０５の戻り値として、スキーマ情報、パス情報をリターンする。
【００５０】
（４：活性区間３５３（インスタンスＩＤ取得処理）の補足説明）
図８の活性区間３５３は、ストレージシステム２がインスタンスＩＤ取得要求（受信処理部１６のインスタンスＩＤ問合せ機能が送信したメッセージ３０６）を受信したときの処理である。
（４−１）データ管理部２７のインスタンスＩＤ取得機能は、メッセージ３０６を受信し、参照ＵＲＬ、スキーマ情報、パス情報を取得する。
（４−２）データ管理部２７のインスタンスＩＤ取得機能は、参照ＵＲＬを検索キーとして、登録データ管理情報データベース２６を検索し、登録データ（業務データ１０１）を取得する。
データ管理部２７のインスタンスＩＤ取得機能は、参照ＵＲＬが検索キーとして扱えない文字列の場合、又は、検索の結果該当する登録データが存在しない場合は、業務プロセス制御システム１に対してメッセージ３０６の戻り値としてエラーメッセージをリターンする。
（４−３）前記（４−２）において、登録データを取得することができた場合は、データ管理部２７のインスタンスＩＤ取得機能は、前記（４−１）にて取得したスキーマ情報により登録データ（業務データ１０１）のデータ構造を検証する。
検証の結果、登録データ（業務データ１０１）のデータ構造に不正がある場合は、データ管理部２７のインスタンスＩＤ取得機能は、業務プロセス制御システム１に対してメッセージ３０６の戻り値としてエラーメッセージをリターンする。
（４−４）前記（４−３）における検証の結果、登録データ（業務データ１０１）のデータ構造が正しい場合は、データ管理部２７のインスタンスＩＤ取得機能は、登録データ（業務データ１０１）の、前記（４−１）にて取得したパス情報に示された場所にある値をインスタンスＩＤ１０４として取得したうえで、業務プロセス制御システム１に対してメッセージ３０６の戻り値として当該インスタンスＩＤ１０４をリターンする（リターン３０７）。
インスタンスＩＤ１０４を取得できない場合は、データ管理部２７のインスタンスＩＤ取得機能は、業務プロセス制御システム１に対してメッセージ３０６の戻り値としてエラーメッセージをリターンする。
【００５１】
（５：活性区間３５４（インスタンスＩＤ識別処理）の補足説明）
図８の活性区間３５４は、業務プロセス制御システム１がインスタンスＩＤ取得要求（メッセージ３０９）を受信したときの処理である。ここで、メッセージ３０９は、業務プロセス制御システム１が自分自身のメソッドを呼び出す再帰呼び出しである。
（５−１）プロセス制御部１７のプロセス制御機能は、メッセージ３０９を受信し、インスタンスＩＤ１０４を取得する。
（５−２）処理中のアクティビティのアクティビティ種別が「サービス要求受信」であり、かつ、処理中のアクティビティが業務を新たにインスタンス化する場合(インスタンス生成“Ｙｅｓ”)は、プロセス制御部１７のプロセス制御機能は、メッセージ３０９の戻り値として正常終了（当該活性区間を終了した後、次のアクティビティに遷移する旨のメッセージ）をリターンする。
（５−３）処理中のアクティビティのアクティビティ種別が「サービス要求受信」であり、かつ、アクティビティがインスタンス化された業務の後続処理として実行される場合（インスタンス生成“Ｎｏ”）は、プロセス制御部１７のプロセス制御機能は、取得したインスタンスＩＤ１０４が既に開始されている業務を特定するインスタンスＩＤと一致するか否かを検証する。
検証の結果、一致する場合は、プロセス制御部１７のプロセス制御機能はメッセージ３０９の戻り値として正常終了をリターンする。一致しない場合は、プロセス制御部１７のプロセス制御機能はメッセージ３０９の戻り値としてエラーメッセージをリターンする。
図８の例では、受発注業務プロセス７０のアクティビティアイコン７１（発注伝票受信）は業務を新たにインスタンス化するため、前記検証を行わずに、正常終了をリターンする。
【００５２】
（６：活性区間３５５（ダウンロード処理）の補足説明）
図８の活性区間３５５は、ストレージシステム２がダウンロード要求（メッセージ３１２）を受信したときの処理である。
（６−１）データ管理部２７のダウンロード機能は、メッセージ３１２を受信し、参照ＵＲＬを取得する。
（６−２）データ管理部２７のダウンロード機能は、参照ＵＲＬを検索キーとして、登録データ管理情報データベース２６を検索し、登録データ（業務データ１０１）を取得する。
（６−３）データ管理部２７のダウンロード機能は、メッセージ３１２の戻り値として業務データ１０１をリターンする（リターン３１３）。
【００５３】
（第２の実施形態）
本発明の第１の実施形態においては、業務プロセス制御システム１は、ストレージシステム２に対してスキーマ情報を送信する。しかしながら、このスキーマ情報自体のデータ容量が大きい場合には、通信コストが大きくなってしまう。
そこで、本発明の第２の実施形態では、通信コストを下げるために、ストレージシステム２がスキーマ情報の管理を行い、業務プロセス制御システム１は、ストレージシステム２に対して、スキーマ情報の代わりにより情報量の小さいメッセージ識別子（詳細後記）を通知する。
【００５４】
以下、第１の実施形態との相違点を中心に説明する。
図９は、第２の実施形態に係る全体構成図である。図１との相違点は、ストレージシステム２がスキーマ情報データベース２８を追加的に有していることである。その他の構成は、図１と同じである。
【００５５】
（パス情報データベース１８ｂ）
図１０は、第２の実施形態に係るパス情報データベース１８ｂの一例を示す図である。図７との相違点は、図７のスキーマ情報欄２１２が、メッセージ識別子欄２３２に変更されていることである。その他の構成は図７と同じである。
メッセージ識別子欄２３２のメッセージ識別子は、アクティビティ識別子によって特定されるアクティビティが受信するメッセージを一意に特定する情報である。
なお、「第３の識別子」には、メッセージ識別子が相当する。
【００５６】
（スキーマ情報データベース２８）
図１１は、第２の実施形態に係るスキーマ情報データベース２８の一例を示す図である。スキーマ情報データベース２８は、第１の実施形態にはなかったものであり、ストレージシステム２の補助記憶装置２４に格納される。
メッセージ識別子欄２４１に記憶されたメッセージ識別子に関連付けて、スキーマ情報欄２４２にスキーマ情報が記憶されている。
メッセージ識別子欄２４１のメッセージ識別子は、図１０のメッセージ識別子と同一である。
スキーマ情報欄２４２のスキーマ情報は、図７のスキーマ情報と同一である。スキーマ情報データベース２８のレコードは、パス情報データベース１８ｂのレコードの数（アクティビティ種別として「サービス要求受信」が選択されたアクティビティの数）だけ存在する。
なお、「第３のデータベース」には、スキーマ情報データベースが相当する。
【００５７】
（処理手順）
図１２は、第２の実施形態に係る、業務プロセス制御システム１、ストレージシステム２及び業務システム３が実行する処理手順を示したシーケンス図である。
図１２は、その殆どの部分が図８と共通している。よって、図８において説明した内容のうち以下に記載する部分のみを読み替えて、図１２の説明とする。
ちなみに、図８との相違点は、メッセージ３０５、３０６の内容、及び活性区間３５２、３５３の処理内容である。なお、「（１−６）」等のカッコ内の数字は、図８の説明におけるカッコ内の数字に対応している。
【００５８】
（１：処理手順の全体的概要）
（１−６）フレーム３０４の処理手順を実行する場合、業務プロセス制御システム１は、まず、メッセージ３０３に基づいて（例えば、メッセージ３０３の送信元を示す情報、送信先を示す情報又は受信ポートを示す情報等に基づいて）業務プロセス制御システム１の補助記憶装置１４を検索し、アクティビティ識別子を取得する。次に、パス情報取得メソッドを実行し、メッセージ識別子、パス情報を取得する。このメソッドの引数には、アクティビティ識別子を指定する（メッセージ３０５）。
図１２において、「○○＝◎◎（    ）」との記載は、「（  ）内の文字列等を引数として◎◎というメソッドを実行した結果として○○という情報を得る」ことを示すものとする（メッセージ３０９においても同様）。活性区間３５２については補足説明を後記する。
【００５９】
（１−７）続いて、業務プロセス制御システム１は、ストレージシステム２へ、メッセージ３０６（インスタンスＩＤ取得要求）を送信する。このメッセージ３０６の引数には、参照ＵＲＬ、前記（１−６）にて取得したメッセージ識別子、パス情報を指定する（メッセージ３０６）。
【００６０】
（１−８）ストレージシステム２は、メッセージ３０６を受信し、参照ＵＲＬ、メッセージ識別子、パス情報を取得する。
次に、ストレージシステム２は、参照ＵＲＬを検索キーとして登録データ管理情報データベース２６を検索して登録データを取得し、メッセージ識別子を検索キーとして、スキーマ情報データベース２８を検索してスキーマ情報を取得する。
さらに、登録データのデータ構造をスキーマ情報によって検証し、インスタンスＩＤ１０４をパス情報によって取得する。
参照ＵＲＬによって登録データを取得できない場合、データ構造に不正がある場合、又はインスタンスＩＤ１０４を取得できない場合は、エラーメッセージを返す。
インスタンスＩＤ１０４の取得に成功した場合は、メッセージ３０６の戻り値としてインスタンスＩＤ１０４をリターンする（リターン３０７）。
これらにより、不正な参照ＵＲＬや不正なデータ構造、不正なインスタンスＩＤを検知したことを、業務プロセス制御システム１へ通知することができる。活性区間３５２については補足説明を後記する。
【００６１】
（３：活性区間３５２（パス情報取得処理）の補足説明）
（３−２）受信処理部１６の受信制御機能は、アクティビティ識別子を検索キーとしてパス情報データベース１８ｂを検索し、メッセージ識別子、パス情報を取得する。
（３−３）受信処理部１６の受信制御機能は、メッセージ３０５の戻り値として、メッセージ識別子、パス情報をリターンする。
【００６２】
（４：活性区間３５３（インスタンスＩＤ取得処理）の補足説明）
図１２の活性区間３５３は、ストレージシステム２がインスタンスＩＤ取得要求（メッセージ３０６）を受信したときの処理である。
（４−１）データ管理部２７のインスタンスＩＤ取得機能は、メッセージ３０６を受信し、参照ＵＲＬ、メッセージ識別子、パス情報を取得する。
（４−２）データ管理部２７のインスタンスＩＤ取得機能は、参照ＵＲＬを検索キーとして、登録データ管理情報データベース２６を検索し、登録データ（業務データ１０１）を取得する。
データ管理部２７のインスタンスＩＤ取得機能は、参照ＵＲＬが検索キーとして扱えない文字列の場合、又は、検索の結果該当する登録データが存在しない場合は、業務プロセス制御システム１に対してメッセージ３０６の戻り値の戻り値としてエラーメッセージをリターンする。
（４−３）前記（４−２）において、登録データを取得することができた場合は、データ管理部２７のインスタンスＩＤ取得機能は、前記（４−１）にて取得したメッセージ識別子を検索キーとして、スキーマ情報データベース２８を検索して、スキーマ情報を取得する。
データ管理部２７のインスタンスＩＤ取得機能は、当該スキーマ情報により登録データ（業務データ１０１）のデータ構造を検証する。
検証の結果、登録データ（業務データ１０１）のデータ構造に不正がある場合は、データ管理部２７のインスタンスＩＤ取得機能は、業務プロセス制御システム１に対してメッセージ３０６の戻り値としてエラーをリターンする。
【図面の簡単な説明】
【００６３】
【図１】第１の実施形態に係る全体構成図である。
【図２】第１の実施形態に係る業務プロセス定義画面の一例を示す図である。
【図３】第１の実施形態に係る業務プロセス制御システムと業務システムの関連を、受発注業務プロセスを例にＢＰＭＮにより定義した概念図である。
【図４】第１の実施形態に係る業務データの一例を示す図である。
【図５】第１の実施形態に係る業務データの他の一例を示す図である。
【図６】第１の実施形態に係る登録データ管理情報データベースの一例を示す図である。
【図７】第１の実施形態に係るパス情報データベースの一例を示す図である。
【図８】第１の実施形態に係る、業務プロセス制御システム、ストレージシステム及び業務システムが実行する処理手順を示したシーケンス図である。
【図９】第２の実施形態に係る全体構成図である。
【図１０】第２の実施形態に係るパス情報データベースの一例を示す図である。
【図１１】第２の実施形態に係るスキーマ情報データベースの一例を示す図である。
【図１２】第２の実施形態に係る、業務プロセス制御システム、ストレージシステム及び業務システムが実行する処理手順を示したシーケンス図である。
【符号の説明】
【００６４】
１      業務プロセス制御システム
２      ストレージシステム
３      業務システム
４      ネットワーク
１０、２０  中央制御装置（制御部）
１３、２３  主記憶装置（記憶部）
１４、２４  補助記憶装置（記憶部）
１６    受信処理部
１７    プロセス制御部
１８ａ、１８ｂ  パス情報データベース（第１のデータベース）
１９    プロセス定義情報データベース
２６    登録データ管理情報データベース（第２のデータベース）
２７    データ管理部
２８    スキーマ情報データベース（第３のデータベース）
５０    業務プロセス定義画面
６０    アクティビティ定義画面
１０１、１１１  業務データ
１０４  インスタンスＩＤ（第１の識別子）
２０３  参照ＵＲＬ（参照情報）
２１１  アクティビティ識別子（第２の識別子）
２３２  メッセージ識別子（第３の識別子）
【図１】
2009187174.tif 000003
【図２】
2009187174.tif 000004
【図３】
2009187174.tif 000005
【図４】
2009187174.tif 000006
【図５】
2009187174.tif 000007
【図６】
2009187174.tif 000008
【図７】
2009187174.tif 000009
【図８】
2009187174.tif 000010
【図９】
2009187174.tif 000011
【図１０】
2009187174.tif 000012
【図１１】
2009187174.tif 000013
【図１２】
2009187174.tif 000014