...
En el apartado 8.1 se detallan los campos a informar para la parametrización con el Middleware.
Se han creado 3 tres tipos de comunicación con la AEAT: Comunicación por PI asíncrona, comunicación Cloud por Fuse FUSE asíncrona(TO_DO) y comunicación Cloud PT (pasarela) por Fuse 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:
| Método | Descripción |
|---|---|
ENVIO | Envío de los parámetros necesarios sobre el Lote o Lotes que se generan y envían para comunicarse con la AEAT al Middleware. |
| INT_ENVIO | Interrumpir envío. Este método se utiliza para las comunicaciones asíncronas cuando el Middleware ha devuelto un error técnico. Si se desea descartar el lote, primero debemos interrumpir el envío para que no haya una inconsistencia entre los estados de los eDocuments. Cuando se realiza el envío, el Middleware por su cuenta intenta el envío tantas veces como se haya parametrizado. Si inicialmente ha llegado un error técnico, y queremos descartar el lote, si no ejecutamos antes la interrupción puede ser que en uno de los tantos intentos del Middleware alguno sea éxito y llegue este estado al monitor cuando nosotros hemos decidido descartar lote sin interrumpir el envío antes, lo que causaría una inconsistencia. |
| DESCARTAR_LOTE | Este método sólo se utiliza en las comunicaciones asíncronas. Cuando se ha producido un error a nivel de Middleware y se desea descartar el lote se debe informar al sistema Middleware de dicho descarte para que el estado de este lote sea consistente en todos los sistemas de la arquitectura. |
| INT_ENVIO_DESCARTAR_LOTE | Interrumpir envío y descartar lote. Es una suma de los dos métodos anteriores. |
| REENVIO | En las comunicaciones asíncronas este método se utiliza para forzar el reenvío cuando ha habido un error técnico. |
Comunicación por PI
Para este tipo de comunicación se provee por defecto la clase /EDGE/CL_SII_COM_AEAT_PI.
Con esta comunicación, PI facilita la herramienta sproxy que agiliza la creación del Web Service por el cual nos comunicamos se establece la comunicación con el Middleware.
Comunicación Cloud PT síncrona
Para este tipo de comunicación, se provee por defecto la clase /EDGE/CL_SII_COM_AEAT_CLOUD_PT. Con esta comunicación necesitamos es necesario configurar el Proxy para consumir el Web Service. Esta configuración tiene que ser configurada por el implantador de Fuse FUSE y Abap ABAP donde el cliente tiene que informar del EndPoint endPoint y el puerto.
Para ello vamos se accede a la transacción correspondiente de SOA Manager y configuramos se configura el EndPoint del Proxy.
Buscamos nuestro ProxySe selecciona el proxy: /EDGE/CO_SII_CLOUDPROCESAR_LOT
Creamos Se crea el puerto lógico:
Y añadimos Finalmente, se añaden las configuraciones necesarias:
Usuario y contraseña de cloud (a facilitar por el implantador de Cloud),
...
Una vez configurados ambos Web Services, debemos configurar debe configurarse un endpoint para cada uno de ellos a través de la transacción SOAMANAGER. Se indican los pasos para uno de los Web Services, el otro es análogo.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 que tenemos se tienen los dos Endpoints endpoints para los dos Webservices pulsamos , se selecciona el link 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.
...