on 04-13-2015 1:30 PM
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
83 | |
24 | |
12 | |
9 | |
7 | |
6 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.