| Oracle® Fusion Middleware Oracle SOAコア拡張機能開発者ガイド 12c (12.1.3) E54313-02 |
|
 前 |
 次 |
この章では、変換マップの概要を示し、変換マップの作成方法、ドメイン値マップ(DVM)と相互参照の使用方法およびエンタープライズ・ビジネス・メッセージ(EBM)ヘッダーへの値の入力方法について説明します。
この章の内容は次のとおりです。
変換マップは、データの形状および意味の観点で、ソースまたはターゲット・アプリケーションで必要とされるドキュメントが、ソースまたはターゲット・アプリケーションによって生成されるドキュメントと異なる場合に使用します。変換マップによって、その構造的および意味的な相違を解決します。
Oracle Application Integration Architecture (AIA)では、正規パターンおよび直接パターンを利用して、ビジネス・プロセスを実装するためにアプリケーションを接続します。
AIAには、エンタープライズ・ビジネス・オブジェクト(EBO)と呼ばれる一連の汎用データ構造が導入されています。EBOは、勘定科目、受注、品目など、ビジネス概念の共通オブジェクト定義を表します。ビジネス統合プロセスは、完全なEBOまたはEBOのサブセットであるメッセージに対してのみ効果があります。このアプローチによって、参加アプリケーションから独立した産業間共通のアプリケーション・プロセスにできます。EBOには、ターゲット・アプリケーション・データ・モデルからビジネス・オブジェクトの要件を満たすコンポーネントが格納されます。変換によって、アプリケーション・ビジネス固有のメッセージが、AIA正規データ・モデルであるEBMにマップされます。
図16-1に、正規パターンがどのようにAIAに実装されるかを示します。
図16-1 AIAに実装された正規パターン
データ統合に大量のレコードまたは大型のデータが含まれる場合は、再利用性とのトレードオフによって高いパフォーマンスでのデータの移動を専門的に取り扱う直接統合を実装するように選択できます。直接統合には、データの分離ではなく実装の分離のみに集中するバルク処理およびトリクル・フィードを含めることが可能です。
バルク処理の場合は、ETLツールが使用され、変換はツールを使用してデータ・レイヤーで実行されます。アプリケーション非依存オブジェクトがトリクル・フィードの実装に使用されることはありませんが、リクエスタ・アプリケーションでは、プロバイダ・アプリケーションで必要とされるデータ形状になるように引き続きコンテンツを変換する必要があります。
詳細は、「バルク処理に対するOracle Data Integratorの使用」を参照してください。
変換マップの作成には、XSLTボキャブラリを使用することをお薦めします。
JDeveloperのXSLTマッパーを使用すると、Oracle BPEL Process ManagerまたはOracle Mediatorを使用して開発されたサービスのコンテキスト内でソース・スキーマ要素とターゲット・スキーマ要素間のデータ変換を作成できます。
マップ・ファイルの内容は、XSLTマッパー変換ツールを使用して作成します。図16-2に、XSLTマッパーのレイアウトを示します。
図16-2 XSLTマッパーのレイアウト
XSLTマッパーの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のXSLTマッパーでの変換の作成に関する項を参照してください。
統合プロセスに対して統合オブジェクトを構成するステップの1つは、内部統合オブジェクトのコンポーネントおよびフィールドを外部統合オブジェクトのメッセージ要素にマップすることです。これらのマップを使用して、ある統合オブジェクトから別の統合オブジェクトにデータを移動します。
変換マップを作成する場合は、次のガイドラインを考慮してください。
不要または冗長なAIAConfigurationProperties.xml参照コールを作成しないでください。
静的な構成プロパティは、変換の最初に1回取得します。
AIAConfigurationProperties.xmlを使用してデプロイメント時の構成を外部化するには、「$SOA_HOME/aia_instances/$INSTANCE_NAME/AIAMetaData/configでのAIAConfigurationProperties.xmlの使用方法」を参照してください。
設計には無限ループが含まれていないことが必要です。
コンポーネントごとに変換マップを開発します。
アプリケーション全体で使用できる再使用可能なコンポーネント固有の変換マップを作成してください。
すべてのカスタム要素に対して変換テンプレートを作成します。
変換マップは常に整理された状態にしておきます。
ドメイン値マップは静的参照のためにのみ使用し、構成または設定データの格納には使用しないでください。
例16-1に、通貨コードをフェッチするドメイン値マップ参照コールを示します。ドメイン値マップは、通貨コード、場所コードなどの静的参照コールにのみ使用してください。
例16-1 通貨コードをフェッチするドメイン値マップ参照コール
<corecom:PreferredFunctionalCurrencyCode>
<xsl:value-of select="dvm:lookupValue('oramds:/apps/AIAMetaData/dvm/CURRENCY_
CODE.dvm',$SenderSystemId,/xsdLocal:ListOfCmuAccsyncAccountIo/xsdLocal:Account/
xsdLocal:CurrencyCode,$TargetSystemId,'')"/>
</corecom:PreferredFunctionalCurrencyCode>
変換ロジックおよびxpathは、例16-2に示すように、欠落または空の要素がある可能性を考慮して設計する必要があります。
この例では、空の要素をチェックするif条件があります。このような変換ロジックを採用し、ワイヤ全体で空の要素のトランスポートを回避してください。
例16-2 欠落または空の要素を処理するように設計されたロジックを示すサンプル・コード
<xsl:iftest="normalize-
space="/xsdLocal:ListOfCmuAccsyncAccountIo/xsdLocal:Account/xsdLocal:AccountId/
text() )">
<corecom:ApplicationObjectKey>
<corecom:ID>
<xsl:value-of
select="/xsdLocal:ListOfCmuAccsyncAccountIo/xsdLocal:Account/xsdLocal:
AccountId"/>
</corecom:ID>
</corecom:ApplicationObjectKey>
</xsl:if>
オプションのソース・ノードをオプションのターゲット・ノードにマップする場合は、ソース・ノードが存在するかどうかをテストするxsl:if文でマッピングを囲みます。このように処理しないと、例16-3に示すように、入力ドキュメントにソース・ノードが存在しない場合は、ターゲット・ドキュメントに空のノードが作成されます。
PHONEフィールドがソースとターゲットの両方でオプションであり、WorkContactNumberがソース・ドキュメントに存在しない場合は、ターゲット・ドキュメントに空のPHONE要素が作成されます。この状況を回避するには、例16-4に示すように、ターゲット・ノードの作成前に、ソース・ノードが存在するかどうかをテストするif文を追加します。
例16-3 xsl:Ifを使用しない文
<portal:PHONE>
<xsl:value-of
select="corecom:Contact/corecom:ContactPhoneCommunication[1]/corecom:
PhoneCommunication/corecom: WorkContactNumber"/>
</portal:PHONE>
例16-4 xsl:Ifを使用した文
<xsl:if
test="corecom:Contact/corecom:ContactPhoneCommunication[1]/corecom:
PhoneCommunication/corecom:WorkContactNumber">
<portal:PHONE>
<xsl:value-of
select="corecom:Contact/corecom:ContactPhoneCommunication[1]/corecom:
PhoneCommunication/corecom:WorkContactNumber"/>
</portal:PHONE>
</xsl:if>
例16-5に示すように、ABCSおよびXSLスクリプトには、特定の単一論理アプリケーション・インスタンスに対して機能するようなハードコード化を適用しないでください。XSLスクリプトおよびABCSには、ハードコード化されたシステムIDを挿入しないでください。
適切なアプローチは、例16-6に示すように、システムIDを動的にロードする方法です。
例16-5 ハードコード化されたシステムIDを示すサンプル・コード - 非推奨
<corecom:PreferredFunctionalCurrencyCode>
<xsl:value-of
select="dvm:lookupValue('oramds:/apps/AIAMetaData/dvm/CURRENCY_CODES.
dvm','SEBL_01',
/xsdLocal:ListOfCmuAccsyncAccountIo/xsdLocal:Account/xsdLocal:CurrencyCode,
'COMMON','")"/>
</corecom:PreferredFunctionalCurrencyCode>
例16-6 ハードコード化されたシステムIDではなく変数の使用を示すサンプル・コード - 推奨
<corecom:PreferredFunctionalCurrencyCode>
<xsl:value-of select="dvm:lookupValue('oramds:/apps/AIAMetaData/dvm/CURRENCY_
CODES.dvm',$SenderSystemId,/xsdLocal:ListOfCmuAccsyncAccountIo/xsdLocal:
Account/xsdLocal:CurrencyCode,$TargetSystemId'")"/>
</corecom:PreferredFunctionalCurrencyCode>
BPELおよびOracle Mediatorでは、XSLTでドキュメント全体を横断する必要がある場合は、メモリー不足のエラーが発生する可能性があるため、大規模なペイロードにXSLT変換を適用しないことをお薦めします。
すべてのEBMにはlanguagecode要素の値を入力し、リクエストを送信する必要があるロケールを指定する必要があります。言語依存データ要素の値がEBMルート要素に設定された値と異なる場合は、その要素にlanguageCode属性の値を入力しておく必要があります。DataAreaに指定されたlanguageCodeが優先されます。
EBMヘッダーを含め、EBMのすべてのコンポーネントには、必要な要素を追加するように構成できるカスタム領域があります。次の項のガイドラインを使用して、拡張機能を提供するコア変換XSLファイルを開発してください。
EBMヘッダーの詳細は、「EBMヘッダー概念の概要」を参照してください。
変換マップ拡張機能を使用できるようにする手順は、次のとおりです。
変換ごとに拡張XSLファイルを作成します。
PurchaseOrder_to_PurchaseOrder.xslは、コア変換XSLファイルの一例です。
すべてのコアXSLファイル名には、たとえば、PurchaseOrder_to_PurchaseOrder_Custom.xslなど、単一の拡張XSLファイルがあります。
メッセージ内のすべてのコンポーネントに対して、拡張ファイルに空の名前付きテンプレートを定義します。
コア変換ファイルに拡張ファイルを組み込みます。
コア変換の各コンポーネントに対してcall-templateを追加します。
例16-7に示すように、カスタム要素の変換に変換で対応できるようにします。
例16-7 カスタム要素の変換に対応可能な変換
<!-XSL template to transform Address-->
<xsl: template name="Core_AddressTemplate">
<xsl:param name = "context" select ="."/>
<xsl:param name = "contextType" select ="'CORE'"/>
<address1><xsl:value-of select="$context/address1"><address1>
<address2><xsl:value-of select="$context/address1"></address2>
<city><xsl:value-of select="$context/city"></city>
<state><xsl:value-of select="$context/state"></state>
<zip><xsl:value-of select="$context/zip"></zip>
<xsl:if test="$contextType!='CORE'">
<xsl:call-template name="Vertical_AddressTemplate">
<xsl:with-param name="context" select="$context"/>
<xsl:with-param name="contextType" select="$contextType">
</xsl:call-template>
</xsl:if>
</xsl: template>
顧客固有のスキーマ拡張機能に関連するマッピング・ルールは、そのxsl拡張テンプレートに定義されます。
変換テンプレートの業種を拡張可能にする手順は、次のとおりです。
例16-8 業種拡張可能な変換テンプレート
<xsl: template name="Core_AddressTemplate">
<xsl:param name = "context" select ="."/>
<xsl:param name = "contextType" select ="'CORE'"/>
<address1><xsl:value-of select="$context/address1"><address1>
<address2><xsl:value-of select="$context/address1"></address2>
<city><xsl:value-of select="$context/city"></city>
<state><xsl:value-of select="$context/state"></state>
<zip><xsl:value-of select="$context/zip"></zip>
<xsl:if test="$contextType!='CORE'">
<xsl:call-template name="Vertical_AddressTemplate">
<xsl:with-param name="context" select="$context"/>
<xsl:with-param name="contextType" select="$contextType">
</xsl:call-template>
</xsl:if>
</xsl: template>
この項では、DVM、相互参照、ネーミング標準、およびそれらを使用する場合について説明します。
ドメイン値は静的参照にのみ使用します。構成または設定データの保存には使用しないでください。パラメータ化された構成情報の格納および取得には、個別の機能が用意されています。
実行時にDVMにアクセスするには、JDeveloper XSLマッパーにあるlookup-dvm XSL関数を使用します。
DVMは、データベース永続性を使用するMDSリポジトリに格納され、JDeveloperまたはSOAコア拡張機能に用意されているツールを使用して管理されます。
ネーミング標準の詳細は、「AIA開発でのOracle AIAネーミング標準」を参照してください。
DVMは3つのグループに分類できます。
可能な値はすべてシードされ、なにも定義できません。
これらの値にはロジックが追加され、そのロジックは参加アプリケーションによって定義されるため、値は追加できません。
参加アプリケーションに存在するシード値に基づいて、すべてまたはいくつかのサンプルがシードされています。
参加アプリケーションにさらに追加可能で、DVMに途中でさらに追加して対応できます。
通常、これらの値にロジックは追加されません。照合によって値を取得して受信側アプリケーションに渡します。参加アプリケーションで定義した可能な値すべてが含まれるように、リストを拡張する必要があります。
カスタマイズされています。
依存する列を追加した場合に備えて、独自のDVMタイプおよび値を定義するように、命名規則が用意されています。これらのタイプまたは値はアップグレード時に影響を受けません。
相互参照表に相互参照仮想表を作成する場合は、次の項に記載されているネーミング標準に従います。
ABCSの中心的な設計タスクの1つは、疎結合アプリケーションからの一意の識別子に対する相互参照を維持することです。
AIAでは、階層的な相互参照はサポートしていません。子オブジェクトの共通キーは、親のコンテキスト管理下になく、それ自体で一意です。子オブジェクトには、共通IDに使用されるGUIDを備えた相互参照表内に独自のエントリがあります。
相互参照APIではマルチパート・キーをサポートしていません。アプリケーションに単一の一意キーがない場合は、キーを連結することをお薦めします。
{Key1}::{Key2}::Key3
ほとんどのリクエスタABCSは、次のロジックを変換で使用します。
相互参照は、EBMオブジェクト識別要素およびOracle Mediatorが提供する相互参照API (Xrefの入力、Xrefの参照、Xrefの削除)を使用して実行されます。
表16-1に、ポータルBRMとSiebel CRMシステム間での製品同期シナリオに実装された相互参照構成をリストします
表16-1 相互参照構成
| エンティティ | Siebel CRM ID | 共通ID | Oracle BRM ID |
|---|---|---|---|
アイテムID |
製品ID |
自動生成されたGUID |
製品ID |
価格帯ID |
価格帯ID |
自動生成されたGUID |
製品ID |
ITEM_IDは、BRM (ポータル) ProductIDとSiebel ProductIDを相互参照します。
PRICELINE _IDは、BRM (ポータル) 製品IDをSiebel PriceLineIDに対して相互参照します。
Oracle SOA Suiteは、次のコンポーネントで構成される相互参照インフラストラクチャを提供します。
様々な相互参照オブジェクト・タイプを格納する仮想表が含まれている単一のXrefデータベース表と、データをインポート/エクスポートするコマンド行ユーティリティ。
相互参照の問合せ、追加および削除を実行するXPath関数。
ネーミング標準の詳細は、「AIA開発でのOracle AIAネーミング標準」を参照してください。
相互参照の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の相互参照の操作に関する項を参照してください。
各EBMには、情報を識別するオブジェクトのインスタンスを保持するために、少なくとも1つの要素があります。複数のオブジェクトに関する詳細が格納されたEBMには、各オブジェクトの詳細を識別するオブジェクト・インスタンスを保持するために専用の要素を確保できます。EBMには、全体的なオブジェクト内に埋め込まれたビジネス・コンポーネントの最上位レベル・オブジェクトのインスタンスおよび子と孫のインスタンスを一意に識別するスキームがあります。識別スキームは、最上位レベル・インスタンスの識別(例: オーダー・インスタンス識別)か、孫インスタンスの識別(例: スケジュール明細品目識別)であるかに関係なく同じです。
一般的なプラクティスは、共通コンポーネント・スキーマ・モジュールで使用可能にされる識別タイプというデータ・タイプに定義されている識別テーマを採用することです。各オブジェクトは、様々なアプリケーションおよび統合レイヤーに表現を保持できます。各表現は、識別キーを使用して一意に識別されます。たとえば、Siebelアプリケーションでは、オーダー番号でオーダーIDまたはオーダー・インスタンスのいずれかを一意に識別でき、一方、PeopleSoftアプリケーションでは、オーダー・インスタンスがビジネス・ユニットとオーダーIDの組合せで一意に識別されます。
例でわかるように、様々なアプリケーションおよびシステムにあるこれらの表現の識別キーはかなり異なっています。識別タイプを使用して、単一オブジェクト・インスタンスに対するこれらの表現の識別キーを取得できます。図16-3に、識別タイプのスキーマ定義を示します。
図16-3 識別タイプ要素の構造
識別タイプ構造では、1つのオブジェクトに対して、3つの特定の識別子と1つの汎用識別子を取得できます。表16-2に、各識別子を示します。
表16-2 識別タイプ構造の識別子
| 名前 | 目的 | 詳細 |
|---|---|---|
BusinessComponentID |
オブジェクト・インスタンスのアプリケーション非依存表現の一意キー |
Oracle AIAアプリケーションで生成されたビジネス・ドキュメントにBusinessComponentIDの値を入力しておきます。 BusinessComponentIDは、Oracle AIAインフラストラクチャによって提供されるAPIを使用して生成されます。 |
ID |
参加アプリケーションに存在するこのオブジェクト・インスタンスに対するビジネス・フレンドリな識別子 |
Oracle AIAアプリケーションで生成されたビジネス・ドキュメントに適用可能なかぎり値を入力しておきます。 例: PO番号、オーダー番号。 |
ContextID |
IDの追加の修飾子を識別するためのオプションの要素。マルチパート・キーに使用され、たとえば、品目がセット内で一意の場合、品目番号はID、SetID値はContextID値 |
Oracle AIAアプリケーションで生成されたビジネス・ドキュメントに適用可能なかぎり値を入力しておきます。 例: セットのSetID |
ApplicationObjectKey |
このオブジェクト・インスタンスに対して内部的に生成された参加アプリケーション固有の一意の識別子 |
Oracle AIAアプリケーションで生成されたビジネス・ドキュメントでこの情報を入力します。 参加アプリケーションのオブジェクトの主キーを表します。 |
AlternateObjectKey |
オブジェクトのインスタンスを識別する別の1つ以上の方法。 |
オプション 必要に応じてこの要素を使用し、その他の識別詳細を取得します。 |
識別子が有効なコンテキストを識別するために、実際のキー値に加え、キーのコンテキストを記述する一連の属性がサポートされています。
表16-3に、各属性の目的を示します。
表16-3 キー・コンテキスト属性
| 名前 | タイプ | 説明 |
|---|---|---|
BusinessComponentID/ID ApplicationObjectKey/ID AlternateObjectKey/ID |
要素 |
実際のオブジェクトIDの格納に使用される要素。 |
schemeID |
オプションの属性 |
識別子の識別スキーム。 schemeID属性は、IDで識別されるオブジェクト・タイプに関する情報を提供します(たとえば、品目のGUIDに対するItemGUID、関係者のGUIDに対するPartyGUID)。 BusinessComponentIDの場合、schemeIDにはオブジェクト名の後ろにGUIDが付く名前が設定されます。IDの場合、schemeIDには参加アプリケーションで認識されている要素の名前が設定されます。 |
scheme VersionID |
オプションの属性 |
識別スキームのバージョン。 |
schemeAgencyID |
オプションの属性 |
識別子の識別スキームを管理するエージェンシのID。 Oracle AIAによって生成されたGUIDには、この属性にAIA 01が入力されます。参加アプリケーションによって生成された識別子の場合は、参加アプリケーションの識別子に対する短縮コードがこの属性に格納されます。 |
図16-4に、ビジネス・コンポーネントIDを示します。
図16-4 ビジネス・コンポーネントIDの構造
例16-9に、EBMでのBusinessComponentIDの入力の例を示します。
例16-9 EBMによって入力されたBusinessComponentID
<telcoitem:Identification> <corecom:BusinessComponentID mlns:corecom="http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V1" schemeID="ITEM_ID_COMMON" schemeAgencyID="AIA_ 20">31303838373539343330313937393531 </corecom:BusinessComponentID> <corecom:ID xmlns:corecom="http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V1" schemeID="ItemNumber" schemeAgencyID="PORTAL">0.0.0.1 /product 349330 1</corecom:ID> <corecom:ApplicationObjectKey xmlns:corecom="http://xmlns.oracle.com/Enterpriser Objects/Core/Common/V1"> <corecom:ID schemeID="PortalPoid" schemeAgencyID="PORTAL">0.0.0.1 /product 349330 1</corecom:ID> </corecom:ApplicationObjectKey> </telcoitem:Identification>
corecom:Identificationまたはその派生では、次のガイドラインに従ってください。
CommonのSchemeAgencyIDはCOMMONです。
ID/ContextID/ApplicationObjectKeyのSchemeAgencyIDは、exsl:node-set ($senderNodeVariable)/IDと同じで、lookupXrefおよびlookupDVMの列名としても使用されます。
BusinessComponentIDのスキームIDは、lookupXref/populateXrefのXrefTableNameと同じです。
ABCSおよびエンタープライズ・ビジネス・サービス(EBS)によって処理されるすべてのEBMには、オブジェクト固有の情報に加え、EBMヘッダーが含まれています。EBMヘッダーの目的は、次のために使用可能な情報を伝達することです。
重要な情報の追跡
監査
ソース・システムとターゲット・システムの指定
エラーおよびトレースの処理
図16-5に、EBMヘッダーの構成要素を示します。
図16-5 EBMヘッダーの構成要素
次の各項では、各構成要素について詳細に説明します。
この項では、メッセージ・ヘッダーの標準的な要素について説明します。
例16-10に示すように、この要素には、EBMを一意に識別するGUIDが格納されます。GUIDは、用意されている標準のXPath関数を使用して生成されます。
GUIDを生成するXPath関数: orcl:generate-guid()
例16-10 EBMID
<EBMHeader> <EBMID>33303331343032313534393138393830</EBMID> . . . </EBMHeader>
例16-11に示すように、この要素には、{namespaceURI}localpartという表記で完全修飾されたEBO名が格納されます。
例16-11 EBO名
<EBMHeader>
<EBOName>{http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/Invoice/V1}Query
Invoice</EBOName>
. . .
</EBMHeader>
例16-12に示すように、この要素には、送信元のリクエストIDを一意に識別するための送信元のリクエストGUIDが格納されます。EBSでは、レスポンス・メッセージのこのフィールドをリクエスト・メッセージから抽出して値を設定します。
例16-12 RequestEBMID
<EBMHeader> <RequestEBMID>33303331343032313534393138393830</RequestEBMID> . . . </EBMHeader>
例16-13に示すように、この要素には、EBMが作成された時点のタイムスタンプが格納されます。タイムスタンプはUTCで表現し、現在の日時とGMTからの時差で、次のように表現します。
yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s +)? (zzzzzz)?
XPath function to generate CreationDateTime:
xp20:current-dateTime()
例16-13 CreationDateTime
<EBMHeader> <CreationDateTime>200 7-04-2 7T12:22:17-08:00</CreationDateTime> . . . </EBMHeader>
例16-14に示すように、この要素には、EBMで表見された動詞が格納されます。
例16-14 VerbCode
<EBMHeader> <VerbCode >Query</VerbCode> . . . </EBMHeader>
この要素には、メッセージを処理する方法の指示が格納されます。このセクションは、EBMが、標準的な処理経路を通る必要がある本番システム・レベルのメッセージであるか、テストまたはシミュレーション用の処理経路を通る必要があるテストレベルのメッセージであるかを示します。
MessageProcessingInstructionには、2つのフィールドがあります。
EnvironmentCode:
CAVSまたはPRODUCTIONに設定します。デフォルトはPRODUCTIONです。値をPRODUCTIONに設定することは、リクエストを具体的なエンドポイントに送信する必要があることを示します。値をCAVSに設定することは、リクエストをCAVSシミュレータに送信する必要があることを示します。
DefinitionID:
テスト用の定義IDを指定します。
AIAConfigurationProperties.xmlのRouting.[PartnerlinkName].RouteToCAVSプロパティがtrueに設定されている場合は、AIAConfigurationProperties.xmlのRouting.[PartnerlinkName].CAVS.EndpointURIプロパティの値が入力されます。
メッセージを作成するときは常に標準的なヘッダー要素の値を入力する必要があります。次の場合が該当します。
リクエスタABC実装サービスでアプリケーション・リクエストABMをEBMに変換する場合。
プロバイダABC実装サービスでアプリケーション・レスポンスABMをEBMに変換する場合。
メッセージ処理の指示を入力する手順は、次のとおりです。
メッセージの処理方法を示す指示を追加します。
例16-15に示すように、通常は、本番モードまたはシミュレーション/テスト・モードのどちらでメッセージを実行するかをシステムに伝えるために、この指示を使用します。
これらのフィールドは、現在はCAVSで値が入力されます。
通常、フィールドは、テスト用のリクエストを開始する前に、SOAPヘッダーに値が入力されます。
例16-15 メッセージ処理の指示の入力
<corecom:MessageProcessingInstruction>
<corecom:EnvironmentCode>
<xsl:text disable-output-escaping="no">Production</xsl:text>
</corecom:EnvironmentCode >
</corecom:MessageProcessingInstruction>
図16-6に示すように、Senderには送信元アプリケーション・システムに関する情報が格納されます。
図16-6 Sender要素の構造
表16-4に、Sender要素の各要素について詳細を提供します。
表16-4 Sender要素の各要素
| 要素 | 説明 |
|---|---|
ID |
送信側システム識別子コードが格納されます。これは必須要素です。この要素は各ソース・システムの一意の識別子を表します。この値を入力するには、ReqABCSImplから例16-16に詳細が記載されているAPIをコールする必要があります。 |
説明 |
送信側システムの詳細な説明です。この値を入力するには、ReqABCSImplから例16-16に詳細が記載されているAPIをコールする必要があります。 |
IPAddress |
送信側システムのIPアドレスを表します。この値を入力するには、詳細が記載された後述のAPIをReqABCSImplからコールする必要があります。 |
SenderMessageID |
送信側システムによって送信されたメッセージを一意に識別できるIDです。この情報がReqABCSImplに確保されている場合もあり、その情報を使用してこの要素の値の入力できます。 |
Transaction Code |
このメッセージの生成に使用された送信側システムのタスク・コードです。ReqABCSImplがこの情報を保持し、EBMを準備する際に使用されます。 |
CallingServiceName |
ABCSのコール元の名前。ソースABCSによって値が入力されます。 |
Application |
送信元アプリケーションに関する情報を保持します。 |
Application/ID |
送信側システムは、この要素の送信元アプリケーション・コードを指定できます。この値を入力するには、ReqABCSImplから例16-16に詳細が記載されているAPIをコールする必要があります。 |
Application/Version |
送信側システムは、この要素の送信元アプリケーションのバージョンを指定できます。この値を入力するには、ReqABCSImplから例16-16に詳細が記載されているAPIをコールする必要があります。 |
例16-16 Sender要素のコード・サンプル
<corecom:Sender>
<corecom:ID>SEBL_01</corecom:ID>
<corecom:Description/>
<corecom:IPAddress/>
<corecom:SenderMessageID>33303331343032313534393138393830</corecom:
SenderMessageID>
<corecom:CallingServiceName>{http://xmlns.oracle.com/SampleSiebelApp}
CreateCustomerSiebelInputFileReader</corecom:CallingServiceName>
<corecom:Application>
<corecom:ID/>
<corecom:Version>1.0</corecom:Version>
</corecom:Application>
<corecom:ContactName/>
<corecom:ContactEmail/>
<corecom:ContactPhoneNumber/>
</corecom:Sender>
この要素は、ソース・アプリケーションで開始されたメッセージを一意に識別します。インバウンド・リクエスト・メッセージは、この要素に対する潜在的なソースの1つです。アプリケーション・ビジネス・メッセージ(ABM) (ソース・アプリケーションによって送信されたペイロード)は、ペイロードでSenderMessageIDに値を入力しておくか、ABMヘッダーに格納できます。ReqABCSImplでのABMからEBMへのインバウンド・メッセージ変換時に値が入力されます。
その後、この情報は、コンテキストを設定するために、同じ送信側アプリケーションにメッセージを送信する予定のダウンストリーム・サービスによって使用されます。
EBMを作成するときは常に送信側システム情報を入力する必要があります。次の場合が該当します。
リクエスタABC実装サービスでリクエストABMをEBMに変換する場合。
プロバイダABC実装サービスでレスポンスABMをEBMに変換する場合。
送信側システム情報を入力する手順は、次のとおりです。
次のXPath関数を使用して、システムID/コードに基づいてAIAシステム登録リポジトリから送信側システムの情報を取得し、データをXMLノードセットとして返します。
ebh:getEBMHeaderSenderSystemNode(senderSystemCode as string, senderSystemID as string, ) return senderSystem as node-set
senderSystemCodeまたはsenderSystemIDのいずれかを渡します。
この関数によって、コードまたはIDに基づいてAIAシステム登録リポジトリのシステム情報が検索されます。
TransactionCodeを使用して、送信側メッセージを生成した送信側システムの操作を識別します。
インバウンド・リクエスト・メッセージは、この要素に対する潜在的なソースの1つです。
コンテキストを保持するために、フォルト・ハンドラの捕捉でAIAFaultMessageを作成する際に、この要素の値が使用されます。
その後、この情報は、コンテキストを設定するために、同じ送信側アプリケーションにメッセージを送信する予定のダウンストリーム・サービスによって使用されます。
この要素は送信側システムの連絡先の名前です。参照を実行することで、値がAIAシステム登録リポジトリから取得されます。この値を入力するには、ReqABCSImplから例16-16に詳細が記載されているAPIをコールする必要があります。この情報は、フォルト・メッセージで、またはダウンストリーム・サービスによって外部ビジネスに送信されるリクエスト・メッセージで使用可能になります。
この要素は送信側システムの連絡先の電子メールです。参照を実行することで、値がAIAシステム登録リポジトリから取得されます。この値を入力するには、ReqABCSImplからAPIをコールする必要があります。この情報は、フォルト・メッセージで、またはダウンストリーム・サービスによって外部ビジネスに送信されるリクエスト・メッセージで使用可能になります。
この要素は送信側システムの連絡先の電話番号です。参照を実行することで、値がAIAシステム登録リポジトリから取得されます。この値を入力するには、ReqABCSImplからAPIをコールする必要があります。この情報は、フォルト・メッセージで、またはダウンストリーム・サービスによって外部ビジネスに送信されるリクエスト・メッセージで使用可能になります。
この要素は、図16-7に示すように、ソース・アプリケーションからの追加の情報の転送に対応します。送信側システムから渡されるデータの一部は、EBMメッセージのライフ・サイクルを通じて転送される必要があり、ターゲット・システムを識別して処理する際に必要となります。ターゲットのアプリケーション・ビジネス・メッセージ(ABM)には、このような種類のデータに対するプレースホルダがない場合もあります。このような各要素に対するプレースホルダを提供することは強制できないため、このエンタープライズ・サービス・バス(ESB)ヘッダーをこの情報の保持に使用します。ESBには名前と値のペアがあり、この構成要素にはこのような要素を必要に応じて確保できます。
図16-7 ESBHeaderExtension要素の構造
表16-5に、ESBHeaderExtension要素の各要素を示します。
表16-5 ESBHeaderExtension要素の各要素
| 要素 | 説明 |
|---|---|
ESBHeaderExtension/Name |
ESBヘッダーの要素名はIDと同じです。EBMヘッダーのシナリオでは複数の名前を使用できますが、IDと同じ値は1つのみです。 このフィールドには、EBMヘッダーのライフ・サイクル内のどの変換でも値を入力できます。 |
ESBHeaderExtension/DataTypeCode |
ESBヘッダー要素のデータ・タイプは、ソースABCSによって入力されます。 |
ESBHeaderExtension/Value |
ESBヘッダー要素の値は、ソースABCSによって入力されます。データ・タイプごとに異なるプレースホルダを使用できますが、簡単にするために、この要素にのみ値が入力されます。 このフィールドには、EBMヘッダーのライフ・サイクル内のどの変換でも値を入力できます。 |
図16-8に、ESBHeaderExtension要素の構造を示します。
図16-8 ESBHeaderExtension要素の構造
図16-9に示すように、この構成要素には、送信側オブジェクトの識別子情報と、対応する相互参照の識別子が格納されます。EBMはバルク処理に使用できるため、この要素を繰り返すこともできます。このデータをデータ領域で繰り返すこともできますが、これらに関するXPathの位置情報を一定に保つため、ここに保持されます。ReqABCSImplを使用してこの値を入力します。
図16-9 ObjectCrossReference要素の構造
表16-6に、ObjectCrossReference要素の各要素を示します。
表16-6 ObjectCrossReference要素の各要素
| 要素 | 説明 |
|---|---|
ObjectCrossReference/SenderObjectIdentification |
オブジェクトのすべてのキー・フィールド名およびキー・フィールド値が格納されます。データは送信側システムによって提供されます。 この情報はReqABCSImplによって保持され、この値が入力されます。 |
ObjectCrossReference/SenderObjectIdentification/ID |
送信側システムのオブジェクト・タイプ(たとえば、ORDER)を識別します。この情報はReqABCSImplによって保持され、この値が入力されます。 |
ObjectCrossReference/SenderObjectIdentification/Name |
送信側システムの説明(たとえば、注文書)を識別します。 この情報はReqABCSImplによって保持され、この値が入力されます。 |
ObjectCrossReference/SenderObjectIdentification /ContextID |
送信側システムのオブジェクト識別子を識別します。送信側のオブジェクトに複数の値がある場合は、これを複数回繰り返します。キー名の設定にはschemeID属性を使用し、キーの値が要素自体に格納されます。この情報はReqABCSImplによって保持され、この値が入力されます。 |
ObjectCrossReference/EBOID |
対応する相互参照の識別子で、統合レイヤーに格納されます。 この情報はReqABCSImplによって保持され、この値が入力されます。 |
相互参照エントリを送信側システムのObjectCrossReferenceに追加する手順は、次のとおりです。
送信側オブジェクトの識別子情報と、対応する相互参照の識別子を追加する必要があります。
EBOID - 統合レイヤーにあり、対応する相互参照の識別子を提供します。この情報はReqABCSImplによって保持され、この値が入力されます。
SenderObjectIdentification - オブジェクトのキー・フィールド名およびキー・フィールド値を入力します。データは送信側システムによって提供されます。
ID - 送信側システムのオブジェクト・タイプ(たとえば、オーダー)を識別します。この情報はReqABCSImplによって保持され、この値が入力されます。
NAME - 送信側システムの説明(たとえば、注文書)を識別します。この情報はReqABCSImplによって保持され、この値が入力されます。
ContextID - 送信側システムのオブジェクト識別子を識別します。送信側のオブジェクトに複数の値がある場合は、これを複数回繰り返します。キー名の設定にはSchemeID属性を使用し、キーの値が要素自体に格納されます。この値はReqABCSImplによって保持され、この値が入力されます。
この要素には、すべてのWS-Addressing要素が保持され、WS-Addressing要素を転送し、リクエスタとターゲット・システム間でのWS-Addressing要素の交換します。WS-Addressスキーマのローカル・バージョンが指定のディレクトリに保存され、この値はReqABCSImplによって入力されます。プロバイダ・アプリケーションがレスポンスを非同期モードで送信する場合にのみ、リクエストEBMでこの要素に値を入力する必要があります。非同期レスポンスを送信するプロバイダ・アプリケーションでは、この要素の値を利用してコールバック・アドレスを識別します。
この要素は、ユーザーが拡張して独自の要素を追加できる複合タイプです。
この要素固有の使用方法の詳細は、「ファイア・アンド・フォーゲット・メッセージ交換パターンの実装」を参照してください。
Targetセクションの値は、Oracle Mediatorで定義されたターゲット・システムに対するルーティング・ルールをオーバーライドする必要がある場合にのみ入力します。バルク処理の場合は、ルーティング・ルールに定義されている同一のターゲット・システムにすべてのオブジェクトが到達するものと想定されます。そのようなシナリオでは、ルーティング・ルールをオーバーライドするために、適切なターゲット・システム情報をこの要素に定義します。ターゲット・システム情報のオーバーライドは、データ領域内のすべてのオブジェクトに適用されます。リクエスタABCSでは、ターゲット・システムの値を入力しないでくささい。詳細を入力できるのは、エンタープライズ・ビジネス・フロー(EBF)またはEBSのみです。
Target要素には、ターゲットまたは受信側のシステムに関する情報が格納され、図16-10に示すような要素があります。
図16-10 Target要素の構造
例16-17に示すように、ルーティング・ルールのオーバーライドの際に、この要素を使用してルーティング対象のターゲット・システムを識別します。参加アプリケーションのインスタンス・コードの値でターゲット・システムをオーバーライドする必要がある場合に、EBSによって値が入力されます。
この要素は、アプリケーションのタイプを識別します。同じアプリケーション・タイプの複数のインスタンスが統合プラットフォームに登録されている場合のアプリケーション・タイプの識別子です。システムで複数のバージョンがサポートされている場合、アプリケーション・タイプにはアプリケーションのバージョン番号が格納されます。
例16-17に示すように、このフィールドには、EBS (またはEBF)でTarget/IDフィールドに値が入力されるのと同時に、通常はABCSで値を入力する必要があります。このフィールドの値は、aia:getSystemType(<ID>)関数(IDは、Target/IDに入力されたシステムIDの値)で取得します。ルーティング・ターゲットの判断では、ほとんどの場合、このフィールドの値または値の欠落がEBSルーティング・ルールによってチェックされます。
これは、必要な場合にユーザーが拡張して独自の要素を追加できる複合タイプです。
例16-17に、target要素のコードの例を示します。
例16-17 Target要素のコード・サンプル
<corecom:Target> <corecom:ID>PORTAL_01</corecom:ID> <corecom:ApplicationTypeCode>PORTAL_01</corecom:ApplicationTypeCode> </corecom:Target>
このセクションでは、UN/CEFACT標準のビジネス定義ヘッダーに定義されたビジネス範囲の仕様に関連する情報を取得します。
すべてのEBMには、次の要素に対して少なくとも2行の情報が必要です。
Business Scopeというタイプの行には、メッセージが属しているエンドツーエンドのビジネス・プロセスを記述します。
2つ目の行には、フローに関連付けられた主要なメッセージを記述します(たとえば、ProcessOrderフローのオーダー・メッセージ)。
ほとんどの場合、各エンドツーエンド・プロセスのメッセージは1つのみです。ただし、複雑なビジネス・シナリオでは、プロセスから複数のメッセージが生成されたり、分岐することがあります。その場合、生成される各メッセージは、このセクションの行である必要があります。図16-11に、この仕組みを示します。
図16-11 BusinessScope要素の構造
このインスタンスが関連しているコントラクトを識別するオプションの識別子。ReqABCSImplを使用してこの値を入力します。これはアプリケーションによって指定されたプロセスまたはメッセージの名前です。
範囲のインスタンスを参照する一意の識別子(たとえば、ドキュメント・インスタンスのプロセス実行インスタンス)。これは、アプリケーション・チームによって割り当てられた英数字コードにGUIDが連結された値です。メッセージ・タイプの場合、このセクションには、先頭のセクションで使用したEBMIDと同じものが使用されます。
この要素は、ビジネス範囲の種類を示します。値は次のとおりです。
BusinessScope (UMM)
BusinessService (ebXMLの場合)
Message
ReqABCSImplを使用してこの値を入力します。
このメッセージが属しているEBSの名前。メッセージの作成者には認識されており、ABCSまたはEBSになります。ReqABCSImplを使用してこの値を入力します。
このメッセージが属しているEBSの処理の名前。メッセージの作成者には認識されており、ABCSまたはEBSになります。ReqABCSImplを使用してこの値を入力します。
すべてのEBMには、次の要素に対して少なくとも2行の情報が必要です。
Business Processというタイプの行には、メッセージが属しているエンドツーエンドのビジネス・プロセスを記述します。
2つ目の行には、フローに関連付けられた主要なメッセージを記述します(たとえば、ProcessOrderフローのオーダー・メッセージ)。
ほとんどの場合、各エンドツーエンド・プロセスのメッセージは1つのみです。ただし、複雑なビジネス・シナリオでは、プロセスから複数のメッセージが生成されたり、分岐することがあります。その場合、生成される各メッセージは、このセクションの行である必要があります。
次のユースケースの例で、この仕組みを説明します。例を簡単に示すため、メッセージをプロセスの直属の子のみに制限し、その後のメッセージの連結については考慮していません。
GetAccountBalance: 図16-12に示すように、入力として勘定科目番号を使用してリクエスト・メッセージを送信し、レスポンスとして勘定残高を受信します。
図16-12 ユースケース: リクエスト/レスポンス
例16-18に、2つの行(1つはプロセス用、もう1つはプロセスに関係するリクエストEBMメッセージ用)を示します。
例16-18 リクエスト/レスポンス・ユースケースのリクエストEBM
<BusinessScope> <ID>Siebel- Portal-Get -Account-Balance</ID> <InstanceID>GETACCTBAL/1001</InstanceID> <BusinessScopeTypeCode>BusinessScope</BusinessScopeTypeCode> <EnterpriseServiceName>AccountEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>GetAccountBalance</ EnterpriseServiceOperationName> <BusinessScope> <BusinessScope> <ID> AccountBalanceReqMessage </ID> <InstanceID> ACCTBALMSG/9001[the EBMID in the top element to be used here] </InstanceID> <BusinessScopeTypeCode>Message</BusinessScopeTypeCode> <EnterpriseServiceName>AccountEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>GetAccountBalance </EnterpriseServiceOperationName> </BusinessScope>
例16-19に、2つの行(1つはプロセス用、もう1つはプロセスに関係するレスポンスEBMメッセージ用)を示します。
例16-19 リクエスト/レスポンス・ユースケースのレスポンスEBM
<BusinessScope> <ID>Siebel- Portal-Get -Account-Balance</ID> <InstanceID>GETACCTBAL/10 01</InstanceID> <BusinessScopeTypeCode>BusinessScope</BusinessScopeTypeCode> <EnterpriseServiceName>AccountEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>GetAccountBalance </EnterpriseServiceOperationName> </BusinessScope> <BusinessScope> <ID>] AccountBalanceResMessage </ID> <InstanceID> ACCTBALMSG/9002[the EBMID in the top element to be used here </InstanceID> <BusinessScopeTypeCode>Message</BusinessScopeTypeCode> <EnterpriseServiceName>AccountEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>GetAccountBalance</ EnterpriseServiceOperationName> </BusinessScope>
SyncProduct: 図16-13に示すように、ポータルが非同期メッセージをSiebelに送信し、製品の詳細を同期します。
図16-13 ユースケース: 非同期プロセス
例16-20に、2つの行(1つはプロセス用、もう1つはプロセスに関係するリクエストEBMメッセージ用)を示します。
例16-20 リクエスト/レスポンス・ユースケースのリクエストEBM
<BusinessScope> <ID>Portal-Siebel-Product-Sync</ID> <InstanceID>PRODSYNC/1003</InstanceID> <BusinessScopeTypeCode>BusinessScope</BusinessScopeTypeCode> <EnterpriseServiceName>ProductEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>SyncProduct</EnterpriseServiceOperationName> </BusinessScope> <BusinessScope> <ID> ProductSyncReqMessage </ID> <InstanceID> PRODSYNCREQ/9003 </InstanceID> <BusinessScopeTypeCode>Message</BusinessScopeTypeCode> <EnterpriseServiceName>ProductEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>SyncProduct</EnterpriseServiceOperationName> </BusinessScope
ProcessOrder: Siebelがオーダーを送信します。図16-14に示すように、最初にポータルでCreateAccountを生成し、次にポータルでオーダーを処理します。
図16-14 子プロセスの生成を伴う同期プロセス
図16-15にProcessOrderのフローを示します。
図16-15 ProcessOrderフロー
メッセージ1: 勘定科目作成リクエストEBM
例16-21に、4つの行を示します。
1つはプロセス用
1つはプロセスの勘定科目作成リクエスト・メッセージ用
1つはプロセスの顧客作成リクエスト・メッセージ用(直属の子を生成)
1つはプロセスの顧客作成レスポンス・メッセージ用(直属の子を生成)
メッセージ2: 勘定科目作成レスポンスEBM
例16-22に、2つの行を示します。
1つはプロセス用
1つはプロセスの勘定科目作成レスポンス・メッセージ用
メッセージ3: 顧客作成リクエストEBM
例16-23に、2つの行を示します。
1つはプロセス用
1つはプロセスの顧客作成リクエスト・メッセージ用
メッセージ4: 顧客作成レスポンスEBM
例16-24に、2つの行を示します。
1つはプロセス用
1つはプロセスの顧客作成レスポンス・メッセージ用
メッセージ5: ProcessOrderリクエストEBM
例16-25に、4つの行を示します。
1つはプロセス用
1つはプロセスのオーダー処理リクエスト・メッセージ用
1つはプロセスの勘定科目作成リクエスト・メッセージ用(直属の子を生成)
1つはプロセスの勘定科目作成レスポンス・メッセージ用(直属の子を生成)
メッセージ6: オーダー処理レスポンスEBM
例16-26に、2つの行を示します。
1つはプロセス用
1つはプロセスのオーダー処理レスポンス用
例16-21 勘定科目作成リクエストEBM
<BusinessScope> <ID> Portal-Account-Creation </ID> <InstanceID> CREATEACCT/1008 </InstanceID> <BusinessScopeTypeCode>BusinessScope</BusinessScopeTypeCode> <EnterpriseServiceName>AccountEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>CreateAccount</EnterpriseServiceOperationName> </BusinessScope> <BusinessScope> <ID> Create-Account-Request-Message </ID> <InstanceID> CREATEACCTREQMSG/9008 </InstanceID> <BusinessScopeTypeCode>Message</BusinessScopeTypeCode> <EnterpriseServiceName>AccountEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>CreateAccount</EnterpriseServiceOperationName> </BusinessScope> <BusinessScope> <ID> Create-Customer-Request-Message </ID> <InstanceID> CREATECUSTREQMSG/9009 </InstanceID> <BusinessScopeTypeCode>Message</BusinessScopeTypeCode> <EnterpriseServiceName>CustomerEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>CreateCustomer</EnterpriseServiceOperationName> </BusinessScope> <BusinessScope> <ID> Create-Customer-Response-Message </ID> <InstanceID> CREATECUSTRESPMSG/9021 </InstanceID> <BusinessScopeTypeCode>Message</BusinessScopeTypeCode> <EnterpriseServiceName>CustomerEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>CreateCustomer</EnterpriseServiceOperationName> </BusinessInstruction>
例16-22 勘定科目作成レスポンスEBM
<BusinessScope> <ID> Portal-Account-Creation-Response </ID> <InstanceID> CREATEACCTRESP/1008 </InstanceID> <BusinessScopeTypeCode>BusinessScope</BusinessScopeTypeCode> <EnterpriseServiceName>AccountEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>CreateAccount</EnterpriseServiceOperationName> </BusinessScope> <BusinessScope> <ID> Create-Account-Response-Message </ID> <InstanceID> CREATEACCTRESPMSG/9020 </InstanceID> <BusinessScopeTypeCode>Message</BusinessScopeTypeCode> <EnterpriseServiceName>AccountEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>CreateAccount</EnterpriseServiceOperationName> </BusinessScope>
例16-23 勘定科目作成レスポンスEBM
<BusinessScope> <ID> Oracle-Customer-Create </ID> <InstanceID> CREATECUST/1009 </InstanceID> <BusinessScopeTypeCode>BusinessScope</BusinessScopeTypeCode> <EnterpriseServiceName>CustomerEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>CreateCustomer</EnterpriseServiceOperationName> </BusinessScope> <BusinessScope> <ID> Create-Customer-Request-Message </ID> <InstanceID> CREATECUSTREQMSG/9009 </InstanceID> <BusinessScopeTypeCode>Message</BusinessScopeTypeCode> <EnterpriseServiceName>CustomerEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>CreateCustomer</EnterpriseServiceOperationName> </BusinessScope>
例16-24 顧客作成リクエストEBM
<BusinessScope> <ID> Oracle-Customer-Create-Response </ID> <InstanceID> CREATECUSTRESP/10 09 </InstanceID> <BusinessScopeTypeCode>BusinessScope</BusinessScopeTypeCode> <EnterpriseServiceName>CustomerEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>CreateCustomer</EnterpriseServiceOperationName> </BusinessScope> <BusinessScope> <ID> Create-Customer-Response-Message </ID> <InstanceID> CREATECUSTREQMSG/9021 </InstanceID> <BusinessScopeTypeCode>Message</BusinessScopeTypeCode> <EnterpriseServiceName>CustomerEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>CreateCustomer</EnterpriseServiceOperationName> </BusinessScope>
例16-25 ProcessOrderリクエストEBM
<BusinessScope> <ID>End-to-End-Order-Processing </ID> <InstanceID> ORDPROCESSING/1004 </InstanceID> <BusinessScopeTypeCode>BusinessScope</BusinessScopeTypeCode> <EnterpriseServiceName>OrderEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>ProcessOrder</EnterpriseServiceOperationName> </BusinessScope> <BusinessScope> <ID> Process-Order-Request-Message </ID> <InstanceID> PROCESSORDERREQMSG /9004 </InstanceID> <BusinessScopeTypeCode>Message</BusinessScopeTypeCode> <EnterpriseServiceName>OrderEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>ProcessOrder</EnterpriseServiceOperationName> </BusinessScope> <BusinessScope> <ID>Create-Account-Request-Message </ID> <InstanceID> CREATEACCTREQMSG /9005 </InstanceID> <BusinessScopeTypeCode>Message</BusinessScopeTypeCode> <EnterpriseServiceName>AccountEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>CreateAccount</EnterpriseServiceOperationName> </BusinessScope> <BusinessScope> <ID> Create-Account-Response-Message </ID> <InstanceID> CREATEACCTRESPMSG /9020</InstanceID> <BusinessScopeTypeCode>Message</BusinessScopeTypeCode> <EnterpriseServiceName>AccountEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>CreateAccount</EnterpriseServiceOperationName> </BusinessScope>
例16-26 オーダー処理レスポンスEBM
<BusinessScope> <ID>End-to-End-Order-Processing </ID> <InstanceID> ORDPROCESSING/1004 </InstanceID> <BusinessScopeTypeCode>BusinessScope</BusinessScopeTypeCode> <EnterpriseServiceName>OrderEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>ProcessOrder</EnterpriseServiceOperationName> </BusinessScope> <BusinessScope> <ID> Process-Order-Response-Message</ID> <InstanceID> PROCESSORDERRESPMSG /9019</InstanceID> <BusinessScopeTypeCode>Message</BusinessScopeTypeCode> <EnterpriseServiceName>OrderEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>ProcessOrder</EnterpriseServiceOperationName> </BusinessScope>
図16-16に示すように、EBMTrackingには、EBMが通過した各ノードに関する追跡情報が格納されます。通過した各実行単位に対して、EBMTrackingは複数回存在する可能性があります。
図16-16 EBMTracking要素の構造
この要素には、EBMが実行単位によって処理された時点を示すタイムスタンプが格納されます。タイムスタンプはUTCで表現し、現在の日時とGMTからの時差で、yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)?のように表現します。
例16-27に示すように、サービスを使用してメッセージを処理するときは常にEBMTrackingエントリをEBMヘッダーに追加します。
このセクションは、次の場合に値を入力する必要があります。
リクエスタABC実装サービスでリクエストABMをEBMに変換する場合。
プロバイダABC実装サービスでレスポンスABMをEBMに変換する場合。
メッセージがBPELプロセスを経由する場合。
例16-27 EBM追跡情報の入力
<EBMTracking>
<SequenceNumber>1</SequenceNumber>
<ExecutionUnitID>6 8 56 8</ExecutionUnitID>
<ExecutionUnitName>{http://xmlns.oracle.com/ABCSImpl/Siebel/Invoice/v0}
QueryInvoiceSiebelReqABCSImpl</ExecutionUnitName>
<CategoryCode>BPEL</CategoryCode>
<ActivityDateTime>2 001-12-17T09:30:47-05:00</ActivityDateTime>
</EBMTracking>
<EBMTracking>
<SequenceNumber>2</SequenceNumber>
<ExecutionUnitID>4435</ExecutionUnitID>
<ExecutionUnitName>OrderEBS</ExecutionUnitName>
<ExecutionUnitName>{http://xmlns.oracle.com/EnterpriseServices/Core/Invoice/v0}
QueryInvoiceEBS</ExecutionUnitName>
<CategoryCode>ESB</CategoryCode>
<ActivityDateTime>2 001-12-17T09:30:47-05:00</ActivityDateTime>
</EBMTracking>
<EBMTracking>
<SequenceNumber>3</SequenceNumber>
<ExecutionUnitID>6 8 594</ExecutionUnitID>
<ExecutionUnitName>{http://xmlns.oracle.com/ABCSImpl/Portal/Invoice/v0}Query
InvoicePortalProvABCSImpl</ExecutionUnitName>
<CategoryCode>BPEL</CategoryCode>
<Activity DateTime>2 001-12-17T09:30:47-05:00</ActivityDateTime>
</EBMTracking>
