on 11-01-2007 10:33 AM
Hi guys,
I have to design and implement the following scenario:
I will receive one file with many lines (Records) with data for materials, quantities, operations etc..
Based on the values of some fields of each line, I will have to create an IDOC for each material.
For example:
if operation type = "INSERT", and Labor = 001 then create 3 Idocs of type MBGMCR with movement types=101, 261,311 that have to be posted one after the other to the same receiver system.
else if operation type = "INSERT", and Labor <> 001 then create an Idoc MBGMCR with movement type=311 and plant = 1001.
else if operation type = "Delete", and Labor = 001 the created 3 Idocs MBGMCR with movement type=312, 262 1002 and post them serially to the same receiver system.
else if operation type = "Delete", and Labor <> 001 the created 1 Idoc MBGMCR with movement type=312.
All IDOCS are posted to the same SAP R/3 system. We do not care about the sequence, except for the cases where 3 IDOCS are created.
I am trying to think of a good design in performance terms.
It is obvious that I will need BPM for sure.
I am thinking of creating a mapping program that will produce 4 message types for the different cases from the initial file and then create a different message mapping for each case from the message type to the IDOC.
I am asking you if I have to include everything (mappings) in BPM with a "fork" step?
Or shall I produce only the 4 message types and then post them to R/3 and execute the mappings in R/3?
Best Regards
Evaggelos
Hi,
In your File2IDoc sceanrio , U r IDoc type is MBGMCR needs to populate no.of times as per the content contains by the file.I think no need to use the BPM for this.You can do this without BPM.
Change the Occurence of IDoc to 1..Unbounded, and handle the conditions in graphical mapping.For this you can write a simple UDF or by using the standarad functions u can acheive it.
Let me know if have any issues in this approach.
Cheers
Veera
>>>Reward Points,if it is needful
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If you have same Idoc type to be generated at target then you can avoid BPM
Refer this blog
/people/michal.krawczyk2/blog/2005/12/04/xi-idoc-bundling--the-trick-with-the-occurance-change
you may have to play around in mapping f
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
May be this can be helpful:
/people/anish.abraham2/blog/2005/12/22/file-to-multiple-idocs-xslt-mapping
Thanks
Kiran
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
hi,
>>I am thinking of creating a mapping program that will produce 4 message types for the different cases from the initial file and then create a different message mapping for each case from the message type to the IDOC.
To me this seems to be the right solution.
here u will create different message mappings and write them sequentially in interface determination. the multi mapping will then be utilised in transformation step in BPM.
thus if this is the only requirement there is no need of using a fork step.
[reward if helpful]
regards,
latika.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I am thinking of another scenario, since I will have to create at least one Idoc for each material (for each record of the file), maybe I could do the following:
1) Configure the sender file adapter so as to create one message type for each record
2) Not use a BPM
3) Create all interface determinations with a separate mapping program used in each case and click on "maintain order at runtime" and specify the conditions for the creation of IDOCs in Interface determination. In the case of the 3 IDOCs, the condition will be the same and they will be created sequentially.
I think that if a condition is not satisfied in Int. Determ., then the next one will be chosen.
What u think?
User | Count |
---|---|
84 | |
10 | |
10 | |
10 | |
7 | |
6 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.