Variable Nodes
Paul Campbell 23 February 2010 09:25:14 AM
Variable nodes are nodes that can be used as temporary storage areas on the Schema so that decision designers can make use of temporary nodes that are not defined in the supplied Schema itself. Because these nodes are not known to the interface schemas they do not affect the calling program.Conceptual Implementation
Variable Nodes:
· Names cannot contain spaces, or start with numbers or punctuation characters (including the ‘@’ character used at the start of attribute names in Decision Manager).
· Cannot share the same name as another variable or ‘real’ node on the same level.
· Can take on the following data types: Boolean, DateTime, Decimal, Integer, and String.
· Can be either repeating or non-repeating.
· Can contain child variable nodes.
· Are always output/decision nodes.
· Do not appear in the final output document unless they were created prior to the document being received by the Decision Server.
From the decision designer’s perspective, you can treat a variable node exactly the same way as you would treat a regular Customized Schema node within the Decision or Formula palettes.
Variable nodes must be instantiated by a decision group or decision that uses one of the node creation actions (Create / CreateIfNecessary / AlwaysCreate).
Creating Variable Nodes
The implementation of variable nodes is driven from the Schema Administration screen (Tools | Schema Administration). Users are able to add custom nodes of a data type of their choosing from the Node Visibility tree view.
This functionality is also available from within the Import Schema Wizard during the “Select Visibility Nodes” step.
By right clicking on a node in the Visibility Tree View, users are presented with an extra menu item that allows them to add a variable node.
The node will initially be editable so that the user can immediately choose a new name for the variable node.
Once a variable node is created, the user can then right click on it to edit the node itself to set data type and cardinality.
NOTE:
Only complex schema nodes are allowed to have variable nodes, this a limitation imposed by the inherent structure of XML documents (i.e. Attribute nodes cannot have child nodes and simple (data typed) elements cannot have children according to the Schema standard).
The same will go for any variable nodes that are going to contain child variable nodes; they will have to be created as complex (no data type) variable nodes, and if they are typed, they cannot contain child nodes.
There is one scenario in which variable nodes can become a child node of a non-complex node. This is the result of source schemas overwriting variable nodes, and will be explained later.
Variable Node Properties
Repeating: When selected, this make the Variable Node into a Repeating node. The icon on the tree view will change to reflect this, and the “Repeating” menu-item will be available.
To switch the node back to a non-repeating node, simply uncheck the “Repeating” option.
Boolean / DateTime / Decimal / Integer / String
These menu-items simply change the data type of the specified variable node. Selecting one of these data types will uncheck any other data type previously selected. When any of these data types are selected, the “Add Variable Node” menu-item becomes disabled.
NOTE:
All of these data type options are disabled if the variable node itself has child nodes, implying that it is a complex (no data type) node.
No Data Type
“No Data Type” pertains to the node being a “complex” node in XmlSchema terminology. When selected, any previously selected data type becomes unchecked, and the “Add Variable Node” menu-item becomes available.
Removing Variable Nodes
Removing nodes is performed simply by selecting the “Delete” menu item from the context menu obtained by right clicking on a Variable node. A confirmation dialogue is presented to the user to ensure that they do not do this accidentally. When any node variable has any one of its ancestors removed, it too is removed.
Node deletion implications
Any deletions that 'break' the repository are handled immediately via the Schema Maintenance function, which is invoked when required when the user attempts to save the modified Customized Schema. This is the same process that happens when the user attempts to remove a regular Customized Schema node that is being used by a Decision/Decision Group/Formula/UDO as its context.
Renaming Variable Nodes
Renaming nodes is performed by selecting the “Rename” menu item from the context menu obtained by right clicking on a Variable node (or via pressing F2 key on the keyboard while the desired variable node is selected).
Node rename implications
Any references to nodes in a Customized Schema is done via a node’s XPath - this is no different for variable nodes. This means that if any variable node is renamed, it will break any existing context sensitive operation, as well as orphan any Decision/Decision Group/Formula/UDO using it. This is similar to actually deleting the node itself and would traditionally be handled via the Schema Maintenance component.
Since we know which nodes are being renamed, any existing contexts are automatically updated to point to the ‘new’ variable node. To keep things simple, we continue to keep Schema Maintenance involved to solve any additional problems to do with changed data types and node multiplicity:
1. User renames variable nodes that are currently in use then attempts to save.
2. If context sensitive operations using that variable node can be updated without requiring Schema Maintenance, the Customized Schema and entities are updated automatically.
3. If Schema Maintenance Validation deems that maintenance is required, the user will have to manually perform Schema Maintenance.
Moving/Maintaining Variable Nodes
Schema Administration now supports dragging and dropping of variable nodes to allow users to relocate any variable nodes.
Undo/Redo Support
Users are able to undo/redo all of their node changes. This can be accessed via the Ctrl-Z and Ctrl-Y shortcut keys, as well as two buttons on the toolbar.
Node Visibility View
Users are able to switch between Node Visibility and Output views without losing any of the variable nodes they have created. They are unable to “uncheck” the visibility of variable nodes themselves (there will be no checkbox); however, if an ancestor Customized Schema node of a variable node is unchecked, the variable node itself is automatically unchecked (vice versa if the ancestor is visible again, the variable node will be too).
Output Nodes View
Variable nodes will always be output nodes and hence will have no checkboxes; users will not be able to change the output node setting on variable nodes in this view.
Variable Node Appearance
Schema Tree Views
On Schema tree views, variable nodes will be identified with the following:
Node Fore Color:
Example:
Source Schema Updates
Schema updates have a chance of using the same names as variable nodes, as well as using different data types than what is specified on a variable node itself.
When this happens the variable node gets replaced by the schema defined node, however, any variable nodes that were previously attached to the replaced variable node, are attached to the schema defined node, regardless of whether it is a complex node or not. This will be up to the user to resolve if they wish to do so.
Schema Maintenance is then launched if necessary to resolve any conflicts, and the Repository Validator (Repository | Release) can then be used to report anything else that may not be handled by Schema Maintenance.
Copy Operator
As far as the Decision Server and the Copy operator is concerned, it will treat Variable nodes as “defined in the (customized) schema” by copying variable nodes as well.
Debugger + Input Document Builder
Variable nodes can be created in the input document builder like any other Customized Schema node, and used with the Decision Model inline-tester/debugger. However, this still means that only the nodes that were created pre-execution will remain available after the Decision Model executes. Any updates done to these existing variable nodes will be visible though.
Repository Template and SubLicenses
Schema Administration is now available to sub-licensees when logged on as the System Administrator. Sub-licenses will be able to create/rename/remove variable nodes of their own and save over the existing customized schema.
Every other function of Schema Administration is disabled for sub-licensees. Other concepts of repository templates remains the same, i.e. Variable nodes can be reclaimed or relinquished by the template repository.
- Comments [0]