特定業界向けのビジネス・アクティビティー・モニタリング

WebSphere Business Monitor と WebSphere Business Services Fabric Industry Content Packs を統合した使用事例

WebSphere Business Services Fabric Industry Content Packs には、WebSphere Business Monitor と Fabric の統合、および Monitor ダッシュボードの新機能を紹介する、特定業界向けのサンプルが含まれています。この記事では、Industry Content Packs に含まれている保険、医療、製品ライフサイクル管理のサンプルに対するビジネス・モニタリング・ソリューションについて説明します。

Jiang Lu (lujjiang@cn.ibm.com), Software Engineer, IBM

Jiang Lu photoJiang Lu は IBM China の WebSphere Business Monitor 開発チームのソフトウェア・エンジニアです。彼女は保険、医療、製品ライフサイクル管理といった業界向けのモニター・モデルの開発を経験してきています。



Wilfred Jamison, Ph.D., Senior Technical Manager, IBM

Dr. Wilfred C. JamisonDr. Wilfred C. Jamison はIBM Research Traiangle LabのWebSphere Bsuiness Monitor 開発チームのシニアテクニカルマネージャーで、現在、ビジネス・パフォーマンス管理の多くのプロジェクトに加わっています。



Yuan Zhao, Software Engineer, IBM

Yuan Zhao photoYuan Zhao は IBM China の WebSphere Business Monitor チームのソフトウェア・エンジニアです。彼は WebSphere Business Monitor の開発やテスト、業界サンプルの開発を経験してきています。



2010年 2月 07日

はじめに

WebSphere Business Services Fabric Industry Content Packs (以下 Fabric ICP) は、ビジネス・プロセス管理 (BPM) 用に事前に作成された一連のアクセラレーター・アセットです。Fabric ICP は、医療、保険、製品ライフサイクル管理、通信、銀行など、一連の業界をサポートしています。この記事では、WebSphere Business Monitor (以下 Monitor) を使用して Fabric ICP のビジネス・アクティビティー・モニタリング機能を補完するために私達が行った作業の成果について説明します。私達の作業から得られたアセットや成果物も ICP に同梱されています。そうしたアセットや成果物により、上記の特定業界用のモニタリング・ソリューションの、より迅速な開発が可能になることを目指しています。

ここで紹介する各サンプルは業界標準や注目点が異なりますが、いずれの場合も Fabric ランタイムから出力されるビジネス・イベントを収集して関連のある情報を抽出し、必要なパフォーマンス・メトリックを計算したうえで各業界向けのダッシュボード上に表示する、という共通の目的を持ちます。

またこの記事では、私達が保険 (Insurance)、医療 (Healthcare)、製品ライフサイクル管理 (Product Lifecycle Management: PLM) 業界用に設計したダッシュボードについても説明します。


保険業界における BAM (ビジネス・アクティビティー・モニタリング)

保険業界は世界経済の中で最も急速に発展している業界の 1 つです。保険業界は主に、保険会社と保険代理店、保険仲介業者で構成されています。一般的に、保険会社は保険を提供する大企業であり、保険商品によってカバーされるリスクを負担します。保険代理店と保険仲介業者は保険会社に代わって保険商品を販売します。

Insurance P&C (Property and Casualty: 損害保険) コンテンツ・パックは Claim Summary (請求サマリー) ビジネス・プロセスのリファレンス実装です (図 1)。このパックには、既存の保険商品所有者に関する情報のスナップショットが含まれています。保険会社は、このエコシステムのパートナーである代理店、仲介業者、顧客、再保険会社、銀行、請求査定業者などとやり取りします。保険会社は ACORD (Association for Cooperative Operations Research and Development: 保険業界の情報交換技術普及推進団体) のトランザクション・リクエストをサービスに送信し、そのサービスは保険請求 ID を基に、保険商品と関連付けられた保険金支払いデータを返します。

図 1. Claim Summary (請求サマリー) ビジネス・プロセス

この Insurance P&C Claim Summary プロセス (図 1) では、受信した請求は Claim Summary ACORD Gateway プロセスに送信されます。請求リクエストは受け付けられ、そして評価されます。最後に、このプロセスが請求ステータスと請求額を提供します。Claim Summary ビジネス・プロセスには、下記の 3 つのステージがあります。

  1. 最初に、さまざまなチャネルを経由してパートナーが保険会社のシステムにアクセスします。
  2. 2 番目に、保険代理店または顧客が、請求サマリー取得のための適切な詳細事項を含んだ ACORD メッセージを送信します。
  3. 3 番目に、さまざまなパートナーが保険会社とやりとりできるように、保険会社は標準化された保険ゲートウェイを持つ必要があります。このゲートウェイを使うことで、パートナーは多様な保険商品や請求などに関する情報の追加、変更、照会を行うことができます。Claim Summary に対して保険ゲートウェイを介して ACORD メッセージを送信すると、その文書は、ACORD サインオン処理、ACORD 検証処理、ACORD 拒否修復処理、そして何らかの Claim Summary ビジネス・サービス処理をとおり、プロバイダーにレスポンスを返します。

場合によると、追加情報として、請求総数、地理的な場所ごとの重要なパフォーマンス情報 (例えば米国の各州での支払い総額と請求状態) などを要求されるかもしれません。こうした種類の情報は Monitor のダッシュボードを使って容易に表示することができます。下記は私達が Insurance P&C コンテンツ・パック用に開発したダッシュボードのスクリーンショットです。Monitor V6.2 では、ダッシュボードが WebSphere の Business Space 上で実行されることに注意してください。

図 2 は Claim Summary ビジネス・プロセスに対する Monitor ダッシュボードのメイン・ページを示しています。この (My Business という名前の) メイン・ページは Claim Summary プロセスのパフォーマンスが現在どんな状態にあるかの概略を示しています。考え方としては、ビジネス・ユーザーにとって最も重要なパフォーマンス・データをメイン・ページに表示しています。

米国の地図の表示には、ダイアグラム・ウィジェットが使われています (左上)。各州の請求総数は背景色を付けて表示されます。Monitor の開発ツールキットに付属しているエディターを使用すると、SVG 図を編集してダイアグラム・ウィジェットの中に表示することができます。またこのメイン・ページには、いくつかの KPI (Key Performance Indicator) が、棒グラフ形式 (左下) と円グラフ形式 (右上) の両方で表示されています。事前定義された KPI の他に、別の KPI を追加して定義することもできます。モニター・モデル・エディターを使って、またはダッシュボードから直接、ターゲットとステータスを設定することができます。

図 2. Insurance サンプルの Business Space

クリックして大きなイメージを見る

図 2. Insurance サンプルの Business Space

ダッシュボードのもう 1 つのページが Analysis (分析) ページです。Analysis ページはビジネス・ユーザーに対し、ビジネスのパフォーマンスに関する詳細な情報を表示します。ユーザーは、現在のパフォーマンス状況に影響しているのは何かを、概要レベルから掘り下げて調べることができます。図 3 は請求サマリーの内訳を自動車保険、住宅保険、アンブレラ保険に分けて表示しています (左上)。また、処理が終了した請求の割合が過去数カ月間または 1 年間でどの程度かを表示することができます (右上)。Monitor には、円グラフ、棒グラフ (下)、折れ線グラフ (図 4) など、多数のグラフ形式があります。

図 3. Insurance サンプルの Analysis ページ

クリックして大きなイメージを見る

図 3. Insurance サンプルの Analysis ページ

図 4. Insurance サンプルの Report ページ

クリックして大きなイメージを見る

図 4. Insurance サンプルの Report ページ


医療業界における BAM

Healthcare コンテンツ・パックは Benefits and Eligibility Inquiry (給付および適格性照会) ビジネス・プロセスのリファレンス実装です。このパックには既存の健康保険商品所有者に関する情報のスナップショットが含まれています。

給付および適格性トランザクションは、健康保険、雇用主、保険負担者、保険加入者およびその被扶養者に関連付けられた、受給資格、保険対象範囲、あるいは保険給付内容の照会に使われる、電子的なトランザクションです。HIPAA (Health Insurance Portability and Accountability Act) で義務付けられた ANSI 270 (Eligibility and Benefit Request: 適格性および給付リクエスト) と ANSI 271 (Eligibility and Benefit Response: 適格性および給付レスポンス) は、給付トランザクションと適格性トランザクションに使われる 2 種類のトランザクションです。270 トランザクションは情報を要求 (照会) し、271 トランザクションは補償範囲情報、適格性情報、給付情報で応答します。この 2 つのトランザクションによって、医療情報システムのメンバーである医療サービス・プロバイダーに顧客の適格性と請求状態を提供します。

図 5 は Benefits and Eligibility Inquiry ビジネス・プロセスを示しています。このプロセスには、医療サービス・プロバイダーが送信した HIPAA ANSI 270 トランザクション・リクエストを受信するサービスがあります。このサービスは患者の給付および適格性ステータスに関する基本データを返します。このデータは HIPAA ANSI 271 に準拠しています。HIPAA 270 メッセージも HIPAA 271 メッセージも、EDI (Electronic Data Interchange: 電子データ交換) 標準フォーマットを使って作成されています。

図 5. Benefits and Eligibility Inquiry ビジネス・プロセス

クリックして大きなイメージを見る

図 5. Benefits and Eligibility Inquiry ビジネス・プロセス

以下は Benefits and Eligibility Inquiry ビジネス・プロセスの概要です。

  1. HIPAA リクエストは検証を受けるために EDI 基本検証サービスに送信されます。医療サービス・プロバイダーは、プロバイダー用ポータル、コール・センター、ファックス、またはバッチ送信により、適格性判断を要求します。このトランザクションは、リアルタイム送信やバッチ送信などの多様な形式でプロバイダーから送信されます。
  2. リクエストが有効な場合には、そのメッセージは EDI Unbundling Basic Service によって分解され、いくつかの HIPAA メッセージが作成されます。各メッセージは HIPAA270 に準拠しているかどうか検証されます。
  3. その保険商品の情報が HIPAA270 メッセージから抽出されます。
  4. バックエンド・システムによって HIPAA271 メッセージが作成されます。
  5. 最後に、その HIPAA271 メッセージはバンドル処理され、検証された後、EDI ゲートウェイ経由で呼び出し側クライアントに送信されます。

医療業界のビジネス・リーダー達から最もよく要求される機能の 1 つは、一定期間内のトランザクション数の追跡機能です。有用な情報としては、受け付けられた HIPAA リクエストの割合や拒否された HIPAA リクエストの割合などがあります。私たちの実装では、関心対象となるビジネス・パフォーマンス情報を特定し、次に、それらに関連する情報をすべてのメッセージから抽出し、そのビジネス・パフォーマンス情報を取得しました。

Monitor には、そうした要件に対応する機能として、KPI ウィジェット、アラート・ウィジェット、ダイアグラム・ウィジェット、ディメンション・ウィジェット、レポート・ウィジェット、インスタンス・ウィジェットなどが用意されています。

HIPAA 270 メッセージも HIPAA 271 メッセージも EDI 標準フォーマットを使ってエンコードされているため、これらのメッセージをデコードし、メッセージから対象の情報を取得するための手段が必要でした。この課題に対し、私達は UDXF (User-Defined XPath functions: ユーザー定義 XPath 関数) を使って対応しました。

UDXF は Monitor V6.1 で導入されました (「Put new capabilities of business activity monitoring (BAM) to work, Part 7: Creating user-defined XPath functions for IBM WebSphere Business Monitor V6.1」を参照)。UDXF を使うことでモニターのプログラミング・モデルを拡張することができ、特に、モニター・モデルに処理ロジックやデータ処理機能、データ取得機能を追加することができます。私達は HIPAA 標準メッセージのデコードと構文解析のための UDXF を作成し、このサンプルの成果物の一部として提供しています。

必要な情報をメッセージから取得すると、その情報から得られたパフォーマンス情報が、さまざまなウィジェットを使って Monitor のダッシュボードに表示されます。下記は医療業界用ダッシュボードのスナップショットをいくつか示したものです。図 6 はこのダッシュボードのメイン・ページです。このページには米国の地図が 表示され、送信されたリクエストの総数がしきい値を超えているかどうかを 2 色で示しています (例えばニューヨーク州が緑色であることは、今月ニューヨーク州で送信されたリクエストの総数がしきい値を下回っていることを意味しています)。またこのページには円グラフが 1 つ表示され、全リクエストのうち各州のリクエストが占める割合を示しています。このダッシュボードには、Average elapsed time of benefits and eligibility transaction (給付および適格性トランザクションの平均所要時間)、Total accepted requests (受け付けられたリクエストの割合)、Percentage of rejected requests (拒否されたリクエストの割合) など、いくつかの KPI も含まれています。また、アクションが必要な重要な状況を通知するための、アラート・ビューが含まれています。このメイン・ページを見ることで、米国のどの州のリクエスト総数がしきい値を超えているのか、容易に検出することができます。

図 6. Healthcare サンプルの Business Space

クリックして大きなイメージを見る

図 6. Healthcare サンプルの Business Space

図 7 ではディメンション・ウィジェットを利用して、州とリクエスト時刻を基に、またはトランザクションの状態を基に、HIPAA トランザクションの分布を表示しています。他の時刻や州を選択して、トランザクションの分布の詳細を分析することができます。

図 7. Healthcare サンプルの Analysis ページ

レポート・ウィジェットを利用すると、トランザクションの状態を折れ線グラフのレポートとして表示することができます (図 8)。図 8 の左側は拒否されたリクエストの数が月ごとに変化する様子を示しています。オレンジ色の線はリクエストの総数を表し、青色の線は拒否されたリクエストの総数を示しています。図 8 の右側は拒否理由を示しており、3 色を使って 3 種類の拒否理由を示しています。レポート・ウィジェットを構成することで、他の折れ線を定義することもできます。

図 8. Healthcare サンプルの Report ページ

クリックして大きなイメージを見る

図 8. Healthcare サンプルの Report ページ


製品ライフサイクル管理 (PLM) における BAM

PLM は、生産される製品の要件、設計、製造、サポート、廃棄に関するすべてのデータの管理を意味します。PLM は明確に定義されたいくつかの段階と手法で構成され、管理者はそれらを使うことで、ライフサイクルの各段階を通過していく製品を管理します。製品が販売される条件は時間とともに変化し、その製品が各段階を通過する中で、そうした条件を管理する必要があります。

製品のライフサイクルには多くのフェーズがあり、多くの専門的手順があり、そして多様なスキルやツール、プロセスが必要です。PLM では、製品の開発期間や使用期間をとおしての製品の記述や特性を、主にビジネスとエンジニアリングの観点から管理します。

Fabric には、技術変更フェーズでの ECR (Engineering Change Request: 技術変更リクエスト) の指定や決定のためのビジネス・プロセスがあります。ECR は 1 つ以上の製品への変更を評価する機能であり、変更の内容としては、製品の部品やアセンブリー、ドキュメントその他の項目の変更や、あるいは製品の設計、製造上で必要なアクティビティーの変更などがあります。ECR の評価方法の概要は以下のとおりです。

  1. まず、計画された変更の対象範囲と影響を判断するために、ユーザーは利用可能な任意のチャネルを使って Manage Engineering Change ゲートウェイから ECR 文書を送信します。
  2. ECR 文書が送信されると、図 9 に示すプロセスは、計画された変更を受け付けるか拒否するかを判断し、ユーザーにレスポンスを返します。このプロセスには 5 つのフェーズが含まれ、各フェーズで 1 つの特定タスクが ECR に対して行われます。
図 9. 技術変更プロセス
技術変更プロセス

この 5 つのフェーズを要約したものが下記です。

  1. Inquiry of ECR (ECR の照会) フェーズでは、ECR に関する申し出を受信します。
  2. Creation of ECR (ECR の作成) フェーズでは、実際に ECR を作成し、その ECR を明確に記述します。
  3. Technical Analysis of ECR(ECR の技術分析) フェーズでは、ECR の技術的側面が判断され、その ECR による影響の最初の概要検討が行われます。
  4. 4 番目のCommenting on ECR(ECR へのコメント) フェーズでは、プロトタイピングや認証などの面での影響の視点から ECR を検証します。
  5. 最後の Approval of ECR (ECR の承認) フェーズでは、その ECR を承認するかしないかの判断が下されます。

変更提案が作成されると、通常は照会 (inquiry) が行われ、その提案を進めるかどうかを判断します。図 10 は Inquiry フェーズのサブプロセスを示しています。ECR リクエストは Inquire VDA (Verband der Automobilindustrie: (ドイツ) 自動車工業会) ECR ビジネス・プロセスに送信されます。この ECR リクエストは受信され、評価されます。最後に、このプロセスは ECR ステータスを提供し、その ECR が受け付けられ、処理が進められるかどうかを示します。

図 10. サブプロセス: ECR の照会 (Inquire)

Monitor を使用する PLM のサンプルでは、ECR 照会サブプロセスによって送受信される情報に注目します (たとえば、1 カ月に何件の ECR が照会されたか、何件の ECR が受け付けられたか、あるいは拒否されたか、など)。

以下の図は Monitor を使って照会プロセスをモニタリングした結果を示しています。図 11 は、Monitor ダッシュボードのメイン・ページを示しています (メイン・ページの名前は My Business です)。ECR のステータスは円グラフで表示されており、このグラフはディメンション・ウィジェットを使って表示されています。また、受け付けられた ECR の合計、処理途中 (判断待ち) の ECR の合計、拒否された ECR の合計が、KPI ウィジェットを使って表示されています。またこのページにはインスタンス・ウィジェットも組み込んであり、各 ECR と、関連する詳細情報を表示することができます。

図 11. PLM サンプルの Monitor ダッシュボード

クリックして大きなイメージを見る

図 11. PLM サンプルの Monitor ダッシュボード

このサンプルでは Monitor の計算機能を利用することで、ECR の提出傾向を折れ線グラフで表示することができます (図 12)。

図 12. PLM サンプルの Report ページ

クリックして大きなイメージを見る

図 12. PLM サンプルの Report ページ

またこのサンプルでは、指定期間内に提出された ECR の合計も表示することができます (図 13)。

Monitor V6.2 には、KPI History and Prediction (KPI 履歴と予測) など、顧客向けの新しいダッシュボード機能がいくつかあります。KPI History and Prediction 機能を利用すると、ある期間内に KPI からデータを収集し、そのデータを分析して傾向を確認することができます。分析結果は完全に対話型のグラフ形式で表示されます (右側)。KPI History and Prediction ウィジェットに表示される線は、指定された KPI に関する過去の履歴と将来予測される傾向を示しています。

図 13. PLM サンプルの Analysis ページ

クリックして大きなイメージを見る

図 13. PLM サンプルの Analysis ページ

ECR に対する照会フェーズの各サブステップには人間によるタスクが 1 つあるため、Human Task という別の新機能を使用して、人間によるタスクのすべてのインスタンスを表示しています (図 14)。

図 14. PLM サンプルの Action ページ

クリックして大きなイメージを見る

図 14. PLM サンプルの Action ページ


考察

どの業界の場合であれ、指定されたプロセス用のダッシュボードを設計するためには専門的訓練と芸術的センスの両方が必要です。設計に際して考慮すべき点は、どんな情報が最も重要かを業界のビジネス・リーダーから聞き出すことであり、またビジネス・プロセスの中にあるデータや、ビジネス・プロセスから生成されるデータから、どのようにして情報を取得するかを判断することです。考慮が必要な 2 番目の点は、そうした情報をダッシュボードに表示するために最適な方法を判断することです。どのウィジェットがどの情報に対して最適なのか。それらのウィジェットを別のタブやページとして論理的にどう整理すればよいのか。どんな順序でページを表示すべきなのか、といったことです。

それらを判断する上で重要なことは、設計や開発のプロセスにおいて、その分野の専門家やビジネス・ユーザーにも参加してもらうことです。そうした人達から、上記の疑問に対する答えを確実に引き出す必要があります。私達の場合は反復型手法を使用し、プロトタイプを作成してユーザーに提示しました。ユーザーに提示した後に作成される各プロトタイプは、ユーザーからのフィードバックを基に改善されていなければなりません。その一方でユーザーに対し、どんなことが技術的に可能なのか、パフォーマンス、マイグレーション、移植性などの観点からは何が現実的なのかを理解してもらう必要があります。

この記事で説明した業界すべてに共通している点として、業界標準の存在、具体的にはデータ・フォーマットの標準の存在が挙げられます。そのため、モニター・モデルの開発では多くの場合、これらの標準を理解する必要があります。つまり、データ・フォーマットのどこから特定のデータを取得するのか、どのようにデータを抽出するのか、また場合によると、どのようにしてデータをデコードするのか、といったことを把握しておく必要があります。データ変換が必要な場合には、UDXF が非常に便利です。もう 1 つの方法としては、モニター・モデルにデータを提供する前に、WebSphere Enterprise Service Bus、XSLT その他のデータ仲介技術を使用してデータ変換を行うことも可能です。


まとめ

この記事では、WebSphere Business Monitor V6.2 を使用する WebSphere Business Service Fabric V6.2 Industry Content Packs から、3 つの特定業界向けサンプルを取り上げ、それぞれのダッシュボードの実装について説明しました。保険 (Insurance) 業界のサンプルでは、Monitor を使うことで、特定の州における保険請求の総数や、その他の重要なパフォーマンス情報を表示することができます。またユーザーは支払総額や請求状態の分布などの統計も見たいかもしれません。そうした情報は、Monitor のダッシュボードを使うことで容易に表示することができます。医療 (Healthcare) 業界のサンプルでは、1 カ月間に発生するトランザクション数や、受け付けられた HIPAA リクエストと拒否された HIPAA リクエストの割合を理解できるように、各メッセージに含まれる関連情報を Monitor によって抽出し、その結果を、KPI ウィジェット、アラート・ウィジェット、ダイアグラム・ウィジェット、ディメンション・ウィジェット、レポート・ウィジェット、インスタンス・ウィジェットなどを使って表示することができます。また私達は、HIPAA 標準メッセージをデコード、解析するためのUDXF を、このサンプルと共に提供される成果物として追加しました。PLM のサンプルでは、1 カ月間の ECR ステータス照会トランザクションの数、ステータス別の ECR の数といった有用な情報を、Monitor によって収集することができます。私達はこれらのサンプルに対し、イベントを収集し、パフォーマンス・データを計算するモニター・モデルを実装しました。

参考文献

  • Put new capabilities of business activity monitoring (BAM) to work, Part 7: Creating user-defined XPath functions for IBM WebSphere Business Monitor V6.1」(developerWorks、2008年): この連載の中で、WebSphere Business Monitor V6.1 の大幅な変更について学んでください。WebSphere Business Monitor V6.1 は機能が拡張され、ビジネス・パフォーマンスの監視方法と管理方法が簡素化されたメジャー・リリースです。ユーザー定義 XPath 関数 (UDXF) はプログラミング・モデルのための有用で強力な拡張機能です。この新機能を使うことで、モニター・モデルのロジックに関数を追加することができます。例えば、通常の Java™ 関数 (リモートの CICS® データベースからのデータの読み取りや Web サービスの呼び出しなど) を実行する UDXF を作成することができます。この記事を読み、独自の UDXF を作成し、それをモニター・モデル内の任意の式で利用する方法について学んでください。
  • Business Process Management Samples & Tutorials: これらのサンプルは、WebSphere Integration Developer で作成し、WebSphere Process Serverと WebSphere Enterprise Service Bus (WebSphere ESB) にデプロイする機能を解説しています。これらのサンプルは、さまざまな製品機能を利用して独自のアプリケーションを作成するために役立ちます。
  • developerWorks の BPM ゾーン: ダウンロード、デモ、技術記事、チュートリアル、イベント情報、ウェブキャストなど、IBM の BPM ソリューションに関する最新の技術リソースを入手してください。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere, Industries
ArticleID=498064
ArticleTitle=特定業界向けのビジネス・アクティビティー・モニタリング
publish-date=02072010