Uma plataforma desenvolvida em java e de muita importância para o cenário. Utilizamos para definir os serviços e mantê-los em funcionamento. O jenkins centraliza as tarefas e garante sua visualização mais limpa dos processos.
Normalmente quando instalamos o jenkins o configuramos para rodar na porta 8081, mas isso é configurável, assim no navegador de internet pelo endereço local http://localhost:8081/login? ou substituindo o nome localhost pelo IP local do servidor é possível carregar o serviço.
Ao carregar a página poderá fazer login no seu ambiente de trabalho. Normalmente utilizamos o usuário com o nome Lopes a senha S#39gpkz mas poderá nos consultar sempre que for necessário.
Quando logar poderá acessar cada serviço separadamente, para visualizar, por exemplo, seu processamento em tempo real. Mas o objetivo não é esse e sim para que você consiga perceber se existe algum serviço parado, ou com erro. Os serviços estão disponíveis de acordo com a necessidade, então você pode ter mais ou menos serviços executando ou até mesmo serviços diferentes.
Cada serviço pode ser acessado clicando no nome do serviço. Depois de estar dentro do serviço poderá entrar na execução de um serviço atual ou anterior, já que fica um histórico das execuções ou falando tecnicamente dos Builds. Clicando no build 112590 e depois na Saída do console, vamos poder ver o log (registro da operação).
Temos um serviço especial que utilizamos para criar os acessos que serão consumidos pelo servidor da infracommerce. Esses serviços são para recebermos Cliente (Customer), Pedido (Order) e Pagamento (Payment), na verdade confirmação do pagamento. Dentro do servidor é possível acessar a raiz desse serviço pelo endereço localhost + porta + serviço (http://localhost:8040/services ou http://localhost:8085/B2bServices) mas precisamos lembrar que o site é externo ao ambiente do seller e para fazer essa transação com segurança é obrigatório que o serviço seja publicado com um Certificado SSL. De acordo com o container, onde roda os serviços vai modificar a forma como se aplica o SSL e esse passo chamamos de Certificação, pois é necessário ter o certificado, mas normalmente não se aplica diretamente, costuma precisar de uma transformação para se adequar ao processo do container. É preciso ter muita atenção com isso porque caso seu certificado vença, os servidores em produção da infracommerce vão rejeitar sua comunicação, fazendo com que o Seller não receba em sua integradora nenhum cliente, pedido ou pagamento.
Utilizando um SSL se muda a forma de acessar o serviço, com o SSL ativo não chamamos mais http e sim https e também não chamamos mais o endereço local, e sim o domínio contido dentro do SSL. Por exemplo: nosso domínio é lopesecia.com.br para usar no SSL especificamente na integradora, criamos um subdomínio chamado de integração, assim nosso endereço ficou integracao.lopesecia.com.br e para chamar o endpoint (ponto de acesso) vamos chamar o dominio + porta + serviço escrevendo https://integracao.lopesecia.com.br:9001/services . Note que também alteramos a porta, porque normalmente configuramos uma porta para acesso local e outra porta para acesso externo, já que o acesso externo depende mais segurança e configurações.
Até aqui foi apresentado como acessar o serviço, mas não como se comunicar com ele, porque para se comunicar com ele é necessário que a integradora esteja configurada e funcionando. Para funcionar, a Integradora precisa do banco de dados Oracle, utilizamos a versão XE já que é apenas um banco de passagem, seu objetivo não é armazenar todas as informações mas sim, receber os dados, tratá-los e depois entregar ao destinatário. Pensando nisso, cada integradora precisará ter uma identificação própria, logo, no mesmo servidor poderemos ter mais de uma integração configurada e funcionando. Identificamos a integração pelo seu código interno e o código interno da filial parametrizada. Logo definimos que uma integração é construída para uma filial e uma filial pode ter mais de uma integração. Exemplo temos a integração Unilever Compra Foods Services rodando na integradora 1 e a integração Unilever Compra Agora rodando na integradora 2 assim seu endpoints ficaram:
Exemplo de endpoint para Compra Foods Services
https://integracao.lopesecia.com.br:9001/services/Customer/Integradora_1/Filial_1
https://integracao.lopesecia.com.br:9001/services/Order/Integradora_1/Filial_1
https://integracao.lopesecia.com.br:9001/services/Payment/Integradora_1/Filial_1
Exemplo de endpoint para Compra Agora
https://integracao.lopesecia.com.br:9001/services/Customer/Integradora_2/Filial_1
https://integracao.lopesecia.com.br:9001/services/Order/Integradora_2/Filial_1
https://integracao.lopesecia.com.br:9001/services/Payment/Integradora_2/Filial_1
ou então:
https://integracao.lopesecia.com.br:9001/B2bServices/CustomerServices
https://integracao.lopesecia.com.br:9001/B2bServices/OrderServices
https://integracao.lopesecia.com.br:9001/B2bServices/PaymentServices
e a definição de Integradora e filial fica amarrada aos dados de acesso configurado no painel de controle. Aqui fizemos uma pequena demonstração, mas para acessar ainda é necessário ter o token ou usuário e senha do serviço. O token é formado pelo usuário e senha que são criptografados utilizando base 64 de criptografia. O usuário e senha são configurados manualmente no painel da integradora.
O fluxo é definido pelo e-commerce, logo precisamos saber o que é possível integrar. A imagem abaixo nos ajuda a entender o processo.
Assim podemos definir que existe ponto de acesso no e-commerce assim como na integradora, que por sua vez traduz a comunicação para o ERP. O e-commerce possui dois ambientes distintos: um chamado de homologação e outro de produção. O ambiente de homologação é criado para uma ação específica chamada rollout, onde é preciso validar todos os processos (cenários) e evidenciá-los com imagens, arquivos, documentos que possam comprovar o funcionamento correto dos ambientes de trabalho. O ambiente de produção conta com vários servidores de acordo com o serviço, logo podemos ter alguns serviços funcionando e outro pode estar parado. Essa afirmação é apenas para ilustração já que a infracommerce garante sempre um bom funcionamento dos seus servidores.
Então vamos definir pela imagem acima que a integradora inicia o processo fazendo envio de estoque e de preço, e que para isto, ela pega os dados no ERP. Com esse entendimento, fica claro que para funcionarmos precisamos antes de tudo, vincular produtos que serão vendidos no e-commerce, mas observe que falamos vincular e não cadastrar. Foi tratado com vincular porque de fato o Seller não tem ferramenta para cadastrar um produto no site e caso ele precise fazer isso, terá que solicitar ao NRP ou ao player que no exemplo dado no início era o Compra Foods Services.
Após termos produtos vinculados, os serviços automaticamente começam a enviar preço e estoque, deixando assim os produtos ativos no site. Caso um item fique sem preço e sem estoque o mesmo é desativado. Outra informação importante sobre o produto é que ele pode ser vendido por unidade ou por caixa e existe uma informação técnica para essa definição que vamos apresentar na parte de vínculo do produto.
Após termos produtos disponíveis no site, um cliente pode se cadastrar e fazer uma compra. O site tem regras de negócio, mas no geral, por se tratar de B2b o cliente se cadastra para ver os preços e só será um preço ou prazo diferenciado após análise do seller. Para isso, o site envia o cadastro do cliente primeiro e depois envia o pedido. Apesar dessa regra, pode ocorrer do cliente já se cadastrar e já efetuar uma compra a vista no cartão ou antecipada no boleto (modalidades default no e-commerce), por isso, podemos receber um pedido mesmo sem ter o cadastro do cliente. A parte boa é que, no pedido vem dados do cliente e assim é possível cadastrá-lo no ERP para integrar o pedido.
Quando um pedido for integrado, a integradora fica a procurar alterações nos status do pedido dentro do ERP para notificar ao e-commerce, esses passos chamados tracking. Existe modalidade de pedido como por exemplo um pedido pago no cartão de crédito cujo recebimento financeiro é feito pelo site, nessa modalidade o e-commerce precisa enviar uma notificação ao ERP autorizando ou negando a entrega do pedido, este passo é conhecido como aprovação ou reprovação do pagamento. Da mesma forma, em casos que o Seller que for emitir a cobrança, por exemplo um boleto para 28 dias, a Integradora deverá notificar o site de aprovação ou reprovação. É importante documentar que os Sellers não são obrigados a dar Crédito ou vender a prazo, eles podem fazer uma análise antes de autorizar ou contratar uma operadora de crédito para assumir essa responsabilidade.
Sobre as operadoras de créditos, existem várias, mas normalmente eles se ligam direto no e-commerce e não costuma passar pela integradora, mas com isso não é uma regra, existe a operadora infrapay (uma divisão da infracommerce) que parametrizamos direto na integradora e pode ser utilizada, assim como com apenas para validação do limite de crédito, temos também os serviços da CDL, que podem ser contratados avulso.
A infracommerce nos ensinava antes a utilizar a ferramenta SoapUI para simular os ambientes e testar os serviços. Mas a verdade é que o seu conhecimento é o limite, pode usar o Postman, o Insomnia ou outra ferramenta capaz de se consumir serviços web transferindo tecnologia Soa. Inclusive em nossa integradora utilizamos as tecnologias Soa e Rest. Mas aqui vamos exemplificar com a ferramenta SoapUI versão 5.5.0 um consumo do nosso endpoint de Payment então perceba o cenário:
Um cliente fez uma compra no e-commerce e escolheu o pagamento Boleto A vista, que na verdade é um pagamento antecipado, assim ao efetuar a compra o pedido foi integrado, mas deve ficar com um bloqueio financeiro esperando a confirmação do pagamento. Quando o banco notificar o pagamento para o site, ele por sua vez fará essa notificação consumindo o endpoint da integradora. No exemplo, utilizaremos o endpoint https://integracao.lopesecia.com.br:9001/services/Payment/Integradora_1/Filial_1 da integradora com o usuário usuarioDeTeste123 e senha Teste123 para notificar a order 90147498 sendo Aprovada. Outro ponto é que vamos utilizar uma estrutura de xml (onde a tecnologia Soa se baseia) para informar ao servidor do Seller que o pagamento foi realizado. Todos esses dados técnicos de estrutura e resposta esperada são fornecidos pela infracommerce pelo manual de integração indicado no início deste documento.
Traduzindo a imagem, enviamos o body:
<soapenv: Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:pay="http://www.accurate.com/acec/PaymentServices">
<soapenv:Header/>
<soapenv:Body>
<pay:confirmPaymentRequest>
<pay:orderId>90147498</pay:orderId>
<pay:status>AP</pay:status>
</pay:confirmPaymentRequest>
</soapenv:Body>
</soapenv:Envelope>
e recebemos como resposta o body:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<confirmPaymentResponse xmlns:ps="http://www.accurate.com/acec/PaymentServices">
<success>True</ps:success>
<statusMessage/>
</confirmPaymentResponse>
</soap:Body>
</soap:Envelope>
Bom, não é comum, mas uma pequena alteração nesses códigos pode ser simples, assim como pode ser complexo, e por não ser o foco deste documento, vamos apenas ficar assim, pois é trabalho da integradora resolver essa comunicação e temos o painel da integradora justo para manipular (fazer envios) tarefas que possam se necessária para o momento.