on 09-03-2015 2:10 PM
Hi AIF Community,
we identified following behavior in the AIF structure mapping processing:
The order in processing the structure mapping is the same as displayed in the structure mapping customizing. It is the alphabetic order of the source structures. In case you cannot control the naming of the source structures you cannot control the order of the structure mapping processing. In a field mapping you need to use a target value from another structure (e.g. company code in a header structure) that is processed afterwards we need to implement function modules extra for this field mapping. The simple existing AIF value mappings cannot be used in this case.
Does someone had also the same problems and used another better solution?
Is there any possibility to control the order of the structure mappings besides the naming of the source structures?
Best regards
Christoph
Good day everyone,
I realize that this is most probably far too late but I also had this issue and found a way around it.
When we are defining the destination structures for the source structure we can have the same destination structures several times over.
This way we can influence the processing order.
For example, my issue was that MATNR needed a conversion routine before any other mapping ran.
I created one destination structure 010 where the only value mapping is for the conversion routine.
I then created a second 020 destination structure for the same source structure where all remaining value mappings/checks were defined.
Hope it helps.
--
Pedro Cerveira Pinto
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Unfortunately my test scenario when I read this topic was prone to misleading. What actually happened in my real scenario was that the value mappings from the first destination structure were cleaned and the second structure mapping ran afterwards. So sorry for having mislead someone else. I eventually solved my real scenario by calling a custom function module that takes care of all conversion routines before the mappings take place. I realize it's an overkill but I very much wanted as much as possible in AIF so that ABAP team is not always needed when something fails.
Again so sorry for misleading. Next time I will definitely test more before posting.
Hi Christoph,
thanks for posting this - I never knew how AIF determined the mapping order. And yes, we've run into this problem - it seems almost unavoidable.
What we've done is implement a process flow like this:
Receive Raw Data
Pass record to AIF for initial mappings / tranlsations
Call Action
So, if we don't have access to the data we need while in AIF mapping, we put that off until the first step of our action.
Message was edited by: Robert Phelan
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Robert,
we considered the same approach but this would lead to a problem in the Error Monitor (/Aif/err) whenever you use the transform feature. This does not apply any of the actions so you dont see the complete result structure.
We also considered overwriting the base customizing by selecting a different (higher?) structure mapping number for the variant and reapply all but the conflicting field mappings and fixed values. But this would lead to error prone double maintainance. In the end we developed a function module based value mapping that fetches the specified fixed values directly from the related tables.
Its bothersome to remember that this has to be applied alongside the fixed value and there are certain constellations that arent covered due to the amount of key fields in the mentioned tables but in general this works nicely within our confines.
Kind Regards
David Rittinghaus
User | Count |
---|---|
83 | |
10 | |
10 | |
9 | |
7 | |
6 | |
5 | |
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.