ebXML - Guide rapide

Les entreprises interagissent inévitablement les unes avec les autres de diverses manières. Jusqu'à ces dernières années, de nombreuses grandes entreprises communiquaient automatiquement via l'échange de données informatisé (EDI), qui permet à deux entreprises de communiquer en utilisant des signaux prédéterminés.

Le problème avec l'EDI est qu'il est très coûteux et à l'origine, il a été créé pour le monde mainframe. Maintenant, ebXML remplace l'EDI.

Définition

ebXML signifie Electronique Business Extendu MArkup Language. Il s'agit d'une norme mondiale pour le commerce électronique qui permet à n'importe qui, n'importe où, de faire des transactions commerciales avec n'importe qui sur Internet.

traits

Les fonctionnalités d'ebXML sont les suivantes:

  • ebXML est un framework XML B2B de bout en bout.
  • ebXML est un ensemble de spécifications qui permettent un cadre modulaire.
  • ebXML s'appuie sur les normes existantes d'Internet telles que HTTP, TCP / IP, MIME, SMTP, FTP, UML et XML.
  • ebXML peut être implémenté et déployé sur pratiquement n'importe quelle plate-forme informatique.
  • ebXML fournit des spécifications concrètes pour permettre des collaborations B2B dynamiques.

Vision ebXML

ebXML est conçu pour créer un marché électronique mondial où les entreprises de toute taille, où qu'elles soient, peuvent:

  • se trouver électroniquement.
  • mener les affaires -
    • en utilisant l'échange de messages XML.
    • conformément aux séquences de processus métier standard.
    • avec une sémantique commerciale claire.
    • en utilisant des applications commerciales achetées dans le commerce.
    • conformément aux accords de protocole des partenaires commerciaux convenus d'un commun accord.

Pourquoi ebXML?

  • Les cadres B2B existants ne sont pas adéquats:
    • EDI et RosettaNet sont trop lourds et trop rigides.
    • BizTalk est propriétaire, fournisseur unique et plate-forme unique.
  • Protocole d'accès aux objets simples (SOAP); Langage de définition de service Web (WSDL); et la description, la découverte et l'intégration universelles (UDDI) seules ne sont pas adéquates:
    • WSDL ne traite pas de la collaboration commerciale.
    • SOAP dans sa forme de base ne fournit pas une livraison de messages sécurisée et fiable.
    • UDDI ne fournit pas de capacité de référentiel pour les objets métier.
  • Il est de plus en plus nécessaire de normaliser les collaborations commerciales pour répondre aux problèmes suivants:
    • Processus d'affaires
    • Les parties impliquées dans la collaboration commerciale et leurs rôles
    • Échange de documents XML dans les collaborations commerciales
    • Exigences de sécurité, de fiabilité et de qualité de service de la collaboration commerciale

    Tous ces besoins sont satisfaits par ebXML.

Organisations fondatrices d'ebXML

ebXML est une initiative conjointe de UN / CEFACT et d'OASIS.

UN/CEFACT:

  • Il signifie Centre des Nations Unies pour la facilitation du commerce et le commerce électronique.
  • Il maintient les normes UN / EDIFACT pour l'échange de données informatisées (EDI).

OASIS:

  • Il signifie Organisation pour l'avancement des normes d'information structurée.
  • Il crée et maintient des spécifications d'interopérabilité XML, une large prise en charge de l'industrie.

Par définition, le cycle de vie itératif de B2B collaboration comprend les étapes suivantes:

  • Définition du processus
  • Découverte des partenaires
  • Inscription des partenaires
  • Plug-in électronique
  • Exécution de processus
  • La gestion des processus
  • Évolution des processus

Les spécifications ebXML globales sont destinées à couvrir presque tout le processus de collaboration B2B et sont conçues pour répondre aux besoins décrits ci-dessus.

L'architecture ebXML telle que définie par l'équipe ebXML fournit:

  • Un moyen de définir les processus métier et leurs messages et contenus associés.
  • Un moyen d'enregistrer et de découvrir des séquences de processus métier avec des échanges de messages associés.
  • Une manière de définir des profils d'entreprise.
  • Une façon de définir les accords de partenaires commerciaux.
  • Une couche de transport de message uniforme.

Par conséquent, l'architecture technique d'ebXML est composée de cinq modules:

  • Spécifications des processus métier
  • Profil du partenaire et accords
  • Registre et référentiel
  • Composants principaux
  • Service de messagerie

Ces modules seront traités dans les cinq prochains chapitres. Le diagramme schématique montre l'architecture simplifiée d'ebXML:

Un processus commercial est quelque chose qu'une entreprise fait, comme l'achat de pièces d'ordinateur ou la vente d'un service professionnel. Cela implique l'échange d'informations entre deux ou plusieurs partenaires commerciaux d'une manière prévisible.

Les spécifications pour la définition des processus métier permettent à une organisation d'exprimer ses processus métier afin qu'ils soient compréhensibles par d'autres organisations. Il permet l'intégration des processus métier au sein d'une entreprise ou entre plusieurs entreprises.

le ebXML Business Process Specification Schema (BPSS)fournit la définition d'un document XML qui décrit la manière dont une organisation mène ses activités. Un BPSS ebXML est une déclaration des partenaires, des rôles, des collaborations, des chorégraphies et des échanges de documents commerciaux qui composent un processus métier.

Le diagramme suivant donne une vue conceptuelle du processus métier.

Collaborations commerciales

Une collaboration commerciale est un ensemble chorégraphié d'activités de transaction commerciale, dans lequel deux partenaires commerciaux échangent des documents.

La plus courante est une collaboration binaire, dans laquelle deux partenaires échangent des documents. Une collaboration multipartite a lieu lorsque des informations sont échangées entre plus de deux parties.

Les collaborations multipartites sont en fait des collaborations binaires chorégraphiées.

À son niveau le plus bas, une collaboration commerciale peut être décomposée en transactions commerciales.

Transactions commerciales

Une transaction commerciale est le niveau atomique de travail dans un processus commercial. Il réussit ou échoue complètement.

Les transactions commerciales sont des transactions dans lesquelles les partenaires commerciaux transfèrent effectivement des documents commerciaux.

Flux de documents commerciaux:

Une transaction commerciale est réalisée sous forme de flux de document commercial entre les rôles demandeur et répondant. Il y a toujours un document commercial demandeur, et éventuellement un document commercial répondant, en fonction de la sémantique de transaction souhaitée, par exemple, notification unidirectionnelle ou conversation bidirectionnelle.

La définition réelle du document est obtenue à l'aide des spécifications des composants de base ebXML, ou par une méthodologie externe à ebXML mais résultant en une DTD ou un schéma vers lequel une spécification de processus métier ebXML peut pointer.

Chorégraphie:

La chorégraphie s'exprime en termes d'états et de transitions entre eux. Une activité commerciale est appelée état abstrait, avec des collaborations commerciales et des activités de transaction commerciale appelées états concrets. La chorégraphie est décrite dans le schéma de spécification de processus métier ebXML à l'aide de concepts de diagramme d'activité tels que l'état de démarrage, l'état d'achèvement, etc.

Documents commerciaux

Les documents commerciaux sont composés d'objets d'informations métier ou de petits morceaux d'informations qui ont été précédemment identifiés.

Ces blocs, ou composants, ne portent bien sûr aucune information. Ce ne sont que des structures, comme un schéma XML ou une DTD, qui définissent les informations et la présentation. Le résultat final est une structure prévisible dans laquelle l'information est placée, de sorte que le destinataire du document final puisse l'interpréter pour extraire l'information.

Exemple de spécification de processus métier

Un exemple partiel de spécification de processus métier est donné ci-dessous:

<BusinessTransaction name="Create Order">
    <RequestingBusinessActivity name=""
        isNonRepudiationRequired="true"
        timeToAcknowledgeReceipt="P2D"
        timeToAcknowledgeAcceptance="P3D">
    <DocumentEnvelope BusinessDocument="Purchase Order"/ >
    </RequestingBusinessActivity>
    <RespondingBusinessActivity name=""
        isNonRepudiationRequired="true"
        timeToAcknowledgeReceipt="P5D">
    <DocumentEnvelope isPositiveResponse="true"
        BusinessDocument="PO Acknowledgement"/>
    </DocumentEnvelope>
    </RespondingBusinessActivity>
</BusinessTransaction>

Conclusion

Une spécification de processus métier:

  • Décrit la collaboration entre deux partenaires
  • Définit les rôles, les relations et les responsabilités
  • Définit la chorégraphie des documents commerciaux
  • Exprimé dans un format neutre de plate-forme et de fournisseur
  • Peut être modélisé avec UMM (méthodologie de modélisation UN / CEFACT)
  • Décrit formellement par Business Process Specification Schema (BPSS)
  • Référencé par CPP et CPA.
  • Fait référence aux définitions de documents commerciaux.

Profil de protocole de collaboration

Un profil de protocole de collaboration (CPP) fournit toutes les informations nécessaires sur la manière dont un partenaire commercial particulier entend faire des affaires électroniques. Un CPP définit les attributs suivants d'un partenaire commercial:

  • Capacités commerciales grâce aux processus commerciaux.

  • Le rôle (acheteur ou assureur) qu'ils jouent au sein d'une collaboration.

  • Canaux de livraison et protocoles de transport. (HTTP, SMTP, etc.)

  • Façon de conditionnement des documents commerciaux.

  • Contraintes de sécurité (SSL, certificats numériques).

  • Configuration par partie selon les spécifications des processus métier.

Un CPP est stocké dans le registre ebXML avec un identifiant global unique (GUID) et les partenaires commerciaux peuvent trouver le CPP de l'autre via le registre.

Les informations contenues dans le RPC peuvent être recherchées, de sorte qu'un partenaire commercial potentiel peut déterminer si l'organisation a les capacités de faire des affaires.

Structure d'un RPC

CPP définit les espaces de noms sur son élément racine et une version pour distinguer les modifications ultérieures. La structure d'un CPP se compose d'un élément de profil de protocole de collaboration racine avec les éléments suivants:

  • PartyInfo: L'élément PartyInfo fournit des informations sur l'organisation.

  • Packaging:L'élément Packaging fournit des informations sur la manière dont les messages sont réellement construits. Les messages sont traités comme des messages SOAP.

  • Signature: Partie facultative du document

  • Comment elements: peut être inclus.

<CollaborationProtocolProfile
xmlns="http://www.ebxml.org/namespaces/tradePartner"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="1.1">
<PartyInfo>
    ...
    <!--REQUIRED, Repeatable-->
...
</PartyInfo>
<Packaging id="ID">
    ...
    <!--REQUIRED-->
    ...
<Packaging>
<ds:Signature>
    ...
    <!--OPTIONAL-->
    ...
</ds:Signature>
<Comment>
    ...
    <!-- OPTIONAL -->
    ...
</Comment>
</CollaborationProtocolProfile>

Accord de partenariat commercial

Un accord de partenaire commercial (TPA) est un contrat définissant à la fois les conditions légales et les spécifications techniques pour les deux partenaires de la relation commerciale. Un CPA est dérivé des CPP des partenaires commerciaux.

Les règles spécifiées par le TPA électronique sont indépendantes des processus métier de l'une ou l'autre des parties. Une description technique des termes et conditions du TPA est exprimée dans un document XML, qui configure chaque système informatique pour fonctionner selon les règles de l'accord.

Les propriétés TPA incluent son nom, les noms des partenaires, les dates de début et de fin, les rôles et d'autres paramètres. En règle générale, une partie génère un CPA et le propose à l'autre partie pour approbation. Une fois que les deux parties sont parvenues à un accord, elles prennent chacune une copie électronique du même CPA et l'utilisent pour configurer leurs systèmes.

Le CPA peut également être ajouté au registre pour référence, mais ce n'est pas une exigence standard.

Structure d'un CPA

CPA définit les espaces de noms sur son élément racine et une version pour distinguer les modifications ultérieures. La structure d'un RPC se compose d'un élément racine du protocole de collaboration et des éléments suivants:

  • Start and End: Ces éléments représentent, en temps universel coordonné, le début et la fin de la période pendant laquelle ce CPA est actif.

  • PartyInfo:L'élément PartyInfo fournit des informations sur l'organisation. Ici, les éléments PartyInfo sont inclus pour les deux parties impliquées dans l'accord.

  • Packaging:L'élément Packaging fournit des informations sur la manière dont les messages sont réellement construits. Les messages sont traités comme des messages SOAP.

  • Signature: Partie facultative du document.

  • Comment elements: peut être inclus.

<CollaborationProtocolAgreement
xmlns="http://www.ebxml.org/namespaces/tradePartner"
xmlns:ds = "http://www.w3.org/2000/09/xmldsig#"
xmlns:xlink = "http://www.w3.org/1999/xlink"
cpaid="http://www.example.com/cpas/CPAS"
version="1.7">
<Status value = "proposed"/>
<Start>1998-04-07T18:50:00</Start>
<End>1999-04-07T18:50:00</End>
<ConversationConstraints invocationLimit = "150"
concurrentConversations = "10"/>
<PartyInfo>
    ...
    <!--REQUIRED, repeatable-->
    ...
</PartyInfo>
<PartyInfo>
    ...
    <!--REQUIRED, repeatable-->
    ...
    </PartyInfo>
<Packaging id="N20">
    ...
    <!--REQUIRED, repeatable-->
    ...
</Packaging>
<ds:Signature>
    <!--OPTIONAL-->
</ds:Signature>
<Comment xml:lang="en-gb">
    <!--OPTIONAL-->
</Comment>
</CollaborationProtocolAgreement>

Qu'est-ce que le registre et le référentiel:

Un registre ebXML sert d'index et de passerelle d'application pour un référentiel vers le monde extérieur, et il contient l'API qui régit la manière dont les parties interagissent avec le référentiel. Un référentiel ebXML est le détenteur des composants.

  • Le registre ebXML est au cœur de l'architecture ebXML.

  • Le registre peut également être considéré comme une API de la base de données d'articles prenant en charge l'e-business avec ebXML.

  • Le registre ebXML sert de base de données pour partager des informations d'entreprise pertinentes pour les transactions commerciales ebXML, telles que les capacités de l'entreprise, les processus commerciaux, les plans techniques, les bons de commande, les factures, etc.

  • Les éléments du référentiel sont créés, mis à jour ou supprimés via des demandes adressées au registre.

  • Les référentiels fournissent aux partenaires commerciaux la sémantique commerciale partagée.

  • Le registre ebXML est une interface pour accéder et découvrir la sémantique commerciale partagée.

  • L'interface de registre est conçue pour être indépendante de la pile de protocoles réseau sous-jacente, telle que HTTP ou SMTP sur TCP / IP.

Le registre fournit un stockage stable et persistant du contenu soumis, qui comprend des schémas et des documents XML, des descriptions de processus, des composants de base, des descriptions de contexte, des modèles UML, des informations sur les parties et même des composants logiciels. Cela peut être représenté comme une pile logicielle de services, comme indiqué ci-dessous:

Objectifs du registre ebXML

L'objectif du registre ebXML est de permettre le partage d'informations entre les parties intéressées à des fins d'intégration des processus métier entre elles.

Avantages du registre ebXML

Un registre ebXML offre les avantages suivants:

  • Découverte et maintenance du contenu enregistré.

  • Prise en charge du développement collaboratif, où les utilisateurs peuvent créer du contenu XML et le soumettre au registre pour utilisation et amélioration potentielle par les parties autorisées.

  • Persistance du langage WS-BPEL (Web Services Business Process Execution Language), du WSDL et des documents commerciaux lors des interactions entre partenaires commerciaux.

  • Contrôle de version sécurisé du contenu enregistré.

  • Fédération des registres coopérants pour fournir une vue unique du contenu enregistré grâce à l'interrogation, la synchronisation et le déplacement transparents du contenu enregistré.

  • Notification d'événements par e-mail ou services Web.

Conformité

Selon la spécification des services de registre ebXML, une implémentation de registre est conforme à la spécification ebXML si elle remplit les conditions suivantes:

  • Il prend en charge le modèle d'informations de registre ebXML.

  • Il prend en charge la syntaxe et la sémantique des interfaces de registre et de la sécurité.

  • Il prend en charge la DTD de registre ebXML.

  • La prise en charge de la syntaxe et de la sémantique de la requête SQL dans le registre est facultative.

Une implémentation de client de registre est conforme à la spécification ebXML si elle remplit les conditions suivantes:

  • Il prend en charge le CPA ebXML et le processus d'amorçage.

  • La syntaxe et la sémantique des interfaces client de registre.

  • Le message d'erreur ebXML DTD.

  • La DTD du registre ebXML.

Objets de registre et métadonnées

Objets de registre

Fait référence à un objet qui est soumis au registre pour stockage et conservation

  • appelé 'élément du référentiel'

  • Document XML ou DTD, modèles de processus métier, CPP, etc.

Metadata

  • Il est utilisé par le registre pour classer et gérer les objets du registre.

  • Il est représenté par une entrée de registre

Modèle d'information de registre (RIM)

Le modèle d'informations de registre (RIM) fournit un plan directeur de haut niveau pour les métadonnées dans le registre ebXML. Cela peut être représenté comme une pile logicielle de services ou comme une pyramide de services, comme illustré dans la figure ci-dessous. Les éléments du modèle d'information représentent des métadonnées sur le contenu, pas le contenu lui-même dans le référentiel. Le modèle d'information du registre définit les types d'objets stockés et organisés dans le registre.

Le modèle d'information est une feuille de route pour le type de métadonnées et les relations entre métadonnées. Le modèle d'informations de registre peut être mappé à un schéma de base de données relationnelle, un schéma de base de données d'objets ou un autre schéma physique.

"Un composant de base capture des informations sur un concept commercial réel et les relations entre ce concept et d'autres concepts commerciaux. Un composant de base peut être soit une information commerciale individuelle, soit une famille d'informations commerciales. Il est essentiel car il se produit. dans de nombreux domaines d’échange d’informations entre l’industrie et l’entreprise "

... Formulaire de définition xbXML simplifié par Eric Chiu

Un composant de base est un bloc de construction de base réutilisable qui contient des informations représentant un concept d'entreprise. Quelques exemples de composants de base pour des parties d'un bon de commande sont la date du bon de commande, la taxe de vente et le montant total.

En général, les composants de base sont utilisés dans de nombreux domaines, industries et processus métier différents. Dans l'environnement ebXML, les composants de base sont les éléments constitutifs de la sémantique XML et du vocabulaire métier utilisés dans les messages et les documents.

À partir d'un document commercial spécifique dans un processus métier, nous pouvons faire référence à un composant de base, qui contient un ensemble minimal d'informations sur le commerce électronique. Si les processus métier sont les verbes en termes de commerce électronique, les composants de base représentent les noms et les adjectifs.

Un composant de base peut être utilisé dans plusieurs secteurs d'activité, mais il peut également devenir spécifique au contexte d'un domaine d'activité, tel qu'un secteur d'activité individuel.

Un composant de base fonctionne avec un registre, car il est stockable et récupérable à l'aide d'un registre ebXML standard. Une bibliothèque de composants de base centrale sert de document de référence pour les pratiques commerciales courantes dans les processus commerciaux de l'industrie.

Outils et références

La liste des références et des outils essentiels pour les composants de base fournis par ebXML pour l'analyste commercial et technique est la suivante:

  • Context and the Re-usability of Core Components: Ce document contient des définitions de contexte, les sources des listes de valeurs de classification et un modèle graphique illustrant les relations entre le composant principal et le descripteur de contexte.

  • Catalog of Context Drivers: Ce document fournit un catalogue de pilotes de contexte.

  • Document Assembly and Context Rules: Ceci décrit les procédures et les schémas d'assemblage de documents à l'aide de composants de base pilotés par le contexte.

  • Core Components Dictionary:Ce document est divisé en sections. Chaque section commence par les informations sur la catégorie applicable et le type de composant principal.

  • Core Components Editor and Browser: Ces outils aident les analystes à parcourir les composants de base existants et à les intégrer pour définir le format des messages XML échangés entre les partenaires commerciaux et pour définir et appliquer correctement les règles de contexte.

Exemples de composants de base:

  • Composant principal A:

    • Fournisseur (Industry1)
    • Fabricant (industrie 2)
    • Fournisseur (industrie 3)
  • Composant principal B:

    • Distributeur (Industrie 1)
    • Grossiste (industrie 2)
    • Marchand (industrie 3)
  • Composant principal C:

    • Magasin (Industrie 1)
    • Outlet (Industrie 2)
    • Détaillant (industrie 3)

Conclusion

Les composants de base sont -

  • Identifiable de manière unique.
  • Structures de données de bas niveau réutilisables
    • -eg, fête, adresse, téléphone, date, devise
    • -Context-sensitive
  • Utilisé pour définir les processus métier et les modèles d'information.
  • Facilite l'interopérabilité entre des systèmes disparates.
  • Un composant principal dans ebXML peut contenir un autre composant principal.

Un message complet est appelé le package de messages, qui est un objet MIME (Multipurpose Internet Mail Extensions). Le paquet de messages contient deux parties principales:

  • SOAP Message Container: Il s'agit d'une partie obligatoire du message et contient les éléments d'extension SOAP pour ebXML, tels que les informations de routage, les informations de partenaire commercial, l'identification du message et les informations de sémantique de livraison.

  • Payload Containers: Il s'agit d'une partie facultative du message et peut contenir tout type d'informations à échanger entre les parties.

Critères de conception de la messagerie

Selon la spécification du service de messagerie, les objectifs de conception du service de messagerie ebXML sont les suivants:

  • Tirez parti des normes existantes dans la mesure du possible.

  • Soyez simple à mettre en œuvre.

  • Soutenez les entreprises de toutes tailles.

  • Prend en charge une grande variété de protocoles de communication (HTTP, SMTP, FTP, etc.)

  • Prise en charge des charges utiles de tout type (XML, transactions EDI, données binaires, etc.)

  • Soutenez une messagerie fiable.

  • Assurer la sécurité.

Architecture de messagerie

Le service de messagerie ebXML a été conçu pour fonctionner dans le contexte général de l'initiative ebXML. Cependant, l'architecture technique ebXML est modulaire et le service de messagerie peut être utilisé indépendamment d'ebXML.

Le service de messagerie ebXML comporte trois niveaux architecturaux logiques entre l'application métier et les protocoles réseau:

  • The Message Service Interface (MSI):Il s'agit d'une interface d'application permettant aux applications d'entreprise d'appeler la fonctionnalité de gestionnaire de messages pour l'envoi et la réception de messages. Semblable à ODBC, JDBC et à d'autres interfaces de service abstrait, il expose la fonctionnalité de gestionnaire de messages en tant qu'ensemble défini d'API pour les développeurs d'applications métier.

  • The Message Service Handler (MSH): Il propose des services de base, tels que le traitement des en-têtes, l'analyse des en-têtes, des services de sécurité, des services de messagerie fiables, le conditionnement des messages et la gestion des erreurs.

  • The Message Transport Interface (MTI):Il est conçu pour envoyer des messages sur divers réseaux et protocoles de communication au niveau des applications. L'interface de transport transforme les données spécifiques ebXML en d'autres formes portées par les services et protocoles réseau. Cela implique un échange complet entre deux parties, en s'ajoutant aux protocoles existants dans la pile réseau.

L'architecture de messagerie ebXML est illustrée dans le diagramme suivant.

Formatage des messages:

Un message ebXML doit être formaté conformément à la spécification du service de messagerie ebXML et doit être conforme à la syntaxe, au format et aux règles de codage MIME. La définition des éléments XML est fournie par un schéma XML, qui étend SOAP pour définir l'en-tête du message ebXML, l'en-tête de trace, le manifeste, l'état et l'accusé de réception.

Conclusion

Un message ebXML doit être formaté conformément à la spécification du service de messagerie ebXML et doit être conforme à la syntaxe, au format et aux règles de codage MIME. La définition des éléments XML est fournie par un schéma XML, qui étend SOAP pour définir l'en-tête de message ebXML, l'en-tête de trace, le manifeste, l'état et l'accusé de réception.

La messagerie ebXML -

  • Utilise SOAP avec pièces jointes comme enveloppe de charge utile.

  • Fonctionne sur divers protocoles de communication tels que HTTP, SMTP, FTP.

  • Prend en charge la sémantique de niveau supérieur nécessaire dans les transactions commerciales. (Sécurité et fiabilité)

Le diagramme suivant montre un scénario ebXML, ce qui facilite la compréhension du concept d'ebXML. L'exemple est tiré de la spécification d'architecture technique.

L'exemple montre comment les organisations se préparent à ebXML, recherchent de nouveaux partenaires commerciaux, puis s'engagent dans le commerce électronique.

  • La société A parcourt le registre ebXML pour voir ce qui est disponible en ligne. Au mieux, l'entreprise A peut réutiliser tous les processus métier, documents et composants de base existants, communs à son secteur, qui sont déjà stockés dans le registre ebXML. Sinon, l'entreprise A conçoit les pièces manquantes, les stocke dans le registre ebXML et les met à la disposition de ses partenaires industriels.

  • La société A décide de faire du commerce électronique selon la méthode ebXML et envisage de mettre en œuvre une application locale conforme à ebXML. Une interface de service métier ebXML (BSI) assure le lien entre l'entreprise et le monde ebXML extérieur. L'entreprise doit créer un profil de protocole de collaboration (CPP) qui décrit les capacités des processus métier pris en charge, les contraintes et les informations techniques ebXML telles que le choix des algorithmes de cryptage, les certificats de cryptage et le choix des protocoles de transport.

  • La société A soumet son CPP au registre ebXML. À partir de ce moment, la société A est cotée publiquement dans le registre ebXML et est susceptible d'être découverte par d'autres sociétés qui recherchent de nouveaux partenaires commerciaux.

  • La société B est déjà inscrite au registre ebXML et recherche de nouveaux partenaires commerciaux. L'entreprise B interroge le registre ebXML et reçoit le CPP de l'entreprise A. L'entreprise B dispose alors de deux CPP: le CPP de l'entreprise A et le sien. Les deux sociétés doivent parvenir à un accord sur la manière de faire des affaires, ce que l'on appelle un accord de protocole de collaboration (CPA) dans la terminologie ebXML. La société B utilise un outil de formation ebXML CPA pour dériver un CPA à partir des exigences des deux CPP

  • Dans ce scénario, la société B communique directement avec la société A et envoie le CPA nouvellement créé pour acceptation à la société A. Après accord du CPA par la société A, les deux sociétés sont prêtes pour le commerce électronique.

  • Les entreprises utilisent ensuite le framework ebXML sous-jacent et échangent des documents commerciaux conformes au CPA. Cela signifie que les deux sociétés suivent les processus métier définis dans le CPA.