はじめに
今日のアプリケーション･ユーザーの間では、ユーザー･エクスペリエンスの一環としてリアルタイム･インテリジェンスの必要性が増して
きています。さまざまな集計情報を探す必要なく、必要なときに必要な場所でキー・パフォーマンス・インディケータ（KPI）と共にリアルタイムで使用でき
ることが求められています。 通常、銀行の窓口係の処理トランザクションでは、接客の際にリアルタイム･インテリジェンスが必要とされます。
このリアルタイム・インテリジェンスの情報がないと、窓口係は節約や投資パターンの変更について適切なアドバイスができず、新しい情報に基づいて行動する
ようアドバイスすることができません。 これでは、新しい製品やサービスのクロスセルおよびアップセルの機会が失われてしまいます。
窓口係が最新の投資信託金利、顧客の投資パターン、顧客の投資に対する健全性におけるリアルタイム･インテリジェンスを備えていれば、たとえば、低金利の
アカウントからパフォーマンスの良い短期のマネー･マーケット･アカウントに資金を移すように顧客にアドバイスすることができます。
ただし、インテリジェンスだけでは十分ではありません。
インテリジェンスが整ったら、次に取り組むべき課題はアクセシビリティです。 ユーザーはどのようにしてこの機密データにアクセスするのでしょうか。
従来は、印刷されたレポートなど、多数の方法が使用されてきました。
従来のアプリケーションでは、データ入力機能やデータ管理機能は、レポート作成機能や分析機能とは常に分離されています。
それらは2つの異なるアプリケーション、2つの異なる情報ポータル、または2つの異なるテクノロジーによって処理されています。
あらゆる情報ワーカーが意思決定者としての権限を持ち、主要なボトルネックを事前に除外するEnterprise
2.0（E2.0）の環境を想像してみてください。
このシナリオでは、情報は金のように扱われ、ユーザーは必要なときに必要な場所で情報を入手できます。
なぜ、ビジネスクリティカルな分析情報は異なる方法で処理される必要があるのでしょうか。
ユーザーは、トランザクションのより適切な作成および管理に役立つ履歴またはリアルタイムのビジネス･インテリジェンス（BI）を常に必要としています。
BIとE2.0を組み合わせると、情報管理と分析を同一のコンテキストおよびトランザクションで組み合わせることができます。
この記事では、コンテキストに基づくリアルタイムのビジネス･インサイトに向けたリファレンス･アーキテクチャを取り上げます。
高品質の整形機器の主要グローバル･プロバイダであるDJOの例を通じて、Oracle WebCenter、Oracle Business
Activity Monitoring、およびOracle Coherenceの使用によって成功を収めた実例について説明します。
リアルタイム･インテリジェンスとは
では、リアルタイムBIとは何でしょうか。
これを理解するために、エンタープライズ内のBIを3つの異なるカテゴリに分類してみましょう。
- 履歴インテリジェンス：数年または数か月にわたって集計され、通常はデータウェアハウス環境に保存される情報。
レポートは、数分または数時間にわたって実行され、大量のデータを収集して詳細なインテリジェンスが生成されます。
- ほぼリアルタイムのインテリジェンス：ここ数週間または数日間にわたって集計され、通常はトランザクション･データベースに保存
されるデータ。 情報は、トランザクション･アプリケーションに近いレポート作成ツールによって生成されます。
- リアルタイム･インテリジェンス：ここ数時間または数日にわたるデータを集計し、通常は高速アクセス向けメモリに保存される情
報。 情報は分析エンジンによって生成され、短期の重要性または関連性が含まれます。
リアルタイム･インテリジェンスの必要性はますます重要度を増しています。従来のERPアプリケーションおよび独自のポータルは、ほと
んど注文の作成、顧客情報の管理、財務情報の更新などのトランザクションに重点を置いているためです。
トランザクションをデータ管理の点から見ていた時期は過ぎました。 プロセスを全体として見る必要があります。
トランザクション中に顧客情報および財務情報を更新しながら注文を作成できることが重要です。
企業は、マルチステップのトランザクション･プロセスを回避するために、ユーザーをプロセス全体の意思決定者にしようとしています。
このプラクティスを採用する企業が増えれば増えるほど、リアルタイム･インテリジェンスはあらゆる意思決定プロセスの鍵となります。
コンテキストを基にしたリアルタイムBIアプリケーションの構築には、4つの主要なテクノロジーを組み合わせることが求められます。
図1に示すように、Web
2.0フレームワーク、ビジネス・アクティビティ監視（BAM）、グリッド･キャッシングおよびサービス指向アーキテクチャ（SOA）の4つです。
図1：リアルタイムBIアプリケーションの構築ブロック
- Web 2.0ポータル：コンテンツ、プレゼンスおよびソーシャル･ネットワーキング機能を
提供し、高度にインタラクティブなユーザー・エクスペリエンスを作成します。
エンド･ユーザーは、このポータルを使用してリアルタイム･ビジネス･アクティビティを把握します。
- ビジネス･アクティビティ監視：アプリケーションはビジネス･アクティビティ中に発生する主
要なイベントを取得できます。 これらの主要なイベントは、理解しやすいKPIでは、Web 2.0ポータルを経由して集計、分析、表示されます。
BAMは、BIによって使用されるダッシュボードとは異なる点に注意してください。
BAMがリアルタイムまたはほぼリアルタイムでイベントを処理するのに対し、BIは履歴インテリジェンスを提供します。
- グリッド･キャッシング：データ･グリッド･キャッシングは、非動的イベントをメモリに
キャッシュすることにより、アプリケーションのパフォーマンスを向上させます。 これにより、Web
2.0ポータルが比較的静的なデータのためにBAM/SOAレイヤーと通信する必要がなくなり、卓越したパフォーマンスおよびスケーラビリティが実現しま
す。
- サービス指向アーキテクチャ：このレイヤーは、BAMレイヤーと共にイベント駆動型アーキテ
クチャのプラットフォームを提供します。
SOAは、さまざまなエンタープライズ･アプリケーションと統合することにより、主要なビジネス･プロセスを調整する役割を担います。
プロセスの実行中、トリガーされたイベントをBAMレイヤーによって取得できるか、または受信イベントで発生したトリガーによってサービスをアクティブ化
できます。 SOAとBAMの統合は、通常はJava Message Service（JMS）を通じて行われます。
次の項では、リファレンス・アーキテクチャを取り上げ、コンテキストに基づいたリアルタイム･インテリジェンス･アプリケーションを構
築する方法について説明します。
リファレンス･アーキテクチャ
前に説明したように、このアプリケーションでは、Web
2.0ポータル、SOA、BAMおよびグリッド・キャッシング･ソリューション間の統合が必要とされます（図2を参照）。
図2：リアルタイムBIアーキテクチャ
処理順序には、6つのステップがあります。
- イベントの生成およびプロセスの調整：分析を必要とするすべてのプロセス･アクティビティは、疎結合の調整プロセスを通してモデ
ル化されます。 これは、必要に応じてアプリケーション･イベントの一部として取得されたパターンおよび情報を効率的に変化させる際に役立ちます。
ここで、Oracle BPEL Process Manager（Oracle BPEL
PM）は、ユーザーによるスタンダードベース（BPEL）のモデル化を可能にすることで役立ちます。 Oracle BPEL
PMを使用することにより、アナリストはアクティビティ･センサーを追加してBPELプロセス内のアクティビティの実行を監視したり、フォルト・センサー
を追加して障害を検出したりできます。
このステップ中に、プロセス･オーケストレーション･レイヤーによってさまざまなイベントが生成されます。これらのイベントは、JMSまたは同様の手段お
よびエンタープライズ･サービス･バス（ESB）を通じて渡されます。
- イベントの検出および統合：JMSバスは、プロセスを通じてイベントをBAMエンジンへ転送する手段を提供します。
JMSメッセージ･キューにより、複数のエンドポイント･システムによるビジネス生成イベントの消費が可能になります。
- 処理とフィルタリング：取得されたイベントにはすべて、フィルタリング、相関、分析が行われ、重要なKPIおよび品質保証契約
（SLA）への影響が測定されます。 エンドユーザーは、新規の関連情報がある場合に通知されます。
BAMエンジンは、ユーザーが確認している間、アクティブ･レポートを更新し続けます。
これらの更新は、ユーザーがレポートをクローズするまで続きます。
- リアルタイムの可用性：通常、BAMエンジンは、組込みデータ･キャッシュに付随します。
ただし、大規模なエンタープライズ・ソリューションでは、速度とスケーラビリティの間にトレードオフは存在しません。
この状況では、インメモリ･データ･キャッシング・ソリューションにより、大幅にアプリケーション･パフォーマンスが向上します。
このステップの間、データ変更の頻度に基づいてデータ･グリッド･キャッシュはリフレッシュされ、Web
2.0ポータルからの後続リクエストがキャッシュによって処理されます。 Oracle
Coherenceは、インメモリ・データ･グリッド･レイヤーを通じてこの機能を提供します。また、そこでは1TBのデータをキャッシュできます。
このアプローチにより、アプリケーション･パフォーマンスが向上するだけでなく、アプリケーションのハードウェアへの集中度を緩和します。
- 表示と可視化：このステップの間、ユーザーには視覚的に強化された情報が表示されます。
開発者は、宣言的なフレームワークを使用して動的データ･オブジェクトをモデル化し、基礎になるインテリジェンスを取得できます。 Oracle
Application Development Framework Data Visualization（Oracle ADF
DVT）コンポーネントは、充実したインタラクティブなOracle ADF
Facesコンポーネントのセットで、データを可視化および解析するためにグラフまたは表形式で表示する機能を提供します。
- ユーザー･インタラクションとパーソナライズ：Web 2.0ポータル（Oracle
WebCenter）により、ユーザーはパーソナライズされたダッシュボードへさまざまな情報を集計できます。
BAMチャート、ビジネス･プロセスのワークフロー･アクティビティ、KPIを調整するインタフェース、およびルールとフィルタを定義する機能はすべて1
つの画面に表示されます。
統合およびランタイム・カスタマイズ・オプションを追加で提供することにより、エンドユーザーの元で直接制御され、エンドユーザーが望む方法でデータを詳
細に分析できます。
図3に6つのステップをすべて表示します。
図3：リアルタイムBIへの6つのステップ
ここまで、リファレンス･アーキテクチャと、そのアプリケーションを構築するための6つのステップについて説明しました。次に、同様の
アプリケーションをDJO Globalで実装する実例について見てみましょう。
DJOにおけるリアルタイム・コール・センター・アプリケーションの構築
DJ
Orthopedics（DJO）は、カリフォルニア州ビスタに本社を置く企業です。急性および慢性の整形外科的脊髄疾患の予防、処置、リハビリテーショ
ンを対象とした技術的にも高度な製品およびサービスを設計、生産し、卸しています。
DJOは、リインバースメント・ビジネスの一環として、アメリカ合衆国全域の個人および政府の保険金請求を処理するコール･センターを運営しています。
このコール･センターでは、患者への医療器具の供給や、保険会社との請求処理も行います。
診療所や患者は、重要な医療情報を保険会社との手続きの一部として提供します。
コール･センターは、電子データ交換（EDI）トランザクションを通じて、医療保険プロバイダと通信します。
顧客や注文に関する情報は、カスタム･データベース、サード・パーティのシステムおよびOracle E-Business
Suiteに配布されます。 ただし、この構成では、コール･センター･エージェントはリアルタイムに集計された顧客情報にアクセスできませんでした。
請求処理に関わるエージェントの仕事では、特定の請求と関連する日次または週次のコール･アクティビティをリアルタイムで参照すること
が必要です。
コール･センター･マネージャは、請求処理、傾向の把握およびキャッシュ･フロー処理をリアルタイムで実行するために、リアルタイムの予測と負荷分散を必
要とします。
DJOは、必要な情報へアクセスするために、コール･センターのユーザー･インタラクションをサポートし、以下に関するリアルタイムの
情報を表示するようなリアルタイムBIアプリケーションの構築を決断しました。
- コール･アクティビティ
- 注文アクティビティ
- 財務アクティビティ
- 個人生産性目標
アーキテクチャ
DJO Globalは、このソリューションを構築するために、Oracle ADF、Oracle
Coherence、Oracle BPEL PM、およびOracle
BAMの組合せを選択し（図4参照）、注文管理、契約管理、フルフィルメント、出荷から、財務と受注から入金に至るまで、すべてのプロセスを提供するため
にOracle E-Business Suiteを中心に置きました。
図4：コール･センターのリアルタイム･インサイト･アプリケーション
請求書の照合に関するDJOのユースケースを使用して、これらのアーキテクチャの内容を見てみましょう。
DJOは、患者からの請求すべてを保険プロバイダに基づいて整理し、払戻しのために請求書を保険会社へ送信します。
これら外部のトランザクションは、Oracle Service-Oriented Architecture Suite（Oracle SOA
Suite）を通じてB2Bプロセスでサポートされます。
保険会社は直接銀行に支払い、銀行はEDIファイルを支払いの説明と共にDJOへ返送します。
この情報は、保険会社に送信された元の情報と照合し、支払い記録を確認して承認する必要があります。
情報が照合できない場合、DJOは、さまざまな理由で支払われない記録を処理します。
場合によっては、数か月前から保留状態のトランザクションがまだ支払い待ちであることがあります。
新しいファイルを受信したり、新しい請求が解決したりしたときは、リアルタイム･インテリジェンスが必要となります。
今日処理された記録、払戻しの全送信記録、すべての入金、および保留状態の照合をリアルタイムで参照できることが必要です。
この照合に関連して、以下の複数のステップが発生します。
- 元のソース･レコードが取得されます。
- ソース･レコードが保険会社へ送信されます。
- 新規の支払いが受信され照合されます。
- エージェントは、患者とやり取りすることで、処理を進めて完了させる必要があるという通知を受けます。
- 保険会社が支払いを実行した場合、情報はARで完了し、受領書が承認される必要があります。
ここで、コール･センターのエージェントと請求書のエージェントが共に参照し、協力、処理および修正を行えるリアルタイムのダッシュ
ボードが必要になります。
| 設計の目標 |
ソリューション・アプローチ |
| コール･センター･エージェントおよび請求エージェントは、請求
書および注文アクティビティを確認するための視覚的に豊富なダッシュボードが必要。 |
Oracle ADF DVTを可視化に利用 |
| 照合情報は、リクエスト時にすぐに参照できることが必要
（1,000トランザクション/秒が理想） |
Oracle
Coherenceがインメモリ･データ･グリッドとして動作し、データを収集および表示 |
| 新しい照合情報が入るとすぐにダッシュボードを更新することが必
要。 エージェントは、さまざまなフォーマット（チャート、グラフ）でデータを分析できることが必要 |
Oracle BAM |
| 注文データおよび請求書データの統合プロセスを自動化することが
必要。 プロセスおよびポリシーは、新しい医療規制に簡単に適応できることが必要 |
Oracle BPEL PMで管理されるOracle
SOA Suiteの一部のBPELエンジン |
請求書照合のユースケースにおいて、すべての部分がどのように組み合わさっているかが分かりました。次に、前に説明した6つのステップ
を見ていきましょう。
- イベント生成およびプロセス･ステップ
新しい請求書照合データを受信してすぐに、Oracle E-Business Suiteは新しいイベントを開始します。 Oracle
E-Business Suite製品の多くは、ビジネス・プロセスの統合にOracle
Workflowのビジネス・イベント・システムを使用しています。 Oracle E-Business
Suiteをビジネス・プロセスに統合する方法は他にもありますが、この方法では、Oracle E-Business
Suiteの標準機能を使用してイベント駆動型のESBプロセスやBPELプロセスを構築できます。
Oracle E-Business Suiteは、リアルタイムのデータを"請求書監視"BPELプロセスへ送信します。 請求書スキーマ（XML
Schema Definition、またはXSD）が、Oracle E-Business
Suiteからのデータ検証のテンプレートとして作成されます。
図5：検証用請求書スキーマ（XSD）
請求書XSDを利用して、Oracle E-Business Suiteイベントは、編成のためにデータを請求書監視BPELプロセスに送信します。
- イベントの検出および統合
請求書監視BPELプロセスは、Oracle E-Business Suiteから請求書照合を受け取って拡充し、BAMレイヤーに送信します。
図6および図7は、請求書監視プロセスの2つのビューを示しています。 図6は、BPELプロセスのService Component
Architecture（SCA）ビューです。図7はプロセスの従来のビューで、データの変換とBAMへの送信方法を示しています。
図6：BAMへの情報を編成するBPELプロセスを示すSCA
図7：データを変換および保存するBPEL編成
- このシナリオでは、Oracle BPEL PMはOracle BAM Webサービスを使用してOracle BAMと統合します。
これは、JMSバスで情報を送信することによっても実行できます。Oracle BAM Webサービスを使用すると、ユーザーはデータをOracle
BAMサーバーに公開してリアルタイムのチャートおよびダッシュボードでの使用を可能にするアプリケーションを構築できます。
標準Webサービスに接続できるクライアントはすべて、これらのAPIを使用してOracle BAMにデータを公開できます。
このケースでは、Oracle BAMサーバーのデータ･オブジェクトは、ICommand Webサービスにより、Oracle BAM
Webサービスを使用して入手できます。 ICommand Webサービス･パートナー･リンクは、図8に示すように構成されます。
-
図8：iCommandサービスのBAMへの構成例
- BPELがこのデータをBAMサーバーへ公開すると、データは処理およびフィルタリングされます。
- 処理とフィルタリング
Oracle
BAMは、請求書照合データをBPELプロセスから受信し、このデータを請求書データ･オブジェクトのサポートでBAMダッシュボードに表示します。
請求書データ･オブジェクトは、表示、分析、警告などのためにBAMに取得されたビジネス･データを反映します。
請求書監視BPELプロセスの実行後、ICommand Webサービス･コールによって請求書データ･オブジェクトが移入されます。
図9は、請求書データ･オブジェクトおよび移入されたデータの定義を示しています。
図9：BAMにおける請求書データ･オブジェクト定義
- フィルタは、データのサブセットの制限や必要なビジネス情報の表示に役立ちます。
フィルタは、特定のKPIまたはSLAを定義し、これらの基準を満たす（または満たさない）コンテンツを表示するためにも使用できます。
図10では、1週間以上前の請求書照合データのみがダッシュボードに表示されるようにデータがフィルタリングされています。
-
図10：1週間以上前の請求書データを表示させるフィルタリング･ルール
- データが保存されてフィルタリングされると、処理済みの情報はBAMダッシュボードにライブで表示されます。 Oracle BAM
Architectプロセスにより、チャートを設定し、ダッシュボードにデータを表示する方法が示されます。
-
図11：BAMダッシュボードに表示されるフィルタリング済みの情報
- ただし、BAMダッシュボードは、請求書エージェントおよびコール･センター･エージェントにとっては不十分です。
エージェントは、この情報を患者や保険会社との処理を行うのと同じダッシュボード内に表示させることを望んでいます。
そこで、次のステップでは、この情報をダッシュボード全体に統合する必要があります。
- リアルタイムの可用性
次のステップでは、Oracle Coherenceの重要なBAMデータを最終的にOracle
ADFのユーザー･インタフェースに表示できるようにキャッシュします。 それでは、これがどのように行われるかを見てみましょう。
スケジュールされたStore Invoices
BPELプロセスにより、BAMからデータを取得し、Oracleデータベース表に送信します（図12）。
-
図12：最終的にOracle
Coherenceによってキャッシュされるデータベースの請求書データを保存するStore Invoicesプロセス
それから、Store Invoices
BPELプロセスは、XSL変換を使用して、Invoices.xmlファイルにあるすべての請求書のコンテンツで構成されるコレクション･オブジェクト
を準備します。 最後に、Store Invoices
BPELプロセスは、生成されたコレクション･オブジェクトを渡すことによってPL/SQLプロシージャを呼び出します。
PL/SQLプロシージャは、データをInvoicesデータベース表に保存します。
既存のレコードを更新します。また、レコードが存在しない場合は新しいレコードを作成します。
次のステップでは、Oracle Coherenceキャッシュを構成して、このデータ･ストアをアプリケーションに反映させます。 Oracle
JDeveloperでアプリケーションを構成することにより、アプリケーションはOracle Coherenceと統合されます。 Oracle
JDeveloperでは、ワークスペース定義を含むOracle Coherenceキャッシュ構成ファイルを参照します。
-
図13：Oracle JDeveloperにおけるOracle Coherenceの構成
以下の行をADFアプリケーションのJava構成へ追加します。
- Dtangosol.coherence.distributed.localstorage=false
- Dtangosol.coherence.log.level=3
- Dtangosol.coherence.cacheconfig=[ConfigLocation]\invoice-cache-config.xml
詳細は、『Oracle
JDeveloperを使用したOracle Coherenceキャッシュの作成』を参照してください。
- 表示と可視化
ここで、キャッシュで使用可能な情報を利用して、Webアプリケーション上で情報をレンダリングする準備ができました。
Oracle Coherenceでレンダリングされたイベント情報の可視化を強化するには、Oracle ADF
11gの一部として入手できるOracle ADF DVTコンポーネントを利用します。 Oracle
ADFのDVTコンポーネントは、棒グラフ、ゲージ、 ガント･チャート、地図など、データのグラフィック表示の構築に使用できます。
DVTコンポーネントの最適な機能は、Oracle ADF
11g内のモデルビューコントローラ･パターンの一部としてキャッシュをモデル･レイヤーにラップできる宣言的モデルです。
このモデルは、ビュー･オブジェクトがOracle Coherenceキャッシュから取得されたリアルタイム･データを保存するのに役立ちます。
-
図14：Oracle ADF 11g DVTと統合し、タスク･フローにラップされるOracle
Coherenceデータ
- これらのチャートは、ポータルまたはアプリケーション内の再利用可能なユーザー･インタフェース･コンポーネントとしてADFタスク･フローにラップされ
ます。 タスク･フロー･コンポーネントは、Oracle WebCenterのBusiness Dictionary機能でも使用できます。
- ユーザー･インタラクションとパーソナライズ
次に、ユーザーがデータと通信してパーソナライズし、情報の可視性を制御するために、どのようにしてこれらのコンポーネントを使用できるのかを見てみま
しょう。
図15のダッシュボードは、アプリケーション全体のビューを表示しています。
請求書エージェントとコール･センター・エージェントは、異なるKPI（ワーク･リスト、注文、患者の詳細、支払人、患者のメモ、医師の詳細）が統合され
ているパーソナライズされたビューを取得します。 結果として、顧客のビューが一元化され、顧客とインテリジェントな議論をする機会ができます。
-
図15：Oracle ADF
11gのBAMグラフなどのダッシュボード･ビューのレンダリング（グラフ･レンダリング向けのサンプル･データ）
結論
BIとE2.0を組み合わせると、情報管理と分析を同一のコンテキストおよびトランザクションで組み合わせることができます。
このソリューションは、複雑なイベント処理をオンライン分析処理と組み合わせて機能を拡張し、ビジネス･インテリジェンスを活用するアーキテクチャに簡単
に進化させることができます。
.
謝辞
Kesteでソリューションをリードしている、Gana DuraiswamyとSandeep
Reddyに感謝します。ソリューションを統合し、実現させてくれた方々です。
 |
Mark Farabaughは、
カリフォルニア州ビスタに居を置くDJOのIT担当副社長です。レガシーERPアプリケーションをすべてOracle Enterprise
Business Suite Release
12のグローバル･シングル･インスタンスへ統合するという、DJOの複数年にわたるプログラムを指揮しています。
ITプロフェッショナルとして20年以上の経験を持ち、ERP、BI、CRM、FP&AなどのOracleエンタープライズ･アプリケーションを
大規模な多国籍企業に実装することに重点を置いてきました。 |
 |
Sri Ayyeppenは、
Oracle Platinum Technology
PartnerであるKesteの共同創立者でCTOです。オラクルのアプリケーション、テクノロジー、インフラストラクチャを用いて複雑なソリューショ
ンを提供するチームを率いる責任者です。 2010年、オラクルのDeputy CTOの1人に認定されました。 |
 |
Harish Gaurは、
オラクルのFusion Middleware部門のDirector of Product Managementです。 Oracle
SOAテクノロジーを使用してサービス指向アーキテクチャを実装する戦略的顧客と密接に関わります。 Harishは、Packt Press『The BPEL Cookbook』の共同執
筆者です。 |
|
Articles
Printer View