JP6758167B2 - データ処理装置、データ処理方法及びデータ処理プログラム - Google Patents

Description

本発明は、データを処理する技術に関する。特に、ワークフローシステムで処理すべきオーダデータに対するルール条件との適合性をチェックする技術に関する。

企業内部の業務統制及び業務効率化を図るため、多くの企業でワークフローシステムが導入されている。ワークフローシステムでは業務処理の流れを図式化し、一連の業務処理手続きを可視化することで、作業の進捗及び作業の問題点を容易かつ迅速に把握できる。

ワークフローシステムは、業務目的を完遂するために段階的な複数のソフトウェア機能で構成される。例えば回線敷設工事の場合、顧客データをデータベースに登録する機能、顧客の注文内容をオーダデータとしてデータベースに登録する機能、そのオーダデータに基づきＩＰアドレスなどの情報をサービス提供機器に設定する機能で構成される。

また、ワークフローシステムは、これらの機能を実行する前の事前段階で実行する機能を更に備えている。例えば、オーダデータの内容が適正かをチェックするためのルールデータや当該ルールデータを生成するための雛形であるルール様式などを予め生成して登録しておく機能である。

ここで、ルール様式及びルールデータの登録機能を開発する場合、一般的にはデータ設計、画面設計、ロジック設計が行われる。しかし、各設計をルール様式毎に行うと開発費用及び開発期間がかかる。そこで、特許文献１では、データをＪＳＯＮ（JavaScript Object Notation）形式のデータ構造で格納する方式を採用している。それゆえ、ルール様式及びルールデータの登録機能にもＪＳＯＮ形式を適用することで、データ構造を一様とするルール様式及びルールデータを登録できる。

特開２０１６−１２６４２０号公報

しかしながら、大量のルールデータがデータベースに登録されるため、オーダデータの値をチェックする際に、全てのルールデータをデータベースから検索してチェック処理を順次実行すると、そのチェック処理によりコンピュータに負荷がかかり、ワークフロー処理のリアルタイム性が失われてしまう。

本発明は、上記事情を鑑みてなされたものであり、ルールデータの検索処理速度を改善し、処理対象データをチェックする処理速度を改善することを目的とする。

以上の課題を解決するため、請求項１に記載のデータ処理装置は、条件項目に設定された設定データまたは設定データの組み合わせに合致する場合と合致しない場合の処理ルールを定めた複数のルールデータを記憶部に登録する登録部と、処理対象データに適用されるルールのルール識別子を受け付け、前記ルール識別子に係るルールデータの条件項目に対応する入力データを前記処理対象データから取得し、前記ルール識別子に対応するルールデータであり、前記入力データと同じ設定データまたは同じ組み合わせの設定データが設定されたルールデータを前記記憶部から検索する検索部と、検索されたルールデータの処理ルールを実行する実行部と、を備えることを要旨とする。

請求項２に記載のデータ処理装置は、請求項１に記載のデータ処理装置において、前記複数のルールデータは、同じ条件項目にワイルドカードが設定されているルールデータからなるルールデータ群に分けられ、前記ルールデータ群は、当該条件項目以外の条件項目に適用されるルールデータ群であって、前記検索部は、複数のルールデータ群のうち前記入力データの条件項目と同じ条件項目のルールデータ群からルールデータを検索することを要旨とする。

請求項３に記載のデータ処理装置は、請求項１又は２に記載のデータ処理装置において、前記検索部は、一部の条件項目の設定データを用いてルールデータを検索した後に、他の一部の条件項目の設定データを用いてルールデータを更に検索することを要旨とする。

請求項４に記載のデータ処理装置は、請求項１乃至３のいずれかに記載のデータ処理装置において、一定単位の処理を示す複数のブロック図形を画面に表示する表示部と、ブロック図形間を連結する任意の経路上に設定可能なブロック図形に対応し、自データ処理装置以外の装置から前記処理対象データの入力データの項目又は前記ルールデータの条件項目に設定可能なデータを検索する検索部と、を備えることを要旨とする。

請求項５に記載のデータ処理装置は、請求項４に記載のデータ処理装置において、前記表示部は、複数の前記入力データのうち各処理でそれぞれ用いる入力データのみを入力させる各画面を画面遷移により段階的に表示することを要旨とする。

請求項６に記載のデータ処理方法は、データ処理装置で行うデータ処理方法において、条件項目に設定された設定データまたは設定データの組み合わせに合致する場合と合致しない場合の処理ルールを定めた複数のルールデータを記憶部に登録するステップと、処理対象データに適用されるルールのルール識別子を受け付け、前記ルール識別子に係るルールデータの条件項目に対応する入力データを前記処理対象データから取得し、前記ルール識別子に対応するルールデータであり、前記入力データと同じ設定データまたは同じ組み合わせの設定データが設定されたルールデータを前記記憶部から検索するステップと、検索されたルールデータの処理ルールを実行するステップと、を実行することを要旨とする。

請求項７に記載のデータ処理プログラムは、請求項１乃至５のいずれかに記載のデータ処理装置としてコンピュータを機能させることを要旨とする。

本発明によれば、ルールデータを検索する処理速度を向上でき、処理対象データをチェックする処理速度を向上できる。

ワークフローシステムの全体構成を示す図である。 ワークフロー定義画面の例を示す図である。 ワークフロー定義画面の模式図である。 オーダ様式の登録動作を示す図である。 ルール様式の登録動作を示す図である。 ルール様式設定画面の例を示す図である。 ルールデータの登録動作を示す図である。 ルールデータ設定画面の例を示す図である。 オーダデータの登録動作を示す図である。 オーダデータ入力画面の例を示す図である。 オーダデータに対するルール実行動作を示す図である。 ルールタスク設定画面の例を示す図である。 分岐設定画面の例を示す図である。 ルールデータの局所化例を示す図である。 ルールデータの分割例を示す図である。 ルールデータの設定例を示す図である。

＜＜概要＞＞
上記課題を解決するため、本発明では、オーダデータに適用されるルールのルールＩＤと、そのルールＩＤに係るルールデータの条件項目とをキーとして、データベースからルールデータを検索する。これにより、全てのルールデータを走査する従来方式と比較して、ルールデータ数に因らない高速なルールデータの検索処理が可能となり、オーダデータのチェック処理を短時間で実現可能となる。

また、ルールデータの条件項目については、オーダデータの項目から選定して定義する。さらに、オーダデータがルールデータの条件項目に合致する場合のアクションについては、ＯＫを画面などに出力する基本方式に加え、オーダデータへの情報の書き込み、他ルールのカスケード的な呼び出し、ロジック処理を想定したスクリプト実行などを指定できるＵＩ画面を提供する。

以下、本発明を実施する一実施の形態について図面を用いて説明する。

＜＜システム構成＞＞
図１は、本実施の形態に係るワークフローシステム１の全体構成を示す図である。ワークフローシステム１（データ処理装置）は、画面処理部１１と、データ処理部１２と、データベース部１３と、を備えて構成される。

画面処理部１１は、図１に例示するように、オーダ様式設定画面１１１と、ルール様式設定画面１１２と、ルールデータ設定画面１１３と、ワークフロー定義画面１１４と、オーダデータ入力画面１１５とを生成し、ワークフローシステム１を利用するユーザ端末の画面に表示する。

データ処理部１２は、オーダ様式登録部１２１と、ルール様式登録部１２２と、ルールデータ登録部１２３と、ワークフロー登録部１２４と、ワークフロー実行部１２５と、オーダデータ登録部１２６と、ルール実行部１２７と、ＡＰＩ呼出し実行部１２８と、を備えて構成される。以降、これらの機能部（１２１〜１２８）を説明する。

オーダ様式登録部１２１は、オーダ様式設定画面１１１で入力されたオーダ様式のデータをデータベース部１３に登録する機能を備える。オーダ様式とは、オーダデータをワークフローシステム１に入力するための元となる雛形データである。また、オーダ様式は、ワークフローシステム１の利用者である事業主の持つサービス提供機器やサービス内容種別に応じて、基本的には事業主により予め定義されるデータである。例えば、オーダデータの構成項目と成り得る項目の名称、その項目に対して入力され得る入力データである。

このオーダ様式のデータは、ルールデータを生成するための元データとしても用いられる。ルールデータは、オーダデータの内容をチェックするためのものであり、オーダ様式のデータは、オーダデータとルールデータとで共通の元データとなる。

ルール様式登録部１２２は、ルール様式設定画面１１２で入力されたルール様式のデータをデータベース部１３に登録する機能を備える。ルール様式とは、ルールデータを生成するための元となる雛形データである。例えば、ルール条件、そのルール条件に合致しない場合のエラー処理（処理ルール）が含まれる。

ルールデータ登録部１２３は、ルールデータ設定画面１１３で入力されたルールデータをデータベース部１３に登録する機能を備える。ルールデータとは、オーダデータの内容が適正かをチェックするためのデータであり、ルール様式を用いて生成される。例えば、ルール様式のルール条件に対して設定された具体的な条件値、そのルール条件に合致する場合のアクション（処理ルール）が含まれる。

ワークフロー登録部１２４は、ワークフロー定義画面１１４で定義されたワークフローのデータをデータベース部１３に登録する機能を備える。ワークフローとは、順次行う複数の処理タスクを業務の流れに沿って関連付けた処理遷移図である。ユーザは、ワークフロー定義画面１１４でタスクを適宜選定し、その処理順を定義可能である。

実行タスクには、例えば、表示画面上で作業者がデータ入力を行う人タスク（Ｔ）、オーダデータに対して所定のルールを実行するルールタスク（Ｒ）、オーダデータの入力データと成り得るデータを自システム以外の他システムから取得するためのＡＰＩ（Application Program Interface）を呼び出すＡＰＩタスク（Ａ）がある。

ここまで説明した機能部（１２１〜１２４）は、ワークフローを開始する前に実行される。一方、ここから説明する機能部（１２５〜１２８）は、オーダデータを処理する際に実行される。

ワークフロー実行部１２５は、所定のワークフローをデータベース部１３から読み出し、そのワークフローで定義された処理順に沿って各タスクをそれぞれ自動で実行する機能を備える。具体的には、読み出された所定パターンのワークフローに沿ってタスク処理を順次実行し、本実施の形態では、所定タイミングの実行タスクが人タスク（Ｔ）であればオーダデータ登録部１２６を実行し、ルールタスク（Ｒ）であればルール実行部１２７を実行し、ＡＰＩタスク（Ａ）であればＡＰＩ呼出し実行部１２８を実行する。

オーダデータ登録部１２６は、人タスク（Ｔ）の機能部であり、オーダデータ入力画面１１５で入力されたオーダデータをデータベース部１３に登録する機能を備える。オーダデータとは、顧客からの注文内容に基づき生成された処理対象データであり、画面に表示されたオーダ様式のデータの中から選択することで生成される。

ルール実行部１２７は、ルールタスク（Ｔ）の機能部であり、オーダデータに対してユーザ指定のルールを実行する機能部である。ルールの実行とは、ルールを識別するルールＩＤとルール様式の条件項目とをキーとしてデータベース部１３からルールデータを検索し、そのルールデータに定義されているアクションを実行することをいう。

具体的には、ルール実行部１２７は、所望のオーダデータに適用されるルールのルールＩＤを受け付け、そのルールＩＤに係るルールデータの条件項目に対応する入力データを該オーダデータから取得し、そのルールＩＤに対応するルールデータであり、取得した入力データと同じ条件値（設定データ）又は同じ組み合わせの設定データが設定されたルールデータをデータベース部１３から検索する。その後、ルール実行部１２７は、検索したルールデータに設定されているアクションを実行する。一方、該当するルールデータが検索されない場合には、受け付けたルールＩＤのルールに設定されているエラー処理を実行する。

また、ルール実行部１２７は、複数のルールデータ群のうち、オーダデータ内の入力データの条件項目と同じ条件項目のルールデータ群からルールデータを検索する機能を更に備える。ここでいうルールデータ群とは、データベース部１３に登録されている複数のルールデータを、同じ条件項目にワイルドカードが設定されているルールデータからなる集合に分けた場合のルールデータ群であり、当該条件項目以外の条件項目に適用されるルールデータ群である。なお、ワイルドカードとは、その取り得る値が複数かつ任意であるデータをいう。

更に、ルール実行部１２７は、複数の条件項目のうち一部の条件項目の設定データを用いてルールデータを検索した後に、他の一部の条件項目の設定データを用いてルールデータを更に検索する機能を備える。

ＡＰＩ呼出し部１２８は、ＡＰＩタスク（Ａ）の機能部であり、自身のワークフローシステム１以外の他システムからオーダデータの入力データと成り得るデータを検索して取得するためのＡＰＩを呼び出す機能を備える。

＜＜ワークフローシステムの画面＞＞
ワークフローの全体を把握するため、先にワークフロー定義画面１１４を説明する。図２は、ワークフロー定義画面１１４の例を示す図である。ワークフロー定義画面１１４は、ワークフロー全体の流れを図式化した画面であり、業務の流れに沿って順次行う複数の処理タスクを関連付けるために用いられる。

ユーザによりワークフロー定義要求が行われると、画面処理部１１は、ワークフロー定義画面１１４をユーザ端末の画面に表示する。ワークフロー定義画面１１４には、ワークフローを定義するための雛形図形（処理タスク用のブロック図形など）が予め用意されている。ユーザは、下部のメニューから雛形図形をドラッグし、上部の描画エリアにドロップして移動させる。そして、業務目的を考慮しつつ、その雛形図形を描画エリア内の適切な位置に配置し、雛形図形間を適宜接続して関連付ける。これにより、所望の業務目的を完遂するためのワークフローが定義される。業務内容に応じて様々なパターンのワークフローを定義可能である。

その後、ユーザ指定のワークフローがデータベース部１３から読み出され、ワークフロー実行部１２５により処理が開始されると、そのワークフローのフロー沿って各タスクが自動的に順次実行される。図２に示したワークフローの場合、例えば、「オーダ入力タスク」→「オーダチェックタスク」→「他システム情報取得タスク」の順で実行される。「オーダチェックタスク」で行われた処理の結果、オーダデータの修正が必要な場合には、「オーダ修正タスク」へ遷移して再び「オーダチェックタスク」が実行される。

ここで、ワークフロー定義画面１１４を構成する図形を説明する。ユーザは、例えばブロック図形を利用できる。ブロック図形とは、一定単位の処理タスクを意味する図形であり、業務の種類又は業務処理の主体などに応じて予め用意されている。例えば、画面入力など人手の作業を要する場合には人タスク（Ｔ）を利用可能であり、図２に示した「オーダ入力タスク」及び「オーダ修正タスク」がそれに該当する。その他、オーダデータに対して所定のルールを実行するルールタスク（Ｒ）、オーダデータの入力データと成り得るデータを自システム以外の他システムから取得するためのＡＰＩを呼び出すＡＰＩタスク（Ａ）を利用可能である。図２に示した「オーダチェックタスク」はルールタスク（Ｒ）に該当し、「他システム情報取得タスク」はＡＰＩタスク（Ａ）に該当する。

その他、ブロック図形間を接続するための接続図形、その接続経路を分岐又は統合するための分岐・統合図形も利用できる。分岐・統合図形としては、例えばＸＯＲ分岐が考えられる。分岐・統合図形に対応する分岐設定画面又は統合設定画面を生成して表示することも可能である。ワークフローは、処理の進捗に伴い接続図形の矢印の方向に沿って自動で進行し、分岐がある場合は分岐図形の定義に従う。

なお、図２に示したワークフロー定義画面１１４は例である。ユーザは、任意のブロック図形及び分岐・統合図形を描画エリア内の任意の位置に配置し、接続図形で図形間を任意に接続できる。また、画面の構成粒度も任意に設定できる。例えば、「他システム情報取得タスク」については、フロー上の特定のタイミングで実行する必要はなく、「オーダチェックタスク」又は「オーダ入力タスク」の前又はその間に実行してもよいことから、ブロック図形間を連結する任意の経路上に設定可能である。

また、図３に示すように、ワークフローが複数の人タスク（Ｔ）で定義される場合、各人タスク（Ｔ）で共通して用いる１つのメイン入力画面を、個々のタスクＡ，Ｂ，Ｃでそれぞれ必要なデータを入力するためのサブ入力画面に分けてもよい。すなわち、複数の入力データのうち各タスクＡ，Ｂ，Ｃでそれぞれ使用する入力データのみを入力させる各サブ画面を画面遷移により段階的に表示してもよい。これにより、ワークフローシステム１のユーザビリティを向上できる。

その他、図２又は図３に示したワークフローの一部のみを生成してもよいし、作成済みのワークフローをコピーして他のワークフローの雛形として利用してもよい。

＜＜システム動作＞＞
次に、ワークフローシステム１の動作を説明する。

＜事前定義処理：オーダ様式の登録＞
図４は、オーダ様式の登録動作を示す図である。ステップＳ１０１において、画面処理部１１は、ユーザによるオーダ様式設定要求に応じてオーダ様式設定画面１１１をユーザ端末の画面に表示する。その後、ステップＳ１０２において、オーダ様式登録部１２１は、オーダ様式設定画面１１１でユーザにより入力されたオーダ様式のデータをＪＳＯＮ形式でデータベース部１３に登録する。

具体的には、オーダデータの構成項目と成り得る大項目並びに小項目の名称、及び小項目に対して入力され得る入力データが予め登録される。例えば、大項目としては「アクセス回線設定」が登録され、その大項目に対する小項目としては「Ｃｏｎｆｉｇ設定」、「設置工事」、「回線種別」が登録される（後述する図１０参照）。また、その「Ｃｏｎｆｉｇ設定」に対する入力データとしては、例えば、「初期設定（新設・機種変更）」、「設定変更」、「未変更」が登録される。これらオーダ様式のデータは、ルール様式を生成する際の元データとしても用いられる。

＜事前定義処理：ルール様式の登録＞
図５は、ルール様式の登録動作を示す図である。ステップＳ２０１において、画面処理部１１は、ユーザによるルール様式設定要求に応じてルール様式設定画面１１２をユーザ端末の画面に表示する。その後、ステップＳ２０２において、ルール様式登録部１２２は、ルール様式設定画面１１２でユーザにより入力されたルール様式のデータをＪＳＯＮ形式でデータベース部１３に登録する。

図６は、ルール様式設定画面１１２の例を示す図である。ルールタブ１１２ｚで所定ルールのルール様式を設定可能である。図６（ａ）に示すように、所定ルールを定めるルール様式には、そのルールに対して一意のルールＩＤ（α，β，γ，…）が割り振られる。また、ルール様式設定画面１１２は、条件設定画面１１２ａと、アクション設定画面１１２ｂと、エラー処理設定画面１１２ｃと、を備える。

条件設定画面１１２ａには、ルールの条件項目が設定される。ルールの条件項目は、増減可能であり、オーダ様式のデータから選択される。具体的には、オーダ様式で小項目として登録されている複数の名称を選択可能に表示し、その中からユーザの指定した名称がルールの条件項目として設定される。図６（ａ）の場合、「Ｃｏｎｆｉｇ設定」、「設置工事」がルールの条件項目として設定されている。また、条件項目の右側には、その条件項目に条件値を設定するための入力欄が設けられており、その入力欄には、オーダ様式で定義されていた小項目に対する複数の入力データが選択可能に用意されている。

アクション設定画面１１２ｂについては後述する。エラー処理設定画面１１２ｃには、ルール（１つのルール様式を用いて設定される全てのルールデータのルール条件）に合致しない場合のエラー処理が設定される。具体的には、各ルールデータの条件項目に設定された条件値（設定データ）又は設定データの組み合わせに合致しない場合におけるエラー処理動作の種別及び詳細処理情報又は詳細処理動作が設定される。エラー処理動作の種別は予め用意された複数の中から選択可能であり、詳細処理情報又は詳細処理動作は任意に設定可能である。例えば、「ＮＧ」、「入力データが不適切です」、「入力データの組み合わせが不適切です」の詳細処理情報が設定される。

ユーザは、このようなルール様式設定画面１１２を画面に表示した後、所望のルール様式で用いる１つ以上の条件項目及び該条件項目の名称を設定し、このルール様式に合致しない場合のエラー処理動作を設定する。この処理を繰り返すことにより、複数のルール様式がデータベース部１３に登録される。

＜事前定義処理：ルールデータの登録＞
図７は、ルールデータの登録動作を示す図である。ステップＳ３０１において、画面処理部１１は、ユーザによるルールデータ登録要求に応じて、その要求で指定されたルール様式で構成されるルールデータ設定画面１１３をユーザ端末の画面に表示する。その後、ステップＳ３０２において、ルールデータ登録部１２３は、ルールデータ設定画面１１３でユーザにより入力されたルールデータをＪＳＯＮ形式でデータベース部１３に登録する。

図８は、ルールデータ設定画面１１３の例を示す図である。図８（ａ）に示すように、ルールデータ設定画面１１３は、条件設定画面１３１ａと、アクション設定画面１３１ｂと、で構成される。

条件設定画面１３１ａには、ルールの条件項目及び該条件項目に条件値を設定するための入力欄が表示される。入力欄右端にあるセレクタボタンの押下げにより、入力欄に予め用意されていた条件項目に対する複数のデータ（オーダ様式のデータ）が選択可能に表示され、その中からユーザにより選択されたデータがルールデータのルール条件値として入力欄に入力される。例えば、「Ｃｏｎｆｉｇ設定」の条件項目に対するデータとして「初期設定（新設・機種変更）」、「変更設定（取り付け工事無し）」、「変更設定（取り付け工事無し）」、「未実施（選択不可）」が予め用意されており、その中から「初期設定（新設・機種変更）」が選択される。

アクション設定画面１３１ｂには、ルールデータのルール条件に合致する場合のアクションが設定される。具体的には、ルールデータの条件項目に設定された条件値（設定データ）又は設定データの組み合わせに合致する場合におけるアクション処理動作の種別及び詳細処理情報又は詳細処理動作が設定される。アクション処理動作の種別は予め用意された後述する複数の中から選択可能であり、詳細処理情報又は詳細処理動作は任意に設定可能である。アクション処理は、１つに限らず複数設定可能である。

ここで、アクション処理動作の種別を説明する。任意の種別を選択して設定できるが、例えば「オーダ書き込み」を選択可能である。このアクションを選択した場合、ルール条件に合致するオーダデータに対して所定の情報を書き込むための入力欄が表示される。この入力欄には、「８％割引」など、オーダデータに対する書き込み情報が入力される。

その他、「ルール実行」又は「スクリプト実行」を選択可能である。「ルール実行」のアクションを選択した場合、当該ルールデータの直後に実行するルールデータを指定するための入力欄が表示される。この入力欄には、「ルールβ」など、１つ以上のルール様式のルールＩＤが指定される。また、「スクリプト実行」のアクションを選択した場合は、スクリプトの編集画面が表示される。例えば、当該ルールデータに関連あるスクリプトを編集するための画面が表示され、ユーザにより編集される。オーダデータがルール条件に合致する場合、編集後のスクリプトが実行される。これら以外のアクション処理動作を設定してもよい。例えば「ＯＫ表示」のアクションを選択可能である。オーダデータがルール条件に合致する場合、ユーザ端末の画面に「ＯＫ」の文字を表示し、又はオーダデータに「ＯＫ」の処理結果を入力する。

ユーザは、図６のルールαに係るルール様式のルールデータ設定画面１１３を画面に表示した後、そのルール様式の条件項目に対して条件値（設定データ）を設定し、その設定データ又は設定データの組み合わせに合致する場合のアクション処理動作を設定する。１つのルールについて、設定データ又は設定データの組み合わせ、及びそれに合致する場合のアクション処理動作を、１つ以上設定可能である。例えば、ルールαについて表１のようなルールデータα_１〜α_４が生成される。

ここで、オーダ様式並びにルール様式のデータ及びルールデータをＪＳＯＮ形式で登録する意義を説明する。ＪＳＯＮ形式とは、人間がある程度理解可能であり、かつ、コンピュータでも把握可能なデータの表現形式である。本実施の形態では、オーダ様式又はルール様式の階層構造に従ってオーダ様式設定画面１１１並びにルール様式設定画面１１２及びルールデータ設定画面１１３を構成し、そのオーダ様式並びにルール様式のデータ及びルールデータをそのままのデータ構造でデータベース部１３に登録する。

そのため、オーダ様式並びにルール様式のデータ及びルールデータが追加されたとしても、データベース部１３のデータベース構造を変更する必要はない。それらのデータをＪＳＯＮ形式で登録することにより、オーダ様式登録部１２１、ルール様式登録部１２２及びルールデータ登録部１２３をルール様式毎に開発する必要がなくなるので、その機能部（１２１〜１２３）の開発費用及び開発期間を低減できる。

なお、オーダデータについてもＪＳＯＮ形式のデータ構造形式を用いる。ルールデータは、オーダデータの項目に従属させてオーダデータのサブセットとして定義する。オーダデータとルールデータとを同じ構造形式で構成することで、汎用的なデータベース構造を実現でき、データ検索処理を向上できる。なお、ＪＳＯＮという形式名称にとらわれず、階層構造形式のデータ構造形式であれば同様の効果が得られる。

ここまでの処理は、ルールデータを定義するための事前定義処理である。これ以降は、オーダデータに対してルールを実行する実オーダ処理である。

＜実オーダ処理：オーダデータの登録＞
図９は、オーダデータの登録動作を示す図である。図２に示したワークフローで「オーダ入力タスク」に遷移すると、ステップＳ４０１において、画面処理部１１は、オーダデータ入力画面１１５をユーザ端末の画面に表示する。その後、ステップＳ４０２において、オーダデータ登録部１２６は、オーダデータ入力画面１１５でユーザにより入力されたオーダデータをデータベース部１３に登録する。

オーダデータとは、ユーザ（法人などを含む）が受け付けた注文データなどであり、ワークフローシステム１においてルールデータのルール条件に合致するか否かをチェックすべき処理対象のデータである。例えば、顧客又はプロバイダから発注された光回線契約情報である。上述の通りオーダデータのデータ構造形式もＪＳＯＮ形式で構成される。

図１０は、オーダデータ入力画面１１５の例を示す図である。オーダデータ入力画面１１５は、データベース部１３に登録されているオーダ様式のデータから選択され作成される。この例では、「申込情報」、「通信グループ」、「アクセス回線設定」、「ＩＰアドレス」、「所属グループ」、「処理結果」がオーダデータの大項目として表示されている。このうち「アクセス回線設定の欄」では、「Ｃｏｎｆｉｇ設定」、「設置工事」、「回線種別」がオーダデータの小項目として表示されている。更に、「Ｃｏｎｆｉｇ設定」に対して「初期設定（新設・機種変更）」が入力され、「設置工事」に対して「オンサイト工事（ＮＴＴ派遣）」が入力され、「回線種別」に対して「アクセス回線」が入力されている。これらの入力データがルールデータのルール条件と比較される。「処理結果」の欄は、チェック処理の結果を書き込むための欄である。

なお、本実施の形態では、オーダデータを人手で入力する場合を例に説明したが、オーダデータが注文元などでデータ入力されている場合、そのデータ化されたオーダデータをそのままワークフローシステム１のオーダデータとしてデータベース部１３に登録してもよい。その際にオーダデータのデータ形式が異なる場合には、そのデータ形式をワークフローシステム１で用いるオーダデータのデータ形式（ＪＳＯＮ形式を含む）に変換するオーダデータ形式変換部を備えてもよい。

＜実オーダ処理：オーダデータのチェック処理及びオーダ実行＞
ここまでの処理により、ルールデータ及びオーダデータがデータベース部１３に登録される。以降、オーダデータがルールデータのルール条件に合致するか否かをチェックし、その結果に応じてオーダデータを処理する動作を説明する。図１１は、オーダデータに対するルール実行動作を示す図である。このルール実行動作は、図２に示した「オーダチェックタスク」に遷移した時に実行される。

ステップＳ５０１において、ルール実行部１２７は、処理対象となるオーダデータをデータベース部１３から読み出し、ステップＳ５０２において、ルールタスク設定画面１１６で指定されたルールＩＤを取得する。

ここで、ルールタスク設定画面１１６を説明する。図１２は、ルールタスク設定画面１１６の例を示す図である。ルールタスク設定画面１１６は、オーダデータに対して適用するルールを指定してオーダ実行を行うための画面であり、データベース部１３に登録されているルールの名称、ルールＩＤ、ルールの説明などを選択可能である。ルールタスク設定画面１１６は、ワークフロー定義画面１１４で「オーダチェックタスク」を設定する際に表示され、ユーザは、表示されたルールＩＤの中から１つ以上のルールＩＤを指定し、指定したルールＩＤに対してルールの実行順位付けを予め決定しておくことになる。ステップＳ５０２以降は、ルールタスク設定画面１１６で予め特定されているルールＩＤ及び実行順位に基づき自動で実行される。

次に、ステップＳ５０３において、ルール実行部１２７は、ステップＳ５０２で取得したルールＩＤに係るルールデータの条件項目をデータベース部１３のルール様式のデータから読み出し、ステップＳ５０４において、読み出したルールデータの条件項目に対応する入力データをオーダデータから取得する。

次に、ステップＳ５０５において、ルール実行部１２７は、ステップＳ５０２で取得した指定ルールＩＤとステップＳ５０４で取得したオーダデータの条件項目の入力データとをキーとして、データベース部１３から該当のルールデータを検索し、検索したルールデータのアクション処理動作を取得する。

ここで、ステップＳ５０３〜Ｓ５０５の処理動作を詳述する。本発明では、データベース部１３に登録されている大量のルールデータを全て検索するのではなく、指定ルールＩＤとオーダデータの条件項目の入力データとに対応するルールデータのみをデータベース部１３から検索する。

例えば、図１２のルールタスク設定画面１１６で「ルールα」が指定された場合、図６に示された「ルールα」のルール様式より、指定「ルールα」に係るルールの条件項目として「Ｃｏｎｆｉｇ設定」と「設置工事」を読み出す。そして、図１０のオーダデータから、それらの条件項目に対応する「初期設定（新設・機種変更）」と「オンサイト工事（ＮＴＴ派遣）」を取得する。その後、データベース部１３に登録されている複数のルールデータの中から、「ルールα」のＩＤ（＝α）に該当し、かつ、「Ｃｏｎｆｉｇ設定」と「設置工事」の条件項目に「初期設定（新設・機種変更）」と「オンサイト工事（ＮＴＴ派遣）」が設定されているルールデータを検索する。ルールＩＤの検索処理とルールデータの検索処理とは一度（同時）に行われる。「ルールα」に係るルールデータが上記表１の通りであれば、ルールデータα_１が検索されることになる。

次に、ステップＳ５０６において、ルール実行部１２７は、ステップＳ５０５でルールデータが１つ以上検索されたか否かを判定する。該当のルールデータが１つ以上ある場合、ステップＳ５０７において、ルール実行部１２７は、そのルールデータに設定されているアクション処理動作の種別が「ルール実行」であるか否かを判定する。アクション処理の種別が「ルール実行」の場合、そのルールデータで指定されているルールでルール実行を更に行う必要があるので、ステップＳ５０３へ戻る。一方、その種別が「ルール実行」以外の場合、ステップＳ５０８において、ルール実行部１２７は、該当のルールデータに設定されている詳細処理動作を実行し又は詳細処理情報を入力し若しくは表示する。具体的な動作内容は、該当のルールデータの設定内容に従う。

なお、ステップＳ５０６で該当のルールデータが無い場合には、ルールデータ（α_１，α_２，…）のルール条件には合致しないが指定ルールＩＤに対応するルール（α，β，…）があれば、ステップＳ５０９において、ルール実行部１２７は、そのルールに設定されているエラー処理動作を実行する。

以上より、本実施の形態によれば、ルールＩＤとオーダデータの入力データとに対応するルールデータのみをデータベース部１３から検索するので、オーダデータのチェック処理を高速に実行でき、ワークフロー処理のリアルタイム性を向上できる。

なお、図２に示したワークフローでは、「オーダチェックタスク」の後に「ＸＯＲ分岐」が設定されている。ユーザは「ＸＯＲ分岐」に対する分岐条件を予め設定可能であり、例えば図１３に示す分岐設定画面１１７を用いて、「オーダチェックタスク」での処理結果に基づくワークフローの遷移先を設定できる。例えば、オーダデータがルールデータのルール条件に合致しない場合、オーダデータの入力データを修正するための「データ修正タスク」へ遷移させる。「データ修正タスク」に遷移するとオーダデータの入力データに対する修正処理が促され、ユーザにより入力データが修正された後に、修正後のオーダデータを用いてチェック処理が再実行される。

（ルールデータの検索方法：具体例１）
引き続き、ルールデータの検索方法の具体例を説明する。具体例１では、インデックス機能を用いた検索方法を説明する。

まず、ルールデータを登録する際、ルールデータ登録部１２３は、ルールデータの条件項目に設定されている設定データをハッシュ化してルールデータのハッシュ値を算出する。例えば、表１のようにルールαの条件項目の数が２つの場合、その２つの条件項目に対応する２つの設定データを用いて各ルールデータ（α_１，α_２，…）のハッシュ値（例えば、１５４，２００，…）をそれぞれ算出する。

次に、ルールデータ登録部１２３は、算出したハッシュ値をルールデータのインデックスとし、そのインデックスとルールＩＤとを関連付けてデータベース部１３に登録する。上記例の場合、ルールデータα_１について、「ルールＩＤ＝α」と「インデックス＝１５４」とを関連付けたインデックステーブルが登録される。このインデックス化処理は、ルールデータを登録する毎に行われる。

その後、オーダデータのチェック処理が開始されると、ルール実行部１２７は、処理すべきオーダデータの入力データを用いてオーダデータのハッシュ値を算出する。そして、そのオーダデータのハッシュ値とインデックステーブル内のルールデータのインデックスとを比較して、オーダデータのハッシュ値に合致するインデックスを持つルールデータを抽出する。

以上より、具体例１によれば、インデックスを用いてルールデータを検索するので、大量のルールデータの中から該当のルールデータを瞬時に検索でき、ワークフロー処理のリアルタイム性を更に向上できる。

なお、インデックスは、ルールＩＤである「α」を更に加えて算出してもよいし、ルールαのカラム値を更に用いてもよい。この場合、インデックスがルールＩＤ又はカラム値を含めて算出されるので、インデックステーブルはインデックスの値のみを管理することで足り、メモリの使用効率を向上できる。

（ルールデータの検索方法：具体例２）
具体例１は、ルールデータの条件項目に一意の設定データが設定されていることを前提としている。一方、その条件項目に複数かつ任意の値を取り得るワイルドカードが設定されている場合、インデックスを算出するには、ワイルドカードの取り得る全ての値を用いなければならない。例えば、その取り得る値が３種類であれば、１つのルールデータ（α_１，α_２，…）について３通りのインデックスが生成される。

しかし、これでは、本来であれば条件項目に対する設定データが１つに定義されていることが好ましいルールデータが複数のパターンを持つことになり、ルールデータの数が増加して管理が大変となる。本発明では、設定データの組み合わせパターンを全て網羅する必要があり、加えて条件項目の数が増えるとその分組み合わせパターン数も更に膨大となり、その結果としてルールデータが更に増加することになる。

そこで、具体例２では、条件項目の範囲を局所化する方法を説明する。つまり、ワイルドカードの有無で条件項目の範囲を絞り、それに基づき複数のルールデータを分割して各ルールデータ群をそれぞれ別々に用いる。具体的には、データベース部１３に登録されている複数のルールデータ（α_１，α_２，…，β_１，…，γ_１，…）を、同じ条件項目にワイルドカードが設定されているルールデータからなるルールデータ群（Ａ，Ｂ，Ｃ，…）に分け、その条件項目以外の条件項目に適用されるルールデータ群として管理する。そして、オーダデータのチェック処理を行う際には、複数のルールデータ群のうち、オーダデータの入力データの条件項目と同じ条件項目のルールデータ群からルールデータを検索する。

具体例２の動作を説明する。データベース部１３には、図１４に示すルールデータ（α_１〜α_５）が登録されているものとする。図中の「−」は、ワイルドカードを示す。

まず、ルールデータ管理部（図１において不図示）は、データベース部１３に登録されているルールデータα_１〜ルールデータα_５を、条件項目「Ｉ_４，Ｉ_５」にワイルドカードがあるルールデータ群Ａ（ルールデータα_１〜ルールデータα_３）と、条件項目「Ｉ_１〜Ｉ_３」にワイルドカードがあるルールデータ群Ｂ（ルールデータα_４，ルールデータα_５）とに分ける。

次に、ルールデータ管理部は、ルールデータ群Ａに含まれるルールデータからワイルドカード以外の条件項目「Ｉ_１〜Ｉ_３」の設定データを抽出（ルールデータα_１であれば設定データ「Ａ，ａ，１」を抽出）してハッシュ値を求め、そのハッシュ値をインデックスとしてルールデータα_１に関連付けてインデックステーブルに登録する。他のルールデータα_２，α_３についても同様の処理を行う。そして、ルールデータ群Ａを条件項目「Ｉ_１〜Ｉ_３」に適用されるルールとして管理する。ルールデータ群Ｂについても同様の処理を行う。

ここまでの処理は、ルールデータをデータベース部１３に登録した後、実オーダ処理を開始する前に実行される。すなわち、全てのルールデータを対象として分離・分割処理を行い、ルールデータ群への分類処理を予め実施しておくことにより、ルールデータ群（Ａ，Ｂ，…）に分類されたルール（α，β，…）のルールデータが自動登録されることになる。なお、この分離・分割処理は、ルール様式を登録する際にユーザが人手で行ってもよい。

その後、ルール実行部１２７は、受け付けたルールＩＤに係るルールデータのハッシュ値を算出し、そのルールＩＤに係るルールデータの条件項目と同じ条件項目を持つルールデータ群（Ａ，Ｂ，Ｃ，…）をデータベース部１３から検索し、検索したルールデータ群の中からオーダデータのハッシュ値と同じハッシュ値を持つオーダデータを抽出する。

以上より、具体例２によれば、複数のルールデータを、同じ条件項目にワイルドカードが設定されているルールデータからなるルールデータ群に分け、当該条件項目以外の条件項目に適用されるルールデータ群として管理し、複数のルールデータ群のうち、オーダデータの入力データの条件項目と同じ条件項目のルールデータ群からルールデータを検索するので、ワイルドカードを除く条件項目の設定データを用いてインデックスが生成されることから、その結果ルールデータ数の増加を抑制できる。

例えば、図１４に示したルールデータα_１の場合、インデックスが一意に決まることになる。ルールデータα_２の場合、条件項目「Ｉ_３」にワイルドカードが設定されているが、条件項目「Ｉ_４，Ｉ_５」のワイルドカードを更に含める場合よりもルールデータ数の増加を抑制できる。仮に、図１４に示した２５つ全てのカラムの設定データがワイルドカードであり、ワイルドカードの取り得る値が５つであれば、３，１２５（＝５×５×５×５×５）通りの組み合わせパターンになるが、実施例２の場合には１２５通り（＝５×５×５）と２５通り（＝５×５）となるので、ルールデータの総数を低減可能となる。

（ルールデータの検索方法：具体例３）
ルールデータの条件項目は追加可能である。しかし、元々の条件項目に新たな条件項目を追加すると、その追加分の条件項目を網羅する設定データの組み合わせパターンは大きく増加する。例えば、条件項目「Ｉ_１〜Ｉ_３」に対して条件項目「Ｉ_４，Ｉ_５」が追加されると、追加した２つの条件項目の取り得る値がそれぞれ２つであれば、設定データの組み合わせパターンは元々の４倍（＝２×２）に増加する。

そこで、具体例３では、条件項目の範囲を分割してルールをカスケードに適用する方法を説明する。具体的には、追加分を含む全ての条件項目に対応するルールデータを、元々の条件項目からなるルールデータ群と新たな条件項目からなるルールデータ群とに分ける。そして、元々の条件項目の設定データを用いてルールデータを検索した後に、その元々の条件項目に関連又は紐付くような項目（新たな条件項目）があれば、その新たな条件項目の設定データを用いてルールデータを更に検索する。

具体例３の動作を説明する。データベース部１３には、図１５に示すルールデータが登録されているものとする。図中の「−」は、ワイルドカードを示す。条件項目「Ｉ_４，Ｉ_５」は、追加された条件項目であり、元々のルールデータα_１にのみ関連する条件項目である。この例では、追加した条件項目「Ｉ_４，Ｉ_５」の設定データの組み合わせパターンは２つなので、ルールデータα_１が１つ分コピーされ、その２パターンにそれぞれ対応する同じ組み合わせの設定データ「Ａ，ａ，１」がルールデータα_１，α_２としてそれぞれ設定されている。

まず、ルールデータ管理部（図１において不図示）は、データベース部１３に登録されているルールデータを、元々の条件項目「Ｉ_１〜Ｉ_３」に係るルールαのルールデータ群Ａ（ルールデータα_１〜α_４）と、新たな条件項目「Ｉ_４，Ｉ_５」に係るルールβのルールデータ群Ｂ（ルールデータβ_１，β_２）とに分ける。ワイルドカードが設定されている場合には、ワイルドカードを除いてルールデータ群を形成する。この処理は、具体例２と同様に、実オーダの処理中以外のタイミングで行われる。また、ユーザが人手で行ってもよい。

その後、ルール実行部１２７は、先ずルールαのルールデータ群Ａの中から条件項目「Ｉ_１〜Ｉ_３」の設定データの組み合わせに合致するルールデータを検索し、ルールデータα_１が検索された場合には当該ルールデータα_１のアクションにルールβのルール実行があるので、引き続きルールデータ群Ｂの中からルールデータを検索する。

以上より、具体例３によれば、一部の条件項目の設定データを用いてルールデータを検索した後に、他の一部の条件項目の設定データを用いてルールデータを更に検索するので、ルールデータを効率よく検索できる。

（ルールデータの検索方法：具体例４）
所定のアクションに対して条件項目の設定データが範囲で指定される場合がある。例えば、「１０％割引」のアクションに対して「購入金額が５００円以上かつ１０００円未満の場合」のルール条件を付与する場合である。この場合、コンピュータ内では、大小比較を行う「ｉｆ」又は「ｔｈｅｎ」でツリー状にカスケードするデシジョンツリーを用いて逐次判断する必要があり、データベース検索に比べて十分な処理時間が得られない可能性がある。

そこで、動作例４では、条件項目の入力欄に設定し得る設定データを一定範囲から選択可能に表示し、その一定範囲をコード値に変換したコードテーブルを予め保持しておく。例えば、図１６に示すように、「数量」の条件項目に対して、「１〜５」，「６〜１０」などの数値範囲を選択可能に表示し、「１〜５」が設定された場合には、その数値範囲をコードテーブルより所定のコード値（例えば「０１」）に変換し、そのコード値「０１」をキーとしてルールデータをデータベース部１３から検索する。

以上より、具体例４によれば、一定範囲の数値を選択可能に表示し、指定された範囲の数値を所定のコード値に変換して該コード値に対応するルールデータを検索するので、ルールデータを効率よく検索できる。

＜他システムからのデータ取得＞
最後に、自身のワークフローシステム１以外の他システムからデータを取得し、自己のシステムで用いるデータとして活用する場合について説明する。

（他システムからのオーダデータ要素の検索・取得）
図２のワークフローの場合、「オーダチェックタスク」の後に「他システム情報取得タスク」へ遷移する。このとき、ＡＰＩ呼出し実行部１２８が起動し、他システムからオーダデータの入力データと成り得るデータを検索して取得する。具体的には、オーダデータを成す項目の入力データをパラメータとしてＡＰＩリクエストに含め、それ以外の項目に対するデータを外部システムから検索・取得してオーダデータに追加する。例えば、図１０のオーダデータにおいて、「Ｃｏｎｆｉｇ設定」，「設置工事」，「回線種別」の３つの項目への入力データをパラメータに含めたリクエストを外部システムへ送信し、その応答としてそれら以外の項目に対する入力データを取得する。これにより、従前の「オーダチェックタスク」で元のオーダデータでルール実行を行った後、新たなオーダデータを用いてルール実行を自動で行うことができる。

（他システムからのルールデータ要素検索・取得）
ルールデータは、一般的に事業主の持つ既存設備に対して生成される。一方、事業協力・経営統合など、他の事業主が持つ設備を用いることも当然に考えられる。例えば、回線種別として光回線を持つ事業主が他の事業主から無線回線の貸与又は譲渡を受ける場合が考えられる。

そこで、ワークフローシステム１は、他のシステムからルールデータの条件項目に設定可能なデータを受信するＡＰＩを持つ。具体的に、ＡＰＩ呼出し部１２８は、ユーザにより指定されたルール条件の要素データをワークフローシステム１以外の他システムから検索して取得する。ルールデータを登録する際には、ここで取得した他システムからのデータも併せてルールの条件項目の入力欄に選択可能に表示される。なお、他システムからのルール要素検索処理は様々なタイミングで行うことが考えられるので、ＡＰＩ呼出し部１２８は、ブロック図形間を連結する任意の経路上に設定可能であることが好ましい。例えば、図２に示した「オーダチェックタスク」の前に配置する又は配置変更する。

以上より、本実施の形態によれば、ワークフローシステム１以外のシステムからルールデータの条件項目に設定可能な要素データを検索して取得するので、その条件項目に設定可能な設定データの適用範囲を拡大できる。

最後に、本実施の形態で説明したワークフローシステム１について補足する。ワークフローシステム１は、少なくともＣＰＵ及びメモリを備えたコンピュータで実現可能である。また、本実施の形態で説明した処理は、ＯＳ（Operating System）、アプリケーションプログラムなどのプログラムで実行される。更に、ワークフローシステム１の各動作をプログラムとして構築し、コンピュータにインストールして実行させ、インターネット等の通信網を介して流通させ、更には、その記録媒体を作成することも可能である。

１…ワークフローシステム（データ処理装置）
１１…画面処理部
１１１…オーダ様式設定画面
１１２…ルール様式設定画面
１１３…ルールデータ設定画面
１１４…ワークフロー定義画面（表示部）
１１５…オーダデータ入力画面
１１６…ルールタスク設定画面
１１７…分岐設定画面
１２…データ処理部
１２１…オーダ様式登録部
１２２…ルール様式登録部
１２３…ルールデータ登録部（登録部）
１２４…ワークフロー登録部
１２５…ワークフロー実行部
１２６…オーダデータ登録部
１２７…ルール実行部（検索部、実行部）
１２８…ＡＰＩ呼出し実行部（検索部）
１３…データベース部（記憶部）

Claims (7)

1. 条件項目に設定された設定データまたは設定データの組み合わせに合致する場合と合致しない場合の処理ルールを定めた複数のルールデータを記憶部に登録する登録部と、
   処理対象データに適用されるユーザからのルールのルール識別子を受け付け、前記ルール識別子に係るルールデータの条件項目に対応する入力データを前記処理対象データから取得し、前記ルール識別子に対応するルールデータであり、前記入力データと同じ設定データまたは同じ組み合わせの設定データが設定されたルールデータを前記記憶部から検索し、検索されたルールデータの処理ルールを実行する実行部と、
   を備えることを特徴とするデータ処理装置。
2. 前記複数のルールデータは、同じ条件項目にワイルドカードが設定されているルールデータからなるルールデータ群に分けられ、前記ルールデータ群は、当該条件項目以外の条件項目に適用されるルールデータ群であって、
   前記実行部は、
   複数のルールデータ群のうち前記入力データの条件項目と同じ条件項目のルールデータ群からルールデータを検索することを特徴とする請求項１に記載のデータ処理装置。
3. 前記実行部は、
   一部の条件項目の設定データを用いてルールデータを検索した後に、他の一部の条件項目の設定データを用いてルールデータを更に検索することを特徴とする請求項１又は２に記載のデータ処理装置。
4. 一定単位の処理を示す複数のブロック図形を画面に表示する表示部と、
   ブロック図形間を連結する任意の経路上に設定可能なブロック図形に対応し、自データ処理装置以外の装置から前記処理対象データの入力データの項目又は前記ルールデータの条件項目に設定可能なデータを検索する実行部と、
   を備えることを特徴とする請求項１乃至３のいずれかに記載のデータ処理装置。
5. 前記表示部は、
   複数の前記入力データのうち各処理でそれぞれ用いる入力データのみを入力させる各画面を画面遷移により段階的に表示することを特徴とする請求項４に記載のデータ処理装置。
6. データ処理装置で行うデータ処理方法において、
   条件項目に設定された設定データまたは設定データの組み合わせに合致する場合と合致しない場合の処理ルールを定めた複数のルールデータを記憶部に登録するステップと、
   処理対象データに適用されるユーザからのルールのルール識別子を受け付け、前記ルール識別子に係るルールデータの条件項目に対応する入力データを前記処理対象データから取得し、前記ルール識別子に対応するルールデータであり、前記入力データと同じ設定データまたは同じ組み合わせの設定データが設定されたルールデータを前記記憶部から検索するステップと、
   検索されたルールデータの処理ルールを実行するステップと、
   を実行することを特徴とするデータ処理方法。
7. 請求項１乃至５のいずれかに記載のデータ処理装置としてコンピュータを機能させることを特徴とするデータ処理プログラム。

Images