(58)【調査した分野】(Int.Cl.,DB名)
前記複数のルールデータは、同じ条件項目にワイルドカードが設定されているルールデータからなるルールデータ群に分けられ、前記ルールデータ群は、当該条件項目以外の条件項目に適用されるルールデータ群であって、
前記実行部は、
複数のルールデータ群のうち前記入力データの条件項目と同じ条件項目のルールデータ群からルールデータを検索することを特徴とする請求項1に記載のデータ処理装置。
【発明を実施するための形態】
【0018】
<<概要>>
上記課題を解決するため、本発明では、オーダデータに適用されるルールのルールIDと、そのルールIDに係るルールデータの条件項目とをキーとして、データベースからルールデータを検索する。これにより、全てのルールデータを走査する従来方式と比較して、ルールデータ数に因らない高速なルールデータの検索処理が可能となり、オーダデータのチェック処理を短時間で実現可能となる。
【0019】
また、ルールデータの条件項目については、オーダデータの項目から選定して定義する。さらに、オーダデータがルールデータの条件項目に合致する場合のアクションについては、OKを画面などに出力する基本方式に加え、オーダデータへの情報の書き込み、他ルールのカスケード的な呼び出し、ロジック処理を想定したスクリプト実行などを指定できるUI画面を提供する。
【0020】
以下、本発明を実施する一実施の形態について図面を用いて説明する。
【0021】
<<システム構成>>
図1は、本実施の形態に係るワークフローシステム1の全体構成を示す図である。ワークフローシステム1(データ処理装置)は、画面処理部11と、データ処理部12と、データベース部13と、を備えて構成される。
【0022】
画面処理部11は、
図1に例示するように、オーダ様式設定画面111と、ルール様式設定画面112と、ルールデータ設定画面113と、ワークフロー定義画面114と、オーダデータ入力画面115とを生成し、ワークフローシステム1を利用するユーザ端末の画面に表示する。
【0023】
データ処理部12は、オーダ様式登録部121と、ルール様式登録部122と、ルールデータ登録部123と、ワークフロー登録部124と、ワークフロー実行部125と、オーダデータ登録部126と、ルール実行部127と、API呼出し実行部128と、を備えて構成される。以降、これらの機能部(121〜128)を説明する。
【0024】
オーダ様式登録部121は、オーダ様式設定画面111で入力されたオーダ様式のデータをデータベース部13に登録する機能を備える。オーダ様式とは、オーダデータをワークフローシステム1に入力するための元となる雛形データである。また、オーダ様式は、ワークフローシステム1の利用者である事業主の持つサービス提供機器やサービス内容種別に応じて、基本的には事業主により予め定義されるデータである。例えば、オーダデータの構成項目と成り得る項目の名称、その項目に対して入力され得る入力データである。
【0025】
このオーダ様式のデータは、ルールデータを生成するための元データとしても用いられる。ルールデータは、オーダデータの内容をチェックするためのものであり、オーダ様式のデータは、オーダデータとルールデータとで共通の元データとなる。
【0026】
ルール様式登録部122は、ルール様式設定画面112で入力されたルール様式のデータをデータベース部13に登録する機能を備える。ルール様式とは、ルールデータを生成するための元となる雛形データである。例えば、ルール条件、そのルール条件に合致しない場合のエラー処理(処理ルール)が含まれる。
【0027】
ルールデータ登録部123は、ルールデータ設定画面113で入力されたルールデータをデータベース部13に登録する機能を備える。ルールデータとは、オーダデータの内容が適正かをチェックするためのデータであり、ルール様式を用いて生成される。例えば、ルール様式のルール条件に対して設定された具体的な条件値、そのルール条件に合致する場合のアクション(処理ルール)が含まれる。
【0028】
ワークフロー登録部124は、ワークフロー定義画面114で定義されたワークフローのデータをデータベース部13に登録する機能を備える。ワークフローとは、順次行う複数の処理タスクを業務の流れに沿って関連付けた処理遷移図である。ユーザは、ワークフロー定義画面114でタスクを適宜選定し、その処理順を定義可能である。
【0029】
実行タスクには、例えば、表示画面上で作業者がデータ入力を行う人タスク(T)、オーダデータに対して所定のルールを実行するルールタスク(R)、オーダデータの入力データと成り得るデータを自システム以外の他システムから取得するためのAPI(Application Program Interface)を呼び出すAPIタスク(A)がある。
【0030】
ここまで説明した機能部(121〜124)は、ワークフローを開始する前に実行される。一方、ここから説明する機能部(125〜128)は、オーダデータを処理する際に実行される。
【0031】
ワークフロー実行部125は、所定のワークフローをデータベース部13から読み出し、そのワークフローで定義された処理順に沿って各タスクをそれぞれ自動で実行する機能を備える。具体的には、読み出された所定パターンのワークフローに沿ってタスク処理を順次実行し、本実施の形態では、所定タイミングの実行タスクが人タスク(T)であればオーダデータ登録部126を実行し、ルールタスク(R)であればルール実行部127を実行し、APIタスク(A)であればAPI呼出し実行部128を実行する。
【0032】
オーダデータ登録部126は、人タスク(T)の機能部であり、オーダデータ入力画面115で入力されたオーダデータをデータベース部13に登録する機能を備える。オーダデータとは、顧客からの注文内容に基づき生成された処理対象データであり、画面に表示されたオーダ様式のデータの中から選択することで生成される。
【0033】
ルール実行部127は、ルールタスク(T)の機能部であり、オーダデータに対してユーザ指定のルールを実行する機能部である。ルールの実行とは、ルールを識別するルールIDとルール様式の条件項目とをキーとしてデータベース部13からルールデータを検索し、そのルールデータに定義されているアクションを実行することをいう。
【0034】
具体的には、ルール実行部127は、所望のオーダデータに適用されるルールのルールIDを受け付け、そのルールIDに係るルールデータの条件項目に対応する入力データを該オーダデータから取得し、そのルールIDに対応するルールデータであり、取得した入力データと同じ条件値(設定データ)又は同じ組み合わせの設定データが設定されたルールデータをデータベース部13から検索する。その後、ルール実行部127は、検索したルールデータに設定されているアクションを実行する。一方、該当するルールデータが検索されない場合には、受け付けたルールIDのルールに設定されているエラー処理を実行する。
【0035】
また、ルール実行部127は、複数のルールデータ群のうち、オーダデータ内の入力データの条件項目と同じ条件項目のルールデータ群からルールデータを検索する機能を更に備える。ここでいうルールデータ群とは、データベース部13に登録されている複数のルールデータを、同じ条件項目にワイルドカードが設定されているルールデータからなる集合に分けた場合のルールデータ群であり、当該条件項目以外の条件項目に適用されるルールデータ群である。なお、ワイルドカードとは、その取り得る値が複数かつ任意であるデータをいう。
【0036】
更に、ルール実行部127は、複数の条件項目のうち一部の条件項目の設定データを用いてルールデータを検索した後に、他の一部の条件項目の設定データを用いてルールデータを更に検索する機能を備える。
【0037】
API呼出し部128は、APIタスク(A)の機能部であり、自身のワークフローシステム1以外の他システムからオーダデータの入力データと成り得るデータを検索して取得するためのAPIを呼び出す機能を備える。
【0038】
<<ワークフローシステムの画面>>
ワークフローの全体を把握するため、先にワークフロー定義画面114を説明する。
図2は、ワークフロー定義画面114の例を示す図である。ワークフロー定義画面114は、ワークフロー全体の流れを図式化した画面であり、業務の流れに沿って順次行う複数の処理タスクを関連付けるために用いられる。
【0039】
ユーザによりワークフロー定義要求が行われると、画面処理部11は、ワークフロー定義画面114をユーザ端末の画面に表示する。ワークフロー定義画面114には、ワークフローを定義するための雛形図形(処理タスク用のブロック図形など)が予め用意されている。ユーザは、下部のメニューから雛形図形をドラッグし、上部の描画エリアにドロップして移動させる。そして、業務目的を考慮しつつ、その雛形図形を描画エリア内の適切な位置に配置し、雛形図形間を適宜接続して関連付ける。これにより、所望の業務目的を完遂するためのワークフローが定義される。業務内容に応じて様々なパターンのワークフローを定義可能である。
【0040】
その後、ユーザ指定のワークフローがデータベース部13から読み出され、ワークフロー実行部125により処理が開始されると、そのワークフローのフロー沿って各タスクが自動的に順次実行される。
図2に示したワークフローの場合、例えば、「オーダ入力タスク」→「オーダチェックタスク」→「他システム情報取得タスク」の順で実行される。「オーダチェックタスク」で行われた処理の結果、オーダデータの修正が必要な場合には、「オーダ修正タスク」へ遷移して再び「オーダチェックタスク」が実行される。
【0041】
ここで、ワークフロー定義画面114を構成する図形を説明する。ユーザは、例えばブロック図形を利用できる。ブロック図形とは、一定単位の処理タスクを意味する図形であり、業務の種類又は業務処理の主体などに応じて予め用意されている。例えば、画面入力など人手の作業を要する場合には人タスク(T)を利用可能であり、
図2に示した「オーダ入力タスク」及び「オーダ修正タスク」がそれに該当する。その他、オーダデータに対して所定のルールを実行するルールタスク(R)、オーダデータの入力データと成り得るデータを自システム以外の他システムから取得するためのAPIを呼び出すAPIタスク(A)を利用可能である。
図2に示した「オーダチェックタスク」はルールタスク(R)に該当し、「他システム情報取得タスク」はAPIタスク(A)に該当する。
【0042】
その他、ブロック図形間を接続するための接続図形、その接続経路を分岐又は統合するための分岐・統合図形も利用できる。分岐・統合図形としては、例えばXOR分岐が考えられる。分岐・統合図形に対応する分岐設定画面又は統合設定画面を生成して表示することも可能である。ワークフローは、処理の進捗に伴い接続図形の矢印の方向に沿って自動で進行し、分岐がある場合は分岐図形の定義に従う。
【0043】
なお、
図2に示したワークフロー定義画面114は例である。ユーザは、任意のブロック図形及び分岐・統合図形を描画エリア内の任意の位置に配置し、接続図形で図形間を任意に接続できる。また、画面の構成粒度も任意に設定できる。例えば、「他システム情報取得タスク」については、フロー上の特定のタイミングで実行する必要はなく、「オーダチェックタスク」又は「オーダ入力タスク」の前又はその間に実行してもよいことから、ブロック図形間を連結する任意の経路上に設定可能である。
【0044】
また、
図3に示すように、ワークフローが複数の人タスク(T)で定義される場合、各人タスク(T)で共通して用いる1つのメイン入力画面を、個々のタスクA,B,Cでそれぞれ必要なデータを入力するためのサブ入力画面に分けてもよい。すなわち、複数の入力データのうち各タスクA,B,Cでそれぞれ使用する入力データのみを入力させる各サブ画面を画面遷移により段階的に表示してもよい。これにより、ワークフローシステム1のユーザビリティを向上できる。
【0045】
その他、
図2又は
図3に示したワークフローの一部のみを生成してもよいし、作成済みのワークフローをコピーして他のワークフローの雛形として利用してもよい。
【0046】
<<システム動作>>
次に、ワークフローシステム1の動作を説明する。
【0047】
<事前定義処理:オーダ様式の登録>
図4は、オーダ様式の登録動作を示す図である。ステップS101において、画面処理部11は、ユーザによるオーダ様式設定要求に応じてオーダ様式設定画面111をユーザ端末の画面に表示する。その後、ステップS102において、オーダ様式登録部121は、オーダ様式設定画面111でユーザにより入力されたオーダ様式のデータをJSON形式でデータベース部13に登録する。
【0048】
具体的には、オーダデータの構成項目と成り得る大項目並びに小項目の名称、及び小項目に対して入力され得る入力データが予め登録される。例えば、大項目としては「アクセス回線設定」が登録され、その大項目に対する小項目としては「Config設定」、「設置工事」、「回線種別」が登録される(後述する
図10参照)。また、その「Config設定」に対する入力データとしては、例えば、「初期設定(新設・機種変更)」、「設定変更」、「未変更」が登録される。これらオーダ様式のデータは、ルール様式を生成する際の元データとしても用いられる。
【0049】
<事前定義処理:ルール様式の登録>
図5は、ルール様式の登録動作を示す図である。ステップS201において、画面処理部11は、ユーザによるルール様式設定要求に応じてルール様式設定画面112をユーザ端末の画面に表示する。その後、ステップS202において、ルール様式登録部122は、ルール様式設定画面112でユーザにより入力されたルール様式のデータをJSON形式でデータベース部13に登録する。
【0050】
図6は、ルール様式設定画面112の例を示す図である。ルールタブ112zで所定ルールのルール様式を設定可能である。
図6(a)に示すように、所定ルールを定めるルール様式には、そのルールに対して一意のルールID(α,β,γ,…)が割り振られる。また、ルール様式設定画面112は、条件設定画面112aと、アクション設定画面112bと、エラー処理設定画面112cと、を備える。
【0051】
条件設定画面112aには、ルールの条件項目が設定される。ルールの条件項目は、増減可能であり、オーダ様式のデータから選択される。具体的には、オーダ様式で小項目として登録されている複数の名称を選択可能に表示し、その中からユーザの指定した名称がルールの条件項目として設定される。
図6(a)の場合、「Config設定」、「設置工事」がルールの条件項目として設定されている。また、条件項目の右側には、その条件項目に条件値を設定するための入力欄が設けられており、その入力欄には、オーダ様式で定義されていた小項目に対する複数の入力データが選択可能に用意されている。
【0052】
アクション設定画面112bについては後述する。エラー処理設定画面112cには、ルール(1つのルール様式を用いて設定される全てのルールデータのルール条件)に合致しない場合のエラー処理が設定される。具体的には、各ルールデータの条件項目に設定された条件値(設定データ)又は設定データの組み合わせに合致しない場合におけるエラー処理動作の種別及び詳細処理情報又は詳細処理動作が設定される。エラー処理動作の種別は予め用意された複数の中から選択可能であり、詳細処理情報又は詳細処理動作は任意に設定可能である。例えば、「NG」、「入力データが不適切です」、「入力データの組み合わせが不適切です」の詳細処理情報が設定される。
【0053】
ユーザは、このようなルール様式設定画面112を画面に表示した後、所望のルール様式で用いる1つ以上の条件項目及び該条件項目の名称を設定し、このルール様式に合致しない場合のエラー処理動作を設定する。この処理を繰り返すことにより、複数のルール様式がデータベース部13に登録される。
【0054】
<事前定義処理:ルールデータの登録>
図7は、ルールデータの登録動作を示す図である。ステップS301において、画面処理部11は、ユーザによるルールデータ登録要求に応じて、その要求で指定されたルール様式で構成されるルールデータ設定画面113をユーザ端末の画面に表示する。その後、ステップS302において、ルールデータ登録部123は、ルールデータ設定画面113でユーザにより入力されたルールデータをJSON形式でデータベース部13に登録する。
【0055】
図8は、ルールデータ設定画面113の例を示す図である。
図8(a)に示すように、ルールデータ設定画面113は、条件設定画面131aと、アクション設定画面131bと、で構成される。
【0056】
条件設定画面131aには、ルールの条件項目及び該条件項目に条件値を設定するための入力欄が表示される。入力欄右端にあるセレクタボタンの押下げにより、入力欄に予め用意されていた条件項目に対する複数のデータ(オーダ様式のデータ)が選択可能に表示され、その中からユーザにより選択されたデータがルールデータのルール条件値として入力欄に入力される。例えば、「Config設定」の条件項目に対するデータとして「初期設定(新設・機種変更)」、「変更設定(取り付け工事無し)」、「変更設定(取り付け工事無し)」、「未実施(選択不可)」が予め用意されており、その中から「初期設定(新設・機種変更)」が選択される。
【0057】
アクション設定画面131bには、ルールデータのルール条件に合致する場合のアクションが設定される。具体的には、ルールデータの条件項目に設定された条件値(設定データ)又は設定データの組み合わせに合致する場合におけるアクション処理動作の種別及び詳細処理情報又は詳細処理動作が設定される。アクション処理動作の種別は予め用意された後述する複数の中から選択可能であり、詳細処理情報又は詳細処理動作は任意に設定可能である。アクション処理は、1つに限らず複数設定可能である。
【0058】
ここで、アクション処理動作の種別を説明する。任意の種別を選択して設定できるが、例えば「オーダ書き込み」を選択可能である。このアクションを選択した場合、ルール条件に合致するオーダデータに対して所定の情報を書き込むための入力欄が表示される。この入力欄には、「8%割引」など、オーダデータに対する書き込み情報が入力される。
【0059】
その他、「ルール実行」又は「スクリプト実行」を選択可能である。「ルール実行」のアクションを選択した場合、当該ルールデータの直後に実行するルールデータを指定するための入力欄が表示される。この入力欄には、「ルールβ」など、1つ以上のルール様式のルールIDが指定される。また、「スクリプト実行」のアクションを選択した場合は、スクリプトの編集画面が表示される。例えば、当該ルールデータに関連あるスクリプトを編集するための画面が表示され、ユーザにより編集される。オーダデータがルール条件に合致する場合、編集後のスクリプトが実行される。これら以外のアクション処理動作を設定してもよい。例えば「OK表示」のアクションを選択可能である。オーダデータがルール条件に合致する場合、ユーザ端末の画面に「OK」の文字を表示し、又はオーダデータに「OK」の処理結果を入力する。
【0060】
ユーザは、
図6のルールαに係るルール様式のルールデータ設定画面113を画面に表示した後、そのルール様式の条件項目に対して条件値(設定データ)を設定し、その設定データ又は設定データの組み合わせに合致する場合のアクション処理動作を設定する。1つのルールについて、設定データ又は設定データの組み合わせ、及びそれに合致する場合のアクション処理動作を、1つ以上設定可能である。例えば、ルールαについて表1のようなルールデータα
1〜α
4が生成される。
【0061】
【表1】
ここで、オーダ様式並びにルール様式のデータ及びルールデータをJSON形式で登録する意義を説明する。JSON形式とは、人間がある程度理解可能であり、かつ、コンピュータでも把握可能なデータの表現形式である。本実施の形態では、オーダ様式又はルール様式の階層構造に従ってオーダ様式設定画面111並びにルール様式設定画面112及びルールデータ設定画面113を構成し、そのオーダ様式並びにルール様式のデータ及びルールデータをそのままのデータ構造でデータベース部13に登録する。
【0062】
そのため、オーダ様式並びにルール様式のデータ及びルールデータが追加されたとしても、データベース部13のデータベース構造を変更する必要はない。それらのデータをJSON形式で登録することにより、オーダ様式登録部121、ルール様式登録部122及びルールデータ登録部123をルール様式毎に開発する必要がなくなるので、その機能部(121〜123)の開発費用及び開発期間を低減できる。
【0063】
なお、オーダデータについてもJSON形式のデータ構造形式を用いる。ルールデータは、オーダデータの項目に従属させてオーダデータのサブセットとして定義する。オーダデータとルールデータとを同じ構造形式で構成することで、汎用的なデータベース構造を実現でき、データ検索処理を向上できる。なお、JSONという形式名称にとらわれず、階層構造形式のデータ構造形式であれば同様の効果が得られる。
【0064】
ここまでの処理は、ルールデータを定義するための事前定義処理である。これ以降は、オーダデータに対してルールを実行する実オーダ処理である。
【0065】
<実オーダ処理:オーダデータの登録>
図9は、オーダデータの登録動作を示す図である。
図2に示したワークフローで「オーダ入力タスク」に遷移すると、ステップS401において、画面処理部11は、オーダデータ入力画面115をユーザ端末の画面に表示する。その後、ステップS402において、オーダデータ登録部126は、オーダデータ入力画面115でユーザにより入力されたオーダデータをデータベース部13に登録する。
【0066】
オーダデータとは、ユーザ(法人などを含む)が受け付けた注文データなどであり、ワークフローシステム1においてルールデータのルール条件に合致するか否かをチェックすべき処理対象のデータである。例えば、顧客又はプロバイダから発注された光回線契約情報である。上述の通りオーダデータのデータ構造形式もJSON形式で構成される。
【0067】
図10は、オーダデータ入力画面115の例を示す図である。オーダデータ入力画面115は、データベース部13に登録されているオーダ様式のデータから選択され作成される。この例では、「申込情報」、「通信グループ」、「アクセス回線設定」、「IPアドレス」、「所属グループ」、「処理結果」がオーダデータの大項目として表示されている。このうち「アクセス回線設定の欄」では、「Config設定」、「設置工事」、「回線種別」がオーダデータの小項目として表示されている。更に、「Config設定」に対して「初期設定(新設・機種変更)」が入力され、「設置工事」に対して「オンサイト工事(NTT派遣)」が入力され、「回線種別」に対して「アクセス回線」が入力されている。これらの入力データがルールデータのルール条件と比較される。「処理結果」の欄は、チェック処理の結果を書き込むための欄である。
【0068】
なお、本実施の形態では、オーダデータを人手で入力する場合を例に説明したが、オーダデータが注文元などでデータ入力されている場合、そのデータ化されたオーダデータをそのままワークフローシステム1のオーダデータとしてデータベース部13に登録してもよい。その際にオーダデータのデータ形式が異なる場合には、そのデータ形式をワークフローシステム1で用いるオーダデータのデータ形式(JSON形式を含む)に変換するオーダデータ形式変換部を備えてもよい。
【0069】
<実オーダ処理:オーダデータのチェック処理及びオーダ実行>
ここまでの処理により、ルールデータ及びオーダデータがデータベース部13に登録される。以降、オーダデータがルールデータのルール条件に合致するか否かをチェックし、その結果に応じてオーダデータを処理する動作を説明する。
図11は、オーダデータに対するルール実行動作を示す図である。このルール実行動作は、
図2に示した「オーダチェックタスク」に遷移した時に実行される。
【0070】
ステップS501において、ルール実行部127は、処理対象となるオーダデータをデータベース部13から読み出し、ステップS502において、ルールタスク設定画面116で指定されたルールIDを取得する。
【0071】
ここで、ルールタスク設定画面116を説明する。
図12は、ルールタスク設定画面116の例を示す図である。ルールタスク設定画面116は、オーダデータに対して適用するルールを指定してオーダ実行を行うための画面であり、データベース部13に登録されているルールの名称、ルールID、ルールの説明などを選択可能である。ルールタスク設定画面116は、ワークフロー定義画面114で「オーダチェックタスク」を設定する際に表示され、ユーザは、表示されたルールIDの中から1つ以上のルールIDを指定し、指定したルールIDに対してルールの実行順位付けを予め決定しておくことになる。ステップS502以降は、ルールタスク設定画面116で予め特定されているルールID及び実行順位に基づき自動で実行される。
【0072】
次に、ステップS503において、ルール実行部127は、ステップS502で取得したルールIDに係るルールデータの条件項目をデータベース部13のルール様式のデータから読み出し、ステップS504において、読み出したルールデータの条件項目に対応する入力データをオーダデータから取得する。
【0073】
次に、ステップS505において、ルール実行部127は、ステップS502で取得した指定ルールIDとステップS504で取得したオーダデータの条件項目の入力データとをキーとして、データベース部13から該当のルールデータを検索し、検索したルールデータのアクション処理動作を取得する。
【0074】
ここで、ステップS503〜S505の処理動作を詳述する。本発明では、データベース部13に登録されている大量のルールデータを全て検索するのではなく、指定ルールIDとオーダデータの条件項目の入力データとに対応するルールデータのみをデータベース部13から検索する。
【0075】
例えば、
図12のルールタスク設定画面116で「ルールα」が指定された場合、
図6に示された「ルールα」のルール様式より、指定「ルールα」に係るルールの条件項目として「Config設定」と「設置工事」を読み出す。そして、
図10のオーダデータから、それらの条件項目に対応する「初期設定(新設・機種変更)」と「オンサイト工事(NTT派遣)」を取得する。その後、データベース部13に登録されている複数のルールデータの中から、「ルールα」のID(=α)に該当し、かつ、「Config設定」と「設置工事」の条件項目に「初期設定(新設・機種変更)」と「オンサイト工事(NTT派遣)」が設定されているルールデータを検索する。ルールIDの検索処理とルールデータの検索処理とは一度(同時)に行われる。「ルールα」に係るルールデータが上記表1の通りであれば、ルールデータα
1が検索されることになる。
【0076】
次に、ステップS506において、ルール実行部127は、ステップS505でルールデータが1つ以上検索されたか否かを判定する。該当のルールデータが1つ以上ある場合、ステップS507において、ルール実行部127は、そのルールデータに設定されているアクション処理動作の種別が「ルール実行」であるか否かを判定する。アクション処理の種別が「ルール実行」の場合、そのルールデータで指定されているルールでルール実行を更に行う必要があるので、ステップS503へ戻る。一方、その種別が「ルール実行」以外の場合、ステップS508において、ルール実行部127は、該当のルールデータに設定されている詳細処理動作を実行し又は詳細処理情報を入力し若しくは表示する。具体的な動作内容は、該当のルールデータの設定内容に従う。
【0077】
なお、ステップS506で該当のルールデータが無い場合には、ルールデータ(α
1,α
2,…)のルール条件には合致しないが指定ルールIDに対応するルール(α,β,…)があれば、ステップS509において、ルール実行部127は、そのルールに設定されているエラー処理動作を実行する。
【0078】
以上より、本実施の形態によれば、ルールIDとオーダデータの入力データとに対応するルールデータのみをデータベース部13から検索するので、オーダデータのチェック処理を高速に実行でき、ワークフロー処理のリアルタイム性を向上できる。
【0079】
なお、
図2に示したワークフローでは、「オーダチェックタスク」の後に「XOR分岐」が設定されている。ユーザは「XOR分岐」に対する分岐条件を予め設定可能であり、例えば
図13に示す分岐設定画面117を用いて、「オーダチェックタスク」での処理結果に基づくワークフローの遷移先を設定できる。例えば、オーダデータがルールデータのルール条件に合致しない場合、オーダデータの入力データを修正するための「データ修正タスク」へ遷移させる。「データ修正タスク」に遷移するとオーダデータの入力データに対する修正処理が促され、ユーザにより入力データが修正された後に、修正後のオーダデータを用いてチェック処理が再実行される。
【0080】
(ルールデータの検索方法:具体例1)
引き続き、ルールデータの検索方法の具体例を説明する。具体例1では、インデックス機能を用いた検索方法を説明する。
【0081】
まず、ルールデータを登録する際、ルールデータ登録部123は、ルールデータの条件項目に設定されている設定データをハッシュ化してルールデータのハッシュ値を算出する。例えば、表1のようにルールαの条件項目の数が2つの場合、その2つの条件項目に対応する2つの設定データを用いて各ルールデータ(α
1,α
2,…)のハッシュ値(例えば、154,200,…)をそれぞれ算出する。
【0082】
次に、ルールデータ登録部123は、算出したハッシュ値をルールデータのインデックスとし、そのインデックスとルールIDとを関連付けてデータベース部13に登録する。上記例の場合、ルールデータα
1について、「ルールID=α」と「インデックス=154」とを関連付けたインデックステーブルが登録される。このインデックス化処理は、ルールデータを登録する毎に行われる。
【0083】
その後、オーダデータのチェック処理が開始されると、ルール実行部127は、処理すべきオーダデータの入力データを用いてオーダデータのハッシュ値を算出する。そして、そのオーダデータのハッシュ値とインデックステーブル内のルールデータのインデックスとを比較して、オーダデータのハッシュ値に合致するインデックスを持つルールデータを抽出する。
【0084】
以上より、具体例1によれば、インデックスを用いてルールデータを検索するので、大量のルールデータの中から該当のルールデータを瞬時に検索でき、ワークフロー処理のリアルタイム性を更に向上できる。
【0085】
なお、インデックスは、ルールIDである「α」を更に加えて算出してもよいし、ルールαのカラム値を更に用いてもよい。この場合、インデックスがルールID又はカラム値を含めて算出されるので、インデックステーブルはインデックスの値のみを管理することで足り、メモリの使用効率を向上できる。
【0086】
(ルールデータの検索方法:具体例2)
具体例1は、ルールデータの条件項目に一意の設定データが設定されていることを前提としている。一方、その条件項目に複数かつ任意の値を取り得るワイルドカードが設定されている場合、インデックスを算出するには、ワイルドカードの取り得る全ての値を用いなければならない。例えば、その取り得る値が3種類であれば、1つのルールデータ(α
1,α
2,…)について3通りのインデックスが生成される。
【0087】
しかし、これでは、本来であれば条件項目に対する設定データが1つに定義されていることが好ましいルールデータが複数のパターンを持つことになり、ルールデータの数が増加して管理が大変となる。本発明では、設定データの組み合わせパターンを全て網羅する必要があり、加えて条件項目の数が増えるとその分組み合わせパターン数も更に膨大となり、その結果としてルールデータが更に増加することになる。
【0088】
そこで、具体例2では、条件項目の範囲を局所化する方法を説明する。つまり、ワイルドカードの有無で条件項目の範囲を絞り、それに基づき複数のルールデータを分割して各ルールデータ群をそれぞれ別々に用いる。具体的には、データベース部13に登録されている複数のルールデータ(α
1,α
2,…,β
1,…,γ
1,…)を、同じ条件項目にワイルドカードが設定されているルールデータからなるルールデータ群(A,B,C,…)に分け、その条件項目以外の条件項目に適用されるルールデータ群として管理する。そして、オーダデータのチェック処理を行う際には、複数のルールデータ群のうち、オーダデータの入力データの条件項目と同じ条件項目のルールデータ群からルールデータを検索する。
【0089】
具体例2の動作を説明する。データベース部13には、
図14に示すルールデータ(α
1〜α
5)が登録されているものとする。図中の「−」は、ワイルドカードを示す。
【0090】
まず、ルールデータ管理部(
図1において不図示)は、データベース部13に登録されているルールデータα
1〜ルールデータα
5を、条件項目「I
4,I
5」にワイルドカードがあるルールデータ群A(ルールデータα
1〜ルールデータα
3)と、条件項目「I
1〜I
3」にワイルドカードがあるルールデータ群B(ルールデータα
4,ルールデータα
5)とに分ける。
【0091】
次に、ルールデータ管理部は、ルールデータ群Aに含まれるルールデータからワイルドカード以外の条件項目「I
1〜I
3」の設定データを抽出(ルールデータα
1であれば設定データ「A,a,1」を抽出)してハッシュ値を求め、そのハッシュ値をインデックスとしてルールデータα
1に関連付けてインデックステーブルに登録する。他のルールデータα
2,α
3についても同様の処理を行う。そして、ルールデータ群Aを条件項目「I
1〜I
3」に適用されるルールとして管理する。ルールデータ群Bについても同様の処理を行う。
【0092】
ここまでの処理は、ルールデータをデータベース部13に登録した後、実オーダ処理を開始する前に実行される。すなわち、全てのルールデータを対象として分離・分割処理を行い、ルールデータ群への分類処理を予め実施しておくことにより、ルールデータ群(A,B,…)に分類されたルール(α,β,…)のルールデータが自動登録されることになる。なお、この分離・分割処理は、ルール様式を登録する際にユーザが人手で行ってもよい。
【0093】
その後、ルール実行部127は、受け付けたルールIDに係るルールデータのハッシュ値を算出し、そのルールIDに係るルールデータの条件項目と同じ条件項目を持つルールデータ群(A,B,C,…)をデータベース部13から検索し、検索したルールデータ群の中からオーダデータのハッシュ値と同じハッシュ値を持つオーダデータを抽出する。
【0094】
以上より、具体例2によれば、複数のルールデータを、同じ条件項目にワイルドカードが設定されているルールデータからなるルールデータ群に分け、当該条件項目以外の条件項目に適用されるルールデータ群として管理し、複数のルールデータ群のうち、オーダデータの入力データの条件項目と同じ条件項目のルールデータ群からルールデータを検索するので、ワイルドカードを除く条件項目の設定データを用いてインデックスが生成されることから、その結果ルールデータ数の増加を抑制できる。
【0095】
例えば、
図14に示したルールデータα
1の場合、インデックスが一意に決まることになる。ルールデータα
2の場合、条件項目「I
3」にワイルドカードが設定されているが、条件項目「I
4,I
5」のワイルドカードを更に含める場合よりもルールデータ数の増加を抑制できる。仮に、
図14に示した25つ全てのカラムの設定データがワイルドカードであり、ワイルドカードの取り得る値が5つであれば、3,125(=5×5×5×5×5)通りの組み合わせパターンになるが、実施例2の場合には125通り(=5×5×5)と25通り(=5×5)となるので、ルールデータの総数を低減可能となる。
【0096】
(ルールデータの検索方法:具体例3)
ルールデータの条件項目は追加可能である。しかし、元々の条件項目に新たな条件項目を追加すると、その追加分の条件項目を網羅する設定データの組み合わせパターンは大きく増加する。例えば、条件項目「I
1〜I
3」に対して条件項目「I
4,I
5」が追加されると、追加した2つの条件項目の取り得る値がそれぞれ2つであれば、設定データの組み合わせパターンは元々の4倍(=2×2)に増加する。
【0097】
そこで、具体例3では、条件項目の範囲を分割してルールをカスケードに適用する方法を説明する。具体的には、追加分を含む全ての条件項目に対応するルールデータを、元々の条件項目からなるルールデータ群と新たな条件項目からなるルールデータ群とに分ける。そして、元々の条件項目の設定データを用いてルールデータを検索した後に、その元々の条件項目に関連又は紐付くような項目(新たな条件項目)があれば、その新たな条件項目の設定データを用いてルールデータを更に検索する。
【0098】
具体例3の動作を説明する。データベース部13には、
図15に示すルールデータが登録されているものとする。図中の「−」は、ワイルドカードを示す。条件項目「I
4,I
5」は、追加された条件項目であり、元々のルールデータα
1にのみ関連する条件項目である。この例では、追加した条件項目「I
4,I
5」の設定データの組み合わせパターンは2つなので、ルールデータα
1が1つ分コピーされ、その2パターンにそれぞれ対応する同じ組み合わせの設定データ「A,a,1」がルールデータα
1,α
2としてそれぞれ設定されている。
【0099】
まず、ルールデータ管理部(
図1において不図示)は、データベース部13に登録されているルールデータを、元々の条件項目「I
1〜I
3」に係るルールαのルールデータ群A(ルールデータα
1〜α
4)と、新たな条件項目「I
4,I
5」に係るルールβのルールデータ群B(ルールデータβ
1,β
2)とに分ける。ワイルドカードが設定されている場合には、ワイルドカードを除いてルールデータ群を形成する。この処理は、具体例2と同様に、実オーダの処理中以外のタイミングで行われる。また、ユーザが人手で行ってもよい。
【0100】
その後、ルール実行部127は、先ずルールαのルールデータ群Aの中から条件項目「I
1〜I
3」の設定データの組み合わせに合致するルールデータを検索し、ルールデータα
1が検索された場合には当該ルールデータα
1のアクションにルールβのルール実行があるので、引き続きルールデータ群Bの中からルールデータを検索する。
【0101】
以上より、具体例3によれば、一部の条件項目の設定データを用いてルールデータを検索した後に、他の一部の条件項目の設定データを用いてルールデータを更に検索するので、ルールデータを効率よく検索できる。
【0102】
(ルールデータの検索方法:具体例4)
所定のアクションに対して条件項目の設定データが範囲で指定される場合がある。例えば、「10%割引」のアクションに対して「購入金額が500円以上かつ1000円未満の場合」のルール条件を付与する場合である。この場合、コンピュータ内では、大小比較を行う「if」又は「then」でツリー状にカスケードするデシジョンツリーを用いて逐次判断する必要があり、データベース検索に比べて十分な処理時間が得られない可能性がある。
【0103】
そこで、動作例4では、条件項目の入力欄に設定し得る設定データを一定範囲から選択可能に表示し、その一定範囲をコード値に変換したコードテーブルを予め保持しておく。例えば、
図16に示すように、「数量」の条件項目に対して、「1〜5」,「6〜10」などの数値範囲を選択可能に表示し、「1〜5」が設定された場合には、その数値範囲をコードテーブルより所定のコード値(例えば「01」)に変換し、そのコード値「01」をキーとしてルールデータをデータベース部13から検索する。
【0104】
以上より、具体例4によれば、一定範囲の数値を選択可能に表示し、指定された範囲の数値を所定のコード値に変換して該コード値に対応するルールデータを検索するので、ルールデータを効率よく検索できる。
【0105】
<他システムからのデータ取得>
最後に、自身のワークフローシステム1以外の他システムからデータを取得し、自己のシステムで用いるデータとして活用する場合について説明する。
【0106】
(他システムからのオーダデータ要素の検索・取得)
図2のワークフローの場合、「オーダチェックタスク」の後に「他システム情報取得タスク」へ遷移する。このとき、API呼出し実行部128が起動し、他システムからオーダデータの入力データと成り得るデータを検索して取得する。具体的には、オーダデータを成す項目の入力データをパラメータとしてAPIリクエストに含め、それ以外の項目に対するデータを外部システムから検索・取得してオーダデータに追加する。例えば、
図10のオーダデータにおいて、「Config設定」,「設置工事」,「回線種別」の3つの項目への入力データをパラメータに含めたリクエストを外部システムへ送信し、その応答としてそれら以外の項目に対する入力データを取得する。これにより、従前の「オーダチェックタスク」で元のオーダデータでルール実行を行った後、新たなオーダデータを用いてルール実行を自動で行うことができる。
【0107】
(他システムからのルールデータ要素検索・取得)
ルールデータは、一般的に事業主の持つ既存設備に対して生成される。一方、事業協力・経営統合など、他の事業主が持つ設備を用いることも当然に考えられる。例えば、回線種別として光回線を持つ事業主が他の事業主から無線回線の貸与又は譲渡を受ける場合が考えられる。
【0108】
そこで、ワークフローシステム1は、他のシステムからルールデータの条件項目に設定可能なデータを受信するAPIを持つ。具体的に、API呼出し部128は、ユーザにより指定されたルール条件の要素データをワークフローシステム1以外の他システムから検索して取得する。ルールデータを登録する際には、ここで取得した他システムからのデータも併せてルールの条件項目の入力欄に選択可能に表示される。なお、他システムからのルール要素検索処理は様々なタイミングで行うことが考えられるので、API呼出し部128は、ブロック図形間を連結する任意の経路上に設定可能であることが好ましい。例えば、
図2に示した「オーダチェックタスク」の前に配置する又は配置変更する。
【0109】
以上より、本実施の形態によれば、ワークフローシステム1以外のシステムからルールデータの条件項目に設定可能な要素データを検索して取得するので、その条件項目に設定可能な設定データの適用範囲を拡大できる。
【0110】
最後に、本実施の形態で説明したワークフローシステム1について補足する。ワークフローシステム1は、少なくともCPU及びメモリを備えたコンピュータで実現可能である。また、本実施の形態で説明した処理は、OS(Operating System)、アプリケーションプログラムなどのプログラムで実行される。更に、ワークフローシステム1の各動作をプログラムとして構築し、コンピュータにインストールして実行させ、インターネット等の通信網を介して流通させ、更には、その記録媒体を作成することも可能である。