Conectar o Sage 100 / Sage 300: verificar a conectividade da Web API do Sage 300

Uma conexão cobre os dois produtos e o campo variant decide qual você quer dizer: sage300 executa um teste de conectividade real contra a Web API do Sage 300 com seu endereço de serviço, código da empresa e conta de usuário, enquanto sage100 devolve um resultado honesto de indisponível. Preencha variant, URL base, empresa, usuário e senha, e teste, começando pelo Sage 300.

Esta é uma conexão para dois produtos Sage, e o primeiro campo, variant, decide tudo o que segue. Com variant em sage300, a conexão verifica se este sistema consegue alcançar sua Web API do Sage 300: ela autentica com sua conta de usuário do Sage 300 via HTTP Basic e lê uma vez o perfil da sua empresa. Com variant em sage100, o teste não envia nenhuma solicitação: ele devolve um resultado honesto de indisponível, porque a chamada ao eBusiness Web Services do Sage 100 é baseada em SOAP e sua solicitação precisa ser confirmada antes com o seu próprio WSDL. Para os dois produtos, tenha o escopo claro: esta conexão apenas verifica a conectividade. Ela não traz pedidos, clientes nem estoque, e não devolve estoque: no Sage 300, os nomes de campo que suas views devolvem precisam ser confirmados antes com o swagger da sua própria implantação. Um teste do Sage 300 aprovado só prova que os cinco valores abaixo funcionam juntos para essa empresa, e nada mais.

Pré-requisitos#

• Você sabe qual produto realmente usa: Sage 300 ou Sage 100. Isso decide o valor de variant, e os dois caminhos se comportam de forma completamente diferente no teste.
• Para o Sage 300: o serviço Web API do Sage 300 está em execução no seu servidor, em um endereço no formato https://server/Sage300WebApi. Você mesmo pode verificar o serviço abrindo {baseUrl}/swagger em um navegador: se essa página responder, o serviço está ativo.
• Uma conta de usuário no seu sistema Sage local para a integração: para o Sage 300, um usuário do Sage 300 que consiga autenticar via HTTP Basic e tenha permissão para usar a Web API; para o Sage 100, um usuário de Web Services. Não há cadastro em nuvem para essas credenciais: a conta vive no seu próprio sistema Sage.
• Seu código de empresa: para o Sage 300, o Org ID da empresa que aparece no endereço da Web API, por exemplo SAMINC; para o Sage 100, seu código de empresa.

Obter credenciais#

1. Decida primeiro a palavra variant, antes de reunir qualquer outra coisa: digite sage300 se você usa o Sage 300, ou sage100 se usa o Sage 100. A palavra exata importa: o teste a lê literalmente.
2. Para o Sage 300, anote o endereço da Web API do seu servidor, por exemplo https://server/Sage300WebApi. Abra primeiro {esse endereço}/swagger em um navegador: se a página responder, você tem o endereço certo e o serviço está em execução.
3. Para o Sage 100, anote em vez disso o endereço do eBusiness Web Services do seu servidor, por exemplo https://server/ebusinesswebservices. Deixe-o pronto junto com o seu WSDL, que fica com o seu administrador do Sage.
4. Anote seu código de empresa: para o Sage 300, o Org ID da empresa usado no endereço da Web API, por exemplo SAMINC; para o Sage 100, o código de empresa da empresa que você quer conectar.
5. Peça ao seu administrador do Sage a conta de usuário de integração no seu sistema Sage local, e anote seu usuário e senha como um par: para o Sage 300, o usuário do Sage 300 para autenticação HTTP Basic; para o Sage 100, o usuário de Web Services. Use uma conta criada para a integração, não o acesso diário de uma pessoa.

Preencher no Integration#

1. Abra Integration → Marketplace → Sage 100 / Sage 300 → Nova conexão.
2. variant, obrigatório, variante de produto: digite a única palavra sage300 se você usa o Sage 300, ou sage100 se usa o Sage 100. sage300 vai para a Web API do Sage 300 (OData). sage100 vai para o eBusiness Web Services do Sage 100 (SOAP), que precisa primeiro da confirmação do seu WSDL e ainda não está aberto para testes.
3. base_url, obrigatório, URL base do serviço: para o Sage 300, cole seu endereço da Web API, por exemplo https://server/Sage300WebApi. Para o Sage 100, cole em vez disso seu endereço do eBusiness Web Services, por exemplo https://server/ebusinesswebservices.
4. company, obrigatório, código da empresa: para o Sage 300, digite o Org ID da empresa que corresponde no endereço da Web API, por exemplo SAMINC. Para o Sage 100, digite seu código de empresa.
5. username, obrigatório, nome de usuário: digite o nome de usuário da conta de integração no seu sistema Sage local: o usuário do Sage 300 para sage300, o usuário de Web Services para sage100. A forma de exemplo é um nome de usuário de API criado para esta conexão.
6. password, obrigatório, senha: cole a senha dessa mesma conta. É um campo do tipo senha e guardado como segredo. O usuário e a senha devem pertencer à mesma conta.

Testar a conexão#

Clique em Testar a conexão. O que acontece depende de variant, e o teste lê esse campo primeiro. Se variant estiver vazio, o teste para com MISSING_VARIANT; se não for sage300 nem sage100, para com INVALID_VARIANT. Se variant for sage100, o teste devolve de imediato o resultado ERP_ENDPOINTS_PENDING e não envia nenhuma solicitação: essa é a resposta honesta para o Sage 100 hoje, não um erro nos seus outros campos. Se variant for sage300, o teste verifica os outros quatro campos e para com MISSING_BASE_URL, MISSING_COMPANY, MISSING_USERNAME ou MISSING_PASSWORD se algum faltar. Depois, autentica com HTTP Basic —seu usuário e senha— e lê o perfil da empresa, o metadado mais leve que pode pedir, em {base}/v1.0/-/{company}/CS/CSCompanyProfile, com um limite de 12 segundos. Uma resposta 200 aprova. Um 401 é informado como INVALID_TOKEN, um 403 como MISSING_SCOPE e um 404 como NOT_FOUND: veja a FAQ para saber o que cada um significa.

Mapping / escolher modelo#

Nesta conexão não há mapeamento padrão para configurar nem modelo para escolher. No Sage 300, as views devolvem nomes de campo que seguem o swagger de cada implantação, então qualquer mapeamento de pedidos, estoque ou clientes precisa ser confirmado com {baseUrl}/swagger do seu próprio servidor quando uma conexão de dados for preparada para você: não é algo para adivinhar nem preencher aqui. No Sage 100, a própria solicitação SOAP precisa primeiro ser confirmada com o seu WSDL. Até que essa confirmação por implantação exista, esta conexão fica na verificação de conectividade que ela faz na etapa de teste. Não renomeie views nem campos no Sage para encaixar um mapeamento adivinhado.

Ativar#

Para o Sage 300, quando o teste passar, ative a conexão para salvá-la no Integration com esses valores verificados, assim a mesma empresa poderá ser verificada de novo depois com a mesma conta. A ativação não inicia nenhum fluxo de dados: por esta conexão não se movem pedidos, clientes nem estoque, em nenhuma direção. Se a senha da conta de integração mudar depois, atualize aqui o campo de senha e teste de novo. Para o Sage 100, ainda não há nada para ativar: o resultado do teste já lhe disse o estado, e mudar os outros campos não o mudará.

Perguntas frequentes#

Uso o Sage 100 e o teste devolve ERP_ENDPOINTS_PENDING

Esse resultado é o esperado para o Sage 100, e não é causado por nada que você digitou. Assim que o teste lê variant como sage100, ele devolve esse resultado sem enviar nenhuma solicitação, porque a conexão do Sage 100 passa pelo eBusiness Web Services sobre SOAP, e essa solicitação precisa ser confirmada primeiro com o WSDL da sua própria implantação. Nenhum endereço, código de empresa, usuário ou senha pode mudar esse resultado hoje.

Não fique mudando os outros campos: eles não são a causa. Verifique só uma coisa: se você na verdade usa o Sage 300, mude variant para sage300 e teste de novo, porque você estava no caminho errado. Se você realmente usa o Sage 100, deixe prontos seu endereço de serviço, código de empresa e usuário de Web Services junto com o seu WSDL, e espere a abertura do caminho do Sage 100 antes de concluir esta conexão.

O teste para com MISSING_VARIANT ou INVALID_VARIANT

O teste lê variant antes de qualquer outra coisa, porque essa única palavra roteia todo o teste. MISSING_VARIANT significa que o campo está vazio. INVALID_VARIANT significa que a palavra nele não é nenhuma das duas que a conexão aceita: um nome de produto escrito em outra forma, com palavras extras ou com um espaço, não roteia para lugar nenhum.

Digite exatamente uma palavra em variant: sage300 para o Sage 300, sage100 para o Sage 100, sem espaços e sem palavras extras. Salve e teste de novo.

O teste do Sage 300 falha com INVALID_TOKEN (401)

A Web API do Sage 300 não aceitou a autenticação HTTP Basic: seu usuário e senha, como par, foram recusados. As causas habituais são erro ao digitar ou copiar, uma senha alterada desde que você a anotou, ou um usuário combinado com a senha de outra conta.

Obtenha novamente o usuário e a senha da única conta de integração com seu administrador do Sage, copie sem espaços extras, confirme que o usuário está em username e a senha em password, e teste de novo. Se a senha da conta foi redefinida no Sage, use aqui a nova.

O teste do Sage 300 falha com MISSING_SCOPE (403)

A autenticação funcionou, mas esse usuário do Sage 300 não tem permissão para usar a Web API. O endereço e a empresa foram alcançados: falta à própria conta a permissão da Web API, então mudar o endereço ou o código da empresa não resolverá este caso.

Peça ao seu administrador do Sage que permita a esse usuário usar a Web API do Sage 300, ou que lhe dê outro usuário do Sage 300 que já tenha a permissão. Atualize aqui username e password se a conta mudar, e teste de novo.

O teste do Sage 300 falha com NOT_FOUND (404)

O perfil de empresa que o teste pede não foi encontrado nesse endereço para essa empresa. Ou o código de empresa não corresponde ao Org ID de nenhuma empresa nesse servidor, ou base_url não aponta para a raiz da Web API do Sage 300: uma pequena diferença no endereço tem o mesmo efeito.

Primeiro abra {baseUrl}/swagger em um navegador: se não responder, corrija base_url até responder, e verifique se o endereço termina na raiz da Web API, por exemplo https://server/Sage300WebApi. Se o swagger responder, confira company com o Org ID usado nos seus endereços da Web API, por exemplo SAMINC, e teste de novo.

O teste do Sage 300 para com MISSING_BASE_URL, MISSING_COMPANY, MISSING_USERNAME ou MISSING_PASSWORD

No caminho sage300, o resultado nomeia o campo exato que está vazio. O teste verifica esses quatro campos depois de variant e não envia nada até que todos estejam presentes, porque a leitura do perfil da empresa precisa do endereço, da empresa e da autenticação Basic juntos.

Preencha o campo nomeado (URL base do serviço, código de empresa, usuário ou senha) com os valores que você reuniu, salve e teste de novo. Repita até que nenhum resultado de faltante apareça.

O teste do Sage 300 passou, mas pedidos, estoque ou clientes não são sincronizados

Esse é o escopo atual desta conexão, não uma falha nos seus valores. O teste só prova que a autenticação Basic e a leitura do perfil da empresa funcionam. A movimentação de dados ainda não faz parte desta conexão, porque os nomes de campo que as views do Sage 300 devolvem seguem o swagger de cada implantação e primeiro precisam ser confirmados com {baseUrl}/swagger do seu próprio servidor.

Trate um teste do Sage 300 aprovado como uma conexão verificada para esta empresa, e mantenha por enquanto o trabalho de pedidos, estoque e clientes no próprio Sage 300. Quando uma conexão de dados for preparada para a sua implantação, ela partirá desses mesmos valores verificados e do seu swagger: você não precisará reunir as credenciais de novo.