Overview
The blog deals with new architectural models introduced by SAP Process Integration that will be enhanced with the introduction of SAP PI 7.3 release. It additionally describes a mandatory architectural approach chosen for handling a scenario over PI, where real-time messages have been processed according to strict time constraints.
Reading SAP document PI Federation–An Overview, it is possible to have a clear overview about number of landscape deployment solutions which can be categorized as central, distributed or federated. It describes advantages and disadvantages for each model helping to choose the best trade-off between Expansion and Consolidation. Considering new PI 7.3 release features, less hardware requirements due to a single engine, a faster setup process and AEX features, probably in the next years, more and more PI architecture models will forward Horizontal scaling, working with additional PI Instances (Federation) or additional PI Decentral Adapter Engines (Distribution) rather then Vertical scaling, mainly involving Hardware specifications (Ram, CPUs, Application Servers).
Scenario
At the end of my blog Handling Low Latency Scenarios with PI it is mentioned a real case scenario where is mandatory to adopt a different architectural model from the central one to handle real-time scenarios. Shortly, the scenario handled messages exchanged by SAP and a Java controller for pallet movement with low latency and strict time frame message delivering. The problem stated while performing stress test was that running heavy load scenarios on PI (e.g. Master Data distribution scenarios) had a significant impact on real-time scenario. The result was that real-time scenario could not run together on the same Runtime environment where also master data and other flows have been running. For having a clearer picture of the problem, imagine a typical master data scenario (e.g. MATMAS) where Idocs sent from R/3 with EOIO QoS, must be forwarded towards two SAP systems after a message mappings phase and to other legacy systems (via FTP) as well. If you run 5000 or more Idocs in the same time, I bet average delivery time of overall PI messages is increasing significantly despite of the hardware you are working on.
Solution
The architecture model to treat with described performance limitation should at first provide and guarantee flow Segregation and Isolation; Indeed, this is the main reason I followed Decentral Adapter Engine setup. The idea is that real-time flows running of Decentral Adapter Engine are never affected by central instance load or by any maintenance activity done on central instance. In order to achieve this good result there was the need to follow a non standard Decentral Adapter Engine setup.
I mean that, after the initial Decentral Adapter Engine setup and performing stress test I stated improvements in performance; on the other hand just analyzing Wily introscope charts I discovered that User Management response time was quite bad even if the real-time scenario worked on Decentral Adapter engine and MATMAS on central one.
Later I found out there is the chance to decouple User Management of Integration Server and Decentral Adapter Engine to let them work independently. In this way, Decentral Adapter Engine should work also in case the Integration Server is not available. During the Setup phase of Decentral Adapter Engine (later is not possible!) you can chose to work on Local User Management (UME) as clearly described into How-to guide How To Install and Configure a Non-Central Advanced Adapter Engine with Local User Management. In this way, users for SOAP authentication together with system users are stored into Java database for a faster logon check at runtime.
Result
After installing Decentral Adapter Engine with Local UME and performing a stress test, the final data have been compared getting great results. But if both central instance and Decentral Adapter Engine are hosted in the same hardware there is a small effect in the overall performance so as final tip I suggest to install them on separate host.
Pictures below show the Processing time for real-time scenario working on Decentral Adapter Engine with local UME and a turnaround time measurement done on application side for a couple of messages (188 ms).
Next Steps
Finally, I want to share picture showing differences between actual and new SAP PI 7.3 release concerning components:
It seems Advanced Adapter Engine Extended (AEX) will be also available as Stand-Alone version or with Decentral Adapter Engine (planned from 7.30 SP2) offering a total independent Design and Runtime environment or only a total independent Runtime environment despite the central instance model. I am also interested to see if the new release provides a faster delivery time or implements an improved priority queue mechanism to dispatch messages with higher priority.
That’s all, I hope this helps you.
2 Comments
