Oracle® Fusion Middleware

Oracle SOAコア拡張機能開発者ガイド

12c (12.1.3)

E54313-02(原本部品番号:E37422-03)

2015年7月

SOAコア拡張機能を使用してプロジェクトを概念化する方法を説明します。プロセス統合パックを拡張する新しいサービスの実装方法について説明します。このマニュアルの情報を使用すると、開発したソリューションをアップグレードしてサポートする際に役立ちます。

Oracle Fusion Middleware Oracle SOAコア拡張機能開発者ガイド, 12c (12.1.3)

E54313-02

Copyright © 2014, 2015, Oracle and/or its affiliates.All rights reserved.

原本著者: Oracle Corporation

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- Oracle AIAのマニュアル

- 関連マニュアル

- ドキュメントのアクセシビリティについて

- 表記規則

1 AIA開発用のSOAコア拡張機能の使用

- 1.1 SOAコア拡張機能を使用したAIA開発

- 1.2 AIAの理解

- 1.2.1 AIA Foundation Pack

- 1.2.2 AIAの事前作成済の統合およびプロセス統合パック(PIP)

- 1.3 AIA統合タイプ

- 1.4 AIA統合フロー

- 1.5 この開発者ガイドの使用方法

2 AIA統合フローの作成

- 2.1 開発環境およびテスト環境の設定

- 2.1.1 AIA開発でのQuick Startの入手

- 2.1.2 AIAワークステーションの設定方法

- 2.2 様々な統合スタイルのAIAアーティファクト

- 2.2.1 Oracle Applicationsのテクノロジ・インフラストラクチャを使用したネイティブ・アプリケーション・インタフェースを介した統合

- 2.2.2 統合フレームワークを備えた統合スタイルの理解

- 2.2.3 バルク・データ処理

- 2.2.4 統合スタイルの選択マトリックス

- 2.3 AIAアーティファクトの開発タスク

- 2.3.1 EBOの識別

- 2.3.2 Oracle AIA統合フローの設計

- 2.3.3 EBSの識別と作成

- 2.3.4 ABCSの作成

- 2.3.5 参加アプリケーションの有効化と登録

- 2.3.6 EBFの識別と作成

- 2.4 Oracle AIA統合フローのテスト

3 直接統合の実装

- 3.1 直接統合の理解

- 3.2 直接統合に対するアプリケーション・ビジネス・フロー設計パターンの使用

- 3.3 適切な粒度の検出

- 3.4 トランザクションの処理

- 3.4.1 トランザクション・コンポジットとしてのABFの作成

- 3.4.2 ABFでのトランザクション機能の実現

- 3.5 アプリケーションとのアウトバウンド相互作用の有効化

- 3.5.1 JCAアダプタの使用

- 3.5.2 標準Webサービス・インタフェース(SOAP/HTTP、XML/HTTP)の使用

- 3.5.3 JMSキューの使用

- 3.5.4 1つのコンポジットにおけるまたは個別のコンポジットとしてのアダプタの使用

- 3.6 ABFの呼出し

- 3.7 エラーの処理

- 3.7.1 直接統合サービスの使用

- 3.7.2 フォルト管理フレームワークの使用

- 3.8 サービスの保護

- 3.8.1 認証のためのOWSMポリシーに関するセキュリティ推奨事項

- 3.8.2 コンポジットへのOWSMポリシーの関連付け

- 3.9 相互参照の使用

- 3.10 命名規則および標準

- 3.10.1 ネーミング・サービスに関する追加のガイドライン

- 3.11 コンポジットの注釈付け

- 3.11.1 WSDLへの注釈の付加

- 3.12 サービス構成

- 3.13 直接統合の拡張

- 3.13.1 XSLの拡張

- 3.13.2 サービスの拡張

- 3.13.3 カスタマイズを可能にするためのガイドライン

4 カスタムXPath関数の開発とデプロイ

- 4.1 JavaでのJava XPathクラスとしての関数の実装

- 4.1.1 カスタムXPath関数のネーミング標準

- 4.1.2 サポートされるデータ型

- 4.2 JDeveloperでのXPath/XSL関数のデプロイ

- 4.3 アプリケーション・サーバーでのXPath/XSL関数のデプロイ

5 エンタープライズ・ビジネス・サービスの設計と開発

- 5.1 エンタープライズ・ビジネス・サービスの概要

- 5.1.1 EBSタイプの理解

- 5.1.2 エンタープライズ・ビジネス・サービス・ライブラリの使用

- 5.2 EBSの設計

- 5.2.1 設計ガイドラインの理解

- 5.2.2 設計上の考慮事項の理解

- 5.2.3 新規プロセスEBSのMEPの設定

- 5.2.4 新規プロセスEBSのMEPの設定方法

- 5.2.5 エラーの処理方法

- 5.2.6 EBSの保護方法

- 5.2.7 トランザクションの構成方法

- 5.2.8 配信の保証方法

- 5.2.9 EBSサービス・コントラクトの定義方法

- 5.3 プロセスEBS用のWSDLの作成

- 5.3.1 アクティビティ・サービスEBS用のWSDL作成の概要

- 5.3.2 <definitions>セクションの完了方法

- 5.3.3 メッセージ構造の定義方法

- 5.3.4 WS-I基本プロファイル準拠の確認方法

- 5.4 メッセージ・ルーティングの使用

- 5.4.1 ルーティング・ルールの作成

- 5.4.2 EBSでのルーティング

- 5.4.3 EBSルーティング・ルールに関するガイドライン

- 5.4.4 EBSでのターゲット・システムの識別方法

- 5.5 Oracle Mediatorを使用したEBSの作成

- 5.5.1 Oracle Mediatorサービスの開発方法

- 5.6 ファイア・アンド・フォーゲット・メッセージ交換パターンの実装

- 5.6.1 EBSの一方向コールを使用したファイア・アンド・フォーゲット・パターンの実装方法

- 5.6.2 EBS WSDLの作成

- 5.6.3 一方向コールEBSを使用した非同期ファイア・アンド・フォーゲット・パターンに対するメディエータ・ルーティング・サービスの作成

- 5.6.4 補正操作を使用した非同期ファイア・アンド・フォーゲットMEPのエラー処理

- 5.6.5 EBSの補正操作の呼出し方法

- 5.6.6 補正操作ルーティング・サービスのルーティング・ルールの有効化方法

- 5.7 同期リクエスト/レスポンス・メッセージ交換パターンの実装

- 5.7.1 EBSでの同期リクエスト/リプライ・メッセージ交換パターンの実装方法

- 5.7.2 同期リクエスト/レスポンスMEPのメディエータ・プロジェクトの作成方法

- 5.7.3 同期リクエスト/レスポンスMEPのルーティング・サービスの作成方法

- 5.7.4 同期リクエスト/レスポンスMEPのエラー処理の実装方法

- 5.8 非同期リクエスト/遅延レスポンス・メッセージ交換パターンの実装

- 5.8.1 EBSの2つの一方向コールを使用したリクエスト/遅延レスポンス・パターンの実装方法

- 5.8.2 2つの一方向コールEBSを使用した非同期リクエスト/遅延レスポンス・パターンに対するメディエータ・ルーティング・サービスの作成

- 5.8.3 非同期リクエスト/遅延レスポンスMEPのエラー処理

6 アプリケーション・ビジネス・コネクタ・サービスの設計

- 6.1 ABCSの概要

- 6.1.1 ABCSタイプ

- 6.1.2 ABCSの設計 - 主要タスク

- 6.2 ABCSコントラクトの定義

- 6.2.1 ABCSの役割の定義

- 6.2.2 ABMスキーマの作成

- 6.2.3 参加アプリケーションの統合機能の分析

- 6.3 MEPの識別

- 6.3.1 MEPの概要

- 6.3.2 適切なMEPの選択

- 6.4 テクノロジ・オプション

- 6.4.1 アプリケーションとのアウトバウンド相互作用

- 6.4.2 BPELを使用したABCSの作成

7 ABCSの作成

- 7.1 ABCSの作成

- 7.1.1 前提条件

- 7.1.2 コンポジット・アプリケーションとしてのABCS

- 7.1.3 作成するコンポーネントの必要数

- 7.2 JDeveloperを使用したABCSコンポジットの作成

- 7.2.1 JDeveloperを使用したABCSコンポジットの作成方法

- 7.2.2 BPELプロセスの開発

- 7.2.3 参照、サービスおよびコンポーネントの作成方法

- 7.2.4 抽象サービスWSDLのMDSへの移動

- 7.3 ファイア・アンド・フォーゲットMEPの実装

- 7.3.1 補正サービスを使用する時期

- 7.3.2 補正サービスを呼び出す方法

- 7.3.3 このMEPを実装するのにプロバイダABCSで必要な追加タスク

- 7.3.4 トランザクションの確認方法

- 7.3.5 エラーの処理方法

- 7.4 非同期リクエスト/遅延レスポンスMEPの実装

- 7.4.1 非同期遅延レスポンスのEBMヘッダーの入力方法

- 7.4.2 非同期リクエスト/遅延レスポンスMEPの相関の設定

- 7.4.3 非同期リクエスト/遅延レスポンスMEPでエラー・レスポンスを処理するためのプログラミング・モデル

- 7.4.4 このMEPを実装するのにプロバイダABCSで必要なタスク

- 7.5 非同期メッセージ交換でのプロバイダABCSの実装シナリオ

- 7.5.1 非同期MEPの実装方法

- 7.5.2 リクエスト/遅延レスポンス・パターンに対するプログラミング・モデルの使用

- 7.5.3 サービスでのトランザクションの確認方法

- 7.5.4 非同期リクエスト/遅延レスポンスMEPでのエラーの処理方法

- 7.6 同期リクエスト/レスポンス・メッセージ交換の実装シナリオ

- 7.6.1 サービスでのトランザクションの確認方法

- 7.6.2 同期リクエスト/レスポンスMEPでのエラーの処理方法

- 7.6.3 レスポンス時間を短縮するためにサービスを最適化する方法

- 7.7 エンタープライズ・ビジネス・サービスの呼出し

- 7.7.1 Create

- 7.7.2 Update

- 7.7.3 Delete

- 7.7.4 Sync

- 7.7.5 Validate

- 7.7.6 Process

- 7.7.7 Query

- 7.8 ABCSの呼出し

- 7.8.1 アプリケーションからABCSを直接呼び出す方法

- 7.8.2 トランスポート・アダプタを使用してABCSを呼び出す方法

- 7.8.3 エンタープライズ・ビジネス・サービスがABCSを呼び出す時期

8 ABCS開発の完了

- 8.1 拡張可能なABCSの開発

- 8.1.1 リクエスタABCSを拡張可能にする方法の概要

- 8.1.2 プロバイダABCSを拡張可能にする方法の概要

- 8.1.3 拡張対応のABCSの設計方法

- 8.1.4 拡張を伴うABCSコンポジットの設計

- 8.1.5 拡張ポイントでのサービスの定義

- 8.1.6 抽象WSDLを使用するサービスの定義

- 8.1.7 デプロイメント時に具象WSDLを指定する方法

- 8.1.8 ABCS BPELプロセスでの拡張ポイントの設計

- 8.1.9 拡張ポイントPre-ProcessABMの設定方法

- 8.1.10 拡張ポイントPre-ProcessEBMの設定方法

- 8.1.11 サーブレットをサンプル拡張サービスとして使用して拡張をテストする方法

- 8.2 エラーおよびフォルトの処理

- 8.2.1 エラーおよびフォルトの処理方法

- 8.3 アダプタの操作

- 8.3.1 トランスポート・アダプタとのインタフェース

- 8.3.2 トランスポート・アダプタの開発方法

- 8.3.3 ポータルDBアダプタを開発する方法

- 8.3.4 1つのコンポジットに複数のアダプタを配置する場合

- 8.3.5 バージョン・アダプタの計画

- 8.3.6 バージョン・アダプタの構成方法

- 8.4 CAVS対応のABCSの開発

- 8.4.1 プロバイダABCSをCAVS対応にする方法

- 8.4.2 リクエスタABCSをCAVS対応にする方法

- 8.4.3 CAVSEndpointURL値設定の概要

- 8.4.4 テスト・シナリオを再実行可能にするためのCAVS関連の相互参照エンティティのパージ

- 8.5 ABCSの保護

- 8.5.1 ABCSを保護する方法

- 8.6 トランザクションの有効化

- 8.6.1 AIAサービスでのトランザクションの確認方法

- 8.6.2 Oracle Mediatorでのトランザクション

- 8.6.3 BPELでのトランザクション

- 8.6.4 グローバル・トランザクションに参加するABCSの開発

- 8.6.5 AIAサービスをトランザクション対応にする方法

- 8.7 メッセージ配信の保証

- 8.8 ABCSのバージョニング

- 8.8.1 バージョニングに関するガイドライン

- 8.9 Oracle Mediatorにおける再順序付け

- 8.9.1 リシーケンサ機能を使用するOracle Mediatorサービスの構成

- 8.9.2 再順序付け戦略の構成方法

- 8.9.3 複数グループの同時処理

- 8.9.4 Oracle Mediatorのリシーケンサのエラー管理の説明

- 8.9.5 リシーケンサの調整

- 8.10 レイヤー・カスタマイズの開発

- 8.10.1 カスタマイズ後のサービスのデプロイ

- 8.10.2 顧客バージョンのカスタマイズ

- 8.10.3 カスタマイズ後のパッチの適用

9 エンタープライズ・ビジネス・フローの設計と作成

- 9.1 エンタープライズ・ビジネス・フローの概要

- 9.2 EBF用のコントラクトの定義方法

- 9.2.1 EBFの必要性を識別する方法

- 9.2.2 EBFのメッセージ・パターンを識別する方法

- 9.2.3 メッセージ構造を識別する方法

- 9.3 EBF用のコントラクトの作成方法

- 9.3.1 EBF用のWSDLの作成

- 9.4 EBFをBPELサービスとして実装する方法

10 AIAを使用したB2B統合の概要

- 10.1 AIAを使用したB2B統合の概要

- 10.2 B2Bドキュメント・フローの理解

- 10.2.1 AIAを使用して作成されたアウトバウンドB2Bドキュメント・フローの説明

- 10.2.2 AIAを使用して作成されたインバウンドB2Bドキュメント・フローの説明

- 10.3 Oracle Fusion MiddlewareのOracle B2Bコンポーネントの理解

- 10.3.1 AIAによるOracle Fusion Middleware Oracle B2Bの補完

- 10.4 B2B用のSOAコア拡張機能インフラストラクチャの理解

- 10.4.1 AIAエラー処理フレームワークのB2Bサポート

- 10.4.2 AIA B2Bインタフェース

11 アウトバウンドB2B統合フローの開発と実装の概要

- 11.1 アウトバウンドB2B統合フローの開発と実装の概要

- 11.2 ステップ1: B2Bドキュメントの識別および要件の分析

- 11.2.1 B2Bドキュメント・プロトコルの識別方法

- 11.2.2 B2Bドキュメント・タイプおよび定義の識別方法

- 11.2.3 Oracle B2Bでのドキュメントの定義方法

- 11.2.4 AIAでのドキュメントの定義方法

- 11.2.5 使用するEBO、EBSおよびEBMの識別方法

- 11.2.6 B2Bドキュメントに対するマッピングの設計方法

- 11.2.7 取引パートナへのマッピングの公開方法

- 11.3 ステップ2: 新規のプロバイダB2Bコネクタ・サービスの開発

- 11.3.1 プロバイダB2Bコネクタ・サービスの概要

- 11.3.2 メッセージ交換パターンの識別方法

- 11.3.3 B2BCSサービス・コントラクトの開発方法

- 11.3.4 Oracle Metadata RepositoryへのWSDLの格納方法

- 11.3.5 B2Bコネクタ・サービスの開発方法

- 11.3.6 AIA B2Bインタフェースのカスタマイズ方法

- 11.3.7 B2Bコネクタ・サービスの注釈付け方法

- 11.3.8 取引パートナ固有のバリアントのサポート方法

- 11.3.9 エラー処理の有効化方法

- 11.4 ステップ3: 既存のエンタープライズ・ビジネス・サービスの開発または拡張

- 11.4.1 取引パートナB2Bプリファレンスに基づいたルーティング方法

- 11.5 ステップ4: 既存のリクエスタABCSの開発または拡張

- 11.5.1 メッセージ交換パターンに関する必要な知識

- 11.5.2 変換に関する必要な知識

- 11.6 ステップ5: Oracle B2Bの構成および取引パートナ・アグリーメントの定義

- 11.7 ステップ6: AIAサービスのデプロイと構成

- 11.8 ステップ7: テストおよび検証

- 11.8.1 CAVSを使用したテスト方法

- 11.8.2 ダミー取引パートナのエンドポイントを使用したテスト方法

- 11.9 ステップ8: 稼働および監視

- 11.9.1 Oracle B2Bレポートを使用した監視

- 11.9.2 Oracle Enterprise Managerコンソールを使用した監視

- 11.9.3 エラー通知を使用した監視

12 インバウンドB2B統合フローの開発と実装の概要

- 12.1 インバウンドB2B統合フローの開発と実装の概要

- 12.2 ステップ1: B2Bドキュメントの識別および要件の分析

- 12.3 ステップ2: AIA B2Bインタフェースへのインバウンド・ルーティング・ルールの追加

- 12.3.1 AIA B2Bインタフェースへの新しいルーティング・ルールの追加方法

- 12.4 ステップ3: 新しいリクエスタB2Bコネクタ・サービスの開発

- 12.4.1 リクエスタB2Bコネクタ・サービスの概要

- 12.4.2 メッセージ交換パターンの識別方法

- 12.4.3 B2BCSサービス・コントラクトの開発方法

- 12.4.4 Oracle Metadata Services RepositoryへのWSDLの格納方法

- 12.4.5 B2Bコネクタ・サービスの開発方法

- 12.4.6 B2Bコネクタ・サービスの注釈付け方法

- 12.4.7 取引パートナ固有のバリアントのサポート方法

- 12.4.8 エラー処理の有効化方法

- 12.5 ステップ4: 既存のエンタープライズ・ビジネス・サービスの開発または拡張

- 12.6 ステップ5: 既存のプロバイダABCSの開発または拡張

- 12.6.1 変換に関する必要な知識

- 12.7 ステップ6: Oracle B2Bの構成および取引パートナ・アグリーメントの定義

- 12.8 ステップ7: AIAサービスのデプロイと構成

- 12.9 ステップ8: テストおよび検証

- 12.10 ステップ9: 稼働および監視

13 イベント集約プログラミング・モデルの説明

- 13.1 概要

- 13.1.1 イベント・プロデューサ

- 13.1.2 イベント・アグリゲータ・サービス

- 13.1.3 サービスの消費

- 13.2 イベント集約プログラミング・モデルの実装

- 13.2.1 イベント集約サービスの作成

- 13.2.2 コンシューマ・サービスの作成

- 13.2.3 イベント集約プログラミング・モデル用のエラー処理の実装

14 リソース接続の確立

- 14.1 リソース接続の概要

- 14.1.1 インバウンド接続

- 14.1.2 アウトバウンド接続

- 14.2 接続のモード

- 14.2.1 SOAP/HTTPを使用したWebサービス

- 14.2.2 SOAP/HTTPを使用したWebサービスを使用する場合

- 14.2.3 SOAP/HTTPを使用したWebサービスのセッション管理

- 14.2.4 SOAP/HTTPを使用したWebサービスのエラー処理

- 14.2.5 SOAP/HTTPを使用したWebサービスのセキュリティ

- 14.2.6 キューまたはトピックを使用したメッセージの伝播

- 14.2.7 保証付きメッセージ配信の確保

- 14.2.8 JCAアダプタを使用する場合

- 14.3 Siebelアプリケーション固有の接続ガイドライン

- 14.3.1 インバウンド: SiebelアプリケーションのAIAサービスとの相互作用

- 14.3.2 SOAP/HTTPを使用したWebサービス

- 14.3.3 サービス設計と作成フェーズでの開発者向けのタスク

- 14.3.4 JMSキュー/トピックからSiebelメッセージを使用するJMSコンシューマの作成

- 14.3.5 サービス設計とアウトライン作成フェーズでの開発者向けのタスク

- 14.3.6 アウトバウンド - SiebelアプリケーションのAIAサービスとの相互作用

- 14.3.7 SOAP/HTTPを使用したWebサービス

- 14.4 Oracle E-Business Suiteアプリケーション固有の接続ガイドライン

- 14.4.1 インバウンド: E-Business SuiteアプリケーションのAIAサービスとの相互作用

- 14.4.2 コンカレント・プログラム実行可能ファイル

- 14.4.3 ベスト・プラクティスと設計非同期パターン

- 14.4.4 ビジネス・イベント・サブスクリプション(OAPPSアダプタを使用したJCA接続)

- 14.4.5 アウトバウンド: Oracle E-Business SuiteアプリケーションのAIAサービスとの相互作用

- 14.5 設計のガイドライン

15 バルク処理に対するOracle Data Integratorの使用

- 15.1 AIA-Oracle Data Integratorアーキテクチャの設計パターンの概要

- 15.1.1 初期データ・ロード

- 15.1.2 Oracle Data Integratorのデータ・ロードの実行方法

- 15.1.3 Xref表ありの大規模トランザクション

- 15.1.4 断続的な大規模トランザクション

- 15.2 Xref表ありの大規模トランザクション

- 15.3 Oracle Data Integratorプロジェクトの作成

- 15.3.1 Oracle Data Integratorプロジェクトの作成方法

- 15.4 XREFナレッジ・モジュールの使用

- 15.4.1 相互参照に関する必要な知識

- 15.5 Oracle Data Integratorの使用

- 15.5.1 変数の定義方法(ソース列名とターゲット列名)

- 15.5.2 最初のインタフェースの作成方法(ソースからターゲット)

- 15.5.3 最初のインタフェースに対するパッケージの作成方法

- 15.5.4 SOAでのXREFビューの定義方法

- 15.5.5 2番目のインタフェースの作成方法(XREFのターゲット識別子の更新)

- 15.6 ドメイン値マップの使用

- 15.7 エラー処理の使用

- 15.8 Oracle Data IntegratorのRef関数

- 15.9 パッケージおよびデータ・モデルをWebサービスとして公開する方法

16 メッセージ変換の使用

- 16.1 変換マップの概要

- 16.1.1 ビジネス・プロセスを実装するためのアプリケーションの接続

- 16.1.2 メッセージ変換を実行するためのツールおよびテクノロジの使用

- 16.2 変換マップの作成

- 16.2.1 変換マップの作成に関する考慮事項

- 16.2.2 欠落または空の要素の処理

- 16.2.3 オプションのターゲット・ノードへのオプションのソース・ノードのマップ方法

- 16.2.4 システムIDの動的ロード方法

- 16.2.5 大規模ペイロードに対するXSLT変換の使用

- 16.2.6 LanguageCode属性の値を入力する場合

- 16.2.7 変換名の指定方法

- 16.3 変換マップ拡張機能の使用

- 16.3.1 変換マップ拡張機能を使用可能にする方法

- 16.3.2 変換テンプレートの業種を拡張可能にする方法

- 16.4 DVMおよび相互参照の使用

- 16.4.1 DVMの概要

- 16.4.2 DVMの使用が必要な状況

- 16.4.3 相互参照の使用

- 16.4.4 相互参照の設定方法

- 16.5 識別タイプのマップと入力

- 16.5.1 corecom:Identificationに対する値の入力方法

- 16.6 EBMヘッダー概念の概要

- 16.6.1 標準的な要素

- 16.6.2送信者

- 16.6.3 ターゲット

- 16.6.4 BusinessScope

- 16.6.5 ユースケース: リクエスト/レスポンス

- 16.6.6 ユースケース: 非同期プロセス

- 16.6.7 ユースケース: 子プロセスの生成を伴う同期プロセス

- 16.6.8 EBMTracking

- 16.6.9 カスタム

17 エラー処理およびトレース・ロギング用のOracle AIAプロセスの構成

- 17.1 Oracle BPELおよびMediatorプロセスのエラー処理の概要

- 17.1.1 Oracle BPELエラー処理の理解

- 17.1.2 Oracle Mediatorエラー処理の理解

- 17.2 AIAエラー・ハンドラ・フレームワークの概要

- 17.3 フォルト処理のためのAIAプロセスの有効化

- 17.3.1 フォルト・ポリシー・ファイルに関する必要な知識

- 17.3.2 BPELプロセスでのフォルト処理の実装方法

- 17.4 同期メッセージ交換パターンに対するエラー処理の実装

- 17.4.1 フォルト・ポリシーを定義するためのガイドライン

- 17.4.2 同期リクエスト/レスポンスでのBPELのCatchおよびCatch-Allブロックに関するガイドライン

- 17.4.3 ビジネス・フォルトを処理するためのメディエータの構成に関するガイドライン

- 17.5 保証付きメッセージ配信を確保するための非同期メッセージ交換パターンに対するエラー処理およびリカバリの実装

- 17.5.1 概要

- 17.5.2 マイルストンの構成

- 17.5.3 マイルストン間のサービスの構成

- 17.5.4 BPELのCatchおよびCatch-Allブロックに関するガイドライン

- 17.5.5 フォルト・ポリシーを定義するためのガイドライン

- 17.5.6 未発行ロールバック・メッセージに対するフォルト・ポリシーの構成

- 17.5.7 メッセージ再発行ユーティリティAPIの使用

- 17.6 通知のためのAIAサービスの構成方法

- 17.6.1 修正処理コードの定義

- 17.6.2 エラー・メッセージ・コードの定義

- 17.7 Oracle AIAフォルト・メッセージ・スキーマの説明

- 17.7.1 EBMReference要素の説明

- 17.7.2 B2BMReference要素の説明

- 17.7.3 FaultNotification要素の説明

- 17.8 フォルト・メッセージの拡張

- 17.8.1 フォルト・メッセージの拡張の概要

- 17.8.2 フォルト・メッセージの拡張

- 17.9 エラー処理の拡張

- 17.9.1 エラー処理の拡張の概要

- 17.9.2 エラー処理の拡張機能の実装

- 17.10 トレース・ロギングのためのOracle AIAプロセスの構成

- 17.10.1 isTraceLoggingEnabledカスタムXPath関数の詳細の説明

- 17.10.2 logTraceMessageカスタムXPath関数の詳細の説明

- 17.10.3 トレース・ロギングJava APIの説明

18 AIA設計パターンの使用

- 18.1 AIAメッセージ処理パターン

- 18.1.1 同期リクエスト/リプライ・パターン: AIAでの同期レスポンスの取得方法

- 18.1.2 非同期ファイア・アンド・フォーゲット・パターン

- 18.1.3 保証付き配信パターン: AIAでの保証付き配信の確保方法

- 18.1.4 サービス・ルーティング・パターン: AIAでの適切なサービス・プロバイダへのメッセージのルーティング方法

- 18.1.5 競合コンシューマ・パターン: 並列性および効率を改善するための複数コンシューマの使用方法

- 18.1.6 非同期遅延/レスポンス・パターン: 同期通信が適切でない状況でのリクエスタに対するサービス・プロバイダの通信方法

- 18.1.7 非同期リクエスト/レスポンス・パターン: サービス・プロバイダによるリクエスタに関連するエラーの通知方法

- 18.2 AIAアセット一元化パターン

- 18.2.1 AIAでの冗長なデータ・モデル表現の回避方法

- 18.2.2 AIAでの冗長なサービス・コントラクト表現の回避方法

- 18.3 AIAアセット拡張性パターン

- 18.3.1 AIAでの既存のスキーマの拡張

- 18.3.2 AIAサービスの拡張

- 18.3.3 AIAでの既存の変換の拡張

- 18.3.4 AIAでのビジネス・プロセスの拡張

19 セキュリティに関する作業

- 19.1 Oracle AIAリモート・セキュリティの概要

- 19.1.1 サービス間相互作用の保護

- 19.1.2 サービスの保護に関するOracle AIAの推奨事項

- 19.1.3 Oracle Web Services Managerを使用したWebサービス・セキュリティの概要

- 19.2 セキュリティの実装

- 19.2.1 AIAサービスに対するセキュリティの有効化

- 19.2.2 保護されたアプリケーション・サービスの呼出し

- 19.2.3 デプロイメント計画を使用したポリシーのオーバーライド

- 19.2.4 CAVSを使用した保護サービスのテスト

- 19.3 アプリケーションのセキュリティ

- 19.3.1 アプリケーション・サービスでのセキュリティの有効化

- 19.3.2 保護されたAIAサービスの呼出し

- 19.4 セキュリティ・ポリシーのデプロイ

- 19.4.1 ポリシーに関するOracle AIAの推奨事項

- 19.5 ポリシーの命名規則

- 19.5.1 グローバル・ポリシー・セットの命名規則

- 19.5.2 構成パラメータをオーバーライドする際の命名規則

- 19.6 AIAサービスの保護に役立つSOAコア拡張機能

- 19.6.1 サービスにアタッチされるデフォルトのポリシー

- 19.6.2 個々のサービスに対するグローバル・ポリシーをオーバーライドする方法

- 19.6.3 AIAセキュリティ構成プロパティ

- 19.7 アプリケーション・セキュリティ・コンテキスト

- 19.7.1 アプリケーション・セキュリティの概要

- 19.7.2 参加アプリケーションとABCS間でセキュリティ・コンテキストを交換する方法

- 19.7.3 ABCSのアプリケーション・セキュリティ・コンテキストと標準セキュリティ・コンテキスト間のマッピング

- 19.7.4 AppContextマッピング・サービスの使用

- 19.7.5 セキュリティ・コンテキストの構造の理解

- 19.7.6 属性名の使用

- 19.7.7 EBSおよびEBFを介した標準セキュリティ・コンテキストの伝播

- 19.7.8 アプリケーション・セキュリティ・コンテキストの実装

20 エンドツーエンド統合フローの設計と作成に関するベスト・プラクティス

- 20.1 AIAプロセスの設計、開発および管理に関する一般的なガイドライン

- 20.1.1 XMLインスタンス・ドキュメントにある空の要素タグの解釈

- 20.1.2 完了したコンポジット・インスタンスのパージ

- 20.1.3 XMLメッセージの構文/機能の検証

- 20.1.4 スロットル機能に対するプロビジョニングの指定

- 20.1.5 アーティファクトの集中管理

- 20.1.6 関心の分離

- 20.1.7 ABCSコンポジット内のアダプタまたは個別のコンポジットとしてのアダプタ

- 20.1.8 AIAの管理

- 20.2 効率的なBPELプロセスの作成

- 20.2.1 プログラミング言語ではなく「グルー」としてのBPELの使用

- 20.2.2 グローバル変数の極力回避

- 20.2.3 大きなFlowNの回避

- 20.2.4 同期BPELプロセスに関する監査詳細の永続性の制御

- 20.2.5 多重呼出し不変ではないサービスの使用は絶対必要な場合のみに限定

- 20.2.6 トランザクションのスコープの定義

- 20.2.7 同期BPELプロセス・サービス・コンポーネントに対する監査の無効化

- 20.2.8 リクエスト/レスポンス・フローへのブレーク・ポイントなしアクティビティの組込み

21 AIA開発でのOracle AIAネーミング標準

- 21.1 一般的なガイドライン

- 21.1.1 XMLネーミング標準

- 21.2 コンポジット

- 21.3 コンポジット・ビジネス・プロセス

- 21.4 エンタープライズ・ビジネス・サービス

- 21.5 エンタープライズ・ビジネス・フロー

- 21.6 アプリケーション・ビジネス・コネクタ・サービス

- 21.6.1 リクエスタ・アプリケーション・ビジネス・コネクタ・サービス

- 21.6.2 プロバイダ・アプリケーション・ビジネス・コネクタ・サービス

- 21.7 JMSおよびアダプタ

- 21.7.1 AQ JMS (追加属性)

- 21.7.2 アダプタ・サービスのネーミング

- 21.7.3 参加アプリケーション・サービス

- 21.8 DVMおよび相互参照

- 21.8.1 DVM

- 21.8.2 相互参照

- 21.9 BPEL

- 21.9.1 BPELアクティビティ

- 21.9.2 その他のBPELアーティファクト

- 21.10 カスタムJavaクラス

- 21.11 パッケージ構造

- 21.12 Deploymentデプロイメント計画

22 マッピング・エディタを使用した変換の編集

- 22.1 マッピング・エディタの概要

- 22.2 マッピング・エディタの管理

- 22.2.1 マッピング・エディタの有効化

- 22.2.2 AgileAPI.jarファイルの共有ライブラリとしてのデプロイ

- 22.3 「マッピングの検索」ページの使用

- 22.4 変換の編集

- 22.4.1 「マッピング・エディタ」ページ

- 22.4.2 マッピングの作成(例)

- 22.5 マッピング・エディタの編集ルール

- 22.5.1 定義

- 22.5.2 読取り専用の文

- 22.5.3 ドラッグ・アンド・ドロップまたは入力

- 22.5.4 行の挿入

- 22.5.5 削除

- 22.5.6 For-Eachの編集ルール

- 22.5.7 実行コンテキストの変更の許可

- 22.5.8 実行コンテキスト変更時の相対パスの調整

- 22.6 カスタマイズ・レイヤーの理解

- 22.7 編集した変換のデプロイ

- 22.8 カスタマイズの削除

A 提供されるOracle AIA XPath関数

- A.1 aia:getSystemProperty()

- A.1.1 パラメータ

- A.1.2 戻り値

- A.1.3 使用方法

- A.2 aia:getSystemModuleProperty()

- A.2.1 パラメータ

- A.2.2 戻り値

- A.2.3 使用方法

- A.3 aia:getServiceProperty()

- A.3.1 パラメータ

- A.3.2 戻り値

- A.3.3 使用方法

- A.4 aia:getEBMHeaderSenderSystemNode()

- A.4.1 パラメータ

- A.4.2 戻り値

- A.4.3 使用方法

- A.5 aia:getSystemType()

- A.5.1 パラメータ

- A.5.2 戻り値

- A.5.3 使用方法

- A.6 aia:getErrorMessage()

- A.6.1 パラメータ

- A.6.2 戻り値

- A.6.3 使用方法

- A.7 aia:getCorrectiveAction()

- A.7.1 パラメータ

- A.7.2 戻り値

- A.7.3 使用方法

- A.8 aia:isTraceLoggingEnabled()

- A.8.1 パラメータ

- A.8.2 戻り値

- A.8.3 使用方法

- A.9 aia:logErrorMessage()

- A.9.1 パラメータ

- A.9.2 戻り値

- A.9.3 使用方法

- A.10 aia:logTraceMessage()

- A.10.1 パラメータ

- A.10.2 戻り値

- A.10.3 使用方法

- A.11 aia:getNotificationRoles()

- A.11.1 パラメータ

- A.11.2 戻り値

- A.11.3 使用方法

- A.12 aia:getAIALocalizedString()

- A.12.1 パラメータ

- A.12.2 戻り値

- A.12.3 使用方法

- A.13 aia:getConvertedDate()

- A.13.1 パラメータ

- A.13.2 戻り値

- A.13.3 使用方法

- A.14 aia:getConvertedDateWithTZ()

- A.14.1 パラメータ

- A.14.2 戻り値

- A.14.3 使用方法

B CAVS対応Oracle AIAサービス開発用のXSL

- B.1 AddTargetSystemID.xsl

- B.2 SetCAVSEndpoint.xsl

はじめに

へようこそ。このマニュアルでは、SOAコア拡張機能を使用してAIAプロジェクトを概念化する方法を説明します。このマニュアルの情報を使用すると、開発したAIAソリューションをアップグレードしてサポートする際に役立ちます。

対象読者

このマニュアルは、開発者を対象としており、Oracle Application Integration Architecture (AIA)プロジェクトの概念化に役立つ情報を提供します。

このマニュアルで提供されるガイドに従うことで、自社のAIAソリューションは最適なアップグレード、サポートおよび保守のパスをたどることができます。

Oracle AIAのマニュアル

このリリースでは、この開発者ガイドに加えて、次のOracle AIAマニュアルが提供されます。

- Oracle Application Integration Architecture Foundation Packコンセプトおよびテクノロジ・ガイド

- Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイド

関連マニュアル

次のマニュアルはOracle AIA開発アクティビティに関連し、Oracle Fusion Middlewareドキュメント・ライブラリの一部として提供されています。

- Oracle SOA SuiteおよびBusiness Process Managementのインストールおよび構成

- Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理

- 『Oracle SOA Suiteを使用したSOAアプリケーションの開発』

- 『Webサービスの管理』

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティへの取り組みについては、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)にアクセスしてください。

Oracle Supportへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info、聴覚に障害があるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このマニュアルでは次の表記規則を使用します。

表記規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 AIA開発用のSOAコア拡張機能の使用

この章では、AIA開発用のSOAコア拡張機能テクノロジの使用方法と機能の概要を説明します。

この章では、次の項目について説明します。

- AIAの理解

- AIA統合タイプ

- AIA統合フロー

- SOAコア拡張機能を使用したAIA開発

- この開発者ガイドの使用方法

1.1 SOAコア拡張機能を使用したAIA開発

SOAコア拡張機能(SCE)はSOA 12cとともに提供されている機能であり、Oracle Application Integration Architecture (AIA)ベースの統合プロジェクトがSOA 12cへのアップグレード後に継続して動作するために必要な機能を提供します。

AIAスタイル統合を11gで実行している顧客は、ドメイン構成時/SOA 12cへのアップグレードの拡張部分でSOAコア拡張機能の機能を選択します。この機能を選択すると、任意のAIAスタイル統合のデプロイに必要なフレームワークと機能が、必要に応じて提供されます。

SOAコア拡張機能では、次の機能が提供されます。

- AIAコンポジット・アプリケーション検証システム(CAVS) - CAVSは、Oracle Application Integration Architecture (Oracle AIA)サービスの統合をテストするための構造化された方式を提供するフレームワークです。CAVS機能には、Webサービスの呼出しをテストするテスト・イニシエータ、およびサービスのエンドポイントをシュミレートするシミュレータがあります。

- AIAエラー処理フレームワーク(AIA-EH) - Oracle AIAエラー処理フレームワークでは、Oracle Application Integration Architecture (AIA)エコシステムで動作する統合サービスのニーズをサポートするためのエラー処理およびロギング・コンポーネントが提供されます。

- AIAエラー再発行ユーティリティ - AIAメッセージ再発行ユーティリティを使用すると、ユーザーは、キュー、トピック、リシーケンサまたはAQの統合マイルストンに基づいてエラー・メッセージを再発行できます。

- AIA管理コンソール - 管理者がCAVSなどの機能を使用するためのWebベースのアプリケーション。

1.2 AIAの理解

Oracle Application Integration Architecture (AIA)は、エンタープライズ・アプリケーション全体にわたるユーザー中心の機動的なビジネス・プロセスを編成するための、事前作成済のコンテンツ、テンプレートおよび手法で構成されるフレームワークです。オラクル社は、コストを削減し、ビジネスの柔軟性を高めるために、業界のベスト・プラクティスおよびオープン・スタンダードを利用して、最も優れたアプリケーション(Oracleおよび非Oracle)の連携を可能にします。

1.2.1 AIA Foundation Pack

Oracle Application Integration Architecture Foundation Packでは、構成を処理するためのより迅速で構造化された反復可能な方法が提供されます。AIA Foundation Packでは、Oracleの事前作成済の統合に対するフレームワークが提供されます。Oracle Application Integration Architecture Foundation Pack 11gでは、共通オブジェクトおよび共有サービス・ライブラリを提供するとともに、SOAプログラミング・モデルおよびベスト・プラクティスの実装方法もサポートしていました。Oracle AIA Foundation Packを使用すると、Oracleの顧客およびパートナは、そのアプリケーションを最新化し、システムを連結して、Oracleアプリケーション、およびOracleで使用されている同じ規則に従う非Oracleアプリケーション全体で、事前作成済の統合を提供するようにビジネス・プロセスを改善および拡張できます。

1.2.2 AIAの事前作成済の統合およびプロセス統合パック(PIP)

Oracle Application Integration Architecture (AIA)では、直接統合またはプロセス統合パックのいずれかで、事前作成済の統合が提供されます。

- 直接統合(DI) - アプリケーション間のデータ・フローおよびデータ同期化を管理する事前作成済の統合。

- プロセス統合パック(PIP) - 事前作成済の統合のアクセラレータでは、データ中心の統合、Webサービス、参照データ問合せまたはプロセス中心の統合(あるいはこれらの組合せ)など、1つ以上の統合スタイルが結合されます。これらでは、Oracle AIA Foundation Pack内で定義されている設計パターン、手法および共通オブジェクトとサービスが利用されます。

1.3 AIA統合タイプ

AIAでは、2つのタイプの統合が処理されます。

- 機能統合
機能統合では、サービスとして公開される異なる参加アプリケーションの様々な機能が、エンタープライズ内の複数のアプリケーションにまたがるタスクを実行するプロセスとして組み込まれます。

- データ統合
データ統合では、アプリケーションがデータ・レベルで連結され、同じデータを複数のアプリケーションで使用できるようにします。このタイプの統合はデータベース・テクノロジに依存し、アプリケーション全体で最小限のビジネス・ロジックが再使用され、大量のデータ・トランザクションが含まれる場合に最適です。このタイプの統合は、バッチ・データのアップロードまたはバルク・データの同期要件に適しています。

1.4 AIA統合フロー

AIAでは、様々な状況に対する参照アーキテクチャが提供されます。統合プロジェクトの規模と複雑さに応じて、統合フローの実装のために採用される統合スタイルはそれぞれ異なります。統合フローにおける参加アプリケーションの数とその役割が、採用する統合スタイルを決定する一因となります。

図1-1に示した統合フローは、ビジネス・イベント・トリガー・ソースから1つ以上のターゲット・マイルストンまでの、考えられる中間マイルストンを通過した後のメッセージの推移を表しています。各マイルストンで、メッセージは様々な状態で保存されます。

図1-1 統合フローの図

統合フローは、メッセージのランタイム・パスを表します。これは設計時のアーティファクトではありません。

AIAでは、次の統合スタイルが処理されます。

- Oracle Applicationsのテクノロジ・インフラストラクチャを使用したネイティブ・アプリケーション・インタフェースを介した統合。

- 統合フレームワークを備えた統合スタイル。

- Oracle SOA Suiteを使用した、アプリケーションWebサービスを介した直接統合。

- Oracle SOAコア拡張機能を使用した、パッケージ化された正規および標準化インタフェースを介した統合。

- バルク・データ処理に対する統合スタイル。

- リアルタイム・データの統合フロー。

- バッチ・データの統合フロー。

1.5 この開発者ガイドの使用方法

販売プロセスでは、AIA提供の値に関する詳細情報が提供されます。提示される値は、ソリューションが要求されているビジネス問題のコンテキストで認識されます。

ビジネス問題の詳細分析、および関連ビジネス要件のドキュメント化によって、機能設計ドキュメントが作成され、次のことが提供されます。

- ビジネス・ケースの詳細な説明

- 多数の異なるアクターによる想定アクションを含む例外ケースなど、様々な使用シナリオを詳細に説明する各種ユースケース

- すべての参加アプリケーションに関する詳細 - 商用、バージョン付き既製品および自社作成

- トリガー・ビジネス・イベントに関する詳細

- 機能フローに関する詳細

- 使用するビジネス・オブジェクトに関する詳細

- 様々なビジネス・オブジェクトに対して実行するアクション

- パフォーマンスおよびスケーラビリティ要件に関する詳細

この開発者ガイドでは、次のことを想定しています。

- 機能設計ドキュメントが使用可能であること。

- AIAソフトウェアにアクセスできること。

- すべてのAIA提供ドキュメントにアクセスできること。

- Oracle Fusion Middleware Oracle Application Integration Architecture Foundation Packコンセプトおよびテクノロジ・ガイド 11g リリース1 (11.1.1.9.0)を参照済であること。

この開発者ガイドの内容は次のとおりです。

- AIA統合フローの作成に必要なすべてのタスクの概要。

- 様々なAIAアーティファクトの開発方法に関する詳細。

- AIAアーティファクトと外部アーティファクト間の相互作用の説明。

- 様々な設計パターン、ベスト・プラクティス、およびランタイム・パフォーマンスのチューニングの説明。

「AIA統合フローの作成」から開始し、必要に応じてこの開発者ガイドの関連する章に進んでください。

2 AIA統合フローの作成

この章では、AIA統合フローの作成方法について説明します。

この章の内容は次のとおりです。

- 開発環境およびテスト環境の設定

- 様々な統合スタイルのAIAアーティファクト

- AIAアーティファクトの開発タスク

- Oracle AIA統合フローのテスト

2.1 開発環境およびテスト環境の設定

AIAの開発とテストでは、開発環境およびテスト環境の設定でSOA SuiteのダウンロードとAIA環境の設定を行います。

2.1.1 AIA開発でのQuick Startの入手

AIA開発を開始するには、まずSOA Suite Quick Startをインストールして、SOAサーバーに接続します。

1. SOA Suite 12.1.3 Quick Startをダウンロードしてインストールします。

2. AIA開発用に設定されたSOA Suiteサーバーへの接続を作成し、Oracle Fusion Middlewareの設定後にこれらの詳細を使用してテストします。

a. 接続名: <アプリケーションの接続名を指定>。

b. 接続タイプ: デフォルト値のWebLogic 12.1.3を使用します。

c. WebLogicサーバーのユーザー名とパスワードを指定します。
WebLogicホスト名: <サーバーのホスト名>。

d. ポート: <サーバーのポート番号>。

e. SSLポート: <サーバーのSSLポート>。

f. WLSドメイン: <SOAサーバーがインストールされているドメイン名を指定>。

2.1.2 AIAワークステーションの設定方法

AIAワークステーションは、AIA開発を実行するために設定された専用システムです。このシステムにSOAコア拡張機能をインストールし、SOAコア拡張機能からAIAプロジェクト・ライフサイクル・ワークベンチを設定します。

この項には次のトピックが含まれます:

- 前提条件

- AIAでのMDSの使用

- $SOA_HOME/AIAMetaDataのコンテンツ

- $SOA_HOME/AIAMetaDataのAIAコンポーネント・コンテンツの使用

- 既存ファイルの変更方法

- ファイルの作成方法

- $SOA_HOME/aia_instances/$INSTANCE_NAME/AIAMetaData/configのAIAConfigurationProperties.xmlの使用方法

- AIAConfigurationProperties.xmlへの新規プロパティの追加方法

- $SOA_HOME/aia_instances/$INSTANCE_NAME/AIAMetaData/configのAIAEHNotification.xmlの使用方法

- $SOA_HOME/AIAMetaData/dvmのドメイン値マップの使用方法

- $SOA_HOME/AIAMetaData/xrefの相互参照(Xref)の使用方法

- $SOA_HOME/AIAMetaData/faultPolicies/V1のフォルト・ポリシーの使用方法

- MDSの更新

2.1.2.1 前提条件

- 12.1.3 WebLogic ServerをOracle Application Development Frameworkとともにインストールします。

- Oracle Databaseをインストールします。

- SOA Suite Quick Startをインストールします。

- OTN(http://www.oracle.com/technetwork/middleware/fusion-middleware/overview/index.html)で詳述されている、サポートされているシステム構成に準拠していることを確認します。

ハードウェアは、サポートされているオペレーティング・システムで、少なくとも4つのCPUと32GBのRAMが搭載されている必要があります。

2.1.2.2 AIAでのMDSの使用

Oracle Metadata Services (MDS)リポジトリには、WLS上のSOA Suiteなど、デプロイ済J2EEアプリケーションのメタデータが格納されます。

SOA用に特別に作成されたパーティションSOA-MDSの下に、すべてのSOAコンポジット(AIAコンポジットを含む)もデプロイメント時に格納されます。

同じパーティションの下に、$SOA_HOME/AIAMetaDataのコンテンツがSOA-MDS→apps/AIAMetaDataにアップロードされます。

メタデータの各セットのコンテンツと詳細、およびそのAIAによる使用方法を次に示します。また、新規コンテンツの作成または既存コンテンツの変更のプロセスについても説明します。

詳細は、OTNネットワークでSOAコア・コンポジット・アプリケーションの開発を参照してください。

2.1.2.3 $SOA_HOME/AIAMetaDataのコンテンツ

注意:

新規の12c顧客は、ユーティリティ・オブジェクトを入手し、ライセンスの取得を選択した適切な事前作成済の統合を介してその他のオブジェクトを受け取ります。

AIAメタデータ($SOA_HOME/AIAMetaData)には次のコンテンツが含まれています。

AIAComponents - 様々なサービスによって参照される様々なスキーマおよびWSDLを提示します。構造は次のとおりです。

- ApplicationConnectorServiceLibrary: 様々なアプリケーション・ビジネス・コネクタ・サービス(ABCS)の抽象WSDL

- ApplicationObjectLibrary: アプリケーションによって公開されるサービスのWSDLおよびアプリケーション・ビジネス・オブジェクトのスキーマ

- B2BObjectLibrary: 企業間(B2B)スキーマ

- B2BServiceLibrary: 様々なB2Bコネクタ・サービス(B2BCS)およびB2Bインフラストラクチャ・サービスの抽象WSDL

- BusinessProcessServiceLibrary: エンタープライズ・ビジネス・フロー(EBF)の抽象WSDL

- EnterpriseBusinessServiceLibrary: エンタープライズ・ビジネス・サービス(EBS)の抽象WSDL

- EnterpriseObjectLibrary: Oracle AIA標準モデルのスキーマ

- ExtensionServiceLibrary: ミラー・サーブレットを指す具象WSDL

- InfrastructureServiceLibrary: インフラストラクチャ・サービスの抽象WSDL

- Transformations: 様々なサービス間で共有されるXSL

- UtilityArtifacts: ユーティリティ・スキーマおよびWSDL

config: AIAConfigurationProperties.xmlおよびAIAEHNotification.xml

dvm: ドメイン値マップ

faultPolicies: すべてのサービスに適用可能なデフォルト・ポリシー

xref: 相互参照用のメタデータ

2.1.2.4 $SOA_HOME/AIAMetaDataのAIAコンポーネント・コンテンツの使用

AIAコンポーネントは、実行時に様々なAIAアーティファクト間で共有されるスキーマ、WSDLおよびXSLで構成されます。これらの各ファイルの使用方法と目的は、このマニュアルのAIAアーティファクト固有の章で詳細に説明します。

AIAコンポーネントのフォルダ構造

様々なアプリケーション・コネクタ・サービスおよびアダプタ・サービスの抽象WSDLはすべて、ここに格納されます。従うフォルダ構造規則は、ApplicationConnectorServiceLibraryです。

AIAMetaData\AIAComponents\ApplicationConnectorServiceLibrary\<アプリケーション名>\<バージョン番号>\<サービス・タイプ>

- <バージョン番号>に使用できる値は、V1、V2などです。

- <サービス・タイプ>に使用できる値は、次のとおりです。

- RequesterABCS

- ProviderABCS

- AdapterServices

- <アプリケーション名>に使用できる値は、次のとおりです。

- PeopleSoft

- BRM

- UCM

- SAP

- PIM

- OracleRetail

- Logistics

- JDEE1

- CRMOD

- Agile

- Ebiz

- Siebel

注意:

ここで指定する<アプリケーション名>は、AIAプロジェクト・ライフサイクル・ワークベンチで、デプロイメントに対する部品構成表の定義で使用されます。これは、ワークベンチの<製品コード>値リストと一致する必要があります。

例:

AIAMetaData/AIAComponents/ApplicationConnectorServiceLibrary/Siebel/V1/RequestorABCS

AIAMetaData/AIAComponents/ApplicationConnectorServiceLibrary/Siebel/V1/ProviderABCS

ApplicationObjectLibrary

参加アプリケーションによって公開されるサービスのWSDLのすべて、および参照されるスキーマは、次の場所に格納されます。

$SOA_HOME/AIAMetaData/AIAComponents/ApplicationObjectLibrary

アプリケーションでは、AIAリクエスタ・サービスのWSDLが使用されます。参加アプリケーションでの変換が必要ないように、AIAリクエスタ・サービスのWSDLは、参加アプリケーションの外部向けビジネス・オブジェクト・スキーマを参照して開発されています。これらのスキーマも次の場所に格納されます。

$SOA_HOME/AIAMetaData/AIAComponents/ApplicationObjectLibrary

従うフォルダ構造規則は、次のとおりです。

ApplicationObjectLibrary/<アプリケーション名>/<バージョン番号>/schemas

ApplicationObjectLibrary/<アプリケーション名>/<バージョン番号>/wsdls

<アプリケーション名>および<バージョン番号>に使用できる値は、前述の項に記載されています。

注意:

ここで指定する<アプリケーション名>は、AIAプロジェクト・ライフサイクル・ワークベンチで、デプロイメントに対する部品構成表の定義で使用されます。

例:

AIAMetaData/AIAComponents/ApplicationObjectLibrary/Siebel/V1/schemas

AIAMetaData/AIAComponents/ApplicationObjectLibrary/Siebel/V1/wsdls

B2BServiceLibrary

B2Bコネクタ・サービス(B2BCS)の抽象WSDLはすべて、この場所に格納されます。

リクエスタB2BCSのWSDLは、$SOA_HOME/AIAMetaData/AIAComponents/B2BServiceLibrary/Connectors/wsdlsの下に格納されます。

従うフォルダ構造規則は、B2BServiceLibrary/Connectors/wsdls/<B2B標準>/RequesterB2BCS/<コネクタ・バージョン>/*.wsdlです。

プロバイダB2BCSのWSDLは、$SOA_HOME/AIAMetaData/AIAComponents/B2BServiceLibrary/Connectors/wsdlsの下に格納されます。

従うフォルダ構造規則は、B2BServiceLibrary/Connectors/wsdls/<B2B標準>/ProviderB2BCS/<コネクタ・バージョン>/*.wsdlです。

再使用可能なインフラストラクチャ・サービスのその他の抽象WSDLは、$SOA_HOME/AIAMetaData/AIAComponents/B2BServiceLibrary/Infrastructure/<サービス・バージョン>/の下に格納されます。

BusinessProcessServiceLibrary

コンポジット・ビジネス・プロセスおよびエンタープライズ・ビジネス・フローの抽象WSDLはすべて、次の場所に格納されます。

$SOA_HOME/AIAMetaData/AIAComponents/ BusinessProcessServiceLibrary

従うフォルダ構造規則は、次のとおりです。

BusinessProcessServiceLibrary/<サービス・タイプ>

<サービス・タイプ>に使用できる値は、CBPおよびEBFです。

例:

AIAMetaData/AIAComponents/BusinessProcessServiceLibrary/CBP

AIAMetaData/AIAComponents/BusinessProcessServiceLibrary/EBF

EnterpriseBusinessServiceLibrary

Oracle AIA標準モデルの一部

エンタープライズ・ビジネス・サービスの抽象WSDLはすべて、次の場所に格納されます。

$SOA_HOME/AIAMetaData/AIAComponents/EnterpriseBusinessServiceLibrary

EnterpriseObjectLibrary

Oracle AIA標準モデルの一部

エンタープライズ・オブジェクト・ライブラリのスキーマ・モジュールはすべて、次の場所に格納されます。

$SOA_HOME/AIAMetaData/AIAComponents/EnterpriseObjectLibrary

ExtensionServiceLibrary

ミラー・サーブレットを指す具象WSDLはすべて、次の場所に格納されます。

$SOA_HOME/AIAMetaData/AIAComponents/ExtensionServiceLibrary

従うフォルダ構造規則は、次のとおりです。

ExtensionServiceLibrary/<アプリケーション名>

<アプリケーション名>に指定できる値は、例の項に記載されています。

注意:

ここで指定する<アプリケーション名>は、AIAプロジェクト・ライフサイクル・ワークベンチで、デプロイメントに対する部品構成表の定義で使用されます。

例:

AIAMetaData/AIAComponents/ExtensionServiceLibrary/Siebel
InfrastructureServiceLibrary

インフラストラクチャ・サービスの抽象WSDLはすべて、次の場所に格納されます。

$SOA_HOME/AIAMetaData/AIAComponents/InfrastructureServiceLibrary

従うフォルダ構造規則は、次のとおりです。

InfrastructureServiceLibrary/<バージョン番号>

例:

AIAMetaData/AIAComponents/InfrastructureServiceLibrary/V1

Transformations

様々なAIAサービス間で共有されるXSLはすべて、次の場所に格納されます。

$SOA_HOME/AIAMetaData/AIAComponents/Transformations

従うフォルダ構造規則は、次のとおりです。

Transformations/<アプリケーション名>/<バージョン>

<アプリケーション名>および<バージョン番号>に使用できる値は、次の項に記載します。

注意:

ここで指定する<アプリケーション名>は、AIAプロジェクト・ライフサイクル・ワークベンチで、デプロイメントに対する部品構成表の定義で使用されます。

例:

AIAMetaData/AIAComponents/Transformations/Siebel/V1

UtilityArtifacts

ユーティリティ・スキーマおよびWSDLはすべて、次の場所に格納されます。

$SOA_HOME/AIAMetaData/AIAComponents/UtilityArtifacts

従うフォルダ構造規則は、次のとおりです。

UtilityArtifacts/schemas

UtilityArtifacts/wsdls

2.1.2.5 既存ファイルの変更方法

既存ファイルを変更する手順は、次のとおりです。

1. JDeveloperから、AIAWorkstation/$SOA_HOME/AIAMetaData/AIAComponents/<ファイルのパス>を参照して、関連ファイルを開きます。

2. 変更します。ガイドのAIAアーティファクト固有の章に示されている、アップグレードの安全拡張性ガイドラインを確認してください。

3. 保存します。

4. SOA-MDS→apps/AIAMetaData/AIAComponentsにアップロードします。「MDSの更新」を参照してください。

2.1.2.6 ファイルの作成方法

ファイルを作成する手順は、次のとおりです。

1. JDeveloperで、このマニュアルのAIAアーティファクト固有の章に示されている、設計および開発ガイドラインに従ってファイルを作成します。

2. ファイルをAIAWorkstation/$SOA_HOME/AIAMetaData/AIAComponents/<ファイルのパス>にコピーします。

注意:

ファイルをこのフォルダに配置します。

3. SOA-MDS→apps/AIAMetaData/AIAComponentsにアップロードします。「MDSの更新」を参照してください。

AIAコンポーネント・フォルダのファイルへのアクセス

次のプロトコルを使用して、設計時および実行時に、すべてのAIAサービス・アーティファクトからAIAコンテンツにアクセスします。

oramds:/apps/AIAMetaData/AIAComponents/<リソース・パス名>

例:

oramds:/apps/AIAMetaData/AIAComponents/ApplicationObjectLibrary/SampleSEBL/schemas/CmuAccsyncAccountIo.xsd

注意:

AIAコンポーネント・フォルダのすべてのファイルで、AIAコンポーネント・フォルダの他のファイルを参照するために、必要に応じて相対パスが使用されます。

エンタープライズ・ビジネス・サービス・ライブラリのWSDLでは、エンタープライズ・オブジェクト・ライブラリのスキーマを参照するために相対パスが使用されます。

2.1.2.7 $SOA_HOME/aia_instances/$INSTANCE_NAME/AIAMetaData/configのAIAConfigurationProperties.xmlの使用方法

AIAでは、システムのランタイム動作、インフラストラクチャ・コンポーネントおよびサービスに影響を与える外部構成プロパティが提供されます。これらのプロパティは、AIAConfigurationProperties.xmlのシステム、モジュールおよびサービスのレベルで、名前と値のペアとして提供されます。

AIAConfigurationProperties.xmlでは、2つの構成タイプがサポートされます。

- モジュール・レベルを含むシステム・レベル
システムレベルの構成の名前と値のペア、およびシステム・レベル内のモジュールレベルの構成の名前と値のペアが含まれます。

- サービス・レベル
サービス固有の構成の名前と値のペアが含まれます。

次のXPath関数は、AIAConfigurationProperties.xmlにある構成の名前と値のペアにアクセスするために提供されています。

- aiacfg:getSystemProperty (文字列のpropertyName, ブール値のneedAnException)では、propertyValueが文字列で返されます

- aiacfg:getSystemModuleProperty (文字列のmoduleName, 文字列のpropertyName, ブール値のneedAnException)では、propertyValueが文字列で返されます

- aiacfg:getServiceProperty (文字列のEBOName, 文字列のserviceName, 文字列のpropertyName, ブール値のneedAnException)では、propertyValueが文字列で返されます

getSystemModuleProperty()およびgetServiceProperty()関数では、最初に適切なモジュール・プロパティとサービス・プロパティが検索され、見つからない場合は、同じプロパティ名のシステム・プロパティが検索されます。

3つの関数すべてで、一致するプロパティが見つからない場合、結果はneedAnException引数の値に依存します。needAnExceptionがtrueの場合は、PropertyNotFound例外がスローされ、それ以外の場合は空の文字列が返されます。

2.1.2.8 AIAConfigurationProperties.xmlへの新規プロパティの追加方法

新規プロパティをAIAConfigurationProperties.xmlに追加する手順は、次のとおりです。

1. JDeveloperから、AIAWorkstation/$SOA_HOME/aia_instances/$INSTANCE_NAME/AIAMetaData/configを参照して、AIAConfigurationProperties.xmlファイルを開きます。

2. AIAアーティファクト開発で、必要に応じて変更します。

3. 保存します。

4. SOA-MDS→apps/AIAMetaData/configにアップロードします。「MDSの更新」を参照してください。

5. AIAホーム・ページから、「設定」エリアで「実行」をクリックします。「構成」タブを選択して、「構成」ページにアクセスします。「リロード」をクリックして、AIA構成キャッシュをリフレッシュします。

2.1.2.9 $SOA_HOME/aia_instances/$INSTANCE_NAME/AIAMetaData/configのAIAEHNotification.xmlの使用方法

このファイルは、エラー処理フレームワークの一部として送信される電子メール通知のテンプレートです。

AIAEHNotification.xmlを変更する手順は、次のとおりです。

1. JDeveloperから、AIAWorkstation/$SOA_HOME/aia_instances/$INSTANCE_NAME/AIAMetaData/configを参照して、AIAEHNotification.xmlファイルを開きます。

2. 必要に応じて変更します。

3. 保存します。

4. SOA-MDS→apps/AIAMetaData/configにアップロードします。「MDSの更新」を参照してください。

2.1.2.10 $SOA_HOME/AIAMetaData/dvmのドメイン値マップの使用方法

ドメイン値マップ・ユーティリティは、Oracle SOA Suiteの機能です。静的な値マップの作成がサポートされ、カスタムXPath関数が提供されます。

dvm:lookupValue("oramds:/apps/AIAMetaData/dvm/<DVM Map Name>",<Source Column>,<Source Column Value>,<Target Column>,"")

DVMの詳細は、「DVMおよび相互参照の使用」を参照してください。

DVMは、AIAの事前作成済の統合すべてで使用され、SOAコア拡張機能の一部として同梱されています。これらは$SOA_HOME/AIAMetaData/dvmに格納されます。

ドメイン値マップを変更する手順は、次のとおりです。

1. JDeveloperから、AIAWorkstation/$SOA_HOME/AIAMetaData/dvmを参照して、DVMファイルを開きます。

2. 必要に応じて変更します。

3. 保存します。

4. SOA-MDS→apps/AIAMetaData/dvmにアップロードします。「MDSの更新」を参照してください。

2.1.2.11 $SOA_HOME/AIAMetaData/xrefの相互参照(Xref)の使用方法

相互参照ユーティリティは、Oracle SOA Suiteの機能です。動的な値の作成がサポートされます。

相互参照の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の相互参照の操作に関する項を参照してください。

すべてのAIAプロセス統合パックによって使用される相互参照のメタ情報は、SOAコア拡張機能の一部として同梱されており、$SOA_HOME/AIAMetaData/xrefに格納されます。

相互参照メタデータを変更する手順は、次のとおりです。

1. JDeveloperから、AIAWorkstation/$SOA_HOME/AIAMetaData/xrefを参照して、相互参照ファイルを開きます。

2. 必要に応じて変更します。

3. 保存します。

4. SOA-MDS→apps/AIAMetaData/xrefにアップロードします。「MDSの更新」を参照してください。

2.1.2.12 $SOA_HOME/AIAMetaData/faultPolicies/V1のフォルト・ポリシーの使用方法

デフォルトのフォルト・ポリシー・ファイルであるfault-bindings.xmlは、SOAコア拡張機能の一部として同梱されており、$SOA_HOME/AIAMetaData/faultPolicies/V1に格納されます。

fault-bindings.xmlを変更する手順は、次のとおりです。

1. JDeveloperから、AIAWorkstation/$SOA_HOME/AIAMetaData/faultPolicies/V1を参照して、fault-bindings.xmlファイルを開きます。

2. 必要に応じて変更します。

3. 保存します。

4. SOA-MDS→apps/AIAMetaData/faultPolicies/V1にアップロードします。「MDSの更新」を参照してください。

2.1.2.13 MDSの更新

注意:

この手順は、ファイルがMDSに追加されるたびに繰り返します。

SOA-MDS→apps/AIAMetaDataを更新する手順は、次のとおりです。

1. $SOA_HOME/aia_instances/$INSTANCE_NAME/binにあるフォルダを参照します。

2. 次のコマンドを実行して、aiaenv.shファイルをソースとして指定します。

source aiaenv.sh

3. $SOA_HOME/aia_instances/$INSTANCE_NAME/configにあるフォルダを参照して、デプロイメント計画ファイルであるUpdateMetaDataDP.xmlを開きます。

4. MDSに追加する各リソース・グループに対してincludeタグを挿入して、UpdateMetaDataDP.xmlファイルを更新します。

a. AIAMetaDataの下にあるすべてのファイルをアップロードするには、次を追加します。

<include name ="**"/>

b. AIAComponents/ApplicationObjectLibrary/SEBL/schemasフォルダにコピーされたファイルをアップロードするには、次を追加します。

<include name ="AIAComponents/ApplicationObjectLibrary/SEBL/schemas/**"/>

注意:

includeタグでは、フォルダ・パスはAIAMetaDataフォルダと相対的である必要があります。

5. SOA_HOME/Infrastructure/Install/configを参照します。コマンドを入力して、UpdateMetaData.xmlスクリプトを実行します。

ant -f UpdateMetaData.xml

注意:

メタデータは、SOAコア拡張機能をアンインストールすると削除されます。SOAコア拡張機能のアンインストール後にMDSを消去する方法の具体的な指示は、Oracle Application Integration Architecture Foundation Packインストレーションおよびアップグレード・ガイドのMDSの消去に関する項を参照してください。

2.2 様々な統合スタイルのAIAアーティファクト

AIAアーキテクチャでは、統合フローでのメッセージのフライトを可能にするために、様々な統合スタイルおよびAIAパターンが推奨されています。

AIA実装チームは、次の点を評価して、様々なAIAアーティファクトを作成する際に従う統合スタイルと手法を選択する必要があります。

ビジネス・シナリオ - 機能設計ドキュメント(FDD)によってビジネス・シナリオが記述され、次が提供されます。

- ビジネス・ケースの詳細な説明。

- 多数の異なるアクターによる想定アクションを含む例外ケースなど、様々な使用シナリオを詳細に説明する各種ユースケース。

- すべての参加アプリケーションに関する詳細 - 商用、バージョン付き既製品および自社作成。

- トリガー・ビジネス・イベントに関する詳細。

- 機能フローに関する詳細。

- パフォーマンスおよびスケーラビリティ要件に関する詳細。

- 使用するビジネス・オブジェクトに関する詳細。

- 様々なビジネス・オブジェクトに対して実行するアクション。

- 利用するOracleのツールおよびテクノロジ。

アプリケーションまたは機能間のコラボレーションに必要なAIAアーティファクトは、統合フローに採用した統合スタイルに依存します。これらのアーティファクトには、ABCS、EBS、EBF、CBPおよび様々なアダプタ・サービスが含まれます。

AIAプロジェクト・ライフサイクル・ワークベンチは、設計、開発、テスト、パッケージ化および配信するすべてのアーティファクトの定義を含む、AIAプロジェクトの定義に使用されます。

2.2.1 Oracle Applicationsのテクノロジ・インフラストラクチャを使用したネイティブ・アプリケーション・インタフェースを介した統合

このスタイルでは、メッセージは、リクエスタ・アプリケーションから提供側アプリケーションに送信されます。接続性のモードは、SOAP/HTTP、キュー、トピックまたはネイティブ・アダプタです。

この統合にミドルウェアは含まれません。

リクエスタ・アプリケーションは、プロバイダ・アプリケーションとの接続を確立する必要があります。リクエスタ・アプリケーションは、プロバイダのAPIで指定された書式でリクエストを送信し、プロバイダが送信するレスポンスを解釈する必要があります。リクエスタ・アプリケーションとプロバイダ・アプリケーションで、リクエストの認証および認可が実行されます。

統合フローは、直接相互作用する個々のアプリケーション機能で構成されます。この相互作用を可能にするために必要なすべての機能が、個々のアプリケーションで使用可能であるかまたは使用可能にする必要があります。

図2-1は、リクエスタ・アプリケーションがプロバイダ・アプリケーションと直接相互作用する方法を示しています。

図2-1 プロバイダ・アプリケーションと直接相互作用するリクエスタ・アプリケーションの例

さらに複雑な状況では、統合フローが複数アプリケーションとの相互作用を含む複数のステップで構成されている場合は、1つ以上のアプリケーションでワークフローに似た機能が利用されます。

このケースでは、AIAアーティファクトは作成されません。アプリケーション間の直接接続を確立します。

接続の様々なモードの詳細は、「リソース接続の確立」を参照してください。

2.2.2 統合フレームワークを備えた統合スタイルの理解

統合フレームワークを備えたすべての統合スタイルで、ミドルウェア・テクノロジが利用されます。アプリケーションによってメッセージがミドルウェアにプッシュされ、ミドルウェアによってそのメッセージがターゲット・アプリケーションにプッシュされます。

これらの統合スタイルに統合フレームワークがあります。

- プロバイダ・サービスを利用する統合フロー

- 標準モデルベースの仮想化を含むプロバイダ・サービスを利用する統合フロー

統合フレームワークを備えた任意の統合スタイルで統合フローを実装するために必要なAIAサービス・アーティファクトは、次に依存します。

- データ交換の複雑さ

- 処理ロジックなし

- 処理ロジックあり

- メッセージ交換パターン

- 同期リクエスト/レスポンス

- 非同期の一方向(ファイア・アンド・フォーゲット) - 保証付き配信の想定の必要性あり

- 非同期リクエスト/遅延レスポンス - 保証付き配信およびレスポンスの相関の想定の必要性あり

これらのAIAサービス・アーティファクトは、AIAアーキテクチャで定義されます。

- CBP

- EBS

- EBF

- ABCS

- アダプタ・サービス

- JMSプロデューサとJMSコンシューマ

- JCAアダプタ・サービス

様々なメッセージ交換パターンの詳細は、「エンタープライズ・ビジネス・サービスの設計と開発」および「AIA設計パターンの使用」を参照してください。

様々なAIAサービス・アーティファクトとこれらの実装に使用されるOracle SOA Suiteコンポーネントの詳細は、Oracle Application Integration Architecture Foundation Packコンセプトおよびテクノロジ・ガイドを参照してください。

注意:

次の各項では、統合フレームワークを備えた統合スタイルごとに、状況の組合せに対して開発するAIAアーティファクトが推奨されます。

2.2.2.1 リクエスタ・アプリケーション・サービスを使用した統合フロー

リクエスタ・アプリケーションによって、ミドルウェアで単一のAIAサービスが呼び出されます。リクエスタ・アプリケーションによって提示されるリクエストは、プロバイダ・アプリケーションで適切なAPIを呼び出すことによってAIAサービスで履行されます。AIAサービスでは、リクエスタ・アプリケーションの書式でメッセージを受け入れることができます。AIAサービスでは、プロバイダのAPIで指定された書式で、リクエストがプロバイダ・アプリケーションに提示されます。AIAサービスでは、必要に応じて、プロバイダ・アプリケーションの書式でレスポンスが受け入れられます。AIAサービスで、リクエストの認証および認可が実行されます。

統合フローは、すべての参加アプリケーションとの相互作用をすべて管理する、ミドルウェアにデプロイされたこの単一のAIAサービス・アーティファクトで構成されます。

図2-2は、ミドルウェアにデプロイされたサービスによって、リクエスタ・アプリケーションとプロバイダ・アプリケーション間の統合を可能にする方法を示しています。

図2-2 ネイティブ・アプリケーション・サービスを使用した統合フローの例

統合フローが複数アプリケーションとの相互作用を含む複数のステップで構成されているさらに複雑な状況の場合、AIAサービスでは、ワークフローに似た機能が実装され、すべての参加アプリケーションとの相互作用がすべて管理されます。

開発するAIAサービス・アーティファクトは、データ交換の複雑さおよび様々なメッセージ交換パターンに依存します。

表2-1に、状況の組合せに対して適切なAIAアーティファクトを示します。

表2-1 リクエスタ・アプリケーション・サービスを使用した統合フローに対するAIAアーティファクト

メッセージ・パターン

処理ロジックなし

処理ロジックあり

同期リクエスト/レスポンス

EBS

EBF

非同期の一方向

EBS

EBF

非同期リクエスト/遅延レスポンス

EBS - リクエスト

EBS - レスポンス

EBF

2.2.2.2 アプリケーションWebサービスを介した直接統合

1つ以上のAPIを利用するプロバイダ・アプリケーションの粒度が粗い機能を公開する、プロバイダ・アプリケーション固有のAIAサービスは、適切なプロバイダ・アプリケーション固有のインタフェースを使用して作成されます。複数のビジネス・イニシエータがこのAIAサービスを呼び出すことができます。ビジネス・イニシエータがプロバイダ・アプリケーション固有のAIAサービスによって理解される書式でリクエストを提示できない場合は、ビジネス・イニシエータのリクエストをプロバイダ・アプリケーションの書式に変換するために、リクエスタ・アプリケーション固有のAIAサービスが使用されます。リクエスタ・アプリケーション固有のAIAサービスで、リクエストの認証および認可が実行されます。プロバイダ・アプリケーション固有のAIAサービスでは、リクエストの認証および認可情報がプロバイダ・アプリケーションに伝播されます。

統合フローは、すべてのプロバイダ・アプリケーション固有のAIAサービスとの相互作用をすべて管理する、ミドルウェアにデプロイされたリクエスタ・アプリケーション固有のAIAサービスで構成されます。

図2-3は、ミドルウェアにデプロイされたサービスによって、リクエスタ・アプリケーションとプロバイダ・アプリケーション間の統合を可能にする方法を示しています。

図2-3 プロバイダ・サービスを利用する統合フローの例

統合フローに複数アプリケーションとの相互作用が含まれているさらに複雑な状況の場合、リクエスタ・アプリケーション固有のAIAサービスによって、ワークフローに似た機能が実装され、すべてのプロバイダ・アプリケーション固有のAIAサービスとの相互作用がすべて管理されます。

開発するAIAサービス・アーティファクトは、データ交換の複雑さおよび様々なメッセージ交換パターンに依存します。

表2-2に、状況の組合せに対して適切なAIAアーティファクトを示します。

表2-2 プロバイダ・サービスを利用するためのAIAアーティファクト

メッセージ・パターン

処理ロジックなし

処理ロジックあり

同期リクエスト/レスポンス

リクエスタABCS

プロバイダABCS

リクエスタABCS

プロバイダABCS

非同期の一方向

リクエスタABCS

プロバイダABCS

リクエスタABCS

プロバイダABCS

非同期リクエスト/遅延レスポンス

リクエスタABCS

プロバイダABCS

リクエスタABCS

プロバイダABCS

2.2.2.3 パッケージ化された正規および標準化インタフェースを介した統合

標準(アプリケーション非依存)モデルを介した疎結合は、真のSOAを表すものです。疎結合された統合の参加アプリケーションは、仮想レイヤーを介して通信します。データ・モデル間の直接マッピングのかわりに、標準データ・モデルにマップするために変換が使用されます。この結果、再利用性が向上しますが、変換によって、メッセージ・サイズが増加するのみでなく、より多くのコンピューティング・リソースも消費されます。機能統合に関しては、獲得する再利用性は多少の諸経費をかける価値があるため、この統合パターンが最善です。

この場合、エンタープライズ・ビジネス・オブジェクト(EBO)とエンタープライズ・ビジネス・メッセージ(EBM)に基づいたEBSが、メディエータ・サービスとして作成されます。

1つ以上のAPIを利用するプロバイダ・アプリケーションの粒度が粗い機能を公開するプロバイダ・サービスは、EBS操作インタフェースと同じEBMインタフェースを使用して作成されます。

ビジネス・イニシエータがEBS操作インタフェースによって理解される書式でリクエストを提示できない場合は、ビジネス・イニシエータのリクエストをプロバイダ・サービスの書式に変換するために、リクエスタ・サービスが使用されます。

図2-4に、ソース・アプリケーションによって送信されたリクエストが、EBSおよび一連の仲介サービスを使用してターゲット・アプリケーションでどのように処理されるかを示します。リクエストおよびプロバイダのトランスポート・サービスはオプションであり、非SOAPベースのトランスポートの場合にのみ必要です。

図2-4 標準モデルベースの仮想化を示す例

統合フローに複数アプリケーションとの相互作用が含まれているさらに複雑な状況の場合、リクエスタ・アプリケーション固有のAIAサービスによって、そのリクエストはメディエータAIAサービスに提示されます。メディエータAIAサービスによってAIAサービスがトリガーされ、AIAサービスでは、ワークフローに似た機能が実装され、メディエータAIAサービスを介して、すべてのプロバイダ・アプリケーション固有のAIAサービスとの相互作用がすべて管理されます。この場合、選択したメディエータAIAサービス・インタフェースは、共通インタフェースとして受け入れられると想定されています。このように、すべてのリクエスタ・アプリケーション固有のAIAサービスによってこのメディエータAIAサービスが呼び出され、すべてのプロバイダ・アプリケーション固有のAIAサービスによってこの共通インタフェースが実装されます。開発するAIAサービス・アーティファクトは、データ交換の複雑さおよび様々なメッセージ交換パターンに依存します。

表2-3に、状況の組合せに対して適切なAIAアーティファクトを示します。

表2-3 複数のアプリケーション相互作用を含む統合フローに対するAIAアーティファクト

メッセージ・パターン

処理ロジックなし

処理ロジックあり

同期リクエスト/レスポンス

リクエスタABCS

EBS

プロバイダABCS

リクエスタABCS

EBS

プロバイダABCS

非同期の一方向

リクエスタABCS

EBS

プロバイダABCS

CBP

リクエスタABCS

EBS

EBF

プロバイダABCS

非同期リクエスト/遅延レスポンス

リクエスタABCS

EBS

プロバイダABCS

CBP

リクエスタABCS

EBS

EBF

プロバイダABCS

2.2.3 バルク・データ処理

バルク・データ処理には、離散レコードまたは非常に大きいデータを含むレコードの大規模バッチが含まれます。手法は、パフォーマンスの高いデータ移動に特殊化したポイントツーポイント統合ですが、再利用性とのトレードオフがあります。

バルク・データ処理は、複数アプリケーション間でレプリケートされる永続データを対象とします。統合は、4つのスタイルに分類されます。

- 初期データ・ロード

- Xref表ありの大規模トランザクション

- 断続的な大規模トランザクション

- Xref表なしの大規模トランザクション

AIAを使用したバルク・データ処理の使用方法の詳細は、「バルク処理に対するOracle Data Integratorの使用」を参照してください。

2.2.4 統合スタイルの選択マトリックス

AIA実装では、それぞれ異なる統合スタイルに準拠する様々な統合フローが共存します。統合フローは、必要なビジネス機能を配信するためにデプロイされたAIAサービスによるメッセージの処理を表します。

統合スタイルの選択は、AIAサービスの設計に影響を与えます。反対に、AIAサービスの設計に関する決定によって特定の統合スタイルが選択されます。

AIAサービス設計の様々な側面を次に示します。

- サービスの粒度
サービスで実装する機能を、ビジネス・アクティビティまたはタスクに必要なビジネス・ロジック(ビジネス・プロセス分析の結果)、あるいはプロバイダ・アプリケーションによって公開される機能に基づいて決定します。

サービスの粒度は、ビジネス・ロジックがビジネス・アクティビティまたはタスクの要件(AIA参照プロセス・モデルのビジネス・プロセス分析の結果)に準拠している場合は、粒度が粗くなります。この場合、サービスは、プロバイダ・アプリケーションの複数の低APIを呼び出すことによって実装されます。

サービスの粒度は、ビジネス・ロジックがプロバイダ・アプリケーションによって公開される低レベル機能に準拠する場合は、細かくなります。

- サービスの再利用性
サービスの再利用は、その設計がモジュール型で、様々なビジネス・ユースケースの要件に対して作成されている場合は、異なる統合フローに対して高くなります。ビジネス・アクティビティまたはタスクの要件(AIA参照プロセス・モデルのビジネス・プロセス分析の結果)に準拠すると、モジュール型設計になります。

サービスが特定のビジネス・ユースケースの要件を満たすように作成された場合、ロジックは一体型となり、再利用は低くなります。

- サービスの仮想化
この側面では、関心の分離、およびリクエスタ・アプリケーションとプロバイダ・アプリケーションの変更からの独立が提供されます。選択肢は、「はい」または「いいえ」です。

- サービスの相互運用性
様々なサービス実装を相互運用する機能は、WS-I標準、一般的なメッセージ・メタ・モデル、および堅牢なバージョニング戦略に準拠しているかどうかに依存します。AIAのEBSのWSDLおよびAIAのEBOとEBMでは、この機能が配信時に提供されます。その他については、相互運用性を保証するには、特別な作業が必要です。

表2-4に、様々な統合スタイルに対する粒度、再利用性、仮想化および相互運用性を要約します。

表2-4 AIAサービス設計の要約

統合スタイル

粒度

再利用性

仮想化

相互運用性

ネイティブ・アプリケーションAPIを使用した統合フロー

ミドルウェア上にAIAサービスなし、アプリケーション間の直接の相互作用

ミドルウェア上にAIAサービスなし、アプリケーション間の直接の相互作用

ミドルウェア上にAIAサービスなし、アプリケーション間の直接の相互作用

ミドルウェア上にAIAサービスなし、アプリケーション間の直接の相互作用

リクエスタ・アプリケーション・サービスを使用した統合フロー

粒度が粗い(高パフォーマンスのオーバーヘッドを伴う)

低

いいえ

特別な作業

プロバイダ・サービスを利用する統合フロー

細かい

高

いいえ

特別な作業

標準モデルベースの仮想化を含むプロバイダ・サービスを利用する統合フロー

粒度が粗い

高

はい

配信時

2.3 AIAアーティファクトの開発タスク

この項では、AIAアーティファクトの開発タスク、および次のことを実行する方法について説明します。

- EBOの識別

- 統合フローの設計

- EBSの識別と作成

- ABCSの作成

- 参加アプリケーションの有効化

- EBFの識別と作成

2.3.1 EBOの識別

FDDでは、次のことを検討します。

- 使用する概念的な標準モデルまたはEBO、およびこのエンティティで実行する必要があるアクション。

- SOAコア拡張機能からのEBOの識別またはEBOの作成。EBOには、この統合で必要なすべての要件を組み込む必要があります。

- SOAコア拡張機能からのEBMの識別または必要に応じたEBMの作成。

詳細は、My Oracle Supportの記事ID 983958.1の『Enterprise Object Library Extensibility Guide』を参照してください。

2.3.2 Oracle AIA統合フローの設計

統合フローの設計は、技術設計ドキュメント(TDD)で詳細に説明しています。TDDの完了の基準は、プロジェクトとそれに付随する成果物に依存します。

TDDでは、フロー・ロジック、統合アーティファクト、オブジェクト/要素マッピング、DVMのタイプと値、エラー処理およびインストールの特性に関する完全な詳細が計画されます。また、開発者がランタイム操作の検証に使用するユニット・テスト計画のアウトラインも含まれます。

統合フローは、ランタイム実行可能アーティファクトではないため、メッセージ交換パターンを統合フローに結び付けることはできません。前述のAIAサービス・アーティファクトの設計には、ビジネス・シナリオの慎重な分析を含める必要があり、これによって、AIAサービス・アーティファクトごとにメッセージ交換パターンを決定します。

メッセージ交換パターンの決定の詳細は、「新規プロセスEBSのMEPの設定」、「MEPの識別」および「EBFのメッセージ・パターンを識別する方法」を参照してください。

Oracle AIAサービス・アーティファクトが様々なメッセージ交換パターンに関与するために必要なタスクは、これらのアーティファクトの開発を詳述している章で説明します。

統合フローを設計する手順は、次のとおりです。

1. 参加アプリケーション・ビジネス・メッセージ(ABM)を分析して、それらをEBMにマップします。

詳細は、Oracle Application Integration Architecture Foundation Packコンセプトおよびテクノロジ・ガイドのEBOおよびEBMの理解に関する項を参照してください。

2. EBSを識別します。

「エンタープライズ・ビジネス・サービスの設計と開発」を参照してください。

3. EBFを識別します。

「エンタープライズ・ビジネス・フローの設計と作成」を参照してください。

4. ABCSを識別します。

「アプリケーション・ビジネス・コネクタ・サービスの設計」を参照してください。

5. 参加アプリケーションの接続方法を識別して決定します。

「エンタープライズ・ビジネス・サービスの設計と開発」を参照してください。

詳細は、Oracle Application Integration Architecture Foundation Packコンセプトおよびテクノロジ・ガイドの相互作用パターンの理解に関する項を参照してください。

6. セキュリティ・モデルを識別して決定します。

「セキュリティに関する作業」を参照してください。

詳細は、Oracle Application Integration Architecture Foundation Packコンセプトおよびテクノロジ・ガイドのセキュリティの理解に関する項を参照してください。

7. パフォーマンスおよびスケーラビリティのニーズを識別して決定します。

8. デプロイメント方法を識別して決定します。

2.3.2.1 Oracle AIA統合の理解

Oracle AIA統合シナリオは、AIAサービス・アーティファクトの論理コレクションであり、次が含まれます。

- EBS

- EBF

- ABCS

AIAサービス・アーティファクトは、複数のAIA統合フローに組み込むことができるため、Oracle Enterprise Repositoryを調べて、再使用可能なサービス・アーティファクトを識別します。AIAサービス・アーティファクトは、再利用性を考慮して作成されます。

アーティファクトごとに、これらの再利用性ガイドラインに従います。

- EBSに関する再利用性ガイドライン

- EBFに関する再利用性ガイドライン

- ABCSに関する再利用性ガイドライン

AIA統合フローを開発する手順は、次のとおりです。

1. 必要に応じて、EBSを識別して作成します。
「エンタープライズ・ビジネス・サービスの設計と開発」を参照してください。

2. 参加アプリケーションを有効化します。
「参加アプリケーションの有効化と登録」を参照してください。

3. ABCSを作成します。
「ABCSの作成」を参照してください。

4. EBFを作成します。
「エンタープライズ・ビジネス・フローの設計と作成」を参照してください。

標準命名規則の詳細は、「AIA開発でのOracle AIAネーミング標準」を参照してください。

2.3.3 EBSの識別と作成

各EBOに、「作成、読取り、更新、削除」(CRUD)操作とその他のサポート操作を公開するためのEBSがあります。関連EBMで提示される各アクションは、EBSのサービス操作として実装されます。EBSの作成およびすべてのサービス操作の実装は、エンドツーエンドの統合フローの実装において重要なタスクです。

注意:

エンティティEBSの操作は、関連ビジネス・オブジェクトのみを実行対象とし、その他のビジネス・オブジェクトは実行対象としない必要があります。複数のビジネス・オブジェクトを実行対象とする操作は、プロセスEBSに常駐する必要があります。

EBSが存在する場合は、この統合フローに関するEBOを実行対象とするために必要なすべてのアクションがサービス操作として実装されたかどうかを確認します。これらが実装されていなかった場合は、既存のEBSを変更してサービス操作を追加します。

この手順では、エンティティ・ベースのEBSを作成する高度なタスクを示します。「エンタープライズ・ビジネス・サービスの設計と開発」に、これらの各タスクを完了する方法の詳細が記載されています。

エンティティベースのEBSを作成する手順は、次のとおりです。

1. EBSに対するコントラクトを定義および作成します。

2. EBSを作成します。

3. 各操作に対する関連プロバイダ・サービスを登録します。

4. 新規または既存の操作に対してルーティング・ルールを追加します。

5. CAVSに対する各サービス操作を有効化します。

詳細は、「エンタープライズ・ビジネス・サービスの設計と開発」を参照してください

2.3.4 ABCSの作成

詳細は、「ABCSの作成」および「ABCS開発の完了」を参照してください。

2.3.5 参加アプリケーションの有効化と登録

この項では、SOAコア拡張機能エコシステムで参加アプリケーションを有効化するために必要な手順について説明します。また、AIAレジストリに対して参加アプリケーションを管理するために使用できるオプションについても説明します。

2.3.5.1 参加アプリケーションの有効化

参加アプリケーションを有効化する手順は、次のとおりです。

1. 呼び出す必要があるサービスAPIを識別します。

2. WSDLを参加アプリケーションに提供します。

3. 必要に応じて、アダプタ・サービスを作成します。

2.3.5.2 Oracle AIAシステム・レジストリの管理

この項では、Oracle Application Integration Architecture (AIA)システム・レジストリを管理する方法について説明します。

2.3.5.2.1 Oracle AIAシステム・レジストリの理解

システム・レジストリの目的は、Oracle AIAエコシステムに参加するリクエスタ・システムとプロバイダ・システムに関する情報を識別し、取得することです。システム・レジストリでは、比較的静的なシステム属性が取得されます。

Oracle AIAエコシステムのシステム・レジストリは、最初はOracle AIAインストール・プロセス時にロードされますが、ユーザー・インタフェースを使用すると、レジストリの情報を管理できます。

システム・レジストリを保存する利点は、特定のシステム属性をエンタープライズ・ビジネス・メッセージのヘッダーに容易にデフォルト設定できることです。リクエスタ・システムとターゲット・システムには複数のインスタンスがあり、それぞれに異なる属性が設定されている場合があります。システム・レジストリを使用すると、各インスタンスに対する属性を取得できるため、後続の処理でそれらを識別できます。

SOAコア拡張機能では、システム・レジストリのデータを管理する方法が2通りあります。

- 「システム」ページ

- SystemRegistration.xml構成ファイル

2.3.5.2.2 「システム」ページを使用したシステム・レジストリの管理方法

目標:

「システム」ページを使用して、Oracle AIAシステム・レジストリに格納されている参加アプリケーションを管理します。

アクター:

システム管理者(AIAApplicationUserロール)

「システム」ページを使用してOracle AIAシステム・レジストリを管理する手順は、次のとおりです。

1. AIAホーム・ページにアクセスします。「設定」エリアで「実行」をクリックします。

2. 「システム」タブを選択します。

3. 検索基準を入力し、「検索」をクリックして、特定の参加アプリケーション・システムの検索を実行します。

4. 表2-5にリストされているページ要素を使用して、参加アプリケーションのシステム・レジストリのエントリを定義します。

表2-5 「システム」ページの要素

ページの要素

説明

削除

システム行を選択し、「削除」をクリックして削除を実行します。

作成

クリックして、参加アプリケーションをシステム・レジストリに追加するために使用できるシステム行を追加します。

保存

クリックして、ページ上のすべてのエントリを保存します。

内部ID

実装者が割り当てたシステム・インスタンス名(例: ORCL 01)。この値は、システム・インスタンスを識別するために、変換およびドメイン値マップの列名で使用されます。たとえば、値を変換で使用すると、リクエスタ・システムまたはプロバイダ・システムを識別できます。

システム・コード

これは必須値です。この値は、エンタープライズ・ビジネス・メッセージ(EBM)のヘッダーに入力されます。

システムの説明

「システム・コード」フィールドで識別されるリクエスタ・システムまたはプロバイダ・システムのインスタンスの詳細な説明。この値は、EBMのヘッダーに入力されます。

IPアドレス

参加アプリケーションのIPアドレスであり、これを使用して、参加アプリケーションのエンドポイントにアクセスできます。この値は、EBMのヘッダーに入力されます。

URL

これは、URL形式で指定されたホスト名とポートの組合せであり、これを使用して、参加アプリケーションにアクセスできます。通常は、http://hostname:port/の形式です。この値は、EBMのヘッダーに入力されます。このURLは、プロセス統合で参加アプリケーションのWebサービスにアクセスするためには使用されませんが、値は情報目的で保存されます。プロセス統合の開発者は、参加アプリケーションのエントリ・ポイントとして使用するURLを決定します。

システム・タイプ

システム・タイプを指定します。たとえば、Oracle EBIZです。これは必須値です。

アプリケーション・タイプ

指定したシステム内で実行中のアプリケーション。たとえば、システム・タイプOracle EBIZでは、アプリケーション・タイプの値にFMSが設定される場合があります。この値は、EBMのヘッダーに入力されます。

バージョン

システムで実行中のアプリケーションのバージョンを指定します。この値は、EBMのヘッダーに入力されます。

連絡先名

システムを担当する連絡先の名前を指定します。この値は、EBMのヘッダーに入力されます。

連絡先電話番号

システムを担当する連絡先の電話番号を指定します。この値は、EBMのヘッダーに入力されます。

連絡先電子メール

システムを担当する連絡先の電子メール・アドレスを指定します。この値は、EBMのヘッダーに入力されます。

2.3.5.2.3 SystemRegistration.xml構成ファイルを使用したシステム・レジストリの管理方法

目標:

「プロジェクト・ライフサイクル・ワークベンチ」プロセス統合プロジェクトに対するsystemRegistration.xml構成ファイルを作成します。プロジェクトごとに1つのsystemRegistration.xmlファイルを作成します。

「システム」ページの詳細は、「「システム」ページを使用したシステム・レジストリの管理方法」を参照してください。

ロール:

統合開発者

SystemRegistration.xml構成ファイルを使用してOracle AIAシステム・レジストリを管理する手順は、次のとおりです。

1. プロセス統合プロジェクトに対するsystemRegistration.xmlファイルを作成します。

2. 参加アプリケーションの値をシステム・レジストリに追加するには、例2-4に示したサンプルのXML構造で提供されている<create>要素を使用します。

<create>要素で作成するトークンは、AIAInstallProperties.xmlファイルの構造に基づいている必要があります。

たとえば、次のトークン${participatingapplications.SamplePortal.server.soaserverhostname}は、例2-5に示したAIAInstallProperties.xmlファイルの構造から導出されます。

太字のトークンの実際の値は、プロセス統合のインストール時に、デプロイメント計画を使用して$AIA_INSTANCE/config/AIAInstallProperties.xmlから導出されます。

3. AIAアプリケーション・レジストリから参加アプリケーションの値を削除するには、例2-6に示したサンプルのXML構造で提供されている<delete>要素を使用し、太字のシステム・コード値を参加アプリケーションのシステム・コードに置き換えます。

4. systemRegistration.xmlファイルを$SOA_HOME/pips/<projectCode>/DatabaseObjects/に保存します。

開発手法でプロジェクト・ライフサイクル・ワークベンチを使用している場合、<projectCode>フォルダ名は、プロジェクト・ライフサイクル・ワークベンチでプロジェクトに割り当てられたプロジェクト・コード値です。

プロジェクト・ライフサイクル・ワークベンチを使用していない場合は、独自のプロジェクト・コード値をフォルダ名に割り当てます。

例2-1 AIAデプロイメント・ドライバによって抽出されるSQLコンテンツ

MERGE INTO AIA_SYSTEMS sysreg
USING dual
on (dual.dummy is not null and sysreg.SYSTEM_CODE='SampleSEBL' )
WHEN NOT MATCHED THEN INSERT
(SYSTEM_ID,SYSTEM_INTERNAL_ID,SYSTEM_CODE,SYSTEM_DESC,SYSTEM_IP_ADDR,SYSTEM_
URL,SYSTEM_TYPE,APPLICATION_TYPE,APPLICATION_VERSION,CONTACT_NAME,CONTACT_
PHONE,CONTACT_EMAIL)
VALUES (AIA_SYSTEMS_S.nextval,'Siebel','SampleSEBL','Sample Siebel Instance
01','10.0.0.1','http://siebel.xy.example.com:7001/ecommunications_enu',
SIEBEL','CRM','1.0, 'Siebel contact','1234567891','Siebelcontact@Siebel.com')
/

例2-2 AIAデプロイメント・ドライバによって抽出されたサンプルのSQLコンテンツ

<?xml version="1.0" encoding="UTF-8"?>
<properties>
<participatingapplications>
<siebel>
<http>
<host>siebel.xy.example.com</host>
<port>7001</port>
</http>
<internal>
<id>Siebel</id>
</internal>
<version>1.0</version>
<siebel>
...
</participatingapplications>
</properties>

例2-3 AIAデプロイメント・ドライバによって抽出されたサンプルのSQLコンテンツ

AIAデプロイメント・ドライバは、デプロイメント計画を読み取り、systemRegistration.xmlのトークンをAIAInstallProperties.xmlの実際の値に置き換え、システム登録のSQL文を実行してシステム・レジストリに値を入力します。

例2-1に、AIAデプロイメント・ドライバによって抽出されるSQLコンテンツを示します。

複数の「プロジェクト・ライフサイクル・ワークベンチ」プロセス統合プロジェクトを使用している場合は、複数のsystemRegistration.xmlファイルが追加されます。参加アプリケーションをデプロイする前に、参加アプリケーションがシステム・レジストリのエントリに追加されているかどうかを確認します。リクエストの重複は、システム・レジストリ表で有効化されている主キーと一意値の制約によって、SQL例外が発生する原因となります。

前述のSQLコンテンツの太字のテキストを組み込むことによって、これらを確認してください。参加アプリケーションの値の重複が検出された場合は作成されません。一意の場合は作成されます。

AIAデプロイメント・ドライバは、systemRegistration.xmlのトークンを$AIA_INSTANCE/config/AIAInstallProperties.xmlで提供されている例2-2のデータに置き換えることで、この例のSQLコンテンツを抽出しました。

例2-4 サンプルSQL作成コード

<AIASystemRegistration>
<create>
MERGE INTO AIA_SYSTEMS sysreg USING dual on (dual.dummy is
not null and sysreg.SYSTEM_CODE='SampleSEBLDPT003' ) WHEN NOT
MATCHED THEN INSERT (SYSTEM_ID,SYSTEM_INTERNAL_ID,SYSTEM_CODE,
SYSTEM_DESC,SYSTEM_IP_ADDR,SYSTEM_URL,SYSTEM_TYPE,APPLICATION_
TYPE,APPLICATION_VERSION,CONTACT_NAME,CONTACT_PHONE,CONTACT_
EMAIL) VALUES (AIA_SYSTEMS_S.nextval,'SampleSEBLDPT003','SampleSEBLDPT003',
'Sample Siebel Instance01','10.0.0.1','http://
${participatingapplications.SampleSiebel.server.
soaserverhostname}:${participatingapplications.SampleSiebel.
server.soaserverport}
/ecommunications_enu'
,'Sample SIEBEL','CRM','${pips.BaseSample.version}
','Siebel contact','1234567891','aiasamples_contact@aia.com')
/
MERGE INTO AIA_SYSTEMS sysreg USING dual on (dual.dummy is
not null and sysreg.SYSTEM_CODE='SamplePortalDPT003' )
WHEN NOT MATCHED THEN INSERT (SYSTEM_ID,SYSTEM_INTERNAL_
ID,SYSTEM_CODE,SYSTEM_DESC,SYSTEM_IP_ADDR,SYSTEM_URL,SYSTEM_
TYPE,APPLICATION_TYPE,APPLICATION_VERSION,CONTACT_NAME,CONTACT_
PHONE,CONTACT_EMAIL) VALUES (AIA_SYSTEMSS.nextval,
'SamplePortalDPT003','SamplePortalDPT003',
'Sample Portal Instance 01','10.0.0.1',
'http://${participatingapplications.SamplePortal.server.
soaserverhostname}:${participatingapplications.SamplePortal.
server.soaserverport}
','Sample Portal','BILLING','${pips.BaseSample.version}'
,'Portal contact','1234567892','aiasamples_contact@aia.com')
/
</create>
</AIASystemRegistration>

例2-5 サンプル参加アプリケーション／コード

<properties>
<participatingapplications>
<SamplePortal>
<server>
<soaserverhostname>adc2180948.xy.example.com
</soaserverhostname>
</server>
...
</participatingapplications>
</properties>

例2-6 サンプル削除コード

<AIASystemRegistration>
<delete>
delete from AIA_SYSTEMS where SYSTEM_CODE='SampleSEBLDPT005'
/
delete from AIA_SYSTEMS where SYSTEM_CODE='SamplePortalDPT005'
/
</delete>
</AIASystemRegistration>

2.3.6 EBFの識別と作成

識別された各EBFには、対応するビジネス・プロセスEBSがあります。このEBS内の操作は、EBFへのエントリ・ポイントです。

詳細は、「エンタープライズ・ビジネス・フローの設計と作成」を参照してください。

2.4 Oracle AIA統合フローのテスト

CAVSでは、アプリケーションのスタブ化によるエンドツーエンドのテストがサポートされます。

CAVSの詳細は、Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイドのコンポジット・アプリケーション検証システムの概要に関する項を参照してください。

3 直接統合の実装

この章では、直接統合の概要を示し、直接統合を実装するための手順について説明します。

この章の内容は次のとおりです。

- 直接統合の理解

- 直接統合に対するアプリケーション・ビジネス・フロー設計パターンの使用

- 適切な粒度の検出

- トランザクションの処理

- アプリケーションとのアウトバウンド相互作用の有効化

- ABFの呼出し

- エラーの処理

- サービスの保護

- 相互参照の使用

- 命名規則および標準

- コンポジットの注釈付け

- サービス構成

- 直接統合の拡張

3.1 直接統合の理解

Oracle SOAコア拡張機能を使用すると、組織では、標準モデルと呼ばれる一般的な情報モデルを使用して、そのアプリケーションを容易に統合できるようになります。正規のエンタープライズ・ビジネス・オブジェクト(EBO)は、統合フローに複数のソース・システムと宛先システムとの接続が含まれている統合で最も効果的に動作します。正規ベースのインタフェースでは、参加アプリケーション間の緊密な結合が最小限になります。この結果、新規アプリケーションがエコシステムに追加された場合に、再利用が可能になり、デプロイメントの速度が向上します。

ただし、すべての統合シナリオに標準統合モデルが必要なわけではありません。SOAコア拡張機能のコンポーネントでも、アプリケーション間(直接)統合がサポートされます。

直接統合を検討する必要があるのは次の場合です。

- 統合の各エンドにあるアプリケーションが1つのみである場合。

- マッピングを少なくする必要がある場合。

- 統合の待ち時間を最大限短縮する必要がある場合。

- 統合が変換中心であり、非常に高いスループット(最大で10,000メッセージ/時間以上、または30メッセージ/秒)が要求される場合。

- 統合がデータ中心ではなくプロセス中心である場合。

- リクエスタ・アプリケーションとプロバイダ・アプリケーションに変更の予定がない場合。

3.2 直接統合に対するアプリケーション・ビジネス・フロー設計パターンの使用

コンシューマ・アプリケーションとプロバイダ・アプリケーションまたはサービス間の単一モードの通信では、プロバイダまたはサービスで指定されたとおりに、XMLベースのデータ構造を使用して直接相互作用できます。

アプリケーション・ビジネス・フロー(ABF)では、統合フローが管理され、統合に必要な次のタスクが実装されます。

1. サービスで、クライアント・アプリケーションからリクエストが受信され、必要に応じてデータ・エンリッチメントが実行されます。
データ・エンリッチメントとは、クライアント・アプリケーションから追加の詳細を取得することであるといえます。

2. サービスで、接続プロトコルを使用してプロバイダがコールされます。
プロバイダ・アプリケーションから受信したレスポンスは、クライアント・アプリケーションの書式に変換された後で、クライアント・アプリケーションに返されます。

統合サービスのインタフェースは、リクエスタ/クライアント・アプリケーションによって定義されます。

注意:

後で追加のプロバイダを導入する場合は、別のABFを追加する必要があります。

3.3 適切な粒度の検出

エンドツーエンドの統合フローは、統合要件に応じて、単一のABFコンポジットまたは複数のABFコンポジットを使用して実装できます。統合フローを設計する際は、次のことを考慮してください。

- サービスの機能を複数回再使用する可能性がある場合は、再使用可能なサービスを定義および設計します。

- サービスに埋め込まれた一部の機能が複数の統合シナリオで必要な場合は、それを別々のABFに再度分解して、それを参照するサービスを作成します。

- オプションで、機能を別々のサービスとして使用できる場合は、図3-1に示すように、ABFを使用して別のABFを呼び出します。

図3-1 ABFを呼び出すABF

3.4 トランザクションの処理

ABFサービス・インタフェースで定義された操作に2つ以上のリソースに対する破壊的な書込みが含まれる場合は、これらのタスクを単一のトランザクションで実行することをお薦めします。

3.4.1 トランザクション・コンポジットとしてのABFの作成

次のシナリオでは、トランザクション属性を設定したABFコンポジットを設計します。

- 2つの異なるアプリケーションの更新が必要であり、1つの更新のみが成功して不整合になった場合に発生する問題を回避する場合。

- 既存のグローバル・トランザクション・コンテキストがあり、統合プロセス・サービスで実行される操作がそのグローバル・トランザクションの一部である必要がある場合。

- アプリケーションでメッセージを送信/受信する必要があり、同時に更新を実行する必要がある場合。

- 関連メッセージのグループをバッチ・モードで処理する必要がある場合。

3.4.2 ABFでのトランザクション機能の実現

トランザクション機能を実現するには、2フェーズ・コミットを使用して共通のトランザクション・コンテキストを作成します。

BPELコンポーネントでは、BPELプロセスが呼び出されると新規トランザクションが作成されます。トランザクションがすでに存在する場合、BPELではそのトランザクションが中断され、新しいトランザクションが作成されます。BPELコンポーネントにトランザクション・フラグを設定して、単一のグローバル・トランザクションに実行を連鎖するには、例3-1に示すように、コンポジット・エディタのソースにbpel.config.transactionをrequiredという値で追加します。

トランザクション・フラグが設定されると、BPELでは既存のトランザクションが継承されます。新しいトランザクションが作成されるのは、同様のトランザクションが存在しない場合のみです。

ABFサービスが別のSOAコンポジットによって呼び出される場合は、必ずコンポジットの単一スレッド実行としてください。これを実装する必要があるのは、サービスによって一方向の操作が公開されている場合のみです。コンポジットの単一スレッド実行を実現するには、次に示すように、コンポジット内のBPELコンポーネントに対してプロパティを設定することによって、コール元のコンポジットでコンポジットの同期タイプの呼出しを設定します。

bpel.config.oneWayDeliveryPolicy=sync

注意:

両方の設定を、JDeveloperでのサービスの設計時に設定できます。

例3-1 BPELコンポーネントのトランザクション・フラグの設定

<component name="<BPELProcessName">
<implementation.bpel  src="<BPELProcessName" >.bpel"/>
<property name="bpel.config.transaction">required</property>
</component>

3.5 アプリケーションとのアウトバウンド相互作用の有効化

この項では、参加アプリケーションとのアウトバウンド相互作用を有効化する方法について説明します。

3.5.1 JCAアダプタの使用

JCAアダプタを使用できる場合、JCAアダプタでは、ランタイム環境との組合せで、接続管理、トランザクション管理およびスケーラビリティに関するタスクがサポートされるため、アプリケーションに接続するための最初の選択肢とする必要があります。

3.5.2 標準Webサービス・インタフェース(SOAP/HTTP、XML/HTTP)の使用

ほとんどのアプリケーションは、Webサービスの形式で機能を公開しています。最も一般的に使用されるトランスポートは、SOAP over HTTPです。ただし、アプリケーションによっては直接XML over HTTPを公開している場合もあります。同期モードのみでアウトバウンド相互作用を行う参加アプリケーションは、SOAP/HTTPを使用してリクエストを送信する必要があります。

3.5.3 JMSキューの使用

メッセージの送信をメッセージの処理と分離する場合は、キューを使用します。JMSキューを使用する場合は、JMSアダプタを使用してアクセスします。メッセージは、ABFアーティファクトによってJMSキューにエンキューされ、そのメッセージがアプリケーションによってデキューされます。

3.5.4 1つのコンポジットにおけるまたは個別のコンポジットとしてのアダプタの使用

同じトランスポート・アダプタ・サービスを複数のABFで使用できる場合にのみ、アダプタを個別のサービス・コンポジットとして開発します。このような再利用の可能性がない場合は、ABFとトランスポート・アダプタを同じコンポジットに組み込みます。

3.6 ABFの呼出し

ABFとアプリケーション間の通信は、アプリケーション機能によって管理されます。次の方法でABFを呼び出すことができます。

- クライアント・アプリケーションでABFに対するWebサービス・コールを実行する標準のWebサービス・インタフェースの使用。

- 必要な機能を個別のABFとして使用できる場合は、別のABFの使用。

- リクエスタでWebサービス・コールを実行できない場合は、サービス・エンドポイントに対するコンポジット内での、JCA/JMSなどの適切なバインディングの使用。
ABFは、クライアント・アプリケーションで呼び出すことができるアダプタを組み込むことによって作成されます。

- メッセージの送信をメッセージの処理と分離する必要がある場合は、JMSキューの使用。JMSキューには、JMSアダプタを使用してアクセスする必要があります。メッセージは、アプリケーションによってJMSキューにエンキューされ、そのメッセージがABFによってデキューされます。JMSを使用すると、保証付きメッセージ配信に対する永続的な方法でのメッセージの交換が容易になります。

- リクエスタ・アプリケーションにメッセージをキューに入れる機能がない場合は、JMSプロデューサ・コンポジットの公開。ABFコンポジットにJMSコンシューマ・アダプタを作成します。JMSコンシューマ・アダプタによってメッセージがデキューされ、サービス・プロバイダ・アプリケーションが呼び出されます。非同期キューイング設計パターンによって、中央のキューが設定され、サービスで可用性の問題を解決できるようになり、非同期データ交換の全体的な堅牢性が向上します。

3.7 エラーの処理

この項では、直接統合の実装時にエラーを捕捉する方法について説明します。

3.7.1 直接統合サービスの使用

直接統合サービスを有効化して、ランタイム・フォルトとビジネス・フォルトを捕捉および処理するように構成します。WSDLコントラクトの決定時に予測できるビジネス・フォルトをすべて組み込み、サービスからABFサービスのコール元にビジネス・フォルトを返すことができるようにします。

考えられるすべてのエラーに対して個別のcatchブロックを作成して、予期しないエラーのみを確実にcatchAllに移動することをお薦めします。

ベスト・プラクティスは、エラー通知およびエラー・ロギングを送信するための一方向のエラー通知サービスを呼び出すことです。

3.7.2 フォルト管理フレームワークの使用

SOAコア拡張機能に付属のエラー処理フレームワークを例外の捕捉および例外処理に利用できます。サービス固有のフォルト・ポリシー・ファイルを定義し、その中にランタイム・フォルトとビジネス・フォルトの両方を定義して、コンポジット・レベルでフォルト・ポリシーを関連付けることをお薦めします。

直接統合でAIAエラー・ハンドラ・フレームワークのAIAAsyncErrorHandlerBPELProcessを使用できますが、それに必要な書式で入力を渡します。AIAFault要素を文字列で表すXML要素を作成した後で、ビジネス・フォルト処理およびエラー通知/ロギング用のAIAAsyncErrorHandlerBPELProcessを呼び出します。

AIAAsyncErrorHanlderBPELProcessを呼び出すには、「同期リクエスト/レスポンスでのBPELのCatchおよびCatch-Allブロックに関するガイドライン」に記載されているガイドラインに従います(XSLTのEBM_to_Fault.xslを適用するステップを除く)。ただし、入力メッセージには、データが入力された次の要素が必要です。

- Fault/FaultNotification/FaultMessage/Text

- Fault/FaultNotification/FaultingService/InstanceID

- Fault/FaultNotification/FaultingService/ECID

- Fault/FaultNotification/FaultingService/ImplementationCode

- Fault/FaultNotification/FaultingService/ID

電子メール通知など、必要なフレームワーク動作すべてを取得でき、EMコンソールを使用してドリルダウンすることもできます。

EBM_HEADERから導出されるフォルト・メッセージの一部である情報にはアクセスできません。ただし、次の要素は、フォルト・ポリシーxmlファイルに構成されている、リモート、結合およびその他のフォルトに対するAIA処理フレームワークによって導出できます。

- フォルト・メッセージ・コード

- フォルト・メッセージ・テキスト

- Severity

- Stack

- フォルト処理サービスID

- フォルト処理サービス実装コード

- フォルト処理サービス・インスタンスID

- 修正処理

- レポート作成日付

エラー・コードおよびサービス名を使用して、通知設定画面からエラー情報のルーティングを有効化します。

注意:

正規統合でフォルト処理に使用する、BPELプロセスのEBM_Header変数の作成は、直接統合では関係ありません。

このリリースでは、メッセージ再発行はデフォルトでサポートされていません。

3.8 サービスの保護

直接統合サービスを保護するためのプロセスは、AIAサービスを保護する方法と同じです。プロセスは次のとおりです。

- すべてのWebサービス・エンド・ポイントを保護する必要があります。

- 個々のサービス・コンポーネントを保護する必要はありません。

- すべてのサービスを認証資格証明付きで提供する必要があります。

- 保護されたABFサービスを呼び出すアプリケーションは、必要な資格証明を送信する必要があります。

3.8.1 認証のためのOWSMポリシーに関するセキュリティ推奨事項

表3-1に、OWSMポリシーに関するセキュリティ推奨事項を示します。

表3-1 OWSMポリシーに関するセキュリティ推奨事項

ポリシー

推奨事項

oracle/aia_wss_saml_or_username_token_service_policy_OPT_ON

これは、「ローカルの最適化」が「オン」に設定されたoracle/wss_saml_or_username_token_service_policyのクローンです。このOWSMセキュリティ・ポリシーをコンポジットのサービス・エンド・ポイントにアタッチします。このポリシーは、WS-Security SOAPヘッダーまたはUsernameToken WS-Security SOAPヘッダーのSAMLトークンで提供される資格証明を使用した受信リクエストの認証時に適用されます。

oracle/aia_wss10_saml_token_client_policy_OPT_ON

これは、「ローカルの最適化」が「オン」に設定されたoracle/wss10_saml_token_client_policyのクローンです。このOWSMセキュリティ・ポリシーをコンポジットの参照エンド・ポイントにアタッチします。このポリシーでは、アウトバウンドSOAPリクエスト・メッセージにSAMLトークンが挿入されます。

注意:

2つのカスタムOWSMポリシーは、SOAコア拡張機能がインストールされるとサーバーで使用可能になります。

その他の推奨事項:

- 保護されたアプリケーション・サービスを呼び出すコンポジットに対しては、適切なクライアント固有のポリシーを使用します。

- 保護されていないアプリケーション・サービスを呼び出す場合は、no_authentication_client_policyを使用します。

- JCAベースのアプリケーション・サービスをコールするコンポジットに対しては、ポリシーをアタッチする必要はありません。

3.8.2 コンポジットへのOWSMポリシーの関連付け

直接統合のサービスでは、SOAコア拡張機能で提供されるグローバル・ポリシー・アタッチメント・サポートを利用できます。デプロイメント後に、SOAコア拡張機能ツールによって、ネーミング・パターンがABFで終わるサービスにグローバル・ポリシーが自動的にアタッチされます。

SOAコア拡張機能を使用しないサービスは、OWSMポリシーを直接(ローカルで)アタッチする必要があります。設計時に、composite.xmlファイルのポリシーをサービスおよび参照エンドポイントにアタッチします。デプロイメント後に、EMコンソールを使用してOWSMポリシーをSOAコンポジットにアタッチすることもできます。

3.9 相互参照の使用

相互参照エンティティごとにカスタム・データベース表を生成します。カスタム相互参照表に相互参照を格納するためXREFエンティティを構成することをお薦めします。これによるプログラミング・モデルの変更はありません。相互参照データが格納されるたびに、それがSOAインフラ(XREF_DATAまたはカスタム・データベース表)に存在するかどうかに関係なく、単一のAPIのセットを使用してXREFの参照と入力が実行されます。

相互参照エディタを使用すると、カスタム・データベース表を使用する必要があるかどうかを指定できます。(相互参照アーティファクトの定義時に、最適化オプションを使用します。)また、必要なDDLスクリプトも生成されます。ただし、SOAでは表は自動的には作成されません。

カスタム相互参照表の使用方法の詳細は、http://www.oracle.com/technetwork/middleware/foundation-pack/learnmore/aiaxref-524690.htmlを参照してください。

注意:

統合レイヤーへの相互参照行の入力は、ソースまたはターゲット・アプリケーションに相互参照を管理する機能がある場合は必要ありません。

3.10 命名規則および標準

ABFは、処理ロジックを取得するためのタスク指向サービスとしてモデル化されます。実際の方法は、処理およびエンティティ・コンテキストに基づいてサービスに名前を付けることです。サービス名に動詞およびエンティティを使用することをお薦めします。

ABFは、特定のアプリケーションを統合するように設計されているため、サービス名の一部としてアプリケーションの名前を使用してください。

ABF名のテンプレートは、[動詞][エンティティ][App1][App2] ABF[バージョンが1より大きい場合はVn]で、App1はソース・アプリケーション、App2はターゲット・アプリケーションです。

たとえば、ProcessFulfillmentOrderEbizFusionABFです。

必要に応じて、参加ソース・アプリケーションと参加ターゲット・アプリケーションの間にToという語を追加することもできます。たとえば、ProcessFulfillmentOrderEbizToFusionABFです。

3.10.1 ネーミング・サービスに関する追加のガイドライン

1. エンリッチメント・サービスの呼出しが含まれる場合のABFの名前設定
統合が、ターゲット・アプリケーションとの統合に使用する値を取得するために、GOP、税金計算などの仲介/ユーティリティ・アプリケーションと相互作用する場合は、これらの仲介/ユーティリティ・アプリケーションの名前をサービス名に含めます。

2. 包括的なABFの名前設定
包括的な編成プロセスには複数のタスクが含まれ、この場合、各タスクに別のアプリケーションとの統合が含まれる場合があります。このような場合は、すべてのアプリケーション名をサービス名に組み込まないでください。ソース・アプリケーション名のみを使用します。

たとえば、ProcessFulfillmentOrderEbizABFは、FusionCRMにエントリを作成し、請求のためにBRMを更新して、B2BGatewayとインタフェースを介して出荷通知を外部のTPに送信します。包括的なプロセスは、ソース・アプリケーションによって指定できるため、ソース・アプリケーション名のみを使用します。

3. 操作名
サービス名は幅広いコンテキストを対象とするため、動詞の後にサービス操作名のエンティティを使用できます。

4. メッセージ名
メッセージ名は、[操作名]Request/[操作名]Responseにする必要があります。

5. コンポジット・ネームスペース
コンポジット・ネームスペースの標準は、http://xmlns.oracle.com/ApplicationBusinessFlow/[機能領域または事前作成済の統合]/[バージョンなしのコンポジット名]/V[n]です。

たとえば、http://xmlns.oracle.com/ApplicationBusinessFlow/OrderToCash/ProcessFulfillmentOrderFusionDOOToEbiz/V1です。

6. メッセージのネームスペース
すべてのネームスペースがhttp://xmlns.oracle.com/で始まり、エンティティ固有およびドメイン固有の識別子が続く必要があります。たとえば、core、Industryです。サブドメインがある場合は、それらを指定します。

たとえば、http://xmlns.oracle.com/ABFMessage/Core/Invoice/V1です。

7. ABF (WSDL)インタフェースのネームスペース
http://xmlns.oracle.com/ApplicationBusinessFlow/\[機能エリアPIP]/[コンポジット名]/V[n]

たとえば、http://xmlns.oracle.com/ApplicationBusinessFlow/OrderToCash/ProcessFulfillmentOrderFusionDOOEbizABF/V1です。

3.11 コンポジットの注釈付け

ABFサービスのメタ情報は、Oracle Enterprise Repository (OER)のアセットの保守で使用されます。公開されたサービスおよび参照先サービスに対して、コンポジットに注釈を付けることをお薦めします。提示されているガイドラインに従い、開発時にこれらのコメントを挿入してください。

この項の例に示すように、<svcdoc:AIA>要素に注釈を埋め込み、<svcdoc:AIA>要素をxmlコメント・タグ<!--と-- >内に配置します。

<svcdoc:ServiceSolutionComponentAssociation>は、例3-2に示すように、すべての注釈付きcomposite.xmlファイルで、最初の注釈要素である必要があります。

この要素は、アーティファクトの生成に使用するグローバル一意識別子(GUID)を記述し、ルート要素<composite>の下に配置される必要があります。この要素の値は、空白のままにする必要があります。GUIDによって、ソリューション・サービス・コンポーネントが、実装されたビジネス・サービス・コンポジットに関連付けられます。この関連付けによって、部品構成表への自動入力が可能になります。

例3-3および例3-4に示すように、composite.xmlのサービスおよび参照要素に注釈を付けます。

前述の例で、コンポジットの注釈要素のルートは、<svcdoc:AIA>です。注釈要素<svcdoc:Service>および<svcdoc:Reference>を使用して、xmlコメント・タグの下にあるコンポジットのサービスおよび参照要素に対して、それぞれ例3-5と例3-6に示すように注釈を付けます。

<svcdoc:Service>
<svcdoc:ImplementationDetails>
<svcdoc:ApplicationName>Source Application</svcdoc:ApplicationName>
.................................................................
<svcdoc:ArtifactType>ApplicationBusinessFlow</svcdoc:ArtifactType>
<svcdoc:ServiceOperation>
......................................................................
</svcdoc:ServiceOperation>
</svcdoc:ImplementationDetails>
<svcdoc:TransportDetails>
<svcdoc:JMSAdapter>
<svcdoc:ResourceProvider>WLSJMS</svcdoc:ResourceProvider>
<svcdoc:ConnectionFactory>JNDINameOfConnectionFactory</svcdoc:ConnectionFactory>
<svcdoc:XAEnabled>true</svcdoc:XAEnabled>
<svcdoc:ResourceTargetIdentifier>JMSUSER1</svcdoc:ResourceTargetIdentifier>
<svcdoc:ResourceType>Queue</svcdoc:ResourceType>
<svcdoc:ResourceName>JMSQueueName</svcdoc:ResourceName>
<svcdoc:ResourceFileName></svcdoc:ResourceFileName>
</svcdoc:JMSAdapter>
</svcdoc:TransportDetails>
</svcdoc:Service>

<svcdoc:Reference>
<svcdoc:ArtifactType>TransportAdapter</svcdoc:ArtifactType>
<svcdoc:ServiceOperation>
<svcdoc:Name>GetSalesOrderLineShippingDetailsEbizAdapter</svcdoc:Name>
</svcdoc:ServiceOperation>
<svcdoc:TransportDetails>
<svcdoc:ApplicationAdapter>
<svcdoc:ResourceProvider>OracleDB</svcdoc:ResourceProvider>
<svcdoc:BaseVersion>12.1.3</svcdoc:BaseVersion>
<svcdoc:ConnectionFactory>eis/Apps/OracleAppsDataSource</svcdoc:ConnectionFactory>
<svcdoc:ApplicationName>ebiz</svcdoc:ApplicationName>
<svcdoc:XAEnabled>true</svcdoc:XAEnabled>
<svcdoc:ResourceTargetIdentifier></svcdoc:ResourceTargetIdentifier>
<svcdoc:ResourceType>Procedure</svcdoc:ResourceType>
<svcdoc:ResourceName></svcdoc:ResourceName>
<svcdoc:ResourceFileName>XX_BPEL_GETSALESORDERLINESHIPP.sql</svcdoc:ResourceFileName>
</svcdoc:ApplicationAdapter>
</svcdoc:TransportDetails>
</svcdoc:Reference>

例3-2 すべてのcomposite.xmlファイルに対する最初の注釈要素

<composite name="SamplesCreateCustomerPartyPortalBusinessService">
........................
<!--<svcdoc:AIA>
<svcdoc:ServiceSolutionComponentAssociation>
<svcdoc:GUID></svcdoc:GUID>
</svcdoc:ServiceSolutionComponentAssociation>
</svcdoc:AIA>-->
.....................................
</composite>

例3-3 注釈付きのcomposite.xmlのスケルトン・サービス要素

<service ui:wsdlLocation .......>
<interface.wsdl ....... />
<binding.ws ........... />
<!-- <svcdoc:AIA>
<svcdoc:Service>
. . . . . . . . . . . .
</svcdoc:Service>
</svcdoc:AIA> -->
</service>

例3-4 注釈付きのcomposite.xmlのスケルトン参照要素

<reference ui:wsdlLocation ........">
<interface.wsdl ............/>
<binding.ws ................/>
<!-- <svcdoc:AIA>
<svcdoc:Reference>
.................
</svcdoc:Reference>
</svcdoc:AIA> -->
</reference>

例3-5 サービス注釈要素の例

<svcdoc:Service>
<svcdoc:InterfaceDetails>
<svcdoc:ServiceName>.....</svcdoc:ServiceName>
<svcdoc:Namespace>.......</svcdoc:Namespace>
<svcdoc:ArtifactType>ApplicationBusinessFlow</svcdoc:ArtifactType>
<svcdoc:ServiceOperation>
.......
</svcdoc:ServiceOperation>
</svcdoc:InterfaceDetails>
<svcdoc:ImplementationDetails>
<svcdoc:ApplicationName>Source Application</svcdoc:ApplicationName>
................
<svcdoc:ArtifactType>ApplicationBusinessFlow</svcdoc:ArtifactType>
<svcdoc:ServiceOperation>
..........
</svcdoc:ServiceOperation>
</svcdoc:ImplementationDetails>
</svcdoc:Service>

例3-6 トランスポート・アダプタがある場合のサービス注釈要素の例

<svcdoc:Reference>
<svcdoc:ArtifactType>UtilityService</svcdoc:ArtifactType>
<svcdoc:ServiceOperation>
<svcdoc:Name>initiate</svcdoc:Name>
</svcdoc:ServiceOperation>
</svcdoc:Reference>

3.11.1 WSDLへの注釈の付加

WSDL注釈は、既存のAIAサービス注釈と同じです。例3-7を参照してください。

例3-7 サンプルのWSDL注釈

<documentation>
<svcdoc:Service>
<svcdoc:Description></svcdoc:Description>
<svcdoc:ServiceType>ApplicationBusinessFlow</svcdoc:ServiceType>
<svcdoc:Version>2</svcdoc:Version>
</svcdoc:Service>
</documentation>

3.12 サービス構成

SOAコア拡張機能のツールを使用する直接統合サービスは、XMLファイルのサービス・レベル構成プロパティの設定に既存の方法を使用できます。ただし、新しく作成された直接統合フローに対しては、SOAのBPELプリファレンス/プロパティ機能を利用することによって、BPELプリファレンスを使用することをお薦めします。コンポジットで、プロパティを使用して、構成可能なプロファイルを定義します。

<property name="bpel.preference.myProperty">myValue</property>

定義済のプロパティに対する追加/削除/変更などの構成の更新は、EMコンソールから直接実行できます。サービス構成にSOAのBPELプリファレンスを使用している場合は、プロパティの更新に別のUIは必要ありません。

この方法には制限があります。この方法の特徴は、次のとおりです。

- XSL変換でサポートされません。

- BPELからのみ使用できます。メディエータではサポートされません。

- ドメイン・レベルの構成はサポートされません。

- EMコンソールのプリファレンスに対するナビゲーションは非直観的です。

SOAコア拡張機能がインストールされると、AIAサービス構成ファイルを直接統合フローによるサービスのランタイム動作の構成に使用できます。

3.13 直接統合の拡張

この項では、直接統合の拡張パターンについて説明します。この項には次のトピックが含まれます:

3.13.1 XSLの拡張

次のガイドラインを使用して、拡張機能を提供するためのベース変換XSLファイルを開発します。

- 変換マップの拡張が認識されるようにするには、すべての変換に対する拡張XSLファイルを作成します。
コア変換XSLファイルの例: PurchaseOrder_to_PurchaseOrder.xsl

すべてのコアXSLファイル名に1つの拡張XSLファイルがあります(例: PurchaseOrder_to_PurchaseOrder_Custom.xsl)。

- メッセージ内のすべてのコンポーネントに対して、拡張ファイルに空の名前付きテンプレートを定義します。

- コア変換ファイルに拡張ファイルを組み込みます。

- コア変換の各コンポーネントに対してcall-templateを追加します。

- 例3-8に示すように、カスタム要素の変換に変換で対応できるようにします。

例3-8 カスタム要素の変換に対応可能な変換

<!-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>

3.13.2 サービスの拡張

- 特定のカスタマイズ・ユースケースがある場合のみ、コンポジットにカスタマイズ可能のマークを付けます。

- 特定のカスタマイズ・ユースケースがある場合のみ、BPELプロセス内の特定のスコープにカスタマイズ可能のマークを付けます。

3.13.3 カスタマイズを可能にするためのガイドライン

この項では、カスタマイズ可能のマークを付けるBPELスコープを識別するための一般的なガイドラインについて説明します。

カスタマイズ可能なスコープ・アクティビティの範囲は、可能なかぎり狭くする必要があります。たとえば、BPELフローの最上位レベルのスコープをカスタマイズ可能としてマーク付けするのではなく、カスタマイズ要件を満たすためにロジックを追加できる特定のスコープを識別します。

- 後で部分的に削除される可能性がある複雑なロジックにカスタマイズ可能のマークを付けないようにしてください。

- コンポジットにカスタマイズ可能のマークを付けた場合は、それをリリースするまでマークを解除しないでください。マークを解除すると、カスタマイズによってパッチ適用が機能しなくなります。

- ベース・バージョンに対して、カスタマイズしたコンポジットにパッチが適用された場合に、ある意味で競合が発生するような変更はしないでください。たとえば、カスタマイズ可能なBPELスコープ内のコンポーネント、ルーティング・ルールおよびアクティビティの削除では、顧客は、カスタマイズされた項目が削除されたときに、マージ競合を手動で解決する必要があります。

- コンポジットがリリースされた後は、カスタマイズ可能コンポジットからのコンポーネントまたはルーティング・ルールの削除、およびカスタマイズ可能とマーク付けされたBPELスコープ内のアクティビティの削除は実行しないでください。

4 カスタムXPath関数の開発とデプロイ

この章では、JavaでJava XPathクラスとして関数を実装する方法、JDeveloperでXPath/XSL関数をデプロイする方法、およびアプリケーション・サーバーでXPath/XSL関数をデプロイする方法について説明します。

この章の内容は次のとおりです。

- JavaでのJava XPathクラスとしての関数の実装

- JDeveloperでのXPath/XSL関数のデプロイ

- アプリケーション・サーバーでのXPath/XSL関数のデプロイ

4.1 JavaでのJava XPathクラスとしての関数の実装

カスタム関数はXPathまたはXSL関数として呼び出すことができるため、実装クラスで両方を処理する必要があります。このため、ホスティング・クラスには少なくとも次が含まれている必要があります。

- 関数名と同じ名前のpublic staticメソッド。
このメソッドは、XSL関数の呼出しで使用されます。現在、カスタム関数のオプション・パラメータは、JDeveloperへの登録時にサポートされません。このため、オプション・パラメータがある関数は使用しないことをお薦めします。

- oracle.fabric.common.xml.xpath.IXPathFunctionを実装するpublic static内部クラス
このインタフェースには次のメソッドがあります。

XPath関数の呼出し時にサービス・エンジンによってコールされるObject call (IXPathContext context, List args) throws XPathFunctionException。関数がコールされると、ランタイム・エンジンによって、XPathContextおよび関数に渡される引数のリストが渡されます。IXPathContextを使用すると、実行コンテキスト内のBPEL変数値にアクセスできます。このメソッドの実装は、関数を表すpublic staticメソッドに必然的に委任することになります。

例4-1に、現在の日付を取得するカスタム関数の実装を示します。実装では、XSLとXPathの両方のサポートを処理する必要があります。関数には、オーバーロードされたメソッドの実装方法を示すオプションのパラメータもあります。

例4-1 現在の日付を取得するためのカスタム関数の実装

package oracle.apps.aia.core;•
import java.text.SimpleDateFormat;
import java.util.Date; import
java.util.List;
import oracle.fabric.common.xml.xpath.IXPathContext;
import oracle.fabric.common.xml.xpath.IXPathFunction;
import oracle.fabric.common.xml.xpath.XPathFunctionException;
public class DateUtils
{
public static class GetCurrentDateFunction implements IXPathFunction
{
public Object call(IXPathContext context, List args)
throws XPathFunctionException
{
if (args.size() == 1)
{
String mask = (String) args.get(0);
if(mask==null || mask.equals(""))
mask = "yyyy-MM-dd";
return getCurrentDate(mask);
}
throw new XPathFunctionException("must pass one argument.");
}
}
public static String getCurrentDate(String formatMask)
{
SimpleDateFormat df = new SimpleDateFormat(formatMask)
String s = df. format (new Date());
return s;
}
. . .
}

4.1.1 カスタムXPath関数のネーミング標準

次のネーミング標準が適用されます。

- 関数名

- 関数実装クラス

- 関数実装メソッド

- 関数内部クラス

- 関数ネームスペース

- 関数ネームスペース接頭辞

4.1.1.1 ファンクション名

関数名は、名前がローワー・キャメルケースである標準のJavaメソッド・ネーミング標準に従う必要があります。

例: getCurrentDate、getEBMHeaderValueなど。

4.1.1.2 関数実装クラス

同じクラスに1つ以上の関数を実装できます。クラス名は、名前がアッパー・キャメルケースであるJavaクラス・ネーミング標準に従い、実装される機能の機能性を伝える必要があります

例: EBMHeaderUtils、RoutingUtilsなど。

4.1.1.3 関数実装メソッド

実装クラスには、各XPath関数に対するメソッドが含まれます。メソッドには、関数名と同じ名前を付ける必要があります。パラメータのデータ型は、関数のパラメータのデータ型と一致する必要があります。関数にオプションのパラメータがある場合は、特別なオプションのパラメータを処理するために、別のオーバーロードされたメソッドを設定する必要があります。

例: getCurrentDate、getEBMHeaderValueなど。

4.1.1.4 関数内部クラス

各XPath関数に対して、その関数のアッパー・キャメルケースにFunction接尾辞を付加したとおりの名前の内部クラスが必要です。内部クラスは、BPELからXPath関数にアクセスするためにのみ必要です。内部クラスでは、com.oracle.bpel.xml.XPath.IXPathFunctionインタフェースを実装する必要があります。

例: GetESBHeaderValueFunctionなど

4.1.1.5 関数ネームスペース

BPEL式ビルダー・ウィザードとXSLマッパーの両方に関数が表示されるようにするには、ネームスペースがhttp://www.oracle.com/XSL/Transform/java/で始まり、その後に、関数を実装するJavaクラスの完全修飾名が続く必要があります。

例:

http://www.oracle.com/XSL/Transform/java/oracle.apps.aia.core.ebmheader.EBMHeaderUtils

http://www.oracle.com/XSL/Transform/java/oracle.apps.aia.order.route.RoutingUtils

4.1.1.6 関数ネームスペース接頭辞

ネームスペース接頭辞は、機能に基づいた読取り可能な略称である必要があります。

例: GetEBMHeaderValueFunctionの場合はebh。

4.1.2 サポートされるデータ型

XPath 1.0とXSL 1.0のデータ型は、表4-1に示すように、関数への戻りパラメータまたは入力パラメータとしてサポートされます。

Table 4-1 XPath関数に対してサポートされているデータ型

XPath 1.0/XSL 1.0

Java

Node-set

XMLNodeList

Boolean

Boolean

String

String

Number

Int、float、doubleなど

Tree

XMLDocumentFragment

4.2 JDeveloperでのXPath/XSL関数のデプロイ

カスタム関数をBPEL式ビルダーおよびXSLマッパーで表示できるようにするには、JDeveloperで登録する必要があります。これを実行するには、例4-2に示すように、ユーザー定義拡張関数構成ファイル[ext-soa-xpath-functions-config.xml]を指定し、それをFilePreferencesXSLマップを介してJDeveloperに登録します。

実装クラスは、zip/jar形式で圧縮して、$SOA_HOME/soa/modules/oracle.soa.ext_11.x.x/classesフォルダに格納する必要があります。このように、これらのクラスは、WebLogicサーバーのクラスパスに配置されます。

例4-2 ユーザー定義拡張関数の構成ファイル

<?xml version="1.0" encoding="UTF-8"?>
<soa-xpath-functions xmlns=http://xmlns.oracle.com/soa/config/xpath xmlns:utl="http://www.oracle.com/XSL/Transform/java/oracle.apps.aia.core.DateUtils"
<function name="utl:getCurrentDate">
<className>oracle.xpath.CustomFunction</className>
<return type="string"/>
<params>
<param name="formatMask" type="string"/>
<params>
</function>
<function ...>
. . .
</function>
</functions>

4.3 アプリケーション・サーバーでのXPath/XSL関数のデプロイ

Java XPath関数は、アプリケーション・サーバーに登録する必要があります。これを実行するには、$SOA_HOME/soa/modules/oracle.soa.ext_11.x.x/classes\META-INFにあるext-soa-xpath-functions-config.xmlファイルにエントリを追加します。このファイルには、システムに定義されているすべてのXPath関数のリストと説明が含まれています。

このファイルの各関数エントリの情報は、次のとおりです。

- <function>: XPath関数名を定義する名前属性が含まれます。

- <classname>: XPath実装クラス名を定義します。この場合は、内部クラス名です。

- <return>: 戻りタイプの定義に使用します。

- <params>:

- 関数に必要なすべてのパラメータ。

- <param name="formatMask" type="string"/>

- 渡される各パラメータで、名前と入力のデータ型を指定します。

<function name="utl:getCurrentDate">
<className>oracle.xpath.CustomFunction</className>
<return type="string"/>
<params>
<param name="formatMask" type="string"/>
<params>
</function>

実装クラスは、$SOA_HOME/soa/modules/oracle.soa.ext_11.x.x/classesフォルダに格納する必要があります。このように、これらのクラスは、SOAコンテナのクラスパスに配置され、クラスローダーで使用できます。

5 エンタープライズ・ビジネス・サービスの設計と開発

この章では、エンタープライズ・ビジネス・サービス(EBS)の概要を示し、EBSの設計、プロセスEBS用のWSDLの作成、メッセージ・ルーティングの処理、Oracle Mediatorを使用したEBSの作成、ファイア・アンド・フォーゲット・メッセージ交換パターンの実装、同期リクエスト/レスポンス・メッセージ交換パターンの実装、および非同期リクエスト/遅延レスポンス・メッセージ交換パターンの実装の各方法について説明します。

この章の内容は次のとおりです。

- エンタープライズ・ビジネス・サービスの概要

- EBSの設計

- プロセスEBS用のWSDLの作成

- メッセージ・ルーティングの使用

- Oracle Mediatorを使用したEBSの作成

- ファイア・アンド・フォーゲット・メッセージ交換パターンの実装

- 同期リクエスト/レスポンス・メッセージ交換パターンの実装

- 非同期リクエスト/遅延レスポンス・メッセージ交換パターンの実装

5.1 エンタープライズ・ビジネス・サービスの概要

EBSは、Oracle Application Integration Architecture (AIA)の基礎です。EBSは、アプリケーションまたは実装に依存しない、タスクを実行するためのWebサービス定義を表し、そのアーキテクチャによってEBSを使用した分散処理が促進されます。EBSは自己完結型であるため、他のサービスから独立して使用できます。さらに、別のEBS内で使用できます。

EBSの詳細は、Oracle Application Integration Architecture Foundation Packコンセプトおよびテクノロジ・ガイドのエンタープライズ・ビジネス・サービスの理解に関する項を参照してください。

EBSを作成する必要があるのは、標準モデルを使用した複数のソース・アプリケーションとターゲット・アプリケーション間でビジネス・プロセス統合が実行される場合です。

EBSの目的は、次のとおりです。

- 要求側サービスと提供側サービス間の仲介を提供します。

- リクエスタ・アプリケーション・ビジネス・コネクタ・サービス(ABCS)、EBSまたはエンタープライズ・ビジネス・フロー(EBF)から呼び出される様々な操作を提供します。

- 操作に対する様々なルーティング・ルールの評価に基づいて、適切なEBS、EBFまたはプロバイダABCSに操作をルーティングします。

Oracle AIAでは、EBSの作成に、Oracle SOA Suiteで使用できるメディエータ・テクノロジが利用されます。

EBSは、メディエータ・ルーティング・サービスとして実装されます。メディエータ・サービスには、EBSの複数操作の保持、各操作に対するルーティング・ルールの作成、XSLT変換の実行、および各ルーティング・ルールに対するエンドポイントの定義を実行するための複雑なメカニズムがあります。

Oracleメディエータの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のOracle Mediatorのサービス・コンポーネントの使用方法の部を参照してください。

EBS操作は、同期または非同期のメッセージ交換パターン(MEP)としてモデル化できます。

5.1.1 EBSタイプの理解

EBSのタイプは、次のとおりです。

- ビジネス・アクティビティ
これらは、システム間の相互作用を含む一連のステップがある自立型ビジネス作業単位を表します。これらは、ABCSまたはEBFを介した実装によってメディエータ・サービスとして公開されます。

- タスク
これらは、エンタープライズ・データの集計されたリアルタイムのビューを提供します。これらは主に、エンタープライズ・ビジネス・オブジェクト(EBO)とそのビジネス・コンポーネントを実行対象とする、作成、読取り、更新、削除(CRUD)操作です。これらは、ABCSを介した実装によってメディエータ・サービスとして公開されます。この結果、データ・レベルでのポイントツーポイント・リンク、およびデータソースのデータ・モデルへの直接依存がなくなります。

EBSタイプの詳細は、Oracle Application Integration Architecture Foundation Packコンセプトおよびテクノロジ・ガイドのエンタープライズ・ビジネス・サービスの理解に関する項を参照してください。

5.1.2 エンタープライズ・ビジネス・サービス・ライブラリの使用

SOAコア拡張機能には、EBSライブラリが同梱されています。EBSライブラリは、エンタープライズ・オブジェクト・ライブラリに存在するすべてのEBOに対して提供されたサービス定義で構成されます。これらはWSDLファイルとして提供されています。EBSに存在するサービス操作は通常、CRUD操作およびエンティティに固有のいくつかの操作です。

エンタープライズ・ビジネス・サービス・ライブラリ内のデータ・サービス・タイプのEBS WSDLの操作はすべて、非同期の一方向サービスとしてモデル化されます。唯一の例外は問合せ操作と検証操作です。これらは、名前付きフォルトとともに同期リクエスト/レスポンス操作としてモデル化されます。

- SOAコア拡張機能で提供されている、AIAComponents/EnterpriseServiceLibraryフォルダの下にあるサンプルWSDLを確認できます。

- 新しいサービスまたは操作の作成を決定する前に、各WSDL、その操作の説明およびメタデータを確認してください。

- 作成する新しいEBSは、タイプがアクティビティ・サービスであり、開発中の統合ソリューションの要件を満たす操作を含んでいる必要があります。

- 新しいEBSは、異なるWSDLに配置する必要があり、エンティティEBSのWSDLには追加しないでください。

5.2 EBSの設計

この項には次のトピックが含まれます:

- 設計ガイドラインの理解

- 設計上の考慮事項の理解

- 新規プロセスEBSのMEPの設定

- 新規プロセスEBSのMEPの設定方法

- エラーの処理方法

- EBSの保護方法

- トランザクションの構成方法

- 配信の保証方法

- EBSサービス・コントラクトの定義方法

5.2.1 設計ガイドラインの理解

EBSを設計および実装する手法はコントラクト優先の手法であり、つまり、EBSの実装前にコントラクトが定義および作成されます。EBSのコントラクトは、WSDLドキュメントとして定義されます。

タスクEBSの場合、SOAコア拡張機能のエンタープライズ・サービス・ライブラリからWSDLを使用します。

同期リクエスト/レスポンスMEPをサポートするサービス操作は、1つのポート・タイプで定義します。操作には、入力、出力およびフォルト・メッセージが定義されている必要があります。

ファイア・アンド・フォーゲットMEPをサポートするサービス操作は、1つのポート・タイプで定義し、操作に入力メッセージが定義されている必要があります。

非同期リクエスト/遅延レスポンス・パターンをサポートするサービス操作には2つの操作が必要であり、1つはリクエスト・メッセージを送信する操作、もう1つはレスポンス・メッセージを処理する操作です。これらの2つの操作それぞれに入力メッセージが必要です。2つの異なるportTypeが、各操作に対して1つずつ存在します。レスポンス・メッセージを処理するサービス操作は、接尾辞がResponseのポート・タイプに存在する必要があります。

EBS WSDLには2種類のportTypeが必要です。

- 同期リクエスト/レスポンス操作およびリクエストのみの操作をモデル化するために使用するすべての操作用のportType。名前にRequestは指定しません。

- 非同期レスポンス操作用のportType。名前にResponseを指定します。

各portTypeに対して2つのメディエータ・ルーティング・サービスを作成する必要があります。

5.2.2 設計上の考慮事項の理解

EBSを設計する際は、次の事項を考慮してください。

- サービスの目的

- 企業では特定のビジネス機能に対してEBSを1つのみ設定する必要があり、そのEBSはいずれのアプリケーションにも依存しない必要があります。

- サービスで、EBS WSDLに定義された複数のビジネス操作を実装できます。

- ビジネス・オブジェクトに対するすべてのビジネス操作の実装が必要です。

- サービスにレスポンス操作も含まれている必要があり、これは非同期リクエスト/レスポンス・パターンに必要です。

- サービスの呼出し方法

- サービスは、HTTPトランスポートを使用してWebサービスとして呼び出されます。

- コール側のクライアントがこのサービスと同じ場所にある場合、パフォーマンスの改善およびトランザクションの伝播のために、最適化されたバインディングを使用したローカル呼出しになるようにコールを構成できます。

- サービスの呼出し元

- アプリケーションでエンタープライズ・ビジネス・メッセージ(EBM)を送信でき、リクエスタABCSのすべての機能を実行できる場合に、サービスをアプリケーションによって呼び出すことができます。

- アプリケーションにこのサービスを直接呼び出す機能がない場合は、リクエスタABCSによってこのサービスが呼び出されます。

- 複数ビジネス・オブジェクト全体を編成するEBFフローでこのサービスを呼び出すこともできます。

- アプリケーションとの相互作用方法

- アプリケーションでEBMメッセージを受信できる場合は、EBSで、HTTPを使用してアプリケーションをWebサービス・コールとしてコールできます。

- そうでない場合は、プロバイダABCSを作成してコールする必要があります。

- クライアントとEBS間の相互作用のタイプ

- クライアントは、3つのMEPのいずれかを使用してEBSをコールできます。

5.2.3 新規プロセスEBSのMEPの設定

EBSライブラリのエンティティEBSのWSDLに対するMEPは事前定義されているため、プロセスEBSのWSDLを設計する必要があります。EBSは、複数の操作を含むようにモデル化されています。各操作では、特定のビジネス・シナリオ要件に対するEBSが実行され、実質的に粒度が細かくなっています。したがって、各操作は、異なる相互作用スタイルまたはパターンをサポートするようにモデル化できます。

図5-1に、EBSパターンの設定における決定ポイントを示します。

図5-1 EBS操作の相互作用パターンの識別

EBSタイプの詳細は、Oracle Application Integration Architecture Foundation Packコンセプトおよびテクノロジ・ガイドのエンタープライズ・ビジネス・サービスの理解に関する項を参照してください。

5.2.4 新規プロセスEBSのMEPの設定方法

新規プロセスEBSのMEPを設定する手順は、次のとおりです。

1. 機能設計からのビジネス・プロセス要件を理解して、EBS操作のトリガー・イベントを識別します。

2. レスポンスが呼出しポイントに戻るまで制御がブロックされる場合は、EBSリクエスト/リプライ・パターンを選択します。

これは同期コールです。この場合、EBS操作には、名前付きフォルトとともに入力メッセージと出力メッセージが含まれます。

3. EBSの呼出し後、トリガー・ポイントがレスポンスを待機せずに続行した場合、このEBSの呼出しは非同期コールになります。

4. 次に、EBSの実行によってレスポンスが返されるかどうかを確認します。

リクエストとレスポンスを相互に関連付ける必要があるかを検討します。答えが「はい」の場合、これは遅延レスポンスです。EBSリクエスト/遅延レスポンス・パターンを使用します。この場合、EBSには2つのportTypeがあり、それぞれが入力メッセージのみを受け入れ、それぞれが異なるポートに属します。

答えがいいえの場合は、EBSファイア・アンド・フォーゲット・パターンを選択します。この場合、EBS操作には入力メッセージのみが含まれます。

5.2.5 エラーの処理方法

EBSは、エラーを再スローして呼出し元クライアントに戻すように構成する必要があります。アプリケーション・エラー処理機能が、統合プラットフォームのエラー処理機能と一致していることを確認します。

エラー処理の詳細は、「エラー処理およびトレース・ロギング用のOracle AIAプロセスの構成」を参照してください。

5.2.6 EBSの保護方法

呼出し元クライアント(リクエスタABCSまたはアプリケーション)がリモートの場合、EBSは、セキュリティの章の説明に従ってセキュリティに対応する必要があります。

セキュリティの詳細は、「セキュリティに関する作業」を参照してください。

EBSの詳細は、Oracle Application Integration Architecture Foundation Packコンセプトおよびテクノロジ・ガイドのエンタープライズ・ビジネス・サービスの理解に関する項を参照してください。

5.2.7 トランザクションの構成方法

Oracle Fusion MiddlewareのSOAトランザクション・セマンティクスに基づいて、ABCS、EBSおよびEBF全体でトランザクションを設計および構成できます。

詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』を参照してください。

5.2.8 配信の保証方法

メッセージ配信を保証する方法の詳細は、「保証付きメッセージ配信」を参照してください。

5.2.9 EBSサービス・コントラクトの定義方法

EBSサービス・コントラクトを定義する手順は、次のとおりです。

1. EBSおよびEBSでサポートする必要がある操作を識別します。

2. EBSの各操作の相互作用パターンを識別します。

3. 各操作に関連するリクエストとレスポンス(ある場合)に使用するEBMを識別します。

5.3 プロセスEBS用のWSDLの作成

この項には次のトピックが含まれます:

- アクティビティ・サービスEBS用のWSDL作成の概要

- <definitions>セクションの完了方法

- メッセージ構造の定義方法

- WS-I基本プロファイル準拠の確認方法

これらの項では、WSDLの各セクションの入力方法について説明します。

5.3.1 アクティビティ・サービスEBS用のWSDL作成の概要

WSDLを作成する際は、次のことを考慮します。

- OracleのJDeveloperおよびテキスト編集ツールをWSDLの作成に使用できます。

- EBO用のEBMスキーマ・モジュールをWSDLで参照する必要があります。

- WSDLでは、中央の場所で管理されているスキーマ・モジュールを参照する必要があります。

- 「AIA開発でのOracle AIAネーミング標準」の説明に従って、サービス、ターゲット・ネームスペース、メッセージ、操作、ポート・タイプなどを作成するための命名規則に従う必要があります。

5.3.2 <definitions>セクションの完了方法

<definitions>セクションを完了する手順は、次のとおりです。

1. 名前:

サービスには、作成と保守に関連する操作、およびEBOで実行されるアクションが含まれます。

2. ネームスペース

このネームスペースをターゲット・ネームスペースとしてマークします。

3. ネームスペース接頭辞

新たに識別したネームスペースに対するネームスペース接頭辞を定義します。

- wsdlは、デフォルト・ネームスペースのネームスペース接頭辞です。

- xsdは、XMLSchemaのネームスペース接頭辞です。

- soapは、SOAPネームスペースのネームスペース接頭辞です。

ネームスペース接頭辞は、EBOに対して定義する必要があります。ネームスペース接頭辞は、提供されているEBOのEBS WSDLと同じである必要があります。

5.3.3 メッセージ構造の定義方法

WSDLタイプ・セクションのメッセージ構造を定義する手順は、次のとおりです。

1. 関連EBMがすべて定義されている適切なスキーマをインポートします。

2. xsd:importを使用して、スキーマから要素をインポートします。

xsd:import要素のネームスペース属性が、インポートするスキーマ・ドキュメントに対するターゲット・ネームスペースと同じであることを確認します。

また、インポートしたスキーマ内の要素をネームスペース接頭辞を使用して参照できるように、ネームスペース接頭辞がそのネームスペースに対して宣言されていることも確認してください。

3. xsd:schema要素の属性targetNamespaceは、このWSDLのtargetNamespaceと同じである必要があります。

メッセージ定義

それぞれの操作に対して、選択したパターンに応じて、リクエストを送信するためのメッセージ、およびレスポンスを受信するための別のメッセージ(オプション)を作成する必要があります。

- リクエストを送信するためのメッセージは、ReqMsgが続く操作と同じである必要があります。

- レスポンス・メッセージは、RespMsgが続く操作と同じである必要があります。

portType定義

各操作のportType名を定義する必要があり、それはサービス名と同じである必要があります。パターンに基づいて、メッセージ定義セクションに、入力および出力要素に指定されるメッセージ名を定義しました。サービスがデプロイされると、メディエータによって、サービスがポート・タイプに追加され、具象WSDLのサービス・セクションに挿入されるサービス名が形成されます。

サービス・インタフェースの注釈付け

WSDLの各セクションで、セクションの詳細に注釈を付けることができるドキュメンテーションが許可されます。WSDL作成者は、セクション全体に、既存のEBS WSDLに注釈を付ける方法と同じように注釈を付ける必要があります。

5.3.4 WS-I基本プロファイル準拠の確認方法

WS-I基本プロファイルは、非独占のWebサービス仕様のセットで構成され、相互運用性を促進する仕様の明確化、改善、解釈および拡充を伴います。

プロファイルへの準拠は、プロファイルの範囲内で特定のターゲットに対する要件のセットを厳守することで定義されます。

5.4 メッセージ・ルーティングの使用

この項には次のトピックが含まれます:

- ルーティング・ルールの作成

- EBSでのルーティング

- EBSルーティング・ルールに関するガイドライン

- EBSでのターゲット・システムの識別方法

5.4.1 ルーティング・ルールの作成

EBSルーティング・サービス操作のルーティング・ルールは、受信メッセージをルーティングするターゲット・エンド・ポイントを決定するために使用されます。

ルーティング・ルールを作成する際は、次のガイドラインに従います。

- ルーティング・ルールは、第一に機能に関して、さらに常に特定の統合トポロジを考慮して定義する必要があります。

- ほとんどの場合、ルーティング・ロジックをEBSのルーティング・ルールで実行する必要があります。

ただし、EBSのすべてのルーティング・ルールで、ヘッダーにスタンプされた既存のターゲット・システムIDを確認し、優先する必要があります。EBSルールでは、ターゲット・システムIDが入力されることは想定しないでください。

- リクエスタABCSでは、ターゲット・システムの決定、またはEBMヘッダーのターゲット・システムIDのスタンプは実行しないでください。

- いずれのEBS操作でも、考えられる各ターゲット・アプリケーション・システム・インスタンスにルーティング・ルールが必要です。
たとえば、SEBL_01とSEBL_02の2つのSiebelプロバイダ・アプリケーション・システム・インスタンスが存在する場合は、両方のルールが同じSiebelプロバイダABCSをターゲットとしている場合でも、それぞれにルーティング・ルールが必要です。

別の方法として、機能要件で、アプリケーション・タイプの単一のインスタンスのみが実行時にメッセージを受信できることを指定した場合は、単一のルールを使用でき、実行時に使用される1つのインスタンスのIDをスタンプするためにXSLTが呼び出されます。

EBS操作に同じアプリケーション・タイプの複数のプロバイダ・アプリケーション・システム・インスタンス(SEBL_01とSEBL_02など)がある場合は、各インスタンスのルーティング・ルールでは、複数インスタンス間で共有されるプロバイダABCSが、呼び出して相互参照するインスタンスを識別できるように、XSLTによってEBMヘッダーに適切なシステム・インスタンスIDをスタンプする必要があります。

- EBS操作が同期リクエスト/リプライ・パターンまたは非同期リクエスト/遅延レスポンス・パターンである場合、ルーティング・ルールは、Oracle AIAシステムの実際のトポロジでは相互に排他的である必要があります。

- ルーティング・ルールは、メディエータ・ルーティング・サービスの一部として、事前作成済の統合とともに提供されます。
これらのルールは、提供されているトポロジに対して機能するように設計されています。システム・インスタンスの追加など、提供されているトポロジに対する変更を実装する場合は、ルーティング・ルールの独自の完全なセットを実装する必要があります。

標準のルーティング・ルール句の構造は、次のとおりです。

(cavs_check)および(ruleset_check)および((target_system_identified_check)または((target_system_absent_check)および(topology_specific_clauses))

表5-1に、ルーティング・ルール句および関連XPath式を示します。

表5-1 ルーティング・ルール句

句

XPath式

cavs_check) =

MessageProcessingInstruction/EnvironmentCode='PRODUCTION' or
not(MessageProcessingInstruction/EnvironmentCode/text()))

ruleset_check) =

TBD

target_system_identified_check) =

EBMHeader/Target/ApplicationTypeCode='SIEBEL'

target_system_absent_check) =

not(EBMHeader/Target/ID/text())

O2C2 OOTB (topology_specific_clauses) =

aia:getSystemType(EBMHeader/Sender/ID)!='SIEBEL'

表5-2に、統合済サプライ・チェーン管理の事前作成済の統合の一部として提供されているルーティング・ルールをいくつか示します。

表5-2 提供されているルーティング・ルール

ターゲット

SiebelプロバイダABCS

XPath Filter:

(MessageProcessingInstruction/EnvironmentCode='PRODUCTION' or
not(MessageProcessingInstruction/EnvironmentCode/text(
)))and (EBMHeader/Target/ApplicationTypeCode='SIEBEL'
or ( not(EBMHeader/Target/ID/text()) and
aia:getSystemType(EBMHeader/Sender/ID)!='SIEBEL' ) )

変換:

なし

説明:

MessageProcessingInstruction/EnvironmentCode='PRODUCTION'またはまったく指定されていないこと、かつターゲット・アプリケーション・タイプはSiebelが指定されているか、またはターゲットが指定されていないこと、かつ送信側アプリケーション・タイプがSiebelではないこと。

ターゲット:

Oracle EBusinessプロバイダABCS

XPath Filter:

(MessageProcessingInstruction/EnvironmentCode='PRODUCTION' or
not(MessageProcessingInstruction/EnvironmentCode/
text())) and ( EBMHeader/Target/
ApplicationTypeCode='EBIZ' or (
not(EBMHeader/Target/ID/text()) and
aia:getSystemType(EBMHeader/Sender/ID)!='EBIZ' ) )

変換:

なし

説明:

MessageProcessingInstruction/EnvironmentCode='PRODUCTION'またはまったく指定されていないこと、かつターゲット・アプリケーション・タイプはEBizが指定されているか、またはターゲットが指定されていないこと、かつ送信側アプリケーション・タイプがEBizではないこと。

ターゲット:

CAVS

XPath Filter:

MessageProcessingInstruction/EnvironmentCode='CAVS'

変換:

なし

説明:

MessageProcessingInstruction/EnvironmentCode='CAVS'

5.4.2 EBSでのルーティング

ルーティング・ルールは、EBSサービスで定義された各操作に対して指定されます。システムでは、ルーティング・ルールを使用して、受信EBMのルーティング先をEBF、EBS、ABCSまたはコンポジット・アプリケーション検証システム(CAVS)のいずれにするかが決定されます。ルーティング・ルールは、メディエータ・ルーティング・ルールのフィルタで、XPath式として指定されます。

すべてのルールが評価されて、ルール評価に基づいてメッセージがエンド・ポイントにルーティングされるため、ルーティング・ルールは相互に排他的である必要があります。

5.4.3 EBSルーティング・ルールに関するガイドライン

最低でも、各EBS操作にこれらのルールが必要です。

- CAVS対応用の1つのルーティング・ルール。
このルールでは、EBMヘッダー→MessageProcessingInstruction→EnvironmentCodeがCAVSに設定されているかどうかを確認する必要があります。

- プロバイダABCSまたはEBFに接続するための1つ以上のルーティング・ルール。
これらのルーティング・ルールに指定されたフィルタ式で、メッセージがテスト・メッセージではないことを保証する必要があります。

各ABCSまたはEBFに対して、1つのルーティング・ルールが存在します。条件は次のいずれかです。

- EBMヘッダーに入力されたターゲット・システムABCS
ターゲット・システムABCSを決定するためのSalesOrderEBSルーティング・ルールのフィルタ式の例は、次のとおりです。

この場合、フィルタには、EBMヘッダーのターゲット・システムABCSが事前に入力されていて、「ルーティングのオーバーライド」インディケータが「False」に設定されているかどうかを確認する式があります。

/sordebo:QuerySalesOrderEBM/ns5:EBMHeader/ns5:Target/ns5:ID = "SEBL78_01" and
/sordebo: Query SalesOrderEBM/ns5:EBMHeader/ns5:Target/ns5: Override
RoutingIndicator = "false"

- コンテンツベース・ルーティング
この場合、ターゲット・システムABCSを決定するためにEBMのコンテンツが評価されます。フィルタ式で、ターゲット・システムの情報がEBMヘッダーに事前入力されなかったことを確認する必要があります。

式の例:

starts-with(/sordebo: CreateSalesOrderEBM
/sordebo: DataArea/sordebo: CreateSalesOrder/sordebo: SalesOrderLine
/sordebo:SalesOrderLineSchedule/ns5:ShipToPartyReference
/ns5:LocationReference
/ns5:Address/ns5:CountrySubDivisionCode,'9') and
/sordebo:CreateSalesOrderEBM/ns5:EBMHeader /ns5:Target/ns5:ID = ""

- パラレル・ルーティング
各ターゲット・サービスでその独自のトランザクションを呼び出し、ターゲット・サービスを再試行する場合は、EBSでパラレル・ルーティングを使用する必要があります。

詳細は、「アプリケーション・ビジネス・コネクタ・サービスの設計」を参照してください。

- エラー処理およびロギングの有効化
EBSでは、クライアントまたは管理者が中央のエラー・ハンドラを介してプロセスを再発行または再トリガーできるようにエラーを処理する必要があります。

詳細は、「エラー処理およびトレース・ロギング用のOracle AIAプロセスの構成」を参照してください。

5.4.4 EBSでのターゲット・システムの識別方法

EBSでは、リクエスタABCS、EBFまたは別のEBSのリクエストを、使用可能な多数のプロバイダABCSのいずれかにルーティングできます。ターゲット・システムを識別する必要があるのは、作成操作の場合のみです。他のすべての操作については、Xref関数lookupPopulatedColumnsを使用して、エンティティのデータの同期が完了しているシステムが識別されます。次に示したステップを組み合せると、適切なABCSになります。

EBSでターゲット・システムを識別する手順は、次のとおりです。

1. コンテンツベース・ルーティングの使用。
EBSのルーティング・ルールはメッセージのコンテンツに基づき、ターゲットABCSの決定に使用されます。これは、作成操作の場合のみ使用されます。これは、EBMヘッダーのターゲット・システム情報が空で、まだ設定されていない場合です。

ターゲット・システムは、決定するとEBMヘッダーに設定されます。この情報は、後続のすべてのサービス(他のEBSまたはABCSなど)で使用されます。

2. EBMヘッダーのターゲット・システム情報の使用。
ターゲット・システム情報がEBMに設定されている場合は、これが適切なABCSへのルーティングに使用されます。

3. 作成以外の操作の場合はXREFを使用。
作成以外のすべての操作では、ターゲット・システムは決定されていて、相互参照IDが設定されています。この場合、XREF関数lookupPopulatedColumnsを使用して、エンティティのデータの同期が完了しているシステムが識別されます。

5.5 Oracle Mediatorを使用したEBSの作成

Oracle Mediatorコンポーネントを使用すると、EBSコンポジットにコンポーネントを作成できます。

Oracle AIAでは、EBSサービスの開発に任意のテクノロジを使用できますが、ほとんどの場合メディエータを使用します。

5.5.1 Oracle Mediatorサービスの開発方法

Oracle Mediatorサービスを開発する手順は、次のとおりです。

1. JDeveloperで、SOAコンポジット・プロジェクトを作成します。

2. 設計モードでcomposite.xmlを開きます。

3. メディエータ・コンポーネントを「コンポーネント」スイムレーンに追加します。

4. Webサービスを外部参照サービスとして「参照」スイムレーンに追加します。

この参照サービスは、プロバイダABCSを表すことができます。

プロバイダABCSの具象WSDLを使用する必要があります。つまり、外部参照として参照されているサービスを事前デプロイする必要があります。

5. メディエータ・コンポーネントを、ステップ4で作成した外部参照コンポーネントに接続します。

6. メディエータ・コンポーネントを開き、ルーティング・ルールを構成します。

7. 図5-2に示すように、入力変数を出力変数にコピーして割当を作成します。

図5-2 割当の作成

5.6 ファイア・アンド・フォーゲット・メッセージ交換パターンの実装

両方の非同期MEP (ファイア・アンド・フォーゲットとリクエスト/遅延レスポンス)を実装するには、EBS WSDLを作成した後、MEPに応じて1つまたは2つのメディエータ・ルーティング・サービスを作成する必要があります。次に、それぞれのMEPに対するガイドラインに従って、リクエスタ・サービスとプロバイダ・サービスを実装します。

要求側サービスは、リクエスタABCS (BPELプロセス)、EBF (BPELプロセス)または参加アプリケーションです。

提供側サービスは、プロバイダABCS (BPELプロセス)、EBF (BPELプロセス)または参加アプリケーションです。

この項には次のトピックが含まれます:

- EBSの一方向コールを使用したファイア・アンド・フォーゲット・パターンの実装方法

- EBS WSDLの作成

- 一方向コールEBSを使用した非同期ファイア・アンド・フォーゲット・パターンに対するメディエータ・ルーティング・サービスの作成

- 補正操作を使用した非同期ファイア・アンド・フォーゲットMEPのエラー処理

- EBSの補正操作の呼出し方法

- 補正操作ルーティング・サービスのルーティング・ルールの有効化方法

5.6.1 EBSの一方向コールを使用したファイア・アンド・フォーゲット・パターンの実装方法

ファイア・アンド・フォーゲット・パターンのイニシエータは、レスポンスを待機または予測しない要求側サービスです。要求側サービスは、参加アプリケーション、リクエスタABCS ImplまたはEBFです。これらのそれぞれの場合で、リクエスト・ペイロードはEBMリクエストである必要があります。

ABCS (リクエスタとプロバイダの両方)の有効化の詳細は、「アプリケーション・ビジネス・コネクタ・サービスの設計」、「ABCSの作成」および「ABCS開発の完了」を参照してください。

EBFの有効化の詳細は、「エンタープライズ・ビジネス・フローの設計と作成」を参照してください。

EBSの一方向コールを使用したファイア・アンド・フォーゲット・パターンを実装する手順は、次のとおりです。

1. EBS WSDLを作成します。

2. 一方向コールEBSを使用した非同期ファイア・アンド・フォーゲット・パターンに対するメディエータ・ルーティング・サービスを作成します。

3. 要求側サービスのリクエストを、リクエストEBSの一方向コール操作のルーティング・サービスにおける適切な提供側サービスにルーティングします。

4. フォルト・ポリシーに基づいて、ロギングおよび通知用のエラー処理を実装します。

注意:

これらのステップは、要求側サービスと提供側サービスに必要な通常のステップに追加します。

5.6.2 EBS WSDLの作成

エンティティEBSの場合、SOAコア拡張機能のエンタープライズ・サービス・ライブラリからWSDLを使用します。

- 同期リクエスト/レスポンスMEPをサポートするサービス操作は、1つのポートタイプで定義し、操作で入力、出力およびフォルト・メッセージが定義されている必要があります。

- ファイア・アンド・フォーゲットMEPをサポートするサービス操作は、1つのポート・タイプで定義し、操作で入力メッセージが設定されている必要があります。

- 非同期リクエスト/レスポンス・パターンをサポートするサービス操作には2つの操作が必要であり、1つはリクエスト・メッセージを送信する操作、もう1つはレスポンス・メッセージを処理する操作です。
これらの2つの操作それぞれで独立した入力メッセージが設定される必要があります。各操作に1つずつ、2つの異なるportTypeが必要です。レスポンス・メッセージを処理するサービス操作は、接尾辞がResponseのportTypeに存在する必要があります。

- EBS WSDLには2つのportTypeが必要です。

- 同期リクエスト、レスポンス操作およびリクエストのみの操作をモデル化するために使用するすべての操作用のportType。名前にRequestは指定しないでください。

- 非同期レスポンス操作用のportType。名前にResponseを指定する必要があります。

- 2つのメディエータ・ルーティング・サービスを各portTypeに対して作成する必要があります。

5.6.3 一方向コールEBSを使用した非同期ファイア・アンド・フォーゲット・パターンに対するメディエータ・ルーティング・サービスの作成

一方向コールEBSを使用した非同期ファイア・アンド・フォーゲット・パターンに対するメディエータ・ルーティング・サービスを作成する手順は、次のとおりです。

1. メディエータ・プロジェクトを作成します。

2. ルーティング・サービスを作成します。

3. ルーティング・ルールを作成します。

4. エラー処理を実装します。

5.6.3.1 非同期ファイア・アンド・フォーゲットMEPのメディエータ・プロジェクトの作成方法

非同期ファイア・アンド・フォーゲットMEPのメディエータ・プロジェクトを作成する手順は、次のとおりです。

1. EBS WSDLの各portTypeに対して1つずつ、2つのメディエータ・プロジェクトを作成します。

EBSに対するすべてのサービス操作に同期リクエスト/レスポンスまたはファイア・アンド・フォーゲット・パターンが設定されている場合、これらの操作はすべて、1つのportTypeにのみ存在する必要があるため、メディエータ・ルーティング・サービスは1つのみ存在します。

EBSに1つ以上の非同期リクエスト/レスポンス操作がある場合は、2つのポート・タイプが必要であり、2つのメディエータ・ルーティング・サービスと2つのメディエータ・プロジェクト(各ルーティング・サービスに1つずつ)が存在します。

2. 付録「Oracle AIAネーミング標準」に記載されている命名規則に従います。

メディエータ・プロジェクトの一般的な名前の例は、次のとおりです。

- CustomerPartyEBSV2 (これには、同期リクエスト/レスポンスとリクエストのみに対するすべての操作を含むルーティング・サービスがあります。)

- CustomerPartyEBSResponseV2 (これには、非同期リクエスト/レスポンスに対するすべての操作を含むルーティング・サービスがあります。)

5.6.3.2 非同期ファイア・アンド・フォーゲットMEPのルーティング・サービスの作成方法

非同期ファイア・アンド・フォーゲットMEPのルーティング・サービスを作成する手順は、次のとおりです。

1. EBS WSDLをメディエータ・プロジェクト・フォルダに配置します。

2. ルーティング・サービスを作成し、「AIA開発でのOracle AIAネーミング標準」に記載されている命名規則に従って名前を付けます。

3. WSDLを選択します。

WSDLを解析し、portType名をルーティング・サービスのportTypeフィールドに入力する必要があります。

4. ルーティング・サービスと一致するportTypeを選択します。ルーティング・サービスを保存します。

あるportType用に作成したルーティング・サービスには、EBS WSDLでそのportTypeに指定したすべての操作が設定されている必要があります。

5.6.3.3 非同期ファイア・アンド・フォーゲットMEPのルーティング・ルールの作成方法

リクエストEBSのルーティング・ルールは、同期リクエスト/レスポンス・セクションに対するルーティング・ルールと同じです。

詳細は、「同期リクエスト/レスポンスMEPのルーティング・サービスの作成方法」を参照してください。

5.6.3.4 非同期ファイア・アンド・フォーゲットMEPのエラー処理の実装方法

詳細は、「エラー処理およびトレース・ロギング用のOracle AIAプロセスの構成」を参照してください。

5.6.4 補正操作を使用した非同期ファイア・アンド・フォーゲットMEPのエラー処理

提供側サービスのエラーの影響を相殺するために、一方向コールの要求側サービスで補正をトリガーする操作をEBSに追加できます。これは、EBSに補正操作を設定することによって実行できます。

一方向コールとしてモデル化される補正操作は、独立した操作です。リクエストportTypeのリクエストのみの各操作には、補正をトリガーするための操作が必要です。

例: CompensateCreateCustomer、CompensateCreateOrder。

補正操作は、ビジネス例外によって回復不能なエラーが発生する可能性が高い場合に呼び出されます。従来の再試行および再発行ができず、要求側サービスで訂正が実行される必要があります。

この状況では、参加アプリケーションの補正アクションWebサービスまたはAPIを利用する、適切な補正を実装する必要があります。

5.6.5 EBSの補正操作の呼出し方法

エラー処理では、一部のエラーに対して補正アクションが実行されて、EBSの補正操作が提供側サービスから呼び出されることを保証する必要があります。EBSの補正操作は、適切な補正サービスにルーティングされます。

EBSの補正操作を呼び出す手順は、次のとおりです。

1. 提供側サービスのエラーの場合、例外が発生し、それがcatchブロックで捕捉されます。

2. catchブロックで、リクエストEBMをEBMヘッダーのフォルト・コンポーネントとともに作成します。

3. 変換ステップを作成し、リクエストEBMを表す入力変数、およびリクエストEBMを表す補正変数を選択します。

4. 例外が生成されたときに、例外の詳細を変数に取り込み、それを補正XSLTの入力として渡します。

5. 次を補正変数にマップします。

- リクエストEBMからの標準のEBMヘッダー・コンテンツ

- リクエストEBMからのデータ・エリア

- フォルト・メッセージ

6. リクエストEBSルーティング・サービスに、対応する補正操作を呼び出すInvokeCompensateステップを設定します。

7. 補正リクエストを適切な補正サービスにルーティングします。

図5-3に、補正操作を含むファイア・アンド・フォーゲット・パターンを示します。

図5-3 補正操作を含むファイア・アンド・フォーゲット・パターン

5.6.6 補正操作ルーティング・サービスのルーティング・ルールの有効化方法

2つのルーティング・ルールが必要です。

補正操作ルーティング・サービスのルーティング・ルールを有効化する手順は、次のとおりです。

1. EBSの補正操作に対するルーティング・ルール。
要求側サービスの<EBO Name>ResponseEBM\corecom:EBMHeader\Sender\ WSAddress/ WSAddress/wsa:FaultTo/wsa:ServiceNameに入力された情報は、補正のリクエストを、EBSの補正操作の適切な補正サービスにルーティングするために使用されます。

このルーティング・ルールをEBSの補正操作に含めます。

<EBO Name>ResponseEBM\corecom:EBMHeader\Sender\ WSAddress/
WSAddress/wsa:FaultTo/wsa:ServiceName = <Compensating Service Name>

2. CAVSに対するルーティング・ルール。
CAVSで作成したテスト・ケースのタイプが非同期遅延レスポンスである場合は、レスポンス・メッセージをCAVSエンドポイントに移動して、テストに合格/失敗するように相関付けることができます。これが発生するには、CAVSシステム・エンドポイントに対する明示的なinvokeが存在する必要があります: http://host:port/AIAValidationSystemServlet/asyncresponserecipient。

5.7 同期リクエスト/レスポンス・メッセージ交換パターンの実装

同期リクエスト/リプライ・パターンのイニシエータは、レスポンスを待機および予測する要求側サービスです。要求側サービスは、参加アプリケーション、リクエスタABCS ImplまたはEBFです。これらのそれぞれの場合で、リクエスト・ペイロードはEBMリクエストで、レスポンス・ペイロードはEBMレスポンスです。

この項には次のトピックが含まれます:

- EBSでの同期リクエスト/リプライ・メッセージ交換パターンの実装方法

- 同期リクエスト/レスポンスMEPのメディエータ・プロジェクトの作成方法

- 同期リクエスト/レスポンスMEPのルーティング・サービスの作成方法

- 同期リクエスト/レスポンスMEPのエラー処理の実装方法

ABCS (リクエスタとプロバイダの両方)の有効化の詳細は、「アプリケーション・ビジネス・コネクタ・サービスの設計」、「ABCSの作成」および「ABCS開発の完了」を参照してください。

EBFの有効化の詳細は、「エンタープライズ・ビジネス・フローの設計と作成」を参照してください。

5.7.1 EBSでの同期リクエスト/リプライ・メッセージ交換パターンの実装方法

EBSで同期リクエスト/リプライMEPを実装する手順は、次のとおりです。

1. ルーティング・サービスを含むメディエータ・プロジェクトを作成します。

2. 要求側サービスのリクエストを、EBSのルーティング・サービスの適切な提供側サービスにルーティングするルーティング・ルールを作成します。

3. フォルト・ポリシーに基づいて、ロギングおよび通知用のエラー処理を実装します。

5.7.2 同期リクエスト/レスポンスMEPのメディエータ・プロジェクトの作成方法

同期リクエスト/レスポンスMEPのメディエータ・プロジェクトを作成する手順は、次のとおりです。

メディエータ・プロジェクトを作成する際は、次のガイドラインに従います。

1. EBS WSDLの各portTypeに対して1つずつ、2つのメディエータ・プロジェクトを作成します。

EBSに対するすべてのサービス操作に同期リクエスト/レスポンスまたはファイア・アンド・フォーゲット・パターンが設定されている場合、これらの操作はすべて、1つのportTypeにのみ存在する必要があるため、メディエータ・ルーティング・サービスは1つのみ存在します。

EBSに1つ以上の非同期リクエスト/レスポンス操作がある場合は、2つのportTypeが存在する必要があり、2つのメディエータ・ルーティング・サービスと2つのメディエータ・プロジェクト(各ルーティング・サービスに1つずつ)が存在します。

2. 「AIA開発でのOracle AIAネーミング標準」に記載されている命名規則に従います。

メディエータ・プロジェクトの一般的な名前の例は、次のとおりです。

- CustomerPartyEBSV2 (この例には、同期リクエスト/レスポンスとリクエストのみに対するすべての操作を含むルーティング・サービスがあります。)

- CustomerPartyEBSResponseV2 (この例には、非同期リクエスト/レスポンスに対するすべての操作を含むルーティング・サービスがあります。)

5.7.3 同期リクエスト/レスポンスMEPのルーティング・サービスの作成方法

同期リクエスト/レスポンスMEPのルーティング・サービスを作成する手順は、次のとおりです。

1. JDeveloperで、EBS WSDLをメディエータ・プロジェクト・フォルダに配置します。

2. ルーティング・サービスを作成し、「AIA開発でのOracle AIAネーミング標準」に記載されている命名規則に従って名前を付けます。

3. WSDLを選択します。WSDLを解析し、portType名をルーティング・サービスのportTypeフィールドに入力する必要があります。

4. ルーティング・サービスと一致するportTypeを選択します。ルーティング・サービスを保存します。

あるportType用に作成したルーティング・サービスには、EBS WSDLでそのportTypeに指定したすべての操作が設定されている必要があります。

5.7.4 同期リクエスト/レスポンスMEPのエラー処理の実装方法

詳細は、「エラー処理およびトレース・ロギング用のOracle AIAプロセスの構成」を参照してください。

5.8 非同期リクエスト/遅延レスポンス・メッセージ交換パターンの実装

リクエスト/遅延レスポンス・パターンのイニシエータは、リクエストEBSを呼び出し、レスポンスを待機する要求側サービスです。要求側サービスは、参加アプリケーション、リクエスタABCS ImplまたはEBFです。これらのそれぞれの場合で、リクエスト・ペイロードはEBMリクエストで、レスポンス・ペイロードはEBMレスポンスです。

提供側サービスのエラーの場合、エラー情報を含むレスポンス・メッセージが作成され、処理のために要求側サービスに返されます。

この項には次のトピックが含まれます:

- EBSの2つの一方向コールを使用したリクエスト/遅延レスポンス・パターンの実装方法

- 2つの一方向コールEBSを使用した非同期リクエスト/遅延レスポンス・パターンに対するメディエータ・ルーティング・サービスの作成

- 非同期リクエスト/遅延レスポンスMEPのエラー処理

ABCS (リクエスタとプロバイダの両方)の有効化の詳細は、「アプリケーション・ビジネス・コネクタ・サービスの設計」、「ABCSの作成」および「ABCS開発の完了」を参照してください。

EBFの有効化の詳細は、「エンタープライズ・ビジネス・フローの設計と作成」を参照してください。

5.8.1 EBSの2つの一方向コールを使用したリクエスト/遅延レスポンス・パターンの実装方法

EBSの2つの一方向コールを使用したリクエスト/遅延レスポンス・パターンを実装する手順は、次のとおりです。

注意:

要求側サービスと提供側サービスに必要な通常のステップに加えて、これらのステップを実行します。

1. EBS WSDLを作成します。

2. 2つの一方向コールEBSを使用した非同期リクエスト/遅延レスポンス・パターンに対するメディエータ・ルーティング・サービスを作成します。

3. 要求側サービスのリクエストを、リクエストEBSの一方向コール操作のルーティング・サービスの適切な提供側サービスにルーティングします。

4. フォルト・ポリシーに基づいて、ロギングおよび通知用のエラー処理を実装します。

5. EBSレスポンスのレスポンス・メッセージを適切な要求側サービスにルーティングします。

図5-4に、リクエスト/遅延レスポンス・パターンを示します。

図5-4 リクエスト/遅延レスポンス・パターン

5.8.2 2つの一方向コールEBSを使用した非同期リクエスト/遅延レスポンス・パターンに対するメディエータ・ルーティング・サービスの作成

メディエータ・ルーティング・アーキテクチャを作成する手順は、次のとおりです。

1. メディエータ・プロジェクトを作成します。

2. ルーティング・サービスを作成します。

3. ルーティング・ルールを作成します。

5.8.2.1 リクエスト/遅延レスポンスMEPのメディエータ・プロジェクトの作成方法

リクエスト/遅延レスポンスMEPのメディエータ・プロジェクトを作成する手順は、次のとおりです。

1. EBS WSDLの各portTypeに対して1つずつ、2つのメディエータ・プロジェクトを作成します。

EBSに対するすべてのサービス操作に同期リクエスト/レスポンスまたはファイア・アンド・フォーゲット・パターンが設定されている場合、これらの操作はすべて、1つのportTypeにのみ存在する必要があるため、メディエータ・ルーティング・サービスは1つのみ使用されます。

EBSに1つ以上の非同期リクエスト/レスポンス操作がある場合は、2つのportTypeが存在する必要があり、2つのメディエータ・ルーティング・サービスと2つのメディエータ・プロジェクト(各ルーティング・サービスに1つずつ)が存在します。

2. 「AIA開発でのOracle AIAネーミング標準」に記載されている命名規則に従います。

メディエータ・プロジェクトの一般的な名前の例は、次のとおりです。

- CustomerPartyEBSV2 (この例には、同期リクエスト/レスポンスとリクエストのみに対するすべての操作を含むルーティング・サービスがあります。)

- CustomerPartyEBSResponseV2 (この例には、非同期リクエスト/レスポンスに対するすべての操作を含むルーティング・サービスがあります。)

5.8.2.2 ルーティング・サービスの作成方法

リクエスト/遅延レスポンスMEPのルーティング・サービスを作成する手順は、次のとおりです。

1. 作成したEBS WSDLをメディエータ・プロジェクト・フォルダに配置します。

2. ルーティング・サービスを作成し、「AIA開発でのOracle AIAネーミング標準」に記載されている命名規則に従って名前を付けます。

3. WSDLを選択します。

WSDLを解析し、portType名をルーティング・サービスのportTypeフィールドに入力する必要があります。

4. ルーティング・サービスと一致するportTypeを選択します。ルーティング・サービスを保存します。

あるportType用に作成したルーティング・サービスには、補正操作を含め、EBS WSDLでそのportTypeに指定したすべての操作が設定されている必要があります。

注意:

これらのガイドラインは、非同期メッセージ交換パターンの実装に追加します。

5.8.2.3 ルーティング・ルールの作成方法

非同期リクエスト/遅延レスポンスEBSの場合、ルーティング・ルールをリクエストとレスポンスの両方に対して作成する必要があります。

リクエストEBSのルーティング・ルール

リクエストEBSのルーティング・ルールは、同期リクエスト/レスポンスの項で説明しているルーティング・ルールと同じです。

詳細は、「同期リクエスト/レスポンスMEPのルーティング・サービスの作成方法」を参照してください。

レスポンスEBSのルーティング・ルール

2つのルーティング・ルールが必要です。

レスポンスEBSのルーティング・ルールを作成する手順は、次のとおりです。

1. 適切な要求側サービスへのルーティング。

複数の参加アプリケーションの複数の要求側サービスでリクエストEBSを呼び出し、遅延レスポンスを待機している場合は、レスポンスを適切な要求側サービスにルーティングする必要があります。

図5-5に示すように、リクエストEBSを呼び出す前に、EBMHeader/Sender/WSAddress/wsa:ReplyTo/wsa:ServiceNameに要求側サービスの要求側サービス名の名前(アプリケーション・ビジネス・メッセージ(ABM)からEBMへの変換)を設定します。

図5-5 WSAddressタイプ要素の構造

提供側サービスでは、この情報はリクエストEBMからレスポンスEBMに転送されます。この情報は、次のように、ルーティング・ルールをフィルタに組み込むことによって、レスポンスEBSで使用されます。

<EBO Name>ResponseEBM\corecom:EBMHeader\Sender\
WSAddress/wsa:ReplyTo/wsa:ServiceName = <Requesting Service Name>

このルールの評価のターゲット・エンドポイントは、要求側サービスに設定する必要があります。

レスポンスEBSによるレスポンスの返送を待機しているリクエストEBSのすべての要求側サービスに対して、前述のようにルーティング・ルールを指定します。

2. CAVSルーティング・ルール。

CAVSルーティング・ルールは、同期リクエスト/レスポンスの項で説明した内容と同じです。

ABCS (リクエスタとプロバイダの両方)の有効化の詳細は、「アプリケーション・ビジネス・コネクタ・サービスの設計」、「ABCSの作成」および「ABCS開発の完了」を参照してください。

エラー処理の実装

詳細は、「保証付きメッセージ配信を確保するための非同期メッセージ交換パターンに対するエラー処理およびリカバリの実装」を参照してください。

5.8.3 非同期リクエスト/遅延レスポンスMEPのエラー処理

非同期リクエスト/遅延レスポンスMEPでは、要求側サービスは、レスポンスを待機する一時停止モードです。提供側サービスにエラーがある場合は、要求側サービスへのレスポンスにエラーの詳細が含まれます。

非同期リクエスト/遅延レスポンスMEPのエラーを処理する手順は、次のとおりです。

1. 提供側サービスのエラーの場合、例外が発生し、それがcatchブロックで捕捉されます。

2. catchブロックで、レスポンスEBMをEBMヘッダーのフォルト・コンポーネントとともに作成します。

3. 変換ステップを作成し、リクエストEBMを表す入力変数、およびレスポンスEBMを表す出力変数を選択します。

4. 例外から生成された変数としてのフォルト・メッセージを、「フォルト変数に対する入力変数」のXSLTに渡します。

5. 出力変数にマップします。

- 相関情報を含むリクエストEBMからの標準のEBMヘッダー・コンテンツ

- フォルト・メッセージ

6. レスポンスEBSルーティング・サービスのレスポンス操作を呼び出すInvokeステップを設定します。

7. 提供側サービスのレスポンスを適切な要求側サービスにルーティングします。

ABCS (リクエスタとプロバイダの両方)の有効化の詳細は、「アプリケーション・ビジネス・コネクタ・サービスの設計」、「ABCSの作成」および「ABCS開発の完了」を参照してください。

6 アプリケーション・ビジネス・コネクタ・サービスの設計

この章では、アプリケーション・ビジネス・コネクタ・サービス(ABCS)の概要を示し、ABCSコントラクトの定義方法とMEPの識別方法、アプリケーションとのアウトバウンド相互作用のテクノロジ・オプション、およびBPELを使用したABCSの作成方法について説明します。

この章の内容は次のとおりです。

- ABCSの概要

- ABCSコントラクトの定義

- MEPの識別

- テクノロジ・オプション

6.1 ABCSの概要

ABCSの役割は、参加アプリケーションによって提供されるビジネス機能を、エンタープライズ・ビジネス・サービス(EBS)に合わせた表現で公開することです。また、参加アプリケーションからEBSを呼び出すことができるように、両者を結び付ける役割も果たします。図6-1に、E-Business SuiteアプリケーションがABCSを使用してEBSを呼び出すシナリオを示します。このシナリオでは、ABCSはリクエスタとして機能しています。また、同じ図では、EBSが3つのABCSの1つを呼び出して、特定のタスクを実行する方法も示されています。ここでは、3つのABCSはプロバイダとして機能しています。

図6-1 Oracle AIAアーキテクチャにおけるABCS

ABCSを使用すると、参加アプリケーションはサービス・プロバイダやサービス・コンシューマになることができます。また、非標準接続を行うアプリケーションの機能をWebサービスとして公開できます。

ABCSの詳細は、Oracle Application Integration Architecture Foundation Packコンセプトおよびテクノロジ・ガイドのアプリケーション・ビジネス・コネクタ・サービスの理解に関する項を参照してください。

6.1.1 ABCSタイプ

ABCSには2つのタイプがあります。

- リクエスタABCS

- プロバイダABCS

6.1.1.1 リクエスタABCS

リクエスタABCSは要求側アプリケーションによって提供され、EBSとインタフェースして1つのタスクを実行します。サービスは、要求側/ソース・アプリケーションとEBS間をインタフェースします。リクエスタABCSの役割は、参加アプリケーションがEBSを呼び出して、データにアクセスしたり、トランザクション・タスクを実行できるようにすることです。

リクエスタABCSは、EBSを呼び出すために要求側アプリケーションによって提供されるサービスです。アプリケーション・ビジネス・メッセージ(ABM)をペイロードとして受け取り、オプションでABMをレスポンスとして返します。

ABMは、リクエスタ・アプリケーションとの追加の対話によってエンリッチできます。ABMは、XSLを使用してエンタープライズ・ビジネス・メッセージ(EBM)に変換されます。EBSから受信するレスポンス(EBM)はABMに変換されます。

非SOAPペイロードは、リクエスタ・アプリケーションとリクエスタABCSの間でトランスポート・アダプタを使用して処理されます。リクエスタ・アプリケーションは、ABCSに関するシステム情報を渡して後続の対話を行う必要があります。

6.1.1.2 プロバイダABCS

プロバイダABCSはプロバイダ・アプリケーションによって提供され、EBSとインタフェースして1つのタスクを実行します。サービスは、EBSとプロバイダまたはターゲット・アプリケーション間をインタフェースします。

プロバイダABCSとは:

- プロバイダ・アプリケーションとインタフェースするために、プロバイダ・アプリケーションによって提供されるサービスです

- EBMをペイロードとして受け取ります

- (オプション) EBMをレスポンスとして返します

EBMは、XSLを使用してABMに変換されます。ABMは、プロバイダ・アプリケーションとの追加の対話によってエンリッチできます。アプリケーションから受信するレスポンス(ABM)はEBMに変換されます。

プロバイダ・アプリケーションとの非SOAP接続は、プロバイダABCSとプロバイダ・アプリケーションとの間でトランスポート・アダプタを使用して処理されます。

ABCSの詳細は、Oracle Application Integration Architecture Foundation Packコンセプトおよびテクノロジ・ガイドのアプリケーション・ビジネス・コネクタ・サービスの理解に関する項を参照してください。

6.1.2 ABCSの設計 - 主要タスク

ABCSのアーキテクトまたは開発者は、設計アクティビティの過程で次のタスクを実行する必要があります。

- ABCSの役割の理解

- ABCSの呼出しをトリガーするビジネス・イベントの識別

- アプリケーションとABCS間の相互作用の識別

- 相互作用を容易にするために使用する適切なテクノロジの識別

- ABCSコントラクトの定義

次の各項では、これらのタスクについて説明します。

- ABCSコントラクトの定義

- MEPの識別

- テクノロジ・オプション

6.2 ABCSコントラクトの定義

ABCSコントラクト(WSDL)は、コール元がビジネス・コネクタ・サービスと相互作用する方法を指定します。コール元は、参加アプリケーションまたは他のサービス(EBSなど)のいずれかです。

図6-2に、ABCSのコントラクト(WSDL)を定義するためのデシジョン・フローを示します。

図6-2 ABCSコントラクトを定義するためのデシジョン・フロー

6.2.1 ABCSの役割の定義

この項では、ABCSがリクエスタまたはプロバイダの役割で参加するために必要な設計デシジョンについて説明します。

6.2.1.1 リクエスタの役割で参加するためのABCSの設計

ABCSがリクエスタの役割で参加できる方法を決定するには、次のことを検討します。

1. ABCSが呼出しまたはトリガーされる方法を決定します。この分析によって、ABCSがアプリケーションによって呼び出される方法が示されます。次を決定します。

a. アプリケーションがSOAPベースでABCSを呼び出せるかどうか。

b. アプリケーション・サービスがJCAアダプタを使用してABCSを呼び出せるかどうか。

c. ビジネス・イベントの発生によってアプリケーションが公開するメッセージを、ABCSがサブスクライブする必要があるかどうか。

2. 必要な相互作用パターンを決定します。
次の質問は、アーキテクトが最適なメッセージ交換パターンを識別するのに役立ちます。

a. リクエスタABCSの呼出しを発生するビジネス・イベントは何か。

b. アプリケーションはリクエスタABCSからのレスポンスが必要か。

c. アプリケーションはレスポンスを受信するまで待機してから次のタスクを実行する必要があるか。

d. アプリケーションはリクエストがプロバイダ・アプリケーションによって完全に処理されるまで待機する必要があるか。

MEPの選択方法の詳細は、「適切なMEPの選択」を参照してください。

3. 呼び出す必要があるエンタープライズ・ビジネス・サービスまたは操作を決定します。

4. リクエスタ・アプリケーションによって送信されるメッセージに、リクエスタABCSがEBMを作成するのに必要な情報がすべて含まれているか。

a. そうでない場合は、アプリケーションにアクセスして追加情報を取得する必要があるか。

b. そうである場合、使用可能なテクノロジは何か。追加情報を取得するのに使用されるアプリケーション・インタフェースは何か。

詳細は、「テクノロジ・オプション」を参照してください。

5. アプリケーションは不完全な情報を含むメッセージを公開できるか。

a. 完全な情報を含むメッセージが公開されるまでABCSは待機する必要があるか。
この場合、関連メッセージの完全セットを受け取るまで、アグリゲータによって各メッセージを収集および格納する必要があります。

b. そうである場合、アプリケーション・サービスは何か、通信はどのような方法か。

6.2.1.2 プロバイダの役割で参加するためのABCSの設計

ABCSがプロバイダの役割で参加できる方法を決定するには、次のことを検討します。

1. EBSによって送信された情報をアプリケーションが直接使用できるかどうかを決定します。

2. ABCSがプロバイダ・アプリケーションと相互作用する方法を決定します。

「リソース接続の確立」を参照してください。

3. このABCSで実行する必要があるタスクを定義します。

4. アプリケーションと通信するのに使用するメッセージ交換パターン(MEP)を決定します。

5. リクエストをプロバイダ・アプリケーションに送信する前に、EBSから送信されたEBMでデータ検証を実行する必要があるかどうかを決定します。

6. メッセージの保証付き配信が必要かどうかを決定します。

7. 複数インスタンスのデータを含む1つのメッセージかどうかを決定します。

8. メッセージ全体を1つの作業単位として処理する必要があるかどうかを決定します。

9. そのメッセージ内にあるインスタンスのサブセットに障害が発生した場合に実行する内容を決定します。

6.2.2 ABMスキーマの作成

ABMスキーマは、参加アプリケーションによって作成されます。ABMを定義するときは、次の点を考慮してください。

- ABM定義を頻繁に変更するとABCS開発に負荷がかかるため、持続的で長期に使用できるメッセージを作成します。

- 変換マップの再利用を促進するために、複数のABM間でビジネス・コンポーネントを再利用できるようにします。

- 次のシステム・データを渡すようにABMを設計します。

- システム・インスタンス - システム・レジストリに登録されたシステムIDの識別に役立つ接続情報

- ロケール - リクエストが送信されるときの言語コード

- 送信者情報 - メッセージの作成に関連するコンテキスト詳細

- 拡張可能なABMを設計します。

6.2.3 参加アプリケーションの統合機能の分析

参加アプリケーションの統合機能を分析する手順は、次のとおりです。

参加アプリケーションを識別した後に、各参加アプリケーションの統合機能およびデータの公開方法を分析する必要があります。

1. アプリケーション・プロバイダ(開発者)と協力して、必要な機能を実現するためにアプリケーションと相互作用する最適な方法を決定します。

相互作用はインバウンドまたはアウトバウンドになります。相互作用メカニズムには次のいずれかを使用できます。

- SOAP/HTTPを使用するWebサービス

- イベント/キュー

- JCAアダプタ

- データベース・アダプタ

様々なリソースへの各種接続タイプの詳細は、「リソース接続の確立」を参照してください。

2. 参加アプリケーションとABCS間の相互作用にメッセージ・キュー・アダプタ、データベース・アダプタまたはJCAアダプタを使用する場合は、アプリケーションから関連する詳細を取得します。

これらの詳細は、アダプタの構成で使用されます。構成によってWSDLが作成されます。環境固有の詳細が、WSDLに直接ではなく、サーバー上の関連リソース・ファイルに構成されていることを確認してください。

3. 参加アプリケーション内で使用可能な機能、およびEBMとアプリケーション・ビジネス・オブジェクト間のマッピング(マップ操作)を識別します。

2つの間には、1対1、1対多または多対1のマッピングが存在します。

4. エンタープライズ・ビジネス・オブジェクト(EBO)属性/要素とアプリケーション・オブジェクト属性/要素の間のマッピングをスプレッドシートで一覧表にします。

変換マップを作成するときは、次の点に注意してください。

5. ABMをEBMにマップする場合は、ABM内に存在するすべてのデータ要素をEBM内の対応する要素に入力するように試みてください。

EBM内のすべてのデータ要素を満たすだけのデータがABM内に存在しない場合は、関連するリクエスタ・アプリケーション・チームと協力して、EBMの内容を入力できるアプリケーション・サービスを識別する必要があります。

たとえば、CreateOrder ABCSを呼び出すSiebelアプリケーションは、ペイロードとして渡されるABMにSiebel顧客IDのみ提供できます。しかし、CreateOrder EBS操作にペイロードとして渡されるEBMには、顧客に関するすべての情報が必要です。そのため、CreateOrder ABCSは、Siebelサービスを呼び出し、Siebelアプリケーションから完全な顧客詳細を取得してEBMに入力する必要があります。このパターンは統合プラットフォームでもサポートされていますが、対話を最小限にするために、参加アプリケーションと協力して、ABCSに渡されるペイロードを可能なかぎりEBMの形式に近づけておくことをお薦めします。

6.3 MEPの識別

ABCSとそのクライアント間で可能な相互作用タイプは次のとおりです。

- 同期リクエスト/レスポンス

- 非同期リクエストのみ

- 非同期リクエスト/遅延レスポンス

MEPの機能と使用方法は、ABCSの役割によって異なります。

MEPの詳細は、Oracle Application Integration Architecture Foundation Packコンセプトおよびテクノロジ・ガイドの相互作用パターンの理解に関する項を参照してください。

6.3.1 MEPの概要

同期リクエスト/レスポンス・パターン

- リクエスタがリクエストをプロバイダに送信すると、プロバイダはそのリクエストを処理してレスポンスを返信します。

- リクエスタは、プロバイダからレスポンスを受信するまで一時停止モードになります。

- 結果は、リアルタイムレスポンスまたはエラー・フィードバックです。

非同期リクエストのみ

- メッセージ交換は、リクエスタがリクエストをプロバイダに送信する一方向です。プロバイダからリクエスタへのレスポンスはありません。

- リクエスタは、リクエストの送信後、通常の実行を再開できます。

非同期リクエスト/遅延レスポンス

- これには、一方向の呼出しが2つ含まれます。

- 最初に、リクエスタからプロバイダへの一方向メッセージが送信されます。その後に、別の一方向メッセージがプロバイダから元のリクエスタに返されます。

- 2つの異なる一方向メッセージは相互に関連しています。

MEPの詳細は、Oracle Application Integration Architecture Foundation Packコンセプトおよびテクノロジ・ガイドの相互作用パターンの理解に関する項を参照してください。

6.3.2 適切なMEPの選択

- 参加アプリケーションがABCSとの間でインバウンドとアウトバウンドの相互作用を行う方法を識別します。

- リクエスタ・アプリケーションは、プロバイダ・アプリケーションからレスポンスを受信するまで、呼出しを待機する必要があるかどうかを識別します。
プロバイダ・アプリケーションからレスポンスを受信するまで待機する場合、リクエスタ・アプリケーションはABCSを同期で呼び出すように強制されます。たとえば、リクエストを送信して請求アプリケーションからアカウント詳細を取得するCRMアプリケーションがこれに該当します。この場合、リクエスタはレスポンスを受信するまで他のタスクを実行できません。

ただし、請求アプリケーションで顧客を作成する場合、CRMアプリケーションからのリクエストの送信は非同期で行うことができます。CRMアプリケーションはアウトバウンド・リクエストを公開した後に次のアクティビティに移行でき、プロバイダ・アプリケーションが顧客を正常に作成するまで待機する必要はありません。この場合、CRMアプリケーションはこのアウトバウンド・リクエストを非同期で呼び出します。

アプリケーションは、様々な種類の統合テクノロジを利用して、同期または非同期の呼出しを行うことができます。状況に応じて、最適なテクノロジを選択する必要があります。

AIAサービスがアプリケーションと相互作用する方法の詳細は、「リソース接続の確立」を参照してください。

1つのフロー内で、リクエスタABCSのMEPは、呼び出されるEBS操作のMEPの影響を受けますが、リクエスタ・アプリケーションの相互作用機能もリクエスタABCSのMEPに影響を与えます。プロバイダABCSの場合、MEPはEBS操作のMEPの影響を多く受けます。

6.3.2.1 同期リクエスト/レスポンスMEPを使用する場合

リクエストを開始した参加アプリケーションはレスポンスを待機しているため、問合せと検証を含むほとんどのケースでこのパターンが必要です。その他のケースでこのパターンが適しているかどうかは、実行される処理量に基づき、求められるレスポンス時間や要件が満たされる可能性によって決まります。

リクエスタABCSとEBS間のMEPは同期です。プロバイダABCSとリクエストを開始する参加アプリケーションとの間のMEPは、同期または非同期が可能です。

問合せの詳細は、「問合せ」を参照してください。

検証の詳細は、「検証」を参照してください。

ユースケース

請求システムから顧客に関するアカウント詳細をリクエストするCRMアプリケーション

図6-3に、AIAサービス、リクエスタABCSおよびCustomerPartyEBS間の双方向通信を示します。

図6-3 GetAccountBalanceSummary統合シナリオ

6.3.2.2 非同期リクエストのみ(ファイア・アンド・フォーゲット) MEPを使用する場合

このパターンは次の場合に使用します。

- リクエスタABCSが参加アプリケーションからリクエスト・メッセージを受信し、EBSを呼び出して終了します。この場合、EBSからリクエスタABCSへのレスポンスはなく、リクエストを開始した参加アプリケーションへのレスポンスもありません。

- プロバイダABCSがEBSからリクエスト・メッセージを受信し、プロバイダ参加アプリケーションAPIを呼び出して終了します。リクエストを開始したEBSへのレスポンスはありません。

ユースケース

CustomerPartyを作成するためにBRMアプリケーションにリクエストを送信するCRMアプリケーション

参加アプリケーションであるSiebelの観点から見ると、CustomerPartyを作成するためのBRMアプリケーションへのリクエスト・メッセージは、後で処理するためにエンキューされます。Siebelアプリケーションは即時に処理を再開できます。リクエスト・メッセージはキューからデキューされ、非同期で処理されます。

図6-4に、AIAサービス、リクエスタABCSおよびCustomerPartyEBS間の一方向呼出しを示します。

図6-4 一方向呼出しの例

6.3.2.3 非同期リクエスト/遅延レスポンスMEPを使用する場合

このパターンは次の場合に使用します。

- リクエスタABCSは、リクエスト・メッセージを受信し、そのメッセージを処理して、最後に、参加アプリケーションによって公開されたAPIを呼び出して、リクエストを開始した参加アプリケーションを更新します。参加アプリケーションはレスポンスを待機しません。

- プロバイダABCSは、EBSリクエスト・メディエータ・サービスからリクエスト・メッセージを受信し、そのメッセージを処理して、最後に、EBSリクエスト・メディエータ・サービスのレスポンス操作を呼び出して、要求側サービス(リクエスタABCSまたはエンタープライズ・ビジネス・フロー(EBF))に応答します。EBSメディエータ・サービスはレスポンスを待機しません。

MEPは、リクエスタABCSとEBS間で同期または非同期が可能で、プロバイダABCSとプロバイダ参加アプリケーション間でも同期または非同期が可能です。

6.4 テクノロジ・オプション

この項では、次のテクノロジ・オプションについて説明します。

- アプリケーションとのアウトバウンド相互作用
インバウンド相互作用については、「ABCSの呼出し」を参照してください。

- BPELを使用したABCSの作成

リソース接続の詳細は、「リソース接続の確立」を参照してください。

6.4.1 アプリケーションとのアウトバウンド相互作用

ABCSとアプリケーション間の通信は、アプリケーション機能によって管理されます。

通信テクノロジは次のとおりです。

- JCAアダプタ

- 標準Webサービス・インタフェース

- アダプタ

- JMSキュー

6.4.1.1 アウトバウンド相互作用でJCAアダプタを使用する場合

JCAアダプタが使用可能で使用が認可されている場合は、開発者がアプリケーションに接続する方法として最初に選択する必要があります。

JCAアダプタとは:

- 同一の場所に配置する方法でネイティブに参加アプリケーションを呼び出します。

- プログラミング・インタフェースを標準化します。

- サービス品質(QoS)の実装を標準化します。

- ランタイム環境と組み合せて、接続管理、トランザクション管理およびスケーラビリティに関連するタスクをサポートします。

アウトバウンド接続の確立の詳細は、「リソース接続の確立」を参照してください。

6.4.1.2 アウトバウンド相互作用に標準Webサービス・インタフェース(SOAP/HTTP、XML/HTTP)を使用する場合

これは、参加アプリケーションと通信する最も一般的な方法です。

ほとんどのアプリケーションは、Webサービスの形式で機能を公開しています。最も一般的に使用されるトランスポートはSOAP over HTTPですが、アプリケーションによっては直接XML over HTTPを公開しています。

6.4.1.3 アウトバウンド相互作用でJCAアダプタ(データベース、ファイル、JMSまたはAQJMS)を使用する場合

メッセージの送信がメッセージ処理から分離している場合は、キューの使用をお薦めします。JMSキューを使用すると、JMSアダプタを使用してJMSキューにアクセスする必要があります。ABCSによってメッセージがJMSキューにエンキューされ、アプリケーションによってそのメッセージがデキューされます。

ヒント:

非同期モードのアウトバウンド相互作用を行う参加アプリケーションの場合は、メッセージ・キューを使用してリクエストを公開することをお薦めします。この方法を推奨するのは、高いスケーラビリティが実現し、エンドユーザーの操作性も向上するためです。同様に、アプリケーションへのアウトバウンド相互作用を行うABCSでは、アプリケーションによって実行されるタスクを評価する必要があります。アプリケーションでタスクを実行するのに長時間かかる場合は、メッセージ・キューを使用してアプリケーションと通信してください。

同期モードのみでアウトバウンド相互作用を行う参加アプリケーションは、SOAP/HTTPを使用してリクエストを送信する必要があります。

JMSアダプタの詳細は、『Oracle WebLogic Server JMSリソースの管理』を参照してください。

6.4.2 BPELを使用したABCSの作成

BPELコンポーネントを使用してABCSコンポジットを作成することをお薦めします。

次の場合にBPELを使用すると最も効率的です。

- 長時間実行プロセスが存在する場合。
数時間または数日を要する長時間実行プロセスが存在する場合は、BPELテクノロジの使用をお薦めします。この場合、BPELは特定のフック・ポイントでプロセスを保持(デハイドレーション)し、必要になった時点でプロセスを再開します。

- 複雑な編成機能が必要な場合。
複雑な編成、並列処理、参加アプリケーションまたは統合サービス(BPA、BAM、ワークフロー、ルール・エンジンなど)との複数の対話を必要とするシナリオの場合は、BPELを使用すると最も効率的です。

- XSLTを使用して実行できないコンテンツを拡充および検証する場合。
意思決定や検証が複雑でXSLTを使用して実行できない場合は、標準的なBPEL手続き型コンストラクトやルール・エンジンの呼出しなどの方法が必要になります。BPELを使用すると、非常に複雑な意思決定ツリーの実行や、複数パートナへの結果のルーティングが容易になります。

- 集約または分割が必要な場合。
メッセージ処理またはデータ収集を行うために、ABCSがアプリケーション呼出しを複数回実行し、結果を1つのメッセージにまとめる必要がある場合は、BPELテクノロジの使用をお薦めします。BPELコンストラクトを使用すると、ペイロードの分割または統合、あるいは呼出しの集約または分割が可能になります。BPELプロセスは、呼出し間の状態保持やトランザクション処理も行います。

- 参加アプリケーション機能の補完が必要な場合。

詳細は、『Oracle SOAスイートでのSOAアプリケーションの開発』を参照してください。

7 ABCSの作成

この章では、アプリケーション・ビジネス・コネクタ・サービス(ABCS)の作成方法について説明します。ここでは、ABCSの作成を開始する前に必要な前提条件をリストし、SOAコンポジット・アプリケーションの概念を簡単に説明します。

注意:

コンポジット・ビジネス・プロセス(CBP)は、次のリリースから非推奨となります。人間/システム相互作用のモデル化には、BPMの使用をお薦めします。

この章の内容は次のとおりです。

- ABCSの作成

- JDeveloperを使用したABCSコンポジットの作成

- ファイア・アンド・フォーゲットMEPの実装

- 非同期リクエスト/遅延レスポンスMEPの実装

- 非同期メッセージ交換でのプロバイダABCSの実装シナリオ

- 同期リクエスト/レスポンス・メッセージ交換の実装シナリオ

- エンタープライズ・ビジネス・サービスの呼出し

- ABCSの呼出し

7.1 ABCSの作成

表7-1に、ABCSを作成するための共通タスクをリストして、詳細情報へのリンクを示します。

表7-1 ABCSを作成するためのタスクの概要

状況

参照先

ファイア・アンド・フォーゲット・メッセージ交換パターン(MEP)を実装する

非同期リクエストのみ(ファイア・アンド・フォーゲット) MEPを使用する場合

ファイア・アンド・フォーゲットMEPの実装

EBSにMEPを実装する場合は、「ファイア・アンド・フォーゲット・メッセージ交換パターンの実装」を参照してください。

非同期リクエスト/遅延レスポンスMEPを実装する

非同期リクエスト/遅延レスポンスMEPを使用する場合

非同期リクエスト/遅延レスポンスMEPの実装

EBSにMEPを実装する場合は、「非同期リクエスト/遅延レスポンス・メッセージ交換パターンの実装」を参照してください。

同期リクエスト/レスポンスMEPを実装する

同期リクエスト/レスポンスMEPを使用する場合

同期リクエスト/レスポンス・メッセージ交換の実装シナリオ

EBSにMEPを実装する場合は、「同期リクエスト/レスポンス・メッセージ交換パターンの実装」を参照してください。

ABCSでエンタープライズ・ビジネス・サービス(EBS)操作を呼び出す

EBSの操作の使用に関するガイドラインは、「エンタープライズ・ビジネス・サービスの設計と開発」を参照してください

メッセージの書式を別の書式に変換する方法の詳細が必要

メッセージ変換の使用。

ABCSと参加アプリケーションの接続方法(インバウンドとアウトバウンドの両方)に関する情報が必要

リソース接続の確立。

開発中のABCSをクライアント(アプリケーション、その他のサービスなど)が呼び出す方法を知る必要がある

ABCSの呼出し

ABCSを保護する

ABCSの保護

ABCSでエラーやフォルトを処理できるようにする

エラーおよびフォルトの処理

顧客がABCSを拡張できるようにする

拡張可能なABCSの開発

ABCSに対応するコンポジット・アプリケーション検証システム(CAVS)のガイドラインが必要

CAVS対応のABCSの開発

AIAインストール・ドライバを使用して、開発中のABCSをデプロイする

AIA統合フローの作成。

ABCS内からAIA構成プロパティにアクセスする

「$SOA_HOME/aia_instances/$INSTANCE_NAME/AIAMetaData/configでのAIAConfigurationProperties.xmlの使用方法」。

7.1.1 前提条件

ABCSの作成を開始する前に、次のことを確認してください。

- 関連する開発SOAサーバーがSOAコア拡張機能とともにインストールされて実行されていること。
「AIAワークステーションの設定方法」を参照してください。

- アプリケーション・エンティティのスキーマ(アプリケーション・ビジネス・メッセージ[ABM]スキーマ)がメタデータ・サービス(MDS)リポジトリからアクセス可能であること。これらは、各ABCSプロジェクトに含まれません。
「AIAでのMDSの使用」を参照してください。

- エンタープライズ・ビジネス・オブジェクト(EBO)およびエンタープライズ・ビジネス・メッセージ(EBM)を含むエンタープライズ・オブジェクト・ライブラリがMDSリポジトリでアクセス可能であること。EBOおよびEBMは、各ABCSプロジェクトに含まれません。
「AIAでのMDSの使用」を参照してください。

- EBSまたは参加アプリケーションのすべての抽象WSDLがMDSリポジトリからアクセス可能であること。

ヒント:

開発中のABCSの抽象WSDLには、MDSからアクセスする必要があります。このルールには次の例外があります。

- EBSは、PartnerLinkタイプを定義するWSDLを参照します

- 参加アプリケーションは、PartnerLinkタイプを定義するWSDLを参照します

- JDeveloperで生成されるアダプタWSDL

- ABCS拡張ポイントで定義されるサービスの抽象WSDL

詳細は、「AIAでのMDSの使用」を参照してください。

- リクエスタおよびプロバイダ参加アプリケーションが識別されていること。

- EBOおよびEBMが識別されていること。

- EBSと参加アプリケーション間の機能マッピングが完了していること。このマッピングには次が含まれます。

- EBOと参加アプリケーション・メッセージ間のデータ要素スプレッドシート・マッピング。

- EBSと参加アプリケーション間の操作マッピング。

- 相互作用のスタイル(MEP: リクエスト/レスポンス、ファイア・アンド・フォーゲット、非同期リクエストおよび遅延レスポンス)が定義されていること。
「適切なMEPの選択」を参照してください。

- 参加アプリケーションとの通信プロトコルが識別されていること。
ABCSが参加アプリケーションと相互作用する方法の詳細は、「リソース接続の確立」を参照してください。

- 参加アプリケーション固有の要件(エラー処理、セキュリティなど)が識別されていること。

7.1.2 コンポジット・アプリケーションとしてのABCS

AIAサービス(ABCSおよびEBS)は、SCA構築ブロックを使用して作成されるコンポジット・アプリケーションとして開発できます。これらのサービスには、4つのSCA要素が適用されます。

- サービス
SCAコンポーネントまたはコンポジットへのエントリ・ポイントを表します。

- 参照
特定のSCAコンポーネントの範囲外にある外部サービスへのポインタを表します。

- 実装タイプ
ビジネス・ロジックのコーディングに使用される特定のSCAコンポーネントに対して、実装コードのタイプを定義します。BPELおよびMediatorは実装タイプの例です。

- ワイヤ
2つのコンポーネントを相互に接続できるメカニズムを表します。通常、1つのコンポーネントの参照が、別のコンポーネントによって公開されたサービスに接続されます。

SCAコンポーネントは、1つ以上のサービスの公開、1つ以上の参照の使用、1つ以上のプロパティによる特定の特性の定義、およびSCAワイヤリングを使用した1つ以上のコンポーネントへの接続が可能です。

SCAの構築ブロックを連結したりアセンブルして、コンポジット・アプリケーションを作成できます。コンポジット・アプリケーションは、大まかなビジネス機能を集約的に提供する、関連するSCAコンポーネントの構成と考えることができます。

7.1.3 作成するコンポーネントの必要数

コンポジット・アプリケーションは、大まかなビジネス機能を集約的に提供する、関連するSCAコンポーネントの構成と考えることができます。コンポジットには、コンポジットの内部実装にのみ必要なコンポーネント、およびコンテキスト内でコンポジットの範囲外とのインタフェースが不要なコンポーネントを含めることができます。

コンポーネントは、コンポジットの内部実装用のみに使用できるため、サービス、参照またはその両方を公開しなくても存在できます。

図7-1に示すリクエスタABCSコンポジットは、サービスとして公開されている1つのコンポーネントを使用して作成できます。

コンポーネントは、EBSを表す1つの参照、または他のアプリケーションとのアウトバウンド相互作用を表す複数の参照を使用できます。

図7-1 リクエスタABCSコンポジットの例

同様に、図7-2に示すプロバイダABCSコンポジットは、サービスとして公開されている1つのコンポーネントを使用して作成できます。

コンポーネントは、アプリケーションとのアウトバウンド相互作用を表す1つ以上の参照を使用できます。

図7-2 プロバイダABCSコンポジットの例

7.2 JDeveloperを使用したABCSコンポジットの作成

この項では、JDeveloperを使用して設計モードでABCSコンポジットを作成する方法の概要を説明します。

実行する高度なタスクは次のとおりです。

- MDSにアクセスするようにJDeveloperを構成します。
「AIAでのMDSの使用」を参照してください。

- ABCSの抽象WSDLを開発します。
「アプリケーション・ビジネス・コネクタ・サービスの設計」を参照してください。

- JDeveloperを使用してABCSコンポジットを作成します。
「JDeveloperを使用したABCSコンポジットの作成方法」を参照してください。

- BPELプロセスを開発します。
「BPELプロセスの開発」を参照してください。

7.2.1 JDeveloperを使用したABCSコンポジットの作成方法

JDeveloperを使用してABCSを作成する手順は、次のとおりです。

1. JDeveloperで、SOAコンポジット・プロジェクトを作成します。

2. composite.xmlを設計モードで開きます。

3. BPELコンポーネントを「コンポーネント」スイムレーンに追加します。

4. Webサービスを外部参照サービスとして「参照」スイムレーンに追加します。

この参照サービスは、EBS、アダプタ・サービスまたは参加アプリケーションを表すことができます。EBS、アダプタ・サービスまたは参加アプリケーションの抽象WSDLは、MDSリポジトリからアクセスできる必要があります。

5. BPELコンポーネントを、ステップ4で作成した外部参照コンポーネントに接続します。

6. フォルトを処理するために、次の作業を完了します。

- Webサービスを外部参照サービスとして「参照」スイムレーンに追加します。AIAAsyncErrorHandlingBPELProcessの抽象WSDLへの参照をMDSリポジトリに設定します。

- BPELコンポーネントをAIAAsyncErrorHandlingBPELProcessサービスに接続します。

AIAサービスでのフォルト処理の詳細は、「エラー処理およびトレース・ロギング用のOracle AIAプロセスの構成」を参照してください。

図7-3に、リクエスタABCSコンポジットを示します。

図7-3 リクエスタABCSコンポジットの例

7.2.2 BPELプロセスの開発

JDeveloperを使用して設計モードでコンポジットを開発した後は、BPELプロセス・コンポーネントとして実装されるABCSの作成を完了する必要があります。

ABCSで、次のタスクを実行します。

- メッセージ・エンリッチメント

- メッセージ・ヘッダーの入力

- メッセージ・コンテンツの変換

- エラー処理およびロギング

- 拡張性

- CAVS対応

- セキュリティ・コンテキスト実装

ABCS開発の完了の詳細は、「ABCS開発の完了」を参照してください。

7.2.3 参照、サービスおよびコンポーネントの作成方法

- ターゲットごとに参照を追加します。

- ターゲットはWebサービスまたはアダプタが可能です。

- ターゲット・サービスで変換が必要な場合は、間にメディエータ・コンポーネントを作成します。

- インタフェースごとにサービスを追加します。

- サービスはWebサービスまたはアダプタが可能です。

- アダプタ・インタフェースで変換が必要な場合は、間にメディエータ・コンポーネントを作成します。

7.2.4 抽象サービスWSDLのMDSへの移動

SOA Suite 12cでは、中央リポジトリのメタデータ・サービス(MDS)が導入され、設計時および実行時にアプリケーション(およびコンポジット)をバックアップします。MDSは、共有している共通のアーティファクトを設計時および実行時に格納して使用できるバージョン管理システムに類似しています。

AIAでは、MDSリポジトリを利用して、すべての開発者が共有する共通の設計時アーティファクトを格納します。MDSには一元的にアクセス可能なエンドポイントとして、抽象WSDLの共通ディレクトリがあります。

MDSに格納されるアーティファクトには、次の内容が含まれます。

- スキーマ: EBOスキーマおよびABMスキーマ

- WSDL: EBS、ABCS、アダプタ・サービス、CBPおよびEBFの抽象WSDL

すべてのAIAサービスの抽象WSDLは、すべてMDSに配置されます。参照先サービスの抽象WSDLを使用して、使用するAIAサービス・コンポジット・アプリケーションを作成します。コンポジットのデプロイメントの順序に対する依存性はありません。

コンポジットのデプロイメント時は参照先サービスに対する依存性がないため、コンポジットのデプロイメントの順序に対する依存性はありません。参照先サービスは、別のサービスで参照するためにデプロイする必要はありません。これによって、サービス間で循環参照がある場合も解決されます。

ヒント:

呼び出す必要があるサービスを参照するには、常に抽象WSDLを使用してください。参照バインディング・コンポーネントでは、常に抽象WSDLを使用する必要があります。

消費アーティファクトでは具象WSDLを直接使用しないでください。

サービス・プロバイダのデプロイ済の具象WSDLを参照しないでください。

この方法については、次の段落で説明します。

これを推奨する理由については、「関心の分離」を参照してください。

AIAでのMDSの使用方法の詳細は、「AIAでのMDSの使用」を参照してください。

ヒント:

抽象WSDLは、MDSから必要なスキーマにアクセスするように変更して、MDSに移動する必要があります。

トラブルシューティングのヒント:

無効なSOAコンポジットを示すエラー・メッセージがサーバーの再起動後に表示される場合があります。これは、抽象WSDLを使用する必要がある場所で具象WSDLを参照していることが原因です。

新しいコンポジットXの最初のデプロイメント時にコンポジットYの具象WSDLを参照した場合は問題がありません。なぜでしょうか。コンポジットYは、コンポジットXのデプロイメント時には起動して稼働しています。問題はサーバーを再起動した際に発生しますが、これは、依存性を解決する正しい順序でコンポジットがアクティブ化される保証がないためです。コンポジットYの前にサービスXがアクティブ化された場合は、Yが停止しているため参照を解決できず、このため、Xのステータスは無効のままとなります。

ABCSおよびアダプタ・サービスの場合、抽象WSDLはMDSの次の場所に配置されます。

AIAMetaData/AIAComponents/ApplicationConnectorServiceLibrary/<PRODUCT_CODE>/<バージョン番号>/<サービス・タイプ>

<サービス・タイプ>に設定可能な値は、RequesterABCS、ProviderABCS、AdapterServicesです。

<バージョン番号>に設定可能な値は、V1、V2です。

アーティファクトをMDSに移動するユーティリティについては、「AIAでのMDSの使用」で説明されています。

例:

AIAMetaData/AIAComponents/ApplicationConnectorServiceLibrary/Siebel/V1/RequesterABCS
AIAMetaData/AIAComponents/ApplicationConnectorServiceLibrary/Siebel/V1/ProviderABCS

7.3 ファイア・アンド・フォーゲットMEPの実装

この項では、ファイア・アンド・フォーゲットMEPを実装する際に必要なガイドラインを示します。

このMEPが推奨されるシナリオの詳細は、「非同期リクエストのみ(ファイア・アンド・フォーゲット) MEPを使用する場合」を参照してください。

ファイア・アンド・フォーゲット・パターンでは、リクエスタにレスポンスが返信されません。プロバイダABCSがタスクを正常に完了できない場合は、トランザクションがロールバックされ、エラー通知が送信される必要があります。

トランザクションをモデル化する方法の詳細は、「メッセージ変換の使用」を参照してください。

フォルトの処理方法の詳細は、「エラー処理およびトレース・ロギング用のOracle AIAプロセスの構成」を参照してください。

RequesterABCSがJMSベースのトランスポート・アダプタによって呼び出される場合、JMS宛先はマイルストンとして考えることができます。このような状況では、失敗したメッセージの自動メッセージ再発行用にJMSコンシューマ・アダプタおよびリクエスタABCSを構成できます。

メッセージ再発行の詳細は、Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイドのメッセージ再発行ユーティリティの使用に関する項を参照してください。

この項には次のトピックが含まれます:

- 補正サービスを使用する時期

- 補正サービスを呼び出す方法

- このMEPを実装するのにプロバイダABCSで必要な追加タスク

- トランザクションの確認方法

- エラーの処理方法

7.3.1 補正サービスを使用する時期

データを自動訂正したり、リクエスタ・サービスで実行された作業を元に戻すことが必要になる場合があります。典型的なシナリオは、トランザクションでエラーが発生し、トランザクションをロールバックできない場合です。

このような状況では、リクエスタ・アプリケーションは補正サービス操作を実装し、サービス操作の名前をプロバイダABCSに渡すことができます。エラーが発生した場合、プロバイダABCSはこの補正サービス操作を呼び出します。要求側サービスに対して補正サービスを実装するための要件がある場合があります。

7.3.2 補正サービスを呼び出す方法

提供側サービスから正しい補正サービスを呼び出す手順は、次のとおりです。

1. リクエストEBMの作成に使用する変換の補正サービス名をEBMHeader/Sender/WSAddress/wsa:FaultTo/wsa:ServiceNameに入力します。
補正サービスの名前の例: CompensateCreateOrderSiebelReqABCSImpl

ネーミングの詳細は、「AIA開発でのOracle AIAネーミング標準」を参照してください。

図7-4に、WSAddressTypeの構造を示します。

図7-4 WSAddressTypeの構造

この情報をEBSの補正操作で使用して、補正のリクエストを適切な補正サービスにルーティングします。

7.3.3 このMEPを実装するのにプロバイダABCSで必要な追加タスク

このMEPの実装については、「非同期メッセージ交換でのプロバイダABCSの実装シナリオ」を参照してください。

7.3.4 トランザクションの確認方法

トランザクションの確認方法については、「AIAサービスでのトランザクションの確認方法」を参照してください。

7.3.5 エラーの処理方法

エラー処理の詳細は、「エラー処理およびトレース・ロギング用のOracle AIAプロセスの構成」を参照してください。

7.4 非同期リクエスト/遅延レスポンスMEPの実装

この項では、非同期リクエスト/遅延レスポンスMEPを実装する際に必要なガイドラインを示します。

このMEPが推奨されるシナリオの詳細は、「非同期リクエスト/遅延レスポンスMEPを使用する場合」を参照してください。

この項では、非同期リクエスト/遅延レスポンスMEPの実装方法について説明します。

このMEPを実装するには、次のことが必要です。

- 非同期遅延レスポンスのEBMヘッダーが入力されていること。

- 相関セットおよび相関IDが定義されていること。

- エラー・レスポンスをリクエスタABCSまたはエラー・ハンドラ・サービスのいずれかに返信するシナリオを処理するために、リクエスタABCS、EBS、ProviderABCSおよびResponseEBSに対して適切なプログラミング・モデルが使用されていること。

この項には次のトピックが含まれます:

- 非同期遅延レスポンスのEBMヘッダーの入力方法

- 非同期リクエスト/遅延レスポンスMEPの相関の設定

- 非同期リクエスト/遅延レスポンスMEPでエラー・レスポンスを処理するためのプログラミング・モデル

- このMEPを実装するのにプロバイダABCSで必要なタスク

7.4.1 非同期遅延レスポンスのEBMヘッダーの入力方法

非同期遅延レスポンスのEBMヘッダーを入力する手順は、次のとおりです。

1. EBMIDを入力します。

これは、適切な要求側サービス・インスタンスへのレスポンスの相関で使用されます。

図7-5に、CreateSalesOrderEBMTypeの構造を示します。

図7-5 CreateSalesOrderEBMTypeの構造

2. 図7-6に示すように、EBMHeader/Sender/WSAddress/wsa:ReplyTo/wsa:ServiceNameに、ABMからEBMへの変換における要求側サービス名の名前を設定します。

これは、レスポンス・メッセージを処理するためにEBSによって呼び出す必要があるサービスの名前です。ほとんどの場合、プロバイダABCSからのレスポンス・メッセージも処理する同じリクエスタABCSです。

図7-6 SWSAddressTypeの構造

この情報をEBSのレスポンス操作で使用して、提供側サービスから適切な要求側サービスにレスポンスをルーティングします。

3. EBM動詞のresponseCode属性を設定します。

EBM動詞のresponseCode属性は、要求側サービスでレスポンスが必要であることを提供側サービスに指示するために設定します。これは、レスポンスを返信するために提供側サービスで評価されます。

4. 要求側サービス・パートナ・リンクに相関情報を設定します。

レスポンスEBSによってルーティングされた提供側サービスからの遅延レスポンスは、Receiveアクティビティで受信されます。要求側サービスでInvokeステップが実行され、プロセスがReceiveステップに移動した後、BPELプロセス・インスタンスは一時停止してデハイドレーションされます。これは、レスポンスが受信された後に再開されます。この動作を容易にするために、ReceiveのpartnerLinkに相関セットを指定する必要があります。

リクエスタABCSプロセスは、図7-7の例のようになります。これは、相関IDの設定が必要なプロセスです。

図7-7 リクエスタABCSプロセスの例

7.4.2 非同期リクエスト/遅延レスポンスMEPの相関の設定

「非同期遅延レスポンスのEBMヘッダーの入力方法」で説明しているプロセスでは、2箇所に相関を設定する必要があります。

- 相関セット
プロセスがデハイドレーション・ストアに進むInvokeアクティビティに対して、相関IDを追加し、相関セットを作成します。

プロバイダ/エッジ・アプリケーションからの遅延レスポンスを取得した後にデハイドレーション・ストアからプロセスが再コールされるReceiveアクティビティに対して、相関IDを追加し、相関セットを作成します。

- 相関プロパティ
前述したように相関セットが定義されるInvokeまたはReceiveアクティビティにリンクするpartnerLinkごとに、名前-値ペアを追加します。プロパティは常にcorrelation = correlationSetとして定義する必要があります。

7.4.3 非同期リクエスト/遅延レスポンスMEPでエラー・レスポンスを処理するためのプログラミング・モデル

この項では、次のためのプログラミング・モデルについて説明します。

- エラー処理用に個別サービスを使用

- RequesterABCSとEBS間でマイルストンとしてJMSキューを使用

- EBSでパラレル・ルーティング・ルールを使用

7.4.3.1 プログラミング・モデル1: エラー処理用に個別サービスを使用

このモデルでは、メッセージが正常に処理されると、プロセスを開始したリクエスタにレスポンスが返信されます。ただし、ProviderABCSで処理中にメッセージ・エラーが発生した場合は、ResponseEBSを使用して個別のエラー・ハンドラ・サービスにルーティングされます。

リクエスタABCSに到達したインバウンド・メッセージはEBSに渡され、EBSでプロバイダABCSが呼び出されてメッセージが処理されます。

メッセージが処理された後に、プロバイダABCSはメッセージをJMSキューにプッシュします。

メッセージの処理中にエラーが発生した場合は、エラー・レスポンス・メッセージが作成され、レスポンスが実際にはエラー・メッセージであることをEBMレスポンス・ヘッダーで示す必要があります。

成功した場合、レスポンスEBSはレスポンス・メッセージを開始requesterABSにルーティングします。

失敗した場合、レスポンスEBSはメッセージをエラー・ハンドラ・サービスにルーティングする必要があります。

注意:

プロバイダABCSがレスポンスまたはエラー・メッセージを送信する必要がある場合は、成功およびエラーのいずれの場合も、プロバイダABCSからJMSキューにメッセージを公開します。

図7-8に示すように、このモデルには2つのトランザクションがあります。

トランザクション1は、requesterABCSによるメッセージのデキュー、またはRequesterABCSを直接コールする外部アプリケーションで開始します。このトランザクションの場合は、プロバイダABCSがリプライまたはエラー・メッセージをJMSキューに公開して終了します。

図7-8 プログラミング・モデル1: エラー処理用に個別サービスを使用

7.4.3.2 プログラミング・モデル2: リクエスタABCSとEBS間でマイルストンとしてJMSキューを使用

図7-9に示すこのモデルでは、リクエスタABCSがインバウンド・メッセージをJMSマイルストンに公開します。トランザクションは、リクエスタABCSによるメッセージのデキュー、またはリクエスタABCSを直接コールする外部アプリケーションで開始します。トランザクションは、リクエスタABCSがメッセージをJMSキューに公開して終了します。

2番目のトランザクションは、JMSキューからメッセージをデキューし、EBSを呼び出して開始します。EBSは、インバウンド・メッセージを処理のためにProviderABCSにルーティングします。

メッセージ処理が成功した場合、プロバイダABCSは既存のトランザクション内でネイティブのバインディング・コールを使用して、レスポンスEBSを呼び出します。

メッセージ処理中にエラーが発生した場合、プロバイダABCSはエラー発生メッセージを別のJMSキューに公開します。レスポンスEBSはメッセージを受け取り、フォルト・ハンドラ・サービスを呼び出します

図7-9 プログラミング・モデル2: リクエスタABCSとEBS間でマイルストンとしてJMSキューを使用

ヒント:

エラーのシナリオの場合のみ、プロバイダABCS参照コンポーネントでこのキューを使用します。

7.4.3.3 プログラミング・モデル3: EBSでパラレル・ルーティング・ルールを使用

リクエスタABCSに到達したインバウンド・メッセージはEBSに渡されます。EBSは、パラレル・ルーティング・ルールを使用して、メッセージ処理のためにメッセージをプロバイダABCSにルーティングします。トランザクションは、リクエスタABCSによるメッセージのデキュー、またはリクエスタABCSを直接コールする外部アプリケーションで開始します。トランザクションは、EBSでキュー済の実行用にインバウンド・メッセージが保持されたときに終了します。

図7-10に、このプログラミング・モデルを示します。

2番目のトランザクションは、EBSからメッセージをデキューして開始します。メッセージ処理が成功した場合、プロバイダABCSは既存のトランザクション内で、レスポンスEBSへのネイティブのバインディング・コールを行います。レスポンスEBSは、別のreceiveアクティビティを呼び出して、リクエスタABCSへのレスポンスをルーティングします。エラーの場合、プロバイダABCSはWebサービス・コールを行ってレスポンスEBSを呼び出し、これによって新規トランザクションが開始されます。このトランザクションでは、レスポンスEBSが直接、またはリクエスタABCSを使用して、エラー・メッセージをアプリケーションに返信します。

図7-10 プログラミング・モデル3: EBSでパラレル・ルーティング・ルールを使用

7.4.4 このMEPを実装するのにプロバイダABCSで必要なタスク

タスクの詳細は、「非同期メッセージ交換でのプロバイダABCSの実装シナリオ」を参照してください。

7.5 非同期メッセージ交換でのプロバイダABCSの実装シナリオ

この項では、プロバイダABCSで非同期MEPを実装する際に必要なガイドラインを示します。

このMEPが推奨されるシナリオの詳細は、「非同期リクエスト/遅延レスポンスMEPを使用する場合」を参照してください。

プロバイダABCSは、一方向サービス・コール・パターンまたはリクエスト/遅延レスポンス・パターンのいずれかとして動作するように実装されます。

リクエスト/遅延レスポンス・パターンでは、プロバイダABCSは、EBSリクエスト・ルーティング・サービスからリクエスト・メッセージを受信し、そのメッセージを処理して、最後に、EBSリクエスト・ルーティング・サービスのレスポンス操作を呼び出して、要求側サービス(リクエスタABCSまたはエンタープライズ・ビジネス・フロー[EBF])に応答します。場合によっては、プロバイダABCSはレスポンスまたはエラー・メッセージ(あるいはその両方)をJMSキューに公開することもできます。EBSリクエスト・ルーティング・サービスはレスポンスを待機しません。

「プログラミング・モデル1: エラー処理用に個別サービスを使用」を参照してください。

すべてのプロバイダABCS (およびEBF)はコールバック操作を呼び出す機能を持つ必要がありますが、リクエスタがコールバックを必要とする場合のみ呼び出すためのスイッチ・ケースが必要です。EBMの動詞要素のresponseCode属性を評価して、要求側サービスでレスポンスが必要かどうかを判断します。

7.5.1 非同期MEPの実装方法

非同期MEPをプロバイダABCSに実装する手順は、次のとおりです。

1. 提供側サービスでリクエスト・メッセージのEBMヘッダーにフォルト情報を入力します。

レスポンスの要件を評価する前にプロバイダ・サービスでエラーが発生し、例外が発行された場合は、リクエスト・メッセージのEBMヘッダーにフォルト情報を入力します。これによって、フォルト・メッセージとともにリクエストEBM全体を処理のためにcatchブロックに渡すのが容易になります。

2. 提供側サービスにエラー処理を実装します。

特定のエラーで補正サービスを呼び出す必要がある場合は、EBSの補正操作が呼び出されて、リクエストを補正サービスにルーティングします。

詳細は、「エラー処理およびトレース・ロギング用のOracle AIAプロセスの構成」を参照してください。

3. 提供側サービスのEBMヘッダーに相関情報を入力します。

EBMヘッダーのEBMIDは、適切な要求側サービス・インスタンスへのレスポンス・メッセージの相関で使用します。図7-11に示すように、相関を容易にするには、提供側サービスのABMからEBMへの変換で、リクエスト・メッセージのEBMヘッダーのEBMIDを、レスポンス・メッセージのEBMヘッダーのRequestEBMIDにコピーする必要があります。

図7-11 CreateSalesOrderResponseEBMType要素の構造

変数でリクエスト・メッセージのEBMHeaderをABMからEBM XSLTに渡す方法については、「メッセージ変換の使用」を参照してください。

これは、リクエストEBMのEBMヘッダーからレスポンスEBMのEBMヘッダーに関連情報をコピーするために必要です。

4. 提供側サービスでレスポンス・メッセージのEBMヘッダーにフォルト情報を入力します。

レスポンスの要件を評価した後にプロバイダ・サービスでエラーが発生した場合は、レスポンス・メッセージのEBMヘッダー・フォルト・コンポーネントにフォルト情報を入力する必要があります。これによって、フォルト・メッセージとともにレスポンスEBMを処理のためにcatchブロックに渡すのが容易になります。

要求側サービスは、フォルト要素が入力されたレスポンスを受信します。

7.5.2 リクエスト/遅延レスポンス・パターンに対するプログラミング・モデルの使用

リクエスト/遅延レスポンス・パターンに対して、「非同期リクエスト/遅延レスポンスMEPでエラー・レスポンスを処理するためのプログラミング・モデル」で説明したプログラミング・モデルを使用する場合は、次のガイドラインに従ってください。

プログラミング・モデル1: エラー処理用に個別サービスを使用

プロバイダABCSがレスポンスまたはエラー・メッセージを送信する必要がある場合、メッセージ処理の成功とエラーの両方のシナリオで、プロバイダABCSはJMSキューにメッセージを公開する必要があります。

注意:

新規トランザクションは、JMSからメッセージをデキューして開始します。

プログラミング・モデル2: リクエスタABCSとEBS間でマイルストンとしてJMSキューを使用

メッセージ処理が成功した場合、プロバイダABCSは既存のトランザクション内でネイティブのバインディング・コールを使用して、レスポンスEBSを呼び出します。

メッセージ処理中にエラーが発生した場合、プロバイダABCSはエラー発生メッセージを別のJMSキューに公開します。レスポンスEBSはメッセージを受け取り、フォルト・ハンドラ・サービスを呼び出します

プログラミング・モデル3: EBSでパラレル・ルーティング・ルールを使用

プロバイダABCSには、レスポンスEBSコンポジットへの2つの参照があります。プロバイダABCSのEBSへの2番目の参照は、命名規則に従って名前を付けてください。

命名規則の詳細は、「AIA開発でのOracle AIAネーミング標準」を参照してください。

図7-12に、ResponseEBSへの2番目の参照がある非同期プロバイダABCSコンポジットを示します。2番目の参照のラベルは<EBS名>ErrorResponseEBSです。

図7-12 ResponseEBSへの2番目の参照がある非同期プロバイダABCSコンポジット

メッセージが正常に処理されると、プロバイダABCSはレスポンスEBSに対するコールバック操作を呼び出します。レスポンスEBSは、別のreceiveアクティビティを呼び出して、リクエスタABCSへのレスポンスをルーティングします。メッセージの処理中にエラーが発生した場合、プロバイダABCSは、レスポンスEBSへの2番目の参照からレスポンスEBSを呼び出します。この場合、responseEBSは、ネイティブ・コールではなく、SOAPコールを使用して呼び出されます。これを行うには、プロバイダABCSのコンポジットで、レスポンスEBSへの2番目の参照に次のプロパティを設定します。

<binding.ws port="<port>" location="<url>"/>
<property name="oracle.webservices.local.optimization type="xs:boolean">false</property>
</binding.ws>

注意:

エラーのシナリオの場合のみ、プロバイダABCS参照コンポーネントでこのプロパティを使用します。

7.5.3 サービスでのトランザクションの確認方法

トランザクションの確認方法の詳細は、「AIAサービスでのトランザクションの確認方法」を参照してください。

7.5.4 非同期リクエスト/遅延レスポンスMEPでのエラーの処理方法

「エラー処理およびトレース・ロギング用のOracle AIAプロセスの構成」を参照してください。

7.6 同期リクエスト/レスポンス・メッセージ交換の実装シナリオ

この項では、同期リクエスト/レスポンスMEPを実装する際に必要なガイドラインを示します。

このMEPが推奨されるシナリオの詳細は、「同期リクエスト/レスポンスMEPを使用する場合」を参照してください。

このシナリオでは、リクエスタABCSはEBSを同期的に呼び出します。EBSはプロバイダABCSを呼び出してレスポンスを待機します。同期性は、リクエスタABCS、EBSおよびプロバイダABCSのWSDLで明確にする必要があります。すべてのWSDLで、入出力メッセージを使用する操作を定義する必要があります。

7.6.1 サービスでのトランザクションの確認方法

このMEPでは、トランザクションをサポートする必要はありません。このMEPの実装に含まれるBPELプロセスには、中間プロセスのReceive、wait、Pick、onMessageアクティビティなどのブレークポイントはありません。

トランザクションの確認方法の詳細は、「AIAサービスでのトランザクションの確認方法」を参照してください。

7.6.2 同期リクエスト/レスポンスMEPでのエラーの処理方法

「エラー処理およびトレース・ロギング用のOracle AIAプロセスの構成」を参照してください。

7.6.3 レスポンス時間を短縮するためにサービスを最適化する方法

このMEPには一時サービス(ブレークポイント・アクティビティがないため、中間にデハイドレーションがない)の実装が含まれるため、失敗したインスタンスの場合のみBPELサービスの監査詳細を保持することをお薦めします。正常に完了した統合フローに関連付けられたサービス・インスタンスは、Oracle Enterprise Managerを使用して表示できません。この方法によって、レスポンス時間が大幅に短縮されます。

auditLevelプロパティには、監査証跡のロギング・レベルを設定します。この構成プロパティは、永続プロセスと一時プロセスの両方に適用されます。このプロパティが制御するのは、プロセスによってログに記録される監査イベントの量です。監査イベントを記録すると、audit_level表およびaudit_details表へのデータベース挿入が増えるため、パフォーマンスに影響が出ることがあります。監査情報は、Oracle Enterprise Managerコンソールからプロセスの状態を確認する目的でのみ使用されます。監査情報を保存しない場合は、Off値を使用します。監査レベルは、常にビジネス要件およびユースケースに従って選択してください。

同期のBPELプロセスの場合は、正常に完了したインスタンスのインスタンス詳細は保持しないことをお薦めします。このためには、auditLevelプロパティをサービス・コンポーネント・レベルでoffに設定します。この一般的なガイドラインは、ユースケースに基づいて個々のサービス用にオーバーライドできます。

7.7 エンタープライズ・ビジネス・サービスの呼出し

この項では、ABCSからEBSを呼び出し、EBSの操作を使用するためのガイドラインを示します。ここでは、EBS操作の呼出し側の観点から説明するため、実装の観点からEBS操作を理解するのにも役立ちます。

この項には次のトピックが含まれます:

- Create

- Update

- Delete

- Sync

- Validate

- Process

- Query

これらの各項では、次の状況における各動詞の詳細を説明します。

- いつ動詞を使用するか

- 動詞を使用するときのコンテンツ・ペイロードは何か

- 動詞の属性は何か(ある場合)

- 対応するレスポンス動詞は何か(ある場合)

- レスポンス動詞のコンテンツ・ペイロードは何か

7.7.1 Create

Create動詞は、Createメッセージのペイロードで提供される情報を使用してビジネス・オブジェクトを作成するためのリクエストを示します。これは、ビジネス・オブジェクトのインスタンスを作成するための操作で使用されます。

Create動詞を使用する場合

サービス・リクエスタとサービス・プロバイダの両方に同じオブジェクトがある場合は、Sync動詞を使用するほうが適切です。ただし、Syncを使用するには、サービス・プロバイダがSync操作を実装していることが条件になります。

Create操作はフロントエンドの顧客管理システムでの使用が一般的で、顧客からサービス・リクエストを取得し、指定された情報に基づいて、顧客にサービスするための作業指示を作成するように作業指示システムにリクエストします。

Create動詞はコンポジット操作では使用されず、ビジネス・オブジェクトの1つ(リストの場合は1つ以上)のインスタンスが常に作成されます。

コンテンツ・ペイロード

通常、Create動詞を使用する操作のペイロードは完全なビジネス・オブジェクトで、すべてのビジネス・オブジェクトにはCreate操作を使用する2つのメッセージ(単一およびリスト)のみ含まれるのが一般的です。

動詞属性

Create動詞には、レスポンス・メッセージで必要なペイロードをCreateリクエストに通知する、オプションのResponseCode属性があります。ResponseCodeの可能な値は、ID (レスポンス・ペイロードは、作成されたオブジェクトの識別子です)またはOBJECT (レスポンス・ペイロードは、作成されたオブジェクト全体です)のいずれかに制限されます。

対応するレスポンス動詞

Create動詞は、各Create EBMのレスポンス・メッセージで使用されるCreateResponse動詞とペアになっています。CreateメッセージのResponseCode属性を設定することによって、元のリクエスト・メッセージがレスポンスを明示的にリクエストしている場合のみ、レスポンスがターゲット・アプリケーションによって提供される必要があります。

レスポンス・コンテンツ・ペイロード

レスポンス動詞のペイロード・タイプは、常にCreate Request操作のペイロード・タイプに基づきます。ユーザーのカスタマイズをサポートする必要がある場合は、別のタイプとして実装されます。

7.7.2 Update

Update動詞は、Updateメッセージで提供されるペイロードを使用してオブジェクトを更新するための、サービス・プロバイダへのリクエストを示します。これは、ビジネス・オブジェクトの1つ以上のプロパティ、またはビジネス・オブジェクトの配列を更新するための操作で使用されます。

Update動詞を使用する操作は、コンテンツを作成または更新する必要があり、他の操作の編成は不可です。

Update動詞を使用する場合

Createと同様に、ビジネス・プロセスでUpdate操作が呼び出されるのは、主として、呼出しをトリガーするソース・イベントが要求側システムにおけるオブジェクトの更新でない場合です。サービス・リクエスタとサービス・プロバイダの両方に同じオブジェクトがある場合は、Sync動詞を使用するほうが適切です。ただし、Syncを使用するには、サービス・プロバイダがSync操作を実装していることが条件になります。

Update操作の例として、受け入れた品目の数量で注文書明細を更新する受入システムや、顧客の住所やその他の情報で顧客レコードを更新する注文獲得システムがあります。

Update動詞を使用するEBMのビジネス・ペイロードに含まれるコンテンツは、ターゲット・アプリケーションで更新が必要なフィールドのみであると想定されます。Update動詞は、ビジネス・コンポーネントおよび共有コンポーネントのActionCodeプロパティを使用して、処理指示をターゲット・システムに通知します。これは、階層的で複数レベルのオブジェクトで、更新が子レベルで発生する場合に必要です。

ActionCodeプロパティは、親と複数のカーディナリティ関係を持つすべてのコンポーネントのEBOに存在します。ActionCodeの可能な値は、Create、UpdateおよびDeleteです。これは、適用される処理アクションをそのビジネス・コンポーネントに通知するために、Update動詞でのみ使用されます。ActionCodeが適用されるのはオブジェクトに子ビジネス・コンポーネントがある場合のみで、ない場合はActionCodeは不要で、この情報を伝達するには動詞のみで十分です。

ActionCodeのユースケースの1つは、購買依頼がセルフサービス購買依頼システムで更新され、購買依頼のコピーを保守している購買システムに、更新されたこの情報を通知する必要がある場合です。

ユーザーが購買依頼を更新して、(1つのトランザクションで)次のアクションを実行するとします。

- 購買依頼ヘッダーの説明を更新します

- 新しい購買依頼明細(明細番号4)を追加します

- 購買依頼明細(明細番号3)の品目を変更します

- 購買依頼明細(明細2)を削除します

- 購買依頼明細の会計配分を変更し、新規の会計配分(明細1)を追加します

例7-1に、前述の変更を通知するインスタンスXMLドキュメントのDataAreaビジネス・ペイロードの内容を示します。

コンテンツ・ペイロード

通常、Update動詞を使用する操作のペイロードはEBO全体で、すべてのビジネス・オブジェクトにはUpdate操作を使用する2つのメッセージ(単一およびリスト)のみ含まれるのが一般的です。

EBOのサブセットの更新が必要な状況が発生した場合、複数の更新メッセージが存在し、それぞれペイロードが異なる可能性があります。SalesOrderLineのみ含まれるペイロードがあるUpdateSalesOrderLineEBMメッセージはその一例です。

動詞属性

Update動詞には、レスポンス・メッセージで必要なペイロードをUpdateリクエストに通知するための、オプションのResponseCode属性があります。ResponseCodeの可能な値は、ID (レスポンス・ペイロードは、作成されたオブジェクトの識別子です)またはOBJECT (レスポンス・ペイロードは、作成されたオブジェクト全体です)のいずれかに制限されます。

対応するレスポンス動詞

Update動詞は、各Update EBMのレスポンス・メッセージで使用されるUpdateResponse動詞とペアになっています。UpdateメッセージのResponseCode属性を設定することによって、元のリクエスト・メッセージがレスポンスを明示的にリクエストしている場合のみ、レスポンスがターゲット・アプリケーションによって提供される必要があります。Updateリクエストで指定されるResponseCodeに応じて、レスポンスのペイロードはIDまたは更新済のオブジェクト全体のいずれかです。

レスポンス・コンテンツ・ペイロード

レスポンス動詞のペイロード・タイプは、常にUpdate Request操作のペイロード・タイプに基づきます。ユーザーのカスタマイズをサポートする必要がある場合は、別のタイプとして実装されます。

例7-1 Update

<UpdateRequisition actionCode="Update">   Root Action Code not processed
<Description>New Description</Description>
<RequisitionLine actionCode="Update"> Indicates that some property or
association of this line is being updated. In this example, the accounting
distribution Percentage has been updated for Line 1, and a new
AccountingDistribution line has been added
<Identification>
<ID>1</ID>
</Identification>
< RequisitionAccountingDistribution actionCode="UPDATE">
<Identification>
<ID>1</ID>
</Identification>
<AccountingDistribution>
<Percentage>15</Percentage>
</AccountingDistribution>
< /RequisitionAccountingDistribution>
< RequisitionAccountingDistribution actionCode="ADD">
<Identification>
<ID>3</ID>
</Identification>
<AccountingDistribution>
<Percentage>15</Percentage>
</AccountingDistribution>
< /RequisitionAccountingDistribution>
</RequisitionLine>
<RequisitionLine actionCode="DELETE"> Indicates this line has been deleted
<Identification>
<ID>2</ID>
</Identification>
</RequisitionLine>
<RequisitionLine actionCode="UPDATE">
<Identification>
<ID>3</ID>
</Identification>
<ItemReference>
<Identification>
<ID>1001</ID>
</Identification>
</ItemReference>
</RequisitionLine>
</RequisitionLine>
<RequisitionLine actionCode="ADD"> Indicates this line has been added
<Identification>
<ID>4</ID>
</Identification>
<ItemReference>
<Identification>
<ID>1005</ID>
</Identification>
</ItemReference>
</RequisitionLine>
</UpdateRequisition>

7.7.3 Delete

Delete動詞は、Deleteメッセージのペイロードで提供されるオブジェクト識別を使用して特定するビジネス・オブジェクトを削除するための、サービス・プロバイダへのリクエストです。

Delete動詞を使用する場合

Delete動詞は、ビジネス・オブジェクトを削除する操作で使用されます。

Delete動詞を使用する操作は、コンテンツを削除する必要があり、他の操作の編成は不可です。

注意:

現在、AIAでは、ビジネス・オブジェクトのコンポーネントに対するDeleteの使用はサポートされておらず、Delete Purchase Order Lineは可能です。

コンテンツ・ペイロード

Delete動詞のペイロードは、削除するビジネス・オブジェクトを一意に識別するidentification要素のみである必要があります。

動詞属性

Delete動詞には、レスポンス・メッセージで必要なペイロードをUpdateリクエストに通知するための、オプションのResponseCode属性があります。DeleteのResponseCodeの可能な値は、ID (レスポンス・ペイロードは、作成されたオブジェクトの識別子です)のみです。

対応するレスポンス動詞

Delete動詞は、各Delete EBMのレスポンス・メッセージで使用されるDeleteResponse動詞とペアになっています。DeleteメッセージのResponseCode属性を設定することによって、元のリクエスト・メッセージがレスポンスを明示的にリクエストしている場合のみ、レスポンスがターゲット・アプリケーションによって提供される必要があります。ResponseCodeの可能な値はIDのみです。

7.7.4 Sync

Sync動詞は、Syncメッセージで提供されるペイロードを使用してオブジェクトに関する情報を同期するための、サービス・プロバイダへのリクエストを示します。

Sync動詞を使用する場合

Sync動詞は、操作のペイロードを受け取り、必要に応じてビジネス・オブジェクトを作成または更新する操作をアプリケーションが提供する状況で使用されます。

Sync動詞を使用する操作は、コンテンツを作成または更新する必要があり、他の操作の編成は不可です。

Syncが使用されるのはバッチ・トランザクションが一般的で、オブジェクトの現在の状態は判明しているが、前回の同期と現在の同期の間でどのように変更されたかが不明な場合です。また、Syncを使用して、オブジェクトの各インスタンスを同期できます。通常、Syncのイニシエータは、同期されるデータを所有するシステムです。

Sync操作を使用することは、ソース・システムとターゲット・システムの両方にオブジェクトが存在し、Syncによってソースとターゲットのコンテンツが同じになることを意味します。Syncは二重の処理指示が含まれる点で他の動詞と異なり、コンテンツの作成および既存のコンテンツの更新の両方を行うことができます。

Syncのコンテンツは、メッセージを生成するシステム内のオブジェクトの現在の状態を反映します。このモードでは、1つのSyncメッセージに名詞のインスタンスを複数含めることができ、インスタンスに特定の変更インディケータはありません。ソース・システムでメッセージが生成され、そのメッセージをサブスクライブするすべてのシステムでデータを同期して、メッセージのコンテンツを反映する必要があります。

Syncは頻繁に変更されないマスター・データ管理シナリオの場合に最も実践的な方法で、データをリアルタイムに同期するのは運用上の観点から実践的ではなく必要ありません。

Sync動詞にはオプションのsyncActionCode属性があり、Syncメッセージの受信者に必要な処理動作をさらに指示するのに使用できます。syncActionCodeの可能な値は次のとおりです。

- CREATE_REPLACE:
syncActionCodeが指定されていない場合は、これがSyncのデフォルト動作です。syncActionCode属性が指定されていないか、syncActionCode属性値がNULLまたはCREATE_REPLACEのSyncメッセージを受信するターゲット・システムでは、ターゲット・システムにオブジェクトが存在しない場合はオブジェクトを作成し、存在する場合は、Syncメッセージで提供された定義にオブジェクト全体を置き換える必要があります。

- CREATE_UPDATE:
syncActionCodeの値がCREATE_UPDATEのSyncメッセージは、ターゲット・システムにオブジェクトが存在しない場合はオブジェクトを作成し、存在する場合は、Syncメッセージで提供されたコンテンツでオブジェクトを更新するように処理される必要があります。

コンテンツ・ペイロード

一般的に、EBOごとにSyncメッセージは1つのみで(単一およびリスト実装による)、メッセージのペイロードはEBO全体です。

ビジネス・オブジェクト全体を同期するには、常にSyncを使用する必要があります。ビジネス・オブジェクトの異なる名前のビューが複数存在するが、ビジネス・オブジェクトの特定のコンポーネントは同期しない場合、複数のSyncメッセージが存在する可能性があります。

ヒント:

SyncのOAGIS実装とは異なり、Oracle AIAでは、追加、変更、置換および削除を示す特定の属性がSyncにありませんでした。Syncのエンタープライズ・オブジェクト・ライブラリ(EOL)実装は、メッセージ・ペイロードで指定された内容にターゲット・オブジェクトを正確に変更するための動詞です。Syncはコンテンツの削除には使用できず、コンテンツを削除する場合は明示的な削除操作を使用する必要があります。

動詞属性

Sync動詞には、レスポンス・メッセージで必要なペイロードをSyncリクエストに通知するための、オプションのResponseCode属性があります。SyncのResponseCodeの可能な値は、OBJECT (レスポンス・ペイロードは、作成または更新されたオブジェクト全体です)およびID (レスポンスは、作成または更新されたオブジェクトのIDのみです)に制限されます。

対応するレスポンス動詞

Sync動詞は、各Sync EBMのレスポンス・メッセージで使用されるSyncResponse動詞とペアになっています。SyncメッセージのResponseCode属性を設定することによって、元のリクエスト・メッセージがレスポンスを明示的にリクエストしている場合のみ、レスポンスがターゲット・アプリケーションによって提供される必要があります。

注意:

設計の意図は、2つの動詞を同じ目的で使用することを避けることです。Sync動詞はオブジェクトの作成もサポートしていますが、ソース・システムとターゲット・システムの両方にオブジェクトが存在するシナリオで主に使用することを意図しています。つまり、Syncを動詞として使用する意味は、同期するオブジェクトがソースとターゲットの両方に存在するという事実を受信アプリケーションに通知することです。これに対して、CreateまたはUpdateは、作成または更新するオブジェクトがソース・システムに存在しないという事実を通知するために使用します。

レスポンス動詞コンテンツ・ペイロード

レスポンス動詞のペイロード・タイプは、常にSync Request操作のペイロード・タイプに基づきます。ユーザーのカスタマイズをサポートする必要がある場合は、別のタイプとして実装されます。

7.7.5 Validate

Validate動詞は、メッセージのペイロードで提供されるコンテンツを検証するための、サービス・プロバイダへのリクエストです。これは、データの有効性を検証するための操作で使用されます。

Validate動詞を使用する場合

Validate動詞を使用する操作では、ビジネス・オブジェクトの作成や更新は実行されず、他の操作の編成として内部的に実装できます。たとえば、承認のために注文書を検証する場合は、予算があるかどうか、サプライヤがアクティブかどうか、明細に品目が必要な購買依頼が有効かどうかなどを検証します。

コンテンツ・ペイロード

Validateカテゴリに該当する操作のペイロードには、ビジネス・オブジェクト、ビジネス・オブジェクトのビジネス・コンポーネント、またはその他のユーザー定義ペイロードがあります。

動詞属性

なし。

対応するレスポンス動詞

Validate動詞は、各Validate EBMのレスポンス・メッセージで使用されるValidateResponse動詞とペアになっています。Validate動詞は、常に同期的に実装されます。

レスポンス・コンテンツ・ペイロード

Validate操作のレスポンス・ペイロードはユーザー定義が可能です。

7.7.6 Process

Process動詞は、サービスに関連付けられたビジネス・オブジェクトに対応する操作を実行するための、サービス・プロバイダへのリクエストです。通常は、他の複数の操作を編成したり、特定のビジネス結果を達成するのに必要な操作で使用されます。

Process動詞を使用する場合

Processは、特定のビジネス・オブジェクト・アクションに対して複数の動詞が使用されるのを避けるために、コンテンツが更新されるがCreate/Update/Deleteカテゴリには該当しないすべてのビジネス操作をカテゴリ化する単独の動詞として使用されます。

Process動詞を使用する操作は、常に1つ以上のビジネス・オブジェクトが作成または更新される必要があり、他の操作の編成を表すことができます。

Process動詞は、単一のビジネス・オブジェクトに対して動作する操作でも使用できますが、Update操作を使用して通信できないビジネス上の特定の意味があります。通常、このようなアクションは、異なるアクセス制御、およびアクションの実行時に適用可能な特定のビジネス・ルールを使用してアプリケーションに実装されます。このようなアクションの例として、状態の変更、機器のメーター値の更新などがあります。

Process動詞によって複数の操作を実行できるため、特定のEBSで複数のProcess動詞を使用することも可能です。

ヒント:

Process動詞を実装する操作は、同期または非同期で実装できます。これは、動詞を使用するすべての操作で一貫性のある実装パターンが適用される他の動詞とは異なります。

コンテンツ・ペイロード

Process動詞によって実行される操作の特性により、操作が実行されるビジネス・オブジェクトに含まれないが、操作によって実装されるビジネス・ルールでは必要なプロパティや値が必要になる場合があります。たとえば、受注の承認では、承認の一部としてコメントを記録できますが、コメント自体は受注のプロパティではありません。

通常、Process動詞を使用する操作のリクエストおよびレスポンス・ペイロードはアプリケーションのメソッド・シグネチャを反映できる必要があり、ペイロードを形成するコンテンツは、サービス操作が関連付けられたビジネス・オブジェクトから取得する必要があるという制限はありません。

これをサポートするために、各Process操作のペイロードはEBO定義からのコンテンツに制限されません。これは、EBMビジネス・コンテンツがEBOコンテンツまたはそのサブセットと同じ必要がある他のすべてのEBOと異なります。

注意:

現在、AIAでは、他のビジネス・コンポーネントからのコンテンツを使用するProcess EBMペイロードのアセンブルをサポートしていません。したがって、顧客パーティに対して定義されるクレジット検証のProcess操作では、Sales Order EBOからのコンテンツを含めてメッセージ・ペイロードを作成できません。

他の汎用動詞で使用されるリスト・パターンも適用可能ですが、一般的には適用しません。つまり、EBSには、Process操作の単一およびリスト実装の両方、またはいずれか1つが存在できます。すべてのEBOに対して単一およびリストの両方が一貫して作成される他の汎用動詞とは異なり、Processは対応する操作の要件によって動作します。

動詞属性

なし。

対応するレスポンス動詞

Process動詞は、各Process EBMのレスポンス・メッセージで使用されるProcessResponse動詞とペアになっています。

レスポンス動詞ペイロード

レスポンス動詞のペイロードは、各Process操作に固有で、操作の目的によって決まります。Process動詞のペイロードと同様に、レスポンスのコンテンツはEBOのコンテンツに制限されるという制限はありません。

7.7.7 Query

Query動詞は、Queryメッセージのペイロードで提供されるコンテンツを使用してビジネス・オブジェクトに対して問合せを実行し、問合せに関連付けられた対応するレスポンス・メッセージを使用して問合せ結果を返すための、サービス・プロバイダへのリクエストです。オプションで、リクエスタはレスポンス・ペイロードの特定のサブセットをリクエストできます。

Query動詞を使用する場合

他の動詞と同様に、単一およびリスト・パターンが問合せにも適用されます。次の各項では、これらの各パターンに対するQueryの使用がリストされています。

ヒント:

同じ動詞が両方のパターンに適用されますが、適用可能な実装および属性は完全に異なります。

1つのインスタンスのみを返す単一オブジェクト問合せ

単一オブジェクト問合せ操作は、コール元がEBOを識別子で参照できる単純なIDによる取得操作です。これは、オブジェクトのIDを指定し、オプションでQueryCodeとResponseCodeをパラメータとその値のセットとともに指定して、ビジネス・オブジェクトの単一インスタンスをリクエストします。オブジェクトの識別子は、Query EBMのDataAreaで指定されます。

単一オブジェクト問合せでは、問合せで複数のオブジェクトが返される可能性を最小限にするために、他の問合せ基準はサポートされておらず、単純問合せのレスポンス・ペイロードは、問い合せるオブジェクトの単一インスタンスに制限されます。

単一オブジェクト問合せには次の要素が含まれます。

- Query要素内のQueryCode (オプション)
単一オプション問合せのQueryCodeは主に、問合せのDataAreaで指定されるIdentification要素の補足として使用されます。問合せコードは、問合せを正常に実行するためにIDに加えて問合せサービス・プロバイダに通知する必要がある場合に、単一オブジェクト問合せで使用できます。コードは、問合せを調整したり、問合せコードに基づいて問い合せるオブジェクトを選択するために使用できます。

ヒント:

これを実現するために、サービス・プロバイダはこのようなコードの処理を実装する必要があります。現在、Oracle AIAでは、EOLの一部として汎用の問合せコードは事前定義されていません。

- Query要素内のResponseCode (オプション)
ResponseCodeは、EBOのレスポンス・コンテンツをレスポンス・オブジェクトの特定のサブセットにフィルタ処理するように問合せサービス・プロバイダに指示する事前定義されたコードです。

汎用問合せの戻りペイロードは常にEBO全体で、デフォルトでは、QuerySalesOrder操作のレスポンス・ペイロードは常に、明細や出荷などを含むSalesOrder全体です。リクエスタがサービス・プロバイダに対して、子コンポーネントは不要でSalesOrderヘッダーのみを提供するようにリクエストする場合は、ResponseCodeをサービス・プロバイダへの指示として使用し、それに従ってレスポンス・ペイロードを作成できます。

ヒント:

これを実現するために、サービス・プロバイダはこのようなコードの処理を実装する必要があります。現在、Oracle AIAでは、EOLの一部として汎用のリクエストまたはレスポンス・コードは事前定義されていません。

コンテンツ・ペイロード

単一オブジェクト問合せのペイロードは常に、問い合せるオブジェクトのIDです。例7-2に示すように、これはDataAreaのIdentification要素内で指定します。

動詞属性

単純問合せにはオプションのgetAllTranslationsIndicatorがあり、翻訳可能なすべての要素について、サービス・プロバイダがすべての翻訳をレスポンスに挿入する必要があるかどうかを指定します。デフォルトでは、リクエストの言語でのみデータを返します。

前の説明に基づいて、複数の方法で単純問合せを作成できます。

- IDのみを使用する単純問合せ:
単一オブジェクトの問合せ例として、ID="3006"を使用した注文書の問合せがあります。この例では、他のコードやパラメータは必要ありません。

- QueryCodeを使用する単純問合せ:
例として、個人顧客と組織顧客の区別を保守するアプリケーションを考えてみます。単一顧客問合せサービスが存在しますが、問合せを正常に実行するために、サービス・プロバイダは問い合せるIDが組織に属するか個人に属するかを指示される必要があります。この場合は、QueryCodeを使用して個人/組織情報を通知できます。

複数のインスタンスを返すことができるリスト問合せ

単一オブジェクト問合せでは、IDによる単純検索以外の検索基準をサポートしておらず、オブジェクトの1つのインスタンスのみ返すことができます。その他の問合せはすべてリスト問合せとして扱われます。

リスト問合せは、問合せへのレスポンスで複数のレコードを返すことができ、複雑な問合せを作成する機能をサポートしています。

リスト問合せは、次の要素を使用して実装されます。

Query要素内のQueryCode (オプション)

リスト問合せのQueryCodeは、サービス・プロバイダがリスト問合せを使用して作成できる問合せを制限する方法として機能します。QueryCodeを使用しない場合、サービス・プロバイダは一般的に、後述するQueryCriteria要素を使用して通知できるすべての問合せをサポートできます。

これを実現するために、サービス・プロバイダはこのようなコードの処理を実装する必要があります。現在、Oracle AIAでは、EOLの一部として汎用の問合せコードは事前定義されていません。

Query要素内のResponseCode (オプション)

ResponseCodeは、EBOのレスポンス・コンテンツをレスポンス・オブジェクトの特定のサブセットにフィルタ処理するように問合せサービス・プロバイダに指示する事前定義されたコードです。リスト問合せの場合、これは問合せのResponseFilter要素を指定するかわりの代替メカニズムとして機能できます。

汎用問合せの戻りペイロードは、常にEBO全体です。たとえば、デフォルトでは、QuerySalesOrder操作のレスポンス・ペイロードは常に、明細や出荷などを含むSalesOrder全体です。リクエスタがサービス・プロバイダに対して、子コンポーネントは不要でSalesOrderヘッダーのみを提供するようにリクエストする場合は、ResponseCodeをサービス・プロバイダへの指示として使用し、それに従ってレスポンス・ペイロードを作成できます。

これを実現するために、サービス・プロバイダはこのようなコードの処理を実装する必要があります。現在、Oracle AIAでは、EOLの一部として汎用のリクエストまたはレスポンス・コードは事前定義されていません。

QueryCriteria (1からn個のインスタンス)

QueryCriteria要素を使用すると、ユーザーは、問い合せるオブジェクトの特定ノード上に複雑な問合せ文を作成できます。リスト問合せでは、少なくとも1つのQueryCriteria要素を指定する必要があります。

問い合せるオブジェクトの複数ノードに問合せ範囲がわたる場合、1つの問合せに複数のQueryCriteria要素が存在できます。複数の問合せ基準は、1つの問合せ基準の結果セットが2番目の基準でフィルタ処理されて、レコードのサブセットがさらに絞り込まれていく部分選択に似ています。

各QueryCriteria要素の構成は次のとおりです。

- QualifiedElementPath (0または1個のインスタンス):
これを使用すると、ユーザーはQueryCriteriaを適用するノードを指定できます。要素が問合せに含まれていない場合、要素が含まれているが値がないかNULL値の場合、または要素の値が/の場合、問合せ基準はオブジェクトのルート要素に適用されます。

QueryExpression (1個のインスタンスのみ、オプションで他のQueryExpressionがネストする): この要素は、実際の問合せのコンテナです。QueryExpressionはネストされた構造で、これによって複雑な問合せを定義できます。各QueryExpressionの構成は次のとおりです。

- logicalOperatorCode属性(可能な値はANDまたはORのいずれか)。これらの属性を指定して、QueryExpression内のコンテンツ(ネストされた複数のQueryExpressionまたはValueExpressionのリスト)に対して実行される論理演算を指定できます。

- 1つ以上のQueryExpressionまたは1つ以上のValueExpressionの選択。

- 1つのQueryExpressionに他の複数のQueryExpressionを含めることができ、その場合は問合せ内で複数のANDまたはOR演算を結合する必要があります。

- 問合せが1つのANDまたはOR演算子を使用して表すことができる場合は、外側のQueryExpression内に複数のValueExpressionを使用して作成できます。

- ValueExpression (1個以上のインスタンス):
各ValueExpressionは、QualifiedElementPath (QualifiedElementPathが存在しない場合はルート・ノード)で表されるノード内での特定ノードへの値の割当を表します。ValueExpressionは次を使用して指定されます。

- 問合せ値が割り当てられるノード(simpleXPath式として表される)、またはコード(ドキュメントに要素が見つからない場合)のいずれかを表すElementPath要素。たとえば、/SalesOrderLine/Status/CodeまたはStatusCodeです。ElementPathに含まれるのがコードかXpath式かを示す明示的な方法はありません。

- ElementPathに割り当てられた値を含むValue要素(例: Approved)。

- ElementPathに割り当てられた値に適用可能な演算子を指定するqueryOperatorCode属性。可能な演算子は、EQUALS、NOT_EQUALS、GREATER_THAN、GREATER_THAN_EQUALS、LESS_THAN、LESS_THAN_EQUALS、CONTAINS、DOES_NOT_CONTAIN、LIKE、NOT_LIKE、LIKE_IGNORE_CASE、NOT_LIKE_IGNORE_CASE、IS_BLANK、IS_NOT_BLANK、BETWEEN、NOT_BETWEEN、IN、NOT_INです。

- SortElement (0個以上のインスタンス):
例7-4に示すように、各QueryCriteriaには1つ以上のSortElementを定義できます。SortElementを使用して、SortElementに指定された基準を使用して問合せ結果セットをソートするようにリクエストします。各SortElementにはオプションのsortDirectionCode属性があり、ソート順としてASC (昇順)またはDESC (降順)を識別します。

例7-4では、QueryExpressionの結果セットがOrderDateTimeの降順およびDescriptionの昇順にソートされます。

複数のQueryCriteriaが存在する場合は、例7-5に示すように、それぞれに独自のSortElementがあります。1つのQueryCriteriaの結果セットがソートされた後に、次のQueryCriteriaフィルタが適用され、そのQueryCriteriaで指定されたSortElementを使用して結果のサブセットがソートされます。

例7-5では、SalesOrderルート問合せがOrderDateTimeとDescriptionによってソートされ、子ノードのSalesOrderLineは価格でソートされます。

QueryCriteriaの例

例

単一のQueryCriteria要素および単一のQuery Expressionを持つ問合せ

例7-3は、単一のQueryCriteria要素、およびValueExpression要素のみが含まれる単一のQueryExpression要素を持つ問合せの例です。実行される問合せはQuery SalesOrderで、"SalesOrder/CurrencyCode = "USD" AND "SalesOrder/OrderDateTime = "2003-12-04"です。問合せ式はルート・ノードに定義されているため、QualifiedElementPathはありません(オプション)。

これは、QueryExpression内にネストされた2つのValueExpressionとしてモデル化されています。QueryExpressionにあるlogicalOperatorCodeは、2つのValueExpressionで実行される演算(AND)を示します。

単一のQueryCriteriaおよびネストされたQueryExpressionを持つ問合せ

図7-13は、単一のQueryCriteriaおよびネストされたQueryExpressionを持つ問合せの例です。実行される問合せはQuery SalesOrdersで、SalesOrder/CurrencyCode=USD AND SalesOrder/OrderDateTime<2003-12-04 OR SalesOrder/Description CONTAINS "BMW 520i"です。両方の問合せ式はルート・ノードに定義されているため、QualifiedElementPathはありません(オプション)。

注意: ネストされたQueryExpressionが存在する場合、それらはすべて同じQualifiedElementPath上にあります。

これは、外部のQueryExpression内にネストされた2つのQueryExpressionとしてモデル化されています。

外部のQueryExpressionは、内部の2つのQueryExpressionに適用されるオペランド(OR)を識別します。図7-13に示すように、ValueExpressionには、実際の問合せデータとともに、データ要素に適用される問合せ演算子が含まれます。

図7-13 ネストされたQuery Expressionを持つ問合せの例

複数のQueryCriteriaを持つ問合せ

例7-6は、複数のQueryCriteriaを持つ問合せの例です。複数のQueryCriteriaが存在する場合、それらに適用可能な論理演算は存在せず、1番目のQueryCriteria要素で指定された問合せが実行され、次に2番目のQueryCriteriaが1番目の結果に適用されるのと同等です。

実行される問合せはQuery CustomerPartyで、Type = GOLD、結果セットはステータスが"ACTIVE"なアカウントのみにフィルタ処理されます。

これは2つのQueryCriteriaとして実装されます。1番目は、CustomerPartyを問い合せて、TYPEが"GOLD"の顧客をすべて取得します。この問合せは、CustomerPartyルート・ノードで実行されます。

次に、この問合せの結果セットは、2番目のQuery Criteriaを適用してフィルタ処理されます。これは、CustomerParty/Accountノードを問い合せて、STATUS = "ACTIVE"のCustomerPartyアカウントをすべて取得します。

ResponseFilter (0から1個のインスタンス)

ResponseFilterを使用すると、リクエスタは対象または対象外の子ノードを指定できます。除外された子ノードは、問合せへのレスポンスが作成されるときに挿入されません。この機能が参加アプリケーションによってサポートされている場合は、問合せから除外されたノードを問い合せないことによってパフォーマンスが向上します。

例

QueryInvoiceメッセージへの単一の戻しのリクエスト

例7-7に、QueryInvoiceメッセージへのレスポンスでInvoiceLineのみ戻すリクエストを示します。

QueryInvoiceメッセージへの特定のメッセージ戻しのリクエスト

例7-8は、ChargeとPaymentTermを除くすべてのQueryInvoiceメッセージ・コンテンツを戻す例です。

ヒント:

理論上は問合せを作成する方法は無限にあり、サービス・プロバイダはQueryCriteriaが指定される可能なすべての方法を処理できないため、問合せを処理するための包括的なフレームワークを使用しないと、このオプションを実際に実装するのは困難です。

コンテンツ・ペイロード

リスト問合せで使用できるコンテンツ・ペイロードはなく、問合せはDataAreaの動詞要素内で完全に定義されます。

動詞属性

- getAllTranslationsIndicator(オプション):
問合せにはオプションのgetAllTranslationsIndicatorがあり、翻訳可能なすべての要素について、サービス・プロバイダがすべての翻訳をレスポンスに挿入する必要があるかどうかを指定します。デフォルトでは、リクエストの言語でのみデータを返します。

- recordSetStart(オプション):
これは、問合せサービス・プロバイダに対して、問合せ結果セットからレコードのサブセットを返し、この属性に指定した番号を最初のレコードの索引に付けるように指示します。

例として、結果セットに200レコードを返す問合せを考えてみます。リクエスタがrecordSetStartパラメータを"101"に設定して問合せを呼び出した場合、サービス・プロバイダはこの値を処理し、結果セットの101番目から200番目のレコードを含む結果セットを作成する必要があります。

- recordSetCount(オプション):
この属性は、サービス・プロバイダに対して、問合せへのレスポンスでレコード件数とともに同じ属性を返すように指示します。この属性を使用しない場合、問合せへのレスポンスでレコード・セット件数は不要です。

- maxItems(オプション):
これは、問合せサービス・プロバイダに対して、問合せレスポンスで返されるレコードの最大数がこの属性に指定した値を超えないように指示します。

問合せの結果セットには問合せ基準を満たす複数のレコードが含まれる場合がありますが、問合せサービス・リクエスタは特定のレコード数のみを一度に処理できます。たとえば、問合せによって1000レコードの結果セットが作成されましたが、問合せリクエスタは一度に100レコードのみ処理できます。サービス・リクエスタはmaxItems属性を使用して、サービス・プロバイダに対してレスポンスで100レコードのみ返すように指示できます。

対応するレスポンス動詞

Query動詞は、各Query EBMのレスポンス・メッセージで使用されるQueryResponse動詞とペアになっています。

レスポンス動詞ペイロード

通常、レスポンス動詞のペイロードはビジネス・オブジェクト全体です。

例7-2 単一オブジェクト問合せのコンテンツ・ペイロード

<QueryAccountBalanceAdjustmentEBM>
<corecom:EBMHeader>

</corecom:EBMHeader>
<DataArea>
<Query>
</Query>
<QueryAccountBalanceAdjustment>
<corecom:Identification>
<corecom:ID>1005</corecom:ID>

</corecom:Identification>
<Custom/>
</QueryAccountBalanceAdjustment>
</DataArea>
</QueryAccountBalanceAdjustmentEBM>

例7-3 単一のQueryCriteriaに対するSortElementの定義

<Query>
<QueryCriteria>
<QueryExpression logicalOperatorCode="AND">
<ValueExpression queryOperatorCode="EQUALS">
<ElementPath>/SalesOrderBase/CurrencyCode</ElementPath>
<Value>USD</Value>
</ValueExpression>
<ValueExpression queryOperatorCode="GREATER_THAN_EQUALS">
<ElementPath>/SalesOrderBase/OrderDateTime</ElementPath>
<Value>2003-12-04</Value>
</ValueExpression>
</QueryExpression>
</QueryCriteria>
</Query>

例7-4 複数のQueryCriteriaに対するSortElementの定義

<QueryCriteria>
<QueryExpression>
<ValueExpression>

</ValueExpression>
</QueryExpression>
<SortElement sortDirection="DESC">/OrderDateTime</SortElement>
<SortElement sortDirection="ASC">/Description</SortElement>
</QueryCriteria>

例7-5 単一のQueryCriteria要素および単一のQueryExpressionを持つ問合せの例

<QueryCriteria>
<QueryExpression>
<ValueExpression>

</ValueExpression>
</QueryExpression>
<SortElement sortDirection="DESC">/OrderDateTime</SortElement>
<SortElement sortDirection="ASC">/Description</SortElement>
</QueryCriteria>
<QueryCriteria>
<QualifiedElementPath>/SalesOrderLine/SalesOrderLineBase</QualifiedElementPath>
<QueryExpression>
...
</QueryExpression>
<SortElement>/SalesOrderLine/SalesOrderLineBase/ListPrice</SortElement>
</QueryCriteria>

例7-6 複数のQueryCriteriaを持つ問合せの例

<Query>
<QueryCriteria>
<QueryExpression>
<ValueExpression queryOperatorCode="EQUALS">
<ElementPath>/Type</ElementPath>
<Value>GOLD</Value>
</ValueExpression>
</QueryExpression>
<SortElement>/LastName</SortElement>
</QueryCriteria>
<QueryCriteria>
<QualifiedElementPath>/CustomerAccount</QualifiedElementPath>
<QueryExpression>
<ValueExpression queryOperatorCode="EQUALS">
<ElementPath>/CustomerAccount/Status/Code</ElementPath>
<Value>ACTIVE</Value>
</ValueExpression>
</QueryExpression>
</QueryCriteria>
</Query>

例7-7 QueryInvoiceメッセージへの単一の戻しのリクエスト

<Query>
<QueryCriteria>

</QueryCriteria>
<ResponseFilter>
<ChildComponentPath>InvoiceLine</ChildComponentPath>
</ResponseFilter>
</Query>

例7-8 QueryInvoiceメッセージへの特定のメッセージ戻しのリクエスト

<Query>
<QueryCriteria>

</QueryCriteria>
<ResponseFilter>
<ExclusionIndicator>true</ExclusionIndicator>
<ElementPath>Charge</ElementPath>
<ElementPath>PaymentTerm</ElementPath>
</ResponseFilter>
</Query>

7.8 ABCSの呼出し

この項は、ABCSの作成が完了していることを前提としています。ここでは、ABCSを呼び出す様々な方法について説明します。

ABCSは、アプリケーションまたは別のサービスによって呼び出すことができます。このサービスがAIAアーティファクトの場合は、トランスポート・アダプタまたはEBSのいずれかになります。この項では、3つのシナリオでそれぞれ実行する内容を説明します。

この項には次のトピックが含まれます:

- アプリケーションからABCSを直接呼び出す方法

- トランスポート・アダプタを使用してABCSを呼び出す方法

- エンタープライズ・ビジネス・サービスがABCSを呼び出す時期

7.8.1 アプリケーションからABCSを直接呼び出す方法

アプリケーションとABCSとのインバウンド相互作用の場合:

1. 参加アプリケーションの識別から開始します。

2. 各参加アプリケーションの統合機能を分析します。

3. アプリケーション・プロバイダ(開発者)と協力して、必要な機能を実現するためにアプリケーションと相互作用する最適な方法を決定します。
相互作用メカニズムには次のいずれかを使用できます。

- SOAP Webサービス

- イベント/キュー

- JCA

4. 参加アプリケーションとABCS間の相互作用にメッセージ・キュー・アダプタまたはJCAアダプタを使用する場合は、アプリケーションから関連する詳細を取得します。
これらの詳細は、アダプタの構成で使用されます。構成によってWSDLが作成されます。環境固有の詳細が、WSDLに直接ではなく、サーバー上の関連リソース・ファイルに構成されていることを確認してください。

7.8.2 トランスポート・アダプタを使用してABCSを呼び出す方法

トランスポート・アダプタによってリクエスタABCSが呼び出されると、ABCSとトランスポート・アダプタ間の相互作用ではSOAP Webサービスまたはネイティブのバインディングのいずれかを使用します。

詳細は、「トランスポート・アダプタとのインタフェース」で指定します。

アダプタとABCS間におけるインバウンド接続の確立の詳細は、「リソース接続の確立」を参照してください。

7.8.3 エンタープライズ・ビジネス・サービスがABCSを呼び出す時期

EBSは次を呼び出します。

- EBS操作を実装するプロバイダABCS。これは、要求側サービスと提供側サービスの間をEBSが仲介するためです。

- レスポンスを送信するリクエスタABCS。要求側サービスが遅延レスポンスを待機している場合、レスポンスEBSによって、待機しているリクエスタABCSに提供側サービスからの遅延レスポンスをルーティングできます。

8 ABCS開発の完了

この章では、アプリケーション・ビジネス・コネクタ・サービス(ABCS)の開発、エラーおよびフォルトの処理、アダプタの使用、CAVS対応のABCSの開発、ABCSの保護、トランザクションの有効化、メッセージ配信の有効化とABCSのバージョニング、Oracle Mediatorにおける再順序付けおよびレイヤー・カスタマイズを行う方法について説明します。

この章の内容は次のとおりです。

- 拡張可能なABCSの開発

- エラーおよびフォルトの処理

- アダプタの使用

- CAVS対応のABCSの開発

- ABCSの保護

- トランザクションの有効化

- 保証付きメッセージ配信

- ABCSのバージョニング

- Oracle Mediatorにおける再順序付け

- レイヤー・カスタマイズの開発

8.1 拡張可能なABCSの開発

ABCSは、リクエスタ固有かプロバイダ固有かに関係なく、実行中にカスタム・コードを最低でも2回または4回呼び出すことができます。これらは、拡張ポイントとして機能します。

同期または非同期モードのいずれかでリクエスト/レスポンス・パターンをサポートするABCSには、4つの拡張ポイントがあります。ファイア・アンド・フォーゲット・パターンをサポートするABCSには、2つの拡張ポイントがあります。アドインを開発して、これらの拡張ポイントにフックできます。顧客が開発するサービスであるこれらのアドインは、提供されたABCSへの拡張として動作します。各拡張ポイントに1つのフックを使用できるため、1つの顧客拡張のみプラグインできます。

この項では、拡張可能サービスを使用するABCSを作成して、提供されたABCSへの変更が不要なサービス実装を可能にするためのメカニズムを説明します。

8.1.1 リクエスタABCSを拡張可能にする方法の概要

リクエスト/レスポンスのリクエスタABCSの場合は、カスタム・コードを4つの拡張ポイントにフックできます。

1. アプリケーション・ビジネス・メッセージ(ABM)からエンタープライズ・ビジネス・メッセージ(EBM)への変換を実行する直前。構成プロパティ名: ABCSExtension.PreXformABMtoEBMを使用します。

2. エンタープライズ・ビジネス・サービス(EBS)を呼び出す直前。構成プロパティ名: ABCSExtension.PreInvokeEBSを使用します。

3. EBMからABMへの変換を実行する直前で、EBSを呼び出した後。構成プロパティ名: ABCSExtension.PostInvokeEBSを使用します。

4. コールバック・サービスまたはレスポンスの戻しを呼び出してEBMからABMに変換する直前。構成プロパティ名: ABCSExtension.PostXformEBMtoABMを使用します。

3番目と4番目の拡張ポイントは、リクエスト/レスポンス・パターンを実装するABCSでのみ使用できます。

ファイア・アンド・フォーゲットのリクエスタABCSの場合は、カスタム・コードを2つの拡張ポイントにフックできます。

1. アプリケーション・ビジネス・メッセージ(ABM)からEBMへの変換を実行する直前。構成プロパティ名: ABCSExtension.PreXformABMtoEBMを使用します。

2. エンタープライズ・ビジネス・サービス(EBS)を呼び出す直前。構成プロパティ名: ABCSExtension.PreInvokeEBSを使用します。

構成パラメータの詳細は、「構成パラメータ」を参照してください。

図8-1に、リクエスタ固有のABCSにおけるアクティビティの高度なフローを示します。この図は、相互作用しているEBSがリクエスト/レスポンス相互作用スタイルを使用していることを前提にしています。顧客拡張を実行して追加タスクを行うためのステップはオプションです。

図8-1 リクエスト/レスポンス相互作用スタイルの拡張

図8-2に、リクエスタ固有のABCSにおけるアクティビティの高度なフローを示します。この図は、相互作用しているEBSがファイア・アンド・フォーゲット相互作用スタイルを使用していることを前提にしています。顧客拡張を実行して追加タスクを行うためのステップはオプションです。

図8-2 ファイア・アンド・フォーゲット相互作用スタイルを使用するリクエスタ固有のABCS

リクエスタABCSの実装者が使用可能な1番目の拡張ポイントは、カスタム・メッセージの検査を実行するのに使用できます。この拡張ポイントを使用して、カスタム検証、メッセージ変更、メッセージのフィルタ処理などのタスクを実行するコードを挿入できます。カスタム・コードは、変換される直前のABMにアクセスして、拡張されたABMを返すか、またはフォルトを発生できます。

2番目の拡張ポイントは、カスタム・メッセージの拡張を実行するのに使用できます。この拡張ポイントを使用して、EBM拡張、カスタム検証などのタスクを実行するコードを挿入できます。カスタム・コードは、EBSの呼出しに使用される直前のEBMにアクセスして、拡張されたEBMを返すか、またはフォルトを発生できます。

3番目の拡張ポイントを使用して、カスタム検証、メッセージ変更、メッセージのフィルタ処理などのタスクを実行するコードを挿入できます。カスタム・コードは、ABMに変換される直前のEBMにアクセスします。カスタム・コードは、変更されたEBMを返すか、またはフォルトを発生できます。

4番目の拡張ポイントを使用して、ABM拡張、カスタム検証などのタスクを実行するコードを挿入できます。カスタム・コードは、コールバック・サービスの呼出しに使用される直前のABMにアクセスします。カスタム・コードは、変更されたABMを返すか、またはフォルトを発生できます

8.1.2 プロバイダABCSを拡張可能にする方法の概要

リクエスト/レスポンスのリクエスタABCSの場合は、カスタム・コードを4つの拡張ポイントにフックできます。

1. EBMからABMへの変換を実行する直前の顧客拡張。構成プロパティ名: ABCSExtension.PreXformEBMtoABMを使用します。

2. アプリケーション・サービスを呼び出す直前の顧客拡張。構成プロパティ名: ABCSExtension.PreInvokeABSを使用します。

3. ABMからEBMへの変換を実行する直前で、アプリケーション・サービスを呼び出した後の顧客拡張。構成プロパティ名: ABCSExtension.PostInvokeABSを使用します。

4. エンタープライズ・ビジネス・サポートを呼び出す直前で、アプリケーション・メッセージからエンタープライズ・ビジネス・メッセージへの変換後の顧客拡張。構成プロパティ名: ABCSExtension.PostXformABMtoEBMを使用します。

3番目と4番目の拡張ポイントは、リクエスト/レスポンス・パターンを実装するABCSでのみ使用できます。

ファイア・アンド・フォーゲットのリクエスタABCSの場合は、カスタム・コードを2つの拡張ポイントにフックできます。

1. EBMからABMへの変換を実行する直前の顧客拡張。構成プロパティ名: ABCSExtension.PreXformEBMtoABMを使用します。

2. アプリケーション・サービスを呼び出す直前の顧客拡張。構成プロパティ名: ABCSExtension.PreInvokeABSを使用します。

構成パラメータの詳細は、「構成パラメータ」を参照してください。

図8-3に、プロバイダ固有のABCSにおけるアクティビティの高度なフローを示します。この図は、相互作用しているEBSがリクエスト/レスポンス相互作用スタイルを使用していることを前提にしています。

図8-3 リクエスト/レスポンス相互作用スタイルを使用するプロバイダ固有のABCS

図8-4に、プロバイダ固有のABCSにおけるアクティビティの高度なフローを示します。この図は、相互作用しているEBSがファイア・アンド・フォーゲット相互作用スタイルを使用していることを前提にしています。

図8-4 ファイア・アンド・フォーゲット相互作用スタイルを使用するプロバイダ固有のABCS

プロバイダABCSの実装者が使用可能な1番目の拡張ポイントは、カスタム検証、メッセージ変更、メッセージのフィルタ処理などのタスクを実行するコードを挿入するのに使用できます。カスタム・コードは、変換される直前のEBMにアクセスします。カスタム・コードは、拡張されたEBMを返すか、またはフォルトを発生できます。

2番目の拡張ポイントは、カスタム・メッセージの拡張を実行するのに使用できます。この拡張ポイントを使用して、ABM拡張、カスタム検証などのタスクを実行するコードを挿入できます。カスタム・コードは、アプリケーション・サービスの呼出しに使用される直前のABMにアクセスします。カスタム・コードは、拡張されたABMを返すか、またはフォルトを発生できます。

3番目の拡張ポイントを使用して、カスタム検証、メッセージ変更、メッセージのフィルタ処理などのタスクを実行するコードを挿入できます。カスタム・コードは、EBMに変換される直前のABMにアクセスします。カスタム・コードは、変更されたABMを返すか、またはフォルトを発生できます。

4番目の拡張ポイントは、カスタム・メッセージの拡張を実行するのに使用できます。この拡張ポイントを使用して、EBM拡張、カスタム検証などのタスクを実行するコードを挿入できます。カスタム・コードは、コールバック・サービスの呼出しに使用される直前のEBMにアクセスします。カスタム・コードは、変更されたEBMを返すか、またはフォルトを発生できます。

8.1.3 拡張対応のABCSの設計方法

各拡張ポイントは、明確に定義されたインタフェースを持つサービス操作としてモデル化されます。ABCSの作成者がこれらのインタフェースを定義します。拡張インタフェースは、カスタム・メッセージのエンリッチメントや変換、または顧客によって実装される検証用コードを実行するために、ABCSで呼び出すサービス操作で構成されます。

各ABCSには、対応する顧客拡張サービスが付随します。リクエスト/レスポンスのABCSには4つの拡張ポイントがあるため、ABCSの拡張サービスには4つのサービス操作があります。ファイア・アンド・フォーゲットのABCSの場合、対応するABCSの拡張サービスには2つのサービス操作があります。

前述したように、ABCSのすべての拡張サービスに対するサービス操作の実装では、常に同じメッセージを返す同じコード部分を呼び出します。このコード部分はサーブレットとして実装されています。

ABCSは、各拡張ポイントで適切なサービス操作を呼び出すように開発されています。オーバーヘッドを最小限にするために、関連する拡張インタフェースのサービスが実装済かどうかがチェックされます。Oracle AIAの構成プロパティには、拡張ポイントごとに1つのプロパティがあります。拡張ポイントにカスタム実装があることを示すには、プロパティをYesに設定します。これらのプロパティのデフォルト値はNoに設定されているため、ABCSは配信時にはこれらの拡張の実装を呼び出しません。

表8-1に、リクエスタABCS固有の拡張ポイントに対するサービス操作を示します。

表8-1 リクエスタABCS固有の拡張ポイントに対するサービス操作

拡張ポイント

サービス操作名

ABMからEBMへの変換を実行する直前

Pre-ProcessABM

EBSを呼び出す直前

Pre-ProcessEBM

EBMからABMへの変換を実行する直前

Post-ProcessEBM

コールバック・サービスまたはレスポンスの戻しを呼び出す直前

Post-ProcessEBM

表8-2に、プロバイダABCS固有の拡張ポイントに対するサービス操作を示します。

表8-2 プロバイダABCS固有の拡張ポイントに対するサービス操作

拡張ポイント

サービス操作名

EBMからABMへの変換を実行する直前

Pre-ProcessEBM

アプリケーション・サービスを呼び出す直前

Pre-ProcessABM

ABMからEBMへの変換を実行する直前

Post-ProcessABM

コールバックEBSまたはレスポンスの戻しを呼び出す直前

Post-ProcessEBM

ABCSと顧客拡張サービスは同一の場所に配置することをお薦めします。SOA 11gでは、複数のサービスが同じサーバーにデプロイされると、SOA 11gランタイムでネイティブの呼出しが使用されます。

拡張サービスは、ABCSトランザクションの一部として登録することをお薦めします。拡張サービスがSOA 11gテクノロジを使用して実装されるときに、拡張サービスのトランザクション・プロパティbpel.config.transactionをrequiredに設定して、その拡張サービスをABCSトランザクションに登録します。

詳細は、「AIAサービスでのトランザクションの確認方法」を参照してください。

8.1.3.1 構成パラメータ

拡張ポイントでの操作は、AIAConfigurationProperties.xmlファイルの特定パラメータの値に基づいて呼び出されます。ABCSに固有の各サービス構成セクションでは、これらのパラメータを指定する必要があります。4つの各拡張ポイントに対するパラメータは次のとおりです。

- ABCSExtension.PreXformABMtoEBM

- ABCSExtension.PreInvokeEBS

- ABCSExtension.PostInvokeEBS

- ABCSExtension.PostXformEBMtoABM

- ABCSExtension.PreXformEBMtoABM

- ABCSExtension.PreInvokeABS

- ABCSExtension.PostInvokeABS

- ABCSExtension.PostXformABMtoEBM

サービスを呼び出す場合は、これらのパラメータの値をtrueに構成する必要があります。ABCSの構成セクションでこれらのパラメータが指定されていない場合、値はデフォルトでfalseとみなされます。

この項の目的は、これらの構成プロパティを作成および利用して拡張を最適化する方法について、一連のガイドラインを開発者に提供することです。この項で提示するサービス操作名や拡張構成プロパティはすべて推奨です。

また、ここでは、拡張ポイントでのすべての呼出しについてガイドラインを提示しているわけではありません。特定のABCSごとにパラメータ数は異なる場合があります。製品管理チームやエンジニアリング・チームは、追加の拡張が必要な拡張ポイントを識別するのに最も適しています。

部門チームやパートナによって拡張できるサービスを開発するIT組織は、ABCSを拡張対応にする必要性を把握できます。このユースケースに示すように、推奨以外の追加の拡張ポイントを持つABCSを顧客が開発する必要がある場合、サービス操作名は適切な命名規則に従い、構成プロパティは現在提示されているプロパティに類似するように、適切な名前を付けることができます。

8.1.4 拡張を伴うABCSコンポジットの設計

ABCSコンポジットを拡張対応サービスとして開発する場合:

- ABCSはコンポジット内の1つのコンポーネント(BPELテクノロジを使用)として実装されます。

- 拡張サービスは、ABCSコンポジットによって外部Webサービスとして参照されます。

拡張ポイントでのサービスがOracle Fusion Middlewareプラットフォームで開発される場合、サービスは個別のコンポジットで開発されます。

ABCSコンポジットによって異なる複数の外部拡張サービスが参照される場合は、ABCSコンポジットから外部サービスへの複数のフックが存在します。つまり、図8-5に示すように、ABCSが2つの拡張ポイントで2つの異なるサービスを呼び出す場合は、コンポジットに2つの異なる外部参照があるように設計する必要があります。

図8-5 2つの異なる外部参照があるコンポジットの例

ただし、同じ外部サービスで公開されている2つの異なる操作をABCSコンポジットが呼び出す場合、図8-6に示すように、ABCSコンポジットにあるのは1つの外部参照のみです。

図8-6 外部参照が1つのコンポジットの例

8.1.5 拡張ポイントでのサービスの定義

拡張ポイントでは、対話において各サービスが果たす役割を指定すること、および対話のコンテキスト内でメッセージを受信するために各サービスが提供するポート・タイプを指定することによって、2つのサービス間での対話関係を設定するようにパートナ・リンクが定義されます。

これは、パートナ・リンクから提供されるサービスを表すWeb Services Description Language (WSDL)ファイルを使用して行います。WSDLは、サービス・コンシューマに対するすべてのサービス・プロバイダ・コントラクトを表すXMLドキュメントです。

WSDLによって、サービス・コントラクトは抽象WSDLと具象WSDLの2つの部分に分割されます。

- 抽象WSDLには、パラメータ(入力および出力タイプ)、フォルト・タイプおよびポート・タイプの構造(インタフェースと呼ばれる)を定義する、タイプやメッセージなどの要素が含まれます。

- 具象WSDLには、プロトコルへのバインディング、具体的なアドレスの場所、およびサービス要素が含まれます。

8.1.6 抽象WSDLを使用するサービスの定義

抽象WSDLは、設計時に外部参照サービスを定義します。このWSDLは、拡張ポイントで呼び出される操作へのインタフェースを提供します。また、アプリケーション・ビジネス・オブジェクト(ABO)およびエンタープライズ・ビジネス・オブジェクト(EBO)のスキーマを含むか、またはインポートする必要があります。通信トランスポート・プロトコル、ネットワーク・アドレスの場所などは含まれていません。

外部ポイント・サービスの定義に使用される抽象WSDLは、プロジェクト・フォルダに配置される必要があります。AIAサービスの他の抽象WSDLとは異なり、これをMDSにプッシュしないでください。

注意: 抽象WSDLは、設計時のモデル化の目的のみで一時的に使用できます。コンポジットがデプロイされるときに、バインディングを指定する必要があります。

JDeveloperを使用する場合は、次の手順に従ってコンポジットを設計します。

コンポジットを拡張対応のABCSに設計する手順は、次のとおりです。

1. JDeveloperで、SOAコンポジット・プロジェクトを開きます。

2. composite.xmlを設計モードで開きます。

3. 拡張ポイント・サービスを参照するには、Webサービスを外部参照サービスとして「参照」スイムレーンに追加します。抽象WSDLを設計時のモデル化のために使用します。

ヒント:

この抽象WDSLはMDS内に格納されません。これはプロジェクトに関連付けられ、プロジェクト・フォルダ内に格納されます。

4. BPELコンポーネントを、前のステップで作成した外部参照コンポーネントに接続します。

コンポジットをソース・モードで開くと、例8-1に示すようなコードが表示されます。

このコード例はcomposite.xmlから再作成され、拡張サービスが抽象WSDLを使用して定義されます。

例8-1 BPELコンポーネントから外部参照コンポーネントへの接続

<reference name="SamplesCreateCustomerSiebelReqABCSImplExtExtension"
ui:wsdlLocation="SamplesCreateCustomerSiebelReqABCSImplExtExtensionAbstract.wsdl">
<interface.wsdl
interface="http://xmlns.oracle.com/ABCSImpl/Siebel/Samples/CreateCustomerSiebelR
eqABCSImplExtExtension/V1#wsdl.interface(SamplesCreateCustomerSiebelReqABCSImpl
ExtExtensionService)"/>
<binding.ws port="" location=""/>
</reference>

8.1.7 デプロイメント時に具象WSDLを指定する方法

具象WSDLは抽象WSDLのコピーで、拡張サービスの定義に使用されます。具象WSDLはバインディング要素も定義して、すべてのポートを結合するトランスポート・プロトコルとサービス要素に関する情報を提供し、顧客がサービス・プロバイダと相互作用するエンドポイントを提供します。

開発の開始時は、具象WSDLはサーブレットであるサンプル拡張サービスをポイントしています。サーブレットの名前はMirrorServletで、SOAコア拡張機能に付属しています。

具象WSDLは、MDSリポジトリの「ExtensionServiceLibrary」フォルダにプッシュする必要があります。

8.1.7.1 composite.xmlへのbinding.ws要素の挿入

外部参照サービスを呼び出すには、ABCSのcomposite.xmlにランタイムWSDLが具象バインディングとともに指定されている必要があります。WSDLのポート・タイプには具象バインディングが必要です。つまり、コンポジット内では、要素の属性binding.wsを空にできません。

注意:

binding.ws要素のlocation属性にランタイムWSDLのURLを入力しても、抽象WSDLのみを使用するサービスの設計の規則には違反しません。その理由は、この具象WSDLにはコンポジットの設計時にもデプロイ時にもアクセスしないためです。このWSDLにアクセスするのは、コンポジットの実行時のみです。

抽象WSDLを使用して定義された外部Webサービスを参照するコンポジットをデプロイするには、binding.ws要素の属性を次に示すように入力する必要があります。

<binding.ws port="[WSDLで定義されたABCS拡張サービスのネームスペース]/V1#wsdl.endpoint(<WSDLで指定されたABCSサービスの名前>/<WSDLで指定されたポートタイプの名前>" location="[MDSでの具象WSDLの場所]" xmlns:ns="http://xmlns.oracle.com/sca/1.0"/>

ABCSサービスの名前は、抽象WSDLのdefinitions/name属性の値です。

これは、ABCSコンポジットのサービス名に対する命名規則に従います。命名規則に従って、サービスの名前は<コンポジットの名前>になるため、これはWSDLのdefinitions要素のname属性の値です。

顧客は、拡張ポイントにおけるサービスを開発およびデプロイする時点で、次のことができます。

- 顧客は、MDS内のサンプル具象WSDLを、拡張サービス用に開発された具象WSDLに置き換えて、ABCSを再デプロイできます。

- 顧客は、デプロイされたサービスの具象WSDLをポイントするようにbinding.ws.locationを変更し、ABCSを再デプロイできます。

詳細は、「AIAでのMDSの使用」を参照してください。

8.1.8 ABCS BPELプロセスでの拡張ポイントの設計

次の項では、一方向呼出しコールを使用するリクエスタABCSに拡張ポイントを提供するためのステップを説明します。

サービスへのリクエストのみのコールを使用するリクエスタABCSには、2つの拡張ポイントが存在できます。1番目の拡張ポイントはABMからEBMへの変換の直前で、2番目の拡張ポイントはサービスの呼出しの直前です。これらの拡張ポイントにおけるサービス操作は、それぞれPre-ProcessABMおよびPre-ProcessEBMとして定義されます。拡張ポイントにおけるサービス操作は、ペイロードを返すのみのサーブレットの呼出しです。

8.1.9 拡張ポイントPre-ProcessABMの設定方法

リクエスタABCSには、指定した順序による次のプロセス・アクティビティが必要です。

1. Switch
Switchアクティビティは、拡張ポイントにおけるサービス呼出しを実行するかどうかを決定します。これを行うには、AIAConfigurationProperties.xmlファイルにあるプロパティ変数の値を確認します。構成パラメータの名前はABCSExtension.PreProcessABMです。このパラメータの値がtrueであることを確認します。これを行うには、switch式で適切なAIAXPathFunctionを使用します。

2. Assign-Invoke-Assign
プロセス・アクティビティのAssign-Invoke-AssignサブシーケンスはSwitchアクティビティに埋め込まれています。

- Assign
Assignアクティビティは、receiveステップの入力変数の値を、後続のinvokeステップの入力変数に割り当てます。

- Invoke
Invokeアクティビティは、パートナ・リンクでサービス・コールを実行します。ABCS拡張ポイントのプログラミング・モデルでは、受信したのと同じペイロードを返すコントラクトをサービスに設定します。

- Assign
Assignアクティビティは、サービス呼出しからのレスポンス・ペイロードの値を、後続のプロセス・アクティビティの変数に割り当てます。

図8-7にシーケンスを示します。

図8-7 拡張ポイントPre-ProcessABMの設定

8.1.10 拡張ポイントPre-ProcessEBMの設定方法

リクエスタABCSには、指定した順序による次のプロセス・アクティビティが必要です。

1. Switch

Switchアクティビティは、拡張ポイントにおけるサービス呼出しを実行するかどうかを決定します。これを行うには、AIAConfigurationProperties.xmlファイルにあるプロパティ変数の値を確認します。構成パラメータの名前はABCSExtension.PreProcessEBMです。パラメータの値がtrueであることを確認します。これを行うには、switch式で適切なAIAXPathFunctionを使用します。

2. Assign-Invoke-Assign

プロセス・アクティビティのAssign-Invoke-AssignサブシーケンスはSwitchアクティビティに埋め込まれています。

- Assign
Assignアクティビティは、EBMの値を、後続のinvokeステップの入力変数に割り当てます。

- Invoke
Invokeアクティビティは、パートナ・リンクでサービス・コールを実行します。ABCS拡張ポイントのプログラミング・モデルでは、受信したのと同じペイロードを返すコントラクトをサービスに設定します。

- Assign
Assignアクティビティは、サービス呼出しからのレスポンス・ペイロードの値を、後続のプロセス・アクティビティの変数に割り当てます。

図8-8にシーケンスを示します。

図8-8 拡張ポイントPre-process EBMの設定

8.1.11 サーブレットをサンプル拡張サービスとして使用して拡張をテストする方法

ドキュメントで使用されるサンプル拡張サービスは、入力ペイロードをミラー化するJavaサーブレットです。例8-2に示すように、エンドポイントとしてのサーブレットは、パートナ・リンク・サービスとして使用して拡張をテストできるという利点があります。これは、抽象WSDLを使用してPartnerLinkサービスを定義する拡張対応ABCSをテストする場合に役立ちます。

メソッドPreProcessABMの実装は必要ありません。SOAPリクエストはサーブレット・ペイロードとして扱われ、サーブレットはペイロード全体を出力して戻します。また、SOAPAction要素はサーブレット側で使用されないため、ダミーがレンダリングされます。

テスト・サーブレットは、Mirror.javaという名前のJavaファイルです。デプロイされると、http://[hostname].com:[portno]/Mirror/mirrorから入手できます。

例8-2 拡張をテストするサーブレット

<service name="CreateCustomerSiebelReqABCSImplExt">
<port name="CreateCustomerSiebelReqABCSImplExt"
binding="tns:CreateCustomerSiebelReqABCSImplExt_Binding">
<soap:address
location="http://{host}:{port}/MirrorServlet/mirror"/>
</port>
</service>

8.2 エラーおよびフォルトの処理

参加アプリケーションがフォルトを処理して渡す方法を決定するには、アプリケーションのエラー処理機能が統合プラットフォームのエラー処理機能と一致していることを確認する必要があります。

8.2.1 エラーおよびフォルトの処理方法

- 同期リクエスト/レスポンス・メッセージ交換パターン(MEP)では、要求側サービスはレスポンスを待機します。
プロバイダ・サービスでエラーが発生するたびに、例外が発生し、フォルト・メッセージが要求側サービスに伝播されます。

- 非同期ファイア・アンド・フォーゲットMEPでは、要求側サービスはレスポンスを待機しません。
提供側サービスでエラーが発生すると、補正が必要になる場合があります。このような場合、EBSでの補正操作を使用して補正をトリガーする必要があります。

- 非同期リクエスト/遅延レスポンスMEPでは、要求側サービスは一時停止モードになり、レスポンスを待機します。
提供側サービスでエラーが発生すると、要求側サービスへのレスポンスにエラーに関する詳細が含まれます。

このシナリオでのABCSおよびEBSサービスの実装の詳細は、「非同期リクエスト/遅延レスポンスMEPの実装」を参照してください。

各MEPにおけるBPELおよびMediatorプロセスでのエラー処理の実装の詳細は、「エラー処理およびトレース・ロギング用のOracle AIAプロセスの構成」を参照してください。

- 非同期MEPでは、送信側から開始されたメッセージは、正常に配信されて受信側で確認(確認が必要な場合)されるまで保持されます。
送信側と受信側は必ずしも参加アプリケーションである必要はありません。むしろ、これらはOracle AIA統合シナリオの論理的なマイルストンになります。各永続ストアはマイルストンを表し、データベース、ファイル・システムまたはJMS永続である場合があります。永続ポイント間でメッセージを移動できるように、統合シナリオに複数のマイルストンを構成できます。

統合フローにおける保証付きメッセージ配信のマイルストンの構成については、「エラー処理およびトレース・ロギング用のOracle AIAプロセスの構成」を参照してください。

8.3 アダプタの使用

この項では、トランスポート・アダプタおよびバージョン・アダプタの使用について説明します。

この項には次のトピックが含まれます:

- トランスポート・アダプタとのインタフェース

- トランスポート・アダプタの開発方法

- 1つのコンポジットに複数のアダプタを配置する場合

- バージョン・アダプタの計画

- バージョン・アダプタの構成方法

8.3.1 トランスポート・アダプタとのインタフェース

これらのシナリオでは、トランスポート・アダプタを使用してABCSとインタフェースします。

- Siebel、PeopleSoft、J.D. Edwards、SAPなどのパッケージ化されたアプリケーションでは、パッケージ化された各アプリケーションのアダプタを使用するルートが優先されます。これらのアダプタは、JCAリソース・アダプタとしてデプロイできます。従来のSOAPインタフェースを使用するよりも、この方法をお薦めします。

- 参加アプリケーションがビジネス・ロジックをWebサービスとして公開していない場合、これらのアプリケーションとの相互作用では、データベース・アダプタ、JMSアダプタなどのテクノロジ・アダプタを使用する必要があります。

トランスポート・アダプタを使用すると、当初はWebサービス・テクノロジを使用するように開発されなかったシステム/アプリケーションとの接続が可能になります。次に、アダプタを使用できるアプリケーションの例を示します。

- 通信にxmlを使用しないシステム

- パッケージ化されたソフトウェア

- データベース・システム

- データソース、永続ストア(例: JMS)など

参加アプリケーションによって公開されたサービスが専用のメッセージ書式、テクノロジおよび標準をサポートしているかどうかを調べてください。機能を実装するアプリケーションが標準およびテクノロジ(XML、SOAP、JMSなど)を固有にサポートしていない場合は、ABCSで変換を実行する必要があります。

たとえば、アプリケーションはファイルのみを使用してメッセージを送受信でき、認識できる形式はEDIのみであるとします。この場合、ABCSでは、ファイル・アダプタを使用し、EDIベースのメッセージをXML形式に変換して、そのメッセージをSOAPメッセージとして公開するアプリケーションとの統合を行う必要があります。

メッセージ集約用のアダプタを使用する場合

場合によっては、複数のソースから発生した複数のレスポンスを1つのリクエストに結合する必要があります。たとえば、通信ソリューションにおける一括請求の場合、getBillDetails EBSのアプリケーション・ビジネス・コネクタ・サービスは、複数の参加アプリケーションから詳細を取得する必要があります。

メッセージ集約の設計パターンの詳細は、「AIA設計パターンの使用」を参照してください。

イベント集約用のアダプタを使用する場合

イベント集約モデルによって、イベント、エンティティまたはメッセージの集約が必要なビジネス・ユースケースで使用できる包括的な方法が提供されます。このようなシナリオでは、ビジネス・メッセージが完了する前に複数のイベントが発生し、これらの粒度が細かいメッセージ・イベントすべてが粒度の粗い1つのイベントに統合されます。

このようなユースケースでは、イベント・コンシューマ・アダプタ・サービスによってリクエスタABCSが呼び出され、集約されたイベント・メッセージがリクエスタABCSに提供されます。

イベント集約の設計パターンの詳細は、「AIA設計パターンの使用」を参照してください。

8.3.2 トランスポート・アダプタの開発方法

ここでは、ABCS側の観点から高度なステップを示します。

JMSコンシューマ・アダプタを開発する手順は、次のとおりです。

1. JMSアダプタを「公開されたサービス」スイムレーンに追加します。

2. アダプタ構成ウィザードを使用して、JMSアダプタ・サービスを構成します。

3. BPELコンポーネントを「コンポーネント」スイムレーンに追加します。

4. BPELコンポーネントをJMSアダプタ・サービスに接続します。

5. BPELコンポーネントを参照先サービスに接続します。

6. BPELコンポーネントを設計モードで開き、JMSアダプタ・パートナ・リンクを呼び出すinvokeアクティビティを追加します。

7. BPELプロセスのコーディングを完了します。

JMSアダプタの詳細は、『Oracle WebLogic Server JMSリソースの管理』を参照してください。

8.3.3 ポータルDBアダプタを開発する方法

ポータルDBアダプタを開発する手順は、次のとおりです。

1. BPELコンポーネントを「コンポーネント」スイムレーンに追加します。

2. DBアダプタを外部参照サービスとして「参照」スイムレーンに追加します。

3. アダプタ構成ウィザードを使用して、アダプタ・サービスを構成します。

4. BPELコンポーネントをdbアダプタ・サービスに接続します。

5. BPELコンポーネントを設計モードで開き、dbアダプタ・パートナ・リンクを呼び出すinvokeアクティビティを追加します。

6. BPELプロセスのコーディングを完了します。

8.3.4 1つのコンポジットに複数のアダプタを配置する場合

原則として、ABCSコンポジットは他のコンポーネントとともに実装された1つのコンポーネントで、これらのコンポーネント間を接続します。たとえば、次を使用するリクエスタABCSコンポジットを実装できます。

- ABCSプロセス・フローを表すBPELプロセス・コンポーネント。

- プロセス・コンポーネントで使用または必要なアダプタを表すBPELまたはメディエータ・ベースのアダプタ・コンポーネント。

- プロセス・コンポーネントとアダプタ・コンポーネントの両方(これらが定義されたコンポジットのサービスとして使用されます)。

ABCSとTransportAdapterサービスは同じコンポジット内に存在でき、その場合のコンポジット名はABCSのコンポジット名と同じです。または、ABCSサービスとTransportAdapterサービスを別々のコンポジットとして開発することもできます。

同じトランスポート・アダプタ・サービスが複数のABCSで使用可能な場合、ABCSとインタフェースするアダプタはABCSのコンポジットとは異なるコンポジットに配置することをお薦めします。

8.3.5 バージョン・アダプタの計画

サービス・プロバイダが新バージョンのアプリケーション・サービスをリリースすると、コンシューマ・コードを移行するときに複数のバージョンを同時に実行する必要があります。

バージョン・アダプタを使用すると、クライアントのリクエストとレスポンスで異なるリリースのサービスを使用でき、コンテンツに基づいてリクエストを適切なサービス・エンドポイントにルーティングできます。

例:

- アセットの場合、統合で使用されるビュー定義は、Oracle 11.5.10とR12で異なります。

- 支払認可の場合、API名はOracle 11.5.10とR12で異なります。

異なるバージョンのアプリケーション間でこれらを変更するには、アプリケーション・バージョンごとに新しいアダプタ・サービスを作成する必要があります。

異なるバージョンのアプリケーション間で変更が頻繁に行われない場合は、図8-9に示すように、メディエータ・コンポーネントに基づいて、既存のコネクタ・サービスとプロバイダ・アプリケーションの間にバージョン・アダプタを導入します。

図8-9 バージョン・アダプタの導入

この方法によって、コネクタ・サービスはアプリケーションのバージョンに依存しないままです。このオプションは、変換が不要な場合、バージョン・アダプタでの入出力変換が単純でパフォーマンスに影響する拡張ロジックが含まれない場合に、検討する必要があります。

8.3.6 バージョン・アダプタの構成方法

バージョン・アダプタを構成する手順は、次のとおりです。

バージョン・アダプタ・サービスは、プロバイダABCS実装サービスと実際の参加アプリケーションの間に存在する、メディエータ・ベースのコンポーネントです。

メディエータ・ベースのバージョン・アダプタ・サービスには、すべてのアプリケーション・アダプタへの参照が必要です。

1. アプリケーションの対応するアダプタ・サービスにルーティングするためのルーティング・ルールをバージョン・アダプタに構成します。

2. 接続元アプリケーションの各アダプタに、コンテンツ・ベースのルーティングと(AIAConfigurationからの)プロパティ・ベースのルーティングの両方を有効にする2つのルーティング・ルールが存在する必要があります。

3. 異なるアプリケーション・バージョン間で、渡されるコンテンツに関する変更が頻繁に行われず、変換されたABMでコンテンツが使用可能な場合は、変換マップを使用して、バージョン・アダプタの入力をプロバイダ・アプリケーションの対応するアダプタ・サービスに変換します。

4. 異なるアダプタからのレスポンスを、コネクタ・サービスが必要なスキーマにマップします。

8.4 CAVS対応のABCSの開発

この項では、コンポジット・アプリケーション検証システム(CAVS)を使用できるOracle AIAサービスの開発方法を説明します。この項には次のトピックが含まれます:

- プロバイダABCSをCAVS対応にする方法

- リクエスタABCSをCAVS対応にする方法

- CAVSEndpointURL値設定の概要

- テスト・シナリオを再実行可能にするためのCAVS関連の相互参照エンティティのパージ

ヒント:

CAVS構成が必要なのは、シミュレータがテスト・シナリオに含まれている場合のみです。これらの構成によって、サービスがメッセージをシミュレータにルーティングするための基盤が構築されます。

CAVSの使用の詳細は、Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイドのコンポジット・アプリケーション検証システムの概要に関する項を参照してください。

8.4.1 プロバイダABCSをCAVS対応にする方法

非同期でResponseEBSサービスへのコールバックを呼び出すプロバイダABCSは、その呼出しもCAVS対応にする必要があります。

開発者は、後述するように、Routing.<PartnerLinkName>.<TargetSystemID>.EndpointURIプロパティの値を入力する必要があります。

Routing.<PartnerLink>.RouteToCAVSプロパティの値がfalseに設定されている場合は、前述のプロパティをサービス構成ファイルに設定する必要があります。

CAVS対応の動的なPartnerLinkでターゲット参加アプリケーションのWebサービスを呼び出すように、プロバイダABCSをコーディングする手順は、次のとおりです。

1. 例8-3に示すように、プロバイダABCSに対して次のサービス・レベル構成プロパティを定義します。
CAVSEndPointURL値は設計時に設定されます。

CAVSEndPointURLの設計時の設定については、「CAVSEndpointURL値設定の概要」を参照してください。

2. 例8-4に示すように、BPELプロセスに次のネームスペース接頭辞が定義されていることを確認します。

3. この変数をグローバル変数セクションに追加します。

<variable name="SystemID" type="xsd:string"/>

4. AddTargetSystemID.xslという名前の添付ファイルをBPELプロセスの「xsl」ディレクトリに追加します。ファイル内の[ABCServiceNamespace]および[ABCServiceName]トークンが適切に置換されていることを確認します。

5. 例8-5に示すように、BPELプロセスの最初のステップとして割当を追加します。トークンが適切に置換されていることを確認します。

6. 例8-6に示すように、各PartnerLinkのinvokeアクティビティの前に、次の<scope>を1回追加します。

a. AssignDynamicPartnerlinkVariables割当アクティビティのトークンを置換して、変数を適切に設定します。

b. AssignPartnerlinkEndpointReference割当アクティビティのPartnerLink nameトークンを更新します。

c. 埋込みのJavaコードの更新は不要です。

例8-3 プロバイダABCSに対するサービス・レベル構成プロパティの定義

<Property name="Default.SystemID">[DefaultTargetSystemID]</Property>
<Property name="Routing.[PartnerlinkName].RouteToCAVS">[true|false]</Property>
<Property
name="Routing.[PartnerlinkName].[TargetSystemID].EndpointURI">[AppEndpointURL]<
/Property>
<Property name="Routing.[PartnerlinkName].CAVS.EndpointURI">[CAVSEndpointURL]</Property>

例8-4 BPELプロセスでのネームスペース接頭辞の定義

xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsa=http://schemas.xmlsoap.org/ws/2003/03/addressing
xmlns:corecom=http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V2

例8-5 割当の追加

<assign name="GetTargetSystemID">
<copy>
<from expression="ora:processXSLT('AddTargetSystemID.xsl',
bpws:getVariableData('[RequestEBMVariableName]', '[RequestEBMPartName]'))"/>
<to variable="[RequestEBMVariableName]"
part="[RequestEBMPartName]"/>
</copy>
<copy>
<from variable="[RequestEBMVariableName]"
part="[RequestEBMPartName]"
query="/[NamespacePrefixedEBMName]/corecom:EBMHeader/corecom:
Target/corecom:ID"/>
<to variable="SystemID"/>
</copy>
</assign>

例8-6 各PartnerLinkに対する追加

<scope name="SetDynamicPartnerlinkScope">
<variables>
<variable name="TargetEndpointLocation" type="xsd:string"/>
<variable name="EndpointReference" element="wsa:EndpointReference"/>
<variable name="ServiceName" type="xsd:string"/>
<variable name="PartnerLinkName" type="xsd:string"/>
<variable name="EBMMsgBpelVariableName" type="xsd:string"/>
<variable name="EBMMsgPartName" type="xsd:string"/>
</variables>
<sequence name="SetDynamicPartnerlinkSequence">
<assign name="AssignDynamicPartnerlinkVariables">
<copy>
<from expression="'{[ABCServiceNamespace]}[ABCServiceName]
'"/>
<to variable="ServiceName"/>
</copy>
<copy>
<from expression="'[PartnerlinkName]'"/>
<to variable="PartnerLinkName"/>
</copy>
<copy>
<from expression="'[RequestEBMVariableName]'"/>
<to variable="EBMMsgBpelVariableName"/>
</copy>
<copy>
<from expression="'[RequestEBMPartName]'"/>
<to variable="EBMMsgPartName"/>
</copy>
</assign>
<bpelx:exec name="GetTargetEndpointLocation" language="java"
version="1.5">
<![CDATA[/*------------------------------------------------------
This code snippet will derive the dynamic endpoint URI for a partnerlink.
-----------------------------------------------------------------*/

java.lang.String serviceName = (java.lang.String)getVariableData("ServiceName");
java.lang.String partnerLinkName = (java.lang.String)getVariableData("PartnerLinkName");
java.lang.String cavsEndpointPropertyName =
"Routing."+partnerLinkName+".CAVS.EndpointURI";
java.lang.String ebmMsgBpelVariableName = (java.lang.String)getVariableData("EBMMsgBpelVariableName");
java.lang.String ebmMsgPartName =
(java.lang.String)getVariableData("EBMMsgPartName");
java.lang.String systemIdBpelVariableName = "SystemID";
java.lang.String targetEndpointLocationBpelVariableName =
"TargetEndpointLocation";
java.lang.String routeToCavsPropertyName =
"Routing."+partnerLinkName+".RouteToCAVS";
java.lang.String defaultSystemIdPropertyName = "Default.SystemID";
java.lang.String targetEndpointLocation = null;
java.lang.String targetID = null;
boolean addAudits = false;

if (addAudits) addAuditTrailEntry("Partnerlink = " + partnerLinkName);

// check configuration for CAVS routing flag
try {
boolean routeToCAVS =
java.lang.Boolean.parseBoolean(oracle.apps.aia.core.config.Configuration.
getServiceProperty(serviceName, routeToCavsPropertyName));
if (addAudits) addAuditTrailEntry("RouteToCAVS = " + routeToCAVS);
if (routeToCAVS) {
targetEndpointLocation = oracle.apps.aia.core.config.Configuration.
getServiceProperty(serviceName, cavsEndpointPropertyName);
if (addAudits) addAuditTrailEntry("Endpoint = '" + targetEndpoint
Location + "' selected from configuration property " +
cavsEndpointPropertyName);
}
}
catch (oracle.apps.aia.core.config.PropertyNotFoundException e) {
if (addAudits) addAuditTrailEntry("Configuration property " + cavs
EndpointPropertyName + " not found!");
}

if (targetEndpointLocation==null || targetEndpointLocation=="") {

// check bpel variable for already retrieved target system Id
try {
targetID = (java.lang.String)getVariableData(systemIdBpel
VariableName);
if (addAudits && targetID!=null) addAuditTrailEntry("Using previously
stored Target System ID = '" + targetID + "'");
}
catch (com.oracle.bpel.client.BPELFault e) {
}

if (targetID==null || targetID=="") {
// try to get Target system ID from EBM Header
try {
oracle.xml.parser.v2.XMLElement targetIdElement =
(oracle.xml.parser.v2.XMLElement)
getVariableData(ebmMsgBpelVariableName,
ebmMsgPartName, "/*/corecom:EBMHeader[1]/corecom:Target/corecom:ID
[text()!='']");
targetID = targetIdElement.getText();
if (addAudits) addAuditTrailEntry("Target System ID = '" + targetID
+ "', selected from EBM header");
}
catch (com.oracle.bpel.client.BPELFault e) {
if (addAudits) addAuditTrailEntry("Unable to retrieve Target System
ID from message header");
}
try {
if (targetID!=null && targetID!="")
setVariableData(systemIdBpelVariableName, targetID);
}
catch (com.oracle.bpel.client.BPELFault e) {
}
}

if (targetID==null || targetID=="") {
// try to get Target system ID from configuration
try {
targetID = oracle.apps.aia.core.config.Configuration.getService
Property(serviceName, defaultSystemIdPropertyName);
if (addAudits) addAuditTrailEntry("Target System ID = '" + targetID
+ "', selected from configuration property " + defaultSystemIdPropertyName);
}
catch (oracle.apps.aia.core.config.PropertyNotFoundException e) {
if (addAudits) addAuditTrailEntry("Configuration property "
+ defaultSystemIdPropertyName + " not found!");
}
try {
if (targetID!=null && targetID!="") setVariableData(systemIdBpel
VariableName, targetID);
}
catch (com.oracle.bpel.client.BPELFault e) {
}
}

if (targetID!=null || targetID!="") {
// try to get EndpointLocation from Configuration
java.lang.String endpointPropertyName = "Routing."+partnerLinkName+
"."+targetID+".EndpointURI";
try {
targetEndpointLocation =
oracle.apps.aia.core.config.Configuration.getServiceProperty(serviceName,
endpointPropertyName);
if (addAudits) addAuditTrailEntry("Endpoint = '" +
targetEndpointLocation + "' selected from configuration property " +
endpointPropertyName);
}
catch (oracle.apps.aia.core.config.PropertyNotFoundException e) {
if (addAudits) addAuditTrailEntry("Configuration property " +
endpointPropertyName + " not found!");
}
}
}

try {
setVariableData(targetEndpointLocationBpelVariableName, targetEndpoint
Location);
}
catch (com.oracle.bpel.client.BPELFault e) {
}]]>
</bpelx:exec>
<switch name="Switch_SetEndpoint">
<case condition="string-length(bpws:getVariableData('Target
EndpointLocation'))>0">
<assign name="AssignPartnerlinkEndpointReference">
<copy>
<from>
<wsa:EndpointReference xmlns:wsa="http://schemas.
xmlsoap.org/ws/2003/03/addressing">
<wsa:Address/>
</wsa:EndpointReference>
</from>
<to variable="EndpointReference"/>
</copy>
<copy>
<from variable="TargetEndpointLocation"/>
<to variable="EndpointReference"
query="/wsa:EndpointReference/wsa:Address"/>
</copy>
<copy>
<from variable="EndpointReference"/>
<to partnerLink="[PartnerlinkName]"/>
</copy>
</assign>
</case>
<otherwise>
<empty name="Empty_NoSetEndpoint"/>
</otherwise>
</switch>
</sequence>
</scope>

8.4.2 リクエスタABCSをCAVS対応にする方法

プロバイダABCSでエンドポイントURIを動的に計算して動的なターゲット呼出しを実現する方法は、汎用プログラミング・モデルの概念に似ています。

メディエータ・サービスとして実装されるエンタープライズ・ビジネス・サービスのCAVS対応呼出しを行うように、リクエスタABCSをコーディングする手順は、次のとおりです。

1. BPELアーティファクトに、switchアクティビティを追加します。

2. caseの条件式は、EBMHeader/MessageProcessingInstruction/DefinitionID要素のゼロ以外の値をテストします。

3. 例8-7に示すように、wsa:EndpointReference要素に、EBMHeader/MessageProcessingInstruction/DefinitionID要素の値を入力します。

ヒント:

一部のリクエスタABCSは、コール元の参加アプリケーションと直接通信する必要があります。このタイプのPartnerlinkでは、リクエスタABCSは参加アプリケーションのWebサービスを呼び出すため、プロバイダABCSと同様に動作します。

例8-7 wsa:EndpointReference要素の入力

<switch name="Switch_CAVSEnablement">
<case condition="string-length(bpws:getVariableData('CreateCustomerPartyList_
InputVariable','CreateCustomerPartyListEBM','/custpartyebo:CreateCustomerPartyLis
tEBM/corecom:EBMHeader/corecom:MessageProcessingInstruction/corecom:DefinitionID'
))>0">
<bpelx:annotation>
<bpelx:pattern>Is_CAVS_DefinitionID</bpelx:pattern>
</bpelx:annotation>
<sequence>
<assign name="Assign_TargetEndpointLocation">
<copy>
<from variable="CreateCustomerPartyList_
InputVariable"
part="CreateCustomerPartyListEBM"
query="/
corepartyebo:CreateCustomerPartyListEBM/corecom:EBMHeader/corecom:Message
ProcessingInstruction/corecom:DefinitionID"/>
<to variable="TargetEndpointLocation"/>
</copy>
</assign>
<assign name="AssignPartnerlinkEndpointReference">
<copy>
<from>
<wsa:EndpointReference>
<wsa:Address/>
</wsa:EndpointReference>
</from>
<to variable="EndpointReference"/>
</copy>
<copy>
<from variable="TargetEndpointLocation"/>
<to variable="EndpointReference"
query="/wsa:EndpointReference/wsa:Address"/>
</copy>
<copy>
<from variable="EndpointReference"/>
<to partnerLink="SamplesCustomerPartyEBS"/>
</copy>
</assign>
</sequence>
</case>
<otherwise> <empty name="Empty_NoSetEndpoint"/> </otherwise>
</switch>

8.4.3 CAVSEndpointURL値設定の概要

CAVSEndPointURL値は、次のように設計時に設定されます。

- ABCSまたはエンタープライズ・ビジネス・フロー(EBF)が同期サービスを呼び出す場合、AIAConfigurationProperties.xmlファイルのCAVSEndPointURL値はデフォルト値のhttp://<host>:<port>/AIAValidationSystemServlet/syncresponsesimulatorに設定されます。

- ABCSまたはEBFが非同期一方向サービスを呼び出す場合、AIAConfigurationProperties.xmlファイルのCAVSEndPointURL値はデフォルト値のhttp://<host>:<port>/AIAValidationSystemServlet/asyncrequestrecipientに設定されます。

- ABCSまたはEBFが非同期リクエスト/遅延レスポンス・サービスを呼び出す場合、AIAConfigurationProperties.xmlファイルのCAVSEndPointURL値はデフォルト値のhttp://<host>:<port>/AIAValidationSystemServlet/asyncresponsesimulatorに設定されます。

- ABCSまたはEBFがレスポンスEBSを呼び出す場合、AIAConfigurationProperties.xmlファイルのCAVSEndPointURL値はデフォルト値のhttp://<host>:<port>/AIAValidationSystemServlet/asyncresponserecipientに設定されます。

8.4.4 テスト・シナリオを再実行可能にするためのCAVS関連の相互参照エンティティのパージ

参加アプリケーションがCAVSテスト・フローに含まれている場合、テストを実行すると参加アプリケーションのデータが変更される可能性があります。したがって、同じテストを連続して実行しても、同じ結果が生成されない場合があります。CAVSは、フローに実際の参加アプリケーションを含めるというユーザーの目的をサポートするため、このようなデータ改ざんを防ぐように設計されていません。CAVSは、参加アプリケーションで実行される変更を制御できません。

ただし、CAVSのテスト・シナリオでテスト定義とシミュレータ定義を使用して、すべての参加アプリケーションおよびその他の依存性を置換する場合、この問題は該当しません。この場合、テスト・シナリオが実行された後に、すべての相互参照データがパージされます。これによって、テスト・シナリオの再実行が可能になります。

このパージは次のようにして行います。

1. Oracle SOAコア拡張機能を使用するために提供される事前作成済の統合は、相互参照システムとともに適切な場所に提供されます。これらの名前はCAVS_<XYZ>で、<XYZ>は参加アプリケーション・システムです。たとえば、システムEBIZおよびSEBLの場合、事前作成済の統合は、相互参照システムCAVS_EBIZおよびCAVS_SEBLとともに提供されます。

2. テスト・シナリオを再実行可能にするために「システム」 - 「アプリケーション・レジストリ」ページで定義したシステム・タイプごとに(<XYZ>)、関連するCAVSシステム(CAVS_<XYZ>)を作成します。CAVS関連エントリの「システム・タイプ」フィールド値は、作成されるシステムの名前と一致する必要があります。「システム」 - 「アプリケーション・レジストリ」ページにアクセスするには、AIAホーム・ページにアクセスし、「設定」エリアで「実行」をクリックして、「システム」タブを選択します。図8-10に、システムおよびCAVS関連エントリを示します。

図8-10 「システム」-「アプリケーション・レジストリ」ページのシステムおよびCAVS関連エントリ

3. プロバイダABCSを単独でテストすると、CAVS_<XYZ>として設定されたNamespacePrefixedEBMName/EBMHeader/Target/ID要素とともに、EBMがCAVSからプロバイダABCSに渡されます。

4. リクエスタABCSを単独でテストすると、アプリケーション・ビジネス・メッセージ(ABM)の要素(通常は内部ID値を含む)には、「システム」 - 「アプリケーション・レジストリ」ページでシステムに設定されたCAVS固有の内部ID値が格納されます。

5. フロー全体(リクエスタABCS-EBS-プロバイダABCS)をテストする場合は、プロバイダABCSのDefault.SystemIDプロパティをCAVS_<XYZ> (<XYZ>はシステム)に設定する必要があります。

これを行うには、$AIA_HOME/aia_instances/$INSTANCE_NAME/AIAMetaData/configディレクトリにあるAIAConfigurationProperties.xmlファイルのDefault.SystemIDプロパティ値を編集します。

「構成」ページにアクセスし、「リロード」をクリックして編集内容をロードします。

これで、フロー全体のテストを開始できます。

注意:

同じシステムの複数のインスタンスを含むフロー全体がテスト・シナリオの場合、前述の方法は機能しません。この場合は、相互参照で作成されたデータが残るため、同じテスト・ケースを再実行できません。

8.5 ABCSの保護

各参加アプリケーションは、異なる時期に、異なるコンセプト、異なる認証および認可の実装を使用して開発されています。アプリケーションが統合される場合は、アプリケーション間で認証および認可情報を渡す必要があります。

セキュリティに関連する情報は、参加アプリケーションとABCSの間で交換されます。AIAアプリケーション・セキュリティ・コンテキストによって、様々なアプリケーション間における参加アプリケーションの認証および認可情報の交換が標準化されるため、すべてのアプリケーションを他のアプリケーションと統合できます。

8.5.1 ABCSを保護する方法

次の質問に回答する必要があります。

- アプリケーションでは認証にセキュリティ資格証明が必要か。
Yesの場合、汎用アカウントを使用できるか、またはメッセージに指定されているリクエスタの資格証明を使用する必要があるか。

- これらの資格証明をどのように転送するか。WS-Securityスキームまたはカスタム・メカニズムを採用しているか。
カスタム・メカニズムの場合、ヘッダーを経由するか、またはペイロードの一部か。

次の方法の詳細は、「セキュリティに関する作業」を参照してください。

- アプリケーション・セキュリティ・コンテキストをABCSの標準形式に変換する。

- 標準セキュリティ・コンテキストをEBSおよびEBFを介してABCSからABCSに伝播する。

- 標準セキュリティ・コンテキストをアプリケーション・セキュリティ・コンテキストに変換する。

8.6 トランザクションの有効化

SOAを使用してエンタープライズ間ワークフローをカプセル化して統合すると、複数のサービスがシステム境界を超えてトランザクションに参加できます。アプリケーション境界を超えるエンドツーエンド・ビジネス・トランザクションには、複数のアプリケーションが含まれます。強力な統合ソリューションを作成するには、単純なメッセージ交換では不十分です。

エンドツーエンド・メッセージ・フローに参加するWebサービスの多くが、非同期、ステートレス、分散および不透明であることは、重要な考慮事項です。トランザクション管理の方法を理解する必要があります。

8.6.1 AIAサービスでのトランザクションの確認方法

ビジネス要件によってトランザクション要件が決まります。トランザクションの検討は設計フェーズから開始する必要があります。これを作成時まで遅らせることはできません。次のことを実行する必要があります。

- ビジネス・アクティビティを構成するすべてのABCSサービスおよびEBFを識別します。

- これらのアクティビティを、全体的に統一された目的を持つ意味のあるグループに編成します。

- トランザクション境界ポイントを指定します。

アクティビティをグループ化すると、トランザクション境界の開始ポイントが判明するため、関連するビジネス操作がトランザクションのコンテキストで実行されます。

マイルストンが構成されない非同期ファイア・アンド・フォーゲット・パターンでは、Oracle XAの相互参照を含む同一のグローバル・トランザクションに、リクエスタ、EBSおよびプロバイダABCSが参加する必要があります。

JMSキューが設定され、参加アプリケーションがキューと相互作用する非同期MEPでは、リクエスタABCS、EBSおよびプロバイダABCSと同様に、JMSコンシューマ・アダプタもグローバル・トランザクションに参加する必要があります。

このような場合、メッセージがマイルストンに保持される前に実行中のトランザクションが中断されると、そのメッセージはJMSキューにロールバックされます。

つまり、トランザクション境界は、JMSコンシューマ・アダプタがメッセージをキューから取得すると開始され、メッセージがコンシューマ・アプリケーションに配信されるか、構成されたマイルストンにメッセージが保持された時点で終了します。

SOAベースの統合では、長時間かかるビジネス・トランザクションの多くに、非互換の信頼できるドメイン、非同時性、および非アクティブ期間が含まれ、これは、従来のACIDスタイルのトランザクション処理に関する課題です。技術上またはビジネス上の基準に基づいて、トランザクション境界を事前定義する必要があります。事前作成済の統合の設計者/アーキテクトは、論理ポイントでJMSインタフェースを使用してトランザクション境界を設定することによって、トランザクション全体を複数の部分に分割する必要があります。

再試行不可のアプリケーション・サービスには、対応する補正サービスが必要です。

再試行不可のアプリケーション・サービスを呼び出すABCSは、ロールバックの場合に補正サービスを呼び出す必要があります。

JCAアダプタを使用して実装されたアプリケーション・サービスは、セッション管理を使用するとトランザクション調整が容易になります。

8.6.2 Oracle Mediatorでのトランザクション

トランザクションが存在する場合、Oracle Mediatorは既存のトランザクションに参加します。トランザクションが存在しない場合、Oracle Mediatorはトランザクションを開始します。連続したルーティング・ルールの場合、すべてのルールは同じトランザクションで実行され、エラーが発生するとロールバックが発行されます。

8.6.3 BPELでのトランザクション

BPELコンポーネントは、デフォルトで、リクエストに基づいて新規トランザクションを作成します。つまり、BPELプロセスが呼び出されると、デフォルトで新規トランザクションが開始します。トランザクションが存在する場合、そのトランザクションは一時停止して、新規トランザクションが作成されます。実行を単一のグローバル・トランザクションに連鎖するには、プロバイダ・プロセス(コール先BPELコンポーネント)でトランザクション・フラグを設定する必要があります。

8.6.3.1 トランザクション・スコープでのBPELアクティビティの影響

BPELエンジンは、フローの最後に到達したとき、またはブレークポイント・アクティビティ(receive、onMessage、onWait、Alarmなど)がヒットしたときに、ローカル・トランザクションを終了します。

トランザクション設計では、次の事項も考慮する必要があります。

- AIA統合で採用されている呼出しパターン
ABCS -- EBS - ABCS

- テクノロジ・パターン: BPEL -- MEDIATOR-BPEL
ABCS - EBS - EBF - EBS -- ABCS

- テクノロジ・パターン: BPEL - MEDIATOR- BPEL - MEDIATOR- BPEL
FMWでのトランザクション・セマンティクスに基づいて、ABCS、EBSおよびエンタープライズ・ビジネス・フロー間でトランザクションを設計および構成する必要があります。

- 参加アプリケーション
参加アプリケーションは、アプリケーション・サービスを使用してトランザクションをサポートできる必要があります。ただし、実際に多くのアプリケーション・サービスがこれを実行できるため、ロールバックに備えて補正サービスが必要です(AIAレイヤーで編成)。

参加アプリケーション・サービス、SCAコンポジット・トランザクション・セマンティクスおよびビジネス要件の特性に特に対応するために、統合ロジックおよびトランザクション境界をAIAレイヤーに設計します。

8.6.4 グローバル・トランザクションに参加するABCSの開発

SOA 11gでは、実行を単一のグローバル・トランザクションに連鎖するために、コール元(使用)プロセスで構成プロパティを設定する必要はありません。

コール先BPELコンポーネントで適切なトランザクション・フラグのみ設定する必要があります。これを行うには、例8-8に示すように、コンポジット・エディタのソースで、値をrequiredに指定したbpel.config.transactionをBPELコンポーネントに追加します。

このようにトランザクション・フラグを設定すると、BPELは親プロセスによって開始されるトランザクションを継承します。親プロセスがトランザクションを開始しなかった場合、BPELは新規トランザクションを作成します。グローバル・トランザクションの場合は、イニシエータがコミットするとトランザクションもコミットされます。

BPELにアダプタとのインバウンド・インタフェースがある場合は、アダプタのコンポジットで適切なトランザクション・フラグを設定する必要があります。

例8-9に、BPELアダプタ・インタフェースにトランザクション・プロパティを設定する方法を示します。

メディエータを呼び出すBPELでは、トランザクションが存在する場合、メディエータは既存のトランザクションに参加します。トランザクションが存在しない場合、メディエータはトランザクションを開始します。

例8-8 wsa:EndpointReference要素の入力

<component name="SamplesCreateCustomerSiebelReqABCSImplProcess">
<implementation.bpel
src="SamplesCreateCustomerSiebelReqABCSImplProcess.bpel"/>
<property name="bpel.config.transaction">required</property>
</component>

例8-9 PELエンドポイント要素の入力

<component name="SamplesCreateCustomerSiebelJMSConsumerProcess">
<implementation.bpel
src="SamplesCreateCustomerSiebelJMSConsumerProcess.bpel"/>
<property name="bpel.config.transaction">required</property>
</component>

8.6.5 AIAサービスをトランザクション対応にする方法

次の各項では、様々なシナリオでAIAサービスをトランザクション対応にする方法を説明します。

- 同期リクエスト/レスポンスのシナリオ

- 非同期MEPでのAIAサービス

- 同じスレッド内で異なるトランザクション内でのABCSからの非同期操作

8.6.5.1 同期リクエスト/レスポンスのシナリオ

同期BPELプロセスを呼び出すと、デフォルトで、ローカル・トランザクション内にBPELインスタンスが作成されます。このトランザクションは、適切に構成してグローバル・トランザクションに登録できます。

したがって、ABCSサービスでのトランザクション設定は例8-10に示すようになります。

この設定によって、コール元のトランザクションが存在する場合は結合され、存在しない場合は新規トランザクションが作成されます。EBSは、リクエスタABCSによって開始されたトランザクションを継承します。

メディエータは常に、受信メッセージを処理しているスレッドを介して伝播されたグローバル・トランザクションにメディエータ自体を登録します。

図8-11に、トランザクション境界を示します。

図8-11 トランザクション境界

例8-10 非同期MEPでのトランザクション設定

<component name="SamplesCreateCustomerSiebelJMSConsumerProcess">
<implementation.bpel
src="SamplesCreateCustomerSiebelReqABCSImplProcess.bpel"/>
<property name="bpel.config.transaction">required</property>
</component>

8.6.5.2 非同期MEPでのAIAサービス

非同期BPELプロセスを呼び出すと、コール元のトランザクション内にある呼出しメッセージ表に呼出しメッセージが保持されます。コール元のトランザクションは終了します。非同期BPELは、独自のローカル・トランザクションで実行されます。コール先がコール元のトランザクション内で実行される場合、次に示すように、コール先のコンポジットでBPELコンポーネントのトランザクション・フラグをrequiredに設定する必要があります。

bpel.config.transaction=required

一方向操作の場合にコール先のシングル・スレッド実行を行うには、syncタイプのコールが必要です。次に示すように、コール先のコンポジットでBPELコンポーネントのプロパティを設定します。

bpel.config.oneWayDeliveryPolicy=sync

したがって、ABCSサービスでのトランザクション設定は例8-11に示すようになります。

リクエスタABCSにアダプタとのインバウンド・インタフェースがある場合は、アダプタのコンポジットで、bpel.config.oneWayDeliveryPolicy=syncのようにBPELコンポーネント・レベルでプロパティを設定します。

例8-12に、アダプタ・コンポーネントでトランザクション・プロパティを設定する方法を示します。

図8-12に、トランザクション境界を示します。

図8-12 非同期MEPでのトランザクション境界

例8-11 非同期MEPでのトランザクション設定

<component name="SamplesCreateCustomerSiebelReqABCSImplProcess">
<implementation.bpel
src="SamplesCreateCustomerSiebelReqABCSImplProcess.bpel"/>
<property name="bpel.config.transaction">required</property>
<property name=bpel.config.oneWayDeliveryPolicy">sync</property>

例8-12 アダプタ・コンポーネントで設定するトランザクション・プロパティ

<component name="SamplesCreateCustomerSiebelJMSConsumerProcess">
<implementation.bpel
src="SamplesCreateCustomerSiebelJMSConsumerProcess.bpel"/>
<property name="bpel.config.transaction">required</property>
<property name=bpel.config.oneWayDeliveryPolicy">sync</property>
</component>

8.6.5.3 同じスレッド内で異なるトランザクション内でのABCSからの非同期操作

ABCSがプロセスで非同期操作を呼び出す必要があり、ABCSと同じスレッド内だが異なるトランザクション内でその操作を実行する必要がある場合は、コール先BPELコンポジットで次の構成を設定します。

<property name="bpel.config.oneWayDeliveryPolicy">sync</property>

この場合、コール先BPELはコール元とは異なるトランザクションで実行されるため、コール先BPELコンポジットでトランザクション構成bpel.config.transactionを設定する必要はありません。

8.7 メッセージ配信の保証

保証付きメッセージ配信とは、エラーが発生した場合でも、プロデューサからコンシューマに送信されるメッセージが失われないことを意味します。

AIAでは、非同期で信頼できるメッセージ配信のためにキューを使用します。次に例を示します

- PeopleSoft CRMは、ビジネス・イベントが発生すると、メッセージをキューに直接プッシュするか、またはキューにメッセージを入れるJMSメッセージ・プロデューサ(JMSトランスポート・アダプタ)にSOAPメッセージをHTTP経由で送信できます。
PeopleSoft CRMは、メッセージがキューに入るのと同時に、そのメッセージを送信済とみなします。このメカニズムを使用して、PeopleSoft CRMアプリケーションは、CRMオンプレミスが使用可能かどうかに関係なく、新規メッセージを継続して送信できます。

- JMSコンシューマ(もう1つのJMSトランスポート・アダプタ)は、メッセージをデキューして、PeopleSoft CRM ABCSを呼び出します。
PeopleSoft CRM ABCSを使用すると、EBS、CRMオンプレミスABCS、JMSメッセージ・プロデューサによって開始されたトランザクションに含まれるWebサービスでは、CRMオンプレミス・アプリケーションでタスクが正常に完了した後にのみメッセージがキューから削除されます。

8.8 ABCSのバージョニング

サービスのバージョニングとは次の意味です。

- コンポジットの名前およびサービス・コンポーネントの名前にバージョン接尾辞がある新規サービス。

- サービス・コンポーネントのWSDLのターゲット・ネームスペースは、新しいバージョンを示します。

AIAネーミング標準の詳細は、「AIA開発でのOracle AIAネーミング標準」を参照してください。

8.8.1 バージョニングに関するガイドライン

準備フェーズでは、次のガイドラインに注意してください。

- 1つのABCSが事前作成済の複数の統合間で使用されます。事前作成済の統合に固有ではありません。
たとえば、EBizRequesterCreateItemABCSは、ISCM事前作成済の統合およびAgile PLM - Ebiz統合の事前作成済の統合で使用されます。

- Oracle Enterprise Repositoryを使用して、サービスの存在を調べます。
サービス定義注釈はOracle Enterprise Repositoryに保持されます。Oracle Enterprise Repositoryは、事前作成済の統合を表してサービスを構成する、概念的および物理的な様々なアセットを文書化します。

- バージョン接尾辞を変更せずにABCSに加えるインライン変更は、下位互換性が必要です。

- バージョン間で意味的および技術的に非互換のコントラクトがある1つのサービスに対して、複数のバージョンは使用できません。
コントラクトが全体的に異なる場合は、実行される操作や動詞が同じ場合でも、既存のABCSのバージョン付けはできません。

- ABCSは、アプリケーション・バージョンとは関係なくバージョン付けされます。
ABCSは、特定のアプリケーション・バージョンにバインドされません。アプリケーションでバージョン変更が行われても、同様のバージョン変更を行うためにABCSにバインドされることはありません。したがって、ABCSはアプリケーションのバージョン変更に依存しないように設計されています。

- ABCSの複数のバージョンが同時に存在するのは避けてください。
たとえば、チームAがバージョン1を所有し、チームBはこのコントラクトが適切でないため、異なるMEP/コントラクトを使用してバージョン2を作成したとします。これで、チームAは、前のバージョンと矛盾するコントラクトを使用してバージョン3を作成できます。

- 特定の役割(リクエスタ/プロバイダ)を使用して単一のビジネス・アクティビティを実行する1つのアプリケーションに対して、複数のサービスは使用できません。

- 同じロジックを使用する複数のサービスに、異なる名前(コンポジットやサービスの異なる名前、またはWSDLの異なるportType)を付けないでください。

- 異なるロジックを使用する複数のサービスに、同じ名前を付けないでください。

EBSに定義される操作によってABCSの実装が決まります。

EBSに定義される操作は、ビジネス・アクティビティ/タスクによって指定されます。

ビジネス・アクティビティ、タスクまたはその両方のバリエーションが可能です。これらはコンテキストの形式で渡され、異なるABCSによって実装されます。

特定のアプリケーションおよびビジネス・アクティビティのABCSを作成、使用またはその両方を行う複数のチームは、コントラクトについて同意する必要があります。

8.9 Oracle Mediatorにおける再順序付け

この項では、Oracle Mediatorにおける再順序付け機能の概要を示し、Oracle AIAの非同期メッセージ交換パターンで設定および使用する方法を説明します。

Oracle AIAの非同期メッセージ交換パターンでは、参加アプリケーションがメッセージをOracle AIAレイヤーにプッシュし、このレイヤーでメッセージがストア・アンド・フォワード方式で処理されます。

このメッセージ交換パターンでは、同じオブジェクト・インスタンスに関連するメッセージを、メッセージが生成された順序で処理する必要があります。Oracle Mediatorのリシーケンサを使用すると、正しい処理順序を維持するのに役立ちます。

リシーケンサは、関連性はあるが順序が正しくないメッセージのストリームを再配置して順序どおりに戻すために使用します。ランダムな順序で到着した受信メッセージを順序付けしてから、ターゲット・サービスに正しい順序で送信します。

メッセージの順序は、次の永続ポイントまで維持されます。次の永続ポイントがアプリケーションでない場合、メッセージは再順序付けされる必要があります。

SiebelアプリケーションがCreateOrder/UpdateOrderメッセージを送信し、そのメッセージがJMSキューにエンキューされる統合シナリオを考えてみます。これらのメッセージは、JMSコンシューマ・アダプタ・サービスによってデキューされ、処理のために下位に送信されます。受信メッセージがJMSキューに到着するとき、ネットワークの遅延、サーバーの停止など様々な理由でメッセージがランダムな順序になる可能性があります。リシーケンサは順次または時系列の情報に基づいてメッセージを順序付けした後、正しい順序でターゲット・サービスにメッセージを送信します。

図8-13に、Siebelアプリケーションからのメッセージの受信ストリームがJMS宛先に保持され、正しい順序で処理されるユースケースを示します。

図8-13 Oracle Mediatorの再順序付け機能を使用したメッセージ順序付け

順序付けは、選択した順序付け方法に基づいて処理されます。メディエータには、3タイプのリシーケンサが用意されています。

- 標準リシーケンサ

- FIFOリシーケンサ

- ベスト・エフォート・リシーケンサ

Oracle Mediatorのリシーケンサ機能の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のOracle Mediatorにおける再順序付けに関する項を参照してください。

8.9.1 リシーケンサ機能を使用するOracle Mediatorサービスの構成

これはOracle Mediatorの機能であるため、メディエータ・サービスが設計どおりに機能するように適切な場所に配置する必要があります。

この項では、再順序付け機能を使用するようにOracle Mediatorサービスを構成する方法を説明します。

- メディエータ・コンポーネントのMplanファイルを設計モードで開きます。

- 「再順序レベル」で「操作」を選択します

注意:

メディエータでは、「再順序レベル」で「操作」または「コンポーネント」のいずれかを選択できます。操作が1つのみのメディエータ・コンポーネントでは、「再順序レベル」で「操作」または「コンポーネント」を選択したかどうかは問題ではありません。複数の操作が定義されているメディエータで「コンポーネント」オプションを選択することは、すべての操作に再順序付けが適用されることを意味します。

メディエータについて、「再順序レベル」で「操作」を選択することをお薦めします。図8-14は、再順序レベルが操作レベルで選択されたコンポジットmplanのスクリーンショットです。

図8-14 操作レベルで選択された再順序レベル

リシーケンサが機能するには、再順序付け方法に応じて、ソース・ペイロードの次の値の一方または両方を使用します。

最初はsequenceIDで、次はgroupIDです。sequenceIDはメッセージ自体の識別子として使用されます。groupIDは、リシーケンサがsequenceIDに基づいてメッセージを再編成するためにメッセージをグループ化するのに使用されます。

8.9.2 再順序付け方法の構成方法

1. 次の3つのオプションから再順序タイプを決定して設定します。

- 標準: 受信メッセージに、既知の増分および開始順序番号を使用する順序IDとして整数が含まれる場合に使用します。

- ベスト・エフォート: 受信メッセージに順序IDとしてタイムスタンプが含まれる場合に使用します。

- FIFO: その他のすべてのケースで使用します。

図8-15は、再順序タイプが表示されたスクリーンショットです。

図8-15 再順序タイプ

2. 再順序オプションを設定します。

a. グループを決定して設定します
グループIDは受信メッセージのパラメータ(フィールドまたは属性)で、順序付けされるメッセージのグループを一意に識別します。

例: CustomerId、OrderId、ProductId、Account IDなど。

グループIDを構成するには、「再順序オプション」の「グループ」に、リシーケンサが受信メッセージのグループ化に使用するペイロードのフィールドをポイントするXPath式を設定します。これによって、特定のグループに属するメッセージが順序に従って処理されます。

例: SyncCustomerPartyListEBM/ns0:SyncCustomerPartyListEBM/ns0:DataArea/ns0:SyncCustomerPartyList/ns0:CustomerPartyAccount/corecom:Identification/corecom:ApplicationObjectKey/corecom:ID[@schemeID='AccountId']。

図8-16は、「グループ」フィールドにXPath式が表示されたスクリーンショットです。

図8-16 再順序オプション

b. IDを決定して設定します
IDは受信メッセージのパラメータ(フィールドまたは属性)で、順序内でのメッセージの位置を示します。

IDは、再順序付けが実行される受信メッセージのフィールドをポイントするXPath式によって宣言されます。

例: $in.SyncCustomerPartyAccountListEBM/ns0:SyncCustomerPartyAccountListEBM/ns0:DataArea/ns0:SyncCustomerPartyAccountList/ns0:CustomerPartyAccount/corecom:Identification/corecom:ApplicationObjectKey/corecom:ID /@schemeID

図8-17は、「ID」フィールドにXPath式が表示されたスクリーンショットです。

図8-17 「ID」パラメータの設定

c. 「ベスト・エフォート」再順序モードの再順序オプションを設定します。受信メッセージは、リシーケンサに対して順序付けに使用する識別子の情報を提供できません。通常、このようなシナリオで順序付けに使用される識別子は、dateTimeタイプまたはnumericタイプです。dateTimeフィールドを順序ID XPathとして使用すると、順序付けを制御できます。
図8-18は、dateTimeオプションが選択されているスクリーンショットです。

図8-18 「ベスト・エフォート」再順序モードの再順序オプション

リシーケンサ・メディエータ・サービスがJMSコンシューマ・アダプタ・サービスとリクエスタABCSの間に配置されている場合は、メッセージがリシーケンサに到達するとJMSキューからそのメッセージが削除されるため、トランザクション境界がリシーケンサ・ストアにシフトします。

8.9.3 複数グループの同時処理

再順序付けのために着信したメッセージは、複数のグループに分割され、IDを選択する再順序付け方法に従ってグループ内のメッセージが順序付けされます。グループ内の順序付けは、他のグループのメッセージの順序とは独立して実行されます。グループ自体は相互に依存していないため、独立して処理できます。

たとえば、Update OrderメッセージのaccountIDがグループIDとして使用される場合、特定のアカウントIDを持つ着信Update Orderメッセージは、別のアカウントIDを持つUpdate Orderメッセージから独立してグループとして処理されます。

リシーケンサは、リシーケンサから直接メッセージを受信するポイントまで、正しい処理順序を維持するのに役立ちます。再順序付けされるメッセージを受信するプロセスに非同時性が導入されている場合、順序は保証されません。つまり、メッセージの順序は、次の永続ポイントまで維持されます。その後、メッセージは再順序付けされる必要があります。

8.9.4 Oracle Mediatorのリシーケンサのエラー管理の説明

グループのメッセージが失敗すると、そのグループのメッセージ処理が停止され、保留メッセージが保持されます。エラー・メッセージはエラー・ホスピタルに配置され、再試行可能なすべてのメッセージについて修正および再発行を行います。

同じグループIDのすべてのメッセージが、異なるトランザクションのシングル・スレッドで処理されます。メッセージの処理に失敗した場合、そのグループの残りのメッセージは一時停止されます。したがって、エラーが発生したメッセージを再発行してください。メッセージを再試行または中断した後にのみ、処理が次の順序から再開します。

他のグループのメッセージの処理は介入なしで続行されます。

エラーが発生したグループの新しいメッセージが着信すると、メッセージはリシーケンサ・ストアに格納されるため失われません。失敗したメッセージがOracle Enterprise Manager (OEM)コンソールまたは別のツールから再発行されると、エラーが発生した関連グループのロックが解除され、そのグループの通常処理が再開します。

8.9.4.1 エラーが発生したメッセージの再発行

メッセージをグローバル・トランザクションのフローのサービスまたはコンポーネントに配信できない場合、そのメッセージは適切なソース・マイルストンにロールバックされます。このソース・マイルストンは、キュー、トピックまたはリシーケンサに相当します。メッセージは、サービスまたはコンポーネントに配信するための再発行が可能になるまで、ここに保持されます。

メッセージ再発行ユーティリティを使用して、エラーが発生したメッセージを再発行するには、JMSコンシューマを使用してソース・マイルストンから受信メッセージがデキューされたときに、最初にメッセージ再発行パラメータを使用して受信メッセージを入力する必要があります。

これらの値を受信メッセージに入力する方法の詳細は、「メッセージ再発行値の入力」を参照してください。

8.9.4.2 メッセージ再発行ユーティリティAPIの使用

メッセージ再発行ユーティリティAPIを使用すると、外部プログラムは、トランザクションで使用できるようにエラー状態のメッセージを有効にできます。通常、このユーティリティは、メッセージがエラーで終了した問題を修正するために実行されます。

再発行ユーティリティの詳細は、Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイドのリシーケンサ・ベースの再発行に関する項を参照してください。

エラーを生成するメッセージはエラー・ホスピタルに移されます。グループはエラー状態に移り、ワーカー・スレッドで取得されません。エラー・ホスピタルを使用して、エラー生成メッセージを再発行できます。メッセージを再発行した後に、グループは通常状態に移るため、ワーカー・スレッドで取得できるようになります。

8.9.5 リシーケンサの調整

次のパラメータを使用して、リシーケンサを調整できます。

ResequencerWorkerThreadCount: リシーケンサによって使用されるスレッドの数。

ResequencerMaxGroupsLocked: スレッドでロックできる最大グループ数。

スリープ間隔: メッセージ頻度が高い場合は、スリープ間隔を低く設定します。ワーカー・スレッドがアイドル状態にならないように、ロックするグループ数にはワーカー・スレッド件数より多い値を設定することをお薦めします。デフォルトでは、ResequencerMaxGroupsLockedとResequencerWorkerThreadCountには同じ値が設定されます。

注意:

コンポジットに対してリシーケンサをオンにした後は、実行時にリシーケンサをオフにできません。

8.10 レイヤー・カスタマイズの開発

Oracleアプリケーションのコンポジットは、特定の業界のニーズにあわせて作成されます。また、各組織のビジネス固有のニーズにあわせて、これらのコンポーネントをさらにカスタマイズするためのオプションも用意されています。カスタマイズとは、新しい動作を形成するために、提供されたアーティファクトを変更することです。このオプションを使用して、Oracleから提供されるデフォルトのコンポジットをカスタマイズでき、そのコンポジットを当初の場所にデプロイすることもできます。いくつかのコンポジットをカスタマイズして、組織に固有のソリューションを作成します。

ただし、新しいバージョンがある場合にパッチまたは更新を適用すると、これらのカスタマイズが上書きされる可能性があります。上位レイヤーでのカスタマイズが更新時に失われないようにするために、カスタマイズされたレイヤーと基本プロセスは独自のメタデータ・ファイルに保持されます。基本バージョンがカスタマイズ可能な場合のみ、カスタマイズを基本コンポジット以外の外部に保持できます。ソリューションをデプロイする場合のみ、レイヤーが基本プロセスとマージされ、単一の実行可能プロセスが作成されます。

レイヤー・カスタマイズの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のSOAコンポジット・アプリケーションのカスタマイズに関する項を参照してください。

すべてのコンポジットがカスタマイズ可能か。

デフォルトの事前作成済の統合セットに提供されたサービスの場合、カスタマイズ可能なスコープがBPELフローに追加されます。事前作成済の統合でサービスのカスタマイズが可能かどうかを確認するには、事前作成済の統合の実装ガイドを参照してください。JDeveloperでカスタマイズ開発者ロールを使用してBPELを開く場合は、カスタム・ロジックをこれらのスコープに追加できます。これらのカスタマイズは基本定義とは別に保持されます。カスタム・ロジックをこれらのスコープに追加する利点は、更新時にカスタマイズが保持されることです。後続のパッチまたは新しいリリースを取り込むと、新しい基本定義に加えてこれらのカスタマイズをマージして、BPELをデプロイできます。

カスタマイズ可能なスコープを含むサービスがない事前作成済の統合は、カスタマイズできません。

カスタマイズを行う際は、次のガイドラインに準拠してください。

- カスタマイズは、カスタマイズ可能なスコープがあるBPELベースのAIAアーティファクトに対してのみ可能です。他のアーティファクトに対して行ったインライン・カスタマイズは、パッチを適用したり新しいバージョンに更新すると上書きされます。

- カスタマイズ可能とマークされていないコンポジットは、後でコンポジットにパッチが適用されるとマージの競合が発生するため、カスタマイズしないでください。

- デフォルトで定義されている変数をカスタマイズされたコードに従ってセクションで使用すると、BPELフローの動作に悪影響を与える場合があるため、デフォルトで定義されている変数やメッセージは変更しないでください。

8.10.1 カスタマイズ後のサービスのデプロイ

カスタマイズ後にサービスをデプロイする手順は、次のとおりです。

1. JDeveloperツリーで、カスタマイズされたコンポジットを右クリックします。

2. Make<カスタマイズされたコンポジット名>.jarを選択して、変更内容をコンパイルします。

3. Jdeveloperの作業場所からCustomizeAppフォルダを開きます。

デフォルトのコードおよびカスタマイズされたコードを格納するmergedという名前のフォルダを参照できます。

4. このマージされたフォルダをサーバーにコピーし、アプリケーション・デプロイメント・ドライバを使用してコンポジットをデプロイします。

8.10.2 顧客バージョンのカスタマイズ

SOAコンポジット・アプリケーションの顧客バージョンをカスタマイズする場合は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の、顧客バージョンのカスタマイズに関する項を参照してください。

8.10.3 カスタマイズ後のパッチの適用

カスタマイズした後にパッチを適用する場合は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の、コンポジットの更新に関する項を参照してください。この指示は、レイヤーを新しい基本コンポジットに適用する場合に役立ちます。

9 エンタープライズ・ビジネス・フローの設計と作成

この章では、エンタープライズ・ビジネス・フロー(EBF)の概要を示し、EBFを定義して実装する方法を説明します。

注意:

コンポジット・ビジネス・プロセス(CBP)は、次のリリースから非推奨となります。人間/システム相互作用のモデル化には、BPMの使用をお薦めします。

この章の内容は次のとおりです。

- エンタープライズ・ビジネス・フローの概要

- EBF用のコントラクトの定義方法

- EBF用のコントラクトの作成方法

- EBFをBPELサービスとして実装する方法

9.1 エンタープライズ・ビジネス・フローの概要

EBFは、複数のアプリケーションで使用可能な機能を含むビジネス・アクティビティまたはタスクを実装するために使用します。EBFは、アプリケーションで使用可能な一連の機能を1列に並べて粒度の粗いビジネス・アクティビティまたはタスクを実装したり、既存の機能を利用する新しいサービスを構成します。EBFには、システム間またはサービス間の相互作用のみ含まれます。EBFには、管理者操作が必要なアクティビティはありません。

正規の統合では、EBFはエンタープライズ・ビジネス・サービス(EBS)操作の実装で、他のEBSをコールします。アプリケーション・ビジネス・コネクタ・サービス(ABCS)やアプリケーションを直接コールすることはありません。他の統合スタイルでは、EBFを呼び出すコール元はアプリケーションまたはその他のサービスのいずれかになります。

図9-1および図9-2に、注文から現金化までのプロセス統合パックの事前作成済の統合にある複数のEBFを実装して、既存の機能を利用する方法を示します。

図9-1に、ソース・アプリケーションとターゲット・アプリケーション間で顧客を同期化するためにフローを編成するEBFを示します。ソース・アプリケーションからsync操作が呼び出されると、EBFは最初に、ターゲット・アプリケーションに顧客が存在するかどうかを確認します。そうである場合はターゲット・アプリケーションの顧客を更新し、そうでない場合はターゲット・アプリケーションに顧客を作成します。

図9-1 ソースからターゲットにフローを編成するEBFの例

図9-2に、受注を受け取り、顧客の作成、履行、およびソース・アプリケーションへのレスポンスによる更新を編成するフローを示します。

図9-2 受注フローの例

9.2 EBF用のコントラクトの定義方法

EBFを設計および実装するためのOracle Application Integration Architecture (AIA)の手法は、コントラクト最優先手法です。したがって、コントラクトはEBFの実装前に定義して作成する必要があります。

コントラクトを定義する手順は、次のとおりです。

1. EBFを識別します。

2. EBFのパターンを識別します。

3. リクエストおよびレスポンス(ある場合)に使用するエンタープライズ・ビジネス・メッセージ(EBM)を識別します。

9.2.1 EBFの必要性を識別する方法

新規サービスの設計に含まれる最初のタスクは、そのサービスが必要かどうかを検証することです。

- 識別した機能の一部またはすべてを提供するサービスがすでに存在している可能性もあります。新しいサービスまたは操作を作成する前に、個々のサービス、操作の説明、およびメタデータをレビューしてください。

- EBFが必要となるのは、EBS操作を一連のタスクとともに実装する必要があり、複数のサービスを呼び出す場合です。

- 正規ベースの統合では、EBFは別のEBSのみ呼び出すことができます。

9.2.2 EBFのメッセージ・パターンを識別する方法

エンタープライズ・ビジネス・フローは、単一の操作を実装するようにモデル化されています。

EBFのメッセージ交換パターン(MEP)を識別する手順は、次のとおりです。

1. 機能設計ドキュメント(FDD)で明らかになったビジネス・プロセス要件に基づいて、EBFをトリガーするイベントを識別します。例9-1を参照してください。

a. 呼出しのポイントにレスポンスが返ってくるまで制御をブロックする場合は、EBFリクエスト/リプライ・パターンを選択します。これは同期コールです。

b. EBFの呼び出した後に、トリガー・ポイントでレスポンスを待たずに処理を続行する場合、そのEBFの呼出しは非同期コールです。
EBFの処理後にレスポンスが返されるかどうかを確認します。

リクエストとレスポンスの関連付けが必要ですか。

答えがYesの場合、これは遅延レスポンスです。EBFリクエスト/遅延レスポンス・パターンを使用してください。答えがNoの場合は、EBFファイア・アンド・フォーゲット・パターンを選択してください。

公開イベントへのサブスクリプションによって呼び出されるすべてのEBF操作は、EBSサブスクライブ・パターンを使用します。

例9-1 EBFのメッセージ交換パターン識別の例

<operation name="InterfaceSalesOrderToCustomer">
<documentation>
<svcdoc:Operation>
<svcdoc:Description>This operation is used to interface
sales order to customer</svcdoc:Description>
<svcdoc:MEP>ASYNC_REQ_RESPONSE</svcdoc:MEP>
<svcdoc:DisplayName>InterfaceSalesOrderToCustomer</svcdoc:DisplayName>
<svcdoc:LifecycleStatus>Active</svcdoc:LifecycleStatus>
<svcdoc:Scope>Public</svcdoc:Scope>
</svcdoc:Operation>
</documentation>
<input message="client:InterfaceSalesOrderToCustomerReqMsg"/>
</operation>

9.2.3 メッセージ構造を識別する方法

メッセージ構造を識別する手順は、次のとおりです。

1. CBPは、コールを外部サービスに編成することによって実装されます。CBPをトリガーするイベントは、CBPが処理するビジネス・オブジェクトを示します。

2. 統合スタイルに応じて、次に説明するようにメッセージ構造が決まります。

a. ビジネス・オブジェクトが既存のエンタープライズ・ビジネス・メッセージ(EBM)で使用可能な場合は、そのビジネス・オブジェクトを使用します。

b. ビジネス・オブジェクトが既存のEBMで使用不可だが、既存のエンタープライズ・ビジネス・オブジェクト(EBO)ライブラリからアセンブル可能な場合は、そのビジネス・オブジェクトを作成します。

c. ビジネス・オブジェクトがEBOライブラリで使用不可の場合は、CBPのすべての関連情報と処理を取得するのに適切なペイロードを識別します。

9.3 EBF用のコントラクトの作成方法

EBF用のコントラクトを作成する手順は、次のとおりです。

1. EBMを識別します。

2. EBF用のWSDLを作成します。

3. サービス・インタフェースに注釈を付加します。

4. WS-1基本プロファイルに準拠していることを確認します。

9.3.1 EBF用のWSDLの作成

EBFの開発はWSDLの作成から始まり、技術設計プロセスの結果がEBF WSDLです。

9.4 EBFをBPELサービスとして実装する方法

EBFを実装する手順は、次のとおりです。

1. WSDLを作成します。

EBFのネーミング標準、および提供されているWSDLテンプレートに従って、EBF用のWSDLを作成します。

2. EBFを同期または非同期BPELプロセスとして実装します。

Oracle JDeveloperでのBPELプロジェクトの作成の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』でOracle BPEL Process Managerの使用開始に関する項を参照してください。

BPELを使用して非同期リクエスト/遅延レスポンス・パターンを実装する方法の詳細は、「非同期リクエスト/遅延レスポンスMEPの実装」に従ってください。相違点は、EBFがEBMを処理することです。

3. エラー処理とロギングを有効にします。

EBSは、クライアントまたは管理者がプロセスを再発行または再トリガーできるようにエラーを処理する必要があります。これは一元的なエラー・ハンドラを使用して行われます。

詳細は、「エラー処理およびトレース・ロギング用のOracle AIAプロセスの構成」を参照してください。

4. EBFの拡張ポイントを有効にします。

10 AIAを使用したB2B統合の概要

企業間(B2B)統合では、選択したB2Bドキュメント・プロトコルを使用して、取引パートナとビジネス情報を交換する機能が必要です。この章では、AIAを使用したB2B統合、B2Bドキュメント・フロー、Oracle Fusion MiddlewareのB2Bコンポーネント、およびB2B用のSOAコア拡張機能インフラストラクチャの概要を説明します。

この章の内容は次のとおりです。

- AIAを使用したB2B統合の概要

- B2Bドキュメント・フローの理解

- Oracle Fusion MiddlewareのOracle B2Bコンポーネントの理解

- B2B用のSOAコア拡張機能インフラストラクチャの理解

10.1 AIAを使用したB2B統合の概要

Oracle Application Integration Architecture (AIA)のB2Bソリューションは、次の主要な機能で構成されています。

- 新しいB2Bドキュメント・プロトコルに対するサポートを迅速に作成するために使用できる柔軟な統合アーキテクチャ。

- AIAおよびOracle Fusion Middlewareを使用したエンドツーエンドのB2Bフローの作成に使用できるインフラストラクチャ・コンポーネント。

- 一般的なB2Bドキュメント・プロトコルに対する事前作成済のサポート。

- 同梱のB2B統合アーティファクトに対するカスタマイズのサポート。

図10-1に、大規模な企業のB2B統合ニーズを満たすためのAIAの正規ベース統合アーキテクチャの適用方法を示します。

図10-1 AIAのB2Bアーキテクチャの構成図概要

次に、B2B統合にAIAを使用する主要な利点を示します。

- AIAでは、参加アプリケーションがB2B統合レイヤーから分離されます。
参加アプリケーションでは、取引パートナの変化するB2B統合ニーズを追跡する必要がなくなりました。また、顧客は、新しいB2Bプロトコルおよび取引パートナ要件に対するサポートを追加でき、この追加によって参加アプリケーション・コードは影響されません。

- B2Bドキュメント・フローは通常、注文獲得などの複雑なビジネス・プロセスで構成されるタスクのサブセットです。
B2B機能をSOAコア拡張機能の最上部のレイヤーとして作成すると、この機能を複数のアプリケーションおよびビジネス・プロセスで再使用できます。

- 顧客、サプライヤ、品目、注文書、出荷、請求書、カタログ住所などの既存のAIAのエンタープライズ・ビジネス・オブジェクト(EBO)は、一般的に使用されるB2Bドキュメントの大半にマップされます。
これらの簡単に使用できるEBOの使用、およびこれらのEBOに対する事前作成済のB2Bコネクタ・サービス(B2BCS)によって、B2B統合では多大な時間とコストが節約されます。

10.2 B2Bドキュメント・フローの理解

この項には次のトピックが含まれます:

- AIAを使用して作成されたアウトバウンドB2Bドキュメント・フローの説明

- AIAを使用して作成されたインバウンドB2Bドキュメント・フローの説明

10.2.1 AIAを使用して作成されたアウトバウンドB2Bドキュメント・フローの説明

図10-2に、AIAを使用して実装されたサンプルのアウトバウンドB2Bフローを示します。

図10-2 アウトバウンドB2Bドキュメント・フロー

次に、アウトバウンドB2Bドキュメント・フローの主要なステップを示します。

1. 参加アプリケーションは、リクエスタ・アプリケーション・ビジネス・コネクタ・サービス(ABCS)およびペイロードとしてアプリケーション・ビジネス・メッセージ(ABM)をトリガーします。
ベスト・プラクティスの推奨は、ファイア・アンド・フォーゲット・フローをモデル化する一方、アプリケーションとリクエスタABCS間でキューベースの通信を使用することです。これによって、リクエスト・メッセージは保持されてその処理は保証されます。

2. リクエスタABCSは、ABMをエンタープライズ・ビジネス・メッセージ(EBM)に変換し、次にエンタープライズ・ビジネス・サービス(EBS)実装を呼び出します。

3. EBSは、EBMを調査して、取引パートナのB2Bドキュメント・プリファレンスに基づいて適切なプロバイダB2BCSにルーティングします。

4. プロバイダB2BCSは、EBMを業界標準のB2B形式に変換して、AIA B2Bインタフェース・サービスを呼び出します。

5. AIA B2Bインタフェース・サービスは、必要なヘッダー・パラメータを入力して、B2Bペイロードを入力として渡すOracle Fusion Middleware B2Bコンポーネントを呼び出します。

6. Oracle B2Bは、取引パートナおよびドキュメント・タイプに対応する取引パートナ・アグリーメントを参照して、B2Bドキュメントをリモート取引パートナに安全にトランスポートします。

7. Electronic Data Interchange (EDI)などの非XML形式ベース・プロトコルの場合は、Oracle B2Bの変換機能を使用して、AIAレイヤーで生成された中間XMLを非XMLのB2Bドキュメント形式に変換できます。

10.2.2 AIAを使用して作成されたインバウンドB2Bドキュメント・フローの説明

図10-3に、AIAを使用して実装されたサンプルのインバウンドB2Bフローを示します。

図10-3 インバウンドB2Bドキュメント・フロー

次に、インバウンドB2Bドキュメント・フローの主要なステップを示します。

1. Oracle B2Bは、取引パートナからB2Bドキュメントを受信して、送信元取引パートナおよびB2Bドキュメント・タイプを識別します。

2. EDIなどの非XML形式の場合、Oracle B2Bは、インバウンド・ペイロードを中間XML形式に変換します。

3. メッセージは、JMS B2Bインバウンド・キューにキューされます。B2Bドキュメント・ペイロードとともに、B2Bドキュメントに関する次の主要メタデータもAIAおよびSOAコンポジット・レイヤーに渡されます。

- 送信元取引パートナ

- 送信先取引パートナ

- ドキュメント・タイプ

- ドキュメント・タイプ・リビジョン

4. AIA B2Bインタフェースは、Oracle B2BからB2Bドキュメントおよびヘッダー情報を受信して、ドキュメント・タイプのパラメータに基づいて適切なリクエスタB2BCSにルーティングします。

5. リクエスタB2BCSは、B2BドキュメントをEBMに変換してEBSを呼び出します。

6. EBSは、EBMを調査して、適切なプロバイダABCSにルーティングします。

7. プロバイダABCSは、EBMをABM形式に変換して、参加アプリケーションAPIまたはWebサービスを呼び出します。

10.3 Oracle Fusion MiddlewareのOracle B2Bコンポーネントの理解

Oracle B2Bは、企業と取引パートナ間における安全で信頼性の高いビジネス・ドキュメントの交信を可能にするE-Commerceゲートウェイです。Oracle B2Bは、B2Bドキュメント標準、セキュリティ、トランスポート、メッセージング・サービス、および取引パートナ管理をサポートしています。Oracle B2Bがバインディング・コンポーネントであるOracle SOA Suiteプラットフォームにより、E-Commerceビジネス・プロセスの実装が可能になります。

この項には次のトピックが含まれます: AIAによるOracle Fusion Middleware Oracle B2Bの補完。

10.3.1 AIAによるOracle Fusion Middleware Oracle B2Bの補完

前の項で説明したように、AIAは、Oracle B2Bコンポーネントの機能を利用して、エンドツーエンドのB2B統合ソリューションを作成します。特に、B2B統合領域では、Oracle B2B機能とAIA機能間の主要な区別に注意してください。

高度なOracle B2Bでは、次の機能を提供することでB2Bをサポートします。

- リモート取引パートナ・システムへのB2Bドキュメント・ペイロードのトランスポート。

- 暗号化、デジタル署名および否認防止を使用した安全な統合のサポート。

- Applicability Statement 2 (AS2)やRosettaNet Implementation Framework (RNIF)などの業界標準のメッセージ・パッケージング・プロトコルのサポート。

- EDI、位置指定フラット・ファイルまたはデリミタ区切りフラット・ファイルなどの非XML形式とXML間での透過的な構成ベースの変換。

- 監査やレポートを含む、単一のエンタープライズB2B情報ゲートウェイのサポート。

高度なAIAでは、次の機能を提供することでB2Bをサポートします。

- AIA正規オブジェクト形式とB2B標準ドキュメント形式間での変換の事前作成。

- カスタムB2B統合の作成に使用できる正規のエンタープライズ・オブジェクト・ライブラリとサービス、参照アーキテクチャ、インフラストラクチャおよび開発ツール。

- SOA統合ベスト・プラクティスを使用したB2Bフローのビジネス・プロセス編成。

Oracle B2Bの詳細は、『Oracle B2Bユーザーズ・ガイド』を参照してください。

10.4 B2B用のSOAコア拡張機能インフラストラクチャの理解

この項には次のトピックが含まれます:

- AIAエラー処理フレームワークのB2Bサポート

- AIA B2Bインタフェース

B2B統合を支援するSOAコア拡張機能では、アーキテクチャおよびプログラミング・モデルとともに、追加のインフラストラクチャ・コンポーネントが提供されます。

この項では、SOAコア拡張機能で提供されるB2Bインフラストラクチャの高度な説明を提供します。AIAを使用してB2Bフローを開発および実装する場合、図10-4に示すインフラストラクチャ・コンポーネントの使用方法の詳細は、「アウトバウンドB2B統合フローの開発と実装」および「インバウンドB2B統合フローの開発と実装」を参照してください。

図10-4 SOAコア拡張機能のB2Bインフラストラクチャ・コンポーネント

10.4.1 AIAエラー処理フレームワークのB2Bサポート

AIAエラー処理フレームワークには、B2B統合フローのエラー・シナリオに対するサポートが含まれています。

1. AIA B2Bエラー処理インタフェース・コンポジットは、Oracle Fusion Middleware B2Bコンポーネントで発生するエラーをリスニングします。

2. Oracle B2Bで発生したエラーは、B2Bキューからデキューされて正規AIAフォルト構造に変換されます。

3. 次に、このフォルト・メッセージを入力としてAIAエラー処理フレームワークがトリガーされます。

4. AIAエラー処理フレームワークがトリガーされた後は、その付属のエラー処理機能をエラー解決のために利用できます。

AIAエラー処理フレームワークの主要機能を次に示します。

- 正規フォルト・メッセージへのすべてのエラーの変換およびAIAエラー・トピックへのエラーのキュー。

- エラー情報のロギング。

- Oracle BPM Worklistアプリケーションを使用したエラー解決タスクの追跡(オプション)。

- 事前構成済ロールへのエラー通知の発行(オプション)。

- カスタム・エラー処理および補正プロセスの起動機能。

これらのすぐに使用できるエラー処理機能によって、統合コード全体でエラー処理コードの重複が削減されます。

エラー処理フレームワークの機能および取込みの詳細は、Oracle Fusion Middleware Oracle Application Integration Architecture SOAコア拡張機能インフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイドのエラー処理の設定に関する項を参照してください。

10.4.2 AIA B2Bインタフェース

AIA B2Bインタフェースは、Oracle Fusion MiddlewareのB2BCSとOracle B2Bコンポーネント間の抽象レイヤーとして機能する再使用可能なメディエータベースのSOAコンポジットです。AIA B2Bインタフェースは、Oracle B2Bとの接続に採用された内部デリバリ・チャネルからB2BCSを保護します。

AIA B2Bインタフェースは、インストール時にOracle AIAインストーラによって、JMSベースのキューを使用してOracle B2Bに接続するように構成されます。ただし、実装では、特定の統合ニーズに基づいて他の使用可能な内部デリバリ・チャネル(Oracle Advanced Queuing、ファイル・デリバリ・チャネル、B2Bアダプタなど)を使用して、AIAとOracle B2Bを統合することが必要な場合があります。AIA B2Bインタフェース・コンポジットは、JMSの使用をこれらの内部デリバリ・チャネルのいずれかで置換するように変更でき、B2BCSをそれぞれ変更する必要はありません。

B2Bアダプタの詳細は、『Oracle B2Bユーザーズ・ガイド』の、Oracle B2Bの使用開始に関する項を参照してください。

11 アウトバウンドB2B統合フローの開発と実装

この章では、アウトバウンドB2B統合フローの開発と実装の概要を示し、B2Bドキュメントの識別方法と要件の分析方法、新しいプロバイダB2Bコネクタ・サービスの開発、既存のエンタープライズ・ビジネス・サービスの開発または拡張、既存のリクエスタABCSの開発または拡張、Oracle B2Bの構成、取引パートナ・アグリーメントの定義、AIAサービスのデプロイと構成、最後にテスト方法および稼働方法について説明します。

この章の内容は次のとおりです。

- アウトバウンドB2B統合フローの開発と実装の概要

- ステップ1: B2Bドキュメントの識別および要件の分析

- ステップ2: 新規のプロバイダB2Bコネクタ・サービスの開発

- ステップ3: 既存のエンタープライズ・ビジネス・サービスの開発または拡張

- ステップ4: 既存のリクエスタABCSの開発または拡張

- ステップ5: Oracle B2Bの構成および取引パートナ・アグリーメントの定義

- ステップ6: AIAサービスのデプロイと構成

- ステップ7: テストおよび検証

- ステップ8: 稼働および監視

11.1 アウトバウンドB2B統合フローの開発と実装の概要

図11-1に、Oracle Application Integration Architecture (AIA)を使用した、アプリケーションから取引パートナへの単純なアウトバウンド企業間(B2B)フローの開発に含まれる高度なステップを示します。

図11-1 単純なアウトバウンドB2Bフローの開発と実装の高度なステップ

この図に示されている各ステップについては、次の各項で説明します。

11.2 ステップ1: B2Bドキュメントの識別および要件の分析

この項には次のトピックが含まれます:

- B2Bドキュメント・プロトコルの識別方法

- B2Bドキュメント・タイプおよび定義の識別方法

- Oracle B2Bでのドキュメントの定義方法

- AIAでのドキュメントの定義方法

- 使用するEBO、EBSおよびEBMの識別方法

- B2Bドキュメントに対するマッピングの設計方法

- 取引パートナへのマッピングの公開方法

アウトバウンドB2Bフロー作成の最初のステップでは、フローで生成する必要があるB2Bドキュメントを識別します。図11-2に示すように、このステップの一環として、フローをサポートするために作成または拡張する必要があるAIAサービスの要件を分析することも必要です。

図11-2 ステップ1: B2Bドキュメントの識別およびサービス要件の分析

このステップの一環として、統合開発チームは次のタスクを実行します。

- 使用するB2Bドキュメント・プロトコルを識別します。

- 使用するB2Bドキュメント・タイプを識別します。

- Oracle B2BでB2Bドキュメントを定義します。

- AIAでB2Bドキュメントを定義します。

- 使用するAIAのエンタープライズ・ビジネス・オブジェクト(EBO)、エンタープライズ・ビジネス・メッセージ(EBM)およびエンタープライズ・ビジネス・サービス(EBS)を識別します。

- メッセージ交換パターンを識別します。

- EBM、B2Bドキュメントおよびアプリケーション・ビジネス・メッセージ(ABM)をマッピングします。

- マッピングをドキュメント化して公開します。

11.2.1 B2Bドキュメント・プロトコルの識別方法

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ドキュメント・プロトコル・バージョンの決定には、前述と同様の検討事項を使用できます。

11.2.2 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ドキュメント・ガイドラインおよびスキーマを変更する必要があります。

11.2.3 Oracle B2Bでのドキュメントの定義方法

B2Bドキュメント・タイプおよび定義を識別した後は、Oracle B2Bでそのドキュメントを定義する必要があります。これは、これらのドキュメントを取引パートナ・アグリーメントで使用するための前提条件です。

ドキュメント定義の作成の詳細は、『Oracle Fusion Middleware Oracle B2Bユーザーズ・ガイド』のドキュメント定義の作成に関する項を参照してください。

11.2.4 AIAでのドキュメントの定義方法

AIA統合のベスト・プラクティスの推奨では、XMLスキーマやWSDLファイルなどの再使用可能なSOAアーティファクトはすべてSOAメタデータ・ストアで集中的にホストします。再使用可能なアーティファクトを集中的にホストし、それらをAIAサービスから参照することによって、AIAサービスのパフォーマンスが向上し、保守が容易になります。SOAメタデータ・ストアにはキャッシュ機能およびクラスタ機能が用意されているため、このストアを集中的な格納場所として使用すると、それらの機能も利用できます。

B2Bコネクタ・サービスで使用するB2BドキュメントのXMLスキーマ定義も、このメタデータ・ストアでホストします。

B2Bドキュメントをメタデータ・ストアにデプロイする手順は、次のとおりです。

1. B2B標準に対応するディレクトリをB2BObjectLibraryに作成します。

2. B2Bドキュメント・タイプを定義しているXMLスキーマ・ファイルおよびディレクトリをこの場所にコピーします。
B2BObjectLibraryディレクトリは、$AIA_HOME/MetaData/AIAMetaData/AIAComponentsの子ディレクトリです。

たとえば、図11-3に示すように、OAGビジネス・オブジェクト定義をコピーするOAGISディレクトリを作成します。

図11-3 OAGビジネス・オブジェクト定義を格納するために作成されたOAGISディレクトリ

3. このフォルダの下にB2Bドキュメント・タイプに対応するXMLスキーマ・ファイルをコピーします。
たとえば、図11-4に示すように、OAGIS ProcessPurchaseOrder.xsdファイルとそのサポート・スキーマすべてを相対的なディレクトリ構造も保持して、このフォルダの場所にコピーします。

図11-4 OAGISディレクトリに格納された対応するXMLスキーマ・ファイル

4. B2Bオブジェクト・ライブラリの新しいコンテンツをSOAメタデータ・ストアにデプロイします。手順は、次のとおりです。

a. 図11-5に示すように、$AIA_HOME/config/UpdateMetaDataDeploymentPlan.xmlファイルを編集して、Oracle Metadata Services (MDS)でディレクトリB2BObjectLibraryを更新する必要があることを指定します。

図11-5 Oracle Metadata ServicesでB2BObjectLibraryを更新するように編集されたUpdateMetaDataDeploymentPlan.xml

b. $AIA_HOME/bin下に配置されたaiaenv.shファイルをソースとして指定します。例: $source /slot/ems5813/oracle/AIA3_HOME/bin/aiaenv.sh

c. ディレクトリを$AIA_HOME/Infrastructure/Install/configに変更します。例: $cd $AIA_HOME/Infrastructure/Install/config

d. AIAコマンドを発行して、メタデータをデプロイします。例: $ant -f UpdateMetadata.xml

e. コマンドが成功してエラーが発生していないことを確認します。

11.2.5 使用するEBO、EBSおよびEBMの識別方法

AIAを使用したB2Bドキュメントの統合を可能にするために、次のステップでは、使用するAIAのEBO、EBMおよびEBSを識別します。統合する必要があるB2Bドキュメントに最も近い説明があるAIAのEBOおよびEBMを選択します。

たとえば、調達アプリケーションでEDI 850 (注文書)ドキュメントをサプライヤに通信する必要があるアウトバウンドB2B統合フローを開発する場合は、次のEBO、EBMおよびEBSを使用できます。

- EBO: PurchaseOrderEBO

- EBM: CreatePurchaseOrderEBM

- EBS操作: CreatePurchaseOrder

11.2.6 B2Bドキュメントに対するマッピングの設計方法

次のステップでは、ビジネス要件を分析して、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.2.7 取引パートナへのマッピングの公開方法

次のステップでは、マッピング・ドキュメントを取引パートナと共有します。これによって、取引パートナは、受信したアウトバウンドB2Bドキュメントを処理する内部システムに必要な変更を加えることができます。また、取引パートナから受信したフィードバックを使用して、マッピング設計を改訂できます。

11.3 ステップ2: 新規のプロバイダB2Bコネクタ・サービスの開発

この項には次のトピックが含まれます:

- プロバイダB2Bコネクタ・サービスの概要

- メッセージ交換パターンの識別方法

- B2BCSサービス・コントラクトの開発方法

- Oracle Metadata RepositoryへのWSDLの格納方法

- B2Bコネクタ・サービスの開発方法

- AIA B2Bインタフェースのカスタマイズ方法

- B2Bコネクタ・サービスの注釈付け方法

- 取引パートナ固有のバリアントのサポート方法

- エラー処理の有効化方法

図11-6に示すように、次のステップでは、アウトバウンドB2B統合フローをサポートするプロバイダB2BCSを開発します。

図11-6 ステップ2: 新規のプロバイダB2Bコネクタ・サービスの開発

プロバイダB2BCSは、プロバイダ・アプリケーション・ビジネス・コネクタ・サービス(ABCS)と類似していますが、アプリケーションと統合するかわりにOracle B2Bを使用して取引パートナと統合する点のみが異なります。したがって、ABCS (リクエスタおよびプロバイダ)の設計と開発もよく理解することをお薦めします。

11.3.1 プロバイダB2Bコネクタ・サービスの概要

プロバイダB2BCSによって提供される主要な機能は、次のタスクを実行することでアウトバウンドB2Bドキュメント統合を可能にすることです。

- B2BドキュメントへのAIA EBMの変換。

- これらのB2Bドキュメントを取引パートナに送信するためのOracle B2Bの呼出し。

図11-7に、単純なファイア・アンド・フォーゲットのメッセージ交換パターンベースのプロバイダB2BCSで実行される処理を示します。

図11-7 ファイア・アンド・フォーゲットのプロバイダB2BCSの処理フロー

次の各項では、B2BCSの開発手順について説明します。

11.3.2 メッセージ交換パターンの識別方法

ほとんどのB2Bドキュメント・フローは、非同期の一方向コールとしてモデル化できます。

たとえば、アウトバウンドB2Bドキュメント・フローを使用して、調達アプリケーションで作成された注文書をサプライヤに送信する必要があるユースケースを検討します。サプライヤは、受信したこの注文書ドキュメントを処理して、注文書確認B2Bドキュメントを送信して戻します。

このユースケースでは、サプライヤから注文書確認ドキュメント形式のレスポンスが予想される場合でも、調達アプリケーションは処理を続行でき、これには、ベンダーへの注文書の通知およびベンダーによる注文書の処理も含まれます。

ベンダーが、注文書確認メッセージでリクエストで使用されたのと同じ注文書IDを指定することが想定されるため、通常、調達アプリケーションでは、この注文書確認ドキュメントを元の注文書に関連付けることもできます。この方法で、リクエストとレスポンスは2つの非同期の一方向フローとしてモデル化できます。

ただし、設計するB2Bドキュメント・フローごとに、類似した分析を実行する必要があります。

メッセージ交換パターンの識別の詳細は、「MEPの識別」を参照してください。

11.3.3 B2BCSサービス・コントラクトの開発方法

最初に、プロバイダ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

11.3.4 Oracle Metadata Repositoryへの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に格納する手順は、次のとおりです。

1. 作成したWSDLを、AIA_HOMEの下の$AIA_HOME/aia_instances/$INSTANCE_NAME/AIAMetaData/AIAComponents/B2BServiceLibrary/Connectors/wsdls/ <B2B_STANDARD> /ProviderB2BCS/ <バージョン> / <wsdlファイル> .wsdlにコピーします。

2. $AIA_HOME/aia_instances/$INSTANCE_NAME/config/UpdateMetaDataDP.xmlに存在するUpdateMetaDataDP.xmlを実行します。

3. MDSへのSOA-MDSサーバー接続を使用して、図11-8に示すように、AIAMetadataが入力されていることを確認します。

図11-8 MDSのAIAメタデータ

4. これで、/apps/AIAMetaData/AIAComponents/B2BServiceLibrary/Connectors/wsdls/EDI_X12/ProviderB2BCS/V1/ X12UpdateSalesOrderProvB2BCSImpl.wsdlのようなURLを使用して、WSDLにアクセスできます。

11.3.5 B2Bコネクタ・サービスの開発方法

このプロセスの次のステップでは、B2BCSを開発します。前のステップで作成したプロバイダB2BCSのWSDLは、具象B2BCSの開発時にインタフェースとして使用します。

サービス・コンストラクタではB2Bサービスの自動生成がサポートされていないため、Oracle JDeveloperを使用してB2BCSを開発します。前のステップで作成した抽象WSDLに基づいて、BPELプロセスを含むコンポジットを開発します。

次に、B2BCS実装のBPELで開発する必要がある主要アクティビティを示します。

B2BCSを開発する手順は、次のとおりです。

1. 変数<EBM>_Varを定義します。

これは、BPELプロセスへの入力変数で、receiveアクティビティで使用されます。

2. corecom:EBMHeaderタイプの変数EBM_HEADERを定義します。

この変数は、AIAプロセス・コンテキスト情報の格納に使用されたり、フォルト処理メカニズムで使用されます。

3. corecom:B2BMHeaderタイプの変数B2BM_HEADERを定義します。

この変数は、B2B固有のAIAプロセス・コンテキスト情報の格納に使用されたり、フォルト処理メカニズムで使用されます。

4. corecom:B2BMタイプの変数<B2BDoc>B2BM_Varを定義します。

この変数は、Oracle B2BにアウトバウンドB2Bドキュメントを送信するAIAB2BInterfaceの入力として使用されます。

5. 外部のB2BDocument定義を使用して、変数 <B2BDoc>_Varを定義します。

これは、EBMからの変換のターゲットとして使用されます。次に、この値は<B2BDoc>B2BM_Var/Payloadに割り当てられます。

6. AIAB2BInterfaceに対するパートナ・リンクを定義します。

このサービスは、Oracle B2Bを介してB2Bドキュメントを取引パートナに送信するために呼び出されます。AIAB2BInterfaceに対する抽象WSDLは、oramds:/apps/AIAMetaData/AIAComponents/B2BServiceLibrary/Infrastructure/wsdls/V1/B2BInterfaceV1.wsdlから参照できます。

7. EBM_HEADER変数を割り当てます。

EBM_HEADERローカル変数の値は、<入力>EBM/EBMHeader要素のすべての値をコピーして割り当てられます。

8. B2BM_HEADER変数を割り当てます。

表11-1に示すように、値が割り当てられます。

表11-1 B2BM_HEADER変数の割当値

要素

値

例

B2BMHeader/B2BMID

EBMHeader/EBMIDからこのフィールドに値がマップされます。

111A1CD2121

B2BMHeader/B2BDocumentType/TypeCode

Oracle B2Bの定義に従ってB2Bドキュメント・タイプが入力されます。

X12_850

B2BMHeader/B2BDocumentType/Version

Oracle B2Bに構成されているB2Bドキュメント・リビジョンが入力されます。

4010

B2BMHeader/SenderTradingPartner/TradingPartnerID

入力のEBMから値が入力されます。/ <XXX> EBM/EBMHeader/B2BProfile/SenderTradingPartner/TradingPartnerID

Acme

B2BMHeader/ReceiverTradingPartner/TradingPartnerID

入力のEBMから値が入力されます。/ <XXX> EBM/EBMHeader/B2BProfile/ReceiverTradingPartner/TradingPartnerID

GlobalChips

9. EBMをB2Bドキュメントに変換します。

transformアクティビティを使用して、EBMをB2Bドキュメント形式に変換します。前のステップで作成したマッピングごとに開発されたXSLTを呼び出します。

10. <B2BDoc>B2BM_Varを割り当てます。

表11-2に示すように、<B2BDoc>B2BM_Varに値を割り当てます。

表11-2 <B2BDoc>B2BM_Varの割当値

B2BM_Varの割当値" width="90%">

要素

値

<B2BDoc>B2BM_Var//B2BMHeader

B2BM_HEADER変数のコンテンツ

<B2BDoc>B2BM_Var//Payload

B2Bドキュメント変数: <B2BDoc>_Varのコンテンツ

11. AIAB2BInterfaceを呼び出します。

取引パートナにドキュメントを送信するAIAB2BInterfaceを呼び出します。前のステップで割り当てた<B2BDoc>B2BM_VarをAIAB2BInterfaceの入力として使用します。

表11-3に示すように、アクティビティ・パラメータを呼び出します。

表11-3 AIAB2BInterfaceアクティビティの呼出しパラメータ

アクティビティ名

InvokeAIAB2BInterface

Input

<B2BDoc>_B2BMVar

Partner Link

AIAB2BInterface

Port Type

B2BInterface

Operation

SendB2BMessage

12. BPELプロセスをコンパイルして、エラーが発生していないことを確認します。JDeveloperを使用すると、BPELプロセスをSOAコア拡張機能とともにインストールされた開発サーバーにデプロイできます。

13. 入力としてサンプルのEBMペイロードを使用して、サービスをテストします。

11.3.6 AIA B2Bインタフェースのカスタマイズ方法

このドキュメントで前述したように、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インタフェースをカスタマイズする手順は、次のとおりです。

1. Oracle JDeveloperを使用して、SOAアプリケーションの$AIA_HOME/Infrastructure/B2B/src/AIAB2BInterfaceAppを開きます。

2. 図2に示すように、コンポジット・エディタを使用して、AIAB2BInterface/composite.xmlファイルを編集します。

図11-10 コンポジット・エディタのAIAB2BInterface/composite.xml

3. 図3に示すように、サードパーティのB2Bソフトウェアのインタフェースに必要な新しいアダプタまたはWebサービス・コールを追加します。

図11-11 サードパーティのB2Bソフトウェアのインタフェースに対する新規Webサービス・コールの追加

4. 図4および図5に示すように、AIAB2BInterface/ProcessB2BDocument.mplanファイルを変更して、アウトバウンドB2BドキュメントをサードパーティのB2Bソフトウェアにルーティングするカスタム・ルーティング・ルールを追加します。

図11-12 コンポジット・エディタのAIAB2BInterface/ProcessB2BDocument.mplan

図11-13 AIAB2BInterface/ProcessB2BDocument.mplanへのカスタム・ルーティング・ルールの追加

5. 次のコード例に示すように、GatewayID要素で条件式を使用して、サードパーティのB2Bソフトウェアにルーティングする必要があるB2Bドキュメントを識別します。

<condition language="xpath">
<expression>$in.SendB2BM/corecom:B2BM/corecom:B2BMHeader/corecom:GatewayID =
'MyB2BSoftware'</expression>
</condition>

6. 次の図に示すように、必要に応じて変換ステップまたは割当ステップ(あるいはその両方)を使用して、入力B2BM変数($in)に基づいてB2Bソフトウェアに入力を提供します。Oracle B2Bに対するサポートは事前作成されているため、変更は不要です。

図11-14 B2Bソフトウェアに入力を提供する変換ステップ

7. 入力B2BM変数は、プロバイダB2BCSから受信します。次の表に、B2Bソフトウェアに入力を提供するために使用できるB2BM変数の情報を示します。

表11-4 B2Bソフトウェアに入力を提供するために使用できるB2BM変数情報

入力要素

説明

Oracle B2Bとの統合時の使用

$in.B2BM/B2BMHeader/SenderTradingPartner/ TradingPartnerID

アウトバウンド・フローでの送信元取引パートナ。

マップ先: JMSProperty.FROM_PARTY

$in.B2BM/B2BMHeader/ReceiverTradingPartner/ TradingPartnerID

アウトバウンド・フローでの受信先取引パートナ。

マップ先: JMSProperty.TO_PARTY

$in.B2BM/B2BMHeader/B2BDocumentType/TypeCode

アウトバウンド・フローで使用するB2Bドキュメント・タイプ。例: 850。

マップ先: JMSProperty.DOCTYPE_NAME

$in.B2BM/B2BMHeader/B2BDocumentType/Version

アウトバウンド・フローで使用するB2Bドキュメント・タイプ・バージョン。例: 4010。

マップ先: JMSProperty.DOCTYPE_REVISION

$in.B2BM/B2BMHeader/B2BDocumentType/TypeCode/ listAgencyID

アウトバウンド・フローで使用するB2B標準。例: X12。

使用されません。

$in.B2BM/B2BMHeader/B2BMID

一意のB2Bドキュメント識別子。取引パートナ全体で一意。

マップ先: JMSProperty.MSG_ID

$in.B2BM/B2BMHeader/Payload

取引パートナに送信される実際のペイロード。

JMSテキスト・ペイロード

8. AIAB2Bインタフェースの呼出し前にGatewayIDの必要な値が確実に提供されるように、B2BCSによってGatewayID要素の値が提供されます。

9. 変更を保存します。AIA B2Bインタフェースをコンパイルしてテストし、再デプロイします。

11.3.7 B2Bコネクタ・サービスの注釈付け方法

B2BCSに関する主要メタデータをプロジェクト・ライフサイクル・ワークベンチおよびOracle Enterprise Repositoryで使用できるようにするには、特定の方法でB2BCS実装SOAコンポジットのcomposite.xmlファイルに注釈付けする必要があります。

B2Bコネクタ・サービスに注釈を付ける手順は、次のとおりです。

1. 表11-5に、後で説明するサービス要素composite.xmlに追加する必要がある注釈を示します。

表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のスニペットの例

2. 表11-6に、composite.xmlのAIA B2Bインタフェース・ユーティリティ・サービス注釈要素を示します。

表11-6 composite.xmlのAIA B2Bインタフェース・ユーティリティ・サービス注釈要素

Annotation Element

説明

AIA/Reference/ArtifactType

UtilityServiceの値を入力します

AIA/Reference/ServiceOperation/Name

ProcessB2BDocumentの値を入力します

図11-16に示すように、composite.xmlでは、AIA B2Bインタフェース・ユーティリティ・サービスの参照に注釈を付ける必要があります。

図11-16 composite.xmlのスニペットのAIA B2Bインタフェース・ユーティリティ・サービス注釈要素

3. $AIA_HOME/Infrastructure/B2B/src/B2BConnectors/EDIX12B2BCSApp/X12Update SalesOrder ProvB2BCSImpl/composite.xmlファイルには、参照用にサンプルのプロバイダB2BCS実装の注釈があります。

11.3.8 取引パートナ固有のバリアントのサポート方法

この項には次のトピックが含まれます:

- 取引パートナ固有のカスタム拡張のサポート

- 取引パートナ固有のXSLTのサポート

- 取引パートナ固有のドキュメント・タイプおよびバージョンのサポート

B2B実装では、異なる取引パートナが同じB2Bドキュメントの異なるバージョンまたはマッピング・ガイドラインをサポートする必要が頻繁にあります。特定のB2Bドキュメントを複数の取引パートナに、各取引パートナに対して決定したバージョンおよびマッピング・ガイドラインに基づいて送信する必要がある場合は、ドキュメントのB2BCSを取引パートナ固有の変換ロジックをサポートするように作成できます。次の項で説明するように、これを実現できる方法が複数あります。

11.3.8.1 取引パートナ固有のカスタム拡張のサポート

未変更のままの共通のコア・マッピングに取引パートナ固有のマッピングを追加する場合は、カスタム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

11.3.8.2 取引パートナ固有のXSLTのサポート

取引パートナ固有のマッピングが相互に競合する場合、またはパートナ固有のマッピングを各マッピング・テンプレートの最後ではなく、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ファイル名の取得

11.3.8.3 取引パートナ固有のドキュメント・タイプおよびバージョンのサポート

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で作成する必要があります。これらの変更の管理には確立された管理プロセスが使用可能である必要があります。

11.3.9 エラー処理の有効化方法

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.4 ステップ3: 既存のエンタープライズ・ビジネス・サービスの開発または拡張

図11-29に示すように、次のステップでは、新しいEBSを開発するか、既存のEBSを拡張して、前のステップで開発したプロバイダB2BCSを呼び出します。たとえば、X12UpdateSalesOrderProvB2BCSImplプロセスを呼び出すには、UpdateSalesOrderEBSを開発または変更する必要があります。

図11-29 ステップ3: 既存のエンタープライズ・ビジネス・サービスの開発または拡張

新しいEBSの作成の詳細は、「エンタープライズ・ビジネス・サービスの設計と開発」を参照してください。

11.4.1 取引パートナB2Bプリファレンスに基づいたルーティング方法

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.5 ステップ4: 既存のリクエスタABCSの開発または拡張

この項には次のトピックが含まれます:

- メッセージ交換パターンに関する必要な知識

- 変換に関する必要な知識

図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を開発する場合は、次の情報を検討してください。

11.5.1 メッセージ交換パターンに関する必要な知識

B2B統合フローは主に非同期で処理されます。したがって、新しいリクエスタABCSを開発する際のメッセージ交換パターンの評価時には、B2Bフローで使用される可能性を考慮する必要があります。

11.5.2 変換に関する必要な知識

リクエスタ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.6 ステップ5: Oracle B2Bの構成および取引パートナ・アグリーメントの定義

図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.7 ステップ6: AIAサービスのデプロイと構成

図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.8 ステップ7: テストおよび検証

この項には次のトピックが含まれます:

- CAVSを使用したテスト方法

- ダミー取引パートナのエンドポイントを使用したテスト方法

図11-37に示すように、次のステップでは、B2B統合フローを構成する新規開発またはデプロイされたAIAサービスをテストします。

図11-37 ステップ7: テストおよび検証

取引パートナとのB2B統合フローを稼働する前に、次の一連のテストを完了することをお薦めします。

11.8.1 CAVSを使用したテスト方法

AIAサービスでコンポジット・アプリケーション検証システム(CAVS)が使用可能な場合は、テスト・シミュレータを使用してAIAサービスをテストできます。

CAVSシミュレータを使用すると、実際の取引パートナのかわりにテスト・ハーネスとの間でメッセージを送受信することで、取引パートナの動作をシミュレートできます。このテストは、取引パートナに関する知識なしに実行できます。

図11-38に示すように、このテストの目的は、AIAサービスが適切に開発、デプロイおよび構成されていることを確認することです。

図11-38 CAVSを使用したB2B統合フローのテスト

11.8.2 ダミー取引パートナのエンドポイントを使用したテスト方法

この項には次のトピックが含まれます:

- "Test"に設定された製品コード値を使用したテスト方法

- ダミー・ビジネス・データを使用したテスト方法

図11-39に示すように、テストする別の一般的な方法は、取引パートナ設定でダミーのデリバリ・チャネルを作成することです。たとえば、アウトバウンド・ドキュメントをリモート取引パートナのサーバーに送信する取引パートナ・アグリーメントを構成するかわりに、サーバー上の一時的なB2Bファイルの場所にアウトバウンドB2Bファイルを作成するようにアグリーメントを構成できます。

図11-39 ダミー取引パートナのエンドポイントを使用したB2B統合フローのテスト

この場合は、アウトバウンドB2Bフローをテストすると、フローに含まれるすべてのコンポーネントが呼び出されますが、生成されたB2Bドキュメントは一時ファイル・ディレクトリにコピーされます。完全性と正確性についてB2Bドキュメントをレビューし、取引パートナとレビューを共有することもできます。

- このテストの目的は、AIAサービス、アプリケーションおよびB2B間の統合を検証して、これらのレイヤー全体の構成に一貫性があることを確認することです。

- このテストも、取引パートナに関する知識なしに実行できます。

11.8.2.1 "Test"に設定された製品コード値を使用したテスト方法

特定のB2Bドキュメント・プロトコルでは、B2Bドキュメントをテスト・モードで送信するか本番モードで送信するかの指定に使用できる、プロトコル・エンベロープレベル・フラグがサポートされています。Oracle B2Bの取引パートナ・アグリーメントは、このインディケータをTestモードに設定するように構成できます。

ここでアウトバウンドB2Bフローをトリガーすると、図11-40に示すように、ドキュメントは取引パートナに送信されますが、取引パートナ・システムによってこのインバウンド・ドキュメントはテスト・インスタンスとして認識され、バックエンド・アプリケーションには渡されません。

図11-40 "Test"に設定された製品コード値を使用したB2B統合フローのテスト

このテストの目的は、B2Bサーバーと取引パートナのB2Bサーバー間のハンドシェイクを検証することです。確認、暗号化、パッケージング、パートナ、ドキュメントIDなどのトランスポート機能およびメッセージング機能の設定が検証されます。

この方法では、各取引パートナにこのテスト・メカニズムについて説明して同意を得る必要があります。

11.8.2.2 ダミー・ビジネス・データを使用したテスト方法

最後に、本番システムからリモート取引パートナの本番システムへの統合を、交換するB2Bドキュメントのダミー・ビジネス・データを使用してテストできます。たとえば、アウトバウンドEDI X12 850 B2Bフローによって統合された、自社(バイヤー)のシステムから取引パートナ(ベンダー)のシステムへのエンドツーエンドのアウトバウンド注文書統合をテストするには、取引パートナ用に作成されたEDIテスト品目を使用するか、注文する品目に1セントの価格を使用して注文を実行します。

図11-41に示すように、注文書のリクエストは取引パートナのビジネス・アプリケーションによって正常に受信されて処理されますが、取引パートナのビジネス・ユーザーまたはルールはこの注文書のリクエストを破棄します。

図11-41 ダミー・ビジネス・データを使用したB2B統合フローのテスト

この方法では、各取引パートナにこのテスト・メカニズムについて説明して同意を得る必要もあります。

11.9 ステップ8: 稼働および監視

この項には次のトピックが含まれます:

- Oracle B2Bレポートを使用した監視

- Oracle Enterprise Managerコンソールを使用した監視

- エラー通知を使用した監視

図11-42に示すように、最後のステップでは、取引パートナとともにアウトバウンドB2Bドキュメント・フローを稼働します。AIAおよびOracle B2Bデプロイメントは、製品サーバーに複製してエンド・ユーザーにロールアウトします。

図11-42 ステップ8: 稼働および監視

11.9.1 Oracle B2Bレポートを使用した監視

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ユーザーズ・ガイド』のレポートの作成に関する項を参照してください。

11.9.2 Oracle Enterprise Managerコンソールを使用した監視

Oracle Enterprise Managerコンソールを使用してAIAフローを監視できます。アウトバウンドB2B統合フローを監視するには、Oracle Enterprise Managerコンソールにログインして、B2BフローをトリガーしたリクエスタABCSのインスタンスを参照します。

ABCSインスタンス、ペイロードおよび子プロセスのステータスのすべてをOracle Enterprise Managerコンソールから監視できます。

コンポジットAIAB2BInterface[1.0]などのインスタンスを参照することで、Oracle B2Bに渡された様々なB2Bヘッダー・パラメータを含むJMSペイロードを表示できます。

11.9.3 エラー通知を使用した監視

AIAレイヤーまたはOracle B2Bでの失敗の場合は、AIAエラー・ハンドラがトリガーされます。AIAフォルト・メッセージには、エラー・テキストと説明が含まれます。また、失敗したトランザクションに関係する送信者、受信者、取引パートナ、ドキュメント・タイプなどのB2B情報もAIAフォルトで提供されます。

エラー通知の詳細は、Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイドのエラー通知の使用に関する項を参照してください。

12 インバウンドB2B統合フローの開発と実装の概要

この章では、インバウンドB2B統合フローの開発と実装の概要を示し、B2Bドキュメントの識別方法と要件の分析方法、AIA B2Bインタフェースへのインバウンド・ルーティング・ルールの追加、新しいリクエスタB2Bコネクタ・サービスの開発、既存のエンタープライズ・ビジネス・サービスの開発または拡張、既存のリクエスタABCSの開発または拡張、Oracle B2Bの構成、取引パートナ・アグリーメントの定義、AIAサービスのデプロイと構成、最後にテスト方法および稼働方法について説明します。

この章では、以下のトピックについて説明します。

- インバウンドB2B統合フローの開発と実装の概要

- ステップ1: B2Bドキュメントの識別および要件の分析

- ステップ2: AIA B2Bインタフェースへのインバウンド・ルーティング・ルールの追加

- ステップ3: 新しいリクエスタB2Bコネクタ・サービスの開発

- ステップ4: 既存のエンタープライズ・ビジネス・サービスの開発または拡張

- ステップ5: 既存のプロバイダABCSの開発または拡張

- ステップ6: Oracle B2Bの構成および取引パートナ・アグリーメントの定義

- ステップ7: AIAサービスのデプロイと構成

- ステップ8: テストおよび検証

- ステップ9: 稼働および監視

12.1 インバウンドB2B統合フローの開発と実装の概要

図12-1に、Oracle Application Integration Architecture (AIA)を使用した、アプリケーションから取引パートナへの単純なインバウンド企業間(B2B)フローの開発に含まれる高度なステップを示します。

図12-1 単純なインバウンドB2Bフローの開発と実装の高度なステップ

前述のステップの大部分は、「アウトバウンドB2B統合フローの開発と実装」で説明しています。この章は、適用可能な場合は常に参照されます。

12.2 ステップ1: B2Bドキュメントの識別および要件の分析

図12-2に示すように、インバウンドB2Bフローの作成の最初のステップでは、フローで生成する必要があるB2Bドキュメントを識別します。このステップの一環として、フローをサポートするために作成または拡張する必要があるAIAサービスの要件を分析することも必要です。

図12-2 ステップ1: B2Bドキュメントの識別およびサービス要件の分析

アウトバウンドB2Bドキュメント・フローのこのステップとインバウンドB2Bドキュメント・フローのこのステップは、次の点のみ異なります。

1. マッピングのソースとターゲットが逆です。取引パートナから受信するB2Bドキュメントは、マッピングのソースです。AIAエンタープライズ・ビジネス・メッセージ(EBM)は、マッピングのターゲットです。

2. このステップの終了時には、次のようになります。

a. B2BドキュメントがOracle B2Bに定義されています。

b. B2BドキュメントのXMLスキーマがAIAメタデータ・リポジトリにアップロードされています。

c. 統合で使用されるエンタープライズ・ビジネス・オブジェクト(EBO)およびEBMが識別されています。

d. B2BドキュメントとAIA EBM間の機能マッピングが完了しています。

B2Bドキュメントの識別および要件の分析の詳細は、「ステップ1: B2Bドキュメントの識別および要件の分析」を参照してください。

12.3 ステップ2: AIA B2Bインタフェースへのインバウンド・ルーティング・ルールの追加

図12-3に示すように、インバウンドB2Bフロー作成の次のステップでは、ルーティング・ルールをAIAB2BInterfaceインフラストラクチャ・サービスに追加します。

図12-3 ステップ2: AIA B2Bインタフェースへのインバウンド・ルーティング・ルールの追加

図12-4に示すように、インバウンドB2Bドキュメント・フローでは、AIAB2BInterfaceサービスが、Oracle B2Bで受信する新しいB2Bドキュメントをリスニングして、リクエスタB2Bサービスにルーティングします。

図12-4 新しいB2BドキュメントをリクエスタB2BサービスにルーティングするOracle B2B

AIA B2Bインタフェース・コンポジットには、Oracle B2Bによって処理される新しいインバウンドB2BドキュメントをリスニングするJMSアダプタがあります。Oracle B2Bの取引パートナ・アグリーメントは、インバウンドB2BドキュメントをAIA_B2B_IN_QUEUEのJMSキューにルーティングするように構成されています。

AIA B2Bインタフェースは、インバウンドB2BドキュメントのB2Bドキュメント・タイプを識別して、そのドキュメントをB2Bドキュメントを処理するリクエスタB2Bコネクタ・サービス(B2BCS)実装にルーティングします。

たとえば、B2Bドキュメント・タイプがOAG_Process請求書の場合、AIA B2Bインタフェースは、このドキュメントをOAGProcessInvoiceRequesterB2BCSImplサービスにルーティングします。

リクエスタB2BCS実装への入力は、B2BM要素です。B2BM要素は、AIAComponents/EnterpriseObjectLibrary/Infrastructure/V1/Meta.xsdファイルで定義されます。

ここに示すように、AIA B2Bインタフェースは、Oracle B2Bから受信したB2BドキュメントからB2BM要素を作成します。

- /corecom:B2BM /corecom:B2BMHeader /corecom:B2BMID

- マップ元: B2BドキュメントのJMSヘッダー・プロパティのMSG_ID

- 説明: インバウンドB2Bドキュメント用にOracle B2Bによって生成される一意の識別子。
このフィールドは、AIAフローをOracle B2Bの対応するトランザクションに関連付けます。

- 例: 5602359000000

- /corecom:B2BM /corecom:B2BMHeader /corecom:B2BDocumentType /corecom:TypeCode

- マップ元: DOCTYPE_NAME

- 説明: Oracle B2Bによって識別されるインバウンド・ドキュメントのドキュメント・タイプ。

- 例: OAG_PROCESS_INVOICE

- /corecom:B2BM /corecom:B2BMHeader /corecom:B2BDocumentType /corecom:Version

- マップ元: DOCTYPE_REVISION

- 説明: Oracle B2Bによって識別されるインバウンド・ドキュメントのドキュメント・リビジョン。

- 例: 9.0

- /corecom:B2BM /corecom:B2BMHeader /corecom:SenderTradingPartner /corecom:TradingPartnerID

- マップ元: FROM_PARTY

- 説明: B2Bドキュメントのソース(送信元)取引パートナ。
この値は、Oracle B2Bで定義される取引パートナ名です。

- 例: GlobalChips

- /corecom:B2BM /corecom:B2BMHeader /corecom:ReceiverTradingPartner /corecom:TradingPartnerID

- マップ元: TO_PARTY

- 説明: インバウンドB2Bドキュメントの送信先である宛先(送信先)取引パートナ。
この値は、Oracle B2Bで定義される取引パートナ名です。

- 例: Acme

- /corecom:B2BM /corecom:Payload

- マップ元: JMSペイロード

- 説明: 取引パートナによって送信されたB2Bドキュメントを含む実際のJMSテキスト・ペイロード。

- 例: <?xml version="1.0"?> <PROCESS_INVOICE_002> <CONTROLAREA>…

12.3.1 AIA B2Bインタフェースへの新しいルーティング・ルールの追加方法

新しいルーティング・ルールをAIA B2Bインタフェースに追加する手順は、次のとおりです。

1. Oracle JDeveloperを使用して、$AIA_HOME/Infrastructure/B2B/AIAB2BInterfaceApp/AIAB2BInterfaceApp.jwsアプリケーションを開きます。

2. 図12-5に示すように、Oracle JDeveloperを使用してcomposite.xmlファイルを開きます。

図12-5 Oracle JDeveloperのcomposite.xml

3. 図12-6に示すように、新しいサービス参照を新しいインバウンドB2Bドキュメント・タイプを処理するリクエスタB2BCSに追加します。このマニュアルの次の項では、リクエスタB2BCSの開発方法について説明します。

図12-6 新しいインバウンドB2Bドキュメント・タイプを処理するリクエスタB2BCSへの新しいサービス参照の追加

4. 図12-7に示すように、コンポジットのReceive B2BMメディエータ・コンポーネントから新しく追加したサービスへの接続を追加します。

図12-7 コンポジットのReceive B2BMメディエータ・コンポーネントから新しく追加したサービスへの接続の追加

5. 接続のソースとしてメディエータ操作のReceiveB2BMessageを、ターゲットとしてターゲットのリクエスタB2BCSによって公開される操作を選択します。変更を保存します。

6. 図12-8に示すように、ProcessInbound.mplanファイルを開きます。

図12-8 ProcessInbound.mplan

7. 図12-9に示すように、composite.xmlファイルに追加したサービス参照を使用して、リクエスタB2BCSを呼び出す新しいルーティング・ルールを追加します。

図12-9 リクエスタB2BCSを呼び出す新しいルーティング・ルール

8. 新しいルーティング・ルールをReceiveB2BMessage操作に追加します。

9. 新しく追加したルーティング・ルールのフィルタ操作を編集します。B2Bドキュメント・タイプに基づいてフィルタを定義します。たとえば、図12-10のルーティング・フィルタでは、EDI X12 Process受注ドキュメントがX12 ProcessSalesOrderのB2BCS実装にルーティングされます。

図12-10 EDI X12 Process受注ドキュメントをProcessSalesOrderのB2BCS実装にルーティングするルーティング・フィルタ

10. 変更を保存します。

11. 変更したSOAコンポジット・アプリケーションをデプロイします。

12.4 ステップ3: 新しいリクエスタB2Bコネクタ・サービスの開発

この項には次のトピックが含まれます:

- リクエスタB2Bコネクタ・サービスの概要

- メッセージ交換パターンの識別方法

- B2BCSサービス・コントラクトの開発方法

- Oracle Metadata Services RepositoryへのWSDLの格納方法

- B2Bコネクタ・サービスの開発方法

- B2Bコネクタ・サービスの注釈付け方法

- 取引パートナ固有のバリアントのサポート方法

- エラー処理の有効化方法

図12-11に示すように、次のステップでは、アウトバウンドB2B統合フローをサポートするリクエスタB2BCSを開発します。

図12-11 ステップ3: 新しいリクエスタB2Bコネクタ・サービスの開発

リクエスタB2BCSは、リクエスタ・アプリケーション・ビジネス・コネクタ・サービス(ABCS)と類似していますが、アプリケーションと統合するかわりにOracle B2Bを使用して取引パートナと統合する点のみが異なります。したがって、ABCS (リクエスタおよびプロバイダ)の設計と開発をよく理解することをお薦めします。

ABCSの開発の詳細は、「ABCSの作成」を参照してください。

12.4.1 リクエスタB2Bコネクタ・サービスの概要

リクエスタB2BCSによって提供される主要な機能は、次のタスクを実行することでインバウンドB2Bドキュメント統合を可能にすることです。

- Oracle B2Bから取引パートナが送信したB2Bドキュメントを受信します。

- B2BドキュメントをAIA EBMに変換します。

- リクエスト・ペイロードとしてEBMを使用して、AIAのエンタープライズ・ビジネス・サービス(EBS)を呼び出します。

図12-12に、単純なファイア・アンド・フォーゲットのメッセージ交換パターンベースのプロバイダB2BCSで実行される処理を示します。

図12-12 単純なファイア・アンド・フォーゲットのメッセージ交換パターンベースのプロバイダB2BCSのプロセス・フロー

次の各項では、B2BCSの開発手順について説明します。

12.4.2 メッセージ交換パターンの識別方法

アウトバウンドB2Bフローと同様に、ほとんどのインバウンドB2Bフローは、ファイア・アンド・フォーゲットのメッセージ交換パターンを使用してモデル化できます。

取引パートナに送信するレスポンスは、個々のアウトバウンド・ファイア・アンド・フォーゲット・フローを使用してモデル化できます。

また、Oracle B2Bでは、関連するプロトコルに基づいて確認または確認メッセージを取引パートナに自動的に送信するように構成できます。

詳細は、「メッセージ交換パターンの識別方法」を参照してください。

メッセージ交換パターンの識別の詳細は、「MEPの識別」を参照してください。

12.4.3 B2BCSサービス・コントラクトの開発方法

最初に、リクエスタB2BCSのサービス・コントラクト(WSDL)を定義します。プロバイダB2BCSのサービス・コントラクトでは、AIAフローによる呼出し方法を指定します。サービス・コントラクトでは、実装するB2B操作および入力リクエスト・メッセージとして処理できるB2Bドキュメント・タイプを指定します。

ABCSに対するWSDLの作成方法の詳細は、「ABCSコントラクトの定義」を参照してください。

次に、B2BCSのWSDL定義での使用に対して推奨される命名規則を示します。

- WSDLファイル名:

- ネーミング・ガイドライン: <B2B標準><動詞><EBO>ReqB2BCSImpl.wsdl

- 例: X12ProcessSalesOrderReqB2BCSImpl.wsdl

- サービス・ネームスペース:

- http://xmlns.oracle.com/B2BCSImpl/{Core|Industry/<業種名> }/<B2B標準><動詞><EBO>ReqB2BCSImpl/<ABCSバージョン>

- 例: http://xmlns.oracle.com/B2BCSImpl/Core/X12ProcessSalesOrderProvB2BCSImpl/V1
ABCSサービス・バージョンは、B2Bのドキュメント/標準バージョンとは無関係です。

AIAサービスのバージョニングに対する推奨の詳細は、「ABCSのバージョニング」を参照してください。

- サービス名:

- ネーミング・ガイドライン: <B2B標準><動詞><EBO>ReqB2BCSImpl

- 例: X12ProcessSalesOrderProvB2BCSImpl

- ポート・タイプ名:

- ネーミング・ガイドライン: <B2B標準><動詞><EBO> ReqB2BCSImplService

- 例: X12ProcessSalesOrderProvB2BCSImplService

- 操作名:

- <動詞><EBO>

- ProcessSalesOrder

- リクエスト・メッセージ名:

- <動詞><EBO>ReqMsg

- ProcessSalesOrderReqMsg

12.4.4 Oracle Metadata Services Repositoryへの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_STANDARD> <動詞> <オブジェクト> ReqB2BCSImpl.wsdlの場所に格納します。

WSDLをMDSに格納する手順は、次のとおりです。

1. 作成したWSDLを次の場所にコピーします。$AIA_HOME/aia_instances/$INSTANCE_
NAME/AIAMetaData/AIAComponents/B2BServiceLibrary

/Connectors/wsdls/<B2B_STANDARD>/RequesterB2BCS

/<バージョン>/<wsdlファイル>.wsdl

2. $AIA_HOME/aia_instances/$INSTANCE_NAME/config/に存在するUpdateMetaDataDP.xmlファイルを実行します。

3. MDSへのSOA-MDSサーバー接続を使用して、図12-13に示すように、AIAメタデータが表示されていることを確認します。

図12-13 MDSのAIAメタデータ

4. これで、/apps/AIAMetaData/AIAComponents/B2BServiceLibrary/ Connectors/wsdls/EDI_X12/RequesterB2BCS/V1/ X12ProcessSalesOrderProvB2BCSImpl.wsdlのようなURLを使用して、WSDLにアクセスできます。

12.4.5 B2Bコネクタ・サービスの開発方法

このプロセスの次のステップでは、B2BCSを開発します。前のステップで作成したリクエスタB2BCSのWSDLは、具象B2BCSの開発時にインタフェースとして使用します。

B2BCSの開発には、Oracle JDeveloperを使用します。前のステップで作成した抽象WSDLに基づいて、BPELプロセスを含むコンポジットを開発します。

次に、B2BCS実装のBPELで開発する必要がある主要アクティビティを示します。

B2Bコネクタ・サービスを開発する手順は、次のとおりです。

1. BPELコンポーネントを含むSOAプロジェクトが格納されたSOAコンポジット・アプリケーションを作成します。

2. 前のステップで作成したWSDLをSOAコンポジットのインタフェースとして選択します。

3. 表12-1に、SOAアプリケーションとプロジェクトの作成に使用する値を示します。

表12-1 SOAアプリケーションとプロジェクトの作成に使用する値

アクティビティ

値

アプリケーション名

<B2B標準> <動詞> <EBO> ReqB2BCSApp

プロジェクト名

<B2B標準> <動詞> <EBO> ReqB2BCSImpl

プロジェクト・ネームスペース

http://xmlns.oracle.com/B2BCSImpl/Core/ <標準> <動詞> <オブジェクト> ReqB2BCSImpl/V1

(B2BCSのWSDLのネームスペースと同じ)

コンポジット名

<B2B標準> <動詞> <EBO> ReqB2BCSImpl

コンポジット・テンプレート

BPELを含むコンポジット

BPELプロセス名

<B2B標準> <動詞> <EBO> ReqB2BCSImpl

ネームスペース

http://xmlns.oracle.com/B2BCSImpl/Core/ <標準> <動詞> <オブジェクト> ReqB2BCSImpl/V1

(B2BCSのWSDLのネームスペースと同じ)

テンプレート

WSDLに基づく

WSDL URL

MDSから参照されるB2BCSサービスのWSDLのURL

4. 変数<B2BM>_Varを定義します。
これは、BPELプロセスへの入力変数で、receiveアクティビティで使用されます。

Meta.xsdで定義したcorecom:B2BMグローバル要素に基づいて変数を定義します。

5. corecom:EBMHeaderタイプの変数EBM_HEADERを定義します。
この変数は、AIAプロセス・コンテキスト情報の格納に使用されたり、フォルト処理メカニズムで使用されます。

Meta.xsdで定義したcorecom:B2BMグローバル要素に基づいて変数を定義します。

6. corecom:B2BMHeaderタイプの変数B2BM_HEADERを定義します。
この変数は、B2B固有のAIAプロセス・コンテキスト情報の格納に使用されたり、フォルト処理メカニズムで使用されます。

Meta.xsdで定義したcorecom:B2BMHeaderグローバル要素に基づいて変数を定義します。

7. 外部のB2BDocument定義を使用して、変数 <B2BDoc>_Varを定義します。
これは、EBMからの変換のソースとして使用されます。次に、この値は<B2BDoc>B2BM_Var/Payloadに割り当てられます。

8. EBSに対するパートナ・リンクを定義します。
これは、リクエスタB2BCSによって呼び出されるAIA EBSです。

抽象EBSのWSDLは、/apps/AIAMetaData/AIAComponents/EnterpriseBusinessServiceLibrary/Core/<EBO>/V<x>/<EBO名>.wsdlから参照できます。

9. EBMをB2Bドキュメントに変換します。
transformアクティビティを使用して、EBMをB2Bドキュメント形式に変換します。前のステップで作成したマッピングごとに開発されたXSLTを呼び出します。

10. ここに示すように、B2B固有のEBMHeader変数を割り当てます。

- 要素: corecom:EBMHeader/corecom:B2BProfile/corecom:SenderTradingPartner/corecom:TradingPartnerID
ソースのB2BM XPATH: corecom:B2BM/corecom:B2BMHeader/corecom:SenderTradingPartner/corecom:TradingPartnerID

- 要素: corecom:EBMHeader/corecom:B2BProfile/corecom:ReceiverTradingPartner/corecom:TradingPartnerID
ソースのB2BM XPATH: corecom:B2BM/corecom:B2BMHeader/corecom:ReceiverTradingPartner/corecom:TradingPartnerID

このように、Oracle B2Bによって識別された送信者および受信者の取引パートナ情報は、EBMに渡されます。

11. EBSを呼び出します。
AIA EBSを呼び出してEBMを処理します。

12. BPELプロセスをコンパイルして、エラーが発生していないことを確認します。Oracle JDeveloperを使用すると、BPELプロセスをSOAコア拡張機能がインストールされている開発サーバーにデプロイできます。

12.4.6 B2Bコネクタ・サービスの注釈付け方法

B2BCSに関する主要メタデータをプロジェクト・ライフサイクル・ワークベンチおよびOracle Enterprise Repositoryで使用できるようにするには、特定の方法でB2BCS実装SOAコンポジットのcomposite.xmlファイルに注釈付けする必要があります。

リクエスタB2Bコネクタ・サービスに注釈付けする手順は、次のとおりです。

1. 表12-2に、後で説明するサービス要素composite.xmlに追加する必要がある注釈を示します。

表12-2 composite.xmlのサービス注釈要素

Annotation Element

説明

例

AIA/Service/InterfaceDetails/Service Operation

<動詞><EBO名>

ProcessSalesOrder

AIA/Service/ImplementationDetails/ArtifactType

RequesterB2BCSImplementation

RequesterB2BCSImplementation

AIA/Service/ImplementationDetails/ServiceOperation/Name

<動詞><EBO名>

ProcessSalesOrder

AIA/Service/ImplementationDetails/B2BDocument

このB2BCSで処理されるB2Bドキュメント・タイプ

850

AIA/Service/ImplementationDetails/B2BDocumentVersion

このB2BCSで処理されるB2Bドキュメント・バージョン

4010

AIA/Service/ImplementationDetails/B2BStandard

このB2BCSで処理されるB2B標準

X12

AIA/Service/ImplementationDetails/B2BStandardVersion

このB2BCSで処理されるB2B標準バージョン

4010

図12-14に示したXMLスニペットは、X12ProcessSalesOrderReqB2BCSImpl composite.xmlと呼ばれる注釈が付いたB2BCSの例です。

図12-14 X12ProcessSalesOrderReqB2BCSImpl composite.xmlと呼ばれる注釈が付いたB2BCSのスニペットの例

2. composite.xmlでは、このB2BCSによって呼び出されるAIA EBSへの参照にも注釈が付けられる必要があります。表12-3に、注釈要素を示します。

表12-3 B2BCSによって呼び出されるAIA EBSの参照に使用されるcomposite.xmlの注釈

Annotation Element

説明

例

AIA/Reference/ArtifactType

EnterpriseBusinessServiceという値を入力します

EnterpriseBusinessService

AIA/Reference/ServiceOperation/Name

EBS操作名

ProcessSalesOrder

図12-15に、composite.xmlに表示された注釈を示します。

図12-15 composite.xmlで注釈が付けられたB2BCSによって呼び出されるAIA EBSへの参照

$AIA_HOME/Infrastructure/B2B/src/B2BConnectors/EDIX12B2BCSApp/X12Process SalesOrder ReqB2BCSImpl/composite.xmlファイルには、参照用にサンプルのリクエスタB2BCS実装の注釈が格納されています。

12.4.7 取引パートナ固有のバリアントのサポート方法

取引パートナ固有の処理に対するサポートは、プロバイダB2BCSに作成した方法と同様の方法でリクエスタB2BCSに作成できます。

B2BCSにおける取引パートナ固有のサポートの作成方法の詳細は、「取引パートナ固有のバリアントのサポート方法」を参照してください。

12.4.8 エラー処理の有効化方法

AIAサービスでエラー処理およびリカバリを有効化する方法の詳細は、Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイドのエラー処理の設定に関する項を参照してください。

簡潔に示すと、次の手順を実行する必要があります。

- fault-policy.xmlをB2BCSコンポジットに関連付けます。

- 図12-16および図12-17に示すように、ビジネス・フォルトに対してAIAAsyncErrorHandlingBPELProcessを呼び出します。

図12-16 AIAAsyncErrorHandlingBPELProcessを呼び出すように定義されたB2BCSコンポジット

図12-17 AIAAsyncEHServiceの呼出し

表12-4に示すように、AIAAsyncErrorHandlingBPELProcessを呼び出す際に、フォルト・スキーマのB2B固有の要素を入力できます。

表12-4 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

B2BMからマップされる送信側取引パートナ

MyCompany

Fault/B2BMReference/ReceiverTradingPartner/TradingPartnerID

B2BMからマップされる受信側取引パートナ

Global

図12-18に、corecom:FaultのB2B固有要素を示します。

図12-18 corecom:FaultでのB2B固有の要素

フォルト・インスタンスで使用可能で、失敗したAIAサービスのB2B詳細は、ログに記録されて失敗フローのデバッグで使用できます。

12.5 ステップ4: 既存のエンタープライズ・ビジネス・サービスの開発または拡張

図12-19に示すように、次のステップでは、リクエスタB2BCSによって呼び出される新規EBSを開発するか、またはこの呼出しに対して既存のEBSを使用します。

図12-19 ステップ4: 既存のエンタープライズ・ビジネス・サービスの開発または拡張

新しいEBSの作成の詳細は、「エンタープライズ・ビジネス・サービスの設計と開発」を参照してください。

12.6 ステップ5: 既存のプロバイダABCSの開発または拡張

図12-20に示すように、次のステップでは、新規のプロバイダABCSを開発するか、または既存のプロバイダABCSを拡張します。プロバイダABCSは、アプリケーションのAPIまたはWebサービスを呼び出すことでAIA EBMを処理します。

図12-20 ステップ5: 既存のプロバイダABCSの開発または拡張

プロバイダABCSの設計方法と作成方法の詳細は、「アプリケーション・ビジネス・コネクタ・サービスの設計」および「ABCSの作成」を参照してください。

12.6.1 変換に関する必要な知識

表12-5に示すように、EBMからABMへのこの変換の開発中に、B2Bメッセージのソースおよびターゲットを取得するために、送信側および受信側取引パートナ情報をABMの適切なフィールドにマップできます。

表12-5 EBMの送信側および受信側取引パートナ・フィールド

EBMヘッダー要素

説明

値の例

/EBMHeader/B2BProfile/SenderTradingPartner/TradingPartnerID

Oracle B2Bに定義されている送信側取引パートナのID。インバウンド・フローの場合、これはリモート取引パートナです。

GlobalChips

/EBMHeader/B2BProfile/ReceiverTradingPartner/TradingPartnerID

Oracle B2Bに定義されている受信側取引パートナのID。インバウンド・フローの場合、これはホスト取引パートナです。

Acme

このステップを終了すると、アウトバウンドB2B統合フローの開発に必要なAIAサービスのすべての準備が整います。

12.7 ステップ6: Oracle B2Bの構成および取引パートナ・アグリーメントの定義

図12-21に示すように、次のステップでは、Oracle B2Bで取引パートナ・アグリーメントを作成します。

図12-21 ステップ6: Oracle B2Bの構成および取引パートナ・アグリーメントの定義

取引パートナを定義してB2B機能と関連付ける方法の詳細は、『Oracle B2Bユーザーズ・ガイド』の取引パートナの構成に関する項を参照してください。

また、EDIベースのアウトバウンドB2Bフローの場合は、アウトバウンド・ドキュメントをバッチ処理するようにOracle B2Bを構成できます。バッチ・サイズやタイムアウトなどのパラメータは、AIAレイヤーを変更せずにOracle B2Bで構成できます。

12.8 ステップ7: AIAサービスのデプロイと構成

図12-22に示すように、次のステップでは、AIAサービスをデプロイします。Oracle JDeveloperを使用すると、サービスをターゲットのOracle SOAサーバーにデプロイできます。

図12-22 ステップ7: AIAサービスのデプロイと構成

アウトバウンド統合に必要なAIAサービスでドメイン値マッピング(DVM)および構成ファイルを使用する場合は、B2B構成に対応するデータを入力する必要があります。

プロジェクト・ライフサイクル・ワークベンチ・アプリケーションを使用してAIAプロジェクト用の部品構成表のXMLファイルを作成し、そのファイルを使用してデプロイメント計画を自動生成することもできます。このデプロイメント計画を使用すると、統合プロジェクトを構成するAIAサービスとリソースを複数の開発環境、テスト環境および本番環境にデプロイできます。

部品構成表の生成の詳細は、「直接統合の実装」を参照してください。

デプロイメント計画の生成の詳細は、「直接統合の実装」を参照してください。

また、AIAエラー処理フレームワークを構成して、AIAフローのエラーを通知する適切なロールを設定します。

エラー処理の詳細は、Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイドのエラー処理の設定に関する項を参照してください。

12.9 ステップ8: テストおよび検証

図12-23に示すように、次のステップでは、テストおよび検証を実行します。取引パートナとのB2B統合フローを稼働する前に、B2B統合フローを構成する、新規に開発したか、またはデプロイしたAIAサービスに対して一連のテストを完了することをお薦めします。

図12-23 ステップ8: テストおよび検証

詳細は、「ステップ7: テストおよび検証」を参照してください。

12.10 ステップ9: 稼働および監視

図12-24に示すように、最後のステップでは、取引パートナとともにアウトバウンドB2Bドキュメント・フローを稼働します。AIAおよびOracle B2Bデプロイメントは、製品サーバーに複製してエンド・ユーザーにロールアウトします。

図12-24 ステップ9: 稼働および監視

詳細は、「ステップ8: 稼働および監視」を参照してください。

13 イベント集約プログラミング・モデルの説明

この章では、イベント集約プログラミング・モデルの概要を示し、その実装方法を説明します。

この章の内容は次のとおりです。

- 概要

- イベント集約プログラミング・モデルの実装

13.1 概要

イベント集約プログラミング・モデルによって、イベント、エンティティおよびメッセージの集約が必要なビジネス・ユースケースに対して包括的な方法が提供されます。

たとえば、イベント集約が必要になるのは、ビジネス・メッセージの完了前に複数のイベントが発生し、未完了のメッセージごとに1つのイベントがトリガーされて統合レイヤーに1つのビジネス・イベントが発生する場合です。

イベント集約プログラミング・モデルは、不連続な間隔で生成された粒度が細かいメッセージ(イベント)から粒度の粗いメッセージ(イベント)を作成するのに役立ちます。一定の間隔で生成されたメッセージは、不完全または重複である場合があります。

イベント集約プログラミング・モデルは、関係および時間ベースの集約で使用できます。

イベント集約プログラミング・モデルは、次の機能を提供します。

- エンティティの同期化による、エンティティの単一で全体的なビューの提供。

- 粒度の細かい複数のイベントを、粒度の粗い単一のイベントに統一。

- 同一イベントの重複のマージ。

- パフォーマンスの向上。

通常、粒度の細かいアプリケーションのパラレル・シミュレーションを行うと、多数のメッセージが生成されます。ネットワークを介してこれらのメッセージを送信するオーバーヘッドによって、パラレル・シミュレーションのスピードはかなり低下します。この場合は、イベント集約によってアプリケーションの粒度が上がり、通信のオーバーヘッドを削減できます。

図13-1に、ビジネス統合シナリオでイベント集約を実現する方法を示します。「顧客の作成」は粒度の粗いイベントで、イベント・プロデューサによって作成される「連絡先の作成」、「アカウントの作成」および「住所の作成」は粒度の細かいイベントです。イベント・アグリゲータ・サービスを使用すると、これらをすべてを統合して、粒度の粗い単一のイベントを発生できます。

図13-1 粒度の細かい複数のイベントから粒度の粗い単一のイベントを発生するイベント集約サービス

13.1.1 イベント・プロデューサ

イベント・プロデューサは、集約対象のメッセージを作成します。作成されたメッセージは、不完全で、他のメッセージに関連したり依存している可能性があります。

イベント・プロデューサの例として、新規のアカウント・オブジェクトが作成され、関連するイベントをトリガーするSiebel CRMシステムがあります。このアカウント・エンティティには子オブジェクトとして連絡先エンティティがあり、アカウント・エンティティとともに作成されるときに粒度の細かい別のイベントを発生できます。

13.1.2 イベント・アグリゲータ・サービス

イベント・アグリゲータ・サービスは、粒度の細かい複数のイベントを統合して、粒度の粗い単一のイベントを発生します。JavaまたはPL/SQLを使用して、担当者、アカウントおよび住所イベント間の関係を実装します。

イベント・アグリゲータ・サービスは、2つの部分に分けられます。

最初の部分は、実際のプログラミング・ロジックを実装して、エンティティ間の集約および関係を保持します。

2番目の部分は、外部クライアントからこのプログラミング・ロジックを呼び出すサービス・ラッパーです。プログラミング・ロジックがPL/SQLを使用して開発されている場合、これらのデータベース・オブジェクトはデータベース・アダプタ・インタフェースを使用して公開できます。プログラミング・ロジックがJavaで開発されている場合、JavaオブジェクトはWebサービス呼出しフレームワーク(WSIF)インタフェースを使用して公開できます。

イベント・アグリゲータ・サービスのフロントエンドとして機能するには、BPELの使用をお薦めします。JavaまたはPL/SQLオブジェクトが呼び出されて、様々な理由で失敗した場合は、イベント・プロデューサに通知して処理する必要があります。BPELは、このシナリオに対して適切なフォルトおよび例外処理機能を備えています。

エンティティ間の関係を保持するプログラミング・ロジックを実装するには、Javaの使用をお薦めします。これは、拡張、モジュール性および例外処理にJavaが適しているためです。

13.1.3 サービスの消費

実際のイベント集約はデータベース内で発生します。これは時間ベースの集約で、コンシューマ・サービスがスレッドを生成して、データベース・アダプタを使用して表オブジェクトをポーリングし、その表にプッシュされたメッセージを検索することを意味します。ポーリングは、構成可能な時間間隔に基づいて発生します。コンシューマ・サービスは、特定の時間間隔内のメッセージをすべてフェッチして、リクエスタ・アプリケーション・ビジネス・コネクタ(ABC)サービスに渡します。

メッセージがデータベースからフェッチされると、コンシューマ・サービスはメッセージを削除します。

13.2 イベント集約プログラミング・モデルの実装

イベント集約プログラミング・モデルの実装には、イベント集約サービスとコンシューマ・サービスの作成、およびエラー処理の実装が含まれます。

この方法を使用すると、単一の自己参照表およびストアド・プロシージャを使用して、集約がデータベース・レイヤーで発生します。自己参照集計表構造では、エンティティ間の複数レベルの関係がサポートされています。

ストアド・プロシージャは、該当するイベントの生成時に集約表を入力するのに役立ちます。また、これは、最初のレベルのオブジェクトについて重複レコードを削減するのに役立ちます。ストアド・プロシージャでは、集約表内のレコードを更新する前に、オプティミスティック・ロックを取得します。

ユースケース: Siebel CRMを使用するCustomer Master Data Management

この実装は、このユースケースに基づいて説明します。

Oracle Customer Master Data Management (MDM)の顧客プロセス統合フローで、Siebel CRMアプリケーションは、ビジネス・レイヤー・レベルで定義されたトリガーを作成および更新します。更新または作成アクションによって、統合に対して複数のイベントが発生する可能性があります。したがって、粒度の細かい各イベントを個別に処理するのではなく、これらのイベントを集約してバッチ処理します。

これらのイベントは、アカウント、担当者および住所の各ビジネス・エンティティで発生できます。

アカウント、担当者および住所エンティティ間の関係は、集約を使用して保持する必要があります。

- アカウントには、1つ以上の担当者と住所を添付できます。

- 担当者には、1つ以上の住所を添付できます。

- 担当者と住所は、複数のアカウント間で共有できます。

13.2.1 イベント集約サービスの作成

この項では、イベント集約サービスの作成(次の方法を含む)について説明します。

- PL/SQLオブジェクトを作成します。

- データベース・サービスと集約サービスを作成します。

13.2.1.1 PL/SQLオブジェクトの作成

PL/SQLオブジェクトを作成する手順は、次のとおりです。

1. 図13-2に示すように、データベースに表オブジェクトAIA_AGGREGATED_ENTITIESを作成します。

図13-2 表オブジェクトの作成例

2. 図13-3に示すように、ステップ1で作成した表オブジェクトの担当者、アカウントおよび住所間の関係を保持するためのプログラミング・ロジックが含まれる、ストアド・プロシージャ・オブジェクトAIA_AGGREGATOR_PUBを作成します。

図13-3 ストアド・プロシージャ・オブジェクトの作成例

13.2.1.2 データベース・サービスと集約サービスの作成

データベース・サービスと集約サービスを作成する手順は、次のとおりです。

1. 図13-4に示すように、前の手順で作成したデータベース・サービスを呼び出すBPELプロジェクトを作成します。

図13-4 データベース・サービスを呼び出すBPELプロジェクト

データベースが使用不可、ストアド・プロシージャの失敗、サービス・レベルでのその他のエラーの場合に備えて、このサービスはエラー処理を実装してクライアント・サービスに速やかに通知する必要があります。

詳細は、「イベント集約プログラミング・モデル用のエラー処理の実装」を参照してください。

外部クライアントは、イベント集約のためにこのBPELサービスを呼び出します。

外部クライアント(Siebel CRMなど)がメッセージを永続キューにポストし、イベント・アグリゲータ・サービスがそのキューからメッセージを取得してイベント集約することをお薦めします。この推奨方法の実装が不可能な場合は、イベント・アグリゲータ・サービスを外部クライアントから直接呼び出すことができます。

13.2.2 コンシューマ・サービスの作成

コンシューマ・サービスを作成する手順は、次のとおりです。

1. メディエータ・コンポジットを使用するコンシューマ・サービスを作成します。

データ・エンリッチメントの実行が必要でないかぎり、メディエータを使用するコンシューマ・サービスを実装することをお薦めします。データベース・アダプタ機能を使用して、正常に処理された時点でレコードをデータベースからパージします。図13-5に、メディエータ・コンポジットを使用するコンシューマ・サービスの実装方法を示します。

図13-5 メディエータ・コンポジットを使用するコンシューマ・サービス

2. コンシューマ・サービスをポーリングする時間間隔を構成します。

実際の集約は、コンシューマ・サービスに設定されたこの時間間隔に基づいて発生します。コンシューマ・サービスは特定の時間間隔内のメッセージをフェッチし、間隔内のすべてのレコードがバッチとして処理されます。図13-6に、コンシューマ・サービスをポーリングする時間間隔の構成方法を示します。

図13-6 コンシューマ・サービスをポーリングする時間間隔の構成

ポーリング間隔およびその他の構成可能プロパティの構成方法については、テクノロジ・アダプタの理解のPollingInterval、MaxTransactionSizeおよびActivationInstancesの構成に関する項を参照してください。

13.2.3 イベント集約プログラミング・モデル用のエラー処理の実装

イベント集約プログラミング・モデルのエラー処理は、Oracle Application Integration Architecture (AIA)のエラー処理の推奨事項に準拠する必要があります。

エラー処理フレームワークの詳細は、Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイドのエラー処理の設定に関する項を参照してください。

リソースが利用不可またはアプリケーション・エラーのためにイベント・アグリゲータ・サービスでエラーが発生した場合は、エラーがイベント・アグリゲータ・サービス・レイヤーで処理され、プロデューサ・サービスに伝播される必要があります。イベント・プロデューサによって生成されたイベントが集約に参加できない場合は、イベント・プロデューサに通知される必要があります。

イベント・アグリゲータ・サービス・レイヤーの実装には、BPELの使用をお薦めします。BPELを使用すると、ユーザーはエラー処理をより制御しやすくなります。このレイヤーが実装されるプログラミング言語に関係なく、アプリケーション例外を処理できる必要があります。

イベント・アグリゲータ・サービスがPL/SQLで実装される場合は、OUTパラメータをプロビジョニングしてイベント・プロデューサに伝播する必要があります。SUCCESSまたはFAILUREのいずれかのメッセージで構成されるリプライをプロデューサ・サービスに返すのと同様に、例外処理のために単純に適切なOUT変数を定義できます。

イベント・アグリゲータ・サービスがJavaで実装される場合は、WSIFインタフェースを使用して例外をプロビジョニングして伝播する必要があります。WSIFインタフェースで使用される適切な例外オブジェクトを定義します。

14 リソース接続の確立

この章では、Oracle Application Integration Architecture (AIA)サービスが外部ソースと相互作用する方法、およびインバウンド接続とアウトバウンド接続について説明します。最後の項では、SiebelアプリケーションおよびOracle E-Business Suiteに固有の接続の確立に関するガイドラインを説明します。

この章の内容は次のとおりです。

- リソース接続の概要

- 接続のモード

- Siebelアプリケーション固有の接続ガイドライン

- Oracle E-Business Suiteアプリケーション固有の接続ガイドライン

- 設計のガイドライン

14.1 リソース接続の概要

参加アプリケーションがビジネス・プロセスを実行します。これは、ビジネス・プロセスのイニシエータであるか、またはビジネス・プロセスの1つ以上のステップで役割を果たします。AIAレイヤーの観点から見ると、参加アプリケーションとビジネス・プロセスとの相互作用は、アウトバウンドまたはインバウンドのいずれかになります。

ビジネス・プロセスは、様々な参加アプリケーションとのアウトバウンドとインバウンド相互作用の組合せです。

14.1.1 インバウンド接続

図14-1に示すように、インバウンドとはAIAレイヤーへのインバウンドを意味します。

図14-1に、参加アプリケーションがビジネス・プロセスとインバウンド相互作用する方法を示します。CRMアプリケーション内のモジュールを取得するために「発行」ボタンをクリックすると、注文履行ビジネス・プロセスが開始されます。

- AIAサービスによって公開されたサービスは、アプリケーションで作成されたプロキシによって呼び出されます。AIAとのインバウンド相互作用は、参加アプリケーションによるイベントの通知やブロードキャストのため、または外部ソースから情報を取得するために発生します。たとえば、CRMモジュールで勘定残高の取得ボタンをクリックすると、SOAPメッセージがHTTP経由で送信されてAIAサービスが呼び出されます。

- アプリケーションは、メッセージをJMSキューとトピックにプッシュします。JMSサーバーは登録済のJMSアダプタ・エージェントをトリガーし、JMSアダプタ・エージェントはAIAサービスをトリガーします。たとえば、CRMモジュール内での顧客の作成や注文の発行によって、AIAへのこれらのイベントのブロードキャストが、JMSキューおよびトピックへのメッセージの形式でトリガーされます。

図14-1 インバウンド接続の例

14.1.2 アウトバウンド接続

図14-2に示すように、アウトバウンドとはAIAレイヤーからのアウトバウンドを意味します。

- AIAサービスは、アプリケーションによって公開されたサービスを呼び出します。AIAサービスはアプリケーション・サービスまたは外部サービスを呼び出して、追加情報の取得、ビジネス・イベントの送信、またはタスクの実行のリクエストを行うことができます。たとえば、CRMモジュールで注文を作成したり、既存の顧客の注文をCRMモジュールで発行するときに請求アプリケーションで顧客を作成しますが、その顧客のプロファイルを請求アプリケーションで使用できないとします。ほとんどの製造システムは、品目が追加されるとイベントを公開しますが、このイベントには品目に関する最小限の情報しか含まれていません。イベントを使用するAIAサービスは、アプリケーション・サービスを呼び出して、その品目に関する完全な情報を取得する必要があります。

- AIAサービスは、JCAアダプタを使用してアプリケーションと相互作用し、メッセージをJMSキュー/トピックにプッシュします。JMSサーバーは、アプリケーションによって登録されたJMSアダプタ・エージェントをトリガーします。

図14-2に、ビジネス・プロセスがアウトバウンド相互作用する方法を示します。このビジネス・プロセス内のステップによってCRM注文獲得アプリケーションが呼び出され、注文ステータスの更新が送信されます。

図14-2 アウトバウンド接続の例

14.2 接続のモード

参加アプリケーションは、インバウンドおよびアウトバウンドの相互作用で様々なタイプのメカニズムを使用します。

次の各項では、参加アプリケーションがAIAアーキテクチャと相互作用するためのガイドラインと推奨事項を示します。

この項には次のトピックが含まれます:

- SOAP/HTTPを使用したWebサービス

- SOAP/HTTPを使用したWebサービスを使用する場合

- SOAP/HTTPを使用したWebサービスのセッション管理

- SOAP/HTTPを使用したWebサービスのエラー処理

- SOAP/HTTPを使用したWebサービスのセキュリティ

- キューまたはトピックを使用したメッセージの伝播

- 保証付きメッセージ配信の確保

- JCAアダプタを使用する場合

注意:

この項の内容は、一般的なガイドラインと推奨事項のみです。AIAサービスのプログラミング方法は参加アプリケーションの機能によって異なり、参加アプリケーションによってはこの項で説明する機能を備えていない場合があります。提供されている機能については、該当するアプリケーション固有のガイドを参照してください。

14.2.1 SOAP/HTTPを使用したWebサービス

インバウンド相互作用の場合、参加アプリケーションは、AIAがWebサービスとして提供するアプリケーション・ビジネス・コネクタ・サービス(ABCS)を呼び出します。参加アプリケーションは、ABCS WSDLを使用してABCS Webサービスを呼び出します。ABCS WSDLは、スタブまたはプロキシを作成するために参加アプリケーションで使用されます。これらは参加アプリケーション内で呼び出され、ABCSの呼出しへと続きます。

図14-3に示すように、外部システムに存在する情報をフェッチする場合のみ、参加アプリケーションがWebサービス・トランスポートを利用してAIAサービスを呼び出すことをお薦めします。たとえば、CSRまたはセルフサービス・アプリケーション画面で、CRMアプリケーションを使用して請求アプリケーションから顧客の勘定残高詳細を問い合せます。

図14-3 SOAP/HTTPを使用したWebサービスの使用

その他のタイプの相互作用(顧客の作成、注文の発行など)では、相互作用が確実に信頼できてトランザクションであるために、JCAまたはJMSトランスポートのいずれかを使用することをお薦めします。参加アプリケーションにJMSまたはJCAトランスポートのいずれかを使用してイベントをAIAレイヤーに公開する機能がない場合は、Webサービス・トランスポートを使用すると、今後の処理のためにイベントをAIAレイヤーのキューに公開できます。

ABCSは参加アプリケーションからのスキーマを使用して開発されるため、アウトバウンド・メッセージ書式とABCSメッセージ書式は同じです。

インバウンド相互作用

インバウンド・メッセージには次の属性があります。

- メッセージID
メッセージIDは、アプリケーションによって生成されるメッセージの一意の識別子で、メッセージにスタンプされます。たとえば、顧客IDまたは注文IDはペイロード内で一意です。

- メッセージ・ペイロード名
ビジネス・オブジェクトの名前は渡される必要があります。

- 参加アプリケーション・インスタンス
エンティティIDの相互参照を設定するにはアプリケーション・インスタンスの一意の識別子が必要であるため、これもペイロードに含める必要があります。

- イベント・セッション・ロケール
クライアント・セッションからのロケール情報によって、アプリケーションで実行されるリクエストにコンテキストが提供されます。これは、レスポンスが同じロケール・コンテキスト内にあることを確認するのに役立ちます。ロケール固有のヘッダーについては、アプリケーション・チームが検討してABMヘッダー属性を決定する必要があります。ロケール固有の情報を設定および取得することは、ABCS実装でABMのリクエストとレスポンスの変換ステップを実行する際のファクタの1つです。

アウトバウンド相互作用

アウトバウンド相互作用の場合、ABCSは、Webサービスとして公開された参加アプリケーションAPIを呼び出します。参加アプリケーションのWebサービスのWSDLは、ABCSによって使用されます。

14.2.2 SOAP/HTTPを使用したWebサービスを使用する場合

SOAP/HTTPを使用するWebサービスを利用して、アプリケーションから情報をフェッチし、その情報をリクエスタに提供できます。これは、相互作用の信頼性に対する要件が低く、操作が情報ストアの問合せに限定される場合に役立ちます。

メッセージ書式はXML (Extensible Markup Language)です。

このモードの接続は、次の場合にAIAで使用されます。

- リクエスト/レスポンス

- リクエストのみ

14.2.2.1 リクエスト-レスポンス

SOAPクライアントは、HTTP GETメソッドを使用して、指定されたリソースの表現をリクエストします。SOAPサーバーは、実行可能ファイルをトリガーして出力とともにレスポンスします。これは多重呼出し不変アクションで、複数の同じリクエストの結果が単一のリクエストと同じ結果になることを意味します。

たとえば、顧客営業担当は、顧客マスター・データ管理システムに新規顧客を作成する前に、顧客が存在するかどうかをシステムに問い合せます。

14.2.2.2 リクエストのみ

SOAPクライアントは、HTTP POSTを使用して、(たとえば、HTMLフォームから)処理されるデータを特定のリソースに発行します。データは、リクエストの本文に含まれます。これによって、新規リソースの作成、既存のリソースの更新、またはその両方が発生する場合があります。これは多重呼出し不変ではないアクションであるため、同じPOSTリクエストを複数回送信すると、状態に影響を与えて、悪影響をもたらす可能性があります。

たとえば、顧客は処理対象の注文をコンポジット・アプリケーションUIから発行します。

14.2.2.3 SOAP/HTTPを使用したWebサービスを使用する利点

SOAP/HTTPを使用したWebサービスは、次のとおりです。

- プラットフォームに依存しない

- 言語に依存しない

14.2.2.4 SOAP/HTTPを使用したWebサービスを使用する短所

XML形式のメッセージは処理が遅いため、メッセージのサイズを小さくしたり、圧縮技術を利用する必要があります。

HTTPは本質的にステートレス(呼出し間でデータを保持しない)であるため、コールごとに明示的なログインが必要になり、パフォーマンスのオーバーヘッドが発生します。

状態管理を伴うアトミック・トランザクションの概念はサポートされていません。回避策は、複数のリクエストで接続を再利用するセッション状態管理です(「SOAP/HTTPを使用したWebサービスでの状態管理」を参照)。

14.2.2.5 SOAP/HTTPを使用したWebサービスを使用する際の重要な考慮事項

AIAでは、相互運用性を促進するために、開発およびデプロイされるWebサービスが公開済のWS-Iに準拠する必要があります。

- WS-Securityを利用して、SOAPでXML暗号化およびXML署名を使用するメッセージ交換を保護するか、またはHTTP (HTTPS)を使用します。

- WS-Addressingを利用して、アドレスをSOAPヘッダーに挿入します。

- WS-ReliableMessagingを利用して、ソフトウェア・コンポーネント、システムまたはネットワークの障害がある場合でも、分散アプリケーション間でメッセージの信頼性のある配信が行われるようにします。

14.2.3 SOAP/HTTPを使用したWebサービスのセッション管理

ステートレスでアトミック・トランザクションをサービスできないというHTTPの短所を解消するには、セッション管理が必要です。この項には次のトピックが含まれます:

- セッション・タイプ

- SessionToken

- セッション・プール・マネージャ

14.2.3.1 セッション・タイプ

セッションには次の3タイプがあります。

- None
新規セッションがリクエストごとに開き、レスポンスが送信されると閉じます。

- Stateless
最初のリクエストで新規セッションが開き、後続のリクエストではセッションは開いたままになります。セッションが閉じた場合は、再ログインが自動的(ユーザーには透過的)に発生します。ステートレス・セッションを開くには、最初のリクエストにSOAPヘッダーとしてUsernameTokenおよびPasswordTextが含まれる必要があります。

- Stateful
最初のリクエストで新規セッションが開き、後続のリクエストではセッションは開いたままになります。セッションが閉じた場合、再ログインは自動的に発生しません。ステートフル・セッションを開くには、最初のリクエストにSOAPヘッダーとしてUsernameTokenおよびPasswordTextが含まれる必要があります。

StatelessまたはStatefulモードでは、WebサービスはSOAP: HEADERのSessionTokenを返す必要があります。これは、アプリケーション実装によって決まります。

14.2.3.2 SessionToken

SessionTokenは、Session ID、UserTokenおよびPasswordTextの暗号化です。

ステートレスまたはステートフルの各コールでは、更新されたSessionTokenが返されます。これは、再生攻撃に対して安全な方法です。

SessionTokenを更新するプロセスでは、セッションを閉じません。したがって、更新されたセッション・トークンを使用する次のコールで、再ログインはありません。セッションは開いたままになります。セッションが閉じるのは、セッション・タイプがNoneに設定されてコールがポストされるか、タイムアウトが発生した場合です。2番目のコール後には2つのセッション・トークンがあり、1つは1番目のコールで戻され、更新されたもう1つは2番目のコールから戻されます。この時点では、いずれかのSessionTokenを3番目のコールに送信できます(3番目のSessionTokenが返されます)。セッション・タイプをNoneに設定してコールをポストするとセッションIDが終了するため、すべてのセッション・トークンが無効になります。

SiebelアプリケーションのURLおよびSOAPヘッダーの例

例14-1、例14-2および例14-3に、SiebelアプリケーションのURLおよびSOAPヘッダーの例を示します。

SOAPヘッダーは次のようになります。

レスポンスは次のようになります。

例14-1 Siebelアプリケーションをコールしてログイン情報をSOAPヘッダーに渡すURL

http://sdcp1952i028.corp.siebel.com/eai_enu/start.swe?SWEExtSource=
SecureWebService&SWEExtCmd=Execute&WSSOAP=1

例14-2 SOAPヘッダー

<soapenv:Header>
<UsernameToken xmlns="http://siebel.com/webservices">rreddy</UsernameToken>
<PasswordText xmlns="http://siebel.com/webservices">rreddy</PasswordText>
<SessionType xmlns="http://siebel.com/webservices">Stateless</SessionType></soapenv:Header>

例14-3 SOAPヘッダーへのレスポンス

<SOAP-ENV:Header>
<siebel-header:SessionToken
xmlns:siebel-header="http://siebel.com/webservices">0f2cnvf0Ii5qsp-zk-
SEyjl2p0JD-QdYLt1LYvARXQMZfAL9YL.THekJHI1cVjZbBGQckQN.
cIfOGPKWKwUd6E0D4LD.VS.CKWsXw...</siebel-header:SessionToken>
</SOAP-ENV:Header>

14.2.3.3 セッション・プール・マネージャ

アプリケーションに対する多数の同時リクエスト/レスポンス・コールが必要なビジネス統合フローの場合は、コールごとにユーザー資格証明を送信するのではなく、セッション・トークン情報を送受信することをお薦めします。

- セッション・プール・マネージャは、後続のリクエストで再利用されるセッション・トークンのプールを管理するサービスです。

- セッションは、メモリーまたはデータベースのいずれかに保持されます。

- ログイン資格証明とURLは、管理者がセッション・プール・マネージャで構成します。

セッション・プール・マネージャの実装はアプリケーション固有で、Webサービス・フレームワークの実装を考慮する必要があります。

14.2.4 SOAP/HTTPを使用したWebサービスのエラー処理

この項では、SOAP/HTTPを使用したWebサービスのエラー処理について説明します。

- インバウンド接続の場合

- アウトバウンド接続の場合

- リクエスト/レスポンスおよびリクエストのみのシステム・エラー

- リクエスト/レスポンスのビジネス・エラー

14.2.4.1 インバウンド接続の場合

参加アプリケーションは、フォルト・メッセージを定義したWSDLを使用する機能が必要です。

参加アプリケーションに提供されるWSDLは、BPEL (ABCS)を使用して作成される粒度の粗いリクエスト/レスポンス・サービスに対して生成されます。これらのサービスの入出力ペイロードは、参加アプリケーションが提供するスキーマです。アプリケーションが提供するフォルト・スキーマは、サービス(WSDL)の定義にアプリケーションを組み込むのに役立ちます。

14.2.4.2 アウトバウンド接続の場合

参加アプリケーション・サービスのWSDLは、AIAサービスによって使用されます。エラー処理は、メッセージ交換パターンによって決まります。

14.2.4.3 リクエスト/レスポンスおよびリクエストのみのシステム・エラー

- 参加アプリケーションからのコールが成功しない
AIAレイヤーはHTTP 4xxクライアント・エラーを返し、参加アプリケーションは手動または自動で再発行するメカニズムを備えている必要があります。

例: FMWが停止して、AIAサービスにアクセスできない。

- 参加アプリケーションからのコールは成功したが、システム・リソースにアクセスできない
AIAレイヤーは5xxクライアント・エラーを返し、参加アプリケーションは手動または自動で再発行するメカニズムを備えている必要があります。

例: AIAサービス実行から、相互参照データベースにアクセスできない。

14.2.4.4 リクエスト/レスポンスのビジネス・エラー

- 参加アプリケーション・サービスのWSDLに名前付きフォルトが含まれる
この場合、WSDLには、指定のフォルト・メッセージ書式による名前付きフォルトが含まれます。AIAサービスは、ビジネス・エラーが発生すると、エラー情報をフォルト・メッセージに挿入して、コール元サービスにリプライします。参加アプリケーションは、それに応じて処理を実行します。

例: 無効なオプションが指定された注文がCRMアプリケーションからERPアプリケーションにプッシュされ、ERPアプリケーションでの検証が失敗しました。AIAサービスは、フォルトを受け取ると、適切なエラー・メッセージを作成し、そのメッセージをCRMアプリケーションのフォルト・スキーマに変換して、名前付きフォルトとして返送します。

- 参加アプリケーション・サービスのWSDLに名前付きフォルトが含まれない
この場合は2つの可能性があります。

- WSDLレスポンス・メッセージに、エラーを指定するためのコンポーネントと要素がある
この場合、AIAサービスは、ビジネス・エラーが発生すると、エラー情報をレスポンス・メッセージのフォルト・コンポーネントと要素に挿入して、コール元サービスにリプライします。参加アプリケーションは、それに応じて処理を実行します。

- WSDLに、フォルト情報を受け取るための有効な方法が指定されていない
次の2つのオプションがあります。

- AIAサービスで使用されているFMWコンポーネントがSOAPフォルトをサポートしている場合は、フォルトをSOAPフォルトとして返信します。

- リクエストのみとして相互作用をモデル化し、各参加アプリケーションのWebサービスが結果を受信するようにプロビジョニングします。

14.2.5 SOAP/HTTPを使用したWebサービスのセキュリティ

参加アプリケーションは、WSセキュリティのユーザー名トークン・プロファイル書式で認証情報を受け取る必要があります。これらは、リクエストを設計および復号化し、レスポンスを署名および暗号化できる必要があります。可能な場合は、SOAPヘッダー内で認証情報をxacml書式で受け取ります。

14.2.6 キューまたはトピックを使用したメッセージの伝播

参加アプリケーションは、インバウンド相互作用のためにメッセージをキュー(JMS、AQ、MQ、MSMQなど)にエンキューできます。参加アプリケーションは、発生した様々なイベントに関するメッセージを作成し、そのメッセージを指定のキューにエンキューします。これらのキューをサブスクライブしているAIAサービスがトリガーされます。これらは実質的に非同期です。メッセージのキューへの公開は、アプリケーション内で発生したのと同じトランザクションに含まれる必要があります。

また、参加アプリケーションは、アウトバウンド相互作用のためにメッセージをキュー(JMS、AQ、MQ、MSMQなど)からデキューできます。AIAサービスは、発生した様々なイベントに関するメッセージを作成し、そのメッセージを指定のキューにエンキューします。これらのキューをサブスクライブしている参加アプリケーションは、メッセージをデキューして処理します。これらは実質的に非同期です。メッセージのキューへの公開は、AIAサービス内で発生したのと同じトランザクションに含まれる必要があります。

キューイング・メカニズムは実質的に非同期です。これは、一方向コールで構成されます。

14.2.6.1 ペイロードなしのイベント通知

ペイロードがないイベント通知の場合は、イベントをサブスクライブしているか、またはイベントをポーリングしているABCSアダプタがメッセージを参加アプリケーションから取得します。一連のイベントがトリガーされますが、参加アプリケーションから取得される更新済エンティティのスナップショットがイベントに対応する保証はありません。データの整合性が失われないように、イベントはユーザーがトリガーすることをお薦めします。この場合、メッセージの順序付けはできません。

イベント通知の保証付き配信を確保するには、これらの通知でAIAレイヤーからの確認を受信でき、参加アプリケーションでこれらのイベント通知の再送信や適切なエラー処理を実行できる必要があります。これらのイベントはすべて、AIAレイヤーでIDまたはタイムスタンプに基づいて保持および集約され、データの整合性を保つために定期的に処理される必要があります。

14.2.6.2 メッセージ・キューイングを導くイベント

イベントが発生したためにメッセージがキューされると、メッセージはエンティティ状態のスナップショットを取得します。エンティティに一連の操作が密接に連続してある場合は、同じエンティティに対する異なる状態の一連のメッセージがキューに到着します。処理されるメッセージでネットワーク遅延やエラーが発生すると、そのような状態にあるメッセージの順序は保証できません。

いくつかの要件が満たされると、AIAサービスはメッセージを正しい順序で処理できます。

- メッセージの順序付けの要件
メッセージが順序付けされるには、順序付けが必要な一連のメッセージが定義される必要があります。さらに、すべてのメッセージが順序内で識別可能であることが必要です。

- 順序付けされるメッセージ・セットの識別子
グループIDのような名前付きパラメータが定義されます。共通する値を持つすべてのメッセージは、同じグループ、つまり順序付けされるメッセージのセットに含まれます。

- 順序付けされるメッセージの識別子
順序IDのような名前付きパラメータが定義されます。このパラメータの値は、数値または日時です。この値によって、各メッセージの順序内での位置が決まります。

14.2.6.3 キューまたはトピックを使用したメッセージの伝播を使用する場合

2つの基準のいずれかを満たすと、キュー/トピックを使用したメッセージの伝播を使用できます。

- プロセスをアトミック・トランザクションに分割する必要があります。

- イベント・トリガー・システムは、メッセージが処理されるまで待機できません。

14.2.6.4 キューのタイプ

次の2タイプがあります。

- キュー

- トピック

キュー

キューとは、処理前の要素を保持するように設計された永続的な格納メカニズムです。

注意点は次のとおりです。

- キューはポイントツーポイントです。

- メッセージを取得するのは1つのコンシューマのみです。

- コンシューマがメッセージを使用する時点でプロデューサが実行中である必要はなく、メッセージが送信された時点でコンシューマが実行中である必要もありません。

- 正常に処理されたすべてのメッセージは、コンシューマによって確認されます。

キューを使用する際の考慮事項

キューを使用する際は、次の点を考慮してください。

- 参加アプリケーションとのインバウンドおよびアウトバウンド相互作用では、WLSJMSキューを使用することをお薦めします。

- アプリケーションがAIAと互換性がなかったり、WLSJMSを使用してAIAとの間でメッセージを送受信できない場合は、サポートされている他のメッセージングを使用する必要があります。たとえば、アプリケーションと相互作用するには、ネイティブのWLSJMSで、AQJMSやTIBCOJMS、必要な外部JMSサーバーを設定する必要があります。

- WLSJMSキューに対してファイル・ベースの永続ストアを構成することをお薦めします。バルク・メッセージ、ポリシーまたはビジネス要件に対してデータベース永続性の使用が必要な場合は、データベース永続性を構成します。永続ストアをファイル・ベースで構成するか、またはデータベース・ベースで構成するかは、デプロイメント時に決定できます。

- SOAコア拡張機能のインストール・ドライバは、各キューのエラー・キューを自動的に作成します。

- エラー・キュー名を生成するには、SOAコア拡張機能のデプロイメント計画ジェネレータのスクリプトで、注釈からリソース名を使用してキューまたはトピック名を取得し、「_ErrorQ」を接尾辞として追加します。たとえば、AIASalesOrderQueueの場合、生成されるエラー・キューはAIASalesOrderQueue_ErrorQになります。

- SOAコア拡張機能のインストール・ドライバは、デプロイメント計画を使用して、WLSで作成するJMSキューごとに生成されるエラー・キュー名の作成、構成または割当を行います。

- SOAコア拡張機能によって、エラー再発行ユーティリティからすべてのエラー・キューに接続するために、汎用の非XAの接続ファクトリが1つ作成されます。汎用の接続ファクトリの名前はAIAErrorQueueConnectionFactoryです。

- 汎用のエラー接続ファクトリは、SOAコア拡張機能インストール時に作成されます。エラー・キューの生成は、注釈に基づいて事前作成済の統合のインストール時に発生します。

- 統合フローのマイルストンごとに、ファイル・ベースの永続ストアとともにWLSJMSキューを使用することをお薦めします。

トピック

トピックとは、処理前の要素を保持するように設計された永続的な格納メカニズムです。処理のために、メッセージが複数のサブスクライバに配信されます。

注意点は次のとおりです。

- 複数のコンシューマがメッセージを取得できます。

- パブリッシャとサブスクライバの間には、タイミング依存性が存在します。クライアントがサブスクライブできるように、パブリッシャはサブスクリプションを作成する必要があります。サブスクライバは、永続サブスクリプションを確立しないかぎり、引き続きアクティブなままでメッセージを受信します。この場合、サブスクライバが接続されていない間に公開されたメッセージは、再接続されるたびに再配されます。

- パブリッシュ/サブスクライブ・モデルの場合は、WLSJMSトピックを使用することをお薦めします。

14.2.7 保証付きメッセージ配信の確保

保証付きメッセージ配信とは、送信側システムから開始されたメッセージが正常に配信されて受信者に確認(確認が必要な場合)されるまで、そのメッセージが保持されることを意味します。この配信方法によって、メッセージはどのような状況でも失われません。

送信側と受信側は必ずしも参加アプリケーションである必要はありません。むしろ、これらはビジネス・プロセスの論理的なマイルストンになります。図14-4および図14-5に示すように、複数のマイルストンが存在できます。

図14-4 ビジネス・プロセスでの複数のマイルストンの例(1/2)

図14-5 ビジネス・プロセスでの複数のマイルストンの例(2/2)

- ハードウェアまたはソフトウェア・サービスが一時的に使用不可になっている場合もメッセージの消失や配信の失敗は発生せず、メッセージは確実に配信されます。

- エラー処理フレームワークには、ハードウェアまたはソフトウェア・サービスが再試行可能になるまでメッセージを保持し、訂正後にメッセージを再処理したり、既存のメッセージを破棄した後に新規メッセージを開始する手段が用意されています。

- メッセージ配信は、2つの統合マイルストン間でのメッセージ処理が1つの作業単位として扱われ、単一のグローバル・トランザクションにバインドされることによって確保されます。

14.2.7.1 トランザクション境界を使用する場合

次の場合にトランザクション境界を使用します。

- メッセージの処理に異なるコンポーネントが含まれる場合。JMSコンシューマ・アダプタ・サービス、BPELプロセス、メディエータ・サービス、相互参照コールおよびJMSプロデューサ・アダプタ・サービスが可能です。

- グローバル・トランザクションがすべてのコンポーネント間で有効になり、トランザクション境界が統合マイルストン間で確立されると、メッセージはターゲット・マイルストンに配信されるまでソース・マイルストンに保持されます。

14.2.8 JCAアダプタを使用する場合

Oracle FMWがサポートされたJCA仕様に基づいてアプリケーションにアダプタが実装されている場合は、JCAアダプタを使用します。これらのアダプタは、オラクル社認定のサードパーティが必要なJCA仕様をサポートしている場合に、そのサードパーティから購入できます。

JCAアダプタは、トランザクション対応である必要があります。保証付き配信を確保し、参加アプリケーションを取得してXAトランザクションに登録するには、JCAアダプタおよびアプリケーションで、AIAコンポジット・ビジネス・プロセスで必要な機能を構築する必要があります。

JCAアダプタは、AQまたはJMSのキューまたはトピック・アダプタです。また、JCAアダプタは参加アプリケーションのビジネス・オブジェクトAPIを公開できます。APIの粒度では、参加アプリケーションとのチャット可能の会話が求められます。アプリケーションは粒度の粗いAPIを公開することをお薦めします(ただし、アプリケーションの実装では粒度の細かい複数のAPIを呼び出す場合があります)。この公開によってチャット可能の会話を回避でき、ビジネス・トランザクションのパフォーマンス全体が向上します。

JMSアダプタの詳細は、『Oracle WebLogic Server JMSリソースの管理』を参照してください。

14.3 Siebelアプリケーション固有の接続ガイドライン

次の各項では、Siebelアプリケーションとのインバウンドおよびアウトバウンド接続を確立する方法を説明します。

- インバウンド: SiebelアプリケーションのAIAサービスとの相互作用

- SOAP/HTTPを使用したWebサービス

- JMSキュー/トピックからSiebelメッセージを使用するJMSコンシューマの作成

- アウトバウンド - SiebelアプリケーションのAIAサービスとの相互作用

- SOAP/HTTPを使用したWebサービス

14.3.1 インバウンド: SiebelアプリケーションのAIAサービスとの相互作用

Siebelアプリケーションがビジネス・プロセス、ビジネス・アクティビティおよびタスクを開始する駆動アプリケーションである場合、SiebelアプリケーションはAIAサービスにリクエストを送信します。Siebelアプリケーションは、Webサービスとして公開されたAIAサービスを呼び出すか、またはメッセージを直接JMSキューにプッシュしてAIA JMSコンシューマをトリガーできます。

要求側メッセージの書式は、Siebelにネイティブであるか、またはAIAエンタープライズ・ビジネス・オブジェクト(EBO)に準拠します。

書式がネイティブの場合、SiebelツールによってSiebel統合オブジェクトのスキーマが生成され、AIAサービスの作成用に提供されます。

詳細は、統合プラットフォーム・テクノロジ: Siebelエンタープライズ・アプリケーション統合を参照してください。

14.3.2 SOAP/HTTPを使用したWebサービス

Siebelツール(Siebel IDE)ではAIAサービスWSDLが必要です。SiebelツールはWSDLを調査し、プロキシを生成して実行時にAIAサービスを呼び出します。SiebelツールはSiebel統合オブジェクト用のスキーマを生成し、それらを使用してAIAリクエスタABCSを開発します。

AIAプロジェクト管理ライフサイクルのサービス構想と定義フェーズおよびサービス設計と作成フェーズの中で、次のタスクを実行します。

サービス構想と定義フェーズでのソリューション・アーキテクト向けのタスクは次のとおりです。

1. SiebelアプリケーションのリクエスタABCSを識別して、AIAプロジェクト定義に追加します。

2. 新規サービスの場合は、ビジネス・アナリストと協力して、要件を詳細に把握します。

3. 既存のサービスの場合は、ビジネス・アナリストと協力して、実行する変更の詳細を把握します。

4. 開発者と協力して、サービスの設計を進めます。

5. メッセージの書式を確定します。

6. AIAリクエスタABCSのWSDLを確定します。

7. サービスのメタデータがOracle Enterprise Repositoryに取得されたことを確認します。

8. AIAプロジェクト定義のデプロイメント計画にサービスを追加します。

14.3.3 サービス設計と作成フェーズでの開発者向けのタスク

サービス設計と作成フェーズでの開発者向けのタスクは次のとおりです。

1. ソリューション・アーキテクトが提供するSiebelリクエスタ・アプリケーション・ビジネス・サービス定義を分析します。

2. Siebelアプリケーション開発と協力して、可能な設計を検討します。

3. Siebelからのメッセージの内容を確定します。

4. Siebelからメッセージのスキーマを取得して次を確認します。

a. TargetNameSpace - バージョン0より上位の場合は、接尾辞V<N> (Vはバージョンの略語、Nはバージョン番号)が必要です。バージョン番号がない場合は、バージョン0とみなされます。例14-4にバージョン1の例を示します。

b. カスタム属性 - 例14-5に示す属性が必要です。
例14-6にカスタム属性のサンプルを示します。

5. リクエスタABCSを作成します。

6. このサービスからSiebelアプリケーション開発チームにWSDLを提供します。

例14-4 バージョン1のTargetNameSpaceの例

<xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema targetNamespace="
http://siebel.com/asi/V1" xmlns:xsd=http://www.siebel.com/xml/SWICustomerPartyIO

例14-5 必要なカスタム属性

<xsd:attribute name="Language" type="xsd:string"/>
<xsd:attribute name="Locale" type="xsd:string"/>
<xsd:attribute name="MessageId" type="xsd:string"/>
<xsd:attribute name="EnterpriseServerName" type="xsd:string"/>

例14-6 サンプルのカスタム属性

<xsd:complexType name="ListOfSwicustomerpartyio">
<xsd:sequence> <xsd:element name="Contact" type="xsdLocal:Contact" minOccurs=
"0" maxOccurs="unbounded"/></xsd:sequence>
<xsd:attribute name="Language" type="xsd:string"/>
<xsd:attribute name="Locale" type="xsd:string"/>
<xsd:attribute name="MessageId" type="xsd:string"/>
<xsd:attribute name="EnterpriseServerName" type="xsd:string"/
</xsd:complexType>

14.3.4 JMSキュー/トピックからSiebelメッセージを使用するJMSコンシューマの作成

SiebelツールはSiebel統合オブジェクト用のスキーマを生成し、それらを使用してAIAリクエスタABCSを開発します。

AIAプロジェクト管理ライフサイクルのサービス構想と定義フェーズおよびサービス設計と作成フェーズの中で、次のタスクを実行します。

サービス構想と定義フェーズでのソリューション・アーキテクト向けのタスクは次のとおりです。

1. Siebelアプリケーションによってプッシュされるメッセージを分析します。

SiebelアプリケーションはSiebel Webサービス・フレームワークを使用してメッセージをプッシュするため、メッセージは<SiebelMessage/>エンベロープにラップされます。JMSコンシューマではこれを除去する必要があります。

2. AIAライフサイクル・ワークベンチでJMSコンシューマ・ソリューション・コンポーネントの定義を作成し、適切なアセット・タイプとしてマークします。

14.3.5 サービス設計とアウトライン作成フェーズでの開発者向けのタスク

サービス設計とアウトライン作成フェーズでの開発者向けのタスクは次のとおりです。

1. JMSキュー内のメッセージによってトリガーされるJMSコンシューマ・サービス・コンポジットを作成し、前述のABCSを呼び出します。

2. キューの名前を識別します。

3. SOAメディエータ・コンポーネントを使用してアダプタ・コンポジットを作成します。

4. composite.xmlに注釈を付けます。
詳細は、「イベント集約プログラミング・モデルの実装」を参照してください。

5. Oracle Enterprise Repositoryに収集します。
詳細は、「直接統合の実装」を参照してください。

14.3.6 アウトバウンド - SiebelアプリケーションのAIAサービスとの相互作用

Siebelアプリケーションのアクションまたはイベントがビジネス・プロセス、ビジネス・アクティビティまたはタスクに含まれる場合、SiebelアプリケーションはAIAサービスからリクエストを受け取ります。AIAサービスは、Webサービスとして公開されたSiebelアプリケーションを呼び出すか、またはメッセージを直接JMSキューにプッシュしてSiebel JMSコンシューマをトリガーできます。

受け取るメッセージの書式は、Siebelにネイティブであるか、またはAIAエンタープライズ・ビジネス・オブジェクト(EBO)に準拠します。書式がネイティブの場合、SiebelツールによってSiebel WebサービスのWSDLが生成され、AIAサービスによって使用されます。

14.3.7 SOAP/HTTPを使用したWebサービス

Siebelツール(Siebel IDE)は、AIAプロバイダABCSの開発に使用されるWebサービスWSDLを生成します。

AIAプロジェクト管理ライフサイクルのサービス設計と作成フェーズの中で、次のタスクを実行します。

サービス設計と作成フェーズでの開発者向けのタスクは次のとおりです。

1. ソリューション・アーキテクトが提供するSiebelプロバイダABCS定義を分析します。

2. Siebelアプリケーション開発と協力して、必要なWebサービスの可能な設計を検討します。

3. Siebelへのメッセージの内容を確定します。

4. WebサービスのWSDLおよび付随するスキーマをSiebelアプリケーション・チームから取得します。

5. AIAMetaData/ApplicationObjectLibraryのMDSにある関連フォルダに格納します。

6. SiebelプロバイダABCSの開発を完了します。

14.3.7.1 セッション管理

Siebel Webサービス・フレームワークは、NonおよびStatelessタイプのセッションをサポートしています。別のセッション・タイプが必要な場合は、SessionTypeをSOAPヘッダーに追加する必要があります。

Siebel認証およびセッション管理のSOAPヘッダーを使用して、ユーザー資格情報およびセッション情報を送受信できます。ログイン用にユーザー名とパスワードを送信して、次のいずれかのセッションを呼び出すことができます。

- アウトバウンド・レスポンスの送信後に閉じるもの。

- レスポンスの送信後も開いたままのもの。

詳細は、次を参照してください。

- 統合プラットフォーム・テクノロジ: Siebelエンタープライズ・アプリケーション統合の「Webサービス」のWebサービスの呼出し例に関する項

- 統合プラットフォーム・テクノロジ: Siebelエンタープライズ・アプリケーション統合の「Webサービス」のXMLスキーマ・ウィザードでのxsd:anyタグのマッピングに関する項

- Oracle Application Integration Architecture事前作成済の統合: ユーティリティ・ガイドのセッション・プール・マネージャに関する項

セッション管理にStatelessタイプを使用します。Statelessは、Siebelセッションを永続的に保持します。

Siebel Webサービス・フレームワークのステートレス・セッションは、Webサーバーから独立しています。

すべてのレスポンスには、次のリクエストで使用する必要がある新しいSessionTokenが含まれます。

14.4 Oracle E-Business Suiteアプリケーション固有の接続ガイドライン

次の各項では、Oracle E-Business Suite (E-Business Suite)アプリケーションとのインバウンドおよびアウトバウンド接続を確立する方法を説明します。

- インバウンド: E-Business SuiteアプリケーションのAIAサービスとの相互作用

- コンカレント・プログラム実行可能ファイル

- ビジネス・イベント・サブスクリプション(OAPPSアダプタを使用したJCA接続)

- アウトバウンド: Oracle E-Business SuiteアプリケーションのAIAサービスとの相互作用

14.4.1 インバウンド: E-Business SuiteアプリケーションのAIAサービスとの相互作用

E-Business Suiteアプリケーションがビジネス・プロセス、ビジネス・アクティビティまたはタスクを開始する駆動アプリケーションである場合、E-Business SuiteアプリケーションはAIAサービスにリクエストを送信します。E-Business Suiteは、コンカレント・プログラム実行可能ファイルを使用してWebサービスとして公開されたAIAサービスを呼び出すか、またはJCAアダプタ(Oracle Apps Adapter)を介してAIAレイヤーにビジネス・イベントを発生できます。JCAアダプタは、特定のビジネス・イベントをサブスクライブするように構成する必要があります。

要求側メッセージの書式は、E-Business Suiteのアプリケーション・ビジネス・メッセージ(ABM)にネイティブであるか、またはAIAエンタープライズ・ビジネス・メッセージ(EBM)に準拠します。

14.4.2 コンカレント・プログラム実行可能ファイル

E-Business SuiteではAIAサービスWSDLが必要です。E-Business Suiteは、プロキシを生成してコンカレント・プログラム実行可能ファイルで使用し、実行時にAIAサービスを呼び出す必要があります。E-Business Suiteは、AIAとE-Business Suite間のコントラクト(WSDL)を定義してAIAリクエスタABCSを開発するのに使用する、スキーマ(ABM)を生成する必要があります。

AIAプロジェクト管理ライフサイクルのサービス構想と定義フェーズおよびサービス設計と作成フェーズの中で、次のタスクを実行します。

サービス構想と定義フェーズでのソリューション・アーキテクト向けのタスクは次のとおりです。

1. E-Business SuiteのリクエスタABCSを識別して、AIAプロジェクト定義に追加します。

2. 新しいABCSの場合は、ビジネス・アナリストと協力して、要件を詳細に把握します。

3. 既存のABCSの場合は、ビジネス・アナリストと協力して、実行する拡張の詳細を把握します。

4. 開発者と協力して、ABCSの設計を進めます。

5. ビジネス要件に従って必要なABMからAIAに通信するE-Business Suite機能に基づき、正しい接続を選択します。コンカレント・プログラム実行可能ファイルまたはビジネス・イベント・サブスクリプションを選択します。

6. メッセージ(E-Business Suite ABM)の書式を確定します。

7. E-Business SuiteとAIA間のコントラクトを確定(つまり、AIAリクエスタABCSのWSDLを定義)します。

8. E-Business SuiteとAIA間のエラーまたはフォルト処理メッセージの書式を定義して確定します。

9. エラー処理メカニズム、およびE-Business Suiteアプリケーション・ユーザー向けに表示して記録するAIAエラーのスタイルを定義します。

10. E-Business SuiteとAIA間のMEPを確定します。

14.4.3 ベスト・プラクティスと設計非同期パターン

ベスト・プラクティスに従って非同期パターンを設計し、長時間実行するトランザクションを回避

1. 非同期操作の確認のタイプを確定します。

2. サービスのメタデータがOracle Enterprise Repositoryに取得されたことを確認します。

3. AIAプロジェクト定義のデプロイメント計画にサービスを追加します。
サービス設計と作成フェーズでの開発者向けのタスクは次のとおりです。

4. ソリューション・アーキテクトが提供するE-Business SuiteリクエスタABS定義を分析します。

5. E-Business Suite開発と協力して、可能な設計を検討します。

6. E-Business Suiteからのメッセージの内容を確定します。

7. E-Business Suiteからメッセージのスキーマを取得して次を確認します。
TargetNameSpace - バージョン0より上位の場合は、接尾辞V<N> (Vはバージョンの略語、Nはバージョン番号)が必要です。バージョン番号がない場合は、バージョン0とみなされます。例14-7にバージョン0の例を示します。

8. リクエスタABCSを作成します。
このサービスからE-Business Suite開発チームにWSDLを提供します。

例14-7 バージョン0のTargetNameSpaceの例

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://xmlns.oracle.com/ebiz/CurrencyExchange"
xmlns:db="http://xmlns.oracle.com/ebiz/CurrencyExchange"
elementFormDefault="qualified">
<xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema
targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/db/top/CreatePayable
InvoiceListEbizDBAdapterV1"
xmlns=http://xmlns.oracle.com/pcbpel/adapter/db/top/CreatePayableInvoiceList
EbizDBAdapterV1

14.4.4 ビジネス・イベント・サブスクリプション(OAPPSアダプタを使用したJCA接続)

エンタープライズ・ビジネス・サービス(EBS)ワークフロー・ビジネス・イベントのサブスクリプションを行うには、ビジネス・イベント・アダプタ(OAPPSアダプタ)を、サービスを呼び出してE-Business Suiteでビジネス・イベントを発生するプラグインとしてOracle JDeveloperで使用可能にします。WF_BPEL_Qがイベントへのサブスクリプションとして作成され、アダプタはWF_BPEL_Qからイベントを読み取り、メッセージがキューに到着するとアダプタ・サービスをトリガーします。

E-Business Suiteは、AIAとE-Business Suite間のコントラクト(WSDL)を定義してAIAリクエスタABCSを開発するのに使用する、スキーマ(ABM)を生成する必要があります。

ビジネス・オブジェクトによっては、生成されるABMにイベント情報のみが含まれる場合があります。このような場合は、公開されているイベント情報からビジネス・オブジェクトIDが抽出され、E-Business Suiteを問い合せてオブジェクト全体を取得します。

AIAプロジェクト管理ライフサイクルのサービス構想と定義フェーズおよびサービス設計と作成フェーズの中で、次のタスクを実行します。

サービス構想と定義フェーズでのソリューション・アーキテクト向けのタスクは次のとおりです。

1. E-Business SuiteのリクエスタABCSを識別して、AIAプロジェクト定義に追加します。

2. 新しいABCSの場合は、ビジネス・アナリストと協力して、要件を詳細に把握します。

3. 既存のABCSの場合は、ビジネス・アナリストと協力して、実行する拡張の詳細を把握します。

4. 開発者と協力して、ABCSの設計を進めます。

a. ビジネス要件に従って必要なABMからAIAに通信するE-Business Suite機能に基づき、最適な接続を選択します。コンカレント・プログラム実行可能ファイルまたはビジネス・イベント・サブスクリプションを選択します。

b. メッセージ(ABM)の書式を確定します。

c. E-Business SuiteとAIA間のコントラクトを確定します。AIAリクエスタABCSのWSDLを定義します。

d. E-Business SuiteとAIA間のエラーまたはフォルト処理メッセージの書式を定義して確定します。

e. エラー処理メカニズム、およびE-Business Suiteユーザー向けに表示/記録/アラートするAIAエラー・メカニズムのスタイルを定義します。

f. E-Business SuiteとAIA間のMEPを確定します。

g. ベスト・プラクティスに従って非同期パターンを設計し、長時間実行するトランザクションを回避します。

h. 非同期操作の確認のタイプを確定します。

5. サービスのメタデータがOracle Enterprise Repositoryに取得されたことを確認します。

6. AIAプロジェクト定義のデプロイメント計画にサービスを追加します。

サービス設計と作成フェーズでの開発者向けのタスクは次のとおりです。

1. ソリューション・アーキテクトが提供するE-Business SuiteリクエスタABCS定義を分析します。

2. E-Business Suite開発と協力して、可能な設計を検討します。

3. E-Business Suiteからのメッセージの内容を確定します。

4. E-Business Suiteからメッセージのスキーマを取得して次を確認します。
TargetNameSpace - バージョン0より上位の場合は、接尾辞V<N> (Vはバージョンの略語、Nはバージョン番号)が必要です。バージョン番号がない場合は、バージョン0とみなされます。例14-8にバージョン1の例を示します。

5. リクエスタABCSを作成します。

6. このサービスからE-Business Suite開発チームにWSDLを提供します。

7. E-Business Suiteのビジネス・イベントによってトリガーされるE-Business Suiteアダプタ・サービス・コンポジットを作成し、JMSプロデューサ・サービスを呼び出します。

8. 接続ファクトリ名およびJNDI参照を識別します。

9. サブスクライブするビジネス・イベントを識別します。

10. 受信メッセージまたはビジネス・イベントに対して確認されるスキーマを識別します。

11. SOAメディエータ・コンポーネントを使用してアダプタ・コンポジットを作成します。

12. ターゲット・キュー名、接続ファクトリ名およびJNDI参照を識別します。

13. composite.xmlに注釈を付けます。
詳細は、「イベント集約プログラミング・モデルの実装」を参照してください。

14. Oracle Enterprise Repositoryに収集します。
詳細は、「直接統合の実装」を参照してください。

例14-8 バージョン1のTargetNameSpaceの例

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://xmlns.oracle.com/ebiz/CurrencyExchange"
xmlns:db="http://xmlns.oracle.com/ebiz/CurrencyExchange"
elementFormDefault="qualified">
<xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema
targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/db/top/CreatePayable
InvoiceListEbizDBAdapterV1"
xmlns=http://xmlns.oracle.com/pcbpel/adapter/db/top/CreatePayableInvoiceList
EbizDBAdapterV1

14.4.5 アウトバウンド: Oracle E-Business SuiteアプリケーションのAIAサービスとの相互作用

AIAサービス、コンポジット・ビジネス・プロセスまたはエンタープライズ・ビジネス・フローがE-Business Suiteへのリクエストを開始すると、E-Business SuiteアプリケーションはAIAサービスからのリクエストを受け取ります。AIAは、次のいずれかの方法でE-Business Suiteを呼び出すことができます。

- データベースまたはOracle Apps Adapterを使用して、PL/SQLプロシージャまたは関数を呼び出すことができます。これらのアダプタは、Oracle JDeveloperでプラグインとして使用できます。Oracle Apps Adapterは、PL/SQLプロシージャ/関数を呼び出す前にFND Appsコンテキストを設定するDBアダプタに対するラッパーです。

- ビジネス・サービス・オブジェクト(BSO)を使用して公開されたJAVAベースのWebサービスを呼び出します。Oracle- E-Business Suiteでは、Oracle E-Business Suiteアプリケーション・サーバーにホストされたサービスとしてJAVA APIを公開する直接的な方法はありません。ただし、Oracle Applicationsの技術スタックで提供されるBSO機能を使用して、Oracle Application Development Frameworkのアプリケーション・モジュールをサービスとして公開することは可能です。これらのサービスは統合リポジトリ(IRep)に到達し、リモート・アクティビティからサービスとして呼び出すことができます。
BSOの詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』を参照してください。

- データをインタフェース表にロードし、コンカレント・プログラムをコールしてデータを処理します。AIAは、DB/Appsアダプタを使用してデータをEBSインタフェース表に挿入し、DB/Appsアダプタを使用してコンカレント・プログラムまたは後処理APIをコールし、このデータを処理します。

- DBアダプタはOracle- E-Business Suite表からポーリングを行い、その統合サービスを開始できます。DBアダプタは、JDeveloperのウィザードを使用し、適切なBusinessEventまたはAPIを選択して構成する必要があります。JDeveloperは、Ebizデータベース上で実行する必要がある.sqlファイルを作成して、イベントをリスニングするためのサブスクリプションを作成します。

送信メッセージの書式は、E-Businessアプリケーション・ビジネス・メッセージ(ABM)のネイティブ書式である必要があります。

開発と設計タスクは、前述したインバウンド接続に似ています。アーキテクトまたは設計者は、E-Businessでビジネス機能が公開されている方法を識別し、E-Businessに接続するための前述の4つの方法から使用可能なパスを識別する必要があります。アーキテクトまたは設計者は、各トランスポートに関する一般的なガイドラインに基づいて、特定のビジネス要件に適したトランスポートを決定する必要があります。

14.5 設計のガイドライン

AIAサービスを利用して、タスク、ビジネス・アクティビティおよびビジネス・プロセスを実装します。

この設計と開発の共通ガイドラインは、様々なリソースを使用するすべての相互作用に適用でき、インバウンドおよびアウトバウンドの両方の相互作用に適用できます。

パターンのタイプに応じて、次の点を考慮してください。

- メッセージなしでイベント通知をプッシュ

- 保証付き配信要件を伴うイベント通知 - JCAアダプタ(使用可能な場合)を利用し、それ以外の場合はキューを使用します。

- 重要な状況ではないイベント通知 - Webサービスを使用します。

- メッセージ付きでイベントをプッシュ

- 情報を要求してその情報を待機するリクエスト・イベント - JCAアダプタ(使用可能な場合)を利用するか、またはWebサービスを使用します。

- 状態変更を伝播するリクエスト・イベント - JCAアダプタ(使用可能な場合)を利用し、それ以外の場合はキューを使用します。

詳細は、「AIA設計パターンの使用」を参照してください。

15 バルク処理に対するOracle Data Integratorの使用

バルク・データ処理は、参加アプリケーション間の離散レコードのバッチ処理です。Oracle AIAでは、Oracle Fusion Middleware SOA SuiteのコンポーネントであるOracle Data Integrator (ODI)を使用して、バルク・データ統合が実行されます。この章では、AIA ODIアーキテクチャの設計パターンの概要を示し、Xref表ありの大規模トランザクションの処理、ODIプロジェクトの作成、XREFナレッジ・モジュール、ODIの使用、ドメイン値マップの使用、エラー処理の使用、ODIのRef関数の使用の各方法、さらにパッケージおよびデータ・モデルをWebサービスとして公開する方法について説明します。

この章の内容は次のとおりです。

- AIA-Oracle Data Integratorアーキテクチャの設計パターンの概要

- Xref表ありの大規模トランザクション

- Oracle Data Integratorプロジェクトの作成

- XREFナレッジ・モジュールの使用

- Oracle Data Integratorの使用

- ドメイン値マップの使用

- エラー処理の使用

- Oracle Data IntegratorのRef関数

- パッケージおよびデータ・モデルをWebサービスとして公開する方法

Oracle Data Integratorの使用方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』を参照してください。

15.1 AIA-Oracle Data Integratorアーキテクチャの設計パターンの概要

Oracle Data Integratorのデータ転送は常にポイントツーポイントであるため、ソース・システムとターゲット・システムは、データのバッチ・ロードを処理できる必要があります。統合プロジェクトでは、ソース側またはターゲット側のいずれかのアプリケーションで処理できる行数に制限がある場合は、Oracle Data Integratorをソリューションとして採用しないでください。

この項では、AIAアーキテクチャでOracle Data Integratorを使用するためのAIA承認済の設計パターンについて説明します。AIAで承認されている設計パターンは、次のとおりです。

- 初期データ・ロード

- Xref表ありの大規模トランザクション

- 断続的な大規模トランザクション

15.1.1 初期データ・ロード

図15-1に示したこの設計パターンでは、特定オブジェクトのデータの初期セットが、ソース・データベースからターゲット・データベースにロードされます(たとえば、既存のソース・アプリケーション・データベースから新しいアプリケーション・データベースへの顧客アカウント情報のロードや請求書情報のロード)。プロセスでは、統合要件に応じて、Xrefデータが設定される場合と設定されない場合があります。

特定の統合用に開発されたOracle Data Integratorパッケージは、別の参加アプリケーションにデータをロードするために再使用することはできません。

図15-1 初期データ・ロード

15.1.2 Oracle Data Integratorのデータ・ロードの実行方法

Oracle Data Integratorのデータ・ロードを実行する手順は、次のとおりです。

注意:

次のサンプルのステップでは、図15-1に示すように、ERP Application 1からERP Application 2への初期データ・ロードを実行する方法について説明します。

1. ソース・アプリケーションのERP APP1では、そのネイティブ・テクノロジを使用してインタフェース表にデータが入力されます。

アプリケーションによっては、インタフェース表ではなく、ビューや実表などの他の方法を選択することもできます。

2. ジョブ・スケジューラによって、ソース側のOracle Data Integratorパッケージが呼び出されます。

3. Oracle Data Integratorによって、ソース・インタフェース表からデータが抽出され、ターゲット・インタフェース表に入力されます。

4. ターゲット・インタフェース表へのデータ入力後、Oracle Data IntegratorによるXref表へのApp 1 IDの入力、および共通IDの生成を実行するかどうかを選択できます。

この手順は省略可能です。

5. Oracle Data Integratorによって、行が処理されたことを示すために、処理された行がソース・インタフェース表から削除または更新されます。

6. ターゲット・アプリケーションのERP APP2では、ネイティブ・アプリケーションによって、ターゲット・インタフェース表からデータが抽出されてターゲット・データベースに入力され、その結果、ERP Application 2 IDが生成されます。

7. ターゲット・アプリケーションのジョブ・スケジューラによってOracle Data Integratorパッケージが呼び出され、Xref表に共通IDと一致するApplication 2 IDが入力されます。

Oracle Data Integratorの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』を参照してください。

15.1.3 Xref表ありの大規模トランザクション

大規模なデータ転送が必要な場合は、アプリケーション間のデータ転送にOracle Data Integratorソリューションを使用することをお薦めします。この方法を使用すると、Oracle Data Integratorパッケージによって、ソース・システムからターゲット・システムにデータが定期的に転送されます。

データのロード方法の詳細は、「Oracle Data Integratorのデータ・ロードの実行方法」を参照してください。

ソース側のインタフェース表に、処理した行を示すためのメカニズムを設定することをお薦めします。

15.1.4 断続的な大規模トランザクション

バッチ・ロードが通常のオンライン・トランザクションと共存する必要がある場合は、図15-2に示した方法をお薦めします。

図15-2 断続的な大規模トランザクション

このシナリオでは、2つの異なるフローによって、ソース・アプリケーションからターゲット・アプリケーションにデータが送信され、一方ではAIA Oracle Data Integratorアプローチを使用し、もう一方では標準のAIAアプローチを使用します。データ整合性は、参加アプリケーション側で確保する必要があります。AIA Oracle Data Integratorアーキテクチャ・アプローチを使用してロードするのは、新しいレコードのみにすることをお薦めします。

AIA-Oracle Data Integratorアーキテクチャを使用してソースからターゲットにデータを送信する方法の詳細は、「Oracle Data Integratorのデータ・ロードの実行方法」を参照してください。

作成操作がAIA Oracle Data Integratorアプローチを使用して実行する必要があるのに対して、その他のすべての操作は、AIAを使用して実行する必要があります。

この設計パターンで、Oracle Fusion Middlewareが使用できない場合にデータを送信する代替ルートとして、AIA Oracle Data Integratorアプローチを使用しないでください。かわりに、メッセージは、JMSQなどの適切なメッセージ・キューイング・テクノロジを使用してキューに入れ、AIAで推奨されている保証付きメッセージ・テクノロジを使用して処理する必要があります。

保証付きメッセージの詳細は、「保証付きメッセージ配信」を参照してください。

15.2 Xref表ありの大規模トランザクション

大規模トランザクション用のXrefデータの格納が有効ではない場合は、図15-3に示すように、Oracle Data Integratorを使用したポイントツーポイント統合を使用することをお薦めします。

図15-3 大規模トランザクション

たとえば、小売ストア・チェーンの本社で、毎日営業終了時に個々の小売ストアからデータを受信するとします。このシナリオでは、個々の各ローカル・ストアとHQの間では、これらのデータ・セットに対するDML操作がないため、Xrefデータを格納する必要はありません。

データのロード方法の詳細は、「Oracle Data Integratorのデータ・ロードの実行方法」を参照してください。

このアーキテクチャにはAIAコンポーネントはありません。ローカルERPアプリケーションによって、そのインタフェース表がロードされ、データをHQインタフェース表に送信するためのOracle Data Integratorパッケージが呼び出されます。データが処理された後で、Oracle Data Integratorによって、ローカルERPアプリケーションのインタフェース表の各行がTransferredまたはProcessedで更新されます。

15.3 Oracle Data Integratorプロジェクトの作成

Oracle Data Integratorを使用するAIAに対するバルク・データ処理戦略は、ポイントツーポイント・ソリューションの作成、Xrefにデータを設定する必要性の考慮、DVMの使用、および処理されたデータが実行時にAIAサービスに参加できることの保証などです。

15.3.1 Oracle Data Integratorプロジェクトの作成方法

Oracle Data Integratorプロジェクトを作成する手順は、次のとおりです。

1. データ・サーバーを定義します。

定義するソースおよびターゲットのデータ・サーバーは、バルク・データ処理用に選択された物理データベース・スキーマを参照する論理エンティティです。

定義する各データ・サーバーを物理データベース・スキーマにリンクします。

詳細は、『Oracle SOAスイートでのSOAアプリケーションの開発』を参照してください。

2. データ・サーバーをリバース・エンジニアリングします。

データ・ストアに加えて様々なモデルを生成するために、データ・サーバーをリバース・エンジニアリングします。

3. インタフェースを定義します。

必要に応じて、各データ・ストアに対するインタフェースを作成します。

インタフェースの作成プロセスで、ソース・フィールドとターゲット・フィールド間のマッピングを指定します。

4. パッケージを定義します。

パッケージは、作成したインタフェースが、XrefおよびDVMの使用も含むいくつかの中間ステップとともに実行されるステップです。パッケージでXrefの実装を選択した場合は、特別な統合ナレッジ・モジュール(IKM)を使用する必要があります。

パッケージには、選択した場合は、ソース表をクリーン・アップするステップも含まれます。

15.4 XREFナレッジ・モジュールの使用

Oracle Data Integratorで、XREFデータの作成は2ステップのプロセスです。各ステップがインタフェースです。全体的なプロセスは図15-4に示されています。

- 最初のインタフェースでは、ユーザーのソース表がOracle Data Integratorのソースであり、ユーザーのターゲット表がOracle Data Integratorのターゲットです。
ソース表からターゲット表へのデータの送信時に、ソース行および共通行に対するXREFデータを作成します。このプロセスでは、ターゲットの任意の列に共通識別子を入力する場合は、これもOracle Data Integratorのナレッジ・モジュールで処理されます。

注意:

ターゲット・インタフェース表に共通データ用のプレースホルダが含まれていない場合は、ソース識別子を入力するか、またはアプリケーションでソース行ごとに共通値用のプレースホルダが識別されるようにする必要があります。

- 最後のステップでは、データがインタフェース表からベース表に転記された後で、前述のインタフェース処理中に送信した、ターゲット識別子と共通(またはソース)識別子間のマッピングが使用可能であるデータ・ストアを、ターゲット・アプリケーションで識別する必要があります。
2番目のインタフェースは、このデータ・ストアがOracle Data Integratorのソースであり、XREF表がターゲットである場合に実行する必要があります。この結果、XREF表に適切なターゲット列が作成されます。

図15-4 XREFナレッジ・モジュールの使用

15.4.1 相互参照に関する必要な知識

相互参照は、メディエータ・コンポーネントを介して使用できるOracle Fusion Middlewareの機能で、通常は、サービス指向アーキテクチャ(SOA)の規則に基づいて作成される疎結合の統合で利用されます。統合の様々な参加アプリケーション間のランタイム相関を管理するために使用されます。

ソース表からターゲット表へのデータのロード時に、トリクル・フィード・アーキテクチャで実行する場合と同様に、SOAデータベースに相互参照データを設定する必要があります。SOA Suiteでは相互参照表のデータ入力に標準APIを使用できますが、これらのAPIは、セットベース処理ではなく行単位の処理になる場合があるため、Oracle Data Integratorでは使用できません。

以降の各項では、ソース表のデータをターゲット表にロードすると同時に、相互参照にデータを入力する方法について説明します。

相互参照の詳細は、「DVMおよび相互参照の使用」を参照してください。

15.5 Oracle Data Integratorの使用

Oracle Data Integratorを使用する前に、これらの前提条件を完了してください。

1. マスター・リポジトリと作業リポジトリを定義します。

2. すべてのトポロジ・パラメータを定義します。

a. 物理アーキテクチャ(ソース、ターゲットおよびXREF_DATA用)

b. 論理アーキテクチャ

c. コンテキスト

3. データ・モデルを定義します。

4. プロジェクトを作成します。

5. 次のナレッジ・モジュールをプロジェクトにインポートします。

a. KM_LKM SQL to SQL (メディエータXREF)またはKM_LKM SQL to Oracle (メディエータXREF)

b. CKM Oracle (提供済)

c. KM_IKM SQL Control Append (メディエータXREF)

ODIの設定方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』を参照してください。

15.5.1 変数の定義方法(ソース列名とターゲット列名)

XREF列名はハードコードできないため、ソース列名とターゲット列名を保持するために2つの変数を定義する必要があります。通常、これらの列名はAIAConfigurationファイルから導出されます。この項では、それをXMLから取得する方法を説明するのではなく、SQLのSELECT文からリフレッシュする方法について説明します。

変数の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』の、変数の取り扱いに関する項を参照してください。

ソース列名とターゲット列名を定義する手順は、次のとおりです。

1. 変数GetSourceColumnNameを作成します。
この変数は、XREF_DATA表の列名を判断するために使用されます。図15-5に示すように、「リフレッシュ中」タブには、実装に応じて、値をソースから取得するための適切なSQLが表示されます。

図15-5 「変数: GetSourceColumnName」ページ

2. 変数GetTargetColumnNameを作成します。
この変数は、XREF_DATA表の列名を判断するために使用されます。「リフレッシュ中」タブには、実装に応じて、値をソースから取得するための適切なSQLが表示されます。

15.5.2 最初のインタフェースの作成方法(ソースからターゲット)

最初のインタフェースを作成する手順は、次のとおりです。

1. インタフェースを作成します。

a. データ・モデルのソース表を「ソース」にドロップする必要があります(この例ではIM_FINANCIALS_STAGE)。

b. ターゲット表(この例ではPS_VCHR_HDR_STG)がターゲット・データ・ストアに表示されます。

2. 図15-6に示すように、各フィールドのマッピングを指定します。

図15-6 インタフェース・ダイアグラム・ページ

3. 「フロー」タブに移動します。

4. カスタマイズしたKM_LKM SQL to SQL (ESB XREF)として「LKM」を選択します。
これには、SOURCE_PK_EXPRESSIONというオプションがあります。このオプションで、XREF表のソース・キー値を表す式を渡します。ソース表にキーとして定義されている列が1列のみの場合は、このオプションにその列名(この例ではSEQ_NO)を単純に記述します。ソース・キーに複数の列が含まれる場合は、キー値を導出するための式を使用します。

たとえば、表に2つのキー列があり、これらの列を連結した値をソース値としてXREF表に格納する場合は、オプション値にSEQ_NO|DOC_DATEという式を入力します。このオプションは必須です。

XREFに加えて更新/削除を使用している場合は、LKMの他のオプションを更新します。更新/削除を使用していない場合は、オプションSRC_UPDATE_DELETE_ACTIONに「NONE」を設定します。

5. IKMで、カスタマイズしたナレッジ・モジュール「IKM SQL to SQL (ESB Xref)」を選択します。
このモジュールで、表15-1にリストしたオプションを定義する必要があります。

表15-1 カスタマイズしたナレッジ・モジュールIKM SQL to SQLの必須オプション

項目

説明

XREF_TABLE_NAME

XREF表の名前。

XREF_COLUMN_NAME

XREF表のソース列の名前。このオプションに、以前に定義した変数名(#GetSourceColumnName)を入力します。

XREF_SYS_GUID_EXPRESSION

共通識別子にGUIDを使用するか、順序を使用するかを選択します。GUIDの場合は、SYS_GUIDを使用します。順序の場合、この値に順序名を使用します。

XREF_ROWNUMBER_EXPRESSION

XREF_DATA表のROWNUMBER列に挿入される値。順序が必要ない場合は、デフォルト値のGUIDを使用します。

6. ナレッジ・モジュールを選択した場合は、「制御」タブで「CKM Oracle」を選択します。
共通値をターゲット表に送信する必要がない場合は、このステップは無視してください。

ターゲット表に共通識別子のプレースホルダがなく、ターゲット表の列の1つにソース識別子を指定する場合は、Oracle Data Integratorの標準マッピング・ルールを使用して、どのソース識別子をどの列に入力するかを示す必要があります。その場合、この統合ナレッジ・モジュールでは何も処理は実行されません。

共通識別子を保持するターゲット列がターゲット表の一意キーである場合は、その列にダミー・マッピングを挿入します。これは、Oracle Data Integratorの制限のためであり、これを実行しない場合は、次回インタフェースを開いたときにキーが表示されません。実行時、このダミー・マッピングは、統合ナレッジ・モジュールで生成された共通識別子で上書きされます。列値を挿入するターゲット列を示すために、UD1列にマークを付けます。

7. インタフェースを検証して保存します。

15.5.3 最初のインタフェースに対するパッケージの作成方法

最初のインタフェースに対するパッケージを作成する手順は、次のとおりです。

1. 図15-7に示すように、インタフェースを実行するパッケージを作成します。

図15-7 インタフェースを実行するパッケージ

これには、少なくとも2つのステップが必要です。

a. ソース列名を保持する変数をリフレッシュします。

b. インタフェースを実行します。

注意:

それぞれの実装で、その独自のエラー処理ステップをパッケージに追加します。

2. パッケージを検証して保存します。

3. パッケージを実行します。
ほとんどの場合、このパッケージは、ソース表にデータが到着するとすぐに実行されます。これを実現するには、Oracle Data Integratorのチェンジ・データ・キャプチャを使用します。

ソース表にデータが到着したときにパッケージを実行する方法は、以降の項で説明します。

15.5.4 SOAでのXREFビューの定義方法

SOAでXREFビューを定義する手順は、次のとおりです。

例15-1に示すように、XREFデータベースにXREFビューを作成します。

注意:

このビューを各実装に対して作成します。

例15-1 XREFデータベースでのXREFビューの作成

CREATE OR REPLACE FORCE VIEW "ORAESB"."INVOICE_XREF_VW" ("ROW_NUMBER",
"XREF_TABLE_NAME", "RETL_01", "COMMON", "PSFT_01") AS
select row_number, XREF_TABLE_NAME,
max(decode(XREF_COLUMN_NAME, 'RETL_01', VALUE,null)) RETL_01,
max(decode(XREF_COLUMN_NAME, 'COMMON', VALUE,null)) COMMON,
max(decode(XREF_COLUMN_NAME, 'PSFT_01', VALUE,null)) PSFT_01
from XREF_DATA
GROUP BY row_number, XREF_TABLE_NAME;

15.5.5 2番目のインタフェースの作成方法(XREFのターゲット識別子の更新)

データがターゲット・ベース表に移動し、ターゲット識別子が作成された後、ループを完了するために、そのデータをソース識別子に対応するXREFデータベースに戻す必要があります。前述のステップで、共通(またはソース)識別子がターゲット・システムに渡されました。ここでは、ターゲット・システムで、その共通(またはソース)識別子とターゲット・ベース識別子間のマップを提供する必要があります。これは、同じインタフェース表に挿入される場合と、別々の表に挿入される場合があります。このマッピング・データ・ストアは、このインタフェースのソースで使用されます。このインタフェースはパッケージ化され、最終的にターゲット・システムとは別のプロセスでそのパッケージが実行されます。

2番目のインタフェースを作成する手順は、次のとおりです。

1. データ・トランスポート用のインタフェースを作成します。
ソース・セクションに、XREF_VWビューおよびマッピング・データ・ストアをドロップします(この例では、PeopleSoft PS_VCHR_HDR_STGの同じインタフェース表)。ターゲット・データ・セクションで、XREF_DATA表を選択します。

2. 図15-8に示すように、表名のみからデータをフィルタするように、WHERE句を使用してXREF_VWにフィルタを適用します。たとえば、INVOICEに対してこれを使用している場合は、XREF_VW.XREF_TABLE_NAME='INVOICE'です。

図15-8 表名のみからデータをフィルタするためのWHERE句を使用したXREF_VWに対するフィルタ

3. 図15-9に示すように、マッピング・データ・ストアとXREF_VWを、共通(またはソース)識別子を格納する列と結合します。
この例では、共通データを格納するPeopleSoftインタフェース表の列はVOUCHER_ID_RELATEDです。

図15-9 共通IDを格納する列と結合されるマッピング・データ・ストアとXREF_VW

4. XREF_TABLE_NAMEのマップは、実装のXREF_TABLE名である必要があります。

5. XREF_COLUMN_NAMEのマップは(以前に作成した変数を指す)#GetTargetColumnNameである必要があります。

6. ROW_NUMBERをXREF_VWのROW_NUMBERにマップします。

7. VALUEフィールドに対するマップは、マッピング・データ・ストアのターゲット識別子を格納する列です(この例では、PS_VCHR_HDR_STGのINVOICE_ID列)。

8. IS_DELETEDに対するマップはNに設定されます。

9. LAST_MODIFIEDおよびLAST_ACCESSEDに対するマップは、実装ごとに異なります。

10. 図15-10に示すように、XREF_TABLE_NAME、XREF_COLUMN_NAMEおよびVALUEにKeyとマーク付けします。

図15-10 Keyとマーク付けされるXREF_TABLE_NAME、XREF_COLUMN_NAMEおよびVALUE

11. 「フロー」タブで、ロード・ナレッジ・モジュールLKM SQL to Oracleを使用します。

12. 統合ナレッジ・モジュールIKM Oracle incremental updateを使用します。

13. 「制御」タブで、チェック・ナレッジ・モジュールCKM Oracleを使用します。

14. インタフェースを検証して保存します。

15.5.5.1 2番目のインタフェースに対するパッケージの作成方法

2番目のインタフェースに対するパッケージを作成する手順は、次のとおりです。

1. 図15-11に示すように、インタフェースを実行するパッケージを作成します。

図15-11 インタフェースを実行するために作成されたパッケージ

これには、少なくとも2つのステップが必要です。

a. ターゲット列名を保持する変数をリフレッシュします。

b. 最初のインタフェースを実行します。

注意:

それぞれの実装で、その独自のエラー処理ステップをパッケージに追加します。

2. パッケージを検証して保存します。

3. パッケージを実行します。
ほとんどの場合、このパッケージは、ターゲットのマッピング・データ・ストアにデータが到着するとすぐに実行されます。これを実現するには、Oracle Data Integratorのチェンジ・データ・キャプチャを使用します。

15.6 ドメイン値マップの使用

ドメイン値マップ(DVM)はXMLファイルとして使用でき、提供時に使用できます。

DVMを使用する手順は、次のとおりです。

1. DVMをリバースエンジニアリングすると、複数のリレーショナル表になります。

次に、リバースエンジニアリング後にDVM XMLがどのように変換されるかを示します。図15-12に示すように、XML自体をデータ・サーバーに対するJDBC摘要で使用し、リバースエンジニアリングに対するスキーマでは使用しません。

図15-12 データ・サーバーに対するJDBC摘要で使用されるXML

図15-13に示すように、DVM XMLは、リバースエンジニアリング後に6つの表になります。

図15-13 DVM XMLのリバースエンジニアリング後の6つの表

2. これらの複数の表を結合して、インタフェースの対応するマッピングを導出します。

3. 図15-14に示すように、IM_FINANCIALS_STAGEをCELL表と結合します。

結合で、DVMに対してメイン・ソース表の列を使用します。

図15-14 IM_FINANCIALS_STAGEとCELL表の結合

4. 図15-15に示すように、CELL表をCOLUMN表と結合します。

図15-15 CELL表とCOLUMN表の結合

5. 図15-16に示すように、COLUMN表に(ソース列名を決定するための)フィルタを追加します。このフィルタでは、ソース列名を保持する変数を使用できます。

図15-16 COLUMN表に追加されたフィルタ

6. CELL表およびCOLUMN表をインタフェースにもう一度ドロップします。これらの名前は変更できますが、ここではCELL1およびCOLUMN1とします。これらの重複セットによって、ターゲット値がフェッチされます。

7. 図15-17に示すように、CELL1をCOLUMN1表と結合します。

図15-17 CELL1とCOLUMN1表の結合

8. 図15-18に示すように、COLUMN1表に(ターゲット列名を決定するための)フィルタを追加します。

このフィルタでは、ソース列名を保持する変数を使用できます。

図15-18 COLUMN1表に追加されたフィルタ

9. 最後に、図15-19に示すように、CELL表を別のCELL (CELL1)表と自己結合します。

図15-19 CELL表と別のCELL (CELL1)表の自己結合

10. 図15-20に示すように、ターゲット・インタフェース・マッピングでこの2番目のCELLデータ(CELL1表のデータ)を使用します。

図15-20 ターゲット・インタフェース・マッピングの2番目CELLデータ

注意:

各DVM中心の列に対してすべての結合を繰り返す必要があります。

15.7 エラー処理の使用

Oracle Data Integratorフローに対してエラー処理を使用する手順は、次のとおりです。

図15-21に示すパッケージは、エラーで終了した場合にAIAAsyncErrorHandlingBPELProcessを呼び出すサンプル・インタフェースです。

図15-21 エラーで終了した場合にAIAAsyncErrorHandlingBPELProcessを呼び出すサンプル・インタフェース

このプロセスに対するXMLリクエストの入力は、例15-2で提供されています。

例15-2 AIAAsyncErrorHandlingBPELProcess用のXMLリクエストの入力

<initiateRequest>
<Fault>
<EBMReference>
<EBMID/>
<EBMName/>
<EBOName/>
<VerbCode/>
<BusinessScopeReference>
<ID/>
<InstanceID>[End to End Process Name, Hard code, every developer must know
this process name]</InstanceID>
<EnterpriseServiceName/>
<EnterpriseServiceOperationName/>
</BusinessScopeReference>
<SenderReference>
<ID>[Sender Reference ID - Hard code the system id of the source system]</ID>
<SenderMessageID/>
<TransactionCode/>
<ObjectCrossReference>
<SenderObjectIdentification>
<BusinessComponentID/>
<ID/>
<ContextID/>
<ApplicationObjectKey>
<ID/>
<ContextID/>
</ApplicationObjectKey>
<AlternateObjectKey>
<ID/>
<ContextID/>
</AlternateObjectKey>
</SenderObjectIdentification>
<EBOID/>
</ObjectCrossReference>
<Application>
<ID/>
<Version/>
</Application>
</SenderReference>
</EBMReference>
<FaultNotification>
<ReportingDateTime><%=odiRef.getPrevStepLog("BEGIN")%></ReportingDateTime>
<CorrectiveAction>[ODI does not have it, leave this element null]</
CorrectiveAction >
<FaultMessage>
<Code>[ODI Error return code to be passed here. Must find the ODI system
variable to get the return code]</Code>
<Text><%=odiRef.getPrevStepLog("CONTEXT_NAME" )%>/<%=odiRef.getSession( "SESS_
NAME" )%>/<%=odiRef.getPrevStepLog("STEP_
NAME")%>:<![CDATA[<%=odiRef.getPrevStepLog("MESSAGE")%>]]></Text>
<Severity>[ODI does not have it, hard code it to 1]</Severity>
<Stack/>
</FaultMessage>
<FaultingService>
<ID>[Hard code a meaningful name of the Process, For example, CustomerInitialLoad (this
could be same as package name)] </ID>
<ImplementationCode>ODI</ImplementationCode>
<InstanceID><%=odiRef.getPrevStepLog("SESS_NO")%></InstanceID>
</FaultingService>
</FaultNotification>
</Fault>
</initiateRequest>

15.8 Oracle Data IntegratorのRef関数

表15-2に、Oracle Data IntegratorのRef関数とそれぞれの説明を示します。

表15-2 Oracle Data IntegratorのRef関数

Ref関数

説明

<%=odiRef.getPrevStepLog("BEGIN")%>

エラーで終了したステップが開始したときの日時

<%=odiRef.getPrevStepLog("MESSAGE")%>

前のステップによって返されたエラー・メッセージ(ある場合)。エラーが発生しなかった場合は空白文字列です。

<%=odiRef.getPrevStepLog("SESS_NO")%>

セッションの番号

<%=odiRef.getPrevStepLog("CONTEXT_NAME")%>

手順が実行されたコンテキストの名前。

<%=odiRef.getSession("SESS_NAME")%>

セッションの名前。

<%=odiRef.getPrevStepLog("STEP_NAME")%>

ステップの名前。

15.9 パッケージおよびデータ・モデルをWebサービスとして公開する方法

パッケージおよびデータ・モデルをWebサービスとして公開する手順は、次のとおりです。

1. スタンドアロン・サーバーとしてAxis2をインストールします。

a. 環境変数JAVA_HOMEに、JDKリリースをインストールしたディレクトリのパス名を設定します。

b. Apache Axis2バージョン1.2 (http://axis.apache.org/axis2/java/core/download.cgi)をダウンロードし、Axis2標準バイナリ・ディストリビューションを適切な場所に解凍して、ディストリビューションがその固有のディレクトリに存在するようにします。環境変数AXIS2_HOMEに、Axis2の抽出したディレクトリのパス名を設定します(例: /opt/axis2-1.2)。

c. コマンド$AXIS2_HOME\bin\axis2server.bat (Windows)を実行して、スタンドアロンAxis2サーバーを起動します。
起動後に、http://localhost:8080/axis2/services/にアクセスすると、Axis2に組み込まれているデフォルトのWebサービスを使用できます。

d. axis2.warをhttp://axis.apache.org/axis2/java/core/download.cgiからダウンロードします。

2. axis2.warをOC4Jアプリケーション・サーバーにデプロイします。

a. axis2.warをOC4Jアプリケーション・サーバー(http://www.oracle.com/technetwork/middleware/ias/downloads/utilsoft-090603.html)にデプロイするか、またはSOA SuiteのOC4Jサーバーも使用できます。http://<Host:port>に移動し、アプリケーション・サーバーを起動するとOC4Jホームが表示されます。「アプリケーション」タブをクリックし、次に「デプロイ」タブをクリックします。ファイルの場所を指定するよう要求されます。参照してAxis2.warファイルを指定し、デプロイします。

b. WARが正常にデプロイされた後、Webブラウザでhttp://<host:port>/axis2にアクセスしてテストします。この結果、「Axis2 Web Application Home Page」が開きます。

c. 手順が正常に終了したことを確認するために、「Validate」をクリックします。

3. Oracle Data Integrator Public Web ServicesをAxis2にインストールします。
Axis2で、「Administration」ページに移動します。

a. 「Upload Service」リンクを選択します。

b. Oracle Data Integrator Web Servicesの.aarファイルを参照します。
これは、Oracle Data Integratorインストール・ディレクトリの/tools/web_services/サブディレクトリにあります。

c. 「アップロード」ボタンをクリックします。
Axis2によって、Oracle Data Integrator Web Servicesがアップロードされます。Data Integrator Public Web ServicesがAxis2のサービス・リストに表示されるようになります。

d. 正常にインストールされたサービスのサービスと操作は使用可能なサービスのページ(http://<Host>:<HTTP port>/axis2/services/listServices)に表示され、ここにOdiInvokeが表示されます。

4. データ・サービス用の環境設定

a. データベース・ドライバ(http://www.oracle.com/technetwork/database/enterprise-edition/jdbc9201-092698.html)を適切なディレクトリにインストールする必要があります。OC4Jの場合はORACLE_HOME/j2ee/home/applibです。

b. データ・サーバーを指すJDBCデータソースを作成します。

- OC4J管理インタフェースに接続します。

- 「管理」タブで、「サービス」|「JDBCリソース」を選択し、「タスクに移動」をクリックします。

- 「接続プール」セクションで「作成」ボタンをクリックします。

- Axis2アプリケーションを選択し、「新規接続プール」を選択した後、「続行」を選択します。

- JDBCデータソースのフィールドを入力して、「終了」をクリックします。

- 「データソース」セクションで「作成」ボタンをクリックします。

- Axis2アプリケーションを選択し、「管理データソース」を選択した後、「続行」を選択します。

c. META-INF/context.xmlおよびWEB-INF/web.xmlがiAxisディレクトリで更新されます。
例15-3に示すように、特定のフォルダORACLE_HOME\j2ee\home\applications\axis2\META-INFのapplication.xmlを更新します。

d. 環境変数ODI_JAVA_HOMEに、JDKリリースをインストールしたディレクトリのパス名を設定します。

5. 図15-22に示すように、トポロジを構成します。

a. トポロジ・マネージャの物理アーキテクチャ・ビューで、Axis2テクノロジを選択します。右クリックして、データサーバーの挿入を選択します。別のWebサービス・コンテナを使用している場合は、適切なテクノロジをかわりに選択します。

b. 「定義」タブで次の各フィールドを入力します。

- 名前: Oracle Data Integratorに表示されるとおりのデータサーバーの名前。

- 公開されたサービスのベースURL: http://<Host>:<HTTP port>/axis2/services。

- 選択したデプロイメント方法に対応するオプションを選択します。

- Webサービスのアップロード: Axis2アプリケーションのルートURL(通常はhttp://<Host>:<HTTP port>/axis2/axis2-admin/)、およびAxis2管理者のユーザー名(admin)とパスワード(axis2)を指定します。

c. 「OK」をクリックします。物理スキーマを作成できるウィンドウが開きます。

d. 「コンテキスト」タブに移動し、データ・サービスをデプロイするコンテキストごとに論理スキーマを1つずつ定義します。

e. 「OK」をクリックします。

図15-22 トポロジ構成

6. Webサービスを使用して表のデータにアクセスするようにデータ・モデルを設定します。

a. モデルを開き、図15-23に示すように「サービス」タブに移動します。

b. 「アプリケーション・サーバー」リストから、以前に設定したWebサービス・コンテナを選択します。

c. 生成したWSDLで使用するネームスペースを入力します。

d. Webサービスが含まれる、生成したJavaパッケージに名前を付けるために使用するパッケージ名を指定します。通常、この名前の形式はcom.<company name>.<project name>です。

e. 「データソースの名前」フィールドで、データソースの設定時にサーバーに対して定義したデータソースの名前をコピーして貼り付けます。(データソースのJNDIロケーションを指定します。)

f. データ・サービス名を定義します。

g. リストからサービス・ナレッジ・モジュール(SKM Oracle)を選択し、そのオプションを設定します。

h. 「デプロイ済データストア」タブに移動します。

i. Webサービスとして公開するために必要なすべてのデータ・ストアを選択します。それぞれに対して、データ・サービス名および公開されたエンティティの名前を指定します。

j. 「OK」をクリックして、変更を保存します。

k. 「生成およびデプロイ」タブをクリックして、OC4Jサーバーにデプロイします。

l. デプロイしたデータ・ストアは、使用可能なすべての操作とともに、http://<Host>:<HTTP port>/axis2/services/listServicesで表示できます。

m. 生成したデータ・サービスは、パッケージで提供されているOdiInvokeWebServiceツールを使用してテストできます。

図15-23 「サービス - データ・サービス」ページ

7. Webサービスを使用してシナリオを実行します。
OdiInvoke Webサービスは、Webサービスを使用してシナリオを実行するために使用されます。WSDLはhttp://<Host>:<HTTP port>/axis2/services/OdiInvoke?wsdlです。使用するポートは、invokeScenarioというポートです。

このWebサービスは、エージェントに対して、特定の作業リポジトリに接続し、特定のシナリオを起動するように指示します。パラメータは、OSコマンドからのシナリオの実行時に使用するパラメータと同じです。例15-4は、このWebサービスに対するサンプルのSOAPリクエストです。

図15-5に示すように、シナリオの実行によってSOAPレスポンスが返されます。

例15-3 ORACLE_HOME\j2ee\home\applications\axis2\META-INFのapplication.xmlの更新

<Context >
<Resource
name="jdbc/TestDS"
type="javax.sql.DataSource"
driverClassName="oracle.jdbc.OracleDriver"
url="jdbc:oracle:thin:@abijayku-idc:1522:orcl1"
username="master"
password="master"
maxIdle="2"
maxWait="-1"
maxActive="4"/>
</Context>
(Resource name will be reused in the web.xml file and in the Model in Designer.)
(driverClassName, url, username and password will explicitly point to the
data source.)
Update the web.xml file with the resource name of the context.xml file
(here res-ref-name) in the given folder ORACLE_
HOME\j2ee\home\applications\axis2\axis2\WEB-INF as follows:
<resource-ref>
<description>Data Integrator Data Services on
Oracle_SRV1</description>
<res-ref-name>jdbc/TestDS</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>

図15-4 OdiInvoke Webサービスに対するサンプルSOAPリクエスト

<invokeScenarioRequest>
<invokeScenarioRequest>
<RepositoryConnection>
<JdbcDriver>oracle.jdbc.driver.OracleDriver</JdbcDriver>
<JdbcUrl>jdbc:oracle:thin:@sbijayku-idc:1522:orcl1</JdbcUrl>
<JdbcUser>MASTER_FINPROJ</JdbcUser>
<JdbcPassword>master</JdbcPassword>
<OdiUser>SUPERVISOR</OdiUser>
<OdiPassword>SUNOPSIS</OdiPassword>
<WorkRepository>WORK</WorkRepository>
</RepositoryConnection>
<Command>
<ScenName>ABC</ScenName>
<ScenVersion>001</ScenVersion>
<Context>RETL_TO_PSFT</Context>
<LogLevel>5</LogLevel>
<SyncMode>1</SyncMode>
</Command>
<Agent>
<Host>sbijayku-idc</Host>
<Port>20910</Port>
</Agent>
</invokeScenarioRequest>
</invokeScenarioRequest>

図15-5 シナリオの実行によって返されるSOAPレスポンス

<odi:invokeScenarioResponse xmlns:odi="xmlns.oracle.com/odi/OdiInvoke">
<odi:CommandResultType>
<odi:Ok>true</odi:Ok>
<odi:SessionNumber>1148001</odi:SessionNumber>
</odi:CommandResultType>
</odi:invokeScenarioResponse>

16 メッセージ変換の使用

この章では、変換マップの概要を示し、変換マップの作成方法、ドメイン値マップ(DVM)と相互参照の使用方法およびエンタープライズ・ビジネス・メッセージ(EBM)ヘッダーへの値の入力方法について説明します。

この章の内容は次のとおりです。

- 変換マップの概要

- 変換マップの作成

- 変換マップ拡張機能の使用

- DVMおよび相互参照の使用

- 識別タイプのマップと入力

- EBMヘッダー概念の概要

16.1 変換マップの概要

変換マップは、データの形状および意味の観点で、ソースまたはターゲット・アプリケーションで必要とされるドキュメントが、ソースまたはターゲット・アプリケーションによって生成されるドキュメントと異なる場合に使用します。変換マップによって、その構造的および意味的な相違を解決します。

16.1.1 ビジネス・プロセスを実装するためのアプリケーションの接続

Oracle Application Integration Architecture (AIA)では、正規パターンおよび直接パターンを利用して、ビジネス・プロセスを実装するためにアプリケーションを接続します。

16.1.1.1 正規パターン

AIAには、エンタープライズ・ビジネス・オブジェクト(EBO)と呼ばれる一連の汎用データ構造が導入されています。EBOは、勘定科目、受注、品目など、ビジネス概念の共通オブジェクト定義を表します。ビジネス統合プロセスは、完全なEBOまたはEBOのサブセットであるメッセージに対してのみ効果があります。このアプローチによって、参加アプリケーションから独立した産業間共通のアプリケーション・プロセスにできます。EBOには、ターゲット・アプリケーション・データ・モデルからビジネス・オブジェクトの要件を満たすコンポーネントが格納されます。変換によって、アプリケーション・ビジネス固有のメッセージが、AIA正規データ・モデルであるEBMにマップされます。

図16-1に、正規パターンがどのようにAIAに実装されるかを示します。

図16-1 AIAに実装された正規パターン

16.1.1.2 直接統合を使用する場合

データ統合に大量のレコードまたは大型のデータが含まれる場合は、再利用性とのトレードオフによって高いパフォーマンスでのデータの移動を専門的に取り扱う直接統合を実装するように選択できます。直接統合には、データの分離ではなく実装の分離のみに集中するバルク処理およびトリクル・フィードを含めることが可能です。

バルク処理の場合は、ETLツールが使用され、変換はツールを使用してデータ・レイヤーで実行されます。アプリケーション非依存オブジェクトがトリクル・フィードの実装に使用されることはありませんが、リクエスタ・アプリケーションでは、プロバイダ・アプリケーションで必要とされるデータ形状になるように引き続きコンテンツを変換する必要があります。

詳細は、「バルク処理に対するOracle Data Integratorの使用」を参照してください。

16.1.2 メッセージ変換を実行するためのツールおよびテクノロジの使用

変換マップの作成には、XSLTボキャブラリを使用することをお薦めします。

JDeveloperのXSLTマッパーを使用すると、Oracle BPEL Process ManagerまたはOracle Mediatorを使用して開発されたサービスのコンテキスト内でソース・スキーマ要素とターゲット・スキーマ要素間のデータ変換を作成できます。

マップ・ファイルの内容は、XSLTマッパー変換ツールを使用して作成します。図16-2に、XSLTマッパーのレイアウトを示します。

図16-2 XSLTマッパーのレイアウト

XSLTマッパーの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のXSLTマッパーでの変換の作成に関する項を参照してください。

16.2 変換マップの作成

統合プロセスに対して統合オブジェクトを構成するステップの1つは、内部統合オブジェクトのコンポーネントおよびフィールドを外部統合オブジェクトのメッセージ要素にマップすることです。これらのマップを使用して、ある統合オブジェクトから別の統合オブジェクトにデータを移動します。

16.2.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>

16.2.2 欠落または空の要素の処理

変換ロジックおよび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>

16.2.3 オプションのターゲット・ノードへのオプションのソース・ノードのマップ方法

オプションのソース・ノードをオプションのターゲット・ノードにマップする場合は、ソース・ノードが存在するかどうかをテストする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.2.4 システムIDの動的ロード方法

例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>

16.2.5 大規模ペイロードに対するXSLT変換の使用

BPELおよびOracle Mediatorでは、XSLTでドキュメント全体を横断する必要がある場合は、メモリー不足のエラーが発生する可能性があるため、大規模なペイロードにXSLT変換を適用しないことをお薦めします。

16.2.6 LanguageCode属性の値を入力する場合

すべてのEBMにはlanguagecode要素の値を入力し、リクエストを送信する必要があるロケールを指定する必要があります。言語依存データ要素の値がEBMルート要素に設定された値と異なる場合は、その要素にlanguageCode属性の値を入力しておく必要があります。DataAreaに指定されたlanguageCodeが優先されます。

16.2.7 変換名の指定方法

個別のコアXSLファイルに、各変換タイプを配置します。

ファイル名は、次の規則に従う必要があります。

<Source Schema Type>_to_<Destination Schema Type>.xsl

例: CreateOrderEBM_to_CreateOrderSiebelABO.xsl

16.3 変換マップ拡張機能の使用

EBMヘッダーを含め、EBMのすべてのコンポーネントには、必要な要素を追加するように構成できるカスタム領域があります。次の項のガイドラインを使用して、拡張機能を提供するコア変換XSLファイルを開発してください。

EBMヘッダーの詳細は、「EBMヘッダー概念の概要」を参照してください。

16.3.1 変換マップ拡張機能を使用可能にする方法

変換マップ拡張機能を使用できるようにする手順は、次のとおりです。

1. 変換ごとに拡張XSLファイルを作成します。
PurchaseOrder_to_PurchaseOrder.xslは、コア変換XSLファイルの一例です。

すべてのコアXSLファイル名には、たとえば、PurchaseOrder_to_PurchaseOrder_Custom.xslなど、単一の拡張XSLファイルがあります。

2. メッセージ内のすべてのコンポーネントに対して、拡張ファイルに空の名前付きテンプレートを定義します。

3. コア変換ファイルに拡張ファイルを組み込みます。

4. コア変換の各コンポーネントに対してcall-templateを追加します。

5. 例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>

16.3.2 変換テンプレートの業種を拡張可能にする方法

顧客固有のスキーマ拡張機能に関連するマッピング・ルールは、そのxsl拡張テンプレートに定義されます。

変換テンプレートの業種を拡張可能にする手順は、次のとおりです。

1. 拡張テンプレートを個別の変換ファイルに配置します。

2. メイン変換ファイルからインポートします。例16-8に、業種拡張可能な変換テンプレートを示します。

例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>

16.4 DVMおよび相互参照の使用

この項では、DVM、相互参照、ネーミング標準、およびそれらを使用する場合について説明します。

16.4.1 DVMの概要

ドメイン値は静的参照にのみ使用します。構成または設定データの保存には使用しないでください。パラメータ化された構成情報の格納および取得には、個別の機能が用意されています。

実行時にDVMにアクセスするには、JDeveloper XSLマッパーにあるlookup-dvm XSL関数を使用します。

DVMは、データベース永続性を使用するMDSリポジトリに格納され、JDeveloperまたはSOAコア拡張機能に用意されているツールを使用して管理されます。

ネーミング標準の詳細は、「AIA開発でのOracle AIAネーミング標準」を参照してください。

16.4.2 DVMの使用が必要な状況

DVMは3つのグループに分類できます。

- 可能な値はすべてシードされ、なにも定義できません。
これらの値にはロジックが追加され、そのロジックは参加アプリケーションによって定義されるため、値は追加できません。

- 参加アプリケーションに存在するシード値に基づいて、すべてまたはいくつかのサンプルがシードされています。
参加アプリケーションにさらに追加可能で、DVMに途中でさらに追加して対応できます。

通常、これらの値にロジックは追加されません。照合によって値を取得して受信側アプリケーションに渡します。参加アプリケーションで定義した可能な値すべてが含まれるように、リストを拡張する必要があります。

- カスタマイズされています。
依存する列を追加した場合に備えて、独自のDVMタイプおよび値を定義するように、命名規則が用意されています。これらのタイプまたは値はアップグレード時に影響を受けません。

相互参照表に相互参照仮想表を作成する場合は、次の項に記載されているネーミング標準に従います。

16.4.3 相互参照の使用

ABCSの中心的な設計タスクの1つは、疎結合アプリケーションからの一意の識別子に対する相互参照を維持することです。

AIAでは、階層的な相互参照はサポートしていません。子オブジェクトの共通キーは、親のコンテキスト管理下になく、それ自体で一意です。子オブジェクトには、共通IDに使用されるGUIDを備えた相互参照表内に独自のエントリがあります。

相互参照APIではマルチパート・キーをサポートしていません。アプリケーションに単一の一意キーがない場合は、キーを連結することをお薦めします。

{Key1}::{Key2}::Key3

ほとんどのリクエスタABCSは、次のロジックを変換で使用します。

1. XrefでアプリケーションIDに対応する既存の共通IDを参照します。

2. 共通IDが見つからない場合は、新しいIDを生成し、Xref表に新しいIDを入力します。

3. 検出されたIDまたは新しい共通IDを変換に使用します。

相互参照は、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に対して相互参照します。

16.4.4 相互参照の設定方法

Oracle SOA Suiteは、次のコンポーネントで構成される相互参照インフラストラクチャを提供します。

- 様々な相互参照オブジェクト・タイプを格納する仮想表が含まれている単一のXrefデータベース表と、データをインポート/エクスポートするコマンド行ユーティリティ。

- 相互参照の問合せ、追加および削除を実行するXPath関数。

ネーミング標準の詳細は、「AIA開発でのOracle AIAネーミング標準」を参照してください。

相互参照の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の相互参照の操作に関する項を参照してください。

16.5 識別タイプのマップと入力

各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>

16.5.1 corecom:Identificationに対する値の入力方法

corecom:Identificationまたはその派生では、次のガイドラインに従ってください。

- CommonのSchemeAgencyIDはCOMMONです。

- ID/ContextID/ApplicationObjectKeyのSchemeAgencyIDは、exsl:node-set ($senderNodeVariable)/IDと同じで、lookupXrefおよびlookupDVMの列名としても使用されます。

- BusinessComponentIDのスキームIDは、lookupXref/populateXrefのXrefTableNameと同じです。

16.6 EBMヘッダー概念の概要

ABCSおよびエンタープライズ・ビジネス・サービス(EBS)によって処理されるすべてのEBMには、オブジェクト固有の情報に加え、EBMヘッダーが含まれています。EBMヘッダーの目的は、次のために使用可能な情報を伝達することです。

- 重要な情報の追跡

- 監査

- ソース・システムとターゲット・システムの指定

- エラーおよびトレースの処理

図16-5に、EBMヘッダーの構成要素を示します。

図16-5 EBMヘッダーの構成要素

次の各項では、各構成要素について詳細に説明します。

16.6.1 標準的な要素

この項では、メッセージ・ヘッダーの標準的な要素について説明します。

16.6.1.1 EBMID

例16-10に示すように、この要素には、EBMを一意に識別するGUIDが格納されます。GUIDは、用意されている標準のXPath関数を使用して生成されます。

GUIDを生成するXPath関数: orcl:generate-guid()

例16-10 EBMID

<EBMHeader>
<EBMID>33303331343032313534393138393830</EBMID>
. . .
</EBMHeader>

16.6.1.2 EBOName

例16-11に示すように、この要素には、{namespaceURI}localpartという表記で完全修飾されたEBO名が格納されます。

例16-11 EBO名

<EBMHeader>
<EBOName>{http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/Invoice/V1}Query
Invoice</EBOName>
. . .
</EBMHeader>

16.6.1.3 RequestEBMID

例16-12に示すように、この要素には、送信元のリクエストIDを一意に識別するための送信元のリクエストGUIDが格納されます。EBSでは、レスポンス・メッセージのこのフィールドをリクエスト・メッセージから抽出して値を設定します。

例16-12 RequestEBMID

<EBMHeader>
<RequestEBMID>33303331343032313534393138393830</RequestEBMID>
. . .
</EBMHeader>

16.6.1.4 CreationDateTime

例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.6.1.5 VerbCode

例16-14に示すように、この要素には、EBMで表見された動詞が格納されます。

例16-14 VerbCode

<EBMHeader>
<VerbCode >Query</VerbCode>
. . .
</EBMHeader>

16.6.1.6 MessageProcessingInstruction

この要素には、メッセージを処理する方法の指示が格納されます。このセクションは、EBMが、標準的な処理経路を通る必要がある本番システム・レベルのメッセージであるか、テストまたはシミュレーション用の処理経路を通る必要があるテストレベルのメッセージであるかを示します。

MessageProcessingInstructionには、2つのフィールドがあります。

- EnvironmentCode:
CAVSまたはPRODUCTIONに設定します。デフォルトはPRODUCTIONです。値をPRODUCTIONに設定することは、リクエストを具体的なエンドポイントに送信する必要があることを示します。値をCAVSに設定することは、リクエストをCAVSシミュレータに送信する必要があることを示します。

- DefinitionID:
テスト用の定義IDを指定します。

AIAConfigurationProperties.xmlのRouting.[PartnerlinkName].RouteToCAVSプロパティがtrueに設定されている場合は、AIAConfigurationProperties.xmlのRouting.[PartnerlinkName].CAVS.EndpointURIプロパティの値が入力されます。

16.6.1.7 標準的なヘッダー・フィールドを入力する場合

メッセージを作成するときは常に標準的なヘッダー要素の値を入力する必要があります。次の場合が該当します。

- リクエスタABC実装サービスでアプリケーション・リクエストABMをEBMに変換する場合。

- プロバイダABC実装サービスでアプリケーション・レスポンスABMをEBMに変換する場合。

16.6.1.8 メッセージ処理の指示の入力方法

メッセージ処理の指示を入力する手順は、次のとおりです。

1. メッセージの処理方法を示す指示を追加します。
例16-15に示すように、通常は、本番モードまたはシミュレーション/テスト・モードのどちらでメッセージを実行するかをシステムに伝えるために、この指示を使用します。

2. これらのフィールドは、現在はCAVSで値が入力されます。
通常、フィールドは、テスト用のリクエストを開始する前に、SOAPヘッダーに値が入力されます。

例16-15 メッセージ処理の指示の入力

<corecom:MessageProcessingInstruction>
<corecom:EnvironmentCode>
<xsl:text disable-output-escaping="no">Production</xsl:text>
</corecom:EnvironmentCode >
</corecom:MessageProcessingInstruction>

16.6.2送信者

図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>

16.6.2.1 SenderMessageID

この要素は、ソース・アプリケーションで開始されたメッセージを一意に識別します。インバウンド・リクエスト・メッセージは、この要素に対する潜在的なソースの1つです。アプリケーション・ビジネス・メッセージ(ABM) (ソース・アプリケーションによって送信されたペイロード)は、ペイロードでSenderMessageIDに値を入力しておくか、ABMヘッダーに格納できます。ReqABCSImplでのABMからEBMへのインバウンド・メッセージ変換時に値が入力されます。

その後、この情報は、コンテキストを設定するために、同じ送信側アプリケーションにメッセージを送信する予定のダウンストリーム・サービスによって使用されます。

16.6.2.2 送信側システム情報を入力する場合

EBMを作成するときは常に送信側システム情報を入力する必要があります。次の場合が該当します。

- リクエスタABC実装サービスでリクエストABMをEBMに変換する場合。

- プロバイダABC実装サービスでレスポンスABMをEBMに変換する場合。

16.6.2.3 送信側システム情報の入力方法

送信側システム情報を入力する手順は、次のとおりです。

1. 次のXPath関数を使用して、システムID/コードに基づいてAIAシステム登録リポジトリから送信側システムの情報を取得し、データをXMLノードセットとして返します。

ebh:getEBMHeaderSenderSystemNode(senderSystemCode as string,
senderSystemID as string,
) return senderSystem as node-set

2. senderSystemCodeまたはsenderSystemIDのいずれかを渡します。
この関数によって、コードまたはIDに基づいてAIAシステム登録リポジトリのシステム情報が検索されます。

16.6.2.4 TransactionCode

TransactionCodeを使用して、送信側メッセージを生成した送信側システムの操作を識別します。

インバウンド・リクエスト・メッセージは、この要素に対する潜在的なソースの1つです。

コンテキストを保持するために、フォルト・ハンドラの捕捉でAIAFaultMessageを作成する際に、この要素の値が使用されます。

その後、この情報は、コンテキストを設定するために、同じ送信側アプリケーションにメッセージを送信する予定のダウンストリーム・サービスによって使用されます。

16.6.2.5 ContactName

この要素は送信側システムの連絡先の名前です。参照を実行することで、値がAIAシステム登録リポジトリから取得されます。この値を入力するには、ReqABCSImplから例16-16に詳細が記載されているAPIをコールする必要があります。この情報は、フォルト・メッセージで、またはダウンストリーム・サービスによって外部ビジネスに送信されるリクエスト・メッセージで使用可能になります。

16.6.2.6 ContactEmail

この要素は送信側システムの連絡先の電子メールです。参照を実行することで、値がAIAシステム登録リポジトリから取得されます。この値を入力するには、ReqABCSImplからAPIをコールする必要があります。この情報は、フォルト・メッセージで、またはダウンストリーム・サービスによって外部ビジネスに送信されるリクエスト・メッセージで使用可能になります。

16.6.2.7 ContactPhoneNumber

この要素は送信側システムの連絡先の電話番号です。参照を実行することで、値がAIAシステム登録リポジトリから取得されます。この値を入力するには、ReqABCSImplからAPIをコールする必要があります。この情報は、フォルト・メッセージで、またはダウンストリーム・サービスによって外部ビジネスに送信されるリクエスト・メッセージで使用可能になります。

16.6.2.8 ESBHeaderExtension

この要素は、図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.6.2.9 ObjectCrossReference

図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によって保持され、この値が入力されます。

16.6.2.10 送信側システムの情報へのオブジェクト相互参照情報の追加方法

相互参照エントリを送信側システムのObjectCrossReferenceに追加する手順は、次のとおりです。

送信側オブジェクトの識別子情報と、対応する相互参照の識別子を追加する必要があります。

- EBOID - 統合レイヤーにあり、対応する相互参照の識別子を提供します。この情報はReqABCSImplによって保持され、この値が入力されます。

- SenderObjectIdentification - オブジェクトのキー・フィールド名およびキー・フィールド値を入力します。データは送信側システムによって提供されます。

- ID - 送信側システムのオブジェクト・タイプ(たとえば、オーダー)を識別します。この情報はReqABCSImplによって保持され、この値が入力されます。

- NAME - 送信側システムの説明(たとえば、注文書)を識別します。この情報はReqABCSImplによって保持され、この値が入力されます。

- ContextID - 送信側システムのオブジェクト識別子を識別します。送信側のオブジェクトに複数の値がある場合は、これを複数回繰り返します。キー名の設定にはSchemeID属性を使用し、キーの値が要素自体に格納されます。この値はReqABCSImplによって保持され、この値が入力されます。

16.6.2.11 WS Address

この要素には、すべてのWS-Addressing要素が保持され、WS-Addressing要素を転送し、リクエスタとターゲット・システム間でのWS-Addressing要素の交換します。WS-Addressスキーマのローカル・バージョンが指定のディレクトリに保存され、この値はReqABCSImplによって入力されます。プロバイダ・アプリケーションがレスポンスを非同期モードで送信する場合にのみ、リクエストEBMでこの要素に値を入力する必要があります。非同期レスポンスを送信するプロバイダ・アプリケーションでは、この要素の値を利用してコールバック・アドレスを識別します。

16.6.2.12 カスタム

この要素は、ユーザーが拡張して独自の要素を追加できる複合タイプです。

この要素固有の使用方法の詳細は、「ファイア・アンド・フォーゲット・メッセージ交換パターンの実装」を参照してください。

16.6.3 ターゲット

Targetセクションの値は、Oracle Mediatorで定義されたターゲット・システムに対するルーティング・ルールをオーバーライドする必要がある場合にのみ入力します。バルク処理の場合は、ルーティング・ルールに定義されている同一のターゲット・システムにすべてのオブジェクトが到達するものと想定されます。そのようなシナリオでは、ルーティング・ルールをオーバーライドするために、適切なターゲット・システム情報をこの要素に定義します。ターゲット・システム情報のオーバーライドは、データ領域内のすべてのオブジェクトに適用されます。リクエスタABCSでは、ターゲット・システムの値を入力しないでくささい。詳細を入力できるのは、エンタープライズ・ビジネス・フロー(EBF)またはEBSのみです。

Target要素には、ターゲットまたは受信側のシステムに関する情報が格納され、図16-10に示すような要素があります。

図16-10 Target要素の構造

16.6.3.1 ID

例16-17に示すように、ルーティング・ルールのオーバーライドの際に、この要素を使用してルーティング対象のターゲット・システムを識別します。参加アプリケーションのインスタンス・コードの値でターゲット・システムをオーバーライドする必要がある場合に、EBSによって値が入力されます。

16.6.3.2 ApplicationTypeCode

この要素は、アプリケーションのタイプを識別します。同じアプリケーション・タイプの複数のインスタンスが統合プラットフォームに登録されている場合のアプリケーション・タイプの識別子です。システムで複数のバージョンがサポートされている場合、アプリケーション・タイプにはアプリケーションのバージョン番号が格納されます。

例16-17に示すように、このフィールドには、EBS (またはEBF)でTarget/IDフィールドに値が入力されるのと同時に、通常はABCSで値を入力する必要があります。このフィールドの値は、aia:getSystemType(<ID>)関数(IDは、Target/IDに入力されたシステムIDの値)で取得します。ルーティング・ターゲットの判断では、ほとんどの場合、このフィールドの値または値の欠落がEBSルーティング・ルールによってチェックされます。

16.6.3.3 カスタム

これは、必要な場合にユーザーが拡張して独自の要素を追加できる複合タイプです。

例16-17に、target要素のコードの例を示します。

例16-17 Target要素のコード・サンプル

<corecom:Target>
<corecom:ID>PORTAL_01</corecom:ID>
<corecom:ApplicationTypeCode>PORTAL_01</corecom:ApplicationTypeCode>
</corecom:Target>

16.6.4 BusinessScope

このセクションでは、UN/CEFACT標準のビジネス定義ヘッダーに定義されたビジネス範囲の仕様に関連する情報を取得します。

すべてのEBMには、次の要素に対して少なくとも2行の情報が必要です。

- Business Scopeというタイプの行には、メッセージが属しているエンドツーエンドのビジネス・プロセスを記述します。

- 2つ目の行には、フローに関連付けられた主要なメッセージを記述します(たとえば、ProcessOrderフローのオーダー・メッセージ)。

ほとんどの場合、各エンドツーエンド・プロセスのメッセージは1つのみです。ただし、複雑なビジネス・シナリオでは、プロセスから複数のメッセージが生成されたり、分岐することがあります。その場合、生成される各メッセージは、このセクションの行である必要があります。図16-11に、この仕組みを示します。

図16-11 BusinessScope要素の構造

16.6.4.1 ID

このインスタンスが関連しているコントラクトを識別するオプションの識別子。ReqABCSImplを使用してこの値を入力します。これはアプリケーションによって指定されたプロセスまたはメッセージの名前です。

16.6.4.2 InstanceID

範囲のインスタンスを参照する一意の識別子(たとえば、ドキュメント・インスタンスのプロセス実行インスタンス)。これは、アプリケーション・チームによって割り当てられた英数字コードにGUIDが連結された値です。メッセージ・タイプの場合、このセクションには、先頭のセクションで使用したEBMIDと同じものが使用されます。

16.6.4.3 BusinessScopeTypeCode

この要素は、ビジネス範囲の種類を示します。値は次のとおりです。

- BusinessScope (UMM)

- BusinessService (ebXMLの場合)

- Message

ReqABCSImplを使用してこの値を入力します。

16.6.4.4 EnterpriseServiceName

このメッセージが属しているEBSの名前。メッセージの作成者には認識されており、ABCSまたはEBSになります。ReqABCSImplを使用してこの値を入力します。

16.6.4.5 EnterpriseServiceOperationName

このメッセージが属しているEBSの処理の名前。メッセージの作成者には認識されており、ABCSまたはEBSになります。ReqABCSImplを使用してこの値を入力します。

16.6.4.6 カスタム

その他の要素を追加するために拡張できる複合タイプ。

16.6.4.7 ビジネス・プロセス情報の追加方法

すべてのEBMには、次の要素に対して少なくとも2行の情報が必要です。

- Business Processというタイプの行には、メッセージが属しているエンドツーエンドのビジネス・プロセスを記述します。

- 2つ目の行には、フローに関連付けられた主要なメッセージを記述します(たとえば、ProcessOrderフローのオーダー・メッセージ)。

ほとんどの場合、各エンドツーエンド・プロセスのメッセージは1つのみです。ただし、複雑なビジネス・シナリオでは、プロセスから複数のメッセージが生成されたり、分岐することがあります。その場合、生成される各メッセージは、このセクションの行である必要があります。

次のユースケースの例で、この仕組みを説明します。例を簡単に示すため、メッセージをプロセスの直属の子のみに制限し、その後のメッセージの連結については考慮していません。

16.6.5 ユースケース: リクエスト/レスポンス

GetAccountBalance: 図16-12に示すように、入力として勘定科目番号を使用してリクエスト・メッセージを送信し、レスポンスとして勘定残高を受信します。

図16-12 ユースケース: リクエスト/レスポンス

16.6.5.1 リクエストEBM

例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.6.5.2 レスポンスEBM

例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>

16.6.6 ユースケース: 非同期プロセス

SyncProduct: 図16-13に示すように、ポータルが非同期メッセージをSiebelに送信し、製品の詳細を同期します。

図16-13 ユースケース: 非同期プロセス

16.6.6.1 リクエストEBM

例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

16.6.7 ユースケース: 子プロセスの生成を伴う同期プロセス

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.6.8 EBMTracking

図16-16に示すように、EBMTrackingには、EBMが通過した各ノードに関する追跡情報が格納されます。通過した各実行単位に対して、EBMTrackingは複数回存在する可能性があります。

図16-16 EBMTracking要素の構造

16.6.8.1 SequenceNumber

この要素には、EBMが通過したノードの順序番号が格納されます。

16.6.8.2 ExecutionUnitID

この要素には、実行単位、ノードまたはプロセスIDのIDが格納されます。

16.6.8.3 ExecutionUnitName

この要素には、実行単位、ノードまたはプロセスIDの完全修飾名が格納されます。

16.6.8.4 ImplementationCode

この要素には、BPEL、メディエータ、Javaサービスなど、実行単位のタイプを示す実行単位のカテゴリが格納されます。

16.6.8.5 ActivityDateTime

この要素には、EBMが実行単位によって処理された時点を示すタイムスタンプが格納されます。タイムスタンプはUTCで表現し、現在の日時とGMTからの時差で、yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)?のように表現します。

16.6.8.6 EBM追跡情報を入力する場合

例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>

16.6.9 カスタム

カスタム・タイプを拡張して、その他の要素または必要な属性を追加できます。また、XSLTファイルの拡張機能を利用して必要なコードを追加し、カスタム・セクションに対する値の入力または値の読取り、あるいはその両方を実行できます。

17 エラー処理およびトレース・ロギング用のOracle AIAプロセスの構成

この章では、Oracle BPELおよびMediatorプロセスのエラー処理およびAIAエラー・ハンドラ・フレームワークの概要を示し、フォルト処理用にAIAプロセスを使用可能にする方法、同期メッセージ交換パターンに対してエラー処理を実装する方法、保証付きメッセージ配信が確保されるように非同期メッセージ交換パターンに対してエラー処理およびリカバリを実装する方法、通知用にAIAサービスを構成する方法、FaultNotification要素の記述、フォルト・メッセージの拡張、エラー処理の拡張、およびトレース・ロギング用にOracle AIAプロセスを構成する方法について説明します。

この章の内容は次のとおりです。

- Oracle BPELおよびMediatorプロセスのエラー処理の概要

- AIAエラー・ハンドラ・フレームワークの概要

- フォルト処理のためのAIAプロセスの有効化

- 同期メッセージ交換パターンに対するエラー処理の実装

- 保証付きメッセージ配信を確保するための非同期メッセージ交換パターンに対するエラー処理およびリカバリの実装

- 通知のためのAIAサービスの構成方法

- Oracle AIAフォルト・メッセージ・スキーマの説明

- フォルト・メッセージの拡張

- エラー処理の拡張

- トレース・ロギングのためのOracle AIAプロセスの構成

Oracle AIA B2Bエラー処理の詳細は、「AIAを使用したB2B統合の概要」を参照してください。

17.1 Oracle BPELおよびMediatorプロセスのエラー処理の概要

この項には次のトピックが含まれます:

- Oracle BPELエラー処理の理解

- Oracle Mediatorエラー処理の理解

17.1.1 Oracle BPELエラー処理の理解

Oracle Application Integration Architecture (AIA)エラー処理フレームワークでは、BPELプロセスのエラーが次の2つのカテゴリに分類されています。

- 実行時フォルト

- ビジネス・フォルト

実行時フォルト

実行時フォルトは、2つのシナリオのいずれかで発生する可能性があります。

- パートナ・リンクの呼出しに失敗した。

- パートナ・リンクが、実行時フォルトであることを示す名前付きフォルトを受信した。

この種のフォルトはユーザー定義ではなく、システムにより発行されます。BPELプロセスで実行時フォルトが発生する可能性がある状況には、次のものがあります。

- プロセスによって、値の不適切な使用が試行される。

- 論理エラーが発生する。

- SOAPコールでSOAPフォルトが発生する。

- サーバーによって例外が発行されるなど。

BPELプロセスとして作成されたAIAサービスは、実行時フォルトを取得して処理するように有効化および構成される必要があります。

ビジネス・フォルト

ビジネス・フォルトは、2つのシナリオのいずれかで発生する可能性があります。

- BPELプロセスが条件をフォルトとして評価してthrowアクティビティを実行した。

- invokeアクティビティが、ビジネス・フォルトであることを示す名前付きフォルトを受信した。

ビジネス・フォルトはアプリケーション固有のフォルトであり、メッセージを処理する際にエラー状況が発生すると生成されます。これらのフォルトはBPELプロセス・コンポーネントによって指定され、WSDLで定義されます。

BPELプロセスとして作成されたAIAサービスは、実行時フォルトおよびビジネス・フォルトを取得して処理するように有効化および構成される必要があります。

17.1.2 Oracle Mediatorエラー処理の理解

メディエータ・コンポーネントでは、実行時フォルトとビジネス・フォルトの両方を処理できます。

実行時フォルト

これらは、ネットワークが使用可能でないなど、基本システムでの問題によって発生するフォルトです。

ビジネス・フォルト

これらはコールされたWebサービスが返す例外です。これらはアプリケーション固有であり、サービスのWSDLファイルで明示的に定義されます。

メディエータ・コンポーネントとして作成されたAIAサービスは、ビジネス・フォルトを取得して処理するように有効化および構成される必要があります。

ただし、フォルト・ポリシーの適用対象は、パラレルのルーティング・ルールのみです。順次ルーティング・ルールの場合、フォルトはコール元に返され、コール元がフォルトの処理を担当します。

順次ルーティング・ルールのみを使用することをお薦めします。

順次ルーティング・ルールを使用した同期呼出しから発生するビジネス・フォルトをメディエータで処理するように構成する方法は、「ビジネス・フォルトを処理するためのメディエータの構成に関するガイドライン」を参照してください。

17.2 AIAエラー・ハンドラ・フレームワークの概要

エラー処理フレームワークおよびその機能の詳細は、Oracle Fusion Middleware Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイド リリース11.1.1.9のエラー処理の設定に関する項を参照してください。

17.3 フォルト処理のためのAIAプロセスの有効化

この項には次のトピックが含まれます:

- フォルト・ポリシー・ファイルに関する必要な知識

- BPELプロセスでのフォルト処理の実装方法

17.3.1 フォルト・ポリシー・ファイルに関する必要な知識

フォルト・ポリシー・バインディング・ファイルは、フォルト・ポリシー・ファイルに定義されているポリシーをSOAコンポジット・アプリケーション(サービス・コンポーネントまたは参照バインディング・コンポーネント)に関連付けます。フォルト・ポリシー・バインディング・ファイルは、fault-bindings.xmlという名前にする必要があります。これは、fault-bindings.xsdスキーマ・ファイルに準拠しています。

フォルト・ポリシー・ファイルの名前は、単一の固有名に限定されているわけではありません。ただし、命名規則に従ったフォルト・ポリシー・ファイルにすることをお薦めします。すべてのフォルト・ポリシー・ファイルには、<ServiceName>FaultPolicy.xmlの規則を使用して名前を指定してください。これらはfault-policy.xsdスキーマ・ファイルに準拠する必要があります。

命名規則の詳細は、「AIA開発でのOracle AIAネーミング標準」を参照してください。

フォルト・ポリシー・バインディング・ファイルを定義して、フォルト・ポリシー・ファイルに定義されたポリシーをSOAコンポジット・アプリケーションに関連付けることをお薦めします。

SOAコア拡張機能には、Oracle Metadata Services (MDS)のAIAMetaData/faultPolicies/V1フォルダに格納されたデフォルトのフォルト・ポリシーが付属しています。デフォルトのフォルト・ポリシーを使用する場合は、例17-1に示した要素をcomposite.xmlファイルに追加してください。

カスタマイズしたサービス固有のフォルト・ポリシー・ファイルをAIAサービスに使用するように選択する場合は、フォルト・ポリシー・ファイルおよびフォルト・ポリシー・バインディング・ファイル(fault-bindings.xml)をSOAコンポジット・アプリケーションのcomposite.xmlファイルと同じディレクトリに配置することをお薦めします。

相互参照の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のFault-policies.xmlのスキーマ定義ファイル操作に関する項およびFault-bindings.xmlのスキーマ定義ファイル操作に関する項を参照してください。

例17-1 composite.xmlに追加する要素

<property name="oracle.composite.faultPolicyFile">[pointer to the fault policy
xml file in the MDS]</property>
<property name="oracle.composite.faultBindingFile">[pointer to the fault policy
bindings file fault-bindings.xml in the MDS]</property>

17.3.1.1 フォルト・ポリシー・バインディング・ファイルへのフォルト・ポリシー・ファイルの関連付け

次の例は、サンプルのフォルト・ポリシー・ファイルに定義されたフォルト・ポリシーをフォルト・ポリシー・バインディング(.xml)ファイルに関連付ける方法を示しています。

例17-2に示すフォルト・ポリシーが定義されたサンプルのフォルト・ポリシー・ファイルSamplesQueryCustomerPartyPortalProvABCSImplFaultPolicy.xmlを検討します。

SOAコンポジット・アプリケーションまたはコンポーネント(BPELプロセスまたはOracle Mediatorサービス・コンポーネント)のいずれかを使用して、前述のフォルト・ポリシー・ファイルに定義されているポリシーをフォルト・ポリシー・バインディングのレベルに関連付けます。

fault-bindings.xmlファイルで、例17-3に示すように関連付けます。

注意:

この例では、関連付けはSOAコンポジット・アプリケーションのレベルで適用されます。

単一のコンポーネントを使用してコンポジットを作成する必要がある提示に準拠するように、フォルト・ポリシー・バインディング・レベルがデフォルトでSOAコンポジット・アプリケーションになるようにすることをお薦めします。

例17-2 フォルト・ポリシーが定義されたサンプルのフォルト・ポリシー・ファイル

<faultPolicies xmlns="http://schemas.oracle.com/bpel/faultpolicy">
<faultPolicy version="2.0.1"
id="SamplesQueryCustomerPartyPortalProvABCSImplFaultPolicy" . . . . . . .>
</faultPolicy>
</faultPolicies>

例17-3 fault-bindings.xmlでの関連付け

<faultPolicyBindings version="2.0.1"xmlns="http://schemas.oracle.com/bpel/
faultpolicy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<compositefaultPolicy="SamplesQueryCustomerPartyPortalProvABCSImpl
FaultPolicy"/>
</faultPolicyBindings>

17.3.2 BPELプロセスでのフォルト処理の実装方法

BPELプロセスでフォルト処理を実装する手順は、次のとおりです。

1. BPELプロセスでEBM HEADER変数を定義し、その変数を最初のステップとして入力します。
エラー処理フレームワークでは、この変数を使用してエンタープライズ・ビジネス・メッセージ(EBM)ヘッダーからフォルト・メッセージにコンテキスト詳細を入力します。BPELプロセスがアプリケーション・ビジネス・コネクタ・サービス(ABCS)である場合、入力はアプリケーション・ビジネス・メッセージ(ABM)であり、ABMがEBMに変換され次第、即時にEBM HEADER変数の値を入力する必要があります。このようにして、この変換ステップの後でパートナ・リンクでエラーが発生した場合は、エラー処理フレームワークがEBMヘッダー詳細にアクセスして情報を使用します。

2. BPELプロセスのフォルト・ポリシーを定義して、fault-bindings.xmlでこのポリシーをプロセスにバインドします。
サービス固有のフォルト・ポリシー・ファイルを使用している場合は、デフォルトのポリシーに指定されているCompositeJavaAction (oracle.apps.aia.core.eh.CompositeJavaAction)を常に使用します。エラー通知およびエラー・ロギングに対して、このCompositeJavaActionアカウントをインクルードします。

ビジネス・フォルトを処理するために、フォルト・ポリシーXMLファイルを定義する方法の詳細は、「ビジネス・フォルトの処理」を参照してください。

実行時フォルトを処理するために、同期メッセージ交換パターン(MEP)にフォルト・ポリシーXMLファイルを定義する方法の詳細は、「同期メッセージ変換パターンに対するエラー処理の実装」を参照してください。

実行時フォルトを処理するために、非同期MEPにフォルト・ポリシーXMLファイルを定義する方法の詳細は、「保証付きメッセージ配信を確保するための非同期メッセージ交換パターンに対するエラー処理およびリカバリの実装」を参照してください。

3. catchブロックを定義します。
CompositeJavaAction後のフォルト・ポリシーのデフォルトの動作は再スローの実行です。これによって、BPELプロセスに指定されたcatchまたはcatch-allブロックに対する実行制御が戻ります。

フォルト・ポリシーを使用したフォルトのインターセプトは、インターセプトしたフォルトと同じフォルトがCompositeJavaActionによって再スローされるため、ある意味では透過的です。したがってBPELでは、invokeアクティビティから発生する可能性があるバインディング・フォルトまたはリモート・フォルトなどのフォルトを捕捉する必要があります。

したがって、設計時に想定される各ビジネス・フォルトおよび各実行時フォルトに対してcatchブロックを定義します。

4. catch-allブロックを定義します。
これは、プロセスの実行中に発生する可能性がある予期しないエラーの捕捉に役立ちます。

同期リクエスト/レスポンスMEPに対するBPELのcatchおよびcatch-allブロックの定義の詳細は、「同期リクエスト/レスポンスでのBPELのCatchおよびCatch-Allブロックに関するガイドライン」を参照してください。

非同期MEPに対するBPELのcatchおよびcatch-allブロックの定義の詳細は、「BPELのCatchおよびCatch-Allブロックに関するガイドライン」を参照してください。

17.4 同期メッセージ交換パターンに対するエラー処理の実装

この項には次のトピックが含まれます:

- フォルト・ポリシーを定義するためのガイドライン

- 同期リクエスト/レスポンスでのBPELのCatchおよびCatch-Allブロックに関するガイドライン

- ビジネス・フォルトを処理するためのメディエータの構成に関するガイドライン

17.4.1 フォルト・ポリシーを定義するためのガイドライン

この項には次のトピックが含まれます:

- 実行時フォルトを処理するためのフォルト・ポリシーXMLファイルの定義

- ビジネス・フォルトを処理するためのフォルト・ポリシーXMLファイルの定義

17.4.1.1 実行時フォルトを処理するためのフォルト・ポリシーXMLファイルの定義

次のコード・スニペットに記載されたガイドラインどおりにフォルト・ポリシーXMLファイルにフォルトを定義します。例17-4に示すように、フォルト・ポリシーのConditionsの下にセクションを定義します。

前述したように、リモート・フォルトおよびバインディング・フォルトはデフォルトで定義することをお薦めしますが、その他の実行時フォルトは、サービスの機能ごとに必要に応じて同様の方法で処理できます。

たとえば、subLanguageExecutionFaultフォルトを処理する必要がある場合は、例17-5に示すようなセクションを定義します。

ただし、フォルト・ポリシー・ファイルに定義されたすべての実行時フォルトを、BPELプロセスのフォルトに固有のcatchブロックで捕捉する必要があります。

同期リクエスト/レスポンスMEPに対するBPELのcatchおよびcatch-allブロックの定義の詳細は、「同期リクエスト/レスポンスでのBPELのCatchおよびCatch-Allブロックに関するガイドライン」を参照してください。

例17-4 フォルト・ポリシーXMLファイルのフォルト定義

<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"name="bpelx:
remoteFault">
<condition>
<action ref="aia-ora-java"/>
</condition>
</faultName>
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:
bindingFault">
<condition>
<action ref="aia-ora-java"/>
</condition>
</faultName>

例17-5 subLanguageExecutionFaultフォルト処理

<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"name="bpelx:
subLanguageExecutionFault">
<condition>
<action ref="aia-ora-java"/>
</condition>
</faultName>

17.4.1.2 ビジネス・フォルトを処理するためのフォルト・ポリシーXMLファイルの定義

フォルト管理フレームワークを使用して、invokeアクティビティに対するビジネス・フォルトを処理します。つまり、invokeアクティビティを使用して呼び出された外部サービスおよびアプリケーションによってスローされたビジネス・フォルトのみが、フォルト・ポリシー・ファイルに指定された定義に従って、Oracle Fusion Middlewareフォルト管理フレームワークによってインターセプトされます。

BPEL内部のビジネス・フォルト(たとえば、throwアクティビティによってスローされたビジネス・フォルト)は、フォルト管理フレームワークではインターセプトされません。

Oracle AIAフォルトをインターセプトするためのフォルト・ポリシーを定義する手順は、次のとおりです。

1. パートナ・リンクWSDLを調査し、Oracle AIAフォルトをスローするかどうかの決定を確認します。

2. Oracle AIAフォルトをスローしている場合は、パートナ・リンクWSDLでパートナ・リンク・ネームスペースとフォルトの名前を検索します。

3. 次に示すように、フォルト・ポリシーのConditionsの下にセクションを定義します。

<Conditions>
<faultName xmlns:corecustomerpartyebs="http://xmlns.oracle.com/Enterprise
Services/Core/CustomerParty/V2" name="corecustomerpartyebs:fault">
<condition>
<test>[ XPath expression to be evaluated for the fault variable
available in the fault]</test>
<action ref="aia-ora-java"/>
</condition>
</faultName>
</Conditions>

注意:

不要な処理を回避するために、明示的に必要な場合にのみretryオプションを指定するようにします。

4. 次に示すように、aia-ora-javaアクションをコールするデフォルトの条件を構成します。

<Conditions>
<faultName xmlns:corecustomerpartyebs="http://xmlns.oracle.com/Enterprise
Services/Core/CustomerParty/V2" name="corecustomerpartyebs:fault">
<condition>
<test>[XPath expression to be evaluated for the fault variable
available in the fault]</test>
<action ref="aia-ora-java"/>
</condition>
</faultName>
<faultName>
<condition>
<action ref="aia-ora-java"/>
</condition>
</faultName>
</Conditions>

5. フォルト・ポリシー・ファイルに定義されたすべてのビジネス・フォルトは、ビジネス・フォルトに固有のcatch-blockのBPELプロセスで捕捉される必要があります。

詳細は、「同期リクエスト/レスポンスでのBPELのCatchおよびCatch-Allブロックに関するガイドライン」を参照してください。

17.4.2 同期リクエスト/レスポンスでのBPELのCatchおよびCatch-Allブロックに関するガイドライン

各BPELプロセスには、リモート・フォルト、バインディング・フォルト、ビジネス・フォルト(Oracle AIAフォルト)および設計時にパートナ・リンクで予想されるその他のフォルトに対して明示的なcatchブロックがあります。次のガイドラインを使用して、これらのcatchブロックを定義します。

17.4.2.1 ビジネス・フォルトの処理

内部ビジネス・フォルトを処理する手順は、次のとおりです。

1. throwアクティビティを実行するBPELプロセスの場合は、例17-6に示すように、ビジネス・フォルト・メッセージ(Oracle AIAフォルト・メッセージ)を作成して、AIAフォルト・メッセージにECIDを入力します。

注意:

EBM_to_Fault.xslで、<corecom:ExecutionContextID/>要素が<corecom:FaultingService>要素の下に挿入されていることを確認します。

2. 前述のフォルト・メッセージをcatchブロックで捕捉します。catchブロックで、次のことを実行します。

- AIAフォルト・メッセージをリプライとして送信します。
このOracle AIAフォルト・メッセージを入力として使用してAIAAsyncErrorHandlingBPELProcessを呼び出します。

- 捕捉されたAIAフォルト・メッセージをスローします。この再スローによって、Enterprise Managerコンソールにプロセスがフォルトとして表示されるようになります。

外部ビジネス・フォルトを処理する手順は、次のとおりです。

BPELのinvokeアクティビティの場合は、AIAフォルト・メッセージをレスポンスとして受信し、AIAフォルト・メッセージをcatchブロックで捕捉します。catchブロックで、次のことを実行します。

- AIAフォルト・メッセージをリプライとして送信します。

- 捕捉されたAIAフォルト・メッセージをスローします。この再スローによって、Oracle Enterprise Managerコンソールにプロセスがフォルトとして表示されるようになります。

注意:

この場合、ビジネス・フォルトは関連するフォルト・ポリシー・ファイルに定義されたフォルト・ポリシーに従ってOracle Fusion Middlewareのフォルト管理フレームワークで処理されるため、AIAではAIAAsyncErrorHandlingBPELProcessは呼び出されません。

例17-6 ビジネス・フォルト・メッセージ

<sequence name="SequenceBusinessFault">
<assign name="AssignBusinessFault">
<copy>
<from expression="ora:processXSLT('xsl/EBM_to_Fault.xsl',bpws:
getVariableData('EBM_HEADER'))"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault"/>
</copy>
<copy>
<from expression="'invalid account id'"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault/
corecom:FaultNotification/corecom:FaultMessage/corecom:Text"/>
</copy>
<copy>
<from expression="'invalid account id'"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault/
corecom:FaultNotification/corecom:FaultMessage/corecom:Stack"/>
</copy>
<copy>
<from expression="ora:getCompositeInstanceId()"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:
Fault/corecom:FaultNotification/corecom:FaultingService/corecom:
InstanceID"/>
</copy>
<copy>
<from expression="'BPEL'"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault/
corecom:FaultNotification/corecom:FaultingService/corecom:
ImplementationCode"/>
</copy>
<copy>
<from expression="ora:getCompositeName()"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:
Fault/corecom:FaultNotification/corecom:FaultingService/corecom:ID"/>
</copy>
<copy>
<from expression="ora:getECID()"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault/
corecom:FaultNotification/corecom:FaultingService/corecom:
ExecutionContextID"/>
</assign>
<throw name="Throw_custom_business_fault" faultName="client:fault"
faultVariable="AIAFaultMessage"/>
</sequence>

17.4.2.2 フォルト・ポリシー・ファイルに定義された実行時フォルトの処理

フォルト・ポリシーxmlファイルに定義された各実行時フォルトに対して、BPELには1つのcatchブロックがあります。

フォルト・ポリシー・ファイルに定義された実行時フォルトを処理する手順は、次のとおりです。

1. catchブロックで、Oracle AIAフォルト・メッセージを作成します。

2. このOracle AIAフォルト・メッセージをリプライとして送信します。

3. 捕捉されたフォルトを再スローします。これによって、Oracle BPELコンソールにプロセスがフォルトとして表示されるようになります。

17.4.2.3 フォルト・ポリシー・ファイルに定義されていない実行時フォルトの処理

また、各BPELプロセスには、catchブロックでは捕捉されない、フォルト・ポリシー・ファイルに定義されていない実行時フォルトを処理する1つのcatch-allブロックがあります。

catch-allブロックを定義する手順は、次のとおりです。

1. Oracle AIAフォルト・メッセージを作成します。例17-7に示すように、AIAフォルト・メッセージにECIDを入力します。

注意:

EBM_to_Fault.xslで、<corecom:ExecutionContextID/>要素が<corecom:FaultingService>要素の下に挿入されていることを確認します。

2. このOracle AIAフォルト・メッセージを入力として使用してAIAAsyncErrorHandlingBPELProcessを呼び出します。

3. このOracle AIAフォルト・メッセージをリプライとして送信します。

4. AIAフォルト・メッセージをスローします。これによって、Oracle Enterprise Managerコンソールにプロセスがフォルトとして表示されるようになります。

5. これらのcatchおよびcatch-allブロックは最上位レベルのスコープに定義できるため、特に必要な場合を除いて、各パートナ・リンクのスコープに定義する必要はありません。

フォルト管理フレームワークの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のフォルト管理フレームワークの使用に関する項を参照してください。

例17-7 Catch-Allブロックの作成

<sequence name="SequenceCatchAll">
<assign name="AssignFault">
<copy>
<from expression="ora:processXSLT('xsl/EBM_to_Fault.xsl',bpws:
getVariableData('EBM_HEADER'))"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault"/>
</copy>
<copy>
<from expression="ora:getFaultAsString()"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault/
corecom:FaultNotification/corecom:FaultMessage/corecom:Text"/>
</copy>
<copy>
<from expression="ora:getFaultAsString()"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault/
corecom:FaultNotification/corecom:FaultMessage/corecom:Stack"/>
</copy>
<copy>
<from expression="ora:getCompositeInstanceId()"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault/
corecom:FaultNotification/corecom:FaultingService/corecom:
InstanceID"/>
</copy>
<copy>
<from expression="'BPEL'"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault/
corecom:FaultNotification/corecom:FaultingService/corecom:
ImplementationCode"/>
</copy>
<copy>
<from expression="ora:getCompositeName()"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault/
corecom:FaultNotification/corecom:FaultingService/corecom:ID"/>
</copy>
<copy>
<from expression="ora:getECID()"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault/
corecom:FaultNotification/corecom:FaultingService/corecom:
ExecutionContextID"/>
</assign>
</sequence>

17.4.3 ビジネス・フォルトを処理するためのメディエータの構成に関するガイドライン

Oracle Mediatorでは、ビジネス・フォルト用のフォルト・ポリシーをベースとしたエラー処理を提供します。ただし、フォルト・ポリシーの適用対象は、パラレルのルーティング・ルールのみです。順次ルーティング・ルールの場合、フォルトはコール元(メディエータの呼出し元)に返され、コール元がフォルトの処理を担当します。

順次ルーティング・ルールのみを使用することをお薦めします。

メディエータによって呼び出されたサービスがビジネス・フォルトをスローした場合は、メディエータを呼び出したサービスまで、このフォルトを伝播する必要があります。

この項では、メディエータが呼び出したサービスから返された例外を処理するように、メディエータを構成する方法について検討します。

いくつかの考慮事項があります。

- メディエータがサービスを呼び出した場合は、呼び出されたサービスがWSDLに定義されているビジネス・フォルトをスローできます。

- 呼び出されたサービスによってスローされるフォルトはメディエータに伝播されます。

メディエータが呼び出したサービスから返された例外を処理するように、メディエータを構成する手順は、次のとおりです。

1. Oracle JDeveloperを使用してメディエータを設計モードで開きます。

2. 「静的ルーティング」パネルを使用して、メディエータに届いたインバウンド・フォルトをアウトバウンド・フォルトに割り当てることで、図17-1に示すように、呼び出したサービスにメディエータによってフォルトが伝播されるようになります。

図17-1 メディエータでのフォルトの割当

3. 前述の図のように、ターゲット・サービスのWSDL操作からのインバウンド・フォルトを、メディエータによってそのインボーカ・サービスに伝播されるアウトバウント・フォルトに割り当てます。

フォルト割当機能の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のフォルトの処理方法に関する項を参照してください。

17.5 保証付きメッセージ配信を確保するための非同期メッセージ交換パターンに対するエラー処理およびリカバリの実装

この項には次のトピックが含まれます:

- 概要

- マイルストンの構成

- マイルストン間のサービスの構成

- BPELのCatchおよびCatch-Allブロックに関するガイドライン

- フォルト・ポリシーを定義するためのガイドライン

- 未発行ロールバック・メッセージに対するフォルト・ポリシーの構成

- メッセージ再発行ユーティリティAPIの使用

17.5.1 概要

AIAにおける非同期MEPに対する保証付きメッセージ配信とは、送信者から開始されたメッセージが正常に配信されて受信者に確認(確認が必要な場合)されるまで、そのメッセージが保持されることを意味します。

送信側と受信側は必ずしも参加アプリケーションである必要はありません。むしろ、これらはOracle AIA統合フローの論理的なマイルストンになります。Oracle AIA統合シナリオには複数のマイルストンが存在する可能性があります。

非同期メッセージ・フローでハードウェアまたはソフトウェア・サービスが一時的に使用不可になっている場合もメッセージの消失や配信の失敗は発生しません。エラー処理フレームワークには、ハードウェアまたはソフトウェア・サービスが使用可能になるまでメッセージを保持する手段が用意されています。

エラー・コンソールでリソースを使用できないことが統合管理者に通知されると、管理者はリソースの問題に対応できます。統合管理者は、その後メッセージ再発行ユーティリティを使用して、統合シナリオに保持されているメッセージを適切なトランザクション・マイルストン・ポイントから再発行し、これによって、次のコンポーネントまたはマイルストンへの配信が可能になります。

メッセージ再発行ユーティリティの実行の詳細は、Oracle Fusion Middleware Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイド リリース11.1.1.9のメッセージ再発行ユーティリティの使用に関する項を参照してください。

次のポイントは、非同期MEPの保証付きメッセージ配信プログラミング・モデルの実装について主な側面を要約しています。

- メッセージ永続性マイルストン
メッセージは永続性ストア(ソース)から選択されて処理され、次の永続性ストア(ターゲット)に格納されます。メッセージは、正常に処理されてターゲットに配信されるまで、ソースから削除されません。ソースおよびターゲットはアプリケーションです。各永続性ストアはマイルストンを表し、データベース、ファイル・システム、JMSキューまたはJMSトピックです。

マイルストンの構成の詳細は、「マイルストンの構成」を参照してください。

- グローバル・トランザクション
次のタスクは、グローバル・トランザクションの一部として実行する必要があります。

- ソースからメッセージを選択します。

- 1つ以上のサービスでメッセージを処理します。

- メッセージをターゲットに配信します。

- 入力メッセージによるソースからのサービスの開始によってトランザクションが開始されます。ダウンストリームが呼び出されたすべてのサービスは、このグローバル・トランザクションに関与します。メッセージがターゲットに正常に配信され、ソースから削除されると、このグローバル・トランザクションは終了またはコミットされます。
エラーの場合は、例外が発生し、開始されたトランザクションはメッセージセーフでソースにロールバックされます。メッセージはソースまたはターゲットのいずれかに存在し、消失することはありません。

グローバル・トランザクションの構成の詳細は、「マイルストン間のサービスの構成」を参照してください。

- エラー処理およびリカバリ
システムまたはビジネス・エラーに起因する例外は、先行するすべてのサービスのロールバックを生成し、単一のエラー通知を統合管理者にトリガーする必要があります。エラー状態が削除されるまでメッセージが処理されないように、ソースのメッセージをフォルトとしてマークする必要があります。

エラー・ロールバックの構成の詳細は、「未発行ロールバック・メッセージに対するフォルト・ポリシーの構成」を参照してください。

システム・エラーの場合は、例外状態が削除された後、ソース内にある失敗したメッセージをリセットする必要があります。これによって再発行できるようになります。メッセージ再発行ユーティリティを使用して、正しいソースで再処理するようにメッセージを再発行できます。

ビジネス・エラーの場合は、ソース内の失敗したメッセージを削除し、さらに処理するためにフォールアウト管理に送信する必要があります。フォールアウト管理は、ビジネス・エラーが発生したメッセージを分離して個別に処理するカスタム実装です。

たとえば、処理のために発行されたオーダーでビジネス・エラーが発生したとします。オーダー・フォールアウト管理の実装の一環として、エラー・メッセージを調査してエラーの説明および是正措置を提供するトラブル・チケットを発行するアプリケーションに、オーダー・メッセージおよびエラー・メッセージがルーティングされます。是正措置に対応した後、オーダーは再処理されます。

非同期MEPのエラー処理およびリカバリは、次のように実装され、保証付きメッセージ配信が確保されます。

1. 各メッセージに一意のメッセージ識別子が割り当てられます。

2. EBMヘッダーにソース・マイルストン識別子が入力されます。

3. 失敗したメッセージのメッセージ識別子とソース・マイルストン識別子がフォルト通知に確実に含まれるようにします。

4. メッセージ再発行ユーティリティを使用して、失敗したメッセージをリカバリし、再発行します。

これらの構成の実装方法の詳細は、「マイルストンの構成」および「マイルストン間のサービスの構成」を参照してください。

メッセージ再発行ユーティリティの使用の詳細は、Oracle Fusion Middleware Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイド 11.1.1.9のメッセージ再発行ユーティリティの使用に関する項を参照してください。

メッセージ再発行ユーティリティAPIの詳細は、「メッセージ再発行ユーティリティAPIの使用」を参照してください。

17.5.2 マイルストンの構成

保証付きメッセージ配信を確保するための非同期MEPに対するエラー処理およびリカバリの実装の一環として、メッセージをマイルストンで保持する必要があります。マイルストン間でのメッセージの移動を保証する必要があります。

マイルストンはJMSキューまたはJMSトピックです。

図17-2および図17-3は、統合フロー全体で考えられるいくつかのマイルストンの場所を示しています。

図17-2 受信者ターゲット・マイルストンがターゲット参加アプリケーションである統合フロー

図17-3 受信者ターゲット・マイルストンがグローバル・トランザクション・スペース内にある統合フロー

17.5.3 マイルストン間のサービスの構成

この項には次のトピックが含まれます:

- メッセージ再発行値の入力

- 単一のグローバル・トランザクションに参加する全サービスの構成

これらのアクティビティを完了すると、マイルストン間のサービスが構成され、保証付きメッセージ配信を確保するために非同期MEPのエラー処理およびリカバリが提供されます。

17.5.3.1 メッセージ再発行値の入力

EBMヘッダーの次のパラメータは、JMSコンシューマ・サービス変換で値を入力する必要があります。

- SenderResourceTypeCode
ロールバックされたメッセージを格納するリソースまたはシステムのタイプ(キューまたはトピック)を示します。

- SenderResourceID
SenderResourceTypeCodeのタイプ(リソース/システム)の識別。

- SenderMessageID
SenderResourceTypeCodeのタイプに関連付けられたリソース/システムに保持されるメッセージの識別。

シナリオ1

JMSキューまたはトピックのABMがJMSコンシューマ・サービスをトリガーしている場合は、ABMヘッダーの一部として前述の情報をリクエスタABCSに渡す必要があります。

詳細は、「JMSConsumerAdapterのメッセージ再発行値のABMへの入力」を参照してください。

JMSコンシューマ・サービスで、この情報をABMヘッダーに送信するように構成する必要があります。リクエスタABCSで、この情報がABMヘッダーから抽出され、変換でEBMヘッダーに送信されます。

詳細は、「リクエスタABCSの再発行値のEBMヘッダーへの入力」を参照してください。

シナリオ2

JMSキューまたはトピックのEBMがJMSコンシューマ・サービスをトリガーしている場合は、EBMからEBMへの変換を使用して、EBMメッセージの再発行値を入力(上書き)します。インバウンド・メッセージのEBMヘッダー・フィールドの次の値は、現在のマイルストンに関連するリソース・タイプ、リソース名およびJMSメッセージIDを新しい値で上書きする必要があります。

- <corecom:SenderResourceTypeCode>

- <corecom:SenderResourceID>

- <corecom:SenderMessageID>

例17-8に、EBMからEBMへのXSLサンプル・コード・スニペットを示します。

例17-8 EBMからEBMへのXSLコードの例

<corecom:IntermediateMessageHop>
<corecom:SenderResourceTypeCode>
<xsl:value-of select="/custebo:CreateCustomerPartyListEBM/corecom:
EBMHeader/corecom:FaultNotification/corecom:FaultMessage/corecom:
IntermediateMessageHop/corecom:SenderResourceTypeCode"/>
</corecom:SenderResourceTypeCode>
<corecom:SenderResourceID>
<xsl:value-of select="/custebo:CreateCustomerPartyListEBM/corecom:
EBMHeader/corecom:FaultNotification/corecom:FaultMessage/corecom:
IntermediateMessageHop/corecom:SenderResourceID"/>
</corecom:SenderResourceID>
<corecom:SenderMessageID>
<xsl:value-of select='mhdr:getProperty("in.property.jca.jms.
JMSMessageID")'/>
</corecom:SenderMessageID>
</corecom:IntermediateMessageHop>

17.5.3.1.1 JMSConsumerAdapterのメッセージ再発行値のABMへの入力

次の内容でABMがエンリッチされていることを確認します。

- 一意のメッセージID。JMSヘッダーのJMSMessageIDが値として使用されます。

- リソース名。これはJMSキュー/トピック名です。この値は、JMSConsumerAdapterのcomposite.xmlの<svcdoc: ResourceName>と同じです。

- リソースのタイプです。可能な値はQueueまたはTopicです。

この目的でABMに明確に指定されたフィールドを使用します。これらのフィールドは設計時に識別されます。

メディエータ・ベースのJMSConsumerAdapter内で、次のようにします。

- メディエータ・ルーティング・ルールの変換ステップを使用します。

- 変換に使用されるXSLで、JMSメッセージID、リソース名およびリソース・タイプの値を、ABMの明確に指定されたフィールドに割り当てます。

例17-9に、JMSメッセージIDをABMに割り当てる方法を示します。

例17-9 ABMへのJMSメッセージIDの割当方法の例

<xsl:attribute name="MessageId">
<xsl:value-of select='mhdr:getProperty("in.property.jca.jms.JMSMessageID")'/>
</xsl:attribute>

この例では、ABMにJMSメッセージIDの割当先について固有の属性MessageIdがあることを前提としています。

場合によっては、指定された1つのフィールドのみがABMで使用できることがあります。このようなシナリオでは、JMSメッセージID、リソース名およびリソース・タイプの値を連結し、ABMの指定された特定のフィールドに値を割り当てます。これらの値を連結する際は、::をセパレータとして使用することをお薦めします。

たとえば、Siebel顧客ABMのListOfCmuAccsyncAccountIoについて検討します。このABMでは、設計時にJMSメッセージID、リソース名およびリソース・タイプに関する情報を保持するために、ListOfCmuAccsyncAccountIo要素のMessageId属性が指定されているとします。例17-10に、データを連結してABMに割り当てる方法を示します。

例17-10 データを連結してABMに割り当てる方法の例

<xsl:attribute name="MessageId">
<xsl:value-of select='concat(mhdr:getProperty("in.property.jca.jms.
JMSMessageID"),":: SampleQueue","::Queue")'/>
</xsl:attribute>

17.5.3.1.2 リクエスタABCSの再発行値のEBMヘッダーへの入力

JMSメッセージID、リソース名およびリソース・タイプの値がABMの指定フィールドで使用可能になっているため、ABMがリクエスタABCSに達するときは、それらの値が含まれます。

ヒント:

ABMからEBMへの変換の際は、<corecom: FaultNotification/>要素がEBMヘッダーに挿入されることを確認してください。

これらの値をABMから抽出し、EBMヘッダーの次の要素を<corecom:IntermediateMessageHop>要素に入力します。

- <corecom:SenderResourceTypeCode>: リソース・タイプの値を入力します。

- <corecom:SenderResourceID>: リソース名の値を入力します。

- <corecom:SenderMessageID>: JMSメッセージIDの値を入力します。

ABMからEBMへの変換を実行するXSLで、このタスクを実行する必要があります。例17-11に示すように、3つの再発行値を保持するために3つの異なるABMフィールドが指定されている場合、タスクは単純です。

例17-11 3つの再発行値の保持に使用される3つのABMフィールドを示す例

<corecom:IntermediateMessageHop>
<corecom:SenderResourceTypeCode>
<xsl:value-of select="[xpath to the ABM field holding the ResourceType]"/>
</corecom:SenderResourceTypeCode>
<corecom:SenderResourceID>
<xsl:value-of select="[xpath to the ABM field holding the
Resource Name]"/>
</corecom:SenderResourceID>
<corecom:SenderMessageID>
<xsl:value-of select="[xpath to the ABM field holding the Message Id]"/>
</corecom:SenderMessageID>
</corecom:IntermediateMessageHop>

次に、3つの再発行値が連結され、ABMの指定された単一のフィールドに割り当てられている場合に、ABMから再発行値を抽出し、EBMヘッダーに割り当てる方法について説明します。

たとえば、Siebel顧客ABMのListOfCmuAccsyncAccountIoについて検討します。このABMでは、JMSメッセージID、リソース名およびリソース・タイプに関する情報を保持するために、::をセパレータとして使用して、ListOfCmuAccsyncAccountIo要素のMessageId属性が指定されているとします。詳細は、前述の項を参照してください。

例17-12に、再発行値を抽出してEBMヘッダー要素に割り当てるコード・スニペットを示します。

例17-12 再発行値の抽出およびEBMヘッダー要素への割当に使用されるコード

<xsl:variable name="MsgId">
<xsl:value-of select="substring-after(/seblcustabo:ListOfCmuAccsyncAccountIo/
@MessageId,'::')"/>
</xsl:variable>
<corecom:IntermediateMessageHop>
<corecom:SenderResourceTypeCode>
<xsl:value-of select="substring-after($MsgId,'::')"/>
</corecom:SenderResourceTypeCode>
<corecom:SenderResourceID>
<xsl:value-of select="substring-before($MsgId,':: ')"/>
</corecom:SenderResourceID>
<corecom:SenderMessageID>
<xsl:value-of select="substring-before(/seblcustabo:ListOfCmuAccsync
AccountIo/@MessageId,'::')"/>
</corecom:SenderMessageID>
</corecom:IntermediateMessageHop>

ABMからEBMへの変換を実行するXSLで、このタスクを実行する必要があります。

メッセージ再発行の詳細は、Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイドのメッセージ再発行ユーティリティの使用に関する項を参照してください。

17.5.3.2 単一のグローバル・トランザクションに参加する全サービスの構成

単一のグローバル・トランザクションは、次のように構成します。

- コミット・ポイントが2つのマイルストン間にないこと。

- 2つのマイルストン間で行われる作業が、単一の論理単位の作業であること。

グローバル・トランザクションの構成の詳細は、「エンタープライズ・ビジネス・サービスの設計と開発」、「アプリケーション・ビジネス・コネクタ・サービスの設計」、「ABCSの作成」および「エンタープライズ・ビジネス・フローの設計と作成」を参照してください。

17.5.4 BPELのCatchおよびCatch-Allブロックに関するガイドライン

この項には次のトピックが含まれます:

- フォルト・ポリシー・ファイルに定義された実行時フォルトの処理

- フォルト・ポリシー・ファイルに定義されていない実行時フォルトの処理

17.5.4.1 フォルト・ポリシー・ファイルに定義された実行時フォルトの処理

フォルト・ポリシーxmlファイルに定義された各実行時フォルトに対して、BPELには1つのcatchブロックがあります。catchブロックで、捕捉したフォルトを再スローします。これによって、Oracle Enterprise Managerコンソールにプロセスがフォルトとして表示されるようになります。

17.5.4.2 フォルト・ポリシー・ファイルに定義されていない実行時フォルトの処理

また、各BPELプロセスには、catchブロックでは捕捉されない、フォルト・ポリシー・ファイルに定義されていない実行時フォルトを処理する1つのcatch-allブロックがあります。

catch-allブロックを定義する手順は、次のとおりです。

1. Oracle AIAフォルト・メッセージを作成します。例17-13に示すように、AIAフォルト・メッセージにECIDを入力します。

2. このOracle AIAフォルト・メッセージを入力として使用してAIAAsyncErrorHandlingBPELProcessを呼び出します。

3. AIAフォルト・メッセージをスローします。これによって、Oracle Enterprise Managerコンソールにプロセスがフォルトとして表示されるようになります。

4. これらのcatchおよびcatch-allブロックは最上位レベルのスコープに定義できるため、特に必要な場合を除いて、各パートナ・リンクのスコープに定義する必要はありません。

詳細は、『Oracle SOAスイートでのSOAアプリケーションの開発』を参照してください。

例17-13 ECIDが定義されているAIAフォルト・メッセージ

<copy>
<from expression="ora:getECID()"/>
<to variable="AIAFaultMessage" part="AIAFault" query="/corecom:Fault/corecom:
FaultNotification/corecom:FaultingService/corecom:ExecutionContextID"/>
</copy>

17.5.5 フォルト・ポリシーを定義するためのガイドライン

詳細は、「実行時フォルトを処理するためのフォルト・ポリシーXMLファイルの定義」を参照してください。

17.5.6 未発行ロールバック・メッセージに対するフォルト・ポリシーの構成

保証付きメッセージ配信プログラミング・モデルに従ってメッセージをグローバル・トランザクションのフローのサービスまたはコンポーネントに配信できない場合、そのメッセージは適切なソース・マイルストンにロールバックされます。このソース・マイルストンは、Oracleアドバンスト・キュー、JMSトピックまたはメディエータ・レスポンス・ストアに相当します。メッセージは、サービスまたはコンポーネントに配信するための再発行が可能になるまで、ここに保持されます。

トランザクション・ロールバック・パスに従って、BPELプロセスがフォルト・メッセージを発行しますが、その際、ロールバック・メッセージを発行しないように構成されている必要があります。ロールバック・パスのサービスが不要な通知を発行しないように、構成によってロールバック・トランザクションを解読します。

ロールバック・メッセージを抑制するこの構成がないと、これらのプロセスによって不要な通知が発行されます。たとえば、図17-4に示すトランザクション・ロールバック・フローでは、リクエスタABCSによって冗長なロールバック通知が送信されることに加え、単に1回発行する必要があるその通知がプロバイダABCSからも送信されることになります。

図17-4 トランザクション・ロールバック・フロー

ロールバック・トランザクションでの不要な通知を抑制する手順は、次のとおりです。

- catchブロックでスローするかわりに、bpelx:rollbackを使用します(<throw name="ThrowEBSFault" faultName="bpelx:rollback"/>)。

- 例17-15に示すように、Javaスニペットを使用してOracle AIAエラー・ハンドラを呼び出します。

- トランザクション・ロールバック・フローに沿って、メディエータおよびBPELプロセスのフォルト・ポリシーに空のno-opアクションを追加します。この空のno-opアクションはaia-no-actionです。

メディエータまたはBPELプロセスがロールバック・メッセージを受信すると、制御は、aia-no-actionアクションに対して実装されたoracle.apps.aia.core.eh.CompositeJavaNoActionというクラスに移動します。

oracle.apps.aia.core.eh.CompositeJavaNoActionクラスは空の操作で、何も実行せずにロールバック・フローの以降の通知を抑制することを意味します。

次のサンプルBPELおよびメディエータのフォルト・ポリシーは、これらの条件を影響を受けるフォルト・ポリシー・ファイルに定義する方法を示しています。

aia-no-actionフォルト・ポリシーにはフィルタ式があり、ロールバック・フォルトORABPEL-02180の場合は、アクションなしを実行します。例17-14に例を示します。

例17-14 Oracle AIAエラー・ハンドラを呼び出すJavaスニペット

<?xml version="1.0" encoding="UTF-8"?>
<faultPolicy version="2.0.1" id="SamplesCreateCustomerPartyPortal
ProvABCSImplFaultPolicy" xmlns:env="http://schemas.xmlsoap.org/soap/
envelope/" xmlns:xs="http://www.w3.org/2001/XMLSchema"xmlns="http://schemas.
oracle.com/bpel/faultpolicy"xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance">
<Conditions>
<faultNamexmlns:plmfault="http://xmlns.oracle.com/EnterpriseServices
/Core/CustomerParty/V2" name="plmfault:fault">
<condition>
<test>$fault.summary/summary[contains(., "ORABPEL-02180")]</test>
<action ref="aia-do-nothing"/>
</condition>
<condition>
<action ref="aia-ora-java"/>
</condition>
</faultName>
<faultName>
<condition>
<test>$fault.summary/summary[contains(., "ORABPEL-02180")]</test>
<action ref="aia-do-nothing"/>
</condition>
<condition>
<action ref="aia-ora-java"/>
</condition>
</faultName>
</Conditions>
<Actions>
<!--  This action will attempt 8 retries at increasing intervals of
2, 4, 8, 16, 32, 64, 128, and 256 seconds. -->
<Action id="aia-ora-retry">
<retry>
<retryCount>1</retryCount>
<retryInterval>2</retryInterval>
<exponentialBackoff/>
<retryFailureAction ref="aia-ora-java"/>
<retrySuccessAction ref="aia-ora-java"/>
</retry>
</Action>
<!--  This is an action will cause a replay scope fault -->
<Action id="ora-replay-scope">
<replayScope/>
</Action>
<!-- This is an action will bubble up the fault  -->
<Action id="ora-rethrow-fault">
<rethrowFault/>
</Action>
<!-- This is an action will mark the work item to be "pending recovery
from console" -->
<Action id="ora-human-intervention">
<humanIntervention/>
</Action>
<!--  This action will cause the instance to terminate  -->
<Action id="ora-terminate">
<abort/>
</Action>
<Action id="aia-do-nothing">
<javaAction className="oracle.apps.aia.core.eh.CompositeJavaNo
Action" defaultAction="ora-rethrow-fault">
<returnValue value="REPLAY" ref="ora-terminate"/>
<returnValue value="RETRHOW" ref="ora-rethrow-fault"/>
<returnValue value="ABORT" ref="ora-terminate"/>
<returnValue value="RETRY" ref="aia-ora-retry"/>
<returnValue value="MANUAL" ref="ora-human-intervention"/>
</javaAction>
</Action>
<Action id="aia-ora-java">
<javaAction className="oracle.apps.aia.core.eh.CompositeJava
Action" defaultAction="ora-rethrow-fault">
<returnValue value="REPLAY" ref="ora-terminate"/>
<returnValue value="RETRHOW" ref="ora-rethrow-fault"/>
<returnValue value="ABORT" ref="ora-terminate"/>
<returnValue value="RETRY" ref="aia-ora-retry"/>
<returnValue value="MANUAL" ref="ora-human-intervention"/>
</javaAction>
</Action>
</Actions>
</faultPolicy>

例17-15 no-opアクションaia-no-actionを使用するサンプル・フォルト・ポリシー

<bpelx:exec name="Java_Embedding_1" language="java" version="1.5">
<![CDATA[ oracle.apps.aia.core.eh.InvokeBusinessErrorHandler.process
((oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable",
"FaultMessage","/ns1:Fault"));]]>
</bpelx:exec>

17.5.7 メッセージ再発行ユーティリティAPIの使用

メッセージ再発行ユーティリティAPIでは、エラー状態のメッセージを有効にして再度トランザクションに使用できるようにする機能を使用するための外部プログラムを有効化します。通常、このユーティリティは、メッセージがエラーで終了する原因となった関連する問題が修正された後に実行されます。

17.6 通知のためのAIAサービスの構成方法

この項では、BPELフォルトを処理する際に実行する必要がある標準的な構成ステップについて説明します。

この項には次のトピックが含まれます:

- 修正処理コードの定義

- エラー・メッセージ・コードの定義

通知ロールの定義方法の詳細は、Oracle Fusion Middleware Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイド リリース11.1.1.9のエラー処理の設定に関する項を参照してください。

17.6.1 修正処理コードの定義

カスタム・フォルトまたはビジネス・フォルト(throwアクティビティでスローされたビジネス・フォルト)の場合は、<MW_HOME>/soa/modules/oracle.soa.ext_11.1.1/classesフォルダにあるAIAMessages.propertiesファイルにコードを追加し、サーバーを再起動することで、修正処理コードを定義します。翻訳された文字列が、その言語が配置されている同じディレクトリの言語に適したプロパティ・ファイルに格納されていることを確認します。

このカスタムXPath関数を使用して、このリソース・バンドルから詳細をローカライズされた形式: Signature: aia:getCorrectiveAction (String key, String locale, String delimiter)で取得できます。

パラメータ詳細には、次の情報が含まれます。

- Key
修正処理コード。

- Locale
言語コード、国コードおよびバリアントの連結した文字列。例: en-US。

- Delimiter
localeパラメータに使用するデリミタ(-など)。

17.6.2 エラー・メッセージ・コードの定義

カスタム・フォルトまたはビジネス・フォルト(throwアクティビティでスローされたビジネス・フォルト)の場合は、<MW_HOME>/soa/modules/oracle.soa.ext_11.1.1/classesフォルダにあるAIAMessages.propertiesファイルにコードを追加し、サーバーを再起動することで、修正処理コードを定義します。翻訳された文字列が、その言語が配置されている同じディレクトリの言語に適したプロパティ・ファイルに格納されていることを確認します。

このカスタムXPath関数を使用して、このリソース・バンドルから詳細をローカライズされた形式: Signature: aia:getErrorMessage (String key, String locale, String delimiter)で取得できます。

パラメータ詳細には、次の情報が含まれます。

- Key
修正処理コード。

- Locale
言語コード、国コードおよびバリアントの連結した文字列(例: en-US)。

- Delimiter
localeパラメータに使用するデリミタ(-など)。

17.7 Oracle AIAフォルト・メッセージ・スキーマの説明

この項には次のトピックが含まれます:

- EBMReference要素の説明

- B2BMReference要素の説明

- FaultNotification要素の説明

このスキーマの最上位レベルの要素はFaultです。図17-5および図17-6に示すように、EBMReference、B2BMReferenceおよびFaultNotificationの3つの要素があります。Faultの要素は、表17-1で説明します。

図17-5 Fault要素とその子要素(1/2)

図17-6 Fault要素とその子要素(2/2)

表17-1 Faultの要素

名前

目的

詳細

EBMReference

フォルト・インスタンスに関するコンテキスト情報を提供します。すべての値は、失敗したサービス・インスタンスのEBMのEBMヘッダーから取得されます。

詳細は、「EBMReference要素の説明」を参照してください。

B2BMReference

Oracle AIAからのB2Bフローにエラーがある場合に、企業間(B2B)固有の詳細を提供します。

詳細は、「B2BMReference要素の説明」を参照してください。

FaultNotification

フォルトの実際の詳細を提供します。

詳細は、「FaultNotification要素の説明」を参照してください。

17.7.1 EBMReference要素の説明

この項では、図17-7に示すような、Oracle AIAフォルト・メッセージ・スキーマのEBMReference要素について詳細に説明します。EBM参照の要素は、表17-2で説明します。

図17-7 EBMReference要素とその子要素

表17-2 EBMReferenceの要素

名前

目的

EBMID

メッセージのEBMIDを提供します。

EBMName

メッセージのEBMNameを提供します。

EBOName

メッセージのEBONameを提供します。

VerbCode

メッセージのVerbCodeを提供します。

BusinessScopeReference

メッセージのBusinessScopeReferenceを提供します。

失敗したサービス・インスタンスが関連していたエンドツーエンド・シナリオについて詳細を提供します。

これは、BusinessScopeTypeCodeとBusinessProcessが等しいBusinessScopeReferenceのインスタンスです。

SenderReference

メッセージのSenderReferenceを提供します。

これらの要素の詳細は、「EBMヘッダー概念の概要」を参照してください。

17.7.2 B2BMReference要素の説明

この項では、図17-8に示すような、Oracle AIAフォルト・メッセージ・スキーマのB2BMReference要素について詳細に説明します。B2BM参照の要素は、表17-3で説明します。

図17-8 B2BMReference要素とその子要素

表17-3 B2BMReferenceの要素

名前

目的

詳細

B2BMID

Oracle B2Bのトランザクションの識別に使用されるメッセージIDを提供します。

ユーザーはこのメッセージIDを使用して、Oracle B2Bで失敗したビジネス・メッセージを問い合せ、失敗したトランザクションを再試行できます。

「AIAを使用したB2B統合の概要」を参照してください。

CollaborationID

同じビジネス・トランザクションに関連する複数のリクエスト/レスポンス・メッセージにわたって共通のコラボレーションIDを提供します。

「AIAを使用したB2B統合の概要」を参照してください。

ReplyToMessageID

返信先メッセージのIDを提供します。

「AIAを使用したB2B統合の概要」を参照してください。

B2BDocumentType/TypeCode

Oracle B2Bで失敗したトランザクションのドキュメント・タイプを提供します。

このフォルトからの情報を使用して、ドキュメント・タイプ固有のエラー処理を定義できます。たとえば、様々なドキュメント・タイプのエラー結果を解決するために異なるユーザーに割り当てることができます。

「AIAを使用したB2B統合の概要」を参照してください。

B2BDocumentType/Version

Oracle B2Bで失敗したトランザクションのドキュメント・タイプ・バージョンを提供します。

「AIAを使用したB2B統合の概要」を参照してください。

SenderTradingPartner/TradingPartnerID

B2Bフローの送信側取引パートナ名を提供します。

「AIAを使用したB2B統合の概要」を参照してください。

ReceiverTradingPartner/TradingPartnerID

B2Bフローの受信側取引パートナ名を提供します。

「AIAを使用したB2B統合の概要」を参照してください。

GatewayID

フローの開始に使用されたB2Bソフトウェアの名前を提供します(例: Oracle B2B)。

「AIAを使用したB2B統合の概要」を参照してください。

17.7.3 FaultNotification要素の説明

この項には次のトピックが含まれます:

- FaultMessage要素

- IntermediateMessageHopの要素

- FaultingService要素

この項では、図17-9に示すような、Oracle AIAフォルト・メッセージ・スキーマのFaultNotification要素について詳細に説明します。フォルト通知の要素は、表17-4で説明します。

図17-9 FaultNotification要素とその子要素

表17-4 FaultNotificationの要素

名前

目的

詳細

BusinessComponentID

アプリケーションの一意キー。

オブジェクト・インスタンスの非依存の表現を提供します。

ReportingDateTime

サービスが失敗となった日時を提供します。

サービスが失敗となった日時。

CorrectiveAction

失敗に対して考えられる修正処理を提供します。

失敗に対する修正処理。

FaultMessage

実際のフォルト・メッセージの詳細を提供します。

詳細は、「FaultMessage要素」を参照してください。

FaultingService

フォルト処理サービスの詳細を提供します。

詳細は、「FaultMessage要素」を参照してください。

17.7.3.1 FaultMessage要素

表17-5に、フォルト・メッセージの要素を示します。

表17-5 FaultMessageの要素

名前

目的

詳細

コード

エラー・コードを提供します。

受信したフォルト・コードです。

Text

エラーの詳細を提供します。

フォルトの詳細な記述です。

Severity

エラーの重大度を提供します。

整数で表現したフォルトの重大度です。

Stack

エラー・スタックを提供します。

完全なフォルト・スタックです。

ApplicationFaultData

あらゆる種類のXML入力を受け入れるようにフォルト・メッセージを拡張可能にします。

実装シナリオで決定されたとおりに、あらゆる種類のXML入力を格納するようにフォルト・メッセージを拡張可能にします。

フォルト・メッセージの拡張の詳細は、「フォルト・メッセージの拡張」を参照してください。

IntermediateMessageHop

マルチホップ・トランザクションのメッセージに固有のプロパティを取得します。

ここに取得されたプロパティを使用して、保証付きメッセージ配信およびメッセージ・リカバリを実装するユースケ－スをサポートできます。

保証付きメッセージ配信およびメッセージ・リカバリの実装の詳細は、「保証付きメッセージ配信を確保するための非同期メッセージ交換パターンに対するエラー処理およびリカバリの実装」を参照してください。

17.7.3.2 IntermediateMessageHop要素

図17-10に、IntermediateMessageHopの要素を示します。中間メッセージ・ホップの要素は、表17-6で説明します。

図17-10 IntermediateMessageHopの要素

表17-6 IntermediateMessageHopの要素

名前

目的

詳細

SenderResourceTypeCode

マルチホッピング・メッセージング・レイヤーで、このメッセージの送信者であるリソースまたはシステムのタイプを格納するために使用されます。

この要素の値の例として、Queue、Topic、Resequence Storeなどがあります。

SenderResourceID

SenderResourceTypeCodeに関連付けられたリソースまたはシステムの識別を提供します。

SenderResourceTypeCodeに関連付けられたリソースまたはシステムの識別。

SenderMessageID

SenderResourceTypeCodeに関連付けられたリソースまたはシステムに応じたメッセージ識別を提供します。

SenderResourceTypeCodeに関連付けられたリソースまたはシステムに応じたメッセージ識別。

17.7.3.3 FaultingService要素

表17-7に、FaultingService要素を示します。

表17-7 FaultingService要素

名前

目的

詳細

ID

サービスが失敗となった日時を提供します。

フォルト処理サービスの名前です。

ImplementationCode

失敗に対して考えられる修正処理を提供します。

失敗したサービスのタイプを説明する文字列です。可能な値は、BPEL、JAVAおよびOTHERです。

InstanceID

実際のフォルト・メッセージの詳細を提供します。

失敗したサービスのインスタンスIDです。サービスがBPELプロセスの場合、これはBPELインスタンスIDです。

ExecutionContextID

ECIDの値を提供します。

サービスの呼出し/実行のグループに対して生成されたIDです。

17.8 フォルト・メッセージの拡張

この項には次のトピックが含まれます:

- フォルト・メッセージの拡張の概要

- フォルト・メッセージの拡張

17.8.1 フォルト・メッセージの拡張の概要

統合フロー、メディエータ・サービスまたはBPELプロセス内でエラーが発生すると、エラー処理フレームワークによってフォルト・メッセージからエラーが取得されます。フォルト・メッセージは、Oracle BPM Worklist内のエラー詳細で使用可能になります。

フォルト・メッセージの内容は、Meta.xsd (\EnterpriseObjectLibrary\Infrastructure\V1\Meta.xsd)のFaultTypeメッセージ・スキーマ定義で定義されます。スキーマのデフォルトの要素ではフォルト・メッセージの要件を満たさない場合は、スキーマに格納されたApplicationFaultMessage要素を使用して、メッセージに取得されるフォルト詳細の範囲を拡張できます。

フォルト・メッセージ・スキーマの詳細は、「Oracle AIAフォルト・メッセージ・スキーマの説明」を参照してください。

フォルト詳細を拡張すると、統合フローのコンシューマがフォルトの状況についてさらに理解でき、より効果的なエラーの解決を導く上で役立つ機能的に豊富な情報をフォルト・メッセージに追加できるようになります。同様に、この追加のフォルト詳細を使用して、拡張されたエラー処理機能を使用可能にできます。

エラー処理の拡張の詳細は、「エラー処理の拡張」を参照してください。

たとえば、オーダー・フォールアウト管理アプリケーションでオーダー表を更新し、新規のサービス・リクエストを作成する拡張エラー処理タスクの実行に必要なオーダー番号と履行システムの値を使用してフォルト・メッセージをエンリッチできます。

17.8.2 フォルト・メッセージの拡張

フォルト・メッセージの拡張には、Meta.xsdのFaultTypeメッセージ・スキーマ定義にあるxsd:anyTypeタイプのApplicationFaultData要素(図17-11で強調表示)を使用します。

図17-11 Meta.xsdで強調表示されたApplicationFaultData要素

ApplicationFaultData要素は、BPELフォルトの場合にエラー処理フレームワークによって実行時に呼び出されるように構成したフォルト拡張ハンドラによって入力されます。

フォルト拡張ハンドラに対する入力は、デフォルトのフォルト・メッセージです。フォルト拡張ハンドラは、ApplicationFaultData要素に定義された追加の内容を使用してフォルト・メッセージをエンリッチします。エンリッチされたフォルト・メッセージの制御は、フォルト拡張ハンドラからエラー処理フレームワークに移動し、処理をさらに進行するために、フォルト・メッセージはOracle AIAの共通エラー・ハンドラに渡されます。

フォルト・メッセージを拡張する手順は、次のとおりです。

1. フォルト・メッセージをエンリッチする際に呼び出すフォルト拡張ハンドラを作成します。

2. 「エラー通知」ページの「エラー拡張ハンドラ」フィールドに、フォルト・メッセージを拡張する際に呼び出すエラー拡張ハンドラの名前を入力します。たとえば、オーダー・フォールアウトのエラー拡張ハンドラにはORDERFOEH_EXTと入力します。
エラー処理フレームワークによって、エラー・コード、システム・コード、サービス名およびプロセス名パラメータの組合せに基づいて、エラー拡張ハンドラにデフォルトでないパラメータが定義されているかどうかが判断されます。

存在する場合は、AIAConfigurationProperties.xmlファイルのパラメータの完全なクラスパスが検索され、基本のフォルト・メッセージを入力として使用して、そのハンドラに対するコールアウトが作成されます。

このエラー拡張ハンドラで、フォルト・メッセージが特別な内容に対応するようにエンリッチされます。その後、処理をさらに進行するためにエラー処理フレームワークに返されます。

「エラー通知」ページの詳細は、Oracle Fusion Middleware Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイド リリース11.1.1.9のAIAエラー処理構成詳細の設定方法に関する項を参照してください。

3. $AIA_HOME/aia_instances/$INSTANCE_NAME/AIAMetaData/configのAIAConfigurationProperties.xmlファイルにアクセスします。図17-12に示すように、ステップ2で定義したエラー拡張ハンドラ名と一致するプロパティ名を定義します。このプロパティの値は、ハンドラの完全修飾クラスパスです。

図17-12 AIAConfigurationProperties.xmlのエラー拡張ハンドラ・プロパティと値の例

このクラスを介して、Meta.xsdのApplicationFaultData要素のxsd:anyTypeを使用して拡張機能(たとえば、オーダー番号および履行システムの値)がフォルト・メッセージに追加されます。

4. AIAConfigurationProperties.xmlに登録されたエラー拡張ハンドラ・クラスにIAIAErrorHandlerExtensionインタフェースを実装します。次のメソッドを実装します。

- BPELシステム・エラーに対するhandleCompositeSystemError

- BPELカスタム・エラーに対するhandleBusinessError

例17-16および例17-17に、インタフェース構造を示します。

Oracle Enterprise Managerでアクセスされたエラー・ログに拡張フィールド値を表示できます。

適切に構成されている場合は、電子メール通知に表示することもできます。

例17-16 IAIAErrorHandlerインタフェース・クラス

public interface IAIAErrorHandler
{
/**
*
* @param ebmHeader
* @param faultMessage
*/
public void logErrorMessage(Element ebmHeader, String faultMessage);

/**
*
* @param XMLELfaultMessage
*/
public void logErrorMessage(XMLElement XMLELfaultMessage);

/**
*
* @param ebmHeader
* @param faultMessage
*/
public void logErrorMessage(Node ebmHeader, String faultMessage);

/**
* @since FP 2.3
* @param faultMessage
* @param jmsCorrelationID
*/
public void sendNotification(String faultMessage, String jmsCorrelationID,
HashMap compositeDetailsHM);
}

例17-17 IAIAErrorHandlerExtensionインタフェース・クラス

package oracle.apps.aia.core.eh;
public interface IAIAErrorHandlerExtension
{
/**
*
* @param iFaultRecoveryContext
* @param faultMessageConstructed
* @param componentType
* @return
*/
public String handleCompositeSystemError(IFaultRecoveryContext iFaultRecoveryContext,
String faultMessageConstructed,
String componentType);

/**
*
* @param faultMessageConstructed
* @return
*/
public String handleBusinessError(String faultMessageConstructed);
}

17.9 エラー処理の拡張

この項には次のトピックが含まれます:

- エラー処理の拡張の概要

- エラー処理の拡張機能の実装

この項では、エラー処理拡張機能の概要を示し、エラー処理拡張機能の実装方法について説明します。

17.9.1 エラー処理の拡張の概要

BPELおよびメディエータのエラーに対するデフォルトのエラー処理動作では、フォルト・メッセージはOracle AIA共通のエラー・ハンドラにルーティングされ、このエラー・ハンドラがエラーをログに記録し、フォルト・メッセージをOracle AIAエラー・トピックに配信します。デフォルトのOracle AIAエラー・リスナーは、このOracle AIAエラー・トピックをサブスクライブし、フォルト・メッセージを選択してエラー通知プロセスをコールし、そのエラー通知プロセスがOracle BPM Worklistに通知を発行します(発行するように構成されている場合)。

エラー処理フレームワークを拡張して、そのデフォルトの動作を超えるアクションを実行できます。

たとえば、表の更新やアプリケーションでの新規リクエストの作成などの拡張されたエラー処理動作に加え、特定のエラーにはデフォルトのエラー処理動作をトリガーする必要があります。

エラー処理拡張機能を実装するには、フォルト・メッセージを拡張して追加の値を用意します。

フォルト・メッセージの拡張の詳細は、「フォルト・メッセージの拡張」を参照してください。

17.9.2 エラー処理の拡張機能の実装

エラー処理の拡張機能を実装する手順は、次のとおりです。

1. 「エラー通知」ページで、エラー・コード、システム・コード、プロセス名およびサービス名の値を組み合せて「エラー・タイプ」フィールドに値を入力します。
エラー処理フレームワークでは、「エラー・タイプ」の値を使用してJMSCorrelationID JMSヘッダーにスタンプを付けます。JMSCorrelationIDは、カスタム・エラー処理が必要なフォルト・メッセージを識別するためにカスタム・エラー・リスナーによって使用されます。

2. Oracle AIAエラー・トピックをサブスクライブするエラー拡張リスナーを実装します。
ステップ1で作成したエラー・タイプによって定義されたJMSヘッダーのJMSCorrelationID値に基づいて、フォルト・メッセージをフィルタ処理するエラー拡張リスナーを構成します。

たとえば、ORDER_FOというJMSCorrelationID値を使用してフォルト・メッセージを選択するオーダー・フォールアウト・エラー拡張リスナーを作成できます。この例では、ステップ1の「エラー通知」ページで定義した「エラー・タイプ」フィールドの値がORDER_FOです。

次に、オーダー・フォールアウト・エラー拡張リスナーは、たとえば、オーダー番号および履行システムの値が含まれるように拡張されたフォルト・メッセージから値を抽出できます。その後、エラー拡張リスナーは、たとえば、オーダー・フォールアウト管理アプリケーションにその値を渡し、アプリケーションがその値を使用してオーダー表を更新し、新規サービス・リクエストを作成できます。

図17-13に、拡張エラー処理フローを示します。

図17-13 拡張エラー処理フローとデフォルトのエラー処理フローのサンプル

17.10 トレース・ロギングのためのOracle AIAプロセスの構成

この項には次のトピックが含まれます:

- isTraceLoggingEnabledカスタムXPath関数の詳細の説明

- logTraceMessageカスタムXPath関数の詳細の説明

- トレース・ロギングJava APIの説明

次のカスタムXPathトレース・ロギング関数は、Oracle AIAエコシステムで機能しているBPELおよびメディエータ・サービスの操作に使用できます。

- aia:isTraceLoggingEnabled(String logLevel, String processName)
トレース・ロギングがサービスに対して有効か、システム・レベル全体で有効かを決定します。

- aia:logTraceMessage(String level, Element ebmHeader, String message)
実際のトレース・ログを生成します。

BPELまたはメディエータ・プロセスの開発時には、常にaia:isTraceLoggingEnabled()関数を最初にコールします。trueの結果が返された場合に、aia:logTraceMessage()関数をコールします。

これらのログ・ファイルは、<aia.home>/logs/ディレクトリに保存されます。

アプリケーション開発者がトレース・メッセージをログに記録できるように、これらのカスタムXPath関数に加え、Java APIも使用できます。

トレース・ログの使用の詳細は、Oracle Fusion Middleware Oracle Application Integration Architecture Foundation Packインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイド リリース11.1.1.9のトレースおよびエラー・ログの使用に関する項を参照してください。

17.10.1 isTraceLoggingEnabledカスタムXPath関数の詳細の説明

isLoggingEnabledカスタムXPath関数は、ブール値の結果を返すユーティリティ関数です。関数シグネチャは、aia:isTraceLoggingEnabled (String logLevel, String processName)です。

パラメータの詳細を示します。

- logLevel
可能な値は次のとおりです。

- Severe

- Warning

- Info

- Config

- Fine

- Finer

- Finest

- processName
この関数を使用するOracle AIAサービスの名前。

17.10.2 logTraceMessageカスタムXPath関数の詳細の説明

logTraceMessageカスタムXPath関数は、トレース・ログに含めるメッセージの詳細が格納されたトレース・メッセージを生成します。

この関数は、EBMヘッダーおよび冗長なロギング・メッセージをパラメータとして受け入れます。EBMヘッダーから様々な要素を使用してログ・メッセージに追加属性の値が入力されます。EBMヘッダーが渡されなかった場合、これらの追加属性は空の文字列として設定されます。

関数シグネチャはaia:logTraceMessage (String level, Element ebmHeader, String message)です。パラメータの詳細を示します。

- level
可能な値は次のとおりです。

- Severe

- Warning

- Info

- Config

- Fine

- Finer

- Finest

- ebmHeader
EBMヘッダー。

- message
ログに記録する冗長なテキスト・メッセージ。

17.10.3 トレース・ロギングJava APIの説明

アプリケーション開発者がトレース・メッセージをログに記録できるように、isTraceLoggingEnabledおよびlogTraceMessageカスタムXPath関数に加え、トレース・ロギングJava APIも使用できます。これらの関数は、トレース・ロギングJava APIを介して使用できます。

関数シグネチャの1つとして、AIALogger.isTraceLoggingEnabled (String logLevel, String processName)があります。この関数は、トレース・ロギングがサービスに対して有効か、システム・レベル全体で有効かを決定します。パラメータの詳細を示します。

- logLevel
可能な値は次のとおりです。

- Severe

- Warning

- Info

- Config

- Fine

- Finer

- Finest

- processName
この関数を使用するOracle AIAサービスの名前。

もう1つの関数シグネチャは、AIALogger.logTraceMessage (String level, Element ebmHeader, String message)です。この関数は実際のトレース・ログを生成します。パラメータの詳細を示します。

- level
可能な値は次のとおりです。

- Severe

- Warning

- Info

- Config

- Fine

- Finer

- Finest

- ebmHeader
EBMヘッダー。

- message
ログに記録する冗長なテキスト・メッセージ。

18 AIA設計パターンの使用

この章では、AIAメッセージ処理パターン、AIAアセット一元化パターン、AIAアセット拡張性パターンの概要を説明します。

注意:

コンポジット・ビジネス・プロセス(CBP)は、次のリリースから非推奨となります。人間/システム相互作用のモデル化には、BPMの使用をお薦めします。

この章の内容は次のとおりです。

- AIAメッセージ処理パターン

- AIAアセット一元化パターン

- AIAアセット拡張性パターン

18.1 AIAメッセージ処理パターン

この項では、AIAメッセージ処理パターンについて説明し、発生する可能性がある特定の問題のソリューションを提供します。

この項には次のトピックが含まれます:

- 同期リクエスト/リプライ・パターン: AIAでの同期レスポンスの取得方法

- 非同期ファイア・アンド・フォーゲット・パターン

- 保証付き配信パターン: AIAでの保証付き配信の確保方法

- サービス・ルーティング・パターン: AIAでの適切なサービス・プロバイダへのメッセージのルーティング方法

- 競合コンシューマ・パターン: 並列性および効率を改善するための複数コンシューマの使用方法

- 非同期遅延レスポンス・パターン: 同期通信が適切でない状況でのリクエスタに対するサービス・プロバイダの通信方法

- 非同期リクエスト/レスポンス・パターン: サービス・プロバイダによるリクエスタに関連するエラーの通知方法

18.1.1 同期リクエスト/リプライ・パターン: AIAでの同期レスポンスの取得方法

問題

コンシューマがサービス・プロバイダにリクエストを同期的に送信し、各リクエストに対するレスポンスを即時に取得することは、多くのユースケースによって正当化されています。これらのユースケースでは、コンシューマは、レスポンスを受信するまで待機してから次のタスクに進む必要があります。

たとえば、顧客関係管理(CRM)アプリケーションでは、勘定残高の取得、与信チェック、ATP(有効在庫)計算などのタスクを実行するために、顧客サービス担当およびシステムからプロバイダにリクエストを送信可能にするなどの機能が提供されます。CRMアプリケーションでは、レスポンスが後続のタスクで使用されることを想定しているため、レスポンスが受信されるまで、ユーザーがその他のタスクを実行できないようにします。

ソリューション

バックエンド・システムの処理または接続を必要とするすべてのコンポジットで、同期リクエスト/レスポンス・サービス・インタフェースを使用することをお薦めします。問合せ処理に関係するサービスにはシングルトン・サービスを挿入できません。一般的には、すべての仲介サービス、およびプロバイダ・アプリケーションによって公開されたサービスに対して、リクエスト/レスポンス・ベース(双方向操作)のインタフェースを実装することをお薦めします。初期コール元を除くすべてのサービスで2つの一方向リクエストを実装するような設計が技術的に可能であっても、回避できる場合はこの実装テクニックを使用しないでください。

状態情報(デハイドレーション)または監査詳細が、いずれかの仲介サービスまたは最終サービス・プロバイダによって永続的に確保されることがない実装を目指してください。これらのテクニックは、待機を可能なかぎり短くするのに役立ちます。

また、SOAPドキュメントのマーシャリングおよびアンマーシャリングによって通常発生するオーバーヘッドを解消するために、仲介サービスを同一の場所に配置することをお薦めします。

図18-1に、リクエスタ・アプリケーションによって、エンタープライズ・ビジネス・サービス(EBS)として実装されたタスクが同期的に呼び出される様子を示します。

図18-1 リクエスタ・アプリケーションによるEBSの同期呼出し

影響

- サービス・プロバイダからのレスポンスが送信元システムまたはユーザーに返るまで、すべてのリソースがロックされます。

- いずれかのサービスまたは参加アプリケーションで処理に時間がかかる場合は、トランザクション・タイムアウトまたは長時間の待機になる可能性があります。

- サービス・プロバイダが常に対応可能で、サービス・リクエストの遂行準備が整っている必要があります。

- サービス・プロバイダがレスポンス・メッセージを生成するために複数のバックエンド・システムからデータのリアルタイム取得および照合を実行すると、全体としてリソースに大きな犠牲が生じたり、待機時間が増加する可能性があります。同期リクエスト/レスポンス設計パターンは、複雑なリアルタイム処理を伴うタスクの実装には使用しないでください。負荷のかからない処理を実行する必要があります。リアルタイム処理を可能なかぎり軽量化できるように、ある程度準備されたデータのステージングに対応するように設計を変更する必要があります。

- 同期リクエスト/レスポンス・パターンに関係するサービスでは、リクエスト・メッセージに存在する繰返し可能な各子ノードに対する処理の実行を抑制してください。本番環境のペイロードに多数の子ノードがあると、システムに悪影響を与える可能性があります。

18.1.2 非同期ファイア・アンド・フォーゲット・パターン

問題

リクエスタ・アプリケーションは、タスクを実行する必要があるサービス・プロバイダが即時に対応可能な状態かどうかに関係なく、リクエストの発行後にその処理を続行できる必要があります。さらに、リクエストを開始するユーザーには、リクエストが完全に処理されるまで待機する必要性は機能的にもありません。つまり、サービス・リクエスタおよびサービス・プロバイダには、相互に直接依存せずに独自のペースで提供するメッセージを作成および使用する機能が必要です。

また、コンポジット・ビジネス・プロセスでは、参加アプリケーションまたはAIA機能プロセス・フローに依存せずに、分離された方法でエラー処理サービスやビジネス・アクティビティ監視サービスなどのインフラストラクチャ・サービスをサポートできる必要があります。

たとえば、注文獲得アプリケーションでは、注文履行システムなどのバックエンド・システムがその時点で使用可能かどうかに関係なく、注文に対応できる必要があります。注文履行プロセスの実行に参加しているなんらかのサービスまたはアプリケーションが有効な状態でないために、注文獲得機能が停止することは望まれません。

ソリューション

データベースまたはファイルを永続ストアとして設定したキューイング・テクノロジを使用するファイア・アンド・フォーゲット・パターンによって、参加アプリケーションを統合レイヤーから分離することをお薦めします。キューは、リクエスタ・アプリケーションがリクエスト・メッセージを配置できるステージング領域として機能します。その後、サービス・プロバイダの処理準備が整っている場合は、リクエスト・メッセージをサービス・プロバイダにリクエスタにかわって転送します。

リクエスト・メッセージをキューにエンキューする場合は、その処理を実行するリクエスタ・アプリケーションによって開始された同じトランザクション内で実行することをお薦めします。これによって、リクエスト・メッセージは、参加アプリケーションのトランザクションが正常に実行された場合にのみ、キューにエンキューされるようになります。トランザクションが正常に実行されていない状況では、リクエスト・メッセージはエンキューされません。連続する2つのマイルストンの間にあるサービスよって、そのサービス自体が単一のグローバル・トランザクションに登録されることに注意してください。

メッセージの保証付き配信を確保するために、マイルストンが仲介信頼性アーティファクトとしてどのように使用されるかを理解するには、「保証付きメッセージ配信を確保するための非同期メッセージ交換パターンに対するエラー処理およびリカバリの実装」を参照してください。

ビジネス・オブジェクトごとにキューを用意することをお薦めします。1つのビジネス・オブジェクトのリクエスタ・アプリケーションで発生するすべてのリクエストで同じキューを使用します。

図18-2に、ソース・アプリケーションを統合レイヤーから分離する際にJMSキューが使用される様子を示します。ソース・アプリケーションは、JMSキューにメッセージを発行し、統合レイヤーからのレスポンスを待機せずに、他の処理を続行します。

JMSキュー内のアプリケーションがメッセージの作成を続行している間、AIAコンポジット・ビジネス・プロセスは起動および実行されません。AIAコンポジット・ビジネス・プロセスが起動すると、メッセージの使用が開始され、メッセージが処理されます。

また、図18-2に、JMSキューを利用して主要なAIA機能フローから監視サービスを分離する方法を示します。すべてのAIAサービスおよび参加アプリケーションは、監視メッセージをキューに発行して、それがダウンストリーム・アプリケーションでどのように処理されるかについては関知しません。このパターンでは、サービスまたは参加アプリケーションはレスポンスを期待しません。同様に、AIAインフラストラクチャ・サービスは、コンポジット・ビジネス・プロセスからシステム・エラーまたはビジネス・エラーを取得してAIAエラー・トピックに公開し、これをエラー・ハンドリング・フレームワークが使用して、その後の処理(再発行、通知、ロギングなど)を実行します。

図18-2 キューイング・テクノロジを使用したファイア・アンド・フォーゲット・パターン

影響

デフォルトの実装には、メッセージの成功または失敗をリクエスタ・アプリケーションに通知するための固有のサポートはありません。ミドルウェア・システムには処理中メッセージ転送の流れを監視して管理する機能が用意されていますが、リクエスタ・アプリケーションが、プログラムによる通知の受信または論理的な逆処理を必要とするユースケースがあります。

このメッセージ交換パターンに対する補正ハンドラの実装方法の詳細は、「アプリケーション・ビジネス・コネクタ・サービスの設計」および「ABCSの作成」を参照してください。

18.1.3 保証付き配信パターン: AIAでの保証付き配信の確保方法

問題

参加システムとそれらのシステムを統合するサービスが信頼性の低い形式で相互作用する場合、メッセージ配信は保証されません。

たとえば、注文獲得システムで、ビジネス・プロセスをトリガーする注文履行リクエストを発行し、リクエストを履行するために複数の異種システムによって提供される各サービスを順番に呼び出します。サービス・プロバイダのすべてが常に使用可能であることを期待するのは現実的ではありません。

ソリューション

マイルストンはメッセージのチェックポイントであり、この論理ポイントで特定量のビジネス機能が完了した後は、エンリッチしたメッセージが保持されるか、そのメッセージをエンドツーエンド・コンポジット・ビジネス・プロセスでさらに処理するように参加アプリケーションに発行されます。マイルストンは、その論理ポイントに対して実行されたビジネス・トランザクションをコミットし、AIAサービスおよび参加アプリケーションで使用されたリソースをリリースするのに役立ちます。

異種システムを統合してビジネス要件に取り組むために、コンポジット・ビジネス・プロセス、ビジネス・アクティビティ・サービスまたはデータ・サービスが設計および実装されたエンドツーエンド統合の適切な論理ポイントにマイルストンを導入することをお薦めします。マイルストンの実装には、データベースまたはファイルを永続ストアとするキューが使用されます。

図18-3に、簡単なユースケースのマイルストンを使用して、保証付き配信を確保する方法を示します。このユースケースでは、カスタマ・サービス担当がソース・アプリケーションで請求プロファイルを更新し、更新されたプロファイルがバックエンド請求システムに反映されます。

図18-3 マイルストンを使用した保証付き配信の確保

メッセージの保証付き配信を確保するために、ソース・アプリケーションがトランザクション・モードで請求プロファイル情報をマイルストン1 (JMSキュー)にプッシュことをお薦めします。このトランザクションは、AIAトランザクションの範囲外にあり、図には表示されていません。マイルストン1への請求プロファイル情報の格納後は、ターゲット・アプリケーションに対するメッセージの保証付き配信が確保されるため、ソース・アプリケーションのリソースをリリースできます。

実装サービスにはメッセージ・エンリッチメント・ロジックがあり(必要な場合)、エンタープライズ・ビジネス・サービス(EBS)は、エンリッチされたメッセージを適切なプロバイダまたはマイルストン2にルーティングします(実装サービスのエンリッチメントや処理の要件がないような、単純でわかりやすいユースケースの場合はオプション)。

エンリッチされたすべてのメッセージは、マイルストン2に転送されるか、修正処理または再発行のためにマイルストン1にロールバックされます。そのためには、マイルストン1とマイルストン2の間にあるすべてのサービスが、単一のグローバル・トランザクションに含まれている必要があります。メッセージがマイルストン2に転送された後、マイルストン1のすべての実装サービス・インスタンスがリリースされ、新規リクエストに対応できるようになります。

プロバイダ実装サービスが請求プロファイル情報を取得し、ターゲット・アプリケーションへのメッセージの配信を確保します。ターゲット・アプリケーションは、マイルストン2とマイルストン3の間のトランザクションへの参加機能に対応している場合も未対応の場合もあるため、補正トランザクションを処理するように実装サービスを設計する必要があります。

ターゲット・アプリケーションでXA機能を作成して、保証付き配信を確保することをお薦めします。ターゲット・アプリケーションにXA機能がない場合は、AIAに付属のビジネス・メッセージに対するターゲット・システムの確認機能に基づいて、手動補正または半自動/自動補正するように実装サービスを設計する必要があります。

図18-4に、ソース・システムがAIAに注文プロビジョニング・リクエストを発行する複雑なユースケースで、保証付き配信を確保するためのマイルストンの使用方法を示します。

図18-4 複雑なユースケースで保証付き配信を確保するためのマイルストンの使用

影響

マイルストンを導入すると、処理オーバーヘッドが加わり、コンポジット・ビジネス・プロセス、ビジネス・アクティビティ・サービスまたはデータ・サービスのパフォーマンスに影響する可能性があります。したがって、マイルストンの数は設計者にとって課題です。しかし、マイルストンを最小にすると、結果的に多くの処理が単一のトランザクションに追加されて悪影響を与える可能性もあります。

保証付き配信を実現するために「マイルストン」間と「アプリケーションとマイルストン」間に信頼できるメッセージングを確保することで、トランザクション・オーバーヘッドは増加します。場合によっては実行時のパフォーマンスに影響する可能性があり(2つのマイルストン間で実行する処理量が非常に多い場合)、補正のための別途のプロセス設計要件が必要になる可能性もあります。

18.1.4 サービス・ルーティング・パターン: AIAでの適切なサービス・プロバイダへのメッセージのルーティング方法

問題

リクエスタ・アプリケーションから特定のターゲット・システムに情報を送信する必要がある場合は、密接に結合されたサービスをリクエスタ・アプリケーションで作成する必要があります。サービス・プロバイダと、場合によってはサービス・プロバイダ・インスタンス(同じプロバイダに対して複数のアプリケーション・インスタンスがある場合)を識別するためのロジックを、コール元サービスのロジックに埋め込む必要があります。新しいサービス・プロバイダがその集合に追加されたり、既存のサービス・プロバイダが集合から撤退されるかぎり、コール元サービスの判断ロジックは常に変更に対応する必要があります。

たとえば、ある顧客に3つの請求システムが実装されており、2つはベンダーAの請求システムに対する2つのインスタンス(北米に居住する顧客専用のインスタンスとアジア太平洋に居住する顧客専用のインスタンス)、もう1つは世界の他の地域に居住する顧客専用のベンダーBの請求システムのインスタンスであるとします。リクエスタ・サービスには、リクエストの委託先を判別するための判断ロジックが必要です。

ソリューション

このメッセージをさらに処理してターゲット・アプリケーションに送信するには、コンテンツ・ベースのサービス・ルーティングで、適切なターゲット・サービスの実装にルーティングすることをお薦めします。実際のリクエスト・アプリケーションまたはサービスから適切なサービス・プロバイダを判断するために、判断ロジックを外部化することをお薦めします。この判断ロジックは、ルーティング・サービスに組み込まれています。これによって、不測の状況が発生した場合にメッセージの経路を宣言的に変更できます。エンタープライズ・ビジネス・サービスがルーティング・サービスとして機能します。これによって、コンテンツ・ベースのフィルタ処理に基づく1対多のメッセージ・ルーティングが容易になります。リクエスタから発信されたメッセージは、ビジネス・ルールまたはコンテンツ・フィルタに基づいて、すべてのターゲット、一部のターゲットまたは単一のターゲットに配信されます。

ルーティング・サービスでは、ルールを評価して、特定のメッセージを処理するために使用する必要がある実際のサービス・プロバイダを把握します。このアプローチを使用することで、クライアントまたはサービス・リクエスタは実際のサービス・プロバイダを一切意識しません。同様に、基礎となるサービス・プロバイダはリクエストを作成したクライアント・アプリケーションには関知しません。これによって、実際のリクエスタ・サービスに変更を加えることなく、新規のプロバイダを導入し、既存のプロバイダを撤退できます。

図18-5に、ルーティング・サービスによるコンテキスト・ベース・ルーティングを使用して、2つのターゲット・アプリケーションのいずれか、または取引パートナ(B2B)にReq Impl Service (リクエスタ・サービス)を送信することで、リクエストを送信する様子を示します。

図18-5 コンテンツ・ベースのサービス・インスタンスのルーティング

影響

実際のサービス・プロバイダと緩やかに結合されたリクエスタ・サービスの場合は、ルーティング・サービスが抽象レイヤーとして機能する必要があるため、そのサービス・インタフェースを慎重に設計する必要があります。一意のサービス・プロバイダが1つのみ存在するか、正規のインタフェースを使用できる場合、そのインタフェースで実際のサービス・プロバイダのインタフェースをエミュレートできます。

メディエータのテクノロジによって、ルーティング・ルールを宣言的な方法で追加できるとしても、本番環境にデプロイする前に、異なるルーティング・パスの妥当性をテストする必要があります。

判断ロジックを各ルーティング・サービスでローカルに管理することは重複や競合の原因になるため、Oracleビジネス・ルール・エンジンなどの一元化されたルール管理システムでの管理を考慮することは選択肢の1つです。

18.1.5 競合コンシューマ・パターン: 並列性および効率を改善するための複数コンシューマの使用方法

問題

リクエスタ・アプリケーションが、処理してターゲット・アプリケーションに送信する必要がある大量のビジネス・メッセージを作成する場合は、期待されるスループットに対応するようにすべてのメッセージを処理することが課題となります。各メッセージの処理に多数のシステムとの相互作用が必要で、その結果、処理の完了を待機して相当な時間ブロックされることになる場合は、さらに深刻です。

たとえば、注文獲得アプリケーションが、注文を履行するために注文処理キューに注文を発行します。各注文履行リクエストは、キューから取得して、分解するために注文編成エンジンに渡す必要があります。次のメッセージを注文処理キューから取得できるのは、確認時のみです。注文編成プラットフォームの機能が予定外に停止すると、注文履行リクエストが大量に蓄積され、プラットフォームが使用可能になったときも、これらのリクエストの一連の処理に非常に大きな遅延が発生する可能性があります。

ソリューション

ソース・キューに接続された複数のコンシューマまたはリスナーを設定することをお薦めします。AIAでは、リクエスタ・アプリケーションからソース・キューにメッセージが発行済であることが前提となります。

詳細は、「非同期ファイア・アンド・フォーゲット・パターン」を参照してください。

図18-6に、複数のリスナーがパラレルに複数のメッセージの使用をトリガーする設定を示します。単一のキューからメッセージを受信するために複数のコンシューマを作成したとしても(ポイントツーポイント・チャネル)、JMSによる配信時にメッセージを受信できるのは単一のコンシューマのみです。すべてのコンシューマが受信者であるために相互に競合するとしても、そのいずれかのコンシューマのみがメッセージを受信することになります。ビジネス要件に基づいて、このパターンは、HA環境の各ノード、拡張性を向上するためのクラスタ、またはAIAアーティファクト内の各コンシューマが設定されている複数のノードで使用できます。

図18-6 ソース・キューに接続された複数のコンシューマまたはリスナーの設定

影響

このソリューションはキューに対してのみ機能し、トピック(パブリッシュ/サブスクライブ・チャネル)では使用できません。トピックの場合、各コンシューマはメッセージのコピーを受信します。

複数のコンシューマがメッセージをパラレルに処理するため、メッセージは特定の順序では処理されません。機能上の理由で並列性および効率に支障を与えずに順番に処理する必要がある場合は、連続した配列を受信するまで、これらのメッセージを保持するステージング領域を導入する必要があり、その後、最終的な受信者に配信します。

18.1.6 非同期遅延/レスポンス・パターン: 同期通信が適切でない状況でのリクエスタに対するサービス・プロバイダの通信方法

問題

サービス・プロバイダによるリクエストの処理に長い時間が必要な場合は、どのようにすると、処理の全体にわたってリクエスタを一時停止モードにせずに、リクエスタが結果を受信できるかを考えてみます。

たとえば、注文獲得アプリケーションが、注文を履行するためのリクエストを発行します。注文履行プロセス自体は、必要なタスクの複雑度によって数分から数日かかります。注文獲得アプリケーションが履行リクエストの結果の把握を希望する場合も、結果を把握するために、プロセスが完了するまで無駄に待機するのは現実的ではありません。

ソリューション

非同期遅延/レスポンス・パターンを使用することをお薦めします。このパターンでは、リクエスタがリクエストを統合レイヤーに発行し、リクエスト・メッセージ(WSAヘッダー)にメタデータ・セクションを挿入することで、コールバック・レスポンス・アドレスを設定します。コールバック・レスポンス・アドレスは、完了後にサービス・プロバイダから連絡を受ける当初のコール元サービスのエンド・ポイントの場所を指します。最終的な受信者にメッセージが送信されるまでに複数の仲介サービスが関係するため、メッセージのメタデータ・セクションを使用したコールバック・アドレスの送信が必要になります。コールバック・アドレスに加え、リクエスタがレスポンス・メッセージを当初のリクエストに関連付けできるように、リクエスタには相関詳細を送信することが期待され、これによって、サービス・プロバイダが将来の対話でこの情報を送信できるようになります。

リクエスト/遅延レスポンス・パターンは実質的に非同期であるため、リクエスタはリクエスト・メッセージを送信した後、レスポンスを待機します。図18-7に示すように、このパターンを実装するフローでは、関係するサービスすべてに2つの一方向操作を確保することをお薦めします。レスポンス・メッセージを開始するには、個別のスレッドを呼び出す必要があります。プロバイダ参加アプリケーションからリプライを取得した後、AIAプロバイダ・サービスがメッセージを処理する場合は、レスポンスEBSを呼び出すことでレスポンス・スレッドを作成します。レスポンスEBSは、要求側アプリケーションが指定したコールバック・アドレスを呼び出すために、WSAヘッダーを使用して要求側サービスを識別し、レスポンスを処理します。EBSには、リクエスト送信用とレスポンス受信用の2つの一方向コールをサポートする1組の操作があります。操作は両方とも独立し、自立しています。相関メカニズムは、アプリケーションまたはコール元のコンテキストを設定する際に使用されます。

図18-7 非同期遅延/レスポンス・パターンの例

影響

プロバイダ・アプリケーションには、リクエスタ・アプリケーションから送信された相関詳細およびコールバック・アドレスを保持する機能が必要で、これらの詳細をレスポンス・メッセージに入力する必要があります。

18.1.7 非同期リクエスト/レスポンス・パターン: サービス・プロバイダによるリクエスタに関連するエラーの通知方法

問題

統合アーキテクトは、非同期リクエスト/レスポンス・パターンの実装を決定する前に、トランザクション要件、グローバル・トランザクションへの参加に対する参加アプリケーションの機能、およびマイルストンの概念を理解する必要があります。次の項では、3つの異なるシナリオについて実装ソリューションのガイドラインを示します。

ソリューション: 成功シナリオでは、エラー処理に対して同じリクエスタの別のサービスをコールします。

このソリューションでは相互作用が2つのトランザクションに分割され、つまり、エラー処理部分がリクエスタABCS実装から切り離されます。レスポンスEBSからエラー・メッセージを受け入れるために新しいサービスを作成し、エラー・レスポンス・サービスをソース参加アプリケーションに転送する必要があります。

図18-8に、リクエストが正常に処理された場合に、残りのプロセス・アクティビティを完了するためにリクエストがリクエスタABCSに戻される様子を示します。レスポンスの処理でエラーを検出した場合は、通常のエラー処理メカニズムに従って、ソース参加アプリケーションに通知が送信されます。エラーがコール元に返された場合、エラー・レスポンス・サービスへのWebサービス・コールは、リクエスタABCS実装のエラー処理ブロックで実行されます。

図18-8 エラー処理とリクエスタABCSの2つのトランザクションに分割された相互作用の例

ソリューション: マイルストンとしてのJMSキューの使用

このソリューションでは、相互作用が3つのトランザクションに分割されます。トランザクション境界を使用可能にするには、JMSキュー/マイルストンを使用する必要があります。図18-9に、エラーのシナリオを示します。成功のシナリオにJMS-2キューはありません。かわりに、プロバイダABCSがレスポンスEBSを直接呼び出します。したがって、成功シナリオでは、相互作用全体が2つのトランザクションで完了します。

図18-9 JMSキューをマイルストンとして使用している場合のエラー・シナリオ

ソリューション: パラレル・ルーティング・ルールおよびWebサービス・コールの使用

このソリューションでは、相互作用が3つのトランザクションに分割されます。図18-10に、エラーのシナリオを示します。トランザクション境界を使用可能にするには、メディエータ(EBS)のパラレル・ルーティング・ルールおよびレスポンスEBSへのプロバイダABCS参照からのWebサービス・コールを使用する必要があります。成功シナリオでは、最適化された参照コンポーネント・バインディングを使用してレスポンスEBSを直接コールします。そのため、成功の場合は2つのトランザクション境界のみがあります。

図18-10 パラレル・ルーティング・ルールおよびWebサービス・コールを使用したエラー・シナリオ

18.2 AIAアセット一元化パターン

この項では、AIAでの冗長なデータ・モデル表現およびサービス・コントラクト表現の回避方法について説明します。

この項には次のトピックが含まれます:

- AIAでの冗長なデータ・モデル表現の回避方法

- AIAでの冗長なサービス・コントラクト表現の回避方法

18.2.1 AIAでの冗長なデータ・モデル表現の回避方法

問題

アプリケーションとAIAインタフェース間のサービス・コントラクトでは、冗長なデータ・モデル表現になる類似したビジネス・ドキュメントまたはデータ・セットを使用する必要があります。データ・モデルの変更は適用するのが非常に難しく、管理も困難です。

ソリューション

サービス・コントラクトまたは実装からデータ・モデルまたはスキーマを物理的に分離することをお薦めします。これらのスキーマは、設計または実行時に簡単に参照できる場所に一元化してください。

EBO (エンタープライズ・ビジネス・オブジェクト)、ABO (アプリケーション・ビジネス・オブジェクト)およびその他のユーティリティ・スキーマのすべてを中央の場所に体系化された方法で保持する必要があります。

様々な共通のビジネス・プロセスでEBOスキーマが使用されるように、正規データ・モデルを策定する前に綿密な分析を実行してください。

影響

- データ・モデルまたはスキーマの変更は、複数の従属サービス・コントラクトに細かい変更の影響を与える可能性があるため、慎重に取り扱う必要があります。

- バージョニング・ポリシーは明確に定義する必要があり、明確にしておかないと、わずかな変更のために冗長なサービス実装が生じる可能性があります。

- 共有データ・モデルまたは共通アセットの取扱いでは、管理が課題になります。

18.2.2 AIAでの冗長なサービス・コントラクト表現の回避方法

問題

サービス・コントラクトの粒度は、操作レベルまたはエンティティ・レベルになります。エンティティ・レベルの定義では、様々な操作を同じサービス・コントラクトに定義できますが、実装は操作レベルとなり、同じサービス・コントラクトを使用して複数の実装アーティファクトを作成することになります。これによって、様々な実装で冗長なサービス・コントラクト表現が発生します。

ソリューション

サービス・コントラクト(WSDL)を実装から物理的に分離することをお薦めします。これらのサービス・コントラクトは、設計または実行時に簡単に参照できる場所に一元化してください。

EBS (エンタープライズ・ビジネス・サービス)、ABCS (アプリケーション・ビジネス・コネクタ・サービス)およびその他のユーティリティ・サービス・コントラクトのすべてを中央の場所に体系化された方法で保持する必要があります。

影響

- サービス・コントラクトの変更は、複数の従属サービスの実装に細かい変更の影響を与える可能性があるため、慎重に取り扱う必要があります。

- 共有サービス・コントラクトまたは共通アセットの取扱いでは、管理が課題になります。

18.3 AIAアセット拡張性パターン

この項では、AIAアセットの拡張性パターンについて説明し、AIAアーティファクトの拡張に関する問題とソリューションを示します。

この項には次のトピックが含まれます:

- AIAでの既存のスキーマの拡張

- AIAサービスの拡張

- AIAでの既存の変換の拡張

- AIAでのビジネス・プロセスの拡張

18.3.1 AIAでの既存のスキーマの拡張

問題

付属のスキーマでは、一部の特定のビジネス操作には十分でない可能性があるため、安全なアップグレード手段で要素を既存のスキーマに追加できます。顧客固有の要素を既存のスキーマに単に追加するのみでは使用可能ではなく、スキーマ拡張モデルが必要です。

ソリューション

EBOまたはエンタープライズ・ビジネス・メッセージ(EBM)のスキーマを負担が少ない手段で拡張できるように、すべてのビジネス・コンポーネントに定義された複合タイプおよび各EBOまたはEBMスキーマにある共通コンポーネントの最後に、Customという拡張プレースホルダ要素があります。このカスタム要素のデータ・タイプは、カスタムEBOスキーマ・ファイルの顧客拡張を保持するために割り当てたスキーマ・モジュールに定義されます。

例18-1では、「スキーマA」の複合タイプの最後に追加されたカスタム要素がプレースホルダとして機能し、「カスタム・スキーマA」に追加された顧客拡張が取得されます。

ここでは、「スキーマA」はAIAComponents\EnterpriseObjectLibrary\Industry\Telco\EBO\ CustomerParty\V2\CustomerPartyEBO.xsdです。

例18-2に、「カスタム・スキーマA」に相当するAIAComponents\EnterpriseObjectLibrary\Industry\Telco\Custom\ EBO\CustomerParty\V2\CustomCustomerPartyEBO.xsdを示します。

例18-1 プレースホルダとして機能するカスタム要素

<xsd:complexType name="CustomerPartyAccountContactCreditCardType">
<xsd:sequence>
<xsd:element ref="corecom:Identification" minOccurs="0"/>
<xsd:element ref="corecom:CreditCard" minOccurs="0"/>

<xsd:element name="Custom"
type="corecustomerpartycust:CustomCustomerPartyAccountContactCreditCardType"
minOccurs="0"/>

</xsd:sequence>
<xsd:attribute name="actionCode" type="corecom:ActionCodeType"
use="optional"/>
</xsd:complexType>

例18-2 EBOまたはEBMスキーマへの拡張の追加

<!-- ================================================================== -->
<!-- ==============  CustomerParty Custom Components ================ -->
<!-- ============================================================ -->
<xsd:complexType name="CustomCustomerPartyAccountAttachmentType"/>
<xsd:complexType name="CustomCustomerPartyAccountContactType"/>
<xsd:complexType name="CustomCustomerPartyAccountContactCreditCardType">

<!-- CUSTOMERS CAN ADD EXTENSIONS HERE ...>
</xsd:complexType>
<xsd:complexType name="CustomCustomerPartyAccountContactUsageType"/>

18.3.2 AIAサービスの拡張

問題

付属のサービスでは、一部の特定のビジネス機能に対応するには十分でない可能性があります。なんらかの検証ロジックの追加、サービスの既存のコンテンツのエンリッチ、または既存のサービス実装間へのなんらかの処理ロジックの追加の必要性が生じることがあります。アップグレード・プロセスでは既存のサービス・コードがアップグレードの一環として追加された新機能で上書きされるため、このロジックを既存のサービス・コードに追加すると、安全なアップグレードが保証されません。そのため、サービス拡張モデルが必要になります。

ソリューション

サービス実装時の論理ポイントで、様々な拡張ポイントを導入することをお薦めします。図18-11に、ABCSに4つの論理拡張ポイントが識別され、顧客固有の検証、コンテンツのエンリッチメントやメッセージの変更、および追加のロジックを実行するために、その拡張ポイントで指定のペイロードを組み込む実装の様子を示します。通常は、2つの前処理拡張ポイントと2つの後処理拡張ポイントが識別されます(前処理ABM、後処理ABM、前処理EBM、後処理EBM)。

拡張ポイントの数は、サービス実装およびそのサービスで使用されるメッセージ交換パターンのタイプに従って、4つより多いまたは少ない場合があります。

これらの拡張ポイントは、そのカスタム拡張ポイントを実装するかどうかに応じて使用可能または使用不可にできます。

図18-11 AIAサービスの拡張

18.3.3 AIAでの既存の変換の拡張

問題

既存のスキーマとともに付属している変換では、一部の特定のビジネス操作には十分でない可能性があります。あるアプリケーションから別のアプリケーションに安全なアップグレード手段で情報を転送するには、要素を既存のスキーマに追加した後、新規に追加した要素の変換マップを追加します。顧客固有の変換を既存のXSLファイルに単に追加するのみでは使用可能ではなく、変換拡張モデルが必要です。

ソリューション

負担が少ない手段で変換を拡張するには、カスタムXSL変換に定義されたカスタム・テンプレートという各XSL変換ファイルに存在するすべてのビジネス・コンポーネント・マッピングに対して、コール・テンプレートを定義します。

例18-3は、顧客によって追加されたカスタム要素に対して新規の変換を追加する例です。

メインXSLマッピングXformListOfCmuAccsyncAccountIoToCreateCustomerPartyListEBM.xslでは、カスタムXSLファイルをインポートし、複合タイプまたはビジネス・コンポーネントごとに、拡張テンプレートに対するテンプレート・コール文があります。

例18-4に、テンプレートが定義されたカスタムXSLファイルを示します。このテンプレートを使用して、メインの変換でマップされない新規に追加されたカスタム要素または既存の要素についてカスタム・マッピングを追加できます。

例18-3 顧客が定義したカスタム要素に対する新しい変換の追加

<?xml version = '1.0' encoding = 'UTF-8'?>
..………………………………………..
xmlns:dvm="http://www.oracle.com/XSL/Transform/java/oracle.tip.dvm.LookupValue">
<xsl:import href="XformListOfCmuAccsyncAccountIoToCreateCustomerPartyListEBM_
Custom.xsl"/>
..………………………………………..
<xsl:value-of select="aia:getServiceProperty($ConfigServiceName,
'Routing.CustomerPartyEBS.CreateCustomerPartyList.CAVS.EndpointURI', false())"/>
</corecom:DefinitionID>
</xsl:if>
<xsl:call-template name="MessageProcessingInstructionType_ext">
<xsl:with-param name="currentNode" select="."/>
</xsl:call-template>
</corecom:MessageProcessingInstruction>

例18-4 カスタムXSLテンプレート定義

<!-- HEADER CUSTOMIZATION -->
<xsl:template name="MessageProcessingInstructionType_ext">
<xsl:template name="EBMHeaderType_ext">
<xsl:param name="currentNode"/>
<!-- Customers add transformations here -->
</xsl:template>

<xsl:param name="currentNode"/>
<!-- Customers add transformations here -->
</xsl:template>

<!-- DATA AREA CUSTOMIZATION -->
<xsl:template name="ContactType_ext">
<xsl:param name="currentNode"/>
<!-- Customers add transformations here -->
</xsl:template>

18.3.4 AIAでのビジネス・プロセスの拡張

問題

付属のコンポジット・ビジネス・プロセスまたはエンタープライズ・ビジネス・フローでは、一部の特定のビジネス機能に対応するには十分でない可能性があります。追加の処理ステップ、メッセージの変更、または既存のコンポジット・ビジネス・プロセス実装間への処理ロジックの追加の必要性が生じることがあります。このロジックを既存のプロセス編成に追加すると、安全なアップグレードが保証されないため、プロセス拡張モデルが必要になります。

ソリューション

サービス実装時の論理ポイントで、拡張ポイントを導入することをお薦めします。コンポジット・ビジネス・プロセス(CBP)またはエンタープライズ・ビジネス・フロー(EBF)では、固定の論理拡張ポイントは識別されません。拡張ポイントの数は、ビジネス・プロセスの複雑性および実装でプロセスを処理するメッセージ・タイプの数で異なります。

CBPまたはEBF実装では、様々な論理ポイントの各メッセージに対して、1つの前処理拡張ポイントと1つの後処理拡張ポイントを保持することをお薦めします。拡張プロセスは常に、その拡張ポイントに対するリクエストおよびレスポンスに同じメッセージ・ペイロードを使用した同期プロセスである必要があります。

これらの拡張ポイントは、そのカスタム拡張ポイントを実装するかどうかに応じて使用可能または使用不可にできます。

19 セキュリティに関する作業

この章では、リモート通信のサービス・エンドポイントを保護する方法、およびソース・アプリケーションからAIAレイヤーを介してターゲット・アプリケーションに認証コンテキストを渡すために使用されるアプリケーション・セキュリティ・コンテキストを保護する方法を説明します。

この章の内容は次のとおりです。

- Oracle AIAリモート・セキュリティの概要

- セキュリティの実装

- アプリケーションのセキュリティ

- セキュリティ・ポリシーのデプロイ

- ポリシーの命名規則

- AIAサービスの保護に役立つSOAコア拡張機能

- アプリケーション・セキュリティ・コンテキスト

19.1 Oracle AIAリモート・セキュリティの概要

デフォルトでは、Oracle AIAのすべてのサービスが保護されます。アダプタ・ベースのすべてのサービスは、JNDIを使用してセキュリティが有効化されます。SOAP over HTTPを使用するすべてのコンポジット・サービスと参照は、Oracle Web Services Manager (WSM)を使用して保護されます。

提供されたセキュリティが自社のユースケースに十分でない場合は、セキュリティをオーバーライドできます。

19.1.1 サービス間相互作用の保護

サービス間相互作用の保護では、次のことを実行します。

- 認証によってクライアントを識別します。

- 暗号化によってメッセージを保護します。

- デジタル署名を使用してメッセージの改ざんを防止します。

- SSLを使用してチャネルを暗号化します。

図19-1に、AIAの高度なセキュリティ構造を示します。

図19-1 高度なセキュリティ・アーキテクチャ

Oracle WSMを使用してWebサービス・セキュリティをOracle AIAに構成することをお薦めします。AIAサービスに対するセキュリティを有効にするには、Oracle WSMを使用して適切なサービス・ポリシーを割り当てます。保護されたサービスをコールするには、適切なクライアント側ポリシーを割り当てます。

19.1.2 サービスの保護に関するOracle AIAの推奨事項

サービスの保護に関するAIAの推奨事項は次のとおりです。

- すべてのWebサービスを保護してください。これには、次のものが含まれます。

- アプリケーション・ビジネス・コネクタ・サービス(ABCS)、エンタープライズ・ビジネス・サービス(EBS)、トランスポート・アダプタ・サービスなどのAIAサービス。

- Oracle Fusion Middlewareでホストされているその他のアプリケーション・サービス。

- 標準のインストールでは、セキュリティ・ポリシーが適用されたサービスをデプロイしてください。

- このリリースでは、AIAサービスが提供する最低限の保護は認証です。

- 本番環境では、メッセージ保護を使用してサービスを強化してください。

19.1.3 Oracle Web Services Managerを使用したWebサービス・セキュリティの概要

Oracle Web Services Manager (WSM)のセキュリティと管理は、Oracle WebLogic Serverに統合されています。

Oracle Web Services Managerの詳細は、『Webサービスの管理』を参照してください

デプロイメント時にOracle WSMを使用してWebサービス・セキュリティを宣言して構成することによって、セキュリティ・ロジックをサービス開発から分離することをお薦めします。やむを得ない理由(参加アプリケーションがWebサービス・セキュリティをサポートしていないなど)がないかぎり、SSLではなくWebサービス・セキュリティを使用してください。

AIAでは、SOA Suiteの一部としてOracle WSMがインストールされ、最もよく使用されるセキュリティのユースケースに対するポリシーが提供されます。Oracle WSMには、特別なセキュリティ機能をスタンドアロンで追加したり、他のセキュリティ機能と組み合せて追加するためのポリシーがあります。

ポリシーは、次のような様々な粒度でサービスに対してグローバルにアタッチされます。

- ドメイン - ドメイン内のすべてのサービス

- インスタンス - WLSサーバー・インスタンス内のすべてのサービス

- SOAコンポジット名ベース - コンポジット内のすべてのサービス

提供されるポリシーのリストは、『Webサービスの管理』の事前定義済ポリシーに関する項を参照してください

19.2 セキュリティの実装

この項には次のトピックが含まれます:

- AIAサービスに対するセキュリティの有効化

- 保護されたアプリケーション・サービスの呼出し

- デプロイメント計画を使用したポリシーのオーバーライド

- CAVSを使用した保護サービスのテスト。

19.2.1 AIAサービスに対するセキュリティの有効化

AIAサービスのセキュリティを有効にする手順は、次のとおりです。

1. 必要なセキュリティのタイプを判断します。
認証、暗号化および整合性にはWS-securityの使用をお薦めします。

2. グローバル・セキュリティ・ポリシーがWebサービスに十分かどうかをチェックします。

3. 適切な機能の組合せを含むWS-policyを検索します。
たとえば、暗号化と整合性が必要な場合は、暗号化と整合性の両方を処理するポリシーを検索する必要があります。

4. ポリシーをサービスにアタッチして、サービスに対するセキュリティを有効にします。
ポリシーのアタッチ方法の詳細は、『Webサービスの管理』の、Webサービスへのポリシーのアタッチに関する項を参照してください。

5. ポリシーを構成します。
各ポリシーに対して追加の構成を実行できます。

各ポリシーを構成する方法の詳細は、『Webサービスの管理』の、のポリシーの構成に関する項を参照してください。

6. 問題を診断します。
問題の診断方法の詳細は、『Webサービスの管理』の問題の診断に関する項を参照してください。

19.2.1.1 すべてのAIAサービスを保護するかどうかの判断

セキュリティは、パフォーマンスにマイナスの影響を与える場合があるため、慎重に使用する必要があります。AIAでは、組織の境界を越えて他のサービスと相互作用するサービスの保護が必須です。企業ネットワーク外部のクライアントからコールされるすべてのAIAサービスを保護する必要があります。すべてのサービスが同じ組織内かつファイアウォールの内側に存在するA2A統合では、必ずしもすべてのサービスを保護する必要はないと判断できます。

初期状態のすべてのAIAサービスが保護されていて、自社のデプロイメントにセキュリティが必要ないと考えられる場合は、セキュリティを無効にしてください。

19.2.2 保護されたアプリケーション・サービスの呼出し

保護されたアプリケーション・サービスを呼び出す手順は、次のとおりです。

1. 必要なセキュリティのタイプを判断します。
認証、暗号化および整合性にはWS-securityの使用をお薦めします。

2. グローバル・セキュリティ・ポリシーがWebサービスに十分かどうかをチェックします。

3. 適切な機能の組合せを含むWS-policyを検索します。
たとえば、暗号化と整合性が必要な場合は、暗号化と整合性の両方を処理するポリシーを検索する必要があります。

4. ポリシーをサービスにアタッチして、サービスに対するセキュリティを有効にします。
ポリシーのアタッチ方法の詳細は、『Webサービスの管理』の、Webサービスへのポリシーのアタッチに関する項を参照してください。

5. ポリシーを構成します。
各ポリシーに対して追加の構成を実行できます。

WS-Securityのクライアント側の基本認証ポリシーの場合は、次の操作を実行する必要があります。

a. 資格証明ストアを構成します。

b. キーに関連するユーザーIDとパスワードをストアに追加します。

c. ポリシーでキーを使用します。

各ポリシーを構成する方法の詳細は、『Webサービスの管理』の、のポリシーの構成に関する項を参照してください。

6. 問題を診断します。
問題の診断方法の詳細は、『Webサービスの管理』の問題の診断に関する項を参照してください。

19.2.3 デプロイメント計画を使用したポリシーのオーバーライド

SOAコア拡張機能には、グローバル・ポリシーを宣言でオーバーライドするインフラストラクチャがあります。ポリシーをオーバーライドするには、サービス開発者が次の操作を実行する必要があります。

1. 「AIAセキュリティ構成プロパティ」の項で説明されているように、サービス構成ファイルを作成します。

2. これをプロジェクト・フォルダに配置します。

19.2.4 CAVSを使用した保護サービスのテスト

CAVSを使用して保護されたサービスをテストするには、要素<cavs:CAVSRequestInput_1>に、例19-1の<soap:Envelope>の下に示した要素が設定されている必要があります。

アイデンティティ・ストアのデフォルト・ユーザーを使用している場合、[user name] = weblogic、[pwd] = weblogic#1です。

例19-1 <soap:Envelop>のコンテンツ

<soapenv:Header>
<wsse:Security
xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-
secext-1.0.xsd"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-
secext-1.0.xsd">
<wsse:UsernameToken>
<Username>[user name]</Username>
<Password>[pwd]</Password>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>

19.3 アプリケーションのセキュリティ

この項では、次の項目について説明します。

- アプリケーション・サービスでのセキュリティの有効化

- 保護されたAIAサービスの呼出し

19.3.1 アプリケーション・サービスでのセキュリティの有効化

参加アプリケーションの組込み機能を使用して、サービスのセキュリティを有効にできます。セキュリティを有効にする製品を選択するには、そのアプリケーションに対するエージェント・サポートがOracle WSMにあるかどうかをチェックし、ある場合はOracle WSMを使用します。

アプリケーションで任意の種類のセキュリティが使用可能な場合は、認証、暗号化および整合性についてWebサービス・セキュリティを使用します。それ以外の場合は、SSLを使用して接続を保護できます。

19.3.2 保護されたAIAサービスの呼出し

WS-securityに対して有効化されたAIAサービスと相互作用する場合は、AIAサービスのセキュリティ機能に必要なすべての情報をSOAPヘッダーのセキュリティ・ヘッダーに追加する必要があります。AIAサービスのセキュリティに基づいて、認証、暗号化および整合性のいずれかの組合せについて情報を追加する必要があります。

例19-2は、認証用のセキュリティ・ヘッダーのサンプルです。

AIAサービスにSSLが必要な場合は、一方向および双方向SSLの両方についてアプリケーションでSSLを構成する必要があります。

例19-2 認証用のセキュリティ・ヘッダー

<wsse:Security  env:mustUnderstand="1">
<wsse:UsernameToken  wsu:Id="UsernameToken-dXtD14011QZUTlfIaSrMhw22">
<wsse:Username>weblogic</wsse:Username>
<wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-
profile-1.0#PasswordText">weblogic1</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>

19.4 セキュリティ・ポリシーのデプロイ

ポリシーは、個別のサービス・レベルで制約したポリシー・アタッチメントではなく、グローバルに適用することをお薦めします。SOAコア拡張機能のインストール時には、グローバル・ポリシーが適用されています。

グローバルにアタッチされたクライアント・ポリシーを直接アタッチされたローカル・ポリシーでオーバーライドすることが避けられない場合があります。一般的なガイドラインは次のとおりです。

- グローバル認証ポリシーが提供されます。

- ポリシーをコンポジット・レベルで定義する必要がなくなります。

- 適用済のグローバル・サービス・ポリシー: oracle/aia_wss_saml_or_username_token_service_policy_OPT_ON
これは、ローカル最適化がオンに設定されたoracle/wss_saml_or_username_token_service_policyのクローン・コピーです。

- 適用済のグローバル・サービス・クライアント・ポリシー: oracle/aia_wss10_saml_token_client_policy_OPT_ON
これは、ローカル最適化がオンに設定されたoracle/wss10_saml_token_client_policyのクローン・コピーです。

- 自社の個別フロー・ニーズを評価し、必要な場合はサービスを強化します。
さらに強化を行うには、ローカル・ポリシーを関連付けます。

- 保護されたAIA Webサービスを呼び出すアプリケーションは、資格証明を送信する必要があります。

- AIA間の通信は、グローバル・サービス・クライアント・ポリシーによって処理されます。

19.4.1 ポリシーに関するOracle AIAの推奨事項

通常は、自社組織のセキュリティ・ポリシーの基本的な要件に基づいて、使用するポリシーを決定します。次の質問は、使用可能なポリシーを判断するのに役立ちます。

- ユーザーの認証のみが必要ですか。

- メッセージの保護が必要ですか。

- トランスポート・レイヤーとSOAPヘッダーのどちらにトークンを組み込みますか。

- 特定タイプのトークンを使用する必要がありますか。

次のポリシーをAIAサービスにグローバルにアタッチする必要があります。

- oracle/aia_wss_saml_or_username_token_service_policy_OPT_ON

- aia_wss_saml_or_username_or_http_token_service_policy_OPT_ON

- oracle/aia_wss10_saml_token_client_policy_OPT_ON

oracle/aia_wss_saml_or_username_token_service_policy_OPT_ON

これは、ローカル最適化がオンに設定されたoracle/wss_saml_or_username_token_service_policyのクローン・コピーです。クライアントとサービス・コンポジットが同一の場所に配置されている場合は、ローカル最適化を使用する必要があります。

このポリシーは、WS-Security SOAPヘッダーのSAMLトークンまたはUsernameToken WS-Security SOAPヘッダーに含まれる資格証明を使用してユーザーを認証します。SAMLトークンの資格証明はSAMLログイン・モジュールに対して認証される一方、UsernameTokenの資格証明は構成済のアイデンティティ・ストアに対して認証されます。UsernameTokenにはプレーン・テキスト・メカニズムのみがサポートされています。このポリシーは、どのようなSOAPベースのエンドポイントにも適用できます。

aia_wss_saml_or_username_or_http_token_service_policy_OPT_ON

これは、ローカル最適化がオンに設定され、HTTP基本認証が追加オプションとして追加されたoracle/wss_saml_or_username_token_service_policyのクローン・コピーです。Webサービス・セキュリティを使用するためのインフラストラクチャがないODIなどのクライアントは、HTTP基本認証を使用してサービスをコールできます。

これはAIAAsyncErrorHandlerBPELサービスのみにアタッチされます。

oracle/aia_wss10_saml_token_client_policy_OPT_ON

これは、ローカル最適化がオンに設定されたoracle/wss10_saml_token_client_policyのクローン・コピーです。クライアントとサービス・コンポジットが同一の場所に配置されている場合は、ローカル最適化を使用する必要があります。

このポリシーには、アウトバウンドSOAPリクエスト・メッセージのSAMLトークンが含まれます。

19.5 ポリシーの命名規則

この項には次のトピックが含まれます:

- グローバル・ポリシー・セットの命名規則

- 構成パラメータをオーバーライドする際の命名規則

19.5.1 グローバル・ポリシー・セットの命名規則

サービス固有のグローバル・ポリシー・セットの命名規則

- AIA_[ServiceType]_WSServicePolicySet

- サービス・タイプの可能な値は次のとおりです。

- ABCS

- EBS

- EBF

- Adapter

- Producer

- Consumer

- 例: AIA_ABCS_WSServicePolicySet

クライアント固有のグローバル・ポリシー・セットの命名規則

- AIA_[ServiceType]_WSClientPolicySet

- サービス・タイプの可能な値は次のとおりです。

- ABCS

- EBS

- EBF

- Adapter

- Producer

- Consumer

- 例: AIA_ABCS_WSClientPolicySet

19.5.2 構成パラメータをオーバーライドする際の命名規則

構成パラメータの命名規則 - CSFキー

- AIA_APPSHORTNAME_ServiceName_PortTypeName

- APPSHORTNAME: サービス・レジストリに定義されたアプリケーションの短縮名。

- ServiceName: 外部WebサービスのWSDLにあるservice要素のname属性の値。

- PortTypeName: 外部WebサービスのWSDLにあるportType要素のname属性の値。

19.6 AIAサービスの保護に役立つSOAコア拡張機能

SOAコア拡張機能では、次の処理が自動的に実行されます。

- 推奨グローバル・ポリシー・セットが作成されます。

- 必要な場合はコンポジットに対するローカル・ポリシーがアタッチされます。

この項には次のトピックが含まれます:

- サービスにアタッチされるデフォルトのポリシー

- 個々のサービスに対するグローバル・ポリシーをオーバーライドする方法

- AIAセキュリティ構成プロパティ

19.6.1 サービスにアタッチされるデフォルトのポリシー

グローバル・ポリシーのデプロイメントは、SOAコア拡張機能のインストール時に処理されます。グローバル・サービスとクライアント・ポリシーのセットがSOAコア拡張機能のインストール時にWLSドメインにアタッチされます。結果として、そのサーバーにデプロイされる(パターンが一致する)すべてのサービスが自動的に保護されます。

SOAコア拡張機能のインストーラでは、コンポジット名のパターンに対して、サービス固有とクライアント固有の両方のグローバル・ポリシー・セットが作成されます。

- ABCS

- EBS

- EBF

- Adapter

- Producer

- Consumer

SOAコア拡張機能のインストーラでは、次のポリシー・セットが作成されます。

- コンポジット・サービスにアタッチされるグローバルPolicySet

- AIA_ABCS_WSServicePolicySet

- AIA_EBS_WSServicePolicySet

- AIA_EBF_WSServicePolicySet

- AIA_Adapter_WSServicePolicySet

- AIA_Consumer_WSServicePolicySet

- AIA_Producer_WSServicePolicySet

- コンポジット参照にアタッチされるグローバルPolicySet

- AIA_ABCS_WSClientPolicySet

- AIA_EBS_WSClientPolicySet

- AIA_EBF_WSClientPolicySet

- AIA_Adapter_WSClientPolicySet

- AIA_Consumer_WSClientPolicySet

- AIA_Producer_WSClientPolicySet

19.6.2 個々のサービスに対するグローバル・ポリシーをオーバーライドする方法

異なるセキュリティ・ポリシーを必要とする保護されたアプリケーション・サービスと相互作用するコンポジットにはローカル・ポリシーがアタッチされ、デプロイメント時にグローバル・ポリシーがオーバーライドされます。

同様に、保護されていないアプリケーション・サービスと相互作用する必要があるコンポジットにはNoClientAuthenticationPolicyがアタッチされ、グローバル・ポリシー・セットがオーバーライドされます。

AIAデプロイメント・ドライバでは通常、オーバーライド・ローカル・セキュリティ・ポリシーのアタッチがサポートされますが、サポートされるのは、saml-tokenおよびusername-tokenクライアント・ポリシーに対する構成オーバーライドのみです。

異なるクライアント(ローカル)ポリシーを使用すると、AIAデプロイメント・ドライバによってポリシーがアタッチされますが、その構成は手動タスクとなります。

例19-3は、XMLファイルの構造を示しています。

19.6.3 AIAセキュリティ構成プロパティ

サービス・エンドポイントまたは参照エンドポイント(あるいはその両方)にアタッチされたローカル・ポリシーを必要とするコンポジットは、SOAコア拡張機能ツールに情報を提供する必要があります。これらのコンポジットには、xmlベースのセキュリティ構成ファイルが関連付けられている必要があります。このファイルの名前は、AIASecurityConfigurationProperties.xmlです。

SOAコア拡張機能ツールでは、次の情報が必要です。

- コンポジットの名前

- ローカル・ポリシーを必要とするすべてのサービス・エンドポイントの名前

- ローカル・ポリシーを必要とするすべての参照エンドポイントの名前

- ローカルにアタッチする必要があるポリシーの名前

ローカル・ポリシー・アタッチメントを必要とするコンポジットに関連付けられたAIASecurityConfigurationProperties.xmlによって、前述の情報を提供する必要があります。このファイルは、プロジェクト・アーティファクトとともにcomposite.xmlと同じフォルダに配置されます。

このファイルはソースで制御されます。

コンポジットにローカル・ポリシー・アタッチメントが必要ない場合、そのコンポジットに対するxmlファイルを定義は不要です。

例19-3に、サンプルのAIASecurityConfigurationProperties.xmlを示します。

ヒント:

composite.xml内のreference要素のbinding.wsで、port属性には次のフォームの値を指定します。

<binding.ws port="[wsdlに定義されているサービスのネームスペース]/V1#wsdl.endpoint(<サービス>/<ポート>"

ここで指定したPortNameがcomposite.xmlの<ポート>と同じであることを確認してください。

コンポジットに関する注意点は次のとおりです。

- サービス・エンドポイントに直接ポリシー・アタッチメントは必要ないが、参照エンドポイントには必要な場合、AIASecurityConfigurationProperties.xmlにservice要素を設定する必要はありません。

- 参照エンドポイントに直接ポリシー・アタッチメントは必要ないが、サービス・エンドポイントには必要な場合、AIASecurityConfigurationProperties.xmlにreference要素を設定する必要はありません。

- 複数のサービス・エンドポイントがあり、その1つのみにポリシーを直接アタッチする必要がある場合、AIASecurityConfigurationProperties.xmlに存在する必要があるのは1つのservice要素のみです。

- 複数の参照エンドポイントがあり、その1つのみにポリシーを直接アタッチする必要がある場合、AIASecurityConfigurationProperties.xmlに存在する必要があるのは1つのreference要素のみです。

例19-3 AIASecurityConfigurationProperties.xmlのサンプル

<?xml version="1.0" encoding="UTF-8"?>
<!--Note: the attribute 'compositeName' is the name of the AIA Service
composite preprended by {namespace of the AIA service as defined
in its wsdl} -->
<SecurityConfiguration xmlns="http://xmlns.oracle.com/fp/core/security/V1"
version="1.0"
compositeName="{http://xmlns.oracle.com/ABCSImpl/Siebel/Samples/
SamplesCreateCustomerSiebelReqABCSImpl/V1}SamplesCreateCustomerSiebel
ReqABCSImpl">
<!-- the following element is repeated for each service end point of this
Composite ,which requires a direct (local) policy attachement -->
<Service resourceType='SOA-Service' >
<!-- It is the service endpoint. It should be same as attribute 'name' of
element  'service' in composite.xml -->
<Name>SamplesCreateCustomerSiebelReqABCSImpl</Name>
<!-- This is the port name. For BPEL-based references, its value is Name of the
Porttype as given in the WSDL of this AIA service
For Mediator-based reference, this is [Name of the Porttype element as given in
the WSDL]_pt This example assumes a scenario when services and wsdls are coded
by following the AIA naming conventions.In other scenarios, the value might be
slightly different. Look at the hint below to come up with the correct value
for the element PortName.-->
<PortName>SamplesCreateCustomerSiebelReqABCSImpl</PortName>
<WSPolicies>
<WSPolicyName policyType ="authentication">oracle/wss_username_token_service_
policy</WSPolicyName>
</WSPolicies>
</Service>
<!-- the following element is repeated for each reference end point of this
Composite ,which requires a direct (local) policy attachement -->
<Reference resourceType = 'SOA-Reference'>
<!-- should be same as attribute 'name' of element  'reference' in
composite.xml -->
<Name>SamplesCustomerPartyEBS</Name>
<!-- port name.
For BPEL-based references, its value is name of the Porttype element as given
in the WSDL of this AIA service.
For Mediator-based reference, the value is [Name ofthe Porttype element as
given in the WSDL]_pt
-->
"This example assumes a scenario when services and wsdls are coded by following
the AIA naming conventions. In other scenarios, the value might be slightly
different. Look at the hint below to come up with the correct value for the
element PortName. Hint: In the composite.xml, for the binding.ws of the
'service' element, the attribute 'port' takes value of the following form.
<binding.ws port="[namespace of the service as defined in the
wsdl]/V1#wsdl.endpoint(<Service>/<Port>" Make sure that the PortName provided
by you here, is same as <Port> in the composite.xml"
<PortName>CustomerPartyEBS_pt</PortName>
<WSPolicies>
<WSPolicyName policyType ="authentication">oracle/wss_username_token_client_
policy</WSPolicyName>
<ConfigParams>
<!-- Param could be a repeating element- Future use only -->

<!-- APPSHORTNAME should be same as application's short name  -->

<!-- ServiceName and PortTypeName are as given in the APP's web service WSDL
-->
<Param paramName="csf-key">APPSHORTNAME_ServiceName_PortTypeName</Param>

</ConfigParams>
</WSPolicies>
</Reference>
</SecurityConfiguration>

19.7 アプリケーション・セキュリティ・コンテキスト

この項には次のトピックが含まれます:

- アプリケーション・セキュリティの概要

- 参加アプリケーションとABCS間でセキュリティ・コンテキストを交換する方法

- ABCSのアプリケーション・セキュリティ・コンテキストと標準セキュリティ・コンテキスト間のマッピング

- AppContextマッピング・サービスの使用

- セキュリティ・コンテキストの構造の理解

- 属性名の使用

- EBSおよびEBFを介した標準セキュリティ・コンテキストの伝播

- アプリケーション・セキュリティ・コンテキストの実装

19.7.1 アプリケーション・セキュリティの概要

Oracle AIAアプリケーション・セキュリティ・モデルを使用すると、AIAではポイントツーポイント・セキュリティを排除することによって、セキュリティ表現が異なる複数の参加アプリケーションを標準的な方法で統合できます。

各参加アプリケーションは、異なる時期に、異なるコンセプト、異なる認証および認可の実装を使用して開発されています。アプリケーションが統合される場合は、アプリケーション間で認証および認可情報を渡す必要があります。AIAアプリケーション・セキュリティ・コンテキストは、任意のアプリケーションを他のアプリケーションと統合できるように、様々な参加アプリケーション間でのアプリケーションの認証および認可情報の交換を標準化します。

図19-2に、高度なセキュリティ機能フローを示します。

図19-2 セキュリティ機能フロー

19.7.2 参加アプリケーションとABCS間でセキュリティ・コンテキストを交換する方法

アプリケーション・コンテキストは、メッセージを処理するためにリクエスタ・アプリケーションとプロバイダ・アプリケーション間で送信する必要がある情報です。これには、認証および認可情報なども含まれます。AIAでは認可情報の交換がアプリケーション・コンテキストで処理されますが、設計では他のコンテキスト情報の追加がサポートされています。

AIAでは、XACMLコンテキスト・リクエストが認可情報を表現する最適な標準であると判断されました。XACMLは、アクセス制御ポリシーを管理するためのOASIS標準です。XACMLはXMLをベースとして2003年にリリースされ、アクセス権のあるユーザーとアクセスできるリソースを記述するための共通の標準になるように設計されています。XACMLには、許可、拒否、中間(問合せのエラー)または適用不可のレスポンスを生成するポリシー言語と問合せ言語が含まれています。問合せ言語は、認可情報の交換のためにAIAが推奨するXACMLコンテキストで表現されます。

19.7.2.1 リクエスタ・アプリケーション

優先アプローチは、リクエスタ・アプリケーションがコンテキスト情報をXACMLリクエストとしてリクエスタABCSに送信することです。コンテキスト情報をXACMLリクエストに編成する機能がアプリケーションにない場合、参加アプリケーションはアプリケーション・コンテキスト情報をSOAPヘッダーで、またはビジネス・メッセージ・コンテンツの一部として送信します。

参加アプリケーションでSOAPインタフェースが使用されていない場合は、プロトコル固有アダプタの使用をお薦めします。このシナリオでは、アダプタがアプリケーション・コンテキストをカスタムの方法で受信し、参加アプリケーション固有のXACMLリクエストを準備してABCSに送信します。

図19-3に、リクエスタ・アプリケーション・フローを示します。

図19-3 リクエスタ・アプリケーション・フロー

19.7.2.2 プロバイダ・アプリケーション

優先アプローチは、プロバイダABCSがアプリケーション・コンテキストをXACMLリクエストとしてプロバイダ・アプリケーションに送信することです。プロバイダ・アプリケーションではXACMLリクエストを受信できないが、SOAPインタフェースがある場合、プロバイダABCSはアプリケーション・セキュリティ・コンテキストをSOAPヘッダーのカスタムXML形式で、またはビジネス・ドキュメントの一部として送信します。プロバイダ・アプリケーションでSOAPインタフェースがサポートされていない場合、プロバイダABCSはアプリケーション・コンテキストをXACMLリクエストの形式でアダプタ・サービスに送信し、アダプタ・サービスが、使用中のセキュリティ・メカニズムに必要な適切なセキュリティ・コンテキストを設定します。

図19-4に、プロバイダ・アプリケーション・フローを示します。

図19-4 プロバイダ・アプリケーション・フロー

19.7.3 ABCSのアプリケーション・セキュリティ・コンテキストと標準セキュリティ・コンテキスト間のマッピング

リクエスタABCSは、アプリケーション・セキュリティ・コンテキストをXACML形式で受信するか、またはXACML形式に変換します。リクエスタABCSは外部サービスをコールして、アプリケーション・セキュリティ・コンテキストを標準セキュリティ・コンテキストにマップします。ABCSは、アプリケーション・セキュリティ・コンテキストをXACML形式で渡し、アプリケーション・ニュートラル・セキュリティ・コンテキストをXACML形式で受信します。

19.7.4 AppContextマッピング・サービスの使用

アプリケーションごとに1つの外部サービスの使用をお薦めします。このサービスは、返される標準またはアプリケーション・コンテキストに必要な追加の値も入力します。このサービスは、XPath関数または次の名前のWebサービスとして実装できます。

- Request TransformToAppContext (EBMHeader)

- Request TransformToAppNeutralContext (Request)

例19-4に、サンプルのAppContextMappingServiceを示します。

このサービスは参加アプリケーションに対して実装され、そのアプリケーションを使用したすべての統合シナリオに対応します。

このサービスを実装するには、同一の場所に配置されたBPELの使用をお薦めします。ABCSでは、このサービスの他の実装をプラグインできるように、動的パートナ・リンクを使用してこのサービスをコールする必要があります。

TransformAppContextServiceは、サービス実装をAIAConfigプロパティ・ファイルからロードする際に使用するプロパティです。デフォルトでは、このプロパティは構成されておらず、デフォルトの実装が使用されます。

このサービスのデフォルトの実装は、DVMおよび相互参照に基づいています。新しいアプリケーションまたは統合シナリオを追加する場合は、DVMの値を必ず入力する必要がありますが、サービスの変更は不要です。

例19-4 AppContextマッピング・サービスの例

<definitions
targetNamespace="http://www.oracle.com/AIA/AppContextTransformService"
xmlns:corecom="http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V2"
xmlns:xacml-context="http://docs.oasis-open.org/xacml/access_
control-xacml-2.0-context-schema-cd-04.xsd"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:tacs="http://www.oracle.com/AIA/AppContextTransformService"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
<types>
<xsd:schema
targetNamespace="http://www.oracle.com/AIA/AppContextTransformService"
elementFormDefault="qualified">
<xsd:import namespace="http://docs.oasis-open.org/xacml/access_
control-xacml-2.0-context-schema-cd-04.xsd"
schemaLocation="http://[HOST:PORT]/AIAComponents/EnterpriseObjectLibrary/Release2
/Core/Common/V2/access_control-xacml-2.0-context-schema-cd-04.xsd" />
<xsd:import namespace="http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V2"
schemaLocation="http://[HOST:PORT]/AIAComponents/EnterpriseObjectLibrary/Release2
/Core/Common/V2/Meta.xsd" />
</xsd:schema>
</types>
<message name="Request">
<part name="Request" element="xacml-context:Request"/>
</message>
<message name="EBMHeader">
<part name="EBMHeader" element="corecom:EBMHeader"/>
</message>
<portType name="TransformAppContext">
<operation name="TransformToAppContext">
<input message="EBMHeader"              name="EBMHeader"/>
<output message="Request"/>
</operation>
<operation name="TransformToAppNeutralContext">
<input message="Request"              name="Request"/>
<output message="Request"/>
</operation>
</portType>
</definitions>

19.7.5 セキュリティ・コンテキストの構造の理解

XACMLリクエスト要素は、アプリケーション・コンテキスト構造に対するパラメータとして使用されます。このリクエスト要素には、認可情報に加えて、参加アプリケーション情報とコール側サービス情報が保持されます。

図19-5に、XACMLリクエストの構造を示します。

図19-5 XACMLリクエストの構造

図19-6に、XACMLサブジェクトの構造を示します。

図19-6 XACMLサブジェクトの構造

図19-7に、XACMLリソースの構造を示します。

図19-7 XACMLリソースの構造

図19-8に、XACMLアクションの構造を示します。

図19-8 XACMLアクションの構造

図19-9に、XACML環境の構造を示します。

図19-9 XACML環境の構造

例19-5に、セキュリティ・サービスに送信されるSEBL AppContext情報を示します。

例19-5 セキュリティ・サービスに送信されるSEBL AppContext情報の例

<AIAAppContext xmlns=http://www.oracle.com/AIA/AppContext>
<ServiceInfo>
<ServiceName>O2C2SeibelABCS</ServiceName>
</ServiceInfo>
<ParticipatingAppInfo>
<Name>Siebel</Name>
<Version>8.0</Version>
</ParticipatingAppInfo>
<Request xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:cd:04"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
urn:oasis:names:tc:xacml:2.0:context:schema:cd:04
http://docs.oasis-open.org/xacml/access_
control-xacml-2.0-context-schema-cd-04.xsd">
<Subject>
<Attribute AttributeId="siebel:user" DataType="xs:string">
<AttributeValue>SAdmin</AttributeValue>
</Attribute>
<Attribute AttributeId="siebel:org" DataType="xs:string">
<AttributeValue>siebl1</AttributeValue>
</Attribute>
</Subject>
<Resource>
</Resource>
<Action>
</Action>
<Environment/>
</Request>
</AIAAppContext>

19.7.6 属性名の使用

属性名には次のガイドラインを使用します。

- サービス情報の属性:
AIA:Service:Name - 変換サービスをコールするサービスの名前

- 参加アプリケーション情報の属性:
AIA:ParticipatingApp:Name - 参加アプリケーションの名前

AIA:ParticipatingApp:Version - 参加アプリケーションのバージョン

AIA:ParticipatingApp:SystemID - 参加アプリケーションの一意識別子

- アプリケーションの属性:
アプリケーションのすべての属性について、「アプリケーション名: 属性名」のネーミング規則の使用をお薦めします。

- アプリケーションのニュートラル属性:
アプリケーションのすべてのニュートラル属性について、AIAを接頭辞として使用することをお薦めします。これまでに識別されているアプリケーションのニュートラル属性は次のとおりです。

User: ユーザーを表します。

BusinessUnit: 組織または営業単位を表します。

19.7.7 EBSおよびEBFを介した標準セキュリティ・コンテキストの伝播

標準セキュリティ・コンテキストは、エンタープライズ・ビジネス・メッセージ(EBM)に挿入されます。EBMは様々なEBSおよびEBFを介して宛先ABCSに伝播されるため、セキュリティ・コンテキストは、EBMとともにターゲットABCSに伝播され、そこでターゲット・アプリケーションに伝播するために使用されます。

19.7.8 アプリケーション・セキュリティ・コンテキストの実装

次の項では、リクエスタ側とプロバイダ側の両方でアプリケーション・セキュリティ・コンテキストを実装するための高度なステップを示します。

19.7.8.1 リクエスタ側アプリケーション・セキュリティ・コンテキストの実装方法

リクエスタ側アプリケーション・セキュリティ・コンテキストを実装する手順は、次のとおりです。

1. アダプタを使用する場合は、アダプタ・サービスでアプリケーション・セキュリティ・コンテキスト情報をXACML形式に変換します。

2. アプリケーションでデータの情報を直接リクエスタABCSに送信する場合は、アプリケーション・セキュリティ・コンテキスト情報をXACML形式に変換します。

3. 新しい標準属性が必要な場合は、内部のアーキテクチャ・チームとともに作業します。

4. アプリケーション・コンテキスト・マッピング・サービスを実装します。

5. リクエスタABCSで、アプリケーション・マッピング・サービスをコールして、アプリケーションに固有なアプリケーション・コンテキスト情報をアプリケーションにニュートラルなアプリケーション・コンテキスト情報に変換します。

6. EBSをコールします。

19.7.8.2 プロバイダ側アプリケーション・セキュリティ・コンテキストの実装方法

プロバイダ側アプリケーション・セキュリティ・コンテキストを実装する手順は、次のとおりです。

1. アプリケーション・コンテキスト・マッピング・サービスを実装します。

2. プロバイダABCSで、アプリケーション・コンテキスト・マッピング・サービスをコールして、アプリケーションにニュートラルなアプリケーション・コンテキスト情報をアプリケーションに固有なアプリケーション・コンテキスト情報に変換します。

3. データの情報を直接プロバイダ・アプリケーションに送信する場合は、アプリケーション・セキュリティ・コンテキスト情報をXACMLデータから必要な形式に変換します。

4. アダプタを使用する場合は、アダプタ・サービスでアプリケーション・セキュリティ・コンテキスト情報をXACML形式から必要な形式に変換します。

20 エンドツーエンド統合フローの設計と作成に関するベスト・プラクティス

この章では、エンドツーエンド統合フローの設計と作成に関するベスト・プラクティスについて説明します。

注意:

コンポジット・ビジネス・プロセス(CBP)は、次のリリースから非推奨となります。人間/システム相互作用のモデル化には、BPMの使用をお薦めします。

この章の内容は次のとおりです。

- AIAプロセスの設計、開発および管理に関する一般的なガイドライン

- 効率的なBPELプロセスの作成

20.1 AIAプロセスの設計、開発および管理に関する一般的なガイドライン

この項には次のトピックが含まれます:

- XMLインスタンス・ドキュメントにある空の要素タグの解釈

- 完了したコンポジット・インスタンスのパージ

- XMLメッセージの構文/機能の検証

- スロットル機能に対するプロビジョニングの指定

- アーティファクトの集中管理

- 関心の分離

- ABCSコンポジット内のアダプタまたは個別のコンポジットとしてのアダプタ

- AIAの管理

20.1.1 XMLインスタンス・ドキュメントにある空の要素タグの解釈

XMLインスタンス・ドキュメントに空の要素タグが必要なのは、コンシューマが要素の値を無効にすることを送信者が意図している場合のみです。それ以外の場合、これらのタグは指定できません。このような重要でないタグの設定は、メモリーの消費量に影響を与え、アプリケーションのスケーラビリティに重大な影響を与えます。

エンタープライズ・ビジネス・メッセージ(EBM)には重大な要素のみを指定することをお薦めします。

他のアプリケーションと異なり、一部のアプリケーションでは、コンテンツを検査して重大なタグのみが指定されたXMLドキュメントを生成できます。ABCSにはアプリケーションとの密接な関係があるため、アプリケーションの動作に基づいて適切なスタイルを選択できます。変更の有無に関係なくすべての要素が含まれたアプリケーション・ビジネス・メッセージ(ABM)がアプリケーションで生成される状況でのリクエスタ・コネクタ・サービスでは、ABM内の空の要素は重要ではないと想定し、EBMの生成時には無視する必要があります。例20-1の最初のコード例に、この実行方法を示します。値の変更があった要素のみがABMに含まれている状況でのコネクタ・サービスでは、その要素の値をコンシューマが無効にすることが送信者の意図であるとして、空の要素の存在を処理する必要があります。例20-2に、このユースケースを示します。前述の方法でEBMを生成するサービス・リクエスタの場合、コンシューマのジョブは簡単になります。すべての要素が重要であると想定できるため、EBMを使用するABCSでは空の要素をスキップしません。例20-3に、重要な要素を含むメッセージの処理方法を示します。

例20-1の構造を使用するのは、ソース・アプリケーションのABMに、値の変更の有無に関係なくそのスキーマに定義されているすべての要素が含まれている場合です。この状況ではメモリー節約のために、AIAでは、空の要素は重要ではない要素と想定して無視します。

例20-2の構造を使用するのは、値の変更があった要素のみがソース・アプリケーションのABMに含まれている場合です。この状況での空の要素の存在は、重要である可能性があるため、AIAは無視しません。

前述のルールに従った場合、EBM内の空の要素はすべて重要であると想定できるため、EBMからABMへの変換時に無視されることはありません。従って、例20-3の構造を使用します。

例20-1 ABMからEBMへの変換

~--> <xsl:if test="ABMSourceElement/text()"> <EBMTargetElement> <xsl:value-of
select="ABMSourceElement"/> </EBMTargetElement> </xsl:if>

例20-2 ABMからEBMへの変換

~--> <xsl:if test="ABMSourceElement/text()"> <EBMTargetElement> <xsl:value-of
select="ABMSourceElement"/> </EBMTargetElement> </xsl:if>

例20-3 EBMからABMへの変換

~--> <xsl:if test="EBMSourceElement"> <ABMTargetElement> <xsl:value-of
select="EBMSourceElement"/> </ABMTargetElement> </xsl:if>

20.1.2 完了したコンポジット・インスタンスのパージ

完了したコンポジット・インスタンスを指定期間後にアーカイブしてクリーン・アップするプロセスの指定をお薦めします。

- 同期リクエスト/レスポンスに基づいて完了したコンポジット・インスタンスは、1か月後にSOAデハイドレーション・データ・ストアからパージしてください。

- データの同期に関連したコンポジット・インスタンスは、完了後3か月から4か月の間にパージしてください。

- コンポジット・ビジネス・プロセスは、完了後1年から2年の間にパージしてください。

この期間は会社のポリシーに基づいて変更されますが、なるべく早い時期にパージしてください。パージは、インスタンス・データのアーカイブより先に実行する必要があります。

詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のデータベースのサイズの増大の管理に関する項を参照してください。

20.1.3 XMLメッセージの構文/機能の検証

この項では、次の内容を説明します。

- 構文の検証

- データ/機能の検証

20.1.3.1 構文の検証

Webサービス・エンドポイントでは、ドキュメント・スタイルに従って検証パーサーの機能を使用し、構文の検証をビジネス文書で実行するためのランタイムをそれぞれのスキーマ定義に対して使用できます。

スキーマによって、Webサービス操作に送信可能なペイロードのデータ形状が指定されます。Webサービス・ハンドラがSOAPメッセージを受信すると、コールされている操作に関連するスキーマが、そのSOAPメッセージのコンテンツの検証に使用されます。

この検証にはパフォーマンスの影響があるため、本番環境では慎重に使用してください。範囲外のリクエスタからのサービス受信メッセージに対してはスキーマ検証のみの有効化をお薦めします。リクエスタが内部アプリケーションの場合でも、外部ソースからのメッセージに構文の検証が適用されるのは通常、実行時のみです。AIAレイヤー内の仲介サービスに対するスキーマ検証はオフにすることをお薦めします。

開発環境では、特定のテスト・フェーズ中はすべてのサービスに対するスキーマ検証をオンにし、サービスによって生成されたメッセージが構文的に有効であることの確認をお薦めします。

スキーマ検証を有効化する方法の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』を参照してください。

20.1.3.2 データ/機能の検証

検証はサービス・プロバイダが実行することをお薦めします。これは、プロバイダABCSまたはアプリケーション自体のいずれかで実行できます。

20.1.4 スロットル機能に対するプロビジョニングの指定

多くの場合、クロス機能ビジネス・プロセスの実装には、可用性などの異なる非機能的な特性および同時処理機能を備えたエンドポイント・システムの統合が必要です。計画または未計画の停止が原因でエンドポイントが使用できず、多くのシステムで大量のコンカレント・メッセージを処理できなくなる場合があります。大量のリクエストによるこれらのシステムへの負担は、結果としてターゲット・エンドポイントの失敗となり、統合全体にカスケード的な影響を与える場合があります。ほとんどの場合、リクエスタまたはプロバイダ・アプリケーションと相互作用する際は、キューを使用してストア・アンド・フォワード機能を実装することをお薦めします。これによって、顧客は、メッセージ・リクエストを特定のエンドポイントに渡す比率への制限設定に役立つスロットルを実装できます。

詳細は、「AIAメッセージ処理パターン」を参照してください。

20.1.5 アーティファクトの集中管理

エンタープライズ・ビジネス・オブジェクト、エンタープライズ・ビジネス・サービスWSDL、アプリケーション・ビジネス・メッセージ・スキーマ、ABCS WSDL、ドメイン値マップ、相互参照メタ・データなどの共有アーティファクトの管理を容易にするために、これらのアーティファクトはそれを使用するサービス機能とは関係なしに設計して実装することをお薦めします。これらのアーティファクトの管理と保持を個々のサービスの一部としないことをお薦めします。AIAのプログラミング・モデルでは、これらのアーティファクトの保持にMDSを使用することをお薦めします。

MDSを使用してアセットを集中管理する方法の詳細は、「AIAでのMDSの使用」を参照してください。

20.1.6 関心の分離

関心の分離はSOAのコアとなる原則です。これは、疎結合を、それが必要な統合フローに導入する際に役立ちます。ただし、アーキテクチャ・レベルのみでなく、実装レベルにも適用する必要があります。

開発時と実行時におけるサービス間の依存性の管理は、開発者がリクエスタとプロバイダABCサービスを実装している場合、困難なタスクです。1つの方法は分離です。この方法を使用すると、サービスの各関心を処理するコード内の相互依存性を最小化できます。

無効なSOAコンポジットを示すエラー・メッセージがサーバーの再起動後に表示される場合があります。これは、抽象WSDLを使用する必要がある場所で具象WSDLを参照していることが原因です。

新しいコンポジットXの最初のデプロイメント時にコンポジットYの具象WSDLを参照した場合は問題がありません。なぜでしょうか。コンポジットYは、コンポジットXのデプロイメント時には起動して稼働しています。問題はサーバーを再起動した際に発生しますが、これは、依存性を解決する正しい順序でコンポジットがアクティブ化される保証がないためです。コンポジットYの前にサービスXがアクティブ化された場合は、Yが停止しているため参照を解決できず、このため、Xのステータスは無効のままとなります。

実装からインタフェースを分離することから開始できます。

- 消費アーティファクトでは具象WSDLを直接使用しないでください。サービス・プロバイダ(ProviderABCS内のサービス・プロバイダ以外)の変更がある場合は、コンシューマの再デプロイが必要です。

- サービス・プロバイダのデプロイ済の具象WSDLを参照しないでください。プロバイダが使用できない場合は、コンシューマをコンパイルしたりデプロイすることはできません。
たとえば、アダプタ・サービスを使用するプロバイダABCSを作成する場合は、そのアダプタ・サービスの具象WSDLを直接参照し、消費プロバイダABCSを開発します。アダプタ・サービスが使用できない場合やデプロイされていない場合、プロバイダABCSをコンパイルまたはデプロイしている場合は、ここで障害となります。

- サービスの抽象WSDLの共通ディレクトリを導入し、集中的にアクセス可能なエンドポイントにそれらの抽象WSDLを格納します。

SOAでは、設計時にサービスを完全に分離する方法が用意されています。コンポジットが他のコンポジットを参照する際は、常に抽象WSDLを使用することをお薦めします。設計時にはすべて必要となるサービスのインタフェースが抽象WSDLで完全に記述されていることを確認してください。具象WSDLが後で必要となるのは、バインディング詳細(デプロイしたコンポジットを呼び出す方法に関する情報)を指定する実行時のみです。

図20-1に、抽象WSDL (設計時)と具象WSDL (実行時)の2つの部分で実際に構成された複数のSOAコンポジット間での参照を示します。

図20-1 SOAコンポジット間の参照

AIAでは、各サービスの抽象WSDLの格納にメタデータ・サービス(MDS)を使用します。このため、MDSがすべてのサービス・インタフェースに関する真のソースとなるため、コンポジットに冗長なコピーはありません。

20.1.6.1 MDSを使用した抽象WSDLと他の共有アーティファクトの中央記憶域

SOA Suite 11gでは、中央リポジトリのメタデータ・サービス(MDS)が導入され、設計時および実行時にアプリケーション(およびコンポジット)をバックアップします。MDSは、共有している共通のアーティファクトを設計時および実行時に格納して使用できるバージョン管理システムに類似しています。

AIAでは、MDSリポジトリを利用して、すべての開発者が共有する共通の設計時アーティファクトを格納します。AIAでは、集中的にアクセス可能なエンドポイントである抽象WSDLの共通ディレクトリがMDSに導入されました。

MDSに格納されるアーティファクトには、次の内容が含まれます。

- スキーマ - EBOスキーマおよびABMスキーマ

- WSDL - EBS、ABCS、アダプタ・サービス、CBPおよびEBFの抽象WSDL

- DVMおよびXREF

AIAコンポーネントは、様々なスキーマおよび様々なサービスが参照するWSDLを提示します。表20-1に構造を示します。

表20-1 AIAコンポーネントの構造

場所

アーティファクト

ApplicationConnectorServiceLibrary

様々なアプリケーション・ビジネス・コネクタ・サービス(ABCS)の抽象WSDL

ApplicationObjectLibrary

複数のアプリケーションおよびアプリケーション・ビジネス・オブジェクトのスキーマによって公開されたサービスのWSDL

B2BObjectLibrary

企業間(B2B)スキーマ

B2BServiceLibrary

様々なB2Bコネクタ・サービス(B2BCS)およびB2Bインフラストラクチャ・サービスの抽象WSDL

BusinessProcessServiceLibrary

コンポジット・ビジネス・プロセス(CBP)およびエンタープライズ・ビジネス・フロー(EBF)の抽象WSDL

EnterpriseBusinessServiceLibrary

エンタープライズ・ビジネス・サービス(EBS)の抽象WSDL

EnterpriseObjectLibrary

Oracle AIA標準モデルのスキーマ

InfrastructureServiceLibrary

インフラストラクチャ・サービスの抽象WSDL

Transformations

様々なサービス間で共有されるXSL

UtilityArtifacts

ユーティリティ・スキーマおよびWSDL

config

AIAConfigurationProperties.xmlおよびAIAEHNotification.xml

dvm

ドメイン値マップ

faultPolicies

すべてのサービスに適用可能なデフォルトのポリシー

xref

相互参照用のメタデータ

これらのアーティファクトのMDSへのアップロード方法およびMDS内での更新方法の詳細は、「AIAでのMDSの使用」を参照してください。

すべてのAIAサービスの抽象WSDLは、MDSに格納されています。コンシューマAIAサービス・コンポジット・アプリケーションは、参照サービスの抽象WSDLを使用して作成します。

MDSはどこにあり、アプリケーションではどのようにして参照しますか。

開発環境を構成してMDSをポイントします。構成ファイルは$application_home/.adf/META-INF/adf-config.xmlにあり、デフォルトでローカル(JDeveloperファイル・システム・ベースのMDS)をポイントしています。これを構成して、管理対象SOAサーバー上のMDSをポイントする必要があります。

詳細は、「AIA開発でのQuick Startの入手」を参照してください。

コンポジット内で、参照サービスはそのサービスの抽象WSDLによって定義されます。

例として、この項では前述のシナリオを使用します。

アダプタ・サービスの抽象WSDLを参照して、そのアダプタ・サービスを使用するプロバイダABCSを作成します。

表への影響

最初に、コンポジットのデプロイメント中に参照先サービスへの依存関係はありません。したがって、コンポジットに対するデプロイメント順序への依存関係はありません。参照先サービスは、他のサービスが参照できるように、最初にデプロイする必要はありません。これによって、サービス間で循環参照がある場合も解決されます。

コンポジットを設計した後は、タスクをいくつか実行する必要があります。外部サービスの参照に抽象WSDLを使用したため、コンポジットにはランタイム・バインディングが生成されていません。参照先サービスの場合は、コンポジットをソース・モードで開き、このバインディング情報(要素binding.wsの値)を指定する必要があります。

コンポジットのbinding.ws.port要素およびbinding.ws.location要素の入力方法の詳細は、「composite.xmlへのbinding.ws要素の挿入」を参照してください。

20.1.7 ABCSコンポジット内のアダプタまたは個別のコンポジットとしてのアダプタ

既存アプリケーションの移行で最も一般的な推奨方法は、1対1の移行です。これによって、古いアプリケーションのすべてのコンポーネントがSCAコンポジットになります。次のステップではSCAの利点を使用して、複数のSCAコンポジットを1つのコンポジットに結合します。複数コンポジットの結合は常に有利でしょうか。

アーキテクチャ上の判断は、SCAの作成方法によって異なります。SOA/SCAでは、すべてが再利用性に関係します。SCAをビジネス・フローに基づいて設計しているのか、技術的な視点から設計しているのかについて考えてみます。答えは、両者の間の適切なバランスの中にあります。

一度設計したサービスは、何回も再利用できる必要があります。この視点からは、小型のSCAを作成することになります。しかし、外部に公開する複数サービスを備えた大型のSCAを選択することもできます。この場合、SCAは比較的大型であるため、保守性が向上します。

必要なことは、サービスの定義と設計およびこれらのサービスを参照するコンポジットの作成です。結果として、一度設計されたサービスが何回も再利用されます。

ベスト・プラクティスとして、アダプタはABCSコンポジット内か、または個別のコンポジットとして開発するかという質問に戻った場合、図20-2に示すように、異なるコンポジット内のABCSとインタフェースしているアダプタを配置することをお薦めします。これは、同じトランスポート・アダプタ・サービスが複数のABCSで使用できる場合の推奨方法でもあります。

図20-2 異なるコンポジット内のABCSとインタフェースするアダプタの例

ただし、そのような再利用性が予測されない場合は、図20-3に示すように、ABCSおよびトランスポート・アダプタ・サービスが同じコンポジットにある代替の設計を使用しても構いません。

図20-3 同じコンポジット内にあるABCSおよびトランスポート・アダプタ・サービスの例

20.1.8 AIAの管理

開発して作成し、デプロイした後のAIAアーティファクトは、管理の対象となります。

EBO、EBS WSDL、ABMスキーマ、ABCS WSDL、DVM、XREFなどの共有アーティファクトの管理を可能にするために、これらのアーティファクトはそれを使用するサービスの機能とは関係なしに設計して実装することをお薦めします。これらは、サービス・アーティファクトとして処理せず、中央の場所で管理して保持する必要があります。

いくつかの項で前に説明したように、AIAでは、MDSを使用してアーティファクトを保持します。

注釈は、WSDLファイルの注釈とは別に、開発フェーズ時にコンポジットXMLファイルに挿入されます。コンポジット・ファイル内の注釈には、次の内容に関する詳細な情報が記述されています。

- AIAアーティアクトおよび他のAIAアーティアクトとの関係。

- デプロイメント時と実行時にコンポーネントを構成するために使用する、コンポジットレベルのディスクリプタ・プロパティ。

20.2 効率的なBPELプロセスの作成

この項では、BPELベースのプロセスを可能なかぎり最小に保持する方法に関する推奨事項を示します。

この項の内容は、次のとおりです。

- プログラミング言語ではなく「グルー」としてのBPELの使用

- グローバル変数の極力回避

- 大きなFlowNの回避

- 同期BPELプロセスに関する監査詳細の永続性の制御

- 多重呼出し不変ではないサービスの使用は絶対必要な場合のみに限定

- トランザクションのスコープの定義

- 同期BPELプロセス・サービス・コンポーネントに対する監査の無効化

- リクエスト/レスポンス・フローへのブレーク・ポイントなしアクティビティの組込み

20.2.1 プログラミング言語ではなく「グルー」としてのBPELの使用

BPELは編成言語であるため、主に、アプリケーション・システムによって公開される一連のサービスを編成するためのグルーとして使用する必要があります。BPELでは多様なプログラミング構成をサポートしていますが、これらの構成は、BPELプロセス内での複雑なプログラミング・ロジックの作成が目的ではありません。

20.2.1.1 BPELアクティビティの数を極力少数に維持

割当のかわりにXSLを使用

XMLメッセージに様々な要素を挿入するために複数のassignアクティビティを使用することは避けてください。変換の実行にはXSLの使用を考慮してください。XSLスクリプトの呼出しはコストを伴うため、8個から10個の割当を実行する必要がある場合のみ、メッセージの入力にXSLを使用することを考慮してください。

データ・セットの制約にXPath式を使用

指定のデータ配列(A)をループし、(条件Cを使用して)その配列の特定サブセットで操作する必要があるプログラミング・シナリオがあります。これを実行する簡単な方法は、Aにwhileループを設定し、次にそのwhileループ内に切替え条件Cを設定します。この方法では、常にすべての行をループすることになり、非効率となります。この状況に対するより効率的な方法は、多重インデックスの使用です。これによって、AをA[i]としてアクセスしてから条件を確認するかわりに、AをA[C][i]としてアクセスできるため、(iを使用して)条件Cを満たすAのすべての要素をループします。この方法で、BPELアクティビティの数を減らします。

20.2.1.2 大きなwhileループの回避

通常、whileループは次の内容を処理するために使用されます。

- XMLメッセージ内にある複数の反復する子インスタンス

- XMLメッセージ内にある大量の独立したオブジェクト・インスタンス

XMLメッセージ内にある反復する子インスタンス(maxOccurencesの制限なし)の処理にwhileループが使用されている状況では、そのwhileループ内のBPELアクティビティは、大量の反復数の可能性に注意しながら設計する必要があります。たとえば、100個の反復インスタンスがあるインスタンス・ドキュメントを処理する場合、whileループ内で単一のインスタンスを処理するアクティビティが50個あるとすると、実行時には急に5000個のアクティビティが作成される結果となります。

20.2.2 グローバル変数の極力回避

BPELのassignアクティビティ内では、可能なかぎりプロセス変数のかわりにローカル変数を使用してください。ローカル変数は、BPELプロセスのスコープ内に制限されます。これらの変数は、スコープを閉じた後はメモリーおよびデータベースから削除されます。一方、グローバル変数またはプロセス変数のライフ・サイクルは、インスタンスのライフ・サイクルと結び付けられています。これらの変数は、インスタンスが完了するまで、メモリー内またはディスク内にとどまります。したがって、プロセス変数またはグローバル変数より、ローカル変数をお薦めします。ただし、同じ変数がwhileループ内またはプロセス全体のすべての反復で使用されている場合は、1つのグローバル変数を作成してすべての反復でアクセスするほうが効率的です。

例20-4のBPELフラグメントは、ローカル変数の使用を示しています。

例20-4 ローカル変数の使用

<scope name="Scope_1">
<variables> <variable name="Invoke_CallprocessBillingMove_InputVariable"
messageType=

"sordmovsubabcs:ProcessFulfillmentOrderBillingBRMCommsMoveAddSubProcessRequest
Message"/>
<variable name="Invoke_CallprocessBillingMove_OutputVariable"
messageType=

"sordmovsubabcs:ProcessFulfillmentOrderBillingBRMCommsMoveAddSubProcessResponse
Message"/>
</variables>
<sequence name="Sequence_MoveAdd_SubProcess">
<assign name="Assign_Variable_Invoke_CallMoveAdd">
<copy>
<from variable="inputSubProcess"

query="/sordsubebo:ProcessFulfillmentOrderBillingBRMCommsSubprocessMessage"/>
<to variable="Invoke_CallprocessBillingMove_InputVariable"
part="payload"
query="/sordsubebo:ProcessFulfillmentOrderBillingBRMCommsSubprocessMessage"/>
</copy>
</assign>
<invoke name="Invoke_CallMove-Add_Subprocess"
partnerLink="ProcessFulfillmentOrderBillingBRMCommsMoveAddSubProcess"
portType="sordmovsubabcs:ProcessFulfillmentOrderBillingBRMCommsMoveAddSubProcess"
operation="processBillingMove"
inputVariable="Invoke_CallprocessBillingMove_
InputVariable"
outputVariable="Invoke_CallprocessBillingMove_
OutputVariable"/>
</sequence>
</scope>

20.2.3 大きなFlowNの回避

FlowNアクティビティがあるBPELプロセスの設計には慎重な考慮が必要です。Nの上限について十分な理解が必要です。フローで実行するアクティビティのタイプによっては、composite.xmlのnonBlockingInvokeプロパティをtrueに設定して、フローを非同期モードで実行するオプションを慎重に考慮する必要があります。

20.2.4 同期BPELプロセスに関する監査詳細の永続性の制御

auditLevelプロパティには、監査証跡のロギング・レベルを設定します。この構成プロパティは、永続プロセスと一時プロセスの両方に適用されます。このプロパティが制御するのは、プロセスによってログに記録される監査イベントの数です。監査イベントを記録すると、audit_level表およびaudit_details表へのデータベース挿入が増えるため、パフォーマンスに影響が出ることがあります。監査情報は、Oracle Enterprise Managerコンソールからプロセスの状態を確認する目的でのみ使用されます。

監査情報を保存しない場合は、Off値を使用します。監査レベルは、常にビジネス要件およびユースケースに従って選択してください。

同期BPELプロセスの場合は、インスタンス詳細は保持しないことをお薦めします。このためには、auditLevelプロパティをサービス・コンポーネント・レベルでOffに設定します。この一般的なガイドラインは、ユースケースに基づいて個々のサービス用にオーバーライドできます。

20.2.5 多重呼出し不変ではないサービスの使用は絶対必要な場合のみに限定

多重呼出し不変サービスは再試行できます。サービスを呼び出す回数に関係なく、同じ結果が再生成されます。悪影響はありません。

多重呼出し不変プロパティに対するデフォルト値は、trueです。多重呼出し不変プロパティをfalseに設定すると、プロセスはパートナ・リンクの実行後にデハイドレーションとなります。多重呼出し不変プロパティの構成に関する判断は、設計時と開発時に開発者が行う必要があります。

idempotentプロパティの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』を参照してください

20.2.6 トランザクションのスコープの定義

各反復ノードを処理する一連のアクティビティがXMLメッセージ内にある場合や反復ノードの数がきわめて多数の場合、トランザクションは、大きくなる傾向があります。

dspMaxThreadDepthプロパティに対するデフォルト値は、600に設定されています。トランザクションで実行するBPELアクティビティがこの数を超えた場合、BPELエンジンは暗黙的なコミットを自動発行してそのトランザクションを終了します。これは、アプリケーション・トランザクション・セマンティクスと一致しない場合があります。この問題は、このプロパティを任意の高い値に設定することで排除できる場合があります。この方法では、BPELが新しいしきい値に到達するずっと前に、統合開発者が定義したグローバル・トランザクションが終了することを想定しています。ほとんどの状況で、高い値へのプロパティの設定はトランザクションの完了に役立っています。ただし、アプリケーションの全体的なスケーラビリティに影響を与える可能性があります。このため、トランザクションのスコープは極力小さくするようにしてください。

20.2.7 同期BPELプロセス・サービス・コンポーネントに対する監査の無効化

中間プロセス・ブレークポイント・アクティビティがない同期BPELベースのサービスに対する監査は完全にオフにすることをお薦めします。

auditLevel

このプロパティは、監査証跡のロギング・レベルを設定し、プロセスによってログに記録される監査イベントの数を制御します。SOAインフラストラクチャ、BPELプロセス・サービス・エンジンおよびコンポジット・アプリケーションの各レベルで指定した値は、BPELプロセス・サービス・コンポーネント・レベルで設定した値によってオーバーライドされます。値をオーバーライドする対象は、中間プロセス・ブレークポイント・アクティビティがない同期BPELプロセスのみです。

このプロパティに次の値を設定することをお薦めします。

Off: BPELサービス・エンジンはペイロードを取得しません。フローの監査証跡でペイロード詳細は使用できません。他のBPELアクティビティのペイロード詳細は、assignアクティビティを除いて収集されます。多くの場合、通常の操作およびテストにはこのレベルが最適です。

例20-5に、SOAプロジェクトのcomposite.xmlファイルのbpel.config.auditLevelプロパティを適切な値に設定する方法を示します。

例20-5 composite.xmlのbpel.config.auditLevelプロパティの設定

<component name="BPELProcess">
<implementation.bpel src="graphics/BPELProcess.bpel" />
<property name="bpel.config.auditLevel">Off</property>
</component>

20.2.8 リクエスト/レスポンス・フローへのブレーク・ポイントなしアクティビティの組込み

同期リクエスト/レスポンス・メッセージ交換パターンを実装しているBPELサービスには、midprocess receive、wait、onMessage、onAlarmなどのブレークポイント・アクティビティを指定しないことをお薦めします。

同様に、同期リクエスト/レスポンス・メッセージ交換パターンを実装しているメディエータ・サービスには、パラレル・ルーティング・ルールを指定しないでください。リクエスト/レスポンス・メッセージ交換パターンを実装しているESBルーティング・サービスには、非同期モードで呼び出したターゲット・サービスを指定しないでください。

21 AIA開発に関するOracle AIAネーミング標準

この項では、AIA開発用の様々なAIAコンポーネントのネーミング標準に関するガイドラインの概要を説明します。

注意:

コンポジット・ビジネス・プロセス(CBP)は、次のリリースから非推奨となります。人間/システム相互作用のモデル化には、BPMの使用をお薦めします。

この章の内容は次のとおりです。

- ガイドライン

- コンポジット

- コンポジット・ビジネス・プロセス

- エンタープライズ・ビジネス・サービス

- エンタープライズ・ビジネス・フロー

- アプリケーション・ビジネス・コネクタ・サービス

- JMSおよびアダプタ

- DVMおよび相互参照

- BPEL

- カスタムJavaクラス

- パッケージ構造

- デプロイメント計画

21.1 一般的なガイドライン

目標は、各アーティファクトの意図が明白であることと、そのアーティファクトに関連するテキストを使用して、指定のスペース制約内でできるかぎり詳細な情報を伝えることです。適用可能な場合は常に、次の内容を適用してください。

- 略語は避けてください。
略語は、あいまいさを招く場合があります。使用する名前は省略せずに記述する必要があります。オブジェクト名は、長くなりすぎる場合を除いて略さないでください。

- アーティファクト名は英数字にしてください。
名前は、次の規則に従って英数字のみで構成する必要があります。

名前を構成する語は、空白なしのアッパー・キャメルケース方式で連結してください。

例: Purchase Order

名前に数字を使用することは、ビジネス上の意味を持たせる場合を除いて、避けてください。

空白、「-」、「_」、「.」、「$'」、「%」、「#」、[]などの特殊文字は使用しないでください。

- あいまいさを回避するために、名前にはアーティファクト・タイプを指定してください。
異なる複数のアーティファクト・タイプに同じ名前を使用する場合は、タイプを示す接尾辞を追加します。アーティファクトの識別は、タイプの指定によって容易になります。

<アーティファクト名><タイプ接尾辞>

例: InvoiceEBO、InvoiceEBOType、InvoiceEBM、InvoiceEBMType。

- 名前付きアーティファクトに対する合計パス長の最大文字数は17000です。
Windowsなど、一部のオペレーティング・システムではファイル名に対して255文字の制限があります。完全なネットワーク・ディレクトリまたはURLを使用した接頭辞用に多少の余裕を残します。

21.1.1 XMLネーミング標準

次の基準は、XMLのネーミングおよび設計規則であるUN/CEFACTに基づいています。

21.1.1.1 一般的なネーミング標準

次の一般的なネーミング標準に従います。

- 属性のネーミングにはローワー・キャメルケースを使用してください。
例: <xsd:attribute name="unitCode"/>

- 要素およびタイプのネーミングにはアッパー・キャメルケースを使用してください。
例: <xsd:element name="UnitOfMeasure"/> <xsd:complexType name="InvoiceEBOType"/>

- 概念自体が複数形でない限り、名前は単数形にしてください。
たとえば、反復要素には単数形の名前を指定してください。

- 名前には、空白、「-」、「_」、「.」、「$」、「%」、「#」などの特殊文字を含めないでください。

- 名前に数字を指定することは避けてください。
重要度を伝える必要から数字が使用される場合があります。

- 複合タイプ名は、要素からタイプが認識できるように、接尾辞Typeで終了してください。
例: <xsd:complexType name="InvoiceEBOType"/>

- 単純タイプ定義の名前は、ルート要素の名前に接尾辞ContentTypeを付けた名前にしてください。
例: <xsd:simpleType name="PhoneNumberContentType">

21.1.1.2 一般的なネームスペースのネーミング標準

次に、一般的なネームスペースのネーミング規則を示します。次の各項では、特にEBSとABCSに関するネーミング規則も含めて、さらに詳細に説明します。

- すべてのネームスペースは、http://xmlns.oracle.com/で開始する必要があります。

- エンタープライズ・ビジネス・オブジェクト(EBO)およびエンタープライズ・ビジネス・メッセージ(EBM)で使用するネームスペースは、http://xmlns.oracle.com/EnterpriseObjects/で開始します。
例: http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/Invoice/V1

- 外部向けサービスに使用するネームスペースは、http://xmlns.oracle.com/EnterpriseServices/で開始する必要があります。
例: http://xmlns.oracle.com/EnterpriseServices/Core/Invoice/V1 http://xmlns.oracle.com /EnterpriseServices/Industry/Telco/Invoice/V1

- バージョン付きアーティファクトのネームスペースには、versionの略語であるVを付けたメジャー・バージョン番号を接尾辞として指定する必要があります。
例: http://xmlns.oracle.com/ EnterpriseObjects/Core/EBO/Invoice/V1

- ネームスペースの構造は、カプセル化するタイプの分類に密接に対応している必要があります。
例: 全業種向け: http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/Invoice/V1。

Telco向け: http://xmlns.oracle.com/EnterpriseObjects/Industry/Telco/EBO/Invoice/V1。

- ABCS内で生成されたアーティファクトのネームスペースは、http://xmlns.oracle.com/ABCS/で開始する必要があります。

- スキーマ・ファイルにスキーマをインポートまたは含める場合、そのスキーマの場所には必ず相対パスを使用する必要があります。
例: <xsd:importnamespace="http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/Invoice/V1" schemaLocation="../../../../Core/EBO/Invoice/InvoiceEBO .xsd"/>

- ネームスペースの接頭辞は、そのネームスペースの最小6つの小文字による略語である必要があります。
この略語は、使用されているコンテキスト内で説明的であり、明白である必要があります。

- EBOとEBMのネームスペース接頭辞は、使用するアプリケーションやテクノロジに関係なく次の標準に従う必要があります。
ns1、ns2などの自動生成される接頭辞は使用しないでください。xsdやxsiなどの標準のネームプレースに対して自動生成される接頭辞は使用できます。

表21-1に、ネームスペース接頭辞に関連するネームスペース・パターンおよびファイルの詳細を示します。

表21-1 ネームスペース接頭辞

接頭辞

ネームスペース・パターン

ファイル

corecomcust

http://xmlns.oracle.com/EnterpriseObjects/Core/Custom/Common/V1

CustomCommonComponents、CustomReferenceComponents

coreinvcust

http://xmlns.oracle.com/EnterpriseObjects/Core/Custom/EBO /Invoice/V1

CustomInvoiceEBO

corecom

http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V1

CommonComponents.Reference Components

coreinv

http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/Invoice/V1

InvoiceEBO

coreinv

http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/Invoice/V1

InvoiceEBM

telcocomcust

http://xmlns.oracle.com/EnterpriseObjects/Industry/Telco/Custom/Common/V1

CustomCommonComponents、CustomReferenceComponents

telcoinvcust

http://xmlns.oracle.com/EnterpriseObjects/Industry/Telco/Custom/EBO/Invoice/V1

CustomInvoiceEBO

telcocom

http://xmlns.oracle.com/EnterpriseObjects/Industry/Telco/Common/V1

CommonComponents.Reference Components

telcoinv

http://xmlns.oracle.com/EnterpriseObjects/Industry/Telco/EBO/Invoice/V1

InvoiceEBO

telcoinv

http://xmlns.oracle.com/EnterpriseObjects/Industry/Telco/EBO/Invoice/V1

InvoiceEBM

21.1.1.3 参加アプリケーション名

参加アプリケーション名がアーティファクト名の一部の場合は、アッパー・キャメルケースの短縮名を使用してください。略語が必要な場合は、大文字の略語を使用してください。

表21-2に、参加アプリケーションに使用する短縮名および略語のリストを示します。

表21-2 参加アプリケーション名に対する短縮名および略語

Application

短縮名

略語

Oracle E-Business Suite

Ebiz

EBIZ

Oracle Siebel

Siebel

SEBL

Oracle PeopleSoft

PeopleSoft

PSFT

Oracle JD Edwards Enterprise One

JDEOne

JDE1

Oracle JD Edwards World

JDEWorld

JDEW

Oracle Transportation Management Suite

Logistics

LOGIS

Oracle Telephony @Work

Telephony

TELE

Oracle Demantra

Demantra

DMTR

Oracle Communications Billing and Revenue Management

Portal

PORTAL

Oracle Retail Applications

Retek

RETEK

21.2 コンポジット

コンポジットはSCAに対するデプロイメントの単位で、複数のサービス・コンポーネントが含まれています。

コンポジットの名前はOracle Application Integration Architecture (AIA)アーティファクトの名前と同じです。

コンポジットは、次のAIAアーティファクトに対して作成されます。

- コンポジット・ビジネス・プロセス

- エンタープライズ・ビジネス・フロー

- エンタープライズ・ビジネス・サービス

- アプリケーション・ビジネス・コネクタ・サービス

- ユーティリティ・サービス

例: SalesOrderOrchestrationProcess、InterfaceCustomerToFulfillmentEBF、CreateCustomerEBS、CreateOrderSiebelReqABCSImpl、AsyncErrorHandlerService

21.3 コンポジット・ビジネス・プロセス

コンポジット・ビジネス・プロセスは、長時間実行のSOA BPEL編成プロセスです。

表21-3に、コンポジット・ビジネス・プロセスに関するネーミング標準の詳細を示します。

表21-3 コンポジット・ビジネス・プロセスに関するネーミング標準

アーティファクト

名前

例

サービス名(WSDL内)

[オプションの業種] [動詞][EBO名]CBP

OrchestrateSalesOrderCBP、TelcoResolveComplaintCBP

ネームスペース

http://xmlns.oracle.com/CompositeProcess/{Core/またはIndustry/[業種名]}/{EBO名}/V{バージョン番号}

http://xmlns.oracle.com/CompositeProcess /Core/SalesOrder/V1

http://xmlns.oracle.com/ CompositeProcess /Industry/Telco/SalesOrder/V1

ネームスペース接頭辞

ネームスペース接頭辞の標準に従います。

coreordprocess、telordprocess、…

WSDL

[サービス名].wsdl

OrchestrateSalesOrderCBP.wsdl

TelcoResolveComplaintCBP.wsdl

WSDLメッセージ

リクエスト・メッセージ: [動詞][EBO名]ReqMsg　レスポンス・メッセージ: [動詞][EBO名]RespMsg

OrchestrateSalesOrderReqMsg、OrchestrateSalesOrderRespMsg

WSDLポート・タイプ

[サービス名]Service

OrchestrateSalesOrderCBPService、TelcoResolveComplaintCBPService

WSDLポート・タイプ操作

[動詞][EBO名]

OrchestrateSalesOrder

BPELフロー名

[サービス名]V[バージョン番号]

ProcessSalesOrderCBP、TelcoVerifyCustomerCBPV2

21.4 エンタープライズ・ビジネス・サービス

エンタープライズ・ビジネス・サービス(EBS)はルーティング・ルールを備えたSOAメディエータのルーティング・サービスで、適切なコンポジット・ビジネス・プロセス、エンタープライズ・ビジネス・フローおよびアプリケーション・ビジネス・コネクタ・サービスを呼び出します。

表21-4に、エンタープライズ・ビジネス・サービスに関するネーミング標準の詳細を示します。

表21-4 エンタープライズ・ビジネス・サービスに関するネーミング標準

アーティファクト

名前

例

サービス名[WSDL内]

[オプションの業種名][EBO名]EBS

OrderEBS、CustomerEBS、TelcoInvoiceEBS

ネームスペース

http://xmlns.oracle.com/EnterpriseServices/{Core/またはIndustry/[業種名]}/{EBO名}/V{バージョン番号}

http://xmlns.oracle.com/EnterpriseServices/Industry/Telco/Invoice/V1

http://xmlns.oracle.com/EnterpriseServices/Core/Invoice/V2

ネームスペース接頭辞

ネームスペース接頭辞の標準に従います。

coreinv、telcoinv、…

WSDL

[サービス名].wsdl

CreateOrderEBS.wsdl、UpdateCustomerEBS.wsdl、TelcoProcessInvoiceEBS.wsdl

WSDLメッセージ

リクエスト・メッセージ: [動詞][EBO名]ReqMsg

レスポンス・メッセージ: [動詞][EBO名]RespMsg

CreateOrderReqMsg CreateOrderRespMsg

WSDLポート・タイプ

リクエスト/レスポンスEBSまたはリクエスト専用EBS: [業種名][サービス名][バージョン番号]

一方向コールでのレスポンスEBS: [業種名][サービス名]Response[バージョン番号]

CreateOrderEBS、CreateOrderEBSResponse、TelcoProcessInvoiceEBS、TelcoProcessInvoiceEBSResponse

WSDLポート・タイプ操作

リクエスト/レスポンスEBSまたはリクエスト専用EBS: [動詞][EBO名]

一方向コールでのレスポンスEBS: [動詞][EBO名]Response

CreateOrder、CreateOrderResponse

メディエータ・ルーティング・サービス名

[サービス名]V[バージョン番号]

CreateOrderEBS、CreateOrderEBSV2、UpdateCustomerEBSV2、TelcoProcessInvoiceEBSV2

21.5 エンタープライズ・ビジネス・フロー

表21-5に、主に複数のエンタープライズ・ビジネス・サービスとの相互作用で使用するBPELフローに関するネーミング標準の詳細を示します。

表21-5 エンタープライズ・ビジネス・フローに関するネーミング標準

アーティファクト

名前

例

サービス名(WSDL内)

[オプションの業種] [動詞][EBO名]EBF

ProcessOrderEBF、TelcoVerifyCustomerEBF

ネームスペース

http://xmlns.oracle.com/EnterpriseFlows/{Core/またはIndustry/[業種名]}/{EBO名}/V{バージョン番号}

http://xmlns.oracle.com/EnterpriseFlows /Core/Order/V1

http://xmlns.oracle.com/ EnterpriseFlows /Industry/Telco/Order/V1

ネームスペース接頭辞

ネームスペース接頭辞の標準に従います。

coreordflow、telordflow、…

WSDL

[サービス名].wsdl

ProcessOrderEBF.wsdl、TelcoVerifyCustomerEBF.wsdl

WSDLメッセージ

リクエスト・メッセージ: [動詞][EBO名]ReqMsg

レスポンス・メッセージ: [動詞][EBO名]RespMsg

ProcessOrderReqMsg、ProcessOrderRespMsg

WSDLポート・タイプ

[サービス名]Service

ProcessOrderEBFService、VerifyAccountEBFService

WSDLポート・タイプ操作

[動詞][EBO名]

ProcessOrder

BPELフロー名

[サービス名]V[バージョン番号]

ProcessOrderEBF、TelcoVerifyCustomerEBFV2

21.6 アプリケーション・ビジネス・コネクタ・サービス

アプリケーション・ビジネス・コネクタ・サービスは、リクエスタとプロバイダという2つのカテゴリで構成されています。

21.6.1 リクエスタ・アプリケーション・ビジネス・コネクタ・サービス

リクエスタABCSは、クライアント・アプリケーションからのリクエストに対処して処理し、EBSに委任するサービスです。

表21-6に、リクエスタABCSに関するネーミング標準の詳細を示します。

表21-6 リクエスタABCSに関するネーミング標準

アーティファクト

名前

例

サービス名(wsdl内)

[動詞][アプリケーション・エンティティ名][短縮アプリケーション名][オプションの業種]ReqABCSImpl

CreateOrderSiebelReqABCSImpl UpdateOrderSiebelTelcoReqABCSImpl CreateCustomerPortalTelcoReqABCSImpl

ネームスペース

http://xmlns.oracle.com/ABCSImpl/{参加アプリケーション名}/{Core/またはIndustry/[業種名]}/{アプリケーション・エンティティ名}/V{バージョン}

http://xmlns.oracle.com/ABCSImpl/Siebel/Core/Order/V1 http://xmlns.oracle.com/ABCSImpl/Portal/Industry/Telco/ Customer/V2

ネームスペース接頭辞

ネームスペース接頭辞の標準に従います。

abcsimplsieblelinv、abcsimplportalprod、…

WSDL

[サービス名].wsdl

CreateOrderSiebelReqABCSImpl.wsdl UpdateOrderSiebelTelcoReqABCSImpl.wsdl CreateCustomerPortalTelcoReqABCSImpl.wsdl

WSDLメッセージ

リクエスト・メッセージ: 動詞[ABO名]ReqMsg

レスポンス・メッセージ: 動詞[ABO名]RespMsg

CreateOrderReqMsg、CreateOrderRespMsg UpdateOrderLinesReqMsg、UpdateOrderLinesRespMsg

WSDLポート・タイプ

BPEL: [サービス名]Service

メディエータ: [サービス名]

CreateOrderSiebelReqABCSImplService UpdateOrderSiebelReqABCSImpl

WSDLポート・タイプ操作

動詞[ABO名]

アプリケーションで必要な機能を反映した自己説明型である必要があります。

UpdateOrder、GetOrderLines、…

BPELフロー名/メディエータ・ルーティング・サービス名

[サービス名]V[バージョン番号]

CreateOrderSiebelReqABCSImplV2Process

UpdateOrderSiebelTelcoReqABCSImplProcess CreateCustomerPortalTelcoReqABCSImplProcess

21.6.2 プロバイダ・アプリケーション・ビジネス・コネクタ・サービス

プロバイダABCSは、エンタープライズ・ビジネス・サービスの実装です。

表21-7に、プロバイダABCSに関するネーミング標準の詳細を示します。

表21-7 プロバイダABCSに関するネーミング標準

アーティファクト

名前

例

サービス名(WSDL内)

[動詞][アプリケーション・エンティティ名][短縮アプリケーション名][オプションの業種]ProvABCSImpl

CreateOrderSiebelProvABCSImpl UpdateOrderSiebelTelcoProvABCSImpl CreateCustomerPartyTelcoPortalProvABCSImpl

ネームスペース

http://xmlns.oracle.com/ABCSImpl/{参加アプリケーション名}/{Core/またはIndustry/[業種名]}/{アプリケーション・エンティティ名}/V{バージョン}

http://xmlns.oracle.com/ABCSImpl/Siebel/Core/Order/V1 http://xmlns.oracle.com/ABCSImpl/Portal/Industry/Telco/ CustomerParty/V2

ネームスペース接頭辞

ネームスペース接頭辞の標準に従います。

abcsimplsieblelinv、abcsimplportalprod、…

WSDL

[サービス名].wsdl

CreateOrderSiebelProvABCSImpl.wsdl UpdateOrderSiebelTelcoProvABCSImpl.wsdl CreateCustomerPartyTelcoPortalProvABCSImpl.wsdl

WSDLメッセージ

リクエスト・メッセージ: [動詞][ABO名]ReqMsg

レスポンス・メッセージ: [動詞][ABO名]RespMsg

CreateOrderReqMsg、CreateOrderRespMsg

WSDLポート・タイプ

BPEL: [サービス名]Service

メディエータ: [サービス名]

CreateOrderSiebelProvABCSImplService UpdateOrderSiebelProvABCSImpl

WSDLポート・タイプ操作

[動詞][ABO

対応するEBSによって公開された操作と一致する操作を1つ指定します。

UpdateOrder、getOrderLines、…

BPELフロー名/メディエータ・ルーティング・サービス名

[サービス名]V[バージョン番号]

CreateOrderSiebelProvABCSImplV2Process

UpdateOrderSiebelTelcoProvABCSImplProcess CreateCustomerPortalTelcoProvABCSImplProcess

21.7 JMSおよびアダプタ

表21-8に、JMSおよびアダプタに関するネーミング標準の詳細を示します。

表21-8 JMSおよびアダプタに関するネーミング標準

アーティファクト

名前

例

JMSストア、JMSサーバー、JMSモジュール

SOAコア拡張機能によって作成されたデフォルト構成を使用します

N/A

キューまたはトピック接続ファクトリのJNDI名

eis/wlsjms/AIA<アプリケーション名>CFOReis/wlsjms/AIACommonCF (EBSまたはEBFの前後のマイルストンとして使用されている共通キューまたはトピックの場合)。XA接続ファクトリの場合は、eis/wlsjms/AIA<アプリケーション名>XACFの規則に従います

eis/wlsjms/AIAPeopleSoftCF。XAの場合: eis/wlsjms/AIAPeopleSoftXACF。Oracle SOAコア拡張機能では、指定の接続ファクトリ名に「jms/aia」を追加することで、JMSモジュール・レベル接続ファクトリが自動的に作成されます。例:jms/aia/AIAPeopleSoftCF

キュー名またはトピック名

AIA_<アプリケーション名> <EBO/ABO名><オプションの業種>JMSQueueV<バージョン番号>AIA_<アプリケーション名> <EBO/ABO名><オプションの業種>JMSTopicV<バージョン番号>

AIA_PeopleSoftCurrencyExchangeJMSQueue

AIA_SiebelCustomerPartyJMSTopicV1

注意:

- ここの「JMSQueue」は、デフォルトで「WLS JMS Queue」を示します。他のJMSプロバイダの場合は,　AqJMSQueueやTibJMSQueueなどの接頭辞を追加してください。

- キュー/トピック名を考え出す場合、次のユースケースでは、意味のある短縮名や略語を使用できます。
長いアプリケーション/業種名。長いEBO/ABO名。

字数に制限があるJMSプロバイダ。たとえば、AQ JMSプロバイダには、キュー名について24文字の制限があります。

- 前述の場合は、「JMSQueue」および「JMST」のかわりに短縮名「JMSQ」を使用してください。キュー名に関するJMSプロバイダの最大文字制限に基づき、アプリケーション/業種とEBO/ABOの短縮名や略語に従って、適切な意味のあるキュー名やトピック名を考え出すことをお薦めします。例: AIA_PSFTCurExchangeJMSQ、AIA_SEBLCustPartyJMSTV1

- Oracle SOAコア拡張機能では、デプロイメント時に「jms/aia」を追加することで、JMSモジュール下のキューやトピックのJNDI名が作成されます。例: jms/aia/ AIA_SiebelCustomerPartyJMSTopicV1

エラー・キュー

<キュー名>_ErrorQ

FPスクリプトでは、注釈のリソース名を使用してキュー/トピック名を取得し、次に接尾辞として「_ErrorQ」を追加します。

例: 「AIASalesOrderQueue」の場合、FPでは「AIASalesOrderQueue_ErrorQ」が生成されます。

AQJMSプロバイダの表名

AIA_<アプリケーション><ABO/EBO><オプションの業種>JMSQTABV[バージョン番号]

AIA_SiebelCustomerProvJMSQTAB

AIA_EbizOrderProvJMSQTABV2

21.7.1 AQ JMS (追加属性)

表21-9に、AQ JMS追加属性に関するネーミング標準の詳細を示します。

表21-9 AQ JMS追加属性に関するネーミング標準

アーティファクト

名前

例

AQJMSプロバイダでのキューおよびキュー表作成に関するデータベース・ユーザー/スキーマ

JMSUSER

N/A

AQJMSプロバイダの表名

AIA_<アプリケーション><ABO/EBO><オプションの業種>JMSQTABV[バージョン番号]

AIA_SiebelCustomerProvJMSQTAB

AIA_EbizOrderProvJMSQTABV2

21.7.2 アダプタ・サービスのネーミング

表21-10に、アダプタ・サービスに関するネーミング標準の詳細を示します。

表21-10 アダプタ・サービスに関するネーミング標準

アーティファクト

名前

例

トランスポート・アダプタ・サービス(ファイル/FTP)

<オプションのアプリケーション短縮名><オプションの動詞><EBO/ABO名><オプションの業種><リソース・プロバイダ><操作>V<バージョン番号>

E1PurchaseOrderFileReadAdapter

E1PurchaseOrderFileWriteAdapterV1

CRMODPOFtpGetAdapter

CRMODPOFtpPutAdapterV1

AQJMS/WLSJMSコンシューマ・アダプタ・サービス

<オプションのアプリケーション短縮名><オプションの動詞><EBO/ABO名><オプションの業種><リソース・プロバイダ><操作>V<バージョン番号>

PSFTupdateCurrencyExchange

AQJMSCons

SiebelCustomerPartyJMSConsumerV1

AQJMS/WLSJMSプロデューサ・アダプタ・サービス

<オプションのアプリケーション短縮名><オプションの動詞><EBO/ABO名><オプションの業種><リソース・プロバイダ><操作>V<バージョン番号>

PSFTupdateCurrencyExchange

AQJMSProd

SiebelCustomerPartyJMSProducerV1

アプリケーション/DBアダプタ

<オプションの動詞><EBO/ABO名><オプションの業種><アプリケーション短縮名><リソ－ス・プロバイダ>V<バージョン番号>

SyncCurrencyExchangeListEBiz

DBAdapter

CreateCustomerEBizAppAdapterV1

UpdatePriceListEBizEventAdapter

21.7.3 参加アプリケーション・サービス

表21-11に、参加アプリケーション・サービスに関するネーミング標準の詳細を示します。

表21-11 参加アプリケーション・サービスに関するネーミング標準

アーティファクト

名前

名前

アプリケーションで公開された名前と同じ名前でメディエータに登録されています。例: BRMCUSTService、Account_BS

ネームスペース

アプリケーションで使用されているネームスペースに従います。

ネームスペース接頭辞

ネームスペース接頭辞の標準に従います。

WSDL

アプリケーションで公開されているWSDL名に従います。

WSDLメッセージ

アプリケーションWSDLに公開されているメッセージ名に従います。

WSDLポート・タイプ

アプリケーションWSDLに公開されているポート・タイプに従います。

WSDLポート・タイプ操作

アプリケーションWSDLに公開されている操作名に従います。

WSDLバインディング

WSDLに従います

WSDLサービス

アプリケーションWSDLに公開されているサービス名に従います。

21.8 DVMおよび相互参照

この項では、次の内容に関するネーミング標準を説明します。

- DVM

- 相互参照

21.8.1 DVMs

DVMを作成するときは、次のネーミング標準に従ってください。

21.8.1.1 マップ名

マップ名:

- オブジェクト名で開始する必要があります。
これによって、特定のオブジェクトに属しているマップを識別できます。オブジェクト名はEBO名と同じにしてください。

- ドメイン値マッピングが必要な要素名が後に続く必要があります。

- 大文字である必要があります。

パターン: {オブジェクト名}_{要素名}

例: CUSTOMERPARTY_ACCOUNTTYPECODE、INVOICE_REJECT_REASON、SALESORDER_CARRIER_TYPECODE

DVMファイル名の例: CUSTOMERPARTY95ACCOUNTTYPECODE、INVOICE95REJECT95REASON、SALESORDER95CARRIER95TYPECODE

21.8.1.2 マップ列名

マップ列名:

- 列値が示す参加アプリケーション・インスタンス名の略称に設定する必要があります。この名前はアプリケーション名とそのバージョンか、同じバージョンの同じアプリケーションが2つ統合されている場合はインスタンス名になります。名前は{アプリケーションの略称}_{順序番号}の形式とし、統合プラットフォーム全体にわたるアプリケーション・インスタンスに対する一意の識別子である必要があります。同じアプリケーションの複数のインスタンスは、順序番号によって一意に識別されます。

- 大文字である必要があります。

- COMMONという名前の列を必ず追加する必要があります。この列には、プラットフォーム内のEBOで使用される値が格納されます。

例: COMMON、EBIZ_01、PSFT_01、SEBL_02、SEBL_03、PORTAL_01、IFLEX_01

21.8.2 相互参照

相互参照表内に相互参照の仮想表を作成するときは、次のネーミング標準に従ってください。

21.8.2.1 表名

表名:

- 名前は48文字以下である必要があります。

- オブジェクト名で開始する必要があります。
これによって、特定のオブジェクトに属している相互参照を識別できます。オブジェクト名はEBO名と同じにしてください。

- 相互参照が必要な要素名が後に続く必要があります。
48文字を超える場合は、適切に略してください。

- 大文字である必要があります。

パターン: {オブジェクト名}_{要素名}

例: ORDER ORDERID、INVOICE INVOICEID、CUSTOMER ID

21.8.2.2 列名

列名:

- 名前は48文字以下である必要があります。

- 列値が示す参加アプリケーション・インスタンス名の略称に設定する必要があります。
名前は{アプリケーションの略称}_{順序番号}の形式とし、統合プラットフォーム全体にわたるアプリケーション・インスタンスに対する一意の識別子である必要があります。同じアプリケーションの複数のインスタンスは、順序番号によって一意に識別されます。

- 大文字である必要があります。

- COMMONという名前の列を追加する必要があります。
この列には、プラットフォーム内のEBOで使用される値が格納されます。

例: COMMON、EBIZ_01、PSFT_01、SEBL_02、SEBL_03、PORTAL_01、IFLEX_01

21.9 BPEL

この項では、次の内容に関するネーミング標準を説明します。

- BPELアクティビティ

- その他のBPELアーティファクト

21.9.1 BPELアクティビティ

この項では、次のBPELアクティビティに関するネーミング標準を説明します。

- 割当

- 補正

- フロー

- FlowN

- Invoke

- Java Embedding

- Pick

- 受信

- 有効範囲

- Sequence

- スイッチ

- Case

- 終了

- Throw

- Transform

- 待機

- While

21.9.1.1 BPELプロセス名およびネームスペース

BPELプロセスのJDeveloperプロジェクト名は、BPELプロセス名と一致させる必要があります(デフォルトのプロジェクト設定を使用します)。

名前の標準

- 名前は、EBS、ABCS実装またはアダプタ・サービスのいずれで使用されるかに応じて、一般的なネーミング標準に従う必要があります。

- 名前は、実行するプロセスやアクション/動詞を明確に示している必要があります。

ネームスペースの標準:

- ネームスペースは、EBS、ABCS実装またはアダプタ・サービスのいずれで使用されるかに応じて、一般的なネームスペース標準に従う必要があります。

- ネームスペースは、プロセスの分類を反映している必要があります。

- ネームスペースには、必要に応じてメジャー・バージョン番号を含める必要があります。

- BPELコンポジットの参照コンポーネント名は、コールしているAIAアーティファクトのタイプに基づいた一般的なネーミング標準に従う必要があります。

21.9.1.2 割当

次のガイドラインに従ってください。

- 名前は、一般的なネーミング標準に従う必要があります。

- Assign接頭辞で開始します。

- 割り当てる内容を示す名前が後に続きます。割り当てる内容がメッセージの場合は、メッセージ名を使用します。

- 複数の割当がある場合は、割当のグループを示す名前を指定します(可能な場合)。

パターン: Assign<割り当てる内容の名前>

例: AssignPaymentEBM、AssignOrderInitialValues

21.9.1.3 Compensate

次のガイドラインに従ってください。

- 名前は、一般的なネーミング標準に従う必要があります。

- Compensate接頭辞で開始します。

- 補正対象のタスクをカプセル化するスコープが後に続きます。

パターン: Compensate<スコープ名>

例: CompensateProcessCreditCheckMilestone、Compensate TranseferFundsScope

21.9.1.4 フロー

次のガイドラインに従ってください。

- 名前は、一般的なネーミング標準に従う必要があります。

- 同時に実行するタスクを示す名前で開始します。

- Flow接尾辞で終了します。

パターン: <同時タスクを示す名前>Flow

例: CallManufacturersFlow、GetQuotesFlow

21.9.1.5 FlowN

次のガイドラインに従ってください。

- 名前は、一般的なネーミング標準に従う必要があります。

- 同時に実行する動的タスクを示す名前で開始します。

- FlowN接尾辞で終了します。

- 索引変数名は、Indexを接尾辞として付けたフロー名にしてください。

パターン: 名前 = <同時タスクを示す名前>FlowN、索引変数 = <同時タスクを示す名前>FlowNIndex

例: ActivateUsersFlowN (ActivateUsersFlowNIndex)、CheckSuppliersFlowN (CheckSuppliersFlowNIndex)

21.9.1.6 呼出し

次のガイドラインに従ってください。

- 名前は、一般的なネーミング標準に従う必要があります。

- Invoke接頭辞で開始します。

- 呼び出すパートナ・リンクが後に続きます。

- 同期呼出しの場合はCallが、非同期呼出しの場合はStartが後に続きます。

- パートナ・リンク内の操作名が後に続きます。

パターン: Invoke<パートナ・リンク名>{Call/Start}<操作>

例: InvokeCustomerServiceCallGetCustomer、InvokeNotificationServiceStartNotifyByEmail

21.9.1.7 Java埋込み

次のガイドラインに従ってください。

- 名前は、一般的なネーミング標準に従う必要があります。

- 名前は、ローワー・キャメルケースを使用したJavaメソッド名に類似している必要があります。

パターン: <機能を示す名前>

例: getDiscountPrice

21.9.1.8 ピック

次のガイドラインに従ってください。

- 名前は、一般的なネーミング標準に従う必要があります。

- Pick接頭辞で開始します。

- pickアクティビティ内のすべてのブランチ(onMessageおよびonAlarm)をできるだけ正確に示す名前が後に続きます。

パターン: Pick<選択元のブランチを示す名前>

例: PickOrderAckOrTimeout、PickFirstQuote

21.9.1.9 受信

次のガイドラインに従ってください。

- 名前は、一般的なネーミング標準に従う必要があります。

- Receive接頭辞で開始します。

- 受信するメッセージの名前を含めます。

パターン: Receive<メッセージ名>

例: ReceiveUpdateInvoiceEBM

21.9.1.10 スコープ

次のガイドラインに従ってください。

- 名前は、一般的なネーミング標準に従う必要があります。

- トランザクション・タイプに関する簡単な情報の組込みが適切な場合があります。

- スコープがエンドユーザー・モニターに対する候補の場合は、接尾辞にMilestoneを使用してください。

- エンドユーザー・モニターが対象でない場合は、接尾辞にScopeを使用してください。

パターン: <スコープ指定されたタスクを示す名前>{Scope |Milestone}

例: GetCreditRatingScope、GetLoanOfferScope、ProcessCreditCheckMilestone

21.9.1.11 順序

次のガイドラインに従ってください。

- 名前は、一般的なネーミング標準に従う必要があります。

- 順序名は、順番に実行するステップを示す必要があります。

- 順序名は、Sequence接尾辞で終了する必要があります。

パターン: <順序付けされたタスクを示す名前>Sequence

例: GetCustomerInfoSequence

21.9.1.12 Switch

次のガイドラインに従ってください。

- 名前は、一般的なネーミング標準に従う必要があります。

- Switch接頭辞で開始します。

- 評価する内容が後に続きます。

パターン: Switch<評価する内容の名前>

例: SwitchCreditRating

21.9.1.13 ケース

次のガイドラインに従ってください。

- 名前は、一般的なネーミング標準に従う必要があります。

- Case接頭辞で開始します。

- 評価する値が後に続きます。

パターン: Case<評価する値の名前>

例: CaseBadCredit、CaseApprovalRequired

21.9.1.14 終了

次のガイドラインに従ってください。

- 名前は、一般的なネーミング標準に従う必要があります。

- Terminate接頭辞で開始します。

- 終了理由を示す名前が後に続きます。

パターン: Terminate<終了の理由>

例: TerminateTimeout、TerminateEndOfProcess

21.9.1.15 スロー

次のガイドラインに従ってください。

- 名前は、一般的なネーミング標準に従う必要があります。

- Throw接頭辞で開始します。

- フォルト名が後に続きます。

- フォルト変数名は通常、フォルト名と同じです。

パターン: Throw<フォルト名>

例: ThrowExceededMaxAmount(ここではExceededMaxAmount変数が使用されています。)

注意:

ScopeアクティビティでCatchを定義するときは、表示されるcatch名がフォルト名です。

21.9.1.16 変換

次のガイドラインに従ってください。

名前は、一般的なネーミング標準に従う必要があります。

- Xform接頭辞で開始します。

- ソース名が後に続きます。

- Toが後に続きます。

- 宛先名が後に続きます。

パターン: Xform<ソース>To<宛先>

例: XformBillToPortal80Bill

21.9.1.17 待機

次のガイドラインに従ってください。

名前は、一般的なネーミング標準に従う必要があります。

- Wait接頭辞で開始します。

- 待機理由を示す名前が後に続きます。

パターン: Wait<待機理由を示す名前>

例: WaitOrderAcknowledgeTimeout、WaitWarmUpTime

21.9.1.18 While

次のガイドラインに従ってください。

- 名前は、一般的なネーミング標準に従う必要があります。

- While接頭辞で開始します。

- ループ条件を示す名前が後に続きます。

パターン: While<ループ条件を示す名前>

例: WhileAllMsgsSent

21.9.2 その他のBPELアーティファクト

その他のBPELアーティファクトについては、次のガイドラインに従います。

21.9.2.1 Variables

次のガイドラインに従ってください。

- 名前は、一般的なネーミング標準に従う必要があります。

- 変数名にはローワー・キャメルケースを使用してください。

- データ・タイプを変数名の一部にすることはできません。

例: accountBalance、invoiceAmount。

21.9.2.2 プロパティ

プロパティ名は、一般的なBPEL変数のネーミング標準に従います。

21.9.2.3 相関セット

次のガイドラインに従ってください。

- 名前は、一般的なネーミング標準に従う必要があります。

- 相関セットを示す名前で開始します。

- CorSet接尾辞で終了します。

パターン: <相関を示す名前>CorSet

例: PurchaseOrderCorSet

21.9.2.4 相関セット・プロパティ

相関セット・プロパティ名は、一般的なBPEL変数のネーミング標準に従います。

21.10 カスタムJavaクラス

カスタムJavaクラスは、標準のJavaコーディングの慣例に従う必要があります。Javaコード・コンポーネント名タイプは、オラクル社のJavaコーディング標準(http://bali.xy.example.com/bali/ojcs/front.html)に準拠している必要があります。

すべてのAIAカスタムJavaコードは、サブパッケージ内に存在している必要があります。

oracle.apps.aia.<lba>... lbaは、logical business area(論理ビジネス・エリア)を表しています。

Javaで実装した外部向けサービスには、ネームスペース・ネーミング標準に沿ったパッケージのバージョン番号部分を指定する必要があります。これによって、同じサービスの異なるバージョンを同時に公開することもできます。

oracle.apps.aia.<lba>... v<バージョン> lbaはlogical business area(論理ビジネス・エリア)を表しています。

ヒント:

衝突を回避するために、「aia」は、Fusion Application内のアプリケ－ションとして定義する必要があります。

例:

- oracle.apps.aia.util.logging: ロギングに使用するutil Javaクラスが含まれています。

- oracle.apps.aia.security.siebel.login: SiebelにログインするためのJavaモジュールが含まれています。

- oracle.apps.aia.order.siebel.V1: Javaで実装した注文問合せサービスが含まれています。

- oracle.apps.aia.item.pricediscount.v3: Javaサービスの価格割引エンジンが含まれています。

21.11 パッケージ構造

完全なソース・コントロールとパッケージ構造に関する情報は、Oracle Fusion Middleware Oracle Application Integration Architecture Foundation Packインストレーションおよびアップグレード・ガイドに記述されています。

21.12 デプロイメント計画

表21-12に、デプロイメント計画に関するネーミング標準の詳細を示します。

表21-12 デプロイメント計画に関するネーミング標準

アーティファクト名

アーティファクト・ファイル名

目的

必須/オプション

詳細

顧客拡張があるデプロイメント計画

<PIPコード>CustomDP.xml

顧客が作成したアーティファクトのデプロイメント手順

<プロジェクト・コード>CustomDP.xml: PLWとDPGを使用して、顧客サイトで再生成されたデプロイメント計画。含まれているのは、ネイティブ・アーティファクトのみです。

これは、インストール前、構成、デプロイメントおよびインストール後セクションをすべて備えたメインのデプロイメント計画に類似しています。

非ネイティブ・アーティファクトがあるデプロイメント計画

<PIPコード>SupplementaryDP.xml

非ネイティブ・アーティファクト(J2EEアプリケーション、Javaクラス、Webサービスおよび収集できなかった他のすべてのアーティファクト)に対するデプロイメント手順

非ネイティブ・アーティファクトのみが指定されている事前作成済の統合では、この計画が配信されます。

これは、インストール前、構成、デプロイメントおよびインストール後セクションをすべて備えたメインのデプロイメント計画に類似しています。

22 マッピング・エディタを使用した変換の編集

この章では、マッピング・エディタを使用して変換を編集するプロセスを説明します。

この章の内容は次のとおりです。

- マッピング・エディタの概要

- マッピング・エディタの管理

- 「マッピングの検索」ページの使用

- 変換の編集

- マッピング・エディタの編集ルール

- カスタマイズ・レイヤーの理解

- 編集した変換のデプロイ

- カスタマイズの削除

22.1 マッピング・エディタの概要

マッピング・エディタはブラウザベースのアプリケーションで、これを使用すると、事前作成済の統合マッピングをカスタマイズできます。変更内容は階層化されたカスタマイズとして保存され、パッチまたはアップグレードの適用時にオーバーライドされないように保護されます。また、このアプリケーションでは、カスタマイズをマージして、影響を受けたコンポジット・サービスをランタイム環境にデプロイすることもできます。

22.2 マッピング・エディタの管理

この項では、マッピング・エディタに関する次の管理タスクについて説明します。

- マッピング・エディタの有効化

- AgileAPI.jarファイルの共有ライブラリとしてのデプロイ

22.2.1 マッピング・エディタの有効化

マッピング・エディタを有効にするには、AIAMappingCustomizerエンタープライズ・ロールが適切なユーザーに割り当てられている必要があります。

このロールはOracle WebLogic管理者がユーザーに対して有効にする必要があります。

AIAMappingCustomizerエンタープライズ・ロールは、AIAHomeアプリケーションのデプロイ後にOracle WebLogicコンソールで使用可能になります。

AIAMappingCustomizerエンタープライズ・ロールをユーザーに割り当てる手順は、次のとおりです。

1. Oracle WebLogic Server管理コンソールを開きます。

2. 「セキュリティ・レルム」→「myrealm」→「ユーザーとグループ」の順にナビゲートして、ユーザーを選択します。

3. 「ユーザーの設定」画面で、「グループ」タブを選択します。

4. 「AIAMappingCustomizer」を「使用可能」から「選択済み」に移動します。

5. 「保存」ボタンをクリックします。
そのユーザーのOracle SOAコア拡張機能コンソールでマッピング・エディタのパネルが使用可能になります。

22.2.2 AgileAPI.jarファイルの共有ライブラリとしてのデプロイ

AgileAPI.jarを共有ライブラリとしてデプロイすると、ユーザーはAgileフレックスフィールドのユーザー定義名を取得して、「マッピング・エディタ」ページでの編集時に表示できます(表22-2の「フレックスフィールド名の表示」を参照)。

マッピング・エディタではAgileAPI.jarファイルを使用して、ソースまたはターゲット・システムがAgileである変換に対応するフレックスフィールド名を取得します。

初期状態では、スタブ・バージョンのAgileAPI.jarファイルがSOAサーバーのAgileAPI 1.0, 0.0共有ライブラリにデプロイされています。しかし、現時点でAgile XSLTファイルをマッピング・エディタで編集しようとすると、「フレックスフィールド名の警告。」エラーが表示されます(図22-1を参照)。

図22-1 「フレックスフィールド名の警告。」エラー

「フレックスフィールド名の警告。」ダイアログにリストされているシステムでの現行のセッション中にこのエラーが再度表示されないようにする場合は、「今後、この警告を表示しない。」オプションを選択します。

フレックスフィールド名機能を有効にするには、AgileAPI.jarファイルを共有ライブラリとしてWebLogicサーバーにデプロイする必要があります。AgileAPI.jarファイルではwlsauth.jarおよびcrypto.jarファイルを使用します。これら3つのJARファイルは実行時に使用可能である必要があります。また、wlsauth.jarおよびcrypto.jarファイルは、SOAサーバー起動時のクラスパスに含まれている必要があります。

AgileAPI.jar、wlsauth.jarおよびcrypto.jarファイルには、Agileサーバーの次の場所からアクセスできます。

- <AGILE_HOME>/integration/sdk/lib/AgileAPI.jar

- <AGILE_HOME>/<AGILE_DOMAIN>/lib/wlsauth.jar

- <AGILE_HOME>/<AGILE_DOMAIN>/lib/crypto.jar

<AGILE_HOME>の場所はインストールに応じて異なります。

マッピング・エディタでは、Agile 9.3.1.2、9.3.2および9.3.3バージョンとバイナリ互換性のあるAgileAPI.jarファイルのバージョンのみをサポートしています。

Agile APIの使用に関する詳細は、Agile PLM 9ドキュメント・ライブラリで入手可能なSDK開発者ガイドのAgile APIの使用に関する項を参照してください。

AgileAPI.jarファイルを共有ライブラリとしてデプロイする手順は、次のとおりです。

1. AgileAPI.jarファイルを共有ライブラリとしてWebLogicサーバーにデプロイします。

デプロイメント順序は370にできます。デプロイメント順序は505より前にする必要があります。

共有ライブラリのデプロイ方法については、『Oracle Fusion Middleware Oracle WebLogic Serverアプリケーションの開発』の共有Java EEライブラリと依存アプリケーションのデプロイに関する項を参照してください。

2. AIAHomeApp.earファイルを再デプロイします。

3. wlsauth.jarおよびcrypto.jarを実行時にSOAサーバーで使用されるクラスパスに含めるには、使用中のFusion Middlewareドメイン(<FMW_HOME>/user_projects/domains/soainfa/bin)にあるsetDomainEnv.shファイルにアクセスします。

PRE_CLASSPATH変数の宣言を検索します。wslauth.jarおよびcrypto.jarファイルの絶対パスをPRE_CLASSPATHに追加します。

(参考)デフォルトのPRE_CLASSPATH構成を次に示します: PRE_CLASSPATH="${SOA_ORACLE_HOME}/soa/modules/user-patch.jar${CLASSPATHSEP}${SOA_ORACLE_HOME}/soa/modules/soa-startup.jar${CLASSPATHSEP}${PRE_CLASSPATH}"

4. setDomainEnv.shファイルを保存します。

5. SOAサーバーを再起動します。

これで、ユーザーはAgile変換に対応するユーザー定義のフレックスフィールド名を、「マッピングの検索」ページで表示できると同時に、「マッピング・エディタ」ページでAgile変換を編集する際にも表示できます。

22.3 「マッピングの検索」ページの使用

「マッピングの検索」ページを起動するには、Oracle SOAコア拡張機能コンソールにナビゲートし、「AIAマッピング・エディタ」セクションにある「実行」ボタンをクリックします。

図22-2に示すように、「マッピングの検索」ページが表示されます。このページには、2つのセクションがあります。上部のセクションでは、検索基準を入力できます。下部のセクションには、カスタマイズ可能な変換ファイル(.xsl)がリストされます。変換ファイルには、統合の際にデータをソースからターゲットに変換する個々のマッピングが格納されています。このリストは、MapperConfiguration.xmlファイルから導出されたものです。

図22-2 「マッピングの検索」ページ

「フィルタ」エリアに用意されているフィルタを使用すると、カスタマイズする変換ファイルを容易に検出できます。表22-1に、フィルタとその説明を示します。

表22-1 「マッピングの検索」ページの「フィルタ」エリア

フィールド

説明

一致

「すべて」または「いずれか」の検索パラメータに基づいて変換を取得できます。

変換名

ファイル・システムにある変換ファイル(.xsl)の名前。

サービス・ソリューション・コンポーネント

プロジェクト・ライフサイクル・ワークベンチにあるサービス・ソリューション・コンポーネントの名前。

ソース・システム

送信元のアプリケーション・システム。

ビジネス・タスク

プロジェクト・ライフサイクル・ワークベンチにあるビジネス・タスクの名前。

ターゲット・システム

受信先のアプリケーション・システム。

PIP

プロジェクト・ライフサイクル・ワークベンチにあるプロセス統合パック(Oracleによって提供される事前作成済の統合)の名前。

カスタマイズ済

変換がカスタマイズされているかどうかに基づいてフィルタ処理します。

「フィルタ」のいずれかのフィールドに検索パラメータを入力して、「検索」をクリックします。

マッピング検索の結果を操作するには、表22-2で説明されているコントロールを使用します。

表22-2 「マッピングの検索」ページのコントロール

コントロール

説明

編集

選択した変換を編集してカスタム・マッピングを適用する場合にクリックします。

フレックスフィールド名の表示

「編集」ボタンと組み合せて使用します。選択すると、ソースまたはターゲット・アプリケーションのメタデータに対する動的問合せが実行されて、フレックスフィールドに対応するユーザー定義名が取得され、「マッピング・エディタ」ページにビジネス・エイリアスとして表示されます。

注意: このリリースでサポートされているアプリケーションはE-Business SuiteおよびAgileです。

Agileマッピングの編集時に「フレックスフィールド名の警告。」メッセージが表示された場合は、「AgileAPI.jarファイルの共有ライブラリとしてのデプロイ」を参照してください。

E-Business Suiteマッピングの編集時に警告メッセージが表示された場合は、その警告メッセージの内容とSOAサーバー・ログを使用してトラブルシューティングしてください。

デプロイ

マッピングをカスタマイズした後、カスタマイズ・レイヤーをベース・ファイルにマージして、影響を受けたコンポジット・サービスをランタイム・サーバーにデプロイする場合にクリックします。

カスタマイズの削除

カスタマイズしたすべてのマッピングを選択した変換から削除する場合にクリックします。

22.4 変換の編集

変換を編集する手順は、次のとおりです。

1. 変換を選択します。

2. (オプション)ソースまたはターゲット・システムがE-Business SuiteまたはAgileの場合は、「フレックスフィールド名の表示」オプションを選択して、フレックスフィールドに対応するユーザー定義名を表示します。

注意:

このオプションを選択すると、マッピングのロードに時間がかかる場合があります。

3. 「編集」ボタンをクリックします。
「マッピング・エディタ」ページが表示されます。

22.4.1 「マッピング・エディタ」ページ

「マッピング・エディタ」ページでは、図22-3に示すように、既存のマッピングを表示して拡張できます。マッピング・エディタには、選択した変換から既存のマッピングが事前ロードされます。個別のマッピングの追加、変更および削除ができます。「マッピング・エディタ」ページは複数のフレームに分割されています。

図22-3 「マッピング・エディタ」ページ

22.4.1.1 ページ・ヘッダー

- 編集している変換ファイル(.xsl)の名前が表示されます。

- 保存して閉じる: このボタンでは、マッピングの変更をカスタマイズ・レイヤーに保存して「マッピングの検索」ページに戻ります。

- 取消: このボタンでは、マッピングの変更を保存せずに「マッピングの検索」ページに戻ります。

22.4.1.2 ターゲット・フレーム

ターゲット・フレームは、左上部に表示される最初のフレームです。ターゲット・スキーマ名が記載され、ターゲット・スキーマ要素が表示されます。マッピング・エディタは、出力ドキュメントを作成できるように設計されています。ページは、左側でターゲット要素を選択し、マッピングを作成する右側の要素にドラッグ・アンド・ドロップするように配置されています。

- ターゲット要素はツリー構造で表示されます。属性のみの子を含む要素は最初は展開されていません。これらを展開すると、属性要素が表示されます。ツリーは、最初は6番目の子まで展開されています。6番目の子の下に子がある場合、それらの子は展開されません。MaxDepth値はMapperConfiguration.xmlファイルで構成できます。

- 「要素の検索」では、ツリー内の要素を検索できます。検索する要素の名前を入力し、[Enter]を押すか、またはアイコンをクリックして検索を開始します。入力したテキストを含む次の要素が取得されます。[Enter]を押し続けるか、またはアイコンを複数回クリックすることで、一致する次の要素を検索できます。

- 「* すべてのアイテム」、「マップ済」および「未マップ」オプションを使用して要素をフィルタ処理できます。

- * すべてのアイテム: ターゲット・スキーマのすべての要素が表示されます。

- マップ済: マップ済のターゲット要素のみを表示するようにツリーがフィルタ処理されます。子要素がマップ済の場合は、その親が表示されてターゲット・スキーマの構造がそのまま保持されます。

- 未マップ: 現在マップされていないターゲット要素のみを表示するようにツリーがフィルタ処理されます。子要素がマップされていない場合は、その親がマップ済であっても親が表示され、ターゲット・スキーマの構造がそのまま保持されます。

- 任意の要素を右クリックして、先頭として表示、「すべて縮小」または「すべて展開」を選択します。

- このフレームは2つの列に分割されています。これらは「ノード名」と「マッピング・サマリー」です。

- 「マッピング・サマリー」列は、ターゲット要素にマップされている内容のサマリーです。ソース要素、変数、テキストおよび関数が表示されます。マッピングで関数が使用されている場合は通常、ソース要素、変数、テキスト、演算子などを含むいくつかのパラメータが含まれています。「マッピング・サマリー」列の長さには制限があり、関数で使用される様々な組合せすべてを格納することができないため、関数が使用され、その関数にパラメータが渡されることを伝えるために省略書式が表示されます。

- カスタマイズされたマッピングがあるターゲット要素は、青色のドット・インディケータでマークされます。

- ターゲット要素を選択すると、「マッピング・ビルダー」フレームの「マッピング」セクションに完全な式が表示されます。

22.4.1.3 ソース・フレーム

右側にあるこのフレームには、アコーディオン・コントロール内の3つのセクションであるソース・スキーマ、「マッピング・コンポーネント」および「変数」が表示されます。このフレーム内の3つのセクションにはすべて検索フィールドがあります。

- ソース・スキーマ

- ソース要素はツリー構造で表示されます。属性のみの子を含む要素は最初は展開されていません。これらを展開すると、下に属性要素を表示できます。ツリーは、最初は6番目の子まで展開されています。6番目の子の下に子がある場合、それらの子は展開されません。MaxDepth値はMapperConfiguration.xmlファイルで構成できます。

- ソース要素にあるチェック・マークは、その要素がすでにターゲットにマップされていることを示します。

- 「要素の検索」では、ツリー内の要素を検索できます。検索する要素の名前を入力した後は、[Enter]を押すか、またはアイコンをクリックして検索を開始します。入力したテキストを含む次の要素が取得されます。[Enter]を押し続けるか、またはアイコンを複数回クリックすることで、一致する次の要素を検索できます。

- ソース要素はマップされていないターゲット要素または「マッピング・ビルダー」内にドラッグ・アンド・ドロップできます。あるいは、「マッピングに追加」ボタンをクリックして、選択したソース要素を「マッピング・ビルダー」に挿入できます。

注意:

ソース要素をマッピングに挿入すると、現在の実行コンテキストに基づいて適切な相対または絶対パスが自動的に計算されます。

- マッピング・コンポーネント: 「マッピング・コンポーネント」は「XSL要素」、「関数」および「演算子」で構成されています。

- 「XSL要素」は、XSL言語で最も頻繁に使用される要素のサブセットです。すべてのマッピング文はXSL要素で始める必要があります。次の要素がサポートされています。

- Attribute: マッピングの完成に属性が必要な場合に使用します。たとえば、nil属性をtrueに設定している場合です。

- Choose: 複数のケースを使用して条件を指定する場合に使用します。When要素は、Chooseとともに自動的に挿入されます。

- For-each: 繰返しソース要素を繰返しターゲット要素にマップする場合に使用します。For-each文では、実行コンテキストが変更され、その結果として、子の文内のソースおよび変数の相対パスが自動的に調整される場合があります。

- If: 単一のケースを使用して条件を指定する場合に使用します。

- Otherwise: Choose文で最終条件を指定する場合にこの文を使用します。

- Text: リテラル値を指定する場合に使用します。

- Value-of: 実際のマッピング割当を実行する場合にこの主文を使用します。

- When: Choose文で条件を指定する場合に使用します。Chooseがまだ親の文でない場合は、自動的にWhenとともに挿入されます。

- 「関数」は、日付関数、拡張関数、文字列関数などの標準的なXPATH関数で構成されています。DVM、XREFなどの頻繁に使用されるAIA関数もあります。

- 「演算子」は、「加算」、「論理積」、「除算」、「次より大きい」、「次より小さい」などで構成されています。

- 「マッピング・コンポーネント」セクションでは、「検索」および「マッピングに追加」もサポートされています。

- 変数: 選択したターゲット要素に使用できる変数が表示されます。変数はコンテキストに依存します。

- ターゲット要素を最初に選択すると、そのターゲット要素がマップされていない場合のみ、適用可能な変数が表示されます。これはvalue-of select文としてターゲット要素にドラッグ・アンド・ドロップできます。

- 変数は、「マッピング」パネルで行が選択されている場合にも表示されます。選択したマッピング行に適用可能であるかぎり、変数が表示されます。

- 特定の変数にはツリー構造が設定されている場合があります。このような変数を展開するとその変数の子が表示され、リーフ・ノードに到達するまで引き続き展開できます。

注意:

変数要素をマッピングに挿入すると、現在の実行コンテキストに基づいて適切な相対または絶対パスが自動的に計算されます。

- 「変数」セクションでは、「検索」および「マッピングに追加」もサポートされています。

22.4.1.4 マッピング・ビルダー・フレーム

このフレームには、マッピング作成ユーティリティが用意されており、ユーザーは複雑なマッピングを作成して編集できます。このフレームは、左下部にあります。このフレームには、2つのセクションがあります。

マッピング・ビルダー・ヘッダー

- ターゲット要素: (上部のターゲット・フレームで)選択したターゲット要素のフルパスが表示されます。

- 保存: 「マッピング・ビルダー」内で加えた変更をメモリー内の内部ドキュメントに保存します。1つのターゲット要素の変更を保存してから別のターゲット要素を選択する必要があります。

- 取消: 「マッピング・ビルダー」内で加えた変更を破棄します。ターゲット・マッピングは以前の状態に戻ります。
マッピングのクリア: ターゲット要素に対して実行されたマッピングをすべて消去します。

コンテキスト

現在選択されているターゲット要素がどの条件とコード・パスでマップされるかをユーザーが理解するのに役立つ関連コンテキスト情報が表示されます。コンテキストは編集できません。実行コンテキストには、マッピングを実行するために満たす必要があるapply templates、match templates、call templates、for-each、choose/when/otherwiseおよびif文が含まれる場合があります。このペインは最初は閉じた状態です。内容を表示するには、ペインのサイズを元に戻すアイコンをクリックします。

マッピング

ターゲット要素のマッピングで使用されている文の完全なコレクションが表示されます。マッピングには、マッピングの割当自体に加えて、ターゲットに影響を与える条件文が含まれます。ユーザーは、次のツールバー・オプションを使用して、文を挿入、編集または削除できます。

- 挿入: Insert Parent、Insert Sibling Before、Insert Sibling AfterおよびInsert Childの各文を「マッピング」ペインに挿入するオプションを提供します。このオプションは、ユーザーがペイン内で文を右クリックしたときに表示されるコンテキスト・メニューからも使用できます。

- 編集: ユーザーは選択した文を展開して、その文を構成しているサブコンポーネントを表示できます。展開したサブコンポーネントは編集可能です。このボタンとコンテキスト・メニューの「編集」オプションは、編集可能な文に対してのみ有効になります。たとえば、value-of select、if、whenなどの文です。ペイン内の編集可能な文の前には鉛筆アイコンが表示されます。

- 編集完了: このオプションは、「編集」ボタンをクリックし、選択した文を展開すると有効になります。サブコンポーネントのいずれかに対する変更を加えた後は、このボタンをクリックして変更を完了し、文を縮小します。「保存」ボタンをクリックすると、「編集完了」ボタンが自動的にクリックされます。

- 入力リテラル: このオプションは、展開したサブコンポーネントに、リテラルに変更可能な式が含まれている場合に有効になります。

- 削除: このオプションは、選択した文または式が削除に適格である場合に有効になります。

22.4.2 マッピングの作成(例)

この項では、単純な例を使用して、「マッピング・エディタ」ページの使用方法を示します。

22.4.2.1 単純なマッピングの作成

複雑な条件が必要ない場合は、単純なマッピングを実行できます。たとえば、ソース・システムの製品IDをターゲット・システムの製品IDにマップする必要があり、条件が必要ない場合は、単純なマッピングを実行します。

図22-4 マッピング式ビルダー画面

要素の単純なマッピングを実行する手順は、次のとおりです。

1. ターゲット・フレームで、マップする必要がある要素を選択します。

2. ソース・フレームで、マップする必要がある要素を選択します。

3. ソース要素を、マップする必要があるターゲット要素行にドラッグします。
その行の「マッピング・サマリー」列がソース要素でリフレッシュされ、要素がカスタマイズされたことを示す青色のドットで行が強調表示されます。

マッピング・ビルダー・フレームが、直前に作成した単純なマッピング用の完全なマッピング文でリフレッシュされます。単純な割当を行うXSLのvalue-of文が自動的に追加されます。

この方法で、変数をターゲットにマップすることもできます。ただし、マッピング・コンポーネントは、マッピング・ビルダーでのみマップできます。

注意:

作成済のマッピングを削除するには、ターゲット・フレームで要素を選択して、「マッピングのクリア」ボタンをクリックします。

22.4.2.2 複雑なマッピングの作成

条件や関数などを必要とする複雑なマッピングを実行する場合は、マッピング・ビルダーを使用します。

マッピング・ビルダーを使用してマッピングを作成する手順は、次のとおりです。

1. ターゲット・フレームで要素を選択します。

- 選択した要素がマップされていない場合は、「マッピング」セクションに空の行が追加され、「-- ここにドラッグ・アンド・ドロップまたは入力」というテキストが表示されます。

- 選択した要素がマップ済の場合、「マッピング」セクションにはそのターゲットの完全なマッピング文のセットが表示されます。続行する前に、空の行を作成して新しい文を追加したり、既存の文を編集できます。詳細は、後続の新しいマッピング文の行を追加する手順を参照してください。

2. ソース要素を選択してドラッグし、「マッピング」セクションの空の行にドロップします。

- 単純な割当を行うXSLのvalue-of文が追加されます。

- あるいは、ソース要素を選択し、「マッピング式に追加」ボタンをクリックすることもできます。

3. 変更作業の完了後は、「編集完了」ボタンをクリックします。

4. 「保存」をクリックします。

22.4.2.3 新しいマッピング文の行の追加

マッピング文の行を編集する手順は、次のとおりです。

1. 「マッピング」セクションで、編集する行を選択します。

2. 「編集」をクリックして、必要な変更を加えます。
この文を展開して、そのサブコンポーネントを表示します。ソース、関数、演算子または変数を既存のサブコンポーネント行に挿入することによって既存のサブコンポーネントを編集します。

3. 変更作業の完了後は、「編集完了」ボタンをクリックします。

4. 「保存」をクリックします。

マッピングの変更をすべて保存する手順は、次のとおりです。

すべての編集の完了後に、「保存して閉じる」ボタンをクリックします。この操作によって、変換の検索ページが表示されます。このページは、カスタマイズした変換をデプロイする際に役立ちます。

マッピングの変更をすべて破棄するには、「取消」ボタンをクリックします。

式の編集に進む前に、「マッピング・エディタの編集ルール」の項を参照してください。

22.4.2.4 マッピング文の行の編集

新しいマッピング文の行を追加する手順は、次のとおりです。

1. 「挿入」ボタンをクリックし、親、兄弟の前、兄弟の後、または子の行を選択します。
目的の位置に空の行が追加され、「-- ここにドラッグ・アンド・ドロップまたは入力」というテキストが表示されます。

2. 「マッピング・コンポーネント」セクションから、XSL要素を新しい行にドラッグ・アンド・ドロップします。たとえば、ifを選択します。

3. この文を展開して、次の必須サブコンポーネントを表示します。

- Test(if XSL要素の必須属性)の子行。

- Testの下に新しい空の行がデフォルト設定され、「-- ここにドラッグ・アンド・ドロップまたは入力(Test用)」というテキストが表示されます。

4. 有効なソース、関数、演算子または変数を新しい空の子行に挿入して、新しいXSL要素を完成します。関数または演算子を挿入した場合は、行を再び展開して、その必須サブコンポーネントを表示します。同様に完成させます。

5. 変更作業の完了後は、「編集完了」ボタンをクリックします。

6. 「保存」をクリックします。

22.5 マッピング・エディタの編集ルール

この項では、変換を編集する際のルールについて説明します。各フィールドの編集ルールについても詳細に説明します。

22.5.1 定義

- 空の行: ターゲット・タグ、ソース要素、マッピング・コンポーネント、変数またはリテラルが含まれていない行。空の行は、ドラッグ・アンド・ドロップまたは入力可能であることが示されます。

- ターゲット・タグ: ターゲット要素のタグを定義するXML文。

- 属性値テンプレート・マッピング: 式ビルダー・ウィンドウに表示される属性値テンプレートの式。

- 正規マッピング: 属性値テンプレートを対象としないマッピング。

- マッピング・コンポーネント: 「マッピング・コンポーネント」アコーディオン・パネル下にリストされるコンポーネント。

- 文: XML要素またはXMLの完全な文。

- 祖先の文: 共有文を除いた、親、祖父母、曾祖父母などの文。

- サブコンポーネント: 文の一部またはサブコンポーネントの一部。

- 共有文: そのスコープ内に複数の兄弟ターゲット要素があるXSLT文。

- OOTB: Out Of The Box(初期状態)。

22.5.2 読取り専用の文

次の文は読取り専用です。

- xsl:copy

- xsl:copy-of

- xsl:element

- xsl:attribute

- xsl:for-each

- 属性値テンプレートが指定されたターゲット・タグ

- 関数または演算子が指定された、「マッピング・コンポーネント」パネルにリストされていない初期状態の文

22.5.3 ドラッグ・アンド・ドロップまたは入力

表22-3に、変換の編集中に実行できる様々なドラッグ・アンド・ドロップ(D&D)または入力アクティビティを示します。

表22-3 ドラッグ・アンド・ドロップまたは入力

D&D

D&D

D&D

D&D

D&D

D&D

タイプ

マッピング・タイプ

親

宛先

ソース要素

XSLT要素

XSLT属性

関数

演算子

変数

リテラル

N/A

N/A

ターゲット・ツリー内のマップされていないターゲット

はい

いいえ

いいえ

いいえ

いいえ

はい

いいえ

N/A

N/A

ターゲット・ツリー内のマップ済のターゲット

いいえ

いいえ

いいえ

いいえ

いいえ

いいえ

いいえ

正規

ターゲット・タグ

空の行

はい

はい

いいえ

いいえ

いいえ

はい

はい

正規

XSLT要素

空の行

いいえ

はい

はい

いいえ

いいえ

いいえ

(1) はい

正規

XSLT属性

空の行

はい

いいえ

いいえ

はい

はい

はい

はい

正規

関数

空の行

はい

いいえ

いいえ

はい

はい

はい

はい

正規

演算子

空の行

はい

いいえ

いいえ

はい

はい

はい

はい

正規

リテラル

空の行

(2)なし

(2)なし

(2)なし

(2)なし

(2)なし

(2)なし

(2)なし

属性値テンプレート

任意

空の行

(2)なし

(2)なし

(2)なし

(2)なし

(2)なし

(2)なし

(2)なし

任意

任意

ターゲット・タグ

いいえ

いいえ

いいえ

いいえ

いいえ

いいえ

いいえ

正規

任意

ソース要素

はい

いいえ

いいえ

はい

はい

はい

はい

属性値テンプレート

属性

ソース要素

はい

いいえ

いいえ

いいえ

いいえ

はい

はい

正規

任意

変数

はい

いいえ

いいえ

はい

はい

はい

はい

属性値テンプレート

属性

変数

はい

いいえ

いいえ

いいえ

いいえ

はい

はい

正規

任意

XSLT要素

いいえ

いいえ

いいえ

いいえ

いいえ

いいえ

いいえ

正規

任意

XSLT属性

いいえ

いいえ

いいえ

いいえ

いいえ

いいえ

いいえ

正規

任意

関数

はい

はい

はい

はい

はい

はい

はい

正規

任意

演算子

はい

はい

はい

はい

はい

はい

はい

正規

ターゲット

リテラル

いいえ

いいえ

いいえ

いいえ

いいえ

いいえ

はい

正規

テキストXSL要素

リテラル

いいえ

いいえ

いいえ

いいえ

いいえ

いいえ

はい

正規

value-of XSL要素のSelect属性

リテラル

はい

いいえ

いいえ

はい

はい

はい

はい

属性値テンプレート

任意

関数

(2)なし

(2)なし

(2)なし

(2)なし

(2)なし

(2)なし

(2)なし

属性値テンプレート

任意

演算子

(2)なし

(2)なし

(2)なし

(2)なし

(2)なし

(2)なし

(2)なし

属性値テンプレート

任意

リテラル

(2)なし

(2)なし

(2)なし

(2)なし

(2)なし

(2)なし

(2)なし

任意

任意

任意の読取り専用

いいえ

いいえ

いいえ

いいえ

いいえ

いいえ

いいえ

(1) 可: <xsl:text>に対して有効。その他のxslt文は実行時にエラーになります。

(2) なし: この親に対して空の行を作成することはできません。

注意:

異なる属性を持つ2つの子要素を追加すると、マッピング・エディタでは両方の子要素が保存されます。同じ属性を持つ2つの子要素を追加すると、マッピング・エディタでは1つの属性のみが保存されます。これは予想された動作です。

22.5.4 行の挿入

表22-4では、新しい行を挿入できる状況を説明します。

表22-4 行を挿入する際のルール

挿入形式

挿入形式

挿入形式

挿入形式

マッピング・タイプ

選択した行の親

選択した行

親

子

兄弟の前

兄弟の後

正規

なし

任意

はい

はい

いいえ

いいえ

正規

任意

ターゲット・タグ

はい

はい

はい

はい

正規

任意

XSLT要素

はい

はい

はい

はい

正規

XSLT要素

XSLT属性

いいえ

(1) はい

はい

はい

正規

任意

関数

いいえ

はい

いいえ

いいえ

正規

任意

演算子

いいえ

はい

いいえ

いいえ

正規

サブコンポーネント

サブコンポーネントとしてのリテラル

いいえ

いいえ

いいえ

いいえ

正規

XML文

XML文の値としてのリテラル

はい

いいえ

いいえ

いいえ

正規

任意

ソース要素

いいえ

いいえ

いいえ

いいえ

正規

任意

変数

いいえ

いいえ

いいえ

いいえ

属性値テンプレート

任意

任意

いいえ

いいえ

いいえ

いいえ

(1) 可: <xsl:text>に対して有効。その他のxslt文は実行時にエラーになります。

22.5.5 削除

この項では、変換を削除する際のルールについて説明します。

22.5.5.1 すべてのマッピング・ルールの削除(すべて削除)

- ターゲット要素がリーフ要素の場合は、ターゲット・タグとすべての子の文が変数宣言も含めて削除されます。

- ターゲット要素が親要素の場合、マッピング・エディタでは、子ターゲット・マッピングがすべて削除されるまで親の削除は許可されません。最初に子を削除してから親を削除する必要があります。

- 式のUIにターゲット要素タグの祖先の文が表示される場合、その祖先の文は他のターゲットと共有されておらず、それが表示される理由です。これらの祖先の文は祖先の変数とともに削除されます。

22.5.5.2 個別に保存した文の削除

- 個別に保存した文は、属性値テンプレートの文から除外されます。

- マッピング全体の削除は、個別の文の削除より優先します。

- 作成したが保存していない文は削除できます。これらに適用するルールはありません。

- 削除対象の文によってソース実行コンテキスト(たとえば、for each)が定義されている場合は、一時的に読取り専用のフラグが設定されるため、削除できません。

22.5.5.3 ターゲット要素タグの文の削除

- ターゲット・タグの文が親ターゲット・タグで、子ターゲットにマッピングが設定されている場合、その文は削除できません。

- ターゲット・タグの文に子の文がある場合、その文は削除できません。

- ターゲット・タグに祖先の文がある場合、その文は削除できません。
子、親または祖先のないターゲット・タグの文のみを削除対象としてください。

22.5.5.4 属性値テンプレートの削除

属性値テンプレートの例: <changeEBO:CreateEngineeringChangeOrderList actionCode="CREATE">文のアクション="CREATE"の削除。

属性値テンプレートはマッピング全体として削除できます。個々の行は削除できません。

22.5.5.5 サブコンポーネントの削除

- 属性、パラメータ、オペランドの削除: オプションのサブコンポーネントのみを削除できます。必須のサブコンポーネントは削除できません。

- 関数、演算子、リテラル、ソースXpath、変数Xpathの削除: これらは削除できます。

22.5.6 For-Eachの編集ルール

この項では、for-eachの編集ルールについて説明します。

22.5.6.1 定義

- 実行コンテキスト: 実行コンテキストはスコープの概念です。実行コンテキストが定義されると、それぞれの子XSL文がその実行コンテキストを継承します。実行コンテキストは主に次のXSLT文で定義されます。

- <xsl:template match='xxxx'>

- <xsl:apply-template select='xxx'/>

- <xsl:for-each select='xxx'/>
xxxは実行コンテキストを定義するXPath式です。

- 実行コンテキスト定義: 実行コンテキストを定義するXSL文。

- ペイロードまたは変数に基づいた実行コンテキスト: 実行コンテキストは、ペイロード(ソース)または変数のパス(相対/絶対)を使用して定義できます。相対パスを使用したXPath式は、現在の実行コンテキストの情報にアクセスします。つまり、実行コンテキストが変数に基づいている場合は、相対パスによってペイロード・コンテンツではなく変数コンテンツがアクセスされます。

- 実行コンテキスト依存(ECD)文: ECD文は、相対パスが設定されたXPathを使用した文です。
属性値テンプレートはXSLTではありません。ただし、このマニュアルでは、属性に割り当てられた値に相対パスが使用されている場合は、属性値テンプレートをECD文とみなします。

- 不明な実行コンテキスト: これは、実行コンテキストを定義している文(for-each、apply-templateなど)に無効なXPathがある場合、または有効なXPathだが複雑なXPathが使用されているためにマッパーが解読できない場合に発生します。このような文とそのスコープについては、実行コンテキストに不明のフラグが設定されます。

- 編集不可の文: 次のような、式ビルダーに表示されない文:

- 変数の宣言

- テンプレートの呼出し

- テンプレートの宣言

- 読取り専用の文

- ワイルドカードXPathを使用した文(//xxx)

22.5.7 実行コンテキストの変更の許可

- 初期状態(OOTB)のfor-each: OOTBのfor-eachスコープに編集不可のECD文が含まれている場合、その<xsl:for-each>文は読取り専用に設定されます。
OOTBのfor-eachに不明な実行コンテキストがある場合、その<xsl:for-each>文は読取り専用に設定されます。

- OOTBの不明な実行コンテキスト: コンテキスト定義文に不明な実行コンテキストが定義されている場合は、ECDの子の文がすべて読取り専用に設定されます。

- <xsl:for-each>のドラッグ・アンド・ドロップまたは既存の<xsl:for-each>の編集: <xsl:for-each>は、次の状況の場合は、ドラッグ・アンド・ドロップまたは編集できます。

- 新しいfor eachスコープの下に編集不可のECD文がない。編集不可のECD文がある場合は、エラーが表示されます。
<xsl:for-each>を親ターゲットのタグ文の祖先の文として挿入すると、そのターゲットの子マッピングのマッピング文は、新しいfor-eachのスコープ内となります。これらの文も編集不可のECD文として評価されます。

- 編集モードの子の文が存在しない。編集モードの子の文が存在する場合は、エラーが表示されます。

- < xsl:for-each>の削除: xsl:for-eachは、次の場合を除いて削除できます。

- 読取り専用の場合。

- <xsl-for-each>スコープに編集不可のECD文が含まれている場合。

22.5.8 実行コンテキスト変更時の相対パスの調整

<xsl:for-each>を追加、変更または削除すると、実行コンテキストが変更されます。

実行コンテキストが変更されると、ECDの子の文(新しい<xsl:for-each>スコープ下の文)は、新しいコンテキストが導入される前と同じデータに引き続きアクセスするように調整されます。マッパーは、可能なかぎり相対パスを維持し続けようとします。

新しい実行コンテキストがペイロードから変数(またはその逆)に変更されたり、ある変数から別の変数に変更されると、ECDの子の文は、実行コンテキストの変更前と同じデータに引き続きアクセスするために絶対パスを使用するように調整されます。

新しい実行コンテキストが、ある場所から同じペイロードまたは変数内の別の場所に変更されると、ECDの子の文は、引き続き相対パスを使用して調整されます。これは、XPathのナビゲーション・コマンド(「../」、「.」、「/」)を使用して行われます

絶対パスで指定された文は、実行コンテキスト変更時に調整されません。

ECD文が式ビルダーに表示されている場合は、調整された相対パスを即時に確認できます。子ターゲット・マッピングにおけるECDの子の文は、「保存」ボタンをクリックすると自動的に調整されます。

表22-5に、実行コンテキストの変更時に調整される相対パスの例をいくつか示します。

表22-5 実行コンテキストの変更時に調整される相対パスの例

実行コンテキスト変更前->変更後(次の行)

従業員名のXPathの調整前->調整後(次の行)

/company/employee/employee/name

first_name

/company/employees/employee

name/first_name

$department

/company/employee/employee/name/first_name

/company/employees/employee

/company/employee/employee/name/first_name

実行コンテキスト変更前->変更後(次の行)

会社電話番号のXPathの調整前->調整後(次の行)

/company/employee/employee/name

../../../phone_number

/company/employees/employee

../../phone_number

$department

/company/phone_number

/company

/company/phone_number

実行コンテキスト変更前->変更後(次の行)

会社の市区町村所在地の絶対XPath。調整されません。

/company/employee/employee/name

/company/address/city

/company/employees/employee

/company/address/city

$department

/company/address/city

実行コンテキスト変更前->変更後(次の行)

変数$departmentから部門名のXPath。これは絶対パスのため調整されません。

/company/employee/employee/name

$department/name

/company/employees/employee

$department/name

$department

$department/name

22.6 カスタマイズ・レイヤーの理解

- マッピング・エディタでMDSレイヤー・カスタマイズを利用する際に以前に推奨されたように、_Custom.xslにコードを配置する必要はありません。

- マッピング・エディタを使用すると、既存の変換を変更して、変更内容を新しいmdssysフォルダに保存できるようになりました。

- mdssysフォルダにはmapperuiを含むサブフォルダが格納されます。このサブフォルダには、変更されたxslと名前が一致するxmlファイルが格納されます。たとえば、AgileCreateEngineeringChangeOrderListABM_to_CreateEngineeringChangeOrderListEBM.xsl.xmlです。

- このxmlファイルには、元のxslファイルに加えられたマッピングの変更が格納されます。これらのマッピングの変更は、一意のxml:id=”mapperui_xxxでマーキングされています。このファイルのマッピングは初期状態にマージされ、マッピング・エディタに適切に表示されます。

- カスタマイズ・レイヤーのマッピングは、事前作成済の統合のアップグレードやパッチの適用時に影響されません。

22.7 編集した変換のデプロイ

カスタマイズした変換は、カスタマイズ列でマークが付けられます。カスタマイズした変換をデプロイするには、その変換を選択して、「デプロイ」ボタンをクリックします。

「デプロイ」ボタンをクリックすると、次の処理が実行されます。

1. カスタマイズ・レイヤーがベースXSLファイルがマージされて、マージ・ファイルが作成されます。

2. 選択したコンポジット・サービスに対してカスタムのデプロイメント計画が生成されます。

3. SOAコア拡張機能のAIDユーティリティを使用してカスタムのデプロイメント計画が実行され、選択したコンポジット(複数可)がランタイム・サーバーに再デプロイされます。

22.8 カスタマイズの削除

実行済のカスタマイズを取り消すには、カスタマイズ変換を選択して、「カスタマイズの削除」ボタンをクリックします。

A 提供されるOracle AIA XPath関数

この付録では、自社の統合フローで使用するためにOracle SOAコア拡張機能とともに提供されるXPath関数の詳細を示します。

この付録の内容は次のとおりです。

- aia:getSystemProperty()

- aia:getSystemModuleProperty()

- aia:getServiceProperty()

- aia:getEBMHeaderSenderSystemNode()

- aia:getSystemType()

- aia:getErrorMessage()

- aia:getCorrectiveAction()

- aia:isTraceLoggingEnabled()

- aia:logErrorMessage()

- aia:logTraceMessage()

- aia:getNotificationRoles()

- aia:getAIALocalizedString()

- aia:getConvertedDate()

- aia:getConvertedDateWithTZ()

注意:

これらの関数はBPEL、XSLT、およびメディエータ・ルーティング・ルールのフィルタからコールできます。

A.1 aia:getSystemProperty()

namespace aia="http://www.oracle.com/XSL/Transform/java/oracle.apps.aia.core.
xpath.AIAFunctions"
string aia:getSystemProperty (string propertyName, boolean needAnException)

A.1.1 パラメータ

- propertyName
値を取得するシステム・プロパティの名前。

- needAnException
プロパティが見つからない場合に例外をスローするか、または空の文字列を返すかを指定するために使用します。

A.1.2 戻り値

propertyNameによって識別されるシステム・プロパティの文字列値を返します。プロパティが見つからない場合は、needAnExceptionパラメータの値に従って、例外がスローされるか、空の文字列が返されます。

A.1.3 使用方法

- XSLTの例:

<xsl:variable name="activeRuleset" select="aia:getSystemProperty('Routing.
ActiveRuleset',true())"/>

- BPELの例:

<assign name="AssignVar">
<copy>
<from expression="aia:getSystemProperty('Routing.    ActiveRuleset',
true())"/>
<to variable="ActiveRuleset"/>
</copy>
</assign>

A.2 aia:getSystemModuleProperty()

namespace aia="http://www.oracle.com/XSL/Transform/java/oracle.apps.aia.core.
xpath.AIAFunctions"
string aia:getSystemModuleProperty (string moduleName, string propertyName,
boolean needAnException)

A.2.1 パラメータ

- moduleName
プロパティを取得するモジュール。

- propertyName
値を取得するプロパティの名前。

- needAnException
プロパティが見つからない場合に例外をスローするか、または空の文字列を返すかを指定するために使用します。

A.2.2 戻り値

moduleNameとpropertyNameによって識別されるモジュール・プロパティの文字列値を返します。モジュール・プロパティが見つからない場合は、同じ名前のシステム・プロパティが返されます。同じ名前のシステム・プロパティが見つからない場合は、needAnExceptionパラメータの値に従って、例外がスローされるか、空の文字列が返されます。

A.2.3 使用方法

- XSLTの例:

<xsl:variable name="errHdlrImpl" select="aia:getSystemModuleProperty
('ErrorHandler','COMMON.ERRORHANDLER.IMPL',true())"/>

- BPELの例:

<assign name="AssignVar">
<copy>
<from expression="aia:getSystemModuleProperty('ErrorHandler',
'COMMON.ERRORHANDLER.IMPL',true())"/>
<to variable="ErrorHandler"/>
</copy>
</assign>

A.3 aia:getServiceProperty()

namespace aia="http://www.oracle.com/XSL/Transform/java/oracle.apps.aia.core.
xpath.AIAFunctions"
string aia:getServiceProperty (string serviceName, string propertyName,
boolean needAnException)

A.3.1 パラメータ

- serviceName
プロパティを取得するサービス。

- propertyName
値を取得するプロパティの名前。

- needAnException
プロパティが見つからない場合に例外をスローするか、または空の文字列を返すかを指定するために使用します。

A.3.2 戻り値

serviceNameとpropertyNameによって識別されるサービス・プロパティの文字列値を返します。サービス・プロパティが見つからない場合は、同じ名前のシステム・プロパティが返されます。同じ名前のシステム・プロパティが見つからない場合は、needAnExceptionパラメータの値に従って、例外がスローされるか、空の文字列が返されます。

A.3.3 使用方法

- XSLTの例:

<xsl:variable name="defaultSystemID" select="aia:getServiceProperty
('{http://xmlns.oracle.com/ABCSImpl/Siebel/Core/UpdateCustomerParty
SiebelReqABCSImpl/V2}UpdateCustomerPartySiebelReqABCSImplV2','Default.
SystemID',true())"/>

- BPELの例:

<assign name="AssignVar">
<copy>
<from expression= "aia:getServiceProperty('{http://xmlns.oracle.com
/ABCSImpl/Siebel/Core/UpdateCustomerPartySiebelReqABCSImpl/V2}
UpdateCustomerPartySiebelReqABCSImplV2','Default.SystemID',true())"/>
<to variable="DefaultSystemID"/>
</copy>
</assign>

A.4 aia:getEBMHeaderSenderSystemNode()

namespace aia="http://www.oracle.com/XSL/Transform/java/oracle.apps.aia.core.
xpath.AIAFunctions"
node-set aia:getEBMHeaderSenderSystemNode (string senderSystemCode, string
senderSystemID)

A.4.1 パラメータ

- senderSystemCode
Oracle AIAシステム・レジストリに定義されたシステム・コード。

- senderSystemID
Oracle AIAシステム・レジストリに定義されたシステム内部ID。

Oracle AIAシステム・レジストリの保守方法については、「Oracle AIAシステム・レジストリの管理」を参照してください。

A.4.2 戻り値

Oracle AIAシステム・レジストリに入力された特定のシステム・コードまたは内部IDに対するシステム情報のノード・セットを返します。

A.4.3 使用方法

図A-1に示すような「システム」ページの設定がある場合、aia:getEBMHeaderSenderSystemNode('SEBL_01', '')とaia:getEBMHeaderSenderSystemNode('', 'siebel')の両方が、例A-1に示すノード・セットを返します。

図A-1 「システム」ページのエントリとaia:getEBMHeaderSenderSystemNode()

例A-1 aia:getEBMHeaderSenderSystemNode()で返されるノード・セット

<ID xmlns="">SEBL_01</ID>
<Description xmlns="">Siebel Instance 01</Description>
<IPAddress xmlns="">xxxxx.siebel.com</IPAddress>
<ContactName xmlns="">Siebel contact</ContactName>
<ContactPhone xmlns="">1234567891</ContactPhone>
<ContactEmail xmlns="">Siebelcontact@Siebel.com</ContactEmail>
<Url xmlns="">http://xxxxx.siebel.com:80/ecommunications_enu</Url>
<Application xmlns="">
<ID>CRM</ID>
<Version>8.0</Version>
</Application>

aia:getEBMHeaderSenderSystemNode()に対応するXSLTの例を例A-2に示します。

ヒント:

この例では<xsl:stylesheet version="2.0" ...>が必要です。

例A-2 aia:getEBMHeaderSenderSystemNode()に対応するXSLTの例

<xsl:variable name="senderNodeVariable">
</xsl:variable>

<corecom:Sender>
<corecom:ID>
<xsl:value-of select="$RequestTargetSystemID"/>
</corecom:ID>
<corecom:Description>
<xsl:value-of select="$senderNodeVariable/Description"/>
</corecom:Description>
<corecom:IPAddress>
<xsl:value-of select="$senderNodeVariable/IPAddress"/>
</corecom:IPAddress>
<corecom:CallingServiceName> ...
</corecom:CallingServiceName>
<corecom:Application>
<corecom:ID>
<xsl:value-of select="$senderNodeVariable/Application/ID"/>
</corecom:ID>
<corecom:Version>
<xsl:value-of select="$senderNodeVariable/Application/Version"/>
</corecom:Version>
</corecom:Application>
<corecom:ContactName>
<xsl:value-of select="$senderNodeVariable/ContactName"/>
</corecom:ContactName>
<corecom:ContactEmail>
<xsl:value-of select="$senderNodeVariable/ContactEmail"/>
</corecom:ContactEmail>
<corecom:ContactPhoneNumber>
<xsl:value-of select="$senderNodeVariable/ContactPhone"/>
</corecom:ContactPhoneNumber>
...
</corecom:Sender>

A.5 aia:getSystemType()

namespace aia="http://www.oracle.com/XSL/Transform/java/oracle.apps.aia.
core.xpath.AIAFunctions"
string aia:getSystemType (string systemCode)

A.5.1 パラメータ

systemCode: Oracle AIAシステム・レジストリに入力されたシステム・コード。

Oracle AIAシステム・レジストリの保守方法については、「Oracle AIAシステム・レジストリの管理」を参照してください。

A.5.2 戻り値

Oracle AIAシステム・レジストリに入力されたシステム・コードに関連するシステム・タイプを返します。

A.5.3 使用方法

図A-2に示すような「システム」ページの設定がある場合、aia:getSystemType('SEBL_01')の結果は文字列SIEBELになります。

図A-2 「システム」ページのエントリとaia:getSystemType()

- XSLTの例:

<xsl:variable name="systemType" select="aia:getSystemType('SEBL_01')"/>

- BPELの例:

<assign name="AssignVar">
<copy>
<from expression= "aia:getSystemType('SEBL_01')"/>
<to variable="SystemType"/>
</copy>
</assign>

A.6 aia:getErrorMessage()

namespace aia="http://www.oracle.com/XSL/Transform/java/oracle.apps.aia.core.
xpath.AIAFunctions"
string aia:getErrorMessage (string errorCode, string localeString, string
delimiter)

A.6.1 パラメータ

- errorCode
エラー・コード。

- localeString
デリミタで区切られたロケール文字列。

- Delimiter
localeStringで使用されるデリミタ。

A.6.2 戻り値

この関数はエラー・メッセージ・バンドルを参照し、入力errorCodeに対応するローカライズ文字列を返します。localeStringは、LanguageCode、CountryCodeおよびバリアントを指定のデリミタで連結した文字列です。入力パラメータでロケールが見つからない場合は、システムのデフォルト・ロケールが使用されます。

詳細は、java.util.Localeドキュメント(http://download.oracle.com/javase/1.5.0/docs/api/java/util/class-use/Locale.html)を参照してください。

A.6.3 使用方法

- XSLTの例:

<xsl:variable name="errMsg" select="aia:getErrorMessage('AIA_ERR_AIAO2C2_
1007','','')"/>

- BPELの例:

<assign name="Assign_Fault">
<copy>
<from expression="'AIA_ERR_AIAO2C2_1007'"/>
<to variable="AIAFaultMsg" part="AIAFault"query="/corecom:
Fault/corecom:FaultNotification/corecom:FaultMessage/corecom:Code"/>
</copy>
<copy>
<from expression="aia:getErrorMessage('AIA_ERR_AIAO2C2_1007','','')"/>
<to variable="AIAFaultMsg" part="AIAFault"query="/corecom:
Fault/corecom:FaultNotification/corecom:FaultMessage/corecom:Text"/>
</copy>
</assign>

A.7 aia:getCorrectiveAction()

namespace aia="g aia:getCorrectiveAction (string correctiveActionCode,
string localeString, string delimiter)

A.7.1 パラメータ

- correctiveActionCode
修正処理コード。

- localeString
デリミタで区切られたロケール文字列。

- Delimiter
localeStringで使用されるデリミタ。

A.7.2 戻り値

この関数は修正処理コード・リソース・バンドルを参照し、入力correctiveActionCodeに対応するローカライズ文字列を返します。

localeStringは、LanguageCode、CountryCodeおよびバリアントを指定のデリミタで連結した文字列です。入力パラメータでロケールが見つからない場合は、システムのデフォルト・ロケールが使用されます。

詳細は、java.util.Localeドキュメント(http://download.oracle.com/javase/1.5.0/docs/api/java/util/class-use/Locale.html)を参照してください。

A.7.3 使用方法

- XSLTの例:

<xsl:variable name="corrAction" select="aia:getCorrectiveAction('SAMPLECODE'
,'','')"/>

- BPELの例:

<assign name="Assign_Fault">
<copy>
<from expression="aia:getCorrectiveAction('SAMPLECODE','','')"/>
<to variable="AIAFaultMsg" part="AIAFault" query="/corecom:Fault/
corecom:FaultNotification/corecom:CorrectiveAction"/>
</copy>
</assign>

A.8 aia:isTraceLoggingEnabled()

namespace aia="http://www.oracle.com/XSL/Transform/java/oracle.apps.aia.
core.xpath.AIAFunctions"
string aia:isTraceLoggingEnabled (string logLevel, string processName)

A.8.1 パラメータ

- logLevel
記録するログのレベル。

- processName
プロセスの名前。

A.8.2 戻り値

指定したプロセスに対して指定のlogLevelが有効かどうかを示すブール値。

この関数は2つの処理を実行します。

1. AIAConfigurationProperties.xmlファイルの入力プロセス名に対してロギングが有効か無効かをチェックします。

2. トレース・ロガーのログ・レベルが入力ログ・レベルを記録するように設定されているかどうかをチェックします。

この関数は、前述の両方の条件がtrueを返す場合はtrueを、それ以外の場合はfalseを返します。logLevelパラメータがnullの場合または正しく指定されていない場合、この関数はfalseを返します。processNameがnullまたは空の文字列の場合、この関数はnullを返します。

A.8.3 使用方法

- XSLTの例:

<xsl:variable name="testVal" select="aia:isTraceLoggingEnabled('INFO',
'SamplesCreateCustomerSiebelReqABCSImpl')" />

- BPELの例:

<assign name="Assign_Fault">
<copy>
<from expression="aia:isTraceLoggingEnabled('INFO',
'SamplesCreateCustomerSiebelReqABCSImpl')"/>
<to variable="isTraceLoggingEnabledVal"/>
</copy>
</assign>

A.9 aia:logErrorMessage()

namespace aia="http://www.oracle.com/XSL/Transform/java/oracle.apps.aia.
core.xpath.AIAFunctions"
string aia:logErrorMessage (node-set ebmHeader, string message)

この関数はエラー・メッセージをログに記録します。ebmHeaderパラメータがnullまたは渡されない場合、メッセージは追加属性なしでログに記録されます。エラー・メッセージは常にレベルSEVEREでログに記録されます。

A.9.1 パラメータ

- ebmHeader
エラー・メッセージのコンテキストを示すエンタープライズ・ビジネス・メッセージ(EBM)ヘッダー。

- Message
ログに記録するメッセージ。

A.9.2 戻り値

空の文字列を返します。

A.9.3 使用方法

- XSLTの例:

<xsl:variable name="testVal"  select="aia:logErrorMessage
(oraext:parseEscapedXML('<test></test>'),'LogError:: Your Error message
goes here................................')"/>

- BPELの例:

<assign name="Assign_Fault">
<copy>
<from expression="aia:logErrorMessage(oraext:parseEscapedXML
('<test></test>'),'LogError from XSL::Your Error Message goes
here...........')"/>
<to variable="testXpathVal"/>
</copy>
</assign>

A.10 aia:logTraceMessage()

namespace aia="http://www.oracle.com/XSL/Transform/java/oracle.apps.aia.
core.xpath.AIAFunctions"
string aia:logTraceMessage (string level, node-set ebmHeader, string message)

この関数はトレース・メッセージをログに記録します。

ebmHeaderパラメータがnullまたは渡されない場合、メッセージは追加属性なしでログに記録されます。

レベル・パラメータがnullの場合または正しく指定されていない場合、メッセージはレベルINFOでログに記録されます。レベルはjava.util.logging.Levelである必要があります。

次に、レベルを降順で示します。

- SEVERE (最高値)

- WARNING

- INFO

- CONFIG

- FINE

- FINER

- FINEST(最低値)

A.10.1 パラメータ

- Level
トレース・メッセージのレベル。

- ebmHeader
トレース・メッセージのコンテキストを示すEBMヘッダー。

- Message
ログに記録するメッセージ。

A.10.2 戻り値

空の文字列を返します。

A.10.3 使用方法

- XSLTの例:

<xsl:variable name="testVal"  select="aia:logTraceMessage('ERROR',
oraext:parseEscapedXML('<test></test>'),'LogTrace :: Your Trace message
goes her................')" />

- BPELの例:

<assign name="Assign_Fault">
<copy>
<from expression="aia:logTraceMessage
('ERROR',ora:parseEscapedXML('<test></test>'),'LogTraceError::
Your trace message goes here..........')"/>
<to variable="testXpathVal"/>
</copy>
</assign>

A.11 aia:getNotificationRoles()

namespace aia="http://www.oracle.com/XSL/Transform/java/oracle.apps.aia.
core.xpath.AIAFunctions"
node-set aia:getNotificationRoles (string systemId, string errorCode,
string serviceName, string processName)

A.11.1 パラメータ

- systemId
システムID。

- errorCode
エラー・コード。

- serviceName
エラーが発生したサービスの名前。

- processName
エンドツーエンド・プロセスの名前。

A.11.2 戻り値

この関数は、入力値を使用してOracle AIAシステム・レジストリに対する問合せを実行し、入力errorCodeに対応するアクター・ロールとFYIロールを含むノードセットを返します。

次に例を示します。

<actor>seblAdmin</actor>
<fyi>seblCSR</fyi>

serviceNameがnullまたは空の文字列の場合、またはOracle AIAシステム・レジストリに値が見つからない場合、この関数はAIAConfigurationProperties.xmlファイルに指定されたデフォルトのロールを返します。

Oracle AIAシステム・レジストリの保守方法については、「Oracle AIAシステム・レジストリの管理」を参照してください。

A.11.3 使用方法

- XSLTの例:

<xsl:variable name="testVal"  select="aia:getNotificationRoles
('AIADEMO','AIADEMO_ORDER_FALLOUT','AIADemoProcessSalesOrderCBP',
'AIADemoProcessSalesOrderCBP')" />

- BPELの例:

<assign name="Assign_Fault">
<copy>
<from expression="aia:getNotificationRoles('AIADEMO','AIADEMO_ORDER_
FALLOUT','AIADemoProcessSalesOrderCBP','AIADemoProcessSalesOrderCBP')
"/>
<to variable="testXpathVal"/><to variable="NotificationRole"/>
</copy>
</assign>

A.12 aia:getAIALocalizedString()

namespace aia="http://www.oracle.com/XSL/Transform/java/oracle.apps.aia.
core.xpath.AIAFunctions"
string aia:getAIALocalizedString (string resourceBundleId, string key,
node params)
string aia:getAIALocalizedString (string resourceBundleId, string key,
string language, string country, node params)

A.12.1 パラメータ

- resourceBundleId
ローカライズ文字列を取得するAIAリソース・バンドルを識別します。

- key
リソース・バンドルから値を選択する必要があるキー。

- language
ローカライズ文字列を取得するjava.util.Localeに従った言語。

- Country
ローカライズ文字列を取得するjava.util.Localeに従った国。

- Params
ローカライズ文字列内のバインド変数に対して値を提供するノード。

例A-3に示すように、AIAConfigurationProperties.xmlファイルにはresourceBundleId値からリソース・バンドル・クラス名へのマッピングを提供する一連のモジュール構成プロパティが格納されています。

このマッピングは、ローカライズ文字列の参照に使用するリソース・バンドル・クラスを判別するために実行時に使用されます。

例A-3 モジュール構成プロパティ

<ModuleConfiguration moduleName="ResourceBundle">
<property name="Telco/BillingManagement">oracle.apps.aia.core.
i18n.AIAListResourceBundle</property>
<property name="Telco/ProductLifeCycle">oracle.apps.aia.core.
i18n.AIAListResourceBundle</property>
<property name="Telco/SalesOrder">oracle.apps.aia.core.i18n.
AIAListResourceBundle</property>
<property name="Telco/CustomerParty">oracle.apps.aia.core.i18n.
AIAListResourceBundle</property>
</ModuleConfiguration>

A.12.2 戻り値

この関数は、resourceBundleIdによって識別されたAIAリソース・バンドルから渡されたキーに対するローカライズ文字列を返します。言語または国を省略すると、デフォルトのロケールが想定されます。

A.12.3 使用方法

例A-4に、aia:getAIALocalizedString()に対応するBPELの使用例を示します。

例A-4 aia:getAIALocalizedString()に対応するBPELの使用例

<assign name="Assign_1">
<copy>
<from variable="inputVariable" part="payload" query="/sordabo:
ListOfSWIOrderIO/sordabo:SWIOrder/sordabo:OrderNumber"/>
<to variable="localizedStringParams" query="/bpelcom:parameters/
bpelcom:item/bpelcom:value"/>
</copy>
<copy>
<from expression="aia:getAIALocalizedString ('Telco/SalesOrder','ORDER_
NUMBER_MESSAGE',bpws:getVariableData(&quot;localizedStringParams&quot;))
"/>
<to variable="internationalizedstring"/>
</copy>
</assign>

A.13 aia:getConvertedDate()

namespace aia="http://www.oracle.com/XSL/Transform/java/oracle.apps.aia.
core.xpath.AIAFunctions"
string getConvertedDate(String dateTimeTz, String timeZone, boolean
needAnException)

A.13.1 パラメータ

- dateTimeTz
標準W3CおよびRFC日付書式の日時(文字列)。例: yyyy-MM-dd'T'HH:mm:ss.SSSZ。

- timeZone
ターゲット・タイムゾーン(3文字のコード)。例: IST、GMTオフセット+05:30。

- needAnException
ブール・フラグ: trueは解析エラーの場合に例外をスローし、falseは入力日を返します。

A.13.2 戻り値

この関数は、変換後の日付(文字列)をyyyy-MM-dd'T'HH:mm:ss.SSSの書式でタイムゾーンの指定なしに返します。

A.13.3 使用方法

- XSLTの例:

<xsl:value-of select="aia:getConvertedDate(ns0:
CreateEngineeringChangeOrderList/ns0:ImplementationDate,$ebizTimeZone,false
())"/>

- BPELの例:

<copy>
<from expression="aia:getConvertedDate("2010-04-26T16:25:00+05:30",
"-08:00", false()) "/>
<to variable="getConvertedDateVal"/>
</copy>

A.14 aia:getConvertedDateWithTZ()

namespace aia="http://www.oracle.com/XSL/Transform/java/oracle.apps.aia.
core.xpath.AIAFunctions"
string getConvertedDateWithTZ(String dateTimeTz, String timeZone,
boolean needAnException)

A.14.1 パラメータ

- dateTimeTz
標準W3CおよびRFC日付書式の日時(文字列)。例: yyyy-MM-dd'T'HH:mm:ss.SSSZ。

- timeZone
ターゲット・タイムゾーン(3文字のコード)。例: IST、GMTオフセット+05:30。

- needAnException
ブール・フラグ: trueは解析エラーの場合に例外をスローし、falseは入力日を返します。

A.14.2 戻り値

この関数は、変換後の日付(文字列)を入力日付書式でタイムゾーンの指定なしに返します。

A.14.3 使用方法

- XSLTの例:

<xsl:value-of select="aia:getConvertedDateWithTZ(ns0:
CreateEngineeringChangeOrderList/ns0:ImplementationDate,$ebizTimeZone,
false())"/>

- BPELの例:

<copy>
<from expression="aia:getConvertedDateWithTZ('2010-04-26T14:30:00
+00:00','+05:30', false())"/>
<to variable="getConvertedDateWithTZVal"/>
</copy>

B CAVS対応Oracle AIAサービス開発用のXSL

この付録では、コンポジット・アプリケーション検証システム(CAVS)対応のOracle Application Integration Architecture (AIA)サービスの開発で使用する必要があるXSLテキストを示します。

この付録の内容は次のとおりです。

- AddTargetSystemID.xsl

- SetCAVSEndpoint.xsl

B.1 AddTargetSystemID.xsl

例B-1に、CAVS対応のプロバイダ・アプリケーション・ビジネス・コネクタ・サービス(ABCS)を開発する際に使用する必要があるXSLテキストを示します。

このXSLの使用方法の詳細は、「CAVS対応のABCSの開発」を参照してください。

例B-1 AddTargetSystemID.xsl

<?xml version="1.0" encoding="UTF-8" ?>
<xsl:stylesheet version="1.0"
xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"
xmlns:ehdr="http://www.oracle.com/XSL/Transform/java/oracle.tip.esb.server.
headers.ESBHeaderFunctions"
xmlns:hwf="http://xmlns.oracle.com/bpel/workflow/xpath"
xmlns:xp20="http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.
functions.Xpath20"
xmlns:xref="http://www.oracle.com/XSL/Transform/java/oracle.tip.xref.xpath.
XRefXPathFunctions"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:ora="http://schemas.oracle.com/xpath/extension"
xmlns:ids="http://xmlns.oracle.com/bpel/services/IdentityService/xpath"
xmlns:orcl="http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.
functions.ExtFunc"
xmlns:corecom="http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V2"
xmlns:aia=http://www.oracle.com/XSL/Transform/java/oracle.apps.aia.core.
xpath.AIAFunctions exclude-result-prefixes="xsl plnk coresalesorder ns0 ns3
ns5 ns1 client corecustcom ns4 corecom bpws ehdr aia hwf xp20 xref ora ids
orcl">
<xsl:param name="ConfigServiceName">{[ABCServiceNamespace]}[ABCServiceName]
</xsl:param>
<xsl:param name="ConfigPropertyName">Default.SystemID</xsl:param>

<xsl:template match="/*">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>

<xsl:template match="corecom:EBMHeader">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>

<xsl:template match="corecom:EBMHeader/corecom:Sender">
<xsl:copy-of select="."/>
<xsl:if test="not(following-sibling::corecom:Target)">
<corecom:Target>
<xsl:variable name="TargetID" select="aia:getServiceProperty
($ConfigServiceName,$ConfigPropertyName,true())"/>
<corecom:ID>
<xsl:value-of select="$TargetID"/>
</corecom:ID>
<corecom:ApplicationTypeCode>
<xsl:value-of select="aia:getSystemType($TargetID)"/>
</corecom:ApplicationTypeCode>
</corecom:Target>
</xsl:if>
</xsl:template>

<xsl:template match="corecom:EBMHeader/corecom:Target">
<corecom:Target>
<xsl:copy-of select="@*"/>
<xsl:variable name="TargetID">
<xsl:choose>
<xsl:when test="corecom:ID/text()">
<xsl:value-of select="corecom:ID/text()"/>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="aia:getServiceProperty
($ConfigServiceName,$ConfigPropertyName,true())"/>
</xsl:otherwise>
</xsl:choose>
</xsl:variable>
<corecom:ID>
<xsl:copy-of select="corecom:ID/@*"/>
<xsl:value-of select="$TargetID"/>
</corecom:ID>
<xsl:copy-of select="corecom:OverrideRoutingIndicator"/>
<xsl:copy-of select="corecom:ServiceName"/>
<corecom:ApplicationTypeCode>
<xsl:copy-of select="corecom:ApplicationTypeCode/@*"/>
<xsl:choose>
<xsl:when test="corecom:ApplicationTypeCode/text()">
<xsl:value-of select="corecom:ApplicationTypeCode/text()"/>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="aia:getSystemType($TargetID)"/>
</xsl:otherwise>
</xsl:choose>
</corecom:ApplicationTypeCode>
<xsl:copy-of select="corecom:EndPointURI"/>
<xsl:copy-of select="corecom:Custom"/>
</corecom:Target>
</xsl:template>

<xsl:template match="@*|node()">
<xsl:copy-of select="."/>
</xsl:template>

</xsl:stylesheet>

B.2 SetCAVSEndpoint.xsl

例B-2に、CAVS対応のリクエスタABCSを開発する際に使用する必要があるXSLテキストを示します。

このXSLの使用方法の詳細は、「CAVS対応のABCSの開発」を参照してください。

例B-2 SetCAVSEndpoint.xsl

<?xml version="1.0" encoding="UTF-8" ?>
<xsl:stylesheet version="1.0"xmlns:xsl=http://www.w3.org/1999/XSL/Transform
xmlns:ehdr="http://www.oracle.com/XSL/Transform/java/oracle.tip.esb.server.
headers.ESBHeaderFunctions" xmlns:jhdr="http://xmlns.oracle.com/esb"
xmlns:corecom=http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V2
exclude-result-prefixes="xsl corecom ehdr jhdr">
<xsl:template match="/">
<xsl:copy-of select="/*"/>
<xsl:variablename="Endpoint"select="/*/corecom:EBMHeader/corecom:Message
ProcessingInstruction/corecom:DefinitionID"/>
<xsl:if test="$Endpoint!=''">
<xsl:variable name="SetEndpoint"select="ehdr:setOutboundHeader
('/jhdr:ESBHeader/jhdr:location',$Endpoint,'jhdr=http://xmlns.
oracle.com/esb;')"/>
</xsl:if>
</xsl:template>
</xsl:stylesheet>

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2015, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。