Variant Configuration – Mixing Constraints and Procedures

Home / Blog / Variant Configuration – Mixing Constraints and Procedures

Well, I recently ran into a glitch that forced me to do some investigating, so I figured I’d post it here.  For my VC guru’s out there, you already know this, but obviously, I forgot =)  The order of execution tends to be very important, especially when you mix constraints and procedures.  Let me start by laying out what I found, so it might make more sense to you.
I have a model that is primarily driven by constraints.  I’m heavily using variant tables in order to restrict my values.  There are also a handful of reference characteristics, along with some procedures to set things as INVISIBLE or NOENTRY, or setting defaults.  Now, everything worked just fine in CU50, but as soon as we started sales order testing, we started running into issues with the INVISIBLE characteristics (dynamic of course) not working properly.
So, like any good modeler, I looked at my rules and they all seemed fine in CU50.  Therefore, I’m “SURE” it must have been a user error.  ha ha.  Then I took it to the sales order and found that indeed, it was broken.  So, I went back to my old friend, trace.  This is what lead me to this post =)  When you start looking at the detailed trace, you see that a LOT happens for a constraint, and unfortunately, it’s not always intuitive.  What I was happening was a value was being set, then unset, then the procedure ran (unfortunately, dependent on the value), and then finally it was set again.  So I did some homework…  and short story was that there really wasn’t any around this “behavior”. The reason it behaved differently in CU50 vs. VA01 is because we had to manually enter a value for the reference characteristics.  When you enter a value, the execution works a little different behind the scenes.  This is why the issue only shows up in the sales.

So, the solution we came up with was to move the INVISIBLE and NOENTRY to a constraint.  What this accomplished for us was to make sure that everything kept getting re-executed to get the proper behavior.  Now, this still won’t solve all the issues…  since you can’t use SET_DEFAULT, or SPECIFIED in a constraint.  This will force you to use procedures if you must use this functionality.

The morale of today’s story, try to as much as you can in either the constraint or the procedures.  The more you mix these 2 technologies, the more testing you should expect to do in the sales order.  Happy modeling =)

 

As always, thanks for reading and don't forget to check out our SAP Service Management Products at my other company JaveLLin Solutions,
Mike

Leave a Reply

Your email address will not be published. Required fields are marked *