Your form has been successfully submitted.
SAP offers a newer and enriched version of the Process Integration (PI) Middleware: Process Orchestration (PO). Nonetheless, a vast customer base is still using SAP PI.
This middleware, connecting different systems and services, is often considered as a black box not to be touched, due to several reasons.
For example, there might be some resistance to change the environment, after all, it is pretty critical to the different business processes running over PI! Customer reasoning might be not to change the working middleware integration platform (if it ain't broke, don't fix it!). Another reason might be the lack of expertise at hand. Maybe the initial set-up of a PI system was done quite some time ago by an external provider. The fear of the ‘unknown’ is probably not a motivation for putting modernization and simplification of the integration processes on the agenda.
And yet, it might be very worthwhile to take into account the different solutions and scenarios within SAP’s product portfolio to bring back control of the customer environment. Whether you want to prepare for the next generation Middleware solutions, simplify data mappings, give better insight in the data traffic in the middleware application or question whether the current middleware solution in place is best suited for the integration of cloud, Emeritis will come to the rescue. With this short series of blogs, we will shed a light on some alternatives and hopefully answer all your questions. (If not, please do give us a call!).
In common middleware integration processes, data mapping is a necessary step. Although SAP PI offers this functionality, choosing the right approach to set up these mappings may not be easy. First of all, the data mapping & conversion in PI can be configured in a graphical interface. This is excellent and very transparent for some very simple data mappings and conversions but might become ‘unreadable’ when it becomes more complex.
An alternative could be not to use the graphical interface but to use PI’s ABAP stack for programming the logic in a less visual but more flexible way. This may not be the most future proof method! For instance the PI’s successor PO does not have an ABAP stack anymore. Migrating PI to PO might require some redesign and urge for some alternatives to be used.
Single field mappings are quite easy for configuring, but when a target value needs to be determined by combining the values of two fields together (as we’ve seen in HCM integration contexts for Action & Action Reason mappings or for Personnel Area & Personnel Subarea combinations), a more creative solution could be used. For example designing mapping tables (ABAP stack) in PI for determining the target values or the mapping could be configured on an SAP back-end system being called at run time in the PI message processing.
All of this brings some complexity in the solution design, making PI less independent of other systems when it comes to processing messages – a failed message might no longer be processed by PI if the back end system can’t be reached, performance could be lower due to RFC’s being called, etc …
In our next blog post on 'SAP middleware' we talk about how to make mappings and conversions more transparent and ready for migration to PO. Enjoy the read!
January 9 2020
Infrabel jumps on the employee experience train
Infrabel puts employee experience high on their agenda. With ‘My Talents’ they’ve introduced a brand new approach to support the personal growth of their employees. Infrabel is changing on a...read more
January 9 2020
Etex Talent: the road to 2020
2020 is here! Over the past years, the team at Etex has been working hard to reach their transformation goals for 2020. With about 15,000 employees working at 113 production sites in 42 count...read more