In today’s PO landscape with single stack AEX systems, it is common to have one central and multiple decentral systems to have better load balancing between the servers.
In this situation, if we have a value mapping maintained in the runtime cache which we are populating using the ValueMappingReplication program provided by SAP, the problem is that the value mapping can only be executed on one of the central or decentral engines at a time. Or, we need to maintain multiple ICOs, one for each of the central and decentral engines and the data needs to be triggered multiple times from the source system, to each of these ICOs. This is due to the fact that an ICO can only exist on one AEX and we cannot have the sender and receiver channels residing on different adapter engines.
However, an ingenious solution to this, as we found, was to have only a single ICO, with multiple receivers, one for each of the adapter engines, but still maintained on the central adapter engine.
For a step-by-step example for how to create a valueMapping scenario, please refer the below blog by Marco Salazar.
For my scenario, I will only concentrate on the receiver part of the configuration.
Scenario :
A valueMapping is maintained on the PO runtime cache and triggerd from ECC using outbound proxy
We have a central AEX system and a decentral adapter engine for load balancing. The ICO is of course maintained on the central adapter engine.
Before moving to the ICO creation, maintain two HTTP destinations on the central AEX system, one pointing to the central AEX JPR and the other to the JPR of the decentral engine.
HTTP destination pointing to central JPR
HTTP destination pointing to decentral JPR
As mentioned earlier, both of these are created on the NWA of the central AEX.
Now to the ID configuration. For the two business systems for the central and decentral adapter engines, maintain two SOAP receiver channels, again on the central adapter engine.
For the SOAP channel for the central adapter engine, maintain the HTTP destination created earlier for the central instance.
Similar channel for the decentral engine.
Now, in the ICO, maintain two receivers for the two business systems for the central and decentral engines and use the receiver channels created earlier.
Since all the channels are maintained on the central instance, there is no issue in creating the ICO with the two receivers.
Now we are ready to test. If a message is triggered from the source, in the message monitoring for the central instance, we will see a message branch, for the two receivers.
In the decentral engine message monitoring, you can see the message has successfully triggered the valuemap replication program.
