cXML ProfileRequest

Capability-discovery transaction. It enumerates the URLs at which a partner accepts each kind of cXML request and also doubles as an application-level ping to confirm the server is reachable.

Purpose

Before sending any cXML transaction, a buyer does not necessarily know which URL the supplier exposes for each kind of request. The ProfileRequest solves that : it is an empty payload (declared EMPTY in the DTD) that asks the partner to reply with a ProfileResponse listing every supported transaction and its endpoint. The DTD also notes that the same request acts as a ping : a Status code="200" means the server is reachable.

The profile is meant to be stable ("the content should not change frequently", per the DTD), so buyers cache it and refresh it periodically rather than on every transaction.

XML structure

ProfileRequest

The element itself is EMPTY. The useful payload is the Header, which identifies the requester through From, To and Sender, each carrying one or more Credential elements.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.069/cXML.dtd">
<cXML payloadID="260513.143000.profile@buyer.example"
      timestamp="2026-05-13T14:30:00+00:00"
      version="1.2.069">
  <Header>
    <From>
      <Credential domain="DUNS"><Identity>123456789</Identity></Credential>
    </From>
    <To>
      <Credential domain="DUNS"><Identity>987654321</Identity></Credential>
    </To>
    <Sender>
      <Credential domain="DUNS">
        <Identity>123456789</Identity>
        <SharedSecret>shared-secret-here</SharedSecret>
      </Credential>
      <UserAgent>ediverse-buyer/1.0</UserAgent>
    </Sender>
  </Header>
  <Request>
    <ProfileRequest/>
  </Request>
</cXML>

ProfileResponse

The response arrives synchronously over HTTP, wrapped in a top-level Response. It contains a Status, then a ProfileResponse with a required effectiveDate, optional global Option values, and at least one Transaction. Each Transaction carries a requestName (the cXML transaction name, e.g. OrderRequest) and a URL pointing at the matching endpoint.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.069/cXML.dtd">
<cXML payloadID="260513.143005.profile-resp@supplier.example"
      timestamp="2026-05-13T14:30:05+00:00"
      version="1.2.069">
  <Response>
    <Status code="200" text="OK"/>
    <ProfileResponse effectiveDate="2026-01-01T00:00:00+00:00">
      <Option name="Locale">en_US</Option>
      <Transaction requestName="OrderRequest">
        <URL>https://supplier.example/cxml/order</URL>
      </Transaction>
      <Transaction requestName="PunchOutSetupRequest">
        <URL>https://supplier.example/cxml/punchout</URL>
      </Transaction>
      <Transaction requestName="ProfileRequest">
        <URL>https://supplier.example/cxml/profile</URL>
      </Transaction>
    </ProfileResponse>
  </Response>
</cXML>

Required vs optional

On the request side, everything sits in the root: the DTD requires payloadID and timestamp (#REQUIRED). The Header requires From, To and Sender, and the Sender must contain at least one Credential plus a UserAgent.

On the response side, the DTD declares ProfileResponse ( Option*, Transaction+ ) — so at least one Transaction is required — with the effectiveDate attribute as #REQUIRED and lastRefresh as #IMPLIED. Each Transaction has a #REQUIRED requestName. The contained URL is mandatory (cardinality 1 in the content model).

Common patterns

The Header follows the same shape everywhere in cXML: From and To represent the business identities of the issuer and recipient (typically DUNS, GLN, or network IDs), while Sender represents the party that physically opens the HTTP connection — frequently a network hub such as SAP Business Network that is neither the business From nor the To. The Sender credential carries the SharedSecret used as transport authentication.

The UserAgent is free-form (#PCDATA) and identifies the sending application, analogous to the HTTP User-Agent. Hubs and logs use it for provenance tracking.

The requestName attribute on Transaction is not a closed enumeration in the DTD — it is a free %nmtoken. The DTD does list the canonical values: ProfileRequest, OrderRequest, PunchOutSetupRequest, StatusUpdateRequest, InvoiceDetailRequest, ConfirmationRequest, ShipNoticeRequest, etc.

Documentation

• cXML.dtd — current version — search for ELEMENT ProfileRequest and ELEMENT ProfileResponse.
• cXML Reference Guide (PDF) — chapter dedicated to the Profile transaction and discovery flow.
• cXML overview — document anatomy and the rest of the transaction set.