cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with large inbound ABAP proxy message

Former Member
0 Kudos

Hi experts,

we have an interface with file sender and ABAP proxy receiver (receiver is SAP Retail). The messages we get on sender side (XML) can be about 18 megabytes and after mapping they can be up to 200 megabyte (as the target structure has a lot of redundancy). In this case, we get an error from the SOAP adapter:

Even in the log viewer we don't get further information about the error:

If we send a smaller file without changing any parameters, it works fine. So the reason is obviously the payload size. Neither the sender message nor the target structure can be changed as they are determined by the sender / receiver system.

We already checked the maximum request size of the web dispatcher. It is set to 300 MB, the message causing the error is just 205 MB. This does not seem to be the problem.

Any ideas how to solve this?

Thanks in advance.

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi,

it would be good to split the message in any case as the message is very big. It is easy to create a new split mapping which is executed BEFORE the existing mapping. But then comes the problem: I will have to change the occurence in the existing mapping to "0..unbounded" and adjust the original mapping. This mapping is VERY complex and not build for that case. It would take a week or more to adjust that.

Is there any possibility to create many messages in the first (split) mapping and to execute the original mapping for each of them (without changing it)? As far as I understand the original mapping is called only once when I change the occurence and I would have to maintain the correct context changes. The idea would be:

SplitMapping (1 --> 1..unbounded)

N calls of OriginalMapping (1 --> 1)

So I don't want to change the existing mapping, just add something before it. Any ideas?

If I just add the split mapping in the operation mapping before the original mapping, the original mapping is only called once.

iaki_vila
Active Contributor
0 Kudos

Hi Stefan,

In my opinion i would figure out how to avoid this problem.

On the other hand you can use two alternatives.

1. Creating a first scenario to split your file in n files and later to use your current scenario.

2. Split the file via OS command before to take the file. Check Anupam Ghosh, wiki Optimum File Size for various file scenarios in PI part-2 - Process Integration - SCN Wiki

Regards.

engswee
Active Contributor
0 Kudos

Hi Stefan

I think it should not be a problem to change your original mapping so that both source & target occurrence = 0.. unbounded.

After you have changed the occurrences, there would be a button to enable you to correct the structure. This allows you to realign the mapping quickly without having to rework all your mapping logic. Therefore your "original" mapping can still behave like N calls of 1-1 mapping.

I use this all the time when changing occurrences and it works perfectly without having to redo the complex logic or adjust for context change.

I would suggest that you try it out first.

If it does not work according to what you expect, there is another alternative you can consider. You can use the multi-mapping with SOAP loopback approach that I have wrote about in the article below.

The article was written for the usage of multiple dynamic configuration but the same 2 iFlow approach is applicable for your scenario.

Basically, the first iFlow performs a multimapping to split it into multiple child messages, and sends all of them to the SOAP adapter.

Then the second iFlow will perform the original mapping for each child message. Refer to the diagrams below from the article.

Rgds

Eng Swee

iaki_vila
Active Contributor
0 Kudos

Hi Stefan,

The problem with write failed could be a memory problem or problem related with the maximum message size accepted. Try to change this parameter in the IE (RZ10), if you are in PI dual stack:

Check this parameter in your ECC as well.

Regards

Former Member
0 Kudos

Hi! We already set this parameter to 300 MB.

iaki_vila
Active Contributor
0 Kudos

Hi Stefan,

And the message in the monitoring is less than 300MB?.

Have you checked the message in PI/ECC queues?, SMQ1/SMQ2 transactions.

What is your PI version?

Regards.