A Light shines in Darkness ... Or does it?

Now the Valve example might be extreme, but it certainly serves the purpose. If you've got a complex configuration ... and many, many SAP customers do ... then you can easily benefit from Advanced Mode, even if you don't have "solutions," or "systems," or "bottom-up" configuration. It's there, it's in the system, and ... if you've got ERP2005, you've got it. There's absolutely no reason ... no good reason that I can think of, at any rate ... not to take advantage of it .... Henk Meeter, March 04, 2006 Copyright © by Henk Meeter

It's Already There ... Or is it?

Let's pick up from where we left off last week. I made the assertion that, now that the IPC is integrated into the ABAP stack, the "Advanced Mode" doesn't have to be integrated into the R/3 world ... because it's already there.

And now we have the assertion, in the accompanying article (Comparison of Sales Requirements with SAP 2005 abilities, by Jan-Peter Oeser), stating, rather baldly, that "SAP 2005 does not support advanced mode."

So which is it? Does it, or doesn't it?

It's really a question of definitions. If you start out with the assumption that "Advanced Mode" means "System" or "Solution" or "Bottom-up" configuration capability, then it's certainly not there.

If you think that "Advanced Mode" means you should automatically get the ability to create a virtually infinitely extensible configuration at run-time with a minimum of Bill-of-Material definitions during product modeling, or what we call "Multi-Instantiation, then the new "integrated IPC" doesn't bring you "Advanced Mode."

And, too, if you think that "Advanced Mode" means that you should automatically get the ability to do all sorts of interesting MRP-ish things with the new "Abstract Data Type" Characteristics that are at your disposal, then certainly the new "integrated IPC" doesn't bring you that aspect of "Advanced Mode" either.

But I suspect that, by limiting our definition of "Advanced Mode" to being only those things that come along with what we might define as "Advanced Mode in its entirety," we are doing ourselves a very great disservice.

To see why, let's talk through a little product modeling exercise, targeted toward showing how the use of "Advanced Mode" might help you greatly, even without "advanced" systems or solutions or bottom-up configuration capability.

Abstract Data Types

We'll focus on ADT's, which is shorthand for Abstract Data Types.

First, before we talk about ADT's themselves, let's imagine, again (as we did last week) that we're from a company that makes Valve Terminals. Our Valve Terminals can be broken down into anywhere from eight to sixty-four positions, each of which might be said to represent an individual Valve.

Our Valve Terminals are also pneumatic. They could be hydraulic too, without changing the general parameters of the Valve Terminal "problem" too much, but let's just say, for the sake of argument, that in this case we're working with pneumatic Valves.

Now there are a couple of things we want to make sure we handle. We obviously need to handle the relationships between adjacent Valves ... they have to be able to "fit" together.

But we also ... and perhaps not so obviously ... need to be able to ensure that it's impossible to set up the model in such a way as to "block" a particular Valve from the overall Valve Terminal air supply.

In other words, our Valve Terminal consists of many Valves all in a row.

Our air supply (that's what "pneuma" means) can come in from either end of the row, or it can even come in from somewhere in the middle. And that means that each individual Valve could potentially get its air supply from either direction.

Now, for certain reasons (which are beyond me), it might be appropriate to cut off a Valve from air input from one of those directions. You do it by stating, during the configuration process, that it's got a seal on one side. The seal stops the air from coming in.

Obviously, however, if you can put a seal on one side of the Valve, then you can put a seal on the other side too.

And that means that, if your product model doesn't have the intelligence to "recognize" that a seal lies on both sides of a Valve, then our customer is going to be able to specify a malfunctioning Valve Island, and that's going to cause both us and our company a lot of trouble.

So that means we have to solve this problem.

Bill-of-Material Comparisons

There is a note, available from OSS, which describes certain performance issues following on the use of constraints.

It's note number 917987, and it's cited by many, consultants, product modelers, and others, as their justification for why they avoid constraints, even in the face of the assertions, by those such as Gartner, to the effect that any Sales Configurator worthy of the name has to be a constraint-based configurator.

Let's cite one of the relevant portions in German (I'll then translate) ...

"Constraints dienen in Wesentlichen zwei Funktionalitäten. Zum einen ist es, Werte über die gesamte Struktur setzen zu können, zum anderen Werte in Abhängigkeit anderer Werte einzuschränken. Gerade letzteres ist sehr rechenintensiv ..."

And that means ...

"Constraints serve essentially two functions. On the one hand, to be able to set Values over the whole structure; while on the other to be able to restrict Values based on the settings of still other Values. Exactly the latter is very computation intensive ..."

Now obviously that's very true. We gave a sample in our editorial from last week, showing just how true it was. Upwards of 90% of an Inference Engine's processing is absorbed by its Pattern-Matching System (the part that keeps track of which constraints need to be fired when).

What's interesting, however, is its contrast between Domain Restrictions (restricting Values based on the settings of still other Values) and Value settings "over the whole structure."

That's because our own experience suggests that the real "performance-hogging" is exactly the other way around.

When should one use constraints "to set Values over the whole structure"?

Well, certainly not to bring Values "down" (from parent KMAT to child KMAT or Class). Procedures can do that very easily, with a much less discernible "hit" on performance.

And probably not to bring Values "up" (from child KMAT or class to parent KMAT). While that sounds "esoteric" and therefore "interesting," I've never yet found the need to do it outside of "counting" scenarios.

No, usually you need to use constraints to manage Dependencies between siblings. Or in other words, between components at the same Bill-of-Material level ... exactly what we're talking about now.

So let's get back to the Valve Terminal "problem" ...

It's already obvious, probably, that the problem has to do with adjacencies. Adjacent Valves need to "fit" together, and Valves either get, or don't get, air from the Valves that are next to them.

So how do we model this in Classical Mode?

There are actually two ways that I know of, one rather more intuitive, but horrible when it comes to performance, and the other quite a bit better in performance, but almost a head-breaker when it comes to understanding.

Let's just say that the second one has to do with Multiple-Value Characteristics on the parent Valve Terminal KMAT, assignment of Characteristic Values "up" from the Valve positions to these Multiple-Value Characteristics (at which point I recognize immediately that I've contradicted myself ... let's just say I haven't done this "interestingly esoteric" thing in an actual production model), and some wild ">=", "=", and "=<" comparisons between the Multiple-Value Characteristics.

And then let's forget about it, because it doesn't really bring enough performance benefit to make its incomprehensibility worth it.

The more intuitive one goes like this ...

You assign a Position_Number Characteristic to your Valve Class, and you set it when you instantiate your Valve Position. Then you write the Pattern sections of your Constraint (i.e. the Objects block and the Condition block) as follows:

Objects:

?VT Is_a (300) Valve_Terminal,

?V1 Is_a (300) Valve,

?V2 Is_a (300) Valve.

Condition:

Part_of (?V1, ?VT) and

Part_of (?V2, ?VT) and

?V1.Position_Number = ?V2.Position_Number - 1.

What you get from this is pretty straightforward. The Objects section declares the Objects the constraint is supposed to "be on the lookout for" ... in this case Two Valves and a Valve Terminal.

The Condition section then restricts the scope of the "pattern" further. The constraint isn't supposed to fire for every combination of two Valves and one Valve Terminal, but rather only for those combinations where both Valves are each "part of" the Valve Terminal, and even then only for those Valves whose Position Numbers are only 1 integer different.

For Valves, in other words, which are adjacent.

Now here's where it gets wild. Let's imagine that our Valve Terminal consists of sixty-four different Valve Positions. The beauty of this pattern is that it gets us directly to all "instances" of adjacent Valves.

The reason it's so horribly performance-intensive, however, is because, in order to get us directly to the adjacent Valves, it first has to search through every single Valve pair combination.

And that's the not exactly trivial number of 64 * 64 comparisons. If we imagine that we have many Dependencies between adjacent Valves, each single one of which requires stating a variant of the same pattern, we can easily start to see just how quickly we might run into problems.

Back to ADT's

When it comes to solving problems like these, Abstract Data Types offer two significant advantages. The first (first only because, as a modeler, I "like" it better) is maintainability. The second is performance.

First, let's explain what an "Abstract Data Type" is. It might sound imposing and difficult and esoteric, but it's really nothing more than this ... a Characteristic that can, during the course of a configuration session, point to an Instance of a Class.

In other words, it's a "reference."

Let's say that we've set the User Parameter that gives us Advanced Mode (to do it, just go into your User Parameters, enter a parameter "CFG" on the left-side of the table, and, as its value, on the right-side of the table, enter "SCE" ... you'll find, immediately after you do it, that a couple mysterious, unavailable checkboxes, scattered here and there throughout your maintenance transactions, are suddenly available).

We create ourselves a Characteristic called Valve_On_Left, and, when we define its format, we select ADT (this comes "new" with the User Parameter CFG=SCE). We are asked to choose a Class.

No big deal, we choose Class (300) Valve, and we make it single-valued, because, for every Valve, there will always be at most just one Valve immediately on its left.

Now we create ourselves another ADT Characteristic, this time called Valve_On_Right, and we choose again, as its "value" (i.e. its Class), the Class (300) Valve. We assign those two Characteristics to our Valve Class, and suddenly, presto!, we have an amazing new ability within our reach.

All we have to figure out is what it's actually good for.

First, in order to use it, we have to go back to the "pattern" we described above, because that's the only way we know, without anything else being given to us, which Valves are adjacent to which. We have to start somewhere ...

Objects:

?VT Is_a (300) Valve_Terminal,

?V1 Is_a (300) Valve,

?V2 Is_a (300) Valve.

Condition:

Part_of (?V1, ?VT) and

Part_of (?V2, ?VT) and

?V1.Position_Number = ?V2.Position_Number - 1.

Restrictions:

?V1.Valve_On_Right = ?V2,

?V2.Valve_On_Left = ?V1.

Inferences:

?V1.Valve_On_Right,

?V2.Valve_On_Left.

But fortunately, we only have to do it once. From now on, if we need to write a Dependency about the relationship between adjacent Valves, we need write nothing more in the "pattern" than this:

Objects:

?V1 Is_a (300) Valve

Where

?V2 = Valve_On_Right.

And if we need to say, for example, that the diameter of the air passage between the two of them has to be equal, we can say it as follows, in the entry on the left. For comparison purposes we include the Bill-of-Material based constraint too.

 

ADT-based Comparison BOM Position-based Comparison

Objects:

?V1 Is_a (300) Valve

Where

?V2 = Valve_On_Right.

Restrictions:

?V1.Air_Flow_Diameter =

?V2.Air_Flow_Diameter.

Inferences:

?V1.Air_Flow_Diameter,

?V2.Air_Flow_Diameter.

Objects:

?VT Is_a (300) Valve_Terminal,

?V1 Is_a (300) Valve,

?V2 Is_a (300) Valve.

Condition:

Part_of (?V1, ?VT) and

Part_of (?V2, ?VT) and

?V1.Position_Number =

?V2.Position_Number - 1.

Restrictions:

?V1.Air_Flow_Diameter =

?V2.Air_Flow_Diameter.

Inferences:

?V1.Air_Flow_Diameter,

?V2.Air_Flow_Diameter.

It's pretty obvious from the two, I think, which is the more intuitively obvious. For the Product Modeler that's a really nice benefit.

But it brings an enormous benefit for our End-Users (not to mention our Managers, and thereby us) too. That's performance.

Last week we described a comparison between the IPC and the LO-VC, in terms of how they process exactly the same model, if the model makes extensive use of constraints. And we saw how the IPC brought huge benefits, relative to performance.

Bear in mind, though, and again, that in the case of this Valve Terminal model in Classical Mode, and even in the IPC, any constraint that checks the adjacency of two Valves has to perform a test of each Valve against each other Valve, a test which has to happen 64 * 64 times.

And we might potentially have many tests based on adjacency.

If we use ADT's, however, we perform the ugly BOM Position-based (64 * 64 times) constraint exactly once, in order to set our ADT Characteristic Values, and then we use the very simple Objects declaration, above, in all the rest of them.

And what we can rely on is the fact that, for every subsequent test of adjacency for any individual Valve, the Pattern-Matching System has to perform exactly one test.

That's just one test, in contrast to 4,096 of them.

Conclusion

Now the Valve example might be extreme, but it certainly serves the purpose. If you've got a complex configuration ... and many, many SAP customers do ... then you can easily benefit from Advanced Mode, even if you don't have "solutions," or "systems," or "bottom-up" configuration.

It's there, it's in the system, and ... if you've got ERP2005, you've got it.

There's absolutely no reason ... no good reason that I can think of, at any rate ... not to take advantage of it.

Please send comments to Henk Meeter, Managing Editor, at henry.meeter@integrity-gmbh.de.