Topics
カスタム・ペイロードを使用したビジネス・イベントのサブスクリプション
Michael Baguley著[2008年3月]
Oracle E-Business Suite製品の多くは、ビジネス・プロセスの統合にOracle Workflowのビジネス・イベント・システムを使用しています。 Oracle E-Business Suiteをビジネス・プロセスに統合する方法はほかにもありますが、この方法では、Oracle E-Business Suiteの標準機能を使用してイベント駆動型のESBプロセスやBPELプロセスを構築できます。
ビジネス・イベントのサブスクリプションには、WF_EVENT_Tというペイロード・タイプがあります。Oracle E-Business Suiteアダプタを使用してOracle E-Business Suiteと統合すれば、このペイロードを使用できます。 ただし、WF_EVENT_Tペイロードで対応できないユースケースも存在します。 こうした状況への対応方法として、ビジネス・イベント・システムとOracle Advanced Queuing（Oracle AQ）を組み合わせて使用する方法があります。 ビジネス・イベントのトリガーによるBPELプロセスやESBプロセスの起動に、Oracle AQアダプタを使用できます。
この方法に必要なものをまとめると、次のようになります。
· Oracle E-Business Suiteのアドバンスト・キューの作成
· アドバンスト・キュー用のビジネス・イベント・システムのエージェントの作成
· XMLメッセージの作成に必要なイベントのサブスクリプション
· XMLメッセージをエージェントに送信するイベントのサブスクリプション
· アドバンスト・キュー・メッセージのペイロードに一致したXMLスキーマ
· アドバンスト・キューからメッセージをデキューするOracle AQのパートナー・リンク、または、Oracle Enterprise Service Busを使用する場合は、アドバンスト・キューからメッセージをデキューするOracle AQアダプタ・サービスにより開始されるBPELプロセス
複数のビジネス・イベントのサブスクリプションについても、サブスクリプションでOracle E-Business Suiteの内部プロセスを開始している場合（Oracle Workflowの開始など）には、同じ方法を使用します。
ビジネス・イベント・システムの構成
1. APPSスキーマに、ビジネス・イベント・システムで使用するAQを作成します。 ここに示すAPPS_OUT_Qの例では、RAWペイロードを使用しています。
2. ビジネス・イベント・エージェントをサポートするにはカスタム・キュー・ハンドラが必要です。 AQ上のメッセージをエンキュー/デキューする際にビジネス・イベント・システムで使用したプロシージャに従って、APPSスキーマにパッケージを作成します。 このパッケージ作成には、WF_EVENT_QH標準パッケージをベースとして使用できます。 パッケージ名は、後ほどビジネス・イベント・システムのエージェントを構成する際にキュー・ハンドラ値として使用します。 AQはアウトバウンド・メッセージにのみ使用されるため、デキュー・プロシージャは処理ロジックのないスタブとして使用できます。
/*-------------------------------------------------- | Queue Handler Enqueue Procedure --------------------------------------------------*/ PROCEDURE enqueue (p_event IN WF_EVENT_T , p_out_agent_override IN WF_AGENT_T) IS /*-------------------------------- | AQ Variables --------------------------------*/ l_msgid RAW(16); l_enq_opt dbms_aq.enqueue_options_t; l_msg_prop dbms_aq.message_properties_t; l_xml_clob CLOB; l_amt NUMBER; l_data VARCHAR2(32000); BEGIN /*---------------------------------------- | Event XML to CLOB for AQ ----------------------------------------*/ dbms_lob.createtemporary( lob_loc => l_xml_clob , cache => FALSE , dur => dbms_lob.call); l_amt := length(p_event.getEventData()); -- set amount to process /*-------------------------------- | Enqueue RAW message --------------------------------*/ DBMS_LOB.READ ( lob_loc => p_event.getEventData(), amount => l_amt, offset => 1, buffer => l_data); IF l_data != 'VOID' THEN DBMS_AQ.ENQUEUE ( queue_name => 'APPS_OUT_Q' , enqueue_options => l_enq_opt , message_properties => l_msg_prop , payload => utl_raw.cast_to_raw(l_data) , msgid => l_msgid); END IF; END ENQUEUE; PROCEDURE dequeue (p_agent_guid IN RAW, p_event OUT WF_EVENT_T) IS BEGIN NULL; END;
3. 次に、ビジネス・イベント・システムのエージェントを設定します。
4. 最初のサブスクリプションで使用するPL/SQLファンクションが必要です。 このファンクションは、XMLメッセージを作成します。 パラメータはビジネス・イベントのペイロード（WF_EVENT_T）から抽出されて、サブスクリプションで使用されます。 Oracle Applications Managerのエージェント・アクティビティを使用すれば、WF_DEFERREDキューで処理されたサブスクリプションを表示して、イベントで使用されたパラメータ・リストを確認できます。
ファンクションは、サブスクリプションの標準形式を取得します。次に例を示します。
FUNCTION person_record ( p_subscription_guid IN RAW , p_event IN OUT WF_EVENT_T) RETURN VARCHAR2
ファンクションには、次の処理が必要です。
· イベントのパラメータを取得します。たとえば次のように記述します。
l_user_id:= to_number(p_event.GetValueForParameter (pName => 'USER_ID'));
· FND_GLOBAL.APPS_INITIALIZEとイベントのパラメータから取得したユーザーの資格証明を使用して、Oracle E-Business Suite環境を初期化します。
· XMLメッセージを作成します。 PL/SQLパッケージのDBMS_XMLQUERYを使用して、CLOBにXMLペイロードを作成できます。
· DBMS_XMLQUERYで返されるCLOB値を使用して、p_event.event_dataのCLOB値を設定します。
p_event.setEventData(l_xml_query_result);
· 最初のサブスクリプションでは、XMLメッセージを作成します。 PL/SQLのRule Function値は、手順4で定義したファンクションとなります。
· 2番目のサブスクリプションでは、エージェント（アドバンスト・キュー）にメッセージを送信します。
サブスクリプションのフェーズ番号は、最初のメッセージ・サブスクリプションよりも大きい値にする必要があります。
ビジネス・イベントを消費するBPELプロセス
次の例では、Oracle AQアダプタを使用して、前述のOracle E-Business SuiteのサブスクリプションからメッセージをデキューするBPELプロセスを開始する方法について説明します。
1. Oracle E-Business Suiteからのメッセージに転送されるペイロードと一致するXMLスキーマが必要です。
2. 空のBPELプロジェクトを作成します。
3. ビジネス・イベント・システムのエージェントとして定義されたAQのメッセージをデキューするBPELプロセスにOracle AQアダプタのパートナー・リンクを追加します。
BPELプロセスのMessage Schemaとして定義されたXMLスキーマを選択します。
4. BPELプロセスにReceiveアクティビティを追加します。
5. これで、残りのBPELプロセスの追加、配置、テストが完了しました。
 |
|
|
Oracle BPEL Process ManagerによるR12 TCAのビジネス・オブジェクトAPIの使用
Michael Baguley著[2008年3月]
Release 12には、Trading Community Architecture（TCA）のビジネス・オブジェクトAPIが導入されています。 これらは、操作可能なビジネスの論理単位を形成するTCAエンティティの抽象グループです。
もっと簡単にいえば、BPELプロセスからOracle E-Business Suiteアダプタを起動する場合、TCA内の複数のエンティティを処理できます。粒度の細かいAPIを順番に呼び出す必要はありません。 APIを使用すれば、複雑なエンティティの作成が簡素化されるうえ、Update操作やSave操作（渡された識別情報が既存のビジネス・オブジェクトと一致するかどうかに基づいて作成または更新を実行する）、さらにGet操作（ビジネス・オブジェクト・データを抽出して返す）を実行できます。
それでは、実際にはどのように機能するのでしょうか。
次のプロセス例では、API HZ_PERSON_BO_PUB.get_person_boを使用してTCA内にその人物が存在するかをテストし、存在しない場合は、HZ_PERSON_BO_PUB.create_person_boというAPIを使用してPerson Party、Location、Party Site、およびParty Site Useを作成します。 Oracle E-Business Suiteアダプタは、これらのAPIをコールするために使用されます。
まずは、入力データとAPIの返す出力パラメータ（party_idなど）を処理するためのXMLスキーマを定義します。
<?xml version="1.0" encoding="windows-1252" ?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.mb.com/xsd" targetNamespace="http://www.mb.com/xsd" elementFormDefault="qualified"> <xsd:element name="Person"> <xsd:annotation> <xsd:documentation> A sample element: </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element name="FirstName" type="xsd:string"/> <xsd:element name="LastName" type="xsd:string"/> <xsd:element name="Country" type="xsd:string"/> <xsd:element name="Address1" type="xsd:string"/> <xsd:element name="City" type="xsd:string"/> <xsd:element name="Zip" type="xsd:string"/> <xsd:element name="PartyId" type="xsd:int"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema>
次の図は、プロセスの概要を示しています。 その人物がTCA内に存在するかどうかの確認は、PersonExistenceCheckスコープで実行されています。 続いてSwitchアクティビティで、TCA内にその人物が見つかったかどうかが処理されます。
Oracle E-Business Suiteの各パートナー・リンクで、適切なTCAのビジネス・オブジェクトAPIが使用されます。 『 TCA Technical Implementation Guide』で公式に文書化されていますが、TCAのビジネス・オブジェクトのPL/SQLパッケージは、Oracle Applications Module Browserで「 Other Interfaces」→「 Custom Objects」→「 PLSQL APIs」の順に選択すると表示されます。
Invokeアクティビティのために定義された入力変数にプロセス入力変数からデータを転送するため、各Invokeアクティビティの前にTransformアクティビティが追加されます。
さらにこれによりペイロードが変換され、APIに必要なデフォルト値や必須値が追加されます。 必要なデフォルト値には、たとえばCREATED_BY_MODULEなどがあります。 デフォルト値は、要素を右クリックするか、またはXSLTマッパーの「 Set Text…」を選択して追加できます。
これらのAPIを使用するさらなるメリットは、APIのエラー・メッセージが出力変数のx_messages要素内のBPELプロセスに返されることです。
次の図は、全プロセスを示しています。
要するに、機能性の向上したこのようなAPIは、BPELプロセスでの使用に非常に適しています。 プロセスを迅速に作成でき、しかも複雑さが緩和されるため、結果として明確なプロセスが作成できます。 使用可能なAPIとその使用方法の詳細については、『 TCA Technical Implementation Guide』を参照してください。
|
|
|
|
Kevin Bouwmeester著[2008年3月]
Oracle Fusionが間もなくリリースされます。 今回の設定では、Oracle BI Publisher（Oracle BIP）が主要レポート・ツールとなる予定です。 今後使用可能となるテンプレート数はまさに驚異的といえます。 テンプレート作成時の柔軟性が向上することは、文書要件に対応できるという点では喜ばしいことです。 しかし、開発者がそれぞれ独自の方法を採用した場合、保全性、可読性、協力性に関してこうした自由度が深刻な問題となる可能性もあります。
結果的には、すべてのテンプレートは拡張やカスタマイズが必要だと思われます。 近い将来、EMEA（または世界中）のOracle BI Publisherの開発者は、他者の作成したテンプレートを調整するようになることでしょう。 しかし、ガイドラインなしで他者の仕事を把握して状況に合わせて調整することは、それほど簡単ではありません。 そのため、Oracle BI Publisherの開発では、標準とベスト・プラクティスを使用できるようになっています。 さらに、ここでは概要を無償でご覧になれます。
ネーミング
Oracle BI Publisherのより直感的な開発を目指すうえでまず思い浮かぶのは、ネーミング規則です。 最終的には、データ・テンプレート、バースト制御ファイル、プレビュー・データなどの複数のXMLファイルを使用することになるでしょう。 その結果、混乱が生じ、Wordのテンプレート・ビルダーにデータ・テンプレートをロードして、レイアウトを上書きしてしまったという例もあります。 この問題を解消するのは、非常に簡単です。ネーミングの際に、どのファイルであるかがすぐにわかる名前をつけることでファイルを探す手間を省くことができます。
· データ・テンプレート： _DT.xmlをファイル名の接尾辞に使用
· バースト制御ファイル： _BC.xmlをファイル名の接尾辞に使用
· プレビュー・データ： _DATA.xmlをファイル名の接尾辞に使用
以下は、Oracle BI Publisherをカスタマイズした際のファイル名です。各ファイルがどのようなものであるかが簡単にわかるようになっています。
XMLの最適な構築方法
Oracle BI Publisherレポートを作成するにあたっては、必要な回答がすべて揃っていることを確認する必要があります。 そのため、XML構造の定義を開始する前に、次のようなOracle BIPの基本的な特徴について検討しておくことが大切です。
· XML構造のレイアウト・テンプレートをいくつ作成するか。 XML構造を検討する際には、各テンプレートの要件を考慮する必要があります。 また、データを完成させ、XMLファイルの階層構造をレポートの構造（マスター・レコードと詳細レコード）に合わせる必要があります。
· バーストは必要かどうか。 必要な場合は、XML構造では注意が必要です。 バーストによりXMLデータが細分化されるため、バースト処理後はバースト範囲外のすべての要素にアクセスできなくなります。 そのため、関連データはすべて、バースト対象のXML要素の下に配置しておく必要があります。 これにより、XML内にデータの冗長が発生します。
· 変換が必要かどうか。 必要な場合は、データを複数言語で使用できるようにして、そのデータから問合せを作成し、XML用のデータを選択する必要があります。
XMLデータの生成時に、生成方法や生成日時を確認することはできません。 バグの発生源を追跡するため、XMLファイルが生成されたデータベースと、同時リクエストのIDと引数を把握しておくことが大切です。 そのためには、Oracle BI Publisherで生成される各XMLファイルにメタデータを保存しておく必要があります。 以下は、生成された各XMLデータに記述情報を保存するため、データ・テンプレートに追加できる問合せの例を示します。
理想的なRTFテンプレート
理想のRTFテンプレートというものは存在しませんが、できるだけ理想的な状態に近づけることは可能です。 理想的なテンプレートとはつまり、生成すべきレポートのレイアウトに類似し、開発者が簡単かつ完全に理解できるものと言えるでしょう。 これらは相反する場合もありますが、Wordの非表示機能を使用すれば、RTFテンプレートに2種類の"ビュー"を作成できるため、両要件を満たすことができます。
考え方は簡単です。開発者だけが確認したいものをすべて非表示にするというものです。 基本的には、処理フローを制御する、データを印刷しないステートメントがこれに該当します。 それにはたとえば次のようなものがあります。
· 条件 （<?if:CURRENCY='EUR'?>および <?end if?>）
· 反復 （<?for-each:INVOICE?>および <?end for-each?>）
· サブテンプレートの定義 （<?template:footer?>および <?end template?>）
このボタン（ 
）を使用して、レイアウト・ビューと開発者ビューを切り替えることができます。
さらに、テンプレートへのデータの挿入に使用するText Form Fieldのすべてに、記述的な名前をつけることもできます。 可読性を向上するには、Text Form Fieldの表すデータの例を名前にします。 そうすれば、データ例に基づいて、生成される文書がどのように表示されるかを確認できます。 これは、入力データがうまく収まる列の幅を決定する場合に便利です。
詳細情報
この記事の目的は、同僚のSerge Vervaetとともに作成中のベスト・プラクティスと標準のごく一部を紹介することです。 詳細について知りたい場合は、私まで直接ご連絡ください。Oracle BI Publisherの開発における最善事項をより幅広くご紹介します。 まだ公式には開始されていませんが、Oracle BI Publisherのベスト・プラクティス・トレーニングが間もなく開始される予定です。情報が入り次第お知らせしますので、Oracle BIPのベスト・プラクティスの詳細情報に引き続きご注目ください。
|
|
|
|
Oracle E-Business Suiteアダプタの概要
Neeraj Chauhan著[2008年3月]
Oracle E-Business Suiteアダプタは、Oracle E-Business Suiteとの包括的な双方向のマルチモーダルな接続機能を提供し、企業の異機種エコシステムでシームレスな統合を実現します。 Oracle E-Business Suiteアダプタは、Oracle E-Business SuiteのインタフェースをWebサービスとして公開します。 このWebサービスにより、エンタープライズ・アプリケーションのビジネス・プロセス間に、Oracle Fusion Middlewareを使用したSOAベースの統合ソリューションを構築できます。
Oracle E-Business Suiteアダプタのおもな特徴をまとめると、次のようになります。
統合リポジトリの活用
Oracle E-Business Suiteアダプタは、Oracle E-Business Suiteの統合リポジトリを活用して、統合パブリック・インタフェースのメタデータを提供します。 統合リポジトリは、Oracle E-Business Suiteの公開する外部との統合のための情報源です。 Oracle E-Business Suite 11i10では、統合リポジトリはホスト・インスタンス（http://irep.oracle.com）でしたが、Oracle E-Business Suite R12.0では、"統合リポジトリ"としての責任のもとに製品にバンドルされています。
幅広い対応インタフェース
Oracle E-Business Suiteアダプタは、PL/SQL API、ビジネス・イベント、オープン・インタフェース表、コンカレント・プログラム、XMLメッセージ、Oracle E-Commerce Gatewayインタフェース、およびインタフェース・ビューなどのOracle E-Business Suiteの各種統合テクノロジーに対応しています。
安全で信頼性の高い接続
ミドルウェアとエンタープライズ・アプリケーション間の接続の確立は、共有接続のための認証資格証明の不正使用を回避するためにはもっとも重要です。 Oracle E-Business Suiteアダプタは、Oracle Fusion MiddlewareとOracle E-Business Suite間の安全で信頼性の高い接続環境で機能します。FNDユーザー名とパスワードのみを使用し、ほかに共有の資格証明を必要としません。 詳細については、Metalink Note # 464164.1を参照してください。
Oracle E-Business Suiteの機能セキュリティの有効化
セキュリティは、アプリケーションのコンテンツを不正アクセスから守るためのもっとも重要な機能です。 Oracle E-Business Suiteアダプタは、Oracle E-Business Suiteの機能セキュリティモデルを実装し、Oracle E-Business Suite アダプタを介して公開されるAPIを認証ユーザーのみが実行できるようにするセキュリティ機能を提供します。 この機能は、Oracle EBS 11i10とOracle EBS R12.0で使用できます。 詳細については、Metalink Note # 464164.1を参照してください。
トランザクションのサポート
Oracle E-Business Suiteアダプタは、JCA準拠のOracle Fusion Middlewareアダプタ・フレームワークの技術基盤に対応した、2フェーズ・コミットのトランザクションを実装し、提供します。 2フェーズ・コミット機能は、Java Connector Architecture（JCA）に基づくJava Transaction API（JTA）の実装を介して利用できます。この機能は、全アプリケーションの更新の有無を確認して、全アプリケーション・データベースを同期化します。
アプリケーション・コンテキスト対応
グローバル・アプリケーション・コンテキストの採用により、複数のデータベース・セッションで同じアプリケーション・コンテキストに接続できるため、ユーザー・セッションごとに別々のアプリケーション・コンテキストを作成する必要性が低減または排除されます。 Oracle EBSアダプタは、Oracle EBSサービスの起動前にユーザー・セッションを暗黙的に初期化します。 FND_GLOBAL.APPS_INITIALIZEプロシージャがコールされ、データベース・セッションのグローバル・アプリケーション・コンテキストが初期化されます。
Oracle E-Business Suite Release 12.0のサポートとOracle EBSアダプタのロードマップ
Oracle E-Business Suite Release 12.0については、Oracle Fusion Middleware SOA Suiteのバージョン10.1.3.3でサポートされており、セキュリティ機能については、10.1.3.3以降とMetalink Note # 464164.1に記載されたパッチ番号で利用できます。
Oracle E-Business Suiteアダプタのロードマップ機能である統合エラー/例外処理機能とランタイムのサービス監視機能も間もなく導入される予定です。
|
|
|
|
Oracle E-Business SuiteアダプタとOracle E-Businessアプリケーション・セキュリティを使用したOracle E-Business Suiteとの統合
James Lewis著[2008年3月]
長いタイトルになってしまいましたが、長いタイトルに寛容な方々がいらっしゃることを幸いに思います。 私は、アリゾナ州テンペにあるE2E ConsultingというOracleパートナーのコンサルティング企業で、インテグレーション・アーキテクトを務めています。 SOAプロジェクトの一環で、Oracle E-Bizという愛称で呼ばれているOracle E-Business Suiteとの統合が必要になりました。 Oracle E-Bizや大規模のERPシステムとの統合経験はありませんでしたが、データベースやキュー、ファイルなどとの一般的な統合には精通していたため、難しいことではないと思っていました。 実際におこなってみると、Oracle SOA SuiteとOracle JDeveloperでOracle E-Business Suiteアダプタを使用すれば、Oracle E-Bizとの統合は簡単であることがわかりました。 鋭い方は、前文でOracleという言葉が何度も使用されていることにお気づきのことと思います。これは意図的なものです。 おそらくユーザーは、既存の製品間のシームレスな統合計画を企業に対して期待していると思いますが、これはまさにオラクルがOracle E-Business Suiteアダプタを通じて実践していることです。
私のプロジェクトでは、Oracle E-Bizをプロジェクト管理の記録システムとして使用しています。 Oracle E-Bizとの最初の統合では、Oracle E-Bizに各種作業管理システムからの作業指示を送信してOracle E-Bizのタスクとし、従業員がタスクIDを使用してタイムシートや指示項目に時間を入力できるようにしました。幸い、当時すでにOracle JDeveloperでBPELにどっぷり漬かっており、Oracle E-Business Suiteアダプタの便利なアイコンがOracle JDeveloperのBPELサービスとして使用できると気づいたため、それは当然の選択でした。 しかし、Oracle E-Business Suiteアダプタを使用するとしても、Oracle E-Bizとの統合方法はいろいろあります。
どの統合方法を使用するか
図1に示すとおり、Oracle E-Bizとの統合方法は多数存在します。 今回は、Oracle BPEL Process ManagerからOracle E-Bizへの統合であったため、図に示す方法のいくつかが除外され、次の方法が残りました。
· Oracle XML Gateway
· コンカレント・プログラム
· PL/SQL API
· インタフェース表
ここでは、今後Oracle E-Bizをアップグレードした場合の追加構成とメンテナンスを不要にするため、PL/SQL APIを直接使用することを選択しました。 上図に示すとおり、Oracle Applicationsアダプタ内では、J2CA（J2EE Connector Architecture）を頻繁に使用して、Oracle E-Bizとの物理接続を確立します。 Oracle E-Business Suiteアダプタ内のJ2CA接続の構成については、後ほどblogで説明します。 ここで重要なのは、J2CAを使用すれば、J2CAコネクタをBPELプロセスに公開するだけで、各アダプタに何が必要かといった接続情報をOracle SOA Suiteで非表示にできるということです。
読者の方々は、Oracle JDeveloperのBPELプロセス作成方法についてはすでによくご存じであり、Oracle E-Business Suiteアダプタを使用したOracle E-Bizへの接続がいかに簡単であるかに関心をおもちのことと思います。 そうでない方々には、Oracle JDeveloperのBPELプロセス作成手順を紹介した優れたチュートリアルが多数提供されており、さらにOracle E-Business SuiteアダプタによるOracle E-Bizへの接続手順を紹介したチュートリアルも提供されています。 ここでの目的は、重複した情報をお伝えすることではなく、Oracle E-Business Suiteアダプタをプロジェクトで使用した個人的な体験を通じて得た見解をお伝えすることにより、情報の増強を図ることです。 とはいえ、ほかで紹介される手順をやむを得ずここで取り上げる場合もありますが、あくまで特定の点を説明する目的で取り上げます。
そのうちの1つは、Oracle Applicationsモジュール・ブラウザです。これは、Oracle JDeveloperのOracle Applicationsウィザードで、起動する通信方法とAPIを決定する場合に使用します。 我々のケースでは、統合チームに客先企業からOracle E-Bizのサポート開発者が派遣されており、どのAPIやパッケージを使用する必要があるかを把握していたため、Oracle Projectsモジュールへの追加タスクや更新タスクに必要なAPIを見つけるのに時間はかかりませんでした。 先ほど挙げた通信方法に基づいて、モジュール・ブラウザの上部で使用する通信方法を選択することによっても、表示されるAPIにフィルタをかけることができます。 図2は、Oracle JDeveloper内でのOracle Applicationsモジュール・ブラウザの表示例を示しています。
アプリケーション・コンテキストとOracle E-Business Suite
アプリケーション・コンテキストの定義方法についてはこの記事の対象範囲外であるため、ここでは追加情報について説明します。 まず重要なのは、Oracle E-Bizデータベースへの接続でデータベース・レベルのセキュリティが使用されるのに加え、API使用時の認証でアプリケーション・レベルのセキュリティが使用される点です。 アプリケーション・レベルの認証に対応するためには、Oracle E-Business Suiteアダプタを使用すれば、BPELプロセスのヘッダー変数を使用できます。 ヘッダー変数に最小限含まれている必要があるのは、アプリケーション・レベルの認証を得るために使用するアプリケーションのユーザー名と権限です。 さらに、Oracle E-Bizのバージョンに応じて、また、複数の組織単位を使用する構成になっているかどうかによって、そのユーザー名と権限に適用する組織を含めることができます。 我々の場合、必要なのはユーザー名と権限のみでしたが、そのヘッダー変数で複数のPL/SQL APIを起動する必要があったため、BPELプロセスの初めの部分でヘッダー・タイプのグローバル変数を宣言し、ユーザー名と権限を割り当てました。 幸い、パートナー・リンク・サービスを作成すると、Oracle JDeveloperでOracle Applicationsヘッダーのメッセージ・タイプを定義するAdapterHeader.wsdlプロシージャというWSDLが作成されたため、このタイプのグローバル変数を作成するだけで済みました。 次に、グローバル・ヘッダー変数をあとで初期化できるように、BPELプロセスにAssignアクティビティを追加しました。 必要なAPIすべてにアクセスするためには、ユーザー名をSysadminに、権限を“Order Management Super User, Vision Operations (USA)”に設定する必要がありました。
次に、Oracle E-Bizにタスクを追加するためのInvokeアクティビティをBPELプロセスに追加する際に、懐中電灯型の“Browse”アイコンを使用して、使用するOracle E-Bizの資格証明をAPIに保存する変数を選択しました。 これで手順は完了です。 Oracleでエラーが発生することなく、先ほど選択したAPIにアクセスできるようになりました。 Oracle E-Bizのタスクを更新するためのInvokeアクティビティを追加する際にも、同じ変数を使用して同じ手順を実行しました。
アプリケーション・コンテキストについての説明を終える前に、1ついい忘れていたかもしれませんが、Oracle JDeveloperでは、Oracle E-BizのAPI用として作成されるパートナー・リンクのWSDLに、標準のユーザー名と権限が埋め込まれます。 デフォルトでは、“sysadmin”というユーザー名と“System Administrator”という権限がWSDLの<jca:operation>に埋め込まれます。その設定で、Oracle E-Bizとアクセスが必要なAPIに問題がない場合は、APIコールのアプリケーション・コンテキストを設定する際にヘッダー変数は不要になります。
慎重に確認
これまでデータベース・アダプタを使用してOracle SOA Suiteの各種システムを統合した経験があっても、Oracle E-Business Suiteアダプタを初めて使用する場合は、BPELサーバー・インスタンスの構成に不備が残る場合があります。 データベース・アダプタと同様に、BPELプロセスにデータベース・アダプタのパートナー・リンクを追加する場合には、そのパートナー・リンクのためにWSDL内のOracle JDeveloperデータベース接続情報が使用されます。そのため、対応するJNDIエントリを使用してサーバーのJ2CAアダプタが構成されていない場合にも、一応正常には機能しますが、起動するたびに開発データベースへの新たな接続が作成されるため、非効率的になります。 同様に、Oracle E-Business Suiteアダプタを使用したパートナー・リンクが作成されると、Oracle JDeveloperによりWebサービスのWSDLに接続情報が埋め込まれます。 データベース・アダプタの使用時には、WSDLの<jca:address/>要素内で、Oracle E-Bizデータベースへの接続に使用するJDBC URL接続文字列、ユーザー名、およびパスワードを確認できます。 ここには、アダプタがどの接続情報を使用するかを把握するためにとくに役立つダイアグラムが収められています。 我々は、このダイアグラムに基づいて、XAトランザクションをサポートするOracle Application Serverにデータベース接続プールとデータソースを作成します。次に、JDeveloperによって作成されたWSDLの記述どおりにAppsAdapterのoc4j-ra.xmlファイルを編集し、パートナー・リンクのためにJDeveloperによって作成されたWSDLの<jca_address>要素と一致するlocation属性をもつ<connector-factory>要素を作成します。 最後に、名前が”xADataSourceName”であり、値が作成したXAデータソースと一致する<connector-factory>の下に、<config-property>要素を追加しました。 OC4Jインスタンスの再起動後、BPELプロセスを配置し、構成したデータソースと接続プールを使用してOracle E-Bizに接続できるようになり、プロセスを起動するたびにWSDLプロパティを使用して新たに接続を作成することはなくなりました。
苦労無くすべてを得る
以上のプロセスは、すべてわずか数時間で完了しました。この時間には、Oracle EBSのAPIコール用のヘッダー変数の設定方法に目を通し、調査した時間も含まれています。 しかし、いったん完了してしまえば、Oracle E-Bizへの接続、既存のAPIの使用、サーバーの構成、BPELプロセスの配置はわずか数分で済みます。 うまくいけばこの記事で、Oracle E-Bizの資格証明をOracle E-Bizアダプタに渡す方法について調べる時間を節約できるでしょう。
|
|
|
|
WebCenter/ADFアプリケーションへのOracle Configuratorの組込み
Varun Puri、Anand Verma著[2008年3月]
Oracle Configuratorとは
Oracle Configuratorは、製品のオンライン構成を可能にして、顧客にガイド形式の販売をおこなうアプリケーションです。 Oracle Configuratorは、Oracle Order ManagementとOracle CRMの一部であり、Oracle Order ManagementとOracle CRMに搭載されているOracle iStore、Oracle Order Management、Oracle Quoting、Oracle Sales、およびOracle TeleSalesなどのアプリケーションとシームレスに統合されます。
使用方法
Oracle Configuratorは、ソース・アプリケーションにインストールされます。 Oracle Configuratorには、ソース・アプリケーションの各種製品の構成を設計するOracle Configurator Developerというコンポーネントが備わっています。 また、このアプリケーションにはサーブレットが組み込まれているため、顧客はこれを使用してアプリケーションのWebサイトにアクセスし、各自で選択した製品を構成して、構成データを送信できます。 それに対し、Configuratorサーブレットは、選択された構成に基づいて、見積りや価格などの処理情報を返します。
Oracle CRMやOracle Order ManagementなどのOracleアプリケーションでは、Oracle Configuratorがその一部としてインストールされます。一方、Oracle iStore、Oracle Quoting、Oracle Sales、Oracle TeleSalesなどのアプリケーションでは、Oracle Configuratorが標準で統合されています。
Oracle Configuratorのカスタム・アプリケーションへの統合方法
前項で述べたように、Oracle Configuratorにはサーブレットが備わっています。サーブレットは、ソース・アプリケーション（Oracle CRMやOracle Order Managementなど）で定義された製品構成にアクセスできるよう、アプリケーションに組み込む必要があります。
サーブレットの使用を開始するには、まずはサーブレットを初期化してセッションを作成する必要があります。 そのためには、XML形式の初期化メッセージを渡す必要があります。 初期化メッセージには、ブラウザにどの製品構成のUIをロードするかを決定するパラメータ・リストが含まれます。 以下に、XML形式の初期化メッセージの例を示します。
渡すことのできるパラメータはいくつか存在し、渡されるパラメータの組合せは要件によって異なります。 全パラメータの詳細については、『 Oracle Configurator Implementation Guide』を参照してください。
このデータは、 HTMLフォームを通じてConfiguratorサーブレットに送信されます。 HTMLフォームのAction属性は、 http://<host>:<port>/OA_HTML/CZInitialize.jspのように、Configuratorサーブレットを指すように設定します。 <host>と <port>には、ソース・アプリケーション（Oracle CRMやOracle Order Managementなど）にインストールされているConfiguratorサーブレットのホスト名とポート番号が入ります。 これにより、独自構成が可能な製品のUIがロードされます。 ユーザーは、構成終了後、「 Finish」ボタンをクリックします。 送信されたデータはOracle Configuratorによって処理され、Oracle Configurator UIの製品構成に基づいて、サーブレットがXML形式の 終了メッセージをreturn_urlパラメータ内で指定されたURLに渡します。 終了メッセージには、構成された製品の処理情報が含まれます。 return_urlページの開発者は、このXML形式の終了メッセージを処理して情報を抽出する必要があります。 以下に、XML形式の終了メッセージの例を示します。
この方法は、単純なJ2EEアプリケーションでは十分に機能しますが、ADFアプリケーションやWebCenterアプリケーションでは、これに加えてもうすこし作業が必要です。 ここでは、Oracle ConfiguratorをADFアプリケーションに統合する方法について、ガイドラインに従って順を追って説明します。
ADFアプリケーションとの統合
統合は、次の3つの手順で達成されます。
1. 初期化メッセージをConfiguratorサーブレットに渡すため、単純なJ2EEアプリケーションを作成し、HTMLフォームのあるページを作成します。 ページの名前はInitialization Pageとします。
2. Configuratorサーブレットから渡される終了メッセージを処理するページを作成します。 ページの名前はReturn Pageとします。
3. Initialization PageをADFアプリケーションに組み込みます。
注： 以下のガイドラインは、Oracle JDeveloperを使用してアプリケーションを開発する場合を想定していますが、その他の一般的なJava/J2EE Developer IDEを使用することもできます。
単純なJ2EEアプリケーションとInitialization Pageの作成
1. 単純なJ2EE（非ADF）アプリケーションを作成します。
2. アプリケーションに、HTMLページまたはJSPページを作成します。 このページは、Configuratorサーブレットに初期化データを送信する際に使用されます。 このページは、あとでHTMLのiframeを使用してADFアプリケーションに組み込まれます。
3. ページ内のHTMLフォームを、次のパラメータで作成します。
|
フォーム属性 |
値 |
説明 |
|
action |
http://<host>:<port>/OA_HTML/CZInitialize.jsp |
ConfiguratorサーブレットのURL |
|
method |
post |
フォームのメソッド・タイプ |
4. フォーム内に 非表示のHTMLフィールドを XMLmsgという名前で作成します。
5. 初期化メッセージのフォーム内のフィールドの値を設定します。
注： パラメータ値を動的に渡す場合は、静的なHTMLページではなくJSPページを作成する必要があります。
6. ページの <body>タグに、 onload=”document.forms[0].submit()”というJavaScriptコードを追加します。 このコードを追加すると、ページのロード時に、HTMLフォームがただちに送信されます。
7. 初期化メッセージの return_urlパラメータを、次項で作成するReturn Pageを指すように設定します。
注： return_urlパラメータ内には絶対URLを指定してください。 これは、Initialization Pageが送信されると、制御がConfiguratorサーブレットに移り、製品構成が完了すると、Configuratorサーブレットによって制御が return_urlパラメータで指定されたURLに返されるためです。
Return Pageの作成
1. 単純なJ2EEアプリケーション内に、JSPページを作成します。 このページは、ユーザーがConfiguratorサーブレットUIの「 Finish」をクリックした際に、Configuratorサーブレットが終了メッセージを渡すために使用されます。
2. 終了メッセージは、HTTPリクエスト・パラメータのXMLMsg経由で渡されます。 このメッセージは、HTTPRequestObject.getParameter(“XMLMsg”)を使用して抽出できます。
3. 次に、JavaScriptを使用してXML形式の終了メッセージを解析し、抽出されたデータをADFアプリケーションに渡す必要があります（このページはADFアプリケーションのiframeにロードされます）。
4. config_header_idパラメータと config_rev_nbrパラメータをADFページに渡します。
5. 次の図は、手始めとして使用できるJSPの例を示しています。
ADFアプリケーションへのInitialization Pageの組込み
1. Oracle Configurator機能を組み込むADFページを開きます。
2. ページ内の適切な場所に、次のようにHTMLのiframeを挿入します。
3. このADFページには、Configuratorサーブレットの処理データを移入するConfigurator Header IdフィールドとConfigurator Revision Numberフィールドの2つのフィールドがあると仮定します。
4. af:formコンポーネントを変更して、 Id属性を指定します。 Oracle JDeveloperでは、フォームのプロパティ・インスペクタを使用しておこなうことができます。 以下に例を示します。
5. 同様の方法で、Configurator Header IdフィールドとConfigurator Revision NumberフィールドのId属性を指定します。 かならず前項で作成したReturn Page（JSP）のJavaScript機能と同じIdを使用してください。
6. いったんADFページにデータを入力すれば、ADFアプリケーションでの処理に使用できます。
7. これで統合は完了です。 次に、ADFアプリケーションを実行して、Oracle Configurator UIからADFアプリケーションに渡されるデータを確認します。
画面フローの例
画面フローは、次のようになります。
ステップ1： ADFアプリケーションのiframeで、Configuratorサーブレットが開きます。
ステップ2： Oracle Configurator UIの製品を構成して、「Finish」をクリックします。
ステップ3： Configuratorサーブレットが制御をReturn PageのURLに返し、JavaScriptによりデータがADFアプリケーションに渡されます。
|
|
|
|
Oracle E-Business Suiteによる統合向けのサービス指向のアプローチ
Peeyush Tugnawat著[2008年9月]
Oracle E-Business Suite（Oracle EBS）は、現在もっとも広く使用されているエンタープライズ・アプリケーションの1つです。 Oracle EBSユーザーは、企業の内外に分散された従来のビジネス機能間のコラボレーションを向上させるという課題に頻繁に直面しています。 ベスト・オブ・ブリードの多様なアプリケーションを使用するビジネス機能から成る企業においては、この問題は何倍にも膨れ上がります。
従来のエンタープライズ・アプリケーションの統合メカニズムでは、短期目標は達成されるものの数多くの欠点が見られ、密結合的な統合やベンダー・ロックダウンが生じることも多々あります。 Oracle E-Business Suiteの統合にサービス指向の方法を採り入れることで、基本的なビジネス・ニーズを満たすことができます。 サービス指向の統合方法では、当座の要件に対応するのに加え、統合が必要となった根本的な理由についても明らかにして対応します。 それでは、Oracle EBSのSOAベースの統合ソリューションを成功させるうえで必要ないくつかの点について確認してみましょう。
基本要件への対応
ビジネス・プロセスの柔軟性とコラボレーションは、Oracle EBSやその他のエンタープライズ・アプリケーションとの統合で継続的な要件に対応していく際の原動力となります。 ビジネス・プロセスの機敏性、簡易性、可視性の向上、効率性、および再利用性という基本的な暗黙のビジネス要件を満たすためには、Oracle EBS統合時にサービス指向アーキテクチャ（SOA）に基づく方法を試してみる必要があります。 基本要件に対応できれば、いずれは既存のビジネス機能とビジネス・プロセスから成る新しいビジネス・プロセスを簡単に作成できるようになります。
Oracle EBSの組込み統合メカニズムの把握
Oracle EBSに搭載された各種統合コンポーネントを把握しておくことは、十分な情報に基づいてSOA統合プロジェクトに使用するコンポーネントを決定するためには重要です。 何を選択するかは、統合要件と最適な相互作用パターンに応じて異なります。
Oracle E-Business Suiteには、次の統合メカニズムが搭載されています。
|
Oracle XML Gateway |
Oracle E-Business Suiteでは、Oracle Workflowのビジネス・イベント・システムを使用してイベント・ベースのXMLメッセージの作成と消費を実行します。 これにより、Oracle E-Business Suiteで発生したイベントを消費し、インバウンド・イベントをサブスクライブして処理できます。 企業間（B2B）およびアプリケーション間（A2A）の統合シナリオに活用できます。 |
|
ビジネス・イベント |
Oracle Workflowのビジネス・イベント・システムは、Oracle Advanced Queuing（Oracle AQ）インフラストラクチャを使用してビジネス・イベントのシステム間通信をおこなうアプリケーション・サービスです。 Oracle EBSには、ビジネス・プロセスのイベント・ベースの統合に活用できる1,000種類を超えるイベントが組み込まれています。 |
|
コンカレント・プログラム |
コンカレント・プログラムは、実行ファイルのインスタンスです。 コンカレント・プログラムでは、正しい実行ファイルを検出する際に実行可能なコンカレント・プログラムが使用されます。 パラメータのデフォルト値が異なる複数のコンカレント・プログラムで同じ実行ファイルを使用して、特定のタスクを実行できます。 |
|
インタフェース表 |
インタフェース表は、データが最初に挿入される中間表です。 中間表に挿入されたデータは、検証後、実表に転送されます。 |
|
PL/SQL API |
Oracleアプリケーションのデータを挿入/更新するためのストアド・プロシージャです。 |
|
Oracle E-Commerce Gateway |
Oracle E-Commerce Gatewayは、Oracleアプリケーションとサード・パーティ・アプリケーション間の電子データ交換（EDI）統合で一般的に使用される標準ベースの統合方法です。 |
Oracle IREPを使用したビジネス・サービスの検出とカタログへの追加
SOAベースの統合を計画するにあたっては、設計者とビジネス・ユーザーが、統合サービスの一部として利用できるOracle EBSのサービスを把握しておく必要があります。 統合を計画し、設計する際の最初のステップは、Oracle IREPの使用です。 Oracle IREPは、Oracle EBSのビジネス・サービスとサービスのエンドポイントの詳細が記載された情報源として使用できます。 Oracle IREPを使用すれば、任意のシステム、アプリケーション、ビジネス・パートナーと統合する際に適切なビジネス・サービス・インタフェースをユーザーが簡単に検出できます。
Oracle IREPを入手するには、 http://irep.oracle.com/にアクセスしてください。 Oracle EBS Release 12をご使用の場合は、Navigatorメニューで「 Integration Repository」権限を選択し、表示される「 Integration Repository」リンクをクリックしてください。
統合アーキテクチャへのSOAの原則の採用
Oracle EBSによるサービス指向の統合では、抽象化、疎結合、発見可能性、コンポジションといったSOAの原則を使用します。 Oracle SOA SuiteにはSOAを構築、配置、管理するためのサービス・インフラストラクチャ・コンポーネント一式が備わっているため、Oracle SOA Suiteをサービス指向の統合に使用すれば、多大なメリットを得ることができます。
標準の使用
標準ベースのテクノロジーをサービス指向の統合に使用すれば、製品や企業とのロックダウンを回避できます。 そのため、統合に関連したサービスを使用するビジネス・プロセスの革新、拡張、構成が簡単になります。
サービス対応のエンタープライズ・アプリケーション機能
Oracle IREPを検討して、使用するサービスやインタフェースを把握したら、次に、その機能やサービスをサービス指向の統合アーキテクチャにWebサービスとして加える必要があります。 ビジネス・イベントやPL/SQL APIなどの統合機能をSOAベースのソリューション（統合プロセスや複合プロセス）で使用する場合、Oracle ApplicationsアダプタでそれらをWebサービスとして公開すれば、比較的簡単に使用できます。 これにより、再利用性や拡張性が向上し、設計から配置までの時間が短縮されます。 Oracle Applicationsアダプタは、既存のOracle EBS統合インタフェースをWebサービスとして公開します。 このアダプタは、J2CA、XML、WSIF、WSIL、およびWSDLなどのオープン・スタンダードを使用します。 最大のメリットは、Oracle EBSのWebサービス・ベースの統合インタフェースと連動するSOAベースの統合を設計し、開発する時間が大幅に短縮される点です。
メッセージ・ペイロードのビジネス・セマンティクス
統合サービスのメッセージ・ペイロードに含まれるビジネス・オブジェクトは、全社共通のビューとセマンティクスを共有し、中立的に設計する必要があります。 たとえば、企業内では、顧客や販売注文が1つの標準ビューのみで表示されることが必要です。 そうすれば共通用語を使用でき、再利用性、拡張性、ピラー/アプリケーション間の相互運用性が実現します。 ビジネス情報の共通ビューという概念は、一般には標準データ・モデル（CDM）パターンとして知られています。 オラクルでは、このパターンをAIAファウンデーション・パックに実装しており、エンタープライズ・ビジネス・オブジェクト（EBO）と呼んでいます。 Oracle XML Gatewayの送信メッセージの大半は、Open Applications Group（OAG）標準を使用してマッピングされます。
統合要件の分類
Oracle EBS要件を大まかに分類すると、リアルタイムの一括統合とニア・リアルタイムの一括統合の2つになります。 両統合タイプに、メッセージ交換パターンを特定する必要があります。 イベント・ベースの非同期MEPを使用すれば、両統合タイプをモデル化できます。 同期サービスは、ほかの統合方法ではSLAを満たすことができない場合や絶対に必要な場合にのみ使用してください。
非同期統合パターン
イベント・ベースの統合サービスを使用して、ニア・リアルタイムの非同期ビジネス・インタラクションを実行できます。 ビジネス・イベントをイベント駆動型アーキテクチャの基本コンポーネントとして使用して、疎結合で非同期のサービス指向統合プロセスを促進できます。 ビジネス・イベントとAQコンポーネントは、それぞれアプリケーションとAQアダプタで使用できるメカニズムを提供します。 たとえば、Oracle EBSに新規雇用情報が入力された場合、従業員作成イベントにより、アウトバウンド統合サービスをリアルタイムで起動できます。
一括統合
一括統合要件では、容量やサイズなどのトランザクション要件にかかわる要素を慎重に検討する必要があります。 一括統合要件には、通常、セキュアな場所からのファイルの読取り、データ変換、データベースへの書込みなどが含まれます。 こうした要件は、ファイル・アダプタとOracle ESBを使用して満たすことができます。 大容量のファイルには、File/FTPアダプタのサポートするデバッチ機能の使用を検討してください。 一括統合の対象に複雑なデータ整合性要件をもつ大量のデータが含まれる場合は、Oracle ODIの使用を検討してください。
サービス・レイヤー
サービスの設計時には、レイヤーを使用した設計方法を採用するのも一計です。 そうすればサービス・スタック内が明確に分離され、サービスの再利用が促進されます。 たとえば、次のようなレイヤーを検討してみます。
アプリケーション・サービス・レイヤー：特定のビジネス機能に関連するPL/SQL APIやビジネス・イベントなどのアプリケーション固有のサービスです。 PL/SQL Webサービスも含まれます。
ビジネス・サービス・レイヤー：このレイヤーのサービスは、販売注文の作成などの特定のビジネス機能をカプセル化するサービスです。 やや大まかに分類されたWebサービスであり、外部エンティティはこれを使用して、Oracle EBSでの販売注文の作成や、ほかのシステムへの新規雇用の通知などのビジネス機能を実行できます。 このレイヤーのサービスは、リソース・アダプタ（アプリケーション・アダプタ、データベース・アダプタ、AQアダプタ）とOracle ESBを使用して実装できます。
オーケストレーション・サービス・レイヤー：このレイヤーのサービスは、ビジネス・サービス・レイヤーやそのほかの外部Webサービスなどの複数のサービスから構成された、長期にわたり使用できる部門共通のプロセス・サービスです。 実際のビジネス・サービスやインタラクションに、ビジネス・プロセスを組み込むためのレイヤーや抽象化機能を提供します。 このレイヤーのサービスは、Oracle BPELを使用して、ビジネス・プロセスとパートナー間のインタラクションに基づいてビジネス・プロセスの動作を記述する際のモデルと文法を定義することにより実装できます。
SOAコンポーネントへのリジリエンスの実装：各統合プロセスにリジリエンスを構築します。 これは、最適なアーキテクチャが配置されていても見落とされがちな点です。 常に"what-if"シナリオを検討し、各統合プロセスにプロセス・レベルのリジリエンスを実装するようにしてください。
たとえば、partnerLinkBinding構成プロパティを使用して、BPELプロセスやESBプロセスに応じてエンドポイント障害に対するリジリエンスを実装できます。 retryMaxCountとretryIntervalを使用してください。
例外処理：どんなに前向きに考えても、うまくいかない場合もあります。 そこで、再利用性、拡張性、機敏性を備えたプロセス・レベルの例外処理方法や未知の例外の処理方法を定義します。 拡張可能なインタフェースで共通の例外ハンドラを使用すれば、柔軟性、再利用性、拡張性を向上できます。 こうした共通サービスは、Oracle BPELサービスとして実装できます。
サポート機能の簡易化：アプリケーションの統合に携わる者は誰でも、統合上の問題のトラブルシューティングに多大な時間と労力を注ぐことになります。 非同期メッセージングと複合サービスにより、従来のEAIサポート機能をより簡単に利用できます。
Oracle EBSでは、統合の例外処理をおこなうため、速断でカスタム表を作成してしまいがちです。 代わりに、Oracle BPELに組み込まれたヒューマン・ワークフロー機能とワークリスト・アプリケーションを活用してみてください。 例外発生時には、通知メカニズムを使用してサポート担当者に通知し、ワークリスト・アプリケーションのわかりやすい形式で詳細情報を表示して分析できます。 このヒューマン・ワークフロー機能は、サポート担当者には大変便利な機能であることが実証済みです。
人的インタラクションと人的介入：ビジネス・プロセスには、何らかの形で人的介入が必要です。 統合プロセスにそうしたロール・ベースの人的インタラクションが必要であれば、前もって計画し、標準ベースのヒューマン・ワークフロー・メカニズムを使用する必要があります。 Oracle BPELには、統合サービスの人的インタラクションをモデル化できる標準ベースのヒューマン・ワークフロー機能が備わっています。
ビジネス・ルールの分離： 統合プロセスは、ビジネス・ルールを組み込んでハードコードするのに適した場所ではありません。 PL/SQLには、ビジネス・ルールの適用や、データ検証を実行するカスタム・レイヤーを作成しないでください。 ルールを特定し、Oracle Business Rulesを使用して統合サービスとルールを疎結合してください。 これにより柔軟性が向上し、ビジネス・ユーザーがビジネス・ルールを変更できるようになるため、開発者によるPL/SQLの変更や統合サービスの再配置が不要になります。
ビジネス・プロセスの可視性：統合プロセスやビジネス・プロセスの可視化を計画します。 これは、現在、異機種混在のシステムやアプリケーション、複数のシステムの統合により実行時の可視化がきわめて困難となっているため、非常に重要な事項です。 Oracle BAMを使用すれば、ユーザー（ITスタッフとビジネス・ユーザー）が、ビジネス・プロセスと統合ポイントをリアルタイムで監視し、表示できます。
SOAガバナンス：簡単にいうと、統合サービスのサービス・ポートフォリオ内のサービスに対して、ポリシーの管理と適用の実行を計画します。 これはSOA上重要な事項であり、サービスの管理と制御を確実にするため十分に計画する必要があります。 Oracle Web Services Managerを使用して、Webサービスに対するポリシーの管理と適用を実行します。
Oracle AIA製品の確認：Oracle EBSのサービス指向の統合に真っ向から取り組む前に、まずはOracle AIA製品を確認してください。 Oracle Application Integration Architecture（Oracle AIA）には、アプリケーション共通のビジネス・プロセスを作成し、価値創出までの時間を加速化するオープン・スタンダード・ベースのフレームワークが備わっています。 Oracle AIAのプロセス統合パック（PIP）を使用すれば、事前パッケージ化された機能を使用して、Oracleアプリケーション間のエンド・ツー・エンドのビジネス・プロセスの統合を実現できます。 さらに、ファウンデーション・パックにはリファレンス・アーキテクチャと再利用可能なWebサービス・コンポーネントが搭載されているため、Oracle EBS統合時のSOA構想を加速化できます。
結論
Oracle E-Business Suiteのサービス指向の統合方法は、従来のEAI方法に比べて多大なメリットをもたらします。 エンタープライズ環境を統合すれば、サービス指向の統合アーキテクチャを構成するすべてのコンポーネントに、柔軟性、機敏性、拡張性といったきわめて基本的な原則を適用することにより、実装に依存しない、再利用可能で便利なサービスへと進化させることができます。
|
|
|
|
Oracle Enterprise Service Busを使用したOracle E-Business Suiteの統合
Jaco Verheul著[2008年3月]
はじめに
ここでは、Oracle E-Business Suiteとカスタム・アプリケーションの簡単な統合方法について説明します。 この統合方法では、Oracle Enterprise Service Busを使用します。
この統合方法は、オランダのAppstech Communityによる調査結果に基づくものです。 オラクルでは、顧客環境における標準統合シナリオをご紹介したいと考えていました。 そうした理由から、概念実証（POC）プロジェクトでの開発に向けた統合シナリオを作成しました。 ここでは、そのうちの1つについて説明します。
統合シナリオ
顧客データは、Oracle E-Business SuiteのTCAモデルで管理されます。 カスタム・アプリケーションは、新規顧客データを受信します。 Oracle E-Business Suite環境は、顧客データの情報源となります。 以下の図を参照してください。
わかりやすくするため、カスタム・アプリケーションの顧客表は非常に簡単な構成となっています。 以下の表を参照してください。
|
列 |
データ型 |
|
cust_id |
varchar2(20) |
|
cust_num |
varchar2(20) |
|
name |
varchar2(100) |
|
street |
varchar2(100) |
|
city |
varchar2(30) |
|
zip |
varchar2(6) |
|
country |
varchar2(100) |
Oracle E-Business SuiteのTCAモデルでは、データ・モデルはこれよりも複雑になります。 この統合に必要な情報は、次の表に保存されます。
· hz_cust_accounts
· hz_parties
· hz_cust_acct_sites_all
· hz_party_sites
· hz_locations
技術設計の概要
この段落では、統合方法の作成方法について説明します。 統合フローでは、以下の手順を実行します。
· 統合には、ビジネス・イベント・システムを使用します。 顧客アカウントを作成すると、oracle.apps.ar.hz.CustAccount.createというイベントが発生します。 ビジネス・イベントでは、通常、パラメータとして主要フィールド値のみが渡されます。 ここでは、CUST_ACCOUNT_IDパラメータがもっとも重要となります。
· ビジネス・イベントでは、作成された顧客アカウントのIDのみがイベント・パラメータとして渡されるため、ほかの顧客フィールドを取得してCustomerCreatedメッセージを作成する必要があります。 ビジネス・イベントのデータについては、拡充が必要です。 これは、次の2つの方法でおこなうことができます。
o ESBフローを直接トリガーするようにビジネス・イベントを設定します。 ESBフロー内で、Oracle E-Business Suiteアダプタまたはデータベース・アダプタを使用して、Oracle E-Business Suiteデータベースから必要なフィールドに問合せを実行します。
o oracle.apps.ar.hz.CustAccount.createイベントのPL/SQLイベント・サブスクリプションを作成します。このイベントでは、メッセージの作成に必要な全顧客データが取得されます。 メッセージに必要な全フィールドが追加されると、そのメッセージはカスタム・キューに配置されます。 拡充されたこのメッセージは、ESBフローのトリガーに使用されます。 このシナリオでは、PL/SQLにさらにロジックが追加されます。
· 必要なのは複数の表のデータであるため、PL/SQLのイベントの拡充は非常に簡単です。 イベント・サブスクリプションで、CustAccount.createイベントをリスニングします。CUST_ACCOUNT_IDに渡されたデータに基づいて、関連するE-Business表から、必要な全フィールドが取得されます。 メッセージは、カスタム・キューに配置されます。 このメッセージには、受信側アプリケーションに必要な列が正確に含まれています。
· アドバンスト・キュー・アダプタが、カスタム・キューの新規メッセージをリスニングします。 新規メッセージはデータベース・アダプタにルーティングされ、カスタム・アプリケーションに書き込まれます。
技術設計の詳細
この段落では、前段落の手順の詳細を説明し、コード例を紹介します。
アドバンスト・キューの設定
拡充されたメッセージを保存するカスタム・キューが必要です。 キューを作成する前に、キューのメッセージ・タイプを作成する必要があります。
キューのメッセージ・タイプ：
create or replace type xxjv_customer_t as object (
cust_id varchar2(20),
cust_num varchar2(20),
name varchar2(100),
street varchar2(100),
city varchar2(30),
zip varchar2(6),
country varchar2(100));
これは、受信側アプリケーションのオブジェクト・タイプの定義と顧客表の定義に類似しています。
メッセージ・タイプを作成したら、キューとキュー表を作成する必要があります。
キュー表の作成：
dbms_aqadm.create_queue_table( queue_table => 'xxjv_customers_sqtab', comment => 'Queue table holding customer data for integration with ESB', queue_payload_type => 'xxjv_customer_t', message_grouping => DBMS_AQADM.TRANSACTIONAL, compatible => '9.2', primary_instance => 1, secondary_instance => 2);
キューの作成：
dbms_aqadm.create_queue ( queue_name => 'xxjv_customers_new', queue_table => 'xxjv_customers_sqtab');
作成後、次のとおりキューを起動する必要があります。
dbms_aqadm.start_queue ( queue_name => 'xxjv_customers_new', queue_table => 'xxjv_customers_sqtab');イベント・サブスクリプション
カスタム・キューが配置されたので、イベント・サブスクリプションを作成できます。 以下を実行するPL/SQLファンクションが必要です。
· oracle.apps.ar.hz.CustAccount.createイベントのトリガー
· TCA表からの全必要情報の取得
· xxjv_customer_tタイプのメッセージの作成
· xxjv_customers_newキューへのメッセージの配置
PL/SQLファンクションのソースについては、付録Aの"イベント・サブスクリプションのソース"を参照してください。
ファンクションを作成したら、以下の手順に従って、Oracle E-Business Suiteのイベント・サブスクリプションを管理する必要があります。
· Workflow Administratorとしてログインします。
· 「 Business Events」ファンクションを選択します。
· oracle.apps.ar.hz.CustAccount.createイベントに問合せを実行します。
· 「 Subscription」をクリックします。 以下のスクリーンショットを参照してください。
新規サブスクリプションを作成します。 最初の画面に、以下のスクリーンショットと同じように入力します。
ただし、Systemの名前のみが異なります。
「 Next」をクリックして、次の画面に以下のスクリーンショットのとおりにデータを入力します。
Oracle E-Business Suiteの新規顧客アカウントを作成してここまでの設定をテストし、カスタム・キューにメッセージが配置されているかどうかを確認できます。
次のコードで、カスタム・キューの新規メッセージをリスニングします。 このスクリプトは、メッセージが到着するまで待機します。
SET SERVEROUTPUT ON; DECLARE queue_options DBMS_AQ.DEQUEUE_OPTIONS_T; message_properties DBMS_AQ.MESSAGE_PROPERTIES_T; message_id RAW(2000); my_message xxjv_customer_t; BEGIN -- queue_options := dbms_aq.dequeue_options_t(); queue_options.navigation:=DBMS_AQ.FIRST_MESSAGE; DBMS_AQ.DEQUEUE( queue_name => 'xxjv_customers_new', dequeue_options => queue_options, message_properties => message_properties, payload => my_message, msgid => message_id ); COMMIT; DBMS_OUTPUT.PUT_LINE( 'Dequeued cust_id: ' || my_message.cust_id); DBMS_OUTPUT.PUT_LINE( 'Dequeued cust_num: ' || my_message.cust_num); DBMS_OUTPUT.PUT_LINE( 'Dequeued zip: ' || my_message.zip); END; / SET SERVEROUTPUT ON; DECLARE queue_options DBMS_AQ.DEQUEUE_OPTIONS_T; message_properties DBMS_AQ.MESSAGE_PROPERTIES_T; message_id RAW(2000); my_message xxjv_customer_t; BEGIN -- queue_options := dbms_aq.dequeue_options_t(); queue_options.navigation:=DBMS_AQ.FIRST_MESSAGE; DBMS_AQ.DEQUEUE( queue_name => 'xxjv_customers_new', dequeue_options => queue_options, message_properties => message_properties, payload => my_message, msgid => message_id ); COMMIT; DBMS_OUTPUT.PUT_LINE( 'Dequeued cust_id: ' || my_message.cust_id); DBMS_OUTPUT.PUT_LINE( 'Dequeued cust_num: ' || my_message.cust_num); DBMS_OUTPUT.PUT_LINE( 'Dequeued zip: ' || my_message.zip); END; /
ESBフロー
カスタム・キューに拡充されたメッセージを配置するイベント・サブスクリプションが作成されたので、ESBフローを作成して統合を完了します。
以下のダイアグラムを参照してください。
左にあるデキュー操作でフローが開始されます。この操作は、カスタム・キューから読み込まれます。 設定ウィザードで、リスニングするキューの名前を設定します。
以下のスクリーンショットを参照してください。
デキュー操作により、Routing Service CustCreation_RSにメッセージが渡されます。 このルーティング・サービスにより、CustWriteToFileファイル・アダプタ（ログ作成のため）とWriteCustomerデータベース・アダプタの両方にメッセージが渡されます。
結論
ここで紹介した統合シナリオは、簡単に実行できます。 おもな特徴は、PL/SQLを拡充する点です。 Oracle E-Business SuiteとOracle SOA Suiteに関する知識がある場合、この種の統合はわずか数日間で完了します。
付録A：イベント・サブスクリプションのソース
xx_event_substファンクションは、必要な全顧客情報を読み取り、メッセージを作成してカスタム・キューに配置します。その後、Oracle ESBで残りの処理が実行されます。
-- event subscription for oracle.apps.ar.hz.CustAccount.create
-- receives cust_account_id from event
-- reads account and customer information
-- put information on custom queue for esb processing
CREATE OR REPLACE FUNCTION xx_event_subst(
p_subscription_guid IN RAW
,p_event IN OUT NOCOPY wf_event_t)
RETURN VARCHAR2 IS
l_user_name VARCHAR2(100);
l_user_id INTEGER;
cursor c_cust (b_cust_id number) is
SELECT c.cust_account_id cust_id
, p.party_number cust_num
, p.party_name name
, l.address1 street
, l.city
, l.postal_code zip
, l.country
FROM hz_cust_accounts c JOIN hz_parties p ON (c.party_id = p.party_id)
JOIN hz_cust_acct_sites_all ca ON (c.cust_account_id=ca.cust_account_id)
JOIN hz_party_sites ps ON (ca.party_site_id = ps.party_site_id)
JOIN hz_locations l ON (l.location_id = ps.location_id)
WHERE c.cust_account_id = b_cust_id;
r_cust c_cust%rowtype;
l_cust_account_id number;
queue_options DBMS_AQ.ENQUEUE_OPTIONS_T;
message_properties DBMS_AQ.MESSAGE_PROPERTIES_T;
message_id RAW(16);
my_message xxjv_customer_t;
BEGIN
l_cust_account_id := p_event.getvalueforparameter('CUST_ACCOUNT_ID');
open c_cust (l_cust_account_id);
fetch c_cust into r_cust;
close c_cust;
my_message := xxjv_customer_t(
r_cust.cust_id,
r_cust.cust_num,
r_cust.name,
r_cust.street,
r_cust.city,
r_cust.zip,
r_cust.country
);
DBMS_AQ.ENQUEUE(
queue_name => 'xxjv_customers_new',
enqueue_options => queue_options,
message_properties => message_properties,
payload => my_message,
msgid => message_id);
RETURN 'SUCCESS';
END;
/
Printer View