4. プロファイルトランザクション

プロファイルトランザクションを使用すると、サポート対象の cXML のバージョン、トランザクション、およびそれらのトランザクションに対するオプションなどを含む cXML サーバー機能を確認できます。ProfileRequest ドキュメントとProfileResponse ドキュメントは、cXML 1.1 およびそれ以降のバージョンで実装されたすべてのサーバーでサポートされます。

4.1 プロファイルトランザクションの概要
4.2 ProfileRequest
4.3 ProfileResponse

4.3.1 Option 要素
4.3.1.1 MAC オプション
4.3.1.2 サービス
4.3.1.3 PunchOutSetupRequest オプション
4.3.1.4 OrderRequest オプション
4.3.1.5 SessionStatusRequest オプション
4.3.2 トランザクション

4.4 シナリオ

4.4.1 バイヤーからサプライヤへ
4.4.2 バイヤーからネットワークハブへ
4.4.3 ネットワークハブからサプライヤへ
4.4.4 ネットワークハブからサービスプロバイダへ
4.4.5 ネットワークハブからバイヤーへ
4.4.6 サービスプロバイダからバイヤーへ

4.1 プロファイルトランザクションの概要

プロファイルトランザクションを使用すると、組織またはグループから相手側に対して、cXML 機能に関する照会ができます。これらの組織には、サプライヤ、バイヤー、ネットワークハブ、サービスプロバイダ、およびマーケットプレイスがあります。サーバー機能を照会するには、ProfileRequest ドキュメントを送信します。サーバーは、そのサーバー情報を含む ProfileResponse ドキュメントを返信します。 cXML を実装したすべてのサーバーは、プロファイルトランザクションをサポートする必要があります。それは、アプリケーション間のバックエンド統合を行うためで、それにより cXML サーバーの機能がクライアントのシステムで使用可能になります。 ProfileResponse には、特定の Web サイトでサポートされるすべての Request が記載されますが、組織がサポートするすべての Request を記載する必要はありません。OrderRequest ドキュメントの受信、さまざまなメッセージの送信、または Request/Response トランザクションの開始を実行できるサプライヤは、プロファイルトランザクションで自社の OrderRequest サポートを記述します。ProfileRequest によって返されたデータはキャッシュしておき、取引を行うコミュニティの管理者によって決められた期間使用できます。プロファイルトランザクションはサーバーを “ping” する cXML プロトコル機能としても使用することができます。プロファイルトランザクションは、ドキュメントのトラッキングでその所在地を検索するためにも使用することができます。この使用方法は、OrderRequest ドキュメントで使用される Followup 要素に代わるものです。任意のドキュメントの送信先を取得するには、ProfileRequest ドキュメントをサーバーに送信します。

4.2 ProfileRequest

この要素には内容はありません。Header を使用して、該当する cXML サーバーに単にルーティングされるだけです。サーバーは、以下に示すように ProfileResponse 要素を 1 つ含めて応答します。この応答で唯一変更される部分は、cXML 要素自体の payloadID 属性と timestamp 属性です。このメッセージに限り、サーバーは複数の地域情報で応答する必要はありません。この種類の Request の例を示します。

ProfileRequest ドキュメントをネットワークハブに送信するときは、「ルート」 URL に送信する必要があります。この URL は絶対に変更されることがありません。このルート URL に ProfileRequest を送信することによって、cXML のすべての Request の種類の URL 所在地を取得できます。ネットワークハブからの ProfileResponse は、ProfileRequest の To 要素によって異なります。

4.3 ProfileResponse

この要素には、サポートされるトランザクション、それらの所在地、およびサポートされるすべてのオプションのリストが含まれます。次のような ProfileResponse を取得できます。

現在のサプライヤから次のような ProfileResponse が取得されます。

ProfileResponse には次の属性があります。

属性説明
effectiveDate(必須)これらのサービスを利用できるようになった日付と時刻。将来の日付は使用できません。
lastRefreshプロファイルのキャッシュの最終更新がいつかを表します。アプリケーションがプロファイルキャッシュサーバーから ProfileResponse を受信すると、キャッシュ内のデータの年数がわかります。

4.3.1 Option 要素

Option 要素には、サービス全体または特定のトランザクションのどちらかに定義されたオプションの値が含まれます。Option には次の属性があります。

属性説明
name
(必須)
このオプションの名称。この属性をそのまま表示しないでください (プロファイルは機械が読み取るためのものだからです)。ProfileResponse ドキュメントを受信する前に、クライアントシステムはこの制約を理解する必要があります。 name に現在定義されている値は、”service”、”attachments”、”changes”、および”requestNames” です。
4.3.1.1 MAC オプション

ProfileResponse ドキュメントが信頼できるサードパーティ (ネットワークハブなど) によって送信されており、MAC 認証を前提としたトランザクションがリストされている場合には、MAC 認証値をリストした Option 要素が含まれます。クライアントは、サーバーに直接送信するドキュメント内の CredentialMac 要素にこれらの値を挿入します。

例:

サーバーがダイレクトパンチアウトをサポートしている場合は、ProfileResponse 内の PunchOutSetupRequest
に追加の Option 要素が表示されます。

4.3.1.2 サービス

プロファイルトランザクションでは、1 つのトランザクションタイプについて複数のバリエーションを返せます。 cXML サーバーが特定のトランザクションについて複数の実装をサポートしている場合、ProfileResponse でそれらを区別することができます。たとえば、マーケットプレイスが ProviderSetupRequest トランザクション内で marketplace.signin と marketplace.console という 2 つのサービスを提供しているとします。ProfileReponse では、その 2 つを区別できるように一覧表示される必要があります。 ProfileResponse は、1 トランザクションのバリエーションごとに、特定の所在地を一意に識別できます。 ProviderSetupRequest の場合、バリエーションはサービス名です。ProfileResponse では Option 要素を使用して、サービス名と値が設定されます。次に例を示します。

特定のトランザクションタイプの所在地が 1 つしかない場合は、Option 要素は不要です。特定のトランザクションタイプの検索で、Option name=”service” と記述されている場合は、記述されたサービスに一致するトランザクションを使用します。そのような Option 名と値に一致するものがない場合は、オプション名と値のない最初のトランザクションを使用します。1 トランザクションの各バリエーションは、それ自体の特定の所在地を一意に識別する必要があります。 ProviderSetupRequest の場合、一意に識別できる識別子は「service」です。これらの識別子では、Transaction 要素の Option 要素が使用されます。この Option 要素には、一意に識別できる識別子名が含まれます。この Option 要素の値は、一意に識別できる識別子の値です。

4.3.1.3 PunchOutSetupRequest オプション

PunchOutSetupRequest がサポート対象のトランザクションとして返された場合、ダイレクトパンチアウトがサポートされていることを示す 3 つのオプションを指定できます。これらのオプションによって、認証のためネットワークハブ経由にすることなく PunchOutSetupRequest ドキュメントをサーバーに直接送信可能であること、およびどの認証方法がサポートされているかがクライアントに通知されます。

  • ダイレクトパンチアウトの PunchOutSetupRequest ドキュメントを直接受信する URL を指定するには、次のようにします。
  • サーバーでメッセージ認証コード (MAC) による認証がサポートされていることを示すには、次のようにします。
  • さらに、このオプションは、この信頼できるサードパーティに対してサーバーのメッセージ認証コード (MAC) を生成するように指示しています。信頼できるサードパーティが送信したプロファイルの ProfileResponse 要素内には、追加の Option 要素が表示されます。

  • サーバーでデジタル証明書による認証方法がサポートされていることを示すには、次のようにします。
  • このオプションは、PunchOutSetupRequest を検証するために、サーバーにより AuthRequest ドキュメントが送信されることを示しています。これらのオプションは通常のパンチアウトには使用されません。

    4.3.1.4 OrderRequest オプション

    OrderRequest がサポート対象のトランザクションとして返された場合は、attachments と changes という 2 つのオプションを指定する必要があります。attachments オプションでは、添付ファイルが受け取られるかどうかが指定されます。changes オプションでは、変更オーダーと削除オーダーが受け取られるかどうかが指定されます。添付ファイルの受け取りの指定は、次のとおりです。

     変更オーダー受け取りの指定は、次のとおりです。

    どちらのオプションも、通常の値は No です。attachments または changes が No に設定されているドキュメントは、これらのオプションの記述がないドキュメントとまったく同様に処理する必要があります。

    4.3.1.5 SessionStatusRequest オプション

    SessionStatusRequest がサポート対象の取引として返された場合、requestNames というオプションを指定する必要があります。このオプションには通常の値はありません。このオプションでは、Option 要素の内容で指定したどのトランザクションの実行時にも、サーバーがセッションのチェックと更新をサポートすることがクライアントに通知されます。この内容は、「OrderStatusSetupRequest」、「ProviderSetupRequest」、および「PunchOutSetupRequest」の組み合せをスペースで区切った形式のリストで指定する必要があります。一覧表示された各 Request の Transaction 要素も、ProfileResponse ドキュメントに含まれる必要があります。

    4.3.2 トランザクション

    サーバーのサービスによってサポートされるトランザクションの説明です。プロファイル定義は、特定の Request を送信する宛先の現在の所在地を示します。cXML の将来のバージョンでは、さらに Option 定義が追加されるとともに、現在サポートされている Request のより詳細な情報が含まれるようにプロファイル情報が拡張される可能性があります。 Transaction 要素には URL 属性が含まれている必要があります。Transaction には次の属性があります。

    属性説明
    requestName(必須)このサーバーが特定の Request を受け付ける URL を指定します。この値は、cXML で定義されている Request ドキュメント名のいずれかになります。

    4.4 シナリオ

    ProfileRequest ドキュメントをさまざまな組織またはグループから送信して、サプライヤ、バイヤー、ネットワークハブ、サービスプロバイダ、およびマーケットプレイスのサーバー機能および情報を取得することができます。次のシナリオで現実的な組織の組み合せと、そこから入手できるトランザクション情報の種類について、説明します。

    4.4.1 バイヤーからサプライヤへ

    ProfileRequest ドキュメントは、ネットワークハブを介してバイヤーからサプライヤに送信されます。ネットワークハブは、定期的にサーバー情報をサプライヤに照会してキャッシュします。この情報は、バイヤーに送信する ProfileResponse ドキュメントで使用されます。

    図 3: バイヤーからサプライヤに送信される ProfileRequest

    サプライヤは、サポートしているトランザクションを ProfileResponse で返します。

    例:

  • OrderRequest
  • PunchOutSetupRequest

    バイヤーに送信される ProfileResponse には、そのサプライヤに代わってネットワークハブが提供する機能も含めることができます。

    4.4.2 バイヤーからネットワークハブへ

    ProfileRequest ドキュメントは、バイヤーからネットワークハブに送信されます。

    図 4: バイヤーからネットワークハブに送信される ProfileRequest ドキュメント

    ネットワークハブは、サポートしているトランザクションを ProfileResponse で返します。

    例:

  • SupplierDataRequest
  • SubscriptionListRequest
  • SubscriptionContentRequest
  • GetPendingRequest
  • OrderStatusSetupRequest
  • SupplierListRequest
  • ProviderSetupRequest
  • SessionStatusSetupRequest

    ProfileRequest ドキュメントの例:

    ProfileResponse ドキュメントの例:

    4.4.3 ネットワークハブからサプライヤへ

    ProfileRequest は、ネットワークハブからサプライヤに送信されます。ネットワークハブは、定期的にサーバー情報をサプライヤに照会してキャッシュします。この特定のサプライヤに関する情報は、バイヤー企業に送信する ProfileResponse ドキュメントで使用されます。

    図 5: ネットワークハブからサプライヤに送信される ProfileRequest

    サプライヤは、サポートしているトランザクションを ProfileResponse ドキュメントで返します。

    例:

  • OrderRequest
  • PunchOutSetupRequest

    ProfileRequest ドキュメントの例:

    ProfileResponse ドキュメントの例:

    4.4.4 ネットワークハブからサービスプロバイダへ

    ProfileRequest は、ネットワークハブからサービスプロバイダに送信されます。ルーティングサービスプロバイダは、返信される ProfileReponses の数が 1 つであるか 2 つであるかを指定する必要があります。プロファイル情報はサービスプロバイダおよびサービスプロバイダに紐付けられたサプライヤアカウントの両方に返信することができるためです。

    図 6: ネットワークハブからサービスプロバイダに送信される ProfileRequest

    サービスプロバイダは、サポートしているトランザクションを ProfileResponse ドキュメントで返します。

    例:

  • ProviderSetupRequest
  • SessionStatus
  • OrderRequest

    4.4.5 ネットワークハブからバイヤーへ

    ProfileRequest は、ネットワークハブからバイヤーに送信されます。ネットワークハブは、定期的にサーバー情報をバイヤーに照会してキャッシュします。後で、バイヤーに関するこの情報は、サービスプロバイダとサプライヤに送信される ProfileResponse ドキュメントで使用されます。

    図 7: ネットワークハブからバイヤーに送信される ProfileRequest

    バイヤーは、サポートしているトランザクションを ProfileResponse ドキュメントで返します。

    例:

  • StatusUpdateRequest
  • InvoiceDetailRequest

    4.4.6 サービスプロバイダからバイヤーへ

    ProfileRequest はネットワークハブを介してルーティングされ、サービスプロバイダからバイヤーに送信されます。このシナリオは、Followup 要素に代わるものです。ネットワークハブは、定期的にサーバー情報をバイヤーに照会してキャッシュします。後で、バイヤーに関するこの情報は、サービスプロバイダに送信される ProfileResponse ドキュメントで使用されます。

    図 8: サービスプロバイダからバイヤーに送信される ProfileRequest

    ネットワークハブは、バイヤーの代わりにサポートしているトランザクションを ProfileResponse でサービスプロバイダに返します。

    例:

  • StatusUpdateRequest
  • InvoiceDetailRequest