(57)【要約】  本発明の実施形態は、レガシーアプリケーションからルールコンポーネントを取得し、次に、ルールコンポーネントのレガシールールから中間状態式を生成するための装置、コンピュータ媒体および方法を提供する。中間状態式は、ターゲットアプリケーションによって利用されるターゲットルールに変換される。また、データコンポーネントはレガシーアプリケーションから取得され、中間データ要素はレガシーデータ要素から生成される。中間データ要素は、ターゲットルールの実行時にターゲットアプリケーションによってアクセスし得るターゲットデータ要素に変換される。語彙項目はルールコンポーネントから抽出される。語彙項目が中間状態式に統合されて、ターゲットルールを形成する。次に、ターゲットルールがターゲットアプリケーションに展開される。
2010530575.tif 000002
【特許請求の範囲】
【請求項１】
方法であって、
（ａ）レガシーアプリケーションから第１のコンポーネントを取得するステップと、
（ｂ）前記第１のコンポーネントに含まれるレガシー要素から中間状態要素を生成するステップと、
（ｃ）前記中間状態要素をターゲット要素に変換するステップであって、ターゲットアプリケーションが前記ターゲット要素を利用するように構成されるステップと、
を含む方法。
【請求項２】
前記第１のコンポーネントがルールコンポーネントから構成され、さらに、
（ｄ）第１のソフトウェア言語で指定されたレガシーソースコードを含む前記レガシーアプリケーションから、前記ルールコンポーネントを取得するステップと、
（ｅ）前記ルールコンポーネントに含まれるレガシールールから中間状態式を生成するステップと、
（ｆ）前記中間状態式をターゲットルールに変換するステップであって、ターゲットアプリケーションが前記ターゲットルールを実行するように構成され、前記ターゲットアプリケーションが、第２のソフトウェア言語で指定されたターゲットソースコードを含むステップと
を含む請求項１に記載の方法。
【請求項３】
（ｇ）前記レガシーアプリケーションからデータコンポーネントを取得するステップと、
（ｈ）前記データコンポーネントに含まれるレガシーデータ要素から中間データ要素を生成するステップと、
（ｉ）前記中間データ要素をターゲットデータ要素に変換するステップと
をさらに含む請求項２に記載の方法。
【請求項４】
（ｊ）前記ターゲットルールの実行時に、前記ターゲットデータ要素にアクセスするステップ
をさらに含む請求項３に記載の方法。
【請求項５】
前記第１のソフトウェア言語および前記第２のソフトウェア言語が異なるソフトウェア言語である請求項２に記載の方法。
【請求項６】
前記第１のソフトウェア言語および前記第２のソフトウェア言語が同じソフトウェア言語である請求項２に記載の方法。
【請求項７】
（ｄ）前記レガシーアプリケーションからコレスポンデンスコンポーネントを取得するステップと、
（ｅ）レガシーデータ要素から中間コレスポンデンス要素を生成するステップであって、レガシーコレスポンデンス要素が前記コレスポンデンスコンポーネントに含まれるステップと、
（ｆ）前記中間コレスポンデンス要素を、前記ターゲットアプリケーションによって利用されるターゲットコレスポンデンス要素に変換するステップと
をさらに含む請求項１に記載の方法。
【請求項８】
（ｄ）前記レガシーアプリケーションからインタフェースコンポーネントを取得するステップと、
（ｅ）前記インタフェースコンポーネントに含まれるレガシーインタフェース要素から中間インタフェース要素を生成するステップと、
（ｆ）前記中間インタフェース要素を、前記ターゲットアプリケーションによって利用されるターゲットインタフェース要素に変換するステップと
をさらに含む請求項１に記載の方法。
【請求項９】
（ｄ）前記レガシーアプリケーションからレポートコンポーネントを取得するステップと、
（ｅ）前記レポートコンポーネントに含まれるレガシーレポート要素から中間レポート要素を生成するステップと、
（ｆ）前記中間レポート要素を、前記ターゲットアプリケーションによって利用されるターゲットレポート要素に変換するステップと
をさらに含む請求項１に記載の方法。
【請求項１０】
（ｄ）前記レガシーアプリケーションから前記ターゲットアプリケーションへの移行時に、前記第１のコンポーネントと他のコンポーネントとを同期させるステップ
をさらに含む請求項１に記載の方法。
【請求項１１】
（ｄ）前記ターゲット要素への前記レガシー要素の移行時にエラーが検出された場合、エラー回復手順を呼び出すステップ
をさらに含む請求項１に記載の方法。
【請求項１２】
前記第１のソフトウェア言語がＣＯＢＯＬ仕様によって指定される請求項２に記載の方法。
【請求項１３】
前記レガシーアプリケーションが納税管理システムに向けられる請求項１に記載の方法。
【請求項１４】
（ｇ）前記ルールコンポーネントから、前記レガシールールに関連する語彙項目を抽出するステップと、
（ｈ）前記中間状態式と前記語彙項目とを統合して、前記ターゲットルールを形成するステップと、
（ｉ）前記ターゲットルールを前記ターゲットアプリケーションに展開するステップと
をさらに含む請求項２に記載の方法。
【請求項１５】
装置であって、
メモリと、
（ａ）第１のソフトウェア言語で指定されたレガシーソースコードを含む前記レガシーアプリケーションから、ルールコンポーネントを取得するステップと、
（ｂ）前記ルールコンポーネントに含まれるレガシールールから中間状態式を生成するステップと、
（ｃ）前記中間状態式をターゲットルールに変換するステップであって、ターゲットアプリケーションが前記ターゲットルールを実行するように構成されるステップと
を実行するために、前記メモリにアクセスして、コンピュータ実行可能な命令を取得し、前記コンピュータ実行可能な命令を実行するプロセッサと、
を備える装置。
【請求項１６】
前記プロセッサが、さらに、
（ｄ）前記レガシーアプリケーションからデータコンポーネントを取得するステップと、
（ｅ）前記データコンポーネントに含まれるレガシーデータ要素から中間データ要素を生成するステップと、
（ｆ）前記中間データ要素をターゲットデータ要素に変換するステップであって、前記ターゲットアプリケーションが、前記ターゲットルールの実行時に前記ターゲットデータ要素を利用するように構成されるステップと
を実行するために、前記コンピュータ実行可能な命令を実行する請求項１５に記載の装置。
【請求項１７】
前記プロセッサが、さらに、
（ｄ）前記ルールコンポーネントから、前記レガシールールに関連する語彙項目を抽出するステップと、
（ｅ）前記中間状態式と前記語彙項目とを統合するステップと、
（ｆ）前記ターゲットルールを前記ターゲットアプリケーションに展開するステップと
を実行するために、前記コンピュータ実行可能な命令を実行する請求項１５に記載の装置。
【請求項１８】
コンピュータ読み取り可能な有形媒体であって、
（ａ）第１のソフトウェア言語で指定されたレガシーソースコードを含む前記レガシーアプリケーションから、ルールコンポーネントを取得するステップと、
（ｂ）前記ルールコンポーネントに含まれるレガシールールから中間状態式を生成するステップと、
（ｃ）前記中間状態式をターゲットルールに変換するステップであって、ターゲットアプリケーションが前記ターゲットルールを実行するように構成されるステップと
を実行するための、コンピュータ実行可能な命令を有するコンピュータ読み取り可能な有形媒体。
【請求項１９】
（ｄ）前記レガシーアプリケーションからデータコンポーネントを取得するステップと、
（ｅ）前記データコンポーネントに含まれるレガシーデータ要素から中間データ要素を生成するステップと、
（ｆ）前記中間データ要素をターゲットデータ要素に変換するステップであって、前記ターゲットアプリケーションが前記ターゲットデータ要素を利用するように構成されるステップと
を実行するようにさらに構成される請求項１８に記載のコンピュータ読み取り可能な有形媒体。
【請求項２０】
（ｄ）前記ルールコンポーネントから、前記レガシールールに関連する語彙項目を抽出するステップと、
（ｅ）前記中間状態式と前記語彙項目とを統合するステップと、
（ｆ）前記ターゲットルールを前記ターゲットアプリケーションに展開するステップと
を実行するようにさらに構成される請求項１８に記載のコンピュータ読み取り可能な有形媒体。
【請求項２１】
コンバータであって、
レガシーアプリケーションのルールコンポーネントからレガシールールを取得して、前記レガシールールを中間状態式に変換するルールエクストラクタと、
前記中間状態式をターゲットルールに変換して、前記ターゲットルールをターゲットアプリケーションに展開するルールデプロイヤと、
前記レガシーアプリケーションのデータコンポーネントからレガシーデータ要素を取得して、前記レガシーデータ要素を中間データ要素に変換するデータエクストラクタと、
前記中間データ要素をターゲットデータ要素に変換して、前記ターゲットデータ要素を前記レガシーアプリケーションに展開するデータデプロイヤと、
を含むコンバータ。
【請求項２２】
前記ルールコンポーネントから、前記レガシールールに関連する語彙項目を抽出する語彙エクストラクタと、
前記中間状態式と前記語彙項目とを統合して、前記ターゲットルールを形成するアグリゲータと、
をさらに含む請求項２１に記載のコンバータ。
【請求項２３】
前記中間状態式がＸＭＬファイルに含まれている請求項２１に記載のコンバータ。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、２００７年６月８日に出願された米国特許出願第６０／９４２，７８９号明細書、および２００８年３月１９日に出願された米国特許出願第１２／０５１，４０１号明細書の優先権を主張する。これらの開示全体は参照により本明細書に援用される。
【０００２】
本発明は、一般に、ビジネスルールおよびビジネスデータをレガシーアプリケーションから指定アプリケーションに移行することに関する。
【背景技術】
【０００３】
会社および政府機関は、多くの場合、アプリケーションに投資し、長年にわたりその成功した動作のアプリケーションに依存する。アプリケーション（多くの場合、レガシーアプリケーションと呼ばれる）を維持する必要があるが、ある時点で、レガシーアプリケーションを維持することが困難になる。したがって、会社または政府機関は、レガシーアプリケーションからターゲットアプリケーションへの移行を所望し、これにより、新たなハードウェアおよびソフトウェアを組み込む可能性がある。典型的には、移行を容易にして、業務の混乱を低減することが重要である。
【０００４】
上記した状況の一例として、いくつもの政府機関が、課税管轄内の個人および会社から税を徴収するために、アクセンチュア（商標）納税管理システム（ＴＡＳ）を利用している。納税管理システム（レガシーアプリケーションに対応）は元の設計要件に従って機能しているが、レガシーアプリケーションが、ＣＯＢＯＬと呼ばれるより初歩的なソフトウェア言語で書かれているので、政府機関は、システムの維持が次第に困難になりつつあることを見出す可能性がある。さらに、新たな（ターゲット）アプリケーション（例えば、ＳＡＰ（登録商標）収納管理（ＰＳＣＤ）ソフトウェアおよび／またはマイクロソフトＢｉｚＴａｌｋ（商標）ビジネスルールエンジン）は、レガシーアプリケーションの増強を提供し得る。もちろん、徴税の混乱が行政運営機能にもたらす代償は非常に大きい場合がある。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上記従来技術の例は、レガシーアプリケーションからターゲットアプリケーションへの移行を容易にすることへの強い市場ニーズがあることを示している。
【課題を解決するための手段】
【０００６】
本発明の態様は、レガシーアプリケーションから第１のコンポーネントを取得し、次に、第１のコンポーネントのレガシー要素から中間状態要素を生成するための装置、コンピュータ媒体および方法を提供する。中間状態要素は、ターゲットアプリケーションによって利用されるターゲット要素に変換される。
【０００７】
本発明の態様によれば、ルールコンポーネントが、第１のソフトウェア言語で指定されたレガシーソースコードを含むレガシーアプリケーションから取得される。中間状態式が、ルールコンポーネントに含まれるレガシールールから生成される。中間状態式はターゲットルールに変換され、このターゲットルールは、それを実行するように構成されるターゲットアプリケーションによって実行される。ターゲットアプリケーションは、第２のソフトウェア言語で指定されたターゲットソースコードを含み得る。また、データコンポーネントがレガシーアプリケーションから取得され、中間データ要素がレガシーデータ要素から生成される。中間データ要素は、ターゲットルールの実行時にターゲットアプリケーションによってアクセスし得るターゲットデータ要素に変換される。
【０００８】
本発明の他の態様によれば、語彙項目がルールコンポーネントから抽出される。語彙項目は中間状態式と統合されて、ターゲットルールを生成する。次に、ターゲットルールはターゲットアプリケーションに展開される。
【０００９】
他の態様によれば、他のコンポーネント、例えば、コレスポンデンス、インタフェース、またはレポートコンポーネントがレガシーアプリケーションから取得され、対応する中間要素が生成される。対応する中間要素はターゲットアプリケーションに変換される。
【００１０】
本発明の態様によれば、レガシーアプリケーションは、ＣＯＢＯＬソースソフトウェアを用いる納税管理システムに向けられる。
【００１１】
本発明は、実施例で示され、そして同じ参照番号が同様の要素を示す添付図に限定されない。
【図面の簡単な説明】
【００１２】
【図１】レガシーアプリケーションが、本発明の一実施形態による指定アプリケーションに移行されるアーキテクチャの図である。
【００１３】
【図２】本発明の一実施形態による納税管理システム（ＴＡＳ）のコンバータのアーキテクチャの図である。
【００１４】
【図３】本発明の一実施形態によるＴＡＳからＡＥＲＳ（アクセンチュア・エンタープライズ・レベニュー・ソリューション）へのルールエンジン変換の高レベルフロー図である。
【００１５】
【図４】本発明の一実施形態によるルールコンポーネントを変換するためのアーキテクチャの図である。
【００１６】
【図５】本発明の一実施形態による形式ルール変換を行うための高レベルフロー図である。
【００１７】
【図６】本発明の一実施形態によるバックエンドルール変換を行うための高レベルフロー図である。
【００１８】
【図７】本発明の一実施形態によるデータ移行処理の図である。
【００１９】
【図８】本発明の一実施形態による納税管理システム（ＴＡＳ）のコンバータの処理の図である。
【００２０】
【図９】本発明の一実施形態による納税管理システム（ＴＡＳ）からの収益勘定科目一覧表を変換するための高レベルフロー図である。
【００２１】
【図１０】本発明の一実施形態による納税管理システム（ＴＡＳ）からのデータコンポーネントを変換するための高レベルフロー図である。
【００２２】
【図１１】本発明の一実施形態による納税管理システム（ＴＡＳ）からのコレスポンデンスコンポーネントの高レベルフロー図である。
【００２３】
【図１２】本発明の一実施形態による納税管理システム（ＴＡＳ）からのインタフェースコンポーネントを変換するための高レベルフロー図である。
【００２４】
【図１３】本発明の一実施形態による納税管理システム（ＴＡＳ）からのレポートコンポーネントを変換するための高レベルフロー図である。
【００２５】
【図１４】本発明の一実施形態によるＴＡＳの人口統計表の構造図である。
【発明を実施するための形態】
【００２６】
アーキテクチャの概要
図１は、本発明の一実施形態によるアーキテクチャ１００を示す。このアーキテクチャ１００においては、レガシーアプリケーション（ＣＯＢＯＬプログラム１０１およびデータソース１０３に対応）が、指定アプリケーション（ＳＱＬサーバ１１３およびＳＡＰ（登録商標）サーバ１１５に対応）に移行される。（ドイツのウォルドルフ（Ｗａｌｌｄｏｒｆ）に本部があるＳＡＰ社（ＳＡＰ  ＡＧ）は、欧州最大のソフトウェア企業である。ＳＱＬ（構造化照会言語）は、リレーショナルデータベース管理システムからデータを生成、検索、更新および消去するために用いられるコンピュータ言語である。ＳＱＬはＡＮＳＩおよびＩＳＯの両方で標準化されている。）アクセンチュアＴＡＳ−ＡＥＲＳ移行ツールは、アクセンチュアＴＡＳ（納税管理システム）の実行を既に適切に行っているクライアントのＡＥＲＳ（アクセンチュア・エンタープライズ・レベニュー・ソリューション）の開発努力を低減するように意図され、このようにして、正味の競争上の優位性が提供される。アクセンチュアＴＡＳからＡＥＲＳへの移行ツールの開発の第１段階は、主に、ビジネスルールの抽出および変換と、レガシーデータの移行とが中心となる。クライアントは、処理すべき全ての形式の定義に関連するＣＯＢＯＬプログラム１０１を含む全てのファイルを提供するように要求される。（ＣＯＢＯＬは第３世代のプログラミング言語であり、そして今でも使用されている最古のプログラミング言語の１つである。ＣＯＢＯＬという名前は、ビジネス、金融、および企業と政府機関用の管理システムのプライマリードメインを定義する共通のビジネス向け言語（ＣＯｍｍｏｎ  Ｂｕｓｉｎｅｓｓ−Ｏｒｉｅｎｔｅｄ  Ｌａｎｇｕａｇｅ）の頭文字である。ＣＯＢＯＬは、最初に、ショートレンジ委員会（１９５９年５月２８日と２９日に米国国防総省で開催された会議で提案された３つの委員会のうちの１つ）によって１９５９年に作成された。）以下の３つのファイルが必要となる。  
●編集モジュールプログラム
●項目情報モジュール
●提出日プログラム
クライアントは、ＡＥＲＳターゲットデータベース１１５に移行すべきデータを含む全てのデータソース１０３を提供するように要求される。
【００２７】
変換タスク
ビジネス要件に基づいて、ビジネスルール移行処理を以下のタスクに分割することができる。
１．ソースコードからの語彙項目の抽出
２．スキーマの作成および展開
３．抽出された語彙の分類
４．ビジネスルールエンジンデータベースへの語彙の展開
５．ソースコードからのルール論理の抽出
６．ルールと語彙との相関
７．ビジネスルールエンジンデータベースへの、抽出されたポリシーのエクスポート
８．ポリシーの検証
９．ポリシーの発行および展開
１０．処理状態の記録
以下の説明は、設計検討およびトレードオフを識別するための上記タスクの追加の説明である。
【００２８】
ステップ１：ソースコードからの語彙項目の抽出
現在、形式の定義はＣＯＢＯＬソースコード１０１にのみ含まれる。ＣＯＢＯＬプログラム１０１は、典型的に、レガシーＦＤＦの実行において単一の納税フォーム／課税年度定義を定義するように組み合わさる３つのファイルのセットで構成される。ファイル名はＸｎｎｎＹＹｒｒであり、ここで、
●Ｘ＝プログラム時間（Ｅ−ライン編集、Ｌ−ライン項目定義、Ｆ−提出日）
●ｎｎｎ＝形式タイプコード（クライアントのインストール固有に、ＰＯＣコードおよびＤＣコードによって前進したときに、全リストを提供する）
●ＹＹ＝課税年度、例えば０５＝２００５
●ｒｒ＝訂正番号、ここで、００は最初の定義を示し、０１、０２．．．等
例えば、２００５年度の売上税および使用税の月報（形式タイプ＝３５０）を定義するのに必要な３つのファイルは以下のものである。
●Ｅ３０００５００．ｔｘｔ
●Ｌ３０００５００．ｔｘｔ
●Ｆ３０００５００．ｔｘｔ
【００２９】
本発明の実施形態では、語彙抽出処理とユーザとの任意の同時の相互作用が所望される。これは、語彙エクストラクタ１０５が抽出処理の状態を返し、選択的に、抽出された全ての語彙の包括的なリストをユーザに提供するまで、クライアントが待機することを意味する。このことは、提供されたソースコードからの抽出ライン項目の定義、提出日の定義およびライン編集を含む。
【００３０】
ステップ２：スキーマの作成および展開
語彙がソースコードから抽出されて、その語彙構造が確立された後に、ＧＡＣ（グローバルアセンブリキャッシュ）に作成され、強く指定され、そして展開されたＸＭＬから、スキーマを推定しなければならない。
【００３１】
ステップ３：語彙ファイルの作成
ソースコードから抽出されたら、語彙をいくつかのタイプに分類しなければならない。上記語彙は、定数、ＸＭＬ要素、．ＮＥＴコンポーネントまたはデータベースフィールドであり得る。次に、語彙を用いて、ルールエンジンで認識される語彙スキーマを構成しなければならない。
【００３２】
ステップ４：ビジネスルールエンジンデータベースへの語彙の展開
ステップ３で作成された語彙ＸＭＬは、ルールエンジンデータベースにインポートされ、語彙は、それらを用いる必要があるビジネスルールによってアクセス可能であるように発行される。
【００３３】
ステップ５：ソースコードからのルール論理の抽出
ルールはライン編集のＣＯＢＯＬコードに含まれる。ルールエクストラクタ１０７はルールを抽出し、それらをある構造に再構成し、その構造は、論理を処理して、ルールエンジンで要求された構造にマッピングすることを容易にする。基本ルールが抽出された後、ルール編集が、コードから抽出され、抽出されたルールに適用される。
【００３４】
ステップ６：ルールと語彙との相関
この処理において、抽出されたビジネスルールによって用いられる語彙は、抽出されている語彙に相関させなければならない。この処理はアグリゲータコンポーネント１０９によって扱われる。必要ないくつかのフィールドは存在していない可能性があり、より多くの情報がクライアントから要求される可能性がある。結果として、ルールエクストラクタ１０７は、存在していない語彙をクライアントに通知する必要があり得る。
【００３５】
ステップ７：ビジネスルールエンジンデータベースへの、抽出されたポリシーのエクスポート
ソースコードから抽出されたら、ルールをポリシーによってグループ化しなければならない。形式毎におよび年毎に１つのポリシーを有するように意図される。ポリシーの命名法は「ＴＡＳ＿ｎｎｎＹＹｒｒ」である。
【００３６】
ステップ８：ポリシーの検証
各ポリシーバージョンは、開発中に、またはそれが発行され、展開され、そして動作した後でも検証することが可能である。ポリシーがセーブされ、しかし未だ展開されていない後に、検証が行われる。ルールセットが展開された後に、それを変更することはより困難である可能性がある。
【００３７】
ステップ９：ポリシーの発行および展開
ポリシーが検証された後、それらが典型的に展開される。展開後にのみ、外部アプリケーションによって、そのルールセットを有するポリシーにアクセスすることができる。
【００３８】
ステップ１０：処理状態の記録
ＴＡＳコンバータ（例えばコンバータ２００）によって実行される全てのステップは、ユーザに送り返されるログに捕捉されて含まれる。複数の承認が存在する場合、それらを共に連結しなければならない。アグリゲータコンポーネント１０９を使用して、ルール変換およびデータ変換用の変換処理の各ステップに関連する個々の応答および関連情報を収集して記憶することが可能である。次に、アグリゲータ１０９は、捕捉された個々のメッセージおよび情報ピースから抽出された単一のログを作成する。
【００３９】
データの移行
本発明の実施形態では、ＤＢ２からＳＡＰへのデータ移行（データソース１０３からＳＡＰサーバ１１３へのものに対応）は、ＳＱＬサーバ統合サービス（ＳＳＩＳ）によって行われる。データが収納管理（ＰＳＣＤ）にバルク挿入される前に、ＳＡＰサーバへのＳＳＩＳバルク挿入によって扱われる変換およびＥＴＬ（抽出、変換、ロード）が、ｉＤｏｃｓを用いかつ検証を行うＳＡＰプログラムによって行われる。（ＳＡＰ収納管理は、戻りファイル、支払い処理、収集、顧客支援、および金融管理を提供する。ＳＡＰ  ＰＳＣＤは、スチューデントアカウンティングを含む異なるシナリオに用いることができる。）
【００４０】
他の考察
本発明の実施形態では、エラー処理が含まれる。追加のアーキテクチャコンポーネントは応答情報の収集器として機能する。結果として、エラー処理の一形態は動作をリトライすることである。変換または転換を行うことができない場合、ユーザに適切に通知する必要がある。ＴＡＳコンバータは、エクスポートパラメータを変更する能力を提供すべきであり、ユーザは単純に要求をリトライすることができるべきである。
【００４１】
実行方法
全てのコンポーネントの間での同時の相互作用を用いて、相互作用モデルをできるだけ簡単に保つが可能である。検証およびデバッグがより容易であり得るという事実によって簡単さが得られるが、その理由は、単一スレッドの実行内でユーザが実行するからである。
【００４２】
概要
ルール移行ツールは以下の態様をサポートし、そのことについてさらに詳細に説明する。
●既存のＴＡＳクライアント用のアップグレードパスを提供すること
●ＩＴＳアップグレードのコストを低減すること
●ＩＴＳアップグレードのリスクを低減すること
●コアアップグレードの時間を短縮すること
●既存の形式ルールおよびバックエンドビジネスルールを迅速に変換すること
●ルールを中央レポジトリすること
●検索をより容易にするために、ルールが形式タイプによってグループ化されること
●管理をより容易にすること
●形式ルール変換が、既存の形式ルールを抽出し、ＩＴＳアップグレードを通常伴うグリーンフィールド形式定義の作業の必要性を排除すること
●計画が、ペナルティと利息と返済とを含むＴＡＳバックエンドビジネスルールをも抽出することであること
●目標が、これらのルールを抽出し、それらを共通のルールセットに統合させて、インポート用のルールを解釈して標準化することであること
●ルールが標準化されたら、ルールをＢｉｚＴａｌｋ（商標）にインポートして、ルールの実行を果たすことができること
●ＴＡＳ内のバックエンドルールがアプリケーションレベルおよびデータベースレベルに埋め込まれること。この作業により、それらのレイヤが結合され、ルールが共通のビジネスルール言語に変換されて、ＢｉｚＴａｌｋにインポートされる。
●ＣＯＢＯＬコードから抽出された意味のある要素からデータ構造を作成すること
●ＦＤＦによって作成され、その後、ＣＯＢＯＬとして作成されたルールが抽出されて変換されること
●以下の分野がＴＡＳコンバータによってカバーされること
＞データ変換
＞形式ルール変換
＞インタフェース変換
＞コレスポンデンス変換
＞バックエンドルール変換
＞収益勘定科目一覧表の移行
＞既存のＴＡＳレポートの変換
【００４３】
本発明の実施形態では、アクセンチュア納税管理システムのコンテキスト以外のＴＡＳコンバータのコンポーネントを使用することが可能である。例えば、ルールコンバータは、適切にフォーマットされた任意のＣＯＢＯＬアプリケーションからルールを抽出することを可能にする一般的な能力を含む。ルールがレガシーアプリケーションの定義領域に記憶される限り、ルール変換用のＴＡＳコンバータは、非ＴＡＳアプリケーション用のルールを抽出して変換することができる。同様の状態がＴＡＳデータコンバータに存在する。ＴＡＳデータコンバータは、データベースコンポーネントをＴＡＳから非正規化データに抽出し、次に、当該情報をターゲットアプリケーションにロードするので、任意のレガシーデータセットに対して、非正規化データ抽出を簡単に行うことが可能である。データが所定のフォーマットにあると、ＴＡＳコンバータは、所定のルーチンおよび処理を用いて情報をターゲットアプリケーションにロードすることができる。
【００４４】
図２は、本発明の一実施形態による納税管理システム（ＴＡＳ）のコンバータ２００のアーキテクチャを示している。レガシーアプリケーション２０１（例えば納税管理システム）は、形式ルールコンポーネント、バックエンドルールコンポーネント、人口統計コンポーネント、財務コンポーネント、勘定科目一覧表コンポーネント、コレスポンデンスコンポーネント、インタフェースコンポーネント、およびレポートコンポーネントを含む複数のコンポーネントを含む。移行アプリケーション２１５は、レガシーコンポーネントを変換し、ステージングデータベース２０３を介して前記レガシーコンポーネントをターゲットアプリケーション２１７に移行させる。
【００４５】
ルールコンポーネントは、形式ルールコンポーネントおよびバックエンドルールコンポーネントの両方を含み得る。形式ルールは、フォームの対応する形式ラインのルールに関連し、一方、バックエンドルールは、形式ラインの情報をさらに処理するためのルールに関連する。例えば、納税フォームによって提供された情報と税務当局でのポリシーの適用とに従って、バックエンドルールをペナルティ計算と利息計算と返済計算とに関連させることが可能である。データコンポーネントは、人口統計コンポーネントと財務コンポーネントと勘定科目一覧表コンポーネントとを含み得る。人口統計コンポーネントは、個人、会社、または関連する実体（例えば納税者）の人口統計情報に関連する。財務コンポーネントは、納税義務の前年または公開期間の、既に提出されたフォームに関連し、勘定科目一覧表コンポーネントは、金融取引と、異なる政府機関への収集収益の分配とをまとめるために使用される計算書を示す。
【００４６】
ルールコンポーネントは、レガシーアプリケーション２０１から抽出され、ルールエクストラクタ２０５によって中間式（例えばＸＭＬファイル２０７）に生成される。ルールデプロイヤ２０９は、中間式をターゲットルールに変換し、ターゲットルールを、ターゲットアプリケーション２１７に含まれるビジネスルールエンジン（ＢＲＥ）２１９に展開する。したがって、ターゲットアプリケーション２１７が動作しているとき、ビジネスルールエンジン２１９がターゲットルールを実行することができる。
【００４７】
本発明の実施形態では、ビジネスルールエンジン２１９はＢｉｚＴａｌｋ（商標）サーバを利用し、このサーバは、エンタープライズアプリケーション統合（ＥＡＩ）およびビジネスプロセス管理（ＢＰＭ）用のマイクロソフトの中央プラットフォームであり、ＸＭＬおよびウェブサービスの技術の統合能力および自動化能力を具体化する。ＢｉｚＴａｌｋサーバは、プロセス実行エンジンとして、ならびにメッセージングおよび文書変換用のマルチトランスポートハブとして機能する。ウィンドウズ（商標）サーバシステム製品は、顧客がシステム、従業員および取引相手を効率的かつ効果的にまとめるのを助けるものである。
【００４８】
データコンポーネントは、レガシーアプリケーション２０１からＳＱＬデータベース２１１に抽出されて、中間データ要素に変換される。次に、中間データ要素は変換されて、フラットファイル２１３から、ターゲットアプリケーション２１７に含まれるＡＢＡＰを実行するＳＡＰサーバ２２１に移行される。ＡＢＡＰ（アドバンスド・ビジネス・アプリケーション・プログラミング）は、ＳＡＰによって作成された高レベルプログラミング言語である。その言語は、現在、ごく最近になって導入されたＪａｖａと並んで、ＳＡＰのウェブアプリケーションサーバをプログラミングするための言語として位置付けられる。
【００４９】
図２には明示されていないが、コンバータコンバータ２００は、さらに、コレスポンデンス、インタフェース、およびレポートコンポーネントを変換し、それらをターゲットアプリケーション２１７に移行させることが可能である。本発明によってカバーされる２種類のコレスポンデンス変換がある。第１に、一般にレガシーシステム内に存在するコレスポンデンステンプレートの変換がある。これらのテンプレートは、データおよびルールと同様の抽出処理およびロード処理を受ける。基本的に、コレスポンデンステンプレートは抽出されて、ターゲットアプリケーションのテンプレート生成領域に配置される。さらに、簡単なマッピング実行により、既存の定義データ要素がレガシーアプリケーションからターゲットシステムにおけるＸＭＬレファレンスに変換される。第２に、コレスポンデンスはレガシーシステム内における履歴文書の変換を含む。納税者には、通知またはコレスポンデンスがレガシーシステムから周期的に送信される。文書全体をセーブする代わりに、ＴＡＳは、当該コレスポンデンスに入っているコレスポンデンステンプレートおよびデータ要素をセーブする。履歴コレスポンデンスを変換して、それを今後の照会およびアクセス用にターゲットアプリケーション内にセーブすることができる。
レポート変換およびインタフェース変換は同様の概念で動作する。実行中、基本的なレガシーアプリケーション（ＴＡＳ）のデータ構造が一貫している場合、レガシーシステムからのデータ要素をターゲットシステムにマッチングさせて、そのターゲットシステムに関連するインタフェースおよびレポートを再生成することが可能である。このことは、手動マッチング処理として行うか、または標準サービスおよび標準処理によって自動化することができる。レポートコンポーネントは、レガシーアプリケーション２０１によって生成されるレポートに関連する。
【００５０】
ターゲットアプリケーション２１７は、データポータル２２３を介して他のデータ（例えば本年度の納税フォーム）を取得し得る。レガシーアプリケーション２０１から移行されたルールコンポーネントおよびデータコンポーネントと共に、他のデータを処理することが可能である。
【００５１】
図２に示したアーキテクチャは、レガシーアクセンチュア納税管理システムからＳＡＰサーバへの移行を示しているが、本発明の実施形態は他のターゲットシステムへの移行もサポートする。
【００５２】
ルール変換するための高レベルフロー−第１の実施形態−
図３は、本発明の一実施形態によるＴＡＳからＡＥＲＳへのルールエンジン変換の高レベルフロー３００を示している。フローチャート３００は、以下のことを行うためのレガシールールエンジンアーキテクチャの高レベルフロー全体を示している。
●ＣＯＢＯＬドライバプログラムをＢｉｚＴａｌｋ（商標）に変換すること（コンポーネント３１９〜３２５）。これは１回限りの処理であり、この処理中、ＴＡＳコンバータ（コンポーネント３２１）によってレガシールールストア（コンポーネント３２５）内のビジネスルールを構成している全てのデータ部分が識別され、かつ抽出され、ＢｉｚＴａｌｋルールエンジンによってビジネスルール言語ＸＭＬを認識することができるようにそのＸＭＬに変換され、その後、ルール展開ツール（コンポーネント３１７）によってルールストア（コンポーネント３１５）に移行される。
●ビジネスルールを公開して検証を行うこと（コンポーネント３０９〜３１３）。これらのルールは、上記の１回限りの処理で抽出されたビジネスルールである。これらのルールは、規則正しく構成され、それらが関連する特定の納税フォームによってグループ化される。さらに、抽出／変換処理中に、ＡＥＲＳ語彙が自動的に作成されている。それらの目的は、ルールがデータベースクエリー、ＸＭＬ要素またはＸＭＬクラスから生じているかにかかわらず、分かりやすい英語様の文法でルールを構成しているデータ要素を提供することである。
●納税フォームの検証を処理すること。ルールエンジンＡＰＩ（コンポーネント３０３に対応するルールアシスタントと呼ばれる）を用いて、納税フォーム入力３０１がアプリケーションに送られる。ルールアシスタント３０３はドライバコンポーネントであり、このドライバコンポーネントは、納税フォーム入力と、ＢｉｚＴａｌｋルールエンジンＡＰＩ（コンポーネント３０７）によって提供されるパターンマッチング論理とに基づいて、どのポリシー（コンポーネント３０５）を呼び出すかに関する知識を有する。ポリシーはルールのコレクションである。以下のものは、この変換に必要な異なるタイプのポリシーである。
＞簡単な編集
＞クロス検証
＞行の編集
＞出口ルーチン
＞トランザクションアプリケーション
ポリシーを構成するための２つの可能な方法がある。
上記タイプの各々の単一のポリシー
ｔａｂｌｅｒｅｆまたはｔａｂｌｅｉｄに基づく複数のポリシー
以下のコンポーネントは、アプリケーションを変換するために必要となる。
【００５３】
共通の語彙
語彙は、英語様の文法でビジネス要件をカプセル化する述語のリストである。ＢＲＥが、３つの異なるバインディング.Ｎｅｔ、ＳＱＬおよびＸｍｌをサポートするとしても、ＴＡＳシナリオには、.Ｎｅｔバインディングが最適である。（典型的には、.Ｎｅｔクラスベースの語彙が用いられ、その場合、語彙が抽象クラスに見出される。）実行により、典型的に、異なるＬＯＢによってルールおよびポリシーの再利用が可能になる。このコンポーネントは多くの場合ＴＡＳ語彙と呼ばれる。
【００５４】
ファクト用のＸＭＬスキーマ
これにより、種々の独立したデータ要素を１つ以上のＸＭＬ文書に統合することが可能になる。ＸＳＤ.ｅｘｅを用いて、.ＸＳＤスキーマが.Ｎｅｔクラスに変換される。この.Ｎｅｔクラスはルールエンジン用のファクトとして用いられる（直接ｘｍｌを用いない）。このスキーマはＴＡＳＴａｘＦｏｒｍＤｏｃｕｍｅｎｔと呼ばれる。
【００５５】
全てのポリシーのリスト、およびポリシー実行の順序
現在のデータフローとポリシー実行の順序とが識別される。これはビジネスコンポーネントにカプセル化される。このコンポーネントは、ルールと通信するための主データオブジェクトである。このコンポーネントはＴＡＳＲｕｌｅＡｓｓｉｓｔａｎｔと呼ばれる。
【００５６】
レガシールールの自動移行
これらのコンポーネントはＴＡＳＲｕｌｅｓＣｏｎｖｅｒｔｅｒと呼ばれる。典型的に、より少数のルールの手動リステートメントを自動的にアップロードすることができない。
【００５７】
レガシールールを移行させるためのアルゴリズム
本発明の実施形態は以下の態様をサポートする。
１．既存のレガシールールでのパターンを識別する（これらのパターンは、頻繁に繰り返しているルールおよび構造であり得る）。
例：
１.１.  ’０１−０１−１９００’〜’０１−０１−２００３’のＥｆｆｅｃｔｉｖｅＤａｔｅの場合。
１.２.  リスト「１｜２｜３｜４」のカラム値の場合。
２．上記パターンをサポート語彙を作成する。
【数１】
2010530575.tif 000003
３．上記抽象クラスを用いて、ＢＲＥ語彙を作成する（サンプル語彙は本明細書と共に提供される）。
４．全ての抽象メソッドの少なくとも１つのルールで、テンプレートポリシーを作成する。
５．種々の「および、または」の構造を用いて、サンプルテンプレートルールを作成する（入れ子にされる「および」あるいは「または」が必要となる場合、それらの構造を用いてルールを作成する）。
６．「ルールエンジン展開ウィザード」を用いて、テンプレートポリシーを.ＸＭＬにエクスポートする。エクスポートされたＸＭＬポリシーの構造を認識する。
７．エクスポートされたポリシーＸＭＬを種々のより小さなファイルに分割する（各ファイルは固有のパターンを含む）。
例：
ａｄｄＥｒｒｏｒＩＤと呼ばれる動作を加えるために、
【数２】
2010530575.tif 000004
バージョン番号およびメインヘッダを作成するために、
【数３】
2010530575.tif 000005
カラムが所定のリストにあるか否かを見出すために、
【数４】
2010530575.tif 000006
「｛ 」および「 ｝」の括弧が、Ｃ＃言語を用いるテキスト置換用の位置ホルダとして用いられることに留意されたい。レガシールールからの実際値は中括弧を置換する。
８．パターンを作成した後、既存のレガシールールベースをウォークし、テンプレート内のレガシー値を置換し、そして、種々のルールおよびポリシーへのテンプレートを構成する手続き事項である。以下にそのコードを示す。
【数５−１】
2010530575.tif 000007
【数５−２】
2010530575.tif 000008
【数５−３】
2010530575.tif 000009
【数５−４】
2010530575.tif 000010
【数５−５】
2010530575.tif 000011
【数５−６】
2010530575.tif 000012
【００５８】
ルールを変換するための高レベルフロー−第２の実施形態−
ポリシーおよび語彙のオーサリング
ポリシーおよび語彙をオーサリングする複数の方法がある。最も一般的な方法、およびルールベースの処理が主要な目標であるビジネスアナリストによってのみ用いられる方法は、ビジネスルールコンポーザツールを使用することである。プログラマ向けにオーサリングについて以下に説明する。これらの技術により、ルールを動的に作成するアプリケーションを書くことが可能になり、さらに、アプリケーション開発用のツールを作成することが可能になる。コンポーザ以外で、２つの方法でルールセットをオーサリングするができる。これらの方法は、主に、ツール開発およびシステム管理のためのものである。第１の方法ではＸＭＬ文書が用いられる。この方法は、ＢｉｚＴａｌｋを用いて、ポリシーおよび語彙をエクスポートおよびインポートする方法である。他の方法は、．ＮＥＴ  ＡＰＩおよびプログラミングによるものである。
【００５９】
ＢＲＬ文法のＸＭＬ文書
データベース管理の経験があるプログラマは、リレーショナルデータベースの大容量データダンプをテキストファイルに導くことが可能である。これらのデータダンプは、通常、ＣＳＶ等のフォーマットのフラットファイルである。ＸＭＬはより多くの構造を提供し、したがって、ＸＭＬによってＢｉｚＴａｌｋがＳＱＬサーバストアへルールを渡したり、そこからルールデータを取得する方法自体は、驚くべきことではない。さらに、その方法は、ポリシーおよび語彙をＳＱＬサーバ外のファイルストアにセーブするために用いられる。一般的ではないが、ファイルストアによって、ルールベースのアプリケーションを完全に動作させることが可能である。マイクロソフトがこのタスクのために考え出したＸＭＬ文法は、Ｂｕｓｉｎｅｓｓ  Ｒｕｌｅｓ  Ｌａｎｇｕａｇｅ、またはＢＲＬとして知られている。ＢＲＬ用のネームスペースは、ｈｔｔｐ：／／ｓｃｈｅｍａｓ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｂｕｓｉｎｅｓｓｒｕｌｅｓｌａｎｇｕａｇｅ／２００２として公表されていることに留意されたい。このネームスペースはマイクロソフト独自のネームスペースである。ポリシーおよび語彙が、ビジネスルールコンポーザから別個の文書にエクスポートされるが、両方の文書は同じ文書要素ｂｒｌを有する。リストＡは、この場合ルールセットとして知られているポリシーファイルの始まりを示す。以下の通り、リストＡは、バージョン情報、設定情報、およびバインディング情報を表す部分的なルールセット文書を示す。
【数６】
2010530575.tif 000013
【００６０】
バージョン要素が、ポリシーのメジャーバージョンおよびマイナーバージョン、ならびに誰がポリシーを変更したのか、それはいつかを表すことに留意されたい。バージョン管理はルール開発で非常に重要である。設定要素に移ると、ポリシーがデータベースファクトレトリーバを使用するように設定されていることがわかる。アセンブリおよびクラス情報が指定される。考慮される最後の領域はバインディングセクションである。バインディング要素の第１のチャイルドは、.ＮＥＴ形式で修飾されたクラスネームと、ローカルネームおよびネームスペースに基づいて文書のルートを選択するＸＰａｔｈ式と、スキーマを指定する物理ファイルとを指定することによって、ＸＭＬ文書をファクトソースとしてポリシーにバインディングする。最後の項目はファイルパスなので、ルールセットをエクスポートするときに、ファイルを新たなサーバに転送すべきである。
【００６１】
続いて例示的文書において、前置表記法で条件および動作を表すことが可能になるＸＭＬ構造を用いてルールを指定する。リストＢは、１つの複合条件と３つの動作とを有するルールを示す。スペースのために、最後の２つの動作が編集されている。以下の通り、リストＢは、分かりやすい形式でビジネスルールを示す。
【数７】
2010530575.tif 000014
【００６２】
ルールがルール要素によってどのように固定されるかについて留意されたい。そこでは、属性を用いて、ルールのネーム、優先度、および状態が与えられる。ルールよりも下位の全てのものがルールの構造を表す。条件はｉｆ要素内に含まれる。前置表記法に従って、ＡＮＤ要素（２つの条件を組み合わせる論理演算子である）が最初に来る。第１の述語に関するｇｒｅａｔｅｒ  ｔｈａｎ演算子が次に来る。語彙リンク要素は述語組込語彙内のこの演算子を識別する。そこから、ファクト、この場合、自身のＸＭＬ文書のＨｏｕｒｓフィールドにバインディングする。これは述語の左側（ｌｈｓ）を形成する。右側（ｒｈｓ）は定数であり、すなわち、デシマル値１６０である。以下の通り、リストＣはルールセット文書からのルール定義フラグメントを示す。
【数８】
2010530575.tif 000015
【００６３】
上記のようにしてルールは、ルールの動作セクションを固定するｔｈｅｎ要素に達するまで続く。リストＢからの第１の動作は、ＸＭＬ文書のＡｐｐｒｏｖｅｄフィールドをブール値真値に割り当てることである。割当関数は、ＸＭＬ文書バインディングおよび単一の引数のその値を取得する。リストＡとＣの語彙リンクは、ルールセット文書と、２つの組込語彙（関数および述語）および自身で考えた語彙とを関連させる。リストＤは自身の語彙の一部を示す。ルールセット文書と同様に、ｂｒｌ要素から始まる。この後に、バージョン管理情報を有する語彙要素が続く。そこから、一連の語彙定義要素が始まる。各々の語彙定義要素は、分かりやすいネームをデータベースカラムまたはＸＭＬ文書フィールドにバインディングする。以下の通り、リストＤは語彙ＢＲＬ文書を示す。
【数９−１】
2010530575.tif 000016
【数９−２】
2010530575.tif 000017
【００６４】
第１の定義は、ＣｏｎｓｕｌｔｉｎｇデータベースのＲａｔｅテーブルにおけるネームＳｖｃＮａｍｅとカラムｒａｔｅ＿ｎａｍｅとのバインディングである。最初に、ｄａｔａｂａｓｅｃｏｌｕｍｎｂｉｎｄｉｎｇｄｅｆｉｎｉｔｉｏｎ要素にカラムを指定し、次に、ｄａｔａｂａｓｅｉｎｆｏ要素にデータベース情報およびテーブル情報を提供する。示される第２の定義は、ＸＭＬ文書におけるネームＣｏｓｔとＥｓｔｉｍａｔｅフィールドとの関連付けである。ｄｏｃｕｍｅｎｔｅｌｅｍｅｎｔｂｉｎｄｉｎｇｄｅｆｉｎｉｔｉｏｎ要素は、ＸＭＬ文書要素へのバインディングではなく、ＸＭＬ文書における要素へのバインディングを示す。フィールドを選択する適切なＸＰａｔｈ式を当該要素に提供した後に、ｄｏｃｕｍｅｎｔｉｎｆｏ要素が、文書の．ＮＥＴスタイルタイプと、物理スキーマファイルと、この特定の文書クラスの文書要素の場所を明示的に示すＸＰａｔｈとを提供する。知ってのとおり、ＢＲＬへのルールセットおよび語彙のオーサリングは過酷な作業である。典型的に、これは決して手作業で行いたくないようなものなので、スキーマが存在する。おそらく、そのスキーマを用いて、既存のエクスポートファイルを変更することが可能である。例えば、ＸＰａｔｈを用いて、スキーマファイルパスの位置を示して整え、ターゲットサーバ環境を反映することが可能である。さらに、ＸＳＬＴを用いて、正規文書化を行うことにより、ルールセットをＨＴＭＬとして表示することが可能である。
【００６５】
ルールベースのアプリケーション開発用の．ＮＥＴ  ＡＰＩ
ルールをオーサリングする他の方法は、ルール開発用の．ＮＥＴ  ＡＰＩのクラスを用いたプログラムである。必要とされるクラスはＭｉｃｒｏｓｏｆｔ．ＲｕｌｅＥｎｇｉｎｅパッケージで認識される。このことは、ＢｉｚＴａｌｋサーバ２００４のインストールフォルダで認識されるＭｉｃｒｏｓｏｆｔ．ＲｕｌｅＥｎｇｉｎｅ．ｄｌｌアセンブリで実現される。基本的な方法は、ルールの条件部を表すＬｏｇｉｃａｌＥｘｐｒｅｓｓｉｏｎクラスのインスタンス、ＡｃｔｉｏｎＣｏｌｌｅｃｔｉｏｎのインスタンスを生成して、ルールの動作を維持することである。両方のオブジェクトが適切に設定されたときに、それらがルールクラスのインスタンスに加えられる。次に、ルールがＲｕｌｅｓｅｔオブジェクトに加えられる。ルールを継続しようとする場合、ＦｉｌｅＲｕｌｅＳｔｏｒｅまたはＳｑｌＲｕｌｅＳｔｏｒｅクラスの１つが用いられる。開発中にルールセットを実行するには、ＰｏｌｉｃｙＴｅｓｔｅｒオブジェクトが必要となる。ルールセットが作成された後、より簡単なＰｏｌｉｃｙクラスを用いることができる。これらのクラスは、ルール開発ＡＰＩの多くのクラスのごく僅かなものであるが、オーサリングのために用いられる主要なクラスである。オーサリングツールの作成と、．ＮＥＴクラスとの広範囲な連携を要求する場合、プロダクト文書化を詳細に調査する必要がある。しかしながら、ルールベースのアプリケーション開発に用いられる主要なクラスを考慮することができる。
【００６６】
ルール開発ＡＰＩ
ルールＡＰＩは２つのパッケージに属する。主要なパッケージは、Ｍｉｃｒｏｓｏｆｔ．ＲｕｌｅＥｎｇｉｎｅ．ｄｌｌで実現されるＭｉｃｒｏｓｏｆｔ．ＲｕｌｅＥｎｇｉｎｅである。他のＭｉｃｒｏｓｏｆｔ．ＢｉｚＴａｌｋ．ＲｕｌｅＥｎｇｉｎｅＥｘｔｅｎｓｉｏｎｓにより、３つのクラスが加えられて、ルールベースのシステムが拡張される。両方のアセンブリはＢｉｚＴａｌｋサーバのインストールフォルダに配置される。これらのパッケージは実際に多数のクラスを含むが、重要なものは少ししかない。これらのコアクラス、例えばポリシーが考慮されるべきである。開発中に、他のクラスのＰｏｌｉｃｙＴｅｓｔｅｒがその代わりをする可能性があるが、ポリシーは、実行に利用可能な作成知識ベースの完全なシステムを表す。実行のために、システムを設定すべきであり、ルールセットをロードすべきである。次に、Ｒｕｌｅｓｅｔクラスにより、Ｒｕｌｅクラスの１つ以上のインスタンスがロードされて用いられる。上記のように、Ｒｕｌｅオブジェクトは、ＬｏｇｉｃａｌＥｘｐｒｅｓｓｉｏｎオブジェクトとＡｃｔｉｏｎオブジェクトとを含む。ルールが重要であるにもかかわらず、ファクトなしには、知識ベースのシステムを有することができない。ポリシーのインスタンスにより、ＩＦａｃｔＲｅｔｒｉｅｖｅｒインタフェースを実現する、自身が開発したクラスが用いられる。このインタフェースは、長期ファクトおよびファクトベースを管理するインタフェースである。ポリシーがルールおよびファクトをロードし終えたとき、ルールエンジンによる実行の態勢にある。メモリにのみポリシーを保持し得るルールエンジンは、興味深い研究ツールであるが、企業アプリケーションには適切でないかもしれない。抽象クラスＲｕｌｅＳｔｏｒｅは、ポリシーおよび語彙用の永続的ストアの動作を発現させる。そのことは、２つの導出クラス、ＦｉｌｅＲｕｌｅＳｔｏｒｅおよびＳｑｌＲｕｌｅＳｔｏｒｅによって実現される。名前が示すように、ＦｉｌｅＲｕｌｅＳｔｏｒｅにより、記憶用のディスクファイルが使用され、ＳｑｌＲｕｌｅＳｔｏｒｅにより、ＳＱＬサーバ関連のエンジンが使用される。
【００６７】
ポリシー
ＢｉｚＴａｌｋポリシーはルールセットであり、ＢｉｚＴａｌｋルールエンジンに対応するクラスが存在するが、ポリシークラスは複数のもののカプセル化に有用である。そのカプセル化により、ルールストアおよびルールエンジンと協働する仕組みからプログラマが守られる。したがって、ポリシーインスタンスを設定し、それがあたかもルールエンジン自体であるかのように前記ポリシーインスタンスを連携させるべきである。ポリシーインスタンスはＲｕｌｅｓｅｔのインスタンスをロードし、このようにして、ポリシークラスとＢｉｚＴａｌｋポリシーの概念との区別を行うことができる。ポリシークラスは２つのコンストラクタを有する。一方のコンストラクタはストリングを取得し、その値は、連携を望むポリシーを指定する。他方のコンストラクタは、同じパラメータを取得し、メジャーおよびマイナーなポリシーバージョン番号の２つのＳｙｓｔｅｍ．Ｉｎｔ３２パラメータを加える。ポリシーコンストラクタを介してロードされた任意のポリシーをルールストアに展開しなければならない。他のクラスのＰｏｌｉｃｙＴｅｓｔｅｒは、そのインタフェースがＰｏｌｉｃｙに非常に類似しているが、発行ポリシー、および他のサーバからのポリシーのロードを可能にする追加のコンストラクタを有する。対照的に、Ｐｏｌｉｃｙは、ローカルストアと協働し、作成即応のルールセットに関連する。Ｐｏｌｉｃｙは４つのパブリックプロパティを有する。ＭｉｎｏｒＲｅｖｉｓｉｏｎおよびＭａｊｏｒＲｅｖｉｓｉｏｎはＰｏｌｉｃｙインスタンスのバージョン番号を集合的に定義する。ＰｏｌｉｃｙＮａｍｅはポリシーの名前である。ＲｕｌｅＳｅｔｌｎｆｏは、先行情報を繰り返して、誰がポリシーをセーブし、それがいつかに関するデータを加えるクラスである。４つの全てのプロパティは読み取り専用である。ポリシークラスは、１つの主要なパブリックメソッド、すなわちＥｘｅｃｕｔｅを有する。このメソッドは４つのオーバロード形式を有する。このメソッドの目的は、ファクトをポリシーにロードし、ルールセットを前記ファクトに適用することである。第１の形式はＳｙｓｔｅｍを取得する。クラスのあるインスタンスであるオブジェクトパラメータはシステムのファクトを表す。第２の形式はこのようなパラメータのアレイを取得する。残りの形式は、このパターン（単一のオブジェクトおよび一連のオブジェクト）を繰り返すが、第２のパラメータ、ＩＲｕｌｅＳｅｔＴｒａｃｋｉｎｇｌｎｔｅｒｃｅｐｔｏｒを実現するオブジェクトのインスタンスを加える。このインタフェースは、ルールエンジン用のデバッグシステムを実現するために用いられる。
【００６８】
ルールセット
このクラスは、提供された８つのバージョンのコンストラクタを有する。第１のコンストラクタは、ルールセットを指定するストリングパラメータを取得する。ポリシーとは異なり、このことは、クラスがストアから、指定されたルールセットをロードすることを意味しない。前記第１のコンストラクタは、典型的に、クラスの新たなインスタンスを初期化し、それに特定のネームを与える。ネームおよびバージョン番号を取得し、かつ同じ初期化を実行する他のコンストラクタが存在する。同じパラメータを取得し、かつタイプＳｙｓｔｅｍ．Ｃｏｌｌｅｃｔｉｏｎｓ．ＩＣｏｌｌｅｃｔｉｏｎのオブジェクトを加えるコンストラクタの２つ以上のバージョンが存在する。これは、ルールセットを構成するためのルールのコレクションである。残りのバージョンは、これまで見てきた全てのことを繰り返し、それと共に、タイプＶｏｃａｂｕｌａｒｙＬｉｎｋの最後のパラメータを加える。このパラメータは、分かりやすいネームおよび特定のファクトバインディングをルールセットに提供する語彙を引き込む。クラスは６つのプロパティを有し、これらのうちの３つがプログラマにとって特に重要である。これらのことを表１に示す。
【表１】
2010530575.tif 000018
【００６９】
ルール
これは、アプリケーションでルールセットを動的に作成する場合に用いるクラスである。このクラスを用いて、ツールを作成し得るか、またはそのクラスを用いて、規則的に変化する値を含む既知の基本ルールセットを有するルールセットを自動的に生成し得る。その場合、アプリケーションまたはデータベースから値を引き出し、ルールをプログラムで作成することによって、ルールセットを再生成することが可能である。このクラスの６つのコンストラクタが存在する。第１のコンストラクタは、新たなルールを指定するＳｙｓｔｅｍ．Ｓｔｒｉｎｇを取得する。このコンストラクタはストアからルールをロードしない。当該コンストラクタは、典型的に、空ルールオブジェクトを作成し、それにネームを与える。次のコンストラクタは、ネームパラメータを取得し、ＶｏｃａｂｕｌａｒｙＬｉｎｋオブジェクトを第２のパラメータとして加える。このコンストラクタも空オブジェクトを与えるが、ここで、前記パラメータは、構成されたルールに用いたかもしれないネームにリンクしている。残りのコンストラクタは、コンストラクタに渡されたパラメータに基づいて、完全なルールを作成する。このグループの第１のコンストラクタは、ネームのＳｙｓｔｅｍ．Ｓｔｒｉｎｇと、ルール条件のＬｏｇｉｃａｌＥｘｐｒｅｓｓｉｏｎオブジェクトと、動作のＡｃｔｉｏｎＣｏｌｌｅｃｔｉｏｎオブジェクトとを取得する。次の形式は、ルールの優先度を表すネームパラメータＳｙｓｔｅｍ．Ｉｎｔ３２を取得し、次に、ＬｏｇｉｃａｌＥｘｐｒｅｓｓｉｏｎオブジェクトおよびＡｃｔｉｏｎＣｏｌｌｅｃｔｉｏｎオブジェクトを取得する。最後の２つのコンストラクタは、上記のように、２つの形式を繰り返し、終了時に、ＶｏｃａｂｕｌａｒｙＬｉｎｋオブジェクトを加える。これらの２つコンストラクタのうち最初のコンストラクタは、ネーム、条件、動作、およびリンクを取得する。最後の形式は、ネーム、優先度、条件、動作、およびリンクを取得する。ルールクラスは６つのプロパティを有し、これらのプロパティの全てが読み書きである。プロパティはルールオブジェクトの部分および状態を示す。動作は、ルールの動作を含むＡｃｔｉｏｎＣｏｌｌｅｃｔｉｏｎである。Ａｃｔｉｖｅは、ルールがアクティブまたは休止状態であるかどうかを示すブール値変数である。ＣｏｎｄｉｔｉｏｎｓはＬｏｇｉｃａｌＥｘｐｒｅｓｓｉｏｎである。そのネームにもかかわらず、ルールは、１つのみの条件を有するが、複合式であってもよい。Ｎａｍｅは、ルールセット内で固有でなければならないストリングである。ＰｒｉｏｒｉｔｙはＩｎｔ３２であり、関連する範囲を有する。値が大きくなると、それだけ優先度が高くなる。しかし、ゼロ（０）はデフォルト値および中間値の両方である。ＶｏｃａｂｕｌａｒｙＬｉｎｋは最後のプロパティのネームおよびそのタイプの両方である。ＶｏｃａｂｕｌａｒｙＬｉｎｋはルールとドメイン固有の定義とのリンクを確立する。クラスは１つのみのメソッド、Ｃｌｏｎｅを有する。Ｃｌｏｎｅはルールのディープコピーを作成する。クローンは、同様の多数のルールを生成する迅速かつ便利な方法である。クローンを呼び出した後、オリジナルとは異なるルールのそれらの部分を変更することができる。
【００７０】
ＬｏｇｉｃａｌＥｘｐｒｅｓｓｉｏｎ
ルールの内部ワーキングおよび内部コンポーネントに進むことができる。ＬｏｇｉｃａｌＥｘｐｒｅｓｓｉｏｎはルール条件を表す。ＬｏｇｉｃａｌＥｘｐｒｅｓｓｉｏｎは単一のコンストラクタを有し、このコンストラクタは、パラメータを取得せず、空の条件オブジェクトを作成する。このクラスは２つのプロパティを有する。第１に、Ｔｙｐｅは、Ｓｙｓｔｅｍ．Ｔｙｐｅクラスの読み取り専用プロパティである。ＶｏｃａｂｕｌａｒｙＬｉｎｋは、当該ネームを有するクラスのオブジェクトとして分類される読み書きプロパティである。Ｒｕｌｅと同様にこのクラスは、条件のディープコピーを作成する単一のメソッド、Ｃｌｏｎｅを有する。これらのものはクラスの全てのプロパティおよびメソッドである。明らかに存在しないものは、論理式自体を作成するための任意の種類のメソッドである。そのことから、全ての述語を表すクラス、例えばＮｏｔＥｑｕａｌが存在し、そして複合式またはそれらの否定を作成するための３つの論理演算子のクラス、すなわち、ＬｏｇｉｃａｌＡｎｄ、ＬｏｇｉｃａｌＯｒ、およびＬｏｇｉｃａｌＮｏｔが存在することが理解される。自身のクラスまたは語彙リンクと組み合わせて、上記述語および論理演算子を用いることにより、柔軟にルールの条件が作成される。
【００７１】
ＡｃｔｉｏｎＣｏｌｌｅｃｔｉｏｎ
このクラスは、上記のように、ルールの条件が正しいと評価する場合に、順に実行される動作のコレクションである。クラスは２つのコンストラクタを有する。一方のコンストラクタはパラメータを取得せず、空のコレクションを作成する。他方のコンストラクタは、ＩＣｏｌｌｅｃｔｉｏｎのインスタンスを取得し、動作の既存のコレクションに基づいてオブジェクトを作成する。このクラスは、Ｃ＃のクラスインデクサとして機能する単一のプロパティ、Ｉｔｅｍを有する。Ｉｔｅｍは、整数インデックスを取得し、かつＦｕｎｃｔｉｏｎクラスのインスタンスを取得または設定する読み書きプロパティである。ＦｕｎｃｔｉｏｎはＲｕｌｅＥｎｇｉｎｅネームスペースから提供される。Ｆｕｎｃｔｉｏｎは、動作を実現する任意のクラスの原型として機能する抽象クラスである。この抽象性のため、ＡｃｔｉｏｎＣｏｌｌｅｃｔｉｏｎが、特殊目的のコードなしに、全ての種類の動作を扱うことが可能になる。このクラスは８つのメソッドを有し、それらのいくつかはオーバロード形式を有する。これらのメソッドを表２に示す。
【表２】
2010530575.tif 000019
【００７２】
ＦｉｌｅＲｕｌｅＳｔｏｒｅ
クラスＦｉｌｅＲｕｌｅＳｔｏｒｅおよびＳｑｌＲｕｌｅＳｔｏｒｅは、ヘッドにＲｕｌｅＳｔｏｒｅクラスを有する継承ツリーから導出される。ルールを作成するのに必要な相関セットのクラスを形成した他のクラスが実行可能な何かとして動作する。記憶クラスは、語彙およびルールセットを記憶する場所を提供するのに必要となる。大部分のプログラマはそれら自体のルールストアクラスを実行しておらず、したがって、抽象ベースクラスをカバーする必要はそれほどない。ＳＱＬサーバルールストアを扱うとき、ＰｏｌｉｃｙおよびＰｏｌｉｃｙＴｅｓｔｅｒのメソッドを用いて、ルールセットをロードすることができる。分かりやすくするために、ルール記憶のトピック全体に向けられる手段としてＦｉｌｅＲｕｌｅＳｔｏｒｅの詳細を調べることができる。ＦｉｌｅＲｕｌｅＳｔｏｒｅは、表３に記載される４つのコンストラクタを有する。基本的に、全てのコンストラクタは、ファイルストアの場所を示すことによって、新たに作成されたオブジェクトを初期化する。最後の３つのコンストラクタは、セキュリティとロードの利便性とに関するパラメータを加える。
【表３】
2010530575.tif 000020
【００７３】
ＦｉｌｅＲｕｌｅＳｔｏｒｅは、プロパティを有さず、表４に記載される６つのメソッドを有する。ファイルルールストアはルールセットおよび語彙の簡単なコレクションである。これらのメソッドにより、コレクションの項目の追加、削除、および読み出しの共通のコレクション動作が実行される。
【表４】
2010530575.tif 000021
【００７４】
ＧｅｔＲｕｌｅＳｅｔｓおよびＧｅｔＶｏｃａｂｕｌａｒｉｅｓがルールセットおよび語彙を直接検索しないことに留意されたい。むしろ、ＧｅｔＲｕｌｅＳｅｔｓおよびＧｅｔＶｏｃａｂｕｌａｒｉｅｓは、当該メソッドのパラメータで指定されたいくつかの基準に合う、全てのルールセットまたは語彙を見出すために、ルールストアの問い合わせを提供する。ＧｅｔＲｕｌｅＳｅｔまたはＧｅｔＶｏｃａｂｕｌａｒｙを用いて、関心のある実際のルールセットまたは語彙を検索することが必要となり得る。
【００７５】
ＩＦａｃｔＲｅｔｒｉｅｖｅｒインタフェース
このインタフェースを実現するクラスを書き込むときに、長期ファクトベースを管理する必要があり得る。インタフェースは単一のメソッドからなり、このようにして、この実行の複雑さがキャッシングスキームの洗練度のみによって決定される。ファクトベースが、メモリのキャッシングファクトから得るべき利益に対して、当該情報をどの程度の頻度で変更して平均化する可能性があるかという適切な予測を行う必要があり得る。ＵｐｄａｔｅＦａｃｔｓは実行に必要なメソッドである。このメソッドにより、Ｓｙｓｔｅｍ．Ｏｂｊｅｃｔのインスタンスが返され、当該インスタンスが自身の更新されたファクトへのハンドルであるようにルールエンジンが受け取る。システムは、戻された実際のオブジェクトをどのように処理するかを決定する際に、そのオブジェクトを検証する。例えば、システムは、ＡＤＯデータベースコネクションを受けるとき、ＡＤＯオブジェクトおよびメソッドを用いて、当該データベースからファクトを検索すべきであることを理解する。ＵｐｄａｔｅＦａｃｔｓは３つのパラメータを取得する。第１のパラメータは、使用ルールセットを記述するＲｕｌｅＳｅｔＩｎｆｏオブジェクトである。第２のパラメータは、ルールセットを実行するＲｕｌｅＥｎｇｉｎｅオブジェクトに対するリファレンスである。これらのクラスのメソッドを用いて、いかなるファクトが必要となるかについての手がかりを得る。第３のパラメータはＳｙｓｔｅｍ．Ｏｂｊｅｃｔインスタンスである。最初に自身のクラスが呼び出されたとき、このパラメータはゼロである。その後、このパラメータはＵｐｄａｔｅＦａｃｔｓのその前の呼び出しの戻り値となり、これによって、ファクトベースの状態に関するより多くの情報が前記パラメータに与えられる。
【００７６】
ルール変換および移行に関する設定
ルールで静的メソッドを呼び出すことができる。
ルールで静的関数を直接呼び出すことができる。例えば、ルールをファクトオブジェクトとしてパスさせることなく、ルール内でＤａｔｅＴｉｍｅ．Ｎｏｗ関数または他の同様の標準関数を直接呼び出すことができる。ＳｔａｔｉｃＳｕｐｐｏｒｔレジストリキーを加えるために、
●Ｓｔａｒｔをクリックし、Ｒｕｎをクリックし、ＲｅｇＥｄｉｔをタイプし、そしてＯＫをクリックする。
●ＨＫＥＹ＿ＬＯＣＡＬ＿ＭＡＣＨＩＮＥを拡張し、Ｓｏｆｔｗａｒｅを拡張し、Ｍｉｃｒｏｓｏｆｔを拡張し、ＢｕｓｉｎｅｓｓＲｕｌｅｓを拡張し、そして３．０を選択する。
●右側のウィンドウ枠において、右クリックし、Ｎｅｗにポイントし、そしてＤＷＯＲＤ値をクリックする。
●Ｎａｍｅについて、ＳｔａｔｉｃＳｕｐｐｏｒｔとタイプする。
【００７７】
ＳｔａｔｉｃＳｕｐｐｏｒｔレジストリキーが既に存在し、その値を変更する必要がある場合、以下のステップを実行する。ＳｔａｔｉｃＳｕｐｐｏｒｔレジストリキーの値を変更するために、
●Ｓｔａｒｔをクリックし、Ｒｕｎをクリックし、ＲｅｇＥｄｉｔをタイプし、そしてＯＫをクリックする。
●ＨＫＥＹ＿ＬＯＣＡＬ＿ＭＡＣＨＩＮＥを拡張し、Ｓｏｆｔｗａｒｅを拡張し、Ｍｉｃｒｏｓｏｆｔを拡張し、ＢｕｓｉｎｅｓｓＲｕｌｅｓを拡張し、そして３．０を拡張する。
●ＳｔａｔｉｃＳｕｐｐｏｒｔレジストリキーをダブルクリックするか、またはそのレジストリキーを右クリックし、そしてＭｏｄｉｆｙをクリックする。
【００７８】
上記キーは、以下に示すような３つの有効値を受け入れる。
０−  これは、キーのデフォルト値であり、この値はＢｉｚＴａｌｋサーバ２００４の動作を模倣し、ここで、オブジェクトのインスタンスは常に入力ファクトとして必要となり、そしてルールが評価または実行されるときにのみメソッドが呼び出される。
１−  オブジェクトのインスタンスが不要となり、ルールが評価または実行されるときは常に静的メソッドが呼び出される。
２−  オブジェクトのインスタンスは不要となるが、ルール翻訳時に（パラメータが定数である場合にのみ）静的メソッドが呼び出される。この値は主に性能の最適化を意味する。しかし、動作として用いられる静的メンバは翻訳時に実行されず、パラメータとして用いられる静的メソッドが実行され得ることに留意されたい。
このようにして、１または２を用いて、静的サポートを可能にし、静的メソッドを直接呼び出す必要がある。
【００７９】
アプリケーション設定ファイルによるレジストリキーの無効化
アプリケーション設定ファイルを用いることによって、レジストリエントリを無効化することができる。レジストリ設定は、ルールエンジンインスタンスをホストする全てのアプリケーションについてグローバルである。アプリケーション設定ファイルを用いることによって、これらのレジストリ設定をアプリケーションレベルで無効化することができる。ＢｉｚＴａｌｋサーバアプリケーションについて、ホストアプリケーションはＢＴＳＮＴＳｖｃ．ｅｘｅであり、設定ファイルは、ＢｉｚＴａｌｋサーバのインストールディレクトリで見出すことができるＢＴＳＮＴＳｖｃ．ｅｘｅ．ｃｏｎｆｉｇである。以下に示すように、アプリケーション設定ファイルで無効化しようとする設定パラメータの値を指定する必要があり得る。
【数１０】
2010530575.tif 000022
【００８０】
ＢＲＥへのルールのプログラム展開
Ｍｉｃｒｏｓｏｆｔ．ＲｕｌｅＥｎｇｉｎｅ．ＲｕｌｅＥｎｇｉｎｅＥｘｔｅｎｓｉｏｎｓネームスペースのＲｕｌｅＳｅｔＤｅｐｌｏｙｍｅｎｔＤｒｉｖｅｒクラスを用いて、およびＲｕｌｅＥｎｇｉｎｅＣｏｍｐｏｎｅｎｔＣｏｎｆｉｇｕｒａｔｉｏｎクラスを用いてアプリケーション内でルールまたはポリシーを呼び出して、ルールをプログラムで展開することができる。以下のものは、ルールをプログラムで展開するコードを典型的に示す。
【数１１】
2010530575.tif 000023
【００８１】
自身のＢｉｚＴａｌｋサーバ環境が使用すると設定されているデータベースにポリシーを展開している場合、コードでＲｕｌｅＳｅｔＤｅｐｌｏｙｍｅｎｔＤｒｉｖｅｒオブジェクトを作成する必要はない。代わりに、ルールエンジンにリクエストを行い、ＣｏｎｆｉｇｕｒａｔｉｏｎクラスのＧｅｔＤｅｐｌｏｙｍｅｎｔＤｒｉｖｅｒメソッドをＳｙｓｔｅｍ．ＲｕｌｅＥｎｇｉｎｅネームスペースに呼び出すことにより、自身のＲｕｌｅＳｅｔＤｅｐｌｏｙｍｅｎｔＤｒｉｖｅｒオブジェクトを作成させることができる。以下のコードサンプルは、ＧｅｔＤｅｐｌｏｙｍｅｎｔＤｒｉｖｅｒメソッドを呼び出す方法を示す。
【数１２】
2010530575.tif 000024
【００８２】
ＧｅｔＤｅｐｌｏｙｍｅｎｔＤｒｉｖｅｒメソッドは、ＨＫＥＹ＿ＬＯＣＡＬ＿ＭＡＣＨＩＮＥ＼Ｓｏｆｔｗａｒｅ＼Ｍｉｃｒｏｓｏｆｔ＼ＢｕｓｉｎｅｓｓＲｕｌｅｓ＼３．０において、ＤｅｐｌｏｙｍｅｎｔＤｒｉｖｅｒＡｓｓｅｍｂｌｙレジストリキーおよびＤｅｐｌｏｙｍｅｎｔＤｒｉｖｅｒＣｌａｓｓレジストリキーの値を取り出し、ＤｅｐｌｏｙｍｅｎｔＤｒｉｖｅｒＣｌａｓｓのインスタンスを作成する。以下のものは上記キーの２つの値である。
【数１３】
2010530575.tif 000025
【００８３】
ＲｕｌｅＳｅｔＤｅｐｌｏｙｍｅｎｔＤｒｉｖｅｒクラスはＩＲｕｌｅＳｅｔＤｅｐｌｏｙｍｅｎｔＤｒｉｖｅｒインタフェースを実現する。ＩＲｕｌｅＳｅｔＤｅｐｌｏｙｍｅｎｔＤｒｉｖｅｒインタフェースを実現するクラスを作成することによって、自身のポリシー展開ドライバを開発し、適切な場合、上記レジストリキーの値を変更することができる。上記ＲｕｌｅＥｎｇｉｎｅＣｏｍｐｏｎｅｎｔＣｏｎｆｉｇｕｒａｔｉｏｎクラス内のＲｕｌｅＥｎｇｉｎｅＣｏｍｐｏｎｅｎｔＣｏｎｆｉｇｕｒａｔｉｏｎメソッドを用いて、以下のコードで示すようにカスタムファクトを渡すことができる。
【数１４】
2010530575.tif 000026
【００８４】
上記のことに加えて、Ｐｏｌｉｃｙクラスには、Ｃｌｅａｒとネームされた新たなメソッドが加えられ、これにより、ポリシーを実行するために作成されたルールエンジンインスタンスのメモリがリセットされる。また、Ｎｕｌｌａｂｌｅタイプ、一般的なメソッドおよびクラスのサポートは、ＢｉｚＴａｌｋサーバ２００６のビジネスルールエンジンの他の増強である。
【００８５】
発行された語彙およびルールの変更
全てのソフトウェア開発と同様に、その開発には、それを正しく実行できるようにする前に、ファクト語彙の多くのバージョンが通常必要となる。所望するとおり動作する自身のルールができあがるまで、自身の語彙が２０〜３０のバージョンに容易に場合があることは誇張して言っているわけではない。代替方法は語彙をルールデータベースに直接発行しないことである。処理は以下のようなものである。
１．自身の語彙を発行する。
２．語彙に関連する自身のルールを検証する。
３．ＢｉｚＴａｌｋＲｕｌｅＥｎｇｉｎｅＤｂのｒｅ＿ｖｏｃａｂｕｌａｒｙテーブルを開き、ｎＳｔａｔｕｓフィールドを１から０に変更する（１＝発行する、０＝発行しない）。ｓｔｒＮａｍｅフィールドに保持された語彙ネームによって、自身の語彙を識別することができる。
４．語彙をルールコンポーザにリロードし、自身のファクトを追加／変更する。
５．語彙をセーブし、次に、ｎＳｔａｔｕｓフィールドを１に戻す設定をする（ルールコンポーザから語彙を再発行しないこと。さもなければ、主要なキー違反を受ける）。
６．ポリシー／語彙をルールコンポーザに再びリロードし、自身のポリシーを再検証する。
【００８６】
ポリシーでも、同じ方法を用いることができる。典型的に、ルールを発行し、ルールコンポーザの検証機能を用いて、当該ルールを検証することは不要であるが、意図する場合、自身のオーケストレーションからルールを検証する。自身のユニット検証中と同じくらいに、この処理でバグを発見することができる場合がある。ポリシーの新たなバージョンを作成する代わりに、ｒｅ＿ｒｕｌｅｓｅｔテーブルのｎＳｔａｔｕｓフィールドを変更して、ポリシーを一時的に発行しないようにすることができ、その結果、そのポリシーを編集することができる。
【００８７】
図４は、本発明の一実施形態によるルールコンポーネントを変換するためのアーキテクチャ４００を示している。ルールは、ルールエクストラクタ４０５によってＣＯＢＯＬコード４０１（図１に示したようなルールエクストラクタ１０７により提供される機能と同様）から抽出される。ＣＯＢＯＬコード４０１からの語彙（語彙エクストラクタ４０３によって抽出される）と抽出された論理とが組み合わされて、新たなルールセットを形成し、これらのルールセットがルールデプロイヤ４０７によってビジネスルールエンジン４０９にインポートされる。
【００８８】
ルールコンポーネントを変換するための高レベルフロー
図５は、本発明の一実施形態による形式ルール変換を行うための高レベルフロー５００を示している。語彙およびルールは、ルール変換モジュール５０３によって、アクセンチュア納税管理システム（ＴＡＳ）５０１からの一般的なルールエンジン言語（ＢＰＥＬ）に変換されて書き出される。語彙およびルールは、ＢｉｚＴａｌｋ５０５（図２に示したようなターゲットアプリケーション２１７のビジネスルールエンジンに対応）にインポートされる。さらに、サードパーティルールエンジン５０７をＢＰＥＬにエクスポートして、開発されたルーチンにより、当該ルールエンジンをロードすることが可能である。
【００８９】
図６は、本発明の一実施形態によるバックエンドルール変換を行うための高レベルフロー６００を示している。変換ルーチン６０５は、ＴＡＳ６０１およびそれに関連するデータベース６０３からバックエンドルールを抽出する。ルールは、ＢＰＥＬに標準化され、バックエンドルールを実行するためにＢｉｚＴａｌｋ６０７にエクスポートされる。
【００９０】
データ変換
図７は、本発明の一実施形態によるデータ移行処理７００を示している。クライアントのより高い要求を実現するために、アクセンチュア・エンタープライズ・レベニュー・ソリューション（ＡＥＲＳ）プログラムは、ＴＡＳコンバータアプリケーション７０３を組み込んでおり、このアプリケーションは、ソースサーバ７０１からのルールおよびデータを変換し、そしてステージングサーバ７０５を介して、変換されたルールおよびデータを１つまたは複数の宛先サーバ７０９に移行させる。移行アプリケーションは、データを変換するための／ＡＥＲＳに切り替えるためのファーストトラックな方法をＴＡＳの顧客に提供する。ＴＡＳコンバータは以下のことを提供することを意図する。
●既存のＴＡＳクライアントのためにアップグレードパスを提供すること
●ＩＴＳアップグレードのコストを低減すること
●ＩＴＳアップグレードのリスクを低減すること
●コアアップグレードの時間を短縮すること
【００９１】
ＴＡＳコンバータ７０３は、変換の以下の分野、すなわち、データ変換、形式ルール変換、インタフェース変換、コレスポンデンス変換、バックエンドルール変換、収益勘定科目一覧表の移行、および既存のＴＡＳレポートの変換を組み込んでいる。
【００９２】
データ移行処理
高レベルにおいて、データ移行は、以下に示すような５つのステップを経る。
１．ＴＡＳコンバータアプリケーション７０３が、指定されたＩＴＳ（統合納税システム、この場合、アクセンチュア納税管理システム）のバックエンド構造７０１からデータを選択して抽出する。アプリケーションが、一般的なＳＱＬの「ＳＥＬＥＣＴ」および「ＪＯＩＮ」のステートメントの組み合わせを利用して、関連するデータを引き出す。
２．アプリケーションが、抽出されたデータの任意の予備的なクレンジング動作およびフォーマット動作を実行する。その後、ＩＴＳデータが挿入され、ＳＱＬサーバのレポジトリ７０５に一時的に記憶される。
３．フラットファイルをエクスポートする前の最後のクレンジングおよびフォーマッティング用に、ＴＡＳコンバータアプリケーション７０３が、一般的なＳＱＬの「Ｓｅｌｅｃｔ」のステートメントを用いて、ＳＱＬレポジトリ７０５から全てのデータを抽出する。
４．ＴＡＳコンバータアプリケーション７０３を介して抽出された全てのデータが、必要なクレンジングおよびフォーマットを受ける。その後、データが、ターゲットシステム（ＳＡＰまたは他のシステム）７０９へのバルク挿入のために、自動生成されたフラットファイル７０７にエクスポートされる。フラットファイルが、予め指定されたファイルシステムの位置にセーブされる。
５．Ｅｍｉｇａｌｌが、生成されたフラットファイルのデータをＳＡＰバックエンドシステム７０９にアップロードするバルク挿入プログラムとして用いられる。
【００９３】
ＴＡＳコンバータ７０３は、ＩＴＳデータをＳＡＰシステム７０９に移行させ、かつクレンジングするための、一般的で、分離されていて、かつ柔軟なメソッドを提供する４つの階層構造に依存する。この構造は以下の階層を含む。
●ソース−  「ソース」階層は、移行させるべき元のデータセットを保持する顧客のＩＴＳを収容する。
●ステージング−  「ステージング」階層は、クレンジングして一時的に記憶すべき「ソース」データを受け取る一時的な構造を提供する。
●宛先−  「宛先」階層は、クレンジングされた「ステージング」を含む生成されたフラットファイルを受け取って保持する。
●ＳＡＰ−  「ＳＡＰ」階層はソースデータの最後の宛先である。
【００９４】
図８は、本発明の一実施形態によるＴＡＳコンバータ処理８００を示している。移行処理の多くはＴＡＳコンバータの処理８００によって管理される。処理８００は、ＳＳＩＳを利用して、ＩＴＳデータの抽出、変換およびロードを行う。さらに、処理８００は、移行フローの進行を視覚的に示すグラフィックインタフェースを提供し得る。
【００９５】
ＴＡＳコンバータ処理８００によって、以下のステップが実行される。
ステップ１：ステージングデータベーステーブルをパージする（ステップ８０１）
●ステージングデータベースから全てのデータを消去する
ステップ２：ＴＡＳデータを抽出してロードする（ステップ８０３）
●データをＤＢ２テーブルのＴＦ１ＥＮＴＩＴＹおよびＴＦ１ＢＵＳＤＥＴから抽出してＳＱＬテーブルＴＡＸＰＡＹＥＲＳにロードする
●データをＤＢ２テーブルのＴＦ１ＡＤＤＲから抽出してＳＱＬテーブルのＡＤＤＲＥＳＳＥＳにロードする
●データをＤＢ２テーブルのＴＦ１ＩＤから抽出してＳＱＬテーブルのＩＤＥＮＴＩＦＩＣＡＴＩＯＮＳにロードする
●データをＤＢ２テーブルのＴＦ１ＡＣＣＴから抽出してＳＱＬテーブルのＡＣＣＯＵＮＴＳにロードする
●データをＤＢ２テーブルのＴＦ１ＲＥＬＡから抽出してＳＱＬテーブルのＲＥＬＡＴＩＯＮＳＨＩＰＳにロードする
●データをＤＢ２テーブルのＴＦ１ＮＡＭＥから抽出してＳＱＬテーブルのＮＡＭＥＳにロードする
ステップ３：テーブルの納税者、ネーム、アドレス、識別を変換する（ステップ８０５）
●ＴＡＸＰＡＹＥＲＳの変換およびコードマッピングを実行し、ＴＡＸＰＡＹＥＲＳ＿ＮＥＷにロードする
●ＡＤＤＲＥＳＳＥＳの変換およびコードマッピングを実行し、ＡＤＤＲＥＳＳＥＳ＿ＮＥＷにロードする
●ＮＡＭＥＳの変換を実行し、ＮＡＭＥＳ＿ＮＥＷにロードする
●ＩＤＥＮＴＩＦＩＣＡＴＩＯＮＳの変換およびコードマッピングを実行し、ＩＤＥＮＴＩＦＩＣＡＴＩＯＮＳ＿ＮＥＷにロードする
●ＴＡＸＰＡＹＥＲＳ変換およびコードマッピングを実行し、ＴＡＸＰＡＹＥＲＳ＿ＮＥＷにロードする
ステップ４：テーブルの関係、契約アカウント、契約オブジェクトを変換する（ステップ８０７）
●ＡＣＣＯＵＮＴＳの変換およびコードマッピングを実行し、ＡＣＣＯＵＮＴＳ＿ＣＡにロードする
●ＡＣＣＯＵＮＴＳの変換およびコードマッピングを実行し、ＡＣＣＯＵＮＴＳ＿ＣＯにロードする
●ＲＥＬＡＴＩＯＮＳＨＩＰＳ変換およびコードマッピングを実行し、ＲＥＬＡＴＩＯＮＳＨＩＰＳ＿ＮＥＷにロード
ステップ５：自身の関係を削除する（ステップ８０９）
●ＳＱＬを用いて、自身に関する全ての関係を削除する
ステップ６：フラットファイルを作成する（ステップ８１１）
●スクリプトは、フラットファイルＴａｘＰａｙｅｒｓ．ｔｘｔ、ＣｏｎｔｒａｃｔＡｃｃｏｕｎｔｓ．ｔｘｔ、ＣｏｎｔｒａｃｔＯｂｊｅｃｔｓ．ｔｘｔ、およびＲｅｌａｔｉｏｎｓｈｉｐｓ．ｔｘｔを生成する
●ＴＡＳＣｏｎｖｅｒｔｅｒ．ＤａｔａＣｏｎｖｅｒｓｉｏｎクラスを用いて、フラットファイルの作成を行う
ステップ７、ステップ８（ＳＡＰ  ＧＵＩ内で行われるが、図８には明示していない）
ステップ７：ＳＡＰ用のインポートファイルを作成する
●トランザクションＥＭＩＧＡＬＬ−＞移行オブジェクト−＞データインポートにナビゲートする
●ＳＡＰがロードすることができるインポートファイルを作成する
●編集−＞データ−＞アップロード
ステップ８：データのインポートを行う
●データメニューからインポートデータを選択する
【００９６】
データコンポーネントを変換するための高レベルフロー
図９は、本発明の一実施形態によるＴＡＳからの収益勘定科目一覧表を変換するための高レベルフロー９００を示している。変換ルーチン９０３は、アクセンチュア納税管理システム（ＴＡＳ）９０１から勘定科目一覧表を取得し、その表を標準フォーマットに変換する。共通の構造において、更新された構造を提供するために、勘定科目一覧表がＳＡＰサーバ９０５に１回インポートされる。
【００９７】
図１０は、本発明の一実施形態によるアクセンチュア納税管理システム（ＴＡＳ）１００１からのデータコンポーネントを変換するための高レベルフロー１０００を示している。データコンポーネントのデータ要素が納税管理システム１００１から取得され、このシステムにおいて、レガシーデータ要素が、予め定義された非正規化構造に抽出される。データ要素用の非正規化データ構造はＳＡＰアプリケーション１００５にマッピングされる。
【００９８】
他のコンポーネントを変換するための高レベルフロー
【００９９】
図１１は、本発明の一実施形態による納税管理システム１１０１からのコレスポンデンスコンポーネントの高レベルフロー１１００を示している。変換ルーチン１１０３はコレスポンデンスデータ要素をアクセンチュア納税管理システム（ＴＡＳ）１１０１からＳＡＰデータ要素にマッピングする。コレスポンデンスコンテンツおよびデータ要素はＳＡＰアプリケーション１１０７にインポートされる。さらに、サードパーティテンプレートまたはサードパーティデータ１１０５を変換ルーチンにマッピングすることができる。
【０１００】
図１２は、本発明の一実施形態による納税管理システムからのインタフェースコンポーネントを変換するための高レベルフロー１２００を示している。インタフェース１２０５を所定の位置に配置して、ＳＡＰサーバ１２０１により進行中の動作をサポートすることができる。仮想データベース１２０３は、レガシー変換ルーチンおよびレガシー変換インタフェースを実行することができる概念的なＴＡＳデータ構造である。
【０１０１】
図１３は、本発明の一実施形態による納税管理システム１３０１からのレポートコンポーネントを変換するための高レベルフロー１３００を示している。同じデータ入力をエージェンシレポートに提供するために、ＴＡＳレポートのデータ要素がＳＡＰシステム１３０５におけるデータ要素にマッピングされる。レポート能力１３０７により、データ要素の同じ解釈を用いておよび同様のプレゼンテーションで、レポートを再生することが可能になる。さらに、クライアントは、ＳＡＰシステム１３０５にマッピングするために、レガシーデータ構造１３０３を変換ルーチンにマッピングし得る。
【０１０２】
典型的なＴＡＳ人口統計表の説明
図１４は、本発明の一実施形態によるＴＡＳ人口統計表構造１４００を示している。ＴＡＳコンバータは、ソースおよび宛先バックエンドシステムとして使用される選択された産業のＩＴＳおよびＡＥＲＳ設定のソフトウェアに基づいて、開発および検証される。ソースＩＴＳシステムとして、アクセンチュアＴＡＳシステムが使用された。具体的には、既存のクライアント実装と同様のバックエンド設定によった。宛先ＡＥＲＳバックエンドシステムはＳＡＰ  ＰＳＣＤモジュールであった。アクセンチュアの管理およびＳＭＥが関与して、人口統計データ構造が、移行させるべき第１の一連のデータに選ばれた。ＴＡＳシステムは、人口統計データを保持しかつＴＡＳコンバータによって処理される９つのバックエンドテーブルを含む。ＴＡＳ人口統計表について以下に詳細に説明する。
【表５】
2010530575.tif 000027
【０１０３】
ＴＡＳ人口統計表の説明
ＴＦ１ＡＣＣＴ：
納税者は、登録されている全ての課税方式に関するこのテーブルに、例えば、所得税、消費税および使用税、法人所得税、源泉徴収税等を記録し得る。各々について、テーブルは、ａｃｃｔ  ｉｄ（適用できる場合、消費税および使用税アカウントならびに源泉徴収税アカウントのみ）、アカウントの有効日付、申告の頻度等のような情報を保持する。注：季節毎の申告者については、それらの申告者が数ヶ月毎に申告する情報が記憶される。
【０１０４】
ＴＦ１ＡＤＤＲ：
納税者はこのテーブルの２つ以上のエントリを有することができ、例えば、プライマリ、メール、ロケーション等の異なるアドレスタイプを有することができ、これらの異なるアドレスタイプは、全納税者に、または例えば、消費税および使用税、源泉徴収税等の特定のアカウントタイプに関連させることができる。
【０１０５】
ＴＦ１ＡＳＳＥＴ：
納税者はこのテーブルの情報を有しても有しなくてもよい。テーブルは、徴収目的（すなわち銀行口座、雇用者等）のために用い得る、納税者について収集されている資産情報を記憶する。
【０１０６】
ＴＦ１ＢＵＳＤＥＴ：
このテーブルのネームにもかかわらず、個人を含む全ての納税者は、このテーブルのエントリを有するが、いくつかのフィールドは事業体、例えばＮＡＩＣＳコードにのみ関連する。テーブルは、ビジネスタイプ、ＮＡＩＣＳコード、ならびにいつビジネスが開始および／または終了したか等の情報を保持する。
【０１０７】
ＴＦ１ＥＮＴＩＴＹ：
このテーブルは、例えば、納税者、関係者、プロパティ等のエンティティタイプを記憶し、納税者が、例えば、あるセキュリティを有するユーザにしか閲覧することができない制限された納税者であるか否かを記憶し、そして納税者がＣＲＭシステムのサービス要求を有するか否かを記憶する。
【０１０８】
ＴＦ１ＥＸＥＭＰＴ：
納税者はこのテーブルの情報を有しても有しなくてもよい。テーブルは特定のアカウント用の控除タイプを記憶し、例えば、非営利団体はそれらの消費税および使用税アカウント用のレコードを本テーブルに有することが可能である。
【０１０９】
ＴＦ１ＩＤ：
ＩＤ＿ＩＮＴＥＲＮＡＬは全ての納税者の固有の識別子であり、納税者は、２つ以上の外部ＩＤタイプを有することができるので、このテーブルに２つ以上のエントリを有することができるが、１つの外部ＩＤのみがプライマリＩＤであり得る。
【０１１０】
ＴＦ１ＮＡＭＥ：
納税者は、２つ以上のネームタイプ（すなわち正式名称、商号等）を有することができるので、このテーブルに２つ以上のエントリを有することができる。
【０１１１】
ＴＦ１ＲＥＬＡ：
納税者はこのテーブルの情報を有しても有しなくてもよい。このテーブルは、システムのエンティティを互いにリンクし、その関係が相殺にふさわしいか否かを示す。
【０１１２】
典型的な要件
本項の目的は、ＡＥＲＳに関するＴＡＳコンバータの開発インフラストラクチャをサポートするのに必要なハードウェア要件およびソフトウェア要件の概要を提供することである。
注：記載されるソフトウェアは、用いられる開発および検証シナリオに対応する。これらのソフトウェアコンポーネントが展開されてＴＡＳコンバータの技術ランドスケープに導入される順序は、詳細な展開計画の項で明示的に取り上げる。
【０１１３】
ＴＡＳコンバータはＡＥＲＳ環境の以下のオペレーティングシステムを使用する。
●１  ウィンドウズ２００３サーバ  −  １  ＣＰＵ、２ＧＢ  ＲＡＭ（ＤＢ２ＤＢ）
●１  ウィンドウズ２００３サーバ  −  １  ＣＰＵ、２ＧＢ  ＲＡＭ（ＳＱＬサーバＤＢ）
●１  ウィンドウズ２００３サーバ  −  １  ＣＰＵ、４ＧＢ  ＲＡＭ（ＥＣＣ６．０）
【０１１４】
ＴＡＳコンバータの開発環境を構築するために、以下のソフトウェアが必要となる。
●マイクロソフトＳＱＬサーバ２００５エンタープライズエディション
●ＩＢＭ  ＤＢ２バージョン９．１
●マイクロソフトビジュアルスタジオ２００５プロフェッショナルエディション
●ＤＢ２用のマイクロソフトＯＬＥ  ＤＢプロバイダ
●マイクロソフトビジュアルソースセーフ２００５（オプション）
●ＳＡＰ  ｍｙＳＡＰ  ＥＲＰ２００５（ＰＳＣＤ）
【０１１５】
典型的な展開計画
本項の目的は、ＴＡＳコンバータの環境をセットアップするのに必要なステップの順序を詳細に説明することである。これは、ＴＡＳコンバータチームがＴＡＳコンバータインフラストラクチャを構成するときのＴＡＳコンバータチームのロードマップとして機能すべきである。
【０１１６】
本項は、ソフトウェアのインストールおよびソフトウェアコンポーネントの高レベルの詳細である。ユーザは、ＴＡＳコンバータの展開の順序および概要に関するロードマップとしてこの項を参照し得る。
１．ＳＡＰ  ＰＳＣＤをインストールする
ａ．基盤チームによってインストールされたタスク
２．ＩＢＭ  ＤＢ２のインストール
ａ．ＤＢ２  Ｖ９をインストールする
ｂ．ＴＡＳテーブル構造をインポートする
ｉ  ＳＱＬ挿入クエリを実行する
ｃ．ＴＡＳデータをアップロードする
ｉ  フラットファイルフィールドをマッピングする
３．ＤＢ２用のマイクロソフトＯＬＥデータプロバイダのインストール
ａ．開発マシンにおけるＤＢ２プロバイダのインストール
ｂ．ランタイムマシンにおけるＤＢ２プロバイダのインストール
４．マイクロソフトＳＱＬサーバ２００５のインストール
ａ．開発マシンにおけるＳＱＬサーバ２００５のインストール
ｂ．ランタイムマシンにおけるＳＱＬサーバ２００５のインストール
ｃ．ＳＱＬテーブル構造をインポートする
５．ＴＡＳコンバータアプリケーションのインポート
ａ．既存のＳＳＩＳアプリケーションをコピーする
ｂ．ＳＳＩＳアプリケーションをビジュアルソースセーフにアップロードする
ｃ．アプリケーションを設定する
ｉ  データソースの証明書および場所を設定する
ｉｉ  ファイルシステムの証明書および場所を設定する
【０１１７】
本発明を実施する現在好ましい形態を含む特定の実施例を参照して、本発明について説明してきたが、当業者は、添付された特許請求の範囲に記載される本発明の精神および範囲内に含まれる上記システムおよび技術の多数の変形形態および置換があることを理解するであろう。
【０１１８】
付録Ａ：ＤＢ２インストール／設定のレファレンス
使用
この付録を用いて、ＤＢ２のインストールガイドおよび設定ガイドの参照場所を示す。
手順
●ＤＢ２  Ｖ９データベースのインスタンスをインストールおよび／または構成することができる
レファレンス
単一のパーティションのインストール（ウィンドウズ）
ｈｔｔｐ：／／ｐｕｂｌｉｂ．ｂｏｕｌｄｅｒ．ｉｂｍ．ｃｏｍ／ｉｎｆｏｃｅｎｔｅｒ／ｄｂ２ｌｕｗ／ｖ８／ｔｏｐｉｃ／ｃｏｍ．ｉｂｍ．ｄｂ２．ｕｄｂ．ｄｏｃ／ｓｔａｒｔ／ｔ０００７１８４．ｈｔｍ
データをテーブルにロードする
ｈｔｔｐ：／／ｐｕｂｌｉｂ．ｂｏｕｌｄｅｒ．ｉｂｍ．ｃｏｍ／ｉｎｆｏｃｅｎｔｅｒ／ｄｂ２ｌｕｗ／ｖ８／ｔｏｐｉｃ／ｃｏｍ．ｉｂｍ．ｄｂ２．ｕｄｂ．ｃｃ．ｄｏｃ／ｄｂ２＿ｕｄｂ／ｌｏａｄｔａｂｌｅｕｉ．ｈｔｍ？ｒｅｓｕｌｔｏｌ＝％２２％６７％７２％６１％７０％６８％６９％６３％６１％６Ｃ％２２％２０％２２％６７％７２％６１％７０％６８％６９％６３％２２％２０％２２％６ｄ％６１％７０％７０％６５％７２％２２％２０
ＤＢ２クライアントおよびサーバ（ウィンドウズ）のインストールの要件
ｈｔｔｐ：／／ｐｕｂｌｉｂ．ｂｏｕｌｄｅｒ．ｉｂｍ．ｃｏｍ／ｉｎｆｏｃｅｎｔｅｒ／ｄｂ２ｌｕｗ／ｖ９／ｔｏｐｉｃ／ｃｏｍ．ｉｂｍ．ｄｂ２．ｕｄｂ．ｕｐｒｕｎ．ｄｏｃ／ｄｏｃ／ｒ０００６８６７．ｈｔｍ
【０１１９】
付録Ｂ：頭文字および略語
【表６】
2010530575.tif 000028
【０１２０】
付録Ｃ：ＳＱＬクエリ
ＤＢ２抽出クエリ
ＴＦ１ＥＮＴＩＴＹおよびＴＦ１ＢＵＳＤＥＴ  ＤＢ２テーブル：
【数１５−１】
2010530575.tif 000029
【数１５−２】
2010530575.tif 000030
ＴＦ１ＡＤＤＲ  ＤＢ２テーブル：
【数１６−１】
2010530575.tif 000031
【数１６−２】
2010530575.tif 000032
ＴＦ１ＩＤ  ＤＢ２テーブル：
【数１７】
2010530575.tif 000033
ＴＦ１ＡＣＣＴ  ＤＢ２テーブル：
【数１８−１】
2010530575.tif 000034
【数１８−２】
2010530575.tif 000035
ＴＦ１ＲＥＬＡ  ＤＢ２テーブル：
【数１９】
2010530575.tif 000036
ＴＦ１ＮＡＭＥ  ＤＢ２テーブル：
【数２０】
2010530575.tif 000037
変換のためのＳＱＬ抽出クエリ
テーブルＴＡＸＰＡＹＥＲからテーブルＴＡＸＰＡＹＥＲ＿ＮＥＷへ
【数２１】
2010530575.tif 000038
テーブルＡＤＤＲＥＳＳＥＳからテーブルＡＤＤＲＥＳＳＥＳ＿ＮＥＷへ：
【数２２】
2010530575.tif 000039
テーブルＮＡＭＥＳからテーブルＮＡＭＥＳ＿ＮＥＷへ：
【数２３】
2010530575.tif 000040
テーブルＩＤＥＮＴＩＦＩＣＡＴＩＯＮＳからテーブルＩＤＥＮＴＩＦＩＣＡＴＩＯＮＳ＿ＮＥＷへ：
【数２４】
2010530575.tif 000041
テーブルＡＣＣＯＵＮＴＳからテーブルＡＣＣＯＵＮＴＳ＿ＣＡへ：
【数２５】
2010530575.tif 000042
テーブルＡＣＣＯＵＮＴＳからテーブルＡＣＣＯＵＮＴＳ＿ＣＯへ：
【数２６】
2010530575.tif 000043
テーブルＲＥＬＡＴＩＯＮＳＨＩＰＳからテーブルＲＥＬＡＴＩＯＮＳＨＩＰＳ＿ＮＥＷへ：
【数２７】
2010530575.tif 000044
【０１２１】
付録Ｄ：スクリプトコード
ＣＡおよびＣＯのＴＥＭＰ＿ＩＤの割り当て：契約アカウントおよび契約オブジェクトの固有の番号を作成する
【数２８】
2010530575.tif 000045
日付の変換：日付フィールドから「−」を削除する
【数２９】
2010530575.tif 000046
相手カテゴリの変換：コードマッピングを実行する
【数３０】
2010530575.tif 000047
番地の変換：住所から番地を導く
【数３１】
2010530575.tif 000048
アドレスタイプの変換：コードマッピングを実行する
【数３２】
2010530575.tif 000049
郵便番号の変換：郵便番号から「−」を削除する
【数３３】
2010530575.tif 000050
識別タイプの変換：コードマッピングを実行する
【数３４】
2010530575.tif 000051
アカウントカテゴリの変換：コードマッピングを実行する
【数３５−１】
2010530575.tif 000052
【数３５−２】
2010530575.tif 000053
【数３５−３】
2010530575.tif 000054
【数３５−４】
2010530575.tif 000055
周期性の変換：コードマッピングを実行する
【数３６】
2010530575.tif 000056
相手カテゴリＣＯの変換：コードマッピングを実行する
【数３７】
2010530575.tif 000057
関係の変換：コードマッピングを実行する
【数３８】
2010530575.tif 000058
フラットファイルの作成：人口統計フラットファイルを生成する
【数３９−１】
2010530575.tif 000059
【数３９−２】
2010530575.tif 000060
【数３９−３】
2010530575.tif 000061
【０１２２】
付録Ｅ：ＳＡＰ人口統計構造
人口統計構造は、このファイルが抽出されたのと同じディレクトリにある。
ファイル：
【数４０】
2010530575.tif 000062
【０１２３】
付録Ｆ：典型的なスクリーンショット−データ移行
【０１２４】
ＤＢ２：ＴＦ１ＩＤ
2010530575.tif 000063
【０１２５】
ＤＢ２：ＴＦ１ＮＡＭＥ
2010530575.tif 000064
【０１２６】
ＤＢ２：ＴＦ１ＡＤＤＲ
2010530575.tif 000065
【０１２７】
ＳＱＬ：ＩＤＥＮＴＩＦＩＣＡＴＩＯＮＳ
2010530575.tif 000066
【０１２８】
ＳＱＬ：ＮＡＭＥＳ
2010530575.tif 000067
【０１２９】
ＳＱＬ：ＡＤＤＲＥＳＳＥＳ
2010530575.tif 000068
【０１３０】
ＦＬＡＴＦＩＬＥ：ＴＡＸＰＡＹＥＲ
2010530575.tif 000069
【０１３１】
ＥＭＩＧＡＬＬ：ＴＡＸＰＡＹＥＲ
2010530575.tif 000070
【０１３２】
ＳＡＰ：ＮＡＭＥ
2010530575.tif 000071
【０１３３】
ＳＡＰ：ＡＤＤＲＥＳＳ
2010530575.tif 000072
【０１３４】
ＳＡＰ：ＩＤＥＮＴＩＦＩＣＡＴＩＯＮ
2010530575.tif 000073
【図１】
2010530575.tif 000074
【図２】
2010530575.tif 000075
【図３】
2010530575.tif 000076
【図４】
2010530575.tif 000077
【図５】
2010530575.tif 000078
【図６】
2010530575.tif 000079
【図７】
2010530575.tif 000080
【図８】
2010530575.tif 000081
【図９】
2010530575.tif 000082
【図１０】
2010530575.tif 000083
【図１１】
2010530575.tif 000084
【図１２】
2010530575.tif 000085
【図１３】
2010530575.tif 000086
【図１４】
2010530575.tif 000087
【国際調査報告】
2010530575.tif 000088
2010530575.tif 000089
2010530575.tif 000090