We was upgrading to SP 9 to make sure the system was as updated as possible. We did have one BIG issue on how the runtime works, compared to how we are working as developers. We did not find the issue in development since we did not thing that there could be an issue with it. But a test in QA reviled the problem.

Update: it was in SP9 the change was introduced and not SP10


Update: 29 march 2014: The issue is now solved. See SAP Note 1986871. Mauris last comments gives more information


Update 24 feb 2014. We have spoken with SAP Labs and have found that the issue is only when dealing with constants and variables in duplicated element, so it is only in few instances. SAP is working on a fix for this. I’ll update when the bug is fixed.


I do apologize for the confusion for that this caused. We had tried to make a simple case to show the issue, which contained constants had caused the problem. Most often the pattern will contain field mapping and not constants it is less likely to cause problems.


Comment from Mauri Frandsen, who also help look at the issue. This blog was written because we had some concerns on our project that the problems we faced during our 7.31 SP10 upgrade were widespread and would affect a lot of customers. To us it initially seemed that the problem was due to a change of behavior regarding validation of duplicated mandatory elements. SAP gave us some information about a bug fix from SP09 onwards that led us to believe that this was the reason for the mapping problems we experienced during SP10 testing. It seems not to be correct or at least not the full truth. SAP has informed us that the problem is tied into the use/behavior of constants and is currently doing analysis of the problem. We will await the final outcome of this work and look forward to seeing the solution which will then be announced in an update or comment to the blog.


Update: 22 feb 2014. We have now identified that the mapping pattern is used by many customers. I have got confirmation from Udo Paltzer that SAP development is looking into the issue. And I have a call with Development on monday. I’ll update when we get a solution on the issue.  So no need for more comments about that you also may have the problem.

The issue is in a common pattern that I often use to simplify the mapping. It when you want to make different mappings for some instances with createIf. So map the first element if something is true otherwise map the duplicated instance. The second mandatory element is then a dublicate subtree. Notice the second element does not have any occurrences.

2014-02-14 12_43_25-Enterprise Services Builder (grusapx11_X11_30).png

Using this pattern can in many situations make it clear what is in each field for the different.

A good example could be mapping the partner informations. I have situations where I’ll map the buyer partner different depending on if they provide a customer number or just an address.

If we run the same mapping on the old SP6 version we don’t have an issue. It seems like it is a new feature with SP 10 and the corresponding PI 7.4 SP.

We have created an OSS message for the case, but without any luck. The issue is that there have been some updates to the SAX parser or the way it is used. The solution is to find all mappings using createIf and determinate if it is an issue. You the query http://PISERVER/rep/support/private/MappingReport.jsp?searchString=createIf

The resolution is to update the mappings. We have around 70 mappings where createIf is used. So it can be a big problem to find and  update all of the mappings. My guess is that we will have to spend 20-40 hours updating the mappings to handle the problem.

There are some solutions, but the only one that is easy to implement is the first.

  • Update the schema to change the minimum occurrence to 0 and save the mapping.
  • Remove the createIf on the first element and combine the values for it. In some of my mappings this can be a big issue.
  • Create an always on dummy element on the first element. And then remove current mapping to lower levels. It can take some time.

Last time SAP made changes to the If functions and BigDecimal it was optional to use it. Because it did have a huge impact on how PI was run. This evaluation is in my perspective also something that users should be explicit if they want to use.

Are you also using this pattern please comment on the blog, so SAP can see how big the issue are. If it just us who is doing this we can probably get over it. But it is more common that it is something we must have changed.

Thanks Mikael Mauri Frandsen and Hans Hougaard for helping with identify and comment on the problem.

To report this post you need to login first.

48 Comments

You must be Logged on to comment or reply to a post.

  1. Mikael Mauri Frandsen

    It was after upgrade from 7.31 SP06 to SP10 we faced the problem. I was told by SAP support that the change in behavior was introduced in SP09 (released 20-Sep-2013). So most customers running PI 7.31 probably still runs versions older than SP09 and therefore they have not yet faced the problem.

    Here is the the simple mapping Daniel shows in text preview:

    /test/optional=createIf(const(value=false))

    /test/optional/field=const(value=optional 1)

    /test/optional[1]=createIf(const(value=true))

    /test/optional[1]/field=const(value=optional 2)

    /test/mandatory=createIf(const(value=false))

    /test/mandatory/field=const(value=mandatory 1)

    /test/mandatory[1]=createIf(const(value=true))

    /test/mandatory[1]/field=const(value=mandatory 2)

    Under SP06 we get this result:

    <?xml version=”1.0″ encoding=”UTF-8″?>

    <test>

       <optional>

          <field>optional 2</field>

       </optional>

       <mandatory>

          <field>mandatory 2</field>

       </mandatory>

    </test>

    Under SP10 we get this result:

    Cannot create target element /test/mandatory. Values missing in queue context. Target XSD requires a value for this element, but the target-field mapping does not create one. Check whether the XML instance is valid for the source XSD, and whether the target-field mapping fulfils the requirement of the target XSD com.sap.aii.mappingtool.tf7.IllegalInstanceException: Cannot create target element /test/mandatory. Values missing in queue context. Target XSD requires a value for this element, but the target-field mapping does not create one. Check whether the XML instance is valid for the source XSD, and whether the target-field mapping fulfils the requirement of the target XSD

    (0) 
    1. Mikael Mauri Frandsen

      So prior to SP09 ( I can confirm at least it goes for SP04 and SP06 ) we as PI developers had the freedom to let any element (where “duplicate subtree” was used) produce the output to meet the minimum required number of elements. To my understanding this freedom was implemented by the fact that the check for minimum (and probably also maximum) occurrence was disabled for ALL elements where “duplicate subtree” had been applied, including the “original” (index 0).

      Now from SP09 onwards this freedom (disabled check) no longer exists on the original ( index 0 ) of the duplicated elements, only on the following ( index > 0 ). Therefore conditional mapping (as used with createIf) is no longer an option on the original element. The original MUST produce output to meet the minimum occurrence requirement.

      So if you have already implemented mappings that make use of conditional creation of mandatory elements, you may be in trouble.

      I requested SAP to introduce a new configuration option so we can choose between old ( pre-SP09 ) and new (SP09 onwards) behavior. This way we would not have to spend a lot of time and effort on identifying the mapping programs where we now suddenly have a problem and on changing and testing them once again. But unfortunately SAP’s position on this issue is simply that the new behavior is the correct one.

      I must admit that in this particular case I wonder what happened to “Innovation without disruption”…

      (0) 
      1. Øystein Emhjellen

        Hi! Where do I find information that this behavior is changed in SP09 for PI 7.31

        Looked at the release notes (“whats new”), but did not find this particular information.

        Do you know for which SP of PI 7.4 this change is introduced? (I assume the same change is done for 7.4..)

        (0) 
        1. Daniel Graversen

          Hi

          Support said that it was from SP 9.

          The corresponding SP on 7.4 is SP 4 since SP5 is the newest.

          (0) 
  2. Agasthuri Doss

    Thanks Daniel & Mark, for bringing it up

    >>Are you also using this pattern please comment on the blog, so SAP can see how big the issue are.

    Please, loop me into the status, If I find anything before that I will update in your blog…

    Cheers

    Agasthuri

    (0) 
  3. Øystein Emhjellen

    Hi! I agree with you that this is a big issue.

    SAP should not implement forced changes that affect current mappings, in any case.

    This makes upgrading much more difficult, or time-consuming.

    It may result SAP customers reluctant to upgrading SAP PI at all, or discontinuing the use of PI.

    Any new functionality introduced in new versions of SAP PI should be optional, and possible to switch on/off using parameters. A similar case happened when SAP introduced the java based IDOC adapter in AEX, where they tightened the rules for mapping the Segment node (from allowing just a “blank” to requiring a value of “1”.). They also introduced some strange rules to mapping the idoc Control record.

    So we had to change all mappings involving idocs, when upgrading.

    For this new rule that is making all mandatory elements mandatory (not allowing a second duplcate node to fulfill the mandatory requirement), my customers would need to go through ALL mappings to check that the mandatory element is always filled in on its first occurrence. Although this sounds reasonable at first, it is impossible to use the mapping as it has been designed. This results in minor or major changes to each mapping, with the time and cost involved.

    I see this change only as a drawback, with no added benefits. SAP should change the behaviour of the parser back to its original, and implement this change only where a certain (new) parameter is set.

    (0) 
  4. Buntu Ntozake

    As mapping IDOCS is complicated on its own, this will add more woes.  I wish SAP can address the issue for better efficiency. Reviewing all the mappings can be time consuming especially if you have numerous number of mappings.

    (0) 
  5. Carlos Ocampos

    Hi all,

    Agreed. This cause a big impact because is not only time to change mappings, but also testing all interfaces in all environments. From my point of view, SAP should give us an alternative or leave the functionality as it was.

    Thank you very much Daniel for update. Keep me updated.

    (0) 
  6. Stephen Bentley

    It’s bad enough trying to use the Java Idoc adapter, which can mean that existing mappings to idocs need changing, or your idocs will no longer post.  We don’t need any more obstacles to upgrading. This is poor from SAP.

    (0) 
  7. Robert Warde

    I totally agree with the bloggers comments. A change such as this can have a significant impact on the development required. Very poor response from SAP. They need to address this issue. We are running 7.31 SP8 and plan to upgrade to SP12 when available. At present we cannot do this.

    SAP,please listen to your customers.

    (0) 
  8. Øystein Emhjellen

    Daniel wrote: “The solution is to find all mappings using createIf and determinate if it is an issue.”

    Is this really only a problem for mappings where function CreateIF has been used?

    I believe this problem exist whereever you add a duplicate node in the target Message and map a certain source node to this.

    If you do not make sure that the original mandatory node is filled with a value, there will be a missing value in a mandatory target field.

    So checking only where CreateIf has been used is not enough, I fear.

    (0) 
    1. Daniel Graversen

      Hi

      Yes you may see it in different instances where you at runtime is selcting which node or element to fill. Or you could have created custom functions to perform the same operation. But i think that createIf would be the biggest part of this.

      Daniel

      (0) 
      1. Øystein Emhjellen

        Well, then the search for CreateIf will only show some of the mappings where the problem exist. You will need to look at each of the mappings to chech if you have duplicated a mandatory node.

        In some cases, you might not even find there is a way to replace the current Logic with some new logic!

        Good if you can raise this with SAP (Udo P) so that this is fixed asap.

        (0) 
            1. Mikael Mauri Frandsen

              Hi Øystein,

              I found out you can use keyword “setNextDuplicated” to find where “Duplicate subtree” is used. I tried with just “Duplicate” and it worked ( as it is contained in setNextDuplicated ).

              If you have access to a 7.1x system you can export a mapping with ctrl-shift-0 ( provided you disabled Windows controlling ctrl-shift under “Region and Language” in Control Panel ). Then you can find a file named “value” in ZIPPED_SOURCE_CODE.zip. It contains java code where you can see the setNextDuplicated method being used.

              So this will work:

              http://server:port/rep/support/private/MappingReport.jsp?searchString=setNextDuplicated

              Still the big issue here is not finding mappings that have a problem. The big issue is that we have to deal with the problem at all. This risk should be eliminated by SAP that needs to fix their bug fix…

              (0) 
  9. Daniel Graversen

    Hi

    Thanks for all the comments.

    I have also got 12 emails today from people who also saw this problem as an issue.

    Update form Udo is that it is sent to the development for evaluation. Which was the point of this blog.

    (0) 
  10. Aaron Myers

    Thanks for highlighting the potential problem Daniel, Mikael, and Hans. It could affect a future upgrade for us. Maybe be hard to catch in regression testing, especially if the behavior change is glossed over in the release notes.

    (0) 
  11. William Li

    Hi,

    Yes, this is a problem, but, I am not sure it is as serious as indicated throughout the comments within this blog.

    As indicated in the blog comments, a simple solution is already available, by changing the data type of the number of occurrences of the element to a minimum of 0.  With this, there is actually no mapping change.  Of course, this solution is only relevant to the data types that we can actually change.  There are also others which we have no control over, e.g. IDoc, RFC.  For those situations, there is another solution.

    We can develop an UDF, “create_if”, and place it in a function library.  “create_if” can replace any place where the “createIf” function is used.  “create_if” will have the same effect as “createIf” before SP9.  Yes, we will still have to identify the places where “createIf” is being used and replace it with “create_if”.  But, at least, this is not a re-development of the mapping logic.

    Below is the code for “create_if”:/wp-content/uploads/2014/02/create_if_393210.png

    The code in below:

    _________________________________

    if (var1[0].equalsIgnoreCase(“false”))

    result.addSuppress();

    else

    result.addValue(“”);

    _________________________________

    /wp-content/uploads/2014/02/create_if2_393211.png

    Regards,

    William

    (0) 
    1. Sreeram G Reddy

      Hi Bill,

      I think the issue is not limited with CreateIF only there are many situations where we have used duplicate subtree so in all those cases its going fail if the first nodes is not created. How this can be fixed? as you pointed out we don’t have control on structure on IDOC,RFC and especially with 3rd party vendors like Banks etc…

      Regards

      Sreeram

      (0) 
      1. William Li

        Hi Sreeram,

        This might be true.  But, when I briefly glance through all the node functions, “createIf” is the only one I can identify that has an effect on the target element.

        I think this can be a work-around while we wait for development to come up with a resolution, without having to hold up the project.

        In most situations I’ve dealt with, I have been populating all the elements that have been duplicated.  When there is a situation where I may not create an element, I’ve only used “createIf”.  This error will result only when we do not want to create an element that has been declared as mandatory.

        For everyone, I would be interested in mappings relating to duplicate elements, which will result with error due to this change, other than the “createIf” situation.

        Any information will be greatly appreciated.

        Thanks,

        William

        (0) 
        1. Mikael Mauri Frandsen

          Thanks, Bill, for providing this idea for a workaround that can be used until a permanent solution is available. I have tested it and I can confirm it makes the mapping behave as before the change when I replace createIf with your create_if.

          I have checked all our custom message mappings that use createIf ( 74 mappings out of 216 ). Then I also checked all mappings that use “Duplicate subtree” ( run mapping report with keyword setNextDuplicated ) which found 95 mappings. I excluded those already checked and had about 30 left to check.

          At the end I found 8 mappings (all INVOIC02 idoc to EDIFACT INVOIC) which use duplicated subtree on mandatory elements. All of them use createIf. Three different target message types are involved.

          Element(s) with problem

          Ext. definition

          /LIST/S_UNB/S_UNH/G_SSG45

          ED_INVOIC93A

          /LIST/S_UNB/S_UNH/G_SSG48

          ED_INVOIC96A

          /LIST/S_UNB/S_UNH/G_SSG48

          ED_INVOIC96A

          /LIST/S_UNB/S_UNH/G_SSG48

          ED_INVOIC96A

          /LIST/S_UNB/S_UNH/G_SSG48 and /LIST/S_UNB/S_UNH/S_DTM

          ED_INVOIC96A

          /LIST/S_UNB/S_UNH/G_SSG48 and /LIST/S_UNB/S_UNH/S_DTM

          ED_INVOIC96A

          /LIST/S_UNB/S_UNH/G_SSG48 and /LIST/S_UNB/S_UNH/S_DTM

          ED_INVOIC96B

          /LIST/S_UNB/S_UNH/G_SSG48 and /LIST/S_UNB/S_UNH/S_DTM

          ED_INVOIC96B

          I think for the S_DTM elements we found out that input data should always be present. So only elements G_SSG45 and G_SSG48 will cause problems. For these we would have to make a workaround if we want to upgrade to 7.31 SP10 before SAP comes up with a permanent solution. The workaround would be either to set minOccurs=”0″ in the XSD for the elements that cause problems and re-save the mappings – or to implement your altervative create_if.

          I appreciate your valuable input. Still I must emphasize that a permanent solution from SAP is needed. Otherwise ALL PI customers who runs 7.31 SP04 (and earlier?) to SP08 will have to deal with this which means either to spend several days on this topic during SP upgrade – or to risk getting errors in production environment. Not all customers will have a problem. But nobody wants to be exposed to the risk.

          (0) 
        2. Mikael Mauri Frandsen

          Some doubts:

          1. I do not know for sure the status of 7.31 before SP04 in this regard.

          2. I am not sure about how SP levels of 7.40 are affected.

          3. I am not sure if any 7.1x versions are affected.

          Yesterday SAP support wrote this about the bug fix that causes the problem:

          “This was a bug in certain releases of 7.31 which is now being fixed. The

          functionality which you are observing in 7.31 SP09 has been the same

          in older releases  of PI as well. We have not changed the behavior.

          The behavior observed in 7.31 SP04 and SP06 release is a bug which has

          now been fixed.

          We will soon be releasing a Note for the same.”

          So it appears there is a SAP note in the making about this. Hopefully it clarifies exactly what versions are affected. BUT…hopefully it comes with BIG WARNING, too. If not, customers applying this SAP note will be exposed to the risk of broken mappings.

          (0) 
    2. Daniel Graversen

      Hi Bill,

      Thanks for the function. It seems like it can solve the issue in most cases.

      But it still is a large job to find and replace all of problematic createIf metods and transport to production. If there is  a few problem it can probabaly be fixed quite easily afterwards.

      I still hope that SAP provides with a update of the functionality.

      Daniel

      (0) 
  12. waldemar roberti

    Thank you Daniel and other coleagues for the hint.

    We do have scenarios like you mention, and are planning to update in a couple of months. We would be glad to help you supporting the effort to convince SAP to fix this issue.

    Waldemar

    (0) 
  13. Murali Palanikumar

    Dear All,

    Seeing that this blog has created a lot of interest on this topic, I would like to clarify few points. It looks like there is a misunderstanding on the actual problem and the clarification provided by SAP which was specific to the scenario reported in the message.

    1. “Createif” and “Duplicate subtree” functionalities have no change in behavior between any of the SPs.

    2. When there is a mandatory element with no input, there is no error raised. This issue which was fixed with SP9 and this is the change explained by SAP before. There were no changes with “Createif” and “Duplicate subtree”.

    3. The error you are noticing in your landscape is neither related to createif nor with duplicate subtree. But it is related only to the usage of constant together with Createif.

    4. This can be verified by replacing the constant with a normal input field.

    @Mikael: We are currently analyzing the issue reported by you which is limited only to the usage of constant and we will be updating you soon on it.
    @Daniel: Are you referring to the same message as Mikael? If not, could you please drop in an email to me with the details of your reported issue? We could have further discussions on it.

    This is not serious as discussed here. There is an error in a specific scenario involving constants which is currently being analyzed and the solution would be updated soon.

    To brief it, there is no change in behavior with “Createif” and “Duplicate subtree”, the error you notice is specific only to a particular scenario which is under analysis and there is no additional efforts involved in changing the mappings with the upgrade to SP9 or above.

    Best regards,

    Murali Palanikumar, Development Support, IMS PI.

    (0) 
    1. Vicky G

      To ensure I have the correct understanding, the issue is with case 2 and not with case 1 and 3  i.e the issue is only when creatif and constant are used together and not individually. We are starting our upgrade from PI 7.11 to PI 7.31 and understanding the impact of this issue is very important before we decide the SP we would want to go to.

      Please advice.

      Case 1

      Capture102.PNG

      Case2

      Capture103.PNG

      Case 3

      Capture101.PNG

      (0) 
      1. Mikael Mauri Frandsen

        Hi Vicky – NONE of your cases 1-3 are affected by the problem. All of your cases have an optional target element ( minimum occurrence 0 ) – and optional elements are not affected.

        My understanding is that the potential problem is limited to a combination of ALL of the below circumstances:

        1. MANDATORY target element ( minimum occurrence > 0 ),

        2. Use of “Duplicate subtree”

        3. Conditional creation of the FIRST ( index 0 ) node based on a CONSTANT or a VARIABLE ( of type “Add variable” ).

        If “Duplicate subtree” is not used, conditional creation of the target element that does not meet the condition (or does not produce the minimum number of occurrences) will lead to an error. But this would also be desired bahavior as the mapping can not fulfill the minimum requirement. When “Duplicate subtree” is used, you would like to see that the mapping does not fail just because the first (index 0) node did not produce required output, because you want to give the duplicated nodes (index > 0) the chance as well to produce output.

        regards

        Mauri

        (0) 
        1. Vicky G

          Case1:

          /wp-content/uploads/2014/03/case11_414323.png

          Case2:

          Case22.png

          Email is connected to the CustomerNumber Node 0 and Telephone to node 1

          Per your explanation Case1 will be impacted.

          (0) 
          1. Mikael Mauri Frandsen

            No. As already said, ALL of these 3 circumstances must be present before you have a potential problem (which will always be on node 0):

            1. MANDATORY target element ( minimum occurrence > 0 ),

            2. Use of “Duplicate subtree”

            3. Conditional creation of the FIRST ( index 0 ) node based on a CONSTANT or a VARIABLE ( of type “Add variable” ).

            I do not see (3) in your case 1. Your are just moving a constant which is not conditional creation.

            Furthermore you are not showing the minimum occurrence of your target element. If it is not greater than zero it is not mandatory and it would then be another reason why this case is not affected. But one reason is enough, your case 1 is not affected.

            (0) 
  14. Øystein Emhjellen

    Good that the bug (according to info update 24th of Feb, based on info from SAP) seems only related to use of constants to create the duplicate instances of mandatory nodes.

    In most cases the duplicate instances are created based on field mapping (fields occurring in the source message). At least this is how I use the feature of creating duplicate instances. But in some cases I just add a blank constant to enable the output of a duplicate instance. I usually do not use constant value “true” and function CreateIf in these cases.

    It would be nice if this blog gets an update on what mappings eventually seems to be affected by this bug, and another update when SAP releases a bug fix.

    Thanks!

    (0) 
    1. Mikael Mauri Frandsen

      Hi Øystein, see my answer to Vicky above for an explanation of my understanding of the scope of the problem.

      SAP is currently testing a change/fix related to the use of constants and variables. When given the chance I will test it as well on the system and mappings where we have seen the problem.

      Currently we are using a workaround which is simply to make the mandatory elements optional by changing minimum occurence in our XSDs/external definitions to zero. We found 7 message mappings that were affected. They use 3 different target messages, so we added minOccurs=”0″ to the element in question for those 3 XSDs and re-saved the 7 mappings.

      The 3 target messages are (Seeburger) EDIFACT INVOIC.

      Ver.     Mandatory element where we have used workaround

      93A     /LIST/S_UNB/S_UNH/G_SSG45

      96A     /LIST/S_UNB/S_UNH/G_SSG48

      96B     /LIST/S_UNB/S_UNH/G_SSG48

      regards

      Mauri

      (0) 
      1. Mikael Mauri Frandsen

        Yes. Yesterday I tested the fix and found it does indeed solve the problem, nice!

        The solution, as I mentioned a week ago, is delivered in SAP Note 1986871. It means deployment of patched version of software components MESSAGING and SAP_XIESR.

        After the SCs were deployed the mapping problem was solved. We did, however, see another problem after this deployment. It is in Monitoring under Adapter Engine / Message Monitor where we get this error when we try to select a time range on the overview tab:

        Could not connect to message processing system- java.lang.NoSuchMethodError

        com.sap.aii.af.service.statistic.ViewDataManager.getHash

        (click image to see full text)

        MonitorError.JPG

        I am almost sure this error comes because we have deployed only the two listed SCs and not yet the corresponding dependent SCs which you can see in the note if you click the “SCA Dependency Analysis” icon/link.

        What you will see is that both of the above mentioned SCs have a list of 15 dependent SCs. The two SCs are both inter-dependent, so if you remove this entry from the list you get 14 dependent SCs which are identical for the two SCs. We can exclude the one which is the old SE (Standard Edition) connectivity, compatible with XI 2.0. So we have a list of 13 SCs to be deployed.

        SCA Dependency Analysis.JPG

        (click image to see full details)

        We are still discussing if we should deploy them all or just those we think cause the problem. I would say go for all, but is still to be decided. You may be able to find the missing class/method if you download and browse through all of the SCA files, but that may take some time. So that is why I think it would be easiest to just deploy all dependent SCs.

        So to summarize this: The SAP note solved the mapping problem. But we see another error now in monitoring which will probably disappear when we deploy all (or some) of the mentioned dependent SCs.

        regards

        Mauri

        (0) 
        1. Rick Xon Kuan

          Hi,

          After we upgrade from PI 7.11 SP07 to 7.31 SP11. We are having the createIF mapping issue. I thought this only happen in SP09. Will it happen in SP11 also?

          Anyone facing the same issue for SP11?

          Regards,

          Rick

          (0) 
          1. Daniel Graversen

            Hi Rick

            The issue was interduced in SP8 and then fixed with a support pack for 10 and possible also for SP11. You may have to install the latest version of the PI tools components, that should fix the issue.

            (0) 
            1. Rick Xon Kuan

              Hi Daniel,

              But my issue is a bit different. The input value is true, but the second segment get surpress in 7.31. Is it the same with your issue?

              7.31 Mapping

              7.31_createIf.jpg

              7.11 Mapping

              7.11_createIf.jpg

              (0) 

Leave a Reply