How You Write Extension Rule Text

The Groovy Scripting Language

The Groovy language provides a convenient means of writing scripts for extension rules.

Groovy is object-oriented and dynamically compiled. It can be used as a scripting language for the Java platform. Groovy is widely described elsewhere, at http://groovy-lang.org, and other public sources.

For writing extension rule scripts, some relevant features of Groovy are:

Many base Java packages are automatically imported, so that you don't have to import them in your scripts.
You can declare variables with the def keyword, without having to declare their type.
You can define methods and variables outside a class. They're considered as global within the script. Global definitions are executed within the built-in class ScriptClass, and executed under the built-in method run().
Some advantages to placing methods and variables in classes are:
- You can use encapsulation and inheritance.
- You can build complex logic, as in Java.
- Organizing methods in classes makes it easier to select them from the Class and Method lists when adding event bindings.
Advantages to not placing methods and variables in classes include:
- If you don't use classes, you can write code and test your code more quickly, simply adding and running code bound to the global class ScriptClass and the global method run().

Accessing Important Configurator Objects

Certain objects in the Configurator runtime core package provide access to the objects most commonly needed during a configuration session.

When an extension rule runs, the Configurator framework automatically initializes an object that represents the event specified by the event binding of the rule. This object is an instance of the interface ICXEvent named cxEvent.

The following table presents the objects most commonly needed during a configuration session. For each object, the table provides:

A short description of the object
The Java interface containing methods to access that object
A short example of code that creates an instance of the object
A short example of code that uses an instance of the object

Object	Entity Accessed	Interface Used	Example of Creating the Object	Example of Using the Object
Configurator event	The event specified by an event binding in the rule.	`ICXEvent`	No code needed. The object `cxEvent` is created automatically when the rule runs.	Get the current configuration associated with the event that triggered the rule. `IConfiguration config = cxEvent.getConfiguration()`
Base node of rule	The base node associated with the rule.	`ICXEvent`	Get the base node of the rule triggered by a bound event. `def baseNode = cxEvent.getBaseNode()`	Test whether the base node of the rule is selected by the end user. `if (baseNode.isSelected()) ...`
Configuration	The active configuration during a session.	`IConfiguration`	Get the configuration affected by the rule triggered by a bound event. `IConfiguration config = cxEvent.getConfiguration()`	Get the root node of the item-based model currently being configured. `def root = config.getRootBomModel()`
Root node of model	The root node of the model being configured.	`IBomModelInstance`	Get the root node of the item-based model currently being configured. `IBomModelInstance root = config.getRootBomModel()`	Get a child node of the current model, using its item name to search the model tree, starting from its root node. `def childItem = root.getChildByName("CM85010")`

Interacting with Model Node Values

You can get, and set, the values and states of model nodes using the interfaces described here.

The following table presents the objects that represent the types of nodes in a configurator model. For each object, the table provides:

The Java interface containing methods to access that object
The prototype of a method for getting the current value or state of the object.
The prototype of a method for setting a new value or state for the object.
Note that Groovy can derive data types when they're used at run time, so it's not strictly necessary to declare return types in your script. However, it's a good practice to understand the objects and interfaces involved in your model interactions.

The interfaces of the Configurator API also provide many other interfaces and methods for other types of interactions with node objects. This table provides an introduction to methods that are useful for common operations. For details, see the Java API Reference for Oracle Fusion Configurator.

Object	Interface	Get Value	Set Value
Integer feature	IIntegerFeature	`int getValue()`	`void setIntValue(int value)`
Decimal feature	IDecimalFeature	`double getValue()`	`void setDecimalValue(double value)`
Option of option feature	IOptionFeature	`IOption getSelectedOption()`	`void select()`
Boolean feature	IBooleanFeature	`boolean isSelected()`	`void toggle()`

Other Model Interactions

You can perform a variety of important interactions with model nodes using the interfaces described here.

Getting and Setting Logic States
Accessing properties
Access to options
Overriding contradictions
Handling logical contradictions
Handling exceptions

Reference Documentation for Available Classes

The package containing the classes for interacting with configurator is oracle.apps.scm.configurator.runtime.core.

The reference documentation for the interfaces in that package that you use in writing extension rule scripts is the Java API Reference for Oracle Fusion Configurator.

Some members of supported classes and interfaces aren't supported for use in extension rules, and their use will cause an error upon compilation. Unsupported members are omitted from the API reference documentation. If your script refers to a class or member that's not available for use in extension rules, a validation message identifies the invalid reference.