ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

cXML ProfileRequest

Transaction de découverte des capacités. Elle énumère les URLs auxquelles un partenaire accepte chaque type de requête cXML et sert aussi de ping applicatif pour vérifier la disponibilité du serveur.

Objet de la transaction

Avant d'envoyer toute transaction cXML, un acheteur ne sait pas forcément à quelle URL le fournisseur écoute pour chaque type de requête. Le ProfileRequest résout ce problème : c'est un appel vide (élément EMPTY dans le DTD) qui demande au partenaire de répondre par un ProfileResponse listant chaque transaction supportée avec son endpoint. La DTD précise que la même requête peut servir de ping : si l'on reçoit un Status code="200", le serveur est joignable.

Le profil est censé être stable ("the content should not change frequently" selon la DTD), donc les acheteurs le mettent en cache et le rafraîchissent périodiquement plutôt qu'à chaque transaction.

Structure XML

ProfileRequest

L'élément lui-même est EMPTY. Le corps utile du document est le Header qui identifie le demandeur via From, To et Sender, chacun portant un ou plusieurs Credential.

xml profile-request.cxml.xml
<?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+02: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

La réponse arrive en HTTP synchrone, encapsulée dans un Response à la racine. Elle contient un Status, puis un ProfileResponse avec un effectiveDate obligatoire, des Option globaux facultatifs, et au moins une Transaction. Chaque Transaction porte un requestName (le nom de la transaction cXML, ex. OrderRequest) et une URL qui pointe vers l'endpoint correspondant.

xml profile-response.cxml.xml
<?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+02: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>

Requis vs optionnel

Côté requête, tout est dans la racine : la DTD impose payloadID et timestamp en #REQUIRED. Le Header impose From, To et Sender, et chaque Sender doit contenir au moins un Credential plus un UserAgent.

Côté réponse, le DTD déclare ProfileResponse ( Option*, Transaction+ ) — donc au moins une Transaction est requise — avec l'attribut effectiveDate en #REQUIRED et lastRefresh en #IMPLIED. Chaque Transaction a son requestName en #REQUIRED. Le URL à l'intérieur est obligatoire (cardinalité 1 dans le contenu).

Patterns courants

Le Header suit toujours la même structure dans toute la cXML : From et To représentent les identités métier de l'émetteur et du destinataire (typiquement des DUNS, GLN ou identifiants réseau), tandis que Sender représente la partie qui ouvre techniquement la connexion HTTP — souvent un hub réseau comme SAP Business Network qui n'est ni le From ni le To au sens métier. Le Credential du Sender contient le secret partagé (SharedSecret) qui sert d'authentification de transport.

Le UserAgent est une chaîne libre (#PCDATA) qui identifie l'application émettrice — analogue au User-Agent HTTP. Les hubs et les logs s'en servent pour tracer la provenance.

L'attribut requestName de Transaction n'est pas une énumération fermée dans le DTD : c'est un %nmtoken libre. La DTD énumère cependant les valeurs canoniques : ProfileRequest, OrderRequest, PunchOutSetupRequest, StatusUpdateRequest, InvoiceDetailRequest, ConfirmationRequest, ShipNoticeRequest, etc.

Documentation