XI: IDOC bundling – the “trick” with the occurance change
(which still is one of the most popular data exchange formats with the R/3)
very often we come to a point when we’d like to post many IDOCs from just one message.
It can be a file which should be mapped to multiple IDOCs or a select query
from a database which also maps to several (if not several hundreds) IDOCs.
Basicly we have 2 ways of handling such scenarios:
– we can use a block step and send multiple IDOCs from our BPM
– we can also do a little trick and send multiple IDOCs from the XI without a BPM
The first approach is a standard XI approach. It involves the use of a BPM
so the speed of this transfer many not be very good in case you’d like to send
hundreds or thousands of IDOCs in just one call.
The second approach uses a little trick that was mentioned several times
on the Process Integration (PI) & SOA Middleware by a number of XI developers but is still not very clear to the XI newbies.
It allows us to send multiple IDOCs without the use of a BPM. Most probably this will be your choice
if you’d like to use such 1:N (IDOCs) scenarios effectively.
In this weblog I’ll describe the second approach:
– at first you have to import your IDOC definition from your R/3
– as you know this IDOC definition that you’ve just imported allows the mapping of only one IDOC
– in order to change this you have to export the IDOC definition to an XSD file
– now we can change the occurance of the IDOC segment so it will allow many
IDOC segments – you can do it by specifying the IDOC segment occurance
in the same way all multiple IDOC segments are described
– or you can set the occurance to unbounded – like we can specify with any data type that we create within the XI
– then we have to import the IDOC definition again as the “External definition”
– create a mapping from you source message type to the created external IDOC definition
– as you can see the IDOC occurance is not 1..1 anymore
– create an interface mapping that will use your new message mapping
– specify the source and the target of this interface mapping as the standard IDOC
– create your scenario inside Integration Directory and while specyfinig the Interface determination
remember to use your new Interface mapping
While testing your new scenario you should be able to see that the occurance of the IDOC segment is not 1..1 anymore.
This weblog show an alternative way of sending IDOCs through the XI
which was widely discussed on the XI forum but hopefuly now it will be a little bit more clear.
Tested on: XI 3.0 SP14
This is a nice weblog. However, what happens when the idoc does not support multiple objects within a single idoc. For example, this solution works perfectly for MATMAS idoc, but fails for CLFMAS02?
Do you know a way to resolve it?
this is not how this workround works
it allows sending from the XI many idocs inside one structure but in the R/3 they are posted as many idocs (not as one with many inside)
Have you explored the option of Message packages of IDOCs and processing these packages of IDOCs using Event-Driven Message Processing.
I feel this is a better approach as you dont have to change any thing in the IDOC.
this will come in a seperate weblog 🙂
Can the same be used with RFCs, how?
recently i started my journey in XI.
i want step by step process for RFC TO IDOC.
will u plz guide me in this.
Thanks in addvance.
how to process if I need to send multiple different IDOCs from one source massage?
please let me know whether the same trick work while sending 20 IDOCs from R/3 to XI and output as a single file with all the 20 IDOCs data. Will XI handle all those 20 IDOCs in a single call and output the data in a single file.
appreciate your help.
The interface mapping that I created source mssg->file type, target message-->Standard Idoc, but when i call for mapping I can'nt see it, as I have created mapping with external message.
Where and how thisexternal message converts into IDOC is not clear.
I get the following error.
Thanks for this Blog. I have same requirement and i followed the steps mentioned in this blog. However i got error 'ATTRIBUTE_WRONG_INTF'. I believe this error is coming as we have modified the IDOC schema.
Can you please describe the 6th step in more details? or Is there anything else to be done on config part?
and that's all you need to do
I am still not clear of step 6 in the blog.and I need help.
I have used External message in the message mapping and when I use the standard IDOC name in the interface mapping ,it say "no object found" when i try to select message mapping in interface mapping.
The message when triggered from RWB is failing in SXMB_MONI.
I could solve this problem.
In interface mapping we need to used the standard IDOC name as interface whereas in the message mapping we should give the name of actual message mapping which points to newly modified XSD.
In Config part followed normal steps by using Standard IDOC as receiver Interface.
just like presented in the blog...
you just need to read it that's all 🙂
Hi,<br/>I exported IDOC - WMTOCO.WMTCID03 to desktop and tried to change the maxoccurs value from 1:1 to maxoccurs = unbounded, but I did not see maxoccurs name itself in IDOC tag. Please check the below XSD file<br/>--
<br/><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"><br/> <xsd:element name="WMTCID03"><br/> <xsd:complexType><br/> <xsd:sequence><br/> <xsd:element name="IDOC" type="WMTOCO.WMTCID03" /><br/> </xsd:sequence><br/> </xsd:complexType><br/> </xsd:element><br/> <xsd:complexType name="WMTCID03.E1LTCOG"><br/> <xsd:annotation><br/>--
<br/>Please let me know where and how to change it?<br/>Thanks in advance,<br/>Regards,<br/>Krishna
I am doing the scenario File to IDoc ,picking the .CSV file from the FTP server .
The problem is that the file is picking fine from FTP ,but getting an error in SXMB_MONI as : Messages in multi message format can be sent to one adapter engine only. What could be the reason and how to rectify it . Please provide me the solution ASAP.
My Source strucure :
My Target IDoc: ORDERS.ORDERS05
Awesome, loving this blog.
Thanks for writing this.