I’ve recently run into the challenge of managing a really bulky message (over 25 Mb!) in SAP XI, where both source and target are flat structures. So I wondered: why going through the overhead of memory consuming XML conversion? Can I get rid of it in this case? Sure I can!

Benchmark

At the beginning of May 2006 (after writing this blog) I had chance to benchmark this approach, compared to the classic one (IDoc XML – graphical mapping – JMS conversion from XML to flat). Here are the astonishing results. I won’t unveil XI box’s sizing here, as I don’t consider it very interesting. The only thing I’ll say is that both tests were made on the same machine, with the same load conditions. Test data: 60 messages of 4 Mb each (flat size), "dropped in" XI almost simultaneously. Processing: pure XI (adapters, routing, mapping) Results: – classical method: between 45 and 50 minutes – this method: 3 minutes

Introduction

The process I am about to describe here could seem a kind of XI nature negation, but I tend to consider it rather another possibility to achieve a goal. Well, you may be asking yourself, what is this goal? It’ easier said than done. I have an IDoc going out of SAP R/3 that must be mapped against a flat target structure (yeah, the good old classic one with a 4 bytes record type at the beginning), which has to be sent to an MQ queue through JMS Adapter. Unfortunately this IDoc is bulky: its size can easily reach 25 Mb, if weighed flat (imagine when converted into XML!). We all know that managing this kind of message in XI with a mapping that takes place in the J2EE stack (be that graphical, Java or XSLT) can be dangerous, and make our XI box sit down and have coffee&cigarette… 😉

Flow

So I first investigated the IDoc tunneling technique (also described in this Michal’s weblog), sadly realizing that it’s only possible when both sender and receiver are SAP systems exchanging the same IDoc with no mapping at all. Then the weird solution came up to my mind:

R/3 system dumps the IDoc with a file port (in place of the canonical tRfc port) in flat format

XI reads the flat IDoc with a sender file adapter with no content conversion

data are mapped with an ABAP mapping, thus avoiding any unnecessary JCo data flow between the two stacks

a receiver JMS adapter writes data to the queue with no content conversion

Assumptions

I assume you are familiar enough with WE20 (Partner Profiles) and WE21 (Port definition) in SAP R/3, so I won’t go into the details of it. I also assume you’re able to configure both communication channels (file sender and JMS receiver), as it should also be easier than ever, considering my technique allows to cut short with them (remember: no content conversion). The only thing that needs to be mentioned is probably how to enable ABAP mapping (which comes disabled in a brand new XI installation): you need to change something in the Exhange Profile and reboot your J2EE stack. For this purpose refer to SAP documentation.

Realization

Before drawning into ABAP code, another general concept. You may be wondering where and how I have designed source and target structures… Well, for what concerns IDoc, I create them dinamically by reading XI definition of it, while for legacy target structures it’s up to you, but I decided to define ABAP dictionary structures with SE11 trx (you can also have them in an ABAP include as I did for IDoc, see below). First step is to create an ABAP mapping class, which must implement the standard interface IF_MAPPING (see this documentation chapter for details). For details about ho to create ABAP package, change request and so on, please refer to SAP documentation or have a look at this weblog o’ mine, where this steps are given full details. Here below is a simplified version of my own ABAP mapping, hopefully commented enough to be self-explanatory.

THE ABAP MAPPING CODE HERE

————————————————————————————————————————————

******************************************************************* ******************************************************************* * Very important prerequisite: for ZGUA_IDOCSTR_GENERATE_INCL to * work correctly, if IDoc was changed in the backend, * it must be manually deleted (and optionally regenerated) in IDX2. * No automatic refresh is performed by XI in this case because no * IDoc adapter is actually involved. ******************************************************************* *******************************************************************

* Get the control record READ TABLE theidoc INTO edidc INDEX 1. DELETE theidoc INDEX 1. * Check if include with IDoc segments structure has to be regenerated before including it SUBMIT ZGUA_idocstr_generate_incl WITH idoctyp = edidc-idoctyp WITH cimtyp = edidc-cimtyp WITH port = edidc-sndpor AND RETURN.

Conclusion

You may find the whole stuff a bit crazy maybe, but I can guarantee that performance is terrific… 1,5 second mapping time for a 20 Mb file in a DEV box! Last but not least: in my case the source IDoc is custom, so I developed it so that on each segment I always have key field(s) of the parent, just for convenience. If this is not your case, segments numbering and hierarchy is anyway present in the IDoc flat representation and you may need to improve my code in order to handle them in your ABAP mapping. In the next weblog I will show you how I realized a split of the resulting message into several smaller and packaged messages in order to overcome an MQ limitation of JMS message size.

Archives

SAP Interview Questions

SAP Training

SAP Tutorials

DISCLAIMER

DISCLAIMER : All the Content and Data in the SAPPI.SAPAG.CO.IN has been added by people outside of our control. We accept NO LIABILITY whatsoever for the content or use of the data. The user of the data should verify the accuracy of the data and assumes all liability for it's use. We will monitor the Database and remove any Content and Data that we find offensive in any way. If you don’t agree to abide by our rules, you MUST not use our website. We reserve the right to make any modifications that we deem necessary at any time. Thank you for your kind co-operation.