com.katharsys.pub.cx
Class SetInstanceCount

java.lang.Object
  extended bycom.katharsys.pub.cx.SetInstanceCount

public class SetInstanceCount
extends java.lang.Object

The SetInstanceCount CX contains a method for setting the number of instances of a ComponentSet based on the current state of another model node. The CX will either create additional instances or delete existing instances so that the new instance count matches the desired number of instances determined by the other model node.

The CX also contains a method for tracking user changes to the model so that if a LogicalException is thrown while trying to change the instance count, the CX can undo the offending change.

Rule Definition
Model Node Select the model node that will drive the instance count
Java Class com.katharsys.pub.cx.SetInstanceCount
Java Class Instantiation With Model Node Instance

Author:
Ken Truesdale, Katharsys LLC

Constructor Summary
SetInstanceCount()
           
 
Method Summary
 void setInstanceCount(oracle.apps.cz.cio.IRuntimeNode qtyNode, oracle.apps.cz.cio.ComponentSet compSet)
          Sets the quantity of instances of a component set based on another model node.
 void trackRequests(oracle.apps.cz.cio.IRuntimeNode baseNode)
          Tracks the user changes in the configuration in case the main setInstanceCount method failed to complete the instance count change due to a LogicalException.
 
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
 

Constructor Detail

SetInstanceCount

public SetInstanceCount()
Method Detail

setInstanceCount

public void setInstanceCount(oracle.apps.cz.cio.IRuntimeNode qtyNode,
                             oracle.apps.cz.cio.ComponentSet compSet)

Sets the quantity of instances of a component set based on another model node. If there are fewer component instances than the model node requires, additional instances are added. If there are too many component instances, component instances are removed, starting with the last component instance in the set and moving backward.

The model node that controls the instance count can be an integer node or a state node. If the node is an integer, the instance count will be changed to the value specified by the integer; when the value is zero, there are no instances and when the value is greater than zero, the instance count matches the number. (Note that negative values are treated as zero for purposes of this CX.) If the node is a state node, there will be one component instance when the node is true and zero component instances when the node is false or unknown. Decimal nodes are not permitted since the rounding operation would be undefined; but you can create an integer node which gets the appropriately rounded value from a decimal node through a numeric rule and use that integer node to drive this CX. (If the node is not an IntegerNode and it is not a StateNode, the whole CX is ignored.)

This CX is best used when not showing the users the control for adding new instances to the component set or removing existing instances. Nothing will break, but the naming convention will end up out of sync with the number of instances. Generally speaking, if you are going to set up a model where a user can manually create or delete instances, you don't want to have a CX setting the instance count. If you have a model where the instances are primarily hidden from the user then this CX is the right tool for managing the instance count.

Since this CX is merely an automation of what a user could do manually, the CX is subject to the same restrictions as manual creation would be including the maximum number of instances in a component set. If the CX tries to violate a maximum, a LogicalException is generated which the CX traps and undoes any instances that were attempted to be created. The model node that drives the instance count will be left with the incompatible value! This is because at the time that the CX is firing, the model node's new value has already been accepted by the engine. If you believe that your users might run into a max violation (or any other violation), see the trackRequests method below for a way to attempt to undo the model node change.

This CX is a way to mange the behavior that R12.1 now includes in the Fusion Configuration Engine (FCE). If your model uses the FCE, you should use the standard model behavior instead of this CX.

Event Binding
Event postValueChange
Scope Base Node
Method setInstanceCount
Argument Binding(s)
Arg 1 Argument Type IRuntimeNode
Argument Name qtyNode
Argument Specification System Parameter
Binding <BaseNodeOfRule>
Arg 2 Argument Type ComponentSet
Argument Name compSet
Argument Specification Model Node
Binding the Component Set node whose instance count will be managed by this CX


trackRequests

public void trackRequests(oracle.apps.cz.cio.IRuntimeNode baseNode)

Tracks the user changes in the configuration in case the main setInstanceCount method failed to complete the instance count change due to a LogicalException.

This method doesn't do anything visibly but merely tracks changes to the Configuration.

This method does the best it can to undo states but in certain cases it will fail. In particular, you should avoid a numeric feature into which a user can directly enter a value and which is contributed to by another node - in those cases, the "undone" value will likely be the difference between the user entered value and the contributed value. It would be better to have the instance count driven off a feature that is not visible to the user but which can be contributed by a field that the user enters.

Event Binding
Event onConfigValidate
Scope Global
Method trackRequests
Argument Binding(s)
Arg 1 Argument Type IRuntimeNode
Argument Name qtyNode
Argument Specification System Parameter
Binding <BaseNodeOfRule>



Copyright © 2010 Katharsys LLC. All Rights Reserved. Implementation-Version: 0.1-b46