SOA is a modern strategy for building software systems. It can be quite useful for supporting basic design decisions in PI projects. Please note, that this introduction in not a complete demonstration about SOA, than using some SOA principles in PI integration environments with hundreds or thousands of connected systems.
SOA is going to be the dominating paradigma of software design. Reuse and flexible combination of modules can reduce costs significantly. Business Processes can be adapted quickly by less effort and small costs. The enterprices will have therefore a encreased agility and encrease their competence to use offered chances.
The approach for reuse is dominating the design by chaining service calls instead of changing application programs for each new or changed business process.
Reuse of Loose Coupled Objects
PI provides an excellent choice of possibilies for reuse. All objects in Repository and Directory are “modular”, they are just maintainable linked together and there are only a few cases, where reuse is a bit difficult. This special cases will be later discussed. For an optimal reuse systems, interfaces and routing objects have to be loose coupled, they should work complete undependend. In the view of PI Data Type, Message Type, Message Interfaces and other Repository objects can be exchanged with the lowest effort. In case of mass system integration routing objects are concerned to be created in a most reuseable way. In a 3 system environment one routing object too much doesn’t matter, but certainly a senseless development of thousants of routing objects should be avoided. A good reuse strategy costs in the beginning some develop time, but the more systems are connected the more time and money can be saved.
Flexibility / Maintainability
The maintainability is allways an important task during software development. There are some basic principles which support an acceptable maintainability: global documentation strategy, considerd naming conventions, simple solutions, standard implementations. That strategies are comprehensive but for mass system integration there are some particular points: The number of routing objects has to be low as possible. The need for changing thousands of routing objects if just one interface has changed cant be accepted. The problem is that objects are ususally routed by their signature, which include both interface and system, that there are routing objects for each combination of interface and service. For environments with great numbers of interfaces and systems the number of routing objecsts would increase too much so that any maintenance would be hindered.
Flexibility / Scalability
Mostly mass systems are not integrated at once, a typical Go Life affects just a few systems to be able to react on possible errors. In result there is a roll out time in which often unexperienced persons have to add the necessary adjustments. Any develop strategy before has to consider that and to add an addition system must be as easy as possible. Changing or creating hundreds of routing objects for one roll out cant be preferable. A endless failure chain would be the result.
Configuration of a Mass System Integration: Mass of 3rd Party Systems sending to different clients
We assume a scenario where a lot 3rd party systems are sending serveral messages (different business cases). The receiving SAP clients can be determined by a part of the message itself.
The approach of this survey is to reduce the number of objects at IB Directory as much as possible to get a maintainable configuration. If we had for example 100 sending systems with 15 different interfaces (business cases) we would need to create 100 x 15 = 1500 Receiver Determinations. Any change or new rollouts would be very time consuming and error-prone.
Sending Business Systems
A great number of Business Systems could lead to a not acceptable number of channels and sender agreements. Even if there are physically different senders (different URLs) nevertheless from PI view they could be collected to just one system. The most serious disadvantage would be the reduced quality of PI monitoring where a certain sender cant be selected any longer directly. A way would be to select by the receiver system.
Usually one channel per sender and business case (Interface) is required. Some channels allow to send different data with only one channel, for example could a file adapter poll to serveral folders and pick up different data. This would be possible in case of direct processing (no conversion) or if the logic of conversion is the same for different messages. The hardest disadvantage is the use of the same Outbound Inteface and therefore a
- worse monitoring: Selection by Outbound Interface is not possible, but by Inbound Interface
- required X-Path condition for the Inbound Interface at Interface Determination
- exclude of Message Mapping (XSLT, Java or ABAP can be used)
For our example we create one channel for each Business Case, but we use only one sending Business System.
One per sending Channels is required.
For the sending Business System a joker (*) should be used, as well for the receiver.
The Receiver Determination cant be created in that generic matter as the receiver need to be configured here. The receiving business system should be given by an Enhanced Receiver Determination
For synchronous scenarios Jin Shins blog SAP NetWeaver Process Integration: SAP NetWeaver Process Integration: Enhanced Receiver Determination for Synchronous Scenariosshows a solution. In case of expectable high frequency (load) synchronous design can lead to performance bottlenecks.
The receivers theirselfes shouldn’t be part of the mapping program as in case of change or new receivers the mapping program needed to be changed. Therefore the receivers should be stored in an external table. A SAP table at the ECC system would be the best approach to provide an usual way and have controll of access (restricted authorization on SM30).
Alternatively the Receivers can be fetched via lookup: SAP PI 7.1 Mapping Enhancements Series: Graphical Support for JDBC and RFC Lookups
Receiver Business Systems
For each SAP client a Receiver Business System is required.
Receiver Communication Channel
For each SAP client and Adapter type (RFC, IDoc or XI) at least one Channel is mandatory.
For each SAP Receiver Channel only one Receiver Agreement is required.
- For XI (proxy) Channel the joker * can be used for Interface and Namespace. So this Channel will be used as standard except there is no other Agreement where that fields are maintained with real values.
- For IDoc Channel the joker can be used for Inteface, but the Namespace will get the standard value urn:sap-com:document:sap:idoc:messages
- The same trick is used for a generic RFC Channel: joker * for Interface and standard rfc namespace urn:sap-com:document:sap:rfc:functions for the field Namespace
Suppose only one (virtual) Sender Business System is used for a mass of real senders (URLs). The structuring of routing objects needs to support easy extensions and further roll outs. Therefore two main folders should be created:
a. Folder Business Cases:
Including a scenario for each Outbound Interface. This scenario should contain:
- Sender Business System (reuse)
- Sender Channel
- Sender Agreement
- Interface Determination
- Receiver Determination referring a reusable program
For new Interfaces a new PI scenario is to be created. The effort at the 3rd party system, at the SAP system and in the Enterprise Service Builder would be like in a “normal” environment.
b. Folder Systems:
Including a scenario for each Receiver Business System (SAP client):
- Receiver Business System
- Receiver Business Channel
- Generic Receiver Agreement
For each Roll Out a new scenario is to be created. Additional a new entry in the receivers table has to be included. Of course a new SAP client has to be setup and a corresponding SLD entry (Business System).
Creating the Integration Builder Directory objects in a normal, “standard” manner for this mass system integration would lead to a nearly not any longer maintainable scenario. Hundreds of objects would be needed to change by adding a new interface or a new system. With the “uncoppled” design a new interface (Business Case) can be added within half an hour, the bigger effort would be to write a new mapping program (at Enterprise Service Builder). Adding a new system is as well done within a few minutes (including new SLD entries). The scenario is optimal maintainable and extensible; even a not experienced person could do that – the correspondign documentation would embrace just one side.