This is partially a follow up post to my previous blog about E-Commerce 12 things about E-Commerce (I wish someone would have told me)
For those who just want the answer:
PricingItem pricingItem = (com.sap.spe.pricing.transactiondata.impl.PricingItem) item; pricingItem.setAttributeBinding("ZCUSTFIELD", new String ({ myFieldValue })
(Actually, you have to look at the end of this blog for the rest of the code if you don't have the implementing class in your class path).
Below a bit of a story about it how we ended here...
We've all been there, haven't we...life was good in the good ol' ABAP user exits, you could do what you wanted where you wanted and then one day you are asked to move to this new great thing, Java User Exits.
After initial excitement you quickly realize that your freedom has been stripped from you and you have to use these things called interfaces that control what you can access and modify in different types of user exits.
When does this become a challenge?
To keep this short we'll just focus on one specific issue with one type of user exits.
Back in the days someone has implemented a Pricing Requirement User Exit in ABAP. All well, the logic within the user exit returns true or false to determine if a Condition type or access should be evaluated or not.
Somewhere down the line however it has been decided that it is not enough to only determine if the Requirement is true or false, but to also modify the communication structure at the same time. All works, everyone is happy.
Now jump forward to current day and you have just learn about the new VMC based Pricing User Exit model written in Java. After interpreting the logic implemented in ABAP you decide that you know what communication structure fields or Java methods you should use to determine if the Requirement should evaluate to true or false. However, when you reach the point of trying to modify the communication structure you realize that the interface which your method exposes to you does not contain the required methods to modify / add communication structure elements.
Hmm...well, fair enough, should probably not have done that in the first place in the Requirement User Exit, but too hard to change that, so how do we make this work? Obviously first stop is standard related documentation, very thin and not detailed..o.k. second stop SDN forums, surely someone there has hit this before and dealt with it. Nope, well, maybe, but couldn't find it...
Eventually the little devil on the shoulder starts to whisper in your ear...why don't you figure out how this works and "fix it"?
Right...the good thing about Java is that it has now been around for a while and the same rules apply everywhere...if it is an interface it is implemented by a class. Run the remote debugger against the VMC, breakpoint in a Requirement User Exit, add a call to retrieve the class name that implements the interface and check if you can find the right methods to achieve what you are after...
Got lucky, the implementing class was there, all is well. Last little hurdle if you want to call it that was that I didn't have the library for the implementing class in my local environment, which meant that the code presented at the start of this blog wouldn't compile. Obviously the simplest thing (as didn't have access to the server file system) was to simply write a stub class locally to be able to compile it all (but remember not to include it in the Jar you deploy as the deployment would fail and even if it wouldn't you would have some nasty class loader issues).
In this case (as I needed a few different methods in the implementing class) the resulting class looked like the following:
package com.sap.spe.pricing.transactiondata.impl;
import com.sap.spe.condmgnt.finding.IAttributeBinding;
public class PricingItem
{
public IAttributeBinding setAttributeBinding(String string, String[] strings)
{
return null;
}
public char getExclusionFlag()
{
return 0;
}
public String getId()
{
return null;
}
}
Right, that's it...feature replicated in Java User Exits...needless to say, don't use this and if you do, be very much aware that this can't be supported and there is no guarantee that in the next upgrade of any sort your user exits won't spectacularly fail. Something about the road to hell and paving...
However, what this does highlight is that when new models are introduced where rules are stricter than before it is important to remember that the implications for development and maintenance do change as well.
Would you be happy to hear about the right way to resolve this (while still implementing this in the Requirements user exit), now that I have shown you the wrong way?
Now that we have gone through a detailed case from the VMC based User Exit model, maybe it would be time to back up a bit and talk next about how the whole pricing / user exit model on VMC actually works?
Kalle
