cancel
Showing results for 
Search instead for 
Did you mean: 

ABAP Mapping for Large Messages

Former Member
0 Kudos

Hi Folks,

We are exploring different options for dealing with the fact that XI will choke on very large messages/files. One of the options that we are considering is a third party tool that bypasses XI. However, we've just learned that it may be possible to solve the large message problem by using ABAP Mapping, because supposedly, by doing so, one would bypass the large message being converted to XML as it comes into XI. The scenario involves messages coming into XI on their way to SAP R/3. Does the ABAP Mapping option appear to be viable to you experienced folks out there?

Thanks

Nic

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

Nic,

All message which comes to XI get converted into XML....independent of mapping..only advantage of using it is you get better control over data in ABAP and processing would be faster...

Anyway if you are planning to process large files, have a look on this blog...

/people/sravya.talanki2/blog/2005/11/29/night-mare-processing-huge-files-in-sap-xi

Hope it will help you.

Nilesh

Former Member
0 Kudos

Hi,

Mapping is not a effective solution to handle large files. Though the use of right mapping technique has its dividends. There are couple of options available.

In the file adapter configuration you can set No Of Recordsets Per Message to some X value. say 5000.

Though the file size might be large it will limit the number of records that is being transferred to some X mb.

You can refer to sravya blog for further reference.

Simple yet effective.

<b>Cheers,

*RAJ*</b>

Former Member
0 Kudos

Hey

handling of large messages depends upon the interfaces,its possible to do a bypass scenario in which u can bypass whole of IR but then you wont be doing any message mapping.

the second option can be splitting the sender file in smaller chunks using OS command with File adapter.

it all depends upon the interfaces.

similarly for IDOC-IDOC scenario u can do tunneling ,options are a lot but we need to know the interfaces first to suggest the best possible way:)

Thanx

Aamir

Former Member
0 Kudos

The scenario is this: EDI data comes in from VAN and is transformed and stored in a database. We now need to pull the data from the database and push to ECC6. XI is available but as I said before the messages coming out of the database are very large, e.g., 50K lines or more for an order. Splitting the incoming message is NOT an option and tapping into the EDI translator is NOT an option. We must pull the data from the database. I don't know if tunneling is an option because as I understand it from the blogs, it must be IDoc to IDoc and it looks like it only works for R/3 to R/3.

Thanks

Former Member
0 Kudos

Hey

tunneling as per the term is used mainly for IDOC but we use the term bypass to implement the same concept but with other interfaces.

see if u have simple 1-1 mapping then u can do a bypass scenario in which u are not doing anything in IR,u simple do the configurations in ID.

you can not drastically increase the performance just by choosing some specific mapping.mappin is not made for this .

for best performance you can design a bypass JDBC to IDOC scenario(but then you wont be able to do any message mapping.

have a look at the following for bypass scenario

/people/william.li/blog/2006/09/08/how-to-send-any-data-even-binary-through-xi-without-using-the-integration-repository

if u want to do message mapping then design a JDBC to Proxy scenario.

proxy is mainly used to enhance performance and would be the best bet for u i guess

Thanx

Aamir suhail

Message was edited by:

Aamir Suhail

Former Member
0 Kudos

Nic,

What is the volume of data you are expecting at a time? As suggested by Amir, JDBC would be faster approach..but again its depends on the volume of data..

if it is really very high...they you need to rethink of using XI as a middleware...

Also just checkout if receiver idoc type support if line items are more then 50K or so...

Nilesh