プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle B2Bユーザーズ・ガイド
12c (12.2.1.2.0)
E82782-02
目次へ移動
目次
索引へ移動
索引

前
前へ
次
次へ

24 AS4ベースのメッセージ交換の有効化

この章では、Oracle B2Bで取引パートナ間のAS4ベースのメッセージ(通常はSOAPベース)交換を有効化する方法について説明します。

この章の構成は、次のとおりです。

24.1 AS4ベースのメッセージ交換の概要

Applicability Statement4 (AS4)は、トランザクションの必須機能を提供するWebサービスの標準を統合する主要な標準の1つです。これは、確認受領通知とエラー・メッセージを定義することでエラー処理を標準化し、メッセージのコレオグラフィをサポートします。Oracle B2Bは、Webサービスを使用したドキュメントに依存しない安全なペイロードの交換のために、交換プロトコル・スタックでAS4プロトコルをサポートしています。

AS4は、様々な機能(一方向プッシュ、一方向プル、Webサービスを通じた信頼性とセキュリティなど)を提供します。AS4では、認証、メッセージ整合性、発信元の否認防止およびプライバシ機能でデータを保護します。

24.2 カスタムWSDLファイルによるAS4ベースのサービス・メッセージの交換

AS4ベースのメッセージは、インバウンド方向とアウトバウンド方向の両方でサポートされます。Generic WebServiceを作成または使用するか、要件に応じてカスタマイズできるWeb Service Definition Language (WSDL)ファイルをアップロードする必要があります。

AS4 ebHandlerはSOAP 1.2を規定していて、SOAP 1.1に依存するBSP 1.1の要件は適用されません。同様に、ここに適用するDESCRIPTION (WSDL)またはREGDATA (UDDI)の要件は、それらが使用されないために存在しません。SOAP 1.1の場合は、サービスからのSOAPフォルトを受信することになります。

WSDLの指定は必ずしも必要ではありません。これは、AS4では、ドキュメント・タイプとビジネス・プロセスからSOAP操作とアクションへのマッピングにかかわる危険性を回避することで、WSDLの複雑さを排除しているためです。既存のGeneric WSDLは、SOAP 1.2サポートで使用できます。

24.2.1 アウトバウンド・メッセージの交換

その他のメッセージと同じように、バックエンド・アプリケーション(Fabric/AQ/JMS/File/FTP/SFTP)からB2Bにメッセージが送信されます。B2Bでは、From/To/ActionとService、またはFrom/To/DoctypeとDocRevisionに基づいて、アグリーメント識別が行われます。

アグリーメント構成に応じて、メッセージ(あらゆるタイプのドキュメント)は、AS4交換プラグインとSOAPパッキングを使用して処理され、取引パートナ・デリバリ・チャネルで構成したようにAS4トランスポートを通じて送信されます。構成されたデリバリ・チャネルに応じて、トランスポートのSYNC/NoneおよびAsyncモードがサポートされます。

24.2.2 インバウンド・メッセージの交換

登録済のAS4 WSリスニング・チャネルに基づいて、取引パートナは適切なAS4ヘッダー付きのメッセージをポストできます。ユーザーは、「管理」→「リスニング・チャネル」を使用して、AS4エンドポイントを登録できます。ドキュメントは、ユーザー・メッセージのSOAPヘッダーまたは通常のドキュメント識別フローに基づいて識別されます。メッセージは、AS4交換プラグインによって処理され、構成済のバックエンド・アプリケーションに配信されます。

AS4交換は、次のURLによって識別できます。
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/

AS4交換プラグインは、トランスポート・レイヤーとしてWS-HTTPも使用します。汎用のSOAP交換は、これを使用して交換を識別します。AS4交換プラグインはGeneric WSの前に追加されることが多いため、交換がAS4として識別されると、Generic Exchangeは識別レイヤーをスキップします。

ドキュメント識別は、SOAPヘッダーの"CollaborationInfo"-> Action/Serviceの組合せに基づきます。取引パートナの識別は、常に、ebMS 3.0仕様(PartyInfo ->From/To partyIdおよびtypeの組合せ)に基づきます。AS4には特定の識別子は存在しません。ユーザーは「管理」→「タイプ」の一部としてカスタム識別子を構成できます。パートナ・プロファイル構成では同じ識別子を使用します。 デフォルト識別子は、名前およびその他の識別対象(DUNSなど)です。ただし、AS4に特定の識別子は存在しません(AS4識別子はありません)。

24.3 取引パートナとホストの設定

Oracle B2Bは、取引パートナにAS4 Webサービス・ベースのメッセージ交換のサポートを提供します。これは、バックエンド・アプリケーションからのペイロードを開始するB2Bバインディングや、AQ、JMS、File、FTPまたはSFTPのコンポジットにより実現します。AS4を使用する取引パートナに同じものを送信できます。

インバウンド側では、Oracle B2BはAS4メッセージを受信して、SOAコンポジットを使用するか、AQ、JMS、File、FTP、またはSFTPを通じてバックエンド・アプリケーションにメッセージを配信します。Oracle B2Bは、SOAPエンベロープ・ヘッダーの「PartyInfo」に基づいて、着信取引パートナを識別できます。
開始取引パートナを追加して、取引パートナ・デリバリ・チャネルを構成するには:
  1. パートナの構成で、「パートナ」をクリックします。
  2. ホストの名前を自社の名前に変更します。
  3. 「+」をクリックして、取引パートナを追加し、パートナの名前を入力します。
  4. この手順で作成した取引パートナをクリックします。
  5. サポート対象のドキュメントを追加するために「ドキュメント」タブをクリックし、「+」をクリックして該当するドキュメントを追加します。
  6. 「チャネル」タブをクリックし、「+」をクリックして交換/トランスポートを追加します。
  7. 「プロトコル」リストで、AS4-1.0を選択します。
  8. 管理でWSDLファイルを定義した場合は、ここで選択します。カスタムのWSDLファイルがない場合は、「汎用SOAPの使用」オプションを選択します。
  9. 「サービス」ドロップダウン・リストから、Generic SOAPServiceを選択します。
  10. 「ポート」ドロップダウン・リストから、Generic Portを選択します。
  11. 「SOAPアクション」ドロップダウン・リストから、generic/soap/processを選択します。
  12. エンドポイントのURLを入力します。
    URLの例: http://myhost.com:7878/b2b/services/ws/tradingpartnername_listeningchannel
  13. 「保存」をクリックして、詳細を保存します。

    注意:

    前述の手順を実行して、応答者も設定します(手順2では、応答者の名前を使用します)。

24.4 メッセージ・パーティション・チャネル

メッセージ・パーティション・チャネル(MPC)により、送信者から受信者へのメッセージのフローは、複数のフローに分割できるようになります。これらのフローは、個別に制御して別々に利用できます。

MPCにより、次の操作が可能になります。

  • 転送優先度の設定: 一部のメッセージは、送信順序にかかわらず高い優先度で転送できます。

  • 受信者側でのメッセージのインフローの編成: 受信者は、個別の方法で各フローに指示を出せます。

次の図は、一方向プル・トランザクションのMPCワーク・フローの例を示しています。

これは、Oracle B2Bの既存の順序付けメカニズムで実現できます。バックエンド・アプリケーションから、「MPC」プロパティの付いたメッセージが送信されると、MPCがシーケンス・メッセージ・ターゲットとして使用されます。これは、appmessage表と順序付けマネージャの表に挿入されます。このメッセージは、プル・メッセージ・リクエストが受信されるまで、B2Bでは処理できません。

プル・メッセージ・リクエストに基づいて、対応するメッセージが順序付けマネージャの表から取り出され、イベント・キューにエンキューされます。その後、メッセージはFrom/To/Action/ServiceまたはFrom/To/Doctype/Docrevisionに基づいてアグリーメント識別を通過します。アグリーメント構成に基づいて、メッセージが処理され、デリバリ・チャネルの構成どおりに取引パートナに送信されます。

メッセージの優先順位付けは、プル・リクエストとレスポンスの一部として処理されます。

24.5 重複メッセージの検出

重複メッセージ検出機能により、メッセージIDに基づいてメッセージの重複を検出できるようになります。AS4には、既存の重複検出機能が再使用されます。

これは、デリバリ・チャネルの一部として構成できます。インバウンド・メッセージ・フローの場合、重複検出が有効化されていると、メッセージの重複が識別され、メッセージの送信者にフォルト・メッセージが送信されます。

例24-1 例: 重複メッセージの検出

次のメッセージIDは、メッセージの重複の有無を検出するために使用されます。

eb:MessageInfo/eb:MessageId

24.6 P-Modeのパラメータ

B2Bでは、P-Modeパラメータをサポートします。次に、AS4機能に関連するパラメータの一覧を示します。

表24-1 P-Modeのパラメータと説明

P-Modeのパラメータ 説明
PMode.ID 取引パートナのプロファイル(ID)を構成できます。
PMode.Agreement アグリーメントIDは、アグリーメント参照を提供するために使用されます。
PMode.MEP メッセージ交換パターン(MEP)は、バックエンド・アプリケーションからエンキューされたeventNameに基づきます。
PMode.MEPbinding メッセージ交換パターン(MEP)は、バックエンド・アプリケーションからエンキューされたeventNameに基づきます。取引パートナ・デリバリ・チャネルの構成を使用できます。
PMode.Initiator.Party エンキュー時に、常に起案者になる送信元パーティを設定します
PMode.Initiator.Role エンキュー時に、FromRoleを設定するためのActionName/eventNameを設定します
PMode.Initiator.Authorization.username AuthユーザーをOWSM資格証明に設定します(Basic認証の場合)
PMode.Responder.Party エンキュー時、常に応答者になる送信先パーティを設定します
PMode.Responder.Role エンキュー時に、ToRoleを設定するためのActionName/eventNameを設定します
PMode.Responder.Authorization.username AuthユーザーをOWSM資格証明に設定します(Basic認証の場合)
Protocol.Address これに固有の構成は何も必要ありません(常にデリバリ・チャネルHTTPの一部として考慮されます)。
Protocol.SOAPVersion AS4デリバリ・チャネルの構成で十分です(常にSOAP 1.2を使用します)
BusinessInfo.Service: エンキューの一環としてServiceでActionName/eventNameを設定するか、その逆にカスタム・ドキュメント・プロトコルの一環として設定します(スタティックServiceの場合)
BusinessInfo.Action エンキューの一環としてActionでActionName/eventNameを設定するか、その逆にカスタム・ドキュメント・プロトコルの一環として設定します(スタティックActionの場合)
BusinessInfo.Properties[]: プロパティの追加はサポートされていません
ErrorHandling.Report.ReceiverErrorsTo エラー/例外の場合、B2Bは送信者に例外メッセージを送信します
ErrorHandling.Report.AsResponse エラー/例外の場合、B2Bは送信者に例外メッセージを送信します
[1].ErrorHandling.Report.ProcessErrorNotifyProducer エラーが処理されます。さらに、リクエスト・メッセージの状態をErrorに更新します。
ErrorHandling.Report.DeliveryFailuresNotifyProducer エラーは配信されなくなり、エラー受領通知メッセージはErrorの状態に変化します。
Security.WSSVersion OWSM構成ハンドル
Security.X509.Sign OWSM構成ハンドル
Security.X509.Signature.Certificate OWSM構成ハンドル
Security.X509.Signature.HashFunction OWSM構成ハンドル
Security.X509.Signature.Algorithm OWSM構成ハンドル
Security.X509.Encryption.Encrypt OWSM構成ハンドル
Security.X509.Encryption.Certificate OWSM構成ハンドル
Security.X509.Encryption.Algorithm OWSM構成ハンドル
Security.UsernameToken.username OWSM構成ハンドル
Security.UsernameToken.password OWSM構成ハンドル
Security.UsernameToken.Digest OWSM構成ハンドル
Security.UsernameToken.Created OWSM構成ハンドル
Security.PModeAuthorize OWSM構成ハンドル
Security.SendReceipt OWSM構成ハンドル
Security.SendReceipt.ReplyPattern OWSM構成ハンドル

24.7 ローカル・ポリシー・アタッチメント

LPA (ローカル・ポリシー・アタッチメント)を使用すると、1つのデリバリ・チャネルに複数のポリシーをアタッチできます。デリバリ・チャネルの構成の一環として、OWSMポリシーを選択して特定のエンドポイントにアタッチします。

これは、Webサービス・エンドポイントにアタッチされたポリシーの処理に使用されます。ポリシーのリストは、ドロップダウン・リストから選択できます。選択すると、必要な情報が表示されます。たとえば、メッセージ保護ポリシーは、そのポリシーで構成された証明書エイリアスに基づいてメッセージを保護(署名+暗号化)するために使用されます。

24.8 ユース・ケースのシナリオ

2つのパートナ間でのドキュメントの交換に関するシナリオ。

次の各シナリオでは、2社のパートナAcme社とGlobalChips社がAS4プロトコルを使用したドキュメントの交換を求めていることを想定しています。この目的のために、2つの異なるサーバー(それぞれのパートナ用)にOracle B2B AS4がインストールされているとします。Acmeと呼ばれるサーバーの1つが起案者の役割を果たし、AS4プロトコルを使用してXMLドキュメントをGlobalChipsと呼ばれる応答者に送信します。

24.8.1 インバウンド・メッセージング

MSHの送受信は、信頼できるメッセージングを使用して特定のメッセージ・タイプを交換するように構成されます。送信MSHは、このタイプの署名付きメッセージを送信します。

予測される結果は、受信MSHが同期AS4否認防止の受領通知を返すことです。返された受信通知に含まれるNonRepudiationInformation要素の内容は、受信したメッセージのSignatureと一致する必要があります。これは、メッセージ・ログ、メッセージ・トラッカやTCPモニタリング・ツールを使用することで判断できます(後者の場合はTLSを使用する必要がありません)。

24.8.1.1 応答者の設定

応答者(ここではGlobalChips)を設定するには:
  1. 受信者側のOracle B2Bにログインします。
  2. 「管理」をクリックして、ドキュメントを作成します。
  3. 「ドキュメント」タブで、「カスタム」を選択して「ドキュメント・バージョン」を追加します(たとえば、1.0)。
  4. 作成したドキュメント・バージョンを選択して、「ドキュメント・タイプ」を追加します(たとえば、ORDERS)。
  5. 作成したドキュメント・タイプを選択して、「ドキュメント定義」を追加します(たとえば、Ord_def)。
  6. 「定義」をクリックして、スキーマを指定します。
  7. 「識別タイプ」に、xmlを選択します。
  8. 着信ドキュメントを識別するための、「識別式(XPath)」を指定します。
    例: /*/*[local-name()='shipto']/*[local-name()='country']
  9. 「保存」をクリックして、詳細を保存します。
  10. 受信者側で、リスニング・チャネルの設定の一環として、「ポリシー構成」をクリックします。
  11. ポリシー・リストから、oracle/wss10_message_protection_service_policyを選択してアタッチします。
  12. 前の手順で選択したポリシーの「+」をクリックして、証明書エイリアスを指定します。
  13. メッセージの署名を検証するためのホストの秘密鍵の別名として、keystore.sig.csf.keyを指定します。
  14. メッセージを復号化するためのホストの秘密鍵の別名として、keystore.enc.csf.keyを指定します。