A cada dia é mais incomum as plataformas utilizarem comunicação diretamente na base dedos, principalmente para terceiros, mas existem casos que ainda é a melhor opção para se consumir dados. Como o foco desse conteúdo é para um operador da integração e não para um técnico, seremos sucintos com as informações a seguir.
O banco de dados é um sistema de coleção de dados e normalmente está presente nos sistemas especialistas tais como o ERP ou o CRM que apoia a gerência de sua empresa. Assim, provavelmente deve ter um computador central chamado de servidor que nele deve ter o banco de dados instalado. Conseguimos nos comunicar com essa base normalmente através de um programa do tipo SGDB (Gerenciador de banco de dados) e com ele podemos executar tarefas que o usuário logado tiver privilégio (permissão) para executar.
Operar este programa depende de conhecimento técnico e só deve ser manipulado por profissionais capacitados, já é possível em apenas um único comando destruir toda a base de dados da empresa. No nosso exemplo vamos mostrar como se conectar a uma base de dados da Oracle e utilizaremos a versão XE e também como SGDB vamos utilizar o SQL Developer, ferramenta da que também pertence à Oracle.
Quando conectado poderá criar e executar comandos SQL, vamos por exemplo consultar sobre pedido. Com o comando SELECT * FROM PEDIDOCAB WHERE INTEGRADORA = 2; vamos listar todos os pedidos da integradora 2.
De fato nesse ambiente o conhecimento técnico é o limite. Por não ser o foco deste manual, ficaremos por aqui nesta apresentação da ferramenta.
Algo bem mais seguro, moderno e com isso confiável. Primeiro porque não se expõem completamente o ambiente e pode ser acessível de qualquer lugar pela internet, mas é claro que isso vai depender da estrutura oferecida e das regras de segurança estabelecidas pela TI. Mas aqui consideramos que temos todos os dados necessários e ambiente também, vamos exemplificar como acessar utilizando uma API.
Primeiro saiba que vamos abordar dois modelos de API, a que utiliza protocolo Soap e a que se baseia com REST. Igual que falamos antes não é foco desse material, mas é importante que o operador tenha uma visão clara dos cenários contidos no universo da integração e-commerce para ERP.
ERP Tiny
Ficamos muito felizes com a documentação ofertada para comunicação do ERP, mas todo manual, incluindo este, sempre aborda o cenário perfeito e costumeiramente é algo direcionado ao fluxo ideal. Mas ao tratarmos ambientes diferentes, podemos ligar com exceções e isso também é algo natural, por isso existe nosso time de suporte. O tiny nos oferece uma documentação pelo link (https://www.tiny.com.br/api-docs/api2?utm_source=google&utm_campaign=15445705156&utm_medium=ad&utm_content=&utm_term=&utm_campaign_name=&gclid=CjwKCAjw1ICZBhAzEiwAFfvFhBlkaperpzg9crSa_3c2UVKpSZoKAoPTNsKgbTtMUatircmdvK7OXBoC9tUQAvD_BwE). Tendo os dados necessários vamos exemplificar uma consulta de preço conforme indicado pelo manual.
Nesta API se pode receber e enviar dados utilizado a estrutura de XML ou de JSON, nessa amostragem utilizamos JSON.
ERP Sankhya
Essa API também possui uma documentação muito eficiente, mas é um pouco mais profunda, já que é possível até criar consultas personalizadas. No endereço https://developer.sankhya.com.br/reference/api-de-integra%C3%A7%C3%B5es-sankhya se tem a documentação necessária para fazer uma comunicação.
Nesse modelo de negócio é preciso fazer 3 passos.
1º Solicitar um token
2º Executar as tarefas dentro do prazo
3º Fechar a sessão.
Assim vamos precisar de um usuário e senha, podemos fazer o login e adquirir o token. Nesse exemplo o endpoint ficou assim: http://grfnet.ddns.net:60021/mge/service.sbr?serviceName=MobileLoginSP.login&outputType=json
Depois utilizamos o endpoint http://grfnet.ddns.net:60021/mge/service.sbr?serviceName=CRUDServiceProvider.loadRecords&outputType=json aplicando o token no header
agora para finalizar só falta encerrar a sessão no endpoint http://grfnet.ddns.net:60021/mge/service.sbr?serviceName=MobileLoginSP.logout&outputType=json
É importante lembrar que cada requisição possui seu body específico e ele deve ser montado corretamente porque são os parâmetros da operação. No exemplo do login foi utilizado :
{
"serviceName": "MobileLoginSP.login",
"requestBody": {
"NOMUSU": {
"$": "USUARIO"
},
"INTERNO":{
"$":"SENHA"
},
"KEEPCONNECTED": {
"$": "S"
}
}
}
No exemplo da consulta foi utilizado:
{
"serviceName": "MobileLoginSP.login",
"requestBody": {
"NOMUSU": {
"$": "USUARIO"
},
"INTERNO":{
"$":"SENHA"
},
"KEEPCONNECTED": {
"$": "S"
}
}
}
Para mais informações, você deve ler o manual de instruções da API Sankhya ou chamar o time de suporte Sankhya.