Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos

Potentially Problem in Exactly-Once In Order Handling

In the current XI/PI version are EOIO handling in ABAP and J2EE lose coupled. There is no way to synchronize the processing for the EOIO between ABAP stack and J2EE stack. In most cases is it not necessary to synchronize it, since the ABAP stack deliver pipeline service and J2EE stack use Resource Adapter to deliver Payload to external Enterprise Information System (EIS). 

 

Nevertheless some batch oriented scenario and some rarely scenario could cause problem, in case of the delivered EOIO XI message has an impact on the content of the next XI message payload. In this case it is necessary to guarantee the End-to-End EOIO processing in the whole XI process chain.

 

For example, the mapping step within XI has to perform lookup on the external system to get some information, let’s say the package number. This retrieved package number has to be set in the XI message payload. After this XI message is delivered on the target system, the package number for the next XI message is changed. The mapping step is the only pipeline step which changes the XI Message Payload; other pipeline services only modify the XI header information. Since the EOIO can not be guarantee for the whole XI process chain, two XI message could get the same package number. After the first XI message successfully transferred to the J2EE stack, the next XI message in the EOIO queue will get processed, this could happen before the first one get really delivered from J2EE adapter to the target system.  

 

Possible Implementation

One possible solution will be using one Adapter Module. The idea is perform Lookup within Adapter Module and change the XI XML Message Payload within the Adapter module afterwards. The mapping step within ABAP should just prepare the message without a lookup on the target system. Because the EOIO in J2EE stack guarantee the order of XI Message processing, no lookup could be performed before the predecessor is really delivered on the target system.

 

Drawback of the implementation

The XI Lookup API is only released for the Mapping runtime, the lookup implementation within Module have to use other API or other services. For example, if the target System is a Database, one Datasource under JDBC Connection service has to be configured and J2EE API has to be made use of it. In case of SOAP or RFC lookup will require some more efforts to perform lookup.

 

Suggestion

The introduced solution require implementation and configuration, it is not a standard XI solution. There could be one easy way to implement it within XI. If the EOIO queue on the ABAP stack could be coupled with Java Stack, the described problem is obsolete. This could be implemented as form of an acknowledgement, if the XI message is successfully delivered on the target system in J2EE stack, one positive acknowledge will be send back to the ABAP stack, only in this case next message can get processed. Some similar implementation is already available within XI regarding acknowledgement, if one send step required an acknowledgement within BPE, the BPE will stop processing until one permanent acknowledgement arrived. Something similar like that could be able to implemented for End-to-End EOIO handling. It will be a great help, if this can be set as an option to configure EOIO queue on ABAP stack.

1 Comment