JP2008532154A - ワークフローを処理するための方法、コンピュータ・プログラム、およびシステム（ワークフロー・システムへのデータ管理動作の統合） - Google Patents

Abstract

【課題】 ワークフローを処理するための技法を提供することにある。
【解決手段】 １つまたは複数のデータ管理アクティビティを含むワークフローが受信される。１つまたは複数のデータ管理アクティビティの記述を含むワークフロー記述がそのワークフローから生成される。１つまたは複数のデータ管理動作がワークフロー記述から生成される。１つまたは複数のデータ管理動作が１つまたは複数のデータ管理システムに対して実行される。
【選択図】 図１

Description

本発明の諸実施形態は、ワークフロー・システムへのデータ管理動作の統合に関する。

ワークフロー管理システム（ＷＦＭＳ：workflowmanagement system）は、ビジネス・プロセス（businessprocess）のモデリングおよび実行をサポートするものであり、「ワークフロー・システム（workflow system）」と呼ばれる場合もある。ビジネス・プロセスは、複数の作業部分（pieces of work）からなるネットワークのうちのどの作業部分をどの順序で実行し、その作業部分を実行するためにどのリソースを活用するかを指定する。個々の作業部分は、何らかのタイプのネットワークによって接続された多数の異なるコンピュータ・システム全域に分散させることができる。

ＩＢＭ（Ｒ）のＭＱＳｅｒｉｅｓ（Ｒ）Ｗｏｒｋｆｌｏｗという製品（インターナショナル・ビジネス・マシーンズ社から入手可能）などの強力で高度なワークフロー管理システムは、複数のアクティビティからなるネットワークとして、ビジネス・プロセスのモデリングをサポートする。このアクティビティ・ネットワーク（network of activities）、すなわち、プロセス・モデルは、有向非周期加重カラー・グラフ（directed, acyclic, weighted, colored graph）をメタ・モデルとして使用して構築される。このグラフのノードは、実行すべき個々のタスクを定義するアクティビティを表している。プロセス・モデルを構築するために、階層メタ・モデルなどの任意の他のメタ・モデルを使用することもできる。一般に、それぞれのアクティビティは、そのアクティビティに関する適切なタスクを実現する１つのコードに関連付けられている。このグラフのエッジ、すなわち、制御リンク（control link）は、アクティビティの潜在的な実行順序を記述するものである。制御リンクは矢印として表され、矢印の先端は、制御の流れがプロセス中を移動する方向を記述する。

制御リンクが始まるアクティビティはソース・アクティビティ（source activity）と呼ばれ、制御リンクが終わるアクティビティはターゲット・アクティビティ（target activity）と呼ばれる。１つのアクティビティは、種々の制御リンクに関するソース・アクティビティおよびターゲット・アクティビティになる可能性がある。いかなる着信制御リンクも備えていないアクティビティは、プロセスを開始するものであるので、開始アクティビティ（start activity）と呼ばれる。いかなる発信制御リンクも備えていないアクティビティは、その完了後にプロセスが終了するので、終了アクティビティ（end activity）と呼ばれる。１つのアクティビティは、開始アクティビティとともに終了アクティビティになる可能性がある。複数の発信制御リンクを有するアクティビティはフォーク・アクティビティ（fork activity）と呼ばれ、複数の制御リンクを有するアクティビティは結合アクティビティ（join activity）と呼ばれる。

種々のワークフロー言語が使用可能であり、ビジネス・プロセス実行言語（ＢＰＥＬ：Business Process Execution Language）はこのようなワークフロー言語の１つである。ＢＰＥＬは、複数のＷｅｂサービスの組み合わせを使用して分散コンピューティング環境用のタスク共用を可能にするＸＭＬベースの言語として記述することができる。「ＢＰＥＬ」という用語は、Ｗｅｂサービス用ビジネス・プロセス実行言語（ＢＰＥＬ４ＷＳ：Business Process Execution Language for Web Services）またはＢＰＥＬＷＳなど、この言語の他のバージョンを指すために使用される場合もある。また、ＢＰＥＬは、ビジネス・プロセス・アクティビティを記述し、コレオグラフィ化（choreograph）するための標準として記述することもできる。ＷｅｂＳｐｈｅｒｅ（Ｒ）Ｂｕｓｉｎｅｓｓ Ｉｎｔｅｇｒａｔｉｏｎ（ＷＢＩ）という製品（インターナショナル・ビジネス・マシーンズ社から入手可能）は、ＢＰＥＬベースのビジネス・プロセスを設計し実行するための実現例を提供する。ＷＢＩのコンポーネントの１つは、ＷｅｂＳｐｈｅｒｅ（Ｒ）Ｐｒｏｃｅｓｓ Ｃｈｏｒｅｏｇｒａｐｈｅｒ（ＷＰＣ）ワークフロー・システムと命名されている。

Ｗｅｂという用語は、ハイパーテキスト・マークアップ言語（ＨＴＭＬ：HyperText Markup Language）でフォーマットされた文書をサポートする複数のインターネット・サーバからなるグループとして記述可能なワールド・ワイド・ウェブを指すために使用される。Ｗｅｂサービス（「アプリケーション・サービス（application service）」とも呼ばれる）は、典型的にはＷｅｂに接続されたプログラムによって呼び出され、Ｗｅｂサーバから使用可能になっているサービスとして記述することができる。

ＢＰＥＬ４ＷＳは、Ｗｅｂサービスに基づいてビジネス・プロセス動作を指定するための表記法を定義する（２００３年５月５日付けの「Business Process Execution Language for WebServices Specification」の Version1.1、以下「ＢＰＥＬ４ＷＳ規格」という）。ＢＰＥＬ４ＷＳ規格には、ビジネス・プロセスは、ビジネス対話の参加者の実際の動作をモデリングする実行可能なビジネス・プロセスとして記述するか、またはそれぞれの内部動作を暴露せずに、プロトコルに関わるそれぞれの当事者の相互可視メッセージ交換動作（mutually visible message exchange behavior）を指定するプロセス記述を使用するビジネス・プロトコルとして記述することができることが示されている。

ＢＰＥＬ４ＷＳ規格によれば、ＢＰＥＬ４ＷＳは、ビジネス・プロセスおよびビジネス対話プロトコルの形式仕様に関する言語を提供し、企業内空間およびビジネス・トゥー・ビジネス（企業間取引）空間の両方で自動プロセス統合の拡張を容易にする相互運用可能な統合モデルを定義する。また、ＢＰＥＬ４ＷＳ規格は、サポートされるアクティビティも定義する。

従来のワークフロー・システムでは、ワークフロー・システム内からデータ管理システムへのアクセスが不必要に複雑である。従来のワークフロー・システムは、以下の手法のうちの１つまたは両方を提供する。
１．データ管理動作は、たとえば、何らかのＪａｖａ（登録商標）（Ｒ）コードを作成し、データ管理システムによって提供されたアプリケーション・プログラミング・インターフェース（ＡＰＩ：Application Programming Interface）を活用することにより、伝統的なプログラミング言語でコーディングしなければならない。（Ｊａｖａ（登録商標）ならびにすべてのＪａｖａ（登録商標）ベースの商標およびロゴは、米国、その他の国、またはその両方におけるサン・マイクロシステムズ社の商標である。）
２．データ管理動作は、Ｗｅｂサービスを介して提供しなければならない。

たとえば、ＷＰＣワークフロー・システムは、いずれの手法もサポートしている。ＷＰＣワークフロー・システムでは、Ｊａｖａ（登録商標）コードを介してプロセス・アクティビティを実現することが可能になり、Ｗｅｂサービスをプロセス・アクティビティとして使用することが可能になる。

第１の手法を使用する場合、ＷＰＣユーザはＪａｖａ（登録商標）アクティビティをコーディングしなければならない。ユーザは、構造化照会言語（ＳＱＬ：Structured Query Language）ならびにユーザがＪａｖａ（登録商標）環境内からＳＱＬステートメントを発行できるようにするＪａｖａ（登録商標） Ｄａｔａｂａｓｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ（ＪＤＢＣ）ＡＰＩに関する知識に加えて、Ｊａｖａ（登録商標）開発知識も備えていなければならない。ＳＱＬステートメント自体は単一行のコードに収まるものである。しかし、ＪＤＢＣを介してＳＱＬステートメント（ある種の「照会」）を発行し、ＷＰＣワークフロー・システム変数から入力パラメータを取得し、照会に入力パラメータを供給し、照会の結果をＷＰＣワークフロー・システム変数に書き込むには、作成すべき大量のコードと、コーディングを実行するための大量の時間を必要とする。

第２の手法を使用する場合、ＷＰＣワークフロー・システム・ユーザは、ＳＱＬステートメントをコーディングし、そのＳＱＬステートメントをＷｅｂサービス内に折り返さなければならない。これを達成するために、多くのステップと種々の製品が必要である可能性がある。ユーザがどのようにＷｅｂサービスを構築したかとは無関係に、必要な入力をＷｅｂサービスに提供し、結果を処理するために、２つの追加アクティビティ（「割り当て」アクティビティ）をビジネス・プロセスに追加する必要がある場合もある。

データ管理システムにアクセスすることはビジネス・プロセスのための典型的なアクティビティであるが、いずれの手法もユーザにとって厄介なものである。

その上、ＢＰＥＬによって表されるものなどのワークフローは、一連の処理アクティビティを表している。最も一般的に、これらのアクティビティは、一度に単一のデータ・レコードに対して機能する。しかし、シナリオ数が増加すると、一度に１つのレコードではなく、複数組のレコード・セット（「セット」とも呼ばれる）に対して機能する方が好ましい。このパターンは、データを処理するためにデータ・ウェアハウジング（Data Warehousing）アプリケーションで使用される抽出変換ロード（ＥＴＬ：Extract Transform Load）パターンと同様のものである。ＥＴＬにより、１組のレコード・セットがデータベースから検索（「抽出」）され、処理（「変換」）され、データベースにロードされる。

したがって、何らかのセット単位（set-oriented）の動作をレコード単位（record-oriented）の動作と混合するためにワークフロー・エンジンを使用することは有用である。最も多くの場合、これらのセット・アクティビティは、実際には１つまたは複数のデータ・ソース（たとえば、リレーショナル・データベース）からの情報の処理である。たとえば、あるアクティビティは、データベース照会の一部として１つまたは複数のデータ・ソースから情報を検索または更新することができる。従来のワークフロー・システムでは、一連のこのようなアクティビティを実行するために、ワークフロー・エンジンは通常、完全な１組のデータ・セットをマテリアライズ（すなわち、１つまたは複数のデータ・ソースからの情報のすべてを検索）し、データをコピーすることにより、この１組のデータ・セットを他のアクティビティに渡さなければならず、そのアクティビティはその処理を実行し、その１組のデータ・セットをさらに他のアクティビティなどに渡す。したがって、データ・アクティビティ間で完全な１組のデータ・セットがコピーされ渡される。コピーにより大きいセットを渡すことは、非効率的であり、開発しにくいことであるので、パフォーマンス上の理由で受け入れ可能なものではない。

従来のビジネス・プロセス・ランタイム・システムには、データ管理動作の設計および実行に関して、いくつかの弱点がある。たとえば、従来のビジネス・プロセス・ランタイム・システムでは、データ管理アクティビティが対向しなければならないセット（たとえば、テーブル）が、ビジネス・プロセスを実行する前にすでに既知である（すなわち、設計または配備時に指定されている）という静的環境を想定している。

アプリケーションによっては、静的データ管理環境を想定することが受け入れ可能であるが、このような想定は、関心のあるデータの選択が、たとえば、サービス・レベル・アグリーメント（Service Level Agreement）によって決まる可能性のある動的なオンデマンド・アプリケーション・シナリオの場合、受け入れ可能ではない可能性がある。オンデマンド・アプリケーション・シナリオでは、異なるサービス品質（Quality of Service）特性を有するいくつかの場所にデータが冗長に保管されるデータ管理環境が存在する可能性がある。オンデマンド・アプリケーションは、それぞれのユーザとの契約通りのサービス・レベル・アグリーメント次第で、異なるユーザのために異なるデータ・ソースを選択する必要がある場合もある。データ・ソースの選択は、たとえば、それぞれのデータ・ソースのアクセス時間、可用性、または陳腐性、あるいはこれらの組み合わせによって決まる可能性がある。
２００３年５月５日付けの「Business Process Execution Language forWeb Services Specification」の Version 1.1

したがって、多くのオンデマンド・アプリケーションは、ランタイム時にどのデータ・ソースを使用すべきかに関する決定の延期を直接可能にするワークフロー・システムの恩恵を受けるであろう。

ワークフローを処理するための方法、コンピュータ・プログラム、およびシステムが提供される。１つまたは複数のデータ管理アクティビティを含むワークフローが受信される。１つまたは複数のデータ管理アクティビティの記述を含むワークフロー記述がそのワークフローから生成される。１つまたは複数のデータ管理動作がワークフロー記述から生成される。１つまたは複数のデータ管理動作が１つまたは複数のデータ管理システムに対して実行される。

好ましくは、データ管理動作をワークフロー・システムと統合する解決策が提供される。

次に、例証としてのみ、添付図面に関連して、本発明の諸実施形態について説明する。

同様の参照番号は、一貫して、対応する部分を表している。

以下の説明では、本明細書の一部を形成し、いくつかの諸実施形態を例示する添付図面を参照する。他の諸実施形態を使用することができ、本発明の範囲を逸脱せずに構造上および動作上の変更を行えることは言うまでもないことである。

図１は、特定の諸実施形態を実現可能なワークフロー・システム１００の詳細を例示している。コンピューティング・デバイス１１０は、ユーザがワークフロー（たとえば、図３の３１０）のグラフィック表現を作成できるようにするためのワークフロー設計タイム・システム１２０を含む。ワークフロー設計タイム・システム１２０は、ワークフローのグラフィック表現からワークフロー記述１３０を生成するワークフロー記述エディタ１２２を含む。ワークフロー記述１３０は、ワークフロー・ランタイム・システム１５０を含むコンピューティング・デバイス１４０に経路指定される。ワークフロー・ランタイム・システム１５０は、ワークフロー記述１３０を実行することができる。ワークフロー・ランタイム・システム１５０は、ワークフロー記述１３０に統合されたデータ管理動作を処理するために使用されるデータ管理動作サポート・コンポーネント１５２を含む。データ管理動作は、１つまたは複数のデータ管理システム１６０ａ・・・１６０ｎに対してサブミットされる（省略符号は、データ管理システム１６０ａおよび１６０ｎに加えて任意の数のデータ管理システムが存在しうることを示している）。データ管理システム１６０ａ・・・１６０ｎは、データへのアクセスを可能にするコンピューティング・デバイス（たとえば、サーバ・コンピュータ）として記述することができる。

アクティビティという用語はワークフローの「ノード」（たとえば、図３のＣｈｅｃｋＩｔｅｍＩｎＳｔｏｃｋ３２０）を指し、「動作（operation）」という用語はデータ管理システム１６０ａ・・・１６０ｎに対して実行されるステートメント（すなわち、入力パラメータおよび入力セット参照が対応する値で置き換えられているステートメント）を指す。１つのアクティビティの実行は、いくつかの動作を必要とする可能性がある。

図２は、特定の諸実施形態によりデータ管理動作をワークフロー・システムに統合するためのロジックを例示している。制御は、諸実施形態によって提供された１つまたは複数のデータ管理アクティビティを含むワークフロー（「制御フロー（control flow）」とも呼ばれる）の作成をユーザが完了したという表示をワークフロー設計タイム・システム１２０が受信するブロック２００から始まる。とりわけ、諸実施形態は、ワークフロー言語（たとえば、ＢＰＥＬ）に対する拡張機能として新しいデータ管理アクティビティ・グループを提供する。データ管理アクティビティにより、ワークフロー・システム内からデータ管理システム１６０ａ・・・１６０ｎ（たとえば、リレーショナル・データベース・システム）へのアクセスならびにデータ管理システム１６０ａ・・・１６０ｎの管理が可能になる。

データ管理アクティビティは、セットに対して機能することができ、これを可能にするために、諸実施形態はセット参照にライフ・サイクル属性を提供する。したがって、データ管理アクティビティは、ライフ・サイクル属性を有するセット参照を含むことができる。セット参照は、（ビジネス・プロセス内ではなく）データ管理システム内に存在する１組のデータ・セットへのインジケータ（たとえば、ポインタ）として記述することができる。セット参照は、データ管理システムにアクセスし、対応するセットを管理するために必要な情報を含む。セット参照を使用することにより、諸実施形態は、アクティビティ間で大きい情報セットを渡すことを回避する。また、諸実施形態は、たとえば、１つのセットがどのくらいの長さ、使用可能でありうるか、ならびにそのセットをいつ廃棄すべきかを決定するライフ・サイクル属性をユーザが選択できるようにすることにより、セットに関するライフ・サイクル管理サポートを提供する。

データ管理アクティビティとしては、たとえば、構造化照会言語（ＳＱＬ）アクティビティ、マテリアライズ・アクティビティ、およびシステム・コマンド・アクティビティを含む。ＳＱＬアクティビティの例としては、選択（select）、選択導入（selectinto）、呼び出し（call）、挿入（insert）、更新（update）、削除（delete）、マージ（merge）、値（values）、値導入（valuesinto）、およびデータ定義言語（ＤＤＬ：DataDefinition Language）動作を含む。ＤＤＬ動作としては、たとえば、作成（create）、変更（alter）、ドロップ（drop）、リフレッシュ（refresh）、取り消し（revoke）、付与（grant）、および設定（set）を含む。マテリアライズ・アクティビティは、セット参照の内容を（たとえば、ＸＭＬ文書として）ワークフロー・システムにとって使用可能なものにする。システム・コマンド・アクティビティの例としては、データ管理システム開始（start data management system）、データ管理システム停止（stop data management system）、バックアップ（backup）、リストア（restore）、再編成（reorganize）、および実行統計（runstats）を含む。

さらに、諸実施形態は、ユーザが新しいアクティビティ・タイプを追加できるようにする拡張性メカニズムを提供する。また、各アクティビティ・タイプは、データ管理システムの１つまたは複数の動作にマッピングすることができる。たとえば、新しいアクティビティが「リモート・システムからのデータのロード（Load data from remote system）」になる可能性があり、この新しいアクティビティを実行した結果、いくつかの動作がデータ管理システムで実行される（たとえば、いくつかの作成動作に続いて１つの選択動作が行われる）。

その上、諸実施形態により、ビジネス・プロセス変数をデータ管理アクティビティに関する入力パラメータまたは出力パラメータあるいはその両方として使用することができる。ビジネス・プロセス変数は、ワークフロー言語変数（たとえば、ＢＰＥＬ変数）として記述することができる。

さらに、諸実施形態により、ランタイム時にデータ・ソースの選択を可能にするデータ・ソース定義が可能になる。

既存のワークフロー言語は、このようなデータ管理動作、セット参照、またはセット参照に関するライフ・サイクル管理を含まない。その上、既存のワークフロー言語は、諸実施形態によって提供される通り、アクティビティに関するパラメータとしてのビジネス・プロセス変数の拡張使用を提供しない（すなわち、既存のワークフロー言語にはビジネス・プロセス変数の使用に関する制限がある場合が多い（たとえば、ＢＰＥＬでのＷｅｂサービス・アクティビティは、入力としての単一変数と、出力としての単一変数のみを有することができる））。また、既存のワークフロー言語は、ランタイム時にデータ・ソース選択を使用可能にしない。

データ管理動作が容易に呼び出され、データ管理システムとワークフロー・システムとの間でセットの形での情報の共用を可能にするように、新しいデータ管理アクティビティを提供し、追加のアクティビティの作成を可能にすることにより、諸実施形態はワークフロー・システムにデータ管理動作を統合する。

その上、データ管理アクティビティを含むようにワークフロー言語を拡張し、データをマテリアライズする必要なしにデータ・セットを参照するセット参照を提供することにより、諸実施形態は、単一ワークフロー内でレコード単位のアクティビティとセット単位のアクティビティの混合を可能にする。また、諸実施形態により、データ管理アクティビティをワークフロー記述の一部として（たとえば、ワークフロー記述内のＳＱＬステートメントとして）「インライン（inline）」で指定することができる。

図２に戻ると、ブロック２０２で、ワークフロー記述エディタ１２２は、ワークフローからワークフロー記述を自動的に生成する。ワークフロー記述は１つまたは複数のデータ管理アクティビティの記述を含む。選択された場合、ワークフロー記述は、任意のセット参照とそのライフ・サイクル属性、入力パラメータまたは出力パラメータあるいはその両方として使用されるビジネス・プロセス変数、およびデータ・ソース定義の記述も含む。

ブロック２０４で、ワークフロー・ランタイム・システム１５０は、ワークフロー記述から１つまたは複数のデータ管理動作（たとえば、１つまたは複数のＳＱＬ照会）を自動的に生成する。ブロック２０６で、ワークフロー・ランタイム・システム１５０は、１つまたは複数のデータ管理システム１６０ａ・・・１６０ｎに対して１つまたは複数のデータ管理動作を実行する。特定の諸実施形態では、単一のデータ管理システム１６０ａ・・・１６０ｎに対して１つのアクティビティがサブミットされ、そのアクティビティに付加されたデータ・ソース定義（複数も可）次第で、異なるデータ管理システム１６０ａ・・・１６０ｎに対して異なるデータ管理動作を実行することができる。ブロック２０８で、照会の結果がワークフロー・ランタイム・システム１５０に返される。

単に本発明の理解を強化するために、本明細書の例では、ＢＰＥＬベースのワークフロー・システムへのＳＱＬ動作の統合に言及する場合もある。特定の諸実施形態では、ＳＱＬ動作は、ＷｅｂＳｐｈｅｒｅ（Ｒ）Ｐｒｏｃｅｓｓ Ｃｈｏｒｅｏｇｒａｐｈｅｒ（ＷＰＣ）ワークフロー・システムに統合される。

諸実施形態の技法は、その他のタイプのデータ管理動作ならびにその他のタイプのセットおよびデータ管理システム（たとえば、ＸＭＬデータベース・システムおよびコンテンツ・マネージメント・システム）を包含するように拡張することができる。また、その技法は、ＸＱｕｅｒｙ（拡張可能マークアップ言語（ＸＭＬ）照会言語である）およびＸＭＬデータベース・システムに保管されたＸＭＬ文書の集合と、コンテンツ・アクセス操作動作および文書管理システムに保管された文書のセットに拡張することができる。ワークフロー・システムに関しては、諸実施形態の技法は、ＢＰＥＬに基づかない他のサービスサービス指向ワークフロー・システムに拡張することができる。すなわち、諸実施形態の技法は、任意のワークフロー言語（たとえば、書式定義マークアップ言語（ＦＤＭＬ：Forms Definition Markup Language）またはＸＬＡＮＧ（マイクロソフト社による規格））とともに使用することができる。

図３は、特定の諸実施形態によりワークフロー設計タイム・システム１２０によって提供される表示内容を例示している。ユーザはワークフロー３１０のグラフィック表現を作成することができる。図３のワークフロー３１０は、所与の在庫品目（item in stock）の可用性をチェックする「ＣｈｅｃｋＩｔｅｍＩｎＳｔｏｃｋ」データ管理アクティビティ３２０を含む。ワークフロー３１０では、遷移条件によってチェックされるように、在庫品目がまったく残っていない場合、新しい品目を注文するためのＷｅｂサービスが呼び出される。ワークフロー３１０は、その品目の在庫がない場合にＷｅｂサービスの出力を返し、その品目の在庫がある場合にデフォルト値を返す。

画面区画３３０は、ワークフロー記述１３０の一部であるＳＱＬステートメントをユーザが直接指定できるようにするワークフロー設計タイム・システム１２０を使用して構築されたＳＱＬステートメントを例示している。ＩｔｅｍＣｏｕｎｔおよびｉｔｅｍｉｄリンクは、ビジネス・プロセス変数にリンクされる入力／出力パラメータをそれぞれ指している。ＩｔｅｍＴａｂｌｅリンクは入力セット参照を指している。ユーザがこれらのリンクを選択（たとえば、クリック）すると、そのパラメータまたは参照セットをそれぞれ更新するために、ワークフロー設計タイム・システム１２０の諸実施形態によってウィザードが提供される。新しいパラメータおよびセット参照は、「Ｎｅｗ」ボタン３４０を選択することによって作成することができる。すなわち、新しいパラメータおよびセット参照（たとえば、入力または出力セット参照）は、ビジネス・プロセス変数（たとえば、ＢＰＥＬ変数またはプロパティあるいはその両方）にマッピングすることができる。また、ｖａｒｉａｂｌｅ＝ＤａｔａＳｏｕｒｃｅ ｐａｒｔ＝ｍｙＤａｔａＳｏｕｒｃｅというステートメントは、ＳＱＬステートメントに関するデータ・ソースが「ＤａｔａＳｏｕｒｃｅ」ビジネス・プロセス変数の「ｍｙＤａｔａＳｏｕｒｃｅ」部分によって識別されることを示している。

「ＣｈｅｃｋＩｔｅｍＩｎＳｔｏｃｋ」データ管理アクティビティ３２０によって使用すべき特定のデータ・ソースを指定するために、ユーザは、「ＣｈｅｃｋＩｔｅｍＩｎＳｔｏｃｋ」データ管理アクティビティ３２０を選択し、「ｄｅｆｉｎｅ ｄａｔａ ｓｏｕｒｃｅ」ボタンを選択すると、その結果、Ｄａｔａ Ｓｏｕｒｃｅ Ｄｅｆｉｎｉｔｉｏｎ Ｗｉｚａｒｄ（データ・ソース定義ウィザード）４００が表示される（図４）。次にユーザは、（たとえば、ビジネス・プロセス変数またはビジネス・プロセス変数の一部４３０へのマッピングを指定することにより）データ・ソース・タイプ４１０を提供することができる。代わってユーザは、データ・ソース定義をインラインで提供することもできる。したがって、ＳＱＬアクティビティに関するデータ・ソースは、そのデータ・ソースをビジネス・プロセス変数（たとえば、ＢＰＥＬ変数）またはビジネス・プロセス変数の一部（たとえば、ＢＰＥＬ変数の一部）にマッピングすることにより指定することができる。

また、諸実施形態により、入力セット参照をビジネス・プロセス変数（たとえば、ＢＰＥＬ変数）またはビジネス・プロセス変数の一部（たとえば、ＢＰＥＬ変数の一部）にマッピングすることができる。図５は、ビジネス・プロセス変数および部分５２０へのマッピングを可能にする、特定の諸実施形態によるＡｄｄ ｏｒ Ｅｄｉｔ Ａｎ ＩｎｐｕｔＳｅｔＲｅｆｅｒｅｎｃｅ（ＩｎｐｕｔＳｅｔＲｅｆｅｒｅｎｃｅの追加または編集）画面５００を例示している。「ＣｈｅｃｋＩｔｅｍＩｎＳｔｏｃｋ」データ管理アクティビティ３２０によって使用すべき入力セット参照およびライフ・サイクル属性を指定するために、ユーザは、「ＣｈｅｃｋＩｔｅｍＩｎＳｔｏｃｋ」データ管理アクティビティ３２０を選択し、「Ｎｅｗ」ボタン３４０を選択すると、その結果、Ａｄｄ ｏｒ Ｅｄｉｔ ａｎ ＩｎｐｕｔＳｅｔＲｅｆｅｒｅｎｃｅ画面５００が表示される。Ａｄｄ ｏｒ Ｅｄｉｔ ａｎ ＩｎｐｕｔＳｅｔＲｅｆｅｒｅｎｃｅ画面５００では、ユーザは、ビジネス・プロセス変数および部分５２０を識別し、クリーンアップ５１０が必要であるかどうか、ならびにどの時点でクリーンアップを実行しなければならないかなどのライフ・サイクル属性を識別する。

「ＣｈｅｃｋＩｔｅｍＩｎＳｔｏｃｋ」データ管理アクティビティは、ワークフロー記述でインラインＳＱＬを使用して指定される。以下のサンプル擬似コードＡは、「ＣｈｅｃｋＩｔｅｍＩｎＳｔｏｃｋ」データ管理アクティビティに関するワークフロー記述を例示している。
擬似コードＡ

擬似コードＡのデータ管理アクティビティ・ステートメント要素（「ｄａｔａＭａｎａｇｅｍｅｎｅｎｔＡｃｔｉｖｉｔｙ」）は、データ・ソース定義要素（「ｄａｔａＳｏｕｒｃｅ」）とボディ要素（「ｂｏｄｙ」）とを含む。

データ・ソース定義要素は、実際のデータ・ソース定義を含むＢＰＥＬ変数（「ｍｙＤａｔａＳｏｕｒｃｅ」）を指す。

ステートメントのボディ要素内に定義されたＳＱＬは、データ・ソース定義要素によって識別されたデータ・ソースに対して実行される。とりわけ、ボディ要素は、ＳＱＬの「ＳＥＬＥＣＴ ＩＮＴＯ」ステートメントを定義する。ＳＱＬトークンは、ｓｅｔＲｅｆｅｒｅｎｃｅおよびパラメータ要素と混合される。ｓｅｔＲｅｆｅｒｅｎｃｅ要素は、実際のデータベース・テーブルを決定するために使用されるセット参照定義を含むＢＰＥＬ変数「ＳｅｔＲｅｆｅｒｅｎｃｅ」を指す。入力パラメータは、ＳＱＬステートメントのｗｈｅｒｅ節に使用すべきｉｔｅｍｉｄを含むＢＰＥＬ変数「ＩｎｐｕｔＶａｒｉａｂｌｅ」を指す。このステートメントの結果は、出力パラメータによって定義された通り、変数「ＩｔｅｍＣｏｕｎｔ」に保管される。その上、セット参照は、ｃｌｅａｎｕｐ＝“ｎｏ”およびｐｒｅｐａｒａｔｉｏｎ＝“ｎｏ”というライフ・サイクル・オプションを有し、後者は、セット参照を使用するためにいかなる準備も不要であり、対応するセットが削除されないことを示す。「ＩｔｅｍＣｏｕｎｔ．ｇｅｔ（“ｍｙｉｎｔ”） ＝＝ ０」という遷移条件は、「ＣｈｅｃｋＩｔｅｍＩｎＳｔｏｃｋ」データ管理アクティビティの結果をチェックすることにより、Ｗｅｂサービスを呼び出す必要があるかどうかをチェックする。

ワークフロー・ランタイム・システム１５０は、その後、データ管理システム１６０ａ・・・１６０ｎに対して実行可能なデータ管理動作（たとえば、ＳＱＬ照会）を擬似コードＡから生成する。実行のために生成されるデータ管理動作は、任意の入力パラメータおよび入力セット参照に関する値によって決まる。

とりわけ、ワークフロー・ランタイム・システム１５０における「ＣｈｅｃｋＩｔｅｍＩｎＳｔｏｃｋ」アクティビティの実行は、データ管理動作サポート・コンポーネント１５２がこのアクティビティのワークフロー記述ならびにプロセスのコンテキストを受信することを含む。コンテキストは、ＢＰＥＬ変数とプロパティとを含む。データ管理動作サポート・コンポーネント１５２は、まず、入力パラメータと入力セット参照変数の有無をチェックし、指定されたＢＰＥＬ変数から対応する値を入手する。たとえば、ｉｔｅｍｉｄはＢＰＥＬ変数「ＩｎｐｕｔＶａｒｉａｂｌｅ」から抽出される。この例では、整数の値が１３５であると想定する。選択（select）照会で使用されるテーブルの名前は、ＢＰＥＬ変数「ＳｅｔＲｅｆｅｒｅｎｃｅ」の「ｍｙＳｅｔＲｅｆｅｒｅｎｃｅ」部分から抽出される。この例では、テーブルの名前が「ＩＴＥＭＳ」であると想定する。

データ管理動作サポート・コンポーネント１５２は、それに対して照会を実行しなければならないデータ・ソースを決定する。この例では、データ・ソースは、ＢＰＥＬ変数「ＤａｔａＳｏｕｒｃｅ」の「ｍｙＤａｔａＳｏｕｒｃｅ」部分の内容によって指定される。この例の場合、その値が「ｊｄｂｃ／ｓａｍｐｌｅ」というｊｎｄｉ名であると想定する。データ管理動作サポート・コンポーネント１５２は、データ・ソース「ｊｄｂｃ／ｓａｍｐｌｅ」との接続を作成し、入力パラメータおよび入力セット参照がＢＰＥＬ変数から抽出された値で置き換えられているＳＱＬステートメントを実行する。生成される照会例は以下の通りである。

データ管理動作サポート・コンポーネント１５２は、ＢＰＥＬ変数「ＩｔｅｍＣｏｕｎｔ」に「ＯＵＴＰＵＴＰＡＲＡＭＥＴＥＲ１」という値を書き込む。

理解しやすくするため、単純化されたワークフロー・ランタイム・システム１５０において「ＧｅｔＥｕｒｏｐｅａｎＯｒｄｅｒｓ」アクティビティの第１のステートメントを実行する他の例が提供される。この例では、ワークフロー・ランタイム・システム１５０におけるデータ管理動作サポート・コンポーネント１５２は、アクティビティの記述ならびにプロセスのコンテキストを受信する。このコンテキストは、ＢＰＥＬ変数とプロパティティとを含む。

データ管理動作サポート・コンポーネント１５２は、まず、入力パラメータと入力セット変数の有無をチェックする。この例には、入力セット参照が存在する。ＳＥＬＥＣＴ照会で使用されるテーブルの名前は、ＢＰＥＬ変数「ＳｅｔＲｅｆｅｒｅｎｃｅ＿ＯｒｄｅｒｓＥｕｒｏｐｅ」の「ｍｙＳｅｔＲｅｆｅｒｅｎｃｅ」部分から抽出される。この例の場合、テーブルの名前が「ＩＮＰＵＴ．ＥＵＲＯＰＥＡＮＯＲＤＥＲＳ」であると想定する。

データ管理動作サポート・コンポーネント１５２は、それに対して照会を実行しなければならないデータ・ソースを決定する。この例では、データ・ソースは、ＢＰＥＬ変数「ＤａｔａＳｏｕｒｃｅＶａｒｉａｂｌｅ」の「ｍｙＤａｔａＳｏｕｒｃｅ」部分の内容によって指定される。この例の場合、その値が「ｊｄｂｃ／ｓａｍｐｌｅ」というｊｎｄｉ名であると想定する。データ管理動作サポート・コンポーネント１５２は、データ・ソース「ｊｄｂｃ／ｓａｍｐｌｅ」との接続を作成し、以下のＳＱＬステートメントを実行する。

指定された結果セット参照が存在する。したがって、データ管理動作サポート・コンポーネント１５２は、変数「ＲｅｓｕｌｔＳｅｔＲｅｆｅｒｅｎｃｅ＿Ｅｕｒｏｐｅ」の「ｍｙＳｅｔＲｅｆｅｒｅｎｃｅ」部分によって指定されたテーブルにこの照会の結果を書き込む。このテーブルのためにライフ・サイクル管理オプションが指定される。このテーブルは、現行プロセスの存続期間の終了時にデータ管理システムから削除される予定である。データ管理動作サポート・コンポーネント１５２は、この情報を永続的に保管する。このプロセスの実行終了時に、クリーンアップ作業を実行するために、データ管理動作サポート・コンポーネント１５２がワークフロー・ランタイム・システム１５０によって呼び出される。

図６、図７、および図８は、特定の諸実施形態によるワークフロー６１０に関するサンプル擬似コード６００、６１０、６２０を示している。擬似コードＡは、例示された擬似コード６００、６１０、６２０の一部である。

図９は、特定の諸実施形態によりワークフロー設計タイム・システム１２０によって提供される表示内容を例示している。ユーザはワークフロー７１０のグラフィック表現を作成することができる。図９のワークフロー７１０は、「ＧｅｔＥｕｒｏｐｅａｎＯｒｄｅｒｓ」７２０、「ＧｅｔＵＳＯｒｄｅｒｓ」７２２、「ＵｎｉｏｎＯｒｄｅｒｓ」７２４、および「ＭａｔｅｒｉａｌｉｚｅＯｒｄｅｒｓ」７２６というデータ管理アクティビティを含む。図９のワークフローは、２つの異なる地域（ヨーロッパおよび米国）からの注文データをロードする。２つのデータ・ストリームが一緒に結合される前に、（ユーロからドルへの）通貨換算が行われる。２つのデータ・セットの結合後に、結果として得られるデータがＸＭＬ文書にマテリアライズされる。最後に、ワークフローの出力としてＸＭＬ文書が返される。

以下のサンプル擬似コードＢは、ＧｅｔＥｕｒｏｐｅａｎＯｒｄｅｒｓデータ管理アクティビティ７２０に関するワークフロー記述を例示している。ＧｅｔＥｕｒｏｐｅａｎＯｒｄｅｒｓデータ管理アクティビティ７２０は、ＢＰＥＬ変数「ＲｅｓｕｌｔＳｅｔＲｅｆｅｒｅｎｃｅ＿Ｅｕｒｏｐｅ」内に保管されたセット参照にヨーロッパ・データをロードし（ステートメント１）、次にユーロからドルへの通貨換算を実行する（ステートメント２）。この換算は、ＳＱＬ ＵＰＤＡＴＥステートメントによって実行される。セット参照ＢＰＥＬ変数「ＲｅｓｕｌｔＳｅｔＲｅｆｅｒｅｎｃｅ＿Ｅｕｒｏｐｅ」は、換算ステートメントに関する入力セット参照として解釈される。
擬似コードＢ

以下のサンプル擬似コードＣは、ＧｅｔＵＳＯｒｄｅｒｓデータ管理アクティビティ７２２に関するワークフロー記述を例示している。ＧｅｔＵＳＯｒｄｅｒｓデータ管理アクティビティ７２２は、ＢＰＥＬ変数「ＲｅｓｕｌｔＳｅｔＲｅｆｅｒｅｎｃｅ＿ＵＳ」内に保管されたセット参照に米国データをロードする。この結果セット参照のライフ・サイクル属性は、それが存在しない場合のみ、基礎となるデータベース・テーブルが作成され（ｐｒｅｐａｒａｔｉｏｎ＝“ｉｆＮｅｅｄｅｄ”）、そのテーブルが削除され（ｃｌｅａｎｕｐ＝“ｙｅｓ”）、テーブルの削除がプロセス・インスタンス終了時に実行される（ｃｌｅａｎｕｐＳｃｏｐｅ＝“ｉｎｓｔａｎｃｅ”）ように設定される。
擬似コードＣ

以下のサンプル擬似コードＤは、ＵｎｉｏｎＯｒｄｅｒｓデータ管理アクティビティ７２４に関するワークフロー記述を例示している。ＵｎｉｏｎＯｒｄｅｒｓデータ管理アクティビティ７２４は、米国の注文と換算されたヨーロッパの注文の和集合（union）を表している。結果として得られるデータ・セットは、ＢＰＥＬ変数「ＲｅｓｕｌｔＳｅｔＲｅｆｅｒｅｎｃｅ＿Ｕｎｉｏｎ」内のセット参照として保管される。
擬似コードＤ

以下のサンプル擬似コードＥは、ＭａｔｅｒｉａｌｉｚｅＯｒｄｅｒｓデータ管理アクティビティ７２６に関するワークフロー記述を例示している。ＭａｔｅｒｉａｌｉｚｅＯｒｄｅｒｓデータ管理アクティビティ７２６は、統合された注文テーブルの内容をプロセス・コンテキストにマテリアライズする。ステートメントの＜ｆｒｏｍ＞要素にはマテリアライズのためのデータのソースが指定され、＜ｔｏ＞要素はマテリアライズ・ターゲットを表している。すなわち、セット参照「ＲｅｓｕｌｔＳｅｔＲｅｆｅｒｅｎｃｅ＿Ｕｎｉｏｎ」の内容は、ＢＰＥＬ変数「ＭａｔｅｒｉａｌｉｚｅｄＯｒｄｅｒｓ」の「ｍｙＭａｔｅｒｉａｌｉｚａｔｉｏｎＲｅｓｕｌｔ」部分にマテリアライズされる。
擬似コードＥ

結果セット参照は、その結果セットを作成するデータ管理アクティビティの指定の一部として指定される。結果セット参照を指定するために、ユーザは「ｃｒｅａｔｅ ｒｅｓｕｌｔ ｓｅｔ ｒｅｆｅｒｅｎｃｅ」ボタンを選択し、その結果、Ｒｅｓｕｌｔ Ｓｅｔ Ｒｅｆｅｒｅｎｃｅｓ Ｄｅｆｉｎｉｔｉｏｎ Ｗｉｚａｒｄ（結果セット参照定義ウィザード）８００が表示される（図１０）。図１０は、「ＧｅｔＥｕｒｏｐｅａｎＯｒｄｅｒｓ」アクティビティ７２０（図９）で使用される結果セット参照に対応するものである。Ｒｅｓｕｌｔ Ｓｅｔ Ｒｅｆｅｒｅｎｃｅｓ Ｄｅｆｉｎｉｔｉｏｎ Ｗｉｚａｒｄ８００では、このパネルの「Ａｔｔｒｉｂｕｔｅｓ」セクションを使用して、ライフ・サイクル管理オプションを定義することができる。たとえば、ユーザは、クリーンアップ８１０が必要であるかどうか、ならびにどの時点でクリーンアップを実行しなければならないかなどのライフ・サイクル属性８１０を識別する。この例の結果セットは、プロセスの終了時（すなわち、「ｉｎｓｔａｎｃｅ」の終了時）にクリーンアップされる。

ユーザは、たとえば、データ・ソースと、結果を保持するための既存のテーブルのＩＤとを提供するか、またはデータ管理動作サポート・コンポーネントによって結果セットを生成しなければならないことを指定することにより、結果セット参照の定義８２０を提供する。この例では、データ・ソース、スキーマ名、およびテーブル名が明示的に指定されている。

図１１、図１２、図１３、図１４、および図１５は、特定の諸実施形態によるワークフロー８１０に関するサンプル擬似コード９００、９１０、９２０、９３０、９４０を示している。擬似コードＢ、Ｃ、Ｄ、およびＥは、例示された擬似コード９００、９１０、９２０、９３０、９４０の一部である。

したがって、データ管理動作をワークフロー・システムに統合するために、データ管理動作は、ファーストクラス・メンバー（first class citizen）としてビジネス・プロセスに関するワークフロー・システムに統合される。諸実施形態では、データ管理動作に関して以下の特性を提供する。
１．データ管理動作の宣言記述から構成される新しいデータ管理アクティビティ
２．これらの動作に関する入力パラメータとしてビジネス・プロセス変数を直接指定するためのメカニズム
３．これらの動作の結果がどのようにビジネス・プロセス変数に保管されるかを直接指定するためのメカニズム
４．ランタイム中に使用すべきデータ・ソースを指定するためのメカニズム
５．ライフ・サイクル属性を有するセット参照を定義するためのメカニズム

諸実施形態は、データ管理アクティビティを実現するために必要なスキル・セットの低減や、これを行うために必要な開発時間の短縮など、従来の手法に関する問題を除去するものである。

統合システムは、設計タイム・システム・ツール１２０、ワークフロー言語（ワークフロー記述１３０に使用）内、ワークフロー・ランタイム・システム１５０という３通りのレベルでファーストクラス・メンバーとしてデータ管理動作をサポートすることによって達成される。ワークフロー設計タイム・システム１２０は、特定のデータ管理アクティビティのためのサポートによって強化される。ワークフロー言語は、アクティビティに関する入力パラメータおよび出力パラメータとしてプロセス変数を直接使用するための能力を含む、ワークフロー記述の一部としてデータ管理アクティビティを「インライン」で指定するためのメカニズムによって強化される。

ワークフロー・ランタイム・システム１５０はワークフロー記述１３０を受信する。ワークフロー・ランタイム・システム１５０は、セット参照のためのサポートおよび対応するセットに関するライフ・サイクル管理を含む、ワークフロー記述１３０に定義されたデータ管理動作を実行することができるデータ管理動作サポート・コンポーネント１５２によって強化される。データ管理動作サポート・コンポーネント１５２は、指定されたデータ管理動作を実行するために１つまたは複数のデータ管理システム１６０ａ・・・１６０ｎにアクセスする。

本発明の諸実施形態の理解を強化するために、もう１つの例が提供される。とりわけ、この例では、注文に関する情報がリレーショナル・データベース・システムに保管され、ビジネス・プロセスは特定の地域からの注文の総額をチェックする。この例では、地域はビジネス・プロセスに対する入力パラメータ（すなわち、ビジネス・プロセス入力変数）である。データベース管理動作はＳＥＬＥＣＴ照会である。この照会の結果は変数に保管され、したがって、その結果を後続アクティビティで使用することができる。

諸実施形態は、ビジネス・プロセス用のワークフロー言語（たとえば、ＢＰＥＬ）に関するインラインＳＱＬを提供する。ＷＰＣワークフロー・システムおよびＳＱＬサポートの場合、ワークフロー・ランタイム・システム１５０へのファーストクラス・メンバーとしての統合は、ワークフロー・ランタイム・システム１５０がＳＱＬコードを直接サポートすることを意味する。インラインＳＱＬステートメントにより、データ管理アクティビティの宣言記述（「Ｊａｖａ（登録商標）スニペット（snippet）」と同様のものであり、「ＳＱＬスニペット」または「ＤＭＡ」と呼ばれるもの）をワークフロー記述１３０に含めることができる。

ＷＰＣワークフロー・ランタイム・システム用のＳＱＬアクティビティに関する擬似コード例は擬似コードＦとして示されている。擬似コードＦの「ｓｅｌｅｃｔ ｃｏｕｎｔ（＊） ｉｎｔｏ」、「ｆｒｏｍ ＯＲＤＥＲＳ」、および「ｗｈｅｒｅ ＲＥＧＩＯＮ＝」というテキストは、ＳＱＬ照会がどのように指定されるかを示している。＜ｄａｔａＳｏｕｒｃｅ ｖａｒｉａｂｌｅ＝“ＤＭＡ＿Ｄａｔａ＿Ｓｏｕｒｃｅ” ｐａｒｔ＝“ｄａｔａＳｏｕｒｃｅ”／＞という要素は使用すべきデータ・ソースを指定する。＜ｐａｒａｍｅｔｅｒ ｋｉｎｄ＝“ｏｕｔ” ｐｒｏｐｅｒｔｙ＝“ＮＢ＿ＥＸＣＥＰＴＩＯＮＡＬ＿ＯＲＤＥＲＳ” ｖａｒｉａｂｌｅ＝“Ｐａｒａｍｅｔｅｒ” ／＞という要素は出力パラメータを指定する。

＜ｐａｒａｍｅｔｅｒ ｋｉｎｄ＝“ｉｎ” ｐｒｏｐｅｒｔｙ＝“ＭＡＸ＿ＰＲＩＣＥ” ｖａｒｉａｂｌｅ＝“Ｐａｒａｍｅｔｅｒ” ／＞という要素は入力パラメータを指定する。したがって、ビジネス・プロセス変数は入力パラメータおよび出力パラメータにすることができ、データ・ソースはビジネス・プロセス変数を介して指定することができる。
擬似コードＦ

この統合システムは、ビジネス・プロセスそのもののセマンティクス（たとえば、複数のアクティビティが相互にどのように関連するか）ならびにこのビジネス・プロセス内のデータ管理アクティビティのセマンティクスの両方を理解することができる。

諸実施形態は、従来のワークフロー・システムの欠陥を克服するセット参照の概念をサポートするワークフロー・システムを提供する。

セット参照は、１組のデータ・セットを指すポインタとして記述することができる。たとえば、セット参照は、そのデータ・セットを突き止めるためのテーブル名および追加情報にすることができる。このセット参照は、たとえば、そのセットにアクセスする方法に関する情報、そのセットに関するメタ情報、そのセットを作成し削除するためのステートメントなどのセット・プロパティを含むことができる。セット参照は、ビジネス・プロセス変数に結合することができ、ステートメントに関する入力および出力セットとして使用することができる。セット参照は、そのデータ・セットをコピーするのではなく、セット参照を転送することにより、アクティビティ間のセットの受け渡しを可能にする。たとえば、第１のデータ管理アクティビティはセット参照を作成することができ、第２のデータ管理アクティビティはそのセット参照を使用することができる。セット参照は動的インフラストラクチャをサポートする（たとえば、ソースおよびターゲット・セットはビジネス・プロセス・ランタイム時に変更することができる）。

特定の諸実施形態では、セット参照は、単一のデータ管理システム１６０ａ・・・１６０ｎを介してアクセス可能なセットを指す（たとえば、リレーショナル・データベース・システム内のテーブルまたはビュー）。データ管理システム１６０ａ・・・１６０ｎは、対応するレコードが異なるデータ管理システム１６０ａ・・・１６０ｎ内に存在するセットとともに機能できるフェデレーテッド・システム（federated system）にすることができる。

以下の擬似コードは、擬似コードＧとして定義されるセット参照の一例を示す。擬似コードＧでは、セット参照を定義するために、ｒｅｓｕｌｔＳｅｔＲｅｆｅｒｅｎｃｅ ｐａｒｔ＝“ｒｅｆｅｒｅｎｃｅ” ｖａｒｉａｂｌｅ＝“ＳｅｌｅｃｔｅｄＥｍｐｌｏｙｅｅｓＳｅｔＲｅｆｅｒｅｎｃｅＶａｒｉａｂｌｅ”／およびｓｅｔＲｅｆｅｒｅｎｃｅ ｐａｒｔ＝“ｒｅｆｅｒｅｎｃｅ” ｖａｒｉａｂｌｅ＝“ＡｌｌＥｍｐｌｏｙｅｅｓＳｅｔＲｅｆｅｒｅｎｃｅＶａｒｉａｂｌｅ”／を使用する。
擬似コードＧ

セット参照は、既存のセットを指すとともに、まだ実行されていないデータ管理アクティビティの結果を表すことができる。後者の場合、セット参照は、そのセットが従わなければならない特性に関するデータ管理アクティビティを指示するメタ情報を含むことができる。

セット参照のためのサポートは、以下のワークフロー・システム機能を含む。
１．セット参照は、ワークフロー・システムのワークフロー・ツールおよびＡＰＩによってサポートされる。ユーザは、セット参照を直接指定し、変更することができる（ファーストクラス・メンバー・サポートの一例）。
２．セット参照は、ビジネス・プロセスの設計時、ビジネス・プロセスの配備時、またはビジネス・プロセス・ランタイム時を含む、様々な時点で指定し変更することができる。
３．セット参照は、データ管理アクティビティに関する入力パラメータおよび出力パラメータとして直接使用することができる。

一例として、セット参照は、リレーショナル・データベース・システム内のテーブルまたはビューを表すことができる。アドレス情報は、そのデータ・セットにアクセスするために必要な情報（たとえば、データ・ソースの指定（たとえば、ＪＮＤＩ名）、スキーマおよびテーブル名、認証方法に関する記述（たとえば、ビジネス・プロセスを実行している現行ユーザの資格情報による））を含む。セット参照内のメタデータ情報は、テーブルまたはビューの列を記述する。

セット参照サポートは、ビジネス・プロセス・アクティビティによりセット参照「Ｓ１」への特定のデータ・ソース内の既存のテーブルの結合を可能にする。このアクティビティは、たとえば、レジストリ・ルックアップ動作にすることができる。その場合、後続ＳＱＬ ＳＥＬＥＣＴアクティビティのＦＲＯＭ節にＳ１を使用することができる（すなわち、Ｓ１は集合値（set-valued）入力パラメータとして使用することができる）。このＳＱＬ ＳＥＬＥＣＴステートメントの結果は、同じく後続データ管理アクティビティに使用可能な第２のセット参照「Ｓ２」に結合することができる。

セット単位の処理は、テーブルの行を表す１組のオブジェクト・セットに対するワークフロー言語のｗｈｉｌｅループを使用して実行することができ、データを豊富にするために何らかのデータ・ソース内のルックアップが実行され、特定の特性の有無をチェックするためにＷｅｂサービスが呼び出され、この特性に基づいて更新が実行される。また、単一のセット単位のＳＱＬ更新動作も提供することができる。このセット単位の処理は、大きいセットのマテリアライズを回避し、データ・ソースへのアクセス回数を削減する。

諸実施形態は、ビジネス・プロセスによって作成されたセットに関するライフ・サイクル管理を提供する。ユーザが特定のビジネス・プロセス・アクティビティで使用するためのセットを作成し、もはや不要になると直ちにそのセットをドロップすることは、頻繁に行われるタスクである可能性がある。したがって、諸実施形態は、セットの作成および削除を単純化する、セット参照に関するライフ・サイクル管理拡張機能を提供する。この拡張機能としては、ビジネス・プロセス配備時、ビジネス・プロセス作成時、ビジネス・プロセス内の特定の範囲の開始時、またはビジネス・プロセス内の特定のアクティビティの開始時を含む特定の時点で自動的にセットを作成するメカニズムを含む。

また、この拡張機能としては、セットを作成したアクティビティの終了時、セットが作成された範囲の終了時、ビジネス・プロセスの終了時、または配備解除（undeployment）時を含む特定の時点で自動的に、ビジネス・プロセスによって作成されたセットをドロップするメカニズムも含む。作成およびドロップはユーザが管理することもできる（すなわち、セットはビジネス・プロセス後も存続することができる）。

以下の擬似コードは、擬似コードＨとしてライフ・サイクル管理拡張機能の使用の一例を示す。擬似コードＨでは、ｃｌｅａｎｕｐ＝“ｙｅｓ” ｃｌｅａｎｕｐＳｃｏｐｅ＝“ｐｒｏｃｅｓｓ” ｐｒｅｐａｒａｔｉｏｎ＝“ｙｅｓ”は、ビジネス・プロセスが終了したときにセットをドロップし、擬似コードＨを含むアクティビティが実行されるたびに新しいセットがデータ管理動作サポート・コンポーネント１５２によって自動的に作成されることを示している。
擬似コードＨ

諸実施形態は、ワークフローへのデータ動作の統合を可能にし、データ動作を含むワークフローの最適化を可能にする。諸実施形態は、ＥＴＬおよびビジネス・プロセス統合とともに使用することができる。

ＩＢＭ、ＭＱＳｅｒｉｅｓ、ＷｅｂＳｐｈｅｒｅ、およびＤＢ２は、米国またはその他の国あるいはその両方におけるインターナショナル・ビジネス・マシーンズ社の登録商標または民事上のマークあるいはその両方である。Ｏｒａｃｌｅは、米国またはその他の国あるいはその両方におけるオラクル社の登録商標または民事上のマークあるいはその両方である。Ｅｘｃｅｌは、米国またはその他の国あるいはその両方におけるマイクロソフト社の登録商標または民事上のマークあるいはその両方である。

追加の実施形態の詳細
記載されている諸実施形態は、ソフトウェア、ファームウェア、ハードウェア、またはそれらの任意の組み合わせを作成するためにプログラミングまたはエンジニアリングあるいはその両方の技法を使用する方法、装置、コンピュータ・プログラム、または製品（article of manufacture）として実現することができる。本明細書で使用する「製品」および「回路」という用語は、ハードウェア・ロジック（たとえば、集積回路チップ、プログラマブル・ゲート・アレイ（ＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）など）または磁気記憶媒体（たとえば、ハード・ディスク、フレキシブル・ディスク、テープなど）、光記憶装置（ＣＤ−ＲＯＭ、光ディスクなど）、揮発性および不揮発性メモリ・デバイス（たとえば、ＥＥＰＲＯＭ、ＲＯＭ、ＰＲＯＭ、ＲＡＭ、ＤＲＡＭ、ＳＲＡＭ、ファームウェア、プログラマブル・ロジックなど）などのコンピュータ可読媒体で実現された状態マシン、コード、またはロジックを指す。コンピュータ可読媒体内のコードは、プロセッサによってアクセスされ実行される。コードまたはロジックがプロセッサによって実行されると、回路は、そのコードまたはロジックを含む媒体ならびにその媒体からロードされたコードを実行するプロセッサを含むことができる。好ましい諸実施形態が実現されるコードはさらに、伝送媒体により、またはネットワーク上のファイル・サーバから、アクセス可能である場合がある。このような場合、コードが実現される製品は、ネットワーク伝送路、無線伝送媒体、空気中を伝搬する信号、電波、赤外線信号などの伝送媒体を含むことができる。したがって、「製品」は、コードが実施される媒体を含むことができる。さらに、「製品」は、コードが実施され、処理され、実行される、ハードウェア・コンポーネントとソフトウェア・コンポーネントの組み合わせを含むことができる。当然のことながら、当業者であれば、この構成に対して多くの変更が可能であり、製品が当技術分野で既知の任意の情報伝送媒体を含むことができることを認識するであろう。さらに、デバイス、アダプタなどは、アダプタまたはマザーボード上の１つまたは複数の集積回路で実現することができる。

特定の諸実施形態は、人または自動処理によってコンピューティング・システムにコンピュータ可読コードを統合することによりコンピューティング・インフラストラクチャを配備するための方法を対象とすることができ、そのコードはコンピューティング・システムと協力して、記載されている諸実施形態の動作を実行することができる。

ロジックという用語は、例証として、ソフトウェアまたはハードウェアあるいはソフトウェアとハードウェアの組み合わせを含むことができる。

図２のロジックは、特定の順序で行われる特定の動作を記載している。代替諸実施形態では、このロジック動作のうちのいくつかを異なる順序で実行するか、変更または除去することができる。その上、上記のロジックに動作を追加し、依然として上記の諸実施形態に適合することもできる。さらに、本明細書に記載した動作を順次実行するか、特定の動作を並行して処理する場合もあれば、単一プロセスによって実行されるものとして記載された動作を分散プロセスによって実行する場合もある。

図２に例示されているロジックは、ソフトウェア、ハードウェア、プログラマブルおよび非プログラマブル・ゲート・アレイ・ロジックで、あるいはハードウェア、ソフトウェア、またはゲート・アレイ・ロジックの何らかの組み合わせで実現することができる。

図１６は、特定の諸実施形態により使用可能なコンピュータ・システムのアーキテクチャ１０００を例示している。コンピューティング・デバイス１１０および１４０はアーキテクチャ１０００を実現することができる。コンピュータ・アーキテクチャ１０００は、プロセッサ１００２（たとえば、マイクロプロセッサ）、メモリ１００４（たとえば、揮発性メモリ・デバイス）、および記憶装置１０１０（たとえば、磁気ディスク・ドライブ、光ディスク・ドライブ、テープ・ドライブなどの不揮発性記憶領域）を実現することができる。オペレーティング・システム１００５は、メモリ１００４で実行することができる。記憶装置１０１０は、内部記憶装置あるいは付加されたまたはネットワーク・アクセス可能な記憶装置を含むことができる。記憶装置１０１０内のコンピュータ・プログラム１００６は、当技術分野で既知の通り、メモリ１００４にロードし、プロセッサ１００２によって実行することができる。このアーキテクチャは、ネットワークとの通信を可能にするためのネットワーク・カード１００８をさらに含む。入力装置１０１２は、プロセッサ１００２にユーザ入力を提供するために使用され、キーボード、マウス、ペンスタイラス、マイクロホン、タッチ検知ディスプレイ画面、あるいは当技術分野で既知の任意のその他の起動または入力メカニズムを含むことができる。出力装置１０１４は、ディスプレイ・モニタ、プリンタ、記憶装置など、プロセッサ１００２またはその他のコンポーネントからの情報を提供することができる。コンピュータ・システムのコンピュータ・アーキテクチャ１０００は、例示されているものより少ないコンポーネントを含むか、本明細書に例示されていない追加のコンポーネントを含むか、あるいは例示されているコンポーネントと追加のコンポーネントの何らかの組み合わせを含むことができる。

コンピュータ・アーキテクチャ１０００は、メインフレーム、サーバ、パーソナル・コンピュータ、ワークステーション、ラップトップ、ハンドヘルド・コンピュータ、電話装置、ネットワーク家電、仮想化装置、記憶コントローラなど、当技術分野で既知の任意のコンピューティング・デバイスを含むことができる。当技術分野で既知の任意のプロセッサ１００２およびオペレーティング・システム１００５を使用することができる。

諸実施形態に関する上記の記述は、例示および説明のために提示されたものである。網羅することあるいは開示された正確な形式に諸実施形態を限定することは意図されていない。上記の教示を考慮すると、多くの変更および変形が可能である。諸実施形態の範囲は、この詳細な説明によって制限されず、むしろ特許請求の範囲によって制限されることが意図されている。上記の指定、例、およびデータは、諸実施形態の構成の製造および使用に関する完全な説明を提供するものである。本発明の精神および範囲を逸脱せずに多くの諸実施形態を作成することができるので、諸実施形態は、本明細書に付加された特許請求の範囲またはその後に出願された任意の請求項、ならびにそれと同等のものに存在する。

特定の諸実施形態を実現可能なコンピュータ・アーキテクチャの詳細を例示する図である。 特定の諸実施形態によりデータ管理動作をワークフロー・システムに統合するためのロジックを例示する図である。 特定の諸実施形態によりワークフロー設計タイム・システムによって提供される表示内容を例示する図である。 特定の諸実施形態によるＤａｔａ Ｓｏｕｒｃｅ Ｄｅｆｉｎｉｔｉｏｎ Ｗｉｚａｒｄ（データ・ソース定義ウィザード）を例示する図である。 特定の諸実施形態によるＡｄｄ ｏｒ Ｅｄｉｔ ａｎ ＩｎｐｕｔＳｅｔＲｅｆｅｒｅｎｃｅ（ＩｎｐｕｔＳｅｔＲｅｆｅｒｅｎｃｅの追加または編集）画面を例示する図である。 特定の諸実施形態によるワークフローに関するサンプル擬似コードを示す図である。 特定の諸実施形態によるワークフローに関するサンプル擬似コードを示す図である。 特定の諸実施形態によるワークフローに関するサンプル擬似コードを示す図である。 特定の諸実施形態によりワークフロー設計タイム・システムによって提供される表示内容を例示する図である。 特定の諸実施形態によるＲｅｓｕｌｔ Ｓｅｔ Ｒｅｆｅｒｅｎｃｅｓ Ｄｅｆｉｎｉｔｉｏｎ Ｗｉｚａｒｄ（結果セット参照定義ウィザード）を例示する図である。 特定の諸実施形態によるワークフローに関するサンプル擬似コードを示す図である。 特定の諸実施形態によるワークフローに関するサンプル擬似コードを示す図である。 特定の諸実施形態によるワークフローに関するサンプル擬似コードを示す図である。 特定の諸実施形態によるワークフローに関するサンプル擬似コードを示す図である。 特定の諸実施形態によるワークフローに関するサンプル擬似コードを示す図である。 特定の諸実施形態により使用可能なコンピュータ・システムのアーキテクチャを例示する図である。

Claims (39)

1. ワークフローを処理するための方法であって、
   １つまたは複数のデータ管理アクティビティを含むワークフローを受信するステップと、
   前記１つまたは複数のデータ管理アクティビティの記述を含むワークフロー記述を前記ワークフローから生成するステップと、
   １つまたは複数のデータ管理動作を前記ワークフロー記述から生成するステップと、
   １つまたは複数のデータ管理システムに対して前記１つまたは複数のデータ管理動作を実行するステップと、
   を含む方法。
2. 少なくとも１つのデータ管理アクティビティがセット参照を含む、請求項１に記載の方法。
3. １つまたは複数のライフ・サイクル属性が前記セット参照に関連付けられる、請求項２に記載の方法。
4. 前記セット参照が、ビジネス・プロセス変数またはビジネス・プロセス変数の一部へのマッピングを含む、請求項２または３に記載の方法。
5. 少なくとも１つのデータ管理アクティビティが入力パラメータとしてビジネス・プロセス変数を含む、請求項１ないし４のいずれかに記載の方法。
6. 少なくとも１つのデータ管理アクティビティが出力パラメータとしてビジネス・プロセス変数を含む、請求項１ないし５のいずれかに記載の方法。
7. 少なくとも１つのデータ管理アクティビティがデータ・ソース定義を含む、請求項１ないし６のいずれかに記載の方法。
8. 前記データ・ソース定義が、ビジネス・プロセス変数またはビジネス・プロセス変数の一部へのデータ・ソースのマッピングを含む、請求項７に記載の方法。
9. 前記１つまたは複数のデータ管理システムから結果を受信するステップをさらに含む、請求項１ないし８のいずれかに記載の方法。
10. 第１のデータ管理アクティビティがセット参照を定義し、第２のデータ管理アクティビティが前記セット参照を使用する、請求項１ないし９のいずれかに記載の方法。
11. 前記データ管理動作が照会を含む、請求項１ないし１０のいずれかに記載の方法。
12. 各データ管理アクティビティが、前記１つまたは複数のデータ管理アクティビティのうちの１つに対応する、請求項１ないし１１のいずれかに記載の方法。
13. 新しいデータ管理アクティビティの作成を可能にするステップをさらに含む、請求項１ないし１２のいずれかに記載の方法。
14. ワークフローを処理するためのコンピュータ・プログラムであって、前記プログラムが動作を実行させることができ、前記動作が、
    １つまたは複数のデータ管理アクティビティを含むワークフローを受信するステップと、
    前記１つまたは複数のデータ管理アクティビティの記述を含むワークフロー記述を前記ワークフローから生成するステップと、
    １つまたは複数のデータ管理動作を前記ワークフロー記述から生成するステップと、
    １つまたは複数のデータ管理システムに対して前記１つまたは複数のデータ管理動作を実行するステップと、
    を含む、コンピュータ・プログラム。
15. 少なくとも１つのデータ管理アクティビティがセット参照を含む、請求項１４に記載のコンピュータ・プログラム。
16. １つまたは複数のライフ・サイクル属性が前記セット参照に関連付けられる、請求項１５に記載のコンピュータ・プログラム。
17. 前記セット参照が、ビジネス・プロセス変数またはビジネス・プロセス変数の一部へのマッピングを含む、請求項１５または１６に記載のコンピュータ・プログラム。
18. 少なくとも１つのデータ管理アクティビティが入力パラメータとしてビジネス・プロセス変数を含む、請求項１４ないし１７のいずれかに記載のコンピュータ・プログラム。
19. 少なくとも１つのデータ管理アクティビティが出力パラメータとしてビジネス・プロセス変数を含む、請求項１４ないし１８のいずれかに記載のコンピュータ・プログラム。
20. 少なくとも１つのデータ管理アクティビティがデータ・ソース定義を含む、請求項１４ないし１９のいずれかに記載のコンピュータ・プログラム。
21. 前記データ・ソース定義が、ビジネス・プロセス変数またはビジネス・プロセス変数の一部へのデータ・ソースのマッピングを含む、請求項２０に記載のコンピュータ・プログラム。
22. 前記動作が、前記１つまたは複数のデータ管理システムから結果を受信するステップをさらに含む、請求項１４ないし２１のいずれかに記載のコンピュータ・プログラム。
23. 第１のデータ管理アクティビティがセット参照を定義し、第２のデータ管理アクティビティが前記セット参照を使用する、請求項１４ないし２２のいずれかに記載のコンピュータ・プログラム。
24. 前記データ管理動作が照会を含む、請求項１４ないし２３のいずれかに記載のコンピュータ・プログラム。
25. 各データ管理アクティビティが、前記１つまたは複数のデータ管理アクティビティのうちの１つに対応する、請求項１４ないし２４のいずれかに記載のコンピュータ・プログラム。
26. 前記動作が、新しいデータ管理アクティビティの作成を可能にするステップをさらに含む、請求項１４ないし２５のいずれかに記載のコンピュータ・プログラム。
27. ワークフローを処理するためのシステムであって、
    動作を実行させることができる回路を備え、前記動作は、
    １つまたは複数のデータ管理アクティビティを含むワークフローを受信するステップと、
    前記１つまたは複数のデータ管理アクティビティの記述を含むワークフロー記述を前記ワークフローから生成するステップと、
    １つまたは複数のデータ管理動作を前記ワークフロー記述から生成するステップと、
    １つまたは複数のデータ管理システムに対して前記１つまたは複数のデータ管理動作を実行するステップと、
    を含む、システム。
28. 少なくとも１つのデータ管理アクティビティがセット参照を含む、請求項２７に記載のシステム。
29. １つまたは複数のライフ・サイクル属性が前記セット参照に関連付けられる、請求項２８に記載のシステム。
30. 前記セット参照が、ビジネス・プロセス変数またはビジネス・プロセス変数の一部へのマッピングを含む、請求項２８または２９に記載のシステム。
31. 少なくとも１つのデータ管理アクティビティが入力パラメータとしてビジネス・プロセス変数を含む、請求項２７ないし３０のいずれかに記載のシステム。
32. 少なくとも１つのデータ管理アクティビティが出力パラメータとしてビジネス・プロセス変数を含む、請求項２７ないし３１のいずれかに記載のシステム。
33. 少なくとも１つのデータ管理アクティビティがデータ・ソース定義を含む、請求項２７ないし３２のいずれかに記載のシステム。
34. 前記データ・ソース定義が、ビジネス・プロセス変数またはビジネス・プロセス変数の一部へのデータ・ソースのマッピングを含む、請求項３３に記載のシステム。
35. 前記動作が、前記１つまたは複数のデータ管理システムから結果を受信するステップをさらに含む、請求項２７ないし３４のいずれかに記載のシステム。
36. 第１のデータ管理アクティビティがセット参照を定義し、第２のデータ管理アクティビティが前記セット参照を使用する、請求項２７ないし３５のいずれかに記載のシステム。
37. 前記データ管理動作が照会を含む、請求項２７ないし３６のいずれかに記載のシステム。
38. 各データ管理アクティビティが、前記１つまたは複数のデータ管理アクティビティのうちの１つに対応する、請求項２７ないし３７のいずれかに記載のシステム。
39. 前記動作が、新しいデータ管理アクティビティの作成を可能にするステップをさらに含む、請求項２７ないし３８のいずれかに記載のシステム。

Images