Some time back, an interesting article was released on SDN titled – How to Set Up the Communication between ABAP Back-end and SOAP Adapter using XI Protocol.
From PI 7.1 EHP1, we have the XI protocol as part of the SOAP adapter and hence now it is possible to connect to the ABAP back-end using the AAE/Integrated Configuration.
Note: IDoc are not supported for AAE communication. In case of designing your scenarios, you would have to base it on ABAP proxies. Else, alternative would be to go for RFC calls.
I have used the new feature in a couple of scenarios and following is my thoughts around it;
1. A well thought feature. Before EHP1, majority of scenarios except for communication with the ABAP back-end was left out. With the XI protocol, you can now use proxies to connect to ECC.
2. Performance – AAE definitely gives you a good performance – I guess there is no doubt around that 🙂
1. Can only use proxies (IDocs are not supported. RFCs are supported by default)
2. Additional settings – Sender ECC scenarios requires some additional configuration SXMSIF and SXMB_ADM. Hence during moving to different environments, these have to be configured separately in ECC (Does SAP provide a report to take these settings as a transport?)
3. Potential issues in Synchronous scenarios – It was observed that while configuring sync scenarios with ECC as the sender system, while initiating parallel calls. Only one call was successful while others failed. I gather this might be a bug. (Did spend a lot of time around this troubleshooting but couldn’t find an explanation) – Find a thread discussion on this <SAP:Code area=”PARSING”>GENERAL</SAP:Code> – Error
In summary, I think this is an excellent feature and guess SAP is providing this as a temporary option. Soon most of the adapters would be moved to the JAVA stack and these communications would be more easier. The SOAP adapter using XI protocol, the way it is being configured might be subjected to changes (you can find some hints around this in the article) .
From a design front, try to stick with async scenarios but before that, do confirm if sync scenarios work fine for you (maybe it was after all some issue at my end that I ran into failures on the parallel calls)
All in all, much appreciated feature that you can ‘definitely’ consider while designing scenarios which are SLA driven and heavily depend on performance and response times.