You’re implementing the “eDocument: Electronic Invoicing for Italy” solution having only one SCPI (HCI) tenant. You have read how to create a TEST copy of the eDocument package but it doesn’t suit your scenario since you registered at SdI indicating the same endpoint for test end production.
In this case, you can’t use the same iFlows for sending and receiving messages from and to SdI: once you’ve switched the parameter Mode to PROD in your iFlows, you stop sending messages to SdI test. When you receive notifications and invoices from SdI, they’re all stored into datastore distinguished by Fiscal Code, regardless of what SdI is calling.
This blog aims at showing how to easily build a custom middleware to put between the standard SCPI eDocument solution and the respective caller (either SAP backend or SdI).
eDocument for Italy solution implemented in accordance with SAP note 2583309.
Latest version of eDocument for Italy deployed (we use the 1.0.3).
If you registered the same endpoint at SdI for test and production, how do you know whether it is SdI TEST or SdI PROD calling your SCPI application? If you run your scenarios both using test and production environment, you might come across a case like this.
The main problem to overcome is allowing SCPI to understand who is calling. For that we need something doing the trick.
Add suffix “/PROD” to all the eDocument: Electronic Invoicing for Italy addresses (even to the process direct connections).
Example of Italy Receive Invoice reconfigured.
Copy the eDocument: Electronic Invoicing for Italy solution from Discovery in your SCPI, add the “TEST” suffix, then add suffix “/TEST” to all the addresses in there.
Example of Italy Receive Invoice (TEST) reconfigured.
Each eDocument iFlow (TEST and PROD) is reachable at an address: the addresses are collected in the below Value Mapping list. The list is accessed based on the respective iFlow name distinguished by the string “TEST” or “PROD”. Altogether we have 14 endpoints (7 for TEST and 7 for PROD).
The Value Mapping gets accessed via a groovy script shown in the next step.
Please notice I’m using the default endpoints, not those custom domain based. You can choose what to use.
The Router iFlow gathers all the addresses called both by SdI and by SAP.
Add SapAuthenticatedUserName among the allowed headers.
Example of Receive Invoice (ROUTER). SdI calls SCPI.
Handle SdI Message works as follows.
Groovy script to access Value Mapping.
To connect to SCPI itself, you could use either the user credentials (create one under Security Material) or a client certificate.
When is SAP that calls SCPI, the only difference is how SCPI recognizes the caller. Build a groovy script accordingly (for example you can get it from the payload, otherwise from the SOAP Header, you choose the option that suits your scenario).
The rest works exactly the same.
Let’s send and invoice from SAP TEST and another one from SAP PROD to SCPI. We expect to receive the two notifications into different datastores and retrieve them in the correct system.
Here some considerations on this solution.
Here some figures in respect to almost a thousand messages (no matter if it was a SendInvoice or a ReceiveNotification) passed through the custom router artifact (only the router, NOT router+<eDocIFlow>).