Welcome to the IDIOM Decision Products Knowledgebase.

alt
 



Recent Comments

    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.

    Image:Variable Nodes

    This functionality is also available from within the Import Schema Wizard during the “Select Visibility Nodes” step.

    Image:Variable Nodes

    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.

    Image:Variable Nodes

    The node will initially be editable so that the user can immediately choose a new name for the variable node.

    Image:Variable Nodes         Image:Variable Nodes

    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.

     Image:Variable Nodes

    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.

    Image:Variable Nodes                Image:Variable Nodes

    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.

    Image:Variable Nodes        Image:Variable Nodes

    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).

    Image:Variable Nodes                Image:Variable Nodes

    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:         Image:Variable Nodes 

    Example:                Image:Variable Nodes

    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.