ebXML - Guia rápido
As empresas inevitavelmente interagem umas com as outras de várias maneiras. Até recentemente, muitas grandes empresas costumavam se comunicar automaticamente por meio de Electronic Data Interchange (EDI), que permite que duas empresas se comuniquem usando sinais pré-determinados.
O problema com o EDI é que ele é muito caro e foi originalmente criado para o mundo do mainframe. Agora o ebXML está substituindo o EDI.
Definição
ebXML significa Eletrônico Butilidade Extensível Markup Llinguagem. É um padrão global para negócios eletrônicos que permite a qualquer pessoa, em qualquer lugar, fazer transações comerciais com qualquer pessoa pela Internet.
Características
Os recursos do ebXML são os seguintes:
- ebXML é uma estrutura XML de B2B de ponta a ponta.
- ebXML é um conjunto de especificações que permitem uma estrutura modular.
- ebXML depende dos padrões existentes da Internet, como HTTP, TCP / IP, MIME, SMTP, FTP, UML e XML.
- ebXML pode ser implementado e implementado em praticamente qualquer plataforma de computação.
- ebXML fornece especificações concretas para permitir colaborações B2B dinâmicas.
Visão ebXML
ebXML é projetado para criar um mercado eletrônico global onde empresas de qualquer tamanho, em qualquer lugar podem:
- encontrar um ao outro eletronicamente.
- conduzir negócio -
- usando troca de mensagens XML.
- de acordo com as sequências de processos de negócios padrão.
- com uma semântica de negócios clara.
- usando aplicativos comerciais adquiridos de prateleira.
- de acordo com acordos de protocolo de parceiros comerciais mutuamente acordados.
Por que ebXML?
- As estruturas B2B existentes não são adequadas:
- EDI e RosettaNet são muito pesados e muito rígidos.
- O BizTalk é proprietário, fornecedor único e plataforma única.
- Protocolo de Acesso a Objetos Simples (SOAP); Linguagem de definição de serviço da Web (WSDL); e Descrição Universal, Descoberta e Integração (UDDI) por si só não são adequados:
- WSDL não aborda a colaboração de negócios.
- SOAP em sua forma básica não fornece entrega de mensagens segura e confiável.
- UDDI não fornece capacidade de repositório para objetos de negócios.
- Há uma necessidade crescente de padronizar as colaborações de negócios para abordar o seguinte:
- Processos de negócios
- As partes envolvidas na colaboração empresarial e suas funções
- Troca de documentos XML nas colaborações de negócios
- Requisitos de segurança, confiabilidade e qualidade de serviço de colaboração empresarial
Todas essas necessidades são atendidas por ebXML.
Organizações fundadoras ebXML
ebXML é uma iniciativa conjunta do UN / CEFACT e OASIS.
UN/CEFACT:
- Significa Centro das Nações Unidas para Facilitação do Comércio e Negócios Eletrônicos.
- Ele mantém os padrões UN / EDIFACT para Electronic Data Interchange (EDI).
OASIS:
- Significa Organização para o Avanço de Padrões de Informação Estruturada.
- Ele cria e mantém especificações de interoperabilidade XML, amplo suporte da indústria.
Por definição, o ciclo de vida iterativo de B2B collaboration inclui as seguintes etapas:
- Definição de Processo
- Partner Discovery
- Inscrição de parceiro
- Plug-in Eletrônico
- Execução do Processo
- Gerenciamento de processos
- Evolução do Processo
As especificações ebXML gerais destinam-se a cobrir quase todo o processo de colaboração B2B e são projetadas para atender às necessidades descritas acima.
A arquitetura ebXML, conforme definida pela equipe ebXML, fornece:
- Uma maneira de definir processos de negócios e suas mensagens e conteúdo associados.
- Uma maneira de registrar e descobrir sequências de processos de negócios com trocas de mensagens relacionadas.
- Uma forma de definir perfis de empresas.
- Uma forma de definir acordos de parceiros comerciais.
- Uma camada uniforme de transporte de mensagens.
Consequentemente, a arquitetura técnica do ebXML é composta por cinco módulos:
- Especificações do processo de negócios
- Perfil de parceiro e acordos
- Registro e Repositório
- Componentes do núcleo
- Serviço de Mensagens
Esses módulos serão abordados nos próximos cinco capítulos subsequentes. O diagrama do diagrama mostra a arquitetura simplificada de ebXML:
Um Processo de Negócios é algo que uma empresa faz, como comprar peças de computador ou vender um serviço profissional. Envolve a troca de informações entre dois ou mais parceiros comerciais de alguma forma previsível.
As especificações para a definição do processo de negócios permitem que uma organização expresse seus processos de negócios de forma que sejam compreensíveis por outras organizações. Permite a integração de processos de negócios dentro de uma empresa ou entre várias empresas.
o ebXML Business Process Specification Schema (BPSS)fornece a definição de um documento XML que descreve como uma organização conduz seus negócios. Um ebXML BPSS é uma declaração dos parceiros, funções, colaborações, coreografia e trocas de documentos de negócios que constituem um processo de negócios.
O diagrama a seguir fornece uma visão conceitual do Processo de Negócios.
Colaborações de negócios
Uma Colaboração de Negócios é um conjunto coreografado de atividades de transações de negócios, nas quais dois parceiros comerciais trocam documentos.
A mais comum é a Colaboração Binária, na qual dois parceiros trocam documentos. Uma Colaboração Multipartidário ocorre quando as informações são trocadas entre mais de duas partes.
As colaborações multipartidárias são, na verdade, colaborações binárias coreografadas.
Em seu nível mais baixo, uma colaboração de negócios pode ser dividida em transações de negócios.
Transações Comerciais
Uma transação comercial é o nível atômico de trabalho em um processo comercial. Ele é bem-sucedido ou falha completamente.
As transações comerciais são transações nas quais os parceiros comerciais realmente transferem documentos comerciais.
Fluxos de documentos comerciais:
Uma transação comercial é realizada à medida que um documento comercial flui entre as funções solicitantes e respondentes. Sempre há um documento comercial solicitante e, opcionalmente, um documento comercial respondendo, dependendo da semântica da transação desejada, por exemplo, notificação unilateral versus conversação bidirecional.
A definição real do documento é obtida usando as especificações do componente principal ebXML ou por alguma metodologia externa a ebXML, mas resultando em um DTD ou Esquema para o qual uma especificação de processo de negócios ebXML pode apontar.
Coreografia:
A coreografia é expressa em termos de estados e as transições entre eles. Uma atividade de negócios é conhecida como estado abstrato, com colaborações de negócios e atividades de transação de negócios conhecidas como estados concretos. A coreografia é descrita no esquema de especificação do processo de negócios ebXML usando conceitos de diagrama de atividades, como estado inicial, estado de conclusão, etc.
Documentos Comerciais
Os documentos de negócios são compostos de objetos de informações de negócios ou pedaços menores de informações que foram identificados anteriormente.
Esses pedaços, ou componentes, não carregam nenhuma informação, é claro. Eles são meramente estruturas, como um esquema XML ou um DTD, que definem informações e apresentação. O resultado final é uma estrutura previsível na qual as informações são colocadas, de forma que o receptor do documento final possa interpretá-lo para extrair as informações.
Exemplo de especificação de processo de negócios
Um exemplo parcial de especificação de processo de negócios é fornecido abaixo:
<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>
Conclusão
Uma especificação de processo de negócios:
- Descreve a colaboração entre dois parceiros
- Define funções, relacionamentos e responsabilidades
- Define coreografia de documentos de negócios
- Expresso em formato neutro de plataforma e fornecedor
- Pode ser modelado com UMM (UN / CEFACT Modeling Methodology)
- Descrito formalmente por Business Process Specification Schema (BPSS)
- Referenciado por CPP e CPA.
- Refere-se às definições de documentos comerciais.
Perfil de protocolo de colaboração
Um Perfil de Protocolo de Colaboração (CPP) fornece todas as informações necessárias sobre como um determinado parceiro comercial pretende fazer negócios eletrônicos. Um CPP define os seguintes atributos de um parceiro comercial:
Capacidades de negócios por meio de processos de negócios.
A função (comprador ou seguradora) que desempenham em uma colaboração.
Canais de entrega e protocolos de transporte. (HTTP, SMTP, etc.)
Forma de embalagem de documentos comerciais.
Restrições de segurança (SSL, Certificados Digitais).
Configuração por parte para especificações do processo de negócios.
Um CPP é armazenado no registro ebXML com um Globally Unique Identifier (GUID) e os parceiros de negócios podem encontrar o CPP uns dos outros por meio do registro.
As informações no CPP estão disponíveis para serem pesquisadas, portanto, um potencial parceiro comercial pode determinar se a organização tem capacidade para fazer negócios.
Estrutura de um CPP
CPP define namespaces em seu elemento raiz e uma versão para distinguir quaisquer alterações subsequentes. A estrutura de um CPP consiste em um elemento raiz do Perfil de Protocolo de Colaboração com os seguintes elementos:
PartyInfo: O elemento PartyInfo fornece informações sobre a organização.
Packaging:O elemento Packaging fornece informações sobre a maneira como as mensagens são realmente construídas. As mensagens são processadas como mensagens SOAP.
Signature: Parte opcional do documento
Comment elements: pode ser incluído.
<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>
Acordo de Parceiro Comercial
Um Acordo de Parceiro Comercial (TPA) é um contrato que define os termos e condições legais e as especificações técnicas para ambos os parceiros na relação comercial. Um CPA é derivado de CPPs de parceiros comerciais.
As regras especificadas pelo TPA eletrônico são independentes dos processos de negócios em qualquer uma das partes. A descrição técnica dos termos e condições do TPA está expressa em documento XML, que configura cada sistema de TI para operar de acordo com as regras do contrato.
As propriedades TPA incluem seu nome, nomes de parceiros, datas de início e término, funções e outros parâmetros. Normalmente, uma parte gera um CPA e o oferece à outra parte para aprovação. Uma vez que ambos os lados tenham chegado a um acordo, cada um pega uma cópia eletrônica do mesmo CPA e a usa para configurar seus sistemas.
O CPA também pode ser adicionado ao registro para referência, mas este não é um requisito padrão.
Estrutura de um CPA
CPA define namespaces em seu elemento raiz e uma versão para distinguir quaisquer alterações subsequentes. A estrutura de um CPP consiste em um elemento raiz do Acordo de Protocolo de Colaboração junto com os seguintes elementos:
Start and End: Esses elementos representam, em tempo universal coordenado, o início e o fim do período de vigência deste CPA.
PartyInfo:O elemento PartyInfo fornece informações sobre a organização. Aqui, os elementos PartyInfo são incluídos para ambas as partes envolvidas no contrato.
Packaging:O elemento Packaging fornece informações sobre a maneira como as mensagens são realmente construídas. As mensagens são processadas como mensagens SOAP.
Signature: Parte opcional do documento.
Comment elements: pode ser incluído.
<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>
O que é registro e repositório:
Um registro ebXML serve como índice e gateway de aplicativo para um repositório para o mundo externo e contém a API que controla como as partes interagem com o repositório. Um repositório ebXML é o detentor dos componentes.
O registro ebXML é central para a arquitetura ebXML.
O registro também pode ser visto como uma API para o banco de dados de itens que suporta e-business com ebXML.
O registro ebXML serve como um banco de dados para compartilhar informações relevantes da empresa para transações de negócios ebXML, como recursos corporativos, processos de negócios, projetos técnicos, formulários de pedidos, faturas e assim por diante.
Os itens do repositório são criados, atualizados ou excluídos por meio de solicitações feitas ao registro.
Os repositórios fornecem aos parceiros comerciais a semântica de negócios compartilhada.
O registro ebXML é uma interface para acessar e descobrir semântica de negócios compartilhada.
A interface do registro foi projetada para ser independente da pilha de protocolos de rede subjacente, como HTTP ou SMTP sobre TCP / IP.
O registro fornece um armazenamento estável e persistente de conteúdo enviado, que inclui esquemas e documentos XML, descrições de processos, componentes principais, descrições de contexto, modelos UML, informações sobre partes e até mesmo componentes de software. Isso pode ser representado como uma pilha de serviços de software, conforme mostrado abaixo:
Objetivos do Registro ebXML
O objetivo do registro ebXML é permitir o compartilhamento de informações entre as partes interessadas com o propósito de integração dos processos de negócios entre elas.
Benefícios do registro ebXML
Um registro ebXML oferece os seguintes benefícios:
Descoberta e manutenção de conteúdo cadastrado.
Suporte para desenvolvimento colaborativo, onde os usuários podem criar conteúdo XML e enviá-lo ao registro para uso e potencial aprimoramento pelas partes autorizadas.
Persistência de Linguagem de Execução de Processos de Negócios de Serviços da Web (WS-BPEL), WSDL e documentos de negócios durante interações entre parceiros comerciais.
Controle seguro de versão de conteúdo registrado.
Federação de registros cooperativos para fornecer uma visão única do conteúdo registrado por meio de consultas, sincronização e realocação contínuas do conteúdo registrado.
Notificação de eventos por e-mail ou serviços da web.
Conformidade
De acordo com a Especificação ebXML Registry Services, uma implementação de registro está em conformidade com a especificação ebXML se atender às seguintes condições:
Ele suporta o modelo de informações de registro ebXML.
Ele suporta a sintaxe e a semântica das interfaces de registro e segurança.
Ele suporta o DTD de registro ebXML.
O suporte da sintaxe e da semântica da consulta SQL no registro é opcional.
Uma implementação de cliente de registro está em conformidade com a especificação ebXML se atender às seguintes condições:
Ele suporta o ebXML CPA e processo de bootstrapping.
A sintaxe e a semântica das interfaces do cliente de registro.
O DTD da mensagem de erro ebXML.
O DTD de registro ebXML.
Objetos e metadados de registro
Objetos de registro
Refere-se a um objeto que é submetido a registro para armazenamento e guarda
chamado 'item de repositório'
Documento XML ou DTD, modelos de processos de negócios, CPPs, etc.
Metadata
É usado pelo registro para classificar e gerenciar objetos do registro.
É representado por uma entrada de registro
Modelo de informações de registro (RIM)
O Registry Information Model (RIM) fornece um blueprint de alto nível para metadados no registro ebXML. Isso pode ser representado como uma pilha de serviços de software ou como uma pirâmide de serviços, conforme mostrado na figura abaixo. Os elementos do modelo de informação representam metadados sobre o conteúdo, não o próprio conteúdo no repositório. O modelo de informações do registro define os tipos de objetos armazenados e organizados no registro.
O modelo de informação é um roteiro para o tipo de metadados e as relações entre os metadados. O modelo de informações de registro pode ser mapeado para um esquema de banco de dados relacional, esquema de banco de dados de objetos ou algum outro esquema físico.
"Um componente principal captura informações sobre um conceito de negócios do mundo real e as relações entre esse conceito e outros conceitos de negócios. Um componente principal pode ser uma parte individual de informações de negócios ou uma família de partes de informações de negócios. É essencial porque ocorre em muitas áreas diferentes da indústria / troca de informações comerciais "
... Formulário de definição xbXML simplificado por Eric Chiu
Um componente principal é um bloco de construção básico reutilizável que contém informações que representam um conceito de negócio. Alguns exemplos de componentes principais para partes de um pedido de compra são Data do Pedido de Compra, Imposto sobre Vendas e Valor Total.
Em geral, os componentes principais são usados em muitos domínios, setores e processos de negócios diferentes. No ambiente ebXML, os componentes principais são os blocos de construção para a semântica XML e vocabulário de negócios que são usados em mensagens e documentos.
A partir de um documento de negócios específico em um processo de negócios, podemos nos referir a um componente central, que contém um conjunto mínimo de informações de e-business. Se os processos de negócios são os verbos em termos de e-business, os componentes principais representam os substantivos e adjetivos.
Um componente principal pode ser usado em vários setores de negócios, mas também pode se tornar específico do contexto para um domínio de negócios, como uma área individual da indústria.
Um componente principal funciona com um registro, pois pode ser armazenado e recuperado usando um registro ebXML padrão. Uma biblioteca de componentes centrais serve como um documento de referência para práticas de negócios comuns nos processos de negócios do segmento de mercado.
Ferramentas e referências
A lista de referências e ferramentas essenciais para componentes principais fornecida por ebXML para o analista técnico e de negócios é a seguinte:
Context and the Re-usability of Core Components: Este documento contém definições de contexto, as fontes de listas de valores de classificação e um modelo pictórico que descreve as relações do componente principal e do descritor de contexto.
Catalog of Context Drivers: Este documento fornece um catálogo de drivers de contexto.
Document Assembly and Context Rules: Isso descreve os procedimentos e esquemas para a montagem de documentos usando componentes principais orientados por contexto.
Core Components Dictionary:Este documento está dividido em seções. Cada seção começa com as informações sobre a categoria aplicável e o tipo de componente principal.
Core Components Editor and Browser: Essas ferramentas ajudam os analistas a navegar nos componentes principais existentes e integrá-los para definir o formato das mensagens XML trocadas entre os parceiros comerciais e definir e aplicar adequadamente as regras de contexto.
Exemplos de componentes principais:
Componente central A:
- Fornecedor (Indústria1)
- Fabricante (Indústria 2)
- Fornecedor (Indústria 3)
Componente central B:
- Distribuidor (Indústria 1)
- Atacadista (Indústria 2)
- Comerciante (Indústria 3)
Componente central C:
- Loja (Indústria 1)
- Outlet (Indústria 2)
- Varejista (Indústria 3)
Conclusão
Os componentes principais são -
- Identificável exclusivamente.
- Estruturas de dados reutilizáveis de baixo nível
- - por exemplo, festa, endereço, telefone, data, moeda
- -Context-sensitive
- Usado para definir processos de negócios e modelos de informação.
- Facilita a interoperabilidade entre sistemas distintos.
- Um componente principal em ebXML pode conter outro componente principal.
Uma mensagem completa é chamada de pacote de mensagem, que é um objeto Multipurpose Internet Mail Extensions (MIME). O pacote de mensagens contém duas partes principais:
SOAP Message Container: Isso é parte necessária da mensagem e contém os elementos de extensão SOAP para ebXML, como informações de roteamento, informações do parceiro comercial, identificação de mensagem e informações semânticas de entrega.
Payload Containers: Esta é uma parte opcional da mensagem e pode conter qualquer tipo de informação a ser trocada entre as partes.
Critérios de design de mensagens
De acordo com a especificação do serviço de mensagens, os objetivos de design para o serviço de mensagens ebXML são:
Aproveite os padrões existentes sempre que possível.
Seja simples de implementar.
Apoie empresas de todos os tamanhos.
Suporta uma ampla variedade de protocolos de comunicação (HTTP, SMTP, FTP, etc.)
Suporta cargas úteis de qualquer tipo (XML, transações EDI, dados binários, etc.)
Suporte a mensagens confiáveis.
Garanta a segurança.
Arquitetura de Mensagens
O serviço de mensagens ebXML foi projetado para funcionar dentro do contexto geral da iniciativa ebXML. No entanto, a arquitetura técnica ebXML é modular e o serviço de mensagens pode ser usado independentemente do ebXML.
O serviço de mensagem ebXML tem três níveis lógicos de arquitetura entre o aplicativo de negócios e os protocolos de rede:
The Message Service Interface (MSI):É uma interface de aplicativo para aplicativos de negócios para invocar a funcionalidade do manipulador de mensagens para enviar e receber mensagens. Semelhante ao ODBC, JDBC e outras interfaces de serviço abstratas, ele expõe a funcionalidade do manipulador de mensagens como um conjunto definido de APIs para desenvolvedores de aplicativos de negócios.
The Message Service Handler (MSH): Possui serviços básicos, como processamento de cabeçalho, análise de cabeçalho, serviços de segurança, serviços de mensagens confiáveis, embalagem de mensagens e tratamento de erros.
The Message Transport Interface (MTI):Ele é projetado para enviar mensagens por várias redes e protocolos de comunicação de nível de aplicativo. A interface de transporte transforma dados específicos ebXML em outras formas transportadas por serviços e protocolos de rede. Isso envolve uma troca completa entre duas partes, pegando carona nos protocolos existentes na pilha da rede.
A arquitetura de mensagens ebXML é mostrada no diagrama a seguir.
Formatação da mensagem:
Uma mensagem ebXML deve ser formatada de acordo com a especificação do serviço de mensagem ebXML e deve estar em conformidade com a sintaxe MIME, formato e regras de codificação. A definição dos elementos XML é fornecida por um esquema XML, que estende o SOAP para definir o cabeçalho da mensagem ebXML, cabeçalho de rastreio, manifesto, status e confirmação.
Conclusão
Uma mensagem ebXML deve ser formatada de acordo com a Especificação de Serviço de Mensagem ebXML e deve estar em conformidade com a sintaxe MIME, formato e regras de codificação. A definição dos elementos XML é fornecida por um esquema XML, que estende o SOAP para definir o cabeçalho da mensagem ebXML, cabeçalho de rastreio, manifesto, status e confirmação.
A mensagem ebXML -
Usa SOAP com anexos como envelope de carga útil.
Funciona em vários protocolos de comunicação, como HTTP, SMTP, FTP.
Suporta semântica de alto nível necessária em transações comerciais. (Segurança e confiabilidade)
O diagrama a seguir mostra um cenário ebXML, o que facilita a compreensão do conceito de ebXML. O exemplo é retirado da Especificação de Arquitetura Técnica.
O exemplo mostra como as organizações se preparam para o ebXML, procuram novos parceiros comerciais e, em seguida, se envolvem em negócios eletrônicos.
A Empresa A navega no registro ebXML para ver o que está disponível online. Na melhor das hipóteses, a empresa A pode reutilizar todos os processos de negócios existentes, documentos e componentes principais comuns a seu segmento de mercado que já estão armazenados no registro ebXML. Caso contrário, a empresa A projeta as peças que faltam, armazena-as no registro ebXML e as disponibiliza para seus parceiros do setor.
A Empresa A decide fazer negócios eletrônicos da maneira ebXML e considera a implementação de um aplicativo compatível com ebXML local. Uma interface de serviço de negócios ebXML (BSI) fornece o link entre a empresa e o mundo ebXML externo. A empresa deve criar um Perfil de Protocolo de Colaboração (CPP) que descreve os recursos de processos de negócios suportados, restrições e informações técnicas de ebXML, como escolha de algoritmos de criptografia, certificados de criptografia e escolha de protocolos de transporte.
A Empresa A envia seu CPP para o registro ebXML. Desse ponto em diante, a empresa A é listada publicamente no registro ebXML e provavelmente será descoberta por outras empresas em busca de novos parceiros comerciais.
A empresa B já está registrada no registro ebXML e está procurando novos parceiros comerciais. A Empresa B consulta o registro ebXML e recebe o CPP da empresa A. A Empresa B então tem dois CPP: o CPP da Empresa A e o seu próprio. As duas empresas precisam chegar a um acordo sobre como fazer negócios, que na terminologia ebXML é chamado de Collaboration Protocol Agreement (CPA). A Empresa B usa uma ferramenta de formação de CPA ebXML para derivar um CPA dos requisitos dos dois CPPs
Nesse cenário, a empresa B se comunica com a empresa A diretamente e envia o CPA recém-criado para aceitação da empresa A. Com o acordo do CPA pela empresa A, ambas as empresas estão prontas para negócios eletrônicos.
As empresas então usam a estrutura ebXML subjacente e trocam documentos de negócios de acordo com o CPA. Isso significa que ambas as empresas seguem os processos de negócios definidos no CPA.