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 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 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
- cXML.dtd — version courante
— chercher
ELEMENT ProfileRequestetELEMENT ProfileResponse. - cXML Reference Guide (PDF) — chapitre dédié à la transaction Profile et au flux de découverte.
- Vue d'ensemble cXML — anatomie générale du document et autres transactions.