XI performances with big flat files

[Former Member]

Hi,

I have a big flat file (thousands of lines) in the outbound that undergoes complex mappings. The whole treatment is resource consuming.

I was wondering whether there were any means to improve the performances? (cutting the file in smaller parts, treating groups of lines...)

Just any idea?

regards

Yann

[MichalKrawczyk]

hi,

>>>>cutting the file in smaller parts,

if possible this is the best idea

but you need to do some tests to find the proper size

of the file chuncks as it depends on the structure

of your file

also

Night Mare-Processing huge files in SAP XI

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

there are not may other things you can

do as it's only one adapter... not the

engine, workflow etc...

Regards,

michal

[Former Member]

Hi Michal,

In fact, I expected XI to cut the file, as it comes directly from our business partners.

Do you think communication channel parameters like "recordsets per message" or "recordset structure" may have any effect? I read that BPM could act on the flow by grouping data for example. Do you think that's an interesting way?

regards

Yann

[Former Member]

Hi Yann,

Yes, "recordsets per message" is what you would use to split the large file into smaller messages. You can see the blog Michal mentioned and the XI help for more information on it. This would be the recommended approach if it fits your scenario.

In general, you only want to use BPM if you absolutely need to since it's more resource intensive. I definitely wouldn't recommend it for processing large files since a BPM interface takes more memory, cpu, and storage than a non-BPM interface.

If you're going flat-file to flat-file, check out the following weblog for an alternative method:

/people/alessandro.guarneri/blog/2006/03/05/managing-bulky-flat-messages-with-sap-xi-tunneling-once-again--updated

Thanks,

Jesse

[Former Member]

Hi Jesse,

I've read Michal's recommanded blog, but the title is misleading as it seems that the encountered problem was due to a bad separator and not from the file size.

So bad : my Inbound message won't be a flat file so I can't apply your suggested alternative method either.

I note your advice not to use BPM and will try some load tests changing the "recordsets per message" parameter value.

Thanks anyway

Yann