2.1.8. Middleware customizing

View in b+SII:

At this point we will explain the Middleware settings that must be made for communication with the AEAT. There are two sections: Parameterization Middleware in the SAP table and the equivalences between the states that the Middleware returns after processing eDocuments.

MW Parametrization in SII

Section 8.1 details the fields to be reported for the parameterization with the Middleware.

Three types of communication with the AEAT have been created: Asynchronous IP communication, Cloud communication by asynchronous FUSE and Cloud PT communication (gateway) by synchronous FUSE.

These three communications (classes) start from a common interface: /EDGE/IF_SII_COMUNICACION_AEAT. This interface consists of 5 methods:

Method	Description
SENDING	Sending the necessary parameters on the Lot or Lots that are generated and sent to communicate with the AEAT to the Middleware.
INT_SENDING	Interrupt send. This method is used for asynchronous communications when the Middleware has returned a technical error. If you want to discard the batch, we must first interrupt the submission so that there is no inconsistency between the states of the eDocuments. When sending, the Middleware on its own tries to send as many times as it has been parameterized. If initially a technical error has arrived, and we want to discard the batch, if we do not execute the interrupt before it may be that in one of the many attempts of the Middleware some success and arrive this state to the monitor when we have decided to discard lot without interrupting the shipment Before, which would cause an inconsistency.
DISCARD_BATCH	This method is only used in asynchronous communications. When a Middleware error has occurred and it is desired to discard the batch, the Middleware system must be informed of such disposal so that the status of this batch is consistent across all systems in the architecture.
INT_SENDING_DISCARD_BATCH	Interrupt send and discard batch. It is a sum of the two previous methods.
FORWARDING	In asynchronous communications this method is used to force forwarding when there has been a technical error.

PI Communication

For this type of communication, the class /EDGE/CL_SII_COM_AEAT_PI is provided by default. In case of working with version 7.10 of the solution b+ SII PI, the class /EDGE/ CL_SII_COM_AEAT_PI_710 must be parameterized.

With this communication, PI facilitates the sproxy tool that speeds up the creation of the Web Service by which communication with the Middleware is established.

Communication CLOUD asynchronous

For this type of communication, the class /EDGE/CL_SII_COM_AEAT_CLOUD_AS is provided by default. With this communication it is necessary to configure the proxy to consume the Web Service. This configuration has to be configured by the FUSE and ABAP implementer where the client has to report the endpoint and port.

To do this, access the corresponding SOAMANAGER transaction and configure the EndPoint of the proxy.

The service for which the endpoint must be configured is /EDGE/CO_SII_CLAPROCESAR_LOTE1.

Logical port is created:

Finally, the necessary configurations are added:

Cloud user and password (to be facilitated by the Cloud deployer),

(Important: Mark it as the default port.)

(Important: Select the "Supress ID Transfer").

(Important: Usually HTTPS protocol is used for communication with FUSE).

(Important:In the asynchronous service we must change the settings of the "Transport Settings" tab. In the access URL we have to enter: /entrada_fuse/services/ProcesarLoteSII).

Equivalence between MW and eDoc states

This is discussed in section 8.2.

RFCs

Two RFCs capable of handling the AEAT messages received through the Middleware have been created. It has been chosen to use RFCs because they are invocable from any point in a SAP system with RFC connection or the system itself in which they are and because Web Services can be implemented based on them. The RFCs used are:

/EDGE/SII_ESTADO_LOTE_MW: Created as RFC, will be used to change the status of a batch in the context of the operation of its communications, for it will retrieve the Middleware state and associate it with the eDocument process, communicating the process of going to the batch. It will then retrieve and update the contents of the table /EDGE/SII_GUIDPI. If an error is being registered and the parameter number has been exceeded, an alarm will be triggered by the BAdI /EDGE/BADI_SII_ALERTAS. Finally, if a file has been received in addition to the pertinent status change information, the file will be appended to the batch.
/EDGE/SII_RESPUESTA_AEAT: Created as RFC, it will be used to receive and process the AEAT response to a batch. Depending on the parameter IV_ESTADO_LOTE_AEAT with the status of the response will accept, accept with errors or reject the batches by calling static methods of the class /EDGE/CL_EDOC_SII.

The management of the response from the middleware is managed through two services created on the basis of these RFCs indicated above (they are supplied in the add on itself and are valid for both the synchronous CLOUD case and the asynchronous CLOUD case). The names of these two services are as follows:

/EDGE/SII_RESPUESTA_AEAT AEAT Web Sevice
/EDGE/SII_ACT_ESTADO_LOTE Update Batch Status Web service

Therefore, it is no longer necessary to configure services associated with these RFCs to be available when receiving responses from the AEAT that manages the Middleware. Just have to configure the endpoint of the same at the project level. The way to do this is through the SOAMANAGER transaction. The following procedure must be followed:

By default, the following features are assumed for Web Services (HTTP, user / password). Other different characteristics have to be explored in each specific implementation (HTTPS, etc.).

Once you have the two endpoints for the two Webservices, select the link "Open WSDL document for selected binding" for each of them, to access the WSDL file and obtain in one of the last lines of the same the access to the created service .

The communication user that is used for these two services must have certain permissions. The user in SAP must have assigned the role SAP_XI_APPL_SERV_USER or another role with the authorization objects that it contains. On the other hand, the user must also have the authorization object S_SERVICE with these two services:

Finally, the user must have the authorization object ZESI_ADM (administrator of the SII) or, failing that, ZESI_RFC, which is the object of authorization to be able to access the two RFCs associated with the response services.