Conectar Sage 100 / Sage 300: verificar la conectividad de la Web API de Sage 300

Una conexión cubre ambos productos y el campo variant decide cuál quiere decir: sage300 ejecuta una prueba de conectividad real contra la Web API de Sage 300 con su dirección de servicio, código de compañía y cuenta de usuario, mientras que sage100 devuelve un resultado honesto de no disponible. Complete variant, URL base, compañía, usuario y contraseña, y pruebe, empezando por Sage 300.

Esta es una conexión para dos productos Sage, y el primer campo, variant, decide todo lo que sigue. Con variant en sage300, la conexión verifica que este sistema pueda llegar a su Web API de Sage 300: se autentica con su cuenta de usuario de Sage 300 mediante HTTP Basic y lee una vez el perfil de su compañía. Con variant en sage100, la prueba no envía ninguna solicitud: devuelve un resultado honesto de no disponible, porque la llamada a eBusiness Web Services de Sage 100 se basa en SOAP y su solicitud debe confirmarse antes con su propio WSDL. Para ambos productos, tenga claro el alcance: esta conexión solo verifica la conectividad. No trae pedidos, clientes ni inventario, y no devuelve inventario: en Sage 300, los nombres de campo que devuelven sus vistas deben confirmarse antes con el swagger de su propio despliegue. Una prueba de Sage 300 aprobada solo demuestra que los cinco valores siguientes funcionan juntos para esa compañía, y nada más.

Requisitos previos#

• Sabe qué producto usa realmente: Sage 300 o Sage 100. Esto decide el valor de variant, y las dos rutas se comportan de forma completamente distinta en la prueba.
• Para Sage 300: el servicio Web API de Sage 300 está en marcha en su servidor, en una dirección con la forma https://server/Sage300WebApi. Puede comprobar el servicio usted mismo abriendo {baseUrl}/swagger en un navegador: si esa página responde, el servicio está activo.
• Una cuenta de usuario en su sistema Sage local para la integración: para Sage 300, un usuario de Sage 300 que pueda autenticarse mediante HTTP Basic y tenga permiso para usar la Web API; para Sage 100, un usuario de Web Services. No hay ningún registro en la nube para estas credenciales: la cuenta vive en su propio sistema Sage.
• Su código de compañía: para Sage 300, el Org ID de compañía que aparece en la dirección de la Web API, por ejemplo SAMINC; para Sage 100, su código de compañía.

Obtener credenciales#

1. Decida primero la palabra variant, antes de reunir cualquier otra cosa: escriba sage300 si usa Sage 300, o sage100 si usa Sage 100. La palabra exacta importa: la prueba la lee literalmente.
2. Para Sage 300, anote la dirección de la Web API de su servidor, por ejemplo https://server/Sage300WebApi. Abra primero {esa dirección}/swagger en un navegador: si la página responde, tiene la dirección correcta y el servicio está en marcha.
3. Para Sage 100, anote en su lugar la dirección de eBusiness Web Services de su servidor, por ejemplo https://server/ebusinesswebservices. Téngala lista junto con su WSDL, que guarda su administrador de Sage.
4. Anote su código de compañía: para Sage 300, el Org ID de compañía usado en la dirección de la Web API, por ejemplo SAMINC; para Sage 100, el código de compañía de la empresa que quiere conectar.
5. Pida a su administrador de Sage la cuenta de usuario de integración en su sistema Sage local, y anote su usuario y contraseña como un par: para Sage 300, el usuario de Sage 300 para la autenticación HTTP Basic; para Sage 100, el usuario de Web Services. Use una cuenta creada para la integración, no el acceso diario de una persona.

Completar en Integration#

1. Abra Integration → Marketplace → Sage 100 / Sage 300 → Nueva conexión.
2. variant, obligatorio, variante de producto: escriba la única palabra sage300 si usa Sage 300, o sage100 si usa Sage 100. sage300 va a la Web API de Sage 300 (OData). sage100 va a eBusiness Web Services de Sage 100 (SOAP), que necesita primero la confirmación de su WSDL y aún no está abierto para pruebas.
3. base_url, obligatorio, URL base del servicio: para Sage 300, pegue su dirección de Web API, por ejemplo https://server/Sage300WebApi. Para Sage 100, pegue en su lugar su dirección de eBusiness Web Services, por ejemplo https://server/ebusinesswebservices.
4. company, obligatorio, código de compañía: para Sage 300, escriba el Org ID de compañía que corresponde en la dirección de la Web API, por ejemplo SAMINC. Para Sage 100, escriba su código de compañía.
5. username, obligatorio, nombre de usuario: escriba el nombre de usuario de la cuenta de integración en su sistema Sage local: el usuario de Sage 300 para sage300, el usuario de Web Services para sage100. La forma de ejemplo es un nombre de usuario de API creado para esta conexión.
6. password, obligatorio, contraseña: pegue la contraseña de esa misma cuenta. Es un campo de tipo contraseña y se guarda como secreto. El usuario y la contraseña deben pertenecer a la misma cuenta.

Probar la conexión#

Haga clic en Probar la conexión. Lo que ocurre depende de variant, y la prueba lee ese campo primero. Si variant está vacío, la prueba se detiene con MISSING_VARIANT; si no es sage300 ni sage100, se detiene con INVALID_VARIANT. Si variant es sage100, la prueba devuelve enseguida el resultado ERP_ENDPOINTS_PENDING y no envía ninguna solicitud: esa es la respuesta honesta para Sage 100 hoy, no un error en sus otros campos. Si variant es sage300, la prueba comprueba los otros cuatro campos y se detiene con MISSING_BASE_URL, MISSING_COMPANY, MISSING_USERNAME o MISSING_PASSWORD si falta uno. Después se autentica con HTTP Basic —su usuario y contraseña— y lee el perfil de la compañía, el metadato más ligero que puede pedir, en {base}/v1.0/-/{company}/CS/CSCompanyProfile, con un límite de 12 segundos. Una respuesta 200 aprueba. Un 401 se informa como INVALID_TOKEN, un 403 como MISSING_SCOPE y un 404 como NOT_FOUND: vea la FAQ para saber qué significa cada uno.

Mapping / elegir plantilla#

En esta conexión no hay un mapping estándar que configurar ni una plantilla que elegir. En Sage 300, las vistas devuelven nombres de campo que siguen el swagger de cada despliegue, así que cualquier mapping de pedidos, inventario o clientes debe confirmarse con {baseUrl}/swagger de su propio servidor cuando se prepare una conexión de datos para usted: no es algo que adivinar ni que completar aquí. En Sage 100, la propia solicitud SOAP debe confirmarse primero con su WSDL. Hasta que esa confirmación por despliegue exista, esta conexión se queda en la comprobación de conectividad que hace en el paso de prueba. No renombre vistas ni campos en Sage para ajustarlos a un mapping adivinado.

Activar#

Para Sage 300, cuando la prueba pase, active la conexión para guardarla en Integration con estos valores verificados, así la misma compañía podrá comprobarse de nuevo más tarde con la misma cuenta. La activación no inicia ningún flujo de datos: por esta conexión no se mueven pedidos, clientes ni inventario, en ninguna dirección. Si la contraseña de la cuenta de integración cambia después, actualice aquí el campo de contraseña y pruebe de nuevo. Para Sage 100, aún no hay nada que activar: el resultado de la prueba ya le dijo el estado, y cambiar los otros campos no lo cambiará.

Preguntas frecuentes#

Uso Sage 100 y la prueba devuelve ERP_ENDPOINTS_PENDING

Ese resultado es el esperado para Sage 100, y no lo causa nada de lo que escribió. En cuanto la prueba lee variant como sage100, devuelve este resultado sin enviar ninguna solicitud, porque la conexión de Sage 100 pasa por eBusiness Web Services sobre SOAP, y esa solicitud debe confirmarse primero con el WSDL de su propio despliegue. Ninguna dirección, código de compañía, usuario o contraseña puede cambiar este resultado hoy.

No siga cambiando los otros campos: no son la causa. Compruebe solo una cosa: si en realidad usa Sage 300, cambie variant a sage300 y pruebe de nuevo, porque estaba en la ruta equivocada. Si realmente usa Sage 100, tenga listos su dirección de servicio, código de compañía y usuario de Web Services junto con su WSDL, y espere a que la ruta de Sage 100 se abra antes de completar esta conexión.

La prueba se detiene con MISSING_VARIANT o INVALID_VARIANT

La prueba lee variant antes que cualquier otra cosa, porque esa sola palabra enruta toda la prueba. MISSING_VARIANT significa que el campo está vacío. INVALID_VARIANT significa que la palabra que contiene no es ninguna de las dos que la conexión acepta: un nombre de producto escrito en otra forma, con palabras extra o con un espacio, no enruta a ninguna parte.

Escriba exactamente una palabra en variant: sage300 para Sage 300, sage100 para Sage 100, sin espacios y sin palabras extra. Guarde y pruebe de nuevo.

La prueba de Sage 300 falla con INVALID_TOKEN (401)

La Web API de Sage 300 no aceptó la autenticación HTTP Basic: su usuario y contraseña, como par, fueron rechazados. Las causas habituales son un error al escribir o copiar, una contraseña cambiada desde que la anotó, o un usuario combinado con la contraseña de otra cuenta.

Vuelva a obtener el usuario y la contraseña de la única cuenta de integración de su administrador de Sage, cópielos sin espacios extra, confirme que el usuario está en username y la contraseña en password, y pruebe de nuevo. Si la contraseña de la cuenta se restableció en Sage, use aquí la nueva.

La prueba de Sage 300 falla con MISSING_SCOPE (403)

La autenticación funcionó, pero ese usuario de Sage 300 no tiene permiso para usar la Web API. Se llegó a la dirección y a la compañía: a la propia cuenta le falta el permiso de Web API, así que cambiar la dirección o el código de compañía no arreglará este caso.

Pida a su administrador de Sage que permita a ese usuario usar la Web API de Sage 300, o que le dé otro usuario de Sage 300 que ya tenga el permiso. Actualice aquí username y password si la cuenta cambia, y pruebe de nuevo.

La prueba de Sage 300 falla con NOT_FOUND (404)

El perfil de compañía que la prueba pide no se encontró en esa dirección para esa compañía. O el código de compañía no coincide con el Org ID de ninguna compañía en ese servidor, o base_url no apunta a la raíz de la Web API de Sage 300: una pequeña diferencia en la dirección tiene el mismo efecto.

Primero abra {baseUrl}/swagger en un navegador: si no responde, corrija base_url hasta que responda, y compruebe que la dirección termina en la raíz de la Web API, por ejemplo https://server/Sage300WebApi. Si swagger responde, contraste company con el Org ID usado en sus direcciones de Web API, por ejemplo SAMINC, y pruebe de nuevo.

La prueba de Sage 300 se detiene con MISSING_BASE_URL, MISSING_COMPANY, MISSING_USERNAME o MISSING_PASSWORD

En la ruta sage300, el resultado nombra el campo exacto que está vacío. La prueba comprueba estos cuatro campos después de variant y no envía nada hasta que todos estén presentes, porque la lectura del perfil de la compañía necesita la dirección, la compañía y la autenticación Basic juntos.

Complete el campo nombrado (URL base del servicio, código de compañía, usuario o contraseña) con los valores que reunió, guarde y pruebe de nuevo. Repita hasta que no aparezca ningún resultado de faltante.

La prueba de Sage 300 pasó, pero no se sincronizan pedidos, inventario ni clientes

Ese es el alcance actual de esta conexión, no un fallo en sus valores. La prueba solo demuestra que la autenticación Basic y la lectura del perfil de la compañía funcionan. El movimiento de datos aún no forma parte de esta conexión, porque los nombres de campo que devuelven las vistas de Sage 300 siguen el swagger de cada despliegue y primero deben confirmarse con {baseUrl}/swagger de su propio servidor.

Trate una prueba de Sage 300 aprobada como una conexión verificada para esta compañía, y mantenga por ahora el trabajo de pedidos, inventario y clientes en el propio Sage 300. Cuando se prepare una conexión de datos para su despliegue, partirá de estos mismos valores verificados y de su swagger: no necesitará reunir las credenciales otra vez.