| Oracle® Fusion Middleware Oracle SOAコア拡張機能開発者ガイド 12c (12.1.3) E54313-02 |
|
 前 |
 次 |
この章では、アウトバウンドB2B統合フローの開発と実装の概要を示し、B2Bドキュメントの識別方法と要件の分析方法、新しいプロバイダB2Bコネクタ・サービスの開発、既存のエンタープライズ・ビジネス・サービスの開発または拡張、既存のリクエスタABCSの開発または拡張、Oracle B2Bの構成、取引パートナ・アグリーメントの定義、AIAサービスのデプロイと構成、最後にテスト方法および稼働方法について説明します。
この章の内容は次のとおりです。
図11-1に、Oracle Application Integration Architecture (AIA)を使用した、アプリケーションから取引パートナへの単純なアウトバウンド企業間(B2B)フローの開発に含まれる高度なステップを示します。
図11-1 単純なアウトバウンドB2Bフローの開発と実装の高度なステップ
この図に示されている各ステップについては、次の各項で説明します。
この項には次のトピックが含まれます:
アウトバウンドB2Bフロー作成の最初のステップでは、フローで生成する必要があるB2Bドキュメントを識別します。図11-2に示すように、このステップの一環として、フローをサポートするために作成または拡張する必要があるAIAサービスの要件を分析することも必要です。
図11-2 ステップ1: B2Bドキュメントの識別およびサービス要件の分析
このステップの一環として、統合開発チームは次のタスクを実行します。
使用するB2Bドキュメント・プロトコルを識別します。
使用するB2Bドキュメント・タイプを識別します。
Oracle B2BでB2Bドキュメントを定義します。
AIAでB2Bドキュメントを定義します。
使用するAIAのエンタープライズ・ビジネス・オブジェクト(EBO)、エンタープライズ・ビジネス・メッセージ(EBM)およびエンタープライズ・ビジネス・サービス(EBS)を識別します。
メッセージ交換パターンを識別します。
EBM、B2Bドキュメントおよびアプリケーション・ビジネス・メッセージ(ABM)をマッピングします。
マッピングをドキュメント化して公開します。
B2Bフローを開発するには、最初に、使用するB2Bドキュメントを識別します。通常、B2Bドキュメントの選択は、使用するアプリケーションと統合する必要がある取引パートナまたはE-Commerceハブの機能に影響されます。
ただし、特定の統合ユースケースに使用するB2Bドキュメント定義を選択する選択肢がある場合は、現在業界標準のE-Commerce標準が複数存在し、それらの使用は地域や業種によって異なります。
B2Bドキュメント・プロトコルの例には、Open Applications Group Integration Specification (OAGIS)、Electronic Data Interchange (EDI) X12、Electronic Data Interchange For Administration, Commerce and Transport (EDIFACT)、Health Insurance Portability and Accountability Act (HIPAA)、EANCOM、RosettaNet、Universal Business Language (UBL)、Health Level 7 (HL7)および1SYNCがあります。
取引パートナと統合するためにB2Bドキュメント・プロトコルを選択する際は、次の質問について検討してください。
ドキュメント・プロトコルには、自社の統合ニーズをサポートするドキュメントのリストがありますか。
ドキュメント・プロトコルには、自社の業種に対する適切なサポートがありますか。
主要な取引パートナによってサポートされるドキュメント・プロトコルですか。
自社の地域で使用されているドキュメント・プロトコルですか。
XMLやXMLスキーマなどのオープン・スタンダードに基づいたドキュメント・プロトコルですか。
ベンダー(例: Oracle)によってサポートされるプロトコルですか。
B2Bドキュメント・プロトコルとともに、B2Bドキュメントのバージョンも決定する必要があります。B2Bドキュメント・プロトコル・バージョンの決定には、前述と同様の検討事項を使用できます。
B2Bドキュメント・プロトコルを選択した後、次のタスクは、特定のB2B統合ニーズを満たすB2Bドキュメントを識別することです。各ドキュメント・プロトコルでは、B2Bドキュメントまたはドキュメント・タイプのリストがサポートされています。プロトコル・ドキュメントおよびドキュメント使用ガイドラインを参照して、特定のビジネス・フローのサポートに最適な特定のドキュメントを識別してください。ドキュメント使用は業種や地域によって異なる可能性があります。
たとえば、調達ビジネス・フローの一環として注文書をサプライヤに電子的に送信するB2Bフローを実装する必要があるとします。B2Bドキュメント・プロトコルには、統合ニーズに基づいてEDI X12を選択します。EDI X12ドキュメント・プロトコルでは、この統合要件には850 (注文書)ドキュメントの使用を推奨しています。
B2Bプロトコル、ドキュメントおよびバージョンの識別後は、ドキュメントに関連する次のアーティファクトの正式バージョンを取得する必要があります。
個々の要素を含むB2Bドキュメントの詳細を説明しているドキュメントおよび使用ガイドライン。
B2Bドキュメントの使用を示しているサンプルのXMLインスタンス。
B2BドキュメントのXMLスキーマ定義。
XMLベースのB2Bドキュメント・プロトコルの場合は、正式なユーザー・ドキュメント、XMLスキーマおよびサンプルのドキュメント・インスタンスのダウンロード元として、標準に関連するインターネット・リソースを使用できます。たとえば、OAGISのWebサイト(www.oagi.org)では、この情報のすべてがOAGドキュメント標準のすべての主要リリースで提供されています。
また、Oracle Fusion Middlewareに付属しているB2Bドキュメント・エディタ・ソフトウェアの一部として、前述の正式なアーティファクトを取得できます。
ガイドライン・ファイルの作成の詳細は、『Oracle Fusion Middleware Oracle B2Bユーザーズ・ガイド』のガイドライン・ファイルの作成に関する項を参照してください。
EDIやフラット・ファイルなどの非XMLプロトコルの場合、Oracle B2Bには、非XML形式のドキュメントをXMLに変換する変換機能が用意されています。ただし、このXMLはB2Bドキュメントの中間XML定義であり、さらにAIA EBMに変換する必要があります。B2Bドキュメント・エディタを使用してOracle B2B統合形式のB2Bドキュメントをエクスポートして、AIA B2Bコネクタ・サービス(B2BCS)とともに使用するXMLスキーマ表現のこの中間XMLを取得できます。
ドキュメントのバリエーションのサポート
統合のベスト・プラクティスとして、B2B統合に標準B2Bドキュメント定義をそのまま使用することをお薦めします。ただし、カスタム統合要件を満たすための追加要素に対応するために、B2Bドキュメント定義を変更する必要が頻繁にあります。
公開されている標準のそのようなバリエーションが必要な場合は、追加の詳細を含めるために、前のステップで取得したB2Bドキュメント・ガイドラインおよびスキーマを変更する必要があります。
B2Bドキュメント・タイプおよび定義を識別した後は、Oracle B2Bでそのドキュメントを定義する必要があります。これは、これらのドキュメントを取引パートナ・アグリーメントで使用するための前提条件です。
ドキュメント定義の作成の詳細は、『Oracle Fusion Middleware Oracle B2Bユーザーズ・ガイド』のドキュメント定義の作成に関する項を参照してください。
AIA統合のベスト・プラクティスの推奨では、XMLスキーマやWSDLファイルなどの再使用可能なSOAアーティファクトはすべてSOAメタデータ・ストアで集中的にホストします。再使用可能なアーティファクトを集中的にホストし、それらをAIAサービスから参照することによって、AIAサービスのパフォーマンスが向上し、保守が容易になります。SOAメタデータ・ストアにはキャッシュ機能およびクラスタ機能が用意されているため、このストアを集中的な格納場所として使用すると、それらの機能も利用できます。
B2Bコネクタ・サービスで使用するB2BドキュメントのXMLスキーマ定義も、このメタデータ・ストアでホストします。
B2Bドキュメントをメタデータ・ストアにデプロイする手順は、次のとおりです。
B2B標準に対応するディレクトリをB2BObjectLibraryに作成します。
B2Bドキュメント・タイプを定義しているXMLスキーマ・ファイルおよびディレクトリをこの場所にコピーします。
B2BObjectLibraryディレクトリは、$AIA_HOME/MetaData/AIAMetaData/AIAComponentsの子ディレクトリです。
たとえば、図11-3に示すように、OAGビジネス・オブジェクト定義をコピーするOAGISディレクトリを作成します。
図11-3 OAGビジネス・オブジェクト定義を格納するために作成されたOAGISディレクトリ
このフォルダの下にB2Bドキュメント・タイプに対応するXMLスキーマ・ファイルをコピーします。
たとえば、図11-4に示すように、OAGIS ProcessPurchaseOrder.xsdファイルとそのサポート・スキーマすべてを相対的なディレクトリ構造も保持して、このフォルダの場所にコピーします。
図11-4 OAGISディレクトリに格納された対応するXMLスキーマ・ファイル
B2Bオブジェクト・ライブラリの新しいコンテンツをSOAメタデータ・ストアにデプロイします。手順は、次のとおりです。
図11-5に示すように、$AIA_HOME/config/UpdateMetaDataDeploymentPlan.xmlファイルを編集して、Oracle Metadata Services (MDS)でディレクトリB2BObjectLibraryを更新する必要があることを指定します。
図11-5 Oracle Metadata ServicesでB2BObjectLibraryを更新するように編集されたUpdateMetaDataDeploymentPlan.xml
$AIA_HOME/bin下に配置されたaiaenv.shファイルをソースとして指定します。例: $source /slot/ems5813/oracle/AIA3_HOME/bin/aiaenv.sh
ディレクトリを$AIA_HOME/Infrastructure/Install/configに変更します。例: $cd $AIA_HOME/Infrastructure/Install/config
AIAコマンドを発行して、メタデータをデプロイします。例: $ant -f UpdateMetadata.xml
コマンドが成功してエラーが発生していないことを確認します。
AIAを使用したB2Bドキュメントの統合を可能にするために、次のステップでは、使用するAIAのEBO、EBMおよびEBSを識別します。統合する必要があるB2Bドキュメントに最も近い説明があるAIAのEBOおよびEBMを選択します。
たとえば、調達アプリケーションでEDI 850 (注文書)ドキュメントをサプライヤに通信する必要があるアウトバウンドB2B統合フローを開発する場合は、次のEBO、EBMおよびEBSを使用できます。
EBO: PurchaseOrderEBO
EBM: CreatePurchaseOrderEBM
EBS操作: CreatePurchaseOrder
次のステップでは、ビジネス要件を分析して、ABMをEBMに、EBMをB2Bドキュメントにマップします。
B2Bドキュメントに対するマッピングを開発する際は、次のガイドラインを検討してください。
ABCSExtension.PreInvokeABS
ABCSExtension.PostInvokeABS
ABCSExtension.PostXformABMtoEBM
識別および参照コンポーネントをB2Bドキュメントにマッピングする際は、次のガイドラインを検討してください。
アプリケーションでサポートされていて使用可能な場合は、ユニバーサル識別子をマップします。たとえば、品目を識別するUPCコードおよび品目カテゴリを識別するUDEXコードをマップします。
取引パートナが使用している使用可能なすべての外部識別子をマップします。たとえば、ベンダーに送信する必要があるベンダーの部品番号をアウトバウンドB2Bドキュメントにマップします。
説明、メモ、添付ファイルなどのフリー・フォーム属性をマップして、ユーザーが取引パートナと通信して詳細を提供できるようにします。
参照コンポーネントをマップする際は、IDのみではなく、参照エンティティのコンテンツをマップします。たとえば、サプライヤに送信するアウトバウンド注文書ドキュメントに納入先事業所をマップする必要がある場合は、納入先事業所の識別子に加えて、実際の住所および連絡先詳細をマップします。
識別タイプのコンポーネントをマッピングする場合は、実際のアプリケーションIDをB2Bドキュメントに直接マップできます。これは、参加アプリケーション識別子とAIA識別子間でのマッピングの格納にXREFを使用するアプリケーション間(A2A)ユースケースとは異なります。
たとえば、インベントリ・システムから取引パートナへのSyncItemを処理しているとします。ITEM_001は、ソースABMの品目識別子です。この値は、そのままID要素に直接マップできます。同期フローのため、取引パートナ・アプリケーションで生成されたIDはXREFで取得されないため、XREFの使用による追加の値はありません。むしろ、直接マッピングが適切です。
現在の要件を超える要件をマップします。現在の統合ユースケースでマップする必要があるのは少しの要素のみの場合でも、ベスト・プラクティスの推奨は、アプリケーションで処理が可能なすべての使用可能フィールドをマップすることです。これによって、複数のユースケースでコネクタを再使用できます。
必要な場合は、EBOを拡張します。ターゲットのB2Bドキュメントに、マップする必要があるがEBOでは使用できない属性が含まれている場合は、ターゲットの要素を含めるようにEBOを拡張して、それらの要素をマップします。
理解しやすいスプレッドシートにマッピングを取得し、変更が行われた場合は最新の状態に維持します。
この項には次のトピックが含まれます:
図11-6に示すように、次のステップでは、アウトバウンドB2B統合フローをサポートするプロバイダB2BCSを開発します。
図11-6 ステップ2: 新規のプロバイダB2Bコネクタ・サービスの開発
プロバイダB2BCSは、プロバイダ・アプリケーション・ビジネス・コネクタ・サービス(ABCS)と類似していますが、アプリケーションと統合するかわりにOracle B2Bを使用して取引パートナと統合する点のみが異なります。したがって、ABCS (リクエスタおよびプロバイダ)の設計と開発もよく理解することをお薦めします。
プロバイダB2BCSによって提供される主要な機能は、次のタスクを実行することでアウトバウンドB2Bドキュメント統合を可能にすることです。
B2BドキュメントへのAIA EBMの変換。
これらのB2Bドキュメントを取引パートナに送信するためのOracle B2Bの呼出し。
図11-7に、単純なファイア・アンド・フォーゲットのメッセージ交換パターンベースのプロバイダB2BCSで実行される処理を示します。
図11-7 ファイア・アンド・フォーゲットのプロバイダB2BCSの処理フロー
次の各項では、B2BCSの開発手順について説明します。
ほとんどのB2Bドキュメント・フローは、非同期の一方向コールとしてモデル化できます。
たとえば、アウトバウンドB2Bドキュメント・フローを使用して、調達アプリケーションで作成された注文書をサプライヤに送信する必要があるユースケースを検討します。サプライヤは、受信したこの注文書ドキュメントを処理して、注文書確認B2Bドキュメントを送信して戻します。
このユースケースでは、サプライヤから注文書確認ドキュメント形式のレスポンスが予想される場合でも、調達アプリケーションは処理を続行でき、これには、ベンダーへの注文書の通知およびベンダーによる注文書の処理も含まれます。
ベンダーが、注文書確認メッセージでリクエストで使用されたのと同じ注文書IDを指定することが想定されるため、通常、調達アプリケーションでは、この注文書確認ドキュメントを元の注文書に関連付けることもできます。この方法で、リクエストとレスポンスは2つの非同期の一方向フローとしてモデル化できます。
ただし、設計するB2Bドキュメント・フローごとに、類似した分析を実行する必要があります。
メッセージ交換パターンの識別の詳細は、「MEPの識別」を参照してください。
最初に、プロバイダB2BCSのサービス・コントラクト(WSDL)を定義します。プロバイダB2BCSのサービス・コントラクトでは、AIAフローによる呼出し方法を指定します。サービス・コントラクトによって、実装されるEBS操作、入力リクエスト・タイプ、およびB2BCSでサポートされるメッセージ交換パターンが指定されます。
ABCSに対するWSDLの作成方法の詳細は、「ABCSコントラクトの定義」を参照してください。
ここでは、B2BCSのWSDL定義での使用に対して推奨される命名規則を示します。
WSDLファイル名:
ネーミング・ガイドライン: <B2B標準><動詞><EBO>ProvB2BCSImpl.wsdl
例: X12UpdateSalesOrderProvB2BCSImpl.wsdl
サービス・ネームスペース:
ネーミング・ガイドライン: http://xmlns.oracle.com/B2BCSImpl/{Core|Industry/<業種名>}/<B2B標準><動詞><EBO>ProvB2BCSImpl/<ABCSバージョン>
例: http://xmlns.oracle.com/B2BCSImpl/Core/X12UpdateSalesOrderProvB2BCSImpl/V1
ABCSサービス・バージョンは、B2Bのドキュメント/標準バージョンとは無関係であることに注意してください。
AIAサービスのバージョニングに対する推奨の詳細は、「ABCSのバージョニング」を参照してください。
サービス名:
ネーミング・ガイドライン: <B2B標準><動詞><EBO>ProvB2BCSImpl
例: X12UpdateSalesOrderProvB2BCSImpl
ポート・タイプ名:
ネーミング・ガイドライン: <B2B標準><動詞><EBO>ProvB2BCSImplService
例: X12UpdateSalesOrderProvB2BCSImplService
操作名:
ネーミング・ガイドライン: <動詞><EBO>
例: UpdateSalesOrder
リクエスト・メッセージ名:
ネーミング・ガイドライン: <動詞><EBO>ReqMsg
例: UpdateSalesOrderReqMsg
リクエスト・メッセージのWSDLパート要素:
ネーミング・ガイドライン: <EBM>
例: <wsdl:part name="UpdateSalesOrderEBMelement=" salesordebo: UpdateSalesOrderEBM"/>
インポートされるスキーマ:
ネーミング・ガイドライン:
oramds:/apps/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/ Core/Common/V2/Meta.xsd
oramds:/apps/AIAMetaData/AIAComponents /B2BObjectLibrary/ <B2Bメッセージ・スキーマ>
oramds:/apps/AIAMetaData/AIAComponents /EnterpriseObjectLibrary/ <EBMスキーマ>
例:
oramds:/apps/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/ Core/Common/V2/Meta.xsd
oramds:/apps/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/ Core/EBO/SalesOrder/V2/SalesOrderEBM.xsd
oramds:/apps/AIAMetaData /AIAComponents/B2BObjectLibrary/ X12/4010/Oracle/855_4010.xsd
インポートされるWSDL:
ネーミング・ガイドライン: oramds:/apps/AIAMetaData/AIAComponents/ UtilityArtifacts/RuntimeFault.wsdl
例: oramds:/apps/AIAMetaData/AIAComponents/UtilityArtifacts/ RuntimeFault.wsdl
SOAのベスト・プラクティスとして、WSDLやXSDファイルなどのすべての共有サービス・アーティファクトを複数のサービスによってアクセス可能な中央の場所に格納することをお薦めします。
AIA共有のアーティファクトのすべては、Oracle Metadata Services (MDS)に格納します。MDSへの共有アーティファクトの格納によって、アーティファクトへのグローバルなアクセスが可能になる以外に、AIAでキャッシュおよびクラスタリングをサポートするMDSの機能を利用できます。
プロバイダB2BCSのWSDLは、MDSの/apps/AIAMetaData/AIAComponents/B2BServiceLibrary/Connectors/wsdls/ <B2B_STANDARD> /ProviderB2BCS/ <バージョン> / <B2B_STANADRD> <動詞> <オブジェクト> ReqB2BCSImpl.wsdlの場所に格納します。
WSDLをMDSに格納する手順は、次のとおりです。
作成したWSDLを、AIA_HOMEの下の$AIA_HOME/aia_instances/$INSTANCE_NAME/AIAMetaData/AIAComponents/B2BServiceLibrary/Connectors/wsdls/ <B2B_STANDARD> /ProviderB2BCS/ <バージョン> / <wsdlファイル> .wsdlにコピーします。
$AIA_HOME/aia_instances/$INSTANCE_NAME/config/UpdateMetaDataDP.xmlに存在するUpdateMetaDataDP.xmlを実行します。
MDSへのSOA-MDSサーバー接続を使用して、図11-8に示すように、AIAMetadataが入力されていることを確認します。
図11-8 MDSのAIAメタデータ
これで、/apps/AIAMetaData/AIAComponents/B2BServiceLibrary/Connectors/wsdls/EDI_X12/ProviderB2BCS/V1/ X12UpdateSalesOrderProvB2BCSImpl.wsdlのようなURLを使用して、WSDLにアクセスできます。
このプロセスの次のステップでは、B2BCSを開発します。前のステップで作成したプロバイダB2BCSのWSDLは、具象B2BCSの開発時にインタフェースとして使用します。
サービス・コンストラクタではB2Bサービスの自動生成がサポートされていないため、Oracle JDeveloperを使用してB2BCSを開発します。前のステップで作成した抽象WSDLに基づいて、BPELプロセスを含むコンポジットを開発します。
次に、B2BCS実装のBPELで開発する必要がある主要アクティビティを示します。
B2BCSを開発する手順は、次のとおりです。
このドキュメントで前述したように、AIA B2Bインタフェースは、B2Bコネクタ・サービスをOracle B2Bと統合するために使用できる再使用可能なコンポジットです。AIA B2Bインタフェースでは、JMSベースの内部デリバリ・チャネルを使用して、Oracle B2Bと統合します。
すべてのB2BCSについて、AIA B2BインタフェースがAIAとOracle B2Bレイヤー間の統合されたインタフェースです。これによって、Oracle B2Bとの間のB2Bドキュメントの送受信の操作がサポートされます。Oracle B2Bとの統合にAIA B2Bインタフェースを使用する利点を次に示します。
B2BとAIA/SOA間の通信に使用する内部デリバリ・チャネルの選択を実装の最後の段階で変更する必要がある場合、B2BCSコードの変更は不要です。
レガシーまたはサードパーティのB2Bソフトウェアを使用している場合は、AIA B2Bインタフェースをカスタマイズして、B2Bドキュメントをレガシー・ソフトウェアに送信するルーティング・ルールを追加できます。アウトバウンド・ドキュメントのターゲットとしてOracle B2BおよびサードパーティのB2Bソフトウェアのいずれかを選択するフィルタ式として、B2BM_Var//B2BMHeader/GatewayIDを使用できます。これによって、B2Bソフトウェアの選択に関係なく、B2BCSを変更から保護できます。
このサービスはすべてのアウトバウンドB2Bドキュメント・フローで呼び出されるため、監査ログやOracle Business Activity Monitoring (BAM)インストゥルメンテーションなどの共通のアウトバウンド機能がサポートされるように、このコンポジットをカスタマイズできます。
次の図に、カスタム内部デリバリ・チャネル(ファイル)およびレガシーのB2B接続性をサポートするAIA B2Bインタフェースの使用を示します。
図11-9 カスタム内部デリバリ・チャネルおよびレガシーのB2B接続性に対するAIA B2Bインタフェースのサポート
たとえば、アウトバウンドの注文書ドキュメントをFusion MiddlewareのOracle B2Bコンポーネントにルーティングし、アウトバウンドの請求書ドキュメントを古いB2Bインスタンスにルーティングするとします。このユースケースをサポートするには、Oracle B2BのJMS呼出し用と古いB2BインスタンスのOracle Advanced Queuing呼出し用の2つのルーティング・ルールを定義します。
特定のB2Bドキュメント・インスタンスは、ProcessB2BDocument.mplanの複数のルーティング・ルールのいずれかを使用して、B2Bにルーティングされます。AIAレイヤーで生成されたB2Bドキュメントを複数のB2Bソフトウェアにルーティングする必要がほとんどない場合は、ProcessB2BDocument.mplanメディエータのルーティング・ルールを順次呼出し用に構成します。
AIA B2Bインタフェースをカスタマイズする手順は、次のとおりです。
図11-10 コンポジット・エディタのAIAB2BInterface/composite.xml
図11-11 サードパーティのB2Bソフトウェアのインタフェースに対する新規Webサービス・コールの追加
図11-12 コンポジット・エディタのAIAB2BInterface/ProcessB2BDocument.mplan
図11-13 AIAB2BInterface/ProcessB2BDocument.mplanへのカスタム・ルーティング・ルールの追加
図11-14 B2Bソフトウェアに入力を提供する変換ステップ
B2BCSに関する主要メタデータをプロジェクト・ライフサイクル・ワークベンチおよびOracle Enterprise Repositoryで使用できるようにするには、特定の方法でB2BCS実装SOAコンポジットのcomposite.xmlファイルに注釈付けする必要があります。
B2Bコネクタ・サービスに注釈を付ける手順は、次のとおりです。
表11-5 composite.xmlのサービス注釈要素
| Annotation Element | 説明 | 例 |
|---|---|---|
AIA/Service/InterfaceDetails/ServiceName |
このプロバイダB2BCS実装によって実装されるEBSの名前 |
SalesOrderEBS |
AIA/Service/InterfaceDetails/Namespace |
このプロバイダB2BCS実装によって実装されるEBSのネームスペース |
http://xmlns.oracle.com/EnterpriseServices/Core/ SalesOrder/V2 |
AIA/Service/InterfaceDetails/ArtifactType |
EnterpriseBusinessService |
EnterpriseBusinessService |
AIA/Service/InterfaceDetails/Service Operation |
<動詞><EBO名> |
UpdateSalesOrder |
AIA/Service/ImplementationDetails/ArtifactType |
ProviderB2BCSImplementation |
ProviderB2BCSImplementation |
AIA/Service/ImplementationDetails/ServiceOperation/Name |
<動詞><EBO名> |
UpdateSalesOrder |
AIA/Service/ImplementationDetails/B2BDocument |
このB2BCSのターゲットB2Bドキュメント・タイプ |
855 |
AIA/Service/ImplementationDetails/B2BDocumentVersion |
このB2BCSのターゲットB2Bドキュメント・バージョン |
4010 |
AIA/Service/ImplementationDetails/B2BStandard |
このB2BCSのターゲットB2B標準 |
X12 |
AIA/Service/ImplementationDetails/B2BStandardVersion |
このB2BCSのターゲットB2B標準バージョン |
4010 |
図11-15に示したXMLスニペットは、X12ProcessSalesOrderReqB2BCSImpl composite.xmlと呼ばれる注釈が付いたB2BCSの例です。
図11-15 X12ProcessSalesOrderReqB2BCSImpl composite.xmlと呼ばれる注釈が付いたB2BCSのスニペットの例
表11-6 composite.xmlのAIA B2Bインタフェース・ユーティリティ・サービス注釈要素
| Annotation Element | 説明 |
|---|---|
|
|
|
|
図11-16に示すように、composite.xmlでは、AIA B2Bインタフェース・ユーティリティ・サービスの参照に注釈を付ける必要があります。
図11-16 composite.xmlのスニペットのAIA B2Bインタフェース・ユーティリティ・サービス注釈要素
この項には次のトピックが含まれます:
B2B実装では、異なる取引パートナが同じB2Bドキュメントの異なるバージョンまたはマッピング・ガイドラインをサポートする必要が頻繁にあります。特定のB2Bドキュメントを複数の取引パートナに、各取引パートナに対して決定したバージョンおよびマッピング・ガイドラインに基づいて送信する必要がある場合は、ドキュメントのB2BCSを取引パートナ固有の変換ロジックをサポートするように作成できます。次の項で説明するように、これを実現できる方法が複数あります。
未変更のままの共通のコア・マッピングに取引パートナ固有のマッピングを追加する場合は、カスタムXSLTテンプレート・コールを使用したパートナ固有のマッピング設定の可能性を調査してください。
カスタムXSLTテンプレートのコールアウトを使用したXSLT拡張のサポートの詳細は、「拡張可能なABCSの開発」を参照してください。
要約すると、図11-17に示すように、XSLTファイルにマップされているすべてのビジネス・コンポーネントの最後に、同梱されているB2BCSからカスタムXSLTテンプレートが呼び出されます。
図11-17 同梱のB2BCSからのカスタムXSLTテンプレートの呼出しを含む、XSLTにマップされたビジネス・コンポーネント
図11-18に示すように、カスタムXSLTテンプレートは、メインのXSLTに含まれるカスタムXSLTファイルに定義されています。
図11-18 カスタムXSLTファイルに定義されているカスタムXSLTテンプレート
実装時には、このカスタムXSLTファイルに追加のマッピングを追加できます。図11-19に示すように、取引パートナIDは、カスタムXSLTテンプレート・コールに入力として渡されて、条件でターゲットのB2B要素にマップされるように使用できます。
図11-19 カスタムXSLTテンプレート・コールに入力として渡される取引パートナID
取引パートナ固有のマッピングが相互に競合する場合、またはパートナ固有のマッピングを各マッピング・テンプレートの最後ではなく、XMLドキュメントの任意の場所に追加する必要がある場合は、カスタムXSLTテンプレートを使用してパートナ固有のマッピングを定義する前述の方法では要件が満たされません。
そのような要件を満たすために、カスタム・マッピングが必要な取引パートナごとにXSLTファイルを1つ開発できます。図11-20に示すように、同梱のXSLTファイルをコピーして、パートナ固有のマッピング・ロジックを含めるように編集し、ファイル名にパートナ接頭辞を使用して保存します。
図11-20 パートナ固有のマッピング・ロジックを含めるように編集されて、ファイル名にパートナ接頭辞を使用して保存された同梱のXSLTファイルのコピー
次に、各取引パートナに使用するXSLTファイルに関する情報を含む構成ファイルを定義できます。たとえば、図11-21に示すように、この構成情報の格納にドメイン値マッピング(DVM)ファイルを使用できます。
図11-21 XSLTファイルへの取引パートナのマップに使用されるDVMファイル
図11-22に示すプロバイダB2BCS実装のBPELプロセスでは、図11-23に示すように、このDVMファイルの参照を実行でき、図11-24に示すように、XSLTファイル名を取得できます。
図11-22 取引パートナ固有のXSLTが必要なプロバイダB2BCS実装のBPELプロセス
図11-23 XSLTファイル名を取得するためのDVMの参照
図11-24 XSLTファイル名の取得
Oracle B2Bでは、取引パートナ固有のXSLTのニーズとともに、同じ外部B2Bドキュメントの複数の取引パートナ・アグリーメントの定義に異なるドキュメント・タイプを使用する場合があります。
たとえば、取引パートナのGlobalでは、X12 855 B2Bドキュメントの5010バージョンが必要で、取引パートナのABC Corpでは、同じドキュメントの4010バージョンが必要な場合です。
前の項で説明した方法を使用すると、同じプロバイダB2BCS実装を使用して、両方の取引パートナに対してB2Bドキュメントを生成できます。
ただし、AIA B2Bインタフェースがサービスの特定のインスタンスに関係する取引パートナに基づいて呼び出されている間に、Globalの場合は4010、ABC Corpの場合は5010など、対応するB2Bドキュメント・バージョンを指定する必要があります。
図11-25に示すように、これらの要件をサポートするには、前の方法で使用したのと類似したDVMファイルを使用して、各取引パートナのB2Bドキュメント・タイプおよびドキュメント・リビジョンを格納します。この情報をBPELプロセスで参照して、/B2BMHeader/B2BDocumentType/TypeCodeおよび/B2BMHeader/B2BDocumentType/Versionの属性に値を入力できます。
図11-25 取引パートナのB2Bドキュメント・タイプおよびドキュメント・リビジョン情報の格納に使用されるDVM
前述の構成ファイルは、Oracle JDeveloperプロジェクト内でローカルに作成して格納できますが、ベスト・プラクティスの推奨は、これらのファイルを外部化してMDSに格納し、oramds参照を使用してそれらをB2BCS実装のBPELプロジェクトから参照することです。
B2Bドキュメント・プリファレンスおよび取引パートナ固有の変換情報の格納にDVMファイルを使用するこの方法は機能しますが、アプリケーションとこれらのDVMファイル間の取引パートナ情報の同期化を維持する必要があります。
アプリケーションで新しい取引パートナを定義するたびに、対応するレコードを、取引パートナのB2Bドキュメント・プリファレンスを格納するこのDVMで作成する必要があります。これらの変更の管理には確立された管理プロセスが使用可能である必要があります。
AIAサービスでエラー処理およびリカバリを有効化する方法の詳細は、Oracle Fusion Middleware Oracle Application Integration Architecture SOAコア拡張機能インフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイドのエラー処理の設定に関する項を参照してください。
簡潔に示すと、次の手順を実行する必要があります。
fault-policy.xmlをB2BCSコンポジットに関連付けます。
図11-26および図11-27に示すように、ビジネス・フォルトに対してAIAAsyncErrorHandlingBPELProcessを呼び出します。
図11-26 AIAAsyncErrorHandlingBPELProcessを呼び出すように定義されたB2BCSコンポジット
図11-27 AIAAsyncEHServiceの呼出し
表11-7に示すように、AIAAsyncErrorHandlingBPELProcessの呼出し時に、フォルト・スキーマの次のB2B固有要素を入力できます。
表11-7 AIAAsyncErrorHandlingBPELProcessによって入力可能なフォルト・スキーマのB2B固有要素
| フォルト要素スキーマ | 説明 | 例 |
|---|---|---|
Fault/B2BMReference/B2BMID |
B2Bドキュメントの一意の識別子 |
13232325 |
Fault/B2BMReference/B2BDocumentType/TypeCode |
プロバイダB2BCSで生成されるB2Bドキュメントのドキュメント・タイプ |
855 |
Fault/B2BMReference/B2BDocumentType/Version |
プロバイダB2BCSで生成されるB2Bドキュメントのドキュメント・バージョン |
4010 |
Fault/B2BMReference/B2BDocumentType/TypeCode/@listAgencyID |
プロバイダB2BCSで生成されるB2Bドキュメントの標準 |
X12 |
Fault/B2BMReference/GatewayID |
使用されるB2Bソフトウェアの名前 |
Oracle B2B |
Fault/B2BMReference/SenderTradingPartner/TradingPartnerID |
EBMHeaderからマップされる送信者の取引パートナ |
MyCompany |
Fault/B2BMReference/ReceiverTradingPartner/TradingPartnerID |
EBMHeaderからマップされる受信者の取引パートナ |
Global |
図11-28に、corecom:FaultのB2B固有要素を示します。
図11-28 corecom:FaultのB2B固有要素
フォルト・インスタンスで使用可能で、失敗したAIAサービスのB2B詳細は、ログに記録されて失敗フローのデバッグで使用できます。
図11-29に示すように、次のステップでは、新しいEBSを開発するか、既存のEBSを拡張して、前のステップで開発したプロバイダB2BCSを呼び出します。たとえば、X12UpdateSalesOrderProvB2BCSImplプロセスを呼び出すには、UpdateSalesOrderEBSを開発または変更する必要があります。
図11-29 ステップ3: 既存のエンタープライズ・ビジネス・サービスの開発または拡張
新しいEBSの作成の詳細は、「エンタープライズ・ビジネス・サービスの設計と開発」を参照してください。
B2B実装では、異なる取引パートナが同じEBM情報を異なるB2Bドキュメント・プロトコルを使用して送信する必要がある場合があります。
たとえば、サプライヤのXLS Inc、New NetworksおよびOffice Systemsでは、新しい注文書をOAGプロセス注文書ドキュメント形式を使用して送信する必要がある一方、サプライヤのABC IncおよびGlobalでは、新しい注文書をX12 850ドキュメント形式を使用して送信する必要がある場合です。
この実装のニーズをサポートするには、図11-30に示すように2つのB2BCSを開発する必要があります。
CreatePurchaseOrderEBMをOAGプロセス注文書B2Bドキュメントに変換するOAGCreatePurchaseOrderB2BCSImpl。
CreatePurchaseOrderEBMをX12 850B2Bドキュメントに変換するX12CreatePurchaseOrderB2BCSImpl。
CreatePurchaseOrderEBM実装には、これらのB2BCSの両方を呼び出すルーティング・ルールを含める必要があります。
図11-30 各取引パートナが同じEBMデータを異なるB2Bドキュメント・プロトコルを使用して送信する必要があるB2B実装
少数の取引パートナが関係する場合は、図11-31に示すように、各B2BCSに対してEBSルーティング・ルールのフィルタ式を使用して、関係する取引パートナに基づいてEBMをルーティングできます。
図11-31 取引パートナに基づいてEBMをルーティングするために使用される、各B2BCSに対するEBSルーティング・ルールのフィルタ式
ただし、多数の取引パートナが関係する場合は、図11-32に示すように、取引パートナのB2Bプリファレンスを外部の構成ファイル(DVMファイルなど)に格納できます。
図11-32 取引パートナのB2Bプリファレンスの格納に使用されるDVM
図11-33に示すように、この構成を実行時にEBS実装で参照して、呼び出すターゲットのプロバイダB2Bを決定できます。
図11-33 呼び出すターゲットのプロバイダB2Bを決定するためのEBS実装による参照
この方法は機能しますが、アプリケーションとこれらのDVMファイル間の取引パートナ情報の同期化を維持する必要があります。
アプリケーションで新しい取引パートナを定義するたびに、対応するレコードを、取引パートナのB2Bドキュメント・プリファレンスを格納するこのDVMで作成する必要があります。これらの変更の管理には確立された管理プロセスが存在する必要があります。
この項には次のトピックが含まれます:
図11-34に示すように、次のステップでは、新規のリクエスタABCSを開発するか、または既存のリクエスタABCSを拡張します。
図11-34 ステップ4: 既存のリクエスタABCSの開発または拡張
リクエスタABCSは、アプリケーションのUIアクションまたはビジネス・イベントからトリガーされるAIAサービスで、アウトバウンドB2Bフローの最初のステップです。リクエスタABCSは、AIAレイヤーのトリガー・アプリケーションのかわりに機能し、AIA EBSを呼び出します。
リクエスタABCSの設計方法と作成方法の詳細は、「アプリケーション・ビジネス・コネクタ・サービスの設計」および「ABCSの作成」を参照してください。
リクエスタABCSは常にEBS実装を呼び出すため、A2AとB2Bの両方の統合シナリオで使用できます。ベスト・プラクティスの推奨は、リクエスタABCSをA2AとB2Bの両方の統合シナリオで使用する可能性を想定しておくことです。
B2B統合フローで使用するリクエスタABCSを開発する場合は、次の情報を検討してください。
B2B統合フローは主に非同期で処理されます。したがって、新しいリクエスタABCSを開発する際のメッセージ交換パターンの評価時には、B2Bフローで使用される可能性を考慮する必要があります。
リクエスタABCSの主要なタスクの1つは、ABMを正規EBMに変換して、AIA EBSを呼び出す入力としてEBMを使用することです。
ABMからEBMへのこの変換を開発する際は、B2BCSにルーティング可能でB2BCSで使用可能なEBMペイロードの生成を変換でサポートする必要があることに注意してください。B2BCSによるB2Bドキュメントの作成に必要なEBMのフィールドを識別するには、「ステップ1: B2Bドキュメントの識別および要件の分析」で説明している2Bマッピング・ガイドラインを検討してください。
その他のいくつかの考慮事項には、次のような点があります。
AIAの推奨に従って、特定の統合シナリオに必要なフィールドのサブセットのみではなく、使用可能なすべてのフィールドを必ずマップします。
UPC製品コードやDUNSなどの外部グローバル識別子は、アプリケーションの内部識別子とともにマップする必要があります。
EBMの参照コンポーネントは完全にマップする必要があります。たとえば、リモート取引パートナでは実際の事業所に対する事業所識別子を解決できないため、事業所識別子以外にも実際の住所の詳細をマップする必要があります。
表11-8に、前の項で説明したようにEBSレイヤーで取引パートナ固有のルーティングを実行できるように、マップする必要があるEBMヘッダーのフィールドを示します。
表11-8 EBSレイヤーで取引パートナ固有のルーティングを可能にするためにマップする必要があるEBMヘッダー要素
| EBMヘッダー要素 | 説明 | 値の例 |
|---|---|---|
/EBMHeader/B2BProfile/SenderTradingPartner/TradingPartnerID |
Oracle B2Bに定義されている送信側取引パートナのID。アウトバウンド・フローの場合、これはホスト取引パートナです。 |
MyCompany |
/EBMHeader/B2BProfile/ReceiverTradingPartner/TradingPartnerID |
Oracle B2Bに定義されている受信側取引パートナのID。アウトバウンド・フローの場合、これはリモート取引パートナです。 |
Globe Inc |
このステップを終了すると、アウトバウンドB2B統合フローの開発に必要なAIAサービスのすべての準備が整います。
図11-35に示すように、次のステップでは、Oracle B2Bで取引パートナ・アグリーメントを作成します。
図11-35 ステップ5: Oracle B2Bの構成および取引パートナ・アグリーメントの定義
取引パートナを定義してB2B機能と関連付ける方法の詳細は、『Oracle Fusion Middleware Oracle B2Bユーザーズ・ガイド』の取引パートナの構成に関する項を参照してください。
また、EDIベースのアウトバウンドB2Bフローの場合は、アウトバウンド・ドキュメントをバッチ処理するようにOracle B2Bを構成できます。バッチ・サイズやタイムアウトなどのパラメータは、AIAレイヤーを変更せずにOracle B2Bで構成できます。
Oracle B2Bでの取引パートナのネーミングに使用する値は、次のフィールドを使用してリクエスタABCSから送信される値と一致する必要があります。
/EBMHeader/B2BProfile/SenderTradingPartner/TradingPartnerID (ホスト取引パートナの名前用)
/EBMHeader/B2BProfile/ReceiverTradingPartner/TradingPartnerID (リモート取引パートナの名前用)
ソース・アプリケーションによってこれらのフィールドに提供される値とOracle B2Bの取引パートナ名が一致しない場合は、ソース・アプリケーションの取引パートナIDとOracle B2Bの取引パートナ名間のマッピングを含むDVMファイルを保守できます。
このDVMをリクエスタABCSでのABMからEBMへの変換時に参照して、SenderTradingPartner/TradingPartnerIDおよびReceiverTradingPartner/TradingPartnerIDのフィールドに値を入力できます。
図11-36に示すように、次のステップでは、AIAサービスをデプロイします。Oracle JDeveloperを使用すると、サービスをターゲットのOracle SOAサーバーにデプロイできます。
図11-36 ステップ6: AIAサービスのデプロイと構成
アウトバウンド統合に必要なAIAサービスでDVMおよび構成ファイルを使用する場合は、B2B構成に対応するデータを入力する必要があります。
プロジェクト・ライフサイクル・ワークベンチ・アプリケーションを使用してAIAプロジェクト用の部品構成表のXMLファイルを作成し、そのファイルを使用してデプロイメント計画を自動生成することもできます。このデプロイメント計画を使用すると、統合プロジェクトを形成するAIAサービスとリソースを複数の開発環境、テスト環境および本番環境にデプロイできます。
また、AIAエラー処理フレームワークを構成して、AIAフローのエラーを通知する適切なロールを設定します。
エラー処理の詳細は、Oracle Fusion Middleware Oracle Application Integration Architecture SOAコア拡張機能インフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイドのエラー処理の設定に関する項を参照してください。
この項には次のトピックが含まれます:
図11-37に示すように、次のステップでは、B2B統合フローを構成する新規開発またはデプロイされたAIAサービスをテストします。
図11-37 ステップ7: テストおよび検証
取引パートナとのB2B統合フローを稼働する前に、次の一連のテストを完了することをお薦めします。
AIAサービスでコンポジット・アプリケーション検証システム(CAVS)が使用可能な場合は、テスト・シミュレータを使用してAIAサービスをテストできます。
CAVSシミュレータを使用すると、実際の取引パートナのかわりにテスト・ハーネスとの間でメッセージを送受信することで、取引パートナの動作をシミュレートできます。このテストは、取引パートナに関する知識なしに実行できます。
図11-38に示すように、このテストの目的は、AIAサービスが適切に開発、デプロイおよび構成されていることを確認することです。
図11-38 CAVSを使用したB2B統合フローのテスト
この項には次のトピックが含まれます:
図11-39に示すように、テストする別の一般的な方法は、取引パートナ設定でダミーのデリバリ・チャネルを作成することです。たとえば、アウトバウンド・ドキュメントをリモート取引パートナのサーバーに送信する取引パートナ・アグリーメントを構成するかわりに、サーバー上の一時的なB2Bファイルの場所にアウトバウンドB2Bファイルを作成するようにアグリーメントを構成できます。
図11-39 ダミー取引パートナのエンドポイントを使用したB2B統合フローのテスト
この場合は、アウトバウンドB2Bフローをテストすると、フローに含まれるすべてのコンポーネントが呼び出されますが、生成されたB2Bドキュメントは一時ファイル・ディレクトリにコピーされます。完全性と正確性についてB2Bドキュメントをレビューし、取引パートナとレビューを共有することもできます。
このテストの目的は、AIAサービス、アプリケーションおよびB2B間の統合を検証して、これらのレイヤー全体の構成に一貫性があることを確認することです。
このテストも、取引パートナに関する知識なしに実行できます。
特定のB2Bドキュメント・プロトコルでは、B2Bドキュメントをテスト・モードで送信するか本番モードで送信するかの指定に使用できる、プロトコル・エンベロープレベル・フラグがサポートされています。Oracle B2Bの取引パートナ・アグリーメントは、このインディケータをTestモードに設定するように構成できます。
ここでアウトバウンドB2Bフローをトリガーすると、図11-40に示すように、ドキュメントは取引パートナに送信されますが、取引パートナ・システムによってこのインバウンド・ドキュメントはテスト・インスタンスとして認識され、バックエンド・アプリケーションには渡されません。
図11-40 "Test"に設定された製品コード値を使用したB2B統合フローのテスト
このテストの目的は、B2Bサーバーと取引パートナのB2Bサーバー間のハンドシェイクを検証することです。確認、暗号化、パッケージング、パートナ、ドキュメントIDなどのトランスポート機能およびメッセージング機能の設定が検証されます。
この方法では、各取引パートナにこのテスト・メカニズムについて説明して同意を得る必要があります。
最後に、本番システムからリモート取引パートナの本番システムへの統合を、交換するB2Bドキュメントのダミー・ビジネス・データを使用してテストできます。たとえば、アウトバウンドEDI X12 850 B2Bフローによって統合された、自社(バイヤー)のシステムから取引パートナ(ベンダー)のシステムへのエンドツーエンドのアウトバウンド注文書統合をテストするには、取引パートナ用に作成されたEDIテスト品目を使用するか、注文する品目に1セントの価格を使用して注文を実行します。
図11-41に示すように、注文書のリクエストは取引パートナのビジネス・アプリケーションによって正常に受信されて処理されますが、取引パートナのビジネス・ユーザーまたはルールはこの注文書のリクエストを破棄します。
図11-41 ダミー・ビジネス・データを使用したB2B統合フローのテスト
この方法では、各取引パートナにこのテスト・メカニズムについて説明して同意を得る必要もあります。
この項には次のトピックが含まれます:
図11-42に示すように、最後のステップでは、取引パートナとともにアウトバウンドB2Bドキュメント・フローを稼働します。AIAおよびOracle B2Bデプロイメントは、製品サーバーに複製してエンド・ユーザーにロールアウトします。
図11-42 ステップ8: 稼働および監視
Oracle B2Bの組込みレポートを使用すると、表11-9にリストしたレポートを作成できます。これらのレポートでは、Oracle B2Bのランタイム・トランザクションに対する問合せが実行され、取引パートナとの個々のトランザクションの監視に使用できます。
Oracle B2Bでは、レポートを作成してレポート定義として保存できるため、この定義を使用して、特定の基準(取引パートナGlobalと交換された注文書の表示など)に対するレポートを生成できます。非定型レポートを作成することもできます。
表11-9 Oracle B2Bのレポート・タイプ
| レポート・タイプ | 説明 | レポートの例 |
|---|---|---|
ビジネス・メッセージ・レポート |
これらのレポートでは、特定の検索基準に基づいてビジネス・メッセージが表示されます。 |
取引パートナのGlobalから受信したすべての注文書ドキュメントが表示されます。 |
ワイヤ・メッセージ・ステータス・レポート |
これらのレポートでは、取引パートナとの間で送受信されたネイティブ・データ・フォーマットのワイヤ・メッセージを問い合せることができます。ワイヤ・メッセージ・レポートには、ビジネス・データに加えて、トランスポートおよびプロトコル関連情報が含まれます。 |
取引パートナABC Corpに送信されたすべてのメッセージ(HTTPヘッダーを含む)が表示されます。 |
コラボレーション・ステータス・レポート |
これらのレポートは、タスクを一緒に実行した関連する個々のトランザクションをグループ化するのに役立ちます。 このレポートは、RosettaNetドキュメント・プロトコルでのみサポートされています。 |
すべてのRosettaNet 3A4のコラボレーションが表示されます。 |
エラー・レポート |
これらのレポートは、Oracle B2Bで失敗したすべてのトランザクションを監視するのに役立ちます。 |
エラーのためにOracle B2Bで失敗した取引パートナGlobalから受信したすべてのメッセージが表示されます。 |
B2Bでのレポート機能の使用方法の詳細は、『Oracle Fusion Middleware Oracle B2Bユーザーズ・ガイド』のレポートの作成に関する項を参照してください。
Oracle Enterprise Managerコンソールを使用してAIAフローを監視できます。アウトバウンドB2B統合フローを監視するには、Oracle Enterprise Managerコンソールにログインして、B2BフローをトリガーしたリクエスタABCSのインスタンスを参照します。
ABCSインスタンス、ペイロードおよび子プロセスのステータスのすべてをOracle Enterprise Managerコンソールから監視できます。
コンポジットAIAB2BInterface[1.0]などのインスタンスを参照することで、Oracle B2Bに渡された様々なB2Bヘッダー・パラメータを含むJMSペイロードを表示できます。
AIAレイヤーまたはOracle B2Bでの失敗の場合は、AIAエラー・ハンドラがトリガーされます。AIAフォルト・メッセージには、エラー・テキストと説明が含まれます。また、失敗したトランザクションに関係する送信者、受信者、取引パートナ、ドキュメント・タイプなどのB2B情報もAIAフォルトで提供されます。
エラー通知の詳細は、Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイドのエラー通知の使用に関する項を参照してください。
