8. Parametrizaciones Middleware

Vista en b+SII:

En este punto se va a explicar las parametrizaciones Middleware que se deben hacer para la comunicación con la AEAT. Se tratan dos apartados: Parametrización Middleware en la tabla de SAP y las equivalencias entre los estados que devuelve el Middleware tras procesar eDocuments.

Parametrización MW en SII

En el apartado 8.1 se detallan los campos a informar para la parametrización con el Middleware.

Se han creado tres tipos de comunicación con la AEAT: Comunicación por PI asíncrona, comunicación Cloud por FUSE asíncrona y comunicación Cloud PT (pasarela) por FUSE síncrona.

Estas tres comunicaciones (clases) parten de una interfaz común: /EDGE/IF_SII_COMUNICACION_AEAT. Esta interfaz se compone de 5 métodos:

Comunicación por PI

Para este tipo de comunicación se provee por defecto la clase /EDGE/CL_SII_COM_AEAT_PI. En el caso de que se trabaje con la versión 7.10 de la solución b+ SII PI se deberá parametrizar la clase /EDGE/CL_SII_COM_AEAT_PI_710.

Con esta comunicación, PI facilita la herramienta sproxy que agiliza la creación del Web Service por el cual se establece la comunicación con el Middleware.

Comunicación Cloud asíncrona

Para este tipo de comunicación, se provee por defecto la clase /EDGE/CL_SII_COM_AEAT_CLOUD_AS. Con esta comunicación es necesario configurar el Proxy para consumir el Web Service. Esta configuración tiene que ser configurada por el implantador de FUSE y ABAP donde el cliente tiene que informar del endPoint y el puerto.

Para ello se accede a la transacción correspondiente de SOAMANAGER y se configura el EndPoint del Proxy.

El servicio para el que hay que configurar el endpoint es el /EDGE/CO_SII_CLAPROCESAR_LOTE1.

Se crea el puerto lógico:

Finalmente, se añaden las configuraciones necesarias:

Usuario y contraseña de cloud (a facilitar por el implantador de Cloud),

(Importante: Marcarlo como puerto por defecto).

(Importante: Seleccionar la opción "Supress ID Transfer").

(Importante: Normalmente se utiliza protocolo HTTPS para comunicación con FUSE).

(Importante: En el servicio asíncrono debemos cambiar la configuración de la pestaña "Transport Settings". En la URL de acceso tenemos que poner: /entrada_fuse/services/ProcesarLoteSII).

Equivalencia entre estados MW y eDoc

Se trata en el apartado 8.2.

RFCs

Se han creado dos RFCs capaces de tratar los mensajes de la AEAT recibidos a través del Middleware. Se ha elegido utilizar RFCs porque son invocables desde cualquier punto de un sistema SAP con conexión RFC o del propio sistema en el que se encuentran y porque se pueden implementar Servicios Web en base a ellas. Las RFCs que se utilizan son:

• /EDGE/SII_ESTADO_LOTE_MW: creado como RFC, se utilizará para cambiar el estado de un lote en el contexto del funcionamiento de sus comunicaciones, para ello recuperará el estado Middleware y lo asociará al proceso eDocument, comunicando el proceso de paso al lote. Posteriormente recuperará y actualizará el contenido de la tabla /EDGE/SII_GUIDPI. En caso de que se esté registrando un error y de que se haya superado el número de errores parametrizado se disparará una alarma mediante la BAdI /EDGE/BADI_SII_ALERTAS. Por último en caso de que se haya recibido un fichero además de la información de cambio de estado pertinente se anexará dicho fichero al lote.

• /EDGE/SII_RESPUESTA_AEAT: creado como RFC, se utilizará para recibir y tratar la respuesta de la AEAT a un lote. En función del  parámetro IV_ESTADO_LOTE_AEAT  con el estado de la respuesta se aceptarán, aceptarán con errores o rechazarán los lotes mediante llamadas a métodos estáticos de la clase /EDGE/CL_EDOC_SII. 

La gestión de la respuesta desde el middleware se gestiona a través de dos servicios creados en base a estas RFCs arriba indicadas (se suministran en el propio add on y son válidos tanto para el caso CLOUD síncrono como para el caso CLOUD asíncrono). Los nombres de estos dos servicios son los siguientes:

• /EDGE/SII_RESPUESTA_AEAT         Servicio Web respuesta AEAT
• /EDGE/SII_ACT_ESTADO_LOTE      Servicio Web actualización estado lote
  
  

Por lo tanto, ya no es necesario configurar servicios asociados a estas RFCs para que estén disponibles a la hora de recibir las respuestas de la AEAT que gestiona el Middleware. Tan solo habrá que configurar el endpoint de los mismos a nivel de proyecto. La forma de hacer esto es  a través de la transacción SOAMANAGER. Se ha de seguir el siguiente procedimiento:

Por defecto, se presuponen las características que se indican a continuación para los Web Services (HTTP, usuario/password). Otras características diferentes han de explorarse en cada implantación de forma específica (HTTPS, etc.).

Una vez se tienen los dos endpoints para los dos Webservices, se selecciona el enlace "Open WSDL document for selected binding" para cada uno de ellos, para acceder al fichero WSDL y obtener en una de las últimas líneas del mismo el acceso al servicio creado.

El usuario de comunicación que se utilice para estos dos servicios debe tener ciertos permisos. El usuario en SAP debe tener asignado el rol SAP_XI_APPL_SERV_USER o otro rol con los objetos de autorización que este contiene. Por otro lado el usuario también debe tener el objeto de autorización  S_SERVICE con estos dos servicios:

Se debe marcar SERVICE_TYPE con 'WS' y en el nombre de SERVICE.

Finalmente, el usuario debe tener el objeto de autorización ZESI_ADM (administrador del SII) o en su defecto, ZESI_RFC, que es el objeto de autorización para poder acceder a las dos RFCs asociadas a los servicios de respuesta.