Creación Webservice: Configurar portales y Webservices

Toda integración debe contener un webservice activo.

Configurado mediante el appserver.ini:

Puert = Defina el puerto

Puert = Defina el puerto

ResponseJob = Defina un nombre de JOB

127.0.0.1 = IP Localhost (facilita para nuestras pruebas)

Obs: Servicio responsabilidad del Framework.

Al iniciar el appserver, en el browse acceda al ip + puerto para que vea el webservice en el aire (ejemplo: 10.173.10.219:8087/ws01), podrá verificar si su servicio está activo al buscar y este conste como "HABILITADO":

Después, busque por EAISERVICE y haga clic en el enlace. Este servicio es el responsable por la comunicación entre los XML:

Haga clic en el enlace "Descripción del servicio (WSDL)", el enlace que se abra se utilizará para configurar tanto el Soap como el MV_EAIURL2:

Camino seleccionado: Utilice para configurar SoapUi o si tiene una integración Protheus vs. Protheus, configure en el parámetro MV_EAIURL2:

Principales parámetros utilizados:

Parámetros: PARÁMETROS TOP VS. PROTHEUS - EAI 1 / EAI 2

• MV_EAIURL2: Responsable para la comunicación entre el Protheus y el otro sistema. Informe el webservice del otro sistema solo cuando el Protheus sea ENVIAR el mensaje único.

• MV_EAIWS: Client Service, ya viene configurado, pero, se debe modificar cuando se integra al Datasul.

• MV_EAIUSER: Si el webservice necesita alguna autenticación de usuario y contraseña, informe el usuario en este parámetro.

• MV_EAIPASS: Si el webservice necesita alguna autenticación de usuario y contraseña, informe el usuario en este parámetro.

• MV_RESTINC:Indica si restringe la inclusión de un pedido de compras sin una solicitud de compras para los usuarios no registrados como compradores. Contenido del parámetro igual Sí.

• MV_SLMPUSR: Define la utilización del usuario enviado por el TOTVS Obras y Proyectos. Este usuario se almacena en el campo C7_USER de la tabla de pedidos de compras.

• MV_PMSITMU: Indica que la integración del módulo SIGAPMS, por mensaje único, está activada. (Es necesario activar para que el sistema busque el usuario informado en el XML).

• MV_SLMPREP: Define el prefijo de los títulos por pagar.

• MV_SLMCOND: Condición de pago estándar.

• MV_SLMTS: Tipo de salida (TES) estándar.

• MV_SLMNATP: Origen estándar del título por pagar.

• MV_SLMNATR: Origen estándar del título por cobrar.

• MV_SLMPROP: Producto estándar del gasto minorista (título por pagar).

• MV_SLMCOMP: Define el nombre del usuario comprador estándar para aprobación/WS.

MV_SLMNTPV: Origen estándar del pedido de venta.

 De/A Empresas - APCFG050  - (SIGACFG->Entorno->Schedule) – Tabla XXD:

• Registro para informar el Sistema/Empresa/Sucursal que integrará el Protheus.
• Referencia = Nombre de la empresa que integrará el Protheus <Product:Name>
• Empresa = Código de la empresa <CompanyId>
• Sucursal = Sucursal de la empresa <BranchId>
• Grupo Emp. Protheus = Código de la empresa (99 - Protheus)
• Suc. Protheus = Sucursal de la empresa (01 - Protheus)

De/A Mensaje único - APCFG070  - (SIGACFG->Entorno->Schedule) – Tabla XXF:

Registro donde quedan los datos que informan la clave única en el Protheus (Valor interno) y la clave única en el otro sistema (RM – Valor externo):

Obs:

En el registro de Adapter de la integració delo registro de proveedores (Rutina: MATA020 - Mensaje: CUSTOMERVENDOR), para que haya integración de la información de Tipo de Cuenta (campo A2_TIPCTA) del registro del proveedor, el XML de ENVÍO mencionado, debe estar en una versión a partir de la 2.004, así como los debidos registros de los Adapter.

Configuración Adapter (SIGACFG -> Schedule -> Adapter E.A.I) – Tabla XX4: Como realizar pruebas de Integraciones (Mensaje único)

Mensaje único = Sí

Rutina = rutina de integración (MATA010)

Mensagem = Nombre del mensaje único (ÍTEM)

Envia = Indica si el Protheus envía el mensaje único (antes de eliminar o después de incluir/modificar).

Recibe = Indica si el Protheus recibe el mensaje único.

Método = Sincrónica (Espera respuesta – Igual transacción) o Asíncrona (No espera respuesta – Otra transacción) del otro sistema.

Condición = Regla para cuando el Protheus enviará el mensaje único (SA2->A2_EST = ‘SP’), solamente proveedores del estado de SP que envían mensaje único.

Canal Envío = 2 – EAI - REST

XSD = Camino de los XSD si el cliente desea validar XSD con XML enviado/recibido

Versión envío = Versión del mensaje (WHOIS)

Alias = Alias de la tabla

Formato = XML

Modelos de mensajes sincrónicas y asíncronas 

 Las integraciones por Mensagería proponen dos modelos de envío y recepción de mensajes. El modelo Sincrónico y el Asíncrono.

Asíncronas:  En el modelo de mensajes Asíncronas el mensaje se envía y el sistema que envió espera el procesamiento del mensaje por el receptor.

Asíncronas:  Por otro lado, en el modelo Asíncrono el mensaje se envía y el sistema que la envió no espera su procesamiento. Posteriormente el mensaje se procesará en el receptor.

La tag InternalId, significa que esta es el identificador único para búsqueda en el sistema de donde se está enviando el XML.

Cuando dentro de la BusinessContent se tengan otros InternalId, significa que el mensaje tiene dependencia de otros mensajes.

-> ÍTEM

-> UNITOFMEASURE

-> WAREHOUSE

Mensaje único/ SOAP UI: Cómo realizar pruebas de Integraciones (Mensaje único)

Esta herramienta nos auxilia cuando es el Protheus que recibe el mensaje.

En “File -> New SOAP Project” informe el camino del servicio EAISERVICE

<![CDATA[

"cola o xml aqui""

]]> 

En “File -> Import Project” importe el archivo con los mensajes ya grabados.

XX0 - Registro de agents (Schedule)

XX1 - Programación de agenda (Schedule)

XX2 - Programación de agenda vs. Empresa/Sucursal (Schedule)

XX3 - Transacciones EAI

XX4 - Adapter EAI

XX5 - Relación de uso de rutinas/módulos

XX6 - Catálogo de personalizaciones

XX7 - Ítems do catálogo de personalizaciones

XX8 - Configuración de empresas

XX9 - Ítems de configuración de empresas

XXF - De/A EAI

XXD - De-A de Empresas del EAI

Simulación de integración de Pedido de Compras (MENSAJE ORDER):

XML Ejemplo:

Pedido de Compras.xml

 XX4 – Adapter EAI

OBS: Registre el UserInternalId como comprador

Es necesario que el Adapter este habilitado:

• MATA120 (Pedido de compras):

• MATA010 (Registro de producto):

• AGRA045 (Lugar de stock):

• PMSA200 (Proyecto):

• PMSA203 (Tareas del proyecto):

 XXF – De/A EAI

 Proveedor

FORNECEDOR

<CustomerInternalId>17|01;F000213</CustomerInternalId>

 Condición de pago

<PaymentConditionInternalId>17|002</PaymentConditionInternalId>

 Moneda contable

<CurrencyId>R$</CurrencyId>

 Producto

<ItemInternalId>17|15724</ItemInternalId>

 Unidad de medida

<UnitOfMeasureInternalId>M2</UnitOfMeasureInternalId>

 Lugar de stock

<WarehouseInternalId>17|1|0000017</WarehouseInternalId>

 Centro de costo

<CostCenterInternalId>1F8ADAFE-F805-4FC6-9A0C-0E9147C5B898</CostCenterInternalId>

 Producto

<ItemInternalId>1EDB480E-3A91-42EA-98B5-2DFB1BE5D4A4</ItemInternalId>

 Lugar de stock

<WarehouseInternalId>86FF78DB-64CE-4575-8711-359B573D13F7</WarehouseInternalId>

 Proyecto

<ProjectInternalId>1|75</ProjectInternalId>

 Centro de costo

<CostCenterInternalId>C00160C9-CE4A-4E7E-BD3D-5490C7CD0902</CostCenterInternalId>

Obs:

En este ejemplo del XML en que las informaciones del Centro de Costo están en el XML en la tag "<ListOfApportionOrderItem>" el Centro de Costo se importará en el Pedido de Compras en la pantalla de Prorrateo del Centro de Costos (tabla SCH):

Verificando con el Equipo del Producto, en el programa MATI120 del Compras del Protheus, que recibe el XML del RM, en este ejemplo del XML, cuando recibe la información, se utilizará la tag "<CostCenterInternalId>" dentro de la "<ListOfApportionOrderItem>" el estándar es que esta sea importada para la pantalla de prorrateo (tabla SCH). Aunque sea 1 o más centro de costo.

Para que el Protheus reciba  información del Centro de Costo en el ítem del Pedido en la SC7 las informaciones de este, deben estar contenidos en la tag "<CostCenterInternalId>" dentro de la "<Ítem>" del archivo XML directamente.

Si se tuviera la tag dentro del "Ítem" y también dentro del "ListOfApportationOrderItem", lo que prevalecerá será lo que esta dentro del "ListOfApportationOrderItem".

 Producto

<ItemInternalId>1EDB480E-3A91-42EA-98B5-2DFB1BE5D4A4</ItemInternalId>

 Lugar de stock

<WarehouseInternalId>86FF78DB-64CE-4575-8711-359B573D13F7</WarehouseInternalId>

 Proyecto

<ProjectInternalId>1|75</ProjectInternalId>

 Centro de costo

<CostCenterInternalId>C00160C9-CE4A-4E7E-BD3D-5490C7CD0902</CostCenterInternalId>

Obs:

En este ejemplo del XML, en que las informaciones del Centro de Costo están en el XML en la tag "<ListOfApportionOrderItem>" el Centro de Costo se importará en el Pedido de Compras en la pantalla de prorrateo del Centro de Costos (tabla SCH):

Verificando con el Equipo del Producto, en el programa MATI120 del Compras del Protheus, que recibe el XML del RM, en este ejemplo del XML, cuando recibe la información, se utilizará la tag "<CostCenterInternalId>" dentro de la "<ListOfApportionOrderItem>" el estándar es que esta sea importada para la pantalla de prorrateo (tabla SCH). Aunque sea 1 o más centros de costo.

Para que el Protheus reciba  información del Centro de Costo en el ítem del Pedido en la SC7 las informaciones de este, deben estar contenidos en la tag "<CostCenterInternalId>" dentro de la "<Ítem>" del archivo XML directamente.

Si se tuviera la tag dentro del "Ítem" y también dentro del "ListOfApportationOrderItem", lo que prevalecerá será lo que esta dentro del "ListOfApportationOrderItem".

 Proyectos

<ProjectInternalId>17|9</ProjectInternalId>

 Tarea del proyecto

<TaskInternalId>17|9|185|0|0</TaskInternalId>

 Estructura del proyecto

<SubProjectInternalId>17|9|185|0|0</SubProjectInternalId>

Simulación de integración de solicitud de compras (MENSAJE REQUEST):

XML Ejemplo:

Solicitação de Compras.xml