Corticon

CORTICON
Business Rules Modeling Studio 5.2 Quick Reference Guide
Studio 5.2 Quick Reference Guide
Page ii
TABLE OF CONTENTS
Table Of Contents ....................................................................................................................................................... ii Preface ........................................................................................................................................................................7 Intended Audience .................................................................................................................................................7 System Requirements ............................................................................................................................................7 Technical Support...................................................................................................................................................7 Corticon Business Rules Management Product Documentation ...........................................................................7 Using the Business Rules Modeling Studio.................................................................................................................8 Installation..............................................................................................................................................................8 Studio Components................................................................................................................................................8 File Suffixes ........................................................................................................................................................8 Starting Studio........................................................................................................................................................9 Initial Toolbar .....................................................................................................................................................9 Initial Menubar Options.................................................................................................................................. 10 File Menu .................................................................................................................................................... 10 Edit Menu ................................................................................................................................................... 11 Project Menu .............................................................................................................................................. 12 Vocabulary, Rulesheet, Ruleflow, Ruletest Menus .................................................................................... 12 Window Menu ............................................................................................................................................ 12 Help Menu .................................................................................................................................................. 13 The File Tab ..................................................................................................................................................... 13 The Active Studio Window.............................................................................................................................. 14 Window Tabs .............................................................................................................................................. 14 File Naming Restrictions ................................................................................................................................. 14 Importing Studio Files from Earlier Versions .................................................................................................. 15 The Rule Project ...................................................................................................................................................... 16 Creating a Rule Project ........................................................................................................................................ 16 The Rule Project Explorer Window ................................................................................................................. 17 The Vocabulary ........................................................................................................................................................ 19 The Vocabulary.................................................................................................................................................... 19 Creating a Vocabulary ......................................................................................................................................... 19 The Vocabulary Window ..................................................................................................................................... 20 Vocabulary Menubar Options......................................................................................................................... 21 File Menu .................................................................................................................................................... 21 Edit.............................................................................................................................................................. 21 Search Menu............................................................................................................................................... 21 Project Menu .............................................................................................................................................. 21 Vocabulary Menu ....................................................................................................................................... 21 Window Menu ............................................................................................................................................ 22 Help Menu .................................................................................................................................................. 22 Vocabulary Toolbar ......................................................................................................................................... 22 Context-Sensitive Right-Click Pop-up Menu ................................................................................................... 23 Populating a New Vocabulary ............................................................................................................................. 23
Copyright 2000-2012 Progress Software Corporation. All rights reserved. January 13, 2012
Page iii
The Vocabulary Tree View .............................................................................................................................. 23 Vocabulary Properties .................................................................................................................................... 24 Vocabulary Node Naming Restrictions ........................................................................................................... 24 Adding Nodes to the Vocabulary Tree View ................................................................................................... 25 Domain Nodes: Adding and Editing Domains and their Properties ........................................................... 25 Entity Nodes: Adding and Editing Entities and their Properties.............................................................. 26 Attribute Nodes Adding and Editing Attributes and their Properties ..................................................... 27 Association Nodes: Adding and Editing Associations and their Properties................................................ 28 Editing an Association ................................................................................................................................ 30 Renaming a Vocabulary Node .................................................................................................................... 30 Saving a New Vocabulary................................................................................................................................ 31 Opening an Existing Vocabulary ..................................................................................................................... 31 Modifying a Vocabulary .................................................................................................................................. 32 Creating a Vocabulary Report ......................................................................................................................... 32 The Rulesheet .......................................................................................................................................................... 33 Rulesheet Window .............................................................................................................................................. 33 Creating a New Rulesheet............................................................................................................................... 34 Rulesheet Menubar ........................................................................................................................................ 36 File Menu .................................................................................................................................................... 36 Edit Menu ................................................................................................................................................... 36 Search Menu............................................................................................................................................... 36 Project Menu .............................................................................................................................................. 36 Rulesheet Menu ......................................................................................................................................... 36 Window Menu ............................................................................................................................................ 39 Help Menu .................................................................................................................................................. 39 Rulesheet toolbar ........................................................................................................................................... 39 Context-Sensitive Right-Click Pop-up Menus ................................................................................................. 40 Rulesheet Tab Pop-up Menu ...................................................................................................................... 40 Rulesheet Pop-up Menu - Row................................................................................................................... 41 Rulesheet Pop-up Menu - Column ............................................................................................................. 42 Rulesheet Sections .......................................................................................................................................... 42 Scope .......................................................................................................................................................... 42 Filters .......................................................................................................................................................... 43 Nonconditional Rules ................................................................................................................................. 43 Rules ........................................................................................................................................................... 44 Rule Statements Window ............................................................................................................................... 44 Ref............................................................................................................................................................... 45 ID ................................................................................................................................................................ 46 Post ............................................................................................................................................................. 46 Alias ............................................................................................................................................................ 46 Text ............................................................................................................................................................. 46 Rule Name .................................................................................................................................................. 46 Rule Link ..................................................................................................................................................... 46 Source Name .............................................................................................................................................. 47 Source Link ................................................................................................................................................. 47 Category ..................................................................................................................................................... 47 Comments .................................................................................................................................................. 47
Page iv
Using the Business Vocabulary to Build Rules ................................................................................................ 47 Using the Operator Vocabulary to Build Rules ............................................................................................... 47 Literal Terms, Functions & Operations ....................................................................................................... 47 Naming Rulesheets ......................................................................................................................................... 48 Deleting Rulesheets ........................................................................................................................................ 48 Saving a New Rulesheet .................................................................................................................................. 49 Validating and Optimizing a Rulesheet ........................................................................................................... 49 Creating a Rulesheet Report ........................................................................................................................... 50 Closing a Rulesheet ......................................................................................................................................... 50 Saving a Modified Rulesheet .......................................................................................................................... 50 The Ruleflow ............................................................................................................................................................ 51 Ruleflow Window ................................................................................................................................................ 51 Creating a New Ruleflow ................................................................................................................................ 51 Naming Ruleflows ........................................................................................................................................... 53 Adding Ruleflows ............................................................................................................................................ 53 Deleting Ruleflows .......................................................................................................................................... 53 Saving a New Ruleflow.................................................................................................................................... 54 Ruleflow Menubar .......................................................................................................................................... 54 File Menu .................................................................................................................................................... 54 Edit Menu ................................................................................................................................................... 54 Search Menu............................................................................................................................................... 54 Project Menu .............................................................................................................................................. 54 Ruleflow Menu ........................................................................................................................................... 54 Window Menu ............................................................................................................................................ 54 Help Menu .................................................................................................................................................. 54 Ruleflow toolbar ............................................................................................................................................. 55 Context-Sensitive Right-Click Pop-up Menus ................................................................................................. 55 Ruleflow Tab Pop-up Menu ........................................................................................................................ 55 Ruleflow Window Pop-up Menu ................................................................................................................ 55 Ruleflow Object Pop-up Menu ................................................................................................................... 58 Ruleflow Window............................................................................................................................................ 59 Rulesheets .................................................................................................................................................. 59 Connectors ................................................................................................................................................. 59 Subflows ..................................................................................................................................................... 60 Service Call-Outs ......................................................................................................................................... 60 Iteration .......................................................................................................................................................... 60 Enabling & Disabling Iteration for Rulesheets............................................................................................ 60 Enabling and Disabling Iteration for Subflows ........................................................................................... 61 Ruleflow Tools Palette .................................................................................................................................... 61 Renaming a Ruleflow and/or Saving a Ruleflow to a Different Location ....................................................... 62 Creating a Ruleflow Report ............................................................................................................................. 62 Closing a Ruleflow ........................................................................................................................................... 63 Ruleflow Properties Tab ...................................................................................................................................... 63 Ruleflow Sub-tab............................................................................................................................................. 64 Rule Vocabulary .......................................................................................................................................... 64 Work Document Entity ............................................................................................................................... 64 Major and Minor Version Numbers ........................................................................................................... 64
Page v
Version Label .............................................................................................................................................. 64 Effective and Expiration Dates ................................................................................................................... 64 Total Number of Rules................................................................................................................................ 65 Comments Sub-tab ......................................................................................................................................... 65 Rulers & Grid Sub-tab ..................................................................................................................................... 66 The Ruletest............................................................................................................................................................. 67 The Ruletest Window .......................................................................................................................................... 67 Creating a New Ruletest ................................................................................................................................. 67 Ruletest Menubar ........................................................................................................................................... 70 File Menu .................................................................................................................................................... 70 Edit Menu ................................................................................................................................................... 70 Search Menu............................................................................................................................................... 70 Project Menu .............................................................................................................................................. 70 Ruletest Menu ............................................................................................................................................ 70 Window Menu ................................................................................................................................................ 73 Help Menu ...................................................................................................................................................... 73 Ruletest Toolbar.............................................................................................................................................. 73 Context-Sensitive Right-Click Pop-up Menus ................................................................................................. 74 Ruletest Tab Pop-up Menu Options ........................................................................................................... 74 Testsheet Window Pop-up Menu Options ................................................................................................. 74 Sample Testsheet Node Pop-up Menu....................................................................................................... 75 Testsheet Tabs ................................................................................................................................................ 75 Populating the Input Panel ............................................................................................................................. 75 Adding Entities to the Test Tree ................................................................................................................. 76 Creating Associations in the Test Tree ....................................................................................................... 76 Assigning Attribute Values in the Test Tree ............................................................................................... 77 Automatically Generating a Test Tree ........................................................................................................ 77 Executing Tests ............................................................................................................................................... 78 Sequence of Message Posting ........................................................................................................................ 79 Sorting Messages ............................................................................................................................................ 79 Using the Expected Panel ............................................................................................................................... 79 Expected Panel Output Results Match Expected Exactly ........................................................................ 80 Expected Panel Different Values Output than Expected......................................................................... 80 Expected Panel Fewer Values Output than Expected ............................................................................. 81 Expected Panel - More Values Output than Expected ............................................................................... 81 Expected Panel All Problems ................................................................................................................... 82 Format of Output Data ................................................................................................................................... 82 Creating Multiple Test Scenarios on the Same Testsheet .............................................................................. 83 Creating Multiple Test Scenarios as a Set of Testsheets ................................................................................ 84 Creating a Sequential Test Using Multiple Testsheets ................................................................................... 84 Naming Testsheets ......................................................................................................................................... 86 Adding Testsheets........................................................................................................................................... 86 Associating One Child Entity with More Than One Parent ............................................................................. 88 Saving Ruletests .............................................................................................................................................. 89 Importing an XML or SOAP Document to a Testsheet.................................................................................... 89 Exporting a Testsheet to an XML Document .................................................................................................. 90 A Sample Testsheet Exported to XML ........................................................................................................ 90
Page vi
Exporting a Testsheet to a SOAP Message ..................................................................................................... 90 Creating a Ruletest Report.............................................................................................................................. 91 Exiting Corticon Studio ........................................................................................................................................ 91 Appendix A: Keyboard Shortcuts Available in Studio ............................................................................................. 93 Appendix B: Corticon Studio and Server 5.2 Technical Publications ...................................................................... 94
Copyright 2000-2012 Progress Software Corporation. All rights reserved.
January 13, 2012
Page 7
PREFACE
INTENDED AUDIENCE
The Studio Quick Reference Guide briefly describes the main features of Studio, where they are located in the user interface and how to use them. It is intended for use by anyone who models business rules using Studio. This document assumes that you have a general understanding of your Windows environment. For assistance with Windows basic commands not fully described in this manual, please consult your Microsoft Windows manual or online help system. Additional documentation may also be found at www.microsoft.com.
SYSTEM REQUIREMENTS
Corticon Studio 5.2 requires: Microsoft Windows 2000, XP, Vista, 7 32-bit (64-bit compatible) The Eclipse plug-in version requires Eclipse 3.5.2 or above Java Runtime Engine 1.6.0 or higher (included)
Hardware requirements include: Pentium M-class CPU or higher 512 MB RAM (1 GB recommended) 200 MB disk space (full install)
TECHNICAL SUPPORT
For Corticon Business Rules Management product support, call +1 650.212.2424 ext 200, or email support@corticon.com.
CORTICON BUSINESS RULES MANAGEMENT PRODUCT DOCUMENTATION

For a detailed listing of current Corticon Business Rules Management technical publications for this product, see Appendix B.
January 13, 2012
Page 8
USING THE BUSINESS RULES MODELING STUDIO

INSTALLATION
To install Corticon Business Rules Modeling Studio software, please refer to the Studio Installation Guide for complete details.
STUDIO COMPONENTS
Studio files consist of four major types: 1. Vocabulary: a structured dictionary containing all necessary business terms and relationships between them used by the business rules. 2. Rulesheet: a set of conditions and actions and plain language statements written from a common business Vocabulary. 3. Ruleflow: a set of one or more Rulesheets organized for sequential execution. Once a Ruleflow has been saved and deployed to the Business Rules Server, it is called a Decision Service. 4. Ruletest: a set of one or more Testsheets containing sample data used for testing Rulesheets and Ruleflows. Like Rulesheets, Ruletests also use a common Vocabulary model. A Rule Project may contain any number of Vocabularies, Rulesheets, Ruleflows or Ruletests. Following construction and testing within Studio, a Rulesheet must be saved before it can be tested by a Ruletest. Ruleflows must be saved before they can be deployed to Corticon Server. Deployment and integration is covered in greater detail in the Server Integration & Deployment Guide. A quick introduction to this topic is provided in the Server Deployment Tutorial.
File Suffixes
The four types of files listed above have the following file types or file suffixes:
.ecore the Vocabulary. .ers the Rulesheet. Multiple Rulesheets may use the same Vocabulary, but each
Rulesheet has only one associated Vocabulary.

.erf the Ruleflow. One Ruleflow may contain multiple Rulesheets, each of which
has only one associated Vocabulary.

.ert the Ruletest. A Ruletest may test either a Rulesheet (in Studio only) or a
Ruleflow.
January 13, 2012
Page 9
STARTING STUDIO
Initial Toolbar
The initial Studio toolbar displays the basic tools that you will need to create a new Vocabulary, Rulesheet, Ruleflow, or Ruletest files, or open existing files. At this point, many of the menubar options and toolbar buttons have limited functionality, but they will be described here because they are options which are commonly available to all open files.
Creates a new Corticon Studio 5.2 resource (also called an asset). Create a new Rule Project Create a new Rule Vocabulary Create a new Ruleflow. Create a new Rulesheet Create a new Ruletest Create a new Folder Saves any changes to the active file Prints the active file Disables the selection Moves a Custom Data Type (CDT) enumerated Label/Value row up in the list. See the Rule Modeling Guides Building the Vocabulary chapter for more info on CDTs. Moves a Custom Data Type (CDT) enumerated Label/Value row down in the list. See the Rule Modeling Guides Building the Vocabulary chapter for more info on CDTs. Inserts a new Column into the active file Removes the selected Column(s) from the active file Inserts 15 Columns at the end of the active file Inserts a new Row into the active file Removes the selected Row from the active file Inserts 15 Rows at the end of the active file
January 13, 2012
Page 10
Initial Menubar Options

The following menubar options are available when you start Studio for the first time or have no files open: File Menu New > Rule Project Rule Vocabulary Ruleflow Rulesheet Ruletest New Folder Open File Close Creates a new Corticon Studio 5.2 resource. Create a new Rule Project. Create a new Rule Vocabulary. Create a new Ruleflow. Create a new Rulesheet Create a new Ruletest Create a new Folder. Opens an existing Vocabulary, Rulesheet, Ruleflow or Ruletest. Closes the open Vocabulary, Rulesheet, Ruleflow or Ruletest. This option is grayed out when no files are open. Closes all open files. This option is grayed out when no files are open. Saves an open, modified file. This option is grayed out when no files are open. Allows you to save the file to a different location or with a different name. This option is grayed out when no files are open. Saves all open, modified files. This option is grayed out when no files are open. Revert to the previously saved version of a file. This option is grayed out when no files are open. Moves the active file to a new location. This option is grayed out when no files are open. Renames the currently active file. This option is grayed out when no files are open. Updates and refreshes the file list within the Rule Project Explorer window.
Close All Save Save As
Save All Revert Move Rename Refresh
January 13, 2012
Page 11
This option is grayed out when no files are open. Print Switch Workspace Allows you to print the currently active file. This option is grayed out when no files are open. Displays the Workspace Launcher dialog box, which allows you to navigate to projects stored in Workspaces other than the default Corticon Workspace directory. Allows you to import resources, including Corticon 4.x assets, from your file system into an existing project. See Importing Files from Earlier Versions. Allows you to export Corticon 5.2 resources to your local file system. Displays a Properties dialog for the open Vocabulary. This option is grayed out when no files are open. As files are opened and closed, a running list of the previous 4 files will be displayed here. Clicking a file name will open it. Closes all open Studio components and exits the application.
Import
Export Properties Recent File List
Exit
Edit Menu Undo Redo Cut Copy Paste Delete Select All Insert Row Remove Row Add Rows to End Insert Column Remove Column Undoes the previous action Re-performs the previous action after if it was undone Cuts the selection and places it in the Clipboard Copies the selection into the Clipboard Pastes the contents of the Clipboard Deletes the selection Applicable to Ruleflows only. See Ruleflow section. Inserts a new Row into the active file Removes the selected Row from the active file Inserts 15 Rows at the end of the active file Inserts a new Column into the active file Removes the selected Column(s) from the active file
January 13, 2012
Page 12
Add Columns to End Move Up
Inserts 15 Columns at the end of the active file Moves a Custom Data Type (CDT) enumerated Label/Value row up in the list. See the Rule Modeling Guides Building the Vocabulary chapter for more info on CDTs. Moves a Custom Data Type (CDT) enumerated Label/Value row down in the list. See the Rule Modeling Guides Building the Vocabulary chapter for more info on CDTs. Disables the selection Disabled in Corticon 5.2
Move Down
Disable Find/Replace Project Menu Open Project Close Project
Opens a closed Rule Project selected in the Rule Project Explorer window Closes a Rule Project selected in the Rule Project Explorer window.
Vocabulary, Rulesheet, Ruleflow, Ruletest Menus These menus appear in the toolbar when the various Studio files are active. Each of these is described in the sections that follow. Window Menu Open Perspective Rule Modeling Other Resets the Studio layout to the default windows most commonly used during modeling If you have created and saved custom perspectives, you can open them in the list displayed when this option is selected Opens the Error Log window Opens the Localization window Opens the Problems window Opens the Properties window for the active file Opens the Rule Messages window
January 13, 2012
Show View > Error Log Localization Problems Properties Rule Messages
Page 13
Rule Operators Rule Project Explorer Rule Statements Rule Vocabulary Other Customize Perspective Save Perspective As Reset Perspective Close Perspective Close All Perspectives Preferences
Opens the Rule Operators window Opens the Rule Project Explorer window Opens the Rule Statements window Opens the Rule Vocabulary window Allows you to customize some of the menus and options Allows you to arrange the windows within Studio and save their layout. Resets the Studio layout to the default windows Closes the open perspective Closes all open perspectives Allows switching between Rule Modeling and Integration Deployment modes of Studio. Integration Deployment mode includes all functionality of Rule Modeling mode plus the ability to map Vocabularies to external data such as XML and Java business objects. Locating and loading your Studio license is also performed in this window.
Help Menu Key Assist Contents About Displays a pop-up menu of shortcut keys that can be utilized within Studio. Displays the Studio Online Help. Displays Studio product, version, build, and copyright information.
The File Tab

When you create a new or open an existing Vocabulary, Rulesheet, Ruleflow, or Ruletest, a tab is displayed at the top of each window. Multiple tabs will be arranged horizontally underneath the Studio toolbar when multiple files are open at once. Shown is the name of the window and
Page 14
the windows controls. 1. 2. 3. 4. File type and name Minimize the files window Maximize files window Close the files window
The Active Studio Window

Throughout this manual, reference will be made to the active Studio window. Any single open window in Studio may be active at a given time. Indication of active status is provided by the windows tab color. As shown below, the active windows tab is colored blue, while inactive tabs are colored gray. Shifting focus or, in other words, activating a different window, is accomplished simply by clicking anywhere within an inactive window or on the windows tab. Below, the tabs of two Studio windows, tutorial_example.erf (a Ruleflow) and Untitled.ers (a Rulesheet) are shown tiled horizontally. tutorial_example.erf is the active window because its tab is blue.
Window Tabs Each window tab contains information about the windows status: This window is the active Studio file, and its save status is up-to-date This window is not active. Clicking on it will cause it to become active This window is the active Studio file, but recent changes have not yet been saved. As soon as the file is saved, the asterisk before the windows tab name will disappear. The small red square overlaying the windows file type icon indicates there is an error somewhere in the window. Look in the Problems window for more information (Window>Show View>Problems in the Studio menubar) The small yellow triangle overlaying the windows file type icon indicates there is a warning somewhere in the window. Look in the Problems window for more information (Window>Show View>Problems in the Studio menubar)
File Naming Restrictions

File names must comply with the following rules:
Page 15
File names may contain or start with almost any alphanumeric character and most special characters - the Save or Save As dialog will inform you if you choose a prohibited character, as shown below. File names may not begin with a space, but may contain spaces in subsequent character positions.
Importing Studio Files from Earlier Versions

Studio version 5.x has an import/upgrade feature that allows you to migrate files from older versions of Studio to the current version. Use the File>Import menu option to launch a wizard that will guide you through the process. When importing files from prior versions, we recommend first upgrading to the most recent release of the major version youre currently using first before migrating to version 5. For example, if youre currently using Studio 4.1, we recommend upgrading your files to the most recent version of the 4.x family (which, as of this writing, is 4.3 SR2) before migrating to 5.2. This 2step upgrade process will help to ensure that all the language changes that have occurred between 4.1 and 5.2 are incorporated in the final migrated files. After migration, we recommend fully testing your files to ensure correct behavior.
January 13, 2012
Page 16
THE RULE PROJECT

In Corticon Studio 5.2, a Vocabulary, as well as any Ruleflows, Rulesheets and Ruletests associated with that Vocabulary, must be stored in a Rule Project. By default, Studio provides you with a new directory, called workspace, to store your Projects in. Although you can create Rule Project folders linked to directories anywhere on your local file system and view them in Studio, we recommend that you use the default path provided: <corticon_install_dir>\Studio \workspace. When you upgrade to later versions of Studio, your Rule Projects will remain and survive the upgrade process intact. Other directory locations in the file system may need to be re-linked to a Rule Project when new versions of Studio are installed.
CREATING A RULE PROJECT

Follow these steps to create a new Rule Project: Select File>New>Rule Project from the menubar
Or, click the down arrow to the right of the New icon Project.
on the toolbar and select Rule
Either method will launch the New Project wizard, shown below.
January 13, 2012
Page 17
Make sure the Use default location checkbox is checked 1 and enter a name for your project in the Project name field. Notice that the path to your new Rule Project is automatically appended to Studios default workspace folder to define its Location. Click Finish to create your new Rule Project.
The Rule Project Explorer Window

The Rule Project you just created should now be displayed in the Rule Project Explorer window within Studio. The Rule Project Explorer window provides a convenient way of navigating between your Studio files, including Vocabularies, Rulesheets, Ruleflows, and Ruletests. Doubleclicking on a highlighted file in the list shown in the Rule Project Explorer window below will cause the file to open and become the active window in Studio. Our new Example_Project, shown below, is empty, so there are no files available to open yet.
You can also choose to create your new Project in a different Workspace by using the Browse button to locate and select it. January 13, 2012
Page 18
Now that we have created a Rule Project, we can turn our attention to creating a Vocabulary that well use to model our Business Rules.
January 13, 2012
Page 19
THE VOCABULARY
THE VOCABULARY
A Vocabulary is used to build rule models in a Rulesheet or test cases in a Ruletest (see the Rulesheet and Ruletest sections of this manual). Once a Vocabulary is open, other Studio options, including a Vocabulary option in the menubar and relevant toolbar icons, become available. Vocabulary files have the file suffix .ecore.
CREATING A VOCABULARY
Well use the same general process to create a new Vocabulary that we used to create our first new Rule Project. Follow these steps to create a new Vocabulary: 1. Select File>New>Rule Vocabulary from the Studio menubar OR 2. click the down arrow to the right of the New icon select Rule Vocabulary. on the Studio toolbar and
Either method will launch the Create a New Vocabulary wizard, illustrated below.
January 13, 2012
Page 20
3. Select the parent Rule Project for the new Vocabulary by highlighting the Example_Project folder we just created. 4. Enter a name for the new Vocabulary in the File name field. It is not necessary to type the file extension .ecore (we used Cargo here). 5. Click Finish to create your new Vocabulary. It is now displayed in the new Rule Vocabulary window (A), in the Rule Project Explorer window (B), and as the open file and active tab in the Cargo.ecore window (C). The window sizes have been adjusted to fit on the page.
C B
THE VOCABULARY WINDOW

Page 21
The Vocabulary window, i.e., the window with a tab containing the name of your Vocabulary file (C, above), provides all the tools you need to create a new or modify an existing Vocabulary.
Vocabulary Menubar Options

The following menubar options are available when the Vocabulary window (C above) is the active window (blue tab, as above) File Menu These options are the same as for the initial Studio Edit These options are the same as for the initial Studio Search Menu These options are the same as for the initial Studio Project Menu These options are the same as for the initial Studio Vocabulary Menu
Add Domain Adds a Domain to the Vocabulary. Domains are a new feature in 5.0 and are discussed in more detail in the Rule Modeling Guide. Adds an Entity to the Vocabulary Adds an Attribute to an Entity (once created) Adds an Association between two Entities (once created) Usable only when Studio is in Integration Deployment mode. Used to map external Java business objects to your Vocabulary nodes. See Server Integration & Deployment Guide for full details Import Java Class Metadata
Add Entity Add Attribute Add Association Java Object Messaging
imports Java object metadata from a specified jar file.
January 13, 2012
Studio 5.2 Quick Reference Guide Clear Java Class Metadata Localize
Page 22
removes imported Java class metadata from memory

Allows you to set the Language parameter (Locale) for the Vocabulary and displays the Vocabularys elements in a list. Creates an HTML report and launches your browser for viewing. See Creating a Vocabulary Report.
Report
Window Menu These options are the same as for the initial Studio Help Menu These options are the same as for the initial Studio
Vocabulary Toolbar
When a Vocabulary window is active, the following additional options become available on the toolbar:
Same as Vocabulary>Add Domain in the menubar. Same as Vocabulary>Add Entity in the menubar. Same as Vocabulary>Add Attribute. Same as Vocabulary>Add Association in the menubar.
The Creating a Vocabulary chapter in the Rule Modeling Guide contains more details on the Vocabulary modeling process, including the use of these options.
January 13, 2012
Page 23
Context-Sensitive Right-Click Pop-up Menu

In addition to the menubar and toolbar functions described above, Studio also provides many Vocabulary functions within a convenient right-click pop-up menu. A sample Vocabulary Editor Pop-up menu is displayed to the right. The right-click pop-up menus are contextsensitive, meaning not all options are available for all Vocabulary nodes. For example, the Add Attribute option is only available when an Entity is selected in the Vocabulary tree.
POPULATING A NEW VOCABULARY

The discussion in this section assumes Vocabulary creation and editing is conducted while in Studios Rule Modeling mode. Features such as XML and Java Object mapping require Integration Deployment mode, which is covered in detail in the Server Integration & Deployment Guide.
The Vocabulary Tree View

All elements of a Vocabulary are referred to generically as nodes, and these nodes are arranged in the Vocabulary window in a hierarchical, or tree view. When a new Vocabulary is displayed in its window, the tree view is empty with the exception of the Vocabularys name node. The name node contains the name of the Vocabulary and a open book icon to its left, as show below:
January 13, 2012
Page 24
Vocabulary Properties
Each type of node in the Vocabulary (including the name) has its own types of properties. These properties are displayed immediately to the right of the node simply by clicking on the node name or icon.
The Vocabularys name node properties consist of Custom Data Types definitions. Please refer to the Building the Vocabulary chapter of the Rule Modeling Guide for complete details regarding the creation and use of Custom Data Types.
Vocabulary Node Naming Restrictions

Following are some guidelines that you should use when creating new nodes in the Vocabulary: Domain, Entity, Attribute, and Association Role node names may only contain the following alphanumeric characters: letters, numbers, and underscores. However: Domain, Entity, Attribute, and Association Role node names may not begin with a number. Spaces are not allowed in Domain, Entity, Attribute or Association node names. If the desired name is composed of multiple words, then underscore characters may be used to combine them in a single-word name. Domain, Entity, Attribute, and Association Role node names may begin with an underscore. Domain, Entity, Attribute, and Association Role node names may begin with either an upper or lower case letter.
No two Entities in the same Domain may have the same node name (caseinsensitive).
January 13, 2012
Page 25
Names of Operators (e.g., sum, size, month, now, today, etc.) or Extended Operators (if any) may not be used as Entity or Domain node names. They may be used as Attribute or Association Role node names. Custom Data Type names may not use the names of any of the base data types (e.g., string, decimal, boolean, etc.). See the Rule Modeling Guides chapter Creating the Vocabulary for more information about Custom Data Types. Names of aliases in the Scope section may not match (case-sensitive) the node names of Entities in the Vocabulary. No two Attributes/Association Role nodes in the same Entity may have the same name (case-insensitive). No two Domains within another Domain may have the same node name (caseinsensitive). No two root-level Domains may have the same node name (case-insensitive).
Adding Nodes to the Vocabulary Tree View

Domain Nodes: Adding and Editing Domains and their Properties The purpose of Domains is explained in more detail in the Rule Modeling Guide, Creating the Vocabulary chapter. Generally, if all your Entity names are unique, you wont need to use Domains in your Vocabulary. To add a Domain node: 1. Select the name node in the Vocabulary tree view, which is the one with the icon. 2. Right-click to display the pop-up menu and choose Add Domain OR Choose Vocabulary>Add Domain from the menubar. 3. Select the new Domain node in the Vocabulary tree to display its properties. 4. Assign a Name for the new Domain in the Property Value column to the right, as shown below. Or, double-click the new Domain node in the tree view to edit the default Domain_1 value. Your changes in either location will be updated in both.
January 13, 2012
Page 26
Entity Nodes: Adding and Editing Entities and their Properties 1. Select the name node in the Vocabulary tree to add a new Entity node to the root level of the tree. Or, select the newly created Domain node to add a new Entity to the Domain. 2. Right-click to display the pop-up menu and choose Add Entity OR Choose Vocabulary>Add Entity from the menubar OR Choose from the toolbar 3. Select the Entity in the Vocabulary tree to display its properties. 4. Assign property values as shown below:
Note: this window is shown as it appears when in Rule Modeling mode. Integration Deployment mode adds fields which are explained in the Server Integration & Deployment Guide. Property Entity Name Value Assign a name to the entity. By default, this will be prefilled as Entity_x, where x is an automatically determined unique number. As with Domains, double-clicking the node in the tree view will also open an editing box. Name changes made in either the node or the property will update in both places Not used in Studio 5.2. Optional. The Vocabulary model contains extensive support for inheritance concepts. For more information on using this feature, please refer to the Rule Modeling Guide, Creating the Vocabulary chapter.
Entity Identity Inherits From
Other properties are visible while in Integration Deployment mode; see the Server Integration & Deployment Guide for details.
January 13, 2012
Page 27
Attribute Nodes Adding and Editing Attributes and their Properties 1. Select any Entity node in the Vocabulary tree view. 2. Right-click to display the pop-up menu and choose Add Attribute OR Choose Vocabulary>Add Attribute from the menubar OR Choose from the toolbar 3. Select an Attribute on the Vocabulary tree view to display its properties. 4. Assign property values as described in the following table.
Note: this window is shown as it appears when in Rule Modeling mode. Integration Deployment mode adds fields which are explained in the Server Integration & Deployment Guide. Property Attribute Name Value Assign a name to the new Attribute. As with Domain and Entity nodes, double-clicking the node in the tree view will also open an editing box. Name changes made in either the node or the property will update in both places Enter the data type of the attribute. The default value is String. Other available data types: Boolean, Decimal, DateTime, Date, Integer and Time. All types are described in the Rule Language Guide and in the Rule Modeling Guides Creating the Vocabulary chapter. A mandatory attribute cannot have a value of null. This setting affects the members of the values sets shown in Rulesheet drop-downs. For example, an attribute whose Mandatory value is No will always include a null value selection in its Rulesheet drop-downs. Choose the attributes Mode from the drop-down list. Base attributes exist or are used by systems outside Corticon, and are included in the XML schemas and contracts generated by the Deployment Console. Base attributes map directly to an element in the XML CorticonRequest/Response documents or object properties processed by the Server in production. Extended Transient attributes are derived fields; they exist only during rule execution and are not part of XML schemas generated by the Deployment Console. They do not need to be included in the XML
January 13, 2012
Data Type
Mandatory
Mode
Page 28
CorticonRequest documents or objects, and they are not included in the XML CorticonResponse documents or objects produced by the Server in deployment. Likewise, they cannot be dragged into a Ruletests Input column because they are created as output. Extended Persistent attributes refer to a special technical feature described in the examples found in
<corticon_install_dir>\Samples\Dynamic Schema.
Association Nodes: Adding and Editing Associations and their Properties To add a new Association node: 1. Select an Entity in the Vocabulary tree view. 2. Right-click to display the pop-up menu and choose Add Association. OR Choose Vocabulary>Add Association from the menubar. OR Choose from the toolbar. 3. Complete the Association window as shown in the following table: Note: this window is shown as it appears when in Rule Modeling mode. Integration Deployment mode adds fields which are explained in the Server Integration & Deployment Guide. Property Source Entity Name Value An association relates two entities. Studio refers to one entity as the source and the other as the target. Choose the name of the supplier from the drop-down list, which includes the entity names already defined in this Vocabulary. Choose the name of the 2nd entity the target entity from the drop down list. Select the combination of radio buttons that describe the desired relationship between the two entities. The possible combinations are: One-To-Many. This is the default and is shown as 1* in the properties. This means that a given instance of the supplier entity may be related to multiple instances of the target entity. In the Vocabulary tree view, a one-to-many association is shown by the icon to the right.
Target Entity Name Cardinality Radio Buttons
Page 29
One-To-One. This is shown as 11. This means that a given instance of the supplier entity may be related to a single instance of the target entity. In the Vocabulary tree view, a one-to-one association is shown by the icon to the right. Many-To-One. This is shown as *1. This means that multiple instances of the supplier entity may be related to a single instance of the target entity. In the Vocabulary tree view, a many-to-one association is shown by the icon to the right. Many-To-Many. This is shown as **. This means that multiple instances of the supplier entity may be related to multiple instances of the target entity. In the Vocabulary tree view, a many-to-many association is shown by the icon to the right. Mandatory. Also known as optionality. Select this box if at least one instance of the source or target MUST be present in data sent to the Corticon Server to be processed by rules using this Vocabulary. Role Names Role names are useful when two entities share more than one association. Custom role names can give each association a unique, descriptive name. Source-To-Target provides a name for the association from the perspective of the source entity. Target-To-Source provides a name for the association from the perspective of the target entity. Bidirectional. Select Bidirectional if you want the association to be traversable (visible) in both directions within the Vocabulary. This means that associations between two entities are visible from each entity in the Vocabulary tree view. This option provides the most flexibility when writing rules. Source Entity Target Entity. Use this option to prevent the association from the Target entity to the Source entity from being displayed in the Vocabulary tree view. This option prevents a rule from being written using the scope
Target_entity.source_entity.attribute.
Navigability
Source Entity Target Entity. Use this option to prevent the association from the Source entity to the Target entity from being displayed in the Vocabulary tree view. This prevents a rule from being written using the scope
Source_entity.target_entity.attribute.
See the Rule Modeling Guide for more information on using associations in rule modeling.
January 13, 2012
Page 30
Editing an Association 1. Select an association on the Vocabulary tree to display its properties. 2. Edit properties as described above.
Renaming a Vocabulary Node 1. Double-click on the node name or icon to display an editing box. 2. Type the desired new node name and press Enter.
January 13, 2012
Page 31
Saving a New Vocabulary

1. Save the Vocabulary from the toolbar or choose File>Save from the menubar to save any changes you have made. OR Use File>Save As on the menubar and Navigate to the directory where you want to store the Vocabulary, or click to create a new directory. 2. Type any name, including embedded blanks (max. of 36 characters) in length, and click Save. 3. See File Naming Restrictions for naming restrictions.
Opening an Existing Vocabulary

1. Choose File>Open File from the Studio menubar or use the toolbar to display the Open window. 2. Navigate to the directory where the desired Vocabulary is stored. 3. Select the appropriate .ecore file and choose Open.
January 13, 2012
Page 32
Modifying a Vocabulary
1. Highlight the Vocabulary Editor tab to enter edit mode. 2. Select any node to display its properties. 3. Modify node properties as described above.
Creating a Vocabulary Report

1. Choose Vocabulary>Report from the menubar. 2. If your local machine has a web browser installed, the HTML report should open as a new web page. 3. Studio will save the report file to C:\Documents and Settings\<your username>\Local Settings\Temp using the name format CorticonVocabularyXXXXX.html, where XXXXX is a unique auto-generated number. You can save the HTML to a different name or location from the browser. 4. For information about creating custom reports or saving them to custom locations, see the Studio Reporting Framework chapter of the Rule Modeling Guide.
January 13, 2012
Page 33
THE RULESHEET
A Rulesheet is a file that contains a set of business rules. By organizing these rules, it becomes a self-contained, independent unit of automated decision-making. A Rule Project can include any number of Rulesheets. Following test and validation, one or more Rulesheets may be packaged in a Ruleflow (see The Ruleflow chapter) and deployed into a production environment (described in the Server Integration & Deployment Guide). Once packaged in a Ruleflow and deployed and available to other IT systems, we refer to the Ruleflow as a Decision Service. Because a Rule Project may contain multiple Rulesheets, there are two methods of navigating between open Rulesheets within Studio: Double-clicking on any Rulesheet name in the Rule Project Explorer window opens that Rulesheet and makes it active. Clicking on any Rulesheet tab makes that Rulesheet active.
Multiple Rulesheets may be open in Studio simultaneously, although only one may be active at any given time. A Rulesheet file has the suffix .ers.
RULESHEET WINDOW
Opening a Rulesheet or making a Rulesheet the active Studio window causes the Studio menubar and toolbar to display the tools needed to begin working with rules.
January 13, 2012
Page 34
Creating a New Rulesheet

Creating Rulesheets involves the same general process as described in Creating a Rule Project and Creating a Vocabulary. Follow these steps to create a new Rulesheet: 1. Choose File>New>Rulesheet from the menubar OR 2. Click the down arrow next to the New icon on the toolbar and select Rulesheet. Either method will launch the Create a New Rulesheet wizard.
3. Highlight the Rule Project you would like to associate the new Rulesheet with in the list (or enter it manually in the Enter or select parent folder: field. 4. Enter a file name for the Rulesheet in the File name: field. Click Next > to continue.
January 13, 2012
Page 35
The Create New Rulesheet Wizard window
5. In this step you must select the Vocabulary to associate the Rulesheet to. A Rulesheet can only be associated with one Vocabulary. Here, we simply expand the Example_Project folder and highlight the Cargo.ecore file we created earlier. As you create additional Vocabulary files within a Rule Project, they become available for selection from this list.
January 13, 2012
Page 36
6. Accept the default Presentation Metaphor of Decision Table and click Finish. Your new Rulesheet is now displayed in the Rule Project Explorer window (A) and in a new Rulesheet window with a tab of the given name (B).
A new Rulesheet as it appears in Studio
A Rulesheet menubar and toolbar replace the Vocabulary menubar and toolbar and you are now ready to begin modeling your rules.
Rulesheet Menubar
Many of the functions provided by the menubar are also accessible through the toolbar. When a menubar option has an equivalent toolbar icon, the icon is shown alongside. File Menu These options are the same as for the Vocabulary file type Edit Menu These options are the same as for the Vocabulary file type Search Menu These options are the same as for the Vocabulary file type Project Menu These options are the same as for the Vocabulary file type Rulesheet Menu Logical Analysis >
January 13, 2012
Page 37
Execution Sequence Diagram
Creates a graphic that shows the execution sequence of the rules in the active Rulesheet. Your default graphic viewer should launch to display the diagram, and a copy of the file will be saved to
<corticon_install_dir>\Studio\plugins\c om.corticon.services_5.2.0\DepGraph
Logical Dependency Graph
Creates a graphic that shows the logical dependencies of the data created in the Rulesheet. This is different than an Execution Sequence Diagram in that it does not show the sequence of rule execution. Your default graphic viewer should launch to display the diagram, and a copy of the file will be saved to
<corticon_install_dir>\Studio\plugins\c om.corticon.services_5.2.0\DepGraph
Clear Analysis Results Check for Logical Loops Check for Completeness Check for Conflicts Enable Conflict Filter Previous Conflict
Removes highlighting that resulted from checking for conflicts and completeness. Performs logical loop detection across all rules in all Rulesheets in the active Project. Highlights incompleteness in the active Rulesheet. Highlights conflict between two or more rules in the active Rulesheet. A toggle that either hides or shows all rule columns not part of the current conflict. Highlights the previous conflict in the sequence. This option is grayed out until you perform a conflict check. Highlights the next conflict in the sequence. This option is grayed out until you perform a conflict check. Highlights the first conflict in the sequence. This option is grayed out until you perform a conflict check. Highlights the last conflict in the sequence. This option is grayed out until you perform a conflict check. Advanced functionality described in the Rule Modeling Guide, Dependency & Looping chapter
Next Conflict
First Conflict
Last Conflict
Rule Column(s) > Use Conditions as Processing
January 13, 2012
Page 38
Threshold Expand Rules Collapse Rules Compress Rules Creates multiple simple rules from each complex rule. Reverses the Expand Rules function. Detects overlapping conditions between rules and combines columns to produce a smaller number, but logically equivalent, set of rule columns. Causes rule columns that have been expanded into component rules (also called sub-rules) to be renumbered from left to right. A toggle that switches between the advanced and simple Rulesheet views.
Renumber Rules
Simple/Advanced View Filters > Precondition
Preconditions are Filter expressions that stop Rulesheet execution if not satisfied by at least one piece
of data. For more information, see the Filters chapter of the Rule Modeling Guide.
Minimum Filter
Applies only to Filter expressions, enabling behavior described in the Filters chapter of the Rule Modeling Guide. Default. This option affects the active Rulesheet only. Causes rules to execute without re-evaluation or reexecution (no looping). For more information about this processing mode, see the Rule Modeling Guide. Allows only multi-rule inter-dependencies to reevaluate and re-execute. This option affects the active Rulesheet only. For more information about this processing mode, see the Rule Modeling Guide. Allows all rule dependencies (including selfdependencies) to re-evaluate and re-execute. This option affects the active Rulesheet only. For more information about this processing mode, see the Rule Modeling Guide. Opens the Rulesheet localization window. See the Localization section of the Rule Modeling Guide for more information. Creates an HTML report and launches your browser for viewing. See Creating a Rulesheet Report.
Processing Mode Optimized Inferencing
Advanced Inferencing
Advanced Inferencing with Self-Triggering
Localize
Report
January 13, 2012
Page 39
Window Menu These options are the same as for the Vocabulary file type Help Menu These options are the same as for the Vocabulary file type
Rulesheet toolbar
Many of the functions provided by the toolbar are also accessible through the menubar.
Toggles to the advanced or simple Rulesheet views. New Rulesheets are initially shown in the simple view. Natural Language view. Clicking this icon will enable Natural Language view of the active Rulesheet. See the Rule Modeling Guide for more information about this feature. Expands conditions and actions to display all component rules (those containing no dashes). Same as menubar option Rulesheet>Rule Column(s)>Expand Rules. Collapses conditions and actions to hide component rules and show only general rules (those containing dashes). Same as menubar option Rulesheet>Rule Column(s)>Collapse Rules. Compresses conditions and actions to eliminate redundancies within general and component rules. Same as menubar option Rulesheet>Rule Column(s)>Compress Rules. Clears the colored highlights that appear when an conflict or completeness check is performed. Same as menubar option Rulesheet>Logical Analysis>Clear Analysis Results. Performs logical loop detection. Same as menubar option Rulesheet>Logical Analysis>Check for Logical Loops. Performs completeness check. Same as menubar option Rulesheet>Logical Analysis>Check for Completeness. Performs conflict check. Same as menubar option Rulesheet>Logical Analysis>Check for Conflicts. Highlights the first conflict in a set. This button is grayed out until you perform an conflict check. Same as menubar option Rulesheet>Logical Analysis>First Conflict. Highlights the previous conflict in a set. This button is grayed out until you perform an conflict check. Same as menubar option Rulesheet>Logical Analysis>Previous Conflict. Highlights the next conflict in a set. This button is grayed out until you perform an conflict check. Same as menubar option Rulesheet>Logical Analysis>Next Conflict. Highlights the last conflict in a set. This button is grayed out until you perform an conflict check. Same as menubar option Rulesheet>Logical Analysis>Last Conflict.
Page 40
Enables the conflict Filter, which hides all rule columns not part of the current conflict. This feature is a toggle the filter is disabled when the red funnel icon is visible. Same as menubar option Rulesheet>Logical Analysis>Conflict Filter. Once enabled, the conflict Filter icon appears like this. Same as menubar option Rulesheet>Logical Analysis>Conflict Filter. Click to disable.
Context-Sensitive Right-Click Pop-up Menus

In addition to the menubar and toolbar functions described above, Studio also provides many functions in convenient right-click pop-up menus. There are two types of rightclick pop-up menus that appear when working with Rulesheets: Rulesheet Tab Pop-up Menu appears when a Rulesheets tab is right-clicked. This menu provides quick access to many of the most frequently used Rulesheet-level functions. Rulesheet Pop-up Menu appears when a section within a Rulesheet is right-clicked. This menu provides quick access to many of the most frequently used Rulesheetlevel functions.
The options available in these pop-up menus depend on which Rulesheet section or section the mouse is over when it is right-clicked. Not all options are available for all sections. Rulesheet Tab Pop-up Menu The Rulesheet Tab Pop-up menu, appearing when a Rulesheet tab is right-clicked, is shown to the right. The right-click pop-up menus are context-sensitive, meaning not all options will be available at all times.
Restore Move Size Minimize Maximize Makes the entire Rulesheet window moveable for relocating into other sections of Studio Assists in resizing the Rulesheet window by providing highlighted bars for dragging. Collapses the entire Rulesheet window. Clicking the Rulesheet tab returns it to its original size and position Expands the Rulesheet window to fill the entire screen
January 13, 2012
Page 41
Close Close Others Close All New Editor
Closes the Rulesheet. You will be asked to save any changes Closes any other tabs that may be open. You will be asked to save any changes Closes all open Vocabulary, Rulesheet, Ruleflow, and Ruletest windows Opens a copy of the existing Rulesheet window
Many of the options in the Rulesheet Tab Pop-up Menu rearrange the Studio view, or perspective. If you want to revert to the original, default view, select Window>Reset Perspective from the Studio menubar. Rulesheet Pop-up Menu - Row Right-clicking in a row within a Rulesheet causes a pop-up menu to appear with the following options: A sample Rulesheet Pop-up menu when you right-click within a row is shown to the right. These options repeat several of those found in the Studio menubar and toolbar, as described previously.
The right-click pop-up menus are context-sensitive, meaning not all options are available for all active sections of the Rulesheet. For example, this pop-up menu displays options available for condition and action rows.
January 13, 2012
Page 42
Rulesheet Pop-up Menu - Column Right-clicking in a column within a Rulesheet causes a pop-up menu to appear with the following options: A sample Rulesheet Pop-up menu when you right-click within a column is shown to the right. These options repeat several of those found in the Studio menubar and toolbar, as described previously.
The right-click pop-up menus are context-sensitive, meaning not all options are available for all active sections of the Rulesheet. For example, this pop-up menu displays options available for condition and action columns.
Rulesheet Sections
The Rulesheet window is divided into several sections, each with a specific use in creating business rules. Scope This section is visible only when the Advanced View icon on the Studio toolbar is clicked.
Scope section, showing an Entity and its alias
The Scope section provides a reduced set of Vocabulary terms with which to
January 13, 2012
Page 43
build a Rulesheet. The Scope section can be populated directly by dragging and dropping Vocabulary elements into it, or indirectly, by dragging and dropping Vocabulary nodes onto other Rulesheet sections. Once a node is visible in the Scope section, it can be dragged and dropped to other Rulesheet sections henceforth. For those Entities in the Scope section, aliases can be defined by double-clicking the Entity to open an edit box. An alias replaces the fully qualified entity name wherever it is used in the Rulesheet, and serves as a sort of local name for use in that Rulesheet only. See the Rule Modeling Guide for details on scope, context and Rulesheet aliases. Filters This section is visible only when the Advanced View icon on the Studio toolbar is clicked.
Filters are boolean expressions 2 that are applied to data before rule columns are evaluated. Before using this section, we recommend reading the Filters chapter of the Rule Modeling Guide.
Nonconditional Rules This section is visible in all Rulesheet views, both Simple and Advanced
Column 0 in the Conditions/Actions section of the Rulesheet is special because the Conditions rows are grayed-out and unusable. Expressions may only be modeled in the Action rows. Logically, this means that all Actions modeled in Column 0 are unconditionally executed. In other words, no Conditions must be satisfied in order for these Actions to execute.
2
Boolean expressions are those expressions which resolve or reduce to a true or false answer. In other words, for given test data, the expression is either true or false. For more discussion of boolean expressions, see the Rule Language Guide January 13, 2012
Page 44
Each Action row in Column 0 acts as a separate, independent rule. In earlier versions of Corticon Studio, a separate Nonconditional Rules section contained this type of logic. In version 5.2, Nonconditional rules appear as Actions in Column 0. Each Action row constitutes a separate Nonconditional rule. Rules This section of the Rulesheet organizes Conditions, Values and Actions in a table format.
Conditions (quadrant 1) and Actions (quadrant 2) are organized in the decision table shown above. Sets of Conditions and Actions are tied together to form rules by the vertical columns spanning the two right quadrants (3 & 4) of this section. The cells in a vertical rule column (highlighted in blue) specify the Condition rows which must be satisfied (determined by the cell values in quadrant 3) necessary to execute or fire the Action rows (determined by the cell values in quadrant 4). The illustration above contains the model of the sample business rule: if a cargos volume is less than 300, then assign its packaging a value of Pallet.
Rule Statements Window

The Rule Statements window displays a list of natural language statements which describe the rules modeled in the Rulesheet. The Rule Statements window has several columns:
January 13, 2012
Page 45
Rule Statements serve as documentation or elaboration on the meaning and intent of business rules modeled in the Rulesheet. Linking the plain-language description of a business rule in the Rule Statement section to its formal model in the other sections can provide important insight into rule operation during testing and deployment. Here, rule statement #2 is an informal description of the rule logic modeled in the Rulesheet column #2, as shown above. When a Rule Statement row is clicked, the corresponding Columns or Action rows will highlight in orange in the Rulesheet. When a Rulesheet column is selected, the corresponding Rule Statement will highlight in orange. Ref This field is mandatory when linking Rule Statements to their Rulesheet columns (the rule models). Rule Statements have a many-to-many relationship with Rulesheet columns. In other words, a Rule Statement may be reused for multiple Columns, and multiple Rule Statements may be expressed for a single Column. Entries in the Ref column serve to establish the relationship between the Rule Statements and Rulesheet columns. The various options are summarized below: Ref 1 1:3 {1,3} 0 A0 B1 C1 A1:B2 { A1 , B2 } 1:B2 A:2 The Rule Statement is linked or connected to: Column 1 Columns 1,2 and 3 Columns 1 and 3 Column 0 Action Row A in Column 0 Action Row B in Column 1 Action Row C in Column 1 Action Rows A and B in Columns 1 and 2 Action Row A in Column 1 and Action Row B in Column 2 invalid invalid
January 13, 2012
Page 46
When a colon (:) character is used to indicate that a range of Action cells is linked to the Rule Statement, then the left-hand and right-hand sides of the : must have the same form: both [column][row], both [column], or both [row] values. When they do not, the values will turn red, as shown in the last two rows above. ID This column is optional. It allows you to link Rule Statements to external source documentation using a code or ID number. Post This field is mandatory if you want the Rule Statement to appear as a Rule Message during Rulesheet execution (called posting the Rule Statement). Three severity levels are available: Info, Warning, and Violation. These severity levels have no intrinsic meaning - you can use them however you want. In a Studio Ruletest, Rule Messages with Info severity are color-coded green, Warnings yellow, and Violations red. Alias This field is mandatory if you want the Rule Statement posted during Rulesheet execution. All posted Rule Messages must be attached or linked to a Vocabulary entity. The choice of entity to post to is usually based on the entity being tested or acted upon in the associated rule. Text Technically, this field is optional, but posting a Rule Statement with no text results in an empty Rule Message. In order to have a meaningful posted Rule Message, we recommend entering plain language business rule statement in this field. Even when you dont plan to post messages during Rulesheet execution, creating a clear, concise version of the rule model is considered a best practice in rule modeling. Rule Name This field is optional. It allows you to assign custom names to the Rule Statements and the rule models they link to. Rule Link This field is optional. When a rule model has external documentation, you can enter an absolute path to a file on your local system to link it to.
January 13, 2012
Page 47
Source Name This field is optional. It allows you to reference the name of the source material the rule originates from. Source Link This field is optional. It allows you to link to the source material the rule originates from using an absolute path to a local file. Category This field is optional. It allows you to assign a category name to each Rule Statement and the rule model it links to. Comments This field is optional. It allows you to enter any comments for this Rule Statement and rule model it links to.
Using the Business Vocabulary to Build Rules

Select the Rule Vocabulary tab; click the icon beside an entity to expand the node & view its tree structure. Then, drag the desired term and drop it onto the Rulesheet.
You can use either the TAB key to move from cell to cell within a row or the ARROW keys to move between rows within the Rulesheet grid. To move to another section in the Rulesheet, click on a cell within that section. Dragging and dropping is shown in this Guide as a dotted orange line, with an orange circle indicating the drag origin, and an orange diamond indicating the drag destination.
Using the Operator Vocabulary to Build Rules

Literal Terms, Functions & Operations Studios built-in library of operators is located (in the default Rule Modeling perspective) in the Rule Operators window in the lower left-hand corner of the Studio window. If this window tab is not visible, select Window>Show View>Rule Operators from the Studio menubar.
January 13, 2012
Page 48
Not all operators may be used in all types of rules or in all parts of the Rulesheet refer to the Rule Language Guide for complete details. 1. Click the General or Attribute Operators folders, or click the plus sign beside a category, to expand them. 2. Select the desired operator and drag and drop it onto the Rulesheet.
Naming Rulesheets
Rulesheets may be named when created and renamed by File>Save As
Deleting Rulesheets
Deleting Rulesheets is performed using one of the following methods: Right-click the Rulesheet in the Rule Project Explorer window and select Delete from the pop-up menu Select the Rulesheet in the Rule Project Explorer window and hit the Delete key.
January 13, 2012
Page 49
Saving a New Rulesheet

1. Save the Rulesheet using the menubar or toolbar as described previously. 2. Navigate to the Project folder where you want to store the Rulesheet. 3. The same file naming conventions apply to Rulesheets as apply to Vocabularies. See File Naming Restrictions.
Validating and Optimizing a Rulesheet

Conflict, Completeness, and Logical Loop Checkers, as well as the Compress Rules feature, are collectively known as validation and optimization functions. These topics are addressed briefly in the Basic Rule Modeling Tutorial, and in more depth in the Rule Modeling Guide. On very rare occasions, expanding, compressing or completing very large Rulesheets may cause Studio to run out of memory. If this occurs, try increasing Studios memory allotment by modifying the shortcut you used to launch Studio. Details on this procedure are included in the Studio Installation Guide, Changing Studio Memory Allocation section.
January 13, 2012
Page 50
Creating a Rulesheet Report

1. Choose Rulesheet>Report from the menubar. 2. If your local machine has a web browser installed, the HTML report should open as a new web page. 3. Studio will save the report file to C:\Documents and Settings\<your username>\Local Settings\Temp using the name format CorticonRulesheetXXXXX.html, where XXXXX is a unique auto-generated number. You can save the HTML to a different name or location from the browser. 4. For information about creating custom reports or saving them to custom locations, see the Studio Reporting Framework chapter of the Rule Modeling Guide.
Closing a Rulesheet
1. Close the Rulesheet using on its tab or the File>Close in the menubar. 2. Choose Yes to save any changes and close the file.
Saving a Modified Rulesheet

When you save a modified Rulesheet, the Studio automatically saves it to the current Rulesheet name. To save the Rulesheet to another name, choose File>Save As from the menubar.
January 13, 2012
Page 51
THE RULEFLOW
A Ruleflow is a way of aggregating and organizing Rulesheets into a single unit of automated decision-making. It is a flow diagram depicting a set of one or more Rulesheets that have been validated using tools introduced earlier in this manual. A Ruleflow may be assembled from as many Rulesheets as you want, provided that all the Rulesheets use the same Vocabulary file. In other words, a Ruleflow can have only one associated Vocabulary. Following test and validation, a Ruleflow may be deployed into a production environment (described in the Server Integration & Deployment Guide). Once deployed and available to other IT systems, we refer to a Ruleflow as a Decision Service. In Studio, an individual Rulesheet may be tested using a Ruletest. But in order to deploy a Rulesheet to Corticon Server, it must be packaged as a Ruleflow. Only Ruleflows are deployable to Corticon Server and invocable as Decision Services. The Ruleflow concept, new in Corticon Studio 5, is intended to facilitate Rulesheet reuse - any Rulesheet can be included in as many Ruleflows as desired. In earlier versions of Corticon Studio, reusing a Rulesheet required cutting and pasting, or recreating it, into multiple Rule Set files. Ruleflow files have the suffix .erf.
RULEFLOW WINDOW
Opening a Ruleflow or making a Ruleflow the active Studio window causes the Studio menubar and toolbar to display the tools needed to begin working with Ruleflows.
Creating a New Ruleflow

Creating Ruleflows is a simple process described in this section. Follow these steps to create a new Ruleflow: 1. Choose File>New>Ruleflow from the menubar or click the down arrow next to the New icon on the toolbar and select Ruleflow. Either method will launch the Create a New Ruleflow wizard.
January 13, 2012
Page 52
2. Highlight the Project you would like to associate the new Ruleflow with on the Project list (or enter it manually in the Enter or select parent folder: field. 3. Enter a file name for the Ruleflow in the File name: field. Click Next > to continue.
4. Select the Vocabulary to associate the Ruleflow to. A Ruleflow can only be associated with one Vocabulary. Here, we simply expand the Example_Project folder and highlight the Cargo.ecore file, which was created earlier in the Creating a Vocabulary section. As you create additional Vocabulary files within a Project they
Page 53
become available for selection from this list for use with this or other Ruleflows that you create.
A new Ruleflow as it appears in Studio
5. Your new Ruleflow is now displayed in the Rule Project Explorer window (A) and in a new Ruleflow window with tab of the given name (B). A Rulesheet menubar and toolbar replace the Vocabulary menubar and toolbar and you are now ready to begin modeling your rules.
Naming Ruleflows
As noted earlier, you name your Ruleflows during the Ruleflow creation process. As always, Ruleflow names, just like any other Studio files, must adhere to and comply with the guidelines shown in the File Naming Restrictions section of this document.
Adding Ruleflows
To add additional Ruleflows to a Rule Project, select File>New>Ruleflow from the menubar and repeat the steps recounted earlier in the Ruleflow creation process. Alternatively, you can select New>Ruleflow from the toolbar or highlight a file in the Rule Project Explorer file list and select New>Ruleflow from the pop-up menu to create additional Ruleflows.
Deleting Ruleflows
A Ruleflow can be deleted by highlighting it in the Rule Project Explorer file list and selecting Edit>Delete from the menubar, or by right-clicking the file in the Rule Project Explorer file list and selecting Delete from the pop-up menu.
January 13, 2012
Page 54
Saving a New Ruleflow

Select File>Save from the menubar or click the Save icon on the toolbar to save a new or modified Ruleflow. Refer to the following section for details regarding saving, or renaming, a Ruleflow with a different name or to a different file location.
Ruleflow Menubar
Many of the functions provided by the menubar are also accessible through the toolbar. When a menubar option has an equivalent toolbar icon, the icon is shown alongside. File Menu These options are the same as for the Vocabulary, Rulesheet, and Ruleflow file types Edit Menu With the following exception, these options are the same as for the Vocabulary, Rulesheet, and Ruleflow file types Select All Search Menu These options are the same as for the Vocabulary, Rulesheet, and Ruleflow file types Project Menu These options are the same as for the Vocabulary, Rulesheet, and Ruleflow file types Ruleflow Menu Properties Report Opens the Ruleflow properties window, usually at the bottom of the Studio window Creates an HTML report and launches your browser for viewing. See Creating a Ruleflow Report. Selects all Ruleflow objects
Window Menu These options are the same as for the Vocabulary, Rulesheet, and Ruleflow file types Help Menu These options are the same as for the Vocabulary, Rulesheet, and Ruleflow file types
January 13, 2012
Page 55
Ruleflow toolbar
A few special toolbar icons, shown below inside orange boxes, are inserted into the standard Studio toolbar when the Ruleflow is the active window. Many of the functions provided by the toolbar are also accessible through the menubar.
Opens the Ruleflow properties window, usually at the bottom of the Studio window Zooms the Ruleflow window to magnification selected

In addition to the menubar and toolbar functions described above, Studio also provides many functions in convenient right-click pop-up menus. There are two types of rightclick pop-up menus that appear when working with Ruleflows: Ruleflow Tab Pop-up Menu appears when a Ruleflows tab is right-clicked. This menu provides quick access to many of the most frequently used generic, windowlevel functions. Ruleflow Window Pop-up Menu appears when you right-click within the Ruleflow window. This menu provides quick access to many of the most frequently used Ruleflow-specific functions. Ruleflow Object Pop-up Menu appears when you right-click an object in the Ruleflow, such as a Rulesheet or a Connector.
The options available in these pop-up menus depend on where within the Ruleflow the mouse is when it is right-clicked. Ruleflow Tab Pop-up Menu The Ruleflow tab pop-up menu has the same options as the other tab pop-ups, including the Rulesheet. Ruleflow Window Pop-up Menu Right-clicking within a Ruleflow window will cause a pop-up menu to display with the following options:
January 13, 2012
Page 56
A sample Ruleflow Window Pop-up menu, that is displayed when you right-click within the Ruleflow window, is shown to the right.
All right-click pop-up menus are context-sensitive, meaning not all options are available for all active sections of the Ruleflow.
File > Save as Image File Print Select > All All Shapes All Connectors Arrange All View > Grid Ruler Page Breaks Recalculate Page Breaks Snap to Grid Same as Studio toolbar Selects objects as follows: Selects all objects in the Ruleflow Selects all shapes in the Ruleflow Selects all connectors in the Ruleflow Arrange all objects in the Ruleflow displays a light gray grid overlay in the Ruleflow window displays rulers on the X and Y axes of the Ruleflow window displays breaks in the Ruleflow window when the window is larger than the size of the page updates breaks when changes are made to the Ruleflow window assists in aligning Ruleflow shapes to the overlay grid (whether visible or not) displays a light gray grid overlay in the Ruleflow window
January 13, 2012
Page 57
Zoom > Zoom In Zoom Out Zoom to 100% Zoom to Fit Fit to Width Fit to Height Fit to Selection Align > Align Left Align Center Align Right Align Top Align Middle Align Bottom Auto Size Make Same Size Both Height Width Order > Bring to Front Send to Back Bring Forward
Changes the magnification of the Ruleflow diagram in the follow ways: increases magnification reduces magnification reverts to default magnification changes magnification to fit selection changes magnification to fit the selections width changes magnification to fit the selections height changes magnification to fit the selections height and width
Aligns the left edges of all selected objects Aligns the centerlines (vertically) of all selected objects Aligns the right edges of all selected objects Aligns the top edges of all selected objects Aligns the centerlines (horizontally) of all selected objects Aligns the bottom edges of all selected objects
Resizes selected Rulesheet block icons to be the same size Resizes selected Rulesheet block icons to be the same height Resizes selected Rulesheet block icons to be the same width Brings the selected object to the front of the diagram Sends the selected object to the back of the diagram Brings the selected object one level closer to the front of the diagram
January 13, 2012
Page 58
Send Backward
Sends the selected object one level further to the back of the diagram
Ruleflow Object Pop-up Menu Right-clicking within a Ruleflow window will cause a pop-up menu to display. The options available in the pop-up menu depend on the object selected, but most contain the following: A sample Ruleflow Object Pop-up menu, that is displayed when you right-click on a Ruleflow object, is shown to the right.
The right-click pop-up menus are context-sensitive, meaning not all options are available for all active sections of the Ruleflow. This pop-up menu displays options available for condition and action rows.
File > Save as Image File Align > Align Left Align Center Align Right Align Top Align Middle Align Bottom Auto Size Make Same Size Both Height Resizes selected Rulesheet block icons to be the same size Resizes selected Rulesheet block icons to be the same height Aligns the left edges of all selected objects Aligns the centerlines (vertically) of all selected objects Aligns the right edges of all selected objects Aligns the top edges of all selected objects Aligns the centerlines (horizontally) of all selected objects Aligns the bottom edges of all selected objects
January 13, 2012
Page 59
Width Order > Bring to Front Send to Back Bring Forward Send Backward
Resizes selected Rulesheet block icons to be the same width Brings the selected object to the front of the diagram Sends the selected object to the back of the diagram Brings the selected object one level closer to the front of the diagram Sends the selected object one level further to the back of the diagram
Ruleflow Window
Ruleflow diagrams are displayed within the Ruleflow window. The objects that comprise or populate a Ruleflow window include: Rulesheets Rulesheets are the core objects in a Ruleflow. By arranging and organizing Rulesheets in the Ruleflow, you can specify execution sequence of the Rulesheets and control the iteration (if desired) of the Rulesheets. Ruleflows serve as a kind of deployable container for Rulesheets. Rulesheets remain the basic unit of decision making, but they become much more reusable when combined in different ways in different Ruleflows. For example, Rulesheet sample.ers can be included in many Ruleflows, each of which may have its own use in different business processes or applications. This is a serviceoriented approach (SOA) to using Rulesheets, which is compatible with the SOA design practices commonly in use in modern IT system development. Rulesheets may be designated for iteration by clicking the iteration icon which appears when you hover the mouse cursor over a Rulesheet object in the Ruleflow window. Connectors Connectors are the objects that serve to connect or stitch Rulesheets together and control their sequence of execution. If a connector is drawn from Rulesheet sample1.ers to sample2.ers, then when a deployed Ruleflow is invoked, it will execute the rules in sample1.ers first, followed by the rules in sample2.ers.
January 13, 2012
Page 60
Subflows Subflows provide yet another level of reusability of Ruleflow objects. A Subflow may contain many Rulesheets and connectors - it essentially becomes a package of these objects that can be copied and pasted and re-used within the Ruleflow. Subflows may also be designated for iteration, so that all the objects in the Subflow are re-executed until the values derived by their constituent rules cease changing. Service Call-Outs Service Call-outs are a type of extension to a Ruleflow, and require significant Java development expertise. The method for building Service Call-outs is documented in detail in the Extensions User Guide. Service Call-outs are enabled by your Corticon license. If you do not see the Service Callout icon in your Studios Ruleflow editor palette (see below), then your license does not enable Service Call-outs.
Iteration
Iteration may be enabled for Rulesheet and Subflow objects in a Ruleflow. When an object is set to iterate, it will repeatedly re-execute until the values derived by the objects rules cease to change. Once values in the object cease changing, the iteration stops and execution continues to the next (as determined by the Connectors) object, which may be either another Rulesheet or Subflow. Enabling & Disabling Iteration for Rulesheets To enable iteration for Rulesheets, hover your mouse cursor over the Rulesheet block icon. You should see a circular icon appear in a call-out pop-up window. Move your mouse to click the circular icon, and the icon will appear inside the Rulesheet block icon, underneath the Rulesheets name label, as shown below:
enabling iteration for a Rulesheet
iteration enabled for a Rulesheet
To disable iteration, click on the circular icon and hit the Delete key.
January 13, 2012
Page 61
Enabling and Disabling Iteration for Subflows To enable iteration for Subflows, hover your mouse cursor over the Subflow blocks title section. You should see a circular icon appear in a call-out pop-up window. Move your mouse to click the circular icon, and the icon will appear near the bottom of the Subflow block icon. To disable iteration, click the circular icon and hit the Delete key Logical loop processing options within a Rulesheet do not result in a circular icon appearing on the Rulesheet object within the Ruleflow.
Ruleflow Tools Palette

The far right-hand column of the Ruleflow window contains the Ruleflow tools palette. The Ruleflow tools palette contains five tools: Select Allows you to select one or more diagram objects. You can select multiple objects by click-hold-dragging to surround the objects with the box that appears. Zoom Allows you to zoom in or out on a portion of the Ruleflow window. Connection Creates a flow link between two Rulesheets in a sequence. Select this tool and then use your mouse to drag a line from one Rulesheet rectangle to another, then release. Rulesheet Adds a Rulesheet to the Ruleflow window. Select this tool and use your mouse to drag a rectangular shape in the Ruleflow window. Iterative Allows you to designate individual or multiple Rulesheets or Subflows as iterative. Subflow Allows you to create Subflows within a Ruleflow window. Use your mouse to drag a rectangular shape in the Ruleflow window. If you want to include Rulesheets in your Subflow, be sure to drag and drop the Rulesheets into the Subflow rectangle. Dragging a new Subflow rectangle to surround existing Rulesheets will not include them in the Subflow. Service Call-out Service Call-outs are a type of extension to a Ruleflow, and require significant Java development expertise. The method for building Service Call-outs is documented in detail in the Extensions User Guide. Service Call-outs are enabled by your Corticon license. If you do not see the Service Call-out icon in your Studios Ruleflow editor palette, then your license does not enable Service Call-outs.
January 13, 2012
Page 62
Once a tool has been selected, it remains selected until you perform the action. To perform the same action again, re-select the tool.
Renaming a Ruleflow and/or Saving a Ruleflow to a Different Location

Selecting File>Save As from the menubar displays the Save As dialog, allowing you to assign the Ruleflow a different name or save it to another location. 1. To rename the Ruleflow, modify the name in the File name: field with the Project folder highlighted in the Project list. 2. To save the Ruleflow to a different location, whether you are renaming it or not, select that Project folder in the Project list or enter the parent folder name manually in the Enter or select the parent folder: text field. 3. The same file naming conventions apply to Rulesheets as apply to Rulesheets. See File Naming Restrictions.
Creating a Ruleflow Report

1. Choose Ruleflow>Report from the menubar. 2. If your local machine has a web browser installed, the HTML report should open as a new web page. 3. Studio will save the report file to C:\Documents and Settings\<your username>\Local Settings\Temp using the name format CorticonRuleflowXXXXX.html, where XXXXX is a unique auto-generated number. You can save the HTML to a different name or location from the browser. 4. For information about creating custom reports or saving them to custom locations, see the Studio Reporting Framework chapter of the Rule Modeling Guide.
January 13, 2012
Page 63
Closing a Ruleflow
1. Close a Ruleflow using the on the Ruleflow tab, by rightclicking the tab and selecting Close from the pop-up menu or by selecting File>Close on the menubar. 2. Choose Yes to save any changes if you have modified the Ruleflow in any way prior to closing it.
RULEFLOW PROPERTIES TAB

Ruleflow properties are set in the Properties tab at the bottom of the Studio window when a Ruleflow is the active file. This window is comprised of several sub-tabs arranged vertically at the left-hand side of the window. These sub-tabs are shown below in the orange box.
Assigning a Version Number to a Ruleflow
January 13, 2012
Page 64
Ruleflow Sub-tab
Rule Vocabulary Use this field to change the Vocabulary referenced by this Ruleflow. Notice that the location of the Rule Vocabulary associated with the Ruleflow is automatically entered for you in the Rule Vocabulary field. You can change this value by selecting Browse and choosing a different Vocabulary, if necessary. Work Document Entity The Work Document Entity drop-down menu allows you to choose from among the existing entities in your Vocabulary and designate one of them the Work Document Entity. The Work Document Entity provides the root for XML schemas generated in the Deployment Console. Rule Modelers generally need not be concerned with this setting, as it relates to the Ruleflow deployment on Corticon Server. Major and Minor Version Numbers Major Version numbers for Ruleflows are optional and are assigned manually. Minor Version numbers are automatically incremented each time a Ruleflow is saved. A Minor version number may also be incremented manually. When we use different version numbers to label identically named Ruleflows, the Server keeps them straight in memory, and responds correctly to requests for the different (Major) versions. In other words, an application or process can use (or call) different (Major) versions of the same Ruleflow simply by including the (Major) version number in the request message. The details of how this works at the Server level are technical in nature and are described in the Server Integration & Deployment Guide. A plain-text description of this version can be added in the Ruleflow Version Label field, immediately below the Ruleflow Minor Version field. Version numbers may be manually raised anytime but never lowered. Version Label Optional. Give the version a unique text label. Effective and Expiration Dates Effective and Expiration dates are optional for Ruleflows and can be assigned singly or in pairs. When we use different Effective and Expiration dates to describe identically named Ruleflows, the Server keeps them straight in memory, and responds correctly to requests for the different dates. In other words, an application or process can use
Page 65
different versions of the same Ruleflow depending on date criteria. The details of how this works at the Server level are technical in nature and are described in the Server Integration & Deployment Guide. Effective and Expiration Dates may be assigned using the same window as above. Clicking on the Effective Date or Expiration Date drop-down displays a calendar:
Setting Effective and Expiration Dates
Effective Date and Expiration Date Times are entered in their respective Time fields. Total Number of Rules Counts the total number of rules in all the Rulesheets included in this Ruleflow. For Column numbers 1 and higher, each enabled column is counted as one rule. For Column 0, each enabled Action row is counted as one rule.
Comments Sub-tab
Selecting the Comments link within the Properties window allows you to add comments to your Ruleflows, as shown below:
January 13, 2012
Page 66
The Ruleflow Comments Sub-tab
Rulers & Grid Sub-tab

Selecting the Rulers & Grid sub-tab lets you display or hide the Ruler and Grid as well as format the color and style of the Grid Line. You can also adjust the unit of measure for the Ruler, the spacing within the Grid and Snap objects within the Ruleflow diagram to the Grid (or to align with other shapes), if desired. Clicking Restore Defaults will re-set these properties to the original default settings. The Rulers & Grid sub-tab is shown below:
The Ruleflow Rulers and Grid Sub-tab
January 13, 2012
Page 67
THE RULETEST
THE RULETEST WINDOW
A Ruletest is the mechanism within Studio for creating use cases or test scenarios of sample data and sending them to a Rulesheet or Ruleflow for processing. Ruletests consist of one or more Testsheets which test independent Rulesheets or Ruleflows, or can be linked together to test a succession of Rulesheets or Ruleflows to simulate a process sequence. Opening a Ruletest or making a Ruletest the active Studio window causes the Studio menubar and toolbar to display the tools needed to test Rulesheets and Ruleflow. Rulesheets, as individual files, may only be tested using a Studio Ruletest. In order to deploy and test using Corticon Server, Rulesheets must be packaged as Ruleflows before they can be executed. Ruleflows may be tested both in Studio using Ruletests and on Server using standard request messages.
Creating a New Ruletest

1. Choose File>New>Ruletest from the Studio menubar, or click to display a new Create New Ruletest dialog box. from the toolbar,
January 13, 2012
Page 68
2. Select the parent folder for the new Ruletest, in our example Example_Project. This will associate the Ruletest with the Example_Project project and display it in the Rule Project Explorer window along with the other files in that project. 3. Enter a file name for the new Ruletest, in our example Example_Ruletest. 4. Click Next > to continue and display the Select Test Subject dialog box, shown below. Here, you select the Rulesheet or Ruleflow that is to be tested. Youll be presented with 2 lists of available test subjects, both Local and Remote. The Local test subjects are the Rulesheets and Ruleflows available in your active Project. The Remote section contains a list of remote Corticon Server instances that Studio is aware of 3. If these remote Servers are running, and if Studio has network access to them, then clicking Update list will tell these remote Servers to report which Ruleflows are currently deployed to them and available for execution. You can select one from the list.
5. In the screenshot below, we chose local Rulesheet Tutorial.ers.
The list of remote services Studio is aware of is configured in Studios properties. Please see the CcDeployment.properties section of the Server Integration & Deployment Guide for more details Copyright 2000-2012 Progress Software Corporation. All rights reserved. January 13, 2012
Page 69
6. Click Finish to display your new Ruletest in Studio:
January 13, 2012
Page 70
7. The new Ruletest should appear as a new node in the Rule Project Explorer tree (A), a new window with the chosen Ruletest name as its tab name (B). The new Ruletest will also have a Testsheet tab (C). A Testsheet tab is divided into 3 vertical panels: Input, Output, and Expected. In the graphic above, Expected is not shown. 8. You can easily change the Ruletests test subject by double-clicking on the current test subject, immediately below the Testsheet tab (C). This will re-open the Select Test Subject window, where you can change your selection.
Ruletest Menubar
The Ruletest menubar includes the same File, Edit, Search, Window and Help options as shown in Rulesheet menubar, in addition to a Ruletest menubar and toolbar containing specialized Ruletest options. Many of the functions provided by the menubar are also accessible through the toolbar. When a menubar option has an equivalent toolbar icon, the icon is shown alongside. File Menu These options are the same as for the Vocabulary, Rulesheet, and Ruleflow file types Edit Menu These options are the same as for the Vocabulary, Rulesheet, and Ruleflow file types Search Menu These options are the same as for the Vocabulary, Rulesheet, and Ruleflow file types Project Menu These options are the same as for the Vocabulary, Rulesheet, and Ruleflow file types Ruletest Menu Testsheet > Add Testsheet Remove Testsheet Link To Previous Testsheet Inserts a new Testsheet. Deletes the specified Testsheet. Linking a Testsheet to a previous Testsheet causes the Input panel of the 2nd Testsheet to be populated with the date from the Output panel of the 1st.
January 13, 2012
Page 71
Change Test Subject Cut Testsheet Copy Testsheet Paste Testsheet Rename Testsheet Move Backward Move Forward Move To Beginning Move To End
Opens a window that allows you to select a new Rulesheet or Ruleflow to test. Cut the active Testsheet Copy the active Testsheet Paste the active Testsheet Displays an entry window to change the Testsheet name Moves the selected Testsheet tab one tab towards the beginning of the Ruletest. Moves the selected Testsheet tab one tab towards the end of the Ruletest. Moves the selected Testsheet tab directly to the start of the Ruletest. Moves the selected Testsheet tab directly to the end of the Ruletest. Import a valid CorticonRequest XML document into Studio as a Ruletest. Set to Null Go to Entity Sort Entities resets the selected Testsheet tree node to null Displays an entity when an association tree node is selected Sorts entity nodes alphabetically by name. One entity must be selected. Displays the Ruletest Properties window
Import XML/SOAP Data >
Properties Input >
January 13, 2012
Page 72
Export Request XML
Exports the active Testsheets Input pane as a 4 CorticonRequest XML document Exports the active Testsheets Input pane as a CorticonRequest XML document with SOAP envelope Constructs the minimum Input data structure necessary to test the chosen Rulesheet. Uses the Rulesheets scope for guidance. Exports the active Testsheets Output pane as a CorticonResponse XML document Exports the active Testsheets Output pane as a CorticonResponse XML document with SOAP envelope Copies the data in the Output panel to the Expected panel. Exports the active Testsheets Expected pane as a CorticonResponse XML document Exports the active Testsheets Expected pane as a CorticonResponse XML document with SOAP envelope Create a WSDL directly from the Input pane of a Ruletest. For more information about using WSDLs to integrate Decision Services, see Server Integration & Deployment Guide.
Export Request SOAP Generate Data Tree
Output > Export Response XML Export Response SOAP Copy to Expected Expected > Export Response XML Export Response SOAP Export WSDL
CorticonRequest and CorticonResponse documents are the standard messages passed to and from Corticon Server. See Server Integration & Deployment Guide for more information. January 13, 2012
Page 73
Deploy Run Test Output Validation > Validate
Compiles the Ruletest target without executing it. Compiles (if needed) and executes Ruletest
Reruns the color-coded validation of the Output and Expected data. See Using the Expected Panel. Executes all Testsheets in the Ruletest. Creates an HTML report and launches your browser for viewing. See Creating a Ruletest Report.
Run All Tests Report
Window Menu
These options are the same as for the Vocabulary, Rulesheet, and Ruleflow file types
Help Menu
These options are the same as for the Vocabulary, Rulesheet, and Ruleflow file types
Ruletest Toolbar
When a Ruletest is the active Studio window, the Studio toolbar will adjust to show additional, Ruletest-specific options.
Same as Ruletest>Testsheet>Add Testsheet Same as Ruletest>Testsheet>Remove Testsheet Same as Ruletest>Testsheet>Link to Previous Testsheet Same as Ruletest>Testsheet>Change Test Subject Same as Ruletest>Testsheet>Cut Testsheet Same as Ruletest>Testsheet>Copy Testsheet Same as Ruletest>Testsheet>Paste Testsheet
Page 74
Same as Ruletest>Testsheet>Rename Testsheet Same as Ruletest>Testsheet>Move Backward Same as Ruletest>Testsheet>Move Forward Same as Ruletest>Testsheet>Move to Beginning Same as Ruletest>Testsheet>Move to End Same as Ruletest>Testsheet>Data>Output>Copy to Expected Same as Ruletest>Testsheet>Output Validation>Validate Same as Ruletest>Testsheet>Deploy Same as Ruletest>Testsheet>Run Test

Ruletest Tab Pop-up Menu Options The Ruletest tab pop-up menu has the same options as the other tab pop-ups, including the Rulesheet and Ruleflow. Testsheet Window Pop-up Menu Options Undo Re-do Cut Copy Paste Delete Set to Null Go to Entity Sort Entities Properties Same as Studio toolbar Same as Studio toolbar Same as Studio toolbar Same as Studio toolbar Same as Studio toolbar Deletes/removes the selected node Resets the value of the selected node(s) to null. Locates the parent entity of a selected collection element. Sorts entities alphabetically and by element ID number Opens the Ruletests Properties window. The Ruletest sub-tab displays the location of the Vocabulary associated with the Ruletest, the Testsheet sub-tab displays the location of the Rulesheet associated with the Ruletest
January 13, 2012
Page 75
Sample Testsheet Node Pop-up Menu A sample Testsheet Node Pop-up menu is shown to the right.
Testsheet Tabs
A Ruletest is comprised of Input, Output and Expected panels. Ruletests you create are displayed in the Rule Project Explorer window. You can navigate between open Testsheets by clicking the Testsheets tab to make it active.
Populating the Input Panel

Creating a set of test data in the Input panel is also called creating the test tree, since the Input data structure uses the same nodes as the Rule Vocabulary window and arranges them in the same tree view.
January 13, 2012
Page 76
Adding Entities to the Test Tree Drag and drop entity nodes from the Rule Vocabulary window onto the Testsheet as shown to the right. When creating new root-level entities, the nodes may be dropped anywhere on the Input panel of the Testsheet. Entities may be deleted by pressing the Delete key or by selecting Delete from the right-click pop-up menu. Creating Associations in the Test Tree Creating an association adds an instance of the selected entity in the Testsheet, but this is different from creating an instance of a root-level entity by itself (without forming the association to the parent entity). An association creates a link between entities; if this did not exist, there would be no direct relationship between them. To create an association: 1. Drag and drop the association for the desired child entity directly on top of the parent entity, as indicated by the orange line in this illustration, from the Rule Vocabulary window into the Input panel. 2. Verify the child entity has the appropriate indented structure underneath the parent entity, indicating the association has been created correctly.
January 13, 2012
Page 77
Be careful to follow precisely the orange line in these illustrations, which shows that the association must be dragged from the Vocabulary and dropped directly onto the yellow entity icon to which it is being associated. Dropping the association on an empty or incorrect portion of the Testsheet will produce a message informing you that the association request was ignored. Assigning Attribute Values in the Test Tree 1. Double-click the desired term to open a data entry box 2. Type test data in the box and press Return to enter the data, or 3. Press Tab to advance the entry box to the next attribute, and press Return to open its data entry box.
Attributes not used in a scenario may be deleted by selecting them and pressing the Delete key or by selecting Delete from the right-click pop-up menu. Multiple attributes may be selected using Shiftclick and Ctrl-click to select contiguous and non-contiguous groups, respectively. In the illustration above, the attributes of aircraft[1] have not been deleted, just collapsed and hidden from view. Automatically Generating a Test Tree When creating a Ruletest, its important to provide the input data required by the Rulesheet being tested. Without the necessary input data, the rules cannot create the expected output. Creating a test tree manually can be tedious for very large Rulesheet test subjects. Studio provides a way to simplify and speed up the process. Generate Test Tree is an option in Studio menu Ruletest>Testsheet>Data>Input that automatically analyzes the Vocabulary terms used by the Rulesheet and generates the corresponding tree structure in the Input pane of the Testsheet. The input of specific data values for the attributes still must be performed manually, but the tree structure is created automatically. When a Vocabulary association between two entities is one-to-many, then the Generate Test Tree feature will create 2 instances (copies) in the tree. You can add more to test a larger collection, or delete them to test a smaller collection. You can always edit the resulting test tree by adding or removing terms.
January 13, 2012
Page 78
Executing Tests
Before a Ruletest can be executed, the corresponding Rulesheets (whether being tested directly or as contained in Ruleflows) must be compiled. This compilation process does not occur until the Ruletest is run. Depending on how many Rulesheets and rules must be compiled, this compilation step may take a few seconds. Each time a change is made to a rule in a Rulesheet referenced by the Ruletest, the rules will need to be re-compiled. This recompilation will occur automatically when Run Test is selected. This will cause a brief delay in execution while the new compilation is performed. Once a Ruletest has been executed, it will rerun without recompiling as long as the rules have not changed since the last execution. Changing the Input test data does not require recompilation. To compile rules without running them, a special Deploy toolbar option is provided: . This is a different sequence of events than that performed by earlier versions of Corticon Studio. In versions 4.x and earlier, the compilation step occurred whenever a Rule Set was saved, so rules were already compiled when a Ruletest was executed. This resulted in longer save times, but shorter test execution times. The sequence in Studio 5.2 results in shorter save times, but longer test execution times. The overall sum of both save and test execution steps remains the same, however. 1. Execute the test by choosing Ruletest>Testsheet>R un Test or toolbar. on the
2. Check the outcome of the test in the Results panel. 3. Test results are displayed in regular type style. Parts of the test tree (nodes) modified by the Server are shown in bold black text. Any errors are shown in red.
January 13, 2012
Page 79
4. Posted rule statements appear in the Rule Messages window at the bottom of the Testsheet. In addition to the Message and Severity columns, the box also displays the Entity node to which the rule statement has been posted. In the example above, the Rule Message displayed was posted, or linked to Cargo[1]. This means that it was the data contained in Cargo[1] which caused the rule corresponding to the posted Rule Statement to fire. 5. Make any necessary adjustments to the Rulesheet, save and re-test by repeating steps 1-5.
Sequence of Message Posting

Message posting normally occurs at the tail end of a rules execution a sort of final action even though not technically an action like expressions in Action rows. An exception to this behavior occurs for Column 0. A rule statement with Ref = 0 posts at the beginning of Rulesheet execution. If you want to force your rule statements in Column 0 to post after the Action rows execute, use Ref values of A0, B0, etc, rather than 0.
Sorting Messages
Messages posted by rules and displayed in the Rule Messages window are a useful tool for understanding and troubleshooting Rulesheet execution. Messages displayed can be sorted in the following ways: When the Severity header is clicked, the messages sort by severity level first (Info then Warning then Violation), then in order of generation, with earlier messages posted higher in the table. When the Message header is clicked, the messages sort in order or generation, with the first message generated displayed in the first row. When the Entity header is clicked, the messages sort in ascending order by entity name/number, then in order of generation.
When any Rule Message row is clicked, the corresponding Entity highlights in the Output panel above. This provides a convenient way of navigating among the data in a large data set, rather than vertically scrolling.
Using the Expected Panel

If you use the Ruletests Expected panel to create a set of expected test results, then Studio will automatically compare the actual Output data to your Expected data, and color code the differences for easy review and analysis. The Expected panel can populated in the same manner as the Input panel - by dragging and dropping nodes from the Rule Vocabulary window to create an identical tree structure. A simpler method is provided by the Ruletest>Testsheet>Data>Output>Copy to Expected option in the Studio menubar, or the
in the Studio toolbar.

January 13, 2012
Page 80
Expected Panel Output Results Match Expected Exactly In the example below, both packaging values are shown in bold text, indicating that these values were changed by the rules. Because all colors are black, the Output data is consistent with the Expected data.
Expected Panel Different Values Output than Expected In the example shown below, the expected value of Cargo[1] packaging value is Container, but the Ruletest produced an actual value of Pallet. Since the Output does not match the Expected data, the text is colored red.
January 13, 2012
Page 81
Expected Panel Fewer Values Output than Expected In the example below, Cargo[2] is included in the Input and Expected trees, but did not appear in the Output tree. Because data was expected but not produced, the difference is colored green.
Expected Panel - More Values Output than Expected In the example below, Cargo[2] was produced in the Output, but was not anticipated by the Expected panel. For this reason, the difference is colored blue.
January 13, 2012
Page 82
Expected Panel All Problems All the problems and differences described individually above are combined below to show how a real Ruletest (with many problems) may appear.
Format of Output Data

By default, the data in the Output pane will be displayed in the same format as the Input. In other words, if the Input data is flat, then the so will be the Output. If the Input is hierarchical, then so will be the Output. You can change this default behavior to force full-time hierarchical or flat Output, regardless of Input structure. See the Server Integration & Deployment Guide for more information about the xmlmessagingstyle property in CcStudio.properties. For more information about flat and hierarchical data formats, including examples, see the Integrating Decision Services chapter of the Server Integration & Deployment Guide.
January 13, 2012
Page 83
Creating Multiple Test Scenarios on the Same Testsheet

1. To test more than one scenario with the same Input panel, drag as many entity nodes from the Rule Vocabulary as you need. You can drag and drop as per standard procedure, or copy & paste elements already in the Input panel. 2. New elements will be automatically numbered to ensure a unique ID for each. These unique ID numbers are the same referenced by posted messages in the Results panel. See step 5 in Executing Tests. 3. Additional descriptive text may be added to any node by selecting Properties from its right-click pop-up menu, and typing in the Comments subtab of the Properties window.
January 13, 2012
Page 84
Creating Multiple Test Scenarios as a Set of Testsheets

1. It may be more convenient to organize multiple scenarios as a set of Testsheets each scenario with its own set of Input, Output, and Expected panels. 2. Each Input panel must be linked to a Rulesheet or Ruleflow. See step 1 of Executing Tests. 3. Each Input panel will generate its own Results panel. All of these Testsheet tabs may be renamed for better organization.
Creating a Sequential Test Using Multiple Testsheets

1. Multiple Ruleflows may be tested in an integrated scenario by linking them together in a single Ruletest. This simulates a complex series of decisions or a part of a business process. Note: Rulesheets may also be linked together like this, but Ruleflows are more commonly used to test sequences of Rulesheets.
January 13, 2012
Page 85
2. Assume we want to test 3 Ruleflows (named Cargo, Cargo2 and Cargo3) in sequence. 3. Create a new Ruletest as before and link it to Ruleflow cargo.erf as usual. See step 1 of Executing Tests. 4. Execute the Ruletest to generate data in the Output panel. 5. Add a new Testsheet using and link it to Ruleflow cargo2.erf. 6. Link this new Testsheet to the previous Testsheet using . The data from the Output panel of the previous Testsheet should appear in the Input panel of the new Testsheet. 7. Repeat for as many new Testsheets as needed to model the sequence. You can execute one sheet at a time by selecting from the toolbar, or execute all at once by selecting Ruletest>Run All Tests from the menubar
January 13, 2012
Page 86
Naming Testsheets
When you add a new Testsheet, it is assigned a default name of Untitled_X, where X is a sequential number. You can rename each Testsheet tab for easy reference. Unnamed Testsheet tabs will be saved with the default name. 1. You can either select Ruletest>Testsheet>R ename Testsheet from the menubar or the right-click pop-up menu, or select the Rename Testsheet icon from the Ruletest toolbar to display the Rename Test Tab dialog box. 2. Type the new name in the space provided and press or click Enter. 3. Like Rulesheets and Vocabularies, Test and Testsheet names must comply with the guidelines described in File Naming Restrictions.
Adding Testsheets
1. You can either select Ruletest>Testsheet>A dd Testsheet from the menubar or the rightclick pop-up menu, or select the Add Testsheet icon from the Ruletest toolbar to display the Select Test Subject dialog box.
January 13, 2012
Page 87
2. Select the Rulesheet to associate with the new Ruletest and click OK. Studio creates a new Testsheet tab at the end of the current set of tabs, assigns the new tab a system-generated name, and automatically selects the new tab.
January 13, 2012
Page 88
Associating One Child Entity with More Than One Parent

To create associations between a child entity and more than one parent: 1. First, ensure the parent-child (sourcetarget) association supports a multiplicity of many-to-many or many-to-one. 2. Drag and drop the parent entities (here, FlightPlan) as usual. 3. Create an association between aircraft and FlightPlan[1] as described in Creating Associations. 4. To associate
aircraft[1] to FlightPlan[2] in
addition to
FlightPlan[1], drag aircraft as
shown to the right, and press the CTRL key as you drop it. 5. A pop-up window will ask you to select the Aircraft you are linking to. In this case, select Aircraft[1] and click OK.
January 13, 2012
Page 89
6. Verify the child entity has the appropriate indented structure underneath both parent entities, indicating the two associations have been created correctly. 7. Notice that data for aircraft[1] is only entered once, under the FlightPlan[1] entity, even though it is associated with both FlightPlans. 8. In large Testsheets, it may be difficult to locate the original instance of aircraft[1]. Clicking on any copy and choosing Ruletest>Go To Entity from the menubar will automatically locate the original instance.
Saving Ruletests
When you save a new test, the Save Window displays. Follow the instructions shown in Saving a New Rulesheet to save your test scenario. When you save an existing test, the system automatically saves it to the existing name (*.ert). To save the Ruletest to another name, choose File>Save As from the menu.
Importing an XML or SOAP Document to a Testsheet

In some cases, it may be more convenient to import data into the Tester rather than recreate it. If this data can be structured in an XML document that adheres to the structure defined by the Vocabulary, then this document can be directly imported into Studio using Test>Import XML/SOAP. Studio can provide a sample XML or SOAP document to use as a template by choosing Test>Export XML or Test>Export SOAP.
January 13, 2012
Page 90
Exporting a Testsheet to an XML Document

Exporting Testsheets into XML documents can be useful for a few reasons: For use as a template for structuring much larger data sets for subsequent XML Import (as described above). To generate an XML data payload to test a deployed Rulesheet (a Decision Service on the Server).
A Sample Testsheet Exported to XML The sample XML file shown below is a direct export of the Input Testsheet created in Populating the Input Testsheet section. Notice the hierarchical structure. Consult the Server Integration & Deployment Guide for more information about the sections of the XML document, including the important decisionServiceName parameter shown in line 2 of the CorticonRequest tag, below.
Exporting a Testsheet to a SOAP Message

This feature is similar to Export to XML, except that it encloses the XML payload within SOAP-compliant envelope information. The XML payload is identical to the XML generated by the Export to XML option, as shown above. Consult the Server Integration & Deployment Guide for more information about the sections of the SOAP request document, including the important decisionServiceName parameter shown in the first line of the CorticonRequest tag, below.
January 13, 2012
Page 91
Creating a Ruletest Report

1. Choose Ruletest>Report from the menubar. 2. If your local machine has a web browser installed, the HTML report should open as a new web page. 3. Studio will save the report file to C:\Documents and Settings\<your username>\Local Settings\Temp using the name format CorticonRuletestXXXXX.html, where XXXXX is a unique auto-generated number. You can save the HTML to a different name or location from the browser. 4. For information about creating custom reports or saving them to custom locations, see the Studio Reporting Framework chapter of the Rule Modeling Guide.
EXITING CORTICON STUDIO
January 13, 2012
Page 92
When you close the Studio (select File>Exit from the menu), you are prompted to save all open Vocabulary, Rulesheet, Ruleflow, and Ruletest files. If you choose to exit without first saving your files, any changes you made since opening them will be lost.
January 13, 2012
Page 93
APPENDIX A: KEYBOARD SHORTCUTS AVAILABLE IN STUDIO

Many of the options in the menubar also have keyboard shortcuts. Where available, these shortcuts are listed next to the menubar option. In addition to these, the following keyboard shortcuts are also available for use in Studio and are accessed by selecting Help>Key Assist on the Studio menubar.
January 13, 2012
Page 94
APPENDIX B: CORTICON STUDIO AND SERVER 5.2 TECHNICAL PUBLICATIONS

The following documents are included with the Corticon Studio and Server 5.2 release:
Document or Resource Corticon Tutorials Tutorial for Corticon Studio 5.2 Basic Rule Modeling Tutorial for Corticon Studio 5.2 Advanced Rule Modeling Tutorial for Corticon Server 5.2 Deploying Web Services A step-by-step introduction to modeling, analyzing, and testing rules and decisions in Studio 5.2. Recommended for all new users. An intro to more advanced modeling concepts and practices in Studio 5.2. For users who want a more thorough introduction to Studio 5.2s capabilities. A step-by-step introduction to installing the Server as a Web Services server and deploying and exposing decisions as Web Services. Format Description
Model Business Rules: Corticon Studio Documentation Studio 5.2 Installation Guide A step-by-step procedure for installing Studio 5.2 on a PC running Microsoft Windows or in an Eclipse environment. A guide to the Studio 5.2 User Interface and its mechanics, including descriptions of all menu options, buttons, and basic actions. An online .pdf version of all documents in this table, available from within Studio 5.2. An in-depth discussion of several essential Studio 5.2 concepts. Recommended for all Studio 5.2 users. A detailed reference of all operators available in the Studio Vocabulary. An actual Studio Rulesheet example is included for every operator.
Studio 5.2 Online Help Rule Modeling Guide
Rule Language Guide
Integrate & Deploy Business Rules: Corticon Server Technical Documentation Server Integration & Deployment Guide An in-depth, technical description of Server installation, deployment methods, integration, messaging, APIs, and configuration. Detailed technical explanations describing the Corticon extension framework for extended operators and service call-outs
Extensions User Guide
January 13, 2012
CORTICON
Business Rules Modeling Studio 5.2 Installation Guide
TABLE OF CONTENTS
Table of Contents ................................................................................................................................................. ii Installing the Business Rules Modeling Studio .................................................................................................... 3 Preface ........................................................................................................................................................... 3 Corticon Business Rules Management Product Documentation .................................................................. 3 Documentation Conventions......................................................................................................................... 3 Installation Environment ............................................................................................................................... 4 Option 1 Windows Application ............................................................................................................ 4 Option 2 Eclipse Plug-in ....................................................................................................................... 4 Option 1: Installing Studio as a Windows Application ......................................................................................... 5 About the Studio Installer ............................................................................................................................. 5 System Requirements.................................................................................................................................... 5 Technical Support .......................................................................................................................................... 5 Before Installing Corticon Studio................................................................................................................... 6 Corticon Studio Setup Wizard ....................................................................................................................... 6 Startup Screen......................................................................................................................................... 7 License Agreement ................................................................................................................................. 8 Choose Install Folder............................................................................................................................... 8 Changing Installation Directory .............................................................................................................. 9 Choose Install Set .................................................................................................................................... 9 Pre-Installation Summary ..................................................................................................................... 10 Installation Status ................................................................................................................................. 10 Completing the Installation .................................................................................................................. 11 Desktop Shortcuts ................................................................................................................................. 11 Changing Studio Memory Allocation .................................................................................................... 12 Program Removal ........................................................................................................................................ 12 Option 2: Installing Studio as an Eclipse Plug-in ................................................................................................ 13 Supported Configurations ........................................................................................................................... 13 Installation Instructions ............................................................................................................................... 13 Appendix A: Enabling Studio Internationalization ............................................................................................. 24 Displaying Studio in your locale of choice ............................................................................................ 24 Creating a new language bundle .......................................................................................................... 24 Switching Operating System Locales .................................................................................................... 25 Appendix B: Corticon Studio and Server 5.2 Product Documentation ............................................................. 27
Copyright 2000-2012 Progress Software Corporation All rights reserved.
January 13, 2012
Studio 5.2 Installation Guide
Page 3
INSTALLING THE BUSINESS RULES MODELING STUDIO

PREFACE
The Studio Installation Guide provides detailed information necessary to assist you in installing the Studio on your computer. This application is intended for use by anyone who develops and implements business rules using Studio and will provide you with unique business rule technology to leverage your enterprise software development.

For a detailed listing of current Corticon technical publications, see Appendix A.
DOCUMENTATION CONVENTIONS
Corticon documentation uses the following conventions: Document names are shown in bold face italic type: Studio Installation Guide. Screen, button and window names are shown in bold face type: Custom Setup screen. Important information such as Notes, Tips and Warnings are shown in this color scheme: Tools Notes and Tips Warnings
Hyperlinks are underlined and shown in blue: the cursor changes to a hand: System Requirements. File names, code and user-defined information are shown as: Installing.pdf. Menu options are indicated using bold text and arrows: File>Save denotes the selection of the Save option from the File menu.
January 13, 2012
Page 4
INSTALLATION ENVIRONMENT
There are 2 primary methods of installing Studio. Your choice will depend on your technical background and your current development environment.
Option 1 Windows Application

Install Studio as a standard Windows application. Use this option if youll be modeling rules in a typical Windows-based business environment, are not a Java developer, or if you just want to install Studio with a minimum of complication. Most business analysts, managers, and evaluators will choose this option. To choose this option, proceed to the Installing Studio as a Windows Application section.
Option 2 Eclipse Plug-in

Install Studio as a plug-in in an Eclipse development environment. Use this option if youre a Java developer who wants to incorporate a business rule modeling facility into your existing Eclipse environment. If youre not already very comfortable working in an Eclipse environment, we do not recommend this option. To choose this option, proceed to the Installing Studio as an Eclipse Plug-in section.
January 13, 2012
Page 5
OPTION 1: INSTALLING STUDIO AS A WINDOWS APPLICATION

ABOUT THE STUDIO INSTALLER
The Studio installer, Corticon_Studio_Installer.exe, contains: The Corticon Studio. Java Runtime Environment, version 1.6.0 Sample rule files. An Online Help file (PDF format). A 30-day evaluation license.
SYSTEM REQUIREMENTS
Corticon Studio 5.2 requires: Microsoft Windows 2000, XP, Vista, 7 32-bit (64-bit compatible) The Eclipse plug-in version requires Eclipse 3.5.2 or above Java Runtime Engine 1.6.0 or higher (included)
Hardware requirements include: Pentium M-class CPU or higher 512 MB RAM (1 GB recommended) 200 MB disk space (full install)
TECHNICAL SUPPORT
For Corticon product support, contact +1 650.212.2424 ext. 200 or email support@corticon.com
January 13, 2012
Page 6
BEFORE INSTALLING CORTICON STUDIO

Before running the Corticon Studio setup wizard (also called the installer) as described in the following sections, be sure to prepare the workstation by: ensuring you have Administrator access privileges to the workstation. Administrator rights allow the Installer to copy all Studio files to their proper locations. obtaining system access. By default, the Studio installer copies files to the C:\Program Files\Corticon directory on versions of Windows prior to Vista, and to C:\Corticon for Vista and Windows 7. Several of the Studio features write files to this same home directory structure. If the workstation receiving Studio will not normally have read and write access to this directory, you will need to perform a Custom Installation and choose a directory location that the Studio user will have both read and write access to. disabling all anti-virus, anti-malware, and anti-spyware protection applications because some have been known to interfere with proper Studio installation. Once installation is complete, restart these applications to resume protection. initializing the license. After installation, launch Studio while Administrator rights are still active. This is necessary because Studio accesses the Windows Registry to initialize its license. Once launched, Studio may be shutdown and the workstation returned to its previous access rights. Thereafter, Studio will not require Administrator rights to launch and run normally.
CORTICON STUDIO SETUP WIZARD

To install Studio software, insert the product CD in the CD-ROM drive of your computer or download the installation file from the designated website. Double click on the Corticon_Studio_Installer.exe file to open the Studio Setup Wizard. The screens shown in this document were captured on computers using Windows 2000 and XP as their operating systems. You must have Administrator rights and permissions to install this software. See your system administrator to obtain these rights.
Copyright 2000-2012 Progress Software Corporation All rights reserved. January 13, 2012
Page 7 Before performing the installation, we highly recommend temporarily disabling any anti-virus and anti-spyware software that may be running on your machine. This software often prevents or interferes with proper installation.
Startup Screen
The first screen of the Studio Setup Wizard appears briefly and requires no action on your part.
This is the second main screen of the Studio Setup Wizard. Click Next to continue.
January 13, 2012
Page 8
License Agreement
This screen displays the Corticon Standard License Agreement. Use the scroll bar at the right of the screen to read through this agreement. When you are finished and agree to the terms, choose I accept the terms in the license agreement. Click Next to continue.
Choose Install Folder

Select the installation directory. The default folder is C:\Program Files\Corticon on versions of Windows prior to Vista and Windows 7. If you would like to change this, click Choose and proceed to the next step. If you change your mind, clicking Restore Default Folder will revert to the default directory. To accept the default directory, click Next to continue.
If you are installing Corticon Studio on Microsoft Vista or Windows 7, the default installation location may appear as C:\Corticon. Regardless of default, be sure to select an Install Folder for which you have full read and write access rights. If you install Studio to Program Files in a Windows Vista or 7 environment without Administrator rights, Studio may not function correctly.
January 13, 2012
Page 9
Changing Installation Directory

If you selected Choose in the previous step, enter your preference in this window. Click OK to continue. If you accepted the default location in the previous step, skip this step.
Choose Install Set

Choose the installation type, Complete, Minimal or Custom. The Complete option is selected by default. If you want a custom setup, choose Custom and deselect the components you dont want to install. All options install files to your previously chosen destination directory. Click Next to continue.
January 13, 2012
Page 10
Pre-Installation Summary
In the Pre-Installation Summary, ensure that your installation location has enough disk space to accommodate the Studio components. Click Install to continue.
Installation Status
This screen displays a status bar as the necessary Studio files are being copied to your computer.
January 13, 2012
Page 11
Completing the Installation

Choose Done to complete the Studio installation.
Desktop Shortcuts
The installation program will not create an Studio shortcut on your desktop, but if you would like to create one, follow these steps: 1. Go to
<corticon_insta ll_dir>\Studio
2. Right-click
Studio.exe
3. Choose Send To>Desktop (Create Shortcut)
January 13, 2012
Page 12
Changing Studio Memory Allocation

Edit the command file named Studio.ini inside
<corticon_install_dir >\Studio and increase the Xmx value (maximum -Xmx350m
memory setting). By default, the Xmx setting is 350m, which means 350Mb.
PROGRAM REMOVAL
Remove earlier versions using the standard Windows utility Add or Remove Programs, which can be found in the Control Panel option on your Start menu. This screen shows the Add or Remove Programs utility, with the Studio application highlighted. 1. Click Remove to proceed with the removal.
2. Confirm you wish to remove. Track progress of the removal. Once complete, restart the installer and return to the beginning of this manual.
January 13, 2012
Page 13
OPTION 2: INSTALLING STUDIO AS AN ECLIPSE PLUG-IN

SUPPORTED CONFIGURATIONS
Software Component JDK Eclipse Version 1.5.0 or higher Callisto (3.2.0 or higher) Europa (3.3.0 or higher) Ganymede (3.4.0 or higher) Galileo (3.5.0 or higher) EMF GEF GMF 2.2.2.v200702131851 or higher 3.2.2.v20070208 or higher 1.0.3.v20070202-1200 or higher 2.5.0.v200906151043 3.5.1.v20090910-2020 1.2.0.v20090615-0700 Certified on Version JDK 1.6.0_20 Galileo 3.5.2
INSTALLATION INSTRUCTIONS
1. If you dont already have a Java JDK installed, download and install the desired JDK from the Oracle Java website http://www.oracle.com/technetwork/java (important: it is necessary to install a JDK as opposed to JRE). 2. If you dont already have an Eclipse installation, download the Galileo version of Eclipse from www.eclipse.org. Unzip the file into your Eclipse directory (e.g., C:\eclipse). 3. Obtain a copy of Corticon_e_UpdateSite.zip and unzip it to a temporary installation directory (e.g., C:\CorticonLocalSite). If you have a ClearCase development view, you can create this file by invoking the build.xml ant target updatesite. 4. Start the Eclipse IDE by double-clicking on eclipse.exe in the C:\eclipse directory. The system will prompt for a workspace location
January 13, 2012
Page 14
5. Either accept the default location or choose a different location if desired. Click OK to continue. The system will display the Welcome View.
January 13, 2012
Studio 5.2 Installation Guide 6. Close the Welcome View, then select menu item Help>Install New Software...
Page 15
7. Click the Add button and the system will display the Add Site dialog:
January 13, 2012
Studio 5.2 Installation Guide 8. Click Local... and navigate to the C:\CorticonLocalSite directory:
Page 16
9. Click OK and assign your new site any name of your choosing:
10. Click OK again to add the new site
January 13, 2012
Studio 5.2 Installation Guide 11. Select Corticon Studio>Corticon Business Rules Modeling Studio
Page 17
January 13, 2012
Page 18
12. Click Next > and the system will analyze the dependences and show the complete set of features to be installed, including GMF, GEF and EMF
January 13, 2012
Studio 5.2 Installation Guide 13. Click Next > to review the licenses
Page 19
January 13, 2012
Studio 5.2 Installation Guide 14. Select I accept the terms of the license agreement and click Finish
Page 20
15. When the system displays the Security Warning dialog box, click OK
January 13, 2012
Page 21
16. When the system prompts regarding certifications, select Eclipse.org and click OK
17. The system will install all of the necessary plug-ins. When the system is finished, press Yes to restart your Eclipse session
January 13, 2012
Page 22
18. Once Eclipse restarts, verify the installation by selecting menu item Help>About Eclipse SDK, then press the Installation Details button
19. Note that Corticon Business Rules Modeling Studio has been successfully installed
January 13, 2012
Page 23
20. Exit from Eclipse and create a Windows icon shortcut on your Windows desktop to make it easier to launch eclipse.exe. Update the Target and Start In fields as shown:
21. The Target field command line parameters should specify the proper JDK (e.g., -vm c:\jdk1.6.0_20\bin), and should increase the memory heap settings for optimal performance (e.g., -vmargs Xms256m Xmx1024m). Example:
C:\eclipse\eclipse.exe -vm c:\jdk1.6.0_20\bin -vmargs Xms256m Xmx1024m
22. Use your new shortcut to restart Corticon Studio, and you should be able to switch to the Rule Modeling Perspective and create your first Rule Project. Happy rule modeling!
January 13, 2012
Page 24
APPENDIX A: ENABLING STUDIO INTERNATIONALIZATION

Localizing your rule modeling environment involves two pieces: Displaying the Studio program in your locale of choice. This means switching the Studio user interface (menus, operators, system messages, etc) to a new language. This part is described here, but is not yet supported in Corticon Business Rules Management 5.2. Displaying your Studio assets in your locale of choice. This means switching your Vocabularies, Rulesheets, Ruleflows, and Ruletests to a new language. This part is described in the Localization chapter of the Rule Modeling Guide
Displaying Studio in your locale of choice

Localization of the Studio user interface is not supported in Corticon Business Rules Management 5.2 When localized, Studio can: Display its full user interface in localized languages and fonts. Display all operators in the Operator Vocabulary in localized languages and fonts. Process XML messages (or Test inputs) containing data comprised of non-Latin characters (e.g., Japanese, Chinese or Korean). Post Rule Statements that contain non-Latin characters.
In order for Studio to display its user interface in your chosen locale, two requirements must be satisfied: 1. A language bundle or template must be created for your chosen language and installed in CcI18nBundles.jar, both Studio and all deployed Server installations. 2. Your operating system must be running in your chosen locale when Studio starts up.
Creating a new language bundle

A Localization Toolkit is not yet available for Corticon Business Rules Management 5.2 To create a new language bundle for Studio, youll need to download the Localization Toolkit for your version. Toolkits are available for all versions of Studio, and are normally available from the Corticon Support Site. The Toolkit contains a ReadMe that explains how to create a new bundle, save it, and install it.
January 13, 2012
Page 25
Switching Operating System Locales

Before switching to a different locale, you may need to install necessary language support into the Windows operating system and set the appropriate Regional Settings in the Regional and Language Options. Installing Language Support in Windows You must install the desired language(s) into the operating system via the Regional and Language Options selection in Windows Control Panel. In Windows XP, select the Languages tab and press the Details... button to see the languages currently installed. The system will display a dialog similar to the one shown below:
Use the Add... button to add the desired languages. Note: the operating system may prompt you to insert the installation media in order to complete the installation.
Studio 5.2 Installation Guide Changing Your Machines Region
Page 26
Next, you must change you regional settings so that your machines locale specifies the non-English language youve installed. You must change both the Standards and formats specification and the Location specification. For example, to enable Japanese, choose the specifications shown below:
Testing the Setup Start Studio in the normal manner, and invoke the open dialog window by selecting menu option File>Open. If the installation was successful, buttons on the dialog (and other key static text labels) should be presented in the selected regions language. To create Studio assets in a different locale, see the Localization chapter of the Rule Modeling Guide.
January 13, 2012
Page 27
APPENDIX B: CORTICON STUDIO AND SERVER 5.2 PRODUCT DOCUMENTATION

Rule Language Guide
January 13, 2012
Basic Rule Modeling Tutorial
Corticon Decision Management Software

The Easiest Way to Manage and Automate Your Business Rules
Corticon Business Rules Modeling Studio 5.2 Tutorial Basic Rule Modeling
2012 Progress Software Corporation and/or its subsidiaries or affiliates. All rights reserved. These materials and all Progress software products are copyrighted and all rights are reserved by Progress Software Corporation. The information in these materials is subject to change without notice, and Progress Software Corporation assumes no responsibility for any errors that may appear therein. The references in these materials to specific platforms supported are subject to change. Actional, Apama, Artix, Business Empowerment, Business Making Progress, Corticon, Corticon (and design), DataDirect (and design), DataDirect Connect, DataDirect Connect64, DataDirect Technologies, DataDirect XML Converters, DataDirect XQuery, DataXtend, Dynamic Routing Architecture, Empowerment Center, Fathom, Fuse Mediation Router, Fuse Message Broker, Fuse Services Framework, IONA, Making Software Work Together, Mindreef, ObjectStore, OpenEdge, Orbix, PeerDirect, Powered by Progress, PowerTier, Progress, Progress DataXtend, Progress Dynamics, Progress Business Empowerment, Progress Empowerment Center, Progress Empowerment Program, Progress OpenEdge, Progress Profiles, Progress Results, Progress Software Business Making Progress, Progress Software Developers Network, Progress Sonic, ProVision, PS Select, RulesCloud, RulesWorld, Savvion, SequeLink, Shadow, SOAPscope, SOAPStation, Sonic, Sonic ESB, SonicMQ, Sonic Orchestration Server, SpeedScript, Stylus Studio, Technical Empowerment, WebSpeed, Xcalia (and design), and Your Software, Our TechnologyExperience the Connection are registered trademarks of Progress Software Corporation or one of its affiliates or subsidiaries in the U.S. and/or other countries. AccelEvent, Apama Dashboard Studio, Apama Event Manager, Apama Event Modeler, Apama Event Store, Apama Risk Firewall, AppsAlive, AppServer, ASPen, ASP-in-a-Box, BusinessEdge, Cache-Forward, CloudEdge, DataDirect Spy, DataDirect SupportLink, Fuse, FuseSource, Future Proof, GVAC, High Performance Integration, ObjectStore Inspector, ObjectStore Performance Expert, OpenAccess, Orbacus, Pantero, POSSE, ProDataSet, Progress Arcade, Progress CloudEdge, Progress Cloudware, Progress Control Tower, Progress ESP Event Manager, Progress ESP Event Modeler, Progress Event Engine, Progress RFID, Progress RPM, Progress Responsive Cloud, Progress Responsive Process Management, Progress Software, PSE Pro, SectorAlliance, SeeThinkAct, Shadow z/Services, Shadow z/Direct, Shadow z/Events, Shadow z/Presentation, Shadow Studio, SmartBrowser, SmartComponent, SmartDataBrowser, SmartDataObjects, SmartDataView, SmartDialog, SmartFolder, SmartFrame, SmartObjects, SmartPanel, SmartQuery, SmartViewer, SmartWindow, Sonic Business Integration Suite, Sonic Process Manager, Sonic Collaboration Server, Sonic Continuous Availability Architecture, Sonic Database Service, Sonic Workbench, Sonic XML Server, The Brains Behind BAM, WebClient, and Who Makes Progress are trademarks or service marks of Progress Software Corporation and/or its subsidiaries or affiliates in the U.S. and other countries. Java is a registered trademark of Oracle and/or its affiliates. Any other marks contained herein may be trademarks of their respective owners.
About this Guide
Note The Decision Services that you build using Studio may be deployed as executable, standards-based services available to other software applications via Java, .NET, or SOAP messaging. Corticon Decision Services are in use today across the globe, automating many high-volume decisionintensive processes. See the Server Integration & Deployment Guide or the Server Deployment Tutorial for instructions on how to deploy and integrate the Decision Services you build here.
This Basic Rule Modeling Tutorial provides an introduction to the Corticon Business Rules Modeling Studio 5.2. You will learn how to capture rules from business specifications, model the rules, analyze them for logical errors, and test the execution of your rules; all without programming. Your goal is to create a Decision Service: A group of rules that captures the logic of a single decision-making step completely and unambiguously. In one sense, a Decision Service (when managed with Corticon Studio) is a business-friendly model of your rules (i.e., your decision-making logic). In another sense, a Decision Service is a powerful asset, allowing you to automatically process the rules as a part of business transactions.
Note This Tutorial is designed for hands-on use. We recommend that you type along with the instructions and illustrations presented.
The Corticon Decision Services Methodology

Corticon provides a simple yet powerful methodology for modeling business rules called the Corticon Decision Services Methodology. This methodology follows the lifecycle of your decision service, and involves the following steps:
1. Scope the business problem. Ask the question: What decision are we trying to make?
2. Discover the business rules. Ask the question: How do we make the decision?
Scope
Discover
3. Model the business rules. Using Corticon Studio, logically express the rules.
5. Test the business rules. Using Corticon Studio, test rule execution to ensure expected business results.
Test
Model
Analyze
Note Steps 2-6 are repeated when rules change. This tutorial includes two iterations through the lifecycle, including an initial implementation and subsequent change cycle. Deployment is covered in a separate tutorial (see Server Deployment Tutorial and Server Integration & Deployment Guide).
4. Analyze the business rules. Using Corticon Studio, ensure that the rules are complete, consistent and free of logical errors.
Deploy
6. Deploy the business rules. Using Corticon Server, automate the rules across enterprise applications.
Table of Contents
The Business Process & Rules The Business Problem Page 6 Discover New Rules Page 7 Page 44

Start Corticon Studio Open the Vocabulary Create a New Rulesheet Model the Rules Add New Rule Statements Edit the Vocabulary Add an Attribute Save the Vocabulary Changes Model the New Rules Page 9 Page 13 Page 15 Page 18 Page 45 Page 46 Page 47 Page 50 Page 51
Scope
Discover
Test
Create a New Ruletest Set Up the Test Scenario Execute the Ruletest Verify the Test Results Save the Ruletest Modify the Ruletest Page 34 Page 37 Page 40 Page 41 Page 43 Page 55
Model
Analyze
Check for Conflicts Resolve Conflict Errors Check for Completeness Resolve Completeness Errors Save the Rulesheet Check New Rules for Conflicts Page 25 Page 28 Page 29 Page 30 Page 33
Deploy
Summary Page 52
Page 56
The Business Problem
Scope
Note The example used in this Tutorial was developed from a business problem in which an air cargo company loads cargo of various sizes and weights into containers, then onto its fleet of aircraft prior to shipment. To operate safely, the company must ensure that an aircraft is never loaded with cargo that exceeds an aircrafts capabilities. Flight plans are created by the company that assign cargo shipments to containers, then containers to aircraft. Part of the flight plan creation process involves verifying that no plan violates any safety or operational rule. The air cargo company desires to improve the quality and efficiency of the flight planning process by modeling and automating business rules using Corticons Business Rule Management System.
The Business Process & Rules

Complex problems such as flight planning are better described in their component parts. The best way to do this is by describing the business process for this problem. From a process diagram, we can easily identify the decision-making activities, which in turn are described by business rules.
Scope
Action First, define your business process as a sequence of activities or steps:
Collect Cargo
Package Cargo
Ship Cargo
Action Next, determine which process steps involve decisions. Any step involving a decision is a candidate for automation using Corticon. In this process, all three steps involve decisions, in addition to physical labor. The scope of this tutorial is the Package Cargo step, which involves the decision about what container to use for various cargo, based upon such criteria as the cargos weight, volume and contents. Today, the packaging decision is made by our shipping personnel based upon their experience. The problem is that some people make better decisions than others, which leads to inconsistent practices. We want to use Corticon to standardize and automate the packaging decision.
The Business Process & Rules
Discover
Now that we have scoped our problem, we need to discover our business rules. Note To discover our business rules, we simply ask: How do we make this decision? For this case, we ask How do we package cargo? We ask this question to the people who perform and manage this step in the process. They often provide the answer in the form of a policy or procedure manual, or simply as a set of rules that they follow. Sometimes the rules are embedded in the code of our legacy systems. In other cases, the rules are not documented and found only in the heads of our people. In all cases, we will capture the discovered rules directly into Corticon Studio.
Collect Cargo
Package Cargo
Ship Cargo
Cargo weighing <= 20,000 kilos must be packaged in a standard container. Cargo with volume > 30 cubic meters must be packaged in an oversize container.
Start Corticon Studio
Model
Action Open Corticon Studio Double click on the Studio icon in your Corticon installation directory
OR Note You first need to install the software. Refer to the Studio Installation Guide for detailed instructions. Choose Programs > Corticon > Corticon Business Rules Modeling Studio from the Start menu.
Note For further details and reference information not presented here, you can choose Help > Contents and Index from the Studio menubar or click the icon on the Studio toolbar.
Corticon Studio Orientation

Note When starting Corticon Studio, the screen will look similar to this:
Model
10
Switch Workspaces
Action Your initial workspace will be empty. Switch to a new workspace (where this Tutorials sample files are located) by choosing File > Switch Workspace from the Studio menubar.
11
The Rule Projects Workspace

Action In the navigation window that appears, browse to your Corticon installation directory and select \Samples\Rule Projects. Be sure Rule Projects appears in the Folder field at bottom. Click OK. Corticon Studio will automatically close and restart, with the new workspace open in the Rule Project Explorer window.
12
Open the Vocabulary
Model
Note The first step in modeling business rules is to build a Vocabulary, which includes the Model terms referenced by our business rules (such as aircraft and flight plan). Using Studio, you can define or edit Vocabularies, or import Vocabularies from existing object models, class diagrams, database schemas, or XML schemas. In this case, we opened an existing model created in Studio. Once you open a Vocabulary, you can see it in the upper left Rule Vocabulary window. In addition, you can edit the Vocabulary in the upper right editor window. Later in this Tutorial, we will edit the Vocabulary. First, we will model some rules using the Vocabulary provided. We model rules using a Rulesheet.
Action Open an existing Vocabulary by double-clicking Cargo.ecore in the Rule Project Explorer window.
13
Open the Vocabulary
Model
Action Take a moment to explore the Rule Operators, which are located in a tab to the lower left, adjacent to the Rule Project Explorer tab.
Note While the Rule Vocabulary contains our nouns (the things we reference in our business rules), the Rule Operators contain our verbs (the actions we take in our business rules). Corticon Studio comes with a rich set of operators for manipulating data, similar to the Excel function library. In addition, programmers can add new Extended Operators through an API (e.g., to perform a new statistical function or to make a call out). See Appendix D of the Rule Language Guide for more information.
14
Create a New Rulesheet
Model
Action To create a new Rulesheet, select File > New > Rulesheet from the Studio menubar.
15
The Create New Rulesheet Wizard

Action
Select Tutorial as the Parent Folder and enter Cargo as the File name. Click Next. Now, select Cargo.ecore as the Vocabulary to associate with your new Rulesheet and click Finish to complete the process.
16
Orientation to Corticon Rulesheets

This is an example of a Corticon Rulesheet, the metaphor used to model your business rules. Based on a decision table, the Corticon Rulesheet has been extended to allow the modeling of any business rules logic from simple to complex inferencing problems. This tutorial models only simple rules. See the Advanced Rule Modeling Tutorial and Rule Modeling Guide for some complex examples.
Model
5 1
Note Rulesheets contain sections for specific parts of rules. Sets of Conditions (label 1) and Actions (label 2) are tied together by the vertical columns on the right to form rules. For example, rule column 1 (label 3) is read as if Applicants skydiver value is true, then assign High to Applicants riskRating. We say that this column provides the model or implementation of the rule statement (label 4). Column 0 (label 5) is used to define calculation rules that contain Actions, but no Conditions (see Rule Modeling Guide for examples).
17
Model the Rules Step 1

Model the first rule: Cargo weighing <= 20,000 kilos must be packaged in a standard container.
Model
Action Enter the plain-language business rule into the Rule Statements section of the Rulesheet as shown. You can copy and paste from the text above.
18

Model the first rule: The condition of our first rule: Cargo weighing <= 20,000 can be restated as Cargo.weight <= 20000. Lets model this logic in Studio.
Model
Action Drag the Cargo.weight term from the Vocabulary and drop it in Row a of the Conditions pane, as shown.
Note Well use an orange dotted line to indicate dragging and dropping. Drag from the orange circle, and drop on the orange diamond.
Note Our first rule evaluates a condition and takes an action if and only if the condition is satisfied. Therefore, we will use the Conditions and Actions panes to model the rule.
19
Model
Continue modeling the first rule: Cargo weighing <= 20,000 kilos must be packaged in a standard container.
Action Next we type a value for cargo weight in cell 1a (row a, column 1). Type <=20000 in the cell. Dont use commas in values because commas are reserved to indicate multiple values.
20
Model
Action Now drag the appropriate term from the Vocabulary and drop it in row A of the Actions section. Next, define the action for rule 1 by selecting standard in the drop-down menu within Actions row A of column (rule) 1. The drop-down menu options were defined in the Vocabulary, which we will edit later. This action assigns the value of standard to the Cargo.container attribute.
21

Action Finally, enter the Rule Statements Reference number. This connects the Rule Statement to the corresponding model in a column in the Rulesheet above.
Model
Note Reference numbers logically link rows in the Rule Statements section to columns in the Conditions/Actions section notice how clicking on Rule Statement Ref 1 causes column 1 to highlight. The highlighting reminds you that column 1 is the model of the rule (expressed in plainlanguage) in Rule Statement Ref 1.
22

Model the second rule : Cargo with volume > 30 cubic meters must be packaged in an oversize container.
Model
Note When completed your Rulesheet should look like this
Action Finally, save your Rulesheet by selecting File > Save from the Studio menubar (or clicking the Save button).
Note When saved, Studio places a dash in the empty cells, meaning that the condition is ignored. The conditions and actions in a column are anded together. For example, rule 1 reads: Cargo weighing less than or equal to 20,000 kilos, ignoring volume, must be packaged in a standard container.
23

Note Next, we will Post the Rule Statements to the Cargo entity. This will provide an audit trail during rule execution, which you will see during rule testing.
Model
Note When you define a Post, an icon appears in the Post Message(s) row of the Rulesheet.
Action To Post, select the appropriate Severity Level from the drop-down box in the Post column. (in this case, select Info) . You must also select an Alias for the Rule Statement to post. The Alias defines what Entity the Rule Statement is posted to (in this case, select Cargo, which is the only option).
24
Check for Conflicts
Analyze
Now that we have finished modeling our rules, it is time to analyze our rules for logical errors. Very often, initial business rule specifications are ambiguous and incomplete. By ambiguous, we mean that the rules are conflicting under certain scenarios. By incomplete, we mean that the rules fail to address all possible scenarios. Prior to automating your rules, it is critical to eliminate logical errors in order to ensure that our decision service provides correct, consistent results. We call this Rule Referential Integrity. Studio provides unique and powerful features to help you ensure Rule Referential Integrity. These features will be explored in this Analyze phase of the rule management lifecycle.
Click on the Check for Conflicts icon on the Studio toolbar. OR Action Be sure your Cargo.ers tab is selected (colored blue), then Check for Conflicts. Choose Rulesheet > Logical Analysis > Check for Conflicts from the Studio menubar.
25
Identify Conflicts
Note Columns containing conflicts are shaded in pink. This indicates that one or more conflicts exist between the pink rules.
Analyze
Note The total number of conflicts detected is displayed.
26
Expand the Rules

Action Expand the Rules to reveal subrules (rules without dashes) inside the general rules (rules with at least one dash value). This helps you more accurately pinpoint the source of the ambiguity. Click on the Expand Rules icon on the Studio toolbar. OR Choose Rulesheet > Rule Column(s) > Expand Rules from the Studio menubar.
Analyze
Note When the rules are expanded, the source of the conflict becomes obvious. In scenarios with cargo weight <=20000 and cargo volume > 30, our rules are in conflict, defining mutually exclusive actions (assigning both standard and oversize containers). To get your rules right, this scenario must be addressed!
When expanded, rule 1 is represented as two columns (1.1 and 1.2), and rule 2 is represented as two columns (2.1 and 2.2). Expansion shows all of the logical possibilities for each rule. Rule 1 states Cargo weighing <= 20,000 pounds, ignoring volume, must be packaged in a standard container. Studio recognizes that there are only two possible ranges for volume (<=30 and >30), which we see in the expanded state.
27
Resolve Conflict Errors

Action To resolve the conflict, you can either change your original rules, or decide that one rule should override the other. Lets implement the override.
Analyze
First, collapse your rules back to the original state by clicking on the Collapse Rules icon on the Studio toolbar.
Action Next, override Rule 1 with Rule 2. In the Overrides row, from the overriding rule, select the column number of the rule to be overridden. Multiple selections can be made by holding the CTRL key.
Action Now, click the Check for Conflicts button again, and you will see that the conflict has been resolved. With the override, Rule 2 now means Use oversized containers when volume is >30, even when weight is <=20,000.
28
Check for Completeness

Conflict is one form of logical error. Another form is incompleteness, or loopholes in our logic.
Analyze
Action Check for logical errors in the Rulesheet.
Click on the Check for Completeness icon on the Studio toolbar. OR Choose Rulesheet > Logical Analysis > Check for Completeness from the Studio menubar.
Action This message window informs us that our rules were incomplete. We missed one scenario. Click OK to dismiss the window.
29
Resolve Completeness Errors Step 1
Analyze
The Completeness Checking algorithm calculates the set of all possible mathematical combinations of all values in all conditions. The algorithm then compares this set of possible combinations to those already specified in the Rulesheet and automatically inserts missing combinations of conditions as new columns. These new columns are shaded in green.
Note The Completeness Check adds condition values, but does not choose actions thats our job as rule modelers.
Lets define a new Rule Statement for this (formerly) missing scenario: Cargo weighing > 20,000 kilos, with volume <= 30 cubic meters, must be packaged in a heavyweight container.
30
Resolve Completeness Errors Step 2

Action
Analyze
First, add the new Rule Statement for rule 3. Next, define an action in rule cell 3a. In this case, select heavyweight as the container option. Last, post an Info message to the Cargo entity as we did for the first two rules. Your Rulesheet should look like the one below.
Note Dont forget to add enter the Rule Statement Reference to link it with the corresponding column. In this example, incompleteness was resolved by specifying an action for column 3, along with adding a new Rule Statement. Once resolved, remove the green highlighting by clicking the Clear Analysis Results button on the Studio toolbar.
31
Check for Completeness

A third form of logical error is circular logic.
Analyze
Click on the Check for Logical Loops icon on the Studio toolbar. OR
Action Check for logical errors in the Rulesheet.
Choose Rulesheet > Logical Analysis > Check for Logical Loops from the Studio menubar.
Note This is a very simple Rulesheet and contains no logical loops. Of note, while unintended logical loops are problematic, sometimes logical loops are a useful technique for solving complex inferencing problems that require recursive reasoning. You can learn more in the Rule Modeling Guide.
32
Save the Rulesheet
Analyze
Action Save your Rulesheet.
Click on the Save icon on the Studio toolbar.
OR Choose File > Save from the Studio menubar.
33
Create a New Ruletest
The Analyze phase helped to ensure the logical integrity of our rules. The Test phase helps to ensure that our rules give us the correct business results. Lets move on to testing. First, were going to define a test case for each one of our rules below by defining some input values and expected results. Corticon Studio allows us to pre-define our expected results and then highlights any variances in our test results. The table below defines one test case for each rule.
Test
Test Rule 1 Input Values Cargo.weight Cargo.volume Expected Results Cargo.container standard 1000 10
Test Rule 2
Test Rule 3
1000 40
30000 20 Note For test 2, we expect rule 2 to override rule 1.
oversize
heavyweight
34

Action Create a new Ruletest. Select Tutorial as the Parent Folder and name the file Cargo. All test files are assigned a file extension of .ert. Click Next > to continue.
Test
1. Select File > New > Ruletest on the Studio menubar OR 2. Use the New icon on the toolbar by selecting the down arrow to the right of the icon and select Ruletest.
35
Action Select the appropriate Rulesheet as your Test Subject. For our example, we want to use the Cargo Rulesheet within our Tutorial project directory. Click Finish to display the new Ruletest.
Note You can disregard the Remote Servers and Remote Decision Service panes - if you are interested in those, please refer to the Server Deployment Tutorial for more information.
36
Set Up the Test Scenario Step 1
Test
Action Drag the Cargo entity from the Vocabulary and drop it anywhere in the Ruletests Input and Expected panes, as shown. Cargo [1] on the Ruletests Input and Expected panes represents one instance or example of the Cargo entity.
Note As you can see, your new Ruletest is associated with the appropriate Rulesheet. This ensures that your Ruletest scenario will be tested by the right rules.
Note Changes you make to any Studio file will cause an asterisk character to appear in the files tab. This is a reminder to us to save the file.
37

Test Rule 1 Input Values Cargo.weight Cargo.volume Expected Results Cargo.container standard oversize heavyweight 1000 10 1000 40 30000 20 Test Rule 2 Test Rule 3
Test
Action First, remove unneeded attributes by selecting them and pressing the Delete key. Shift-click and Ctrlclick are also supported for multi-selecting contiguous and non-contiguous attributes, respectively. We will remove the manifestNumber attribute as it is not needed to test these rules.
Action Next, add test data for test #1 to the Testsheet, per the table above. Double-click on the desired term to open a data entry box. When complete, your Ruletest should look like this.
38

Test Rule 1 Input Values Cargo.weight Cargo.volume Expected Results Action Cargo.container standard oversize 1000 10 1000 40 Test Rule 2

Test Rule 3
Test
30000 20
heavyweight
Enter the remaining test data as shown to complete the Input pane of the Ruletest. You can easily duplicate the first test scenario by selecting Cargo [1], copying it, then pasting it below. Repeat for both the Input and Expected panes Also, select the expected container values from the drop-downs that appear when the container attribute is clicked. Your Ruletest should look like the one below.
39
Execute the Ruletest
Basic Rule Modeling Tutorial Test
Action Run the Ruletest. Running the Ruletest sends the data on the Input Testsheet to the rule engine embedded within Studio. The rule engine fires the appropriate rules and displays the results in the Output pane.
Click on the Run Test icon on the Studio toolbar. OR Choose Ruletest > Testsheet > Run Test from the Studio menubar.
Note The first time rules are executed, they are automatically compiled from the rule model into an optimized executable form, then deployed into the engine, which may take a few seconds. Once deployed, the rules will execute much faster on subsequent tests.
40
Verify the Test Results

Action Check the outcome of your test in the Ruletest Output pane. Note
All unchanged terms and values in the Ruletests Output pane are displayed in normal style. Any terms altered by rules, including their parent entities, are shown in bold text.
Note Messages shown in the Rule Messages pane are produced by using the Post command in your Rule Statements. Severity indicates whether a message contains information, warnings or violations. Message contains the Rule Statement text. Entity shows the entity to which this message is bound or linked. When we select the Cargo[1] entity within the Output pane, the third rule message is highlighted, showing the audit trail of rules that fired for that entity (in this case only one rule fired for Cargo[1]).
41
Verify the Test Results

Action Next, lets change one of the test cases in the Expected pane to illustrate how variance testing works. In the Expected pane, change the container value in Cargo[2] to standard. Then, rerun the test. Your Ruletest should look like this.
Note Here we see that the Cargo[2] entity and the container attribute are colored red in both the Output and Expected panes, indicating that our Output results differ from our Expected results. Change Cargo[2] Expected container value back to oversize before saving the Ruletest on the next page. Studio automatically highlights differences in values in red in both the Output and Expected panes. Other types of differences are also highlighted. Unexpected entities in the Output pane are highlighted in blue. And missing entities are highlighted green within the Expected pane. More details about color codes are included in the Studio Quick Reference Guide.
42
Save the Ruletest
Action Save the Test for future use.
Click on the Save icon on the Studio toolbar.
OR Choose File > Save from the Studio menubar.
43
Discover New Business Rules
Basic Rule Modeling Tutorial Discover

Scope Discover
When the time comes to change your rules, youll be glad you decided to model and manage them in Corticon Studio.
Test Model
Lets go through another development lifecycle, starting with the discovery of a new business rule.
Analyze Deploy
Collect Cargo
Package Cargo
Ship Cargo
Initial Rules: Cargo weighing <= 20,000 kilos must be packaged in a standard container. Cargo with volume > 30 cubic meters must be packaged in an oversize container. Added after Completeness Check: Cargo weighing > 20,000 kilos, with volume <= 30 cubic meters, must be packaged in a heavyweight container. New Rule (to add now): Cargo requiring refrigeration must be packaged in a reefer container.
44
Add New Rule Statements

Action Switch back to your Rulesheet by clicking the Cargo.ers tab. If you closed it earlier, reopen it using the Open menu or by double-clicking the file inside the Rule Project Explorer window.
Basic Rule Modeling Tutorial Model
Action Enter the new Rule Statement from the previous page. This will guide us when we model the new rule.
Note To model this rule, we will need to add two terms to the current Vocabulary. First, we need to add a new attribute to the Cargo entity to define whether the Cargo requires refrigeration or not (well call this needsRefrigeration). Second, well need to add reefer as another possible selection option for the container attribute.
45
Open and Edit the Vocabulary
If already open , select the Cargo.ecore tab. If not open: Select Cargo.ecore from the Recent File list at the bottom of the File menu OR Use the File > Open File menu option OR Double-click on the file in the Rule Project Explorer pane.
46
Add an Attribute Step 1

Action Edit the Vocabulary using Corticon Studios Vocabulary Editor. Within the Vocabulary editor window in the upper right pane (not the Vocabulary window in the upper left pane), right click on the Cargo entity and choose Add Attribute from the popup menu. OR
Action
Action
Highlight the Cargo entity and choose the Add Attribute icon on the toolbar. OR Highlight the Cargo entity and choose Vocabulary > Add Attribute from the Studio menubar.
Add a new attribute.
47
Add an Attribute Step 2
Action Change the attribute name to needsRefrigeration and set the data type to Boolean.
First, double click on the attribute name to type over its initial default value.
Next, choose the datatype Boolean in the pull-down menu.
48
Modify a Custom Data Type

Action
Add an reefer as another allowable type of container.
Select the container attribute and note the Data Type: containerType. This is a custom data type that defines a set of allowable values for container (an enumerated set).
To define custom data types, you must first click on the root node of the Vocabulary, noted by the open book icon
Next, click on the containerType entry. This will display the enumerated set in the rightmost table, if available.
Last, add reefer as both a Label and a Value, as above.
Note Custom data types is a powerful capability that allows you to define rules at the level of the Vocabulary that are reused anywhere the Vocabulary terms are used. You can learn more about custom data types in the Rule Modeling Guide.
49
Save the Vocabulary Changes
Click on the Save icon on the Studio toolbar. Action Save the Vocabulary and exit the Vocabulary Editor pane. OR Choose File > Save from the Studio menubar.
50
Model the New Rules
New rule: Cargo requiring refrigeration must be packaged in a reefer container.
Action Now that the Vocabulary contains the new terms required by the new rule, complete the model as shown below.
Action Be sure to include Reference links from the Rule Statements to the columns containing the new rule models. And, add Post and Alias.
51
Check New Rules for Conflicts

To review this procedure, refer to page 25. Note
Basic Rule Modeling Tutorial Analyze
Action
Check for logical errors in the Rulesheet.
Rule analysis is an iterative process. Whenever we add or change our rules, it is necessary to re-analyze. In this case, adding a single new rule has caused three new conflicts, one with each of our three existing rules. You can step through multiple conflicts, and filter the Rulesheet to view only the conflicting rules, via the buttons to the right of the Conflict Check button:
52
Check New Rules for Conflicts
Action Reefer containers are only available for standard and heavyweight, but not for oversize loads. Thus, lets set rule 4 to override rules 1 & 3, and rule 2 to override rules 1 & 4. You can select multiple values in the override cell by holding down the Ctrl key. When complete, your Rulesheet should look like this:
53
Check New Rules for Completeness
Action Check for Completeness again
54
Modify the Ruletest
Action Your last step is to modify your test case to test the new rule. First save your rules. Next, in Ruletest Cargo.ert, first copy and paste Cargo[1] to create Cargo[4], in both the Input and Expected panes. Next, drag and drop the needsRefrigeration attribute from your Vocabulary onto both Cargo[4] entities. In both panes, set the value of needsRefrigeration to true. Next, in the Expected pane, change the value of container to reefer. Last, execute the test. Your Ruletest should look like this:
55
Summary
Congratulations! You have now completed two full iterations of the Corticon development lifecycle, and understand the basic concepts of rule modeling, analysis, and testing in Studio.
Note
Scope
Discover
To learn advanced rules modeling techniques, see the Advanced Rules Modeling Tutorial.
Test
Model
Analyze
Deploy
Note To learn how to deploy rules, see the Tutorial for Corticon Server Deploying Web Services.
56
Appendix A: Corticon Technical Publications

Document or Resource Corticon Tutorials Tutorial for Corticon Studio 5.2 Basic Rule Modeling Tutorial for Corticon Studio 5.2 Advanced Rule Modeling Tutorial for Corticon Server 5.2 Deploying Web Services Format Description
A step-by-step introduction to modeling, analyzing, and testing rules and decisions in Studio 5.2. Recommended for all new users. An intro to more advanced modeling concepts and practices in Studio 5.2. For users who want a more thorough introduction to Studio 5.2s capabilities. A step-by-step introduction to installing the Server as a Web Services server and deploying and exposing decisions as Web Services.
Rule Language Guide
57
Advanced Rule Modeling Tutorial
Corticon Decision Management Software

The Easiest Way to Manage and Automate Your Business Rules
Corticon Business Rules Modeling Studio 5.2 Tutorial Advanced Rule Modeling
2012 Progress Software Corporation and/or its subsidiaries or affiliates. All rights reserved. These materials and all Progress software products are copyrighted and all rights are reserved by Progress Software Corporation. The information in these materials is subject to change without notice, and Progress Software Corporation assumes no responsibility for any errors that may appear therein. The references in these materials to specific platforms supported are subject to change. Actional, Apama, Artix, Business Empowerment, Business Making Progress, Corticon, Corticon (and design), DataDirect (and design), DataDirect Connect, DataDirect Connect64, DataDirect Technologies, DataDirect XML Converters, DataDirect XQuery, DataXtend, Dynamic Routing Architecture, Empowerment Center, Fathom, Fuse Mediation Router, Fuse Message Broker, Fuse Services Framework, IONA, Making Software Work Together, Mindreef, ObjectStore, OpenEdge, Orbix, PeerDirect, Powered by Progress, PowerTier, Progress, Progress DataXtend, Progress Dynamics, Progress Business Empowerment, Progress Empowerment Center, Progress Empowerment Program, Progress OpenEdge, Progress Profiles, Progress Results, Progress Software Business Making Progress, Progress Software Developers Network, Progress Sonic, ProVision, PS Select, RulesCloud, RulesWorld, Savvion, SequeLink, Shadow, SOAPscope, SOAPStation, Sonic, Sonic ESB, SonicMQ, Sonic Orchestration Server, SpeedScript, Stylus Studio, Technical Empowerment, WebSpeed, Xcalia (and design), and Your Software, Our TechnologyExperience the Connection are registered trademarks of Progress Software Corporation or one of its affiliates or subsidiaries in the U.S. and/or other countries. AccelEvent, Apama Dashboard Studio, Apama Event Manager, Apama Event Modeler, Apama Event Store, Apama Risk Firewall, AppsAlive, AppServer, ASPen, ASP-in-a-Box, BusinessEdge, Cache-Forward, CloudEdge, DataDirect Spy, DataDirect SupportLink, Fuse, FuseSource, Future Proof, GVAC, High Performance Integration, ObjectStore Inspector, ObjectStore Performance Expert, OpenAccess, Orbacus, Pantero, POSSE, ProDataSet, Progress Arcade, Progress CloudEdge, Progress Cloudware, Progress Control Tower, Progress ESP Event Manager, Progress ESP Event Modeler, Progress Event Engine, Progress RFID, Progress RPM, Progress Responsive Cloud, Progress Responsive Process Management, Progress Software, PSE Pro, SectorAlliance, SeeThinkAct, Shadow z/Services, Shadow z/Direct, Shadow z/Events, Shadow z/Presentation, Shadow Studio, SmartBrowser, SmartComponent, SmartDataBrowser, SmartDataObjects, SmartDataView, SmartDialog, SmartFolder, SmartFrame, SmartObjects, SmartPanel, SmartQuery, SmartViewer, SmartWindow, Sonic Business Integration Suite, Sonic Process Manager, Sonic Collaboration Server, Sonic Continuous Availability Architecture, Sonic Database Service, Sonic Workbench, Sonic XML Server, The Brains Behind BAM, WebClient, and Who Makes Progress are trademarks or service marks of Progress Software Corporation and/or its subsidiaries or affiliates in the U.S. and other countries. Java is a registered trademark of Oracle and/or its affiliates. Any other marks contained herein may be trademarks of their respective owners.
About this Guide
The Basic Rule Modeling Tutorial provided you with an introduction to the Corticon Studio, the easiest way to manage and automate your business rules. You learned how to capture rules from business specifications, model the rules, analyze them for logical errors and test the execution of your rules; all without programming. Unlike the Basic Rule Modeling Tutorial, this manual does not attempt to capture or reproduce the mechanics of rule modeling. Instead, you will learn the concepts underlying some of Studios more complex and powerful functions, including: Using Scope and Defining Aliases in rules Understanding Collections Using String, DateTime, and Collection operators Modeling formulas and equations in rules Using Filters Sequencing Rulesheets in a Ruleflow Testing at rule, Rulesheet and Ruleflow levels.
Note As you already know, the Ruleflows that you build using Studio may be deployed as executable, standards-based Decision Services that can be used by other software applications via Java Messaging or XML Web Services. Decision Services are in use today across the globe, automating many high-volume decision-intensive processes. See the Tutorial for Corticon Server Deploying Web Services for instructions on how to deploy and test as Decision Services the Ruleflows you build here.
Note This Tutorial is designed for hands-on use. We recommend that you type along with the instructions and illustrations presented. Screenshots in this Tutorial will be cleanest and sharpest when printed using a Postscript printer driver (usually identified by PS in the printer name).
Table of Contents
p. 1 Building the Vocabulary Create an ER Diagram The Barcode System Our New Vocabulary High-Level Business Process Low-Level Business Process Organizing the Business Rules Defining Scope Modeling the 1st Rulesheet 1st Rulesheet Completed Modeling the 2nd Rulesheet 2nd Completed Rulesheet Modeling the 3rd Rulesheet 3rd Rulesheet Completed Summary Appendix A Tech. Pubs p. 2 p. 5 p. 10 p. 11 p. 12 p. 13 p. 14 p. 16 p. 18 p. 31 p. 32 p. 51 p. 52 p. 60 p. 61 p. 62
Discover
Test the 1st Rulesheet Summary The Test Results Testing the 2nd Rulesheet Summary The Test Results Testing the 3rd Rulesheet Summary The Test Results p. 19 p. 30 p. 36 p. 50 p. 56 p. 59
Test
Model
Analyze
Logical Analysis and Validation are not demonstrated in this Tutorial in order to minimize duplication with the Basic Rule Modeling Tutorial. Please also see the Rule Modeling Guide for more information on Logical Analysis and Validation features of Corticon Studio.
Deploy
See the Tutorial for Corticon Server Deploying Web Services and the Server Integration & Deployment Guide for more information about deploying Ruleflows as Decision Services.

Scenario
Advanced Rule Modeling Tutorial Discover
The owner of a chain of grocery stores intends to build and install a system of business rule-based smart cash registers in all of its branches. Some branches are large supermarkets, and some are smaller convenience stores, which sell gasoline and other essentials. In addition to minimum cash register functionality (adding up the prices of items in a customers shopping cart, for example) the new system will also include the ability to apply promotional rules, rules that determine coupon generation, loyalty program rules, and special warning rules to alert the cashier to take certain actions. Because every item in every store has a bar-coded label, the systems scanner will be able to determine complete information about each item, such as which department the item comes from. To foster customer loyalty and drive additional sales, a Preferred Shopper program will be launched in conjunction with the installation of the new business rule-based cash registers. Shoppers who enroll in the program will be issued Preferred Shopper membership cards (one card per household) to present to the cashier at check-out time. Benefits of the Preferred Shopper program include: A Preferred Shopper earns 2% cash back on all purchases at any branch The Preferred Shopper account will track the accumulated cash back and allow the shopper to apply it to any visits total amount. The cashier will ask a Preferred Shopper if he/she would like to apply a cash back balance to his/her current purchase Once a Preferred Shopper chooses to apply his cash back balance, the cumulative cash back total maintained by the system will be reset to zero, and the accumulation of cash back begins anew with the customers next purchase. A Preferred Shopper will be eligible for special promotions and coupons as defined below: Preferred Shoppers receive a coupon for one free balloon for every item purchased from the Floral department Expiration date: none Preferred Shoppers receive a coupon for $2 off their next purchase when 3 or more Soda/Juice items are purchased in a single visit. Expiration date: one year from date of issue Preferred Shoppers receive a coupon for 10% off their next gasoline purchase at any chain-owned convenience store with any purchase of $75 or more. Expiration date: 3 months from date of issue In compliance with local, state and federal laws, the chain needs to ensure that all purchases of liquor (any items from the Liquor department) are made by shoppers 21 or older. A simple alert or warning to the cashier will be sufficient to prompt an ID check.
Building the Vocabulary Identifying the Terms

Identifying the Terms of the Scenario
Advanced Rule Modeling Tutorial Model
The owner of a chain of grocery stores intends to build and install a system of business rule-based smart cash registers in all of its branches. Some branches are large supermarkets, and some are smaller convenience stores, which sell gasoline and other essentials. In addition to minimum cash register functionality (adding up the prices of items in a customers shopping cart, for example) the new system will also include the ability to apply promotional rules, rules that determine coupon generation, loyalty program rules, and special warning rules to alert the cashier to take certain actions. Because every item in every store has a bar-coded label, the systems scanner will be able to determine complete information about each item, such as which department the item comes from. To foster customer loyalty and drive additional sales, a Preferred Shopper program will be launched in conjunction with the installation of the new business rule-based cash registers. Shoppers who enroll in the program will be issued Preferred Shopper membership cards (one card per household) to present to the cashier at check-out time. Benefits of the Preferred Shopper program include: A Preferred Shopper earns 2% cash back on all purchases at any branch The Preferred Shopper account will track the accumulated cash back and allow the shopper to apply it to any visits total amount. The cashier will ask a Preferred Shopper if he/she would like to apply a cash back balance to his/her current purchase Once a Preferred Shopper chooses to apply his cash back balance, the cumulative cash back total maintained by the system will be reset to zero, and the accumulation of cash back begins anew with the customers next purchase. A Preferred Shopper will be eligible for special promotions and coupons as defined below: Preferred Shoppers receive a coupon for one free balloon for every item purchased from the Floral department. Expiration date: none. Preferred Shoppers receive a coupon for $2 off their next purchase when 3 or more Soda/Juice items are purchased in a single visit. Expiration date: one year from date of issue. Preferred Shoppers receive a coupon for 10% off their next gasoline purchase at any chain-owned convenience store with any purchase of $75 or more. Expiration date: 3 months from date of issue. In compliance with local, state and federal laws, the chain needs to ensure that all purchases of liquor (any items from the Liquor department) are made by shoppers 21 or older. A simple alert or warning to the cashier will be sufficient to prompt an ID check.
Building the Vocabulary Grouping the Terms
Identifying the Terms of the Scenario Compiling a list of terms based on our findings within the previous slide, the following assumptions can be made and can be used to build a Fact Model or an ER Diagram. A Customer may be a Preferred Shopper and have a Preferred Shopper account that is identified by swiping their Preferred Card at checkout A Preferred Shopper account has a Card Number A Preferred Shopper account holds a Cash-Back Balance One Preferred Shopper account may be used by anyone in a family A Customer uses a Shopping Cart to carry items A Customer has a Name An Item has a Name An Item has a Price An Item has a Bar-coded Label An Item is located in a Department A Shopping Cart contains the Items a Customer purchases during each visit A Shopping Cart has a Total Amount A Cash-Back Bonus is calculated using the Shopping Carts Total Amount and is deducted from the Total Amount upon Customer request Coupons are issued to shoppers A Coupon has a Description A Coupon has an Expiration Date A Coupon has an Issue Date
Building the Vocabulary Organizing the Terms

Identify the Business Terms The terms that we will use to build a Fact Model or ER Diagram translate to the terms that we can use in our Vocabulary, first building our entities and then adding their attributes, including their data types and mode, then adding any associations that exist between entities in the diagram we create.
name isPreferredMember Item name price department barCode
Term Customer Entity
Type of Term
Data Type
Attribute Mode
attribute of Customer attribute of Customer Entity attribute of Item attribute of Item attribute of Item attribute of Item Entity attribute of Shopping Cart attribute of Shopping Cart attribute of Shopping Cart attribute of Shopping Cart attribute of Shopping Cart Entity attribute of PreferredAccount attribute of PreferredAccount Entity attribute of Coupon attribute of Coupon attribute of Coupon
String Boolean
base extended transient
String Decimal String String
base base base base
Attribute Mode Most of these attributes use Base mode because their values will be sent in to the rules or sent back from the rules. In other words, base attributes are what carry values to and from the client application. Extended Transient mode is used when an attributes value is assigned or derived by rules, but not sent in from or back to the client application. Well discuss this more later in this tutorial.
ShoppingCart totalAmount cashBackEarned savings useCashBack checkID PreferredAccount cardNumber cumulativeCashBack Coupon issueDate description expirationDate
Decimal Decimal Decimal Boolean Boolean
base extended transient base base extended transient
String Decimal
base base
Date String Date
base base base
Create an ER Diagram
Create an ER Diagram
The Entity-Relationship (ER) Diagram below is a graphical depiction of the entities and their respective attributes, as well as the associations (relationships) between entities, that we will be using in our Vocabulary during this exercise.
Define Entities
Entities Based on our ER Diagram, we will need to build Customer, Coupon, ShoppingCart, Item, and PreferredAccount (our main business terms) into our Vocabulary.
Note The Customer Entity.
10
Add Attributes to the Entities

Attributes
Entities have properties or characteristics that distinguish them from other Entities, and which distinguish one instance of an Entity from another instance of the same Entity. We call these Attributes. Obviously, all customers cant be the same customer, so how do we distinguish between them? By defining attributes that will hold the values of each customers name, etc
Note A customers attributes hold values for each customer.
11
Extended Transient Attributes

Extended Transient Attributes
Some attributes are little more than intermediate or temporary value holders. We dont need to return these values in a response, or save them in a database. In Studio, Extended Transient attributes fill this purpose. Because an extended transient is not part of the Decision Services response message, its presence (or absence) in the Vocabulary or rules does not affect the technical integration with the Decision Service in runtime. Therefore, a Rule Modeler may add/remove extended transients to/from the Vocabulary without fear of upsetting the runtime integration. In our example, the cashBackEarned attribute will serve as an intermediate value, helping to calculate other attribute values that will be included in the Decision Services response message (Base attributes).
Note A Shopping Cart has the Extended Transient attribute cashBackEarned. Its value will be based on the totalAmount of the items purchased in the shopping cart.
12
Define Associations Between Entities

Associations
Associations between entities allow us to define relationships between them. In our example, each individual Customer will have his/her own shopping cart, most likely with different items in each cart. How do we distinguish between them? By associating a unique instance of a shopping cart with each Customer who visits our store. Over successive visits, a customer may have several shopping carts.
Note An association (one-to-many) between the Customer and a Shopping Cart.
13
The Barcode System
The Barcode System As part of our scenario, the following tables display the Barcode key and the codes for various departments within a store. We will make use of the codes during our rule modeling to identify items being purchased from specific departments. Produce Canned Goods Grocery Store Barcode Key sample barcode: xxyyyzzzzz xx yyy zzzzz store code department code item number Meat Deli Frozen Foods Soda/Juice Floral Bakery Housewares Detergent & Cleaning Supplies School Supplies Liquor
Grocery Store Department Codes Department Code 260 265 270 275 280 285 290 295 300 305 310 291
Page 14 10
Our New Vocabulary

Our New Vocabulary Based on our ER Diagram, here is the new Vocabulary, within Studio, that we will use in this Tutorial. Notice that we are interested in working with the Customer root-level entity, and the associations between it and the preferredAccount, Shopping Cart and Item entities. Read on to find out why we are interested in this particular perspective or view of our Vocabulary Also notice that we defined a role named preferredCard for the association from Customer to preferredAccount. Role names are optional but may help in describing or specifying relationships between two entities.
Action From the previous pages, we have everything needed to build a Vocabulary that incorporates the key facts and relationships in our Scenario. If necessary, refer to the Basic Rule Modeling Tutorial and the Studio Quick Reference Guide to review the mechanics of building the Vocabulary in Studio. The Rule Modeling Guides Building the Vocabulary chapter contains more detail on the steps followed up to this point.
15
The High-Level Business Process
Customer arrives
Customer shops
Checkout
Customer departs
Note At a high level, this is the basic process followed by every customer making purchases at a store. While there may be several steps involved in this process, we as rule modelers are most concerned with those steps where decisions are made. In this case, the Checkout step contains the rule-based decisions that are built into the stores cash registers. On the next page, well drill down into the Checkout step and define more detail about the rules inside.
16
The Low-Level Process & Rules
Customer arrives
Customer Shops
Checkout
Customer departs
Note If a natural sequence or flow of logical steps can be identified within a single decision step, it often makes sense to organize the steps using separate Rulesheets for each logical step, then combining them into a Ruleflow. Well do that in this Scenario.
Note According to the Scenario, there are a few general categories of activity performed by rules during the Checkout step: 1) Identify warning/alert situations. 2) Calculate totals, apply promotions and generate coupons. 3) Apply cash back (if applicable).
Raise Alerts
Calculations, Promotions, and Coupons
Apply Cash Back
17
Organizing the Business Rules
Raise Alerts
Apply Cash Back
Liquor purchases (any items from the Liquor department) can only be made by shoppers 21 or older
Preferred Shoppers receive a coupon for one free balloon for every item purchased from the Floral department. Expiration date: none Preferred Shoppers receive a coupon for $2 off their next purchase when 3 or more Soda/Juice items are purchased in a single visit. Expiration date: one year from date of issue Preferred Shoppers receive a coupon for 10% off their next gasoline purchase at any chain-owned convenience store with any purchase of $75 or more. Expiration date: 3 months from date of issue Preferred Shoppers earn 2% cash back on all purchases at any branch A Preferred Shopper account will track the accumulated cash back and allow the customer to apply it to reduce any visits total amount. The cashier will ask a Preferred Shopper if he/she would like to apply a cash back balance to his/her current purchase. Once a Preferred Shopper chooses to apply his cash back balance, the cumulative cash back total maintained by the system will be reset to zero, and the accumulation of cash back begins anew with the customers next purchase.
18
Preparing to Model the 1st Rulesheet

Note Before we build or model anything, we need to think about how to approach this part of the problem. The 1st business rule requires the system to examine all items in a customers shopping cart and determine which items (if any) come from the Liquor department. According to the barcode chart, this means any item with numbers 291 occupying the 4th thru 6th characters of the barcode. If any are present, the cashier must be alerted to check the customers identification. So lets approach this Rulesheet as containing two rules: the first will determine the department code for every item in the shopping cart, and the second will determine if any of the items come from the Liquor department. If so, a rule will fire which raises an alert of some kind.
Action Once an approach has been chosen, we need to choose the perspective in the Vocabulary that best represents the terms required by the rules themselves. This perspective may change from Rulesheet to Rulesheet. For this first Rulesheet, beginning with Customer as the root entity and working with the associated shoppingCart and its items makes sense because its a Customers transaction that is processed by the checkout process step. The contents of the transaction are the shoppingCart and its associated items.
19
Defining Scope
Action Display the Scope section of the Rulesheet by clicking the icon in Studios toolbar, or select Rulesheet>Advanced View from Studio's menubar. Drag and drop the Customer entity and then the highlighted shoppingCart (the one associated with Customer) into the Scope pane of the Rulesheet. Action
Enter an Alias for this term by double-clicking it. Lets call a customers shopping cart their currentCart. Henceforth, when we model rules involving a customers shopping cart, well use the alias currentCart.
Note Scope is a powerful and important concept. It helps us tell the Corticon rule engine which data to use when evaluating and executing rules In our example, we want the cash register system to process not just any shopping cart, but customers shopping carts. This ownership role between a customer and his shopping cart is what the association means. Well incorporate this association in the rules we build by using the alias that represents it. Scope is such an important concept that we devote an entire chapter to it in the Rule Modeling Guide.
Action Weve also named this Rulesheet checks as a way of reminding ourselves of the overall organization: this Rulesheet will perform any necessary checks and raise alerts as required. Rulesheets can be renamed or saved to another location by selecting the Save As option on the File menu and renaming the Rulesheet and/or selecting the Project folder where you want to move it, if necessary.
3 20
Defining Scope
Action
We know from the cardinality of the association between ShoppingCart and Item that one shopping cart can contain many items. So it may prove convenient to define another alias that represents all of the items in a customers shopping cart. We do this by dragging the associated item from the Vocabulary to the Scope window, dropping it on shoppingCart, and giving it an alias name by double-clicking it and typing items in the entry box. Assigning meaningful alias names is good practice and using the plural form of item reminds us that the alias represents all of the items in the customers shopping cart. Using aliases is optional in many cases they serve to simplify and shorten rule expressions. But in certain cases, using aliases is mandatory. Applying collection operators to sets or collections of data in rules requires the use of aliases. Since well be working with the collection of items in a customers shopping cart a bit later, we must have the items alias defined and ready.
Note Aliases will always insert themselves automatically when terms are dragged and dropped from the Scope section or Vocabulary window to the Rulesheet. Since all Studio expressions are casesensitive, its better to drag and drop terms instead of typing them manually less chance of errors!
21
Modeling the 1st Business Rule

Our First Rule
In order to model the 1st business rule, we need to be able to identify items in a customers shopping cart that come from the Liquor department. We know an items department is identified by the 4th thru 6th characters in the items barCode. Using the items alias, weve added a rule in an Actions row of Column 0 using the .substring operator to determine the department code for an item. Remember that the alias items represents the collection of all items associated with a customers shopping cart. So this rule will evaluate and process every item in a customers shopping cart, extract the department code for each, and then assign that code to the items department attribute. For all items in a given customers shopping cart, this rule will execute once per item. This iteration is a natural behavior of the rule engine: it will automatically process all data that matches the rules scope. As terms are dragged from the Vocabulary, they are automatically added to the Scope window. Over time, the Scope window becomes a reduced version of our Vocabulary, containing only those terms used by the rules in that Rulesheet.
22
Testing the 1st Rule

Action Lets test our first rule. In the Input column of a new Ruletest as shown here, we have a customer with an associated shopping cart containing two items. One of them is from the Liquor department. Logical Analysis
Advanced Rule Modeling Tutorial Test
Ordinarily, wed check for Conflicts and Completeness before testing with data. But these are meaningful only for columns containing Conditions. Since Column 0 has no Conditions, its not necessary to perform these checks now. The steps for performing these checks, and taking any necessary corrective actions, are detailed in the Basic Rule Modeling Tutorial and will not be repeated in this guide.
Action It is critical to drop the items from the Vocabulary into the Input panel of the Ruletest in the order indicated so that we duplicate the Scope of the rule which will be processing this data. First, drag and drop the Customer entity into the Input panel. Then, drop the shoppingCart entity onto the Customer entity. Finally, drag and drop the item entity onto the shoppingCart entity twice. When finished, enter test data as shown. Finally, execute the Ruletest.
3 4
23
1st Rule Test Results
Test Results Our first rule has worked as expected! Characters 4-6 have been successfully parsed from each items barCode and assigned to its department attribute.
Testing as you go By modeling a rule and then immediately testing it, weve demonstrated good Studio modeling practice. Testing right away will help expose flaws in our rules before we build too many.
24
Modeling the 1st Business Rule Continued

Our 1st Business Rule Continued Now that department codes are readily available for every item in a customers shopping cart, we need to determine if any came from the Liquor department. This type of question requires us to look inside our collection of items and see if there exists an item with department = 291. Since we only need one check ID alert per checkout transaction, this is a job for a collection operator. A collection operator, because it acts on collections, will evaluate once per collection and not once per item as the previous rule did. In other words, we want one check ID alert if the shopping cart contains any liquor. But we dont need, say, 5 alerts if the shopping cart contains 5 liquor items. Once is enough. Making use of the items alias, weve added a Condition that determines if any Liquor items exist in the customers shopping cart. An Action assigns a value of true to the shopping carts checkID attribute if any are found. Were assuming that the checkID term will act as the alerting mechanism to signal the cashier that an ID check is required during this checkout transaction.

Aliases with Collections Using aliases to represent collections is mandatory when collection operators (like exists) are used. Much more information on collections and collection operators is contained in the Rule Modeling Guide and the Rule Language Guide.
25
1st Business Rule Test Results Continued

Testing the Complete 1st Business Rule Re-running the same Ruletest as before, we see that our Condition/Action rule has worked as expected! A customers shopping cart containing an item from the Liquor department has been identified, and the checkID attribute is set to true to alert the cashier to check the customers ID. Notice that the business rule statement has also been posted in the Message Box. Often, a simple message is all we need to raise an alert or warning.
Rule Models vs. Business Rules There isnt always a one-to-one correlation between the Business Rules defined in a business scenario and the corresponding rules modeled in Studio. Often, as we see in this example, one Business Rule requires more than one rule in Studio. This is normal. A good guideline is to keep your individual rule models relatively simple and let them work together to perform more complex logic defined by the Business Rules. In this first Rulesheet, two rule columns work together to accomplish the goal of the Scenarios check ID Business Rule.
26
Adding to Scope
Action
Next, lets add an alias to represent a customers Preferred Account. Not all customers will have Preferred Accounts, but those who do will have an associated preferredCard. Remember from our initial scenario, customers holding a preferredCard are eligible for various promotions, such as coupons for discounts on gasoline purchases. The account alias defined here prepares us to examine the collection it represents in the next rule.
Note The account alias represents a potential collection, that is, a customer will have a Preferred Card only if they have a Preferred Account. And the many-toone cardinality of the association means a customer will have at most one account. Other customers (as with a family) may share the same Preferred Account. For Customers who dont have Preferred Accounts, the alias account represents an empty collection (the collection contains no elements).
27
Modeling a 2nd Condition/Action Rule

Flagging our Data The notEmpty collection operator checks a collection for the existence of at least one element in the set. Because notEmpty is acting on a collection, the account alias must be used with it. If the condition is true, we know the customer has an account. Weve added an action that assigns the isPreferredMember attribute (from the Customer entity) the value of true and posts an informational message. Now, whenever we need to know if a customer is a preferred customer, we simply refer to the value of her isPreferredMember attribute. This method of flagging an entity with a boolean attribute (also known as a flag) is convenient when modeling larger Ruleflows. The value of the flag, like all attributes, will carry over to other rules on this and other Rulesheets in the same Ruleflow.
Action Now well add a second Condition/Action rule that checks if the customer has a Preferred Card account. Weve modeled a boolean condition in row b that does this using the notEmpty collection operator. If the account alias is not empty, we know the customer has such an account.
28
Testing the 2nd Condition/Action Rule

Action Now lets test our second Condition/Action rule. For our rule to detect the presence of a Preferred Card account associated with this customer, we need to provide the appropriate test data. Drag and drop the preferredCard entity onto the Customer entity in the Ruletest Input, as shown to the right. If you dont get the identical indented structure as shown, delete the entity and try again. Now execute the Ruletest.
29
2nd Condition/Action Rule Test Results

Results Notice that the isPreferredMember extended transient attribute has been inserted and assigned a value of true, and that an informational message has been posted. Our second Condition/Action rule has worked as we expected!
30
Modeling the Price Summation Rule

Action
Finally, well add one more Action to Column 0 that will calculate the totalAmount of all items in a customers shopping cart. This is accomplished by using the sum operator to add up the price attributes of all elements in the items alias, then assigning that value to the totalAmount attribute.
Note Adding Rule Statements is good practice, even if you dont post them as messages.
31
Testing the Price Summation Rule

Action
Lets test our third, and final, rule on this Rulesheet. In the Input Testsheet shown here, we have a customer with two items in his shopping cart. Does our third rule provide us with the totalAmount for the items in the Customers shopping cart?
Action Lets run our test and see what happens...
32
Price Summation Test Results
Results A lot has happened here First, note that our rules to determine if a) an ID check is required and b) if the customer is a Preferred Card holder still work as before. Its always good to doublecheck cumulative test results to make sure nothing has broken along the way. Also, notice that the totalAmount attribute has returned a value of 8.98, which is the correct sum of the prices of items 1 and 2. Our third rule has also worked as we expected!
33
Summary The Test Results

Summary An item has been purchased from department 291, the Liquor department (identified by the barCode). A checkID alert is issued and a warning message is posted. The isPreferredMember attribute has a value of true because a preferredCard entity is associated with the customer; the appropriate informational message has been posted. Finally, the totalAmount shows that the two item prices have been added together correctly. So the rules weve built on this Rulesheet have all functioned as we expected them to!
34
1st Rulesheet Completed

Completed Rulesheet Heres our first completed Rulesheet!
35
Model the 2nd Rulesheet

Action
Now its time to apply some promotions to our Preferred Account holders when they spend a pre-defined amount of money or buy items from specific departments at our store. According to the Scenarios Business Rules, these promotions vary, but include discounts, rebates, or even free gifts when items are purchased in specific amounts or from specific departments. The promotions will change frequently modeling them in Corticon will make future changes much easier. Lets create a second Rulesheet (well call it coupons) and model our rules to reflect these promotions for our Preferred Account holder customers. When multiple Rulesheets are included in a Ruleflow (a single .erf file), the Rulesheets will execute in a sequence determined by their Rulesheet order in the Ruleflow Editor. For more information about sequencing Rulesheets as well as additional details on the Ruleflow Editor, see the Studio Quick Reference Guide.
Raise Alerts
Apply Cash Back
Preferred Shoppers earn 2% cash back on all purchases at any branch Preferred Shoppers receive a coupon for one free balloon for every item purchased from the Floral department. Expiration date: none Preferred Shoppers receive a coupon for $2 off their next purchase when 3 or more Soda/Juice items are purchased in a single visit. Expiration date: one year from date of issue Preferred Shoppers receive a coupon for 10% off their next gasoline purchase at any chain-owned convenience store with any purchase of $75 or more. Expiration date: 3 months from date of issue
36
Scope Revisited
Scope Revisited Create the Scope for the new coupons Rulesheet as shown below.
First, a customers shopping cart is still assigned an alias of currentCart, just like on the checks Rulesheet. But on the coupons Rulesheet we have created two new aliases to define the currentCart.item perspective of our data. For now, well simply define the two aliases allItems and SodaItems to represent the same perspective, but well differentiate between them shortly. As before, the account alias still represents the preferredCard account associated with our customer.
Note When creating Ruletests that need to process multiple Rulesheets in sequence, be sure to choose your Ruleflow as the Test Subject during the Ruletest Creation Wizard process. That will ensure that all Rulesheets are processed in the correct sequence and allow values derived on prior Rulesheets to be used in subsequent Rulesheets. Ruleflow The Rulesheet processing sequence is visible here in the Ruleflow diagram at the right. For a complete discussion of the Ruleflow Editors purpose and functionality, please refer to the Quick Reference Guide.
37
Filter Expressions
Filters
Filters A Filter expression acts to limit or reduce the data in working memory to only that subset whose members satisfy the expression. A filter does not permanently remove or delete any data, it simply excludes data from evaluation by the rules in the same Rulesheet. We often say that data satisfying the Filter expression survives the filter. Data that does not satisfy the expression is said to be filtered out. Data that has been filtered out is ignored by other rules in the same Rulesheet. Data filtered out in one Rulesheet is not also filtered out in other Rulesheets unless you include the Filter expression in those Rulesheets, too.
Customers who are not Preferred Card holders are not eligible for the promotions defined in the original business rules. So we want to exclude non-preferred customers from evaluation by the Rulesheet. The Filter expression shown below filters out all non-preferred customers by allowing only those customers with isPreferredMember attribute value of true to pass (survive). Those customers whose isPreferredMember attribute value is not true are filtered out and not evaluated by other rules on this Rulesheet.
Note Filter expressions can behave in ways more complex and powerful than the simple filter shown here. An entire chapter in the Rule Modeling Guide is devoted to them.
38
Calculating CashBackEarned Amount

Action Row A Action row A in column 0 calculates the cashBackEarned for a customers total purchase. Our original Business Rule defines the formula as the totalAmount of all items in the customers shopping cart multiplied by 0.02, which is the same as 2% of totalAmount.
Parameterizing Rules Often, its desirable to use another Vocabulary attribute (a parameter) to hold a value, such as the percentage used in this formula, rather than hard-coding it (as in 0.02). If the value of an attribute such as cashBackRate is derived by other rules or maintained in an external database then it can be changed without changing this rule. For more information on parameterization techniques, see the Rule Modeling Guide.
39
Testing CashBackEarned Calculation

Test the Rule
Heres a simple test for Action row A in column 0. Weve added a few items to the shoppingCart and entered prices for each of them. According to the rule we are testing, the shopping cart of a preferred cardholder should earn cash back equal to 2% of the totalAmount in the shopping cart.
Action Lets run the Ruletest and see what happens
40
CashBackEarned Calculation Test Results
Results Notice that the totalAmount attribute now has a value of $98.99 and the cashBackEarned attribute has been assigned a value of $1.9798, or 2% of $98.99. Our rule has worked as expected!
41
Modeling Cumulative CashBackEarned

2nd Action in Column 0 Action row B in Column 0 calculates the cumulativeCashBack amount in a customers account by incrementing its value (using +=) by the cashBackEarned in the current shopping cart. Well also want to post a message displaying that amount. The choices are made from the drop-down menus in the Post and Alias columns.
42
Testing the Cumulative CashBackEarned Model

Test the Rule Model
For this test, weve entered a totalAmount of $100 for the shoppingCart and a cumulativeCashBack amount of $10. Weve already tested this Ruleflows ability to sum up the prices of each individual item to calculate a totalAmount, so we wont test that Rulesheet now.
Test the Rule When building Ruletests, its easy to forget that a Rulesheets Filters, if not satisfied, may prevent your rules from executing. The Rulesheet being tested here has a Filter expression that filters out all customers who arent Preferred Card members, so we needed to include an associated preferredCard entity in our test to ensure the Filter is satisfied, and our new rule model has a chance to execute!
43
Cumulative CashBackEarned Test Results
Test Results As you can see in the Results Testsheet below, the cashBackEarned has been calculated as $2, and cumulativeCashBack amount has been incremented from its original value of $10 to a new value of $12. Our rule model works as expected!
44
Modeling Condition/Action Rule 1

Model C/A Rule 1
The first Condition on our Rulesheet is used to identify any items purchased from department 290, the Floral Department. For each item identified, we want to give the customer a coupon (using the .new operator) for a free balloon. Notice the assignment of the value 12/31/9999 to the expirationDate attribute, which is a common way to indicates that the expiration date is essentially indefinite. There are other ways to accomplish this. For example, the entity Coupon might have a boolean attribute named expires, to which a true or false value could be assigned inside the .new expression.
45
Testing Condition/Action Rule 1
Test for the Floral Department In this Ruletest, we want to make sure that when an item has been purchased from the Floral Department (department 290 according to the code table) that a new Coupon is created entitling the customer to one free balloon. The coupons expiration date should also be created, though here we use a date that makes this coupon essentially non-expiring.
Test Results Notice we also set cumulativeCashBack to 0 for this test. The formula (in Action row B, column 0) depends on a real value of cumulativeCashBack to increment. If its initial value is null, the rule will not fire. More discussion on null values and their effects on rule execution can be found in the Troubleshooting chapter of the Rule Modeling Guide.
46
Condition/Action Rule 1 Test Results

Results of our Test
Department 290 has been recognized and the informational message has been posted. Also, our new Coupon entity has been created, displaying a value of One Free Balloon in the description attribute and 12/31/9999 in the expirationDate attribute, indicating that the coupon will not expire (practically speaking). Also, note the new Message posted by our new rule: it contains the value of allItems.name embedded inside. The syntax to embed attributes is shown in the Rule Statement and is discussed in more detail in the Rule Language Guide, Special Syntax chapter.
47
Modeling Condition/Action Rule 2 Filter
Filters Continued The next Business Rule to be modeled creates a $2 off coupon when a customer buys 3 or more items from the Soda Department. When determining whether any items from the Floral Department were in the shopping cart, we used the allItems alias in Condition/Action rule 1. But to determine if 3 or more items were purchased from the Soda department, we wont count all items in the shopping cart, just those from the Soda Department. To help us, well use the SodaItems alias we defined earlier in the Scope section. To reduce the collection of items in the shopping cart to only those we want to count, we will use a Filter expression to filter the SodaItems alias. Filters row 2 ensures that the surviving members of the SodaItems alias all have a department value of 285, which is that part of the barCode that identifies the Soda Department. If you drag item from the Vocabulary window, you may need to edit the spelling to the SodaItems alias. This is a case where dragging the SodaItems alias directly from the Scope window may be more convenient, although doing so requires you to type .department manually.
48
Condition Row 2 The size operator counts the number of elements in the SodaItems collection of data. If 3 or more, then the $2 off coupon is issued to the customer. Please refer to the Rule Language Guide for more details about the size operator, and all other operators available within Studio. Action Row 2 The expirationDate attribute derives its value from use of the .addYears operator, set here to 1, so we know that the coupon will expire one year from its date of issuance.
49
Test for the Soda Department To test this rule, our shopping cart must contain 3 or more items from the Soda Department (department 285). When the condition determines that 3 or more Soda items are present (counted using the size operator) then the action will fire and generate the appropriate coupon.
50

Results of the Ruletest
The items from the Soda Department have been identified and counted, the Coupon has been added with a $2 off next purchase description and an expirationDate of 04/02/2009 (which is 1 year from the date this test was run), and the informational message has been posted. Coupon rule 2 works as expected!
51

Rule Statement for Condition/Action Rule 3
The third condition on our Rulesheet is used to identify when a customers totalAmount exceeds the $75 threshold prescribed in the scenario and award a new coupon (again, using the .new operator) for 10% off a future gasoline purchase at our stores gas pumps. The expirationDate attribute derives its value from the .addMonths operator, set here to 3, so the coupon will expire three months from its date of issue. As always, best practice recommends adding the corresponding Rule Statement, explaining in clear language what the business rule does.
52

Total Amount Test For our test, we need to include items in the shopping cart that add up to more than $75 in order to generate a 10% off gas coupon for the customer.
53

Results of the Test The items have been totaled and the amount exceeds the $75 threshold so the Coupon has been created and the info message has been posted. Our 3rd Condition/Action rule works!
54
2nd Completed Rulesheet

Second Rulesheet Heres our second completed Rulesheet!
55
Modeling the 3rd Rulesheet

Action
The previous Rulesheet calculated the cashBack earned by a Preferred Card member for each purchase and incremented the members cumulativeCashBack amount. Now, lets give the shopper the option of using the money in his cumulativeCashBack account to reduce his total amount at checkout time. Well assume that at time of checkout, the cashier asks the shopper if he wants to apply his cumulativeCashBack amount to the current purchase totalAmount. If the shopper says Yes, then we assume the shopping carts useCashBack attribute is true. If the shopper answers No then the attribute is false. If useCashBack is true, then we need to deduct it from the totalAmount, thereby reducing the amount the shopper pays. Finally, when a shopper applies the balance in his cumulativeCashBack account, we need to reset that balance to zero.
Raise Alerts
Calculations, Promotions, And Coupons
Apply Cash Back
A Preferred Shopper account will track the accumulated cash back and allow the customer to apply it to any visits total amount. The cashier will ask a Preferred Shopper if he/she would like to apply a cash back balance to his/her current purchase Once a Preferred Shopper chooses to apply his cash back balance, the cumulative cash back total maintained by the system will be reset to zero, and the accumulation of cash back begins anew with the customers next purchase.
56
3rd Rulesheet Scope
Rulesheet 3 Scope Now we will build our third and final Rulesheet and call it use_cashBack. Notice that with the addition of this third Rulesheet, we can complete our Ruleflow Diagram indicating execution sequence of the 3 Rulesheets. Because the rules on this Rulesheet deal with a preferred shoppers cart, we only need a few aliases to represent these perspectives of our data.
57
Filters
Filters The first thing we want to accomplish with this Rulesheet is to make sure we only evaluate preferred customers since only they are eligible for the cash back and bonus incentives. The expression in Filters row 1 of the Rulesheet filters out those customers that are not preferred members (because they dont have a Preferred Card).
58

Condition/Action Rule 1
We only need to create one Condition/Action rule here, with one Condition and a few Actions. As you can see in the illustration below, we only want to process the currentCart when the shopper has chosen to apply his or her cashBack balance to the current purchase, in other words, when useCashBack = true. Then, well deduct the cumulativeCashBack balance from totalAmount, as shown below. In keeping with our model/test approach, well test the rule before adding more to it. Also, well postpone adding a Rule Statement until we have completed the rule model.
59
Use Cash Back Test For this test, we have manually entered $9.24 in the preferred customers cumulativeCashBack attribute and indicated that the she wants to apply this balance towards todays totalAmount (useCashBack = true) According to our first Condition/Action rule, the cumulativeCashBack should first be incremented by the new cashBack earned by todays purchase, then subtracted from the totalAmount to arrive at the final price.
60
Test Results The Output panel shows the new cashBackEarned ($1.64) added to cumulativeCashBack ($10.88) and subtracted from totalAmount ($71.60). We also see some of those values embedded in the 3rd Message displayed at the bottom. But were not done. We still need to reset the cumulativeCashBack attribute to 0. Lets modify the rule to add the necessary logic.
61
Adding Action Rows B & C

Adding Actions Rows B & C
Before we reset cumulativeCashBack to 0, lets ensure our preferred customer is aware of her savings today. Lets assign the value of cumulativeCashBack to the attribute named savings. Well assume that this savings value will be printed on a receipt, displayed on a screen, or by some other mechanism made visible to the shopper. Then, following this assignment, we can safely reset the cumulativeCashBack value to 0, ready to begin accumulating new cashBack beginning with the preferred shoppers next purchase. Adding a Rule Statement completes this business rule model.
62
Final Condition/Action Rule 1 Test Results
Test Results Using the same Input Testsheet as in the previous test, we can see that cumulativeCashBack is now 0, and savings has the value previously held by cumulativeCashBack. We also receive the new Message below explaining what has happened. Our final rule works as expected! Since this was a cumulative test, we also can verify that the entire Ruleflow (all 3 Rulesheets) work as expected. The Scenario has now been fully modeled and tested.
63
3rd Rulesheet Completed

Final Note about Logical Validation
Completed Rulesheet 3 Heres our third, and final, completed Rulesheet! While these Rulesheets successfully model the Scenarios Business Rules, they are not complete from a logical standpoint. Studios Completeness Check will reveal incompletenesses in each of the 3 Rulesheets. The Completeness Check and the other Studio Logical Analysis and Validation tools are covered in more detail in the Basic Rule Modeling Tutorial and in a special chapter in the Rule Modeling Guide. Identifying and resolving incompletenesses or conflicts in these rules are left to you.
64
Summary/What Youve Learned

Summary What Youve Learned
Congratulations on completing the Corticon Advanced Rule Modeling Tutorial! We hope you have found this tutorial useful in your quest to get the most out of Corticon Studio, the best business rule modeling system in the business. You have learned to incorporate some of Studios more powerful functionality into your rule modeling process, including: Diagramming a Vocabulary Based on the necessary items identified during analysis of a Business Problem, weve shown you how to diagram a Vocabulary using an ER Diagram from which you can confidently create a valid Studio Vocabulary for use in rules modeling and testing. Scope and Aliases Scope helps us tell the Corticon rules engine which data to use when evaluating and executing rules. Using Scope to incorporate associations between entities, and defining Aliases to represent it in your rules, establishes the context in which your data is analyzed. Collections and Collection Operators You now know that a Collection is often comprised of one entity associated with one or more other entities, which we call elements of the collection, and that Collection Operators are used to analyze groups of entities rather than individuals. Studio contains a number of Collection Operators which operate on the Collections you create and its mandatory to use them with Aliases that represent those collections. Condition/Action Column 0 Weve shown you how to use the this portion of a Rulesheet to perform mathematical calculations which can contribute data to other rules in the Rulesheet, or in downstream Rulesheets in the same Ruleflow. Filters Youve learned that a Filter expression acts to limit or reduce the data being evaluated to only that subset whose members satisfy the expression. A filter does not permanently remove or delete any data, it simply excludes data from evaluation by other rules in the same Rulesheet. Sequencing Rulesheets using Ruleflows If a natural sequence or flow of logical steps can be identified within a single decision step, it often makes sense to organize the flow using separate Rulesheets for each logical step. Rulesheets will execute in a sequence determined by their order in the Ruleflow. Using multiple Rulesheets helps us both visualize our logic and maintain and reuse it more easily. Extended Transient Attributes You are now aware that some attributes are little more than intermediate or temporary value holders. We dont need to return these values in a response, or save them in a database. In Studio, a special type of attribute called Extended Transient fills this purpose. Embedding Attributes within Rule Statements Weve shown you how you can embed attributes within Rule Statements and the proper syntax to use when doing so. Rule Statement Messaging Weve explained the value of Studios Rule Statement Messaging for use in posting messages of business significance (as in the ID check alert) as well as for feedback during testing. Even when Rule Statements are not posted, they are useful as documentation.
65
Appendix A: Corticon Technical Publications

Document or Resource Corticon Tutorials Tutorial for Corticon Studio 5.2 Basic Rule Modeling Tutorial for Corticon Studio 5.2 Advanced Rule Modeling Tutorial for Corticon Server 5.2 Deploying Web Services Format Description
A step-by-step introduction to modeling, analyzing, and testing rules and decisions in Studio 5.2. Recommended for all new users. An intro to more advanced modeling concepts and practices in Studio 5.2. For users who want a more thorough introduction to Studio 5.2s capabilities. A step-by-step introduction to installing the Server as a Web Services server and deploying and exposing decisions as Web Services.
Rule Language Guide
66
CORTICON
Business Rules Modeling Studio 5.2 Rule Modeling Guide
Rule Modeling Guide
Page iii
TABLE OF CONTENTS
Table of Contents ...................................................................................................................................................... iii Preface ........................................................................................................................................................................1 Intended Audience .................................................................................................................................................1 Corticon Business Rules Management Product Documentation ...........................................................................1 Documentation Conventions .................................................................................................................................1 Corticon Studio Technical Support.........................................................................................................................1 Building the Vocabulary..............................................................................................................................................2 Purpose of the Vocabulary.....................................................................................................................................2 Starting from Scratch .........................................................................................................................................4 Designing the Vocabulary ......................................................................................................................................5 Step 1 Identify the Terms ................................................................................................................................5 Step 2 Separating the Generic Terms from the Specific .................................................................................5 Step 3 Assembling and Relating the Terms.....................................................................................................5 Step 4 Diagramming the Vocabulary ..............................................................................................................6 Modeling the Vocabulary in Studio........................................................................................................................8 Custom Data Types ............................................................................................................................................. 10 Data Type Name ............................................................................................................................................. 11 Base Data Type ............................................................................................................................................... 11 Enumeration ................................................................................................................................................... 11 Constraint Expression ..................................................................................................................................... 11 Label and Value ............................................................................................................................................... 12 Using Custom Data Types in the Vocabulary .................................................................................................. 14 Using Enumerated Custom Data Types in Rulesheets .................................................................................... 15 Using Enumerated Custom Data Types in Ruletests....................................................................................... 15 Using Non-Enumerated Custom Data Types in Rulesheets and Ruletests ..................................................... 16 Using Custom Data Types in Extended Operators .......................................................................................... 17 Upgrading Enumerated Values Sets in 3.x and 4.x to Custom Data Types in 5.x ........................................... 17 Domains .............................................................................................................................................................. 19 Support for Inheritance....................................................................................................................................... 22 Inherited Attributes ........................................................................................................................................ 24 Inherited Associations..................................................................................................................................... 24 Controlling the Tree View ............................................................................................................................... 24 Using Aliases with Inheritance ........................................................................................................................ 25 Inheritances Effects on Rule Execution.......................................................................................................... 26 Inheritance and Java Object Messaging ......................................................................................................... 28 Test Yourself:....................................................................................................................................................... 30 Rule Scope & Context .............................................................................................................................................. 34 Rule Scope ........................................................................................................................................................... 40 Aliases ................................................................................................................................................................. 44 Scope and Perspectives in the Vocabulary Tree ................................................................................................. 45 Roles .................................................................................................................................................................... 47 Technical Aside.................................................................................................................................................... 54
January 13, 2012
Rule Modeling Guide
Page iv
Test Yourself:....................................................................................................................................................... 55 Rule Writing Techniques Logical Equivalents ....................................................................................................... 61 Filters vs. Conditions ........................................................................................................................................... 61 Boolean Condition vs. Values Set........................................................................................................................ 62 Exclusionary Syntax......................................................................................................................................... 63 Using other in Condition Cells ..................................................................................................................... 65 Use of Ranges in Condition Cells ......................................................................................................................... 66 Alternatives to Value Ranges .............................................................................................................................. 67 Standard Boolean Constructions ........................................................................................................................ 68 Test Yourself:....................................................................................................................................................... 69 Collections ............................................................................................................................................................... 71 Understanding How Studio Handles Collections ................................................................................................ 71 Visualizing Collections ......................................................................................................................................... 71 A Basic Collection Operator ................................................................................................................................ 72 Filtering Collections............................................................................................................................................. 73 Using Aliases to Represent Collections ............................................................................................................... 73 Special Collection Operators ............................................................................................................................... 83 Universal Quantifier ........................................................................................................................................ 83 Existential Quantifier ...................................................................................................................................... 85 Another Example Using the Existential Quantifier ......................................................................................... 88 Test Yourself:....................................................................................................................................................... 95 Rules Containing Calculations & Equations ............................................................................................................. 99 Terminology ........................................................................................................................................................ 99 Operator Precedence .......................................................................................................................................... 99 Datatype Compatibility and Casting ................................................................................................................. 100 Datatype of an Expression ............................................................................................................................ 103 Defeating the Parser ..................................................................................................................................... 104 Manipulating Datatypes with Casting Operators ......................................................................................... 105 Supported Uses of Calculation Expressions ...................................................................................................... 106 Calculation as a Comparison in a Precondition ............................................................................................ 107 Calculation as an Assignment in a Noncondition.......................................................................................... 108 Calculation as a Comparison in a Condition ................................................................................................. 108 Calculation as an Assignment in an Action ................................................................................................... 110 Unsupported Uses of Calculation Expressions.................................................................................................. 110 Calculations in Value Sets and Column Cells ................................................................................................ 110 Calculations in Rule Statements ................................................................................................................... 111 Test Yourself:..................................................................................................................................................... 111 Rule Dependency: Chaining and Looping .............................................................................................................. 114 What is Rule Dependency? ............................................................................................................................... 114 Forward Chaining .............................................................................................................................................. 114 Rulesheet Processing: Modes of Looping ......................................................................................................... 115 Types of Loops .............................................................................................................................................. 116 Looping Controls in Studio ................................................................................................................................ 120
January 13, 2012
Rule Modeling Guide
Page v
Identifying Loops........................................................................................................................................... 121 Looping Example ............................................................................................................................................... 123 Problem......................................................................................................................................................... 123 Solution ......................................................................................................................................................... 123 Using Conditions as a Processing Threshold ..................................................................................................... 127 Test Yourself:..................................................................................................................................................... 130 Filters & Preconditions .......................................................................................................................................... 132 What is a Filter? ................................................................................................................................................ 132 Maximum Filters ........................................................................................................................................... 134 Minimum Filters ............................................................................................................................................ 135 What is a Precondition? .................................................................................................................................... 137 Summary of Filter and Preconditions Behaviors .......................................................................................... 142 Performance Implications of the Precondition Behavior ............................................................................. 142 Using Collection Operators in a Filter ............................................................................................................... 142 Location Matters ........................................................................................................................................... 144 Multiple Filters on Collections .......................................................................................................................... 147 Filters that use OR ............................................................................................................................................. 150 Collection Operations & Minimum Filters .................................................................................................... 150 Test Yourself:..................................................................................................................................................... 151 Recognizing and Modeling Parameterized Rules .................................................................................................. 154 Parameterized Rule where a specific attribute is a variable (or parameter) within a general business rule ... 154 Parameterized Rule where a specific business rule is a parameter within a generic business rule ................. 155 Populating an AccountRestriction table from a Sample User Interface ........................................................... 158 Warning! ........................................................................................................................................................... 160 Test Yourself:..................................................................................................................................................... 160 Logical Analysis and Optimization ......................................................................................................................... 161 Testing, Analysis and Optimization ................................................................................................................... 161 Scenario Testing ............................................................................................................................................ 161 Rulesheet Analysis & Optimization ............................................................................................................... 161 Traditional Means of Analyzing Logic ............................................................................................................... 162 Flowcharts ..................................................................................................................................................... 163 Test Databases .............................................................................................................................................. 165 Using Studio to Validate Rulesheets ................................................................................................................. 168 Expanding Rules ............................................................................................................................................ 168 The Conflict Checker ..................................................................................................................................... 170 The Completeness Checker........................................................................................................................... 173 Automatically Determining the Complete Values Set .................................................................................. 174 Automatic Compression of the New Columns.............................................................................................. 174 Limitations of the Completeness Checker .................................................................................................... 174 Renumbering Rules ....................................................................................................................................... 176 Letting the Expansion Tool work for you: Tabular Rules .............................................................................. 178 Memory Management .................................................................................................................................. 180 Logical Loop Detection ...................................................................................................................................... 180 Optimizing Rulesheets ...................................................................................................................................... 181
January 13, 2012
Rule Modeling Guide
Page vi
The Compress Tool ....................................................................................................................................... 181 Producing Characteristic Rulesheet Patterns ............................................................................................... 183 Compression Creates Sub-Rule Redundancy ................................................................................................ 186 Effect of Compression on Corticon Server Performance ............................................................................. 187 Test Yourself:..................................................................................................................................................... 187 Ruleflow Versioning & Effective Dating................................................................................................................. 190 Setting a Ruleflow Version ................................................................................................................................ 190 Setting Effective and Expiration Dates .............................................................................................................. 190 Major and Minor Versions ................................................................................................................................ 191 Test Yourself:..................................................................................................................................................... 191 Localizing Corticon Studio ..................................................................................................................................... 192 Localizing the Vocabulary ................................................................................................................................. 192 Localizing the Rulesheet.................................................................................................................................... 193 Working with Rules in Natural Language .............................................................................................................. 194 Modeling and Managing Rules using Server Console ........................................................................................... 196 Lifecycle Management in Server Console ......................................................................................................... 196 Creating a New Decision Service Version ..................................................................................................... 196 Opening the New Version ............................................................................................................................. 197 Modifying the New Version .......................................................................................................................... 197 Promoting the New Version to Live .............................................................................................................. 198 Removing the Version from Live................................................................................................................... 198 The Studio Reporting Framework ......................................................................................................................... 199 How Studio Creates Reports ............................................................................................................................. 199 Customizing the XSLT Stylesheets................................................................................................................. 199 Troubleshooting Rulesheets and Ruleflows .......................................................................................................... 200 Where did the problem occur? ......................................................................................................................... 200 Using Studio to reproduce the behavior ........................................................................................................... 200 Running a Studio Ruletest............................................................................................................................. 201 Analyzing Ruletest Results ............................................................................................................................ 202 Identifying the Breakpoint ............................................................................................................................ 203 At the Breakpoint .......................................................................................................................................... 204 No Partial Rule Firing .................................................................................................................................... 205 Initializing Null Attributes ............................................................................................................................. 205 Troubleshooting Corticon Server Problems.................................................................................................. 206 Test Yourself...................................................................................................................................................... 211 Appendix A: Standard Boolean Constructions ..................................................................................................... 214 AND ................................................................................................................................................................... 214 NAND................................................................................................................................................................. 216 OR ...................................................................................................................................................................... 217 XOR.................................................................................................................................................................... 218 NOR ................................................................................................................................................................... 219
January 13, 2012
Rule Modeling Guide
Page vii
XNOR ................................................................................................................................................................. 220 Appendix B: Extended Transients in the Vocabulary ........................................................................................... 221 Building the Vocabulary .................................................................................................................................... 221 Appendix C: Corticon Studio and Server 5.2 Product Documentation................................................................. 222 Appendix D: Answers to Test Yourself Questions ................................................................................................. 223 Building the Vocabulary .................................................................................................................................... 223 Rule Scope & Context........................................................................................................................................ 226 Rule Writing Techniques Logical Equivalents................................................................................................. 228 Collections ......................................................................................................................................................... 230 Rules Containing Calculations & Equations ...................................................................................................... 231 Rule Dependency: Dependency & Inferencing ................................................................................................. 233 Preconditions & Filters ...................................................................................................................................... 234 Recognizing & Modeling Parameterized Rules ................................................................................................. 235 Logical Analysis & Optimization ........................................................................................................................ 236 Ruleflow Versioning & Effective Dating ............................................................................................................ 238 Troubleshooting Rulesheets ............................................................................................................................. 238
January 13, 2012
Rule Modeling Guide
Page 1
PREFACE
INTENDED AUDIENCE
The Rule Modeling Guide is intended for use by business analysts and others who will use Corticon Business Rules Modeling Studio to build and test rules. It provides the theory and concepts necessary to acquire a deeper understanding of rule design, allowing the rule modeler and developer to fully leverage Studios unique and advanced capabilities. This document assumes that you are familiar with using various thirdparty software packages and operating environments.

For a detailed listing of current Corticon technical publications, see Appendix C.
Corticon documentation uses the following conventions: Document names are shown in bold face italic type: Studio Installation Guide. Screen, button and window names are shown in bold face type: Custom Setup screen. Important information such as Notes, Tips and Warnings are shown in this color scheme:
Tools Notes and Tips Warnings
Hyperlinks are underlined and shown in blue: the cursor changes to a hand: Building the Vocabulary. File names, code, and user-defined information are shown as: Installing.pdf. Menu options are indicated using bold text and arrows: File>Save denotes the selection of the Save option from the File menu.
CORTICON STUDIO TECHNICAL SUPPORT

For Corticon product support, contact +1 650.212.2424 ext. 200 or email support@corticon.com.
January 13, 2012
Rule Modeling Guide
Page 2
BUILDING THE VOCABULARY

Purpose: The purpose of this chapter is to explain the concept behind, and purpose of, the Vocabulary, and details how to build a Vocabulary starting from scratch or from an existing data model. It is essential that users fully understand the Vocabulary since it is fundamental to defining business rules and modeling them in Business Rules Modeling Studio.
PURPOSE OF THE VOCABULARY

What is a Vocabulary? The Vocabulary represents different things and serves different purposes depending on your perspective. From the rule modelers perspective, the Vocabulary provides the basic elements of the rule language the building blocks with which business rules are implemented in Studio. From the systems analysts or programmers perspective, it is an abstracted version of a data model that contains the objects used in those business rules implemented in Studio. More specifically, it serves all of the following purposes: Provides terms that represent business things. Throughout the product documentation, we will refer to these things as entities, and properties or characteristics of these things as attributes. Entities and their attributes in underlying data sources (such as tables in a relational database or fields in a user interface) can be represented in the Vocabulary. Provides terms that are used to hold temporary or transient values within Studio (such as the outcome of intermediate derivations). These entities and attributes usually have a business meaning or context, but do not need to be saved (which we will also refer to as persisting) in a database or communicated to other applications external to Studio. An example of this might be the following two simple computational rules:
In these two rules, itemSubTotal is the intermediate or transient term. We may never use itemSubTotal by itself; instead, we may only create it for purposes of subsequent derivations, as in the calculation of orderTotal in rule #2. Since a transient attribute may be the result of a very complicated rule, it may be convenient to create a Vocabulary term for it and use it whenever rewriting the complex rule would be awkward or unclear. Also see Appendix B, Extended Transients in the Vocabulary. Provides a federated data model that consolidates entities and attributes from various enterprise data resources. This is important because a companys data may be stored in many different databases in many different physical locations. Corticon believes that rule modelers need not be concerned with where data is, only how it is used in the context of building and evaluating business rules. The decision management system should ensure that proper links are maintained between the Vocabulary and the underlying data. We often refer to this concept as abstraction the complexities of an enterprises data storage and retrieval systems have been hidden so that only the aspects relevant to rule writing are presented to the rule modeler.
January 13, 2012
Rule Modeling Guide
Page 3
Provides a built-in library of literal terms and operators that can be applied to entities or attributes in the Vocabulary. This part of the Vocabulary, the lower half of the Vocabulary window shown in Figure 1, is called the Operator Vocabulary because it provides many of the verbs (the operators) needed in our business rules. Many standard operators such as the mathematical functions { +, -, *, /} and comparator functions {<, >, =} as well as more specialized functions are contained within this portion of the Vocabulary. See the Rule Language Guide for descriptions and examples of all operators available, as well as detailed instructions for extending the library.
Figure 1 Operator Vocabulary
Defines a schema that supplies the contract for sending data to and from a Corticon Decision Service (Rulesheets deployed in production). Since XML messaging is used to carry data to and from the rules for evaluation, data must be organized in a pre-defined structure that can be understood and processed by the rules. An XML schema that accomplishes this purpose can be automatically generated directly from the Vocabulary. This schema is called a Vocabulary-Level service contract and details can be found in the Server Integration & Deployment Guide.
An important point about the Vocabulary: there does not need to be a one-to-one correlation between terms in the Vocabulary and terms in the enterprise data model. In other words, there may be terms in the data model that are not included in or referenced by rules such terms need not be included in the Vocabulary. Conversely, the Vocabulary may include terms (such as extended transient attributes) that are used only in rules these terms need not be present in the data model. Two guiding principles: If the rule modeler desires to use a particular term in a business rule, then that term must be part of the Vocabulary. This can include terms that exist only within the Vocabulary these are the transient attributes introduced above.
January 13, 2012
Rule Modeling Guide
Page 4
If a rule produces a value that must be retained, persisted, or otherwise saved in a database (or other means external to the rules), then that Vocabulary term must also be present in the enterprise data model. There are many methods for linking or mapping these Vocabulary terms with corresponding terms in the data model, but a discussion of these methods is technical in nature and is not included in this manual.
There are two basic starting points for creating a Vocabulary: starting from an existing data model or starting from scratch. We will start by examining the latter since it is typically more challenging.
Starting from Scratch

Investigation The first step in creating a Vocabulary from scratch is to collect information about the specifics of the business problem you are trying to solve. This usually includes research into the more general business context in which the problem exists. Various resources may be available to you to help in this process, including: Interviews the business users and subject matter experts themselves are often the best source of information about how business is conducted today. They may not know how the process is supposed to work, or how it could work, but in general, no one knows better how a business process or task is performed today than those who are actually performing it. Company policies and procedures when they exist, written policies and procedures can be an excellent source of information about how a process is supposed to work and the rules that govern the process. Understanding the gaps between what is supposed to happen and what is actually happening can provide valuable insight into the root problems. Existing systems & databases systems are usually created to address specific business needs, but needs often change faster than systems can keep up. Understanding what the systems were designed to do versus how they are actually being used often provides clues about the core problems. Also, business logic contained in these legacy systems often captures business policies and procedures (i.e., the business rules) that are not recorded anywhere else. Forms and reports even in heavily automated businesses, forms and reports are often used extensively. These documents can be very useful for understanding the details of a business process. Reports also illustrate the desired output from a system, and highlight the information users require.
Analyze the chosen scenario and/or existing business rules in order to identify the relevant terms and the relationships between these terms. We refer to statements expressing the relevant terms and relationships as facts and recommend developing a Fact Model to more clearly illustrate how they fit together. We will use a simple example to show the creation of a Fact Model and its subsequent development into a Vocabulary for use in Studio.
January 13, 2012
Rule Modeling Guide
Page 5
DESIGNING THE VOCABULARY

Example An air cargo company has a manual process for generating flight plans. These flight plans assign cargo shipments to specific aircraft. Each flight plan is assigned a flight number. The cargo company owns a small fleet of three airplanes, 2 Boeing 747s and 1 McDonnell-Douglas DC-10 freighter. Each airplane type has a maximum cargo weight and volume that cannot be exceeded. Each aircraft also has a tail number which serves to identify it. A cargo shipment has characteristics like weight, volume and a manifest number to identify it. Now lets assume the company wants to build a system that automatically checks flight plans to ensure no scheduling rules or guidelines are violated. One of the many business rules that need to be checked by this system is:
Step 1 Identify the Terms

We identify the terms (entities and attributes) for our Vocabulary by circling or highlighting those nouns that are used in the business rules we seek to automate. The previous example is reproduced below: An air cargo company has a manual process for generating flight plans. These flight plans assign cargo shipments to specific aircraft. Each flight plan is assigned a flight number. The cargo company owns a small fleet of three airplanes, 2 Boeing 747s and 1 McDonnell-Douglas DC-10 freighter. Each airplane type has a maximum cargo weight and volume that cannot be exceeded. Each aircraft also has a tail number which serves to identify it. A cargo shipment has characteristics like weight, volume, packaging method, and a manifest number to identify it.
Step 2 Separating the Generic Terms from the Specific

Why did we only circle the aircraft term above and not the names of the aircraft in the fleet? It is because 747 and DC-10 are specific types of the generic term aircraft. The type of aircraft can be said to be an attribute of the generic aircraft entity. Along these same lines, we also know from the example that several cargo shipments and flight plans can exist. Like the specific aircraft, these are instances of their respective generic terms. For the Vocabulary, we are only interested in identifying the generic (and therefore reusable) terms. But ultimately, we also will need a way to identify specific cargo shipments and flight plans from within the set of all cargo shipments and flight plans assigning values to attributes of a generic entity will accomplish this goal, as we will see later.
Step 3 Assembling and Relating the Terms

None of the terms we have circled exists in isolation they all relate to each other in one or more ways. Understanding these relationships is the next step in Vocabulary construction. We begin by simply stating facts observed or inferred from the example:
January 13, 2012
Rule Modeling Guide An aircraft carries a cargo shipment. A flight plan schedules cargo for shipment on an aircraft. A cargo shipment has a weight. A cargo shipment has a manifest number. An aircraft has a tail number. An aircraft has a maximum cargo weight. A 747 is a type of aircraft.
Page 6
And so on Notice that some of these facts describe how one term relates to another term; for example, an aircraft carries a cargo shipment. This usually provides a clue that the terms in question, aircraft and cargo shipment, are entities and are two of the primary terms we are interested in identifying. Also notice that some facts describe what Business Rule Solutions, LLC (BRS) calls has a relationships; for example, an aircraft has a tail number, or a cargo has a weight. This type of relationship usually identifies the subject (aircraft) as an entity and the object (tail number) as an attribute of that entity. By continuing the analysis, we discover that the problem reduces to a Vocabulary containing 3 main entities, each with its own set of attributes: Entity: aircraft Attributes: aircraft type, max cargo weight, max cargo volume, tail number Entity: cargo shipment
Attributes: weight, volume, manifest number, packaging Entity: flight plan
Attributes: flight number
Step 4 Diagramming the Vocabulary

Using this breakdown, we can sketch a simple Fact Model that illustrates the entities and their relationships, or associations. In our Fact Model, we will represent entities as rectangular boxes, associations between entities as straight lines connecting the entity boxes, and entity-to-attribute relationships as a diagonal line from the associated entity. The resulting Fact Model appears below in Figure 2:
January 13, 2012
Rule Modeling Guide
Page 7
Figure 2 Fact Model
The UML Class diagram contains the same type of information, and may be more familiar to you:
Figure 3 UML Class Diagram
Its not a requirement to construct diagrams or models of the Vocabulary before building it in Studio. But it can be very helpful in organizing and conceptualizing the structures and relationships, especially for very large and complex Vocabularies. The BRS Fact Model and UML Class Diagram are appropriate
Rule Modeling Guide
Page 8
because they remain sufficiently abstracted from lower-level data models which contain information not typically required in a Vocabulary.
MODELING THE VOCABULARY IN STUDIO

Our next step is to transform the diagram into our actual Vocabulary. This can be done directly in Studio using the built-in Vocabulary Editor feature. Refer to the Quick Reference Guides Vocabulary chapter for complete details on building a Vocabulary inside Studio. The following considerations apply to this transformation process: The same naming conventions for entities and attributes used in the Fact Model will also be used in the Vocabulary. All attributes in our Vocabulary must have a data type specified. These may be any of the following common data types: String, Boolean, DateTime, Date 1, Time, Integer or Decimal. Attributes may be classified according to the method by which their values are assigned. They may be either: Base (i.e., obtained directly from input data or request message) or Extended Transient (created, derived, or assigned by rules in Studio). Extended Persistent. This is an advanced feature discussed in a separate document located here: <corticon_install_dir>\Samples\Dynamic Schema.
It may be convenient to use a naming convention to distinguish transient attributes from base; for instance, we might add a lowercase letter d to the start of totalWeight to indicate it is a derived attribute. However, we caution against modifying the names of terms too much, since the intent is to express them in a language accessible to business users, not just developers. Associations between entities have role names that are assigned when building the associations in the UML class diagram or Vocabulary Editor. Default role names simply duplicate the entity name with the first letter in lowercase. For example, the association between the Cargo and FlightPlan entities would have a role name of flightPlan as seen by the Cargo entity, and cargo as seen by the FlightPlan entity. Roles are useful in clarifying context in a rule a topic covered in more detail within the Scope chapter. Associations between entities can be directional (one-way) or bi-directional (two-way). If the association between FlightPlan and Aircraft were directional (with FlightPlan as the source entity and Aircraft as target), we would only be able to write rules that traverse from FlightPlan to Aircraft, but not the other way. This means that a rule may use the Vocabulary term flightPlan.aircraft.tailNumber but may not use
Some earlier versions of Studio 4.x used only 5 main datatypes: Date and Time were subtypes of the DateTime type. Upgrading from these versions will automatically convert datatypes to those used in v5.x.
January 13, 2012
Rule Modeling Guide
Page 9
aircraft.flightPlan.flightNumber. Bi-directional associations allow us to traverse the
association in either direction, which clearly allows us more flexibility in writing rules. Therefore, it is strongly recommended that all associations be bi-directional whenever possible. New associations are bi-directional by default. Associations also have cardinality, which indicates how many instances of a given entity may be associated with another entity. For example, in our air cargo scenario, each instance of FlightPlan will be associated with only one instance of Aircraft, so we can say that there is a one-to-one relationship between FlightPlan and Aircraft. The practice of specifying cardinality in the Vocabulary deviates from the UML Class modeling technique because the act of assigning cardinality can be viewed as defining a constraint-type rule. For example, a flightPlan schedules exactly one aircraft and one cargo shipment is a constraint-type business rule that can be implemented in a Studio Rulesheet as well as embedded in the associations within a Vocabulary. In practice, however, it may often be more convenient to embed these constraints in the Vocabulary, especially if they are unlikely to change in the future. Another consideration when creating a Vocabulary is whether derived attributes must be saved (or persisted) external to Studio, for example, in a database. It is important to note that while the structure of your Vocabulary may closely match your data model (often persisted in a relational database), the Vocabulary is not required to include all of the database entities/tables or attributes/columns, especially if they will not be used for writing rules. Conversely, our Vocabulary may contain attributes that are used only as transient variables in rules and that do not correspond to fields in an external database. Finally, the Vocabulary must contain all of the entities and attributes needed to build rules in Studio that reproduce the decision points of the business process being automated. This will most likely be an iterative process, with multiple Vocabulary changes being made as the rules are built, refined, and tested. It is very common to discover, while building rules, that the Vocabulary does not contain necessary terms. But the flexibility of Studio permits the rule developer to update or modify the Vocabulary immediately, without programming.
January 13, 2012
Rule Modeling Guide
Page 10
Figure 4 Vocabulary Window in Studio
Note: in Figure 4, Studio is shown in Rule Modeling mode. If in Integration Deployment mode, the Property Name column will contain additional rows. For more information on Integration Deployment mode, see the Server Integration & Deployment Guide.
CUSTOM DATA TYPES

Corticon uses 7 basic data types: Boolean, Decimal, Integer, String, DateTime, Date, and Time. An attribute must use one of these types. But you also have the option of creating custom data types that extend any one of these basic 7. The section of the Vocabulary dealing with custom data types can be seen by selecting the Vocabulary name in the tree view, as shown circled below.
Figure 5 Vocabulary Editor Showing the Custom Data Type Editor
January 13, 2012
Rule Modeling Guide
Page 11
Data Type Name

When defining a custom data type, you must choose a name for it. The name must comply with standard entity naming conventions (see the Studio Quick Reference Guide for details) and must not overlap (match) any of the base data types, any other custom data type names, or the names of any Vocabulary entities.
Base Data Type

The selection in this field determines which base data type the custom data type extends.
Enumeration
If yes is selected in this field, the Constraint Expression field (next field to right) becomes disabled (grayed out) and the Label and Value columns are enabled. Values for the Label and Value columns must be entered - see the Label and Value section below for more information. If Enumeration is no, then the Constraint Expression field is enabled and the Label and Value columns are disabled.
Constraint Expression
Constraint expressions are optional for non-enumerated custom data types, but if none are used then the custom data type probably isnt necessary because it reduces to a base attribute with a custom name. For custom data types which are not enumerated, you can define an expression to constrain the range of acceptable values. All Constraint Expressions must be Boolean expressions, in other words they must return or resolve to a boolean value of true or false. The supported syntax is the same as Filter expressions with the following rules and exceptions: we use the keyword value to represent the Custom Data Type value. logical connectors such as and and or are supported parentheses may be used to form more complex expressions The expression may include references to Base and Extended Operators which are compatible with the Base Data Type chosen. No Collection operators may be referenced in the expression. There should be NO references to keyword null. This is because null represent lack of value and is not a real value. The Constraint Expression is intended to constrain the value space of the data type and expressions such as attribute expression <> null do not belong in it. An attribute that must not have a null value can be so designated by selecting Yes in its Mandatory property value.
The following are typical Constraint Expressions:
January 13, 2012
Rule Modeling Guide
Page 12
Constraint Expression
Meaning
value > 5 value >= 10.2 value in (1.1..9.9]
Integer values greater than 5 Decimal values greater than or equal to 10.2 Decimal values between 1.1 (exclusive) and 9.9 (inclusive) DateTime values between 1/1/2000 12:30:00 PM (inclusive) and 1/2/2000 11:00:00 AM (exclusive) Time values between 1:00:00 PM (inclusive) and 2:00:00 PM (inclusive) String values of minimum 6 characters in length that contain at least a 1 or 2
value in [1/1/2000 12:30:00 PM..1/2/2000 11:00:00 AM)
value in [1:00:00 PM..2:00:00 PM]
value.size >= 6 and (value.indexOf(1) > 0 or value.indexOf(2) > 0)
Label and Value

If your custom data type is an enumeration, then youll need to enter the enumerated values in these columns. The Label column is optional: you enter Labels only when you want to provide an easier-to-use or more intuitive set of names for your enumerated values. The Value column is mandatory: you need to enter the enumerations in as many rows of the Value column as necessary to complete the enumerated set. Be sure to use normal syntax, so custom data types that extend String, DateTime, Date, or Time base data types must be enclosed in single quote characters. Here are some examples of enumerated custom data types:
Figure 6 Custom Data Type, example 1
January 13, 2012
Rule Modeling Guide
Page 13
PrimeNumbers is an Integer-based, enumerated custom data type with Value-only set members.
packingType is a String-based, enumerated custom data type with Label/Value pairs.
USHolidays2008 is a Date-based, enumerated custom data type with Label/Value pairs.
ShirtSize is an Integer-based, enumerated custom data type with Label/Value pairs.
January 13, 2012
Rule Modeling Guide
Page 14
RiskProfile is an Integer-based, enumerated custom data type with Label/Value pairs
.
BoyNames is a String-based, enumerated custom data type with Value-only set members.
Use the Move Up list.
or Move Down
toolbar icons to change the order of Label/Value rows in the
Using Custom Data Types in the Vocabulary

Once a custom data type has been defined as shown above, it may be used and reused throughout the Vocabularys attribute definitions.
Figure 12 Using Custom Data Types in the Vocabulary
January 13, 2012
Rule Modeling Guide
Page 15
Notice in Figure 12 that custom data type packingType is shown in the drop-down as a sub-category of the String-based data type. The other custom data types will be grouped with their base data types as well. Multiple attributes may use the same custom data type.
Using Enumerated Custom Data Types in Rulesheets

Once an enumerated, custom data type has been defined and assigned to an attribute, its labels are displayed in selection drop-downs in both Conditions and Actions expressions, as shown below. If Labels are not available (since Labels are optional in an enumerated custom data types definition), then Values are shown. The null option in the drop-down is only available if the attributes Mandatory property value is set to No.
Figure 13 Using Custom Data Types in the Rulesheet
Those enumerated custom data types having Labels can also be used in Condition or Action expressions of the form:
Figure 14 Using special "hash" syntax to specify a custom data type label
Using Enumerated Custom Data Types in Ruletests

Once an enumerated custom data type has been defined and assigned to an attribute, its enumerated Labels or Values become available as selectable inputs in a Ruletest, as shown below. If its desired that the attribute value should be null, then null may be assigned by right-clicking the attribute and selecting Set to Null from the pop-up menu.
January 13, 2012
Rule Modeling Guide
Page 16
Figure 15 Vocabulary Editor Showing the Properties of the packaging Attribute
Using Non-Enumerated Custom Data Types in Rulesheets and Ruletests

Non-enumerated custom data types use Constraint Expressions and do not cause Rulesheet dropdowns to become populated with custom sets. Also, manually entering a cell value that violates the custom data types Constraint Expression is not prohibited in the Rulesheet. For example, in the example below, weightRange is defined as a non-enumerated custom data type with Base Data Type of Decimal.
Figure 16 Non-enumerated Custom Data Types
Then, after assigning it to the Vocabulary attribute Cargo.weight, its used in a Rulesheet Condition row as shown below:
Figure 17 Using Custom Data Types in a Rulesheet
January 13, 2012
Rule Modeling Guide
Page 17
Notice in Figure 17 that the 300000 entry violates the Constraint Expression of the custom data type assigned to Cargo.weight, but does not turn red or otherwise indicate a problem. The indication comes when data is entered for the attribute in a Ruletest, as shown below:
Figure 18 Violating a Custom Data Types Constraint Expression
Notice that the small yellow warning icon indicates a problem in the attribute, entity, and both Ruletest tabs. Such an error is hard to miss! Also, an Warning message will appear in the Problems tab (if open and visible) as shown below. If the Problems tab is closed, you can display it by selecting Window>Show View>Problems from the Studio menubar.
Figure 19 Violating the Constraint Expression of a Custom Data Type
A Warning will not prevent you from running the Ruletest. However, an Error, indicated by a small red icon , will prevent the Ruletest execution. You must fix any errors before testing.
Using Custom Data Types in Extended Operators

This is not supported in Corticon BRMS 5.2.
Upgrading Enumerated Values Sets in 3.x and 4.x to Custom Data Types in 5.x
Vocabularies created in Corticon BRMS 4.x may include Possible Values Sets defined for attributes. If such a Vocabulary is imported into Corticon Studio 5.2, these Possible Values Sets will be converted into custom data types according to the following process. Values in Studio 4.x Possible Value Set Name (from Lookup Table) fields are mapped directly to Studio 5.2 custom data types. Should a v4.x attribute have a Possible Value Set Name (from Lookup Table) value, then this value is mapped directly to the Studio 5.2 attributes Data Type property value.
January 13, 2012
Rule Modeling Guide
Page 18
If the v4.x attributes Possible Values property is not empty, then the upgrade process proceeds as follows: 1. If the Studio 4.x attributes Possible Values contain only literal values (which may include null or other) then a new enumerated custom data type will be created in the Studio 5.2 Vocabulary as follows: a. Create a custom data type called <AttributeName>Type. In the event this name already exists, then the name will be made unique by adding _1, _2, etc. b. Set the Base Data Type of the Studio 5.2 custom data type to the value of the v4.x attributes Data Type. c. Set the Enumeration value to Yes d. Populate the Values list with the Possible Values of the v4.x attribute, excluding null and other. e. Set the Data Type of the Studio 5.2 attribute to the newly created custom data type. 2. Otherwise, analyze the old Possible Values and determine the minimum possible value allowed and the maximum possible value allowed. If both minimum and maximum values are infinite then the set is unbounded. a. If the set is unbounded on both ends then: i. Set the Data Type of the upgraded attribute to the Data Type of the old attribute and ignore the Possible Values definition. b. Otherwise: i. Create a Custom Data Type called <AttributeName>Type. In the event the Custom Data Type already exists, the name can be made unique by adding _1, _2, ii. Set the Base Type of the newly created type to the Data Type of the old attribute iii. If the set has a lower and/or upper bound then add a Constraint Expression using the corresponding template below:. 1. value > <MinValue> 2. value >= <MinValue> 3. value < <MaxValue> 4. value <= <MaxValue> 5. value in (<MinValue>..<MaxValue>) 6. value in (<MinValue>..<MaxValue>] 7. value in [<MinValue>..<MaxValue>) 8. value in [<MinValue>..<MaxValue>]
January 13, 2012
Rule Modeling Guide Upgrade Example A
Page 19
Studio 4.x Integer attribute named oddNos with Possible Values = {1,3,5,7,null,other}. Qualifies for step 1 above. Upon upgrade, a Studio 5.2 enumerated custom data type is created named oddNosType of Base Type Integer and the Value entries = {1,3,5,7} Upgrade Example B Studio 4.x Decimal attribute named temperature with Possible Values = {<=98.6,99.0,>=100.0,null}. Qualifies for 2.a This set is unbounded. Therefore, no custom data type is created. The Studio 5.2 attribute temperature receives Data Type = Decimal. Upgrade Example C Studio 4.x Integer attribute named age with Possible Values = {>0,20,30,<=120,null,other}. Qualifies for 2.b.iii.7 Ignoring null and other, this is a constrained range with lower bound 0 (exclusive) and upper bound 120 (inclusive). Upon upgrade, a custom data type is created named ageType with Base Type = Decimal with the following Constraint Expression: value in [0..120). Values 20, 30, null, and other are ignored.
DOMAINS
Occasionally, it may be necessary or desirable to include more than one entity of the same name in a Vocabulary. This can be accomplished using Domains 2. Domains allow us to bundle one or more entities in a sub-set within the Vocabulary, allowing us to reuse entity names so long as the entity names are unique within each Domain. Additional Domains, also called sub-Domains, can be defined within other Domains. To create Domains in a Vocabulary, select Vocabulary>Add Domain from the Studio menubar or click from the Studio toolbar, as shown in Figure 20.
Technical analogs to Domains are packages in the Java world and namespaces in the XML world.
January 13, 2012
Rule Modeling Guide
Page 20
Figure 20 Creating Domains in the Vocabulary
Youll see a new folder icon appear in the Vocabulary tree - assign it a name. The example in Figure 21 shows a Vocabulary with 2 Domains, US_Fleet and WW_Fleet:
Figure 21 Using Domains in the Vocabulary
Notice that the entity Aircraft appears in each Domain, using the same spelling and containing slightly different attributes (FAAnumber vs. ICAOnumber). Notice too that the Association role names from FlightPlan to Aircraft have been named manually to ensure uniqueness: one is now USaircraft and the other is WWaircraft.
January 13, 2012
Rule Modeling Guide Domains in a Rulesheet
Page 21
When using entities from domains in a Rulesheet, its important to ensure uniqueness, which means aliases must be used to distinguish one entity from another.
Figure 22 Non-unique Entity names prior to defining Aliases
In Figure 22, both Aircraft entities have been dropped into the Scope section of the Rulesheet. But because their names are not unique, an error icon appears. Also, the fully qualified domain name has been added after each to distinguish them. By fully qualified, we mean the ::US_Fleet:: designator that follows the first Aircraft and ::WW_Fleet:: that follows the second. But it would be inconvenient (and ugly) to use these fully qualified names in Rulesheet expressions. So we require that you define a unique alias for each. The aliases will be used in the Rulesheet expressions, as shown in Figure 23.
Figure 23 Non-unique Entity names after defining Aliases
Domains in a Ruletest When using Vocabulary terms in a Ruletest, just drag and drop them as usual. Youll notice that they are automatically labeled with the fully qualified name, as shown in Figure 24.
January 13, 2012
Rule Modeling Guide
Page 22
Figure 24 Domains in a Ruletest
SUPPORT FOR INHERITANCE

UML Class diagrams frequently include a modeling/programming concept called inheritance, whereby a class may inherit attributes and/or associations from another class. For example:
Figure 25 Rose UML Model Showing Inheritance
In Figure 25, we see a UML model that includes inheritance. The solid-headed arrow symbol indicates that the Employee class is a descendant of the Person class, and therefore inherits some of its properties. Specifically, the Employee class inherits the age and name attributes from Person. In other words, Employee has all the same attributes of a Person plus two of its own, hireDate and
January 13, 2012
Rule Modeling Guide

IDnumber. Likewise, Aircraft inherits all of Equipments attributes (acquireDate and propertyID) plus has attributes of its own, type and tailNumber.
Page 23
Modeling this UML Class Diagram as a Studio Vocabulary is straightforward. All Entities, Attributes and Associations are created as per normal practice. To incorporate the elements of inheritance, we only need add one additional setting for each of the descendant entities, as shown in Figure 26:
Figure 26 Selecting Ancestor Entity for Descendant
Once all descendant entities have been configured to inherit from their proper ancestor entities, we can save the Vocabulary and view it in the Rule Vocabulary window:
Figure 27 Vocabulary with Inheritance
January 13, 2012
Rule Modeling Guide
Page 24
Notice that many of the term names and icons are varying shades of gray - these color codes help us to understand the inherited relationships that exist in the Vocabulary.
Inherited Attributes
Attributes with names displayed in solid black type, such as Customer.loyaltyNumber in Figure 27, are native attributes of that entity. Attributes with names displayed in dark gray type, such as Customer.age, are inherited attributes from the ancestor entity (in the case of Customer, Person).
Inherited Associations
Inherited Associations are a bit more complicated. An entity may be directly associated with another entity or that entitys descendants. An entity may also inherit an association from its ancestor. Using the example shown in Figure 26 and Figure 27 above, lets dissect each of these combinations.
Customer.aircraft is a direct association between Customer and Aircraft entities. No inheritance is involved, so the association icon is black and the rolename is black Customer.operator (Equipment) is an association inherited from Customers ancestor entity Person, which has a direct association with Equipment and the rolename operator in our Vocabulary (the UML Class Diagram in Figure 26 shows the rolename as operates because
it is more conventional in UML to use verbs as rolenames, whereas nouns usually make better rolenames in a Corticon Vocabulary). Because the association is inherited from the ancestors direct association, the icon is dark gray and the rolename is black.
Equipment (which we can see equally well in the expanded operator rolename) has several associations with Person. One of these is a direct association with the Person entity. In this case, both association icon and rolename are black. But Equipment also has associations with descendants of the Person entity, specifically Employee, Customer, and Pilot. We call
these filtered associations, and display their rolenames as dark gray. Finally, Customer has another association with operator (Aircraft) because Aircraft is a descendant of Equipment. So we combine the inherited dark gray icon and the filtered dark gray rolename to display this association.
Controlling the Tree View

In cases where a Vocabulary contains inheritance (and includes the various icons and color schemes described above) but the modelers who use it dont intend to use inheritance in their rules, the inherited associations and filtered rolenames can be hidden from view by clicking the upper right corner of the Rule Vocabulary window, as shown in Figure 28: icon in the
January 13, 2012
Rule Modeling Guide
Page 25
Figure 28 Vocabulary with Inheritance Properties Hidden
Person and Equipment are associated (using named roles), but what relationship does Employee have with Equipment or Aircraft, if any? In version 5.2, Studio also supports inherited
associations3.
Using Aliases with Inheritance

Any Entity, Attribute, or Association can be dragged into the Scope section for use in Rulesheets. But if two or more terms share the same name, they must be assigned unique alias names before they can be used in rules. For example, in Figure 27, we see that there are 4 Customer.operator.person terms in the Vocabulary due to the various forms of inheritance used by the entities and associations. If 2 or more of these nodes are dragged into the Scope window (as shown in Figure 29), theyll be assigned error icons to indicate that their names are not unique. Without unique names, Studio wont know which one is intented in any rule that uses one of the nodes. To ensure uniqueness, aliases must be assigned and used in rules, as shown in Figure 30.
Figure 29 Non-Unique Nodes used in the Scope Window
In versions 4.1 and earlier, Studio supported inherited attributes only.
January 13, 2012
Rule Modeling Guide
Page 26
Figure 30 Uniqueness Established using an Alias
Inheritances Effects on Rule Execution

The point of inheritance is not to complicate the Vocabulary. The point is to be able to write rules on ancestor entities and have those rules affect descendant entities automatically. Here are simple examples: Inherited Conditions and Actions A very simple Rulesheet, shown in Figure 31, contains 2 rules that test the age value of the Employee entity. There are no explicit Actions taken by these rules, only the posting of messages.
Figure 31 Rules written on Employee
A Ruletest provides an instance of Employee and an instance of Pilot. Recall from the Vocabulary that Pilot is a descendant of Employee, which means it inherits its attributes and associations. But more importantly from a rule execution perspective, a Pilot will also be affected by any rules that affect an Employee. This is shown in Figure 32:
January 13, 2012
Rule Modeling Guide
Page 27
Figure 32 Inheritance in action
Using inheritance can be an efficient and powerful way to write rules on many different types of employees, such as pilots, gate agents, baggage handlers, mechanics, etc, without needing to write individual rules for each. Inherited Association A similar test demonstrates how associations are inherited during rule execution. In this case, we test Employee.hireDate to see whos qualified to operate a piece of Equipment. The += syntax used by the Action row is explained in more detail in the Rule Language Guide.
January 13, 2012
Rule Modeling Guide

Figure 33 Rulesheet populating the operators collection
Page 28
Now in , we provide a sample Equipment entity, one Employee, and one Pilot. Both hireDates satisfy the rules Condition (the Pilot inheriting hireDate from its Employee ancestor as before). When the Employee is added to the operators collection alias, an instance of the association between Equipment and Employee is created. But what may be surprising is that the same occurs for Pilot, which also has an association to Equipment that it inherited from Employee!
Figure 34 Inheriting an Association
Inheritance and Java Object Messaging

Each Entity in a Vocabulary can be mapped to a Java Class or Java Interface. Java Classes may have one ancestor. Java Interfaces may have multiple ancestors. A Java Class may implement one or more Interfaces. Say a Java Class A inherits from Java Class B and implements Java Interfaces C & G. Say Java Interface C has as its ancestors Java Interfaces D & F. Say these Classes and Interfaces are mapped to Entities EA, EB, EC, ED, EF & EG in the Vocabulary. The relationships amongst the Java Classes shall be reflected in the Vocabulary using multiple inheritance. Entity EA shall have as its ancestors Entities EB, EC & EG. Entity EC shall have as its ancestors entities ED & EF as shown below:
January 13, 2012
Rule Modeling Guide
Page 29
Figure 35 How the Vocabulary Incorporates Inheritance from a Java Object Model
When a collection of Java objects are passed into the engine through the JOM API, the Java translator determines how to map them to the internal Entities using the following algorithm: Naming conventions used in the graphic above: DS = Decision Service JO = Java Object in input collection JC = Java Class for the JO and any of its direct or indirect ancestors JI = Java Interfaces implemented directly or indirectly by JO E = A Vocabulary Entity with no descendents found in DS context AE = An Ancestor Entity (one with descendents) found in DS context CDO = In memory Java Data Object created by Corticon for use in rule execution
For each E: If there is a JO whose JC or JI is mapped to E then Instantiate a CDO for E and link to JO Put CDO in E bucket Traverse Es inheritance hierarchy one level up For each AE discovered in current level: Put CDO in AE bucket If E has another level of inheritance hierarchy, repeat last step
January 13, 2012
Rule Modeling Guide
Page 30
This design effectively attempts to instantiate the minimum number of CDOs possible and morphs them into playing multiple Entity roles. Ideally, no duplicate copies of input data exists in the engines working memory thus avoid data synchronization issues.Test Yourself
TEST YOURSELF:
Answers are provided in Appendix D 1. 2. 3. 4. 5. Give 3 functions of the Vocabulary. True or False: All Vocabulary terms must also exist in the object or data model? True or False: All terms in the object or data model must also exist in the Vocabulary? True or False: In order to create the Vocabulary, an object or data model must already exist. The Vocabulary is an __________ model, meaning many of the real complexities of an underlying data model are hidden so that the rule author can focus on only those terms relevant to the rules. The UML model that contains the same types of information as a Vocabulary is called a ______________ What are the three components (or nodes) of the Vocabulary? Which of the following are acceptable attribute names? hair_color 9. hairColor HairColor hair color
6.
7. 8.
Which color is used in the Entity icon?
10. Which of the three Vocabulary components can hold an actual value? 11. What are the five main data types used by Vocabulary attributes? 12. Which colors are used in the Base attribute icon? 13. Which colors are used in the Extended Transient attribute icon? 14. What is the purpose of an Extended Transient Vocabulary term?
January 13, 2012
Rule Modeling Guide 15. Associations are ________________ by default. 16. Association icons indicate: optionality singularity cardinality musicality 17. Which of the following icons represents a one-to-many association?
Page 31
18.
Which of the following icons represents a one-to-one association?
19.
If an association is one-directional from the Source entity to the Target entity, then which term is not available in the Vocabulary? Target.attribute Target.source.attribute Source.target.attribute Source.attribute
20.
The default role name of an association from the Source entity to the Target entity is: role1 source target theTarget
21. Sketch a model for the following scenario:
22. Create a Studio Vocabulary for the model sketched in 22. 23. List the (4) steps in generating a Vocabulary from scratch. 24. Cardinality of an association determines: a. The number of possible associated entities. b. The number of attributes for each entity. c. The number of associations possible within an entity. d. The number of attributes for each association. 25. The Vocabulary terms are the nouns of Corticon rules. What are the verbs?
January 13, 2012
Rule Modeling Guide
Page 32
26. What Corticon document contains the complete list of all Vocabulary Operators, descriptions of their usage, and actual examples of use in Rulesheets? 27. True or False. In addition to the supported vocabulary data types, you can create any type of custom data type you want? 28. You must name your custom data type. Which of the following are not custom data type naming convention requirements? a. Can not match any other vocabulary entity names b. May match other Custom Data Type Names c. Base Data Type names may not be re-used. d. The name must comply with the standard entity naming rules. 29. True or False. The Enumeration section of the Custom Data Types exposses the Label/Value columns and allows you to create a list of acceptable value rows. 30. Selecting no in the Enumeration section of the Custom Data Types enables the Contraint Expression. Give an example of a Constraint Expression: _______________________________________ 31. True or False. Constraint Expressions must be equivalent to a Boolean expression to be vaild. 32. In an Enumeration, are both the Label and Value columns required? 33. When you create Enumerated Custom data Types, which of the following are acceptable entries for the Value column: 12/12/2011 12/12/2011 Airbus Airbus
34. Name an advantage to using Enumerated Custom Data Types when it comes to testing your rules in a Ruletest. 35. Explain what Domains do in the Vocabulary? 36. True or False. If you use a Domain, then you will be required to create an alias for each unique Entity/Domain pair? 37. True or False. Inheitance can be modeled in a Vocabulary.
January 13, 2012
Rule Modeling Guide 38. In the following vocabulary, which Entities have native attributes and which Entities has inherited attributes?
Page 33
39. Give two examples of inherited attributes from the vocabulary above: ______________ ______________
40. True or False. Using Inheritance can be a way to write efficient and powerful rules. For example, one rule could be used to modify the cadence attribute for all the entities in the Vocabulary example above.
January 13, 2012
Rule Modeling Guide
Page 34
RULE SCOPE & CONTEXT

The air cargo example that we started in the Vocabulary chapter is continued here to illustrate the important concepts of scope and context in rule design. A quick recap of the fact model:
Figure 36 Fact Model
According to this Vocabulary, an Aircraft is related to a Cargo shipment through a FlightPlan. In other words, it is the FlightPlan that connects or relates an Aircraft to its Cargo shipment. The Aircraft, by itself, has no direct relationship to a Cargo shipment unless it is scheduled by a FlightPlan; or, no Aircraft may carry a Cargo shipment without a FlightPlan. Similarly, no Cargo shipment may be transported by an Aircraft without a FlightPlan. These facts constitute business rules in and of themselves and constrain creation of other rules because they define the Vocabulary well use to build all subsequent rules in this scenario. Also recall that the company wants to build a system that automatically checks flight plans to ensure no scheduling rules or guidelines are violated. One of the many business rules that need to be checked by this system is:
With our Vocabulary created, we can build this rule in the Studio. As with many tasks in Studio, there is often more than one way to do something. Well explore two possible ways to build this rule one correct and one incorrect.
January 13, 2012
Rule Modeling Guide
Page 35
To begin with, well write our rule using the root-level terms in the Vocabulary. In Figure 37 below, column #1 (the true Condition) is the rule we are most interested in weve added the false Condition in column #2 simply to show a logically complete Rulesheet.
Figure 37 Expressing the Rule Using Root-Level Vocabulary Terms
Please refer to the Embedding Attributes in Posted Rule Statements section of the Rule Language Guide for additional details regarding the syntax introduced in the Rule Statements portion of Figure 10, above. We can build a Ruletest to test the rule using the Cargo companys actual data, as follows: The company owns 3 Aircraft, 2 747s and a DC-10, each with different tail numbers. The 3 Aircraft are shown in Figure 11. Each box represents a real-life example (or instance) of the Aircraft term from our Vocabulary.
January 13, 2012
Rule Modeling Guide
Page 36
Figure 38 The Cargo Companys 3 Aircraft
These Aircraft give the company the ability to schedule 3 Cargo shipments each night {there is another business rule implied here an Aircraft must not be scheduled for more than one flight per night, but we wont address this now because it is not relevant to the discussion}. On a given night, the Cargo shipments look like those shown below. Again, like the Aircraft, these Cargo shipments represent specific instances of the generic Cargo term from the Vocabulary.
Figure 39 The 3 Cargo Shipments for the Night of June 25th
Finally, our sample business process manually matches specific aircraft and cargo shipments together as three flightplans, shown below. This organization of data is consistent with the structure and constraints implicit in our Vocabulary.
January 13, 2012
Rule Modeling Guide
Page 37
Figure 40 The 3 FlightPlans with their related Aircraft and Cargo instances
We can construct a Ruletest (Figure 41) so that the companys actual data will be evaluated by the rule. Since the rule used root-level Vocabulary terms in its construction, we will use root-level terms in the Ruletest as well:
Figure 41 Test the Rule Using Root-Level Vocabulary Terms
January 13, 2012
Rule Modeling Guide Running the Ruletest:
Page 38
Figure 42 Results of the Ruletest
Note the messages returned by the Ruletest. Recall that the intent of the rule is to verify whether a given Flightplan is in violation by scheduling a Cargo shipment that is too heavy for the assigned Aircraft. But we already know there are only three Flightplans. And we also know, from examination of Figure 40, that the combination of aircraft N1003 and cargo 625C does not appear in any of our three Flightplans. So why was this combination, one that does not actually exist, evaluated? For that matter, why has the rule fired nine times when only three sets of Aircraft and
January 13, 2012
Rule Modeling Guide Cargo were present? The answer lies in the way we defined our rule, and in the way the Server evaluated it.
Page 39
We gave the Ruletest three instances of both Aircraft and Cargo. Studio treats Aircraft as a collection or set of these three specific instances. When Studio encounters the term Aircraft in a rule, it applies all instances of Aircraft found in the Ruletest (all three instances in this example) to the rule. Since both Aircraft and Cargo have three instances, there are a total of nine possible combinations of the two terms. See Figure 43: The set of these nine possible combinations is called a cross product, Cartesian product, or tuple set in different disciplines. We tend to use crossproduct when describing this outcome.
Figure 43 All Possible Combinations of Aircraft and Cargo
One pair, the combination of manifest 625B and plane N1003 (shown as the red arrow in Figure 43), is indeed illegal, since the plane, a DC-10, can only carry 150,000 lbs, while the cargo weighs 175,000 lbs. But this pairing does not correspond to any of the three FlightPlans created. Many of the other combinations evaluated (five others, to be exact) are not represented by real flight plans either. So why did Studio bother to perform three times the necessary evaluations? It is because our rule, as implemented in Figure 37, does not capture the essential elements of scope and context. We want our rule to express the fact that we are only interested in evaluating the CargoAircraft pair for each FlightPlan, not for all possible combinations. How do we express this desire in our rule? We use the associations included in the Vocabulary. Refer to Figure 44, below:
January 13, 2012
Rule Modeling Guide
Page 40
Figure 44 Rule Expressed Using FlightPlan as the Rule Scope
In Figure 44, weve rewritten the rule using the aircraft and cargo terms from inside the FlightPlan term 4. This is significant. It means we want the rule to evaluate the Cargo and Aircraft terms only in the context of a FlightPlan. For example, on a different night, the Cargo company might have eight Cargo shipments assembled, but only the same three planes on which to carry them. In this scenario, three flight plans would still be created. Should the rule evaluate all eight Cargo shipments, or only those three associated with actual flight plans? From the original business rule, it is clear we are only interested in evaluating those Cargo shipments in the context of actual flight plans. To put it differently, the rules application is limited to only those Cargo shipments assigned to a specific Aircraft via a specific FlightPlan. We express these relationships in the Rulesheet by including the FlightPlan term in the rule, so that cargo.weight is properly expressed as FlightPlan.cargo.weight, and Aircraft.maxCargoWeight is properly expressed as FlightPlan.aircraft.maxCargoWeight. By attaching FlightPlan to the terms aircraft.maxCargoWeight and cargo.weight, we have indicated mandatory traversals of the associations between FlightPlan and the other two terms, Aircraft and Cargo. This instructs Corticon Server to evaluate the rule using the intended context. In writing rules, its extremely important to understand the context of a rule and the scope of the data to which it will be applied.
RULE SCOPE
Because the rule is evaluating both Cargo and Aircraft in the context of a FlightPlan, we say that the rule has scope, which means that the rule evaluates only that data which matches the rules scope. This has an interesting effect on the way the rule is evaluated. When the rule is executed, its
By inside we mean the aircraft and cargo terms that appear when the FlightPlan term is opened in the Vocabulary tree, as shown by the orange circles in Figure 44.
January 13, 2012
Rule Modeling Guide
Page 41
scope ensures that the Server evaluates only those pairings that matches the same FlightPlan. This means that a cargo.weight will only be compared to an aircraft.maxCargoWeight if both the cargo and the aircraft share the same FlightPlan. This simplifies rule expression greatly, because it eliminates the need for us to specify which FlightPlan we are talking about for each Aircraft-Cargo combination. When a rule has context, the system takes care of this matching automatically by sending only those Aircraft-Cargo pairs that share the same FlightPlan to be evaluated by the rule. And, since Studio automatically handles multiple instances as collections 5, it sends all pairs to the rule for evaluation. To test this new rule, we need to structure our Ruletest differently to correspond to the new structure of our rule and reflect the rules scope. For more information on the mechanics of creating associations in Ruletests, also refer to the Set Up the Ruletest Scenario section in the Basic Tutorial for Corticon Studio Modeling Rules and the Creating Associations chapter in the Studio Quick Reference Guide. Finally, one FlightPlan is created for each Aircraft-Cargo pair. This means a total of three FlightPlans are generated each night. Using the terms in our Vocabulary and the relationships between them, we have the possibilities shown in Figure 40. The rule will evaluate these combinations and identify any violations.
See the following chapter, Collections, for a more detailed discussion of this topic.
January 13, 2012
Rule Modeling Guide
Page 42
Figure 45 New Ruletest Using FlightPlan as the Rule Scope
What is the expected result from this Ruletest? If the results follow the same pattern as in the first Ruletest, we might expect the rule to fire nine times (three Aircraft evaluated for each of three Cargo shipments). But refer to Figure 46 and you will see that the rule, in fact, fired only 3 times and only for those Aircraft-Cargo pairs that are related by common FlightPlans. This is the result we want. The Ruletest shows that there are no FlightPlans in violation of our rule.
January 13, 2012
Rule Modeling Guide
Page 43
Figure 46 Ruletest Results Using Scope Note no Violations
One final point about scope: it is critical that the context you choose for your rule supports the intent of the business decision you are modeling. At the very beginning of our example, we stated that the purpose of the application is to check flightplans that have already been created. Therefore, the context of our rule was chosen so that the rules design was consistent with this goal no aircraftcargo combinations should be evaluated unless they are already matched up via a common flightplan. But what if our business purpose had been different? What if the problem we are trying to solve was modified to: Of all possible combinations of aircraft and cargo, determine which pairings must not be
January 13, 2012
Rule Modeling Guide
Page 44
included in the same FlightPlan. The difference here is subtle but important. Before, we were identifying invalid combinations of pre-existing FlightPlans. Now, we are trying to identify invalid combinations from all possible cargo-aircraft pairings. This other rule might be the first step in a screening or filtering process designed to discard all the invalid combinations. In this case, the original rule we built, root-level context, would be the appropriate way to implement our intentions, because now we are looking at all possible combinations prior to creating new FlightPlans.
ALIASES
To clean up and simplify rule expression, Studio allows you to declare aliases in the Rulesheet. Using an alias to express scope results in a less cluttered Rulesheet. To define an alias, you must first shift to the Advanced View of the Rulesheet. This shift is detailed in the Studio Quick Reference Guide. If rules have already been modeled in the Rulesheet, then the Scope window will already contains those Vocabulary terms used in the rules so far. If rules have not yet been modeled, then the Scope window will be empty. Regardless, to define an alias, simply double-click to the immediate right of the term and type a unique name in the entry box, as shown below:
Figure 47 Defining an Alias in the Scope window
Once an alias has been defined, then any subsequent rule modeling in the Rulesheet will automatically substitute the alias for the Vocabulary term it represents. In Figure 48, notice that the terms in the Condition rows of the Rulesheet do not show the FlightPlan term - because the alias plan substitutes for FlightPlan. The small c in cargo and a in aircraft provide other clues that these terms exist within the context of the FlightPlan term defined in the Scope window.
January 13, 2012
Rule Modeling Guide
Page 45
Figure 48 Rulesheet with FlightPlan Alias Declared in the Scope Section
Once an alias is defined, any new Vocabulary term dropped onto the Rulesheet will be automatically abbreviated accordingly. For example, dragging and dropping FlightPlan.cargo.weight onto the Rulesheet will result in plan.cargo.weight being displayed. Aliases work in all sections of the Rulesheet, including the Rule Statement section at the bottom. Also, modifying an alias name defined in the Scope section will cause the name to update everywhere it is used in the Rulesheet. But rules modeled without aliases will not update automatically if aliases are defined later. So if you expect to use aliases, define them before beginning your rule modeling - that way theyll appear automatically when you drag and drop from the Vocabulary or Scope windows.
SCOPE AND PERSPECTIVES IN THE VOCABULARY TREE

Because our Vocabulary is organized as a tree view in Studio, it may be helpful to extend the tree analogy to better understand what aliases do. The tree view permits us to use the business terms from a number of different perspectives, each perspective corresponding to one of the root-level terms and an optional set of one or more branches. Vocabulary Tree Description Branch Diagram
January 13, 2012
Rule Modeling Guide
Page 46
Vocabulary Tree
Description This portion of the Vocabulary tree can be visualized as the branch diagram shown to the right. Because this piece of the Vocabulary begins with the FlightPlan root, the branches also originate with the FlightPlan root or trunk. The FlightPlans associated cargo and aircraft terms are branches from the trunk. Any rule expression that uses FlightPlan, FlightPlan.cargo, or FlightPlan.aircraft is using scope from this perspective of the Vocabulary tree. This portion of the Vocabulary tree begins with Aircraft as the root, with its associated flightPlan branching from the root. A cargo, in turn, branches from its associated flightPlan. Any rule expression that uses Aircraft, Aircraft.flightPlan, or Aircraft.flightPlan.cargo is using scope from this perspective of the Vocabulary tree. This portion of the Vocabulary tree begins with Cargo as the root, with its associated flightPlan branching from the root. An aircraft, in turn, branches from its associated flightPlan. Any rule expression that uses Cargo, Cargo.flightPlan, or Cargo.flightPlan.aircraft is using scope from this perspective of the Vocabulary tree.
Branch Diagram
January 13, 2012
Rule Modeling Guide

Figure 49 Vocabulary Tree Views and Corresponding Branch Diagrams
Page 47
Scope can also be thought of as hierarchical, meaning that a rule written with scope of Aircraft applies to all root-level Aircraft data. And other rules using some piece (or branch) of the tree beginning with root term Aircraft, including Aircraft.flightPlan and Aircraft.flightPlan.cargo, also apply to this data and its associated collections. Likewise, a rule written with scope of Cargo.flightPlan does not apply to root-level FlightPlan data. This provides an alternative explanation for the different behaviors between the Rulesheets in Figure 37 and Figure 44. The rules in Figure 37 are written using different root terms and therefore different scopes, whereas the rules in Figure 44 use the same FlightPlan root and therefore share common scope.
ROLES
Using roles in the Vocabulary can often help to clarify rule context. To illustrate this point, we will use a slightly different example. The UML class diagram for a new (but related) sample Vocabulary is shown in Figure 50.
Figure 50 UML Class Diagram without Roles
As shown in this class diagram, the entities Person and Aircraft are joined by an association. However, can this single association sufficiently represent multiple relationships between these entities? For example, a prior Fact Model might state that a pilot flies an aircraft and a passenger rides in an aircraft both pilot and passenger are descendants6 of the entity Person. Furthermore, we can see that, in practice, some instances of Person may be pilots and some may be passengers. This is important because it suggests that some business rules may use Person in its pilot context, and others may use it in its passenger context. How do we represent this in the Vocabulary and rules we build in Studio?
See Support for Inheritance in the Vocabulary chapter for details about how Corticon supports inheritance.
January 13, 2012
Rule Modeling Guide Lets examine this problem in more detail. Assume we want to implement two new rules:
Page 48
We call these rules cross-entity because they include more than one entity (both Aircraft and Person) in their expression. Unfortunately, with our Vocabulary as it is, we have no way to distinguish between pilots and passengers, so there is no way to unambiguously implement these 2 rules. This class diagram, when imported into Studio, appears in Figure 51 as a Vocabulary:
Figure 51 Vocabulary without Roles
However, there are several ways to modify this Vocabulary to allow us to implement these rules. Well discuss these methods and examine the advantages and disadvantages of each. Use Inheritance Use two separate entities for Pilot and Passenger instead of a single Person entity. This may often be the best way to distinguish between pilots and passengers, especially if the two types of Person reside in different databases or different database tables (an aspect of deployment that rule modelers may not be aware of). Also, if the two types of Person have some shared and some different attributes (Pilot may have attributes like licenseRenewalDate and typeRating while Passenger may have attributes like farePaid and seatSelection) then it may make sense to set up entities as descendants of a common ancestor entity (such as Employee). Add an Attribute to Person If the two types of person differ only in their type, then we may decide to simply add a personType (or similar) attribute to the entity. In some cases, personType will have the value of pilot, and sometimes it will have the value of passenger. The advantage of this method is that it is flexible: in the future, persons of type manager or bag handler or air marshal can easily be added. Also, this construction may be most consistent with the actual structure of the employee database or
January 13, 2012
Rule Modeling Guide
Page 49
database table and maintains a normalized model. The disadvantage comes when the rule modeler needs to refer to a specific type of Person in a rule. While this can be accomplished using any of the filtering methods discussed in Rule Writing Techniques, they are sometimes less convenient and clear than the final method, discussed next. Use Roles A role is a noun that labels one end of an association between two entities. For example, in our PersonAircraft Vocabulary, the Person may have more than one role, or more than one kind of relationship, with Aircraft. An instance of Person may be a pilot or a passenger; each is a different role. To illustrate this in our UML class diagram, we add labels to the associations as follows:
Figure 52 UML Class Diagram with Roles
When the class diagram is imported into Studio, it appears as the Vocabulary below:
Figure 53 Vocabulary with Roles
Notice the differences between Figure 53 and Figure 51 in Figure 53, Aircraft contains 2 associations, one labeled passenger and the other pilot, even though both associations relate to the same Person entity. Also notice that we have updated the cardinalities of both Aircraft Person associations to one-to-many.
January 13, 2012
Rule Modeling Guide
Page 50
Written using roles, the first rule appears below. There are a few aspects of the implementation to note: Use of aliases for Aircraft and Aircraft.pilot (plane and pilotOfPlane, respectively). Aliases are just as useful for clarifying rule expressions as they are for shortening them. The rule Conditions evaluate data within the context of the plane and pilotOfPlane aliases, while the Action posts a message to the plane alias. This enables us to act on the aircraft entity based upon the attributes of its associated pilots. Note that Condition row b uses a special operator (->size) that counts the number of pilots associated with a plane. This is called a collection operator and is explained in more detail in the following chapters.
Figure 54 Rule #1 Implemented using Roles
To demonstrate how Studio differentiates between entities based on rule scope, well construct a new Ruletest that includes a single instance of Aircraft and 2 Person entities, neither of which has the role of pilot.
January 13, 2012
Rule Modeling Guide
Page 51
Figure 55 Ruletest with no Person entities in Pilot role
Despite the fact that there are two Person entities, both of whom are members of the Flight Crew department, the system recognizes that neither of them have the role of pilot (in relation to the Aircraft entity), and therefore generates the violation message shown. If we create a new Input Ruletest, this time with both persons in the role of pilot, we see a different result as shown in Figure 56:
January 13, 2012
Rule Modeling Guide
Page 52
Figure 56 Ruletest with both Person entities in role of Pilot
Finally, the rules are tested with one pilot and one passenger:
January 13, 2012
Rule Modeling Guide
Page 53
Figure 57 Ruletest with one Person entity in each of Pilot and Passenger roles
We see that despite the presence of two Person elements in the collection of test data, only one satisfies the rules scope pilot associated with aircraft. As a result, the rules determine that one pilot is insufficient to fly a 747, and the violation message is displayed. These same concepts apply to the DC-10/Passenger business rule, which will not be implemented here.
January 13, 2012
Rule Modeling Guide
Page 54
TECHNICAL ASIDE
Understanding Rule Associations and Scope as Relationships Between Tables in a Relational Database Although it is not necessary for the rule modeler or developer to understand database theory, a business or systems analyst who is familiar with it may have already recognized that the preceding discussion of rule scope and context is an abstraction of basic relational concepts. Actual relational tables that contain the data for our Cargo example might look like the following:
Aircraft tailNumber* N1001 N1002 N1003 aircraftType maxCargoWeight 747 747 DC-10 200,000 200,000 150,000 Cargo manifestNumber* volume 625A 625B 625C 300 300 300 weight 100,000 175,000 150,000
FlightPlan flightNumber* 101 102 103 tailNumber N1001 N1002 N1003 manifestNumber 625A 625B 625C
Figure 58 Tables in a Relational Database
Each table in Figure 58 has a column that serves as a unique identifier for each row (or record). In the case of the Aircraft table, the tailNumber is the unique identifier for each Aircraft record this means that no two Aircraft can have the same tailNumber. ManifestNumber is the unique identifier for each Cargo record. These unique identifiers are known as primary keys. Given the primary key, a particular record can always be found and retrieved. A common notation uses an asterisk character (*) to indicate those table columns that serve as primary keys. If a Vocabulary has been connected to an external database using Direct Database Access features, then you may notice asterisks next to attributes, indicating their designation as primary keys. See the Server Integration and Deployment Guide, Direct Database Access chapter for complete details. Notice that the FlightPlan table contains columns that did not appear in our Vocabulary. Specifically, tailNumber and manifestNumber exist in the Aircraft and Cargo entities, respectively, but we did not include them in the FlightPlan Vocabulary entity. Does this mean that our original Vocabulary was wrong or incomplete? No - the extra columns in the FlightPlan table are really duplicate columns from the other two tables tailNumber came from the Aircraft table and manifestNumber came from the Cargo table. These extra columns in the FlightPlan table are called foreign keys because they are the primary keys from other tables. They are the mechanism for creating relations in a relational database.
January 13, 2012
Rule Modeling Guide
Page 55
For example, we can see from the FlightPlan table that flightNumber 101 (the first row or record in the table) includes Aircraft of tailNumber N1001 and Cargo of manifestNumber 625A. The foreign keys in FlightPlan serve to link or connect a specific Aircraft with a specific Cargo. If the database is queried (using a query language like SQL, for example), a user could determine the weight of Cargo planned for Aircraft N1001 by traversing the relationships from the Aircraft table to the FlightPlan table, we discover that Aircraft N1001 is scheduled to carry Cargo 625A. By traversing the FlightPlan table to the Cargo table, we discover that Cargo 625A weighs 100,000 lbs. Matching the foreign key in the FlightPlan table with the primary key in the Cargo table makes this traversal possible. The Corticon Vocabulary captures this essential feature of relational databases, but abstracts it in a way that is friendlier to non-programmers. Rather than deal with concepts like foreign keys in our Vocabulary, we talk about associations between entities. Traversing an association in the Vocabulary is exactly equivalent to traversing a relationship between database tables. When we use a term like Aircraft.tailNumber in a rule, Studio creates a collection of tailNumbers from all records in the Aircraft table. This collection of data is then fed to the rule for evaluation. If however, the rule uses FlightPlan.aircraft.tailNumber, then Studio will create a collection of only those tailNumbers from the Aircraft table that have FlightPlans related to them it identifies these aircraft instances by matching the tailNumber in the Aircraft table with the tailNumber (foreign key) in the FlightPlan table. If the Aircraft table contains 7 instances of aircraft (i.e., 7 unique rows in the table), but the FlightPlan table contains only 3 unique instances of flight plans, the term FlightPlan.aircraft.tailNumber will create a collection of only 3 tail numbers those instances from the Aircraft table which have flight plans listed in the FlightPlan table. In database terminology, the scope of the rule determines how the tables are joined. When FlightPlan is used as the scope for our rule, Studio automatically ensures that the collection of data contains matching foreign keys. Thats why, when we rewrote the rule using proper scope, the rule only fired 3 times there are only 3 examples of Aircraft-Cargo combinations where the keys match. This also explains why, prior to using scope, the rule produced 6 spurious and irrelevant outcomes 6 combinations of Aircraft and Cargo that were processed by the rule do not, in fact, exist in the FlightPlan table. While the differences in processing requirements are not extreme in our simple example, for a large company like Federal Express, with a fleet of hundreds of aircraft and several thousand unique cargo shipments every day, the system performance differences could be enormous.
TEST YOURSELF:
Use the following Vocabulary to answer the next questions. Answers are provided in Appendix D.
January 13, 2012
Rule Modeling Guide
Page 56
41. How many root-level entities are present in the Vocabulary? 42. Which of the following terms are allowed by the Vocabulary? Movie.roles Actor.roles DVD.actor Award.movie
43. Which of the following terms are not allowed by the Vocabulary?
January 13, 2012
Rule Modeling Guide
Page 57
Movie.oscar
Movie.supplier
Movie.roles.actor Movie.dVD.extras
44. Which Vocabulary term represents the following phrases? a. A movies Oscars b. A movies roles c. An actors roles d. A DVDs distributor e. A movies DVD extras f. An actors Oscars 45. Which of the following terms represents the phrase an actor in a role of a movie Movie.roles.dVD Actor.roles.movie DVD.actor.movie Actor.movie.roles
46. Since the association between Actor and Role is bidirectional, we can use both Actor.roles and _____________ in our rules. 47. Which two entities are associated with each other by more than one role? 48. What are the role names? 49. Besides roles, how else could these two relationships be represented in the Vocabulary to convey the same business meaning? 50. What is the advantage of using roles in this way? 51. When more than role is used to associate two entities, each role name must be: friendly unique colorful melifluous
52. True or False. Rules evaluate only data that shares the same scope 53. Write a conditional expression in a Rulesheet for each of the following phrases: a. If a movies DVD has deleted scenes b. If an actor played a role in a movie winning an Oscar c. If the DVD is an import
January 13, 2012
Rule Modeling Guide d. If the Movie was released more than 50 years before the DVD e. If the actor ever played a leading role f. If the movie was nominated for a Golden Globe g. If the Distributor offers any drama DVDs
Page 58
Given the rule Disney animated classics are priced in the high tier, answer the following questions: 54. Which term should be used to represent Movie? 55. Which term should be used to represent DVD? 56. True or False. The following Rulesheet correctly relates the Movie and DVD entities?
57. Given our business intent, how many times do we want the rule to fire given the Input Testsheet below?
January 13, 2012
Rule Modeling Guide
Page 59
58. Given the Ruletest Input above, how many times does the rule actually fire? 59. Assume we update the Rulesheet to include another rule, as shown below. Answer the following questions:
January 13, 2012
Rule Modeling Guide
Page 60
a. Assuming the same Ruletest Input as question 57, what result do we want for Cinderella? b. What result do we want for Toy Story? c. What results do we get when the Test is executed? d. How many times does each rule fire? e. How many total rule firings occurred? f. This set of combinations is called a ________________ g. Does our result make business sense? h. What changes should be made to the Rulesheet so that it functions as we intend? 60. True or False. Whenever our rules contain scope, we must define aliases in the Scope section of the Rulesheet. 61. Scope is another way of defining a specific _______________ in the Vocabulary 62. If you change the spelling of an alias in the Scope section, then everywhere that alias is used in the Rulesheet will: turn red be deleted be updated be ignored
63. True or False. The spelling of an alias may be the same as the Vocabulary entity it represents?
January 13, 2012
Rule Modeling Guide
Page 61
RULE WRITING TECHNIQUES LOGICAL EQUIVALENTS

The Studio Rulesheet is a very flexible device for writing and organizing rules. It is often possible to express the same business rule multiple ways in a Rulesheet, with all forms producing the same logical results. Some common examples, as well as their advantages and disadvantages, are discussed in this chapter.
FILTERS VS. CONDITIONS

The Filters section of a Rulesheet can contain one or more master conditional expressions for that Rulesheet. In other words, other business rules will fire if and only if data a) survives the Filter, and b) shares the same scope as the rules. Using our air cargo example from the previous chapter, we model the following rule:
Figure 59 Rulesheet Using a Filter and Nonconditional Rule
In Figure 59, the value of an Aircrafts maxCargoWeight attribute is assigned by column 0 in the Conditions/Actions pane (what we sometimes call a Nonconditional rule because it has no Conditons). The Filter acts as a master conditional expression because only Aircraft that satisfy the Filter, i.e., only those aircraft of aircraftType = 747, successfully pass through to be evaluated by rule column 0, and are assigned a maxCargoWeight of 200,000. This effectively filters out all non-747 aircraft from evaluation by rule column 0. If this Filter were not present, all Aircraft, regardless of aircraftType, would be assigned a maxCargoWeight of 200,000 lbs. Using this method, additional Rulesheets may be used to assign different maxCargoWeight values for each aircraftType. The Filter section may be thought of as a convenient way to quickly add the same conditional expression or constraint to all other rules in the same Rulesheet. We can also achieve the same results without using Filters. Figure 60 shows how we use a Condition/Action rule to duplicate the results of the previous Rulesheet. The rule is restated as an if-
January 13, 2012
Rule Modeling Guide
Page 62
then type of statement: if the aircraftType is 747, then its maxCargoWeight equals 200,000 lbs.
Figure 60 Rulesheet Using a Conditional Rule
Regardless of how you choose to express logically equivalent rules in a Rulesheet, the results will also be equivalent 7. That said, there may be times when it is advantageous to choose one way of expressing a rule over another, at least in terms of the visual layout, organization and maintenance of the business rules and Rulesheets. The example discussed in the preceding paragraphs was very simple because only one Action was taken as a result of the Filter or Condition. In cases where there are multiple Actions that depend on the evaluation of one or more Conditions, it may make the most sense to use the Filters section. Conversely, there may be times when using a Condition makes the most sense, such as the case where there are numerous values for the Condition that each require a different Action or set of Actions as a result. In our example above, there are different types of Aircraft in the companys fleet, and each has a different maxCargoWeight value assigned to it by rules. This could easily be expressed on one Rulesheet by using a single row in the Conditions section. It would require many Rulesheets to express these same rules using the Filters section. This leads us to the next topic of discussion.
BOOLEAN CONDITION VS. VALUES SET

Figure 60 illustrates a simple Boolean Condition that evaluates to either True or False. The Action related to this Condition is either selected or not, on or off, meaning the value of maxCargoWeight is either assigned the value of 200,000 or it is not (Action statements are activated by selecting the check box that automatically appears when the cell is clicked). However, there is another way to express both Conditions and Actions using Values sets.
While the logical result may be identical, the time required to produce those results may not be. See Optimizing Rulesheets in the Logical Validation chapter of this Guide for details.
January 13, 2012
Rule Modeling Guide
Page 63
Figure 61 Rulesheet Illustrating use of Multiple values in the same Condition Row
By using different values in the column cells of Condition and Action rows in Figure 61, we can write multiple rules (represented as different columns in the table) for different Condition-Action combinations. Expressing these same rules using Boolean expressions would require many more Condition and Action rows, and would fail to take advantage of the semantic pattern these three rules share.
Exclusionary Syntax
The following examples are also logically equivalent:
Figure 62 Exclusionary Logic Using Boolean Condition, Pt. 1
January 13, 2012
Rule Modeling Guide
Page 64
Figure 63 Exclusionary Logic Using Boolean Condition, Pt.2
Figure 64 Exclusionary Logic Using Negated Value
Notice Figure 64 uses the unary function not, described in more detail in the Rule Language Guide, to negate the value 747 selected from the Values set. Once again we see that the same rule can be expressed in different ways on the Rulesheet, with identical results. It is left to the rule modeler to decide which way of expressing the rule is preferable in a given situation. We recommend, however, avoiding double negatives. Most people find it easier to understand attribute=T instead of attribute<>F, even though logically the two expressions are equivalent 8.
assumes bi-value logic. If tri-value logic is assumed (such as for a non-mandatory attribute), meaning the null value is available in addition to true and false, then these two expressions are not equivalent. If attribute = null, then the truth value of attribute<>F is true while that of attribute=T is false.
January 13, 2012
Rule Modeling Guide
Page 65
Using other in Condition Cells

Sometimes its easier to define values we dont want matched than it is to define those we do. In the example shown above in Figure 64, we specify a maxCargoWeight to assign when aircraftType is not a 747. But what would we write in the Conditions Cell if we wanted to specify any aircraftType other than those specified in any of the other Conditions Cells? For this, we use a special term in the Operator Vocabulary named other, shown in Figure 65 below.
Figure 65 Literal Term other in the Operator Vocabulary
The term other provides a simple way of specifying any value other than any of those specified in other Cells of the same Conditions row. Figure 66, below, illustrates how we can use other in our example.
Figure 66 Rulesheet Using other in a Condition Cell
January 13, 2012
Rule Modeling Guide
Page 66
In Figure 66, we added a new rule (column 4) that assigns a maxCargoWeight of 50000 to any aircraftType other than the specific values identified in the cells in Condition row a (for example, a 727). Our Rulesheet is now complete because all possible Condition-Action combinations are explicitly defined by columns in the decision table.
USE OF RANGES IN CONDITION CELLS

When using values in Condition Cells for attributes of any data type except Boolean, the values do not need to be discreet they may be in the form of a range. A value range is typically expressed in the following format: x..y, where x and y are the starting and ending values for the range inclusive of the endpoints if there is no other notation to indicate otherwise. This is illustrated in Figure 67 below.
Figure 67 Rulesheet Using Value Ranges in the Column Cells of a Condition Row
In this example, we are assigning a maxCargoWeight value to each Aircraft depending on the flightNumber value from the FlightPlan that the Aircraft is associated with. The value range 101..200 represents all values (Integers in this case) between 101 and 200, including the range endpoints 101 and 200. This is an inclusive range in that the starting and ending values are included in the range. Studio also gives you the option of defining value ranges where one or both of the endpoints are exclusive, meaning that they are not included in the range of values this is the same idea as the difference between greater than and greater than or equal to. Figure 68 shows the same Rulesheet shown in Figure 67, but with one difference: we have changed the value range 201..300 to (200..300]. The starting parenthesis ( indicates that the starting value for the range, 200, is exclusive it is not included in the range. The ending bracket ] indicates that the ending value is inclusive. Since flightNumber is an Integer value and there are therefore no fractional values allowed, 201..300 and (200..300] are equivalent.
January 13, 2012
Rule Modeling Guide
Page 67
Figure 68 Rulesheet Using Open-Ended Value Ranges in Condition Cells
Listed below are all of the possible combinations of parenthesis and bracket notation for value ranges and their meanings:
As illustrated in columns 2-3 of Figure 67 and column 2 of Figure 68, if a value range has no enclosing parentheses or brackets, it is assumed to be inclusive. It is therefore not necessary to use the [..] notation for a closed range in Studio; in fact, if you try to create a value range with [..] in Studio, the square brackets will be automatically removed. However, should either end of a value range have a parenthesis or a bracket, then the other end must also have a parenthesis or a bracket. For example, x..y) is not allowed, and is properly expressed as [x..y). Value ranges can also be used in the Filters section of the Rulesheet. See the Rule Language Guides Special Syntax chapter for full details on usage.
ALTERNATIVES TO VALUE RANGES

As you might expect, there is another way to express a rule which contains a range of values. One alternative is to use a series of Boolean Conditions that cover the ranges of concern. This is illustrated in Figure 69.
January 13, 2012
Rule Modeling Guide
Page 68
Figure 69 Rulesheet Using Boolean Conditions to Express Value Ranges
The rules in Figure 69 are identical to the rules in Figure 67 and Figure 68, but are expressed using a series of three Boolean Conditions. Recall that in a decision table, values aligned vertically in the same column represent ANDed Conditions in the rule. So rule 1, as expressed in column 1, reads: if flightNumber is not greater than 100 and flightNumber is not greater than 200 and flightNumber is not greater than 300, then its maxCargoWeight must equal 50,000 lbs. Expressing this rule in friendlier, more natural English, we might say: An Aircrafts max cargo weight must be 50,000 lbs when flight number is less than or equal to 100. This is how the rule is expressed in the Rule Statements section in Figure 69. The same rules may also be expressed using a series of Rulesheets with the applicable range of flightNumber values constrained by Filters. Studio gives you the flexibility to express and organize your rules any number of possible ways as long as the rules are logically equivalent, they will produce identical results when executed. In the case of rules involving numeric value ranges as opposed to discrete numeric values, the value range option allows you to express your rules in a very simple and elegant way. It is especially useful when dealing with Decimal type values.
STANDARD BOOLEAN CONSTRUCTIONS

A decision table is a graphical method of organizing and formalizing logic. But if you have a background in computer science or formal logic, you may have seen alternative methods. One such method is called a truth table. In Appendix A, several standard truth tables are presented with equivalent Rulesheets.
January 13, 2012
Rule Modeling Guide
Page 69
TEST YOURSELF:
Answers are provided in Appendix D 64. Filters act as master rules for all other rules in the same Rulesheet that share the same _________. 65. An expression that evaluates to a True or False value is called a _________ expression. 66. True or False. Condition row values sets must be complete. 67. True or False. Action row values sets must be complete. 68. The special term __________ can be used to complete any Condition row values set. 69. What operator is used to negate a Boolean expression? 70. If a Boolean expression is written in a Condition row, what values are automatically entered in the Values set when Enter is pressed? 71. A Filter expression written as Entity.boolean1=T is equivalent to (circle all that apply)
Entity.boolean 1 Entity.boolean1<> F Entity.boolean1= F not (Entity.boolean1=F)
72.
Of all alternatives listed in Question 71, which is the best choice? Why?
73. Describe the error (if any) in each of the following value ranges. Assume all are used in Conditions values sets. a. {110, other} b. {1..a, other} c. {a..other} d. {1..10, 5..20, other} e. {1..10, [10..20), other} f. {red, green, blue} g. {<0, 0..15, >3}
January 13, 2012
Rule Modeling Guide 74. True or False. The special term other may be used in Action row values sets.
Page 70
75. Using best practices discussed in this chapter, model the following rules on a single Rulesheet a. If the part is in stock and it has a blue tag, then the parts discount is 10% b. If the part is in stock and it has a red tag, then the parts discount is 15% c. If the part is in stock and it has a yellow tag, then the parts discount is 20% d. If the part is in stock and it has a green tag, then the parts discount is 25% e. If the part is in stock and it has any other color tag, then the parts discount is 5% 76. True or False. A Nonconditional rule is equivalent to an Action expression with no Condition. 77. True or False. A Nonconditional rule is governed by any Preconditions on the same Rulesheet.
January 13, 2012
Rule Modeling Guide
Page 71
COLLECTIONS
UNDERSTANDING HOW STUDIO HANDLES COLLECTIONS
Support for using collections is extensive in Studio in fact, the integration of collection support in the Rules Language is so seamless and complete, the rule modeler will often discover that rules are performing multiple evaluations on collections of data beyond what he/she anticipated! This is partly the point of a declarative environment the rule modeler need only be concerned with what the rules do, rather than how they do it. How the system actually iterates or cycles through all the available data during rule execution should not be of concern. As we saw in previous examples, a rule with term FlightPlan.aircraft was evaluated for every instance of FlightPlan.aircraft data delivered to the rule, either by an XML message or by a Ruletest (which are really the same thing, as the Ruletest simply serves as a quick and convenient way to create XML payloads and send them to the rules). A rule is expressed in Studio the same way regardless of how many instances of data are to be evaluated by it contrast this to more traditional procedural programming techniques, where for-do or while-next type looping syntax is often required to ensure all relevant data is evaluated by the logic.
VISUALIZING COLLECTIONS
Collections of data may be visualized as discrete portions, subsets, or branches of the Vocabulary tree a parent entity associated with a set of child entities, which we call elements of the collection. Looking back at the role example from a previous chapter, the collection of pilots can be illustrated as:
Figure 70 Visualizing a Collection of Pilots
In Figure 70, the aircraft entity is the parent of the collection, while each pilot is a child element of the collection. As we saw in the role example, this collection is expressed as aircraft.pilot in CRL. It is important to reiterate that this collection contains scope we are seeing the collection of pilots as they relate to this aircraft. Or, put more simply, we are seeing a plane and its 2 pilots, arranged in a way that is consistent with our Vocabulary. Whenever a rule exists that contains or uses this same scope, it will also automatically evaluate this collection of data. And if there are multiple collections with the same scope (for example, several aircraft, each with its own collection of pilots), then the rule will automatically evaluate all those collections, as well. In our lexicon, evaluate has a different meaning than fire. Evaluate means that a rules scope and Conditions will be compared to
January 13, 2012
Rule Modeling Guide the data to see if they are satisfied. If they are satisfied, then the rule fires and its Actions are executed.
Page 72
Collections can be much more complex than this simple pilot example. For instance, a collection can comprise more than one type or level of association:
Figure 71 3-Level Collection
This collection is expressed as parent.child.grandchild in CRL 9. Now lets look at a simple collection operator and understand how it works given the collection in Figure 70.
A BASIC COLLECTION OPERATOR

Lets use the ->size operator 10 as an example. This operator returns the number of elements in the collection it follows in a rule expression. Using the collection from Figure 70:
aircraft.pilot -> size
returns the value of 2. In the expression:

aircraft.crewSize = aircraft.pilot -> size crewSize (assumed to be an attribute of Aircraft) is assigned the value of 2.
Studio requires that all rules containing collection operators use unique aliases to represent the collections. Using aliases to represent collections is described in greater detail in this chapter. A more accurate expression of the rule above becomes:
plane.pilot -> size
or
plane.crewsize = plane.pilot -> size
The parent and child nomenclature is a bit arbitrary. Assuming bidirectional associations, a child from one perspective could also be a parent in another. A complete description of size can be found in the Rule Language Guide
10
January 13, 2012
Rule Modeling Guide where plane is an alias for the collection of pilots on aircraft.
Page 73
FILTERING COLLECTIONS
The process of screening specific elements from a collection is known as filtering, and the Studio supports filtering by a special use of Filter expressions. Please see the Filters & Preconditions chapter of this manual for more details.
USING ALIASES TO REPRESENT COLLECTIONS

Aliases provide a means of using scope to specify elements of a collection; more specifically, we are using aliases (expressed or declared in the Scope section of the Rulesheet) to represent copies of collections. This concept is important because aliases give you the ability to operate on and compare multiple collections, or even copies of the same collection. There are situations where such operations and comparisons are required by business rules. Such rules are not easy (and sometimes not possible) to implement without using aliases. To ensure that the system knows precisely which collection (or copy) you are referring to in your rules, its necessary to use a unique alias to refer to each collection. For the purposes of illustration, we will introduce a new scenario and business Vocabulary. This new scenario involves a financial services company that compares and ranks stocks based on the values of attributes such as closing price and volume. A model for doing this kind of ranking can get very complex in real life; however, we will keep our example simple. Our new Vocabulary is illustrated in a UML class diagram in Figure 72.
Figure 72 Security Vocabulary UML Class Diagram
This Vocabulary consists of only two entities:

Security represents a security (stock) with attributes like security name (secName), ticker symbol, and rating. SecInfo is designed to record information for each stock for each business day (busDay); attributes include values recorded for each stock (closePrice and volume) and values determined by rules (totalWeight and rank) each business day.
January 13, 2012
Rule Modeling Guide
Page 74
The association between Security and SecInfo is 1..* (one-to-many) since there are multiple instances of SecInfo data (multiple days of historical data) for each Security. In our scenario, we will use three rules to determine a securitys rank:
Finally, rules will be used to assign a rank based on the total weight. It is interesting to note that although the rules refer to a securitys closing price, volume, and rule weights, these attributes are actually properties of the SecInfo entity. Rulesheets that accomplish these tasks are shown in the next two figures.
Figure 73 Rulesheet with Ranking Model Rules 1 and 2
In Figure 73 above, we see two business rules expressed in a total of four rule models (one for each possible outcome of the two business rules). The rules themselves are straightforward, but the shortcuts (alias values) used in these rules are different than any we have seen before. In the Scope section, we see the following:
January 13, 2012
Rule Modeling Guide
Page 75
Figure 74 Close-up of the Scope Section from Figure 73
Security is the scope for our Rulesheet, which is not a new concept. But then we see that there are two aliases for the SecInfo entities associated with Security: secinfo1 and secinfo2. Each of these aliases represents a separate but identical collection of the SecInfo entities associated with Security. In this Rulesheet, we constrain each alias by using Filters; in a later example, we will see
how more loosely constrained aliases can represent many different elements in a collection when the Corticon Server evaluates rules. In this specific example, though, one instance of SecInfo represents the current business day (today) and the other instance represents the previous business day (today.addDays(-1) 11). Once the aliases are created and constrained, we can use them in our rules where needed. In Figure 73, we see that the use of aliases in the Conditions section allows comparison of closePrice and volume values from one specific SecInfo element (the one with todays date) of the collection with another (the one with yesterdays date). Figure 75 shows a second Rulesheet which uses a Nonconditional rule to calculate the sum of the partial weights from our model rules as determined in the first Rulesheet, and Conditional rules to assign a rank value between 1 and 4 to each security based on the sum of the partial weights. Since we are only dealing with data from the current day in this Rulesheet (as specified in the Filters), only one instance of SecInfo per Security applies and we do not need to use aliases.
11
For more details on the .addDays operator, please refer to the Rule Language Guide
January 13, 2012
Rule Modeling Guide
Page 76
Figure 75 Rulesheet with Total Weight Calculation and Rank Determination
We can test our new rules using a Ruleflow to combine the two Rulesheets. In a Ruletest which executes the Ruleflow, we would expect to see the following results: 1. The Security.secInfo collection that contains data for the current business day (we expect that this collection will reduce to just a single secinfo element, since only one secinfo element exists for each day) should be assigned to alias secinfo1 for evaluating the model rules. 2. The SecInfo instance that contains data for the previous business day (again, the collection filters to a single secinfo element for each Security) should be assigned to alias secinfo2 for evaluating the model rules. 3. The partial weights for each rule, sum of partial weights, and resulting rank value should be assigned to the appropriate attributes in the current business days SecInfo element. A Ruleflow constructed for testing the ranking model rules is shown in Figure 77.
January 13, 2012
Rule Modeling Guide
Page 77
Figure 76 Ruleflow to test two Rulesheets in succession
Figure 77 Ruletest for Testing Security Ranking Model Rules
In Figure 77, we have added one Security object and three associated SecInfo objects from the Vocabulary. The current day at the time of the Ruletest is 5/14/2003, so the three SecInfo objects represent the current business day and two previous business days. The third business day is included in this Ruletest to verify that the rules are using only the current and previous business days none of the data from the third business day should be used if the rules are executing correctly. Based on the values of closePrice and volume in our two SecInfo objects being tested, we expect to see the highest rank of 4 assigned to our security in the current business days SecInfo object.
January 13, 2012
Rule Modeling Guide
Page 78
Figure 78 Ruletest for Security Ranking Model Rules
We see the expected results produced above. Both closePrice and volume for 11/12/2008 were higher than the values for those same attributes on 11/11/2008; therefore, both rule1Weight and rule2Weight attributes were assigned their high values by the rules. Accordingly, the totalWeight value calculated from the sum of the partial weights was the highest possible value and a rank of 4 was assigned to this security for the current day. As previously mentioned, the example above was tightly constrained in that the aliases were assigned to two very specific elements of the referenced collections. What about the case where there are multiple instances of an entity that you would like to evaluate with your rules? We will discuss just such an example next. Our second example is also based on our security ranking scenario but, in this example, the rank assignment that was accomplished in Figure 73 will be done in a different way. Instead, we would like to rank a number of securities based on their relative performance to one another, rather than against a preset ranking scheme like the one in Figure 73. In the rules for our new example, we will compare the totalWeight value that is determined for each security for the current business day against the totalWeight of every other security, and determine a rank based on this comparison of totalWeight values. A Rulesheet for this alternate method of ranking securities is shown in the next figure.
January 13, 2012
Rule Modeling Guide
Page 79
Figure 79 Rulesheet with Alternate Rank Determination Rules
In these new ranking rules, we have created aliases to represent specific instances of Security and their associated collections of SecInfo. As in the previous example, Filters constrain the aliases, most notably in the case of the SecInfo instances, where we filter secInfo1 and secInfo2 for a specific value of busDay (todays date). However, we have only loosely constrained our Security instances we merely have a Filter that prevents the same element of Security from being compared to itself (when sec1 = sec2). No other constraints are placed on the Security aliases. Its important to note that we are not assigning specific, single elements of Security to our aliases. Instead, we are instructing the Server to evaluate all allowable combinations (i.e., all those combinations that satisfy the 1st Filter) of Security elements in our collection in each of the aliases (sec1 and sec2). For each allowable combination of Security elements, we will compare the totalWeight values from the associated SecInfo element for busDay = today, and increment the rank value for the first SecInfo element (secinfo1) by 1 if its totalWeight is greater than that of the second SecInfo object (secinfo2). The end result should be the relative performance ranking of each security that we desire.
January 13, 2012
Rule Modeling Guide
Page 80
Figure 80 Ruletest for Testing Alternate Security Ranking Model Rules
Figure 80 shows a Ruletest constructed to test these ranking rules. In our data, we have added four Security elements and an associated secInfo element for each (its important to note that each alias will represent ALL 4 security elements AND their associated secInfo elements). The current day at the time of the Ruletest is 2/9/2009, so each Security.secInfo.busDay attribute is given the value of 2/9/2009 (if we had included additional secinfo elements in each collection, theyd have earlier dates, and therefore would be filtered out by the Preconditions on each alias). We have initially set (or initialized) each Security.secInfo.rank equal to 1, so that the lowest ranked security will still have a value of 1 12. The values of totalWeight for the SecInfo objects are all different; therefore, we expect to see each security ranked between 1 and 4 with no identical rank values.
12
The lowest ranked security will be the one that loses all comparisons with the other securities, i.e., its weight is less than the weights of all other securities. If a securitys weight is less than all the other security weights, its rank will never be incremented by the rule, so its rank will remain 1.
January 13, 2012
Rule Modeling Guide
Page 81
Note: If there were multiple Security.secInfo elements (multiple securities) with the same totalWeight value for the same day, then we would expect the final rank assigned to these objects to be the same as well. Further, if there were multiple Security.secInfo entities sharing the highest relative totalWeight value in a given Ruletest, then the highest rank value possible for that Ruletest would be lower than the number of securities being ranked, assuming we initialize all rank values at 1.
January 13, 2012
Rule Modeling Guide
Page 82
Figure 81 Ruletest for Alternate Security Ranking Model Rules
As seen in Figure 81, our Ruletest results are as expected. The security with the highest relative totalWeight value ends the Ruletest with the highest rank value after all rule evaluation is complete. The other securities are also assigned rank values based on the relative ranking of their
January 13, 2012
Rule Modeling Guide
Page 83
totalWeight values. The individual rule firings that resulted in these outcomes are highlighted in the
message section at the bottom of the results sheet. It is interesting to note that nowhere in the rules is it stated how many security entities will be evaluated. This is another example of the ability of the declarative approach to produce the desired outcome without requiring explicit, procedural instructions.
SPECIAL COLLECTION OPERATORS

There are two special collection operators available in Studios Operator Vocabulary that allow us to evaluate collections for specific Conditions. These operators are based on two concepts from the predicate calculus: the universal quantifier and the existential quantifier. These operators return a result about the collection, rather than about any particular element within it. Although this is a simple idea, it is actually a very powerful capability some decision logic cannot be expressed without these operators.
Universal Quantifier
The meaning of the universal quantifier is that a condition enclosed by parentheses is evaluated (i.e., its truth value is determined) for all instances of an entity or collection. This is implemented as the forAll operator in the Operator Vocabulary. Well demonstrate this operator with an example created using the Vocabulary from our security ranking model. Note that these operators act on collections, so all the examples shown will declare aliases in the Scope section.
Figure 82 Rulesheet with Universal Quantifier (for all) Condition
In Figure 82, we see the Condition

secinfo ->forAll(secinfo.rank >= 3)
January 13, 2012
Rule Modeling Guide
Page 84
The exact meaning of this Condition is that for the collection of SecInfo elements associated with a Security (represented and abbreviated by the alias secInfo), evaluate if the expression in parentheses (secinfo.rank >= 3) is true for all elements. The result of this Condition is Boolean because it can only return a value of true or false. Depending on the outcome of the evaluation, a value of either High or Low will be assigned to the rating attribute of our Security entity and the corresponding Rule Statement will be posted as a message to the user. Figure 83 shows a Ruletest constructed to test our for all Condition rules.
Figure 83 Ruletest for Testing for all Condition Rules
In this Ruletest, we are evaluating a collection of three SecInfo elements associated with a Security entity. Since the rank value assigned in each SecInfo object is at least 3, we should expect that our for all Condition will evaluate to true and a rating value of High will be assigned to
January 13, 2012
Rule Modeling Guide
Page 85
our Security object when the Ruletest is run through Corticon Server. This outcome is confirmed in the Ruletest results shown in Figure 84.
Figure 84 Ruletest for for all Condition Rules
Existential Quantifier
The other special operator available is the existential quantifier. The meaning of the existential quantifier is that there exists at least one element of a collection for which a given condition evaluates
January 13, 2012
Rule Modeling Guide
Page 86
to true. This logic is implemented in the Rulesheet using the ->exists operator from our Operator Vocabulary. As in our last example, we can construct a Rulesheet to determine the rating value for a Security entity by evaluating a collection of associated SecInfo elements with the existential quantifier. In this new example, we will use volume rather than rank to determine the rating value for the security. The Rulesheet for this example is shown in Figure 85.
Figure 85 Rulesheet with Existential Quantifier (exists) Condition
In this Rulesheet, we see the Condition

secinfo -> exists(secinfo.volume > 1000)
Notice again the required use of an alias to represent the collection being examined. The exact meaning of the Condition in this example is that for the collection of SecInfo elements associated with a Security (again represented by the secinfo alias), determine if the expression in parentheses (secinfo.volume > 1000) holds true for at least one Secinfo element. Depending on the outcome of the exists evaluation, a value of either High Volume or Normal Volume will be assigned to the rating attribute of our Security object and the corresponding Rule Statement will be posted as a message to the user. Figure 86 shows a Ruletest constructed to test our exists Condition rules.
January 13, 2012
Rule Modeling Guide
Page 87
Figure 86 Ruletest for Testing exists Condition Rules
Once again, we evaluate a collection of 3 SecInfo elements associated with a single Security entity. Since the volume attribute value assigned in at least one of the SecInfo objects (secInfo[2]) is greater than 1000, we should expect that our exists Condition will evaluate to true and a rating value of High Volume will be assigned to our Security object when the Ruletest is run through Corticon Server. This outcome is confirmed in the Ruletest shown in Figure 87.
January 13, 2012
Rule Modeling Guide
Page 88
Figure 87 Ruletest for exists Condition Rules
Another Example Using the Existential Quantifier

Collection operators are powerful parts of the CRL in some cases they may be the only way to implement a particular business rule. For this reason, we provide another example. Business problem: An auto insurance company has a business process for handling auto claims. Part of this process involves determining a claims validity based on the information submitted on the claim form. For a claim to be classified as valid, both the driver and vehicle listed on the claim must be
January 13, 2012
Rule Modeling Guide
Page 89
covered by the policy referenced by the claim. Claims that are classified as invalid will be rejected, and will not be processed for payment. From this short description, we extract our primary business rule statement: 1. A claim is valid if the driver and vehicle involved in a claim are both listed on the policy against which the claim is submitted.
In order to implement our business rule, we propose the UML Class Diagram shown in Figure 88. Note the following aspects of the diagram: A Policy may cover one or more Drivers A Policy may cover one or more Vehicles A Policy may have zero or more Claims submitted against it The Claim entity has been denormalized to include driverName and vehicleVin. 13
Figure 88 UML Class Diagram
This model imports into Studio as the Vocabulary shown in Figure 89:
13 Alternatively, the Claim entity could have referenced Driver.name and Vehicle.vin (by adding associations between Claim and both Driver and Vehicle), respectively, but the denormalized structure is probably more representative of a real-world scenario.
January 13, 2012
Rule Modeling Guide
Page 90
Figure 89 Vocabulary
Model the following rules in Studio as shown in Figure 90: 1. For a claim to be valid, the drivers name and vehicle ID listed on the claim must also be listed on the claims policy. 2. If either the drivers name or vehicle ID on the claim is not listed on the policy, then the claim is not valid.
January 13, 2012
Rule Modeling Guide
Page 91
Figure 90 Rules Modeled in Studio
This appears very straightforward. But a problem arises when there are multiple drivers and/or vehicles listed on the policy in other words, when the policy contains a collection of drivers and/or vehicles. Our Vocabulary permits this scenario because of the cardinalities we assigned to the various associations. We demonstrate this problem with the Ruletest in Figure 91:
January 13, 2012
Rule Modeling Guide
Page 92
Figure 91 Ruletest
Notice in Figure 92 that there are 3 drivers and 3 vehicles listed on (associated with) a single policy. When we run this Ruletest, we see the results:
January 13, 2012
Rule Modeling Guide
Page 93
Figure 92 Ruletest
As we see from the Ruletest results, the way Studio evaluates rules involving comparisons of multiple collections means that the validClaim attribute may have inconsistent assignments sometimes true, sometimes false (as in this Ruletest). It can be seen from the table below that, given the Ruletest data, 4 of 5 possible combinations evaluate to false, while only one evaluates to true. This conflict arises because of the nature of the data evaluated, not the rule logic, so Studios Conflict Check 14 feature does not detect it.
Claim. driverName Joe Claim.policy .driver.name Joe Claim. vehicle Vin 123-ABC Claim.policy. vehicle.vin 123-ABC Rule 1 fires X Rule 2 fires Rule 3 fires validClaim True
14
The Conflict Checker is discussed in more detail in the Logical Analysis chapter of this manual
January 13, 2012
Rule Modeling Guide
Page 94
Joe Joe
Sue Mary 123-ABC 123-ABC 987-XYZ 456-JKL
X X X X
False False False False
Lets use the existential quantifier to rewrite these rules:
Figure 93 Rules Rewritten Using Existential Quantifier
This logic tests for the existence of matching drivers and vehicles within the two collections. If matches exist within both, then the validClaim attribute evaluates to true, otherwise validClaim is false. Lets use the same Ruletest data as before to test these new rules. The results are shown below:
January 13, 2012
Rule Modeling Guide
Page 95
Figure 94 Ruletest
Notice that only one rule has fired, and that validClaim has been assigned the value of true. This implementation achieves the desired result.
TEST YOURSELF:
Answers are provided in Appendix D. 78. Children of a Parent entity are also known as ____________ of a collection. 79. True or False. All collections must have a parent entity 80. True or False. Root-level entities may form a collection 81. True or False. A collection operator must operate on a collection alias. 82. List 3 Collection operators and describe what they do.
January 13, 2012
Rule Modeling Guide 83. Which reference contains usage details and examples for every collection operator?
84.
Page 96
Write a Rule Statement that is equivalent to the syntax Order.total = items.pricesum
85. In the syntax in question 84, which term is the collection alias? 86. If items is an alias representing the LineItem entities associated with an Order entity, then what would you expect the cardinality of this association to be? 87. Is Order.lineItem.pricesum an acceptable replacement for the syntax in Question 84? Why or why not? 88. If you are a Vocabulary designer and want to prevent rule authors from building rules with LineItem.order terms, what can you do to prevent it? 89. When collection operators are NOT used in a Rulesheet, aliases are (circle all that apply) Optional Mandatory Colorful Convenient
90. If a Nonconditional rule states LineItem.price = 100, and my Input Testsheet contains 7 LineItem entities, then a collection of data is processed by this rule. Is a collection alias required? Why or why not? 91. Which collection operator is known as the Universal Quantifier? 92. Which collection operator is known as the Existential Quantifier? For questions 93-95, refer to the following Vocabulary
January 13, 2012
Rule Modeling Guide
Page 97
93. Write expressions for each of the following phrases: a. If an actor has had more than 3 roles b. If a movie has not been released on DVD c. If a movie has at least one DVD with deleted scenes d. If a movie won at least one Golden Globe e. If the movie had more than 15 actors
January 13, 2012
Rule Modeling Guide f. If theres at least 100 copies available of a movie g. If theres less than 2 copies available of a movie h. If the DVD can be obtained from more than 1 supplier 94. Which entities could be grandchildren of Movie? 95. Which entites could be children of Role? 96. Describe the difference between ->forAll and ->exists operators. 97. Describe the difference between ->notEmpty and ->isEmpty operators. 98. Why are aliases required to represent collections?
Page 98
January 13, 2012
Rule Modeling Guide
Page 99
RULES CONTAINING CALCULATIONS & EQUATIONS

Rules that contain equations and calculations are really no different than any other type of rule. Calculation-containing rules may be expressed in any of the sections of the Rulesheet, examples of which will be described and discussed in this chapter.
TERMINOLOGY
First well introduce some terminology that will be used throughout this chapter. In the most basic expression
A = B
We define A to be the Left-hand Side (LHS) of the expression, and B to be the Right-hand Side (RHS). The equals sign is an Operator, and is included in the Operator Vocabulary in Studio. But even so simple an expression has its complications. For example, does this expression compare the value of A to B in order to take some action, or does it instead assign the value of B to A? In other words, is the equals operator performing a comparison or an assignment? This is a common problem in programming languages, and a common solution is to use two different operators to distinguish between the two meanings. For example the symbol == may signify a comparison operation, whereas := may signify an assignment. In Studio, such special syntax is unnecessary because the Rulesheet itself helps to clarify the logical intent of the rules. For example, typing A=B into a Rulesheets Condition row (and pressing Enter) automatically causes the Values set {T,F} to appear in the rule column cell drop-down lists. This indicates that the rule modeler has written a comparison expression, and Studio expects a value of true or false to result from the comparison. A=B, in other words, is treated as a test is A equal to B or isnt it? On the other hand, when A=B is entered into an Action or Nonconditional row (Actions rows in Column 0), it becomes an assignment. In an assignment, the RHS of the equation is evaluated and its value is assigned to the LHS of the equation. In this case, the value of B is simply assigned to A. As with other Actions, we have the ability to activate or deactivate this Action for any column in the decision table (numbered columns in the Rulesheet) simply by checking the box that automatically appears when the Actions cell is clicked. In the Rule Language Guide, the equals operator (=) is described separately in both its assignment and comparison contexts.
OPERATOR PRECEDENCE
Operator precedence, or the order in which Studio evaluates multiple operators in an equation, is defined by the table in Appendix B of the Rule Language Guide. This table specifies for example, that 2*3+4 evaluates to 10 and not 14 because the multiplication operator * has a higher precedence than the addition operator +. It is a good practice, however, to include clarifying parentheses even when Studio does not require it. This equation would be better expressed as (2*3)+4. Note the addition of parentheses here does not change the result. When expressed as 2*(3+4), however, the result becomes 14.
Rule Modeling Guide
Page 100
DATATYPE COMPATIBILITY AND CASTING

An important prerequisite of any comparison or assignment operation is data type compatibility. In other words, the data type of the equations LHS (the data type of A) must be compatible with whatever data type results from the evaluation of the equations RHS (the data type of B). For example, if both attributes A and B are Decimal types, then there will be no problem assigning the Decimal value of attribute B to attribute A. Similarly, a comparison between the LHS and RHS makes no real sense unless both refer to the same kinds of data. How does one compare lemon (a String) to July 4, 2004 (a Date)? Or false (a Boolean) to 247.82 (a Decimal)? In general 15, the data type of the LHS must match the data type of the RHS before a comparison or assignment can be made. Expressions that result in inappropriate data type comparison or assignment should turn red in Studio. In the examples that follow, well use the generic Vocabulary from the Rule Language Guide, since the generic attribute names indicate their data types:
Figure 95 Generic Vocabulary from the Rule Language Guide
15
The exception to this rule is the comparison or assignment of an Integer to a Decimal. A Decimal can safely contain the value of an Integer without using any special casting operations.
January 13, 2012
Rule Modeling Guide
Page 101
Figure 96 shows a set of Action rows that illustrate the importance of data type compatibility in assignment expressions:
Figure 96 - Datatype Mismatches in Assignment Expressions
Lets examine each of the Action rows to understand why each is valid or invalid. A this expression is valid because the data types of the LHS and RHS sides of the equation are compatible (theyre both Boolean). B this expression is invalid and turns red because the data types of the LHS and RHS sides of the equation are incompatible (the LHS resolves to a DateTime and the RHS resolves to a String). C this expression is invalid and turns red because the data types of the LHS and RHS sides of the equation are incompatible (the LHS resolves to a String and the RHS resolves to a DateTime). D this expression is valid because the data types of the LHS and RHS sides of the equation are compatible even though they are different! This is an example of the one exception to our general rule regarding data type compatibility: Decimals can safely hold Integer values. E this expression is invalid and turns red because the data types of the LHS and RHS sides of the equation are incompatible (the LHS resolves to a Boolean and the RHS resolves to a Decimal). Here, the tool tip provides essentially the same information. Note that the Problems window contains explanations for the red text shown in the Rulesheet.
January 13, 2012
Rule Modeling Guide Figure 97 shows a set of Conditional expressions that illustrate the importance of data type compatibility in comparisons:
Page 102
Figure 97 - Datatype Mismatches in Comparison Expressions
Lets examine each of these Conditional expressions to understand why each is valid or invalid: a This comparison expression is valid because the data types of the LHS and RHS sides of the equation are compatible (theyre both Strings). Note that Studio confirms the validity of the expression by recognizing it as a comparison and automatically entering the Values set {T,F} in the Values column. b This comparison expression is invalid because the data types of the LHS and RHS sides of the equation are incompatible (the LHS resolves to a String and the RHS resolves to a DateTime). Note that, in addition to the red text, Studio emphasizes the problem by not entering the Values set {T,F} in the Values column. c This comparison expression is invalid because the data types of the LHS and RHS sides of the equation are incompatible (the LHS resolves to a Boolean and the RHS resolves to a Decimal). d This comparison expression is valid because the data types of the LHS and RHS sides of the equation are compatible. This is another example of the one exception to our general rule regarding data type compatibility: Decimals may be safely compared to Integer values. e This comparison expression is valid because the data types of the LHS and RHS sides of the equation are compatible. Like example 4, this illustrates the one exception to our general rule regarding data type compatibility: Decimals may be safely compared to Integer values. Unlike an
January 13, 2012
Rule Modeling Guide
Page 103
assignment, however, whether the Integer and Decimal types occupy the LHS or RHS of a comparison is unimportant.
Datatype of an Expression
Its important to emphasize that the idea of a data type applies not only to specific attributes in the Vocabulary, but to entire expressions. Our examples above have been simple, and the data types of the LHS or the RHS of an equation simply correspond to the data types of those single attributes. But the data type to which an expression resolves may be a good deal more complicated.
Figure 98 - Examples of Expression Datatypes
Again, well examine each assignment to understand what is happening: A The RHS of this equation resolves to an Integer data type because the .dayOfWeek operator 16 extracts the day of the week from a DateTime value (in this case, the value held by attribute date1) and returns it as an Integer between 1 and 7. Since the LHS also has an Integer data type, the assignment operation is valid. B The RHS of this equation resolves to an Integer because the .size operator counts the number of characters in a String (in this case the String held by attribute string1) and returns this value as an Integer. Since the LHS also has an Integer data type, the assignment operation is valid. C The RHS of this equation resolves to a Boolean because the ->isEmpty collection operator examines a collection (in this case the collection of Entity2 children associated with parent Entity1, represented by collection alias e2) and returns true if the collection is empty (has no elements) or false if it isnt. Since the LHS also has a Boolean data type, the assignment operation is valid. D The RHS of this equation resolves to a Boolean because the ->exists collection operator examines a collection (in this case, e2 again) and returns true if the expression in parentheses is
16
The .dayOfWeek operator and others used in these examples are described fully in the Rule Language Guide
January 13, 2012
Rule Modeling Guide
Page 104
satisfied at least once, and false if it isnt. Since the LHS also has a Boolean data type, the assignment operation is valid. E the RHS of this equation resolves to an Integer because the ->sum collection operator adds up the values of all occurrences of an attribute (in this case, integer2) in a collection (in this case, e2 again). Since the LHS has a Decimal data type, the assignment operation is valid. This is the lone case where type casting occurs automatically.
Defeating the Parser

The part of Studio that checks for data type mismatches (along with all other syntactical problems) is the Parser. The Parser exists to ensure that whatever is expressed in a Rulesheet can be correctly translated and compiled into code executable by Studios Ruletest as well as by the Business Rules Server. Because this is a critical function, much effort has been put into the Parsers accuracy and efficiency. But rule modelers should understand that the Parser is not perfect, and cant anticipate all possible combinations of the rule language. It is still possible to slip one past the Parser. Here is an example:
Figure 99 LHS and RHS Resolve to Integers
In Figure 99 above, we see an assignment expression where both LHS and RHS return Integers under all circumstances. But making a minor change to the RHS throws this result into confusion:
Figure 100 - Will the RHS Still Resolve to an Integer?
The minor change of adding a division step to the RHS expression has a major effect on the data type of the RHS. Prior to modification, the RHS always returns an Integer, but an odd Integer! When we divide an odd Integer by 2, a Decimal always results. The Parser is smart, but not smart enough to catch this problem.
January 13, 2012
Rule Modeling Guide
Page 105
When the rule is executed, what happens? How does the Server react when the rule instructs it to force a Decimal value into an attribute of type Integer? The Server responds by truncating the Decimal value. For example if integer2 has the value of 2, then the RHS returns the Decimal value of 2.5. This value is truncated to 2 and then assigned to integer1 in the LHS. When we focus on this rule here, alone and isolated, its relatively easy to see the problem. But in a complex Rulesheet, it may be difficult to uncover this sort of problem. Your only clue to its existence may be numerical test results that dont match the expected values. To be safe, its usually a good idea to ensure the LHS of numeric calculations has a Decimal data type so no data is inadvertently lost through truncation.
Manipulating Datatypes with Casting Operators

A special set of operators is provided in the Studios Operator Vocabulary that allows the rule modeler to control the data types of attributes and expressions. These casting operators are described below:
Casting Operator .toInteger .toDecimal .toString .toDateTime .toDate .toTime Applies to data of type Decimal, String Integer, String Integer, Decimal, DateTime, Date, Time String, Date, Time DateTime DateTime
Figure 101 Special Casting Operators
Produces data of type Integer Decimal String DateTime Date Time
Returning to Figure 97, we use these casting operators to correct some of the previous problems:
Figure 102 - Using Casting Operators
January 13, 2012
Rule Modeling Guide
Page 106
Casting operators have been used in Nonconditional rules N.2 and N.3 to make the data types of the LHS and RHS match. Notice however, that no casting operator exists to cast a Decimal into a Boolean data type.
SUPPORTED USES OF CALCULATION EXPRESSIONS

To make our examples more interesting and allow for a bit more complexity in our rules, we have extended the basic Tutorial Vocabulary (Cargo.ecore) to include a few more attributes. The extended Vocabulary is shown below:
Figure 103 Basic Tutorial Vocabulary Extended
The new attributes are described in the table below:

Attribute Aircraft.emptyWeight Aircraft.grossWeight Aircraft.maxfuel Cargo.footprint Data type Decimal Decimal Decimal Decimal Description The weight of an Aircraft with no fuel or cargo onboard. The maximum amount of weight an Aircraft can safely lift, equal to the sum of cargo and fuel weights. The maximum amount of fuel an Aircraft can carry. The floor space, measured in square feet, taken up by
January 13, 2012
Rule Modeling Guide

this Cargo. FlightPlan.approved FlightPlan.planWeight FlightPlan.flightRange FlightPlan.fuel Boolean Decimal Decimal Decimal
Page 107
Indicates whether the FlightPlan has been approved or cleared for operation. The total amount of all Aircraft and Cargo weights for this FlightPlan. The distance the Aircraft is expected to fly. The amount of fuel actually loaded on the Aircraft assigned to this FlightPlan.
Figure 104 - Table of New Attributes Added to the Basic Tutorial Vocabulary
Calculation as a Comparison in a Precondition
Figure 105 A Calculation in a Preconditional Expression
In Figure 105 above, a numeric calculation is used as a comparison in the Filters section of the Rulesheet. The LHS of the expression essentially calculates the average pressure exerted by the total cargo load on the floor of the aircraft (sum of the cargo weights divided by the sum of the cargo containers footprints). This result is compared to the RHS, which is simply the literal value 5. We might expect to see this type of calculation in a set of rules that deals with special cargos where a lot of weight is concentrated in a small area. This might, for example, require the use of special aircraft with sturdy, reinforced cargo bay floors. Such a Filter expression might be the first step in handling cargos that satisfy this special criterion.
January 13, 2012
Rule Modeling Guide
Page 108
Calculation as an Assignment in a Noncondition
Figure 106 A Calculation in a Nonconditional Expression
The example shown in Figure 106 uses a calculation in the RHS of the assignment to derive the total weight carried by an Aircraft on the FlightPlan, where the total weight equals the weight of the fuel plus the weight of all Cargos onboard plus the empty weight of the Aircraft itself. The portion
plan.fuel * 0.13368 * 50.4
converts a fuel load measured in gallons into a weight measured in pounds conversion factors of 0.13368 cubic feet per gallon and 50.4 pounds per cubic foot of jet fuel have been used here. This portion is then added to:
load.weight -> sum
which, of course, is equal to the sum of all Cargo weights loaded onto the Aircraft associated with this FlightPlan. The final sum of the fuel, cargo, and Aircraft weights is assigned to the FlightPlans planWeight. Note the parentheses used here are not required the calculation will produce the same result without them they have been added for improved clarity.
Calculation as a Comparison in a Condition

Once planWeight has been derived by the Nonconditional calculation in Figure 106, it may be used immediately elsewhere in this or subsequent 17 Rulesheets. An example of such usage appears in Figure 107 below:
Subsequent Rulesheets means Rulesheets executed later in a Ruleflow. The concept of a Ruleflow is addressed in the Studio Quick Reference Guide.
17
January 13, 2012
Rule Modeling Guide
Page 109
Figure 107 planWeight Derived and Used in Same Rulesheet
In Condition row a, planWeight is compared to the aircrafts grossWeight to make sure the aircraft is not overloaded. An overloaded aircraft must not be allowed to fly, so the approved attribute is assigned a value of false. This has the advantage of being both clear and easy to reuse the term planWeight, once derived, may be used anywhere to represent the data produced by the calculation. It is also much simpler and cleaner to use a single attribute in a rule expression than it is a long, complicated equation. But this does not mean that the equation cant be modeled in a Conditional expression, if desired. The example shown in Figure 108 places the calculation in the LHS of the Conditional comparison to derive planWeight and compare it to grossWeight all in the same expression.
Figure 108 A Calculation in a Conditional Expression
This approach might be preferable if the results of the calculation were not expected to be reused, or if adding an attribute like planWeight to the Vocabulary were not desirable or possible. Often, attributes like planWeight are very convenient intermediaries or holders to carry calculated values that will be used in other rules in a Rulesheet. In cases where such attributes are conveniences only, and are not used by external applications consuming a Rulesheet, they may be designated as
January 13, 2012
Rule Modeling Guide
Page 110
extended transient attributes in the Vocabulary, which causes their icons to change from blue/yellow to orange/yellow. More details on extended transient attributes are included in Appendix B of this manual.
Calculation as an Assignment in an Action
Figure 109 A Calculation in an Action Expression
Figure 109, above, shows two rules that each make an assignment to maxFuel, depending on the type of aircraft. In rule 1, the maxFuel load for 747s is derived by subtracting maxCargoWeight and emptyWeight from grossWeight. In rule 2, maxFuel for DC-10s is simply assigned the literal value 100,000.
UNSUPPORTED USES OF CALCULATION EXPRESSIONS

Calculations in Value Sets and Column Cells
The Conditional expression shown below is not supported by Studio, even though it doesnt turn red. Some simpler equations may actually work correctly when inserted in the Values cell or a rule column cell, but its a dangerous habit to get into because more complex equations generally dont work. Its best to express equations as shown in the previous sections.
Figure 110 Calculation in a Values Cell and Column
January 13, 2012
Rule Modeling Guide
Page 111
Calculations in Rule Statements

While it is possible to embed attributes from the Vocabulary inside Rule Statements, it is not possible to embed equations or calculations in them. Operators and equation syntax not enclosed in curly brackets {..} are treated like all other characters in the Rule Statement nothing will be calculated. If the Rule Statement shown in Figure 111 below is posted by an Action in rule 1, the message will be displayed exactly as shown; it will not calculate a result of any kind.
Figure 111 Calculation in a Rule Statement
Likewise, including equation syntax within curly brackets along with other Vocabulary terms is also not permitted. Doing so may cause your text to turn red, as shown in the following:
Figure 112 Embedding a Calculation in a Rule Statement
However, even if the syntax does not turn red, you should still not attempt to perform calculations in Rule Statements it may cause unexpected behavior. When red, the tool tip should give you some guidance as to why the text is invalid. In this case, the exponent operator (**) is not allowed in an embedded expression.
TEST YOURSELF:
Answers are provided in Appendix D. 99. What are the two possible meanings of the equals operator =? In which sections of the Rulesheet is each of these meanings applicable? 100. What is the result of each of the following equations? a. 10 + 20 / 5 4 b. 2 * 4 + 5 c. 10 / 2 * 6 8 d. 2 ** 3 * (1 + 2)
January 13, 2012
Rule Modeling Guide e. -5 * 2 + 5 * 2 101. Is the following assignment expression valid? Why or why not? Entity1.integer1 = Entity1.decimal1
Page 112
102. What is the data type of each of the following expressions based on the scope shown below?
a. e1.dateTime1.year b. e1.string1.toUpper c. e2 -> forAll (integer1 = 10) d. e2.decimal1 -> avg e. e1.boolean1 f. e1.decimal1 > e1.decimal2 g. e2.string2.contains(abc) 103. Write valid or invalid for each of the following assignments a. e1.decimal1 = e2.integer1 b. e2.decimal2 = e2.string2 c. e1.integer1 = e2.dateTime1.day d. e2.integer1 = e2 -> size e. e1.boolean2 = e2 -> exists (string1 = abc) f. e2.boolean2 = e1.string1.toBoolean g. e1.boolean2 = e2 -> isEmpty 104. The part of Studio that checks for syntactical problems is called the __________.
January 13, 2012
Rule Modeling Guide 105. True or False. If an expression typed in Studio does not turn red, then the expression is guaranteed to work as expected. Referring to the following illustration, answer questions 106 through 108:
Page 113
106. What does Filters row 1 test? 107. What does Conditions row a test? Is there a simpler way to accomplish this same thing using a different operator available in the Corticon Rule Language? 108. Write a Rule Statement for rule column 1. (Assume that the only action required for this rule is to post a Warning message as shown.) 109. True or False. The following sections of the Rulesheet accept equations and calculations: a. Scope b. Rule Statements c. Condition rows d. Action rows e. Column 0 f. Condition cells g. Action cells h. Filters
January 13, 2012
Rule Modeling Guide
Page 114
RULE DEPENDENCY: CHAINING AND LOOPING

WHAT IS RULE DEPENDENCY?
Dependencies between rules exist when a Conditional expression of one rule evaluates data produced by the Action of another rule. The second rule is said to be dependent upon the first.
FORWARD CHAINING
The first step in learning to use looping is to understand how it differs from normal inferencing behavior of executing rules, whether executed by Corticon Studio or Server. When a Rulesheet is compiled (either by Studio during a Ruletest execution, or by Server during deployment), a dependency network for the rules is automatically generated. Corticon Studio and Server uses this network to determine the order in which rules fire in runtime. For example, in the simple rules below, the proper dependency network is 1 2 3 4. 1. If value = A, then set value = B 2. If value = B, then set value = C 3. If value = C, then set value = D 4. If value = D, then set value = B This is not to say that all three rules will always fire for a given test clearly a test with B as the initial value will only cause rules 2, 3, and 4 to fire. But the dependency network ensures that rule 1 is always evaluated before rule 2, and rule 2 is always evaluated before rule 3, and so on. This mode of Rulesheet execution is called Optimized Inferencing, meaning the rules execute in the optimal sequence determined by the dependency network generated by the compiler. Optimized Inferencing is the default mode of rule processing for all Rulesheets. Optimized Inferencing processing is a powerful capability that enables the rule modeler to break up complex logic into a series of smaller, less complex rules. Once broken up into smaller or simpler rules, the logic will be executed in the proper sequence automatically, based on the dependencies determined by the compiler. An important characteristic of Optimized Inferencing processing: the flow of rule execution is singlepass, meaning a rule in the sequence is evaluated once and never revisited, even if the data values (or data state) evaluated by its Conditions change over the course of rule execution. In our example above, this effectively means that rule execution ceases after rule 4. Even if rule 4 fires (with resulting value = B), the second rule will not be revisited, re-evaluated, or re-fired even though its Condition (If value = B) would be satisfied by the current value (state). We can force rule 2 to be re-evaluated only if a one of Studios looping processing modes is enabled for the Rulesheet. Remember, just because sequential processing occurs automatically does not mean looping will occur too. Looping and its enablement are discussed next.
January 13, 2012
Rule Modeling Guide
Page 115
RULESHEET PROCESSING: MODES OF LOOPING

Occasionally, we want rules to be re-evaluated and re-fired (if satisfied). This scenario requires the Corticon rule engine to make multiple passes through the same Rulesheet. We call this behavior advanced inferencing, and to enable it in Rulesheet execution, we must set Rulesheet processing mode to Advanced Inferencing by selecting Rulesheet > Processing Mode > Advanced Inferencing from the Studio menubar, as shown in Figure 113.
Figure 113 Selecting Advanced Inferencing Processing Mode for a Rulesheet
Also note the circular icon to the immediate left of the Conditions header (see orange arrow). If the rule engine is permitted to loop through the rules above, the following events occur: Given a value of A as the initial data, the Condition in rule 1 will be satisfied and the rule will fire, setting the value to B. The 2nd rules Condition is then satisfied, so the value will advance (or be reset) to C, and so on, until the value is once again B after the 4th rule fires. Up to this point, the rule engine is exhibiting standard, Optimized Inferencing behavior. Now heres the new part: the value (state) has changed since the 2nd rule last fired, so the rule engine will re-evaluate the Condition, and, finding it satisfied, will fire the 2nd rule again, advancing the value to C. The 3rd rule will also be re-evaluated and re-fired, advancing the value to D, and so on. This sequence is illustrated in Figure 114. Heres the key to understanding looping: when a looping processing mode is enabled, rules will be continually re-evaluated and re-fired in a sequence determined by their dependency network as long as data state has changed since their last firing. Once data state no longer changes, looping will cease. Notice that the last column of the table indicates the number of loop iterations the first loop does not begin until rule 2 fires for the second time. The first time through the rules (steps 1-4) does not count as the first loop iteration because the loop does not actually start until step 5.
step # 1
Input value A
Rule fired 1
Output value B
Loop Iteration
January 13, 2012
Rule Modeling Guide 2 3 4 5 6 7 8 9 10 B C D B C D B C D 2 3 4 2 3 4 2 3 4 C D B C D B C D B
Page 116
Figure 114 Loop Iterations
Types of Loops
Infinite Loops In the example above, looping between rules 2, 3 and 4 continues indefinitely because there is nothing to stop the cycle. Some loops, especially those inadvertently introduced, are not self-terminating. Because these loops will not end by themselves, they are called infinite loops. Infinite loops can be especially vexing to a rule modeler because it isnt always apparent when a Rulesheet has entered one. A good indication, however, is that rule execution takes longer than expected to complete! A special control is provided to prevent infinite loops. This control is described in the Terminating Infinite Loops section, below. Trivial Loops Single-rule loops, or loops caused by rules that depend logically on themselves, are also known as trivial loops. We consider single-rule loops to be a special kind of loop because they consist of just a single rule that successively revisits, or triggers, itself. To enable the self-triggering mode of looping, we must select Rulesheet > Processing Modes > Advanced Inferencing with Self-Triggering from Studios menubar, as shown in
Figure 115 Selecting Advanced Inferencing with Self-Triggering Processing Mode for a Rulesheet
January 13, 2012
Rule Modeling Guide
Page 117
Notice the the icon to the left of the Conditions header - it contains the additional tiny arrow, which indicates self-triggering is active. Heres an example of a loop created by a self-triggering rule:
Figure 116 Example of an Infinite Single-Rule Loop
Lets trace this rule to make sure we understand how it works. When Cargo.weight has a value equal to or greater than 0, then rule 1 fires and the value of Cargo.weight is incremented by 1. Data state has now changed, in other words, the value of at least one of the attibutes has changed. In this case, its the value of Cargo.weight which has changed. Because it was rule 1 execution that caused the data state change, and since self-triggering is enabled, the same rule 1 will be re-evaluated. Now, if the value of Cargo.weight satisfied the rule initially, it certainly will do so again, so the rule fires again, and self-triggers again. And so on, and so on. This is also an example of an infinite loop, because no logic exists in this rule to prevent it from continuing to loop and fire. An Exception to Self-Triggering Self-triggering logic can also be modeled in Column 0 of the Rulesheet, as shown in Figure 117:
Figure 117 Example of an Infinite Loop created by a Self-Triggering Rule
But Figure 117 is also a good example of why it might be desirable to disable self-triggering processing: we only want the weight to increment once, not enter into an infinite loop, which it would otherwise do, unconditionally! This is a special case where we have intentionally prevented this rule from iterating, even though self-triggering is enabled. This rule will execute only once, regardless of looping processing mode.
Rule Modeling Guide
Page 118
Another example of a loop caused by self-triggering rule, but one which is not infinite, is shown below. The behavior described only occurs when Rulesheet processing mode is set to Advanced Inferencing with Self-Triggers:
Figure 118 Example of a Finite Single-Rule Loop
In Figure 118 above, the rule continues to fire until Cargo.weight reaches a value of 21, whereupon it fails to satisfy the Condition, and firing ceases. The loop terminates with Cargo.weight containing a final value of 21. Its important to note that in all three examples, an initial Cargo.weight value of 0 or higher was necessary to activate the loop. A negative (or null) value, for example, would not have satisfied the rules Condition and the loop would not have begun at all. Multi-rule Loops As the name suggests, multi-rule loops exist when 2 or more rules are mutually dependent. As with single-rule loops, the Rulesheet containing the looping rules must be configured to process them. This is accomplished as before. Choose Rulesheet > Processing Mode > Advanced Inferencing from the Studio menubar, as shown previously in Figure 113. Heres an example of a multi-rule logical loop:
January 13, 2012
Rule Modeling Guide
Page 119
Figure 119 Example of a Finite Multi-Rule Loop
In Figure 119, rule 2 is dependent upon rule 1, and rule 1 is dependent upon rule 2. Weve also added a rule 3, which doesnt participate in the 12 loop, but will generate a nice Violation message when the 12 loop finally terminates. Note, rule 3 does not cause the 12 loop to terminate, it just announces that the loop has terminated. Lets test these rules and see how they behave. In Figure 120, we see a simple Ruletest.
Figure 120 Ruletest for the Multi-rule Rulesheet
Were providing a starting value of Cargo.weight just to get the loop going. According to the Condition in rule 1, this value needs to be between 1 and 10 (inclusive).
January 13, 2012
Rule Modeling Guide
Page 120
Figure 121 Ruletest for the Multi-rule Rulesheet
When intentionally building looping rules, it is often helpful to post messages with embedded attribute values (as shown in the Rule Statements section of Figure 119) so we can trace the loops operation and verify it is behaving as expected. It should be clear to the reader that the Ruletest shown in Figure 121 contains the expected results.
LOOPING CONTROLS IN STUDIO

To handle the various aspects of rule looping, Studio provides several mechanisms for identifying and controlling looping behavior. Although weve only shown simple examples so far, looping rules can get much more complicated. Sometimes, rules have mutual dependencies by accident we didnt intend to include loops when we built the Rulesheet. Its for this reason that all loop processing is disabled by default (in other words,
January 13, 2012
Rule Modeling Guide
Page 121
the default Rulesheet processing mode is Optimized Inferencing, which does not permit revisiting rules that have already been evaluated once). We must manually enable the loop processing mode of our choice to cause the loops to execute. This is the strongest, most fool-proof mechanism for preventing unexpected looping behavior simply keep loop processing disabled.
Identifying Loops
Assuming we havent intentionally incorporated looping logic in our Rulesheet, then we need a way to discover if unintentional loops occur in our rules. The Loop Detection Tool To help identify inadvertent loops, Studio provides a Check for Logical Loops tool in the Studio toolbar. The tool contains a powerful algorithm that analyzes dependencies between rules on the same Rulesheet, and reports discovered loops to the rule modeler. For the Loop Detector to notice mutual dependencies, a Rulesheet must have looping enabled using one of the choices described earlier. Clicking the Check for Logical Loops icon displays a window that describes the mutual dependencies found on the Rulesheet. To illustrate loop detection, well use a few of the same examples from before.
Figure 122 Example of an Infinite Single-Rule Loop
When applied to a Rulesheet containing just the single-rule loop shown in Figure 122, the Check for Logical Loops tool displays the following window:
January 13, 2012
Rule Modeling Guide

Figure 123 Checking for Logical Loops in a Rulesheet
Page 122
Figure 124 A Single-Rule Loop Detected by the Check for Logical Loops Tool
The Check for Logical Loops tool first lists rules where mutual dependencies exist. Then, it lists the distinct, independent loops in which those rules participate, and finally it lists where self-triggering rules exist (if any). In this simple single-rule loop example, only one rule contains a mutual dependency, and only one loop exists in the Rulesheet. Note that the Check for Logical Loops tool does not automatically fix anything, it simply points out to us that our rules have loops, and gives us an opportunity to remove or modify the offending logic. Removing Loops If the Check for Logical Loops tool detects loops, we can take one of several corrective actions: If no loops are desirable, then click Rulesheet > Processing Mode and de-select whichever of the two looping options is currently selected. Once done, the Check for Logical Loops tool will no longer detect loops and the software will no longer process them. If all loops are desirable, then take measures to ensure that none of the loops are or become infinite. Normally, this means adding conditional logic to one of the looping rules to make sure that the rule cant be satisfied indefinitely. This is similar to the bounding of Condition 1 in Figure 119 using a Values set of 0..20. Once Cargo.weight reaches 21, the rules Condition will no longer be satisfied and the loop will terminate.
January 13, 2012
Rule Modeling Guide
Page 123
If some loops are desirable and some are not, then remove the inter-dependencies in the unwanted loops and ensure the desired loops are not infinite.
Terminating Infinite Loops By definition, infinite loops wont terminate by themselves. Therefore, Corticon provides a safety valve setting described in the Server Integration & Deployment Guide, Appendix E. com.corticon.reactor.rulebuilder.maxloop is a property that caps the number of iterations allowed before the system automatically terminates a loop. The default setting is 100, meaning that a loop is allowed to iterate up to 100 times normally. Once the number of loops exceeds the maxloop setting, then the system automatically terminates the loop and generates a Violation error message. This means that the final number of loop iterations will be 101: 100 normal iterations plus the final iteration that causes the Violation message to appear and the loop to terminate. The Violation message is shown below:
Figure 125 Maxloop Exceeded Violation Message
If you are comfortable writing looping rules, and want the software to be able to loop more than 100 times, be sure to reset this property to a higher value. Keep in mind that the more iterations the system performs, the longer rule execution may take. If the Rulesheets you intend to deploy require high iteration counts, be sure to inform your deployment manager so he/she can configure the target Corticon Server with a higher maxloop cap.
LOOPING EXAMPLE
Problem
For any given day of the week, determine the next working day. Take into consideration weekends and holidays.
Solution
Implemented correctly in Studio, these rules should start with a given input date, and increment as necessary until the next workday is identified (workday defined here as any day not Saturday, Sunday, or a national holiday). A simple Vocabulary that supports these rules is shown in Figure 118.
January 13, 2012
Rule Modeling Guide
Page 124
Figure 126 Sample Vocabulary for Holiday Rules
Next, the rules are implemented in the Rulesheet shown in Figure 127.
Figure 127 Sample Rulesheet for Determining Next Workday
Lets step through this Rulesheet. 1. First, notice that the Scope section wasnt used. Were using a very simple Vocabulary with short entity names and no associations, so aliases arent necessary. Furthermore, none of our rules use collection operations, so aliases representing collections arent required either. 2. The first rule executed is the Nonconditional equation (in Condition/Action column 0) setting nextWorkDay equal to currentDate plus one day. 3. Rule 1 (in column 1) checks to see if the DateTime of the nextWorkDay matches any of the holidays defined in one or more Holiday entities. If it does, then the Action row B increments nextWorkDay by one day and posts a warning message.
January 13, 2012
Rule Modeling Guide
Page 125
4. Rule 3 checks to see if the nextWorkDay falls on a Sunday. Notice that this rule uses the .dayOfWeek operator, which is described in full detail in the Rule Language Guide. If the day of the week is Sunday (in other words, .dayOfWeek returns a value of 1), then the Action increments nextWorkDay by one day and posts a Warning message. 5. Rule 4 checks to see if the nextWorkDay falls on a Saturday. If the day of the week is Saturday (in other words, .dayOfWeek returns a value of 7), then the Action row C increments nextWorkDay by two days and posts a Warning message. By incrementing 2 days, we skip an extra iteration because we know Sunday is also a non-workday! Dont forget to check for conflicts they do exist in this Rulesheet. However, we will make the assumption that a holiday never falls on a weekend. Resolution of the conflicts is straightforward 18, so we wont address that in detail here. A modified Rulesheet displays the overrides added to resolve the conflicts in Figure 128.
Figure 128 Holiday Rules with Ambiguities Resolved by Overrides
Using the same rules as before, lets click the Logical Loop Checker following window appears:
icon in the Studio toolbar. The
18
One conflict that between rules 1 and 4 is left unresolved because we have assumed that a holiday never falls on a weekend. See Logical Analysis chapter more a complete discussion of conflict and other logical problems.
January 13, 2012
Rule Modeling Guide
Page 126
Figure 129 Results of Logical Loop Check
This window first identifies exactly which rules are involved in loops. Secondly, the window outlines the specific attribute interactions that create the loops. Now that we fully understand the looping logic present in our Rulesheet, lets create a Ruletest to verify that the loops operate as intended and produce the correct business results.
January 13, 2012
Rule Modeling Guide
Page 127
Figure 130 Ruletest for Holiday Rules
Given the fact that July 4th, 2003 falls on a Friday, we expect nextWorkDay to contain a final value of July 7th, 2003 a Monday when the loops terminate. Running the Ruletest:
Figure 131 Ruletest for Holiday Rules
As you can see in Figure 131, the expected result is obtained.
USING CONDITIONS AS A PROCESSING THRESHOLD

We want to distinguish looping, which involves revisiting, re-evaluating, and possible re-firing rules, and which requires you to enable one of the looping modes discussed above, from another behavior that may appear similar on the surface.
January 13, 2012
Rule Modeling Guide
Page 128
You have almost certainly noticed Corticons inherent ability to process multiple test scenarios at once. For example, a rule written using the Vocabulary term Cargo.weight will be evaluated (and potentially fired) for every instance of Cargo encountered during execution. If a Ruletest contains 4 Cargo entities, then the rule engine will test the rules conditions with each of them. If any of the Cargo entities satisfy the rules conditions, then the rule will fire. This could mean that the rule fires once, twice, or up to four times, depending on the actual data values of each Cargo. We know from our prior discussion of Scope that a rule will evaluate all data that shares the same scope as the rule itself. This iterative behavior is a natural part of the Corticon rule engine design theres nothing special we need to do to enable it or turn it on. Note, that this behavior is different from the modes of looping discussed above because the Cargo.weight rule is not re-evaluated for a given piece of data. Rule execution is still single-pass. Its just that it makes a single pass through each of the 4 Cargo entities. The advantage of this natural iteration is that we dont need to force it the rule engine will automatically process all data that shares the same scope as the rule. If the Ruletest contains 4 Cargos, the rule will be evaluated 4 times. If the Ruletest contains 4000 Cargos, the rule will be evaluated 4000 times. We dont write the rule any differently in Studio. But this advantage can also be a disadvantage. What if we want rule execution to stop part-way through its evaluation of a given set of entity data (which we call a binding). What if, after finding a Cargo that satisfies the rule among the set (binding) of Cargo entities, we want to stop evaluation mid-stream? In normal operation, this is not possible. Heres a simple example.
Figure 132 Rulesheet and Ruletest, no threshold condition, CaPT disabled
In the example in Figure 132, we see a simple rule that sets thing.selected = true for all thing.aSize = small. Notice in the adjacent Ruletest, that each small Thing is selected. Thing[2] and Thing[3] are both small, so they are both selected by the rule. The rule has evaluated all three Things, but finding only two that satisfy the rules condition, only fires twice. This iteration happened automatically. What if we wanted rule execution to stop after finding the first Thing that satisfies the rule? In other words, allow the rule engine to fire for Thing[2] but stop processing before firing for Thing[3]. Is that possible? You might think the following Rulesheet would accomplish this goal.
January 13, 2012
Rule Modeling Guide
Page 129
Figure 133 Rulesheet and Ruletest, threshold condition added, CaPT disabled
The example in Figure 133 includes two changes: 1) Thing.selected is defaulted to false in the Nonconditional rule (Action row A0). And 2) a second Condition row checks for Thing.selected = false as part of rule 1. This is called a threshold condition. You might be temped to think that when Thing[2] fires the rule, its value of selected (re-set to true) would be sufficient to stop further evaluation and execution of Thing[3]. But as we see in the adjacent Ruletest, that this isnt the case. The reason is that Thing[3] is an entirely separate entity within the binding, and is entitled to its own evaluation of rule 1 regardless of what happended with Thing[2]. The addition of the threshold condition accomplished nothing. A special feature in Studio, called Use Condition as Processing Threshold (abbreviated as CaPT), allows us to interrupt processing of the binding. You activate this option by selecting the rule column involved, then from the Studio menu bar, choose Rulesheet > Rule Columns(s) > Use Condition as Processing Threshold. Once selected, CaPT causes the rule column header to display in bold type, as shown below in Figure 134, circled in orange.
Figure 134 Rulesheet and Ruletest, threshold condition added, CaPT enabled
When CaPT is activated, it breaks out of the automatic binding iteration whenever an instance in the binding fails to satisfy the threshold condition. In this case, Thing[2], having just fired rule 1, no longer satisfies the threshold condition, and causes rule execution to stop before evaluating Thing[3]. If we re-ran this Ruletest, we might see Thing[3] evaluated first, in which case rule execution would stop before evaluating Thing[2]. Within a binding, sequence of evaluation of
Rule Modeling Guide
Page 130
elements is random and may change from execution to execution. There is nothing about the binding that enforces an order or sequence among the bound elements.
TEST YOURSELF:
Answers are provided in Appendix D. 110. What is the main difference between inferencing and looping? 111. A loop that does not end by itself is known as an __________ loop. 112. A loop that depends logically on itself is known as a single-rule or __________ loop. 113. True or False. The Check for Logical Loops tool in Studio will always find mutual dependencies in a Rulesheet if they are present. 114. True or False. The Check for Logical Loops tool in Studio can fix inadvertent loops. Referring to the following illustration, answer questions 115 through 117:
115. Given these two rules, is it necessary for the Rulesheet to use the Inferencing mode shown? Why or why not? 116. Is there any potential harm in having this Rulesheet configured to Advanced Inferencing with SelfTriggering? Why or why not?
January 13, 2012
Rule Modeling Guide
Page 131
117. If the Rulesheet as shown above were tested with a DVD having a price tier of High, quantity available of 150,000, and release date within the past 6 months, what would be the outcome of the test? 118. This icon indicates which type of inferencing is enabled for this Rulesheet?
119. This icon indicates which type of inferencing is enabled for this Rulesheet?
120. A ________________ determines the sequence of rule execution and is generated when a Rulesheet is _______________.
January 13, 2012
Rule Modeling Guide
Page 132
FILTERS & PRECONDITIONS

Conditional expressions modeled in the Filters section of a Rulesheet can behave in two different ways: as filters alone or as filters plus preconditions. Both behaviors are explained and illustrated in this chapter. Henceforth, we will refer to any conditional expression entered in the Filters window of a Rulesheet generically as a Filter, regardless of its strict mode of behavior. This will help us to differentiate the expression itself from its specific behaviors. This chapter uses the automotive insurance Vocabulary example first introduced in the Collections chapter.
WHAT IS A FILTER?
A Filter expression acts to limit or reduce the data in working memory to only that subset whose members satisfy the expression. A Filter does not permanently remove or delete any data; it simply excludes data from evaluation by other rules in the same Rulesheet. We often say that data satisfying a Filter expression survives the Filter. Data that does not survive the Filter is said to be filtered out. Data that has been filtered out is ignored by other rules in the same Rulesheet. A Filter expression, no matter what its full behavior, only affects data in its own Rulesheet Rulesheets are unaffected by Filter expressions in other Rulesheets. As an example, look at the Rulesheet sections shown in Figure 135 and Figure 136, below:
Figure 135 Alaises Declared
The Scope window in Figure 135 defines aliases for a root-level Policy entity, a collection of Driver entities related to that Policy, and a collection of Vehicle entities related to that Policy, named thePolicy, drivers, and cars, in that order. To start with, well write a simple Filter and observe its default behavior. In the simple scenario below, the Filter expression reduces the set of data acted upon by the Nonconditional rule (column 0), which in this case merely posts the Rule Statement as a message.
January 13, 2012
Rule Modeling Guide
Page 133
Figure 136 Rulesheet to Illustrate Basic Filter Behavior
Our result is not unexpected: for every element in the collection (every Driver) whose age attribute is greater than 16, we see a posted message in the Ruletest, as shown below:
Figure 137 Ruletest to test Filter Behavior
January 13, 2012
Rule Modeling Guide Because only Jacob and Lisa are older than 16, Rule Messages are posted only for them.
Page 134
Maximum Filters
By default, each Filter you write acts as a maximum filter. This means not only will the data not satisfying the Filter be filtered out of subsequent evaluations, but in cases where this data comprises a collection where no elements survive the Filter, the parent entity will also be filtered out! Heres an example of a maximum filter in action:
Figure 138 Rulesheet to Show Maximum Filter Behavior
And with different sample data in our Ruletest:
Figure 139 Ruletest for Maximum Filter
Notice two important things about this Ruletest: first, none of the Driver entities in the Input are older than 16, which means none of them survives the Filter. Second, because the parent Policy entity does not contain at least one Driver which satisfies the Filter, then the parent Policy itself
January 13, 2012
Rule Modeling Guide
Page 135
also fails to survive the Filter. If no Policy entity survives the Filter, then rule Column 0 has no data upon which to act, so no Policy is assigned a startDate equal to today. The Ruletests Output, shown in Figure 139, confirms the behavior. Why would we want a Filter to behave this way? The behavior of a maximum filter may seem too powerful to be very practical or useful. In reality, youll probably find that the maximum filter behavior is generally what you want when filtering your data. If other rules on the Rulesheet act or operate on Policy, then a maximum filter gives you a very easy way to specify and control which Policy entities are affected. Maximum filter is also the original 19 behavior of Filters (and of their Precondition/Filter counterparts in Corticon Studio 4 and earlier), so for backward compatibility purposes with older models written with these expectations, we have kept it this way as new versions of Corticon have been released over the years. We wouldnt want to change an important behavior like this and have older Rule Sets begin acting completely differently from their authors intents.
Minimum Filters
There are occasions, however, when the maximum behavior of a Filter is unwanted because its too strong. In these cases, we want to apply a Filter to the elements of a collection but still keep the parent entity even if none of its children survive the Filter. When would we want to do this? When we want to act on the parent independently in subsequent rules When we want to act on data in other collections associated with the same parent.
The first case is neatly illustrated by our previous example. What if we really wanted the Nonconditional rule column 0 to act on Policy regardless of the results of the filter on its Driver children? A maximum filter prevents this in those cases where none of the children survive the Filter, as shown in Figure 139. A minimum Filter ensures a parent always survives, even if none of its children do. To turn a Filter expression into a minimum Filter, right-click on the Filter row and select Minimum Filter from the popup window, as shown (cropped) in Figure 140:
Figure 140 Selecting Minimum Filter Option from the Right-Click Popup Menu
This causes the following:
19
in other words, this is how Preconditions worked in Corticon Studio 1.0.
January 13, 2012
Rule Modeling Guide The yellow funnel icon in the Filter window receives a small green circle symbol The yellow funnel icons in the Scope window receive small green circle symbols
Page 136
The Filter expression included under the parent entitys Scope node is shown in light gray text to indicate that the entity is no longer subject to the Filter. In other words, the entity cant be filtered out by a minimum Filter.
These 3 effects are illustrated below:
Figure 141 A Minimum Filter
Figure 142 Ruletest for Minimum Filter
January 13, 2012
Rule Modeling Guide
Page 137
From Figure 142 its clear that the minimum filter did not prevent the parent Policy entity from surviving and being acted upon by the Nonconditional rule column 0 even though none of its Driver children survived.
WHAT IS A PRECONDITION?
If youre comfortable with the minimum and maximum behaviors of a Filter expression, then its precondition behavior is even easier to understand. While reading this section, keep in mind that Filters always act as either minimum or maximum filters, but they can also act as preconditions if you enable that behavior as described in this section. If you think of filtering as a mandatory behavior but a precondition as an extra, optional behavior, then youll be in good shape later. Also, it may be helpful to think of the precondition behavior, if enabled, taking effect after the filtering step is complete. Precondition behavior of a Filter ensures that execution of a Rulesheet stops unless at least one piece of data survives the Filter. If execution of a Rulesheet stops because no data survived the Filter, then execution moves on to the next Rulesheet (in the case where the Rulesheet is part of a Ruleflow). If no more Rulesheets exist in the Ruleflow, then execution of the entire Ruleflow is complete. In effect, a Filter with precondition behavior enabled acts as a gatekeeper for the entire Rulesheet - if no data survived the Filter, then the Rulesheets gate stays closed and no additional rules on that Rulesheet will be evaluated or executed no matter what. If however, data survived the Filter, then the gate opens and the surviving data can be used in the evaluation and execution of other rules on the same Rulesheet. The precondition behavior of a Filter is significant because it allows us to control Rulesheet execution regardless of the scope used in the rules. Take for example the Rulesheet shown in Figure 143. The Filter in row 1 is acting in its standard default mode of maximum filter. This means that Driver entities in the collection named drivers and the collections parent entity Policy are both affected by this Filter. Only those elements of drivers older than 16 will survive, and at least one must survive for the parent Policy also to survive.
Figure 143 Input Rulesheet for Minimum Filter
But how does this affect the Claim in Nonconditional row A (of rule column 0)? Claim, as a root-level entity, is safely outside of the scope of our Filter, and therefore unaffected by it. Nothing the Filter
Rule Modeling Guide
Page 138
does (or doesnt do) has any effect on what happens in Action row A the two logical expressions are completely independent and unrelated. As a result, Claim.validClaim will always be false, even when none of the elements in drivers are older than 16. A quick Ruletest verifies this prediction:
Figure 144 Ruletest for an Action Unaffected by a Filter
But what if the business intent of our rule is to update Claim based on the evaluation of Policy and its collection of Drivers? What if the business intent requires that the Policy and Claim really be related in some way? How do we model this? Before true precondition behavior was introduced to Studio 20, our only practical option was to mandate an actual physical association between Policy and Claim, then incorporate that association into the scope of our Filter and rules. For example:
20
True precondition behavior was introduced in Studio 4.0 SR2
January 13, 2012
Rule Modeling Guide
Page 139
Figure 145 Rulesheet for Minimum Filter
Notice that Claim is no longer a root-level entity we have associated it with Policy and given the associated Claim an alias aClaim. Its the alias, not the root-level entity, thats used in Nonconditional row A. So, when no elements of drivers are older than 16, the maximum filter ensures the parent Policy entity does not survive. And since the Policy does not survive the filter, its associated Claim does not survive, either. Heres an example of this:
Figure 146 Ruletest for Minimum Filter
The net effect is that validClaim can only be false when one or more drivers is older than 16, which is what we want. But obtaining this result required us to monkey around with our data 21 to
21
And potentially our Vocabulary, data model, and database schema, too!
January 13, 2012
Rule Modeling Guide
Page 140
associate Claim with Policy. Sometimes we as rule modelers have this freedom and flexibility. Often, we do not. If we dont, then we need an alternative method for controlling the execution of subsequent rules without relying on unnatural or artificial data and/or data model manipulations. Heres where the precondition behavior is useful. Using the same example as in Figure 143, right-click on Filter row 1 and select Precondition.
Figure 147 Selecting Precondition Behavior from the Filter Right-Click Popup Menu
Note that the two options Precondition and Minimum Filter are mutually exclusive: turning one on turns the other off. A Filter cannot be both a Precondition AND a minimum Filter because at least one piece of data ALWAYS survives a minimum filter, so a Precondition would never stop execution. Selecting Precondition causes the following: The yellow funnel icon in the Filter window receives a small red circle symbol The yellow funnel icons in the Scope window receive small red circle symbols
Figure 148 shows a Filter in Precondition mode.
Figure 148 A Filter in Precondition Mode
January 13, 2012
Rule Modeling Guide
Page 141
As described before, the precondition behavior of the Filter will cause Rulesheet execution to stop whenever no data survives the Filter. So in the original case where Policy and Claim were unassociated, a Filter in precondition mode, as shown in Figure 149:
Figure 149 Rulesheet with a Filter in Precondition Mode
accomplishes our business intent without artificially changing our Vocabulary or underlying data model. A final proof is provided in Figure 150.
Figure 150 Ruletest for a Filter in Precondition Mode
January 13, 2012
Rule Modeling Guide
Page 142
Summary of Filter and Preconditions Behaviors

A Filter just reduces the available data for other rules in the Rulesheet to use. Filters produce shades of gray - all data, some data, or no data may result from a filter. A Filter in Precondition mode stops Rulesheet execution if no data survives the filter. Preconditions produce black and white results: either data survives the filter and the precondition allows Rulesheet execution to continue, or no data survives and the precondition forces Rulesheet execution to stop. Filter expressions always acts as a filter. By default, they act as filters only. If you also need true precondition behavior, then setting the Filter to Precondition mode will enable precondition behavior while keeping filter behavior.
Performance Implications of the Precondition Behavior

A rule fires whenever data sharing the rules scope exists that satisfies the rules conditions. In other words, to fire any rule, the rule engine must first collect the data that shares the rules scope, and then check if any of it satisfies the rules conditions. So even in a Rulesheet where no rules actually fire, the rule engine may have still needed to work hard to come to that conclusion. And hard work requires time, even for a high-performance rule engine like Corticons. A Filter expression acting only as a filter never stops Rulesheet execution; it simply limits the amount of data used in rule evaluations and firings. In other words, it reduces the set of data that is evaluated by the rule engine, but it doesnt actually stop the rule engines evaluation of remaining rules. Even if a filter successfully filters out all data from a given data set, the rule engine will still evaluate this empty set of data against the available remaining rules. Of course, no rules will fire, but the evaluation process still occurs and still takes time. Filter expressions also acting as preconditions change this. Now, if no data survives the filter (remember, Filter expressions always act as filters even when also acting as preconditions) then Rulesheet execution stops in its tracks. No additional evaluations are performed by the rule engine. That Rulesheet is done and the rule engine begins working on the next Rulesheet. This can save time and improve engine performance when the Rulesheet contains many additional rules that would have been at least evaluated were the expression in filter-only mode (the default mode).
USING COLLECTION OPERATORS IN A FILTER

In the following examples, all Filter expressions use their default Filter-only behavior. As we have already discussed in the Rule Writing Techniques chapter, the logic expressed by the following 3 Rulesheets is identical in result:
January 13, 2012
Rule Modeling Guide
Page 143
Figure 151 A Condition/Action rule column with 2 Conditional rows
Figure 152 Rulesheet with one Condition row moved to Filters row
January 13, 2012
Rule Modeling Guide

Figure 153 Rulesheet with Filter and Condition rows swapped
Page 144
Even though expressions in the Filters section of the Rulesheet are evaluated before Conditions, the results are the same. This holds true for all rule expressions that do not involve collection operations (and therefore do not need to use aliases we have used aliases in this example purely for convenience and brevity of expression): conditional statements, whether they are located in the Filters or Conditions sections, are ANDed together. Order doesnt matter. In other words, to use the logic from the preceding example:
If person.age > 40 AND person.skydiver = true, then person.riskRating = high
Because it doesnt matter which conditional statement is executed first, we could have written the same logic as:
If person.skydiver = true AND person.age > 40, then person.riskRating = high
This independence of order is similar to the commutative property of multiplication: 4 x 5 = 20 and 5 x 4 = 20. Aliases work perfectly well in a declarative language (like Studios) because regardless of the order of processing, the outcome is always the same.
Location Matters
Unfortunately, order independence does not apply to conditional expressions that include collection operations. In the following Rulesheets, notice that one of the conditional expressions uses the collection operator size, and therefore must use an alias to represent the collection Person.
Figure 154 Collection Operator in Condition row
January 13, 2012
Rule Modeling Guide
Page 145
Figure 155 Collection Operator in Filter row
The Rulesheets appear identical with the exception of the location of the two conditional statements. But do they produce identical results? Lets test the Rulesheets to see, testing Figure 154 first:
Figure 156 Ruletest with 3 Skydivers
What happened here? Because Filters are always applied first, our Rulesheet initially screened or filtered out the elements of collection person whose skydiver value was false. Think of the Filter as allowing only skydivers to pass through to the rest of the Rulesheet. The Conditional rule then checks to see if the number of elements in collection person is more than 3. If it is, then ALL person elements in the collection that pass through the filter (in other words, all skydivers) receive a riskRating value of high. Because our first Ruletest included only 3 skydivers, the collection fails the Conditional rule, and no value is assigned to riskRating for any of the elements, skydiver or not. Lets modify the Ruletest and rerun the rules:
January 13, 2012
Rule Modeling Guide
Page 146
Its clear from this run that our rules fired correctly, and assigned a riskRating of high to all skydivers for a collection containing more than 3 skydivers. Now lets test the Rulesheet in Figure 155, where the rule containing the collection operation is in the Filters section.
What happened this time? Because Filters apply first, the size operator counted the number of elements in our person collection, regardless of who skydives and who doesnt. Here, the Filter allows any collection and the whole collection of more than 3 persons to pass through to the Conditions section of the Rulesheet. Then, the Conditional rule checks to see if any of the elements in collection person skydive. Each person who skydives receives a riskRating value of high. Even though our Ruletest included only 3 skydivers, the collection contains 4 persons and therefore passes the Preconditional filter. Any skydiver in the collection then has its riskRating assigned a value of high.
January 13, 2012
Rule Modeling Guide
Page 147
Its important to point out that the Rulesheets in Figure 154 and Figure 155 really implement two different business rules. When we built our Rulesheets, we neglected to write the plain-language business rule statements (violating our methodology!). The rule statements for these two Rulesheets would look like this:
The difference here is subtle but important. In the first rule statement, we are testing for skydivers within groups that contain more than 3 skydivers. In the second, we are testing for skydivers within groups of more than 3 people.
MULTIPLE FILTERS ON COLLECTIONS

Lets construct a slightly more complicated example by adding a third conditional expression to our rule.
Figure 159 Rulesheet with 2 Conditions
Figure 160 Rulesheet with 2 Filters
Once again, our Rulesheets differ only in the location of a Conditional expression. In Figure 159, the gender test is modeled in the second Conditional row, whereas in Figure 160, its implemented in the second Filter row. Does this difference have an impact on rule execution? Lets build a Ruletest and use it to test the Rulesheet in Figure 159 first.
January 13, 2012
Rule Modeling Guide
Page 148
Figure 161 Ruletest
As we see in Figure 161, the combination of a Condition that uses a collection operator (the size test) with another Condition that doesnt (the gender test) produces an interesting result. What appears to have happened is that, for a collection of more than 3 skydivers, all females in that group have been assigned a riskRating of high. Step-by-step, here is what the Server did: 1. The Filter screened the collection of Persons (represented by the alias person) for
skydivers.
2. If there are more than 3 surviving elements in person (i.e., skydivers), then all females in the filtered collection are assigned a riskRating value of high. It may be helpful to think of the Server checking to make sure there are more than 3 surviving elements, then cycling through those whose gender is female, and assigning riskRating one element at a time. Expressed as a plain-language rule statement, our Rulesheet implements the following rule statement:
Its important to note that Conditions do not have the same filtering effect on collections that Filter expressions do, and the order of Conditions in a rule has no effect whatsoever on rule execution. Now that we understand the results in Figure 161, lets see what our second Rulesheet produces.
January 13, 2012
Rule Modeling Guide
Page 149
Figure 162 Ruletest
This time, no riskRating assignments were made to any element of collection person. Why? Because multiple Filters are logically ANDed together, forming a compound filter. In order to survive the compound filter, elements of collection person must be both skydivers AND female. Elements that survive this compound filter pass through to the size test in the Condition/Action rule, where they are counted. If there are more than 3 remaining, then all surviving elements are assigned a riskRating value of high. Rephrased, our Rulesheet implements the following rule statement:
Just to confirm we understand how the Server is executing this Rulesheet, lets modify our Ruletest and rerun:
January 13, 2012
Rule Modeling Guide
Page 150
Figure 163 Ruletest
Figure 163 now includes 4 female skydivers, so, if we understand our rules correctly, we expect all 4 to pass through the compound filter and then satisfy the size test in the Conditions. This should result in all 4 surviving elements receiving a riskRating of high. Figure 163 confirms our understanding is correct.
FILTERS THAT USE OR

Just as compound filters can be created by writing multiple Preconditions, filters can also be constructed using the special word or directly in the Rulesheet. See the Rule Language Guide for an example.
Collection Operations & Minimum Filters

When a collection contains a parent but no children, we call it an empty collection. But when a collection contains neither children nor parent, we call it a null collection. One special exception to the use of minimum filters exists for Filter expressions containing collection operations. You may notice that the minimum filter option is not available in the right-click popup menu for any Filter row containing a collection operation. The reason for this is a bit obscure, but if you are comfortable with the previous explanation of the difference between a null and an empty collection, then you will see that a Filter containing a collection operation either allows an entire collection to pass, or it doesnt. And if that filter were a minimum filter, the parent of the collection would still pass the filter even if the collection as a whole failed it. So how could we differentiate between a collection that a) passed the filter with no children (as in an empty collection) or b) failed it,
Rule Modeling Guide
Page 151
and would have passed no collection at all (a null collection) had it been subjected to a maximum filter? Studio resolves this potential point of confusion by making the minimum filter option unavailable for those filters that contain collection operations. This has the practical effect of ensuring that the parent of a collection that fails a Filter containing a collection operation will never sneak through and appear to the rule writer as an empty collection.
TEST YOURSELF:
Answers are provided in Appendix D. 121. True or False. All expressions modeled in the Filters section of the Rulesheet behave as filters. 122. True or False. All expressions modeled in the Filters section of the Rulesheet behave as preconditions. 123. True or False. Some rules may be unaffected by Filters expressions on the same Rulesheet. 124. When 2 conditional expressions are expressed as 2 Filter rows, they are logically ______ together. ored anded replaced duplicated
125. True or False. A Filter row is a stand-alone rule that can be assigned its own Rule Statement 126. A null collection is a collection that: a. has a parent but no children b. has children but no parent c. has no parent and no children d. has a parent and children 127. An empty collection is a collection that: a. has a parent but no children b. has children but no parent c. has no parent and no children d. has a parent and children 128. A Filter expression is equivalent to a Conditional expression as long as it includes ______ collection operators in the expression. some all no at least one
129. True or False. To join two Filters with an or operator, you must use the word or in between expressions.
January 13, 2012
Rule Modeling Guide 130. By default, all Filter expressions are ______________ filters minimum coffee maximum extreme
Page 152
131. The Filter expression shown below has which behavior(s)?
minimum filter
maximum filter
precondition noncondition
minimum filter
maximum filter
minimum filter
maximum filter
134. What happens when a Filter expression, acting as a precondition, is not satisfied? a. The expression is ignored and Rulesheet execution continues b. The Rulesheet is re-executed from the beginning c. The last Rulesheet is executed d. The next Rulesheet is executed e. All Rulesheet execution stops f. Execution of that Rulesheet stops 135. Which Filters behaviors may be active at the same time? a. Maximum filter and precondition b. Minimum filter and precondition c. Minimum and maximum filter d. Precondition may only act alone
January 13, 2012
Rule Modeling Guide
Page 153
For the sample data shown below, determine which data survives the Filter for each question. Enter the entity number (the number in square brackets) for each survivor in the appropriate column. Assume the collection Movie has alias movies, Movie.dVD has alias dvds, and Movie.oscar has alias oscars. Maximum filters are shown in regular type and minimum filters are shown in bold type. None behave as Preconditions.
Precondition/Filter Expressions example: movies.studio = RKO 136. dvds.priceTier = High 137. oscars -> size > 4 138. oscars.win = T 139. oscars.nomination 140. oscars.win or oscars.category = Best Actor 141. oscars.win and oscars.category = Best Actor 142. dvds.quantityAvailable > 100 143. oscars -> exists(win = T) 144. movies.yearReleased.yearsBetween (today) > 50 145. dvds -> notEmpty 146. movies -> isEmpty 147. dvds.releaseDate > 1/1/2000 148. movies.genre <> Drama 149. oscars -> forAll(win = T) 150. oscars -> size > 2 Movie 1 DVD 1 Oscar 1,2,3,4,5
January 13, 2012
Rule Modeling Guide
Page 154
RECOGNIZING AND MODELING PARAMETERIZED RULES

PARAMETERIZED RULE WHERE A SPECIFIC ATTRIBUTE IS A VARIABLE (OR PARAMETER) WITHIN A GENERAL
BUSINESS RULE
During development, patterns may emerge in the way business rules define relationships between Vocabulary terms. For example, in our sample FlightPlan application, a recurring pattern might be that all aircraft have limits placed on their maximum takeoff weights. We might notice this pattern by examining specific business rules captured during the business analysis phase:
These rules are almost identical; only a few key parts parameters are different. Although aircraft type (747 or DC-10) and max cargo weight (200,000 or 150,000 lbs) are different in each rule, the basic form of the rule is the same. In fact, we can generalize the rule as follows:
Where the parameters X and Y can be organized in table form as shown below:
Aircraft type X 747 DC-10 Maximum cargo weight Y 200,000 150,000
It is important to recognize these patterns because they can drastically simplify rule writing and maintenance in Studio. As shown in Figure 164, we could build these two rules as a pair of Rulesheets, each with a Filter expression that filters data by aircrafttype.
Figure 164 Non-Parameterized Rule
January 13, 2012
Rule Modeling Guide
Page 155
But there is a simpler and more efficient way of writing these two rules that leverages the concept of parameterization. Figure 165 illustrates how this is accomplished:
Figure 165 Parameterized Rules
Notice how both rules are modeled on the same Rulesheet. This makes it easier to organize rules that share a common pattern and maintain them over time. If the air cargo company decides to add new aircraft types to its fleet in the future, the new aircraft types can simply be added as additional columns. Also notice the business rule statements in the Rule Statements section. By entering 1:2 in the Ref column and inserting attribute names into the rule statement, the same statement can be reused for both rule columns. The syntax for inserting Vocabulary terms into a rule statement requires the use of {..} curly brackets enclosing the term. See the Rule Language Guide for more details on embedding dynamic values in Rule Statements. In addition to collecting parameterized rules on the same Rulesheet, other things can be done to improve rule serviceability. In the Trade Allocation sample application that accompanies the Business Rules Management installation, two parameterized rules are accessible directly from the applications user interface the user can update these parameters without entering the Studio because they are stored externally. When the application runs, Studio accesses the parameter table to determine which rules should fire.
PARAMETERIZED RULE WHERE A SPECIFIC BUSINESS RULE IS A PARAMETER WITHIN A GENERIC BUSINESS
RULE
The previous section illustrated the simplest examples of parameterized rules. Other subtler examples occur frequently. For example, lets return to the Trade Allocation sample application included in the Studio installation. A recurring pattern in Trade Allocation might be that specific accounts prohibit or restrict the holding of specific securities for specific reasons. We might notice this pattern by examining specific business rules captured during the business analysis phase:
Rule Modeling Guide
Page 156
The first specific rule might be motivated by another, general rule that states:
The general rule explains why Airbus places this specific restriction on its account holdings Boeing is a competitor. The second rule is very similar in that it also defines an account restriction for a security attribute (the issuers industry classification), even though the rule has a different motivation. (A clients investments must not conflict with its ethical guidelines?) There may be many other business rules that share a common structure, meaning similar entity context and scope. This pattern allows us to define a generic business rule:
Or, rewritten as a constraint:
Absent a method for accommodating many similar rules as a single, generalized case, we need to enter each specific rule separately into a Rulesheet. This makes the task of capturing, optimizing, testing, and managing these rules more difficult and time-consuming than necessary. In the example of Trade Allocation, an Account Restriction (as a Vocabulary term) might be associated with Account (as the holder or owner of the restriction), as well as other entities shown in the following figure. For illustration purposes, the Vocabulary is shown as a UML class diagram.
Figure 166 UML Class Diagram of Sample Vocabulary
With this Vocabulary, the following Rulesheet can be defined:
January 13, 2012
Rule Modeling Guide
Page 157
Entity/Attribute
Generic business rule
Security.type An account must not hold a security of a restricted type Issuer.name Industry.name
An account must not hold a security issued by a restricted company An account must not hold a security issued by a company in a restricted industry
Figure 167 Parameterized Rule Example
Note that Transaction is the scope 22 for this Rulesheet because all included rules apply only to Securities related to a specific Account and contained in the same Transaction. Also, note that the rule statements have been written as generic rules, with parameters appended to identify the specific examples involved in rule execution. This provides the user with a more complete explanation of which rule fired and why it fired. The following Ruletest tests the 2nd and 3rd rule statements. A single transaction contains one account, Airbus, which has two account restrictions: no competitor securities and no tobacco industry securities. Two securities are included in the transaction, one for Boeing (a competitor) and one for RJR (a company in the tobacco industry). Running the Ruletest in Figure 168, we see:
22
See chapter/module Rule Scope and Context for an in-depth explanation of this key concept
January 13, 2012
Rule Modeling Guide
Page 158
Figure 168 Ruletest
Note the Violation messages posted as a result of the rules firing.
POPULATING AN ACCOUNTRESTRICTION TABLE FROM A SAMPLE USER INTERFACE

Parameterizing rules can improve reuse and simplify maintenance. In fact, maintenance of some welldefined rule patterns can be further simplified by enabling users to modify them external to Studio altogether. A user may define and maintain specific rules that follow the generic rule pattern (analogous to an instance of a generic rule class) using a graphical interface or database table built for this purpose. The following is a sample user interface that could be constructed to manage parameterized rules that share similar patterns. Note, this sample interface is discussed here only as an example of a parameterized rule maintenance application. It is not provided as part of the Studio installation.
January 13, 2012
Rule Modeling Guide
Page 159
Account Trading Prohibitions - Parameterized Rule
1 2 3
Select Account: Enter Specific Rule Restrict By:
list of Accounts
type new business rule here
Security Type Issuer Name Industry Name
Types of Securities Names of Issuers Names of Industries
4 5 6
Add Restriction
Delete Restriction
no Junk Bonds (lower than Bbb) no Small Cap equities no RJR-Nabisco no Tobacco securities
check box to activate specific business rule - uncheck box to deactivate
Figure 169 Sample GUI Window for Populating a Rules Parameter Table
Step 1 The user selects an Account for which the Account Restriction will be created. Referring back to our example, the user would select Airbus from the list box. Step 2 The user enters a specific business rule that provides the motivation for the Account Restriction. The prior example used no competitor securities and no tobacco securities. Step 3 The user selects the type of restriction being created. Our example used issuer.name and
industry.name.
Step 4 Once all components of the Account Restriction are entered and selected, clicking Add Restriction creates the restriction by populating the AccountRestriction table in an external database.
AccountRestriction table Account Security.type Issuer.name Industry.name Business Rule
Airbus Airbus
-----
Boeing ---
--Tobacco
No competitor securities No tobacco securities
Step 5 After adding a restriction, it appears in the lower scrolling text box. Selecting the Business Rule in the scrolling text box and clicking Delete Restriction will remove it from the box and from the table. Step 6 The checkbox indicates an active or inactive Business Rule. This allows the user to deactivate a rule without deleting it. In practice, another attribute could be added to the AccountRestriction
January 13, 2012
Rule Modeling Guide
Page 160
entity called active. A Precondition might filter out inactive rules to prevent them from firing during runtime.
WARNING!
Whenever you decide to maintain rule parameters outside of Studio, you run the risk of introducing ambiguities or conflicts into your Rulesheet. The Conflict Checker may not help you discover these problems since some of the rule data isnt shown in Studio. So always try to design your parameter maintenance forms and interfaces to prevent ambiguities from being introduced.
TEST YOURSELF:
Answers are provided in Appendix D. 151. When several rules use the same set of Conditions and Actions, but different values for each, we say that these rules share a common __________________. 152. Another name for the different values in these expressions is _______________ . 153. True or False. When several rules share a pattern, the best way to model them is as a series of Boolean Conditions. 154. Whats a potential danger of maintaining rule parameters outside of a Studio Rulesheet? 155. Write a generalized rule that identifies the pattern in the following rule statements: a. Platinum customers buy $100,000 or more of product each year b. Gold customers buy between $75,000 and less than $100,000 of product each year c. Silver customers buy more than $50,000 and less than $75,000 of product each year d. Bronze customers buy between $25,000 and $50,000 of product each year 156. In the rules listed above, what are the parameters? 157. Describe the ways in which these parameters can be maintained. What are the advantages and disadvantages of each option?
January 13, 2012
Rule Modeling Guide
Page 161
LOGICAL ANALYSIS AND OPTIMIZATION

TESTING, ANALYSIS AND OPTIMIZATION
Studio provides the rule modeler with tools to test, validate, and optimize rules and Rulesheets prior to deployment. Before proceeding, lets define these terms.
Scenario Testing
Scenario testing is the process of comparing actual decision operation to expected operation, using data scenarios or test cases. The Studio Ruletest provides the capability to build test cases using real data, which may then be fed to a set of rules for evaluation. The actual output produced by the rules may then be compared to the output we expect those rules to produce. If the actual output matches the expected output, then we may have some degree of confidence that the decision is performing properly. Why only some confidence and not complete confidence will be addressed over the course of this chapter.
Rulesheet Analysis & Optimization

Analysis and optimization is the process of examining and correcting or improving the logical construction of Rulesheets, without using test data. As with testing, the analysis process verifies that our rules are functioning correctly. Testing, however, does nothing to inform the rule builder about the execution efficiency of the Rulesheets. Optimization of the rules ensures they execute most efficiently, and provide the best performance when deployed in production. The following example illustrates the point: Two rules are implemented to profile life insurance policy applicants into two categories, high risk and low risk. These categories might be used later in a business process to determine policy premiums.
Figure 170 Simple Rules for Profiling Insurance Policy Applicants
January 13, 2012
Rule Modeling Guide To test these rules, we create a new scenario in a Ruletest, as shown in Figure 171.
Page 162
Figure 171 A Test Scenario Created in a Ruletest
In this scenario, we have created a single example of Person, a non-smoker aged 45. Based on the rules we just created, we expect that the Condition in Rule 1 will be satisfied (People aged 55 or younger) and that the persons riskRating will be assigned the value of low. To confirm our expectations, we run the Ruletest:
Figure 172 Ruletest
As we see in Figure 172, our expectations are confirmed: Rule 1 fires and riskRating is assigned the value of low. Furthermore, the .post command displays the appropriate rule statement. Based on this single scenario, can we say conclusively that these rules will operate properly for other possible scenarios; i.e., for all instances of Person? How do we answer this critical question?
TRADITIONAL MEANS OF ANALYZING LOGIC

The question of proper decision operation for all possible instances of data is fundamentally about analyzing the logic in each set of rules. Analyzing each individual rule is relatively easy, but business
January 13, 2012
Rule Modeling Guide
Page 163
decisions are rarely composed of just a single rule. More commonly, a decision is composed of dozens or hundreds of rules, and the ways in which the rules interact can be very complex. Despite this complexity, there are several traditional methods for analyzing sets of rules to discover logical problems.
Flowcharts
A flowchart that captures these two rules might look like the following:
Figure 173 Flowchart with 2 Rules
Upon closer examination, the flowchart reveals two problems with our rules: what Action(s) should be taken if either test fails, in other words, if Person.age>55 or if Person.smoker=false? The rules built in Figure 170 do not handle these two cases. But there is also a third, subtler problem here: what happens if both Conditions are satisfied, specifically when Person.age<=55 and Person.smoker=true? When Person.age<=55, we want Person.riskRating to be given the
January 13, 2012
Rule Modeling Guide
Page 164
value of low. But when Person.smoker=true, we want Person.riskRating to be given the value of high. We have discovered a dependency between our rules they are not truly separate and independent evaluations because they both assign a value to the same attribute. So the flowchart we began with turns out to be an incorrect graphical representation of our rules, because the decision flow doesnt truly follow two parallel and independent paths. Lets try a different flowchart:
Figure 174 Flowchart with 2 Dependent Rules
January 13, 2012
Rule Modeling Guide
Page 165
In the flowchart in Figure 174, we have acknowledged an interdependence between the two rules, and have arranged them accordingly. However, a few questions still exist. For example, why did we choose to place the smoker rule before the age rule? By doing so we are giving the smoker rule an implicit priority over the age rule because any smoker will immediately be given a riskRating value of High regardless of what their age is. Is this what the business intends, or are we as modelers making unjustified assumptions? We call this a problem of logical conflict 23, because its simply not clear from our two rules, as they have been written, what the correct outcome should be. Does one rule take priority over the other? Should one rule take priority over the other? This is, of course, a business question, but the rule writer must be aware of the dependency problem and resulting conflict in order to ask the question in the first place. Also, notice that there is still no outcome for a non-smoker older than 55. We call this a problem of logical completeness and it must be taken into consideration, no matter which flowchart we use. The point we are making is that discovery of logical problems in sets of rules using the flowcharting method is very difficult and tedious, especially as the number and complexity of rules in a decision (and the resulting flowcharts) grows.
Test Databases
The use of a test database is another common method for testing rules (or any kind of business logic, for that matter). The idea is to build a large number of test cases, with carefully chosen data, and determine what the correct system response should be for each case. Then, the test cases are processed by the logical system and output is generated. Finally, the expected output is compared to the actual output, and any differences are investigated as possible logical bugs. Lets construct a very small test database with only a few test cases, determine our expected outcomes, then run the tests and compare the results. We want to ensure that our rules execute properly for all cases that might be encountered in a real-life production system. To do this, we must create a set of cases that includes all such possibilities. In our simple example of two rules, this is a relatively straightforward task: condition Age <= 55 Age > 55
Figure 175 All Combinations of Conditions in Table Form
Smoker (smoker = true)
Non-Smoker (smoker = false)
In Figure 175, we have assembled a table using the Values sets from each of the Conditions in our rules. By arranging one set of values in rows, and the other set in columns, we create the Cross
23
Conflict is also known as Ambiguity. In older versions of Corticon Studio, the term ambiguity is used more frequently.
January 13, 2012
Rule Modeling Guide
Page 166
Product (also known as the direct product or cross product) of the two Values sets, which means that every member of one set is paired with every member of the other set. Since each Values set has only two members, the Cross Product yields 4 distinct possible combinations of members (2 multiplied by 2). These combinations are represented by the intersection of each row and column in the table in Figure 175. Now lets fill in the table using the expected outcomes from our rules. Rule 1, the age rule, is represented by row 1 in the table above. Recall that rule 1 deals exclusively with the age of the applicant and is not impacted by the applicants smoker value. To put it another way, the rule produces the same outcome regardless of whether the applicants smoker value is true or false. Therefore, the action taken when rule 1 fires (riskRating is assigned the value of low) should be entered into both cells of row 1 in the table, as shown in Figure 176.
condition Age <= 55 Age > 55
Smoker (smoker = true) low
Non-Smoker (smoker = false) low
Figure 176 Rule 1 Expected Outcome
Likewise, rule 2, the smoker rule, is represented by column 1 in Figure 175. The action taken if rule 2 fires (riskRating is assigned the value of high) should be entered into both cells of column 1 as shown in Figure 177.
condition Age <= 55 Age > 55
Smoker (smoker = true) low, high high
Non-Smoker (smoker = false) low
Figure 177 Rule 2 Expected Outcome
The table format illustrates the fact that a complete set of test data should contain four distinct cases (each cell corresponds to a case). Rearranging, our test cases and expected results can be summarized as follows: Test case 1 2 3 age
<= 55 <= 55 > 55
smoker
true false true
Expected outcome
low, high low high
January 13, 2012
Rule Modeling Guide
Page 167
> 55
false
Figure 178 Test Cases Extracted from Cross Product
The table format also highlights two problems we encountered earlier with flowcharts. In Figure 177, row 1 and column 1 intersect in the upper left cell (this cell corresponds to test case #1 in Figure 178). As a result, each rule tries to assert its own action one rule assigns a low value, and the other rule assigns a high value. Which rule is correct? Logically speaking, they both are. But if the rule analyst had a business preference, it was certainly lost in the implementation. As before, we simply cant tell by the way the two rules are expressed. Logical conflict reveals itself once more. Also notice the lower right cell (corresponding to test case #4) it is empty. The combination of age>55 AND non-smoker (smoker=false) produces no outcome because neither rule deals with this case the logical incompleteness in our business rules reveals itself once more. Before we deal with the logical problems discovered here, lets build a Ruletest in Studio that includes all four test cases in Figure 178:
Figure 179 Inputs and Outputs of the 4 Test Cases
Lets look at the test case results in Figure 179. Are they consistent with our expectations? With a minor exception in case #1, the answer is yes. In case #1, riskRating has been assigned the value of high. But also notice the rule statements posted: case #1 has produced two messages which indicate
January 13, 2012
Rule Modeling Guide
Page 168
that both the age rule and the smoker rule fired as expected. But since riskRating can hold only one value, the system non-deterministically (at least from our perspective) assigned it the value of high. So if using test cases works, what is wrong with using it as part of our Analysis methodology? Lets look at the assumptions and simplifications made in the previous example: 1. We are working with just two rules with two Conditions. Imagine a rule pattern comprising three Conditions our simple 2-dimensional table expands into three dimensions. This may still not be too difficult to work with as some people are comfortable visualizing in three dimensions. But what about four or more? Its true that large, multi-dimensional tables can be flattened and represented in a 2-D table, but these become very large and awkward very quickly. 2. Each of our rules contains only a single Conditional parameter limited to only two values. Each also assigns, as its Action, a single parameter which is also limited to just two values. When the number of rules and/or values becomes very large, as is typical with real-world business decisions, the size of the Cross Product rapidly becomes unmanageable. For example, a set of only six Conditions, each choosing from only only ten values produces a Cross Product of 106, or one million combinations. Manually analyzing a million combinations for conflict and incompleteness is tedious and time-consuming, and still prone to human error. In many cases, the potential set of cases is so large, that few project teams take the time to rigorously define all possibilities for testing. Instead, they often pull test cases from an actual database populated with real data. If this occurs, conflict and incompleteness may never be discovered during testing because its unlikely that every possible combination will be covered by the test data.
USING STUDIO TO VALIDATE RULESHEETS

Now, having demonstrated how to test rules with real cases (as performed in Figure 179) as well as having discussed two manual methods for developing these test cases, its time to demonstrate how Studio performs conflict and completeness checking automatically.
Expanding Rules
Returning to our original rules (reproduced from Figure 170):
January 13, 2012
Rule Modeling Guide
Page 169
Figure 180 Simple Rules for Profiling Insurance Policy Applicants
As illustrated by the table in Figure 176, rule 1 (the age rule) is really a combination of two sub-rules; we specified an age value for the first Condition but did not specify a smoker value for the second Condition. Because the smoker Condition has two possible values (true and false), the two subrules can be stated as follows:
Studio makes it easy to view sub-rules for any or all columns in a Rulesheet. By clicking the Expand Rules button on the toolbar, or simply double-clicking the column header, Studio will display subrules for any selected column. If no columns are selected, then all sub-rules for all columns will be shown. Sub-rules are labeled using Decimal numbers: rule 1 below has two sub-rules labeled 1.1 and 1.2. Sub-rules 1.1 and 1.2 are equivalent to the upper left and upper right cells in Figure 176.
January 13, 2012
Rule Modeling Guide
Page 170
Figure 181 Expanding Rules to Reveal Components
As we pointed out before, the outcome is the same for each sub-rule. Because of this, the sub-rules can be summarized as the general rules shown in column 1 of Figure 180. We also say that the two sub-rules collapse into the rules shown in column 1. The dash symbol in the smoker value of column 1 indicates that the actual value of smoker doesnt matter to the execution of the rule it will assign riskRating the value of low no matter what the smoker value is (as long as age <= 55, satisfying the first Condition). Looking at it a different way, only those rules with dashes in their columns have sub-rules, one for each value in the complete value set determined for that Condition row.
The Conflict Checker

With our two rules expanded into four sub-rules as shown in Figure 181, most of the Cross Product is displayed for us. Click on the Check for Conflicts button in the toolbar.
January 13, 2012
Rule Modeling Guide
Page 171
Figure 182 A Conflict Revealed by the Conflict Checker
The mechanics of stepping through and resolving each conflict has been covered in detail in the Basic Tutorial for Corticon Studio Modeling Rules. Here, our intent is to correlate the results of the automatic conflict check with the problems we identified first with the flowchart method, then later with test cases. Sub-rules 1.1 and 2.1, the sub-rules highlighted in pink and yellow in Figure 182, correspond to the intersection of column 1 and row 1 of Figure 177 or test case #1 in Figure 178. But note Studio does not instruct the rule writer how to resolve the conflict it simply alerts the rule writer to its presence. The rule writer, ideally someone who knows the business, must decide how to resolve the problem. The rule writer has two basic choices: 1. Change the Action(s) for one or both rules. We could change the Action in sub-rule 1.1 to match 2.1 or vice versa. Or we could introduce a new Action, say riskRating = medium, as the Action for both 1.1 and 2.1. If either method is used, the result will be that the Conditions and Actions of sub-rule 1.1 and 2.1 are identical. This removes the conflict, but introduces redundancy, which, while not a logical problem, can reduce processing performance in deployment. Removing redundancies in Rulesheets is discussed in the Optimization section of this chapter. 2. Use an Override. Think of an override as an exception. To override one rule with another means to instruct the Corticon Server to fire only one rule even when the Conditions of both rules are satisfied. Another way to think about overrides is to refer back to the discussion surrounding the flowchart in Figure 174. At the time, we were unclear which decision should execute first no priority had been declared in our rules. But it made a big difference how we constructed our flowchart and what results it generated. To use an override here, we simply select the number of the sub-rule to be overridden from the drop-down box at the bottom of the column of the overriding sub-rule, as shown circled in Figure 183. This is expressed simply as sub-rule 2.1 overrides 1.1. It is incorrect to think of overrides as defining execution
Rule Modeling Guide
Page 172
sequence. An override does not mean fire rule 2.1 then fire rule 1.1. It means fire rule 2.1 and do not fire rule 1.1.
Figure 183 Override Entered to Resolve Conflict
An override is essentially another business rule, which should to be expressed somewhere in the Rule Statements section of the Rulesheet. To express this override in plain English, the rule writer might choose to modify the rule statement for the overridden rule:
This modification successfully expresses the effect of the override. If ever in doubt as to whether you have successfully resolved a conflict, simply click the Check for Conflicts button again. The affected sub-rules should not highlight as you step through any remaining ambiguities. If all ambiguities have been resolved, youll see the following window:
Figure 184 Conflict Resolution Complete
January 13, 2012
Rule Modeling Guide
Page 173
The Completeness Checker

While our rules are expanded, lets check for incompleteness. Again, the mechanics of this process are described in the Basic Tutorial for Corticon Studio Modeling Rules. Our discussion here will be limited to correlating results with the previous manual methods of logical analysis. Clicking the Check for Completeness displayed: button, the message window shown in Figure 185 is
Figure 185 Completeness Check Message Window
Clicking OK to dismiss the message window, we see that the Completeness Check has produced a new column (3), shaded in green:
Figure 186 New Rule Added by Completeness Check
This new rule, the combination of age>55 AND smoker=false corresponds to the intersection of column 2 and row 2 in Figure 177 and test case #4 in Figure 178. The Completeness Checker has discovered our missing rule! To do this, the Completeness Checker employs an algorithm which calculates all mathematical combinations of the Conditions values (the Cross Product), and compares them to the combinations defined by the rule writer as other columns (other rules in the Rulesheet). If the comparison determines that some combinations are missing from the Rulesheet, these combinations are automatically added to the Rulesheet. As with the Conflict Check, the Action
January 13, 2012
Rule Modeling Guide
Page 174
definitions of the new rules are left to the rule writer. The rule writer should also remember to enter new plain-language Rule Statements for the new columns so its clear what logic is being modeled. The corresponding rule statement might look like this:
Automatically Determining the Complete Values Set

As values are manually entered into column cells in a Condition row, Studio automatically creates and updates a set of values, which for the given datatype of the Condition expression, is complete. This means that as you populate column cells, the list of values in the drop-down boxes you select from will grow and change. In the drop-down box, youll see the list of values you have entered, plus null if the attribute or expression can have that value. But this list displayed in the drop-down is not the complete list Studio maintains the complete list under the covers and only shows you the elements which you have manually inserted. This automatically generated complete value list serves to feed the Completeness Checker with the information it needs to calculate the Cross Product and generate additional green columns. Without complete lists of possible values, the calculated Cross Product itself will be incomplete.
Automatic Compression of the New Columns

Another important aspect of the Completeness Checkers operation is the automatic compression it performs on the resulting set of missing Conditions. As we see from the message displayed in Figure 185, the algorithm not only identifies the missing rules, but it also compresses them into nonoverlapping columns. Two important points about this statement: 1. The compression performed by the Completeness Checker is a different kind of compression from that performed by the Compression Tool introduced in the Optimization section of this chapter. The optimized columns produced by the Completeness Check contain no redundant sub-rules (thats what non-overlapping means), whereas the Compression Tool will intentionally inject redundant sub-rules in order to create dashes wherever possible. This creates the optimal visual representation of the rules. 2. The compression performed here is designed to reduce the results set (which could be extremely large) into a manageable number while simultaneously introducing no ambiguities into the Rulesheet (which might arise due to redundant sub-rules being assigned different Actions).
Limitations of the Completeness Checker

The Completeness Checker is powerful in its ability to discover missing combinations of Conditions from your Rulesheet. However, it is not smart enough to determine if these combinations make business sense or not. The example in Figure 187 below shows two rules used in a health care scenario to screen for high-risk pregnancies:
January 13, 2012
Rule Modeling Guide
Page 175
Figure 187 Example Prior to Completeness Check
Now, well click on the Completeness Checker:
Figure 188 Example after Completeness Check
Notice that columns 3-4 have been automatically added to the Rulesheet. But also notice that column 3 contains an unusual Condition: gender <> female. Because the other two Conditions in column 3
January 13, 2012
Rule Modeling Guide
Page 176
have dash values, we know it contains component or sub-rules. By double-clicking on column 3s header, its sub-rules are revealed:
Figure 189 Non-Female Sub-Rules Revealed
Because our Rulesheet is intended to identify high-risk pregnancies, it would not seem necessary to evaluate non-female (i.e., male) patients at all. And if male patients are evaluated, then we can say with some certainty that the scenarios described by sub-rules 3.1 and 3.3 those scenarios containing pregnant males are truly unnecessary. While these combinations may be members of the Cross Product, they are clearly not combinations that can occur in real life. If other rules in an application prevent combinations like this from occurring, then sub-rules 3.1 and 3.3 may also be unnecessary here. On the other hand, if no other rules catch this faulty combination earlier, then we may want to use this opportunity to raise an error message or take some other action that prompts a reexamination of the input data.
Renumbering Rules
Continuing with the previous pregnancy example, lets assume that we agree that sub-rules 3.1 and 3.3 are impossible, and so may be safely ignored. However, we decide to keep sub-rules 3.2 and 3.4 and assign Actions to them. For this example, well just post violation messages to them. However, when we try to enter Rule Statements for sub-rules 3.2 and 3.4, we discover that Rule Statements can only be entered for general rules (whole-numbered columns), not sub-rules. To convert column 3, with its four sub-rules, into four whole-numbered general rules, select Rulesheet>Rule Column(s)>Renumber Rules from the Studio menubar.
January 13, 2012
Rule Modeling Guide
Page 177
Figure 190 Sub-Rules Renumbered and Converted to General Rules
Now that the columns have been renumbered, Rule Statements may be assigned to columns 4 and 6, and columns 3 and 5 may be deleted or disabled (if desired). When impossible or undesirable rules are created by the Completeness Checker, we recommend disabling the rule columns rather than deleting them. When disabled, the columns remain visible to all modelers, eliminating any surprise (and shock) when future modelers apply the Completeness Check and discover missing rules that you had already found and deleted. And if you disable the columns, be sure to include a Rule Statement that explains why. See Figure 191 for an example of a fully complete and well-documented Rulesheet
January 13, 2012
Rule Modeling Guide
Page 178
Figure 191 Final Rulesheet with impossible rules disabled
Letting the Expansion Tool work for you: Tabular Rules

Business rules, especially those found in operational manuals or procedures, often take the form of tables. Take for example the following table that generates shipping charges between two geographic zones:
Matrix to Calculate Shipping Charges per Pound From/To zone 1 zone 2 zone 3 zone 4 zone 5 zone 1 $0.25 $0.35 $0.45 $0.55 $0.65 zone 2 $0.35 $0.25 $0.35 $0.45 $0.55 zone 3 $0.45 $0.35 $0.25 $0.35 $0.45 zone 4 $0.55 $0.45 $0.35 $0.25 $0.35 zone 5 $0.65 $0.55 $0.45 $0.35 $0.25
Figure 192 Matrix of Shipping Charges by Zone
In Figure 193 we have built a simple Vocabulary with which to implement these rules. Because each cell in the table represents a single rule, our Rulesheet will contain 25 columns (the Cross Product equals 5x5 or 25).
January 13, 2012
Rule Modeling Guide
Page 179
Figure 193 Vocabulary and Rulesheet to Implement Matrix
Rather than manually create all 25 combinations (and risk making a mistake), you can use the Expansion Tool to help you do it. This is a three-step process. Step 1 consists of entering the full range of values found in the table in the Conditions cells, as shown in Figure 194.
Figure 194 Rulesheet with Conditions Automatically Populated
Now, use the Expansion Tool to expand column 1 into 25 non-overlapping columns. We now see the 25 sub-rules of column 1 (only the first ten sub-rules are shown in Figure 195 due to page width limitations in this document):
Figure 195 Rule 1 Expanded to Show Sub-Rules
January 13, 2012
Rule Modeling Guide
Page 180
Each sub-rule represents a single cell in the original table. Now, select the appropriate value of shipCharge in the Actions section of each sub-rule as shown in Figure 196.
Figure 196 Rulesheet with Actions Populated
In step 3, shown in Figure 197, we renumber the sub-rules to arrive at the final Rulesheet with 25 general rules, each of which may now be assigned a Rule Statement.
Figure 197 Rulesheet with Renumbered Rules
Well revisit this example in the Optimization section.
Memory Management
As you might suspect, the Completeness Checker and Expansion algorithms are memory-intensive, especially as Rulesheets become very large. If Studio runs low on memory, refer to the Studio Installation Guide, Changing Studio Memory Allocation section, for details on increasing Studios memory allotment.
LOGICAL LOOP DETECTION

Studio has the ability to both detect and control rule looping. This is important because loops are sometimes inadvertently created during rule implementation. Other times, looping is intentionally
January 13, 2012
Rule Modeling Guide introduced to accomplish specific purposes. Both scenarios are discussed in the chapter Rule Dependency: Chaining and Looping.
Page 181
OPTIMIZING RULESHEETS
The Compress Tool
Studio helps improve performance by removing redundancies within Rulesheets. There are two types of redundancies the Compress Tool detects and removes: 1. Rule or sub-rule duplication. The Compress Tool will search a Rulesheet for duplicate columns (including sub-rules that may not be visible unless the rule columns are expanded), and delete extra copies. Picking up where we left off in Figure 186, lets add another rule (column #4), as shown in Figure 198.
Figure 198 New Rule (#4) Added
While these 4 rules use only 2 Conditions and take just 2 Actions (an assignment to riskRating and a posted message), they already contain a redundancy problem. Using the Expand Tool this redundancy is visible in Figure 199.
January 13, 2012
Rule Modeling Guide
Page 182
Figure 199 Redundancy Problem Exposed
Clicking on the Compress Tool
has the effect shown in Figure 200:
Figure 200 Rulesheet After Compression
Looking at the compressed Rulesheet in Figure 200, we see that column #4 has disappeared entirely. More accurately, the Compress Tool determined that column 4 was a duplicate of one of the sub-rules in column 1 (1.2) and simply removed it. Looking at the Rule Statement section, we see that the rule statement for rule 4 has been renumbered to match the surviving rule.
January 13, 2012
Rule Modeling Guide
Page 183
Compression does not, however, alter the text of the rule statement; that task is left to the rule writer. Its important to note that the compression does not alter the Rulesheets logic; it simply affects the way the rules appear in the Rulesheet the number of columns, Values sets in the columns, etc. Compression also streamlines rule execution by ensuring that no rules are processed more than necessary. 2. Combining Values sets to simplify and shorten Rulesheets. Recall our shipping charge example. By using the Compress Tool, Rulesheet columns are combined wherever possible by creating Values sets in Condition cells. For example, rule 6 in Figure 201 (highlighted below) is the combination of rule 6 and 8 from Figure 197.
Figure 201 Compressed Shipping Charge Rulesheet
Value sets in Condition cells are equivalent to the logical operator OR. Rule 6 therefore reads: 6. A manifest with a Zone 2 sending address AND a Zone 1 OR Zone 3 receiving address costs $0.35 per pound to ship. In deployment, The Server will execute this new rule 6 faster than the previous rule 6 and 8 together.
Producing Characteristic Rulesheet Patterns

Because Studio is a visual environment, patterns often appear in the Rulesheet that provide insight into the decision logic. Once a rule writer recognizes and understands what these patterns mean, he or she can often accelerate rule modeling in the Rulesheet. The Compression Tool is designed to reproduce Rulesheet patterns in some common cases. For example, take the following rule statement: 1. An aircraft with max cargo volume greater than 300 AND max cargo weight greater than 200,000 AND tail number of N123UA must be a 747. 2. Otherwise it must be a DC-10. Applying some of the techniques from this manual, we might implement rule 1 as:
January 13, 2012
Rule Modeling Guide
Page 184
Figure 202 Implementing the 747 Rule
Now, letting the Completeness Checker populate the missing columns:
Figure 203 Remaining Columns Produced by the Completeness Checker
January 13, 2012
Rule Modeling Guide
Page 185
To remind you of the underlying Cross Product used by the Completeness Checker, well Expand the Rulesheet momentarily and examine the sub-rules present:
Figure 204 Underlying Sub-Rules Produced by the Completeness Checker
A total of 26 new columns (counting both rules and sub-rules) have been created exactly what we expect 24 and what the Completeness Check message window states. Now, Compress the Rulesheet and fill in the Actions for the new columns as shown in Figure 205:
Figure 205 Missing Rules with Actions Assigned
Because the added rules are non-overlapping, we can be sure they wont introduce any ambiguities into the Rulesheet. To prove this, select the Conflict Checker .
Three Conditions each with 3 members in their Values sets yields a Cross Product of 27 combinations (3*3*3 or 33). Subtracting the combination already present in column 1, we expect 26 new columns to be added.
24
January 13, 2012
Rule Modeling Guide
Page 186
Figure 206 Proof that no New Conflicts have been Introduced by the Completeness Check
This pattern tells us that the only case where the aircraft type is a 747 is when max cargo volume is greater than 300 AND max cargo weight is greater than 200,000 AND tail number is N123UA. This rule is expressed in column 1. In all other cases, specifically where max cargo volume is 300 or less OR max cargo weight is 200,000 or less OR tail number is something other than N123UA will the aircraft type be a DC-10 (or any of the values are null). These rules are expressed in columns 2, 3 and 4, respectively. The characteristic diagonal line of Condition values in columns 2-4, surrounded by dashes indicates a classic OR relationship between the 3 Conditions in these columns. The Compression algorithm was designed to produce this characteristic pattern whenever the underlying rule logic is present. It helps the rule writer to better see how the rules relate to each other.
Compression Creates Sub-Rule Redundancy

Compressing our example into a recognizable pattern, however, has an interesting side-effect - we have also introduced more sub-rules than were initially present. To see this, simply Expand Rulesheet as shown in Figure 207. the
Figure 207 Expanding Rules Following Compression
You may be surprised to see a total of 54 sub-rules (columns) displayed (in Figure 207) instead of the 26 we had prior to compression. Look closely at the 54 columns and you will see several instances of sub-rule redundancy of the 18 sub-rules within original columns 2, 3 and 4, almost half are redundant (for example, sub-rules 2.1, 3.1 and 4.1, shown in Figure 207, are identical). What happened?
January 13, 2012
Rule Modeling Guide
Page 187
Effect of Compression on Corticon Server Performance

Why does Studio have what amounts to two different kinds of compression one performed by the Completeness Checker and another performed by the Compression Tool? Its because each has a different role during the rule modeling process. The type of compression performed during a Completeness Check is designed to reduce a (potentially) very large set of missing rules into the smallest possible set of non-overlapping columns. This allows the rule writer to assign Actions to the missing rules without worrying about accidentally introducing ambiguities. On the other hand, the compression performed by the Compression Tool is designed to reduce the number of rules into the smallest set of general rules (columns with dashes), even if the total number of sub-rules is larger than that produced by the Completeness Checker. This is important for three reasons: 1. The Compression Tool preserves or reproduces key patterns familiar and meaningful to the rule modeler 2. The Compression Tool, by reducing a Rulesheet to the smallest number of columns, optimizes the executable code produced by Corticon Servers on-the-fly compiler. Smaller Rulesheets (lower column count) result in faster Corticon Server performance. 3. The Compression Tool, by reducing columns to their most general state (the most dashes), improves Corticon Server performance by allowing it to ignore all Conditions with dash values. This means that when the rule in column 3 of Figure 205 is evaluated by Corticon Server, only the max cargo weight Condition is considered the other two Conditions are ignored entirely because they contain dash values. When rule 3 of Figure 205 is evaluated after the Completeness Check is applied but before the Compression Tool, however, both max cargo weight and volume Conditions are considered, which takes slightly more time. So even though both Rulesheets have the same number of columns (four), the Rulesheet with more generalized rules (more dashes - Figure 205) will execute faster because the engine is doing less work.
TEST YOURSELF:
Answers are provided in Appendix D. 158. What does it mean for two rules to be ambiguous? 159. What does it mean for a Rulesheet to be complete? 160. Are all ambiguous rules wrong, and must all ambiguities be resolved before deployment? Why or why not? 161. Are all incomplete Rulesheets wrong, and must all incompletenesses be resolved before deployment? Why or why not? 162. Match the Studio tool name with its toolbar icon
Rule Modeling Guide
Page 188
Conflict Checker Compression Tool Expansion Tool Collapse Tool Conflict Filter Completeness Checker 163. Explain the different ways in which an Ambiguity/Conflict between two rules can be resolved. 164. True or False. Defining an override enforces a specific execution sequence of the two ambiguous rules 165. True or False. A Conditions row with an incomplete values set will always result in an incomplete Rulesheet. 166. If a Rulesheet is incomplete due to an incomplete values set, will the Completeness Checker detect the problem? Why or why not? 167. Can a rule column define more than one override? 168. If rule 1 overrides rule 2, and rule 2 overrides rule 3, does rule 1 automatically override rule 3? 169. Are rules created by the Completeness Checker always legitimate? 170. In a rule column, what does a dash (-) character mean? 171. True or False. The Expansion Tool permanently changes the rule models in a Rulesheet. If false, how can it be reversed? 172. True or False. The Compression Tool permanently changes the rule models in a Rulesheet. If false, how can it be reversed? 173. If a rule has 3 condition rows, and each condition row has a Values set with 4 elements, what is the size of the Cross Product? 174. In above question, is it necessary to assign actions for every set of conditions (i.e., for every column)?
Rule Modeling Guide
Page 189
175. If it is not desired to assign actions for every column, what can be done to/with these columns? 176. Which Studio tool helps to improve Rulesheet performance? Expansion Tool Compression Tool Completeness Checker Collapse Tool Squeeze Tool
177. How is the compression performed by the Completeness Checker different from that performed by the Compression Tool? 178. Whats wrong with using databases of test data to discover Rulesheet incompleteness? 179. If you expand a rule column and change the Actions for one of the sub-rules, what will Studio force you to do before saving the changes? 180. What does it mean for one rule to subsume another?
January 13, 2012
Rule Modeling Guide
Page 190
RULEFLOW VERSIONING & EFFECTIVE DATING

SETTING A RULEFLOW VERSION
Major and minor version numbers for Ruleflows are optional and may be assigned manually by selecting Ruleflow>Properties from the Studio menubar, and then clicking on the upward-pointing arrows in the resulting tab, as shown:
Figure 208 Assigning a Version Number to a Ruleflow
When we use different Version numbers to describe identically named Ruleflows, the Server keeps them straight in memory, and responds correctly to requests for the different Versions. In other words, an application or process can use (or call) different versions of the same Ruleflow depending on certain criteria. The details of how this works at the Server level are technical in nature and are described in the Server Integration & Deployment Guide. A plain-text description of this version can be added in the Comments tab. Version numbers may be raised anytime but never lowered.
SETTING EFFECTIVE AND EXPIRATION DATES

Effective and Expiration dateTimes are optional for Ruleflows and can be assigned singly or in pairs. When we use different Effective and Expiration dateTimes to describe identically named Ruleflows, the Server keeps them straight in memory, and responds correctly to requests for the different dates. In other words, an application or process can use different versions of the same Ruleflow depending on dateTime criteria. The details of how this works at the Server level is technical in nature and is described in the Server Integration & Deployment Guide. Effective and Expiration Dates may be assigned using the same window as above. Clicking on the Effective Date or Expiration Date drop-down displays a calendar and clock interface, as shown below:
January 13, 2012
Rule Modeling Guide
Page 191
Figure 209 Setting Effective and Expiration Dates
MAJOR AND MINOR VERSIONS

Minor and Major version designations are arbitrary and may be adapted to fit the version naming conventions used in different environments. As an example, Ruleflow minor versions may be incremented whenever a component Rulesheet is modified. Major Ruleflow versions may be incremented when more substantial changes are made to it, such as adding, replacing, or removing a Rulesheet from the Ruleflow. Verison numbers may only be incremented, never decremented. The details of how to invoke a Ruleflow by version number, see the Server Integration & Deployment Guide.
TEST YOURSELF:
Answers are provided in Appendix D. 181. True or False. If a Ruleflow has an Effective date, it must also have an Expiration date. 182. True or False. If a Ruleflow has an Expiration date, it must also have an Effective date. 183. True or False. Ruleflow Version numbers are mandatory 184. Which Studio menu contains the Ruleflow Properties settings? 185. True or False. A Ruleflow Minor or Major Version number may be raised or lowered. 186. True or False. Ruleflow Effective and Expiration dates are mandatory.
January 13, 2012
Rule Modeling Guide
Page 192
LOCALIZING CORTICON STUDIO

LOCALIZING THE VOCABULARY
A Vocabulary can be localized into several different languages. If a Vocabulary includes multiple locale information, then Studio will display the locale corresponding to the operating systems current locale. To localize a Vocabulary, select Vocabulary>Localize from Studios menubar as shown below: Studio will display the Vocabulary Localization window as shown below.
Figure 210 Localize a Vocabulary
Notice that weve selected French in the second line of the Supported Locales pane, circled below in orange. This choice causes a second column to appear to the right in the Vocabulary pane (shown below in an orange rectangle).
Figure 211 Selecting and populating a second locale
January 13, 2012
Rule Modeling Guide
Page 193
In the French column, we must manually add French translations for each Vocabulary term, including association role names. These translated terms must be unique from the English or other base version shown in the left-hand column. With a localized Vocabulary, now switch your operating system to French locale. Different OSs have different methods for switching locales - consult your OS help or documentation for assistance.
Figure 212 A Vocabulary displaying its French translation
LOCALIZING THE RULESHEET

When you create a new Rulesheet or Ruletest using a localized Vocabualry, those assets will be localized too. The Rulesheet>Localize menu selection allows you to further localize the Rulesheet by translating Scope aliases and Rule Statements, as shown below:
Figure 213 A Rulesheet displaying its French translation
January 13, 2012
Rule Modeling Guide
Page 194
WORKING WITH RULES IN NATURAL LANGUAGE

Corticon BRMS version 5.2 allows you to define Natural Language (NL) words, phrases, and sentences for use as substitute terms in Rulesheet Conditions and Actions. Display the NL window by choosing Window>Show View>Natural Language from the Studio menubar.
Figure 214 Displaying the Natural Language Window
If you do not see the Natural Language choice listed, you may need to Reset Perspective first. This typically only happens if you are upgrading from an earlier version of Studio. Once selected, you should see a new Window appear in Studio:
Figure 215 Displaying the Natural Language Window
January 13, 2012
Rule Modeling Guide
Page 195
If you have other Locales enabled (see Localization chapter for more details), then the Natural Language window will include columns for other languages besides English. This allows you to define Natural Language text for those locales, too. A populated Natural Language window is shown below. Notice that weve tried to be as clear and descriptive as possible, including the words If in Conditions and Then in Actions. Weve also used to indicate that the expression continues in the column cells to the right. Your use of natural language may vary, but we recommend adopting a consistent, clear style.
Figure 216 Populating the Natural Language Window populated with natural language text
Once natural language expressions are defined, you can view these entries in place of the standard Condition and Action expressions in the Rulesheet. 1. 2. Close the Natural Language window by clicking the tabs X On the Studio menubar, click the icon to display the Natural Language expressions entered previously. Note that while Natural Language is displayed, the text of the Condition and Action rows cannot be edited. To revert to original, editable expressions, click the icon
3.
.
Figure 217 Populating the Natural Language Window populated with natural language text
January 13, 2012
Rule Modeling Guide
Page 196
MODELING AND MANAGING RULES USING SERVER CONSOLE

Corticon BRMS 5.2 allows rule modelers to make modest changes to Rulesheets via the Server Console. Accessing the Server Console, both from a URL standpoint as well as a login standpoint, is addressed in the Monitoring Corticon Server chapter of the Server Integration & Deployment Guide. This chapter assumes you have the necessary access rights to Server Console.
LIFECYCLE MANAGEMENT IN SERVER CONSOLE

Modifying rules within live Decision Services already deployed to Corticon Server involves additional considerations than just updating rules in Studio. In Studio, the rules in Rulesheets are still just a design-time assets, perhaps not even tested yet or packaged in a Ruleflow, let alone deployed to a Server. But rules in a live Decision Service are available for invocation right at that moment, so we need to take a few extra precautions to ensure we dont interfere with clients trying to use our deployed Decision Services.
Creating a New Decision Service Version

Before any rule changes can be made from within Server Console, a new version of the Decision Service must be created first. A new version can be created for a Decision Service deployed via a .cdd, or for a Decision Service deployed via the Server Console. To create a new Decision Service version, follow these steps: 1. 2. 3. 4. Login to Server Console Select Decision Services from the Server Console Main Menu click the name of the Decision Service you want to modify. Each Decision Service listed in the Service Name column is a hyperlink. Select Create New Version button at the top of the page. See the Decision Service Versioning and Effective Dating chapter of the Server Integration & Deployment Guide for more information about versions and how to use them during Decision Service invocation. You will return to the Decision Services page, where you should see an additional Decision Service listed in the Service Name column. The Version should be incremented by 1. In Figure 218 below, a new version of tutorial_example has been created.
5.
January 13, 2012
Rule Modeling Guide
Page 197
Figure 218 Server Console with a new version of tutorial_example shown
Notice in Figure 218 that tutorial_example version 1 is not yet live (the Live column checkbox is unchecked). This means we can make changes to it.
Opening the New Version

To make changes to the new version (or any other non-live Decision Service), follow these steps: 1. 2. click the Decision Service listed in the Service Name column. This will display the Overview tab. Under the General Settings header, select the (Edit) hyperlink following the .erf or .ers you want to modify: a. selecting (Edit) hyperlink following the .erf opens a page which allows you to modify effective/expiration dates of the Decision Service, or increase the Version number. b. selecting (Edit) hyperlink following a .ers opens a page that allows you to modify that Rulesheet.
Modifying the New Version

Server Console allows the following types of changes to a Rulesheet: Changing values in a Condition or Action cell, including creating new values in the existing set
January 13, 2012
Rule Modeling Guide Adding/removing/changing Overrides for rule columns
Page 198
Changing Rule Statements for those rule columns that have them, including Text and Serverity changes. Re-applying the Conflict Checker following any changes to ensure new no new conflicts have been introduced by your changes
Server Console does not allow the following types of changes to a Rulesheet: Adding/removing/changing any Scope used by any rules Adding/removing/changing any Filters used by the Rulesheet Adding/removing/changing Condition or Action expressions Adding/removing rule columns to the decision table Adding/removing Rule Statements Adding/removing/changing and looping or advanced Inferencing features in a Rulesheet Enabling or disabling any Rulesheet rows or columns
The Rulesheet change page also includes a Business View/Technical View toggle button that shows/hides Rulesheet Scope and Filters, if used. Once you have updated the Rulesheet with any changes, click the Save button at the bottom of the page. A message will display the updated Decision Service timestamp and advise that a slight delay may occur before the Decision Service is ready to be promoted to live status. This delay is due to the time required to compile the Decision Service on the fly by Corticon Server. For more information about Decision Service compilation, please see the Server Integration & Deployment Guide.
Promoting the New Version to Live

After saving the new version of the Rulesheet (and after making any other changes to the Ruleflow or other Rulesheets desired), return to the Decision Services|Overview tab for the new version. By clicking the Promote to Live button, you will cause the new version to deploy to live status, which will update the the Live checkbox on the Decision Services page.
Removing the Version from Live

To remove this new Decision Service version (or any other Decision Service deployed via the Server Console), click the No/Remove hyperlink in the Deployed from CDD column of the Decision Services page.
January 13, 2012
Rule Modeling Guide
Page 199
THE STUDIO REPORTING FRAMEWORK

Corticon Studio contains a flexible and extensible framework for generating reports from Studio files. Each type of Studio asset uses a built-in XML template that defines the structure of an XML report generated by Studio. Then, a built-in XSLT stylesheet transforms the XML into a regular HTML file viewable with a standard web browser such as Microsoft Internet Explorer or Mozilla Firefox The Quick Reference Guide covers the mechanics of creating reports using the standard templates included with the installation. This chapter describes how to customize reporting templates and formats by taking advantage of the inherent flexibility of XML.
HOW STUDIO CREATES REPORTS

When a user selects Rulesheet>Report, Studio automatically: generates a XML file using its built-in XML template transforms the XML to HTML using its built-in XSLT stylesheet displays the HTML file in a web browser copies the XML and HTML files to the JVMs temporary directory. In Windows, by default, this is C:\Documents and Settings\<your Windows username>\Local Settings\Temp. You can change this by adding the following line to Studio.ini located in the <corticon_install_dir>\Studio directory
-Djava.io.tmpdir=<your new Reports directory>
be sure to use forward slashes when writing the path to your new Reports directory, such as
C:/Program Files/Corticon/Studio/myReports
Customizing the XSLT Stylesheets

Studios built-in XSLT stylesheets cannot be viewed or modified. However, you can tell Studio to use an XSLT stylesheet of your own creation if you want to generate custom Studio reports. The files required, including a sample copy of the built-in XSLT stylesheets, are located in
<corticon_install_dir>\Samples\Reports\Rulesheet (or \Vocabulary, \Ruleflow, \Ruletest).
Once you have created your own XSLT stylesheet (or modified the sample provided), copy the entire <corticon_install_dir>\Samples\Reports directory to <corticon_install_dir>\Studio \configuration\com.corticon.brms. Close and re-open Studio, and it will discover the new XSLT stylesheets and use them to generate reports.
January 13, 2012
Rule Modeling Guide
Page 200
TROUBLESHOOTING RULESHEETS AND RULEFLOWS

In addition to being a convenient way to test your Rulesheets with real business scenarios, the Studio Ruletest facility is also the best way to troubleshoot rule, Rulesheet, and Ruleflow operation. Studio Ruletest has been designed to replicate exactly the data handling, translation, and rule execution by Corticon Server when deployed as a Java component or web service in a production environment. This means that if your rules function correctly when executed in a Studio Ruletest, you can be confident they will also function correctly when executed by Corticon Server. If they do not, then the trouble is most likely in the way data is sent to Corticon Server in other words, in the technical integration. This is such a fundamental tenet of rule modeling with Corticon, well repeat it again: if your rules function correctly when executed in a Studio Ruletest, they will also function correctly when executed by Corticon Server. If they do not, then the trouble is most likely your client applications integration/invocation with/of Corticon Server. We offer the following methodology to guide your rule troubleshooting and debugging efforts. The basic technique is known generically as half-splitting or binary chopping, in other words, dividing a decision into smaller logical pieces, then setting aside the known-good pieces systematically until the problem is isolated. This guide is not intended to be an in-depth cookbook for correcting specific problems since, as an expression language, the Corticon Rule Language offers too many syntactical combinations to address each in any detail.
WHERE DID THE PROBLEM OCCUR?

Regardless of the environment the error or problem occurred in, we will always first attempt to reproduce the behavior in Studio. If the error occurred while you were building and testing rules in Corticon Studio, then youre already in the right place. If the error occurred while the rules were running on Corticon Server (in a test or production environment), then youll want to obtain a copy of the deployed Ruleflow (.erf file) and open it, its constituent Rulesheet s (.ers files) and its Vocabulary (.ecore file) in Studio.
USING STUDIO TO REPRODUCE THE BEHAVIOR

It is always helpful to build and save known-good Ruletests (.ert files) for the Corticon Rulesheets and Ruleflows you intend to deploy. A known-good Ruletest not only verifies your Rulesheet or Ruleflow is producing the expected results for a given scenario, it also enables you to re-test and reverify these results at any time in future. If you do not have a known-good Ruletest, you will want to build one now to verify that the Ruleflow, as it exists right now, is producing the expected results. If you have access to the actual data set or scenario that produced the error in the first place, it is especially helpful to use it here now. Run the Ruletest.
January 13, 2012
Rule Modeling Guide
Page 201
Running a Studio Ruletest

When the Ruletest is run, does Studio produce any error messages? By this, we do not mean the info, warning, or violation messages that may be posted by normal operation of the rules. If you encounter any of the following errors, please take the actions described in that section. It may be possible, using the techniques in this manual, to work around a problem by identifying the expression syntax that produces it, and trying to express the logic in a different way. The Corticon Rule Language is very flexible and usually allows the same logic to be expressed in many different ways. If you do not encounter any of these errors, proceed to the Analyzing Test Results section.
The Null Pointer Exception
Figure 219 A Null Pointer Exception as Shown in a Ruletest
A null pointer exception (NPE) almost always indicates a problem with the rule engine, whether it is being employed by the Studio or by Corticon Server. If you encounter this error, please contact Technical Support, and set aside copies of the Vocabulary, Rulesheet, and Ruletest so we can use them for further troubleshooting. The Reactor Exception
Figure 220 The Reactor Exception Window
This error is also indicative of a possible rule engine problem, but it may also indicate improper or unnecessarily complex language usage in your rule expressions. The Rule Languages flexibility may permit workarounds to the limitation(s) that produced this message; Corticon Technical Support should be contacted for further assistance. As with the NPE errors, please save copies of the Vocabulary, Rulesheet, and Ruletest for use by Corticon Support staff. The Fatal Exception On very rare occasions, you may experience a full crash of the Studio application. In these cases, youll see a window like the following:
January 13, 2012
Rule Modeling Guide
Page 202
Figure 221 The Fatal Error Window
This type of problem can only be resolved by Corticon. But before contacting Corticon Technical Support, please click on the button, which will display a window with more information about the cause of the error, as shown below:
Figure 222 The Fatal Error Details Window
Click the Copy button (as shown) and paste the text into a text file. Please send us this text file along with the standard set of Studio files (Vocabulary, Rulesheet, Ruletest) when you report this problem.
Analyzing Ruletest Results

This section assumes:
January 13, 2012
Rule Modeling Guide Your Ruletest produced none of the errors listed above, or You or Corticon Technical Support identified workarounds that overcame these errors
Page 203
Does the Rulesheet produce the expected test results? In other words, does the actual output match the expected output? If so, and you were using the same scenario that caused the original problem, then the problem is not with the rules or with Studio, but instead with the data integration or Server deployment. Proceed to Troubleshooting Server Problems If not, the problem is with the rules themselves. Continue in this section.
Identifying the Breakpoint

To understand why your rules are producing incorrect results, its important to know where in the Rulesheet or Ruleflow the rules stop behaving as expected. At some point, the rules stop acting normally and start acting abnormally i.e., they break. Once we identify where the rule breaks, the next step will be to determine why it breaks. Because of a fundamental Corticon Server behavior, the breakpoint will always be a single rule. If the data available to Corticon Server causes all of a rules Conditions to be satisfied and Corticon Server is able to execute all of the rules Actions, then Corticon Server will fire the rule. An important corollary to this: if any one of the rules Actions cannot be executed (for reasons to be discussed later), then none of the Actions will be executed the rule will not fire. Bottom line: a rule will fire in its entirety or not at all. We call this all or nothing behavior. An important tool to help identify the breakpoint is the Ruletests message box. By choosing values for Post and Alias columns in the Rule Messages window, you can generate a trace or log of the rules that fire during execution. The message box in a Ruletest will display those messages in the order they were generated by Corticon Server. In other words, the order of the messages in the box (top to bottom) corresponds to the order in which the rules were fired by Corticon Server. While messages in the message box can also be sorted by Severity or Entity by clicking on the header of those columns, clicking on the Message column header will always sequence according to the order in which the rules fired. Inserting attribute values into rule statements can also provide good insight into rule operation. But beware; a non-existent entity inserted into a rule statement will prevent the rule from firing, becoming the cause of another failure! Enabling and disabling individual Condition/Action rows, entire rule columns, Filter rows, and even whole Rulesheets is another powerful way to isolate problems in your ruleset. Right-clicking Condition or Action row headers, column headers, Filter row headers, or Rulesheet boxes in the Ruleflow will display a pop-up menu containing enable/disable options. Disabled rows and columns will be shaded in gray on the Rulesheet, while disabled Rulesheets turn dark gray in the Ruleflow diagram. Be sure to save these changes before running a Ruletest to ensure the changes take effect.
January 13, 2012
Rule Modeling Guide
Page 204
Figure 223 Rulesheet with Rule Column #2 Disabled
Figure 224 Disabled Rulesheet, Tab Label Circled
Disable rows, rule columns, and/or Rulesheets until the strange or unexpected behavior stops.
At the Breakpoint
At the point at which abnormal behavior begins, what results is the breakpoint rule producing? No results at all the breakpoint rule should fire (given the data in the Ruletest) but does not. Proceed to the No Results section. Incorrect results the breakpoint rule does fire, but without the expected result. Proceed to the Incorrect Results section.
January 13, 2012
Rule Modeling Guide No Results
Page 205
Failure of a rule to produce any results at all indicates the rule is telling the rule engine to do something it cant do 25. Frequently, this means the engine tries to perform an operation on a term that doesnt exist or isnt defined at time of rule execution. For example, trying to: Increment or decrement an attribute (using the += or -= operators, respectively) whose value doesnt exist (in other words, has a null value). Post a message to an entity that doesnt exist, either because it was not part of the Ruletest to begin with, or because it was deleted or re-associated by prior rules. Post a message with an embedded term from the Vocabulary whose value doesnt exist in the Ruletest, or was deleted by prior rules. Create (using the .new operator) a collection child element where no parent exists, either because it was not part of the Ruletest to begin with, or because it was deleted or re-associated by prior rules. Trying to forward-chain 26 within the same rule. For example, if Action row B in a given rule derives a value that is required in Action row C, then the rule may not fire. Both Actions must be executable independently in order for the rule to fire. If forward-chaining is required in the decision logic, then the chaining steps should be expressed as separate rules.
No Partial Rule Firing

A Condition/Action rule column should never partially fire, meaning Action 1 is executed but Action 2 is not. If Action A cannot execute, then Action B will not execute either, even if there is nothing wrong with Action B by itself. An Action containing any one of the problems listed above is sufficient to prevent a rule from firing, even if all other Actions in the rule are valid. Understanding this all or nothing execution behavior is very important for troubleshooting. An exception to this rule is the special Nonconditional rule column 0. Each Action row in column 0 counts as its own separate, independent rule, so Action row A may fire even if Action row B does not.
Initializing Null Attributes

If flightNumber had a non-null value prior to test, the Action would have executed as intended. For this reason, its important to ensure that attributes used on the right-hand-side of equations (i.e., an attribute on the right side of an assignment operator, such as = or +=) are initialized prior to performing these types of operations. It is not necessary for attributes on the left-hand-side of an equation to be initialized the act of assigning a value to it is sufficient. Initialization of attributes is often performed in Nonconditional rules (Actions in column 0), or in rules expressed in Rulesheets that execute beforehand.
25 26
This assumes, of course, that the rule should fire under normal circumstances. Forward-chaining is the process of using the results of one expression as the input to another.
January 13, 2012
Rule Modeling Guide Incorrect Results
Page 206
Once the breakpoint rule has been isolated, it is often helpful to copy the relevant logic into another Rulesheet for more focused testing. Refer to the Rule Language Guide to ensure you have expressed your rules correctly. Be sure to review the usage restrictions for the operator(s) in question. If, after isolating and verifying the suspicious expression syntax, you are unable to fix the problem, please call Corticon Technical Support. As always, be prepared to send us a) the product version used, and b) the set of Studio files (.ecore, .ers, .erf, and .ert) that will allow us to reproduce the problem.
Troubleshooting Corticon Server Problems

This section assumes that Studio problems, including incorrect rule expression, have been ruled out or fixed in previous sections. When Corticon Server side is involved, the best troubleshooting tool is the log file produced during Server operation. To configure logging for maximum benefit, follow these steps: Stop Corticon Server Go to the location of your Corticon Servers CcConfig.jar file. In the default Tomcat installation (in Windows), this is
<corticon_install_dir>\Server\Tomcat\webapps\axis\WEB-INF\lib
Open CcConfig.jar with a standard decompression utility (like WinZip or 7-Zip) and look for a text file named CcCommon.properties. Look for the loglevel property and change its value to INFO Restart Corticon Server and rerun the test.
Go to the directory containing log files. In the default Windows Tomcat installation, this is
<corticon_install_dir>\Server\Tomcat\CcServer\Log and locate todays log file. Its filename is in yyyymmdd.log format.
Either delete or rename todays log file. A new log file is created every day, and each Corticon Server transaction adds entries to the days log. Because daily log files may become quite large, it is useful to start with a fresh log that records only the problematic transaction. The next time Corticon Server processes a transaction, a new log file will be created and entries made in it.
What is Corticon Servers response? No response In most cases, the failure of Corticon Server to produce a log file means that the invocation/request is not even reaching it! The most common causes of a non-responsive (invocation produces no log file entry) Corticon Server include: Incorrect Corticon Server deployment. Review procedures in the Server Integration & Deployment Guide to ensure correct deployment. Incorrect Corticon Server invocation
January 13, 2012
Rule Modeling Guide
Page 207
1. Incorrect URL. If using a web services deployment, ensure the SOAP message is addressed correctly, and that no firewalls or port configurations prevent the SOAP message from reaching Corticon Server. 2. Incorrect API. Review the Server Integration & Deployment Guide for complete details on Java APIs available for Corticon Server invocation. A complete JavaDoc and sample code set is also provided in the <corticon_install_dir>\JavaDoc directory. Even though Corticon Server may not respond to an incorrect invocation, the host server or container (app server, web server, etc) may respond either at a command line or log level. Check to see if the host server has responded to your invocation.
Response containing errors The most common causes of erroneous Corticon Server responses include: Incorrect messaging 1. Message payload does not conform to service contract. Compare your SOAP message to the service contract produced by the Deployment Console to ensure compliance. Many 3rdparty tools are available that automatically validate an XML document (in this case, the SOAP message) to its schema (in this case, the WSDL service contract). Notice that if Corticon Server cannot even parse the inbound SOAP message, no entry will be made in Corticon Servers log. Instead, the error message will be displayed directly in the web server console, as shown below:
Figure 225 Server Console Message Highlighting Incorrect SOAP Request Structure
2. Incorrect or missing Decision Service Name. Ensure the SOAP messages Decision Service Name attribute matches the name of the Decision Service as it was deployed by either a deployment descriptor file or an API method call. See figure below.
January 13, 2012
Rule Modeling Guide
Page 208
Figure 226 Log Excerpt Highlighting Missing Decision Service Name in SOAP Request
Corticon Server licensing problem 1. License not installed. Your CcLicense.jar license file must be located in the same directory as the CcServer.jar file. In the default installation, CcServer.jar appears in both
<corticon_install_dir>\Studio\configuration\org.eclipse.osgi\bund les\6\1\.cp\lib and <corticon_install_dir>\Server\Tomcat\webapps\axis\WEB-INF\lib, so
ensure your valid license file appears in both locations as well. 2. If you are using one of the .war or .ear packages provided in <corticon_install_dir>\Samples, then be sure that those packages also include valid copies of CcLicense.jar. 3. License expired. See your Corticon liaison for an updated license file.
Figure 227 Maintenance Message on Server Console
January 13, 2012
Rule Modeling Guide
Page 209
Figure 228 Log Excerpt Highlighting License Expiration Message
4. License capacity exceeded. License capacity is measured in several ways: Number of unique Decision Services that may run concurrently in Corticon Server. Make sure your license can support the total number of unique .erf files referenced by deployed .cdd files. Number of copies of Decision Services the Server may create to handle transaction volume (known as Reactors). Make sure your license can support the max pool size specified in the deployed .cdd files. See figure below. Number of rules allowed for all Decision Services deployed. Make sure your license can support the total number of rules contained in all the deployed .erf files. IP address (or multiple) allowed. Make sure your license URL address matches the address of your Corticon Server. Number of transactions per time period allowed. Make sure your license can support the total number of transactions per time being requested of Corticon Server.
January 13, 2012
Rule Modeling Guide
Page 210
Figure 229 Log Excerpt Highlighting License Pool Limitation
Deployment Descriptor (.cdd) file problems 1. Missing .erf file. The .erf file has been moved and is no longer located in the directory referenced by the .cdd file.
Figure 230 Log Excerpt Highlighting Incorrect .erf Path
2. Missing .cdd file. The .cdd file is missing from the \cdd directory, or the taskname contained in the SOAP request message does not match any of the tasknames in any of the .cdd files deployed to Corticon Server.
January 13, 2012
Rule Modeling Guide
Page 211
Figure 231 Log Excerpt Highlighting Unknown Decision Service Name
3. Missing \cdd directory. The proper location of this directory (when installed using default parameters) is
<corticon_install_dir>\Server\Tomcat\CcServer\cdd
Figure 232 Log Excerpt Highlighting Missing \cdd Directory
Object translation errors due to incorrect Vocabulary external name mappings 1. External names mapped incorrectly 2. External data types specified incorrectly 3. ALL entities must be mapped, even those with all transient attributes
TEST YOURSELF
Answers are provided in Appendix D. 187. Troubleshooting is based on the principle that Rulesheets behave the same way when tested in Studio as when executed on ___________.
January 13, 2012
Rule Modeling Guide
Page 212
188. The first step in troubleshooting a suspected rule problem is to reproduce the behavior in a Studio _________ (test) 189. If the Rulesheet executes correctly in Studio, then where does the problem most likely occur? 190. Which of the following problems requires you to contact Corticon Support for help? Fatal Error Null Pointer Exception Reactor Error Expired License
191. The specific rule where execution behavior begins acting abnormally is called the _____________. 192. True or False. When a rule fires, some of its Actions may execute and some may not. 193. What Studio tools help you to identify the Rulesheets breakpoint? 194. A dark gray-colored Rulesheet box within a Ruleflow indicates that the Rulesheet has been __________. 195. A disabled rule: a. executes in a Studio Test but not on the Server b. executes on the Studio but not in a Studio Test c. executes in both Studio Tests and on the Server d. executes neither in a Studio Test nor on the Server 196. Where is the Server loglevel setting located? 197. To produce a more detailed Server log file, what loglevel setting should be enabled? 198. True or False. The Server license file needs to be located everywhere the Corticon Server is installed. 199. If you are reporting a possible Studio bug to Corticon Support, what minimum information is needed to troubleshoot? 200. Which of the following cannot be disabled? a. a Condition row
January 13, 2012
Rule Modeling Guide b. an Action row c. a Filter row d. a leaf of the Scope tree e. a Noncondition row (i.e., an Action row in Column 0) f. a rule column g. a Rulesheet h. a Ruleflow
Page 213
January 13, 2012
Rule Modeling Guide
Page 214
APPENDIX A: STANDARD BOOLEAN CONSTRUCTIONS

AND
In a decision table, a rule with ANDed Conditions is expressed as a single column, with values for each Condition aligned vertically in that column. For example:
In this scenario, each Condition has a set of 2 possible values: person is 45 or older: person is a smoker: persons risk rating:
{true, false} {true, false}
and the outcome may also have two possible values:

{low, high}
These Conditions and Actions yield the following truth table:

age >= 45 smoker risk rating
true true false false
true false true false
high
Note that we have only filled in a single value of risk rating, because the business rule above only covers a single scenario: where age >= 45 and smoker = true. A Completeness Check quickly identifies the remaining 3 scenarios:
January 13, 2012
Rule Modeling Guide
Page 215
Completing the truth table and the Rulesheet requires the definition of 2 additional business rules:
and updating the truth table, we recognize the classic AND Boolean function.
high low low low
Once the basic truth table framework has been established in the Rulesheet by the Completeness Checker in other words, all logical combinations of Conditions have been explicitly entered as separate columns in the Rulesheet we can alter the outcomes to implement other standard Boolean constructions. For example, the NAND construction has the following truth table:
January 13, 2012
Rule Modeling Guide
Page 216
NAND
low high high high
Also known as Not And, this construction is shown in the following Rulesheet:
January 13, 2012
Rule Modeling Guide
Page 217
OR
high high high low
January 13, 2012
Rule Modeling Guide
Page 218
XOR
Using Exclusive Or logic, riskRating is high whenever the age or smoker test, but not both, is satisfied. This construction is shown in the following Rulesheet:
age >= 45
smoker
risk rating
low high high low
January 13, 2012
Rule Modeling Guide
Page 219
NOR
Also known as Not Or, this construction is shown in the following Rulesheet:
low low low high
January 13, 2012
Rule Modeling Guide
Page 220
XNOR
Also known as Exclusive NOR, this construction is shown in the following Rulesheet:
high low low high
January 13, 2012
Rule Modeling Guide
Page 221
APPENDIX B: EXTENDED TRANSIENTS IN THE VOCABULARY

As described in Building the Vocabulary, extended transient terms may be used to carry or hold values while rules are executing within a single Corticon Rulesheet. Since XML messages returned by a Decision Service do not contain extended transient attributes, these attributes and their values cannot be used by external components or applications. If an attribute value is used by an external application or component, it must be a base attribute. To remind the rule modeler which attributes are base and which are extended transient, Studio colorcodes attribute icons as follows:
Figure 233 Vocabulary Editor Showing an Extended Transient Attribute
Notice that the extended transient attribute packDate is colored orange in the Vocabulary tree. XML response messages created by Server will not contain the packDate attribute.Appendix C: Answers to Test Yourself Questions
January 13, 2012
Rule Modeling Guide
Page 222
APPENDIX C: CORTICON STUDIO AND SERVER 5.2 PRODUCT DOCUMENTATION

Rule Language Guide
January 13, 2012
Rule Modeling Guide
Page 223
APPENDIX D: ANSWERS TO TEST YOURSELF QUESTIONS

jump to questions 1. any 3 of the following: a. provides terms that represent business things b. provides terms that are used to hold transient (temporary) values within Studio c. provides a federated data model that consolidates entities and attributes from various enterprise data resources d. provides a built-in library of literal terms and operators that can be applied to entities and attributes e. defines a schema that supplies the contract for sending data to and from a Corticon Decision Service 2. False. The Vocabulary may include transient terms that are used only in rules and that dont exist in the data model. False. Terms in the data model that are not used by rules do not need to be included in the Vocabulary. False. A Vocabulary may be created before its corresponding object or data model exists. The Vocabulary is an abstract model, meaning many of the real complexities of an underlying data model are hidden so that the rule author can focus on only those terms relevant to the rules. The UML model that contains the same types of information as a Vocabulary is called a Class Diagram Entities, Attributes, Associations hairColor yellow
3.
4. 5.
6.
7. 8. 9.
10. Attributes
January 13, 2012
Rule Modeling Guide 11. Boolean, DateTime, Decimal, Integer, String 12. blue and yellow 13. orange and yellow
Page 224
14. An Extended Transient Vocabulary term is used when the term is needed to hold a temporary value that is not required to be stored in external data. 15. Associations are bidirectional by default 16. cardinality 17. 18. 19. Target.source.attribute 20. target 21.
22.
January 13, 2012
Rule Modeling Guide
Page 225
23. identify terms, separate terms, assemble and relate terms, diagram vocabulary remove answer from question 24. a 25. operators 26. Rule Language Guide 27. False. Custom Data Types must be based on the 7 base data types. They extend the 7 base data types. 28. b. May match other Custom Data Type Names 29. True 30. value < 10 31. True 32. No 33. Airbus 34. Attribute values are pre-populated in pulldowns based on the enumerated values. 35. Allow you to re-use entities by bundling or creating a sub-set within the vocabulary. (technically equivalent to packages in Java or namespaces in XML.)
Rule Modeling Guide 36. True. 37. True.
Page 226
38. All entities have native attributes, but Bicyle = 100% native, the others have 1 native attribute each and 3 inherited. Entities with inherited attributes = MountainBike, RoadBike,
TandemBike
39. cadence, gear, or speed 40. True.
RULE SCOPE & CONTEXT

jump to questions 41. 7 root-level entities are present 42. all terms are allowed except DVD.actor 43. Movie.supplier 44. a. Movie.oscar b. Movie.roles c. Actor.roles d. DVD.supplier e. Movie.dVD.extras f. Actor.roles.movie.oscar 45. Actor.roles.movie 46. Since the association between Actor and Role is bidirectional, we can use both Actor.roles and Roles.actor in our rules. 47. Movie and Award 48. from Movie to Award: goldenGlobe and oscar. From Award to Movie: two unique rolenames exist for this perspective, too, but are not visible in the Vocabulary diagram.
January 13, 2012
Rule Modeling Guide
Page 227
49. The Award entity could be split into two separate entities, or an attribute could be added to Award to identify the type of award. 50. Using roles helps to clarify rule context. 51. unique 52. True 53. all examples shown are Boolean expressions 54. can use Movie if it is the root term, or DVD.movie if DVD is the root term The root term can either be Movie or DVD no conditions in the rule prevent either one from being the root term 55. can use Movie.dVD if Movie is the root term, or DVD if it is the root term The root term can either be Movie or DVD no conditions in the rule prevent either one from being the root term 56. False. Both Movie and DVD terms in this example are root terms with no relationship to each other. 57. Once for the Movie satisfying the rule conditions and its associated DVD 58. Twice: once for each DVD (i.e. the cross product of the DVDs and the Movie satisfying the rule conditions) 59. a. High b. Low c. Low for each DVD d. Twice: once for each DVD e. Four: each of the 2 rules fired 2 times f. cross product g. no, each rule should only fire once for the DVD associated with the Movie h. change the Movie and DVD terms to share the same scope, starting either with Movie as the root term (Movie and Movie.dVD) or DVD as the root term (DVD and DVD.movie)
January 13, 2012
Rule Modeling Guide
Page 228
60. False. Aliases are only required to be used in certain circumstances, but they can be used at any time and provide a good way of simplifying rule expressions. 61. Scope is another way of defining a specific context or perspective in the Vocabulary 62. be updated 63. False. Each alias must be unique and cannot have the same spelling as any term in the Vocabulary.
RULE WRITING TECHNIQUES LOGICAL EQUIVALENTS

jump to questions 64. Preconditions act as master rules for all other rules in the same Rulesheet that share the same scope 65. An expression that evaluates to a True or False value is called a Boolean expression 66. True 67. False. The requirement for complete Values sets only applies to Condition rows. 68. The special term other can be used to complete any Condition row values set. 69. not 70. { T , F } 71. all except Entity.boolean=F are equivalent, however some expressions are more clear than others! 72. Entity.boolean is probably the best choice since it is the simplest and most straightforward. The other two choices use double negatives which are harder for most people to understand. 73. a. OK as is b. if the value range is supposed to contain Integer values, then a does not belong. If the range is supposed to contain String values then 1 and a need to be surrounded by single quotes as in {1..a, other}
January 13, 2012
Rule Modeling Guide c. the special word other cant be used as a range endpoint. d. the range contains overlaps between 5 and 10, but this is acceptable in v5. e. the range contains an overlap at 10, but this is acceptable in v5. f. this is an incomplete set and should be {red, green, blue, other} g. the range contains overlaps between 3 and 15, but this is acceptable in v5.
Page 229
74. False. The term other may not be used in Action row Values sets since Actions can only assign specific values.
75. The Rulesheet would be modeled as shown above. 76. True 77. False. Nonconditional rules are governed by Preconditions on the same Rulesheet only if they share the same scope as the Preconditions.
January 13, 2012
Rule Modeling Guide
Page 230
COLLECTIONS
jump to questions 78. Children of a Parent entity are also known as elements of a collection. 79. False. A collection can be comprised of root-level entities. 80. True 81. True 82. Refer to the Rule Language Guide for a full list and description of all collection operators. 83. Rule Language Guide 84. Order total is equal to the sum of the line item prices on the order. 85. items 86. one-to-many (1->*) 87. It is not an acceptable replacement since the use of any collection operator requires that the collection be represented by an alias. 88. set the navigability of the association between Order and LineItem to Order->lineItem. In other words, make the association one-directional from Order to LineItem. 89. Optional, Convenient 90. A collection alias is not required in this case because no collection operator is being applied to the collection. 91. forAll 92. exists 93. a. aroles ->size > 3 where aroles is an alias for Actor.roles b. mdvd ->isEmpty where mdvd is an alias for Movie.dVD
Rule Modeling Guide
Page 231
c. mdextras ->exists(deletedScenes=T) where mdextras is an alias for Movie.dVD.extras d. mgglobes ->exists(win=T) where mgglobes is an alias for Movie.goldenGlobe e. mroles ->size > 15 where mroles is an alias for Movie.roles f. mdvd.quantityAvailable ->sum >= 100 where mdvd is an alias for Movie.dVD g. mdvd.quantityAvailable ->sum < 2 where mdvd is an alias for Movie.dVD h. mdsuppliers ->size > 1 where mdsuppliers is an alias for Movie.dVD.supplier 94. Actor, Distributor, DVDExtras 95. Actor, Movie 96. The ->forAll operator tests whether all elements of a collection satisfy a condition. The ->exists operator tests whether at least one element of a collection satisfies a condition. 97. The ->notEmpty operator tests whether a collection is not empty, meaning there is at least one element in the collection. The ->isEmpty operator tests whether a collection is empty, meaning there are no elements in the collection. 98. To ensure that the system knows precisely which collection (or copy) you are referring to in your rules, its necessary to use a unique alias to refer to each collection.
RULES CONTAINING CALCULATIONS & EQUATIONS

jump to questions 99. comparison in Preconditions and Conditions, assignment in Nonconditionals and Actions 100. a. 10 b. 13 c. 22 d. 24 e. 0 101. This assignment is not valid since an Integer attribute cannot contain the digits to the right of the decimal point in a Decimal attribute value. 102.
January 13, 2012
Rule Modeling Guide a. Integer b. String c. Boolean d. Decimal e. Boolean f. Boolean g. Boolean 103. a. valid b. invalid c. valid d. valid e. valid f. invalid g. valid 104. The part of Studio that checks for syntactical problems is called the Parser.
Page 232
105. False. Although the Parser in Studio is very effective at finding syntactical errors, it is not perfect and cant anticipate all possible combinations of the rule language. 106. This Filter tests if the difference between the current year and the year a movie was released is more than 10 years. 107. This Condition tests if the total quantity of DVDs available divided by the number of DVD versions of a movie is less than or equal to 50,000 or greater than 50,000. This same calculation could be performed by using the ->avg operator by itself. 108. If the average quantity available of a DVD is greater than 50,000 for a movie that is more than 10 years old, then flag the movie with a warning. 109. a. False b. False
January 13, 2012
Rule Modeling Guide c. True d. True e. True f. False g. False h. True
Page 233
RULE DEPENDENCY: DEPENDENCY & INFERENCING

jump to questions 110. Inferencing involves only a single pass through rules while looping involves multiple passes. 111. A loop that does not end by itself is known as an infinite loop. 112. A loop that depends logically on itself is known as a single-rule or trivial loop. 113. False. The Rulesheet must have looping enabled in order for the loop detector to notice mutual dependencies. 114. False. The Check for Logical Loops tool can only detect and highlight loops, not fix them. 115. No, looping is neither required nor desired for these rules. Normal inferencing will ensure the correct sequence of execution of these rules. 116. Yes, having this Rulesheet configured to Process All Logical Loops enables an infinite loop between rule 1 and rule 2 for DVDs meeting the conditions for that rule. 117. Rule 1 would change the DVDs price tier value to Medium, and then rule 2 and rule 1 would execute in an infinite loop, incrementing the DVDs quantity available by 25,000 repeatedly until terminating after the maxloop property setting number of iterations. 118. Process all logical loops 119. Process multi-rule loops only 120. A dependency network determines the sequence of rule execution and is generated when a Rulesheet is saved.
January 13, 2012
Rule Modeling Guide
Page 234
PRECONDITIONS & FILTERS

jump to questions 121. True 122. False - precondition behavior is optional 123. True - a filter will only apply to other rules that share the same scope. This means that other rules acting on data outside the filters scope will be unaffected. 124. anded 125. False. Preconditions/Filters are not stand-alone rules. 126. c 127. a 128. no 129. True 130. maximum 131. maximum filter only 132. minimum filter only 133. precondition AND maximum filter 134. f and d 135. a 136. Movie 1; DVD 1; Oscars 1, 2, 3, 4, 5 137. Movie 1; DVD 1; Oscars 1, 2, 3, 4, 5 138. Movie 1; DVD 1; Oscar 2
January 13, 2012
Rule Modeling Guide 139. Movie 1; DVD 1; Oscars 1, 2, 3, 4, 5 140. Movie 1; DVD 1; Oscars 1, 2 141. none 142. none 143. Movie 1; DVD 1; Oscars 1, 2, 3, 4, 5 144. Movie 1; DVD 1; Oscars 1, 2, 3, 4, 5 145. Movie 1; DVD 1; Oscars 1, 2, 3, 4, 5 146. none 147. Movie 1; DVD 1; Oscars 1, 2, 3, 4, 5 148. none 149. Movie 1; DVD 1 150. Movie 1; DVD 1; Oscars 1, 2, 3, 4, 5
Page 235
RECOGNIZING & MODELING PARAMETERIZED RULES

jump to questions 151. When several rules use the same set of Conditions and Actions, but different values for each, we say that these rules share a common pattern. 152. Another name for the different values in these expressions is parameter. 153. False. Its usually easier to model them as Conditions and Actions that use values sets. 154. You may accidentally introduce ambiguities into your rules. 155. X customers buy more than $Y of product each year
January 13, 2012
Rule Modeling Guide
Page 236
156. Type of customer: {Platinum, Gold, Silver, Bronze} and spend amount: {25000..50000, (50000..75000], (75000..10000], >100000}. Depending on how the rules are modeled, one of these values sets will be part of a Condition and should be completed with the special word other. 157. These parameters may be maintained in the values sets of an individual Rulesheet, which is easy to perform, but makes reuse more difficult. They may be maintained as Custom Data Types (Enumerated) in the Vocabulary, which makes reuse easier.
LOGICAL ANALYSIS & OPTIMIZATION

jump to questions 158. They have the same Conditions but different Actions. 159. All combinations of possible values from the Conditions values sets are covered in rules on the Rulesheet. 160. No, not all ambiguous rules are wrong or need to be resolved before deployment. Ambiguities may exist in Rulesheets where there are rules that are completely unrelated to each other. In those cases, it may be desirable for both rules to fire if the Conditions for both are met. 161. No, not all incompletenesses are wrong or need to be resolved before deployment. Incomplete Rulesheets may be missing combinations of Conditions that cannot or should not occur in real data. In those cases, rules for such combinations may not make sense at all. 162. Conflict Checker second icon; Compression Tool fifth icon; Expansion Tool first icon; Collapse Tool third icon; Conflict Filter sixth icon. 163. An ambiguity can be resolved by 1) making the Actions match for both rules, or 2) by setting an override for one of the rules. 164. False. Defining an override does not specify an execution sequence, but rather specifies that the rule with the override will always fire instead of the rule being overridden when the Conditions they share are satisfied. 165. False. The Completeness Checker will auto-complete the Conditions value set prior to inserting missing rules. This ensures the Rulesheet, post-application of the Completeness Check, is truly complete. 166. The Completeness Checker will detect Rulesheet incompleteness caused by an incomplete values set because it will automatically complete the value set first before inserting missing columns.
January 13, 2012
Rule Modeling Guide
Page 237
167. Yes. One rule can override multiple other rules by holding the Ctrl key to multi-select overrides from the drop-down. 168. No, overrides are not transitive and must be specified directly between all applicable rules. 169. No, rules created by the Completeness Checker may be comprised of combinations of Conditions that cannot or should not occur in real data. In those cases, rules for such combinations may not make sense at all. 170. A dash specifies that the Condition should be ignored for this rule. 171. False. The Expansion Tool merely expands a Rulesheet so that all sub-rules are visible. The results can be reversed by using the Collapse Tool. 172. True. It may be reversible using Undo, or by manually removing redundant sub-rules after expansion. 173. 64 (4 x 4 x 4) 174. It is not necessary to assign actions for a rule column if that combination of conditions cannot or should not exist in real data. We recommend disabling columns added by the Completeness Check that you determine need no Actions. 175. They may be disabled, deleted, or just left as-is with no Actions (but this last option is not recommended since it will still cause activity which can impact performance). 176. Compression Tool 177. The compression performed by the Completeness Checker is designed to reduce a large set of missing rules into the smallest set of non-overlapping columns, while the compression performed by the Compression Tool is designed to reduce the number of rules into the smallest set of general rules (i.e. create columns with the most dashes). 178. Even very large databases may still not contain all possible combinations of data necessary to verify Rulesheet completeness. In short, they may be incomplete themselves. 179. Renumber the rules and potentially ask you to consolidate Rule Statements if duplicate row numbers result from the renumbering.
January 13, 2012
Rule Modeling Guide
Page 238
180. Subsumation occurs when the Compression Tool detects that a more general rule expression includes the logic of a more specific rule expression. In this case, the more specific rule can be removed.
RULEFLOW VERSIONING & EFFECTIVE DATING

jump to questions 181. False. Ruleflow Effective and Expiration dates may be assigned singly. 182. False. Ruleflow Effective and Expiration dates may be assigned singly. 183. False. Ruleflow Version numbers are optional. 184. Ruleflow Properties, or click on the Properties window in Studio. 185. False. A Ruleflow Version number may only be raised, not lowered. 186. False. Ruleflow Effective and Expiration dates are optional.
TROUBLESHOOTING RULESHEETS
jump to questions 187. Troubleshooting is based on the principle that Rulesheets behave the same way when tested in Studio as when executed on Server 188. The first step in troubleshooting a suspected rule problem is to reproduce the behavior in a Studio Test. 189. In the integration with Corticon Server. 190. All of them! 191. The specific rule where execution behavior begins acting abnormally is called the breakpoint. 192. True. In v5, partial rule firing is allowed. 193. Disabling Rulesheets; Filters, Nonconditions, Conditions, Action rows; or rule columns 194. A dark gray-colored Rulesheet tab indicates that Rulesheet has been disabled.
January 13, 2012
Rule Modeling Guide 195. d 196. loglevel is located in CcCommon.properties inside CcConfig.jar. 197. loglevel should be set to INFO 198. True.
Page 239
199. Vocabulary (.ecore), Rulesheet (.ers), and a Ruletest (.ert) and the Ruleflow (.erf) if any. We also need to know the Studio version youre using. 200. d and h
January 13, 2012
CORTICON
Business Rules Modeling Studio 5.2 Rule Language Guide
Rule Language Guide
Page i
TABLE OF CONTENTS
Table of Contents ........................................................................................................................................................i Preface ........................................................................................................................................................................1 Intended Audience .................................................................................................................................................1 Corticon Business Rules Management Technical Publications ..............................................................................1 Documentation Conventions .................................................................................................................................1 Reading the PDF File ..............................................................................................................................................1 Introduction ................................................................................................................................................................2 Overview of the Corticon Rule Language...............................................................................................................2 Rule Structure ....................................................................................................................................................2 Basic Data Types ................................................................................................................................................2 Truth Values .......................................................................................................................................................3 Collection Operators ..........................................................................................................................................3 Language Operators...........................................................................................................................................3 Generic Business Vocabulary......................................................................................................................................4 Rule Operators ...........................................................................................................................................................5 Organization ...........................................................................................................................................................5 Icons .......................................................................................................................................................................5 Tool Tips .................................................................................................................................................................6 Usage Restrictions ..................................................................................................................................................7 Rule Operator Summaries by Category ......................................................................................................................8 General Terms ........................................................................................................................................................8 Literals................................................................................................................................................................8 Functions............................................................................................................................................................8 Attribute Operators ...............................................................................................................................................9 Boolean ..............................................................................................................................................................9 DateTime............................................................................................................................................................9 Date................................................................................................................................................................. 13 Time ................................................................................................................................................................ 16 Decimal ........................................................................................................................................................... 19 Integer ............................................................................................................................................................. 22 String ............................................................................................................................................................... 25 Entity/Collection Operators ................................................................................................................................ 27 Entity ............................................................................................................................................................... 27 Collection ........................................................................................................................................................ 28 Sequence......................................................................................................................................................... 30 Rule Operators Sorted Alphabetically ..................................................................................................................... 32 Absolute Value......................................................................................................................................................... 33 Add Numbers ........................................................................................................................................................... 34
1/13/2012
Rule Language Guide
Page ii
Add Strings............................................................................................................................................................... 36 Add Days .................................................................................................................................................................. 37 Add Hours ................................................................................................................................................................ 38 Add Minutes ............................................................................................................................................................ 39 Add Months ............................................................................................................................................................. 40 Add Seconds ............................................................................................................................................................ 41 Add Years ................................................................................................................................................................. 42 Associate Element(s) ............................................................................................................................................... 43 At ............................................................................................................................................................................. 45 Average .................................................................................................................................................................... 47 CellValue .................................................................................................................................................................. 48 Concatenate ............................................................................................................................................................ 52 Contains ................................................................................................................................................................... 54 Day ........................................................................................................................................................................... 56 Days Between .......................................................................................................................................................... 58 Day of Week ............................................................................................................................................................ 60 Day of Year .............................................................................................................................................................. 62 Decrement ............................................................................................................................................................... 63 Disassociate Element(s) ........................................................................................................................................... 65 Divide ....................................................................................................................................................................... 66 Div ............................................................................................................................................................................ 68 Ends With ................................................................................................................................................................ 69 Equals used as an Assignment .............................................................................................................................. 70 Equals used as a Comparison ............................................................................................................................... 72 Equals Ignoring Case ................................................................................................................................................ 74 Equals Strings only ................................................................................................................................................ 75 Exists ........................................................................................................................................................................ 77 Exponent.................................................................................................................................................................. 79 False ......................................................................................................................................................................... 81 First .......................................................................................................................................................................... 83 Floor......................................................................................................................................................................... 85 For All....................................................................................................................................................................... 86
1/13/2012
Rule Language Guide
Page iii
Greater Than............................................................................................................................................................ 88 Greater Than Or Equal To ........................................................................................................................................ 90 Hour ......................................................................................................................................................................... 92 Hours Between ........................................................................................................................................................ 94 Increment ................................................................................................................................................................ 96 Index Of ................................................................................................................................................................... 98 Is Empty ................................................................................................................................................................. 100 Iterate .................................................................................................................................................................... 102 Last ........................................................................................................................................................................ 104 Less Than ............................................................................................................................................................... 106 Less Than Or Equal To............................................................................................................................................ 108 Logarithm (Base 10)............................................................................................................................................... 110 Logarithm (Base x) ................................................................................................................................................. 112 Lowercase .............................................................................................................................................................. 114 Maximum Value .................................................................................................................................................... 116 Maximum Value (Collection) ................................................................................................................................. 118 Minimum Value ..................................................................................................................................................... 119 Minimum Value (Collection).................................................................................................................................. 121 Minute ................................................................................................................................................................... 122 Minutes Between .................................................................................................................................................. 123 Mod ....................................................................................................................................................................... 125 Month .................................................................................................................................................................... 126 Months Between ................................................................................................................................................... 128 Multiply ................................................................................................................................................................. 130 Natural Logarithm ................................................................................................................................................. 132 New........................................................................................................................................................................ 134 New Unique ........................................................................................................................................................... 136 Not ......................................................................................................................................................................... 138 Not Empty .............................................................................................................................................................. 140 Not Equal To .......................................................................................................................................................... 141 Now ....................................................................................................................................................................... 143 Null ........................................................................................................................................................................ 145
1/13/2012
Rule Language Guide
Page iv
Other...................................................................................................................................................................... 147 Or ........................................................................................................................................................................... 149 Remove Element ................................................................................................................................................... 151 Replace Element(s) ................................................................................................................................................ 154 Round .................................................................................................................................................................... 156 Second ................................................................................................................................................................... 158 Seconds Between .................................................................................................................................................. 159 Size of String .......................................................................................................................................................... 161 Size Of Collection ................................................................................................................................................... 162 Sorted By ............................................................................................................................................................... 164 Sorted By Descending ............................................................................................................................................ 167 Starts With ............................................................................................................................................................. 170 Substring ................................................................................................................................................................ 172 Subtract ................................................................................................................................................................. 174 Sum ........................................................................................................................................................................ 176 Today ..................................................................................................................................................................... 178 To Date Casting a DateTime to a Date................................................................................................................ 180 To DateTime Casting a String to a DateTime ...................................................................................................... 181 To DateTime Casting a Date to a DateTime........................................................................................................ 182 To DateTime Casting a Time to a DateTime ....................................................................................................... 183 To DateTime Timezone Offset ............................................................................................................................ 184 To Decimal ............................................................................................................................................................. 185 To Integer .............................................................................................................................................................. 187 To String................................................................................................................................................................. 189 To Time Casting a DateTime to a Time ............................................................................................................... 190 Trend ..................................................................................................................................................................... 191 True........................................................................................................................................................................ 193 Uppercase .............................................................................................................................................................. 195 Week of Month ..................................................................................................................................................... 196 Week of Year ......................................................................................................................................................... 197 Year ........................................................................................................................................................................ 198 Years Between ....................................................................................................................................................... 200
1/13/2012
Rule Language Guide
Page v
Special Syntax ........................................................................................................................................................ 201 Value Ranges ..................................................................................................................................................... 201 Numeric Value Ranges in Conditions ............................................................................................................ 201 Numeric Value Ranges in Filter Rows ........................................................................................................... 201 String Value Ranges in Condition Cells ......................................................................................................... 202 String Value Ranges in Filter Rows................................................................................................................ 202 DateTime, Date, and Time Value Ranges in Condition Cells......................................................................... 202 DateTime, Date, and Time Value Ranges in Filter Rows ............................................................................... 203 Inclusive & Exclusive Ranges ......................................................................................................................... 203 Overlapping Value Ranges ............................................................................................................................ 204 Using Value Sets in Condition Cells ................................................................................................................... 206 Embedding Attributes in Posted Rule Statements............................................................................................ 208 No expressions in Rule Statements .............................................................................................................. 209 Including Apostrophes in Strings ...................................................................................................................... 209 Advanced Collection Syntax .............................................................................................................................. 210 Step 1 ............................................................................................................................................................ 210 Step 2 ............................................................................................................................................................ 210 Step 3 ............................................................................................................................................................ 210 Step 4 ............................................................................................................................................................ 210 Statement Blocks .............................................................................................................................................. 211 Important Notes about Statement Blocks .................................................................................................... 212 Appendix A: Character Precedence: Unicode & Java Collator ............................................................................. 214 Appendix B: Arithmetic Operator Precedence ..................................................................................................... 218 Appendix C: DateTime Data Type ......................................................................................................................... 219 Formats or Masks.............................................................................................................................................. 219 Presentation and Persistence ........................................................................................................................... 219 Appendix D: Corticon Studio and Server 5.2 Product Documentation ............................................................... 220
1/13/2012
Rule Language Guide
Page 1
PREFACE
INTENDED AUDIENCE
Rule Language Guide provides detailed information necessary to assist you in using the Corticon Rule Language to build rules in Studio. This guide is intended for use by technical business analysts and application developers. This document assumes that you are familiar with the Studio and its usage. For assistance in using Studio, refer to Studios Online Help or Studio Quick Reference Guide.
CORTICON BUSINESS RULES MANAGEMENT TECHNICAL PUBLICATIONS

For a detailed listing of current Corticon technical publications, see Appendix D.
Studio documentation uses the following conventions: Document names are shown in bold face italic type: Rule Modeling Guide Screen, Window, and button names are shown in bold face type: Custom Setup screen Important information such as Notes, Tips and Warnings are shown in this color scheme: The Complete setup option is automatically selected. Hyperlinks are underlined and shown in blue: the cursor changes to a hand: Introduction File names and user-defined information are shown in this font and color: Installing.pdf
READING THE PDF FILE

Corticon Business Rules Management product documentation is distributed in Adobe Portable Document Format (PDF). You can use the Adobe Reader toolbar and features to easily navigate through the document. Choose Help>Reader Guide from the toolbar to display Using Acrobat Reader. Refer to the topic Paging Through A Document for further assistance.
1/13/2012
Rule Language Guide
Page 2
INTRODUCTION
OVERVIEW OF THE CORTICON RULE LANGUAGE
Graphical modeling languages and tools (UML, ER, ORM, for example) are not sufficiently precise for specifications. Additional constraints on the objects in the model must also be defined. While natural languages are easily used by individuals without a programming background, they are often ambiguous. On the other hand, formal programming languages are precise, but not easily used by business analysts and other non-programmers. The Corticon Rule Language has been developed to resolve this dilemma. Based on the Object Constraint Language (OCL, an extension of the Universal Modeling Language specification 1.1), the Corticon Rule Language (CRL) is designed to enable non-programmers to express rules clearly and precisely without the use of procedural programming languages. More information on OCL may be found at www.uml.org.
Rule Structure
In traditional programming languages (or logic systems), most rules are expressed via IF/THEN structures. The IF clause contains a conditional expression and the THEN clause contains actions the rule should perform if all conditions have been met. This IF/THEN structure is expressed as Conditions and Actions in the Rulesheet user interface of Studio. For more information on building and organizing rules in Studio, see the Basic Tutorial for Corticon Studio Modeling Rules.
Basic Data Types

The proper expression and execution of rules in Studio is dependent on the type of data involved. Each attribute in the Studio Business Vocabulary has a data type, meaning that it has restrictions on the type of data it may contain. Corticon standard data types as listed and described in the following table: Data Type String Integer Decimal Boolean DateTime Date Time Description Any combination of alphanumeric characters, of any length A whole number, including zero and negative numbers, of any length A number containing a decimal point, including zero and negative numbers, of any length Values are true and false. T and F may also be used. Values must be entered for both date and time. A value with only date information. No Time information is allowed. Value with only time information. No Date information is allowed.
1/13/2012
Rule Language Guide
Page 3
In this guide, the data types Integer and Decimal are often referred to by the generic term <Number>. Wherever <Number> is used, either Integer or Decimal data types may be used. Syntax such as <DateTime> indicates that data must conform to the data type shown in angle brackets (<..>). For this example, you might enter 9/13/2001 2:00:00 PM EST. Do not type the angle brackets themselves. See Appendix C for further details on formatting DateTime, Date, and Time information.
Truth Values
This guide uses the notation <Expression> to refer to some combination of terms from the Vocabulary that resolves or evaluates to a single truth value. A truth value is the Boolean value (true or false) assigned to an expression upon evaluation by the rule engine. For example, the expression Patient.name=John has a truth value of true whenever the patients name is John. If it is not John, then the truth value of this expression is false.
Collection Operators
Many of the operators provided in the CRL deal exclusively with collections of entities. When using collection operators, the expression must use aliases to represent the collection(s) operated on by the collection operator(s). A complete discussion of aliases is included in the Rule Modeling Guide. Reminders are included throughout this manual wherever collection operators are referenced.
Language Operators
CRL operators can be grouped into various classifications as shown in the following tables. Each operator is subsequently described in detail in the Language Reference section of this document. This section includes a detailed description of the operator, its syntax, usage restrictions, and a real example in a Studio Rulesheet.
1/13/2012
Rule Language Guide
Page 4
GENERIC BUSINESS VOCABULARY

The Rule Language Guide uses a generic Business Vocabulary in all examples that follow. The Vocabulary contains four entities, each of which contains the same attribute names and types. Attribute names reflect their data types. For example, integer1 has a data type of Integer. This generic Business Vocabulary provides sufficient flexibility to create examples using all operators and functions in the Corticon Rule Language. Entity1 is shown expanded in Figure 1 below.
Figure 1 - Generic Business Vocabulary used in All Examples
1/13/2012
Rule Language Guide
Page 5
RULE OPERATORS
ORGANIZATION
Rule Operators are classified based on the data type(s) of the terms to which the operator may be applied (known as the operand), as shown in Figure 2:
Figure 2 - Rule Operators Window with Categories Shown
ICONS
Rule Operators are assigned icons which provide the user with information about their usage. The following table describes these icons: Icon Where Found
General, Literals category General, Functions category Operators, Boolean category Operators, all categories
Purpose
indicates special values or constants indicates system values that are automatically retrieved upon rule execution. this special unary operator icon is used only with not indicates the operator uses a period . to attach to its operand. Most operators with this icon typically fell into the previous function category. indicates the operator is used between two operands. Most operators with this icon typically fell into the previous comparison category.
Examples null, true, other now, today not day, round, contains equals, multiply
Operators, all categories
1/13/2012
Rule Language Guide

Operators, Collection & Sequence categories Extended Operators indicates the operator is used with collections or sequences. Also indicates an alias must be used to represent the collection operated on. indicates the operator has been added to the Vocabulary using the extension framework described in Appendix D.
Page 6
sum, size
see Appendix
TOOL TIPS
In Studio, moving the mouse over a Vocabulary operator and pausing, or hovering for a moment, will cause a dynamic tool tip text box to display. This tool tip contains information about operator syntax, return data type, and description, all of which are supplied in more detail in this Guide. For questions not answered by the tool tip, refer to the detailed operator descriptions in this Guide. Figure 3 shows a typical tool tip for the date operator .monthsBetween:
Figure 3 - Typical Rule Operator Tool Tip
1/13/2012
Rule Language Guide
Page 7
USAGE RESTRICTIONS
Figure 4 and Figure 5 show the general usage restrictions for the various types of Vocabulary terms depending on where they are used in a Rulesheet. This table indicates, for example, that entities (terms from the Business Vocabulary) may be used in any section of the Rulesheet. Rule Operators, on the other hand, are restricted to only 3 sections. Note: some operators have specific restrictions that vary from this general table please see each operators usage restrictions for details of these exceptions. Rulesheet Section
Name Scope Filter Rows Condition Rows Condition Cells Actions Rows Action Cells Rule Statements
Rulesheet Section #
Literals Functions Operators Data Values Terms
Figure 4 - Summary Table of Vocabulary Usage Restriction
7
Figure 5 - Sections of Rulesheet: Numbers Correlate with Table Above
1/13/2012
Rule Language Guide
Page 8
RULE OPERATOR SUMMARIES BY CATEGORY

The following tables show the name, syntax, returned data type (as applicable) and brief description for each operator, sorted by category. The categories correspond to those displayed in the Studio Vocabulary.
GENERAL TERMS
Literal Terms may be used in any section of the Rulesheet, except Scope and Rule Statements. Exceptions to this general statement exist see individual literals for detailed usage restrictions.
Literals
Name Null null none The null value corresponds to one of three different scenarios: True true or T False false or F Other other CellValue cellValue any cellValue is a variable whose value is determined by the rule Column that executes any When included in a conditions Values set, other represents any value not explicitly included in the set, including null. Boolean Represents the Boolean value false Boolean Represents Boolean value true the absence of an attribute in a Ruletest scenario the absence of data for an attribute in a Ruletest scenario an object that has a value of null Syntax Returned Data Type Description
Functions
Name Now Syntax Returned Data Type Description
1/13/2012
Rule Language Guide

now Today today Date Date
Page 9
Returns the current system date and time when the rule is executed.
Returns the current system date when the rule is executed.
ATTRIBUTE OPERATORS
The operators summarized in the tables below may be applied to attributes only. They are listed by attribute datatype.
Boolean
Name Syntax Returned Data Type Description
Equals (used as a comparison) <Expression1> = <Expression2> Equals (used as an assignment) <Boolean1> = <Expression1> Not Equal To <Expression1> <> <Expression2> Boolean Returns a value of true if <Expression1> does not have the same truth value as <Expression2> Boolean Assigns the truth value of <Expression1> to <Boolean1> Boolean Returns a value of true if <Expression1> has the same value as <Expression2>.
Or <Expression1> or <Expression2> or Boolean Returns a value of true if either <Expression1> or <Expression2> evaluates to true.
Not not <Expression> Boolean Returns the negation of the truth value of <Expression>
DateTime
Note: A DateTime data type must contain both date information and time information. Applying a DateTime operator to a DateTime attribute should always produce a result. Be sure to use the data type that suits your needs.
1/13/2012
Rule Language Guide

Page 10
Equals (used as a comparison) <DateTime1> = <DateTime2> Boolean Returns a value of true if <DateTime1> is the same as <DateTime2>, including both the Date and the Time portions
Equals (used as an assignment) <DateTime1> = <DateTime2> Not Equal To <DateTime1> <> <DateTime2> Less than <DateTime1> < <DateTime2> Greater than <DateTime1> > <DateTime2> Less than or Equal to <DateTime1> <= <DateTime2> Greater than or Equal to <DateTime1> >= <DateTime2> Year <DateTime>.year Month <DateTime>.month Day <DateTime>.day Hour Integer Returns the day portion of <DateTime> as an Integer between 1 and 31 Integer Returns the month in <DateTime> as an Integer between 1 and 12 Integer Returns the century/year portion of <DateTime> as a four digit Integer Boolean Returns a value of true if <DateTime1> is greater than or equal to <DateTime2> Boolean Returns a value of true if <DateTime1> is less than or equal to <DateTime2> Boolean Returns a value of true if <DateTime1> is greater than or equal to <DateTime2> Boolean Returns a value of true if <Date1> is less than <Date2> Boolean Returns a value of true if <DateTime1> does not equal <DateTime2> DateTime Assigns the value of <DateTime2> to <DateTime1>
1/13/2012
Rule Language Guide

Name Syntax <DateTime>.hour Returned Data Type Integer Description
Page 11
Returns the hour portion of <DateTime>. The returned value is based on a 24-hour clock.
Minute <DateTime>.min Integer Returns the minute portion of <DateTime> as an Integer between 0 and 59
Second <DateTime>.sec Integer Returns the seconds portion of <DateTime> as an Integer between 0 and 59
Add years <DateTime>.addYears(<Integer>) Add months <DateTime>.addMonths(<Integer>) Add days <DateTime>.addDays(<Integer>) Add hours <DateTime>.addHours(<Integer>) Date Adds the number of hours in <Integer> to the number of hours in the Time portion of <DateTime> Date Adds the number of days in <Integer> to the number of days in <DateTime> Date Adds the number of months in <Integer> to the number of months in <DateTime> Date Adds the number of years in <Integer> to the number of years in <DateTime>
Add minutes <DateTime>.addMinutes(<Integer>) Date Adds the number of minutes in <Integer> to the number of minutes in the Time portion of <DateTime>
Add seconds <DateTime>.addSeconds<Integer>) Date Adds the number of seconds in <Integer> to the number of seconds in the Time portion of <DateTime>
Years between
1/13/2012
Rule Language Guide

Name Syntax <DateTime1>.yearsBetween(<DateTime2 >) Returned Data Type Integer Description
Page 12
Returns the Integer number of years between <DateTime1> and <Date2>. This function returns a positive number if <DateTime2> is later than <DateTime1>.
Months between <DateTime1>.monthsBetween(<DateTim e2>) Integer Returns the Integer number of months between <DateTime1> and <DateTime2>. If the month and year portions of <DateTime1> and <DateTime2> are the same, the result is zero. This function returns a positive number if <DateTime2> is later than <DateTime1>.
Days between <DateTime1>.daysBetween(<DateTime2> ) Integer Returns the Integer number of days between <DateTime1> and <DateTime2>. If the two dates differ by less than a full 24-hour period, the value is zero. This function returns a positive number if <DateTime2> is later than <DateTime1>.
Hours between <DateTime1>.hoursBetween(<DateTime2 >) Integer Returns the Integer number of hours between <DateTime1> and <DateTime2>. If the two dates differ by less than a full hour, the value is zero. This function returns a positive number if <DateTime2> is later than <DateTime1>.
Minutes between <DateTime1>.minsBetween(<DateTime2 >) Integer Returns the Integer number of minutes between <DateTime1> and <DateTime2>. This function returns a positive number if <DateTime2> is later than <DateTime1>.
Seconds between <DateTime1>.secsBetween(<DateTime2> ) Integer Returns the Integer number of seconds between <DateTime1> and <DateTime2>. This function returns a positive number if <DateTime2> is later than <DateTime1>.
Day of Week
1/13/2012
Rule Language Guide

Name Syntax <DateTime>.dayOfWeek Returned Data Type Integer Description
Page 13
Returns an Integer corresponding to day of the week, with Sunday equal to 1, in <DateTime>.
Week of Year <DateTime>.weekOfYear Integer Returns an Integer from 1 to 52, equal to the week number within the year in <DateTime>
Day of Year <DateTime>.dayOfYear Integer Returns an Integer from 1 to 366, equal to the day number within the year in <DateTime>
Week of Month <DateTime>.weekOfMonth Integer Returns an Integer from 1 to 6, equal to the week number within the month in <DateTime> or <Date>. A week begins on Sunday and ends on Saturday.
To Date <DateTime>.toDate To Time <DateTime>.toTime To String <DateTime>.toString String Converts DateTime to a String with date and time information Time Returns the time portion only of DateTime Date Returns the date portion only of DateTime
Date
Name Equals (used as a comparison) <Date1> = <Date2> Boolean Returns a value of true if < Date1> is the same as <Date2>, including both the Date and the Time portions Syntax Returned Data Type Description
1/13/2012
Rule Language Guide

Page 14
Equals (used as an assignment) < Date1> = <Date2> Not Equal To < Date1> <> <Date2> Less than < Date1> < <Date2> Greater than < Date1> > <Date2> Less than or Equal to < Date1> <= <Date2> Greater than or Equal to < Date1> >= <Date2> Year <Date>.year Month <Date>.month Day <Date>.day Add years <Date>.addYears(<Integer>) Add months Date Adds the number of years in <Integer> to the number of years in <Date> Integer Returns the day portion of <Date> as an Integer between 1 and 31 Integer Returns the month in <Date> as an Integer between 1 and 12 Integer Returns the century/year portion of <Date> as a four digit Integer Boolean Returns a value of true if < Date1> is greater than or equal to <Date2> Boolean Returns a value of true if < Date1> is less than or equal to <Date2> Boolean Returns a value of true if < Date1> is greater than or equal to <Date2> Boolean Returns a value of true if <Date1> is less than <Date2> Boolean Returns a value of true if < Date1> does not equal <Date2> DateTime Assigns the value of <Date2> to < Date1>
1/13/2012
Rule Language Guide

Name Syntax <Date>.addMonth(<Integer>) Returned Data Type Date Description
Page 15
Adds the number of months in <Integer> to the number of months in <Date>
Add days <Date>.addDays(<Integer>) Years between <Date1>.yearsBetween(<Date2>) Integer Returns the Integer number of years between <Date1> and <Date2>. This function returns a positive number if <Date2> is later than <Date1>. Date Adds the number of days in <Integer> to the number of days in <Date>
Months between <Date1>.monthsBetween(<Date2>) Integer Returns the Integer number of months between <Date1> and <Date2>. If the month and year portions of <Date1> and <Date2> are the same, the result is zero. This function returns a positive number if <Date2> is later than <Date1>.
Days between <Date1>.daysBetween(<Date2>) Integer Returns the Integer number of days between <Date1> and <Date2>. If the two dates differ by less than a full 24hour period, the value is zero. This function returns a positive number if <Date2> is later than <Date1>.
Day of Week <Date>.dayOfWeek Integer Returns an Integer corresponding to day of the week, with Sunday equal to 1, in <Date>.
Week of Year <Date>.weekOfYear Integer Returns an Integer from 1 to 52, equal to the week number within the year in <Date>
Day of Year
1/13/2012
Rule Language Guide

Name <Date>.dayOfYear Syntax Returned Data Type Integer Description
Page 16
Returns an Integer from 1 to 366, equal to the day number within the year in <Date>
Week of Month <Date>.weekOfMonth Integer Returns an Integer from 1 to 6, equal to the week number within the month in <DateTime> or <Date>. A week begins on Sunday and ends on Saturday.
To String <Date>.toString To DateTime <Date>.toDateTime DateTime Returns a DateTime where the date portion is equal to the value of <Date> and the time portion is equal to 00:00:00 in the systems local timezone String Converts DateTime to a String with date and time information
To DateTime with Timezone Offset <Date>.toDateTime(<string>) DateTime Returns a DateTime where the date portion is equal to the value of <Date> and the time portion is equal to 00:00:00 in the timezone specified by the value of <string>
Time
Name Equals (used as a comparison) <Time1> = <Time2> Boolean Returns a value of true if <Time1> is the same as <Time2>, including both the Date and the Time portions Syntax Returned Data Type Description
Equals (used as an assignment) <Time1> = <Time2> DateTime Assigns the value of <Time2> to <Time1>
1/13/2012
Rule Language Guide

Name Not Equal To <Time1> <> <Time2> Less than <Time1> < <Time2> Greater than < Time1> > <Time2> Less than or Equal to < Time1> <= <Time2> Greater than or Equal to < Time1> >= <Time2> Hour <Time>.hour Integer Boolean Boolean Boolean Boolean Boolean Syntax Returned Data Type Description
Page 17
Returns a value of true if <Time1> does not equal <Time2>
Returns a value of true if <Date1> is less than <Date2>
Returns a value of true if < Time1> is greater than or equal to <Time2>
Returns a value of true if < Time1> is less than or equal to <Time2>
Returns a value of true if < Time1> is greater than or equal to <Time2>
Returns the hour portion of <Time>. The returned value is based on a 24hour clock.
Minute <Time>.min Second <Time>.sec Integer Returns the seconds portion of <Time> as an Integer between 0 and 59 Adds the number of days in <Integer> to the number of days in <Time> Integer Returns the minute portion of <Time> as an Integer between 0 and 59
<Time>.addDays(<Integer>) Add hours <Time>.addHours(<Integer>)
Date
Date
Adds the number of hours in <Integer> to the number of hours in the Time portion of <Time>
Add minutes
1/13/2012
Rule Language Guide

Name Syntax <Time>.addMinutes(<Integer>) Returned Data Type Date Description
Page 18
Adds the number of minutes in <Integer> to the number of minutes in the Time portion of <Time>
Add seconds <Time>.addSeconds<Integer>) Date Adds the number of seconds in <Integer> to the number of seconds in the Time portion of <Time>
Hours between <Time1>.hoursBetween(<Time2>) Integer Returns the Integer number of hours between <Time1> and <Time2>. If the two dates differ by less than a full hour, the value is zero. This function returns a positive number if <Time2> is later than <Time1>.
Minutes between <Time1>.minsBetween(<Time2>) Integer Returns the Integer number of minutes between <Time1> and <Time2>. This function returns a positive number if <Time2> is later than <Time1>.
Seconds between <Time1>.secsBetween(<Time2>) Integer Returns the Integer number of seconds between <Time1> and <Time2>. This function returns a positive number if <Time2> is later than <Time1>.
To String <Time>.toString To DateTime <Time>.toDateTime DateTime Returns a DateTime where the time portion is equal to the value of <Time> and the date portion is equal to the epoch. String Converts <Time> to a String with date and time information
1/13/2012
Rule Language Guide
Page 19
Decimal
In this section, wherever the syntax includes <Number>, either Integer or Decimal data types may be used.
Equals (used as a comparison) <Number1> = <Number2> Equals (used as an assignment) <Number1> = <Number2> Not Equal To <Number1> <> <Number2> Less than <Number1> < <Number2> Greater than <Number1> > <Number2> Less than or Equal to <Number1> <= <Number2> Greater than or Equal to <Number1> >= <Number2> Add <Number1> + <Number2> Number Returns the sum of <Number1> and <Number2>. The resulting data type is the more expansive of either <Number1> or <Number2>. For example, if an Integer value is added to a Decimal value, the resulting value will be a Decimal. See Appendix B. Boolean Returns a value of true if <Number1> is greater than or equal to <Number2>. Boolean Returns a value of true if <Number1> is less than or equal to <Number2>. Boolean Returns a value of true if <Number1> is greater than <Number2>. Boolean Returns a value of true if <Number1> is less than <Number2>. Boolean Returns a value of true if <Number1> is not equal to <Number2>. Number Assigns the value of <Number2> to the value of <Number1>. Boolean Returns a value of true if <Number1> is the same as <Number2>.
Subtract
1/13/2012
Rule Language Guide

Name Syntax <Number1> - <Number2> Returned Data Type Number Description
Page 20
Subtracts <Number2> from <Number1>. The resulting data type is the more expansive of either <Number1> or <Number2>. See Appendix B.
Multiply <Number1> * <Number2> Number Returns the product of <Number1> and <Number2>. The resulting data type is the more expansive of either <Number1> or <Number2>. See Appendix B.
Divide <Number1> / <Number2> Number Divides <Number1> by <Number2>. The resulting data type is the more expansive of either <Number1> or <Number2>. See Appendix B.
Exponent <Number1> ** <Number2> Decimal Raises <Number1> to the power of <Number2>. The resulting data type is the more expansive of either <Number1> or <Number2>. See Appendix B.
Increment <Number1> += <Number2> Number Increments <Number1> by <Number2>. The data type of <Number1> must accommodate the addition of <Number2>. See Appendix B.
Decrement <Number1> -= <Number2> Number Decrements <Number1> by the value of <Number2>. The data type of <Number1> must accommodate the addition of <Number2>. See Appendix B.
Absolute Value <Decimal>.absVal Decimal Returns the absolute value of <Number>. If the <Number> is positive, <Number> itself is returned; if <Number> is negative, the negation of <Number> is returned.
Floor
1/13/2012
Rule Language Guide

Name <Decimal>.floor Syntax Returned Data Type Integer Description
Page 21
Returns the largest (closest to positive infinity) Integer that is not greater than <Number>.
Round <Decimal>.round Round(n) <Decimal>.round(<Integer>) To Integer <Decimal>.toInteger Integer Converts an attribute of type Decimal to type Integer. Decimals will have the decimal point and fraction (those digits to the right of the decimal point) truncated. Decimal Rounds <Decimal> to the number of decimal places specified by <Integer>. Decimal Rounds <Decimal> to the nearest Integer.
To String <Decimal>.toString Maximum Value <Decimal>.max(<Number>) Minimum Value <Decimal>.min(<Number>) Logarithm (base 10) <Decimal>.log Logarithm (base x) <Decimal1>.log(<Decimal2>) Decimal Returns the logarithm (base <Decimal2>) of <Decimal1>. <Decimal1> may not be zero. Decimal Returns the logarithm (base 10) of <Decimal>. <Decimal> may not be zero. Number Returns the lesser of <Decimal> and <Number>. Number Returns the greater of <Decimal> and <Number>. String Converts an attribute of type Decimal to type string
Natural Logarithm <Decimal>.ln Decimal Returns the natural logarithm (base e) of <Decimal>. <Decimal> may not be zero.
1/13/2012
Rule Language Guide
Page 22
Integer
In this section, wherever the syntax includes <Number>, either Integer or Decimal data types may be used.
Equals (used as a comparison) <Number1> = <Number2> Equals (used as an assignment) <Number1> = <Number2> Number Assigns the value of <Number2> to the value of <Number1>. The data type of <Number1> must be expansive enough to accommodate <Number2>. Boolean Returns a value of true if <Number1> is the same as <Number2>.
Not Equal To <Number1> <> <Number2> Less than <Number1> < <Number2> Greater than <Number1> > <Number2> Less than or equal to <Number1> <= <Number2> Greater than or equal to <Number1> >= <Number2> Add <Number1> + <Number2> Number Returns the sum of <Number1> and <Number2>. The resulting data type is the more expansive of either <Number1> or <Number2>. For example, if an Integer value is added to a Decimal value, the resulting value will be a Decimal. See Appendix B. Boolean Returns a value of true if <Number1> is greater than or equal to <Number2>. Boolean Returns a value of true if <Number1> is less than or equal to <Number2>. Boolean Returns a value of true if <Number1> is greater than <Number2>. Boolean Returns a value of true if <Number1> is less than <Number2>. Boolean Returns a value of true if <Number1> is not equal to <Number2>.
1/13/2012
Rule Language Guide

Name Subtract <Number1> - <Number2> Number Syntax Returned Data Type Description
Page 23
Subtracts <Number2> from <Number1>. The resulting data type is the more expansive of either <Number1> or <Number2>. See Appendix B.
Multiply <Number1> * <Number2> Number Returns the product of <Number1> and <Number2>. The resulting data type is the more expansive of either <Number1> or <Number2>. See Appendix B.
Divide <Number1> / <Number2> Number Divides <Number1> by <Number2>. The resulting data type is the more expansive of either <Number1> or <Number2>. See Appendix B.
Exponent <Number1> ** <Number2> Number Raises <Number1> to the power of <Number2>. The resulting data type is the more expansive of either <Number1> or <Number2>. See Appendix B.
Increment <Number1> += <Number2> Number Increments <Number1> by <Number2>. The data type of <Number1> must accommodate the addition of <Number2>. See Appendix B.
Decrement <Number1> -= <Number2> Number Decrements <Number1> by the value of <Number2>. The data type of <Number1> must accommodate the addition of <Number2>. See Appendix B.
Absolute Value <Integer>.absVal Number Returns the absolute value of <Integer>. If the < Integer > is positive, < Integer > itself is returned; if < Integer > is negative, the negation of < Integer > is returned.
1/13/2012
Rule Language Guide

Name To Decimal <Integer>.toDecimal To String <Integer>.toString Maximum Value <Integer1>.max(<Integer2>) Minimum Value <Integer1>.min(<Integer2>) Div <Integer1>.div(<Integer2>) Integer Integer Integer String Decimal Syntax Returned Data Type Description
Page 24
Converts an attribute of type Integer to type Decimal.
Converts an attribute of type Decimal to type String.
Returns the greater of <Integer1> and <Integer2>.
Returns the lesser of <Integer1> and <Integer2>.
Returns the whole number of times that <Integer2> fits within <Integer1> - any remainder is discarded.
Mod <Integer1>.mod(<Integer2>) Integer Returns the whole number remainder that results from dividing <Integer1> by <Integer2>. If the remainder is a fraction, then zero is returned.
Logarithm (base 10) <Integer>.log Logarithm (base x) <Integer>.log(<Decimal>) Natural Logarithm <Integer>.ln Decimal Returns the natural logarithm (base e) of <Number>. <Integer> may not be zero. Decimal Returns the logarithm (base <Decimal>) of <Integer>. <Integer> may not be zero. Decimal Returns the logarithm (base 10) of <Integer>. <Integer> may not be zero.
1/13/2012
Rule Language Guide
Page 25
String
Equals (used as a comparison) <String1> = <String2> Boolean Returns a value of true if <String1> exactly matches <String2>. Both case and length are examined to determine equality. See Appendix A for character precedence.
Equals (used as an assignment) <String1> = <String2> Not Equal to <String1> <> <String2> Less than <String1> < <String2> Boolean Returns a value of true if <String1> is less than <String2>. See Appendix A for character precedence. Boolean Returns a value of true if <String1> is not equal to <String2>. String Assigns the value of <String2> to the value of <String1>.
Greater than <String1> > <String2> Boolean Returns a value of true if <String1> is greater than <String2>. See Appendix A for character precedence.
Less than or equal to <String1> <= <String2> Boolean Returns a value of true if <String1> is less than or equal to <String2>. See Appendix A for character precedence.
Greater than or equal to <String1> >= <String2> Boolean Returns a value of true if <String1> is greater than or equal to <String2>. See Appendix A for character precedence.
Adding Strings <String1> + <String2> Size String Concatenates <String1> to <String2>. Alternative syntax.
1/13/2012
Rule Language Guide

Name <String>.size Concatenate <String1>.concat(<String2>) Uppercase <String>.toUpper Lowercase <String>.toLower To DateTime <String>.toDateTime DateTime String String String Syntax Returned Data Type Integer Description
Page 26
Returns the number of characters in <String>.
Concatenates <String1> to <String2>.
Converts all characters <String> to uppercase.
Converts all characters in <String> to lowercase.
Converts the value in <String> to data type DateTime ONLY if all characters in <String> correspond to a valid DateTime mask (format)
To Decimal <String>.toDecimal Decimal Converts an attribute of type String to data type Decimal ONLY if all characters in <String> are numeric and contain not more than one decimal point. If any nonnumeric characters are present (other than a single decimal point or leading minus sign), no value is returned.
To Integer <String>.toInteger Integer Converts an attribute of type String to type Integer ONLY if all characters in <String> are numeric. If any non-numeric characters are present, no value is returned.
Substring <String>.substring(<Integer1>,<Integer2> ) Equals Ignoring Case String Returns that portion of <String> between character positions <Integer1> and Integer2>.
1/13/2012
Rule Language Guide

Name Syntax <String1>.equalsIgnoreCase(<String2>) Starts with <String1>.startsWith(<String2>) Boolean Returned Data Type Boolean Description
Page 27
Returns a value of true if <String1> is the same as <String2>, irrespective of case.
Returns a value of true if the <String1> begins with the characters specified in <String2>.
Ends with <String1>.endsWith(<String2>) Boolean Evaluates the contents of <String1> and returns a value of true if the String ends with the characters specified in <String2>.
Contains <String1>.contains(<String2>) Boolean Evaluates the contents of <String1> and returns a value of true if it contains the exact characters defined by <String2>
Equals <String1>.equals(<String2>) Index Of <String1>.indexOf(<String2) Integer Returns the beginning character position number of <String2> within <String1>, if <String1> contains <String2>. If it does not, the function returns a value of zero. Boolean Returns a value of true if <String1> is the same as <String2>.
ENTITY/COLLECTION OPERATORS
The operators summarized in the tables below may be applied to entities or collections only.
Entity
Name New <Entity>.new[<Expression1>,] Entity Creates a new instance of <Entity>. Expressions (optional) in square brackets [..] must be written in the form: attribute = value. Syntax Returned Data Type Description
1/13/2012
Rule Language Guide

Name New Unique <Entity>.newUnique[<Expression1>,] Entity Syntax Returned Data Type Description
Page 28
Creates a new instance of <Entity> only if the instance created is unique as defined by optional <Expression1>,
Remove <Entity>.remove Entity Deletes the entity from memory and from the resultant XML document.
Collection
Name Replace element(s) <Collection1> = <Collection2> <Collection1> = <Entity> modifies a collection replaces all elements in <Collection1> with elements of <Collection2> or with <Entity>, provided the new associations are allowed by the Business Vocabulary. Syntax Returned Data Type Description
Associate element(s) <Collection1> += <Collection2> <Collection1> += <Entity> modifies a collection Associates all elements of <Collection2> or <Entity> with <Collection1>. Every <Collection> must be expressed as a unique alias.
Disassociate element(s) <Collection1> -= <Collection2> modifies a collection Disassociates all elements of <Collection2> from <Collection1>. Does not delete the disassociated elements. Every <Collection> must be expressed as a unique alias.
Is empty <Collection> ->isEmpty Not empty <Collection> ->notEmpty Exists Boolean Returns a value of true if <Collection> contains at least one element. Boolean Returns a value of true if <Collection> contains no elements
1/13/2012
Rule Language Guide

Name Syntax <Collection> ->exists(<Expression>) Returned Data Type Boolean Description
Page 29
Returns a value of true if <Expression> holds true for at least one element of <Collection>
For all <Collection> ->forAll(<Expression>) Boolean Returns a value of true if every <Expression> holds true for every element of <Collection>
Sorted by <Collection> ->sortedBy(<Attribute>) converts a collection into a sequence Sequences the elements of <Collection> in ascending order, using the value of <Attribute> as the index. <Collection> must be expressed as a unique alias.
Sorted by Descending <Collection>->sortedByDesc (<Attribute>) converts a collection into a sequence Sequences the elements of <Collection> in descending order, using the value of <Attribute> as the index. <Collection> must be expressed as a unique alias.
Iterate <Collection> ->iterate(<Expression>) Executes <Expression> for every element in <Collection>. <Collection> must be expressed as a unique alias.
Size of collection <Collection> ->size Integer Returns the number of elements in <Collection>. <Collection> must be expressed as a unique alias.
Sum <Collection.attribute> ->sum Number Sums the values of the specified <attribute> for all elements in <Collection>. <attribute> must be a numeric data type.
Average
1/13/2012
Rule Language Guide

Name Syntax <Collection.attribute> ->avg Returned Data Type Number Description
Page 30
Averages all of the specified attributes in <Collection>. <Collection> must be expressed as a unique alias. <attribute> must be a numeric data type
Minimum <Collection.attribute> ->min Number Returns the lowest value of <attribute> for all elements in <Collection>. <attribute> must be a numeric data type
Maximum <Collection.attribute> ->max Number Returns the highest value of <attribute> for all elements in <Collection>. <attribute> must be a numeric data type
Sequence
Sequence operators act on collections that have already been ordered by a sorting operator (see sortedBy and sortedByDesc). In other words, sequence operators operate on collections that have been turned into sequences. The notation <Sequence> used below, is shorthand for a completed sorting operation. For example: <Collection> -> sortedBy(<Attribute>) produces a <Sequence>, in this case the elements of <Collection> arranged in ascending order using <Attribute> as the index. This <Sequence> can then be used with one of the sequence operators described below. The design of the Object Constraint Language (upon which the CRL is based), allows for the chaining of operators, so a collection operator and a sequence operator can be used in the same expression to produce a sequence and identify a particular element of that sequence in the same step. For example: <Entity.attribute1> = <Collection> sortedBy(<Attribute3>) first.<Attribute2> performs the following: 1. sorts <Collection> in ascending order according to <Attribute3>, turning it into a <Sequence> 2. locates the first element of <Sequence> 3. reads the value of <Attribute2> of the first element 4. assigns the value of <Attribute2> of the first element to <Entity.attribute1>
1/13/2012
Rule Language Guide

Name At <Sequence> ->at(<Integer>) Entity Returns the element at position <Integer>. <Sequence> must be expressed as a unique alias. Syntax Returned Data Type Description
Page 31
First <Sequence> ->first Entity Returns the first element of <Sequence>. <Sequence> must be expressed as a unique alias.
Last <Sequence> ->last Entity Returns the last element of <Sequence>. <Sequence> must be expressed as a unique alias.
Trend <Attribute> -> <Sequence>.trend String Returns a 4-character string, INCR, DECR, CNST, or NONE depending on the trend of <Attribute> within <Sequence>.
1/13/2012
Rule Language Guide
Page 32
RULE OPERATORS SORTED ALPHABETICALLY

The following pages describe each operator in greater detail. Each Rule Operator has the following sections 1. Syntax describes the standard syntax used with this operator. In this section, as in the previous summary tables, the angle bracket convention <..> is used to indicate what types of terms and their data types can be used with the operator. When using the operator with real terms from the Vocabulary, do not include the angle brackets. 2. Description provides a plain-language description of the operators purpose and details of use. Important reminders, tips, or cautions are also included in this section. 3. Usage Restrictions describes what limitations exist for this operator, and where an operator may not be used in the Rulesheet. Such limitations are rare, but important to a good understanding of Studio. 4. Example an example of each operator is provided so the Studio user can see what it looks like in an actual Rulesheet. A screenshot of the example Rulesheet is provided, with portions of the Rulesheet not used by the example collapsed or truncated for clarity. The example also includes sample input and output data for Ruletest scenarios run against the Rulesheet. Unlike the previous tables, which were organized according to their Vocabulary categories, this section arranges operators alphabetically for easier look-up.
1/13/2012
Rule Language Guide
Page 33
ABSOLUTE VALUE
SYNTAX
<Number>.absVal
DESCRIPTION
Returns the absolute value of <Number>. If the <Number> is positive, <Number> itself is returned; if <Number> is negative, the negation of <Number> is returned.
USAGE RESTRICTIONS
The Operators row of table in Figure 4 applies. No special exceptions.
RULESHEET EXAMPLE
This sample Rulesheet uses .absVal to produce the absolute value of decimal2 and assign it to
decimal1
SAMPLE RULETEST
A sample Ruletest provides decimal2 values for three different scenarios of Entity1. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 34
ADD NUMBERS
SYNTAX
<Number1> + <Number2>
DESCRIPTION
Adds <Number1> to <Number2>. The resulting data type is the more expansive of those of <Number1> and <Number2>. For example, if you are adding an Integer value and a Decimal value, the resulting value will be a Decimal. See Appendix B.
USAGE RESTRICTIONS
RULE SHEET EXAMPLE

This sample Rulesheet uses the add numbers operation to add the value of decimal2 to the value of integer1 and assign the result to decimal1
1/13/2012
Rule Language Guide
Page 35
SAMPLE RULETEST
A sample Ruletest provides an integer1 value of 300 which is added to the value of decimal2 and assigned to the value of decimal1 for three instances of Entity1. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 36
ADD STRINGS
SYNTAX
<String1> + <String2>
DESCRIPTION
Adds <String1> to <String2>. This has the same effect as using the .concat operator. However, the + syntax permits concatenation of more than two String values without nesting, as shown in the example below.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses the add strings operation to add the String AAA to string2 to ZZZ and assign the result to string1
SAMPLE RULETEST
1/13/2012
Rule Language Guide
Page 37
ADD DAYS
SYNTAX
<DateTime>.addDays(<Integer>) <Date>.addDays(<Integer>)
DESCRIPTION
Adds the number of days in <Integer> to the number of days in <DateTime> or <Date>.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses .addDays to add 45 days to the value of dateTime2 and assign the result to dateTime1.
SAMPLE RULETEST
A sample Ruletest provides values of dateTime2 for three instances of Entity1. Input and Output panels are shown below. Notice the month portion of dateTime1 also changes accordingly.
1/13/2012
Rule Language Guide
Page 38
ADD HOURS
SYNTAX
<DateTime>.addHours(<Integer>) <Time>.addHours(<Integer>)
DESCRIPTION
Adds the number of hours in <Integer> to the number of hours in the Time portion of <DateTime> or <Time>.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses .addHours to add 30 hours to the value of dateTime2 and assign the result to dateTime1.
SAMPLE RULETEST
A sample Ruletest provides values of dateTime2 for three instances of Entity1. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 39
ADD MINUTES
SYNTAX
<DateTime>.addMinutes(<Integer>) <Time>.addMinutes(<Integer>)
DESCRIPTION
Adds the number of minutes in <Integer> to the number of minutes in the Time portion of <DateTime> or <Time>.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses .addMinutes to add 90 minutes to the value of dateTime2 and assign the result to dateTime1.
SAMPLE RULETEST
A sample Ruletest provides values of dateTime2 for three instances of Entity1. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 40
ADD MONTHS
SYNTAX
<DateTime>.addMonths(<Integer>) <Date>.addMonths(<Integer>)
DESCRIPTION
Adds the number of months in <Integer> to the number of months in <DateTime> or <Date>.
USAGE RESTRICTIONS
The Operators row of the table in Figure 4 applies. No special exceptions.
RULESHEET EXAMPLE
This sample Rulesheet uses .addMonths in a Nonconditional rule to add 10 months to the value of dateTime2 and assign the result to dateTime1.
SAMPLE RULETEST
A sample Ruletest provides values of dateTime2 for three instances of Entity1. Input and Output panels are shown below. Notice the year portion of dateTime1 also changes accordingly.
1/13/2012
Rule Language Guide
Page 41
ADD SECONDS
SYNTAX
<DateTime>.addSeconds(<Integer>) <Time>.addSeconds(<Integer>)
DESCRIPTION
Adds the number of seconds in <Integer> to the number of seconds in the Time portion of <DateTime> or <Time>.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses .addSeconds in a Nonconditional rule to add 90 seconds to the value of timeOnly2 and assign the result to timeOnly1.
SAMPLE RULETEST
A sample Ruletest provides values of timeOnly2 for three instances of Entity1. Input and Output panels are shown below. Notice how the time wraps around to the beginning of the day, even though Time data type does not include date information.
1/13/2012
Rule Language Guide
Page 42
ADD YEARS
SYNTAX
<DateTime>.addYears(<Integer>) <Date>.addYears(<Integer>)
DESCRIPTION
Adds the number of years in <Integer> to the number of years in the Date portion of <DateTime> or <Date>.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses .addYears in a Nonconditional rule to add 10 years to the value of dateOnly2 and assign the result to dateOnly1.
SAMPLE RULETEST
A sample Ruletest provides values of dateOnly2 for three instances of Entity1. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 43
ASSOCIATE ELEMENT(S)
SYNTAX
<Collection1> += <Collection2> <Collection1> += <Entity>
DESCRIPTION
Associates all elements of <Collection2> or a single element named <Entity> with <Collection1>, provided such an association is allowed by the Business Vocabulary. Every <Collection> must be expressed as a unique alias. If the cardinality of the association between the parent entity of <Collection> and the <Entity> being added is one-to-one (a straight line icon beside the association in the Rule Vocabulary), then this associate element syntax is not used. Instead, replace element syntax is used, since the collection can contain only one element, and any element present will be replaced by the new element.
USAGE RESTRICTIONS
The Operators row of table in Figure 4 does not apply. Special exceptions: associate element may only be used in Action Rows (section 5 in Figure 5).
RULESHEET EXAMPLE
The following Rulesheet uses associate element to associate an element of collection2 to collection1 when boolean1 value of any element in collection2 is true. Note that the Action is not associating all elements in collection2 with collection1, only those elements within collection2 that satisfy the condition.
1/13/2012
Rule Language Guide
Page 44
SAMPLE RULETEST
A sample Ruletest provides two examples of Entity2 with boolean1 values, and a single Entity1. Input and Output panels are described below:
1/13/2012
Rule Language Guide
Page 45
AT
SYNTAX
<Sequence> ->at(<Integer>).<Attribute1>
DESCRIPTION
Returns the value of <Attribute1> for the element at position <Integer> in <Sequence>. Another operator, such as sortedBy, must be used to transform a <Collection> into a <Sequence> before at may be used. <Sequence> must be expressed as a unique alias. See Advanced Collection Syntax for more examples of usage. <Attribute1> may be of any data type.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses at(2) to identify the second element of the sequence created by applying sortedBy to collection1. Once identified, the value of the string1 attribute belonging to this second element is evaluated. If the value of string1 is Joe, then boolean1 attribute of Entity1 is assigned the value of true.
1/13/2012
Rule Language Guide
Page 46
SAMPLE RULETEST
A sample Ruletest provides a collection of three elements, each with a decimal1 value. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 47
AVERAGE
SYNTAX
<Collection.attribute> ->avg
DESCRIPTION
Averages the values of all of the specified attributes in <Collection>. <Collection> must be expressed as a unique alias. <attribute> must be a numeric data type.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses avg to average the integer1 values of all elements in collection2, then assigns the resulting value to decimal1 in Entity1. Note the use of the alias collection2 to represent the collection of Entity2 elements associated with Entity1.
SAMPLE RULETEST
A sample Ruletest provides integer1 values for three elements in collection2. The following illustration shows Input and Output panels:
1/13/2012
Rule Language Guide
Page 48
CELLVALUE
SYNTAX
Various, see Examples below
DESCRIPTION
When used in an expression, cellValue is essentially a variable whose value is determined by the rule Column that executes. Using cellValue in a Condition or Action expression eliminates the need for multiple, separate Rows to express the same logic.
USAGE RESTRICTIONS
The Operators row of table in Figure 4 does not apply. Special exceptions: cellValue may only be used in Condition and Action Rows (sections 3 and 5 in Figure 5).
RULESHEET EXAMPLE 1
This sample Rulesheet uses cellValue to increment integer1 by the amount in the Action Cell of the rule Column that fires. An equivalent Rulesheet which does not use cellValue is also shown for comparison purposes.
Equivalent Rulesheet without using cellValue:
1/13/2012
Rule Language Guide
Page 49
SAMPLE RULETEST 1
A sample Ruletest provides two examples of boolean1. The following table shows Input and Output panels.
RULESHEET EXAMPLE 2
The following Rulesheet uses cellValue to evaluate whether collection1 includes at least one member with a string1 value of the entry in the Conditions Cell of the rule Column.
1/13/2012
Rule Language Guide
Page 50
SAMPLE RULETEST 2
A sample Ruletest provides three examples of collection1 each member has a string1 value. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 51
RULESHEET EXAMPLE 3
The following Rulesheet uses cellValue to create a new member of collection1 with string1 value equal to the Action Cell in the rule Column that fires.
SAMPLE RULETEST 3
A sample Ruletest provides string1 values for three examples. The following illustration shows Ruletest Input and Output panels. Notice that each collection1 already has one element prior to executing the test. This simply ensures the results will be displayed in hierarchical style.
1/13/2012
Rule Language Guide
Page 52
CONCATENATE
SYNTAX
<String1>.concat(<String2>)
DESCRIPTION
Concatenates <String1> to <String2>, placing <String2> at the end of <String1>
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses .concat to create string1 by combining string1 and string2 from Entity1.entity2.
1/13/2012
Rule Language Guide
Page 53
SAMPLE RULETEST
A sample Ruletest provides three examples of string1 and string2. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 54
CONTAINS
SYNTAX
<String1>.contains(<String2>)
DESCRIPTION
Evaluates <String1> and returns a value of true if it contains or includes the exact (case-sensitive) characters specified in <String2>.
USAGE RESTRICTIONS
RULESHEET EXAMPLE 1
The following Rulesheet uses .contains to evaluate whether string1 includes the characters silver and assigns a value to boolean1 for each outcome.
1/13/2012
Rule Language Guide
Page 55
SAMPLE RULETEST 1
A sample Ruletest provides string1 values for three examples. Input and Output panels are shown below. Note case sensitivity in these examples. Posted messages are not shown.
1/13/2012
Rule Language Guide
Page 56
DAY
SYNTAX
<DateTime>.day <Date>.day <DateTime>.day
DESCRIPTION
Returns the day portion of <DateTime> or <Date> as an Integer between 1 and 31.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .day to assign a value to string1 and post a message.
1/13/2012
Rule Language Guide
Page 57
SAMPLE RULETEST
A sample Ruletest provides dateTime1 values for three examples. Input and Output panels are shown below. Posted messages are not shown.
1/13/2012
Rule Language Guide
Page 58
DAYS BETWEEN
SYNTAX
<DateTime1>.daysBetween(<DateTime2>) <Date1>.daysBetween(<Date2>)
DESCRIPTION
Returns the Integer number of days between DateTimes or Dates. This function calculates the number of milliseconds between the date values and divides that number by 86,400,000 (the number of milliseconds in a day). Any fraction is truncated, leaving an Integer result. If the two dates differ by less than a full 24-hour period, the value returned is zero. A positive Integer value is returned when <DateTime2> occurs after <DateTime1>.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .daysBetween to determine the number of days that have elapsed between dateTime1 and dateTime2, compare it to the values in the Condition cells, and assign a value to string1.
1/13/2012
Rule Language Guide
Page 59
SAMPLE RULETEST
A sample Ruletest provides dateTime1 and dateTime2 for two examples. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 60
DAY OF WEEK
SYNTAX
<DateTime>.dayOfWeek <Date>.dayOfWeek
DESCRIPTION
Returns an Integer between 1 and 7, corresponding to the table below:
returned Integer 1 2 3 4 day of the week Sunday Monday Tuesday Wednesday returned Integer 5 6 7 day of the week Thursday Friday Saturday
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .dayOfWeek to assign a value to boolean1.
1/13/2012
Rule Language Guide
Page 61
SAMPLE RULETEST
1/13/2012
Rule Language Guide
Page 62
DAY OF YEAR
SYNTAX
<DateTime>.dayOfYear <Date>.dayOfYear
DESCRIPTION
Returns an Integer from 1 to 366, equal to the day number within the year.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .dayOfYear to assign a value to string1.
SAMPLE RULETEST
1/13/2012
Rule Language Guide
Page 63
DECREMENT
SYNTAX
<Number1> -= <Number2>
DESCRIPTION
Decrements <Number1> by the value of <Number2>. The data type of <Number1> must accommodate the subtraction of <Number2>. In other words, an Integer may not be decremented by a Decimal without using another operator (such as .toInteger or .floor) to first convert the Decimal to an Integer.
USAGE RESTRICTIONS
The Operators row of table in Figure 4 does not apply. Special exceptions: decrement may only be used in Action Rows (section 5 in Figure 5).
RULESHEET EXAMPLE
This sample Rulesheet uses decrement to reduce integer1 by the value of integer2 when boolean1 is false.
1/13/2012
Rule Language Guide
Page 64
SAMPLE RULETEST
A sample Ruletest provides three examples of integer1, integer2, and boolean1. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 65
DISASSOCIATE ELEMENT(S)
SYNTAX
<Collection1> -= <Collection2>
DESCRIPTION
Disassociates all elements of <Collection2> from <Collection1>. Elements are not deleted, but once disassociated from <Collection1>, they are moved to the root level of the data. <Collection1> must be expressed as a unique alias. Contrast this behavior with remove, which deletes elements entirely.
USAGE RESTRICTIONS
The Operators row of table in Figure 4 does not apply. Special exceptions: disassociate element may only be used in Action Rows (section 5 in Figure 5).
RULESHEET EXAMPLE
This sample Rulesheet removes those elements from collection1 whose boolean1 value is true.
SAMPLE RULETEST
A sample Ruletest provides a collection with three elements. The illustration shows Input and Output panels:
1/13/2012
Rule Language Guide
Page 66
DIVIDE
SYNTAX
<Number1> / <Number2>
DESCRIPTION
Divides <Number1> by <Number2>. The resulting data type is the more expansive of those of <Number1> and <Number2>.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses divide to divide decimal1 by integer1 and assign the resulting value to
decimal2
1/13/2012
Rule Language Guide
Page 67
SAMPLE RULETEST
A sample Ruletest provides decimal1 and integer1 values for three examples. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 68
DIV
SYNTAX
<Integer1>.div(<Integer2>)
DESCRIPTION
Returns an Integer equal to the whole number of times that <Integer2> divides into <Integer1>. Any remainder is discarded.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses .div to calculate the whole number of times 3 divides into integer2, and assigns the resulting value to integer1.
SAMPLE RULETEST
A sample Ruletest provides integer2 values for three examples. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 69
ENDS WITH
SYNTAX
<String1>.endsWith(<String2>)
DESCRIPTION
Evaluates <String1> and returns a value of true if it ends with the characters specified in <String2>.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .endsWith to evaluate whether string1 ends with the characters ville and assigns a different value to string2 for each outcome.
SAMPLE RULETEST
A sample Ruletest provides string1 values for three examples. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 70
EQUALS USED AS AN ASSIGNMENT

SYNTAX
Boolean DateTime* Number String <Boolean1> = <Expression1> <DateTime1> = <DateTime2> <Number1> = <Number2> <String1> = <String2>
DESCRIPTION
Boolean DateTime* Number Assigns the truth value of <Expression1> to <Boolean1>. Assigns the value of <DateTime2> to <DateTime1>. Assigns the value of <Number2> to <Number1>. Automatic casting1 will occur when assigning an Integer data type to a Decimal data type. To assign a Decimal value to an Integer value, use the .toInteger operator. Assigns the value of <String2> to <String1>.
String
*includes DateTime, Date, or Time data types
USAGE RESTRICTIONS
The Operators row of table in Figure 4 does not apply. Special exceptions: equals used as an assignment may only be used in Action Rows (section 5 in Figure 5).
RULESHEET EXAMPLE
The following Rulesheet uses equals twice: in an Action row to assign a value to decimal1, and in an Action row to assign a value to string1 based on the value of boolean1.
casting is the process of converting one data type into another.
1/13/2012
Rule Language Guide
Page 71
SAMPLE RULETEST
A sample Ruletest provides two examples of boolean1. Input and Output panels are shown below:
1/13/2012
Rule Language Guide
Page 72
EQUALS USED AS A COMPARISON

SYNTAX
Boolean DateTime* Number String <Expression1> = <Expression2> <DateTime1> = <DateTime2> <Number1> = <Number2> <String1> = <String2>
DESCRIPTION
Boolean DateTime* Number String Returns a value of true if <Expression1> is the same as <Expression2>. Returns a value of true if <DateTime1> is the same as <DateTime2>, including both the Date and the Time portions Returns a value of true if <Number1> is the same as <Number2>. Different numeric data types may be compared in the same expression. Returns a value of true if <String1> is the same as <String2>. Both case and length are examined to determine equality. Studio uses the ISO character precedence in comparing String values. See Appendix A.
*includes DateTime, Date, and Time data types
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses equals to Ruletest whether decimal1 equals decimal2, and assign a value to string1 based on the result of the comparison.
1/13/2012
Rule Language Guide
Page 73
SAMPLE RULETEST
A sample Ruletest provides two examples. Input and Output panels are shown below:
1/13/2012
Rule Language Guide
Page 74
EQUALS IGNORING CASE

SYNTAX
<String1>.equalsIgnoreCase(<String2>)
DESCRIPTION
Returns a value of true if <String1> is the same as <String2>, irrespective of case.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses .equalsIgnoreCase to compare the values of string1 and string2, and assign a value to boolean1 based on the results of the comparison.
SAMPLE RULETEST
A sample Ruletest provides the plane type for three sets of string1 and string2. Input and Output panels are shown below. Notice how these results differ from those shown in the .equals example.
1/13/2012
Rule Language Guide
Page 75
EQUALS STRINGS ONLY

SYNTAX
<String1>.equals(<String2>)
DESCRIPTION
Returns a value of true if <String1> is exactly the same as <String2>, including character case. This is alternative syntax to equals (used as a comparison).
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses .equals to compare the contents of string1 and string2, and assign a value to boolean1 as a result.
1/13/2012
Rule Language Guide
Page 76
SAMPLE RULETEST
A sample Ruletest provides three sets of string1 and string2. Input and Output panels are shown below. Notice how these results differ from those shown in the .equalsIgnoreCase example.
1/13/2012
Rule Language Guide
Page 77
EXISTS
SYNTAX
<Collection> ->exists(<Expression1>,<Expression2>,) <Collection> ->exists(<Expression1> or <Expression2> or )
DESCRIPTION
Returns a value of true if <Expression> holds true for at least one element of <Collection>. <Collection> must be expressed as a unique alias. Multiple <Expressions> are optional, but at least one is required. Both AND (indicated by commas between <Expressions>) and OR syntax (indicated by or between <Expressions>) are supported within the parentheses (..). However, take care to ensure invariant expressions are not inadvertently created. For example:
<Collection> -> exists(integer1=5, integer1=8)
will always evaluate to false because no integer1 value can be both 5 AND 8 simultaneously.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses exists to check for the existence of an element in collection1 whose string1 value equals New, and assigns a value to decimal1 based on the results of the test. Note the use of unique alias collection1 to represent the collection of Entity2 associated with Entity1.
1/13/2012
Rule Language Guide
Page 78
SAMPLE RULETEST
A sample Ruletest provides 2 separate collections of Entity2 elements and Entity1.decimal1 values. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 79
EXPONENT
SYNTAX
<Number1> ** <Number2>
DESCRIPTION
Raises <Number1> by the power of <Number2>. The resulting data type is the more expansive of those of <Number1> and <Number2>. To find a root, <Number2> should be expressed as a fraction. For example, the square root is expressed as 0.5
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses exponent to raise integer1 and integer2 by the power of 2 and 0.5, respectively, and assign the resulting value to decimal1 and decimal2, respectively.
1/13/2012
Rule Language Guide
Page 80
SAMPLE RULETEST
A sample Ruletest provides decimal1 and integer1 values for three examples.
1/13/2012
Rule Language Guide
Page 81
FALSE
SYNTAX
false or F
DESCRIPTION
Represents the Boolean value false. Recall from discussion of truth values that an <expression> is evaluated for its truth value, so the expression Entity1.boolean1=false evaluates to true only when boolean1=false. But since boolean1 is Boolean and has a truth value all by itself without any additional syntax, we could simply state not Entity1.boolean1, with the same effect. Many examples in the documentation use explicit syntax like boolean1=true or boolean2=false for clarity and consistency, even though boolean1 or not boolean2 are equivalent, respectively, to the explicit syntax.
USAGE RESTRICTIONS
The Literals row of the table in Figure 4 applies. No special exceptions.
RULESHEET EXAMPLE
The following Rulesheet uses false in a Filter row to test whether boolean1 is false, and perform the Nonconditional computation if it is. As discussed above, the alternative expression not Entity1.boolean1 is logically equivalent.
1/13/2012
Rule Language Guide
Page 82
SAMPLE RULETEST
A sample Ruletest provides three examples. Assume decimal2=10.0 and integer1=5 for all examples. Input and Output panels are shown below:
1/13/2012
Rule Language Guide
Page 83
FIRST
SYNTAX
<Sequence> ->first.<attribute1>
DESCRIPTION
Returns the value of <attribute1> of the first element in <Sequence>. Another operator, such as sortedBy, must be used to transform a <Collection> into a <Sequence> before first may be used. <Sequence> must be expressed as a unique alias. See Advanced Collection Syntax for more examples of usage. <attribute1> may be of any data type.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses first to identify the first element of the sequence created by applying sortedBy to collection1. Once identified, the value of the string1 attribute belonging to this first element is evaluated. If the value of string1 is Joe, then boolean1 attribute of Entity1 is assigned the value of true.
1/13/2012
Rule Language Guide
Page 84
SAMPLE RULETEST
1/13/2012
Rule Language Guide
Page 85
FLOOR
SYNTAX
<Decimal>.floor
DESCRIPTION
Returns the Integer closest to zero from <Decimal>. .floor may also be thought of as a truncation of <Decimal>.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The Rulesheet uses .floor to assign Integer values to integer1 that are closer to zero than the input decimal1 values.
SAMPLE RULETEST
A sample Ruletest provides three decimal1 values. Input and Output panels are shown below: Notice how these results differ from those shown in the Round example.
1/13/2012
Rule Language Guide
Page 86
FOR ALL
SYNTAX
<Collection> ->forAll(<Expression1>, <Expression2>,) <Collection> ->forAll(<Expression1> or <Expression2> or )
DESCRIPTION
Returns a value of true if every <Expression> holds true for every element of <Collection>. <Collection> must be expressed as a unique alias. Multiple <Expressions> are optional, but at least one is required. Both AND (indicated by commas between <Expressions>) and OR syntax (indicated by or between <Expressions>) is supported within the parentheses (..). However, take care to ensure invariant expressions are not inadvertently created. For example:
<Collection> -> forAll(integer1=5, integer1=8)
will always evaluate to false because no single integer1 value can be both 5 AND 8 simultaneously, let alone all of them.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses forAll to check for the existence of an element in collection1 whose string1 value equals New, and assigns a value to decimal1 based on the results of the test. Note the use of unique alias collection1 to represent the collection of Entity2 associated with Entity1.
1/13/2012
Rule Language Guide
Page 87
SAMPLE RULETEST
A sample Ruletest provides 2 separate collections of Entity2 elements and Entity1.decimal1 values. The following illustration shows Input and Output panels
1/13/2012
Rule Language Guide
Page 88
GREATER THAN
SYNTAX
DateTime* Number String <DateTime1> > <DateTime2> <Number1> > <Number2> <String1> > <String2>
DESCRIPTION
DateTime* Returns a value of true if <DateTime1> is greater than or equal to <DateTime2>. This is equivalent to <DateTime1> occurring after <DateTime2> Returns a value of true if <Number1> is greater than <Number2>. Different numeric data types may be compared in the same expression. Returns a value of true if <String1> is greater than <String2>. Studio uses Appendix A to determine character precedence.
Number String
USAGE RESTRICTIONS
The Operators row of the table in Figure 4 applies, with the following exception: greater than may also be used in Conditional Value Sets & Cells (section 5 of Figure 5).
RULESHEET EXAMPLE
The following Rulesheet uses greater than to test whether string1 is greater than string2, and assign todays date to dateTime1 if it is. See today for an explanation of this literal term.
1/13/2012
Rule Language Guide
Page 89
SAMPLE RULETEST
A sample Ruletest provides three examples. Input and Output panels are shown below:
1/13/2012
Rule Language Guide
Page 90
GREATER THAN OR EQUAL TO

SYNTAX
DateTime* Number String <DateTime1> >= <DateTime2> <Number1> >= <Number2> <String1> >= <String2>
DESCRIPTION
DateTime* Returns a value of true if <DateTime1> is greater than or equal to <DateTime2>. This is equivalent to <DateTime1> occurring on or after <DateTime2> Returns a value of true if <Number1> is greater than or equal to <Number2>. Different numeric data types may be compared in the same expression. Returns a value of true if <String1> is greater than or equal to <String2>. Studio uses Appendix A to determine character precedence.
Number String
USAGE RESTRICTIONS
The Operators row of the table in Figure 4 applies, with the following exception: greater than or equal to may also be used in Conditional Value Sets & Cells (section 5 of Figure 5).
RULESHEET EXAMPLE
The following Rulesheet uses greater than or equal to to test whether string1 is greater than or equal to string2, and assign todays date to dateTime1 if it is. See today for an explanation of this literal term.
1/13/2012
Rule Language Guide
Page 91
SAMPLE RULETEST
1/13/2012
Rule Language Guide
Page 92
HOUR
SYNTAX
<DateTime>.hour <Time>.hour
DESCRIPTION
Returns the hour portion of <DateTime> or <Time>. The returned value is based on a 24-hour clock. For example, 10:00 PM (22:00 hours) is returned as 22.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .hour to evaluate dateTime1 and assign the hour value to integer1.
1/13/2012
Rule Language Guide
Page 93
SAMPLE RULETEST
A sample Ruletest provides three examples of dateTime1. Input and Output panels are shown below. Notice that the hour returned is dependent upon the timezone of the machine executing the rule. The hour returned is independent of the machine running the Ruletest and only depends on the locale/timezone of the data itself.
1/13/2012
Rule Language Guide
Page 94
HOURS BETWEEN
SYNTAX
<DateTime1>.hoursBetween(<DateTime2>)
DESCRIPTION
Returns the Integer number of hours between any two DateTimes or Times. The function calculates the number of milliseconds between the two values and divides that number by 3,600,000 (the number of milliseconds in an hour). The decimal portion is then truncated. If the two dates differ by less than a full hour, the value is zero. This function returns a positive number if <DateTime2> is later than <DateTime1>.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .hoursBetween to determine the number of hours that have elapsed between dateTime1 and dateTime2, compare it to the Values set, and assign a value to string1.
1/13/2012
Rule Language Guide
Page 95
SAMPLE RULETEST
1/13/2012
Rule Language Guide
Page 96
INCREMENT
SYNTAX
<Number1> += <Number2>
DESCRIPTION
Increments <Number1> by the value of <Number2>. The data type of <Number1> must accommodate the addition of <Number2>. In other words, an Integer may not be incremented by a Decimal without using another operator (such .toInteger or .floor) to first convert the Decimal to an Integer.
USAGE RESTRICTIONS
The Operators row of table in Figure 4 does not apply. Special exceptions: increment may only be used in Action Rows (section 5 in Figure 5).
RULESHEET EXAMPLE
This sample Rulesheet uses increment to increment integer1 by the value of integer2 when boolean1 is true.
1/13/2012
Rule Language Guide
Page 97
SAMPLE RULETEST
A sample Ruletest provides three examples of integer1, integer2, and boolean1. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 98
INDEX OF
SYNTAX
<String1>.indexOf(<String2>)
DESCRIPTION
Determines if <String2> is contained within <String1> and returns an Integer value equal to the beginning character position of the first occurrence of <String2> within <String1>. If <String1> does not contain <String2>, then a value of 0 (zero) is returned. This operator is similar to .contains but returns different results. A 0 result from .indexOf is equivalent to a false value returned by the .contains operator. If <String1> contains more than one occurrence of <String2>, .indexOf returns the first character position of the first occurrence. For example: If <String1> holds the String value Mississippi and <String2> holds the String value ss, then the .indexOf operator returns 3. The second occurrence of ss beginning at position 6 is not identified.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .indexOf to evaluate whether string1 includes the characters silver and assigns a value to integer1 corresponding to the beginning character position of the first occurrence.
1/13/2012
Rule Language Guide
Page 99
SAMPLE RULETEST
A sample Ruletest provides string1 values for three examples. Input and Output panels are shown below. Notice sensitivity to case in example 1.
1/13/2012
Rule Language Guide
Page 100
IS EMPTY
SYNTAX
<Collection> ->isEmpty
DESCRIPTION
Returns a value of true if <Collection> contains no elements (i.e., has no children). isEmpty does not check for an empty or null value of an attribute, but instead checks for existence of elements within the collection. As such, a unique alias must be used to represent the <Collection> being tested.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses isEmpty to determine if collection1 has any elements. Note the use of unique alias collection1 to represent the collection of Entity2 associated with Entity1.
1/13/2012
Rule Language Guide
Page 101
SAMPLE RULETEST
A sample Ruletest provides two example collection1. The following illustration shows Input and Output panels
1/13/2012
Rule Language Guide
Page 102
ITERATE
SYNTAX
<Collection> ->iterate(<Expression>)
DESCRIPTION
Executes <Expression> for every element in <Collection>. <Collection> must be expressed as a unique alias.
USAGE RESTRICTIONS
The Operators row of table in Figure 4 does not apply. Special exceptions: iterate may only be used in Action Rows (section 5 in Figure 5).
RULESHEET EXAMPLE
This sample Rulesheet uses iterate to assign the value of test to string1 in every element in collection1 if the collection1 contains at least one element whose integer1 value is 5. See exists for more information on this operator.
SAMPLE RULETEST
A sample Ruletest provides three elements in collection1. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 103
1/13/2012
Rule Language Guide
Page 104
LAST
SYNTAX
<Sequence> ->last.<Attribute1>
DESCRIPTION
Returns the value of <Attribute1> of the last element in <Sequence>. Another operator, such as sortedBy, must be used to transform a <Collection> into a <Sequence> before last may be used. <Sequence> must be expressed as a unique alias. <Attribute1> may be of any data type. See Advanced Collection Syntax for more examples of usage.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses last to identify the last element of the sequence created by applying sortedBy to collection1. Once identified, the value of the string1 attribute belonging to this last element is evaluated. If the value of string1 is Joe, then boolean1 attribute of Entity1 is assigned the value of true.
1/13/2012
Rule Language Guide
Page 105
SAMPLE RULETEST
1/13/2012
Rule Language Guide
Page 106
LESS THAN
SYNTAX
DateTime* Number String <DateTime1> < <DateTime2> <Number1> < <Number2> <String1> < <String2>
DESCRIPTION
DateTime* Number String Returns a value of true if <DateTime1> is less than <DateTime2>. This is equivalent to <DateTime1> occurring before <DateTime2> Returns a value of true if <Number1> is less than <Number2>. Different numeric data types may be compared in the same expression. Returns a value of true if <String1> is less than <String2>. Studio uses Appendix A to determine character precedence.
USAGE RESTRICTIONS
The Operators row of the table in Figure 4 applies, with the following exception: less than may also be used in Conditional Value Sets & Cells (section 5 of Figure 5).
RULESHEET EXAMPLE
The following Rulesheet uses less than to test whether string1 is less than string2, and assign todays date to dateTime1 if it is. See today for an explanation of this literal term.
1/13/2012
Rule Language Guide
Page 107
SAMPLE RULETEST
1/13/2012
Rule Language Guide
Page 108
LESS THAN OR EQUAL TO

SYNTAX
DateTime* Number String <DateTime1> <= <DateTime2> <Number1> <= <Number2> <String1> <= <String2>
DESCRIPTION
DateTime* Number String Returns a value of true if <DateTime1> is less than or equal to <DateTime2>. This is equivalent to <DateTime1> occurring on or before <DateTime2> Returns a value of true if <Number1> is less than or equal to <Number2>. Different numeric data types may be compared in the same expression. Returns a value of true if <String1> is less than or equal to <String2>. Studio uses Appendix A to determine character precedence.
USAGE RESTRICTIONS
The Operators row of the table in Figure 4 applies, with the following exception: less than or equal to may also be used in Conditional Value Sets & Cells (section 5 of Figure 5).
RULESHEET EXAMPLE
The following Rulesheet uses less than or equal to to test whether string1 is less than or equal to string2, and assign todays date to dateTime1 if it is. See today for an explanation of this literal term.
1/13/2012
Rule Language Guide
Page 109
SAMPLE RULETEST
1/13/2012
Rule Language Guide
Page 110
LOGARITHM (BASE 10)

SYNTAX
<Number>.log
DESCRIPTION
Returns a Decimal value equal to the logarithm (base 10) of <Number>. If <Number> is equal to 0 (zero) an error is returned when the rule is executed.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .log to calculate the logarithm (base 10) of integer1 and assign it to decimal1.
SAMPLE RULETEST 1
A sample Ruletest provides results for three examples of integer1. Input and Output panels are shown below:
1/13/2012
Rule Language Guide
Page 111
SAMPLE RULETEST 2
Another sample Ruletest for three examples of integer1 where one example is equal to zero (0). The resulting error is illustrated below. Notice that the error encountered in the 2nd example causes all Rulesheet execution to halt, leaving the 3rd example unprocessed.
1/13/2012
Rule Language Guide
Page 112
LOGARITHM (BASE X)
SYNTAX
<Number>.log(<Decimal>)
DESCRIPTION
Returns a Decimal value equal to the logarithm (base <Decimal>) of <Number>. If <Number> is equal to 0 (zero) an error is returned when the rule is executed.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .log to calculate the logarithm (base 7.0) of integer1 and assign it to decimal1.
SAMPLE RULETEST 1
A sample Ruletest provides results for three examples of integer1. Input and Output panels are shown below:
1/13/2012
Rule Language Guide
Page 113
SAMPLE RULETEST 2
Another sample Ruletest for three examples of integer1 where one example is equal to zero (0). The resulting error is illustrated below.
1/13/2012
Rule Language Guide
Page 114
LOWERCASE
SYNTAX
<String>.toLower
DESCRIPTION
Converts all characters in <String> to lowercase characters.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .toLower to convert string1 to lowercase, compare its value with string2, and assign a value to boolean1 based on the results of the comparison.
1/13/2012
Rule Language Guide
Page 115
SAMPLE RULETEST
A sample Ruletest provides three examples of string1 and string2. Input and Output panels are shown below:
1/13/2012
Rule Language Guide
Page 116
MAXIMUM VALUE
SYNTAX
<Number1>.max(<Number2>)
DESCRIPTION
Returns either <Number1> or <Number2>, whichever is greater.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .max to compare the values of decimal1 and decimal2, and integer1 and integer2, and posts a message based on their size relative to 5.0 and 8, respectively.
1/13/2012
Rule Language Guide
Page 117
SAMPLE RULETEST
A sample Ruletest provides four examples, two using decimal1 and decimal2, and two using integer1 and integer2 as input data.
1/13/2012
Rule Language Guide
Page 118
MAXIMUM VALUE (COLLECTION)

SYNTAX
<Collection.attribute> -> max
DESCRIPTION
Returns the highest value of <attribute> for all elements in <Collection>. <attribute> must be a numeric data type. <Collection> must be expressed as a unique alias.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses max to identify the highest value of decimal1 in all elements of collection1, then assign it to Entity1.decimal1.
SAMPLE RULETEST
A sample collection contains five elements, each with a value of decimal1.
1/13/2012
Rule Language Guide
Page 119
MINIMUM VALUE
SYNTAX
<Number1>.min(<Number2>)
DESCRIPTION
Returns either <Number1> or <Number2>, whichever is smaller.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .min to compare the values of decimal1 and decimal2, and integer1 and integer2, and posts a message based on their size relative to 5.0 and 8, respectively
1/13/2012
Rule Language Guide
Page 120
SAMPLE RULETEST
A sample Ruletest provides four examples, two using decimal inputs, and two using integers.
1/13/2012
Rule Language Guide
Page 121
MINIMUM VALUE (COLLECTION)

SYNTAX
<Collection.attribute> -> min
DESCRIPTION
Returns the lowest value of <attribute> for all elements in <Collection>. <attribute> must be a numeric data type. <Collection> must be expressed as a unique alias.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses min to identify the lowest value of decimal1 in all elements of collection1, then assign it to Entity1.decimal1.
SAMPLE RULETEST
A sample collection contains five elements, each with a value of decimal1.
1/13/2012
Rule Language Guide
Page 122
MINUTE
SYNTAX
<DateTime>.min <Time>.min
DESCRIPTION
Returns the minute portion of <DateTime> or <Time> as an Integer between 0 and 59. This operator cannot be used with Date attributes because no time information is present.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .min to evaluate dateTime1 and assign the minute value to integer1.
SAMPLE RULETEST
A sample Ruletest provides three examples of dateTime1. Input and Output panels are shown below:
1/13/2012
Rule Language Guide
Page 123
MINUTES BETWEEN
SYNTAX
<DateTime1>.minsBetween(<DateTime2>) <Time1>.minsBetween(<Time2>)
DESCRIPTION
Returns the Integer number of minutes between DateTimes or between Times. The function calculates the number of milliseconds between the two dates and divides that number by 60,000 (the number of milliseconds in a minute). The decimal portion is then truncated. If the two dates differ by less than a full minute, the returned value is zero. This function returns a positive number if <DateTime2> is later than <DateTime1>.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .minsBetween to determine the number of minutes that have elapsed between dateTime1 and dateTime2, compare it to the Values set, and assign a value to string1.
1/13/2012
Rule Language Guide
Page 124
SAMPLE RULETEST
A sample Ruletest provides dateTime1 and dateTime2 for two examples. Input and Output panels are shown below. Notice the different masks (formats) used for the DateTime data.
1/13/2012
Rule Language Guide
Page 125
MOD
SYNTAX
<Integer1>.mod(<Integer2>)
DESCRIPTION
Returns the whole number remainder that results from dividing <Integer1> by <Integer2>. If the remainder is a fraction, then 0 (zero) is returned.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .mod to calculate the whole number remainder resulting from the division of integer2 by 3. The result is assigned to integer1.
SAMPLE RULETEST
A sample Ruletest provides three examples of integer2. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 126
MONTH
SYNTAX
<DateTime>.month <Date>.month
DESCRIPTION
Returns the month in <DateTime> or <Date> as an Integer between 1 and 12.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .month to evaluate dateTime1 and dateOnly1 and assign the month value to integer1 and integer2, respectively.
SAMPLE RULETEST
A sample Ruletest provides three examples of dateTime1 or dateOnly1. Input and Output panels are shown below. The month returned is independent of the machine running the Ruletest and only depends on the locale/timezone of the data itself.
1/13/2012
Rule Language Guide
Page 127
1/13/2012
Rule Language Guide
Page 128
MONTHS BETWEEN
SYNTAX
<DateTime1>.monthsBetween(<DateTime2>) <Date1>.monthsBetween(<Date2>)
DESCRIPTION
Returns the Integer number of months between DateTimes or between Dates. The month and year portions of the date data are subtracted to calculate the number of elapsed months. The day portions are ignored. If the month and year portions are the same, the result is zero. This function returns a positive number if <DateTime2> is later than <DateTime1>.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .monthsBetween to determine the number of months that have elapsed between dateTime1 and dateTime2, compare it to the values in the Condition Cells, and assign a value to string1.
1/13/2012
Rule Language Guide
Page 129
SAMPLE RULETEST
A sample Ruletest provides dateTime1 and dateTime2 for two examples. Input and Output panels are shown below. Notice the variations in date masks (formats).
1/13/2012
Rule Language Guide
Page 130
MULTIPLY
SYNTAX
<Number1> * <Number2>
DESCRIPTION
Multiplies <Number1> by <Number2>. The resulting data type is the more expansive of those of <Number1> and <Number2>.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses multiply to multiply integer1 and integer2 and compare the result to
100
SAMPLE RULETEST
A sample Ruletest provides three examples of integer1 and integer2. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 131
1/13/2012
Rule Language Guide
Page 132
NATURAL LOGARITHM
SYNTAX
<Number>.ln
DESCRIPTION
Returns a Decimal value equal to the natural logarithm (base e) of <Number>. If <Number> is equal to 0 (zero), an error is returned when the rule is executed. This error will halt execution for all data present.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .ln to calculate the natural logarithm of decimal2 and assign it to decimal1.
SAMPLE RULETEST 1
A sample Ruletest provides results for three examples of decimal2. Input and Output panels are shown below:
1/13/2012
Rule Language Guide
Page 133
SAMPLE RULETEST 2
Another sample Ruletest for three examples of decimal2 where one example is equal to zero (0). The resulting error is illustrated below:
1/13/2012
Rule Language Guide
Page 134
NEW
SYNTAX
<Entity>.new[<Expression1>,<Expression2>]
DESCRIPTION
creates a new <Entity> with attribute values defined by optional <Expression>. Expressions (when present) should be written as assignments in the form: attribute = value. The attribute used in <Expression> (when present) must be an attribute of <Entity>.
USAGE RESTRICTIONS
The Operators row of the table in Figure 4 does not apply. Special exceptions: new may only be used in Action Rows (section 5 in Figure 5). AND logic, expressed as commas between <Expressions>, is supported within the square brackets [..]. OR logic is not supported within the square brackets [..].
RULESHEET EXAMPLE
The following Rulesheet uses .new to create a new Entity2 element in collection1 when Entity1 has a string1 value equal to PO 123-ABC. An alias is not required by the .new operator, because it is possible to create a new entity at the root level, without inserting it into a collection. The collection alias used here is required by the += (Associate Element to collection) operator.
1/13/2012
Rule Language Guide
Page 135
SAMPLE RULETEST
A sample Ruletest provides 2 collections of Entity1. Input and Output panels are illustrated below:
1/13/2012
Rule Language Guide
Page 136
NEW UNIQUE
SYNTAX
<Entity>.newUnique[<Expression1>,<Expression2>]
DESCRIPTION
newUnique is an unusual operator in that it contains both action and condition logic. When an Action containing this operator is executed, a new <Entity> will be created only if no other entity exists with the characteristics defined by <Expression1> and <Expression2>, etc. <Expression1> and <Expression2> are optional. If no expression is present within the square brackets [..], the newUnique operator will create a new entity only if none currently exists in memory.
USAGE RESTRICTIONS
The Operators row of the table in Figure 4 does not apply. Special exceptions: newUnique may only be used in Action Rows (section 5 in Figure 5). AND logic, expressed as commas between <Expressions>, is supported within the square brackets [..]. OR logic is not supported within the square brackets [..].
RULESHEET EXAMPLE
The following Rulesheet uses .newUnique to create a new Entity2 element with string1=abc, and add it to collection1 only if no existing Entity2 already has string1=abc. A collection alias is not required by the .newUnique operator because it is possible to create a new entity at the root level, without inserting it into a collection. The collection alias used here is required by the += (Associate Element to collection) operator.
1/13/2012
Rule Language Guide
Page 137
SAMPLE RULETESTS
Each of three sample tests provides different combinations of Entity1 and Entity2. Input and Output panels are illustrated below:
1/13/2012
Rule Language Guide
Page 138
NOT
SYNTAX
not <Expression>
DESCRIPTION
Returns the negation of the truth value of <Expression>.
USAGE RESTRICTIONS
The Operators row of the table in Figure 4 applies, with the following special exception: not may also be used in Conditional Cells.
RULESHEET EXAMPLE
The following Rulesheet uses not to negate the value of A in the Condition Cell of rule 2. Not may only be used in this manner if there is at least one other value (including other or null) present in the Condition Cells values drop-down list (i.e., there must be at least one alternative to the value negated by not).
1/13/2012
Rule Language Guide
Page 139
SAMPLE RULETEST
A sample Ruletest provides three examples of string1. Input and Output panels are shown below:
1/13/2012
Rule Language Guide
Page 140
NOT EMPTY
SYNTAX
<Collection> ->notEmpty
DESCRIPTION
Returns a value of true if <Collection> contains at least one element. notEmpty does not check for attribute values, but instead checks for the existence of elements within a collection. As such, it requires the use of a unique alias to represent the collection being tested.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses the notEmpty function to determine if collection1 has elements. Note the use of unique alias collection1 to represent the collection of Entity2 associated with Entity1.
SAMPLE RULETEST
A sample Ruletest provides two collections. The following illustration shows Input and Output panels
1/13/2012
Rule Language Guide
Page 141
NOT EQUAL TO
SYNTAX
Boolean DateTime* Number String <Expression1> <> <Expression2> <DateTime1> <> <DateTime2> <Number1> <> <Number2> <String1> <> <String2>
DESCRIPTION
Boolean DateTime* Number String Returns a value of true if <Expression1> does not have the same truth value as <Expression2>. Returns a value of true if <DateTime1> does not equal <DateTime2>. This is equivalent to <DateTime1> not occurring on <DateTime2> Returns a value of true if <Number1> is not equal to <Number2>. Different numeric data types may be compared in the same expression. Returns a value of true if <String1> is not equal to <String2>. Studio uses Appendix A to determine character precedence.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses not equal to to test whether decimal1 equals decimal2, and assign a value to string1 based on the result of the comparison.
1/13/2012
Rule Language Guide
Page 142
SAMPLE RULETEST
1/13/2012
Rule Language Guide
Page 143
NOW
SYNTAX
now
DESCRIPTION
Returns the current system date and time when the rule is executed. This DateTime value is assigned the first time now is used in a Decision Service (Rule Set), then remains constant until the Decision Service finishes execution, regardless of how many additional times it is used. This means that every rule in a Rule Set containing now will use the same DateTime value.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses now to determine how many hours have elapsed between now and dateTime1 (see .hoursBetween for more details on this operator), and assign a value to string1 based on the result.
SAMPLE RULETEST
A sample Ruletest provides two examples of dateTime1. Assume now is equal to Thursday, March 16, 2006 8:50:00 AM EST. Input and Output panels are shown below. Notice the variation in DateTime masks (formats).
1/13/2012
Rule Language Guide
Page 144
1/13/2012
Rule Language Guide
Page 145
NULL
SYNTAX
null
DESCRIPTION
The null value corresponds to one of three different scenarios: 1. the absence of an attribute in a Ruletest Input pane or request message 2. the absence of data for an attribute in a Ruletest (the value zero counts as data) 3. a business object (supplied by an external application) that has an instance variable of null A null value is different from an empty String (for String data types) or zero for numeric data types. An empty String is represented in Studio Ruletest as []. Any attribute value, including any empty strings, may be reset to null in a Ruletest by right-clicking the attribute and choosing select value to null. Mandatory attributes (property set in the Vocabulary) may not have a null value.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses null to test for the existence of a real value in decimal1, and assign a value to boolean1 as a result.
1/13/2012
Rule Language Guide
Page 146
SAMPLE TEST
A sample Ruletest provides four examples of decimal1. Input and Output panels are illustrated below. Posted messages are not shown.
1/13/2012
Rule Language Guide
Page 147
OTHER
SYNTAX
other
DESCRIPTION
When included in a conditions Values set (the drop-down list of values available in a Conditions Cell), other represents any value not explicitly included in the set, including null. If null is explicitly included in the Values set, then other does not include null.
USAGE RESTRICTIONS
The Literals row of the table in Figure 4 does not apply. Special exception: other may only be used in Condition Cells (section 4 of the Figure 5) because it is a non-specific value used in comparisons.
RULESHEET EXAMPLE
The following Rulesheet uses other to test the value of decimal1. If decimal1 has any value other than null, boolean1 is assigned the value of false.
1/13/2012
Rule Language Guide
Page 148
SAMPLE TEST
A sample Ruletest provides three examples of decimal1. Ruletest Input and Output panels are shown below:
1/13/2012
Rule Language Guide
Page 149
OR
SYNTAX
<Expression1> or <Expression2> or . OR may also be used with forAll and exists expressions
DESCRIPTION
Returns a value of true if either <Expression1> or <Expression2> evaluates to true. When used between two or more expressions in the Preconditions section, creates a compound filter for the Rulesheet that follows. See Rule Modeling Guide for details on using Preconditions as filters. OR is not available in the Conditions section because the logical OR construction is implemented using multiple Columns in the decision table, or by value sets in Conditions Cells.
USAGE RESTRICTIONS
The Literals row of the table in Figure 5 does not apply. Special exception: or may only be used in the Filters section of the Rulesheet to join 2 or more expressions, as shown above, or within forAll and exists expressions as described in those sections.
RULESHEET EXAMPLE
The following Rulesheet uses or to test the value of integer1, boolean1, and string1 to set the value of boolean2
1/13/2012
Rule Language Guide
Page 150
SAMPLE TEST
A sample Ruletest provides three examples. Ruletest Input and Output panels are shown below:
1/13/2012
Rule Language Guide
Page 151
REMOVE ELEMENT
SYNTAX
<Entity>.remove <Collection>.remove
DESCRIPTION
Removes <Entity> or removes elements from <Collection> and deletes it/them. If removing from a collection, then using a unique alias to represent the collection is optional since .remove is not a collection operator. If any elements in <Collection> have one-to-many associations with other entities, then those entities will also be deleted. When using .remove to delete elements of a collection, associated entities will not be removed. To remove a chain of associated entities, use .remove on each level of the association hierarchy, beginning with the last or lowest level and working up. For example of this behavior, see example 2, below.
USAGE RESTRICTIONS
The Operators row of table in Figure 4 does not apply. Special exceptions: .remove may only be used in Action Rows (section 5 in Figure 5).
RULESHEET EXAMPLE
This Rulesheet uses the operator to remove elements from collection1 whose decimal1 value is greater than 5. Note the optional use of unique alias collection1 to represent the collection of Entity2 elements associated with Entity1.
1/13/2012
Rule Language Guide
Page 152
SAMPLE TEST
A sample Ruletest provides a collection with two elements. The illustration showsRuletest Input and Output panels
RULESHEET EXAMPLE 2
This Rulesheet uses the operator to remove elements from Entity1.entity2 whose decimal1 value is greater than 5. Note no unique alias has been used to represent the collection of Entity2 elements associated with Entity1.
1/13/2012
Rule Language Guide
Page 153
SAMPLE RULETEST 2
A sample Ruletest provides an Entity1 with two entity2, each of which has an entity3 child of its own. The illustration shows Ruletest Input and Output panels. Note that when an entity2 is removed, its associated entity3 is moved to the root level.
1/13/2012
Rule Language Guide
Page 154
REPLACE ELEMENT(S)
SYNTAX
<Collection1> = <Collection2> <Collection> = <Entity>
DESCRIPTION
Replaces all elements in <Collection1> with the elements in <Collection2>, provided the association between the two is permitted by the Business Vocabulary. In the second syntax, <Entity> is associated with <Collection>, replacing the <Entity> already associated, when the association between the two is one-to-one in the Business Vocabulary. All collections must be expressed as unique aliases.
USAGE RESTRICTIONS
The Operators row of table in Figure 4 does not apply. Special exceptions: replace element may only be used in Action Rows (section 5 in Figure 5).
RULESHEET EXAMPLE
This sample Rulesheet uses the replace element operator to add Entity3 to collection1 if its boolean1 value is true. Note the use of unique alias collection1 to represent the collection of Entity3 elements associated with Entity2. Recall from the generic Business Vocabulary shown in Figure 1, the association between Entity2 and Entity3 has a cardinality of one-to-one. This means that if multiple Entity3 are present, only one will be added to collection1.
1/13/2012
Rule Language Guide
Page 155
SAMPLE TEST
Four sample tests provide scenarios of two elements which share a one-to-one association. Input and Output panels are illustrated below:
1/13/2012
Rule Language Guide
Page 156
ROUND
SYNTAX
<Decimal>.round(<Integer>)
DESCRIPTION
Rounds <Decimal> to the number of decimal places specified by <Integer>. Standard rounding conventions apply, meaning numbers ending with significant digits of 5 or more round up and numbers ending with significant digits less than 5 round down. <Integer> is optional if no parameter is specified, then <Decimal> rounds to the nearest whole number of type Decimal.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .round to round the value of decimal2 to the 2nd decimal place, and assigns it to decimal1.
1/13/2012
Rule Language Guide
Page 157
SAMPLE TEST
A sample Ruletest provides results for five examples of decimal2.
1/13/2012
Rule Language Guide
Page 158
SECOND
SYNTAX
<DateTime>.sec <Time>.sec
DESCRIPTION
Returns the seconds portion of <DateTime> or <Time>. The returned value is an Integer between 0 and 59.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses the .sec function to evaluate dateTime1, return the seconds value, and assign it to integer1.
SAMPLE TEST
A sample Ruletest provides results for two examples of dateTime1.
1/13/2012
Rule Language Guide
Page 159
SECONDS BETWEEN
SYNTAX
<DateTime1>.secsBetween(<DateTime2>) <Time1>.secsBetween(<Time>)
DESCRIPTION
Returns the Integer number of seconds between DateTimes or between Times. The number of milliseconds in <DateTime1> is subtracted from that in <DateTime2>, and the result divided by 1000 (the number of milliseconds in a second). The result is truncated. This function returns a positive number if <DateTime2> is later than <DateTime1>.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .secsBetween to determine the number of seconds that have elapsed between dateTime1 and dateTime2, compare it to the Values set, and assign a value to string1.
1/13/2012
Rule Language Guide
Page 160
SAMPLE TEST
1/13/2012
Rule Language Guide
Page 161
SIZE OF STRING
SYNTAX
<String>.size
DESCRIPTION
Returns the Integer number of characters in <String>. All characters, numbers, symbols, and punctuation marks are counted, including spaces before, within, and after words.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses the .size function to determine the length of string1 and assign it to
integer1
SAMPLE TEST
1/13/2012
Rule Language Guide
Page 162
SIZE OF COLLECTION
SYNTAX
<Collection> ->size
DESCRIPTION
Returns the Integer number of elements in <Collection>. <Collection> must be expressed as a unique alias.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses size to count the number of elements in collection1, and assign a value to boolean2. Note the use of unique alias collection1 to represent the collection of Entity2 associated with Entity1.
1/13/2012
Rule Language Guide
Page 163
SAMPLE TEST
A sample Ruletest provides three examples of collection1. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 164
SORTED BY
SYNTAX
<Collection> ->sortedBy(<Attribute2>) -> sequence operator.<Attribute1>
DESCRIPTION
Sequences the elements of <Collection> in ascending order, using the value of <Attribute2> as the index, and returns the <Attribute1> value of the element in the sequence position determined by the sequence operator. A sequence must be created before any sequence operator (first, last, or at) is used to identify a particular element. <Attribute1> and <Attribute2> must be attributes of <Collection>. <Attribute2> may be any data type except Boolean. Strings are sorted according to character precedence see Appendix A. <Collection> must be expressed as a unique alias. See Advanced Collection Syntax and special statement block syntax for more examples of usage.
USAGE RESTRICTIONS
RULESHEET EXAMPLE 1 USED IN A CONDITION

This sample Rulesheet uses sortedBy in a conditional expression to create an ascending sequence from collection with decimal1 as the index. first.string1 is used to return the value of the string1 attribute of the first element of the sequence. If the value of string1 is Joe, then boolean1 attribute of Entity1 is assigned the value of true.
1/13/2012
Rule Language Guide
Page 165
SAMPLE RULETEST 1
A sample Ruletest provides a collection of three elements, each with a decimal1 and string1 value. Input and Output panels are shown below.
RULESHEET EXAMPLE 2 USED IN AN ACTION

This sample Rulesheet uses sortedBy in an action expression to create an ascending sequence from collection with decimal1 as the index. first.string1 is used to return the value of the string1 attribute of the first element of the sequence. The value of string1 is assigned the value of Joe if boolean1 attribute of Entity1 is true, if false it is assigned the value of Mary.
1/13/2012
Rule Language Guide
Page 166
SAMPLE RULETEST 2
A sample Ruletest provides a collection of three elements, each with a decimal1 and string1 value. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 167
SORTED BY DESCENDING
SYNTAX
<Collection> ->sortedByDesc(<Attribute2>) -> sequence operator.<Attribute1>
DESCRIPTION
Sequences the elements of <Collection> in descending order, using the value of <Attribute2> as the index, and returns the <Attribute1> value of the element in the sequence position determined by the sequence operator. A sequence must be created before any sequence operator (first, last, or at) is used to identify a particular element. <Attribute1> and <Attribute2> must be attributes of <Collection>. <Attribute2> may be any data type except Boolean. Strings are sorted according to their ISO character precedence see Appendix A. <Collection> must be expressed as a unique alias. See Advanced Collection Syntax and special statement block syntax for more examples of usage.
USAGE RESTRICTIONS
RULESHEET EXAMPLE 1 USED IN A CONDITION

This sample Rulesheet uses sortedByDesc in a conditional expression to create a descending sequence from collection with decimal1 as the index. first.string1 is used to return the value of the string1 attribute of the first element of the sequence. If the value of string1 is Joe, then boolean1 attribute of Entity1 is assigned the value of true.
1/13/2012
Rule Language Guide
Page 168
SAMPLE RULETEST 1
RULESHEET EXAMPLE 2 USED IN AN ACTION

This sample Rulesheet uses sortedByDesc in an action expression to create a descending sequence from collection with decimal1 as the index. first.string1 is used to return the value of the string1 attribute of the first element of the sequence. The value of string1 is assigned the value of Joe if boolean1 attribute of Entity1 is true, if false it is assigned the value of Mary.
1/13/2012
Rule Language Guide
Page 169
SAMPLE RULETEST 2
1/13/2012
Rule Language Guide
Page 170
STARTS WITH
SYNTAX
<String1>.startsWith(<String2>)
DESCRIPTION
Returns a value of true if <String1> begins with the characters specified in <String2>. Comparisons are case-sensitive.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .startsWith to evaluate whether string1 begins with the value of string2 and assigns a different value to boolean1 for each outcome.
1/13/2012
Rule Language Guide
Page 171
SAMPLE TEST
A sample Ruletest provides string1 and string2 values for four examples. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 172
SUBSTRING
SYNTAX
<String>.substring( <Integer1>, <Integer2>)
DESCRIPTION
Returns the portion of <String> beginning with the character in position <Integer1> and ending with the character in position <Integer2>. The number of characters in <String> must be at least equal to <Integer2>, otherwise an error will be produced. Both <Integer1> and <Integer2> must be positive integers, and <Integer2> must be greater than <Integer1>.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses .substring to return those characters of string1 between positions 4 and 7 (inclusive), and assign the resulting value to string2.
1/13/2012
Rule Language Guide
Page 173
SAMPLE RULETEST 1
A sample Ruletest provides string1 values for four examples. Input and Output panels are shown below.
SAMPLE RULETEST 2
Another sample Ruletest shows string1 values with two examples having insufficient character strings. The resulting error message is illustrated below:
1/13/2012
Rule Language Guide
Page 174
SUBTRACT
SYNTAX
<Number1> - <Number2>
DESCRIPTION
Subtracts the value of <Number2> from that of <Number1>. The resulting data type is the more expansive of those of <Number1> and <Number2>.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This sample Rulesheet uses subtract to reduce the value of decimal1 by decimal2, compare the resulting value to zero, and assign a value to boolean1
1/13/2012
Rule Language Guide
Page 175
SAMPLE TEST
A Ruletest provides three examples of decimal1 and decimal2. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 176
SUM
SYNTAX
<Collection.attribute> ->sum
DESCRIPTION
Sums the values of the specified <attribute> for all elements in <Collection>. <attribute> must be a numeric data type. <Collection> must be expressed as a unique alias.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This Rulesheet uses the sum function to add all decimal1 attributes within collection1. Note the use of unique alias collection1 to represent the collection of Entity2 associated with
Entity1
1/13/2012
Rule Language Guide
Page 177
SAMPLE TEST
A sample Ruletest provides 3 elements in collection1. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 178
TODAY
SYNTAX
today
DESCRIPTION
Returns the current system date when the rule is executed. This Date Only value is assigned the first time today is used in a Decision Service (Rule Set), then remains constant until the Decision Service finishes execution, regardless of how many additional times it is used. This means that every rule in a Rule Set using today will use the same Date Only value. No time portion is assigned
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses today to determine how many days have elapsed between today and dateTime1, and assign a value to string1 based on the result.
1/13/2012
Rule Language Guide
Page 179
SAMPLE TEST
A sample Ruletest provides three examples of dateOnly1. Assume today is equal to Friday, November 23, 2007. Input and Output panels are shown below:
1/13/2012
Rule Language Guide
Page 180
TO DATE CASTING A DATETIME TO A DATE

SYNTAX
<DateTime>.toDate
DESCRIPTION
Converts the value in <DateTime> to a Date datatype, containing only the date portion of the DateTime. If <DateTime> contains no date information, then the system epoch is used.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .toDate to convert dateTime1 and DateTime2 to Date datatypes and assign the values to dateTime1 and dateTime2.
SAMPLE TEST
1/13/2012
Rule Language Guide
Page 181
TO DATETIME CASTING A STRING TO A DATETIME

SYNTAX
<String>.toDateTime
DESCRIPTION
Converts the value in <String> to data type DateTime ONLY if all characters in <String> correspond to a valid Date, Time, or DateTime mask (format). For complete details on DateTime masks, see Rule Modeling Guide
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .toDateTime to convert string1 to type DateTime and assign the value to dateTime1.
SAMPLE TEST
1/13/2012
Rule Language Guide
Page 182
TO DATETIME CASTING A DATE TO A DATETIME

SYNTAX
<Date>.toDateTime
DESCRIPTION
Converts the value in <Date> to data type DateTime. The date portion is the same as the <Date> value and the time portion is set to 12:00:00 AM in the current timezone.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .toDateTime to convert dateOnly1 to type DateTime and assign the value to dateTime1.
SAMPLE TEST
1/13/2012
Rule Language Guide
Page 183
TO DATETIME CASTING A TIME TO A DATETIME

SYNTAX
<Time>.toDateTime
DESCRIPTION
Converts the value in <Time> to data type DateTime ONLY if all characters in <Time> correspond to a valid DateTime mask (format). The time portion is the same as the <Time> value and the date portion is the epoch (see .toTime operator)
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .toDateTime to convert timeOnly1 to type DateTime and assign the value to dateTime1.
SAMPLE TEST
1/13/2012
Rule Language Guide
Page 184
TO DATETIME TIMEZONE OFFSET

SYNTAX
<Date>.toDateTime(<String>)
DESCRIPTION
Converts the value in <Date> to data type DateTime ONLY if all characters in <Date> correspond to a valid DateTime mask (format). The date portion is the same as the <Date> value and the time portion is set to 00:00:00 in the timezone specified by <String>, which is the timeZoneOffset. The timeZoneOffset must take the form of a valid timezone offset such as -08:00, +03:30, 01:45
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .toDateTime to convert dateOnly1 to type DateTime and assign the value to dateTime1, with a timezone offset of -5.
SAMPLE TEST
1/13/2012
Rule Language Guide
Page 185
TO DECIMAL
SYNTAX
<Integer>.toDecimal <String>.toDecimal
DESCRIPTION
Converts the value in <Integer> or all characters in <String> to data type Decimal. Converts a String to Decimal ONLY if all characters in <String> are numeric and contain not more than one decimal point. If any non-numeric characters are present in <String> (other than the single decimal point or a leading minus sign), no value is returned by the function. Note: Integer values may be assigned directly to Decimal data types without using the .toDecimal operator because a Decimal data type is more expansive than an Integer.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .toDecimal to convert integer1 and string1 to type Decimal and assign them to decimal1 and decimal2, respectively.
1/13/2012
Rule Language Guide
Page 186
SAMPLE TEST
1/13/2012
Rule Language Guide
Page 187
TO INTEGER
SYNTAX
<Decimal>.toInteger <String>.toInteger
DESCRIPTION
Converts the value in <Decimal> or all characters in <String> to data type Integer. All decimals have fractional portions truncated during the conversion. Strings are converted ONLY if all characters in <String> are numeric, without a decimal point. If any non-numeric characters (with the sole exception of a single leading minus sign for negative numbers) are present in <String>, no value is returned by the function. Do not use on String values of null or empty String () as this will generate an error message.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .toInteger to convert decimal1 and string1 to type Integer and assign them to integer1 and integer2, respectively.
1/13/2012
Rule Language Guide
Page 188
SAMPLE TEST
1/13/2012
Rule Language Guide
Page 189
TO STRING
SYNTAX
<Number>.toString <DateTime*>.toString *includes DateTime, Date, and Time data types
DESCRIPTION
Converts a value to a data type of String.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .toString to convert 3 data types to strings. Rule N.3 also uses the alternative String concatenation syntax. See Add Strings for details.
SAMPLE TEST
1/13/2012
Rule Language Guide
Page 190
TO TIME CASTING A DATETIME TO A TIME

SYNTAX
<DateTime>.toTime
DESCRIPTION
Converts the value in <DateTime> to a Time data type, containing only the time portion of the full DateTime. If <DateTime> contains no time information, then the time portion is set to 12:00:00 AM in the current timezone. Note: Should this value be saved in a database field supporting a full DateTime, the date portion is saved as the epoch specified in com.corticon.crml.OclDate.epochForTimeValues. See Server Integration & Deployment Guide for a complete description of this and other properties inside CcCommon.properties.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .toTime to convert dateTime1 to Time and assign the value to TimeOnly1.
SAMPLE TEST
1/13/2012
Rule Language Guide
Page 191
TREND
SYNTAX
<Collection.attribute> -> <Sequence>.trend
DESCRIPTION
Returns one of the following 4-character strings depending on the trend of <Collection.attribute> once sequenced by the same or different attribute in <Collection>. <Sequence> is an ordered set of <Collection> in the form {x1, x2, x3 xn}, where
INCR the value of <attribute> of element xn+1 is greater than or equal to the value of
<attribute> of element xn for every element. At least one <attribute> value of element x must be greater than that of xn-1
DECR the value of <attribute> of element xn+1 is less than or equal to the value of <attribute>
of element xn for every element. At least one <attribute> value of element x must be less than that of xn-1
CNST the value of <attribute> of element xn+1 is equal to the value of <attribute> for
element xn for every element.

NONE any <sequence> with elements not meeting the requirements for INCR, DECR, or CNST
An alternative way to understand this operator is to view the index attribute used to sequence the collection as the independent variable (traditionally plotted along the x axis in a standard x-y graph) in a set of data pairs. The attribute evaluated by the .trend operator, <Collection.attribute>, is the dependent variable, plotted along the y axis. When so plotted, the 4-character words returned by .trend correspond to curves with positive, negative, zero (constant), or arbitrary slopes2.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
This Rulesheet uses the .trend function to analyze integer1 attributes within collection1 sorted by decimal1. The resulting trend value is assigned to string1.
Technically, the slope of an INCR curve need not be positive everywhere, but must have a first derivative (instantaneous slope) that is positive at some point along the curve and never be negative. The slope of a CNST curve must be zero everywhere.
1/13/2012
Rule Language Guide
Page 192
SAMPLE TEST
Two sample tests provide two collections of elements, each with a decimal1 and integer1 values. Input and Output panels are shown below.
1/13/2012
Rule Language Guide
Page 193
TRUE
SYNTAX
true or T
DESCRIPTION
Represents Boolean value true. Recall from the discussion of truth values that an <expression> is evaluated for its truth value, so the expression Entity1.boolean1=true will evaluate to true only if boolean1=true. But since boolean1 is Boolean and has a truth value all by itself without any additional syntax, we dont actually need the =true piece of the expression. Many examples in the documentation use explicit syntax like boolean1=true or boolean2=false for clarity and consistency, even though boolean1 or not boolean2 are equivalent logical expressions.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses true in a Precondition to Ruletest whether boolean1 is true, and perform the Nonconditional computation if it is. As discussed above, the alternative expression Entity1.boolean1 is logically equivalent.
1/13/2012
Rule Language Guide
Page 194
SAMPLE TEST
A sample Ruletest provides three examples. Assume decimal2=10.0 and integer1=5 for all examples. Input and Output panels are shown below:
1/13/2012
Rule Language Guide
Page 195
UPPERCASE
SYNTAX
<String>.toUpper
DESCRIPTION
Converts all characters in <String> to uppercase.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .toUpper to convert string2 to uppercase and assign it to string1.
SAMPLE TEST
1/13/2012
Rule Language Guide
Page 196
WEEK OF MONTH
SYNTAX
<DateTime>.weekOfMonth <Date>.weekOfMonth
DESCRIPTION
Returns an Integer from 1 to 6, equal to the week number within the month in <DateTime> or <Date>. A week begins on Sunday and ends on Saturday.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .weekOfMonth to assign a value to integer1.
SAMPLE TEST
1/13/2012
Rule Language Guide
Page 197
WEEK OF YEAR
SYNTAX
<DateTime>.weekOfYear <Date>.weekOfYear
DESCRIPTION
Returns an Integer from 1 to 52, equal to the week number within the year in <DateTime> or <Date>. A week begins on Sunday and ends on Saturday. When a year ends between Sunday and the next Friday, or in other words when a new year begins between Monday and the next Saturday, the final day(s) of December will be included in week 1 of the new year. For example, 12/29/2002 fell on a Sunday, so 12/29-31 are included in week 1 of 2003.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .weekOfYear to assign a value to integer1.
SAMPLE TEST
1/13/2012
Rule Language Guide
Page 198
YEAR
SYNTAX
<DateTime>.year <Date>.year
DESCRIPTION
Returns the century/year portion of <DateTime> or <Date>. The returned value is a four digit Integer.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .year to evaluate dateTime1 and dateOnly1 and assign the year values to integer1 and integer2, respectively.
SAMPLE TEST
A sample Ruletest provides three examples of dateTime1 and dateOnly1. Input and Output panels are shown below:
1/13/2012
Rule Language Guide
Page 199
1/13/2012
Rule Language Guide
Page 200
YEARS BETWEEN
SYNTAX
<DateTime1>.yearsBetween(<DateTime2>) <Date1>.yearsBetween(<Date2>)
DESCRIPTION
Returns the Integer number of years between DateTimes or between Dates. The number of months in <DateTime2> is subtracted from the number of months in <DateTime1>, and the result is divided by 12 and truncated. This function returns a positive number if <DateTime2> is later than <DateTime1>.
USAGE RESTRICTIONS
RULESHEET EXAMPLE
The following Rulesheet uses .yearsBetween to determine the number of months that have elapsed between dateTime1 and dateTime2, compare it to the Values set, and assign a value to string1.
SAMPLE TEST
1/13/2012
Rule Language Guide
Page 201
SPECIAL SYNTAX
The following sections describe special rule language syntax not found in the Operator Vocabulary.
VALUE RANGES
When using values in Condition Cells for Integers, Decimals, Strings, or DateTime data types, the values do not need to be discreet they may be in the form of a range 3. A value range is typically expressed in the following format: x..y, where x and y are the starting and ending values for the range inclusive of the endpoints if there is no other notation to indicate otherwise. This is illustrated in Figure 6 below.
Numeric Value Ranges in Conditions
Figure 6 - Rulesheet using Numeric Value Ranges in Condition Values Set
In this example, we are assigning an integer2 value to Entity1 depending on its integer1 value. The value range 101..200 represents all values (integers in this case) between 101 and 200, including 101 and 200. This is an inclusive range because both the starting and ending values are included in the range.
Numeric Value Ranges in Filter Rows

Numeric value ranges can be used as Filter expressions as shown in Figure 7. Note the use of special term in, as shown below.
3
Range syntax is not supported for Boolean data types
1/13/2012
Rule Language Guide
Page 202
Figure 7 - Rulesheet using a Numeric Value Range as a Precondition/Filter
String Value Ranges in Condition Cells

When using value range syntax with String types, be sure to enclose literal values inside single quotes, as shown in Figure 8. Studio will usually perform this for you, but always check to make sure it has interpreted your entries correctly.
Figure 8 - Rulesheet using String Value Ranges in Condition Values Set
String Value Ranges in Filter Rows

String value ranges can be used as Filter expressions as shown in Figure 11. Note the use of special term in. Also notice the use of Boolean operator or to combine two expressions. This single Precondition is satisfied only if string1 is an English letter.
Figure 9 - Rulesheet using String Value Ranges in Precondition Value Set
DateTime, Date, and Time Value Ranges in Condition Cells

When using value range syntax with date types, be sure to enclose literal date values inside single quotes, as shown in Figure 10.
1/13/2012
Rule Language Guide
Page 203
Figure 10 - Rulesheet using a Date Value Range in Condition Cells
DateTime, Date, and Time Value Ranges in Filter Rows

DateTime, Date, and Time value ranges can be used as Filter expressions as shown in Figure 11. Note the use of special term in.
Figure 11 - Rulesheet using a Date Value Range in a Filter
Inclusive & Exclusive Ranges

Studio also gives you the option of defining value ranges where one or both of the starting and ending values are exclusive, meaning that the starting/ending value is not included in the range of values. Figure 12 shows the same Rulesheet as in Figure 6, but with one difference: we have changed the value range 201..300 to (200..300]. The starting parenthesis ( indicates that the starting value for the range, 200, is excluded it is not included in the range of possible values. The ending bracket ] indicates that the ending value is inclusive. Since integer1 is an Integer value, and therefore no fractional values are allowed, 201..300 and (200..300] are equivalent and our Values set in Figure 12 is still complete as it was in Figure 6.
1/13/2012
Rule Language Guide
Page 204
Figure 12 - Rulesheet using an Integer Value Range in Condition Values Set
Listed below are all of the possible combinations of parenthesis and bracket notation for value ranges and their meanings:
(x..y) (x..y] [x..y) [x..y]
- is the range between x & y, excluding both x & y - is the range between x & y, excluding x and including y - is the range between x & y, including x and excluding y - is the range between x & y, including both x & y
As illustrated in Figure 6 and Figure 12, if a value range has no enclosing parentheses or brackets, it is assumed to be closed. It is therefore not necessary to use the [..] notation for a closed range in Studio; in fact, if you try to create a closed value range by entering [..], the square brackets will be automatically removed. However, should either end of a value range have a parenthesis or a bracket, then the other end must also have a parenthesis or a bracket. For example, x..y) is not allowed, and is properly expressed as [x..y). When using range notation, always ensure x is less than y, i.e., an ascending range. A range where x is greater than y (a descending range) may result in errors during rule execution.
Overlapping Value Ranges

One final note about value ranges: they may overlap in Studio 5.2. In other words, Condition Cells may contain the two ranges 0..10 and 5..15. This is a change from Studio 4.x and earlier, where overlapping Value sets were not allowed. However, it is important to understand that when overlapping ranges exists in rules, the rules containing the overlap are frequently ambiguous and more than one rule may fire for a given set of input Ruletest data. Figure 13 shows an example of value range overlap, and the tooltip message generated.
Copyright 2000-2012 Progress Software Corporation. All rights reserved. 1/13/2012
Rule Language Guide
Page 205
Figure 13 - Rulesheet with Value Range Overlap
Figure 14 - Rulesheet expanded with Ambiguity Check applied
Figure 15 - Ruletest showing multiple rules firing for given test data
1/13/2012
Rule Language Guide
Page 206
USING VALUE SETS IN CONDITION CELLS

Most Conditions implemented in the Rules section of the Rulesheet use a single value in a Cell, as shown in Figure 16.
Figure 16 - Rulesheet with One Value Selected in Condition Cell
Sometimes, however, its useful to combine more than one value in the same Cell. This is accomplished by holding CTRL while clicking to select multiple values from the Condition Cell dropdown box. When multiple values are selected in this manner, pressing ENTER will automatically enclose the resulting set in curly brackets {..} in the Cell as shown in the sequence of Figure 17 and Figure 18. Additional values may also be typed into Cells. Be sure the comma separators and curly brackets remain correct during hand-editing.
Figure 17 - Rulesheet with Two Values Selected in Condition Cell
Figure 18 - Rulesheet with Value Set in Condition Cell
The rule implemented in Column 1 of Figure 18 is logically equivalent to the Rulesheet shown in Figure 19. Both are implementations of the following rule statement:
1/13/2012
Rule Language Guide
Page 207
1. If a flightplans cargo weight is less than 200 OR greater than 400, then the flightplans aircraft type must be a DC-10
Figure 19 - Rulesheet with Two Rules in Lieu of Value Set
If you write rules that are logically ORed in separate Columns, performing a Compression will reduce the Rulesheet to the fewest number of Columns possible by creating value sets in Cells wherever possible. Fewer Columns results in faster Rulesheet execution, even when those Columns contain value sets. Compressing the Rulesheet in Figure 19 will result in the Rulesheet in Figure 18. Condition Cell value sets can also be negated using the not operator. To negate a value, simply type not in front of the leading curly bracket { as shown in Figure 20. This is an implementation of the following rule statement:
1. If a flightplans cargo weight is NOT less than 200 OR NOT greater than 400, then the flightplans aircraft type must be a DC-10
which, given the Condition Cells value set, is equivalent to:

1. If a flightplans cargo weight is between 200 and 400 (inclusive), then the flightplans aircraft type must be a DC-10
Figure 20 - Negating a Value Set in a Condition Cell
Value sets can also be created in the Overrides Cells at the foot of each Column. This allows one rule to override multiple rules in the same Rulesheet.
1/13/2012
Rule Language Guide
Page 208
EMBEDDING ATTRIBUTES IN POSTED RULE STATEMENTS

It is frequently useful to embed attribute values within a Rule Statement, so that posted messages contain actual data. Special syntax must be used to differentiate the static text of the rule statement from the dynamic value of the attribute. As shown in Figure 21, an embedded attribute must be enclosed by curly brackets {..} to distinguish it from the static Rule Statement text. It may also be helpful to indicate which parts of the posted message are dynamic, so a user seeing a message knows which part is based on live data and which part is the standard rule statement. As shown in Figure 21, square brackets are used immediately outside the curly brackets so that the dynamic values inserted into the message at rule execution will be bracketed. The use of these square brackets is optional other characters may be used to achieve the desired visual distinction. Remember, Action Rows execute in numbered order (from top to bottom in the Actions pane), so a Rule Statement that contains an embedded attribute value must not be posted before the attribute has a value. Doing so will result in a null value inserted in the posted message.
Figure 21 - Sample Rulesheet with Rule Statements Containing Embedded Attributes
1/13/2012
Rule Language Guide
Page 209
Figure 22 - Rule Messages Window Showing Bracketed Embedded Attributes (Orange Box)
When an attribute uses an Enumerated Custom Data Type, the dynamic value embedded in the posted Rule Message will be the Value, not the Label. See the Rule Modeling Guide, Building the Vocabulary chapter for more information about Custom Data Types.
No expressions in Rule Statements

A reminder about the table in Figure 4, which specifies that the only parts of the Vocabulary that may be embedded in Rule Statements are attributes and functions (today and now). No operators or expressions are permitted inside Rule Statements. Often, operators will cause error messages when you try to save a Rule Set. Sometimes the Rule Statement itself will turn red. Sometimes an embedded equation will even execute as you intended. But sometimes no obvious error will occur, but the rule does not executed as intended. Just remember that operators and expressions are not supported in Rule Statements.
INCLUDING APOSTROPHES IN STRINGS

String values in Studio are always enclosed in single quotes. But occasionally, you may want the String value to include single quote or apostrophe characters. If you enter the following text in Studio:
entity1.string1=Janes dog Spot
The text will turn red, because Studio thinks that the string1 value is Jane and the remaining text s dog Spot is invalid. To properly express a String value that includes single quotes or apostrophes, you must use the special character backslash (\) that tells Studio to ignore the apostrophe(s) as follows:
entity1.string1=Jane\s dog Spot
1/13/2012
Rule Language Guide
Page 210
When preceded by the backslash, the second apostrophe will be ignored and assumed to be just another character within the String. This notation works in all sections of the Rulesheet, including Values sets. It also works in the Possible Values section of the Vocabulary Editor.
ADVANCED COLLECTION SYNTAX

Collection syntax contains some subtleties which are worth learning once you are comfortable with the basics described in the Rule Modeling Guides Collections chapter. Its sometimes helpful when writing collection expressions to step through them, left to right, as if you were reading a sentence. This helps us understand better how the pieces combine to create the full expression. It also helps us to know what else we can safely add to the expression to increase its utility. Lets try this approach in order to dissect the following expression:
Collection1 -> sortedBy(attribute1) -> last.attribute2
Step 1
Collection1
This expression returns the collection {e1, e2, e3, e4, e5,en} where ex is an element (an entity) in Collection1. We already know that alias Collection1 represents the entire collection.
Step 2
Collection1 -> sortedBy(attribute1)
This expression returns the collection {e1, e2, e3, e4, e5,en} arranged in ascending order based on the values of attribute1 (which we call the index).
Step 3
Collection1 -> sortedBy(attribute1) -> last
returns {en} where en is the last element in Collection1 when sorted by attribute1 This expression returns a specific entity (element) from Collection1. It does not return a specific value, but once we have identified a specific entity, we can easily reference the value of any attribute it contains, as in the following:
Step 4
Collection1 -> sortedBy(attribute1) -> last.attribute2
which returns {en.attribute2} This expression not only returns a specific value, but just as importantly, it also returns the entity the value belongs to. This entity context is important because it allows us to do things to the entity itself, like assign a value to one of its attributes. For example:
1/13/2012
Rule Language Guide

Collection1 -> sortedBy(attribute1) -> last.attribute2=xyz
Page 211
The above expression will assign the value of xyz to attribute2 of the entity whose attribute1 is highest in Collection1. Contrast this with the following:
Collection1.attribute1 -> sortedBy(attribute1) -> last
which returns a single integer value, like 14. Notice that all we have now is a number, a value. We have lost the entity context, so we cant do anything to the entity that owns the attribute with value of 14. In many cases, this is just fine. Take for example:
Collection1.attribute1 -> sortedBy(attribute1) -> last > 10
In this expression, its not important that we know which element has the highest value of attribute1, all we want to know is if the highest value (whomever it belongs to) is greater than 10. Understanding the subtleties of collection syntax and the concept of entity context is important because it helps us to use the returned entities or values correctly. For example: Return the lower of the following two values: 12 The age of the oldest child in the family
What is really being compared here? Do we care which child is oldest? Do we need to know his or her name? No. We simply need to compare the age of that child (whichever one is oldest) with the value of 12. So this is the expression that models this logic:
family.age -> sortedByDesc(age) -> first.min(12)
.min, as we know, is an operator that acts upon numeric data types (Integer or Decimal). And since we also know that family.age -> sortedByDesc(age) -> first returns a number, then its legal and valid to use .min at the end of this expression. What about this scenario: Name the youngest child Junior.
family -> sortedByDesc(age) -> last.name=Junior
Now we want to return a specific entity that of the youngest child and assign to its name a value of Junior. We need to keep the entity context in order to make this assignment, and the expression above accomplishes this.
STATEMENT BLOCKS
Sequence operators can easily extract an attribute value from the first, last or other specific element in a sorted collection (see first, last, or at(n) for examples). This is especially useful when the attributes value is involved in a comparison in a Conditional or Preconditional rule. Sometimes, however, it is desirable to identify a particular element in a sequence and flag or tag it for use in subsequent rules. This can be accomplished using special syntax called Statement Blocks.
Rule Language Guide
Page 212
Statement Blocks, permitted only in the Action rows of the Rulesheet, use special variables, prefixed by a ? character, to hold or pin an element so that further action may be taken on it, including tagging it by assigning a value to one of its attributes. These special holder variables may be declared on the fly, meaning they do not need to be defined anywhere prior to use. Heres an example. In a sales management system, the performance of sales reps is analyzed every quarter, and the highest grossing sales rep is awarded Salesperson of the Quarter. This special status is then used to automatically increase the reps commission percentage on sales made in the following quarter. Well use the same generic Vocabulary as in all previous examples, but make these assumptions:
Vocabulary Term Entity2 Entity1.entity2 Entity2.string1 Entity2.decimal1 Entity2.string2 Entity2.decimal2 Meaning a salesperson collection of salespeople a salespersons name a salespersons quarterly sales a salespersons award a salespersons commission percentage
Using this Vocabulary, we construct the Rulesheet shown in
Figure 23 - Rulesheet using Statement Block to Identify and Reward Winner
Important Notes about Statement Blocks

As expressed in Action row A in Figure 23, a statement block consists of two separate expressions: 1. the first part assigns an element of a sequence to a special holder variable, prefixed by the ? character. This variable is unusual because it represents an element, not a value. Here, the highest grossing salesperson is expressed as the last element of the collection of salespeople
Rule Language Guide
Page 213
(e2), sorted in ascending order according to quarterly sales (decimal1). Once identified by the sequencing operator last, this salesperson is momentarily held by the ?tag variable, which we declared on-the-fly. 2. the second part of the statement the part following the semicolon assigns a value to an attribute of the element held by the ?tag. In our example, we are assigning a value of Salesperson of the Quarter to the string2 attribute of the salesperson held by ?tag. In effect, we have tagged the highest grossing salesperson with this award. 3. the two parts above must be included on the same Action Row, separated by a semicolon. If the two parts are separated in different sections or in different Rows of the same section, the element represented by the ? variable is lost, in other words, ?tag loses its grip on the element identified by the sequencing operator. Now that we have tagged our winner, we can use the tagged element (awardee) to take additional actions. In the Conditional rule, we increase the commission percentage of the winner by 5% using the increment operator. The next figure shows a Ruletest Input and Output pane. As expected, our highest grossing salesperson has been awarded Salesperson of the Year honors, and has had her commission raised by an additional 5%.
Figure 24 Output Panel with Winner and Adjusted Commission in Bold Black Text
1/13/2012
Rule Language Guide
Page 214
APPENDIX A: CHARACTER PRECEDENCE: UNICODE & JAVA COLLATOR

The Unicode standard assigns a 4 digit (hexadecimal) code to every character, including many that cant be typed on standard keyboards. Java (and hence Corticon software) uses a special method named Collator to sort these characters in specific sequences based on the I18n locale of the user. While sorting by locale allows for regional variations of language-specific characters like accents, the combination of these two systems can also make determining character precedence very complicated. The Unicode code and Java Collator sequence for standard keyboards in US-English locale is shown in the table below. Sequences for other languages and/or locales may differ, and many other Unicode characters are available but are not shown in the table. We recommend http://www.unicode.org/charts for more information on the Unicode system and http://java.sun.com/docs/books/tutorial/i18n/text/locale.html for more information on the Java Collator method. evaluates to true because character Z has the same precedence as z (69=69). A given letter has the same precedence regardless of its case. This is an important difference between character precedence determined by ISO or ASCII systems, and the Java Collator system used by Corticon.
Z=z C &
S < C and S evaluates to true because character a has a higher
precedence than & (26 < 44). These characters are decisive because they are the first different characters encountered as the two strings are compared beginning with characters in position 1.
B > aardvark
evaluates to true because character B has a higher precedence

evaluates to false because character n has a higher
than a (45 > 44).

Marilynn < Marilyn
precedence than <space> (57 > 1). The first seven characters of each String are identical, so the final character comparison is decisive.
character name typed space _ , ; : ! ? / dash or minus sign underline or underscore comma semicolon colon exclamation point question mark slash precedence 1 2 3 4 5 6 7 8 9 Unicode 5.0 code 0020 002D 005F 002C 003B 003A 0021 003F 002F
1/13/2012
Rule Language Guide

. ` ^ ~ ( ) [ ] { } @ $ * \ & # % + < = > | 0..9 a, A b, B period grave accent circumflex tilde apostrophe quotation marks left parenthesis right parenthesis left bracket right bracket left brace right brace at symbol dollar sign asterisk backslash ampersand number sign or hash sign percent sign plus sign less than sign equals sign greater than sign vertical line numbers 1 through 9 letter a, small and capital letter b, small and capital 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34-43 44 45 002E 0060 005E 007E 0027 0022 0028 0029 005B 005D 007B 007D 0040 0024 002A 005C 0026 0023 0025 002B 003C 003D 003E 007C 0031-0039 0061, 0041 0062, 0042
Page 215
1/13/2012
Rule Language Guide

c, C d, D e, E f, F g, G h, H I, I j, J k, K l, L m, M n, N o, O p, P q, Q r, R s, S t, T u, U letter c, small and capital letter d, small and capital letter e, small and capital letter f, small and capital letter g, small and capital letter h, small and capital letter I, small and capital letter j, small and capital letter k, small and capital letter l, small and capital letter m, small and capital letter n, small and capital letter o, small and capital letter p, small and capital letter q, small and capital letter r, small and capital letter s, small and capital letter t, small and capital letter u, small and capital 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 0063, 0043 0064, 0044 0065, 0045 0066, 0046 0067, 0047 0068, 0048 0069, 0049 006A, 004A 006B, 004B 006C, 004C 006D, 004D 006E, 004E 006F, 004F 0070, 0050 0071, 0051 0072, 0052 0073, 0053 0074, 0054 0075, 0055
Page 216
1/13/2012
Rule Language Guide

v, V w, W x, X y, Y z, Z letter v, small and capital letter w, small and capital letter x, small and capital letter y, small and capital letter z, small and capital 65 66 67 68 69 0076, 0056 0077, 0057 0078, 0058 0079, 0059 007A, 005A
Page 217
1/13/2012
Rule Language Guide
Page 218
APPENDIX B: ARITHMETIC OPERATOR PRECEDENCE
Order 1 2 3
Operator () Unary * /
Operator Name Parenthesis Negation Multiplication Division Addition Subtraction Less Than Less Than Or Equal To Greater Than Greater Than Or Equal To Equal Not Equal Exponentiation
Example (5.5 / 10) -10 5.5 * 10 5.5 / 10 5.5 + 10 10.0 5.5 5.5 < 10 5.5 <= 5.5 10 > 5.5 10 >= 10 5.5=5.5 5.5 <> 10 10 ** 2
+ -
< <= > >=
= <>
**
1/13/2012
Rule Language Guide
Page 219
APPENDIX C: DATETIME DATA TYPE

FORMATS OR MASKS
DateTime information may take many different formats. Studio and Server share a common source of acceptable DateTime, Date Only, and Time Only formats, also known as masks. For example, a date mask may specify yyyy-MM-dd as an acceptable date format, which means that an attribute of type DateTime (or Date) may hold or contain data that conforms to this format. 2003-04-12 conforms to this mask; April 12th, 2003 does not. For proper execution, it is important to ensure that date formats used during rule development and testing (and are included in the rule builders Studio installations) are also present in the Business Rules Servers installation. See Server Integration & Deployment Guide for more details about setting and modifying masks in both Studio and Server.
PRESENTATION AND PERSISTENCE

Most commercial databases represent dates as DateTimes. Such DateTimes are frequently stored as UTC, namely the number of milliseconds that have transpired from an arbitrary epoch (e.g. 1/1/1970 00:00:00 GMT); this is not a universal standard but is a very popular convention. UTC dates can be rendered in the user's local time zone, but this is merely a matter of presentation. A UTC represents a simultaneous point in time for two observers regardless of where on earth they reside. However, some date or time concepts, such as holiday, cannot be expressed conveniently as a discrete time point. Christmas (12/25/XX) actually denotes different time frames depending on the observers' time zones; thus, Corticon carries (i.e., holds in memory) all dates in GMT with the time portion zeroed (i.e., midnight). This approach addresses the holiday problem because a user can enter holiday dates into the database and not have them shift when they are rendered in the user's local time zone. Carrying GMT dates should be transparent to the user. Dates expressed as strings in incoming XML are parsed and the proper data type is inferred; for dates, they are immediately instantiated as GMT and rendered back in GMT with no conversion.
1/13/2012
Rule Language Guide
Page 220
APPENDIX D: CORTICON STUDIO AND SERVER 5.2 PRODUCT DOCUMENTATION

Rule Language Guide
1/13/2012
CORTICON
Business Rules Server 5.2 Tutorial Deploying Web Services with Java
TABLE OF CONTENTS
Table of Contents ......................................................................................................................................... iii Introduction .................................................................................................................................................. 1 Purpose & Intended Audience.................................................................................................................. 1 Corticon Business Rules Management Product Documentation ............................................................. 1 Documentation Conventions .................................................................................................................... 1 Technical Support ..................................................................................................................................... 2 Conceptual Overview .................................................................................................................................... 3 What is a Web Service? ............................................................................................................................ 3 What is a Decision Service? ...................................................................................................................... 3 What is The Corticon Business Rules Server? ........................................................................................... 3 What is a Web Services Consumer? ......................................................................................................... 3 Getting Started.............................................................................................................................................. 4 Deploying the Corticon Business Rules Server as a Web Services Server ................................................ 4 Deploying a Ruleflow to the Corticon Business Rules Server ................................................................... 4 Consuming a Decision Service .................................................................................................................. 4 Starting the Corticon Business Rules Server ................................................................................................. 5 Starting Tomcat and Verifying Operation................................................................................................. 5 Installing Corticon Server.......................................................................................................................... 5 Deploying a Ruleflow to the Corticon Server................................................................................................ 7 Creating a Ruleflow................................................................................................................................... 7 Creating and Installing a Deployment Descriptor File .............................................................................. 7 Launching the Deployment Console .................................................................................................... 8 Using the Deployment Console to Create a Deployment Descriptor file ............................................ 8 Installing the Deployment Descriptor File.......................................................................................... 11 Hot Re-Deploying Deployment Descriptor Files and Ruleflows ......................................................... 11 Consuming a Decision Service..................................................................................................................... 13 Integrating and Testing a Decision Service ............................................................................................. 13 Path 1 Using Corticon Studio as a SOAP Client to Consume a Decision Service.................................. 14 Creating a New Test in Studio ............................................................................................................ 14 Executing the Remote Test ................................................................................................................ 16 Path 2 Using Bundled Sample Code to Consume a Decision Service .................................................. 17 Creating a Request Message for a Decision Service........................................................................... 17 Sending a Request Message to the Server ......................................................................................... 19 Path 3 Using a SOAP Client to Consume a Decision Service ................................................................ 22 Web Services Service Contracts ......................................................................................................... 22 Web Services Messaging Styles.......................................................................................................... 22 Creating a Service Contract Using the Deployment Console ............................................................. 23 Creating a Request Message for a Decision Service........................................................................... 24 Sending a Request Message to the Server ......................................................................................... 25 Limits of the Default Evaluation License ................................................................................................ 25
Tutorial for Corticon Server Deploying Web Services with Java
Page iv
Troubleshooting ..................................................................................................................................... 26 Appendix A: Corticon Business Rules Management Product Documentation .......................................... 27
January 13, 2012
Tutorial for Corticon Server Deploying Web Services
Page 1
INTRODUCTION
PURPOSE & INTENDED AUDIENCE
The Tutorial for Corticon Server - Deploying Web Services provides step-by-step instructions for: Deploying Corticon Business Rules Server as a Web Services server on the bundled Apache Tomcat web server. Loading the Server with a sample Ruleflow or one of your own design. Testing the Ruleflow with live data using bundled SOAP client code.
This manual is intended primarily for use by IT professionals involved with the deployment to the Server of Ruleflows developed in Studio. This manual assumes you have already installed Corticon Business Rules Server software on a PC according to the instructions found in Appendix F of the Server Integration & Deployment Guide.

For a detailed listing of current Corticon Business Rules Management technical publications, see Appendix A.
Corticon documentation uses the following conventions: Document names are shown in bold face italic type: Studio Installation Guide. Screen, button and window names are shown in bold face type: Custom Setup screen. Important information such as Notes, Tips and Warnings are shown in this color scheme: Tools Notes and Tips Warnings
Hyperlinks are underlined and shown in blue: the cursor changes to a hand: Custom Setup. File names, code, and user-defined information are shown as: Installing.pdf.
January 13, 2012
Page 2
Menu options are indicated using bold text and arrows: File>Save denotes the selection of the Save option from the File menu.
TECHNICAL SUPPORT
For Corticon product support, contact +1 650.212.2424 ext. 200 or email support@corticon.com
January 13, 2012
Page 3
CONCEPTUAL OVERVIEW
This tutorial assumes you have a basic familiarity with the concepts of Web Services and Corticon Business Rules Management. This section helps answer some of the foundational questions from new users of the Corticon Business Rules Server.
WHAT IS A WEB SERVICE?

From the business perspective: A Web Service is a software asset that automates a task and can be shared, combined, used, and reused by different people or systems within or among organizations. From the information systems perspective: A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web Service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. [From http://www.w3c.org.]
WHAT IS A DECISION SERVICE?

A Decision Service automates a discrete decision-making task. It is implemented as a set of business rules and exposed as a Web Service (or Java Service). By definition, the rules within a Decision Service are complete and unambiguous; for a given set of inputs, the Decision Service addresses every logical possibility uniquely, ensuring decision integrity. A Ruleflow is built in Corticon Studio. Once deployed to the Corticon Server, it becomes a Decision Service.
WHAT IS THE CORTICON BUSINESS RULES SERVER?

The Corticon Business Rules Server is a high-performance, scalable and reliable system resource that manages pools of Decision Services and executes their rules against incoming requests. The Corticon Server can be easily configured as a Web Services server, which exposes the Decision Services as true Web Services.
WHAT IS A WEB SERVICES CONSUMER?

A Web Services Consumer is a software application that makes a request to, and receives a response from, a Web Service. Most modern application development environments provide native capabilities to consume Web Services, as do most modern Business Process Management Systems.
Page 4
GETTING STARTED
This Tutorial steps through the procedure necessary for running the Corticon Business Rules Server as a Web Services server, deploying Ruleflows to the Server, exposing the Ruleflows as Decision Services and testing them with document-style SOAP requests. There are other installation, deployment and integration options available beyond the SOAP/Web Services method described here, including Javacentric options using Java objects and APIs. More detailed information on all available methods is contained in the Server Integration & Deployment Guide. This Tutorial consists of three main sections:
DEPLOYING THE CORTICON BUSINESS RULES SERVER AS A WEB SERVICES SERVER

This section explains how to deploy the Corticon Business Rules Server to the Tomcat web server, which is installed by default during the installation process described in the first section.
DEPLOYING A RULEFLOW TO THE CORTICON BUSINESS RULES SERVER

This section explains how to deploy Ruleflows to the Server and expose them as web services, which we call Decision Services. Once a Ruleflow becomes a Decision Service, it may be consumed by any external application or process capable of interacting with standard document-style web services.
CONSUMING A DECISION SERVICE

This section explains how to integrate and test your deployed Decision Service by creating and sending request messages to the Server, and viewing the response messages it returns to you. Two methods of integration and testing are discussed: one method assumes you have access only to the tools contained in the default Server installation, while the other method assumes you have a commercially available SOAP client, application or tool to perform these tasks
January 13, 2012
Page 5
STARTING THE CORTICON BUSINESS RULES SERVER

The open-source web server, Tomcat, is automatically installed by the Full Install Corticon Server installation. By default, Tomcats HTTP port is set to 8082. If you want to change this port (for example, because of a port conflict), consult Tomcats documentation or see Corticon Field Note Changing Apaches Default Port.
STARTING TOMCAT AND VERIFYING OPERATION

1. From the Windows Start menu, choose Programs>Corticon> Business Rules Server>Local Server (Tomcat)>Start Server 2. Verify the startup script output ends with line
Apache Tomcat/6.0.20
INSTALLING CORTICON SERVER

By default, Corticon Server comes pre-installed on Tomcat. This is achieved by pre-loading Corticon Servers axis.war file into Tomcats webapps directory, created here by the default Servers installer:
<corticon_install_dir>\Server\Tomcat\webapps
When you start this bundled Tomcat for the first time, it will unpack axis.war, and create a new axis directory inside \webapps. This new folder contains the complete Corticon Server web application. If you intend to install Corticon Server onto another web server besides the bundled Tomcat, refer to the Server Integration & Deployment Guide for more details on using the axis.war package supplied. To verify that Corticon Server is installed correctly on Tomcat, perform the following steps: 1. Be sure Tomcat is already running, as above. 2. Launch your Internet Bowser and go to http://localhost:8082/axis. 3. Click View the list of deployed Web services. 4. You should see the screen shown in Figure 1.
Page 6
Figure 1 Server web console login page
January 13, 2012
Page 7
DEPLOYING A RULEFLOW TO THE CORTICON SERVER

Just because the Server is running does not mean it is ready to process transactions. It must still be loaded with one or more Ruleflows. Once a Ruleflow has been loaded, or deployed, to the Server we call it a Decision Service because it is a service ready and able to make decisions for any external application or process (client) that requests the service properly. Loading the Server with Ruleflows can be accomplished in three ways: Deployment Descriptor files. This is the easiest method and the one we will use in this Tutorial because it is also the method typically used in production web services deployments. Deployment using the Server Web Console. This is another easy way to load Decision Services. It is discussed in more detail in the Monitoring Server chapter of the Server Integration & Deployment Guide. Java APIs. This method requires more knowledge of the Java programming language, and is not discussed in this Tutorial.
All three methods are described more thoroughly in the Server Integration & Deployment Guide.
CREATING A RULEFLOW
For purposes of this Tutorial, we will assume you have already created a Ruleflow suitable for deployment. If you have completed the Basic Tutorial for Corticon Studio Modeling Rules, then you have indeed created a sample Ruleflow that is ready for deployment to the Server. In the Basic Tutorial for Corticon Studio Modeling Rules we built and tested a new Ruleflow from scratch. We will use that Ruleflow here, but the same steps we outline must be followed regardless of the Ruleflow we use. If you no longer have your original Ruleflow, then use tutorial_example.erf located in
<corticon_install_dir>\Samples\Rule Projects\Tutorial\Tutorial-Done as a
substitute. The rules inside are essentially the same as those built in the first part of the Basic Tutorial for Corticon Studio Modeling Rules.
CREATING AND INSTALLING A DEPLOYMENT DESCRIPTOR FILE

A Deployment Descriptor file tells the Server which Ruleflows to load and how to handle transaction requests for those Ruleflows. A Deployment Descriptor file has the suffix .cdd, and we will often simply refer to it as a .cdd file. The .cdd file points at the Ruleflow via a path name its important that this path not contain space characters. For example, a Ruleflow stored in My Documents cannot be referenced by a Deployment Descriptor file because its path contains a space. Even though the
Page 8
default storage location for your Ruleflow files is inside

<corticon_install_dir>\Samples\Rule Projects (which contains a space), we avoid the problem by substituting ../../ as a relative reference to the directory structure.
Deployment Descriptors are easily created using the Deployment Console, which is installed by both the Studio installer (Integration & Deployment mode only) and the Server installer.
Launching the Deployment Console

Launch the Deployment Console in one of two ways: Use the Windows Start menu option Programs>Corticon>Deployment Console. From within Studio, use menubar option Window>Preferences choose Rule Modeling in the left-hand tree, then choose the Integration & Deployment radio button.
Using the Deployment Console to Create a Deployment Descriptor file

Once launched, the Deployment Console will appear as shown below:
January 13, 2012
Page 9
3 1
Figure 2 - Deployment Console's Decision Services Deployment Properties Window, Part 1
Deployment Descriptor files are created within the top half of the Deployment Console (labeled as Decision Service Deployment Properties) using the settings and options listed in the following paragraphs. For the moment, well ignore the lower half of the Deployment Console window that portion (labeled as Service Contract Specification) will be addressed later in this Tutorial. Follow these steps to create a Deployment Descriptor file. 1. If you launched Deployment Console from within Studio, then any open Ruleflows will have already been added to the table, and you can skip this step. If the Ruleflow section is empty, use the Add Ruleflow button to add one. 2. Verify the Ruleflow you added is displayed in this section. All Ruleflows listed will be included in the Deployment Descriptor file, but their deployment characteristics are specified on an individual basis using the next 4 steps. 3. Give the Ruleflow a Decision Service Name. This is a shorthand identifier or handle for the Decision Service. It is used when invoking the Decision Service, either via an API call or a SOAP Request message. A default Decision Service name will be entered automatically based on the Ruleflow name. tutorial_example.erf, for example, will
Page 10
be given the default name tutorial_example. You can change this, but be sure to remember what you entered because you will use this name later to invoke the Decision Service.
4. In this Tutorial we will skip over the Version, Version Label, Effective Date, and Expiration Date settings. Descriptions of these settings can be found in the Server Integration & Deployment Guide and the Rule Modeling Guide. Scroll to the right until you see the Maximum and Minimum Pool Size settings. These tell the Server how to handle higher transaction volumes. The concept of a pool is described in more detail in the Server Integration & Deployment Guide. For now, simply accept the default settings, as shown in Figure 3.
7
5. Continue scrolling to the right until you see the Dynamic Reload setting shown in Figure 4. The default entry is No, which we will keep for this Tutorial example. See the Server Integration & Deployment Guide for more details on this option. 6. XML Messaging Style. The default entry is Auto Detect, which we will keep for this example. See the Server Integration & Deployment Guide for more details on this option.
Page 11
7. Use the Save Deployment File button to create the new Deployment Descriptor file. After youve named and saved it, the .cdd name will appear in the title bar. For the moment, save this file anywhere and remember where it is. We will move it to the correct location in the next section. The Deployment Descriptor files XML structure is fully described in the Server Integration & Deployment Guide.
Installing the Deployment Descriptor File

Once Corticon Server has been installed and deployed to Tomcat (as per the Deployment section), the included startup scripts ensure the following sequence occurs upon launching Tomcat: 1. The Tomcat web server starts up. 2. Corticon Server starts up as a web service in Tomcats Servlet container. 3. Corticon Server looks for Deployment Descriptor files in a specific directory. 4. Corticon Server loads into memory the Ruleflow(s) referenced by the Deployment Descriptor files, and creates Reactors for each according to their minimum pool size settings. At this stage, we say that the Ruleflows have become Decision Services because they are now usable by external applications and clients. In order for the Corticon Server to find Deployment Descriptor files when it looks in step 3, we must ensure that the .cdd files are moved to the appropriate location. In the default installation used in this Tutorial, that location is the <corticon_install_dir>\Server\Tomcat\CcServer\cdd directory. In the future, when creating .cdd files, you may want to save them straight to this directory so they become immediately accessible to the default Corticon Server deployed in this Tutorial. Of course, this location is fully configurable. See the Deploying Corticon Ruleflows chapter of the Server Integration & Deployment Guide for more details. Now, when the startup sequence reaches step 3 above, Corticon Server will know where all Ruleflows are located because .cdd files contain their pathnames.
Hot Re-Deploying Deployment Descriptor Files and Ruleflows

Changes to a Deployment Descriptor file or any of the Ruleflows it references do not require restarting Tomcat. A maintenance thread in the Server watches for additions, deletions, and changes and updates appropriately. A Ruleflow can be modified in Studio even while it is also simultaneously deployed as a Decision Service and involved in a transaction - Server can be configured to update the Decision Service dynamically for the very next transaction. Dynamic updating of deployed Ruleflows is not normally used in production environments because standard IT change control processes require a more disciplined and controlled
Page 12
deployment process. But in development or testing environments, it can be convenient to allow dynamic updates so that Ruleflow changes can be deployed more quickly. Having selected No for the Dynamic Reload setting earlier, our tutorial_example Decision Service will not update automatically when the .erf file is changed. To enable this automatic refresh, choose Yes for the Dynamic Reload setting.
January 13, 2012
Page 13
CONSUMING A DECISION SERVICE

Lets review what we have accomplished so far: 1. We have installed Corticon Server onto a PC (described in Appendix F of the Server Integration & Deployment Guide). 2. We have deployed Corticon Server as a web service onto the bundled Tomcat web server. 3. We have used the Deployment Console to generate a Deployment Descriptor file for our sample Ruleflow. 4. We have installed the Deployment Descriptor file in the location where Corticon Server looks when it starts. Now we are ready to consume this Decision Service by sending a real XML/SOAP request message and inspecting the response message it returns.
INTEGRATING AND TESTING A DECISION SERVICE

In order to use a Decision Service in a process or application, it is necessary to understand the Decision Services service contract, also known as its interface. A service contract describes in precise terms the kind of input a Decision Service is expecting, and the kind of output it returns following processing. In other words, a service contract describes how to integrate with a Decision Service. When an external process or application sends a request message to a Decision Service that complies with its service contract, the Decision Service receives the request, processes the included data, and sends a response message. When a Decision Service is used in this manner, we say that the external application or process has successfully consumed the Decision Service. This Tutorial describes three paths for consuming a Decision Service: Path 1 Use Corticon Business Rules Modeling Studio as a SOAP client to send and receive SOAP messages to a Decision Service running on a remote Corticon Server. This is different from testing Ruleflows in Studio locally. This path is the easiest method to use and requires the least amount of technical knowledge to successfully complete. If you have already installed Studio, then you have all necessary components to complete this path. If you have not installed Studio but wish to follow this path, we recommend completing the Studio Installation Guide and the Basic Tutorial for Corticon Studio Modeling Rules before continuing here. Path 2 Manually integrate and test a Decision Service. Here, well use bundled sample code (a command file) to send a request message built in Corticon Studios Tester, and display the results. This path requires more technical knowledge and confidence to complete, but illustrates some aspects of the software which may be interesting to a more technical audience. If you have already installed Studio, then you have all necessary components to complete this path. If you have not installed Studio but wish to follow
Page 14
this path, we recommend completing the Studio Installation Guide and the Basic Tutorial for Corticon Studio Modeling Rules before continuing here. Path 3 Use a commercially available SOAP client to integrate with and test a Decision Service. In other words, this SOAP client will read a web-services-standard service contract (discussed below), generate a request message from it, send it to the Corticon Server and display the response message. Corticon Business Rules Management does not include such an application, so the reader must obtain one in order to complete this path.
PATH 1 USING CORTICON STUDIO AS A SOAP CLIENT TO CONSUME A DECISION SERVICE

In this path, we will use Corticon Studio as a SOAP client to execute Decision Services running on a remote Corticon Server.
Creating a New Test in Studio

Return to Corticon Studio, or reopen it if closed. Open Cargo.ecore and then, without opening any Ruleflows, open a new Test by selecting File>New>Ruletest from the Studio menubar. For the Ruletest creation process outlined below, see also Figure 5: 1. youll be asked to Select Test Subject. Be sure to select the http://localhost:8082/axis in the Remote Servers box. 2. Then, select Update list. Studio will attempt contact an Server instance at the location specified above. If an Server instance is running, it will respond with a list of available Decision Services, and display that list in the Remote Decision Services window. 3. Choose the Decision Service to invoke. In this Tutorial, we want tutorial_example. 4. Click Next> 5. Select the Vocabulary to use, as per normal Ruletest creation procedure. Remember, even though we are using Studio to test, we are using its remote testing feature, which executes a Decision Service running on Corticon Server (remotely), not a Ruleflow open in Studio (locally). In order to keep this distinction clear in our heads, we are not going to open tutorial_example.erf in Studio its not necessary since were really testing the Decision Service running on Corticon Server. In step 1, you selected the default URL: Corticon Server running on localhost. If you want to change the URL to another address, see Appendix C of the Server Integration & Deployment Guide for more information about configuring Studio properties.
January 13, 2012
Page 15
Figure 5 - Requesting List of Remote Decision Services
Now, drag a Cargo entity from the Vocabulary to the Input pane. Enter sample data as shown in Figure 6.
January 13, 2012
Page 16
.
Figure 6 - Sample Data in an Studio Remote Ruletest
Executing the Remote Test

Execute the Test by selecting Test>Execute Test from the Studio menubar or toolbar. We should see an Output pane similar to that shown in Figure 7. from the
Figure 7 - Response from Remote Decision Service
The Output pane of the Testsheet shown in Figure 7 displays the response message returned by the Corticon Server. This confirms that our Decision Service has processed the data contained in the request and sent back a response containing new data (the container attribute and the message).
January 13, 2012
Page 17
PATH 2 USING BUNDLED SAMPLE CODE TO CONSUME A DECISION SERVICE

Creating a Request Message for a Decision Service
In this path, we will use a feature of Studio to generate a request message directly. The steps to accomplish this are: 1. Open Studio. 2. Open the Ruleflow you have deployed as a Decision Service. If you are using the Tutorial example, this is tutorial_example.erf. 3. Set a work document entity (WDE) for the Ruleflow. This is done in the Properties tab of the Ruleflow, Ruleflow sub-tab. If you are using tutorial_example.erf, the appropriate WDE is Cargo. The WDE simply defines the root element in the XML document. 4. Create a new Ruletest by following the procedure outlines in Option 1 above. For Test Subject, you can choose either your local or remote tutorial_example.erf. 5. Create an Input test tree manually as in Option 1 above, or use menubar option Ruletest>Testsheet>Data>Input>Generate Data Tree, which produces the structure of a request message in the Input pane. One Cargo entity should appear in the Input pane, as shown below:
Figure 8 A New Test
6. Enter data into the Input Testsheet just like you did when testing the Ruleflow in the Basic Tutorial for Corticon Studio Modeling Rules. Your Input Testsheet will now appear similar to Figure 9:
January 13, 2012
Page 18
Figure 9 Test with Data
7. Use Studios menubar option Ruletest>Testsheet>Data>Input>Export Request XML to export this Input pane as an XML document. We will use this exported XML document as the body or payload of our request message. Give the export file a name and remember where you save it. We will assign a filename of sample.xml for purposes of this Tutorial. 8. Open sample.xml in any text editor. It should appear very similar to Figure 10.
Figure 10 Sample XML File Exported from a Studio Test
9. Modify sample.xml by deleting the <?XML version=1.0 encoding=UTF-8?> tag from the very top (this will be added automatically by the bundled sample code we will use to send this as a request message to the Decision Service). This tag is shown above in Figure 10, enclosed in an orange box. 10. Change the decisionServiceName attribute value in the CorticonRequest element from InsertDecisionServiceName to the service name of the Decision Service as it was defined in your deployed .cdd file. In our example, this name is tutorial_example. This piece is shown above in Figure 10 and below in Figure 11 (before and after the changes) enclosed in a blue box. Your sample.xml file should now look like this:
Page 19
Figure 11 Sample XML File with Changes Made
11. Save your changes to the XML file and exit your text editor.
Sending a Request Message to the Server

We include a simple command script in the default Server installation. The command script causes a test XML file to be enclosed (wrapped) in a SOAP envelope and passed to a target Decision Service on the Server. The SOAP response from the Decision Service (in other words, the Decision Services response message) is then displayed to the user in the same command window (also known as a DOS window) used to initiate the test. The steps required for using this command script are described below. 1. Open the TestDS.cmd file, found in
<corticon_install_dir>\Server\Tomcat\CcServer\cddinit, in a text editor.
It should appear as:
January 13, 2012
Page 20
Figure 12 TestDS Command File
2. Replace OrderProcessingPayload.xml (shown in orange box in Figure 12) with the name of your test XML file. In this Tutorial, our test XML file is named sample.xml. 3. Save the changes to TestDS.cmd. 4. Move your XML test file (sample.xml) to the
<corticon_install_dir>\Server\Tomcat\CcServer\cddinit directory.
5. Open a DOS window and change the directory to

<corticon_install_dir>\Server\Tomcat\CcServer\cddinit.
6. Type TestDS (the name of the command script) in the DOS command window and press Enter. 7. You should see the following response from your Decision Service:
January 13, 2012
Page 21
Figure 13 - Corticon Response Message Displayed in DOS Command Window
The response message shown in Figure 13 is exactly what the Servers output looks like when it is returned to the consuming application. There are several things to note in this response. The container attribute has been assigned a value of oversize. The input data volume and weight have been returned in the response message unchanged. If your rules do not change input data, it will be returned exactly as sent. The Studio Ruletest assigned unique id values to our terms during the XML export. However, if the Server receives a request message without id values, it will assign them automatically to ensure resulting terms remain associated properly. The Messages section of the response has been populated with a posted message. Notice that the contents of the severity and text tags match those used in the rules. The entityReference tag in the Messages section uses an href to link or point to the associated elements id value. In this case, we see that the posted message links to (or is associated with) Cargo with id equal to Cargo_id_1. In this case, there is only one Cargo it could link to, but a production request message may contain hundreds or thousands of Cargo entities. In those cases, maintaining href association between entities and their message(s) is critical.
January 13, 2012
Page 22
The SOAP wrapper or envelope tags were added by the bundled sample code to ensure the request message was sent in accordance with web service standards.
Other details of the Server response message are described in the Server Integration & Deployment Guide.
PATH 3 USING A SOAP CLIENT TO CONSUME A DECISION SERVICE

Web Services Service Contracts
Web Services has two main ways of describing a service contract: 1. An XML schema document, also known by its file suffix XSD. 2. A Web Services Description Language document, or WSDL (often pronounced wiz-dull). Many commercial SOAP and web services development tools have the ability to import an XSD or WSDL service contract and generate a compliant request message directly from it. This path assumes you have access to such a tool and want to use it to consume a Decision Service. The Corticon Deployment Console can produce both XSD and WSDL documents. The Server Integration & Deployment Guide contains much more information about these documents, including detailed descriptions of their structure and elements. However, if you have chosen this path, we assume you are already familiar enough with service contracts to be able to use them correctly once generated.
Web Services Messaging Styles

There are also two types of messaging styles commonly used in web services: 1. RPC-style, which is a simpler, less-capable messaging style generally used to send smaller messages and receive single variable answers. Some of the administrative methods in Corticon Servers SOAP API use RPC-style messaging. 2. Document-style, which is more complex, but allows for richer content, both in request and response messages. Corticon Server only supports document-style messaging. Important Any SOAP client or SOAP-capable application used to consume a Decision Service deployed to the Corticon Business Rules Server must use document-style messaging. See the Server Integration & Deployment Guide for complete details on proper structure of a compliant request message.
January 13, 2012
Page 23
Creating a Service Contract Using the Deployment Console
8 9 10 11 12 13 14
Figure 14 - Deployment Consoles Service Contract Specification Window
Launch the Deployment Console as before and follow the instructions below to generate a service contract. All Deployment Console options below are also described in more detail in the Server Integration & Deployment Guide. 8. Decision Service Level / Vocabulary Level. These radio buttons determine whether one service contract is generated per listed Ruleflow, or if a single master service contract is generated from the entire Vocabulary. A Decision Service-level service contract is usable only for a specific Decision Service, whereas a Vocabulary-level service contract can be used for all Decision Services that were built using that Vocabulary. Choose the option that is most compatible with your SOAP tool. 9. Vocabulary File. If generating a Vocabulary-level service contract, enter the Vocabulary file name (.ecore) here. If generating a Decision Service-level contract, this field is readonly and shows the Vocabulary associated with the currently highlighted Ruleflow row above.
Page 24
10. Select Work Document Entity. If generating a Vocabulary-level service contract, enter the entity name from the list that is the root of the service contract. For more details on the concept of work document entity (WDE), refer also to the Rule Modeling Guide. If generating a Decision Service-level contract, the field shows the WDE associated with the currently highlighted Ruleflow. If no WDE has yet been specified, or if you wish to change it, select one from the list. If you are using the tutorial_example.erf Ruleflow, the appropriate WDE is Cargo. 11. Type. This is the service contract type: WSDL, XML Schema, or Java classes. Note, no output is produced when Java classes is selected because there is no standard method for describing service contracts in the Java world. 12. XML Messaging Style. Enabled only for Vocabulary-level service contracts. Describes the message style, flat or hierarchical, in which the WSDL will be structured. 13. SOAP Server URL. URL for the SOAP node that is bound to the Server. Enabled for WSDL service contracts only. The default URL http://localhost:8082/axis/services/Corticon makes a Decision Service available to the default Server installation performed earlier. Note: this URL can be changed and additional URLs can be added to the drop-down list. See Appendix C of the Server Integration & Deployment Guide for details. 14. Generate Service Contracts. Use this button to generate either the WSDL or XML Schema service contracts into the output directory. If you select Decision Service-level contracts, one service contract per Ruleflow listed at top will be created. If you select Vocabularylevel, only one contract is created per Vocabulary file.
Creating a Request Message for a Decision Service

Once your SOAP development tool has imported the WSDL or XSD service contract, it should be able to generate an instance of a request message that complies with the service contract. It should also provide you with a way of entering sample data to be included in the request message when it is sent to the Decision Service. Most commercial SOAP development tools accurately read service contracts generated by the Deployment Console, ensuring well-formed request messages are composed. One occasional problem, however, involves the Decision Service Name, which was entered in field 3 of the Deployment Consoles Deployment Descriptor section. Even though all service contracts list decisionServiceName as a mandatory element, many SOAP tools do not automatically insert the Decision Service Name attribute into the request messages decisionServiceName element. Be sure to check this before sending the request message. If the request message is sent without a decisionServiceName, the Server will not know which Decision Service is being requested, and will return an error message. Server also offers a mode of WSDL generation thats more compatible with Microsofts Windows Communications Framework. See the Server Integration & Deployment Guide for more details.
January 13, 2012
Page 25
Enter all required data into the request message. The tutorial_example.erf example requires the following data: Vocabulary Term
Cargo.weight Cargo.volume
Possible Values A number less than or equal to 200,000 Any real number
Sending a Request Message to the Server

Make sure the Tomcat server is running and your Deployment Descriptor file is in the correct location as described earlier. Now, use your SOAP tool to send the request message to the Server. Your SOAP tool should display the response from the Server. Are the results what you expected? If not, or if the response contains an error, proceed to the Troubleshooting section of this tutorial.
LIMITS OF THE DEFAULT EVALUATION LICENSE

The license included in the default Server installation has pre-set limits on certain Server and Decision Service parameters. These limits are: Number of Decision Services Up to 5 Decision Services may be deployed at any given time. This means the sum total of all Decision Services loaded via .cdd files, Web Console, or APIs cannot exceed 5. Pool Size No Decision Service may have a maximum pool size setting of greater than 5. Pool size is measured on a Decision Service-by-Decision Service basis, so you may have up to 5 Decision Services deployed (compliant with the Decision Service limitation above), each with up to 5 Reactors in its pool, without violating the default license restrictions. Number of Rules All rules in all deployed Ruleflows (i.e., all deployed Decision Services) must not exceed 200. A rule generally consists of a single Condition/Action Column or a single Action row in Column 0. Filter expressions do not count because they only modify other rules.
The Server log will capture errors and exceptions caused by expired or under-strength licenses. These log messages are detailed in the Troubleshooting section of the Rule Modeling Guide. If you are already a Corticon customer, you should have access to an unlimited license that will lift these restrictions. If you are an evaluator, and discover that these limitations are preventing or inhibiting your evaluation, please contact Corticon or your reseller for a license with expanded capabilities.
January 13, 2012
Page 26
TROUBLESHOOTING
The Rule Modeling Guide contains an extensive chapter on Troubleshooting, including tips for troubleshooting rules in Studio, as well as problems encountered during Decision Service consumption. Please refer to the Rule Modeling Guide for more details. Many users will find other installations of Tomcat already present on their machines. Very often, the default port settings for these installations conflict with the default port setting of Corticons Tomcat installation, which is 8082. To change Tomcats default port to something other than 8082, refer to the Field Note Changing Apaches Default Port, available on www.RulesWorld.com.
January 13, 2012
Page 27
APPENDIX A: CORTICON BUSINESS RULES MANAGEMENT PRODUCT DOCUMENTATION

The following documents are included with the Corticon Business Rules Management 5.2 release:
Rule Language Guide
January 13, 2012
CORTICON
Business Rules Server 5.2 Integration & Deployment Guide
Server Integration & Deployment Guide 5.2
Page ii
TABLE OF CONTENTS
Preface ........................................................................................................................................................................8 Intended Audience .................................................................................................................................................8 Corticon Business Rules Management Product Documentation ...........................................................................8 Documentation Conventions .................................................................................................................................8 Reading the PDF File ..............................................................................................................................................9 Overview.................................................................................................................................................................. 10 Choose The Deployment Architecture ................................................................................................................ 10 Installation Option 1: Web Services................................................................................................................ 11 Installation Option 2: Java Services with XML Message Payloads .................................................................. 12 Installation Option 3: Java Services with Java Object Payloads...................................................................... 12 Installation Option 4: In-process Java Classes with Java Object or XML Payloads ......................................... 12 Installing the Business Rules Server ........................................................................................................................ 14 Basic Server Classes............................................................................................................................................. 14 Installing Corticon Server .................................................................................................................................... 14 as a J2EE SOAP Servlet ................................................................................................................................. 15 as a J2EE Enterprise Java Bean (EJB) ............................................................................................................ 15 as Java Classes In-process or in a Custom Java Container ........................................................................... 16 The Corticon Home Directory ............................................................................................................................. 17 A Configuration Setting using CORTICON_HOME........................................................................................... 18 The Corticon Server Sandbox .............................................................................................................................. 18 Testing the Installed Corticon Server .................................................................................................................. 18 as a J2EE SOAP Servlet ................................................................................................................................. 19 as a J2EE Enterprise Java Bean (EJB) ............................................................................................................ 23 as In-Process Java Classes ............................................................................................................................ 24 Preparing Studio Files for Deployment ................................................................................................................... 27 Mapping the Vocabulary ..................................................................................................................................... 27 XML Mapping .................................................................................................................................................. 27 Java Object Mapping ...................................................................................................................................... 31 Java Generics .................................................................................................................................................. 38 Java Enumerations .......................................................................................................................................... 38 Verifying Java Object Mapping ....................................................................................................................... 41 Listeners .......................................................................................................................................................... 41 Deploying Corticon Ruleflows ................................................................................................................................. 42 Ruleflow Deployment.......................................................................................................................................... 42 using Deployment Descriptor files ............................................................................................................... 42 Telling the Server Where to find Deployment Descriptor Files ...................................................................... 49 using the Server Web Console ..................................................................................................................... 52 using APIs ..................................................................................................................................................... 52 Testing the Deployed Corticon Decision Service................................................................................................. 53
January 13, 2012
Page iii
Deploying and Testing Decision Services via Deployment Descriptor Files (.cdd) ......................................... 53 Deploying and Testing Decision Services via APIs .......................................................................................... 54 Deploying Uncompiled vs. Pre-compiled Decision Services ............................................................................... 57 ERF files ........................................................................................................................................................... 57 EDS Files .......................................................................................................................................................... 57 Integrating Corticon Decision Services .................................................................................................................... 59 Components of a Call to Corticon Server ............................................................................................................ 59 the Decision Service Name ............................................................................................................................. 59 the Data .......................................................................................................................................................... 59 Service Contracts: Describing the Call................................................................................................................. 60 The XML WorkDocument................................................................................................................................ 60 Java Business Objects ..................................................................................................................................... 60 Creating XML Service Contracts with Corticon Deployment Console ............................................................ 60 Types of XML Service Contracts .......................................................................................................................... 65 XML Schema (XSD) .......................................................................................................................................... 65 Web Services Description Language (WSDL) .................................................................................................. 65 Annotated Examples of XSD and WSDLs Available in the Deployment Console ............................................ 66 Passing Null Values in XML Messages ................................................................................................................. 66 Support for Windows Communication Framework (WCF) ................................................................................. 67 Definitions Section (WSDL only) ..................................................................................................................... 67 Decision Service Information Section (WSDL & XSD) ..................................................................................... 67 PortType Section (WSDL only) ........................................................................................................................ 69 Binding Section (WSDL only)........................................................................................................................... 69 .NET Compatible XML Messaging ................................................................................................................... 70 Invoking Corticon Server ......................................................................................................................................... 71 Methods of Calling Corticon Server .................................................................................................................... 71 SOAP Call......................................................................................................................................................... 71 Java Call........................................................................................................................................................... 71 Request/Response Mode .................................................................................................................................... 72 Administrative APIs ............................................................................................................................................. 73 Monitoring Corticon Server ..................................................................................................................................... 75 Launching and Logging In to Server Console ...................................................................................................... 75 Console Main Menu Page ................................................................................................................................... 76 Decision Services Page ........................................................................................................................................ 78 Service Name .................................................................................................................................................. 78 Version ............................................................................................................................................................ 82 Live .................................................................................................................................................................. 82 Deployed from CDD ........................................................................................................................................ 82 Dynamic Reload .............................................................................................................................................. 83 Executions ....................................................................................................................................................... 83 Avg Time (ms) ................................................................................................................................................. 85 Clear Stats ....................................................................................................................................................... 85 Deploy Decision Service Page ............................................................................................................................. 85 Server State..................................................................................................................................................... 86
Page iv
Configure Rule Server ......................................................................................................................................... 87 Logging Tab ..................................................................................................................................................... 87 Deployment Directory Tab.............................................................................................................................. 87 Decision Service Options Tab.......................................................................................................................... 88 License Tab...................................................................................................................................................... 88 Monitor Rules Server Page.................................................................................................................................. 88 Rules Server Stats Tab..................................................................................................................................... 89 Rules Server Settings Tab................................................................................................................................ 89 Environment Settings Tab............................................................................................................................... 89 Memory Utilization Tab .................................................................................................................................. 89 Rules Server Log .............................................................................................................................................. 89 WSDLs.................................................................................................................................................................. 89 Configuring Corticon Server .................................................................................................................................... 90 Most Common Property Changes ....................................................................................................................... 91 Log Location .................................................................................................................................................... 91 Log Level ......................................................................................................................................................... 91 Automatic Decision Service Reload ................................................................................................................ 91 Inside Corticon Server ............................................................................................................................................. 93 The Basic Path ..................................................................................................................................................... 93 Ruleflow Compilation the .eds File .................................................................................................................. 93 Multi-threading and Concurrency Reactors and Server Pools ......................................................................... 93 State .................................................................................................................................................................... 94 Reactor State .................................................................................................................................................. 94 Corticon Server State ...................................................................................................................................... 95 Dynamic Discovery of New or Changed Decision Services ................................................................................. 96 Replicas and Load Balancing ............................................................................................................................... 97 Exception Handling ............................................................................................................................................. 97 Decision Service Versioning and Effective Dating ................................................................................................... 98 Deploying Decision Services with Identical Decision Service Names.................................................................. 98 Sample Ruleflows ................................................................................................................................................ 99 Invoking a Decision Service by Major Version Number .................................................................................... 102 Specifying a Major Version in a SOAP Request Message ............................................................................. 102 Specifying Version in a Java API Call ............................................................................................................. 105 Default Behavior ........................................................................................................................................... 105 Invoking a Decision Service by Date.................................................................................................................. 105 Specifying Decision Service Effective Timestamp in a SOAP Request Message ........................................... 106 Specifying Effective Timestamp in a Java API Call ........................................................................................ 109 Default Behavior ........................................................................................................................................... 109 Specifying Both Major Version and Effective Timestamp ............................................................................ 110 Summary of Major Version and Effective Timestamp Behavior ....................................................................... 111 Performance and Tuning Guide............................................................................................................................. 112 Rulesheet Performance and Tuning .................................................................................................................. 112 Server Performance and Tuning ....................................................................................................................... 112
Page v
Optimizing Pool Settings for Performance ................................................................................................... 112 Single Machine Configuration....................................................................................................................... 113 Cluster Configuration .................................................................................................................................... 114 Logging .......................................................................................................................................................... 115 Batching the Data in a Single Transaction .................................................................................................... 115 Capacity Planning.......................................................................................................................................... 116 Internationalization ............................................................................................................................................... 118 Appendix A: Service Contract and Message Samples........................................................................................... 119 Annotated Examples of XSD and WSDLs Available in the Deployment Console .............................................. 119 1 Vocabulary-Level XML Schema, FLAT XML Messaging Style ....................................................................... 119 Header .......................................................................................................................................................... 119 CorticonRequestType and CorticonResponseType ...................................................................................... 119 WorkDocumentsType ................................................................................................................................... 121 MessagesType............................................................................................................................................... 121 VocabularyEntityNameType ......................................................................................................................... 122 VocabularyAttributeNameTypes .................................................................................................................. 123 2 Vocabulary-Level XML Schema, HIER XML Messaging Style ....................................................................... 124 Header .......................................................................................................................................................... 124 CorticonRequestType and CorticonResponseType ...................................................................................... 124 WorkDocumentsType ................................................................................................................................... 124 MessagesType............................................................................................................................................... 124 VocabularyEntityNameType ......................................................................................................................... 124 VocabularyAttributeNameTypes .................................................................................................................. 124 3 Decision-Service-Level XML Schema, FLAT XML Messaging Style............................................................... 125 Header .......................................................................................................................................................... 125 CorticonRequestType and CorticonResponseType ...................................................................................... 125 WorkDocumentsType ................................................................................................................................... 125 MessagesType............................................................................................................................................... 125 VocabularyEntityNameType and VocabularyAttributeNameTypes ............................................................. 125 4 Decision-Service-Level XML Schema, HIER XML Messaging Style ............................................................... 126 Header .......................................................................................................................................................... 126 CorticonRequestType and CorticonResponseType ...................................................................................... 126 WorkDocumentsType ................................................................................................................................... 126 MessagesType............................................................................................................................................... 126 VocabularyEntityNameType and VocabularyAttributeNameTypes ............................................................. 126 5 Vocabulary-Level WSDL, FLAT XML Messaging Style .................................................................................. 127 SOAP Envelope.............................................................................................................................................. 127 Types ............................................................................................................................................................. 127 Messages ...................................................................................................................................................... 127 PortType........................................................................................................................................................ 127 Binding .......................................................................................................................................................... 127 Service........................................................................................................................................................... 128 6 Vocabulary-Level WSDL, HIER XML Messaging Style .................................................................................. 129 SOAP Envelope.............................................................................................................................................. 129 Types ............................................................................................................................................................. 129
January 13, 2012
Page vi
Messages ...................................................................................................................................................... 129 PortType........................................................................................................................................................ 129 Binding .......................................................................................................................................................... 129 Service........................................................................................................................................................... 129 7 Decision-Service-Level WSDL, FLAT XML Messaging Style .......................................................................... 130 SOAP Envelope.............................................................................................................................................. 130 Types ............................................................................................................................................................. 130 Messages ...................................................................................................................................................... 130 PortType........................................................................................................................................................ 130 Binding .......................................................................................................................................................... 130 Service........................................................................................................................................................... 130 8 Decision-Service-Level WSDL, HIER XML Messaging Style .......................................................................... 131 SOAP Envelope.............................................................................................................................................. 131 Types ............................................................................................................................................................. 131 Messages ...................................................................................................................................................... 131 PortType........................................................................................................................................................ 131 Binding .......................................................................................................................................................... 131 Service........................................................................................................................................................... 131 Extended Service Contracts .............................................................................................................................. 132 Examples ........................................................................................................................................................... 134 Vocabulary-Level WSDL, FLAT XML Messaging Style.................................................................................... 135 Decision-Service-Level XSD, HIER XML Messaging Style............................................................................... 139 Sample CorticonRequest Content ................................................................................................................ 141 Sample CorticonResponse Content .............................................................................................................. 142 Appendix B: API Summary .................................................................................................................................... 144 Appendix C: Corticon Business Rules Management Properties & Settings .......................................................... 145 Controlling Corticon Studio ............................................................................................................................... 145 Controlling Corticon Server ............................................................................................................................... 145 Common Properties (CcCommon.properties) .................................................................................................. 146 Properties used by Both Studio and Server ................................................................................................. 146 Corticon Deployment Console Properties (CcDeployment.properties)............................................................ 155 Properties Used by Deployment Console ..................................................................................................... 155 Corticon Studio Properties (CcStudio.properties)............................................................................................. 157 Properties Used by Studio Only .................................................................................................................... 157 Corticon Server Properties (CcServer.properties)............................................................................................. 160 Properties Used Solely by Business Rules Server ......................................................................................... 160 Appendix D: Sample Code Summary .................................................................................................................... 168 Appendix E: Corticon Studio and Server 5.2 Product Documentation ................................................................. 170 Appendix F: Using the Corticon Business Rules Server Installer ......................................................................... 171 Corticon Server Setup Wizard ........................................................................................................................... 171 System Requirements ....................................................................................................................................... 171 New Installation or Upgrade? ....................................................................................................................... 172 License Agreement ....................................................................................................................................... 173
January 13, 2012
Page vii
Choosing Installation Directory .................................................................................................................... 173 Changing Installation Directory .................................................................................................................... 174 Install Set ...................................................................................................................................................... 175 Pre-Installation Summary ............................................................................................................................. 175 Install Status.................................................................................................................................................. 176 Completing the Setup Wizard ....................................................................................................................... 176 Desktop Shortcut .......................................................................................................................................... 177 Program Maintenance ...................................................................................................................................... 177 Remove Program .......................................................................................................................................... 177
January 13, 2012
Page 8
PREFACE
INTENDED AUDIENCE
The Server Integration & Deployment Guide provides you with the necessary steps to install and integrate Corticon Server into a Web Service or Java container. This guide is intended for use by technical architects and application developers. This document assumes that you are familiar with various third-party software products and operating environments. Please refer to Appendix E for references to further documentation.

For a detailed listing of current Corticon Business Rules Management technical publications, see Appendix E.
Corticon Business Rules Management technical documentation uses the following conventions: Document names are shown in bold face italic type: Server Integration & Deployment Guide. Screen, menu and button names are shown in bold face type: Custom Setup screen. The following icons precede important information such as Tools, Notes, Tips and Warnings. Associated text is shown in the font and color scheme illustrated: Tools Notes and Tips Warnings
Hyperlinks are underlined and shown in blue: the cursor changes to a hand: Custom Setup. In some cases, hyperlinks connect to external, 3rd-party resources that were verified current at time of publication. Corticon does not warrant operation of these links beyond date of publication. File names, paths, methods, class names and data are shown in red monotype: Installing.pdf.
January 13, 2012
Page 9
READING THE PDF FILE

Corticon technical documentation is distributed in Adobe Portable Document Format (PDF). You can use the Adobe Reader toolbar and features to easily navigate through the document. Choose Help, Reader Guide from the toolbar to display Using Acrobat Reader. Refer to the topic Paging Through a Document for further assistance.
January 13, 2012
Page 10
OVERVIEW
The Corticon Business Rules Server installation and deployment process involves the sequence of activities illustrated in the following diagram. Use this diagram as a map to this manual each box below corresponds to a following chapter. Choose Deployment Architecture Install the Business Rules Server Deploy Decision Services Integrate Decision Services Invoke Decision Services
CHOOSE THE DEPLOYMENT ARCHITECTURE

Corticon Decision Services are intended to function as part of a service-oriented architecture. Each Decision Service automates a discrete decision-making activity an activity defined by business rules and managed by business analysts. A Corticon Ruleflow deployed to the Business Rules Server and available to process transactions is referred to as a Decision Service. Rulesheets are not directly deployable to Corticon Server. They must be packaged as Ruleflows in order to be deployed and executed on Corticon Server. The application architect must consider how these Decision Services will be used (consumed) by external applications, clients, processes or components. Which applications need to consume Decision Services and how will they invoke them? Your choice of installation and deployment architecture impacts subsequent steps, including installation of Server, and integration and invocation of the individual Decision Services deployed to Corticon Server. The primary available options are described in the following table, and addressed in detail below: Installation Option 1 - Web Services Description Appropriate If:
Corticon Server is deployed with a Currently using Web Services. Servlet interface, causing individual Need to expose Decision Services Ruleflows to act as Web Services. to the Internet or other distributed Invocations to Corticon Server are architecture. made using standard SOAP Using Microsoft .NET or other requests, and data is transferred legacy systems which do not within the SOAP request as an XML support Java method calls payload. (invocations). Corticon Server is deployed with an Prefer to use XML for best Enterprise Java Bean (EJB) interface flexibility in data payload. and integrated with architectures Prefer JMS or RMI method calls for that can make Java method calls high performance and/or tighter
January 13, 2012
2 - Java Services with XML Payloads
Server Integration & Deployment Guide 5.2 and transfer XML payloads. 3 - Java Services with Java Object Payloads coupling to client applications.
Page 11
Corticon Server is deployed with an Prefer Java objects for data Enterprise Java Bean (EJB) interface payload. and integrated with architectures Prefer JMS or RMI method calls for that can make Java method calls high performance. and transfer Java object payloads. Willing to accept decreased portability Corticon Server is deployed into a Require lightest-weight, smallestclient-managed JVM as Java classes footprint install. Prefer direct, in-process method calls for lowest messaging overhead and fastest performance
Table 1 Corticon Server Installation Options
4 - In-process Java Classes (POJO)
Server Installed As Java Servlet Java Session EJB
Call Server With SOAP: RPC or Document-style Server API via JMS Server API via RMI in-process Java methods from the Server API
Send Data As XML String (RPC-style) XML Document (Document-style) XML String or JDOM collection or map of Java Business Objects XML String or JDOM collection or map of Java Business Objects
Java Classes
Table 2 Corticon Server Communication Options
Installation Option 1: Web Services

Web Services is the most common deployment choice. By using the standards of Web Services (including XML, SOAP, HTTP, WSDL, and XSD), this choice offers the greatest degree of flexibility and reusability. Corticon Server may be installed as a Web Service using a Java Servlet running in a J2EE web or application servers Servlet container. You can use a Web Services server with IBM WebSphere, Oracle/BEA WebLogic, Apache Tomcat or other containers that support multi-threading Web Services (see Installing the Business Rules Server). The Web Services option is the easiest to configure and integrate into diverse consuming applications. Refer to the Tutorial for Corticon Server Deploying Web Services.
January 13, 2012
Page 12
When deploying Corticon Decision Services into a Web Services server, the Deployment Console (or Deployment Console API) is used to generate WSDL files for each Decision Service (see Deploying Corticon Ruleflows). These WSDL files can then be used to integrate the Decision Services into Consuming applications as standard Web Services (see Integrating Decision Services). Corticon users can also build their own infrastructure that publishes the WSDL files to UDDI directories for dynamic discovery and binding.
Installation Option 2: Java Services with XML Message Payloads

You are not restricted to Web Services and SOAP as the technical application architecture. Corticon Server is, at its core, a set of Java classes. You can deploy Corticon Server as: A J2EE Stateless Session bean (EJB). A set of In-process Java classes on the server or client-side.
This approach avoids the overhead of SOAP messaging, but requires that consuming applications speak Java, in other words, be able to invoke the Corticon Server API via JMS or RMI. The payload of the call is the same XML representation as in the Web Services deployment method, minus the SOAP wrapper. Using XML offers good decoupling of consuming application from Decision Service and greater degrees of flexibility.
Installation Option 3: Java Services with Java Object Payloads

In cases where it is not desirable to send a string containing the XML payload (or receive a string back as a response) as is required by Option 2, Corticon offers an additional way to pass the payload: As Java objects (by reference) conforming to the JavaBeans specification. Each Java object corresponds to an entity in the Corticon Decision Service Vocabulary. Corticon Server uses introspection to identify the entitys attributes (as JavaBean properties).
This option offers the best performance, as payloads dont need transformation from objects to/from XML. That being said, it is also the least portable because it requires Java objects and a tight relationship between those objects and the Corticon Vocabulary to exist. In addition, it suffers in flexibility because changes to the Vocabulary require changes to the Java object model (note: External name mapping and extended attributes, as discussed below and in the Corticon product documentation, offer some help in coping with these constraints).
Installation Option 4: In-process Java Classes with Java Object or XML Payloads
The installation option with lightest weight and smallest footprint is the In-process Java option. With this option, no interface or wrapper class is used to forward calls from the client application to Corticon Server (CcServer.jar). Instead, the client must use the Corticon Server Java API to initialize the Corticon Server classes, load any Decision Services, and execute them. In addition, the client application must start and manage the JVM in which the Corticon Server classes are loaded.
January 13, 2012
Page 13
JVM and thread management are normally functions of the Servlet or EJB container in a web or application server if you choose to take responsibility for these activities in your client code then you dont need a container, at least as far as Corticon Server is concerned. Installing Corticon Server without a web or application server reduces the overall application footprint and permits more compact installations, but by eliminating the helpful functions of the container, it places more of the deployment burden on you.
January 13, 2012
Page 14
INSTALLING THE BUSINESS RULES SERVER

For Windows-based platforms, Corticon Server may be installed using the Installer file and process described in Appendix F. If you would like to install these Server files on a non-Windows machine, first run the installer on a Windows machine, then copy/move the required files to your destination platform. Depending upon the choice of technical architecture, the Server should be installed into an appropriate container. Details on installation into common environments are provided in this document.
BASIC SERVER CLASSES

At its most basic level, Corticon Server is simply a set of Java classes, packaged in Java archive, or .jar, files. The minimum set of jars needed to deploy and call Corticon Server is listed below:
CcServer.jar this is the main Corticon Server jar, containing the core engine
logic.
CcConfig.jar this contains a set of text .property files that list and set all the
configuration properties needed by Corticon Server.

CcLicense.jar this is an encrypted file containing the licensing information
required to activate Corticon Server.

CcThirdPartyJars.jar this contains 3rd-party software such as XML parsers
and JDOM. Corticon warrants Corticon Server operation ONLY with the specific set of classes inside this jar.
CcI18nBundles.jar this contains the English and other language templates used by Corticon Server. ant-launcher.jar supports Corticon Servers deployment-time Decision
Service compilation capability

CcExtensions.jar optional only necessary if you have added new rule
language operators as Extended Operators. (See the Rule Language Guide for details.)
INSTALLING CORTICON SERVER

In most production deployments, Corticon Server jars are bundled and given a J2EE interface class or classes. The interface class is often called a helper or wrapper class because its purpose is to receive the client applications invocation, translate it (if necessary) into a call which uses Corticon Servers native API, and then forward the call to Corticon Servers classes. The type of interface class depends on the J2EE container you intend to deploy the Corticon Server into. Corticon Studio makes in-process calls to the same Server classes (although packaged differently) when Studio Ruletests are executed. This ensures that Ruleflows behave exactly the same way when
Page 15
executed in Studio Ruletests as they do when executed by Corticon Server, no matter how Corticon Server is installed.
as a J2EE SOAP Servlet

If installation Option 1 was chosen above, then a SOAP Servlet interface is used for most production deployments. Install Corticon Server into the Servlet container of a J2EE web or application server such as BEA WebLogic, Oracle AS, or IBM WebSphere. Commercial application servers offer the greatest degree of manageability, security and reliability, but open-source J2EE web servers such as Apache Tomcat are also excellent, production-quality options. One advantage of the wrapper or helper class approach to installation is that variations in the web server environment (such as SOAP version) may be addressed in the wrapper class itself, rather than in the set of Corticon Server classes. The base set of Corticon Server jars remains the same irrespective of deployment environment only the wrapper class changes. The industry-standard method of deploying a Servlet into a J2EE web servers Servlet container is via a web archive, or.war, file. This file contains everything required to deploy a fully functional Servlet, including all classes, configuration files, and interfaces. Corticon provides a complete sample .war file, along with all source code, with the standard default Server installation. In addition to the base set of Corticon jars, the provided .war file also contains Apache Axis SOAP messaging framework, which is supported by most commercial J2EE web and application servers, including Apache Tomcat web server. Your web server documentation will include instructions for installing or loading a .war file. This .war file, named axis.war, is located in your Corticon installation directory in the Samples\Server\Containers\WAR directory. Note: the .war file provided is intended to be a sample wrapper for instructional purposes. Source code is also included in \src so you can adapt the wrapper to your environment and platform. The sample .war file is not certified for use on any specific web server and is not warranteed by Corticon. This .war file contains the default evaluation license, named CcLicense.jar. If you are a Corticon customer, you will be provided with a permanent version of this file. You must insert it into the .war (replacing the original) in order to remove the evaluation license limitations. For a quick start, Corticon Server ships with Apache Tomcat web server and the Apache Axis SOAP messaging infrastructure, and is pre-configured to work with Corticon Server. Apache is installed by default (unless de-selected in a custom installation) by Corticon Servers Installer. For complete, stepby-step instructions for deploying Corticon Server to the bundled Apache Tomcat web server, please refer to the Tutorial for Corticon Server Deploying Web Services.
as a J2EE Enterprise Java Bean (EJB)

If installation Options 2 or 3 was chosen above, then an EJB interface is used for most production deployments. Install Corticon Server into the EJB container of a J2EE application server such as BEA
Page 16
WebLogic, Oracle AS, or IBM WebSphere. Commercial application servers offer the greatest degree of manageability, security and reliability, but open-source J2EE application servers such as JBOSS are also available. One advantage of the wrapper or helper class approach to installation is that variations in the application server environment may be addressed in the wrapper class itself, rather than in the set of Corticon Server classes. The base set of Corticon Server jars remains the same irrespective of deployment environment only the wrapper class changes. The industry-standard method of deploying an EJB into a J2EE application servers EJB container is via an enterprise archive, or .ear, file. This file contains everything required to deploy a fully functional Session EJB (stateless), including all classes, configuration files and interfaces. Corticon includes a complete sample .ear file along with all source code with the standard default Corticon Server installation. Your application server documentation will include instructions for installing an .ear file. This .ear file, named CcServer.ear, is located in the Samples\Server\Containers\EAR directory, which is in the Corticon installation directory. Note: the .ear file provided is intended to be a sample wrapper for instructional purposes. Source code is also included in \src so you can adapt the wrapper to your specific environment and platform. The sample .ear file is not certified for use on any specific application server and is not warranteed by Corticon. This .ear file contains the default evaluation license, named CcLicense.jar. If you are a Corticon customer, you will be provided with a permanent version of this file. You must insert it into the .ear (replacing the original) in order to remove the evaluation license limitations. The sample .ear file also contains axis.war, enabling you to deploy both a Servlet and a EJB version of Corticon Server simultaneously. This allows you to expose both SOAP and Java interfaces to the same Decision Service, making your Decision Services even easier to use throughout your enterprise infrastructure.
as Java Classes In-process or in a Custom Java Container

If you choose to manage Corticon Server in-process via your client application or via a custom container, you are taking responsibility for many of the tasks that are normally performed by a J2EE web or application server. But by doing it in your own code, you can optimize your environment and eliminate unneeded overhead. This can result in much smaller footprint installations and faster performance. Because Corticon Server is a set of Java classes, it can easily be deployed in-process in a JVM. When deployed in-process, the following tasks are the responsibility of the client application: Management of Java classpaths, ensuring the base set of Corticon Server classes is properly referenced. JVM lifecycle management, including startup/shutdown Concurrency & Thread management Security (if needed)
January 13, 2012
Page 17
Transaction management, including invocation of Corticon Server using the standard Java API set.
Corticon Server can also be installed into a custom container within any application. Corticon Server has a small footprint and thus can be installed into client applications including browser-based applications, laptops and mobile devices. For step-by-step instructions on using the Installer to gain access to Corticon Servers core jar files, see Appendix F of this guide. Installation in-process or in a custom container involves these basic steps: Place the following Corticon Server jar files in a location accessible by the surrounding Java container:
CcServer.jar CcConfig.jar CcServerLicense.jar CcThirdPartyJars.jar CcI18nBundles.jar ant_launcher.jar CcExtensions.jar [optional only necessary if you have added custom rule language
operators to the Operator Vocabulary as Extended Operators. (See Rule Language Guide for details.) Configure the Java classpath to include the jar files listed above. Change the logPath property inside CcCommon.properties to an explicit path to a directory for the Corticon Server Log file. Write code that:
Initializes Corticon Server Sets environment variables such as CORTICON_HOME (see below) Deploys the Decision Services into Corticon Server Requests a decision by marshaling the data payload and then invoking the relevant Corticon Decision Service Processes the response from the Decision Service. Sample code is provided that demonstrates an in-process deployment of Corticon Server. This code, named testServer.bat, is located in the Server directory of your Corticon installation directory.
THE CORTICON HOME DIRECTORY

The Corticon Home directory is a variable that you set and pass into the JVM during initialization of the Corticon Server. This variable, shown as CORTICON_HOME throughout the sample code provided with the Corticon Server installation, helps to establish relative path locations to other important files.
Page 18
A Configuration Setting using CORTICON_HOME

The sample batch file startServer.bat, located in the Server\Tomcat directory of your Corticon installation directory, assigns CORTICON_HOME to ./CcServer. In Java-based systems, ./ means current directory, so the path Corticon Server uses for depositing log files, defined by the logPath property inside CcCommon.properties (inside CcConfig.jar) is:
logpath=%CORTICON_HOME%/Log
Therefore, when Corticon Server starts up from this batch file, the logPath location will be:
Server\Tomcat\CcServer\Log (assuming Windows) in your Corticon installation directory. This
directory will be created the first time Server starts up, if its not already present. Youll find many cases where file paths and locations are controlled by CORTICON_HOME variable - be sure to set this value in your Corticon Server startup script or include it in your Corticon Server wrapper classes.
THE CORTICON SERVER SANDBOX

When Corticon Server starts up, it checks for the existence of a sandbox directory. This Sandbox is a directory structure used by Corticon Server to manage Server state and deployment code. The location of the Sandbox is controlled by com.corticon.ccserver.sandboxDir inside CcServer.properties (inside CcConfig.jar). As above, this configuration setting is also controlled by the CORTICON_HOME variable, in this case:
com.corticon.ccserver.sandboxDir=%CORTICON_HOME%/CcServerSandbox
When using the sample startServer.bat file, this location is Server\Tomcat\CcServer\CcServerSandbox (assuming Windows path notation) in your Corticon installation directory. This directory will be created the first time Server starts up, if its not already present. If the location specified by com.corticon.ccserver.sandboxDir cannot be found or is not available, the location defaults to the JVMs home directory.
TESTING THE INSTALLED CORTICON SERVER

With Corticon Server installed in the environment and container of your choice, it is useful to test the installation to ensure Corticon Server is running and listening. At this point, no Decision Services have been deployed, so Corticon Server is not ready to process transactions. However, the Corticon Server API set contains administrative methods that interrogate it and return status information. Several tools are provided to help you perform this test.
January 13, 2012
Page 19
as a J2EE SOAP Servlet

To test that Corticon Server deployed as a SOAP Servlet is running correctly, all you need is a SOAP client or the sample batch file provided and described below. Testing the Servlet installation here assumes you have already installed and started Corticon Server as a Web Service, either according to the instructions in the Tutorial for Corticon Server Deploying Web Services (in the bundled Apache Tomcat) or using the .war file in another web server. Because a SOAP Servlet is listening for SOAP calls, we need a way to invoke an API method via a SOAP message then send that message to Corticon Server using a SOAP client. In the sample code supplied in the default installation, Corticon provides an easy way to send API calls to Corticon Server via a SOAP message. The included batch file, testServerAxisTomcat.bat, will help ensure that Corticon Server is installed properly and listening for calls. testServerAxisTomcat.bat, located in the Samples\Server\Containers\WAR directory of your Corticon installation directory, provides a menu of available Server methods to call into the SOAP Servlet. Running testServerAxisTomcat.bat (or .sh in a UNIX environment) causes the following actions to occur: Sets classpaths needed by the CcServerAxisTest class, which is acting as our menu-driven SOAP client. The source code (.java) is included in the Samples\Server\Containers\WAR\src directory of your Corticon installation directory. Defines variables for web server location and port. Port changes that may be necessary depending on the type of application or web server you are using to host the Servlet. Notice that the defaults are for the bundled Apache Tomcat web server, which uses localhost and 8082 as the application servers location and port setting. Starts a JVM so that our SOAP client class, CcServerAxisTest, can run inside. Calls the CcServerAxisTest class (our simple SOAP client) with arguments for web server location and port. Notice that the rest of the URI has been hard-coded in this batch file.
January 13, 2012
Page 20
Figure 1 testServerAxisTomcat.bat
When executed, the testServerAxisTomcat.bat opens a DOS window and displays the API menu, as shown below:
January 13, 2012
Page 21
Figure 2 Top Portion of the testServerAxisTomcat.bat DOS Window
The menu displayed in the DOS window is too large to fit on a single printed page, so it has been divided into two screenshots here. In the upper portion of the DOS window, shown in Figure 2, above, the classpath definition process is visible. Once all classes are loaded, the Corticon Server starts up in the JRE, which is needed by our simple SOAP client class.
January 13, 2012
Page 22
Figure 3 Bottom Portion of the testServerAxisTomcat.bat DOS Window
In the lower portion of the DOS window, shown in Figure 3 above, we see the available API methods listed by number. Most of these methods apply to Corticon Server with loaded Ruleflows. Since we have not deployed any Ruleflows yet, we will need to use an administrative method to test if Corticon Server is correctly installed as a SOAP Servlet inside our web server. A good administrative method to call is option #23, Get CcServer current info. This choice corresponds directly to the Java API method getCcServerInfo(), described in complete detail in the JavaDocs provided in the standard Corticon Server installation. Selecting option #23, Get CcServer current info, causes the CcServerAxisTest class to make a call to the Corticon Server SOAP Servlet. It asks for a list of configuration parameters and returns them to the DOS window. The results of the call are shown in Figure 4, below:
January 13, 2012
Page 23
Figure 4 runAxisTest.bat Response
The response verifies that our Server is running correctly as a SOAP Servlet and is listening for, and responding to, calls. At this stage in the deployment, this is all we want to verify.
as a J2EE Enterprise Java Bean (EJB)

A J2EE application server is not included with the Corticon Business Rules Server Installer. However, if you have Oracle/BEA WebLogic or IBM WebSphere app servers installed, you can test your deployed .ear file using the testServerEarWebLogic.bat or testServerEarWebSphere.bat files in a manner similar to those described above. These files are located in the Samples\Server\Containers\EAR directory of your Corticon installation directory.
January 13, 2012
Page 24
as In-Process Java Classes

testServer.bat is a batch file located in the Server directory of your Corticon installation
directory, and is designed to perform the basic in-process initialization, and then present a menu of API methods you can invoke from within a DOS window. Viewing testServer.bat with a text editor, you can see how it sets classpaths, starts the JVM and then invokes the CcServerApiTest class. The source code (.java) for this class is provided in the Server\src directory of your Corticon installation directory. It is a good reference to use when you want to see exactly how the Corticon Server API set is used in your own code. In addition to the 6 base Corticon Server jars listed above, the batch file also loads some hard-coded Java business objects for use with the Java Object Messaging options (menu option 28-33 in Figure 7). These hard-coded classes are included in CcServer.jar so as to ensure their inclusion on the JVMs classpath whenever CcServer.jar is loaded. The hard-coded Java objects are intended for use when invoking the OrderProcessing.erf Decision Service included in the default Corticon Server installation.
Figure 5 testServer.bat
When executed, the testServer.bat opens a DOS window and displays the API menu, as shown below:
January 13, 2012
Page 25
Figure 6 Top Portion of the testServer.bat DOS Window
The menu displayed in the DOS window is too large to fit on a single printed page, so it has been divided into two screenshots here. In the upper portion of the DOS window, shown in Figure 6, above, the class loading process is visible. Once all classes are loaded, Corticon Server starts up in the JVM.
January 13, 2012

Figure 7 Bottom Portion of the testServer.bat DOS Window
Page 26
In the lower portion of the DOS window shown in Figure 7 above, we see the available API methods, listed by number. Most of these methods apply to a Corticon Server with loaded Rulesheets. Since we have not deployed any Rulesheets yet, we will need to use an administrative method to test if Corticon Server is loaded in-process correctly. A good administrative method to call is option #23, Get CcServer Info. This choice corresponds directly to the Java API method getCcServerInfo() described in complete detail in the JavaDoc. Selecting option #23, Get CcServer Info, causes the CcServerApiTest class to make a call to the Corticon Server running in-process. It asks for a list of configuration parameters and returns them to the DOS window. The results of the call are shown in Figure 8, below:
Figure 8 testServer.bat Response
testServer.bat didnt load any Decision Services, so Corticon Server is basically replying with an
empty status message. But the important thing is that we have verified that Corticon Server is running correctly in-process and is listening for, and responding to, calls. At this stage in the deployment, this is all we want to verify.
January 13, 2012
Page 27
PREPARING STUDIO FILES FOR DEPLOYMENT

MAPPING THE VOCABULARY
Part of the integration process involves mapping our Vocabulary terms (which are used by the rules in our Rulesheets) to the structure of the data that will be sent to the deployed Ruleflows in runtime. This ensures that when the Decision Service is invoked, the data included in the invocation will be understood, translated, and processed correctly. To map your Vocabulary, Studio must be set to Integration Deployment mode. This mode can be set by selecting Window>Preferences from the Studio menubar, then selecting Rule Modeling from the left-hand list, then clicking the Integration Deployment radio button, as shown below:
Figure 9 - Selecting Integration Deployment Mode
XML Mapping
If you have chosen to use Option 1 or 2 in Table 1 in other words, the data payload of your call will be in the form of an XML document then your Vocabulary may need to be configured to match the naming convention of the elements in your XML payload. Entity Mapping Vocabulary entities correspond to XML complex elements (complexTypes). If the complexType matches exactly (spelling, case, special characters, everything), then no mapping is necessary. However, if the complexType name differs in any way from the Vocabulary entity name, then the complexType name must be entered into the XML Class Name property, as shown below.
January 13, 2012
Page 28
Figure 10 Mapping a Vocabulary Entity to an XML complexType
In the example shown in Figure 10, the Vocabulary entity name (Aircraft) does not exactly match the name of the external XML Class (Plane), so the mapping entry is required. If the two names were identical, then no mapping entry would be necessary. If XML Namespaces vary within the document, then use the XML Namespace field to enter the full namespace of the XML Element Name. If no XML Namespace value is entered, then it is assumed that all XML Elements use the same namespace. Attribute Mapping Vocabulary attributes correspond to XML simple elements. If the element name matches exactly (spelling, case, special characters, everything), then no mapping is necessary. However, if the element name differs in any way from the Vocabulary attribute name, then the element name must be entered into the XML Property Name property, as shown in Figure 11, below.
Figure 11 Mapping a Vocabulary Attribute to an XML SimpleType
If XML Namespaces vary within the document, then use the XML Namespace field to enter the full namespace of the XML Element Name. If no XML Namespace value is entered, then it is assumed that all XML Elements use the same namespace.
January 13, 2012
Server Integration & Deployment Guide 5.2 Association Mapping
Page 29
Vocabulary associations correspond to references between XML complex elements. If the element name matches exactly (spelling, case, special characters, everything), then no mapping is necessary. However, if the element name differs in any way from the Vocabulary association name, then the element name must be entered into the XML Property Name property, as shown below.
Figure 12 Mapping a Vocabulary Association to an XML ComplexType
XML Namespace Mapping Changes in BRMS Version 5.2 In BRMS versions prior to 5.2, Corticon Server assumed that incoming XML requests were loosely compliant with the XSD/WSDL generated for a particular Decision Service (by the Deployment Console, for example). The Corticon XSD/WSDLs generated all had a targetNamespace of urn:Corticon. The problem with this approach is that most SOA systems, particularly those that care about XML validation, require the targetNamespace to be unique, ideally globally unique. Two properties in CcDeployment.properties (com.corticon.xml.addDefaultNamespace and com.corticon.schemagenerator.addDefaultNamespace) allow you to turn off targetNamespace usage in the XSD/WSDL altogether. But prior to version 5.2, you could not selectively assign specific namespaces to specific elements (either Entities or Attributes) within the Vocabulary. In version 5.2, the XML Schema targetNamespace is controlled by a new CcDeployment.properties property named ensureUniqueTargetNamespace so that you can specify the desired behavior of Corticons XSD/WSDL generation subsystem. By default, the SOAP envelope targetNamespace will be set to a concatenation of the following strings: the WSDL's service soap address location + forward slash character (/) + the decision service name.
You can also switch back to old (prior to version 5.2) behavior for backward compatibility purposes by setting ensureUniqueTargetNamespace=false. The following screenshots juxtapose old XSD/WSDLs with new XSD/WSDLs:
Page 30
Figure 13 Old XSD with Generic Namespace (version 5.1 and earlier)
Figure 14 New XSD with Unique Namespace (version 5.2 and later)
Figure 15 Old WSDL with Generic Namespace (version 5.1 and earlier)
Figure 16 New WSDL with Unique Namespace (version 5.2 and later)
Namespace mapping changes in version 5.2 also affect some APIs. Please see the JavaDoc for full details.
January 13, 2012
Page 31
Java Object Mapping

If you have chosen to use Option 3 in Table 1 in other words, the data payload of your call will be in the form of a map or collection of Java objects then your Vocabulary may need to be configured to match the method names within those objects. Studio can import a package of classes and automatically match the object structure with the Vocabulary structure. In other words, it will try to determine which objects match which Vocabulary entities, which properties match which Vocabulary attributes, and which object references match which Vocabulary associations. To perform this matching, Studio assumes your objects are JavaBean compliant, meaning they contain public get and set methods to expose those properties used in the Vocabulary. Without this JavaBean compliance, the automatic mapper may fail to fully map the package, and you will need to complete it manually. To import package metadata: 1. Open your Vocabulary in Studios Vocabulary Edit mode. 2. From the menubar, select Vocabulary>Java Object Messaging>Import Java Class Metadata, as shown in Figure 17, below.
Figure 17 - Importing Java Class Metadata for Mapping
3. Use the Browse button to select the location of your Java Business Objects. They should be compiled class files or Java archives (.jar files).
January 13, 2012
Page 32
Figure 18 Browsing to your Java Class files
4. Select the package containing the Java business objects as shown above
Figure 19 - Importing Java Class Metadata for Mapping
5. If the import succeeds, you will see the message shown in Figure 20.
January 13, 2012
Page 33
Figure 20 - Java Class Metadata Import Success Message
Now that the import is complete, well examine our Vocabulary to see what happened. Entity Lets take a look at our sample class, which we intend to map to the Aircraft entity.
Figure 21 - 1st Portion of MyAircraft Class
We can see in line 6 of Figure 21 that this class isnt actually named Aircraft its named MyAircraft. The automatic mapper attempts to locate a class by the same name as each entity. In the case of Aircraft, it looks for a class named Aircraft. Not finding one, it leaves the field empty, as shown in Figure 22.
January 13, 2012
Page 34
Figure 22 Default Map of Class to Entity
Because no Aircraft class exists in the package, we need to manually map this entity, using the Java Package and Java Class Name drop-downs, as shown in Figure 23, below. The metadata import process populates the drop-downs for us. Be sure to select the package name from the Java Package drop-down so the mapper knows where to look.
Figure 23 - Manually Mapping MyAircraft Class to Aircraft Entity
Attribute When attempting to map attributes, the mapper looks for class properties which are exposed using public get and set methods by the same name. For example, if mapping attribute flightNumber, the mapper looks for public getFlightNumber and setFlightNumber methods in the mapped class.
January 13, 2012
Page 35
Figure 24 - 2nd Portion of MyAircraft Class
In the case of attribute tailNumber, the mapper finds get and set methods that conform to this naming convention, so the method names are inserted into the fields in gray type, as shown in Figure 25, below.
Figure 25 - Auto-Mapped Attribute Method Names
In those cases where the mapper cannot locate the corresponding methods, you will need to select them manually. Notice in the MyAircraft class shown in Figure 21, no get and set methods exist for istrAircraftType since it is a public instance variable. Therefore, we need to select it from the Java Object Field Name drop-down, as shown in Figure 26, below.
January 13, 2012
Page 36
Figure 26 - Manually Mapped Public Instance Variable Name
When a class property contains get and set methods, but their names do not conform to the naming convention assumed by the auto-mapper, we must select the method names from the Java Object Get Method and Set Method drop-downs, as shown in Figure 27 below.
Figure 27 - Manually Mapped Property Get and Set Method Names
If you worked with Java Object Messaging and mapping in earlier versions of Corticon Business Rules Management, then you may recall that external data types also required manual mapping. In Version 5.2, a propertys data type is detected by the auto-mapper, so theres no need to manually enter it. This is shown by the flightNumber attribute in Figure 28, below. Note from Figure 21 that this property uses a primitive data type int, and it is automatically mapped anyway.
January 13, 2012
Page 37
Figure 28 - Auto-Mapped Property Despite Different Data Type
Association The mapper looks for get and set methods for associations the same way that it does for attributes. In the case of the Aircraft.flightPlan association, shown in Figure 29, below, these methods dont conform to the naming convention expected by the mapper. So once again, we must manually select the appropriate method names from the Java Object Get Method and Set Method drop-downs, as shown in Figure 30, below.
Figure 29 - 3rd Portion of MyAircraft Class
January 13, 2012
Page 38
Figure 30 - Manually Mapped Association Get and Set Method Names
Java Generics
Support for type-casted collections is included in Corticon Business Rules Management Version 5.2. If your Java Business Objects include type-casted collections (introduced in Java 5), then Corticon will ensure these constraints are interpreted correctly in association processing.
Java Enumerations
Enumerations are custom Java objects you define and use inside of your Business Objects. They are used to define a preset value set for a particular type. For simplicity, lets assume that a Java Enumeration has a Name and multiple Labels (or Types). Here is a common example of a Java Enumeration:
public enum Day { MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY; }
The Day enumeration has 5 different Labels {Day.MONDAY, Day.TUESDAY, Day.WEDNESDAY, Day.THURSDAY, and Day.FRIDAY}. All of these labels are all considered of type Day. So if a method signature accepts a Day type, it will accept all 5 of these defined labels. For example:
public class Person { private Day iPayDay = null; public Day getPayDay() {return iPayDay;} public void setPayDay(Day aValue) {iPayDay = aValue;} }
And here is an example of a call to the setPayDay(Day) method:


lPerson.setPayDay(Day.MONDAY);
Page 39
Because Day.MONDAY is of type Day, the setting of the value is complete. Prior to Version 5.2, business rules could only set basic Data Types into Business Objects. Basic data types included String, Long, long, Integer, int, Boolean, boolean, etc. But in 5.2, business rule execution can also set your business objects Enumeration values. Corticon performs this by matching Labels in your business objects enumerations with the Custom Data Type (CDT) labels defined in your Vocabulary. From our example: Java Enumeration Label Names for enum Day:
MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY
Now, the Vocabulary must have these same Labels defined in the CDT that is assigned to the attribute.
Figure 31 Vocabulary CDT Labels must match Business Object Enumeration Labels (Types)
January 13, 2012
Page 40
Figure 32 Vocabulary Mapper found correct Metadata based on matching enumeration labels
The key to metadata matching is the Labels as long as your BO enumeration labels match the Vocabularys CDT Labels, it should work fine. So what happens if the Labels do NOT match? Extra validation has been added to the Vocabulary to help identify this problem. The example below shows a Label mismatch:
Figure 33 Vocabulary CDT Label / Object Enumeration Label Mismatch
Notice the Vocabulary attribute is flagged with the small orange warning icon (shown in the upper left of the figure above). The associated warning message states:
Java Object Get Method getPayDay return type is an Enumeration and has a mismatch in values between the Enumeration Labels [MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY] and Custom Datatype Labels [MONDAYS, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY].
January 13, 2012
Page 41
Verifying Java Object Mapping

You may have noticed that in several of the screenshots above, small orange triangle warning icons appear next to the Vocabulary nodes whose mappings have not yet been selected. Each warning will have a corresponding message entered in the Problems window, which is usually located towards the bottom of the Studio window. If you dont see it, use Window>Show View>Problems to display it.
Figure 34 Problem window showing list of current mapping problems
Once all mappings have been made (either automatically or manually), these warning icons will disappear.
Listeners
During runtime, when an attributes value is updated by rules, the update is communicated back to the business object by way of Listener classes. Listener classes are compiled at deployment time when Corticon Server detects a Ruleflow using Java Object Messaging. Once compiled, these Listener classes are also added to the .eds file, which is the compiled, executable version of the .erf. This process ensures that Corticon Server knows how to properly update the objects it receives during an invocation. Because the update process uses compiled Listener classes instead of Java Reflection, the update process occurs very quickly in runtime. Even though Java Object metadata was imported into Studio for purposes of mapping the Vocabulary, and those mappings were included in the Rulesheet and Ruleflow assets, the Listener classes, like the rest of the .erf, is not compiled until deployment time. As a result, the same Java business object classes must also always be available to Corticon Server during runtime. Corticon Server assumes it will find these classes on your application servers classpath. If it cannot find them, Listener class compilation will fail, and your deployed Ruleflow will be unable to process transactions using Java business objects as payload data. If a Ruleflow (.erf) is deployed to Corticon Server without compiled Listeners, then it will accept only invocations with XML payloads, and reject invocations with Java object payloads. When invoked with Java object payloads, Corticon Server will return an exception, as shown in Figure 35, below.
CcServer.execute(String, Collection, Integer, Date) Decision Service DecisionServiceName is not enabled to run Object Execution. Vocabulary and Ruleset need to be regenerated with proper Java Object mappings in place
Figure 35 - Server Error Message When Listeners Not Present

Page 42
DEPLOYING CORTICON RULEFLOWS
Rulesheets may be tested in Studio using Ruletests, however they must be packaged as Ruleflows in order to be deployed to Corticon Server. Rulesheets cannot be deployed directly to Corticon Server. Once a Ruleflow has been built and tested in Studio, it must be prepared for deployment. Deploying a Ruleflow requires at least one and, often two, steps:
RULEFLOW DEPLOYMENT
Once a Ruleflow has been deployed to the Corticon Server, we stop calling it a Ruleflow and start calling it a Decision Service. The process of deploying a Ruleflow is really an act of instructing a running Corticon Server instance to load a Ruleflow and prepare to execute it in response to a call from an external client application. There are 2 ways to inform the Corticon Server which Ruleflows it should load and how to configure certain execution parameters for each. These methods are discussed in the following paragraphs.
using Deployment Descriptor files

Before a Decision Service can be consumed by a client application, Corticon Server must first be initialized by the application architecture startup sequence. Then, Corticon Server loads one or more Deployment Descriptor files by calling the ICcServer interfaces loadFromCdd method. This causes Corticon Server to read the Deployment Descriptor file(s), load each listed Ruleflow, and set other execution and configuration parameters accordingly. Deployment Descriptor files, which have the filename suffix .cdd, tell Corticon Server the following: The name(s) and directory location(s) of the Ruleflow(s) to load upon startup. The reload option each Decision Service will use. The type of request message style to expect from consumers of each Decision Service. The unique name (Decision Service Name) of each Ruleflow. The concurrency properties of each Decision Service.
Deployment Descriptor files are easily created and managed using the Corticon Deployment Console utility. The Deployment Console is included by default in all Corticon Server installations. Purpose of the Deployment Console Utility The Deployment Console has two functions:
January 13, 2012
Page 43
Create Deployment Descriptor files. These files, carrying the file suffix .cdd, are XML documents which instruct Corticon Server which Ruleflows to load, and how to configure certain parameters and settings for each Ruleflow. Creating and using Deployment Descriptor files will make up the main topics within this chapter. Create XML service contract documents. These documents are used for Ruleflow integration and will be discussed in the Integration chapter of this manual.
Launching the Deployment Console Utility Deployment Console is started in one of two ways: From the Windows Start menu, Programs>Corticon>Deployment Console. Using the batch file DepConsole.exe in the Server directory of your Corticon installation directory.
The Deployment Console is divided into two sections (one section for each of its two functions), shown in Figure 36 with orange labels. Because the Deployment Console is a wide window, it will be shown as two halves - a left half shown in Figure 36 and a right half shown in Figure 37. Depending on your screen resolution, you may need to scroll between the left and right portions of the Deployment Console window using the horizontal scroll bar provided. The blue numbered circles shown in the figures are further described below:
January 13, 2012
Page 44
Deployment Descriptor
2 7
5 8
6 9
Service Contract
This section is described in the Integrating Decision Services chapter of this manual
Figure 36 Left Portion of Deployment Console, with Deployment Descriptor File Options Numbered
The numbered steps below correspond to the Deployment Console diagram above. 1. File menubar. File is used to create new Deployment Descriptor files (File>Save), open an 1 existing .cdd (File>Open), or save a .cdd under a different name (File>Save As). The .cdd name appears in the title bar. 2. Decision Service Name. A unique identifier or label for the Decision Service. It is used when 2 invoking the Decision Service, either via an API call or a SOAP request message. See Invoking Corticon Server for usage details. 3 3. Ruleflow. All Ruleflows listed in this section are included in the open Deployment Descriptor file. The name of the open Deployment Descriptor file is shown in the Deployment Consoles title bar. Deployment properties are specified on a per-Ruleflow basis. Each row represents one Ruleflow. Use the button to navigate to a Ruleflow file and select it for inclusion in this Deployment Descriptor file. Note that Ruleflow absolute pathnames are shown in this section, but relative pathnames are included in the actual .cdd file.
January 13, 2012
Page 45
The term deploy, as we use it here, means to inform the Corticon Server that you intend to load the Ruleflow and make it available as a Decision Service. It does not require actual physical movement of the .erf file from a design-time location to a runtime location, although you may do that if you choose just be sure the files path is up-to-date in the Deployment Descriptor file. But movement isnt required you can save your .erf file to any location in a file system, and also deploy it from the same place as long as the running Corticon Server can access the path. 4 Version: the version number assigned to the Ruleflow in the Ruleflow>Properties window of Corticon Studio. Note that this entry is editable only in Studio and not in the Deployment Console. An explanation of how Corticon Server processes this information is found in the Decision Service Versioning and Effective Dating chapter, below. Also see the Quick Reference Guide for a brief description of the Ruleflow Properties window and the Rule Modeling Guide for details on using the Ruleflow versioning feature. It is displayed in the Deployment Console simply as a convenience to the Ruleflow deployer. 5 Version Label: the version label assigned to the Ruleflow in the Ruleflow>Properties window of Corticon Studio. Note that this entry is editable only in Studio and not in the Deployment Console. See the Quick Reference Guide for a brief description of the Ruleflow Properties window and the purpose of the Ruleflow versioning feature. 6 Effective Date: the effective date assigned to the Ruleflow in the Ruleflow>Properties window of Corticon Studio. Note that this entry is editable only in Studio and not in the Deployment Console. An explanation of how Corticon Server processes this information is found in the Decision Service Versioning and Effective Dating chapter, below. Also see the Quick Reference Guide for a brief description of the Ruleflow Properties window and the purpose of the Ruleflow effective dating feature. 7 2. Add/Remove Ruleflow. The Add button creates a new empty row in section 3. The Remove button removes the highlighted row from section 3. There is no limit to the number of Ruleflows that may be included in a single Deployment Descriptor file. 3. Pre-compile Decision Services: By default, Corticon Server compiles Ruleflows upon 8 deployment, on-the-fly. In other words, a Ruleflow is not compiled until it is deployed to Corticon Server. You can choose to pre-compile Ruleflows in advance of deployment. If you choose to pre-compile, then youll be prompted for a deposit location for the .eds file (which contains the compiled executable code). The .cdd file will contain reference to the .eds instead of the usual .erf file. 4. Save Deployment File: saves the .cdd file. Equivalent to File>Save option from the File 9 menubar. 5. 10 Expiration Date: the expiration date assigned to the Ruleflow in the Ruleflow>Properties window of Corticon Studio. Note that this entry is editable only in Studio and not in the Deployment Console. An explanation of how Corticon Server processes this information is found in the Decision Service Versioning and Effective Dating chapter, below. Also see the Quick Reference Guide for a brief description of the Ruleflow Properties window and the purpose of the Ruleflow expiration dating feature.
Server Integration & Deployment Guide 5.2 6. 11 Pool Size (Min-Max).
Page 46
Minimum: The minimum number of instances or copies created for a Decision Service when it is loaded by Corticon Server. Instances of a Decision Service are known as Reactors. These Reactors are placed in a pool, where they wait patiently until assigned by Corticon Server to an incoming request, or expire due to inactivity. The larger the pool size, the greater the concurrency (but greater the memory usage). Default entry is 1, which means that even under no load no incoming requests Corticon Server will always maintain one Reactor in the pool for this Decision Service. Maximum: The maximum number of Reactors Corticon Server can put into the pool for this Decision Service. Therefore, the number of Reactors that can execute concurrently is determined by the max pool size. If additional requests for the Decision Service arrive when all Reactors are busy, the new requests queue until Corticon Server can allocate a Reactor to the new transaction (usually right after a Reactor is finished with its current transaction). The more Reactors in the pool, the greater the concurrency (and the greater the memory usage). See Performance and Tuning chapter for more guidance on Pool configuration. Default entry is 5.
10
11
12
13
This section is described in the Integrating Decision Services chapter of this manual
Figure 37 Right Portion of Deployment Console, with Deployment Descriptor File Options Numbered
Page 47
7. 12 Dynamic Reload. If Yes, then Corticon Server will periodically look to see if a Deployment Descriptor file, or any of the Decision Service entries in that file, has changed since the .cdd was last loaded. If so, it will be automatically reloaded. The time interval between checks is defined by property com.corticon.ccserver.serviceIntervals in CcServer.properties. Even if No, Corticon Server will still use the most recent Ruleflow when it adds new Reactors into the pool. 8. 13 XML Messaging Style. Determines whether request messages for this Decision Service should contain a flat (Flat) or hierarchical (Hier) payload structure. The Decision Service Contract Structures section of the Integration chapter provides samples of each. If set to Auto Detect, then Corticon Server will accept either style and respond in the same way. A Deployment Descriptor File Template Deployment Descriptor files are expressed in XML. The Deployment Descriptor file shown below contains royal blue parameter names that correspond to fields in the Deployment Console. Each line containing a parameter also has a dark blue index number that references the like-numbered section in one of the two Deployment Console diagrams shown above. For example, <min-size> and <max-size>, shown below labeled with blue index number 8 correspond to the Minimum and Maximum Pool Size settings labeled with blue index number 8 in Figure 36.
<?xml version="1.0" encoding="UTF-8"?> <cdd soap_server_binding_url="URL or SOAP node relaying requests to Corticon Server"> <decisionservice> 3 <ruleset-uri>path to first Ruleflow.erf file</ruleset-uri> <auto-reload-if-modified>Dynamic Reload setting</auto-reload-if-modified> 12 <msg-struct-type>XML Messaging Style</msg-struct-type> 13 <pool> 2 <name>first decision service name</name> <min-size>minimum pool size</min-size> 11 <max-size>maximum pool size</max-size> </pool> </decisionservice> <decisionservice> 3 <ruleset-uri>path to second Ruleflow .erf file</ruleset-uri> <auto-reload-if-modified>Dynamic Reload setting</auto-reload-if-modified> 12 <msg-struct-type>XML Messaging Style</msg-struct-type> 13 <pool> 2 <name>second decision service name</name> <min-size>minimum pool size</min-size> 11 <max-size>maximum pool size</max-size> </pool> </decisionservice> </cdd>
January 13, 2012
Page 48
Note in the template Deployment Descriptor file above, two separate Decision Services are included. There is no limit to the number of Decision Services you can include in a single Deployment Descriptor file. Each Decision Service has its own <decisionservice> element. An Actual Deployment Descriptor File Using the same settings as shown in Figure 37, above, a Deployment Descriptor file was generated:
<?xml version="1.0" encoding="UTF-8"?> <cdd soap_server_binding_url="http://localhost:8082/axis/services/Corticon"> <decisionservice> <ruleset-uri>tutorial_example.erf</ruleset-uri> B <auto-reload-if-modified>true</auto-reload-if-modified> <msg-struct-type />A <pool> <name>tutorial_example</name> <min-size>1</min-size> <max-size>5</max-size> </pool> </decisionservice> <decisionservice> <ruleset-uri>ruleflow2.eds</ruleset-uri> <auto-reload-if-modified>true</auto-reload-if-modified> <msg-struct-type /> <pool> <name>ruleflow2</name> Multiple Decision <min-size>1</min-size> Services allowable <max-size>5</max-size> </pool> </decisionservice> </cdd>
In the actual Deployment Descriptor file shown above, note the following: A <msg-struct-type /> is empty in both Ruleflow sections. This indicates a selection of Auto detect in section 13 of the Deployment Console. If Flat message style is selected in section 13, the Deployment Descriptor file will contain a FLAT entry here. Selecting Hier in section 13 will insert HIER here. The path names to the Ruleflow.erf files (or .eds files if pre-compiled) are B expressed relative to the location of the Deployment Descriptor file (indicated by the ../../ syntax). If the saved location of the Deployment Descriptor file has path in common with the location of the .erf file, then the .erf path included here will be expressed in relative terms. If the two locations have no path in common (they are saved to separate machines, for example), then the .erfs path will be expressed in absolute terms. These paths may always be manually edited if changes are desired. UNC paths can also be used to direct Server to look at remote directories. Use caution in moving .cdd files once deposited because the relative
Page 49
path pointer to the .erf or .eds may be disrupted. If you save a .cdd file to a particular location, then move it later, you may need to edit the relative path pointer to the .erf or .eds. If you are using the bundled Apache Tomcat server to test and deploy your Ruleflow, the Deployment Descriptor file must be copied to the Server \Tomcat\CcServer\cdd directory of your Corticon installation directory because Corticon Server is pre-configured (default settings) to read all .cdd files in this directory upon startup.
Telling the Server Where to find Deployment Descriptor Files

A Deployment Descriptor file (.cdd) tells Corticon Server everything it needs to know to load Ruleflows (uncompiled .erf or pre-compiled .eds) and prepare to execute them, but Corticon Server still needs to know where to find the Deployment Descriptor file (or files) itself. There are several ways to accomplish this. Using the Administrative API set This is accomplished using admin API methods named loadFromCdd() or loadFromCddDir(). loadFromCdd() requires as an argument a complete path to the Deployment Descriptor file you want to load. loadFromCddDir() takes as an argument a path to a directory where Corticon Server will look and load all Deployment Descriptor files it finds inside. These methods are summarized in the Java API Summary in Appendix B: API Summary and described fully in the JavaDoc. These two methods are used in the API testing batch files testServer.bat and testServerAxisTomcat.bat described in installation testing sections (testing the Servlet installation and testing the In-process Installation) above. These methods are invoked from the DOS menus by choosing option 7 and entering path information (the methods arguments) when prompted. How Axis.war Finds the Deployment Descriptor Files If you have installed Corticon Server using Axis.war, you may have wondered how it knows to look in the directory Server\Tomcat\CcServer\cdd of your Corticon installation directory by default to read and load Deployment Descriptor files (.cdd files). Inside Axis.war is a class named CcSoapServerInit. The decompiled source for this class is available in the Samples\Server\Containers\WAR\src directory of your Corticon installation directory. Open the source file and scroll down until you see this portion:
January 13, 2012
Page 50
Figure 38 loadFromCddDir() Inside CcSoapServerInit.class
Were already familiar with loadFromCddDir() it causes Corticon Server to look in the directory defined by the argument string and load any and all .cdd files it finds inside. This is a very convenient way to load Decision Services onto Corticon Server because one call to loadFromCddDir() is all you need to load multiple Decision Services on Corticon Server. But it is less obvious where the argument for the method is coming from. Looking lower in CcSoapServerInit.java, we see some utility methods that define the argument.
findCorticonDirectory() tries to obtain the value of autoloaddir from CcProperties. CcProperties holds all property values from CcConfig.jar for that Corticon Server instance. So in effect, the method is looking into the active CcConfig.jar file and trying to retrieve the value of com.corticon.soap.autoloaddir. But autoloaddir isnt defined in any of the .properties files inside CcConfig.jar.
Figure 39 - Searching for CDD Path...
January 13, 2012
Server Integration & Deployment Guide 5.2 So, failing to find a value for autoloaddir, findCorticonDirectory() next assembles a pathname by combining the values of lstrUserDir and cstrServerCddPath.
Page 51
Figure 40 - Assembling a Path to Locate CDD Files
cstrServerCddPath is a constant defined as CcServer/cdd inside this class. lstrUserDir, on the other hand, comes from cstrUserDirPropName, which is a constant defined earlier in the class as user.dir. User.dir is a variable set during JVM startup. In the case of the bundled Tomcat installation, user.dir is defined in the startServer.bat file.
Figure 41 - Tomcat User.dir assignment
When Tomcat starts, user.dir is given the value of <corticon_install_dir>\Server\Tomcat by default, and then when Corticon Server starts, it retrieves this value of user.dir in order to assemble a pathname string to use as an argument in loadFromCddDir(). When all these variables
Server Integration & Deployment Guide 5.2 are assembled, the final argument to the method is:
<corticon_install_dir>\Server\Tomcat\CcServer\Cdd.
Page 52
Using the autoloaddir Property Although the autoloaddir property isnt set by default, its easy to add and use in your deployments. If you decide youd rather specify your cdd path in a class rather than hard-code in your application server launch scripts, simply add the com.corticon.soap.autoloaddir property to any .properties file inside CcConfig.jar. A pathname will then be available when the findCorticonDirectory() method looks for it when CcSoapServerInit.class runs during Corticon Server initialization.
Figure 42 - Defining autoloaddir as a Property
Be sure to write your absolute pathname using forward slashes, as shown above. Remember, even if you chose to use the autoloaddir property, you will still need code in your interface class (wrapper) to read the property and insert it into the loadFromCddDir() method, as shown in Figure 39. And youll also need code that then invokes the loadFromCddDir() method as shown in Figure 38. Using Servers web console The Monitoring chapter explains how to set Servers autoloaddir property remotely from the web console.
using the Server Web Console

The Server Web Console allows for direct deployment of Decision Services without needing to use a .cdd (as described above) or code a Java method call (as described below). This method of deployment can only be used with pre-compiled .eds files, not with uncompiled .erf files. More information about this option can be found here.
using APIs
While Deployment Descriptor files are a convenient way to specify the Ruleflows to be deployed and their configuration settings, there is another way to communicate the very same information to a running Corticon Server the Java API set. In the section above describing testing an in-process installation, Figure 7 shows an option 9 named Add a Decision Service (6 parameters). Selecting this option, then entering the arguments as prompted invokes the addDecisionService() method. The arguments used by this method include: 1. Decision Service Name
Server Integration & Deployment Guide 5.2 2. Decision Service path 3. Dynamic Reload setting (a.k.a auto-reload) 4. Minimum Pool Size 5. Maximum Pool Size 6. Message Structure Type
Page 53
As you can see, these are the very same parameters contained in the Deployment Descriptor file! Another similar option available in Figure 7 is: Add a Decision Service (3 parameters)
This method provides for backwards compatibility with previous versions of Corticon Server which had fewer features. The 3 parameter version uses only the first 3 entries (respectively) in the list above.
TESTING THE DEPLOYED CORTICON DECISION SERVICE

This testing only verifies that a Decision Service is loaded on Corticon Server. It does not actually request Corticon Server to execute a Decision Service because we have not yet learned how to compose or deliver a full request message to Corticon Server. Actual execution will be covered in the Integrating Corticon Decision Services chapter. In this section, well load Decision Services using the two methods described above, and then test the deployment using the API method getDecisionServiceNames(), which queries a running Corticon Server and requests the names of all deployed Ruleflows.
Deploying and Testing Decision Services via Deployment Descriptor Files (.cdd)
Start the bundled instance of Apache Tomcat and allow about 10 seconds for the web services, including the Corticon Server Servlet, to start up. Now, run the Axis test batch file testServerAxisTomcat.bat referred to earlier. Selecting option 22, shown in Figure 3, invokes the getDecisionServiceNames() method (this method requires no arguments).
Figure 43 Get Decision Service Names Method Success
January 13, 2012
Page 54
When Corticon Server started up, the Decision Service listed in Figure 43 was deployed automatically using Deployment Descriptor files included and pre-installed in <corticon_install_dir>\Server\Tomcat\CcServer\cdd. If you create your own Deployment Descriptor file and put it in this directory, the Ruleflows it contains and describes will also be deployed automatically whenever Corticon Server Servlet starts up inside Tomcat. It is important to note that Decision Services deployed using Deployment Descriptor files may only be removed from deployment or have deployment properties changed via their Deployment Descriptor file. In other words, a Decision Service deployed from Deployment Descriptor file cannot have its deployment properties changed by direct invocation of the API set; for example, if we try to use the Axis test batch file to Remove a Decision Service (option 19 and 20 from Figure 3). This is an important rule and worth reiterating: The deployment settings of Decision Services deployed via Deployment Descriptor files can only be changed by modifying their Deployment Descriptor file. The Java API methods have no effect on these Decision Services. The deployment settings of Decision Services deployed via Java API methods can only be changed via Java API methods. Deployment Descriptor files have no effect on these Decision Services.
Figure 44 Remove Decision Service Method Failure
In Figure 44, above, we see that the attempt to remove OrderProcessing, the Decision Service deployed by OrderProcessing.cdd (located in <corticon_install_dir>\Server\Tomcat\CcServer\cdd) has failed. To remove this Decision Service from deployment, or to modify any of its deployment settings, we must return to the Deployment Descriptor file, make the changes, and then allow the Corticon Server to update via its Dynamic Reload feature.
Deploying and Testing Decision Services via APIs

Rather than remove any Deployment Descriptor files already located by default in <corticon_install_dir>\Server\Tomcat\CcServer\cdd, we will instead use the in-process test batch file to: 1. Verify that no Decision Services are deployed. 2. Deploy a new Decision Service.
Server Integration & Deployment Guide 5.2 3. Verify that the Decision Service is loaded. 4. Remove the Decision Service from Deployment. 5. Verify that the Decision Service has been removed from deployment. Verifying no Decision Services are loaded As shown in Figure 7, option 21 requests the names of deployed Decision Services:
Page 55
Figure 45 - Get Decision Service Names Method Invoked
The response in Figure 45 shows that no Decision Services are currently deployed to Corticon Server running in-process. Now, lets load the Decision Service named tutorial_example.erf located in
<corticon_install_dir>\Samples\Rule Projects\Tutorial\Tutorial-Done using the 6
parameter load method (option 9) in Figure 7.
Figure 46 Add a Decision Service Method Invoked
January 13, 2012
Page 56
Notice that the 6 parameters we entered are the same 6 entries in the list of deployment properties described in the Deployment Descriptor file section, Figure 36 and Figure 37. The very first parameter, Decision Service Name, has been given the value of airCargo. You may notice a pause before the Transaction completed message is displayed. This is due to the deployment-time compilation performed by Corticon Server 5.2. Larger Ruleflows (more Rulesheets or rules) will require more time to compile. Now, to verify that this Decision Service is deployed, well re-invoke the
getDecisionServiceNames() method using option 21.
Figure 47 Get Decision Service Names Method, Re-invoked
Figure 47 shows that the Decision Service named airCargo is deployed to Corticon Server. Now, to remove airCargo from deployment, well use option 18.
Figure 48 Remove Decision Service Method
And then to verify that airCargo has been removed from Corticon Server, we invoke getDecisionServiceNames() once again using option 21:
Figure 49 Get Decision Service Names Method
Figure 49 shows that airCargo has successfully been removed from deployment.
January 13, 2012
Page 57
DEPLOYING UNCOMPILED VS. PRE-COMPILED DECISION SERVICES

You have the choice to deploy uncompiled .erf files or pre-compiled .eds files as Decision Services. There are advantages and disadvantages to each method, which result from the basic difference between the two file types:
ERF files
The .erf file is really just a pointer file that informs Corticon Server where, specifically, to look for the component parts of the Decision Service, including the .ecore and all included .ers files. This has the following important consequences: All of the component files (.ecore and .ers) must be accessible to Corticon Server, so that it is able to read them during compilation. This may mean you need to keep tighter access controls on the various component files involved, which may be less convenient in production environments.
.erf compilation occurs on-the-fly, which may take a few seconds when first
deployed If an .ers file is shared among multiple .erf files, then a change to the .ers will cause .erfs to update also if their auto-reload property is set to true and Corticon Servers dynamic monitoring update service is running.
Because of these considerations, uncompiled Decision Service deployments are often used in nonproduction environments, where component files (.ecore and .ers) are more likely to change frequently or require looser controls.
EDS Files
The .eds file is a self-contained, complete deployment asset that includes compiled versions of all component files, including .ecore and .ers file. This has the following important consequences: Only the .eds file needs to be accessible to Corticon Server. Original component files (.ecore and .ers) can be archived offline and accessed only when changes need to be made to them.
.eds files are already compiled, so Corticon Server can load them quickly upon deployment, without the lag time required by .erf on-the-fly compilation.
if a rule changes inside a component .ers file, then the .eds must be recompiled and redeployed. The Corticon Servers dynamic monitoring update service will detect changes only to the .eds dateTimeStamp, not to the dateTimeStamp changes of any internal component files.
Because of these considerations, pre-compiled Decision Service deployments are often used in production environments, where component files (.ecore and .ers) are less likely to change frequently or require tighter controls.
January 13, 2012
Page 58
If your .erf contains Service Call-Outs, be sure to add the SCO classes to deployConsole.bat so that they are included in the classpath when the .eds is compiled. More information about SCOs can be found in the Extensions User Guide.
January 13, 2012
Page 59
INTEGRATING CORTICON DECISION SERVICES

This chapter explains how to correctly call or consume a Decision Service. Corticon Ruleflows, once deployed to a Corticon Server, are services, a fact we emphasize by calling them Decision Services. Services in a true Service Oriented Architecture have established ways of receiving requests and sending responses. Its important to understand and correctly implement these standard ways of sending and receiving information from Decision Services. In this chapter, we will not actually make a call to a deployed Decision Service that will come in the Invocation chapter that follows. Instead, we focus on the types of calls, their components, and the tools available to help you assemble them.
COMPONENTS OF A CALL TO CORTICON SERVER

Before going any further, lets clarify what calling a Decision Service really means. Technically, we will be making an execute call to, or invocation of, Corticon Server. The call/invocation/request (well use these three terms interchangeably) consists of: The name and location (URL) of the Corticon Server we want to call. The name of the Decision Service we want Corticon Server to execute. The data needed by Corticon Server to process the rules inside the Decision Service, structured in a way Corticon Server can understand. We often call this the payload.
The name and location of Corticon Server we want to call will be discussed in the Invocation chapter, since this information is concerned more with protocol than with content. The focus of this chapter will be on the other two items, Decision Service Name and data payload.
the Decision Service Name

The name of the Decision Service has already been established during deployment. Assigning a name to a Decision Service can be accomplished through a Deployment Descriptor file, shown as item 1 of Figure 36. Or it can be defined as an argument of the API deployment method addDecisionService(). Both versions of this API method, the 3 and 6 parameter versions, require the Decision Service Name argument. Once deployed, the Decision Service will always be known, referenced and invoked in runtime by this name. Decision Service Names must be unique, although multiple versions of the same Decision Service Name may be deployed and invoked simultaneously. See Versioning for more details.
the Data
While the data itself may vary for a given Decision Service from transaction to transaction and call to call, the structure of that data how it is arranged and organized must not vary. The data contained in each call must be structured in a way Corticon Server expects and can understand. Likewise, when
Page 60
Corticon Server executes a Decision Service and responds to the client with new data, that data too must be structured in a consistent manner. If not, then the client or calling application will not understand it.
SERVICE CONTRACTS: DESCRIBING THE CALL

Generically, a service contract defines the interface to a service, informing consuming client applications what they must send to it (the type and structure of the input data) and what they can expect to receive in return (the type and structure of the output data). If a service contract conforms to a standardized format, it can often be analyzed by consuming applications, which can then generate, populate and send compliant service requests automatically. Web Services standards define two such service contract formats, the Web Services Description Language, or WSDL (sometimes pronounced wiz-dull) and the XML Schema (sometimes known as an XSD because of its file extension, .xsd). Because both the WSDL and XSD are physical documents describing the service contract for a specific Web Service, they are known as explicit service contracts. A Java service may also have a service contract, or interface, but no standard description exists for an explicit service contract. Therefore, most service contract discussions in this chapter relate to Web Services deployments only. Depending on the choice of architecture made earlier, you have two options when representing data in a call to Corticon Server: an XML document or a set of Java Business Objects.
The XML WorkDocument

If you chose Option 1 or 2 in Table 1, then the payload of your call will have the form of an XML document. Full details on the structure of these two service contract options (WSDL and XSD) and their variations can be found in section XML Service Contract Descriptions and examples can be found in Appendix A.
Java Business Objects

Unfortunately, no standard method of describing a service contract for a Java service yet exists, so Corticon Business Rules Management provides no tools for generating such contracts.
Creating XML Service Contracts with Corticon Deployment Console

The earlier Deployment chapter introduced the Deployment Console as a way to create Deployment Descriptor files to easily deploy Decision Services and manage their deployment settings. The screenshot in Figure 36 hides the lower portion of the Deployment Console, however, because that portion is not concerned with Deployment Descriptor file generation, which is the focus of that chapter. Now is the time to discuss the lower portion of the Deployment Console. Instructions for starting or launching the Deployment Console are located in the earlier Deployment chapter.
Page 61
This section is described in the Deploying Rule Sets chapter of this manual
Service Contract 16 17 18 19 20 21 22 23
Figure 50 Deployment Console with Input Options Numbered
Service contracts provide a published XML interface to Decision Services. They inform consumers of the necessary input data and structure required by the Decision Service and of the data structure the consumer can expect as output. 9. Decision Service Level / Vocabulary Level. These radio buttons determine whether one service 16 contract is generated for each Ruleflow listed in the Deployment Descriptor section of the Deployment Console (the upper portion), or for the Vocabulary listed in section 17. Often, the same payload structure flows through many decision steps in a business process. While any given Decision Service might use only a fraction of the payloads content (and therefore have a more efficient invocation), it is sometimes convenient to create a single master service contract from the Decision Services Vocabulary. This simplifies the task of integrating the Decision Services into the business process because a request message conforming to the master service contract can be used to invoke any and all Decision Services
January 13, 2012
Page 62
that were built with that Vocabulary. This master service contract, one which encompasses the entire Vocabulary, is called Vocabulary Level. The downside to the Vocabulary-level service contract is its size. Any request message generated from a Vocabulary-level service contract will contain the XML structure for every term in the Vocabulary, even if a given Decision Service only requires a small fraction of that structure. Use of a Vocabulary-level service contract therefore introduces extra overhead because request messages generated from it may be unnecessarily large. In an application or process where performance is a higher priority than integration flexibility, using a Decision Service Level service contract is more appropriate. A Decision Service-level service contract contains the bare minimum structure necessary to consume that specific Decision Service no more, no less. A request message generated from this service contract will be the most compact possible, resulting in less network overhead and better overall system performance. But it may not be reusable for other Decision Services. 17 Vocabulary File. If generating a Vocabulary-level service contract, enter the Vocabulary file name (.ecore) here. If generating a Decision Service-level contract, this field is read-only and shows the Vocabulary associated with the currently highlighted Ruleflow row above. See Corticon Decision Service Contracts for details. 10. Select Work Document Entity. Before any service contract can be generated, a Work 18 Document Entity (WDE) must be chosen. The WDE serves as the root context for the XML document, whether flat or hierarchical in format. To assign a WDE in Studio, use menubar option Ruleflow>Properties and select from the drop-down in the Properties window. A Decision Service invocation should contain a data payload, and the WDE is simply a way of defining the minimum payload necessary. The entity selected as WDE becomes a mandatory element in the invocation. If generating a Vocabulary-level service contract, select a WDE from the list. If generating a Decision Service-level contract, select the Ruleflow row in the Deployment Descriptor file section to highlight it, then select a WDE from the list. Do this for each Ruleflow. If a WDE has already been selected for a Ruleflow, it should appear in this field. If it has already been specified, you can change it here and the Ruleflow file will also be updated. 19 Type. This is the service contract type: WSDL or XML Schema. A WSDL can also be created from within Studio using the Ruletest > Testsheet > Data > Export WSDL menu option. See the Ruletest chapter of the Studio Quick Reference Guide for more details. 20 11. XML Messaging Style. When using XML to describe the payload, there are two structural styles the payload may take, flat and hierarchical. Flat payloads have every entity instance at the top (root) level with all associations represented by reference. Hierarchical payloads represent associations with child entity instances embedded or indented within the parent entity structure.
January 13, 2012
Server Integration & Deployment Guide 5.2 Both styles are illustrated below. Assume a Decision Service uses an Account and its associated SecurityPositions. In the Flat style, the payload is structured as:
Page 63
Each entity at the same document level
Href tags point to the parents associated children entities
Figure 51 - Example of a Flat (FLAT) Message
January 13, 2012
Server Integration & Deployment Guide 5.2 In the hierarchical style, the payload is structured as:
Page 64
Child entity instances are embedded (or indented) under parents via their association role names
Figure 52 - Example of a Hierarchical (HIER) Message
The Hierarchical style need not be solely hierarchical; some associations may be expressed as flat, others as hierarchical. In other words, hierarchical can really be a mixture of both flat and hierarchical. A mixture of hierarchical and flat elements is sometimes called a hybrid style. Note that in the flat style, all entity names start with an upper case letter. Associations are represented by href tags and role names which appear with lowercase first letters. By contrast, in the hierarchical style, an embedded entity is identified by the role name representing that nested relationship (again, starting with a lowercase letter). Role names are defined in the Vocabulary. This option is enabled only for Vocabulary-level service contracts, because the message style for Decision Service-level service contracts is specified in the Deployment Descriptor file section (the upper portion) of the Deployment Console. 12. Output directory. The directory location where the Deployment Console saves new service 21 contracts. 13. SOAP Server URL. URL for the SOAP node that is bound to the Corticon Server. Enabled for 22 WSDL service contracts only. The default URL is http://localhost:8082/axis/services/Corticon that makes a Decision Service
January 13, 2012
Page 65
available to the default Corticon Server Tomcat installation. This default may be changed in CcDeployment.properties see CcDeployment.Properties. 14. 23 Generate Service Contracts. Generates the WSDL or XML Schema service contracts into the output directory. If you select Decision Service-level contracts, one service contract per Ruleflow listed in the Deployment Descriptor section (the upper portion) of the Deployment Console will be created. If you select Vocabulary-level service contracts, only one contract is created for the Vocabulary file specified in section 16.
TYPES OF XML SERVICE CONTRACTS

XML Schema (XSD)
The purpose of an XML Schema is to define the legal or valid structure of an XML document 1. In our case, this XML document will carry the data required by Corticon Server to execute a specified Decision Service. The XML document described by an XSD is the payload (the data and structure of that data) of a SOAP call to the Business Rules Server, or may also be used as the payload of a Java API call or invocation. XSD, by itself, is only a method for describing payload structure and contents. It is not a protocol that describes how a client or consumer goes about invoking a Decision Service; instead, it describes what the data inside that request must look like.
Web Services Description Language (WSDL)

A WSDL service contract differs from the XSD in that it defines both invocation payload and protocol 2. It is the most common and easiest way to integrate with a Web Services server. The WSDL file defines a complete interface, including: Corticon Server SOAP binding parameters. Decision Service Name. Payload, or XML data elements required inside the request message (this portion of the WSDL is identical to the XSD). XML data elements provided within the response message. The Web Services standard allows for two messaging styles between services and their consumers: RPC-style and Document-style. Document-style, sometimes also called Message-style, interactions are more suitable for Decision Service consumption because of the richness and (potential) complexity common in business. RPC-style interactions are more suitable for simple services that require a fixed parameter list and return a single result. As a result,
1 2
From W3C. For more information on XML Schemas, see http://www.w3schools.com/schema/schema_intro.asp For more information on WSDL, see http://www.w3schools.com/wsdl/default.asp January 13, 2012
Page 66
Corticon Decision Service WSDLs are always Document-style! If you intend to use a commercially available software toolset to import WSDL documents and generate request messages, be sure the toolset contains support for Document-style WSDLs.
Annotated Examples of XSD and WSDLs Available in the Deployment Console

The eight variations of service contract documents generated by the Deployment Console are shown and annotated in Appendix A. The table below provides direct links to each variation.
Section 1 2 3 4 5 6 7 8
Type XSD XSD XSD XSD WSDL WSDL WSDL WSDL
Level Vocabulary Vocabulary Decision Service Decision Service Vocabulary Vocabulary Decision Service Decision Service Flat
Style Hierarchical Flat Hierarchical Flat Hierarchical Flat Hierarchical
PASSING NULL VALUES IN XML MESSAGES

Passing a null value to Corticon Server using XML payloads is accomplished in the following ways: Vocabulary Type An attribute of any type An attribute except String types How to Pass As Null Omit the XML tag for the attribute, or Use the XSD special value of xsd:nil=1 as the attributes value. Include the XML tag for the attribute but do not follow it with a value, e.g. <weight></weight> or simply <weight/>. If the type is String, this form is treated as an empty string (a string of length zero, which is not the same as null). Do not include an href to a potentially associable Entity (Flat model) or do not include the potentially associable role in a nested child relationship to its parent. Omit the complexType from the payload entirely.
An association
An entity
January 13, 2012
Page 67
SUPPORT FOR WINDOWS COMMUNICATION FRAMEWORK (WCF)

When using Corticon Server for .NET, you have the option to enable special support for Microsofts Windows Communication Framework (WCF). In CcDeployment.properties, when ensureComplianceWithDotNET_WCF=true then the service contract (WSDL/XSD) generated is modified as shown. Standard (non-WCF) versions are shown for comparison purposes. Major structural differences are indicated in bright red text. AllocateTrade is used as the sample Decision Service Name.
Definitions Section (WSDL only)

<definitions xmlns=http://schemas.xmlsoap.org/wsdl/ xmlns:tns=http://localhost:8082/axis/ser vices/Corticon/AllocateTrade xmlns:cc=urn:decision:AllocateTrade xmlns:xsd=http://www.w3.org/2001/XMLSche ma xmlns:soap=http://schemas.xmlsoap.org/ws dl/soap/ targetNamespace= http://localhost:8082/axis/services/Corti con/AllocateTrade> <definitions xmlns=http://schemas.xmlsoap.org/wsdl/ xmlns:tns= http://localhost:8082/axis/services/Corti con/AllocateTrade xmlns:cc= urn:decision:AllocateTrade w3.org/2001/XMLSchema xmlns:soap=http://schemas.xmlsoap.org/ws dl/soap/ xmlns:wsaw="http://www.w3.org/2006/05/add ressing/wsdl" targetNamespace= http://localhost:8082/axis/services/Corti con/AllocateTrade>
Figure 53 Regular WSDL
Figure 54 .NET WCF WSDL
Decision Service Information Section (WSDL & XSD)

Decision Service-Level
<xsd:complexType name="CorticonRequestType"> <xsd:sequence> <xsd:element name="WorkDocuments" type="tns:WorkDocumentsType" /> </xsd:sequence> <xsd:attribute name="decisionServiceName" use="required" fixed=AllocateTrade type="xsd:string" /> <xsd:attribute name="decisionServiceTargetVersion" use="optional" type="xsd:nonNegativeInteger" /> <xsd:attribute name="decisionServiceEffectiveTimestamp" use="optional" type="xsd:dateTime" /> </xsd:complexType> <xsd:complexType <xsd:complexType name="CorticonRequestType"> <xsd:sequence> <xsd:element name="DecisionServiceName" type="xsd:string" minOccurs="1"/> <xsd:element name="DecisionServiceTargetVersion" type="xsd:nonNegativeInteger" nillable="true"/> <xsd:element name="DecisionServiceEffectiveTimestamp" type="xsd:dateTime" nillable="true"/> <xsd:element name="WorkDocuments" type="tns:WorkDocumentsType" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="CorticonResponseType"> <xsd:sequence>
January 13, 2012

name="CorticonResponseType"> <xsd:sequence> <xsd:element name="WorkDocuments" type="tns:WorkDocumentsType" /> <xsd:element name="Messages" type="tns:MessagesType" /> </xsd:sequence> <xsd:attribute name="decisionServiceName" use="required" fixed=AllocateTrade type="xsd:string" /> <xsd:attribute name="decisionServiceTargetVersion" use="optional" type="xsd:nonNegativeInteger" /> <xsd:attribute name="decisionServiceEffectiveTimestamp" use="optional" type="xsd:dateTime" /> </xsd:complexType>
Page 68
<xsd:element name="DecisionServiceName" type="xsd:string" minOccurs="1"/> <xsd:element name="DecisionServiceTargetVersion" type="xsd:nonNegativeInteger" nillable="true"/> <xsd:element name="DecisionServiceEffectiveTimestamp" type="xsd:dateTime" nillable="true"/> <xsd:element name="WorkDocuments" type="tns:WorkDocumentsType" /> <xsd:element name="Messages" type="tns:MessagesType" /> </xsd:sequence> </xsd:complexType>
Figure 55 Regular WSDL & XSD
Figure 56 .NET WCF WSDL & XSD
Vocabulary-level
<xsd:complexType name="CorticonRequestType"> <xsd:sequence> <xsd:element name="WorkDocuments" type="tns:WorkDocumentsType" /> </xsd:sequence> <xsd:attribute name="decisionServiceName" use="required" type="xsd:string" /> <xsd:attribute name="decisionServiceTargetVersion" use="optional" type="xsd:nonNegativeInteger" /> <xsd:attribute name="decisionServiceEffectiveTimestamp" use="optional" type="xsd:dateTime" /> </xsd:complexType> <xsd:complexType name="CorticonResponseType"> <xsd:sequence> <xsd:element name="WorkDocuments" type="tns:WorkDocumentsType" /> <xsd:element name="Messages" type="tns:MessagesType" /> </xsd:sequence> <xsd:attribute name="decisionServiceName" use="required" type="xsd:string" /> <xsd:attribute name="decisionServiceTargetVersion" use="optional" <xsd:complexType name="CorticonRequestType"> <xsd:sequence> <xsd:element name="DecisionServiceName" type="xsd:string" minOccurs="1"/> <xsd:element name="DecisionServiceTargetVersion" type="xsd:nonNegativeInteger" nillable="true"/> <xsd:element name="DecisionServiceEffectiveTimestamp" type="xsd:dateTime" nillable="true"/> <xsd:element name="WorkDocuments" type="tns:WorkDocumentsType" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="CorticonResponseType"> <xsd:sequence> <xsd:element name="DecisionServiceName" type="xsd:string" minOccurs="1"/> <xsd:element name="DecisionServiceTargetVersion" type="xsd:nonNegativeInteger" nillable="true"/> <xsd:element name="DecisionServiceEffectiveTimestamp" type="xsd:dateTime" nillable="true"/> <xsd:element name="WorkDocuments" type="tns:WorkDocumentsType" /> <xsd:element name="Messages"
January 13, 2012

type="xsd:nonNegativeInteger" /> <xsd:attribute name="decisionServiceEffectiveTimestamp" use="optional" type="xsd:dateTime" /> </xsd:complexType> type="tns:MessagesType" /> </xsd:sequence> </xsd:complexType>
Page 69
Figure 57 Regular WSDL & XSD
Figure 58 .NET WCF WSDL & XSD
PortType Section (WSDL only)

<portType name="AllocateTradeSoap"> <operation name="processRequest"> <input message="tns:CorticonRequestIn" /> <output message="tns:CorticonResponseOut" /> </operation> </portType> <portType name="AllocateTradeSoap"> <operation name="Execute"> <input wsaw:Action="urn:Corticon" name="CorticonMessageRequest" message="tns:CorticonRequestIn" /> <output wsaw:Action="urn:Corticon/CorticonSoap/exe cuteResponse" name="CorticonMessageResponse" message=tns:CorticonResponseOut /> </operation> </portType>
Binding Section (WSDL only)

<binding name="AllocateTradeSoap" type="tns:AllocateTradeSoap"> <soap:binding transport="http://schemas.xmlsoap.org/s oap/http" style="document" /> <operation name="processRequest"> <soap:operation soapAction="urn:Corticon" style="document" /> <input> <soap:body use="literal" namespace="urn:Corticon" /> </input> <output> <soap:body use="literal" namespace="urn:Corticon" /> </output> </operation> </binding> <binding name="CandidatesSoap" type="tns:CandidatesSoap"> <soap:binding transport="http://schemas.xmlsoap.org/soap /http" style="document" /> <operation name="Execute"> <soap:operation soapAction="urn:Corticon" style="document" /> <input name="CorticonMessageRequest"> <soap:body use="literal" namespace="urn:Corticon" /> </input> <output name="CorticonMessageResponse"> <soap:body use="literal" namespace="urn:Corticon" /> </output> </operation> </binding>
January 13, 2012
Page 70
.NET Compatible XML Messaging

When a CorticonRequest document is received, Corticon Server looks for Decision Service info (Decision Service Name, Decision Service Target Version, and Decision Service Effective Timestamp) in two places: As XML attributes of CorticonRequest. If not found then: As XML elements under CorticonRequest. Therefore, any of the following sample CorticonRequests are valid and will be accepted and processed by Corticon Server:
Example 1: Decision Service Name & Target Version as XML Attributes

<CorticonRequest xmlns="urn:Corticon" xmlns:xsi=http://www.w3.org/2001/XMLSchemainstance decisionServiceName="AllocateTrade" decisionServiceTargetVersion=1> <WorkDocuments> </WorkDocuments> </CorticonRequest>
Example 2: Decision Service Name & Target Version as XML Elements

<CorticonRequest xmlns="urn:Corticon" xmlns:xsi=http://www.w3.org/2001/XMLSchemainstance> <DecisionServiceName>AllocateTrade</DecisionServiceName> <DecisionServiceTargetVersion>1</DecisionServiceTargetVersion> <WorkDocuments> </WorkDocuments> </CorticonRequest>
Example 3: Decision Service Name & Effective DateTimeStamp as XML Attributes

<CorticonRequest xmlns="urn:Corticon" xmlns:xsi=http://www.w3.org/2001/XMLSchemainstance decisionServiceName="AllocateTrade" decisionServiceEffectiveTimestamp=2001-12-17T09:30:47.0Z> <WorkDocuments> </WorkDocuments> </CorticonRequest>
Example 4: Decision Service Name & Effective DateTimeStamp as XML Elements

<CorticonRequest xmlns="urn:Corticon" xmlns:xsi=http://www.w3.org/2001/XMLSchemainstance> <DecisionServiceName>AllocateTrade</DecisionServiceName> <DecisionServiceEffectiveTimestamp>2001-1217T09:30:47.0Z</DecisionServiceEffectiveTimestamp> <WorkDocuments> </WorkDocuments> </CorticonRequest>
January 13, 2012
Page 71
INVOKING CORTICON SERVER

The previous chapter discussed the contents of a call to Corticon Server, and what those contents need to look like. This chapter discusses the options available to make the actual call itself, and the types of call Corticon Server can respond to.
METHODS OF CALLING CORTICON SERVER

There are two ways to call Corticon Server: A Web Services (SOAP) request message. A Java method invocation.
SOAP Call
The structure and contents of this message are described in the Integration chapter. Once the SOAP request message has been prepared, a SOAP client must transmit the message to the Corticon Server (deployed as a Web Service) via HTTP. If your SOAP tools have the ability to assemble a compliant request message from a WSDL you generated with the Deployment Console, then it is very likely they can also act as a SOAP client and transmit the message to a Corticon Server deployed to the bundled Apache Tomcat web server. The Tutorial for Corticon Server Deploying Web Services describes one way to test this method of invocation 1. Use a 3rd-party tool or application (like Altova XMLSpy, for example) as a SOAP client. When developing and testing SOAP messaging, its very helpful to use some type of message interception tool 3 that allows you to grab a copy of the request message as it leaves the client and the response message as it leaves Corticon Server. This lets you inspect the messages and ensure no unintended changes have occurred, especially on the client-side.
Java Call
The specific method used to invoke a Decision Service is the execute() method. The method offers a choice of arguments: An XML string, which contains the Decision Service Name as well as the payload data. The payload data must be structured according to the XSD generated by the Deployment Console. Defining this data payload structure to include as an argument to the execute method is the most common use of the XSD service contract. A JDOM XML document, which contains the Decision Service Name as well as the payload data (array).
Such as tcpTunnelUI or TCPTrace
January 13, 2012
Server Integration & Deployment Guide 5.2 The Decision Service Name plus a collection of Java business objects which represent the WorkDocuments. The Decision Service Name plus a map of Java business objects which represent the WorkDocuments.
Page 72
Optional arguments representing Decision Service Version and Effective Timestamp may also be included these are described in the Versioning and Effective Dating chapter of this manual. All variations of the execute() method are described fully in the JavaDoc. These arguments are passed by reference. Vocabulary Term Entity Attribute Association Corresponding Java Construct Java class (JavaBean compliant) Java property within a class Class reference to another class
For example, in the Tutorial for Corticon Studio Basic Rule Modeling, the three Vocabulary entities: FlightPlan, Cargo, Aircraft would be represented by the consumer as three Java classes. Each class would have properties corresponding to the Vocabulary entity attributes (e.g. volume, weight). The association between Cargo and FlightPlan would be handled by Java class properties containing object references; the same would be true for the association between Aircraft and FlightPlan. Note that even if there is only a one-way reference between two classes participating in an association (from FlightPlan to Cargo, for example), if the association is defined as bidirectional in the Vocabulary, rules may be written to traverse the association in either direction. Bidirectionality is asserted by Corticon Server even if the Java association is unidirectional (as most are, due to inherent synchronization challenges with bidirectional associations in Java objects). Use the same testServer.bat (located in <corticon_install_dir>\Server) to see how the execute() method is used with Java objects. In addition to the 6 base Corticon Server jars, the batch file also loads some hard-coded Java business objects for use with the Java Object Messaging options (menu option 28-33 in Figure 7). These hard-coded classes are included in CcServer.jar so as to ensure their inclusion on the JVMs classpath whenever CcServer.jar is loaded. The hard-coded Java objects are intended for use when invoking the OrderProcessing.erf Decision Service included in the default Corticon Server installation.
REQUEST/RESPONSE MODE
Regardless of which invocation method you choose to call Corticon Server, keep in mind that it, by default, acts in a requestresponse mode. This means that one request sent from the client to Corticon Server will result in one response sent by Corticon Server back to the client. Multiple calls may be made by different clients simultaneously, and Corticon Server will assign these requests to
Page 73
different Reactors in the pool as appropriate. As each Reactor completes its transaction, the response will be sent back to the client. Also, the form of the response will be the same as the request: if the request is a web services call (SOAP message), then the response will be as well. If a Java application uses the execute() method to transmit a map of objects, then Corticon Server will also return the results in a map.
ADMINISTRATIVE APIS
In addition to the execute() method (and its variations), a set of administrative APIs allows client control over most Corticon Server functions. These methods are described in more detail in the JavaDoc, CcServerAdminInterface class, including: 1. Adds (deploying) a specific Decision Service onto Corticon Server (addDecisionService) without using a .cdd file. Available in either 3- or 6-parameter versions. 2. Removes all Decision Services which were loaded (deployed) via the addDecisionService method (clearAllNonCddDecisionServices). Does not affect Decision Services deployed via a .cdd file. 3. Queries Corticon Server for admin information such as version number, deployed Decision Service settings, etc. (getCcServerInfo). 4. Queries Corticon Server for a list of loaded (deployed) Decision Service Names (getDecisionServiceNames) 5. Initializes Corticon Server, causing it to start up and restore state from ServerState.xml (initialize) 4 6. Queries Corticon Server to see if a Decision Service Name (or specific version or effective date) is deployed (isDecisionServiceDeployed) 5 7. Instructs Corticon Server to load all Decision Services in a specific .cdd file (loadFromCdd) 8. Instructs Corticon Server to load all Decision Services from all .cdd files located in a specific directory (loadFromCddDir) 9. Changes the auto-reload setting for a Decision Service (or specific version) (modifyDecisionServiceAutoReload). Does not affect Decision Services deployed via a .cdd file. 10. Changes the message structure type setting (FLAT or HIER) for a Decision Service (or specific version) (modifyDecisionServiceMessageStructType). Does not affect Decision Services deployed via a .cdd file. 11. Changes the min and/or max pool settings for a Decision Service (or specific version) (modifyDecisionServicePoolSizes). Does not affect Decision Services deployed via a .cdd file.
4 5
New addition to the API set in eServer 5.1 New addition to the API set in eServer 5.1
January 13, 2012
Page 74
12. Changes the path of a deployed Decision Service (Ruleflow) (modifyDecisionServiceRuleflowPath). Does not affect Decision Services deployed via a .cdd file. 6 13. Instructs Corticon Server to dump and reload (refresh) a specific Decision Service (or version) (reloadDecisionService). 14. Removes (undeploying) a Decision Service (or specific version) (removeDecisionService). Does not affect Decision Services deployed via a .cdd file. 15. Sets Corticon Server Log level (setLogLevel). This is the same Log level that can also be set statically using CcCommon.properties inside CcConfig.jar. All properties files are described in Appendix C. 16. Sets Corticon Server Log path (setLogPath). This is the same Log path that can also be set statically using CcCommon.properties inside CcConfig.jar. All properties files are described in Appendix C. 17. Starts Corticon Servers Dynamic Update monitoring service (startDynamicUpdateMonitoringService). This is the same update service that can also be set statically using CcServer.properties inside CcConfig.jar. All properties files are described in Appendix C. 18. Stops Corticon Servers Dynamic Update monitoring service (stopDynamicUpdateMonitoringService). This is the same update service that can also be set statically using CcServer.properties inside CcConfig.jar. All properties files are described in Appendix C. A Decision Service deployed using a .cdd file may only have its deployment setting changed by modifying the .cdd file. A Decision Service deployed using APIs may only have its deployment settings modified by APIs. All APIs are available as both Java methods (described fully in the JavaDoc) and as operations in a SOAP request message. Corticon provides a WSDL containing full descriptions of each of these methods so they may be called through a SOAP client. When deployed as a Servlet, Corticon Server automatically publishes an Administration Console on port 8082, which among other things, exposes as set of WSDLs. See the next chapter for more details.
New addition to the API set in 5.1

January 13, 2012
Page 75
MONITORING CORTICON SERVER

Business Rule Server Console is an administration utility for monitoring Corticon Server when installed and running on a J2EE application or web server.
LAUNCHING AND LOGGING IN TO SERVER CONSOLE

To launch Server Console, open http://<yourServerURL>:<yourPort>/axis in a web browser. By default, axis.war is installed in the bundled Tomcat, and the default URL is http://localhost:8082/axis. You should see the Server Console login page as shown in Figure 63.
Figure 63 Server Console Login Page
Out of the box, the Console includes 2 user accounts: User Name
admin <empty>
Password
admin <empty>
Access Rights read and write read-only
Access Rights Code

RW R
Table 3 Default User Accounts
January 13, 2012
Page 76
To add, modify, or delete user accounts, open serverconsole-user.xml in a text editor and update accordingly. This file is located in the \axis\WEB-INF directory of your web server. In the bundled Tomcat Windows installation, this location is <corticon_install_dir>\Apache\webapps\axis\WEB-INF. The XML description corresponding to the default accounts is shown in Figure 64.
Figure 64 serverconsole-user.xml
If you login using the <empty> account, or if you choose the Limited Access login option, your use of the Server Console will be limited to read-only mode. In this mode, you will not be able to deploy Decision Services or configure or monitor the Server. If you try to view the Deploy Decision Service, Configure Rules Server, or Monitor Rules Server pages (see below), you will receive a message similar to User does not have rights to deploy a new Decision Service or User does not have rights to view Server settings.
CONSOLE MAIN MENU PAGE

Following a successful login, you should see the Server Console Main Menu page.
January 13, 2012
Page 77
Figure 65 Server Console Main Menu Page
The lower right corner of the Main Menu page also contains icons corresponding to several of the menu options: Icon Description Turn on Server Console display refresh. If enabled, Console will update its display every 4-5 seconds. While making changes to Console page settings, you may want to turn off refresh, otherwise your entries may be wiped out (before you have a chance to save them) when the Console refreshes. Turn off Server Console display refresh. While making changes to Console page settings, you may want to turn off refresh, otherwise your entries may be wiped out (before you have a chance to save them) when the Console refreshes. Go to the Decision Service page. Go to the Deploy Decision Service page. Go to the Configure Rules Server page. Go to the Monitor Rules Server page.
January 13, 2012
Server Integration & Deployment Guide 5.2 Go to the Main Menu page.
Page 78
DECISION SERVICES PAGE

Clicking the Decision Services option from the Home page (or from the icon bar) displays the Decision Services currently deployed to the Corticon Server instance monitored by Server Console.
Figure 66 the Decision Services Page
The table displayed on the Decision Services page contains the following information and controls:
Service Name
This is the name assigned to a deployed Decision Service, whether deployed by a .cdd file, or by data manually entered on the Deploy Decision Service page. When assigned via a .cdd file, the name is entered as the Decision Service Name in the Deployment Console. In Server Console, the Service Names are hyperlinks, which, when clicked, display additional information about the deployment properties of the Decision Service. Clicking the Service Name hyperlink displays 4 tabs:
January 13, 2012
Server Integration & Deployment Guide 5.2 Overview Tab
Page 79
If the Decision Service was deployed by a .cdd file, then the contents of the .cdd are displayed on this page. If the Decision Service was deployed by the Deploy Decision Service page, then the information entered on that page (which is persisted in serverstate.xml) is displayed. The information displayed on the Overview page, shown in Figure 67, is collected from 3 sources: from the .cdd file or from the information entered in the Deploy Decision Service page (depending on how the Decision Service was deployed). In both cases, the information reflects the state of the Decision Service at the time of deployment. the Ruleflow file (.erf) itself, either from file DateTime stamps or from properties set in the Rule Set>Properties menu of Corticon Studio. real-time/dynamic retrieved from Corticon Server Console. For example Pool Settings|Available/Total Instances in Pool reflects the current Reactor pool status for that Decision Service. The number of Reactors available and total, will change as Corticon Server grows/shrinks each Decision Services pool to handle demand. For more information about Reactor pools, see Pool Size and Optimizing Pool Size.
January 13, 2012
Page 80
Figure 67 Overview Tab
Another feature of the Overview tab allows Server Console users with RW access to perform limited management and updates to the deployed Ruleflows and constituent Rulesheets. Since this is fundamentally a rule modeling activity, it is addressed in the Rule Modeling Guide. Service Configuration Tab Available only to users with RW access. If the selected Decision Service was deployed by a .cdd file, then deployment properties cannot be changed on this tab they must be changed in the .cdd file itself. See the Deploying Corticon Ruleflows chapter for more information about .cdd files and the Deployment Console.
January 13, 2012
Server Integration & Deployment Guide 5.2 If the Decision Service was deployed by the Deploy Decision Service page, then the deployment properties can be changed on the Service Configuration tab using the Update button. Also, use Update to re-deploy changes to a Decision Service.
Page 81
Monitored Attribute and Analysis Buckets: Server Console allows you to monitor specific attributes in a deployed Decision Service. By choosing attributes to monitor, you can view the statistical breakdown of attribute values over the course of many Decision Service executions. For example, the Ruleflow created in the Basic Rule Modeling Guide assigns values such as pallet and container to attribute Cargo.packaging. To monitor this attribute, enter the fully qualified attribute name (including the entity) in the Monitored Attribute box (shown in the blue box in Figure 68 below) and enter the exact value or values in the Analysis Buckets box (separated by a comma) as shown in the orange box in Figure 68 below.
Figure 68 Service Configuration Tab: Monitoring Attributes
After entering your attribute and values, click Add to add them to the monitored list. The results of attribute monitoring can be viewed in the Distribution Chart tab, described below.
January 13, 2012
Server Integration & Deployment Guide 5.2 Rules Report Tab
Page 82
Rulesheet reports can be generated directly from this tab. See the Rule Modeling Guide for more information about Corticon Studios reporting framework. Detailed reports display all elements of the Rulesheet, including Scope, Filters, and other sections. Rule Statements reports display only those Rule Statements entered for rules. If a rule has no Rule Statement, then that rule will not appear in this report style. Business Friendly reports display the Natural Language equivalents (if present) of the rules. Test Execution Tab If you have a compliant Corticon Request XML message file, then you can use this tab to send it to Corticon Server and view its Response. Navigate to the XML message file using the Browse button, then click Execute Test to invoke Corticon Server. To be compliant, your XML Request message must follow the same rules as described in Path 2 in the Server Deployment Tutorial.
Version
This indicates the Version number of the Decision Service deployed. A Decision Services version number is set in the Rule Set>Properties menu option of Studio for each Ruleflow (.erf file). See Decision Service Versioning and Effective Dating in this manual, and the Rule Modeling Guide for more information.
Live
This column indicates the deployment status of the Decision Service. If deployed and ready to receive invocations, the Live checkbox will be checked. If a new version of a Decision Service has been created using the Overview tab, then it will not become live until promoted. This process is described in more detail in the Rule Modeling Guide.
Deployed from CDD

This column indicates if a Decision Service has been deployed from a .cdd file (Yes) or from the Deploy Decision Service page (No/Remove). Notice that No/Remove is hyperlinked, indicating that a Decision Service deployed using Server Console (from the Deploy Decision Service page) can also be removed from within Server Console by clicking the link. Decision Services deployed from a .cdd can only be removed by editing or removing the .cdd. Decision Services deployed via the Server Console update the serverState.xml file. Likewise, if a Decision Service is removed using the No/Remove hyperlink, then its corresponding entry is removed from serverState.xml.
January 13, 2012
Page 83
Dynamic Reload
Indicates if Corticon Servers maintenance thread will watch for changes to the Decision Service and refresh the pool if updates are detected. For Decision Services deployed via .cdd, this option is set in the Dynamic Reload field of the Deployment Console. If deployed via the Deploy Decision Service page of Server Console, Dynamic Reload is automatically Yes.
Executions
The number of times the Decision Service has executed since statistics were last cleared. This number is a hyperlink which, when clicked, display two additional tabs. Performance Tab The Decision Service Performance Monitoring Service and Decision Service Time Interval Performance Analysis Service must be On for this feature to work. To turn these services On, go to the Configure Decision Service page, Decision Service Options tab. The top graph displays average execution time for all executions performed within Server Consoles recording interval. The lower graph displays the number of executions performed within Server Consoles recording interval. Server Consoles recording interval is 10 seconds by default, but can be changed in CcServer.properties.
January 13, 2012
Page 84
Figure 69 Performance Tab: Execution Ave. Time & Count Graphs
Distribution Chart Tab The Decision Service Results Distribution Analysis Service must be On for this feature to work. To turn On, go to the Configure Decision Service page, Decision Service Options tab. This tab displays a pie chart of the distribution of values of attributes monitored in the Service Configuration tab.
January 13, 2012
Page 85
Figure 70 Distribution Chart Tab: Results of Monitored Attributes
Avg Time (ms)

The Decision Service Performance Monitoring Service must be On for this feature to work. To turn this service On, go to the Configure Decision Service page, Decision Service Options tab. The amount of time, on average, required by the Decision Service to execute. This number is also a hyperlink which, when clicked, display the Performance and Distribution Chart tabs.
Clear Stats
Clicking Clear resets Execution, Average Time, Performance and Distribution Chart data. This option is available only to users with RW access.
DEPLOY DECISION SERVICE PAGE

This page, including all options and tabs, is available only to users with RW access. Clicking the Deploy Decision Service option from the Home page (or from the icon bar) displays a page which enables you to deploy Decision Services directly from Server Console, instead of using the Deployment Console to create a .cdd file. Server Console uses standard Server APIs to perform the deployment. To deploy Decision Services from the Server Console, you must use the pre-compile option in the Deployment Console to create an .eds file. Only an .eds file can be deployed using Server Console. Only an .eds file can be deployed using Server Console.
January 13, 2012
Page 86
Server State
In many prior versions of Corticon Server (4.2 and earlier), Decision Services deployed via APIs remained deployed only for the duration of Corticon Servers session. If Corticon Server (or its host container) was stopped and restarted, Decision Services deployed previously by APIs would NOT redeploy automatically until those APIs were called again. Decision Services deployed via .cdd files, however, would redeploy automatically. In Corticon Server 5.2, the deployment state of all Decision Services, regardless of how deployed, is persisted in a new file named ServerState.xml, located in \axis\CcServerSandbox\DoNotDelete. The Deploy Decision Service page captures the same deployment information as a .cdd, and stores it in the ServerState.xml file. These fields are described in the Deploying Corticon Ruleflows chapter above. One exception: to update a Decision Service, we assume youll change the Ruleflows compiled.eds file and then redeploy using the Service Configuration tabs Update button. Therefore, a Dynamic Reload setting isnt necessary. When Corticon Server restarts, it reads the ServerState.xml file and redeploys any Decision Services included in it.
Figure 71 Deploy Decision Service Page
To use this page, you must pre-compile your .erf file into an .eds file, and use the in the Rule Set (path) field above. You cannot directly deploy uncompiled .erf files via Server Console. Enter the required deployment information in the provided boxes, and click Deploy.
January 13, 2012
Page 87
Once deployed, Corticon Server creates a local copy of the .eds file in its local CcServerSandbox directory structure. The location path can be seen in the ServerState.xml file in Figure 72 below. It does this so that it always has access to the executable code (stored inside the .eds file) when it attempts to reload/redeploy the Decision Service. If you want to change the Ruleflow, we recommend using the Update button on the Service Configuration tab of the Decision Service page. We dont recommend editing the local copy of the .erf file because the two files will not be identical. Using the Update method ensures the original and local copies are always the same.
Figure 72 ServerState.xml showing Local Storage of Deployed Decision Service
All other entries in the Deploy Decision Service page are visible above in the <NonCDDs> section of the document.
CONFIGURE RULE SERVER

Clicking the Configure Rule Server option from the Home page (or tabs. from the icon bar) displays 4
Logging Tab
The Logging tab displays the current settings of LogPath and LogLevel properties. These properties are stored in CcCommon.properties, but can be overridden with values entered on this tab. The new values are written to ServerState.xml and take effect each time Corticon Server is started.
Deployment Directory Tab

The Deployment Directory tab displays the current value of the autoloaddir property. This property is stored in CcServer.properties, but can be overridden with a path entered on this tab. The new value is written to ServerState.xml and takes effect each time Corticon Server is started.
January 13, 2012
Page 88
Decision Service Options Tab

Server Console provides control of 4 services on this tab. After selecting a service option (On or Off), be sure to click Update to write the new values to ServerState.xml. Users with R access can view the current setting of these 4 services, but only users with RW access can change them. By default, the last three options are Off. Decision Service Automatic Update Service This service, also known as the Dynamic Update Monitoring Service, is performed by Corticon Servers maintenance thread. The com.corticon.ccserver.dynamicupdatemonitor.autoactivate property in CcServer.properties maintains the permanent value of this property, but it can also be controlled during Corticon Servers session via this Server Console option. The option chosen is recorded in ServerState.xml. Decision Service Performance Monitoring Service This service is responsible for generating the Executions and Avg Time (ms) values displayed on the Decision Services page, as well as the Execution Averages and Execution Count graphs on the Performance tab. The option chosen is recorded in ServerState.xml. Decision Service Time Interval Performance Analysis Service This service is responsible for tracking and recording the time intervals across which other services operate. If this service is off, then the Performance Monitoring Service will not be able to display the data it collects because much of it is shown as averages over time. Generally, you will want to activate or deactivate both this and the Performance Monitoring service. The option chosen is recorded in ServerState.xml. Decision Service Results Distribution Analysis Service This service is responsible for tracking and recording the attribute values you designated in the Decision Services pages Service Configuration tab. The option chosen is recorded in ServerState.xml.
License Tab
The values shown are decrypted from the CcLicense.jar currently in use by the running instance of Corticon Server. Licensed To and Deactivate Date are two important fields.
MONITOR RULES SERVER PAGE

Clicking the Monitor Rule Server option from the Home page (or
from the icon bar) displays 4 tabs.

January 13, 2012
Page 89
Rules Server Stats Tab

This tab displays a summary view of basic Corticon Server information, including version/build, total number of Decision Services deployed, session start time, and uptime duration.
Rules Server Settings Tab

This tab displays a view of many of the property settings maintained in CcConfig.jar (see Appendix C for more information about this file). If a property setting (such as logLevel) has been overridden by a setting in Server Console (and persisted in ServerState.xml), then the Server Console value is displayed. The list of properties displayed on this tab is controlled by CcServerConsoleProperties.properties, which is located in Server\Tomcat\webapps\axis\WEB-INF in your Corticon Server installation directory.
Environment Settings Tab

This tab displays basic information about host operating system, application server, and Java virtual machine (JVM). This information may be useful to Progress technical support in the event you need to contact us.
Memory Utilization Tab

This tab displays a graph of JVM memory utilization. This graph will help you understand if Corticon Servers host environment is under-resourced, and may also be useful to Progress technical support in the event you need to contact us about memory problems.
Rules Server Log

This tab reads and displays lines from the current Server log file. This tab allows you to read recent log entries without having direct access to the log file itself.
WSDLS
This page provides access to WSDL files for all Corticon Server APIs. In some prior versions of Corticon Server (4.2 and earlier), this page was accessible via the Axis home page (http://<yourServer>:<yourPort>/axis). In version 4.3 and later (including 5.2), this URL is now used as the home address for Server Console. You also can access this page directly (external of the Console) by using this address: http://<yourServer>:<yourPort>/axis/servlet/AxisServlet
January 13, 2012
Page 90
CONFIGURING CORTICON SERVER

There are five property files used by Corticon Business Rules Management software, as shown in the table below. Corticon Business Rules Management uses property files to control most userconfigurable behaviors in Studio, Server and Deployment Console. Property files are just text files that are automatically read when Server or Deployment Console are started. They are contained within Server\Lib\CcConfig.jar in your Corticon Server installation directory. When installed on the bundled Tomcat web server, CcConfig.jar is also installed in Server\Tomcat\webapps\axis\WEB-INF\lib. Its important to use the CcConfig.jar that is controlling your instance of Server. A common mistake is to change the CcConfig.jar inside the Server\Lib, directory of your Corticon installation directory, but then expect it to control the instance of Server running under Server\Tomcat\webapps\axis\WEB-INF\lib in your Corticon installation directory. It wont. The values of the properties within these files can be changed by editing them directly with a text editor. Once an instance of Corticon Server is running, some properties can be modified via API method calls, as was discussed in the Administrative API section above. Be sure to shutdown or exit Studio, Server and Deployment Console before making changes to these properties, and then restart for the changes to take effect. Property File Name CcCommon.properties Usage Modifies the behavior of elements common to both the Corticon Business Rules Modeling Studio and Business Rules Server. Modifies behavior of the Corticon Deployment Console. Modifies behavior of Corticon Studio. Used to re-brand Corticon components for certain OEM customers. These properties are not described here because end users have no need to modify them. Influences how Corticon Server operates.
CCDeployment.properties CcStudio.properties CcOem.properties
CcServer.properties
Figure 73 - Corticon Business Rules Management Property Files and Purposes
The most commonly changed properties are summarized in this chapter. For a complete description of all properties, see Appendix C.
January 13, 2012
Page 91
MOST COMMON PROPERTY CHANGES

The most common changes to property files and their default values are summarized below.
Log Location
logpath=%CORTICON_HOME%/Log
Set in CcCommon.properties. This path determines where Corticon Server log file is deposited. By default, %CORTICON_HOME% is set to <corticon_install_dir>\Server\Tomcat\CcServer.
Log Level
loglevel=VIOLATION
Set in CcCommon.properties. This property controls the amount of information included in Corticon Servers log file. Options:
DEBUG To be used only at the direction of Progress technical support. Never deploy Corticon Server in production with loglevel set to DEBUG. Log files created
in this mode may become very large and slow down Corticon Servers performance by orders of magnitude.
INFO All messages except debugging messages are logged. Never deploy Corticon Server in production with loglevel set to INFO. Log files created in this mode may
become very large and slow down Corticon Servers performance by orders of magnitude.
RULETRACE Logs rule firings and performance data. Do not deploy Corticon Server in production with loglevel set to RULETRACE. While log files are not nearly as large as those generated in DEBUG or INFO modes, they still require time
to write, and therefore slow Corticon Servers performance.

VIOLATION Only Exceptions are logged. Recommended for deployment because
it maximizes Corticon Server performance. Default.
Automatic Decision Service Reload

Set in CcServer.properties. Corticon Server runs a background maintenance thread which checks for changes to deployed Decision Services or the Deployment Descriptor files that control their deployment settings. For each Decision Service whose Dynamic Reload deployment setting is Yes, the maintenance thread will periodically inspect that Ruleflows timestamp and determine if a newer version is available (based on the last-saved timestamp assigned by the OS). If it is, then the maintenance thread will flush idle Reactors from Corticon Servers pool and reload it with updated Reactors. The maintenance thread checks for:
January 13, 2012
Page 92
Changes to any .cdd loaded to Corticon Server by a loadFromCdd or loadFromCddDir API call, including new or removed Decision Services and changes to settings of deployed Decision Services. Changes to any .cdd file (including new .cdds within the Deployment Descriptor directory) by a loadFromCddDir API call, including new or removed Decision Services and changes to settings of deployed Decision Services. Changes in any of the Decision Services loaded to Corticon Server. This is done via a compilation timestamp check.
This maintenance thread is enabled by default in CcServer.properties, but it can be disabled using
com.corticon.ccserver.dynamicupdatemonitor.autoactivate=false
The periodicity of the maintenance threads inspection is controlled in CcServer.properties by:

com.corticon.ccserver.serviceIntervals=30000
The maintenance thread can be shutdown and restarted dynamically using the Administrative APIs:
CcServerAdminInterface.stopDynamicaUpdateMonitoringService() CcServerAdminInterface.startDynamicUpdateMonitoringService()
January 13, 2012
Page 93
INSIDE CORTICON SERVER

This section describes how Corticon Server operates. The topics illustrate the enterprise-readiness of Corticon Server.
THE BASIC PATH

Client applications (consumers) invoke Corticon Server, sending a data payload as part of a request message. The invocation of Corticon Server can be either indirect (such as when using SOAP) or direct (such as when making in-process Java calls). This request contains the name of the Corticon Decision Service (the Decision Service Name assigned in the Deployment Descriptor file see Deployment Console section) that should process the payload. Corticon Server matches the payload to the Decision Service and then commences execution of that Decision Service. One Corticon Server can manage multiple different Decision Services, which may each reference different Vocabularies.
RULEFLOW COMPILATION THE .EDS FILE

Unlike in previous versions, Ruleflows in 5.2 are compiled on-the-fly during Ruleflow deployment or Corticon Server startup. Ruleflows are not compiled during the .ers or .erf save process in Studio. When Corticon Server detects a new or modified Ruleflow (.erf file) referenced in a Deployment Descriptor file (.cdd) or addDecisionService() API call, it compiles the .erf into an executable version, with file suffix .eds. These new .eds files are stored inside the Sandbox:
<corticon_install_dir>\Server\Tomcat\CcServer\CcServerSandbox\DoNotDelete\De cisionServices. Once a Decision Service has been compiled into an .eds file, the regular Corticon Server maintenance thread takes over and loads, unloads, and recompiles deployed .erf files as
required. If you want to pre-compile Ruleflows into .eds files prior to deployment on Server, the Pre-Compile option in the Deployment Console enables this. See the Deployment chapter for more details.
MULTI-THREADING AND CONCURRENCY REACTORS AND SERVER POOLS

Corticon Server has the ability to create multiple copies (instances) of a deployed Decision Service and execute them simultaneously in a multi-threading environment. An instance of a deployed Decision Service in the Corticon Server pool awaiting consumption by an incoming request is called a Reactor. Each incoming request is processed in its own thread of execution. That is, each Reactor runs in a separate thread. Corticon Server does not create threads or perform thread management 7. Rather, the thread of execution is the one assigned by the enclosing container that receives the request (i.e.,
7
Exception: A maintenance thread is created at Corticon Serverstartup time. This thread does not interact with clients of the Corticon Server. Its sole job is to scan for changes in the Ruleflow (or their included Rulesheet files) for dynamic reload purposes.
January 13, 2012
Page 94
SOAP Servlet or Java Servlet in a web server, EJB in a J2EE application server). In the case where an inprocess Java call is made from a client application, the thread of execution is the same one in which the client runs. All requests, regardless of source, resolve to an execute() API method call to Corticon Server. The execute() method associates the incoming request to the compiled code of the requested Decision Service (the .eds file). For example, if a Decision Service named processLoan.erf is configured with a maximum pool size of 10, then the Corticon Server can create up to 10 Reactors of this Decision Service to handle up to 10 simultaneous requests for that service. If, after processing these 10 requests, subsequent concurrent demand is less than 10, the Corticon Server will reduce the pool size accordingly to release working memory. The period of time elapsed before these inactive Reactors are released is set by property com.corticon.ccserver.inactivity in CcServer.properties. Note that the Corticon Server does not actually force the JVMs garbage collection to clean up it simply notifies the JVM that garbage collection may be performed and the JVM triggers it according to its own processes. Released Reactors are swept up by garbage collection when the JVM performs it. On the other hand, if 15 simultaneous requests for processLoan.erf are received, then Corticon Server will spawn Reactors to handle the demand until its maximum pool size limit for that Decision Service is reached. After the limit is reached, additional requests will be queued until a Reactor finishes a request and becomes available for assignment to a queued request. Requests will stay in queue until a) a Reactor becomes available, or b) the Corticon Servers queue timeout is reached, whichever comes first. The Corticon Servers queue timeout is set by property com.corticon.ccserver.timeout in CcServer.properties. Pool sizing is set at the Decision Service level in the Deployment Descriptor file (.cdd). See the Deployment Console section for details on setting the pool size in a .cdd file. Pool size parameters are also contained in addDecisionService() API method described here.
STATE
Reactor State
A Reactor is an executable instance of a deployed Ruleflow/Decision Service. Corticon Server acts as the broker to one or more Reactors for each deployed Ruleflow. During Ruleflow execution, the Reactor is a stateless component, so all data state must be maintained in the message payloads flowing to and from the Reactor. If a deployed Ruleflow is composed of multiple Rulesheets, state is preserved across those Rulesheets as the Rulesheets successively execute within the Ruleflow. However, no interaction with the client application occurs between or within Rulesheets. After the last Rulesheet within the Ruleflow is executed, the results are returned back to the client as a CorticonResponse message. Upon sending the CorticonResponse message, the Reactor is released and returned to the Server pool, awaiting assignment of a new, incoming CorticonRequest thread of execution.
January 13, 2012
Page 95
As an integrator, you must keep in mind that there are only two ways for you to retain state upon completion of a Ruleflow or Decision Service execution. 1. Receive and parse the data from within the CorticonResponse message. In the case of integration Option 1 or 2, the data is contained in the XML document payload or string/JDOM argument. In the case of Option 3, the data consists of Java business objects in a collection or map. 2. Persist the results of a Decision Service execution to an external database. Once a Decision Service execution has completed, the Reactor itself does not remember anything about the data it just processed. After the CorticonResponse message is sent, the Reactor is returned to the pool in preparation for the next transaction (the next CorticonRequest).
Corticon Server State

Although data state is not maintained by Reactors from transaction-to-transaction, the names and deployment settings of Decision Services deployed to Corticon Server are maintained 8. A file named ServerState.xml, located in <corticon_install_dir>\Server\Tomcat\CcServer\CcServerSandbox\DoNotDelete, maintains a record of the Ruleflows and deployment settings currently loaded on Corticon Server. If Corticon Server inadvertently shuts down, or the container crashes, then this file is read upon restart and the prior Server state is reestablished automatically. A new API method initializes Corticon Server and forces it to read the ServerState.xml file. If the file cannot be found, then Corticon Server initializes in an empty (unloaded) state, and will await new deployments. Initialize() need only be called once per Server session - subsequent calls in the same session will be ignored. If other APIs are called prior to calling initialize(), Server will call initialize() itself first before continuing. Turning Off Server State Persistence By default, Corticon Server automatically creates and maintains the ServerState.xml document during normal operation, and reads it during restart. This allows Corticon Server to recover its previous state in the event of an unplanned shutdown (such as a power failure or hardware crash). However, Corticon Server can also operate without the benefit of ServerState.xml, either by not reading it upon restart, or by not creating/maintaining it in the first place. In this mode, an unplanned Corticon Server shutdown and restart results in the loss of any settings made through the Corticon Server Console. For example, any properties settings made or .eds files deployed using the Console will be lost. If an autoloaddir property has been set inside CcConfig.jar, Corticon Server will still attempt to read .cdd files and load their .erf files automatically. To enable or disable creation of the ServerState.xml document, use the com.corticon.server.serverstate.persistchanges property located in CcServer.properties.
This is a new feature in Corticon Server5.1 and operates differently than in other Corticon BRMS versions.
January 13, 2012
Server Integration & Deployment Guide 5.2 to allow/prevent Corticon Server reading ServerState.xml, use the com.corticon.server.serverstate.load property, also located in CcServer.properties.
Page 96
You can customize Corticon Servers state and restart behavior by combining these two property settings:
serverstate. persistchanges true serverstate. load true
Server Restart Behavior Server maintains ServerState.xml during operation, and automatically reads it upon restart to restore to the old state. Server maintains ServerState.xml during operation, but does NOT automatically read it upon restart. New Server state upon restart is unaffected by ServerState.xml. This allows a system administrator to manually control state restoration from the ServerState.xml, if desired. Server attempts to read ServerState.xml upon restart, but finds nothing there. No old state restored. no ServerState.xml document exists, and Server does not attempt to read it upon restart. No old state restored.
true
false
false false
true false
DYNAMIC DISCOVERY OF NEW OR CHANGED DECISION SERVICES

The location of the Deployment Descriptor file(s) is identified using the loadFromCdd() or loadFromCddDir() API methods, which may be included in a deployment wrapper class (Servlet, EJB, etc) or directly invoked from a client. See Telling the Server Where to find Deployment Descriptor Files for more details. A Deployment Descriptor file, in turn, contains the location of each available Decision Service. As new Decision Services are added, the Corticon Server periodically checks to see if the Deployment Descriptor files have changed or if new ones have been added. If so, the Corticon Server updates the pool for the new or modified Decision Service(s). The frequency of this check is controlled by property com.corticon.ccserver.serviceIntervals in CcServer.properties. The default value is 30 seconds. Alternatively, an API call to the Corticon Server can directly load new Decision Services (or sets of Decision Services). The dynamic update monitor starts automatically by default but may be shut off by setting com.corticon.ccserver.dynamicupdatemonitor.autoactivate in CcServer.properties to false.
January 13, 2012
Page 97
REPLICAS AND LOAD BALANCING

In high-volume applications, enterprises typically deploy replicas of their web application servers across multiple CPUs. The Corticon Server, as a well-behaved Java service, can be distributed across these replicas. Additional Corticon Server licenses may be necessary to support such a configuration. A variety of means exist in modern architectures to spread the incoming workload across these replicas. These include special load balancing servers, clustering features within J2EE application servers, and custom solutions.
EXCEPTION HANDLING
Should an exception occur, the Server throws Java exceptions. These are documented in the JavaDoc.
January 13, 2012
Page 98
DECISION SERVICE VERSIONING AND EFFECTIVE DATING

Corticon Server can execute Decision Services according to the version desired or the date of the request. This chapter describes how the Version and Effective/Expiration Date parameters, if set, are processed by the Corticon Server during Decision Service invocation. Assigning Version and Effective/Expiration Dates to a Ruleflow is described in the Quick Reference Guide and the Rule Modeling Guide.
DEPLOYING DECISION SERVICES WITH IDENTICAL DECISION SERVICE NAMES

Ordinarily, all Decision Services deployed to a single Corticon Server must have unique Decision Service Names. This enables the Corticon Server to understand the request when external applications and clients invoke a specific Decision Service by its name. A Decision Services Name is one of the parameters defined in the Deployment Console and included in a Deployment Descriptor file (.cdd). If Java APIs are used in the deployment process instead of a Deployment Descriptor file then Decision Service Name is one of the arguments of the addDecisionService() method. See Ruleflow Deployment for a refresher. However, the Decision Service Versioning and Effective Dating feature makes an exception to this rule. Decision Services with identical Decision Service Names may be deployed on the same Corticon Server if and only if: They have different Major version numbers; or They have same Major but different Minor version numbers; or They have different effective or expiration dates.
To phrase this requirement differently, Decision Services deployed with the same Major Version and Minor Version number and same Effective/Expiration Dates must have different Decision Service Names. The Deployment Console shown in Figure 93, below, displays the parameters of a Deployment Descriptor file with three Decision Services listed.
January 13, 2012
Page 99
Figure 93 - Deployment Console with 3 Versions of a Decision Service
Notice: All three Decision Service Names are the same: skydiver4. All three Ruleflow filenames are the same: skydiver4.erf. Each Ruleflow deploys a different Rulesheet. Each Rulesheet has a different file name, as shown on the following pages. The file locations (paths) are different for each Ruleflow. This is an operating system requirement since no two files in the same directory location may share a filename. All three Decision Services have different (Major) Version numbers. All three Decision Services have different combinations of Effective and Expiration dates.
It is also possible to place all Ruleflow files (.erf) in the same directory location as long as their filenames are different. Despite having different Ruleflow filenames, they may still share the same Decision Service Name as long as their Version or Effective/Expiration Dates are different.
SAMPLE RULEFLOWS
The Ruleflows well use in this section are based on Rulesheet variations on the same simple theme. Notice that the only difference between the three Rulesheets is the threshold for the age-dependent rules (columns 2 and 3 in each Rulesheet). The age threshold is 35, 45, and 55 for Version 1, 2 and 3, respectively. Although simple, this difference will be sufficient to illustrate how the Corticon Server distinguishes Versions in runtime. Figure 94, below, displays the sample Vocabulary we will be using in support of our Version examples.
January 13, 2012
Page 100
Figure 94 - Sample Vocabulary for Version Examples
Figure 95 Rulesheet skydiver4.ers (version 1)
January 13, 2012
Page 101
Figure 96 Rulesheet skydiver4.ers (version 2)
Figure 97 Rulesheet skydiver4.erf (version 3)
Well use the default Tomcat web server included with Corticon Server installation. We recommend you complete the Tutorial for Corticon Server Deploying Web Services and the prior sections of this manual before proceeding. Once Corticon Server is started and reads the Deployment Descriptor file, the Decision Services are deployed. In order to confirm the deployment, well use the testServerAxisTomcat.bat file (as we did in Testing Decision Services). Selecting Option 22 - Get Decision Service Names, we see:
January 13, 2012
Page 102
Figure 98 - Confirming Deployment of Decision Service skydiver4
Notice that the Decision Service skydiver4 shows up only once in the list, even though there are actually three different versions of this Decision Service deployed and loaded on Corticon Server. This is normal Corticon Server summarizes all deployed versions of the Decision Service as a single entry on the list, even though each entry on the list may have multiple versions. Dont think of these different versions as three different Decision Services think of them as three versions of the same Decision Service.
INVOKING A DECISION SERVICE BY MAJOR VERSION NUMBER

Both Corticon Server invocation mechanisms, SOAP request message and Java method, contain a way to specify Decision Service Major Version. Decision Services cannot be invoked by Minor Version number. If two Decision Services are deployed with the same Major version number, then Corticon Server will execute the highest Minor Version number.
Specifying a Major Version in a SOAP Request Message

Please refer to Appendix A for full details of the XML service contracts supported (XSD and WSDL). In the CorticonRequest complexType, notice:
<xsd:attribute name="decisionServiceTargetVersion" use="optional" type="xsd:nonNegativeInteger" /
In order to invoke a specific Major Version of a Decision Service, the Major Version number must be included as a value of the decisionServiceTargetVersion attribute in the message sample above. As the use attribute indicates, specifying a Major Version number is optional. If multiple Major Versions of the same Decision Service Name are deployed simultaneously and an incoming request fails to specify a particular Major Version number, then Corticon Server will execute the Decision Service with highest Version number.
January 13, 2012
Page 103
If multiple instances of the same Decision Service Name and Major Version number are deployed and an incoming request fails to specify a particular Major Version number, then Corticon Server will execute the Decision Service with highest Minor Version number. Lets try a few invocations using variations of the following message:
Figure 99 - Sample Request Message for Decision Service Version 1
Figure 100 - Response Message from Decision Service Version 1
Notice from the posted message that the age threshold is 35, which corresponds to that in Major Version 1 of the Decision Service (refer back to Figure 95). This should be no surprise we specifically
Page 104
requested Major Version 1 in our request message. Corticon Server has obeyed our request. The Major Version number of the executed Decision Service has been returned in the response message in the version attribute of the <Messages> complexType. This location, along with the age threshold, is shown circled in Figure 100. Now, lets modify our request message to specify Version 2, and resend.
Figure 101 - Sample Request Message for Decision Service Version 2
The Major Version change is shown circled in Figure 101, above.
January 13, 2012

Figure 102 - Response Message from Decision Service Version 2
Page 105
Once again, Corticon Server has obeyed our request and executed Version 2 of the Decision Service. The location in the response message of the Decision Service Version executed is shown circled in Figure 102, above. The age threshold of 45, which is another clue that Version 2 has been executed, is also circled in Figure 102.
Specifying Version in a Java API Call

A version of the execute() method exists which contains an extra argument for a specified Decision Service Version:
execute(String astrDecisionServiceName, Collection acolWorkObjs, int aiDecisionServiceTargetVersion)
where:
astrDecisionServiceName is the Decision Service Name String value. acolWorkObjs is the collection of Java Business Objects the date payload. aiDecisionServiceTargetVersion is the Integer Version number.
More information on this variant of the execute() method may be found in the JavaDoc.
Default Behavior
How does Corticon Server respond when no decisionServiceTargetVersion is specified in a request message? In this case, Corticon Server will select the highest Major Version number available for the requested Decision Service and execute it.
INVOKING A DECISION SERVICE BY DATE

When multiple Major Versions of a Decision Service also contain different Effective and Expiration Dates, we can also instruct Corticon Server to execute a particular Decision Service according to a date specified in the request message. This specified date is called the Decision Service Effective Timestamp. How Corticon Server decides which Decision Service to execute based on the Decision Service Effective Timestamp value involves a bit more logic than the Major Version number. Lets use a graphical representation of the three Decision Service Effective and Expiration Date values to first understand how they relate.
January 13, 2012
Page 106
Figure 103 - DS Effective and Expiration Date Timeline
From study of the example above, we see that our three deployed Decision Services have Effective and Expiration dates that overlap in several date ranges: Version 1 and Version 2 overlap from July 1, 2005 through December 31, 2005. And Version 3 overlaps with both 1 and 2 in July 2005. To understand how Corticon Server resolves these overlaps, well invoke Corticon Server with a few scenarios.
Specifying Decision Service Effective Timestamp in a SOAP Request Message

As with decisionServiceTargetVersion, the CorticonRequest complexType also includes an optional decisionServiceEffectiveTimestamp attribute. This attribute (again, were talking about attribute in the XML sense, not the Corticon Vocabulary sense) is included in all service contracts generated by the Deployment Console - please refer to Appendix A for full details of the XML service contracts supported (XSD and WSDL). The relevant section of the XSD is shown below:
<xsd:attribute name="decisionServiceEffectiveTimestamp" use="optional" type="xsd:dateTime" />
Updating CorticonRequest with decisionServiceEffectiveTimestamp according to the XSD, our new XML payload appears as shown in Figure 104. Our first Effective Timestamp value, 6/1/2004, is circled in orange.
Figure 104 - CorticonRequest with decisionServiceEffectiveTimestamp Value
January 13, 2012
Page 107
Sending this request message using TestDS.cmd as before, the response from Corticon Server is:
Figure 105 - CorticonResponse from Decision Service Version 1
Notice that Corticon Server executed this request message using Decision Service Major Version 1, which has the Effective/Expiration Date pair of 1/1/200412/31/2005. This Major Version is the only Decision Service effective for the date specified in the request messages Effective Timestamp. As before, the Major Version number executed appears in the version attribute of the <Messages> complexType, as shown circled in Figure 105. To illustrate what happens when an Effective Timestamp falls in range of more than one Major Version of deployed Decision Services, lets modify our request message as shown in Figure 106. Our new value of decisionServiceEffectiveTimestamp is 7/10/2005.
January 13, 2012
Page 108
Figure 106 - CorticonRequest with Overlapping decisionServiceEffectiveTimestamp Value
Send this request to Corticon Server and examine the response, below, in Figure 111.
Figure 107 - CorticonResponse from Decision Service Version 3
We can see that this time Corticon Server executed the request with Major Version 3. It did so because whenever a requests decisionServiceEffectiveTimestamp value falls within range of more than one deployed Decision Service, Corticon Server chooses the Decision Service with the highest Major Version number. In this case, all three Decision Services were effective on 7/10/2005, so Corticon Server chose Major Version 3 the highest qualifying Version to execute the request.
January 13, 2012
Page 109
Specifying Effective Timestamp in a Java API Call

A version of the execute() method exists which contains an extra argument for a specified Decision Service Version:
execute(String astrDecisionServiceName, Collection acolWorkObjs, int adDecisionServiceEffectiveTimestamp)
where:
astrDecisionServiceName is the Decision Service Name String value. acolWorkObjs is the collection of Java Business Objects the date payload. adDecisionServiceEffectiveTimestamp is the DateTime Effective
Timestamp. More information on this variant of the execute() method may be found in the JavaDoc.
Default Behavior
How does Corticon Server respond when no decisionServiceEffectiveTimestamp is specified in a request message? In this case, Corticon Server will assume that the value of decisionServiceEffectiveTimestamp is equal to the DateTime of invocation the DateTime right now. Corticon Server then selects the Decision Service which is effective now. If more than one are effective then Corticon Server selects the Decision Service with the highest Major Version number (as we saw in the overlap example).
Figure 108 - CorticonRequest with No decisionServiceEffectiveTimestamp Value
January 13, 2012
Page 110
Figure 109 - CorticonResponse from Decision Service Major Version 2
Specifying Both Major Version and Effective Timestamp

Specifying both attributes in a single request message is not allowed. Despite the fact that both attributes are optional in the XSD and WSDL, they may not be used together in a single request message. If this is attempted, Corticon Server will generate an error message, as shown in Figure 110.
January 13, 2012
Page 111
Figure 110 Server Error Due to Specifying Both Major Version and Timestamp
No variation of the execute() method exists which contains arguments for both decisionServiceTargetVersion and decisionServiceEffectiveTimestamp, so this call cannot be made using the Java APIs.
SUMMARY OF MAJOR VERSION AND EFFECTIVE TIMESTAMP BEHAVIOR

Request Specifies Major Version? Yes No No No No Yes Request Specifies Timestamp? No No No Yes Yes Yes Effective Timestamp N/A DateTime of Invocation DateTime of Invocation Specified Timestamp Specified Timestamp N/A Decision Service Dates Overlap? N/A No Yes No Yes N/A Server Behavior Execute specified Version Execute the effective Decision Service Execute effective Decision Service with highest Version Execute the effective Decision Service Execute effective Decision Service with highest Version Server error, see Figure 110
January 13, 2012
Page 112
PERFORMANCE AND TUNING GUIDE

This section discusses aspects of Server performance.
RULESHEET PERFORMANCE AND TUNING

In general, Studio includes many features that help rule authors write efficient rules. Because one of the biggest contributors to Decision Service (Ruleflow) performance is the number of rules (columns) in the component Rulesheets, reducing this number may improve performance. Using the Compression tool to reduce the number of columns in a Rulesheet has the effect of reducing the number of rules, even though the underlying logic is unaffected. In effect, you can create smaller, better performing Decision Services by compressing your Rulesheets prior to deployment. For more information, refer to the Rule Modeling Guides chapter on Rule Analysis and Optimization.
SERVER PERFORMANCE AND TUNING

Important: Before doing any performance and scalability testing when using an evaluation version of Business Rules Management, check with Corticon or your resellers support team to verify that your evaluation license is properly enabled to allow unlimited concurrency. Failure to do so may lead to unsatisfactory results as the default evaluation license does not permit high-concurrency operation. A Corticon Decision Service (Ruleflow) executes in the same thread as its caller. All Decision Services are stateless and have no latency; that is, they do not call out to other external services and await their response. Therefore, increasing the capacity for thread usage will increase performance. This can be done through: Using faster CPUs so threads are processed faster. Using more CPUs or CPU cores so more threads may be processed in parallel. Allocating more system memory to the JVM so there is more room for simultaneous threads. Distributing transactional load across multiple Corticon Server instances or multiple CPUs.
Optimizing Pool Settings for Performance

When a Decision Service is deployed (via either the Deployment Console or API), the person responsible for deployment (typically an IT specialist) decides how many instances of the same Decision Service (Reactors) may run concurrently. This number establishes the pool size for that particular Decision Service. Different Decision Services may have different pool sizes on the same Server because consumer demand for different Decision Services may vary. Choosing how large to make the pool depends on many factors, including the incoming arrival rate of requests for a particular Decision Service, the time required to process a request, the amount of other
Page 113
activity on the server box and the physical resources (number and speed of CPUs, amount of physical memory) available to the server box. A maximum pool size of one (1) implies no concurrency for that Decision Service. See Multi-threading and Concurrency or the Deployment Consoles pool size section for more details The recommendations that follow are not requirements. High-performing Corticon Server deployments may be achieved with varying configurations dictated by the realities of your IT infrastructure. Our testing and field experience suggests, however, that the closer your configuration comes to these standards, the better Corticon Server performance will be. Configuring the runtime environment revolves around a few key quantities: The number of CPUs in the server box on which the Corticon Server is running. The number of wrappers deployed. The wrapper is the intermediary layer between the web/app server and Corticon Server, receiving all calls to Corticon Server and then forwarding the calls to the Server via the Corticon API set. The wrapper is the interface between deployment-specific details of an installation, and the fixed API set exposed by Corticon Server. A sample Servlet wrapper, axis.war, is provided as part of the default Corticon Server installation. The minimum and maximum pool size settings for each deployed Decision Service. These pool sizes are set in the Deployment Descriptor file (.cdd) created in the Deployment Console.
Single Machine Configuration

CPUs & Wrappers For optimal performance, the number of wrappers 9 (Session EJBs, Servlets, etc) deployed should never exceed the number of CPU cores on the server hardware, minus an allocation to support the OS and other applications resident on the server, including middleware. Typically, the number of these wrappers is controlled via a configuration file: the sample EJB code Corticon provides in its default installation sets this number in the weblogic-ejb-jar.xml file. Servlets are also configured in a similar way. For example, a 4-core server box should have, at most, 4 wrappers deployed to it. Another example: a dedicated Corticon Server box with 16 cores should have at most 15 wrappers deployed, with 1 core of capacity reserved for OS and middleware platform. Wrappers & Pools The number of wrappers should be greater than or equal to the highest pool setting for any deployed Decision Service. For example, take the following example deployment: Ruleflow #1 (Decision Service #1): min pool size = 5, max pool size = 5. Ruleflow #2 (Decision Service #2): min pool size = 4, max pool size = 4.
Oracle WebLogic application server refers to wrappers as Bean Pools

January 13, 2012
Server Integration & Deployment Guide 5.2 Ruleflow #3 (Decision Service #3): min pool size = 9, max pool size = 9.
Page 114
In this case, 9 deployed wrappers are optimum to ensure that unused or idle Reactors in the pool are minimized. This setting, however, may conflict with the wrapper number suggested by CPU core number. If we were starting with a fixed CPU core number, say 8, then we would want to reduce the pool size for Decision Service #3 to: Ruleflow #3 (Decision Service #3): min pool size = 8, max pool size = 8.
And deploy only 8 wrappers instead of 9. Had we retained the original 9/9 pool setting, the ninth Reactor in the pool would have gone unused and simply would have consumed additional memory with no benefit. On the other hand, increasing wrappers to 9 might cause a total of 9 threads of execution to be allocated to 9 reactors (any mix of Reactors for the 3 Ruleflow). Since only 8 threads can process simultaneously (only 8 physical CPU cores), then performance-robbing thread switching will occur. Minimum and Maximum Pool Sizes Current testing suggests that setting minimum and maximum pool sizes equal to each other results in best performance. Although keeping a larger number of Reactors ready in the pool requires more memory, it also eliminates the time necessary to spawn new Reactors into the pool when transaction demand suddenly increases because the pool is already loaded with the maximum number of Reactors allowed. It is also important to note that higher minimum pool settings require more time to initialize during web/app server startup because more Reactors must be put into the pool. Hyper-threading Hyper-threading is an Intel-proprietary technology used to improve parallelization of computations (doing multiple tasks at once) performed on PC microprocessors. For each processor core that is physically present, the operating system addresses two virtual processors, and shares the workload between them when possible. Field experience suggests that Hyper-threading does not allow doubling of wrappers or Reactors for a given physical CPU core number. Doubling wrappers or Reactors with the expectation that Hyperthreading will double capacity will result in core under-utilization and poor performance. We recommend setting wrapper and Reactor parameters based on the assumption of one thread per CPU core.
Cluster Configuration
The recommendations above also hold true in clustered environments, with the following clarifications: CPUs & Pools Because wrappers are typically located on the Main Cluster Instance and Reactors are located on the cluster machines, the direct relationship between CPUs and wrappers isnt so straightforward in clustered environments. The key relationship becomes number of CPUs on the cluster machine and
Page 115
the maximum pool size of any given Decision Service deployed to the same machine. If the number of CPUs in cluster machine A is 4, then the maximum pool size for any Decision Service deployed to cluster machine A should not exceed 4. Wrappers & Pools Wrapper count on the Main Cluster Instance should be greater than or equal to the sum of the maximum pool sizes for any given Decision Service across all clustered machines. For example: Cluster machine A has Decision Service #1 deployed with min/max pool settings of 4/4. Cluster machine B has Decision Service #1 deployed with min/max pool settings of 6/6. Cluster machine C has Decision Service #1 deployed with min/max pool settings of 2/2.
Based on this example, the Main Cluster Instance should have at least 12 instances of the wrapper deployed to make most efficient use of the 12 available Reactors in Decision Service #1s clustered pool. Minimum and Maximum Pool Sizes As with the Single Machine configuration, minimum and maximum pool size settings should also equal each other on each cluster machine
Logging
Corticon Server log settings can have a major impact on performance. The log is set to VIOLATION mode by default, which only logs Corticon Server violations and exceptions. Configuring logging is described in Configuring Server Logging. In production deployments, Corticon Server logging should always be set to VIOLATION mode, as all other modes may increase transaction times by a factor of 10. INFO and RULETRACE modes are intended for testing environments and DEBUG mode should be enabled only on instruction from Progress technical support personnel.
Batching the Data in a Single Transaction

A Reactor can (unless explicitly prohibited by its service contract) accept a batch of work in a single request, and then send a single response. Batching may offer performance advantages over one-at-atime request-response sequences because it minimizes other network overhead and latencies per transaction. To better understand this, consider an airline marketing business process. In one design, the business process retrieves a single customer record from the database and then dispatches it through the
January 13, 2012
Page 116
marketing workflow. Decision Services would be called at each decision-making activity for each customer. Better performance can be achieved if the marketing business process reads a batch of customer records (say, in blocks of 100) and then passes the batch into each Decision Service. The Decision Service responds with an update to the payload (100 new offers). Why might this be faster? Two reasons. First of all, the setup and takedown time of a service invocation is reduced by a factor of 100. Secondly, and more importantly, Corticon Server is optimized to handle large payloads, providing dramatic relative performance benefits versus traditional, RETEbased rule engines. Batching can most easily be done when the application processes large numbers of work documents at once. However, batching is also possible in high volume on-line scenarios such as busy e-commerce sites or call centers. In this situation, a technique known as boxcaring can be used. Incoming work is placed into a buffer (the boxcar) and when the boxcar fills up, it is sent on to the Decision Service. The Decision Service returns the boxcar with the Decision Service results enclosed. To make boxcaring work effectively in on-line situations where work arrives randomly, timers are needed to send unfilled boxcars to Corticon Server so that user response time does not suffer while waiting for the boxcar to fill. A distinct downside of batching is that it prevents Corticon Server from distributing multiple transactions across multiple Reactors in the requested Decision Services pool. If a batch request contains 10 individual payloads, then this request can only be assigned to a single Reactor, and the requesting client must wait for all 10 to complete processing before a response is sent. However, if these same 10 payloads are sent as 10 individual requests, then Corticon Server can distribute them to the available Reactors in the pool, resulting in concurrent execution and better performance.
Capacity Planning
In a given JVM, the Corticon Server and its Decision Services occupy the following amounts of physical memory:
State of Corticon Server Basic Corticon Server overhead with no Decision Services (excludes memory footprint of the JVM which varies by JDK version and platform) Load a single Decision Service from the Deployment Descriptor or addDecisionService() method API. Working memory to handle a single CorticonRequest RAM required 25 MB
~ 5 MB 10 ~ 1 MB 11
10 11
5 MB is for the Trade Allocation sample application with seven (7) Rulesheets, twenty-four (24) rules, five (5) associated entities 1 MB is for the Trade Allocation sample application with seven (7) Rulesheets, twenty-four (24) rules, five (5) associated entities (this is for steady-state usage) January 13, 2012
Page 117
You may reduce the amount of memory required in a large system by dynamically loading and unloading specific Decision Services. This is especially relevant in resource-constrained handheld or laptop scenarios where only a single business transaction occurs at a time. After the first Decision Service is invoked, it is unloaded by the application and the second Decision Service is loaded (and so on). While this will be slower than having all Decision Services always loaded, it can address tight, memory-constrained environments. A compromise alternative would only dynamically load/unload infrequently used Decision Services. The Java clock Finally, whenever performance of Java applications needs to be measured in milliseconds, it should be remembered that Java is dependent upon the operating systems internal clock. And not all operating systems track time to equal degrees of granularity. The following excerpt from the Java JavaDoc explains:
public static long currentTimeMillis()
Returns the current time in milliseconds. Note that while the unit of time of the return value is a millisecond, the granularity of the value depends on the underlying operating system and may be larger. For example, many operating systems measure time in units of tens of milliseconds. See the description of the class Date for a discussion of slight discrepancies that may arise between "computer time" and coordinated universal time (UTC). Returns: The difference, measured in milliseconds, between the current time and midnight, January 1, 1970 UTC.
January 13, 2012
Page 118
INTERNATIONALIZATION
Corticon Server can accept and generate data values in character sets other than English. This section describes the general capabilities of Corticon Server for use outside the English character set. Any attribute of type String can contain any character supported by the UTF-8 encoding standard. This means that characters in European and Asian languages are supported. All encoding of string values passed to Corticon Server is assumed to be UTF-8. Any CorticonResponse outputs, including Messages, will also follow UTF-8 character encoding. Vocabulary names (entities, attributes, associations) are restricted to A-Z, a-z, 0-9, and underscore. File names and their paths are restricted to A-Z, a-z, 0-9, and underscore. All tags in the XML payload must use English characters. All Java class and Java property names in any Java payload must follow Java English conventions.
In Studio, it is possible to use ISO 8859-1 encoding in lieu of UTF-8 (although this will mean that Asian languages are not supported) by setting this property in CcStudio.properties:
com.corticon.encoding.standard=ISO-8859-1
See the Studio Installation Guide for more details on enabling localization in Studio.
January 13, 2012
Page 119
APPENDIX A: SERVICE CONTRACT AND MESSAGE SAMPLES

ANNOTATED EXAMPLES OF XSD AND WSDLS AVAILABLE IN THE DEPLOYMENT CONSOLE
Section 1 2 3 4 5 6 7 8 Type XSD XSD XSD XSD WSDL WSDL WSDL WSDL Level Vocabulary Vocabulary Decision Service Decision Service Vocabulary Vocabulary Decision Service Decision Service Style Flat Hierarchical Flat Hierarchical Flat Hierarchical Flat Hierarchical
1 VOCABULARY-LEVEL XML SCHEMA, FLAT XML MESSAGING STYLE

This section formally defines and annotates the FLAT Vocabulary-level XSD. Annotations are shown in this format, while XML code is shown in this format.
Header
<?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:tns="urn:<namespace>" targetNamespace="urn:<namespace>" elementFormDefault="qualified">
for details on <namespace> definition, see XML Namespace Mapping
CorticonRequestType and CorticonResponseType

The CorticonRequest element contains the required input to the Decision Service:
<xsd:element name="CorticonRequest" type="tns:CorticonRequestType" />
The CorticonResponse element contains the output produced by the Decision Service:
<xsd:element name="CorticonResponse" type="tns:CorticonResponseType" /> <xsd:complexType name="CorticonRequestType"> <xsd:sequence>
Each CorticonRequestType must contain one WorkDocuments element:

<xsd:element name="WorkDocuments" type="tns:WorkDocumentsType" />

</xsd:sequence>
Page 120
This attribute contains the Decision Service Name. Because a Vocabulary-level service contract can be used for several different Decision Services (provided they all use the same Vocabulary), a Decision Service Name will not be automatically populated here during service contract generation. Your request document must contain a valid Decision Service Name in this attribute, however, so the Server knows which Decision Service to execute
<xsd:attribute name="decisionServiceName" use="required" type="xsd:string" />
This attribute contains the Decision Service target version number. While every Decision Service created in Corticon Studio 5.2 will be assigned a version number (if not manually assigned), it is not necessary to include that version number in the invocation unless you want to invoke a specific version of the named Decision Service.
<xsd:attribute name="decisionServiceTargetVersion" use="optional" type="xsd:nonNegativeInteger" />
This attribute contains the invocation timestamp. Decision Services may be deployed with effective and expiration dates, which allow the Corticon Server to manage multiple versions of the same Decision Service Name and execute the effective version based on the invocation timestamp. It is not necessary to include the invocation unless you want to invoke a specific effective version of the named Decision Service by date (usually past or future).
<xsd:attribute name="decisionServiceEffectiveTimestamp" use="optional" type="xsd:dateTime" /> </xsd:complexType> <xsd:complexType name="CorticonResponseType"> <xsd:sequence>
Each CorticonResponseType element produced by the Server will contain one WorkDocuments element:
<xsd:element name="WorkDocuments" type="tns:WorkDocumentsType" />
Each CorticonResponseType element produced by the Server will contain one Messages element, but if the Decision Service generates no messages, this element will be empty:
<xsd:element name="Messages" type="tns:MessagesType" /> </xsd:sequence>
Same as attribute in CorticonRequest. This means that every CorticonResponse will contain the Decision Service Name executed during the transaction.
<xsd:attribute name="decisionServiceName" use="required" type="xsd:string" />
Same as attribute in CorticonRequest.

<xsd:attribute name="decisionServiceTargetVersion" use="optional" type="xsd:nonNegativeInteger" />
Same as attribute in CorticonRequest.

<xsd:attribute name="decisionServiceEffectiveTimestamp" use="optional" type="xsd:dateTime" />
Page 121
WorkDocumentsType
Entities within WorkDocumentsType may be listed in any order.
<xsd:complexType name="WorkDocumentsType">
If you plan to use a software tool to read and use a Corticon-generated service contract, be sure it supports this <xsd:choice> tag
<xsd:choice maxOccurs="unbounded">
In a Vocabulary-level XSD, a WorkDocumentsType element contains all of the entities from the Vocabulary file specified in the Deployment Console. One will be a mandatory WDE and all the others will be optional (non-WDE) entities The WDE entity is mandatory in message instances that use this service contract. It has the form:
<xsd:element name="VocabularyEntityName" type="tns:VocabularyEntityNameType" maxOccurs="unbounded" />
Non-WDE entities are optional in message instances that use this service contract (minOccurs=0 indicates optional) and have the form:
<xsd:element name="VocabularyEntityName" type=" tns:VocabularyEntityNameType" minOccurs="0" maxOccurs="unbounded" /> </xsd:choice>
This element reflects the FLAT XML Messaging Style selected in the Deployment Console:
<xsd:attribute name="messageType" fixed="FLAT" use="optional" /> </xsd:complexType>
MessagesType
<xsd:complexType name="MessagesType">
If you plan to use a software tool to read and use a Corticon-generated service contract, be sure it supports this <xsd:sequence> tag (see important note below)
<xsd:sequence>
A Messages element includes zero or more Message elements.

<xsd:element name="Message" type="tns:MessageType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence>
This version number corresponds to the responding Decision Services version number, which is set in Studio.
<xsd:attribute name="version" type="xsd:string" /> </xsd:complexType>
A Message element consists of several items see the Rule Language Guide for more information on the post operator, which generates the components of a Messages element.

<xsd:complexType name="MessageType"> <xsd:sequence>
Page 122
These severity levels correspond to those of the posted Rule Statements

<xsd:element name="severity"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="Info" /> <xsd:enumeration value="Warning" /> <xsd:enumeration value="Violation" /> </xsd:restriction> </xsd:simpleType> </xsd:element>
The text element corresponds to the text of the posted Rule Statements
<xsd:element name="text" type="xsd:string" /> <xsd:element name="entityReference"> <xsd:complexType>
The href association corresponds to the entity references of the posted Rule Statements
<xsd:attribute name="href" type="xsd:anyURI" /> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType>
The XML tag <xsd:sequence> is used to define the attributes of a given element. In an XML Schema, <sequence> requires the elements that follow to appear in exactly the order defined by the schema within the corresponding XML document. If CcServer.properties com.corticon.ccserver.ensureComplianceWithServiceContract
is:
true, the Server will return the elements in the same order as specified by the service
contract, even for elements created during rule execution and not present in the incoming message. false, the Server may return elements in any order. Consuming applications should be designed accordingly. This setting results in slightly better Server performance.
VocabularyEntityNameType
<xsd:complexType name="VocabularyEntityNameType"> <xsd:sequence>
A VocabularyEntityNameType contains zero or more VocabularyAttributeNames, but any VocabularyAttributeName may appear at most once per VocabularyEntityNameType
<xsd:element name="VocabularyAttributeName" type="xsd:VocabularyAttributeNameType" nillable="false" minOccurs="0" />
Associations between VocabularyEntityNames are represented as follows. This particular association is optional and has one-to-one or many-to-one cardinality:

<xsd:element name="VocabularyRoleName" type="tns:ExtURIType" minOccurs="0" />
Page 123
This particular association is optional and has one-to-many or many-to-many cardinality:

<xsd:element name="VocabularyRoleName" type="tns:ExtURIType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence>
Every VocabularyEntityNameType will contain a unique id number if an id is not included in the CorticonRequest element, the Server will automatically assign one and return it in the CorticonResponse
<xsd:attribute name="id" type="xsd:ID" use="optional" />
The ExtURIType is used by all associations in messages having FLAT XML Message Style
<xsd:complexType name="ExtURIType"> <xsd:attribute name="href" type="xsd:anyURI" /> </xsd:complexType> </xsd:schema>
VocabularyAttributeNameTypes
Every attribute in a Corticon Vocabulary has one of five datatypes Boolean, String, Date, Integer, or Decimal. Thus when entities are passed in a CorticonRequest or CorticonResponse, their attributes must be one of these five types. In addition, the ExtURIType type is used to implement associations between entity instances. The href attribute in an entity points to another entity with which it is associated.
January 13, 2012
Page 124
2 VOCABULARY-LEVEL XML SCHEMA, HIER XML MESSAGING STYLE

This section formally defines and annotates the HIER Vocabulary-level XSD. Most elements are the same or have only minor differences from the FLAT XSD described above.
Header
This section of the XSD is identical to the FLAT version, described above.

WorkDocumentsType
One line in this section differs from the FLAT version (described above): This attribute value indicates the HIER XML Messaging Style selected in the Deployment Console:
<xsd:attribute name="messageType" fixed="HIER" use="optional" />
MessagesType
VocabularyEntityNameType
Because this service contract uses HIER structure, associated entities in the Vocabulary make direct reference to each other, as shown here. The type of an associated Vocabulary entity uses that entitys type, rather than the ExtURIType found in the FLAT version
<xsd:sequence> <xsd:element name="VocabularyEntityName" type="tns:VocabularyEntityNameType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence>
href is present in this element only in the HIER version. This attribute is present because HIER messages typically use an indented or embedded XML structure. However, the HIER option also permits a hybrid or combination FLAT-HIER structure, so the optional href attribute is included purely for handling any FLAT elements that appear in a hybrid message
<xsd:attribute name="href" type="xsd:anyURI" use="optional" />
VocabularyAttributeNameTypes
This section of the XSD is the same as the FLAT version, described above.
Page 125
3 DECISION-SERVICE-LEVEL XML SCHEMA, FLAT XML MESSAGING STYLE

When Decision Service is selected in section 16 of Figure 50, the XML Messaging Style option in section 20 becomes inactive (grayed out). This occurs because the XML Messaging Style option at the Decision Service level, (selected in section 15 of Figure 37) becomes the governing setting.
Header
This section of the XSD is identical to the Vocabulary-level FLAT version, described above.

This section of the XSD is identical to the Vocabulary-level FLAT version, described above, with the exception of the following lines in each complexType:
<xsd:attribute name="decisionServiceName" use="required" fixed="DecisionServiceName" type="xsd:string" />
Notice that the name of the Decision Service you entered in section 2 of Figure 36 is automatically inserted in fixed="DecisionServiceName". The use of the fixed element is optional in some cases, fixed may give XML parsers difficulty. See Extended Service Contracts: Fixed Attribute for details on removing the fixed element from your service contracts.
WorkDocumentsType
This section of the XSD is identical to the Vocabulary-level FLAT version, described here.
MessagesType
This section of the XSD is identical to the Vocabulary-level FLAT version, described here.
VocabularyEntityNameType and VocabularyAttributeNameTypes

The structure of this section of the XSD is identical to the Vocabulary-level FLAT version (described here). However, a Decision-Service-level service contract will contain only those entities and attributes from the Vocabulary that are actually used by the rules in the Decision Service. This means that a Decision-Service-level contract will typically contain a subset of the entities and attributes contained in the Vocabulary-level service contract.
January 13, 2012
Page 126
4 DECISION-SERVICE-LEVEL XML SCHEMA, HIER XML MESSAGING STYLE

When Decision Service is selected in section 8, the XML Messaging Style option in section 12 becomes inactive (grayed out). This occurs because the XML Messaging Style option at the Decision Service level, selected in SECTION 6 becomes the governing setting.
Header

This section of the XSD is identical to the Decision-Service-level FLAT version, described above.
WorkDocumentsType
This section of the XSD is identical to the Vocabulary-level HIER version, described above.
MessagesType
VocabularyEntityNameType and VocabularyAttributeNameTypes

The structure of this section of the XSD is identical to the Vocabulary-level HIER version (described above). However, a Decision-Service-level service contract will contain only those entities and attributes from the Vocabulary that are actually used by the rules in the Decision Service. This means that a Decision-Service-level service contract will typically contain some subset of the entities and attributes contained in the Vocabulary-level service contract.
January 13, 2012
Page 127
5 VOCABULARY-LEVEL WSDL, FLAT XML MESSAGING STYLE

SOAP Envelope
<?xml version="1.0" encoding="UTF-8"?> <definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="urn:<namespace>" xmlns:cc="urn:<namespace>" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" targetNamespace="urn:<namespace>">
for details on <namespace> definition, see XML Namespace Mapping
Types
<types> <xsd:schema xmlns:tns="urn:Corticon" targetNamespace="urn:<namespace>" elementFormDefault="qualified">
This <type> section contains the entire Vocabulary-level XSD, FLAT-style service contract, minus the XSD Header section or details on <namespace> definition, see XML Namespace Mapping
</types>
Messages
The SOAP service supports two messages, each with a single argument. See portType
<message name="CorticonRequestIn"> <part name="parameters" element="cc:CorticonRequest" /> </message> <message name="CorticonResponseOut"> <part name="parameters" element="cc:CorticonResponse" /> </message>
PortType
<portType name="VocabularyNameDecisionServiceSoap">
Indicates service operation: one message in and one message out

<operation name="processRequest"> <input message="tns:CorticonRequestIn" /> <output message="tns:CorticonResponseOut" /> </operation> </portType>
Binding
Use HTTP transport for SOAP operation defined in <portType>

<binding name="VocabularyNameDecisionServiceSoap" type="tns: VocabularyNameDecisionServiceSoap">
Page 128
All WSDLs generated by the Deployment Console use Document-style messaging:

<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" /> <operation name="processRequest">
Identifies the SOAP binding of the Decision Service:

<soap:operation soapAction="urn:Corticon" style="document" /> <input> <soap:body use="literal" namespace="urn:Corticon" /> </input> <output> <soap:body use="literal" namespace="urn:Corticon" /> </output> </operation> </binding>
Service
<service name="VocabularyNameDecisionService">
Any text you enter in a Rulesheets comments window (accessed via Rulesheet>Properties>Comments tab on the Studio menubar) will be inserted here:
<documentation>optional Rulesheet comments</documentation> <port name="VocabularyNameDecisionServiceSoap" binding="tns:VocabularyNameDecisionServiceSoap">
Corticon Server Servlet URI contained in section 22 of the Deployment Console will be inserted here:
<soap:address location="http://localhost:8082/axis/services/Corticon" /> </port> </service> </definitions>
January 13, 2012
Page 129
6 VOCABULARY-LEVEL WSDL, HIER XML MESSAGING STYLE

SOAP Envelope
This section of the WSDL is identical to the Vocabulary-level FLAT version, described above.
Types
<types> <xsd:schema xmlns:tns="urn:<namespace>" targetNamespace="urn:<namespace>" elementFormDefault="qualified">
This <type> section contains the entire Vocabulary-level XSD, HIER-style service contract, minus the XSD Header section or details on <namespace> definition, see XML Namespace Mapping
</types>
Messages
PortType
Binding
Service
January 13, 2012
Page 130
7 DECISION-SERVICE-LEVEL WSDL, FLAT XML MESSAGING STYLE

SOAP Envelope
Types
<types> <xsd:schema xmlns:tns="urn:<namespace>" targetNamespace="urn:<namespace>" elementFormDefault="qualified">
This <type> section contains the entire Decision Service-level XSD, FLAT-style service contract, minus the XSD Header section or details on <namespace> definition, see XML Namespace Mapping
</types>
Messages
PortType
This section of the WSDL is identical to the Vocabulary-level FLAT version, described above, with the exception of the following line:
<portType name="DecisionServiceNameSoap">
Binding
This section of the WSDL is identical to the Vocabulary-level FLAT version, described above, with the exception of the following line:
<binding name="DecisionServiceNameSoap" type="tns: DecisionServiceNameSoap">
Service
This section of the WSDL is identical to the Vocabulary-level FLAT version, described above, with the exception of the following lines:
<service name="DecisionServiceName"> <port name="DecisionServiceNameSoap" binding="tns: DecisionServiceNameSoap">
January 13, 2012
Page 131
8 DECISION-SERVICE-LEVEL WSDL, HIER XML MESSAGING STYLE

SOAP Envelope
Types
<types> <xsd:schema xmlns:tns="urn:<namespace>" targetNamespace="urn:namespace>" elementFormDefault="qualified">
This <type> section contains the entire Decision Service-level XSD, HIER-style service contract, minus the XSD Header section or details on <namespace> definition, see XML Namespace Mapping
</types>
Messages
This section of the WSDL is identical to the Decision Service-level FLAT version, described above.
PortType
Binding
Service
January 13, 2012
Page 132
EXTENDED SERVICE CONTRACTS

NewOrModified attribute Corticon service contract structures may be extended with an optional newOrModified attribute that indicates which parts of the payload have been changed by the Corticon Server during execution.
<xsd:attribute name="newOrModified" type="xsd:boolean" use="optional" /> </xsd:complexType>
Any attribute (the Vocabulary attribute) whose value was changed by the Corticon Server during rule execution will have the newOrModified attribute set to true. Also, In FLAT messages, the newOrModified attribute of an entity is true if: Any contained attribute is modified. Any association to that entity is added or removed.
In HIER messages, the newOrModified attribute of an entity is true if the entity, or any of its associated entities: Any contained attribute is modified. Any association to that entity is added or removed.
This attribute (XML attribute, not Vocabulary attribute) is enabled and disabled by the enableNewOrModified property in CcCommon.properties (see Appendix C for details). In order to make use of the newOrModified attribute, your consuming application must be able to correctly parse the response message. Because this attribute adds additional complexity to the service contract and its resultant request and response messages, be sure your SOAP integration toolset is capable of handling the increased complexity before enabling it. Extended Datatypes If the newOrModified attribute is enabled, then the base XML datatypes must be extended to accommodate it. The following complexTypes are included in service contracts that make use of the newOrModified attribute. ExtBooleanType
<xsd:complexType name="ExtBooleanType"> <xsd:simpleContent> <xsd:extension base="xsd:boolean"> <xsd:attribute name="newOrModified" type="xsd:boolean" use="optional" /> </xsd:extension> </xsd:simpleContent> </xsd:complexType>
January 13, 2012
Server Integration & Deployment Guide 5.2 ExtStringType

<xsd:complexType name="ExtStringType"> <xsd:simpleContent> <xsd:extension base="xsd:string"> <xsd:attribute name="newOrModified" type="xsd:boolean" use="optional" /> </xsd:extension> </xsd:simpleContent> </xsd:complexType>
Page 133
ExtDateTimeType
<xsd:complexType name="ExtDateTimeType"> <xsd:simpleContent> <xsd:extension base="xsd:dateTime"> <xsd:attribute name="newOrModified" type="xsd:boolean" use="optional" /> </xsd:extension> </xsd:simpleContent> </xsd:complexType>
If CcServer.properties com.corticon.ccserver.ensureComplianceWithServiceContract is
False: the Server will return an attribute of type Date in the same form as it was
received.
True: the Server will return an attribute of type Date using the date mask yyyyMM-dd'T'HH\:mm\:ss z
ExtIntegerType
<xsd:complexType name="ExtIntegerType"> <xsd:simpleContent> <xsd:extension base="xsd:integer"> <xsd:attribute name="newOrModified" type="xsd:boolean" use="optional" /> </xsd:extension> </xsd:simpleContent> </xsd:complexType>
ExtDecimalType
<xsd:complexType name="ExtDecimalType"> <xsd:simpleContent> <xsd:extension base="xsd:decimal"> <xsd:attribute name="newOrModified" type="xsd:boolean" use="optional" /> </xsd:extension> </xsd:simpleContent> </xsd:complexType>
January 13, 2012
Server Integration & Deployment Guide 5.2 Fixed attribute
Page 134
As with the newOrModified attribute, some XML or SOAP toolsets have difficulty parsing service contracts and messages which include the fixed attribute, seen in the CorticonRequest and CorticonResponse complexType sections of all service contracts. As of this manuals release date, it is known that versions of Microsofts .NET SOAP toolkit have difficulty with fixed. To improve compatibility, CcDeployment.properties includes a property named com.corticon.deployment.includeFixedTaskValueInServiceContract, which if set to false, removes the fixed attribute from all service contracts generated by the Deployment Console.
EXAMPLES
This section illustrates with an example how the service contract is generated and what the input and output payload looks like. The example used is from the Tutorial for Corticon Studio Basic Rule Modeling. A FlightPlan is associated with a Cargo. A FlightPlan is also associated with an Aircraft. The Vocabulary is shown below.
January 13, 2012
Page 135
FlightPlan is the Work Document Entity (WDE).
In this section, both WSDL and XML Schema service contracts are shown. Some annotations are provided. The WSDL example uses FLAT XML messaging style; the XML Schema example uses HIER messaging style.
Vocabulary-Level WSDL, FLAT XML Messaging Style

<?xml version="1.0" encoding="UTF-8"?> <definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns= "http://localhost:8082/axis/services/Corticon/CargoDecisionService" xmlns:cc= "urn:decision:CargoDecisionService" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" targetNamespace= "http://localhost:8082/axis/services/Corticon/CargoDecisionService">
Page 136
<types> <xsd:schema xmlns:tns= "urn:decision:CargoDecisionService" targetNamespace= "urn:decision:CargoDecisionService" elementFormDefault="qualified"> <xsd:element name="CorticonRequest" type="tns:CorticonRequestType" /> <xsd:element name="CorticonResponse" type="tns:CorticonResponseType" /> <xsd:complexType name="CorticonRequestType"> <xsd:sequence> <xsd:element name="WorkDocuments" type="tns:WorkDocumentsType" /> </xsd:sequence> <xsd:attribute name="decisionServiceName" use="required" type="xsd:string" /> </xsd:complexType> <xsd:complexType name="CorticonResponseType"> <xsd:sequence> <xsd:element name="WorkDocuments" type="tns:WorkDocumentsType" /> <xsd:element name="Messages" type="tns:MessagesType" /> </xsd:sequence>
Even though this is a Vocabulary-level WSDL, the Decision Service Name is still required:
<xsd:attribute name="decisionServiceName" use="required" type="xsd:string" /> </xsd:complexType> <xsd:complexType name="WorkDocumentsType"> <xsd:choice maxOccurs="unbounded">
This is a Vocabulary-level service contract, so all entities in the Vocabulary are included here:
<xsd:element name="Aircraft" type="tns:AircraftType" minOccurs="0" maxOccurs="unbounded" /> <xsd:element name="Cargo" type="tns:CargoType" minOccurs="0" maxOccurs="unbounded" />
FlightPlan is the WDE, so it is a mandatory element notice no minOccurs attribute:

<xsd:element name="FlightPlan" type="tns:FlightPlanType" maxOccurs="unbounded" /> </xsd:choice>
FLAT style specified here:

<xsd:attribute name="messageType" fixed="FLAT" use="optional" /> </xsd:complexType> <xsd:element name="Aircraft" type="tns:AircraftType" minOccurs="0" maxOccurs="unbounded" /> <xsd:element name="Cargo" type="tns:CargoType" minOccurs="0" maxOccurs="unbounded" /> <xsd:element name="FlightPlan" type="tns:FlightPlanType" minOccurs="0" maxOccurs="unbounded" /> </xsd:choice> </xsd:complexType> <xsd:complexType name="MessagesType"> <xsd:sequence> <xsd:element name="Message" type="tns:MessageType" minOccurs="0" maxOccurs="unbounded" />
Page 137
</xsd:sequence> <xsd:attribute name="version" type="xsd:string" /> </xsd:complexType> <xsd:complexType name="MessageType"> <xsd:sequence> <xsd:element name="severity"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="Info" /> <xsd:enumeration value="Warning" /> <xsd:enumeration value="Violation" /> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="text" type="xsd:string" /> <xsd:element name="entityReference"> <xsd:complexType> <xsd:attribute name="href" type="xsd:anyURI" /> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:complexType name="AircraftType"> <xsd:sequence> <xsd:element name="aircraftType" type="xsd:string" nillable="false" minOccurs="0" /> <xsd:element name="maxCargoVolume" type="xsd:decimal" nillable="false" minOccurs="0" /> <xsd:element name="maxCargoWeight" type="xsd:decimal" nillable="false" minOccurs="0" /> <xsd:element name="tailNumber" type="xsd:string" nillable="false" minOccurs="0" /> <xsd:element name="flightPlan" type="tns:ExtURIType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> <xsd:attribute name="id" type="xsd:ID" use="optional" /> </xsd:complexType> <xsd:complexType name="CargoType"> <xsd:sequence> <xsd:element name="manifestNumber" type="xsd:string" nillable="false" minOccurs="0" /> <xsd:element name="volume" type="xsd:decimal" nillable="false" minOccurs="0" /> <xsd:element name="weight" type="xsd:decimal" nillable="false" minOccurs="0" /> <xsd:element name="flightPlan" type="tns:ExtURIType" minOccurs="0" /> </xsd:sequence> <xsd:attribute name="id" type="xsd:ID" use="optional" /> </xsd:complexType> <xsd:complexType name="FlightPlanType"> <xsd:sequence>
January 13, 2012

<xsd:element name="flightNumber" type="xsd:integer" nillable="false" minOccurs="0" /> <xsd:element name="flightRange" type="xsd:integer" nillable="false" minOccurs="0" />
Page 138
This is a FLAT-style message, so all associations are represented by the ExtURIType:

<xsd:element name="aircraft" type="tns:ExtURIType" minOccurs="0" /> <xsd:element name="cargo" type="tns:ExtURIType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> <xsd:attribute name="id" type="xsd:ID" use="optional" /> </xsd:complexType> <xsd:complexType name="ExtURIType"> <xsd:attribute name="href" type="xsd:anyURI" /> </xsd:complexType> </xsd:schema> </types> <message name="CorticonRequestIn"> <part name="parameters" element="cc:CorticonRequest" /> </message> <message name="CorticonResponseOut"> <part name="parameters" element="cc:CorticonResponse" /> </message> <portType name="CargoDecisionServiceSoap"> <operation name="processRequest"> <input message="tns:CorticonRequestIn" /> <output message="tns:CorticonResponseOut" /> </operation> </portType> <binding name="CargoDecisionServiceSoap" type="tns:CargoDecisionServiceSoap">
All Web Services service contracts must be document-style!

<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" /> <operation name="processRequest"> <soap:operation soapAction="urn:Corticon" style="document" /> <input> <soap:body use="literal" namespace="urn:Corticon" /> </input> <output> <soap:body use="literal" namespace="urn:Corticon" /> </output> </operation> </binding> <service name="CargoDecisionService"> <documentation>InsertDecisionServiceDescription</documentation> <port name="CargoDecisionServiceSoap" binding="tns:CargoDecisionServiceSoap"> <soap:address location="http://localhost:8082/axis/services/Corticon" /> </port>

</service> </definitions>
Page 139
Decision-Service-Level XSD, HIER XML Messaging Style

<?xml version="1.0" encoding="UTF-8"?> <definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://localhost:8082/axis/services/Corticon/tutorial_example" xmlns:cc="urn:decision:tutorial_example" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" targetNamespace="http://localhost:8082/axis/services/Corticon/tutorial_examp le"> <types> <xsd:schema xmlns:tns="urn:decision:tutorial_example" targetNamespace="urn:decision:tutorial_example" elementFormDefault="qualified"> <xsd:element name="CorticonRequest" type="tns:CorticonRequestType" /> <xsd:element name="CorticonResponse" type="tns:CorticonResponseType" /> <xsd:complexType name="CorticonRequestType"> <xsd:sequence> <xsd:element name="WorkDocuments" type="tns:WorkDocumentsType" /> </xsd:sequence>
The Decision Service Name has been automatically included here:

<xsd:attribute name="decisionServiceName" use="required" fixed="tutorial_example" type="xsd:string" /> <xsd:attribute name="decisionServiceTargetVersion" use="optional" type="xsd:nonNegativeInteger" /> <xsd:attribute name="decisionServiceEffectiveTimestamp" use="optional" type="xsd:dateTime" /> </xsd:complexType> <xsd:complexType name="CorticonResponseType"> <xsd:sequence> <xsd:element name="WorkDocuments" type="tns:WorkDocumentsType" /> <xsd:element name="Messages" type="tns:MessagesType" /> </xsd:sequence>
The Decision Service Name has been automatically included here:

<xsd:attribute name="decisionServiceName" use="required" fixed="tutorial_example" type="xsd:string" /> <xsd:attribute name="decisionServiceTargetVersion" use="optional" type="xsd:nonNegativeInteger" /> <xsd:attribute name="decisionServiceEffectiveTimestamp" use="optional" type="xsd:dateTime" /> </xsd:complexType> <xsd:complexType name="WorkDocumentsType"> <xsd:choice maxOccurs="unbounded"> <xsd:element name="Cargo" type="tns:CargoType" /> </xsd:choice>
Cargo is the WDE, so it is mandatory notice no minOccurs attribute is present.

Server Integration & Deployment Guide 5.2 HIER message style:
Page 140
<xsd:attribute name="messageType" fixed="HIER" use="optional" /> </xsd:complexType> <xsd:complexType name="MessagesType"> <xsd:sequence> <xsd:element name="Message" type="tns:MessageType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> <xsd:attribute name="version" type="xsd:string" /> </xsd:complexType> <xsd:complexType name="MessageType"> <xsd:sequence> <xsd:element name="severity"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="Info" /> <xsd:enumeration value="Warning" /> <xsd:enumeration value="Violation" /> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="text" type="xsd:string" /> <xsd:element name="entityReference"> <xsd:complexType> <xsd:attribute name="href" type="xsd:anyURI" /> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:complexType name="CargoType"> <xsd:sequence> <xsd:element name="container" type="xsd:string" nillable="false" minOccurs="0" /> <xsd:element name="needsRefrigeration" type="xsd:boolean" nillable="true" minOccurs="0" /> <xsd:element name="volume" type="xsd:long" nillable="false" minOccurs="0" /> <xsd:element name="weight" type="xsd:long" nillable="false" minOccurs="0" /> </xsd:sequence> <xsd:attribute name="id" type="xsd:ID" use="optional" /> <xsd:attribute name="href" type="xsd:anyURI" use="optional" /> </xsd:complexType> </xsd:schema> </types> <message name="CorticonRequestIn"> <part name="parameters" element="cc:CorticonRequest" /> </message> <message name="CorticonResponseOut"> <part name="parameters" element="cc:CorticonResponse" /> </message> <portType name="tutorial_exampleSoap">
Page 141
<operation name="processRequest"> <input message="tns:CorticonRequestIn" /> <output message="tns:CorticonResponseOut" /> </operation> </portType> <binding name="tutorial_exampleSoap" type="tns:tutorial_exampleSoap"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" /> <operation name="processRequest"> <soap:operation soapAction="urn:Corticon" style="document" /> <input> <soap:body use="literal" namespace="urn:Corticon" /> </input> <output> <soap:body use="literal" namespace="urn:Corticon" /> </output> </operation> </binding> <service name="tutorial_example"> <documentation /> <port name="tutorial_exampleSoap" binding="tns:tutorial_exampleSoap"> <soap:address location="http://localhost:8082/axis/services/Corticon" /> </port> </service> </definitions>
Sample CorticonRequest Content

A sample CorticonRequest payload is shown below. It is a Decision-Service-level message which means that only those Vocabulary terms used in the Decision Service are contained in the CorticonRequest. It is also HIER XML messaging style. Notice the Decision Service Name in the CorticonRequest:
<CorticonRequest xmlns=" urn:decision:tutorial_example " xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" decisionServiceName="tutorial_example">
Notice the unique ids for every entity. If not provided by the client, Corticon Server will add them automatically to ensure uniqueness:
<WorkDocuments> <Cargo id="Cargo_id_1">
Attribute data is inserted as follows:

<volume>40</volume> <weight>16000</weight> </Cargo> </WorkDocuments> </CorticonRequest>
January 13, 2012
Page 142
Sample CorticonResponse Content

Notice the Decision Service Name in the CorticonResponse this informs the consuming application (which may be consuming several Decision Services asynchronously) which Decision Service is responding in this message:
<CorticonResponse decisionServiceName="tutorial_example" xmlns="urn:Corticon" xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance"> <WorkDocuments> <Cargo id="Cargo_id_1"> <volume>40.000000</volume> <weight>16000.000000</weight
Notice that the optional newOrModified attribute has been set to true, indicating that container was modified by the Business Rules Server. The value of container, oversize, is the new data derived by the Decision Service.
<container newOrModified="true">oversize</container> </Cargo> </WorkDocuments> </CorticonResponse>
January 13, 2012
Server Integration & Deployment Guide 5.2 The data contained in the CorticonRequest is returned in the CorticonResponse:
<volume>400.000000</volume> <weight>160000.000000</weight> </cargo> </FlightPlan> </WorkDocuments> <Messages version="1">
Page 143
Notice the message generated and returned by the Server:

<Message> <severity>Info</severity> <text>Cargo weighing between 150,000 and 200,000 lbs must be carried by a 747.</text>
The entityReference contains an href that associates this message with the FlightPlan that caused it to be produced
<entityReference href="#FlightPlan_id_1"/> </Message> </Messages> </CorticonResponse>
January 13, 2012
Page 144
APPENDIX B: API SUMMARY

The Corticon Business Rules Management API set is fully defined in the JavaDoc provided separately from the installation kit. The JavaDoc is the official documentation of the API set. It may be updated from time to time in point releases. Readers are encouraged to consult the JavaDoc for the latest details.
January 13, 2012
Page 145
APPENDIX C: CORTICON BUSINESS RULES MANAGEMENT PROPERTIES & SETTINGS

There are five sets of property files used by Corticon Business Rules Management software, as shown in the table below. Corticon software uses property files to control most user-configurable behaviors in Studio and Server. All property files are essentially just text files that are automatically read when Studio and Server are started.
CONTROLLING CORTICON STUDIO

Default property settings are built-in to Studio. If you want to modify any of these property settings, you must create an override file named brms.properties and copy it to <corticon_install_dir>\Studio\configuration\com.corticon.brms. When Studio starts up, it will read this file and override any default settings with yours. Note, the property settings you add in brms.properties replace corresponding properties built-in to Studio. They do not append to the existing list. So if you want to add a new DateTime mask to the built-in list, for example, be sure to include all the masks you intend to use, not just the new one. If your brms.properties file contains only the new mask, then it will be the only mask Studio uses.
CONTROLLING CORTICON SERVER

Property files are collected into a single file named CcConfig.jar, located in <corticon_install_dir>\Server\lib\CcConfig.jar. The properties within these files can be changed by editing them directly with a text editor, or, in some cases, with API calls (see the API reference in Appendix B of this document). When the files themselves are changed, the settings remain in effect between Corticon Server sessions. When property settings are changed using APIs, the changes only remain in effect for that Corticon Server session. When Corticon Server starts a new session, it will use the settings in CcConfig.jar. Be sure to shut down or exit Corticon Studio or Server before making changes to these properties, and then restart for the changes to take effect. Property File Name
CcCommon.properties
Usage
Modifies the behavior of elements common to both the Corticon Studio and Server. Modifies behavior of the Corticon Deployment Console. Modifies behavior of Corticon Studio . Used to re-brand Corticon components for certain OEM customers. These properties are not described here because end users
CCDeployment.properties CcStudio.properties CcOem.properties
January 13, 2012

have no need to modify them. CcServer.properties Controls how Corticon Server operates.
Page 146
Properties are described in detail below. Actual property names and settings are shown in bold type, and explanatory comments in plain text.
COMMON PROPERTIES (CCCOMMON.PROPERTIES)

Properties used by Both Studio and Server
These properties deal with the way Corticon Studio and Server handle date/time formats. Preset formats, or masks are used to: Process incoming date/times on request XML payloads. Insert date/times into output response XML payloads. Parse entries made in the Studio Rulesheets, Vocabulary, and Tests. To display any date/time in Studio.
Masks are divided into 3 categories: dateformat, datetimeformat, timeformat. Use the following chart to decode the date mask formats: The following symbols are used in date/time masks: Symbol
G y
Meaning Era Designator Year Month of the year
Presentation Text Number Text or Number G = {AD, BC}
Patterns yy = {00..99} yyyy = {0000..9999} M = {1..12} MM = {01..12} MMM = {Jan..Dec} MMMM = {January..December} d = {1..31} dd = {01..31} h = {1..12} hh = {01..12} H = {0..23} HH = {00..23} m = {0..59}
day of the month hour in AM or PM hour in 24-hour format (023) minute of the hour
Number Number Number Number
January 13, 2012
Server Integration & Deployment Guide 5.2 mm = {00..59}

s
Page 147
second of the minute millisecond of the minute day of the week day of the year day of week in the month week of the year week of the month AM/PM marker hour of the day (1-24) hour in AM/PM time zone escape character used to insert text single quote
Number Number Text Number Number Number Number Text Number Number Text Delimiter Literal
s = {0..59} ss = {00..59} S = {0..999} SSS = {000..999} E, EE, or EEE = {Sun..Sat} EEEE = {Sunday..Saturday} D = {0..366} DDD = {000..366} F = {0..6} w = {1..53} ww = {01..53} W = {1..6} a = {AM, PM} k = {1..24} kk = {01..24} K = {1..12} KK = {01..12} z, zz, or zzz = abbreviated time zone zzzz = full time zone
F w
W a k
Any characters in the pattern that are not in the ranges of [a..z] and [A..Z] will be treated as quoted text. For instance, characters like {:, ., <space>, #, @} will appear in the resulting time text even they are not embraced within single quotes. A pattern containing any invalid pattern letter will result in a thrown exception during formatting or parsing. Examples: Sample Pattern
yyyy.MM.dd G 'at' hh:mm:ss z EEE, MMM d, ''yy h:mm a
Resulting Formatted Date 1996.07.10 AD at 15:08:56 PDT Wed, Jul 10, '96 12:08 PM
January 13, 2012

hh 'o''clock' a, zzzz K:mm a, z yyyy.MMMM.dd G h:mm a
Page 148 12 o'clock PM, Pacific Daylight Time 0:00 PM, PST 1996.July.10 AD 12:08 PM
Valid Date/Time Formats Studio uses the DateTime datatype to contain both data and time data. The Date datatype handles only date information, and the Time datatype handles only time information. It's also noteworthy that the Corticon XML Translator will maintain the consistency of DateTime, Date, and Time values from input to output documents so long as the masks used are contained in the lists. The first entry for each dateformat, datetimeformat, and timeformat is the default mask. For example, the built-in operator today always returns the current date in the default dateformat mask. The function now returns the current date in the default datetimeformat. The entries can be altered but must conform to the patterns/masks supported by Java class SimpleDateFormat in java.text package.
com.corticon.crml.OclDate.dateformat= MM/dd/yy MM/dd/yyyy M/d/yy M/d/yyyy yyyy/MM/dd yyyy-MM-dd yyyy/M/d yy/MM/dd yy/M/d MMM d, yyyy MMMMM d, yyyy com.corticon.crml.OclDate.datetimeformat= MM/dd/yy h:mm:ss a; MM/dd/yyyy h:mm:ss a; M/d/yy h:mm:ss a; M/d/yyyy h:mm:ss a; yyyy/MM/dd h:mm:ss a; yyyy/M/d h:mm:ss a; yy/MM/dd h:mm:ss a; yy/M/d h:mm:ss a; MMM d, yyyy h:mm:ss a; MMMMM d, yyyy h:mm:ss a;
January 13, 2012
Page 149
MM/dd/yy H:mm:ss; MM/dd/yyyy H:mm:ss; M/d/yy H:mm:ss; M/d/yyyy H:mm:ss; yyyy/MM/dd H:mm:ss; yyyy/M/d H:mm:ss; yy/MM/dd H:mm:ss; yy/M/d H:mm:ss; MMM d, yyyy H:mm:ss; MMMMM d, yyyy H:mm:ss; MM/dd/yy hh:mm:ss a; MM/dd/yyyy hh:mm:ss a; M/d/yy hh:mm:ss a; M/d/yyyy hh:mm:ss a; yyyy/MM/dd hh:mm:ss a; yyyy/M/d hh:mm:ss a; yy/MM/dd hh:mm:ss a; yy/M/d hh:mm:ss a; MMM d, yyyy hh:mm:ss a; MMMMM d, yyyy hh:mm:ss a; MM/dd/yy HH:mm:ss; MM/dd/yyyy HH:mm:ss; M/d/yy HH:mm:ss; M/d/yyyy HH:mm:ss; yyyy/MM/dd HH:mm:ss; yyyy/M/d HH:mm:ss; yy/MM/dd HH:mm:ss; yy/M/d HH:mm:ss; MMM d, yyyy HH:mm:ss; MMMMM d, yyyy HH:mm:ss; MM/dd/yy h:mm:ss a z; MM/dd/yyyy h:mm:ss a z; M/d/yy h:mm:ss a z; M/d/yyyy h:mm:ss a z; yyyy/MM/dd h:mm:ss a z; yyyy/M/d h:mm:ss a z; yy/MM/dd h:mm:ss a z; yy/M/d h:mm:ss a z;
January 13, 2012

MMM d, yyyy h:mm:ss a z; MMMMM d, yyyy h:mm:ss a z; MM/dd/yy H:mm:ss z; MM/dd/yyyy H:mm:ss z; M/d/yy H:mm:ss z; M/d/yyyy H:mm:ss z; yyyy/MM/dd H:mm:ss z; yyyy/M/d H:mm:ss z; yy/MM/dd H:mm:ss z; yy/M/d H:mm:ss z; MMM d, yyyy H:mm:ss z; MMMMM d, yyyy H:mm:ss z; MM/dd/yy hh:mm:ss a z; MM/dd/yyyy hh:mm:ss a z; M/d/yy hh:mm:ss a z; M/d/yyyy hh:mm:ss a z; yyyy/MM/dd hh:mm:ss a z; yyyy/M/d hh:mm:ss a z; yy/MM/dd hh:mm:ss a z; yy/M/d hh:mm:ss a z; MMM d, yyyy hh:mm:ss a z; MMMMM d, yyyy hh:mm:ss a z; MM/dd/yy HH:mm:ss z; MM/dd/yyyy HH:mm:ss z; M/d/yy HH:mm:ss z; M/d/yyyy HH:mm:ss z; yyyy/MM/dd HH:mm:ss z; yyyy/M/d HH:mm:ss z; yy/MM/dd HH:mm:ss z; yy/M/d HH:mm:ss z; MMM d, yyyy HH:mm:ss z; MMMMM d, yyyy HH:mm:ss z com.corticon.crml.OclDate.timeformat= h:mm:ss a h:mm:ss a z H:mm:ss H:mm:ss z hh:mm:ss a
Page 150
January 13, 2012

hh:mm:ss a z HH:mm:ss HH:mm:ss z com.corticon.crml.OclDate.permissive=true
Page 151
If permissive is true (default), then the Corticon date/time parser will be lenient when handling incoming or entered date/times, trying to find a match even if the pattern is not contained in the mask lists. If false, then any incoming or entered date/time must strictly adhere to the patterns defined by dateformat, datetimeformat, timeformat. Default patterns are for United States and other countries that follow the US conventions on date/times.
com.corticon.crml.OclDate.maskliterals=true
If maskliterals is true (default), the system will parse strings and dates more quickly by checking for the presence of mask literals (e.g., "/", "-", ":" or ",") before consulting the date masks (an expensive process). If a string does not contain any of the mask literal characters, it can be immediately deemed a string (as opposed to a date). To take advantage of this feature, all user-specified date masks must contain at least one literal character. If any user-specified masks contain exclusively date pattern characters (e.g., "MMddyy"), maskliterals must be set to false in order to prevent the system from misinterpreting date literals (e.g., '123199') as simple strings.
logpath=%CORTICON_HOME%/Log logverbosity=VERBOSE loglevel=VIOLATION com.corticon.logging.thirdparty.logger.class=
These 4 properties deal with logging performed by Corticon Server. logpath assigns the directory to which logs are written and saved. By default the value of
%CORTICON_HOME%=<corticon_install_dir> logverbosity options:
VERBOSE : Logging is on. Logged Exceptions include stack trace. Default. BRIEF : Logging is on. Logged Exceptions do NOT include stack trace. SILENT : Turns off all logging. Maximizes Corticon Server performance. DEBUG : All messages are logged, including debugging info. To be used only at the
loglevel options:
direction of Progress technical support. Never deploy Corticon Server in production with loglevel set to DEBUG. Log files created in this mode may become very large and slow down Corticon Servers performance by orders of magnitude.
Page 152
INFO : All messages except debugging messages are logged. Never deploy Corticon Server in production with loglevel set to INFO. Log files created in this mode may
become very large and slow down Corticon Servers performance by orders of magnitude.
RULETRACE : Logs performance statistics (e.g., total time for rule execution,
percentage of time on each Rulesheet, etc.) and information on what specific rules were fired (not just evaluated). Do not deploy Corticon Server in production with loglevel set to RULETRACE. While log files are not nearly as large as those generated in DEBUG or INFO modes, they still require time to write, and therefore slow Corticon Server performance.
VIOLATION : Only Exceptions are logged. Recommended for deployment because it
maximizes Corticon Server performance. Default.

com.corticon.logging.thirdparty.logger.class Enables a third-party logger to be used for
all logging. The new Logger would need to implement the com.corticon.log.ICcThirdPartyLogger Interface. If the property is empty, then logging will default back to the Corticon Logger. To use Corticon's Log4JLogger, specify the following logger class for this property: com.corticon.log.CcLog4JLogger
decimalscale=6
This property handles the default precision for Decimal values in Corticon Studio and Server. All Decimal values are rounded to the specified number of places to the right of the decimal point. Default is 6 (e.g. 4.6056127 will be rounded, displayed, and/or returned as 4.605613).
enableNewOrModified=false
Determines whether XML responses from Corticon Server include newOrModified attributes indicating which elements of the XML document are new or have been modified. This flag also impacts the generation of service contracts (XSD, WSDL). Setting the flag to false results in more mainstream XML messaging without the newOrModified attributes. Default value is false.
com.corticon.ccserver.ensureComplianceWithServiceContract=true
Determines whether the returning XML CorticonResponse document must be valid with respect to the generated XSD/WSDL file. Ensuring compliance may require dynamic sorting which, if necessary, will slow performance. Default value is true (ensure compliance and perform the sorting, if necessary).
com.corticon.crml.OclDate.defaultDateForTimeValues=1970-01-01 com.corticon.crml.OclDate.defaultDateFormatForTimeValues=yyyy-MM-dd
Determines the "Default Date" to be used when instantiating or converting to Time data values. It is important that this property matches the database date and date format so that there is consistency
January 13, 2012
Page 153
between Time values inserted into the database directly and those inserted into the database by rules. Default Date value: 1970-01-01. Default DateFormat value: yyyy-MM-dd
com.corticon.jdom.translation.textmode=NORMALIZE
Determines the type of Corticon translation from JDOM to String. Different settings will yield different results.
NORMALIZE : Mode for text normalization (left and right trim plus internal
whitespace is normalized to a single space.

TRIM_FULL_WHITE : Mode for text trimming of content consisting of nothing but
whitespace but otherwise not changing output.

TRIM : Mode for text trimming (left and right trim). PRESERVE : Mode for literal text preservation.
Default is NORMALIZE
com.corticon.validate.on.load=true
Determines whether the Foundation APIs will perform automatic validation of assets when they are loaded. API-controlled validation can help improve performance by validating assets only when necessary. If this flag is set to true, the APIs will validate assets at load time if: New validation rules have been added to the APIs. Related assets have been changed in a manner that justifies revalidation.
For example, if a Rulesheets Vocabulary has been changed, the API will automatically revalidate the Rulesheet to ensure that all Rulesheet expressions are valid with respect to the Vocabulary changes. If this flag is set to false, the APIs will not perform any validation when the asset is loaded; thus, the GUI is required to explicitly call the validate API during editor initialization. Default is true.
com.corticon.validate.on.activation=false
Determines whether the Foundation APIs will defer interdependency validation until asset activation. Normally, the APIs immediately revalidate assets within the editing domain as related assets are modified; however, when a large number of interrelated assets are open simultaneously, this instantaneous revalidation may degrade performance. If this flag is set to true, the APIs will defer revalidation of assets until they are explicitly "activated" via method IModelAPI.activate(), typically when a GUI editor gains the focus. The activate method causes the API to trigger deferred validations if any are pending due to changes in related assets. Default is false.
January 13, 2012
Page 154
com.corticon.localization.setsupportedlocales.swap=true Determines whether foundation API method setSupportedLocales will automatically rearrange
localizations, potentially changing the base locale of the asset. The default setting (true) will cause the API to automatically swap localized values into the base slot if the base locale in the input array is different from the asset base language. This allows the client program to designate what was originally an added (non-base) locale as the new base locale of the asset; however, this setting also imposes a precondition: when setSupportedLocales is called, the asset must contain complete localizations for every localizable element, or the API will throw an exception. This precondition is imposed because the API contract always requires a base value for every localizable element; while localizations are optional, a base value must never be null. If this flag is set to false, the system will allow the client program to indiscriminately change the set of supported locales without preconditions. In this mode, the system will arbitrarily update the asset's language legend and will remove any localizations while leaving the base values unchanged. While this ensures that API contract is not violated (because the base values remain unaffected), it puts the onus on the client program to "manually" update all base values and localizations to match the specified locale array; failure to do so may leave the language legend and localizations out of synch. Default is true.
com.corticon.vocabulary.cache=true
Determines whether the Vocabulary API will use a hash map to speed up Vocabulary element lookups. This can improve Rulesheet parsing performance, particularly for applications with larger Vocabularies. Default is true.
com.corticon.validation.checksum.propertylist=com.corticon.crml.OclDate.date format;com.corticon.crml.OclDate.datetimeformat;com.corticon.crml.OclDate.ti meformat;com.corticon.crml.OclDate.permissive;com.corticon.crml.OclDate.mask literals;decimalscale;com.corticon.crml.OclDate.defaultDateForTimeValues;com .corticon.crml.OclDate.defaultDateFormatForTimeValues;com.corticon.validate. on.load;com.corticon.validate.on.activation;com.corticon.localization.setsup portedlocales.swap
This is a list of Corticon Properties that will be used in the Checksum Calculations during the Post Load of the Models. This will help determine if we need to revalidate the Model.
com.corticon.migration.vocabulary.mandatory.flag=false
In this release, the value of an attributes mandatory property has an impact on engine behavior at runtime, whereas in v4 this was not the case. As a result, migration of v4 assets to this version may result in rule execution behavior that is inconsistent with v4. This property can be used to control this behavior. Here are the allowed values:
preserve : Preserves mandatory property values in migrated asset true : Unconditionally set all mandatory property values to true
January 13, 2012

false : Unconditionally set all mandatory property values to false
Page 155
Default value is false.
com.corticon.reactor.rulebuilder.maxloops=100
Set max loop interation. Determines what constitutes an endless loop. For .ers files with the Process Logical Loops setting on, it is necessary to have a safety net to prevent endless loops. This is done by designating the maximum number of iterations allowed for any loop. Default is 100.
com.corticon.reactor.rulebuilder.exception=raise
Set maxloop exception handling {raise, bury}. Specifies whether the rule engine will raise a MaxLoopsExceededException if the maximum number of loop iterations is exceeded. Default value is raise.
com.corticon.reactor.engine.CheckForAssociationDuplicates=true
Specifies whether the rule engine conducts an integrity check when adding to an existing association. This integrity check ensures that rules do not add redundant associations between the same two entities. Although, this is a rare that occurrence, it is possible. The downside of this integrity check is that Decision Services that create a significant number of new associations can experience a performance degradation. Such Decision Services would require this configuration property to be set to false. Default value is true.
CORTICON DEPLOYMENT CONSOLE PROPERTIES (CCDEPLOYMENT.PROPERTIES)

Properties Used by Deployment Console
com.corticon.deployment.supportBPELinWSDLgeneration=false
Support BPEL in WSDL generation. Used to add a partnerlink section to the generated WSDL to make them BPEL compliant. Default is false.
com.corticon.xml.addDefaultNamespace=true
Adds the default namespace declaration to WSDL generation.
com.corticon.schemagenerator.addDefaultNamespace=true
Adds the default namespace declaration to XSD generation.
January 13, 2012
Page 156
com.corticon.deployment.soapbindingurl_1=http://localhost:8082/axis/services /Corticon
This setting determines the default value of URL used by the Deployment Console. It does NOT determine where Studio looks when testing remote Decision Services (see Controlling Corticon Studio for instructions on changing remote Server locations in Studio). Other listed options include default port settings for other common web or application servers. Defaults are http://localhost:8082/axis/services/Corticon (typically used by the bundled Tomcat Server).
com.corticon.deployment.soapbindingurl_2=http://localhost:9080/axis/services /Corticon (typically used by IBM WebSphere) com.corticon.deployment.soapbindingurl_3=http://localhost:7001/axis/services /Corticon (typically used by Oracle/BEA WebLogic)
com.corticon.deployment.schema.useChoice=true
This property controls whether <choice> or <sequence> tags are used for the <WorkDocuments> section of the generated XSD/WSDL. When useChoice is set to true, <choice> tags are used which results in more flexibility in the order in which entity instances appear in the XML/SOAP message. When useChoise is set to false, <sequence> tags are used which requires that entity instances appears in the same order as they appear in the <WorkDocuments> section of the XSD/WSDL. Some Web Services platforms do not properly support <choice> tags. For these platforms, this property should be set to false. Default is true.
com.corticon.servicecontracts.ensureComplianceWithDotNET_WCF=false
Determines whether generated service contracts (WSDL/XSD) are compliant with Microsoft .NET WCF. This property must be set to true when Corticon Server is deployed inside a Microsoft WCF container. Note: WSDLs meant for .NET consumption should be generated in Hier XML Messaging Style. Default is false.
com.corticon.ccdeployment.sandboxDir=%CORTICON_HOME%/CcDeploymentSandbox
Determines the path to an existing directory used exclusively by the Deployment Console to precompile Ruleflow files into .eds files. Default is %CORTICON_HOME%/DecisionServerSandbox. Note, this is not the same property as the sandboxDir used in CcServer.properties.
com.corticon.deployment.ensureUniqueTargetNamespace=true
This property will tell the XSD and WSDL Generators to create unique Target Namespaces inside the output document.
January 13, 2012
Page 157
If the property is set to true, the following template will be used to create the Target Namespaces for the XSD and WSDL Documents: XSD: urn:decision/<Decision Service Name> WSDL: <soap binding uri>/<Decision Service Name>
If the property is set to false, the following template will be used to create the Target Namespaces for the XSD and WSDL Documents: XSD: urn:Corticon WSDL: urn:CorticonService
Default is true. For backwards compatibility with Corticon Server version 5.1 and earlier, use false.
CORTICON STUDIO PROPERTIES (CCSTUDIO.PROPERTIES)

Properties Used by Studio Only
com.corticon.eclipse.tester.message.use.swt.table=true
Not user configurable.
com.corticon.designer.undoredo.stack.size=3
Specifies the size of the undo/redo stack. This number corresponds to the number of undo/redo operations the system will permit. Default is 3.
com.corticon.designer.corticon.insertrowstoend=10
Determines the number of rows that are added to the end of a Rulesheet section when Rulesheet>Add Rows to End is selected from the Studio menubar or popup menu. Default is 10.
com.corticon.designer.corticon.insertcolumnstoend=10
Determines the number of columns that are added to the end of a Rulesheet section when Rulesheet>Add Columns to End is selected from the Studio menubar or popup menu. Default is 10.
fileHistoryCount=10
Determines the number of opened files that are persisted in the file history list. This determines the maximum number of files that appear when File>Reopen is selected from the Studio menubar. Default value is 10.
January 13, 2012
Page 158
dir.uri.Report=%corticonbase%/Report
Determines the directory where the XML-based reporting files (XSL, XSD, HTML, XML) are located. By default, the normal value of %corticonbase% is <corticon_install_dir>/Report
com.corticon.designer.vocabulary.autofill.objectPropertyAutoFillCollectionTy pe=Vector com.corticon.designer.vocabulary.autofill.useIsMethodForBoolean=false
Determines the parameters used by by Vocabulary|Auto-Fill Object Properties function. objectPropertyAutoFillCollectionType determines Object Collection Type when a x-to-many association end is encountered. There are three possible values:
Vector for java.util.Vector Array for Java arrays (e.g. A[]) ArrayList for java.util.ArrayList
If useIsMethodForBoolean is false then the system generates a getXYZ for a property of type Boolean. If it is true then the system generates a isXYZ in the Getter field for a property of type Boolean. Note: the Setter is not impacted by this flag. Default value for objectPropertyAutoFillCollectionType is Vector Default value for useIsMethodForBoolean is false
com.corticon.encoding.standard=UTF-8
Default character encoding for Studio objects, such as Vocabulary, Rulesheet and Ruletest XML files. Examples: UTF-8, UTF-16, ISO-8859-1, US-ASCII. Default value is UTF-8.
com.corticon.designer.useTextualRulesheetTestsheetStatusIndicator=false
Determines whether [Invalid] and [Disable] text will be added to Rulesheet and Ruletest tab names to help users who have difficulty seeing the red and gray colors. Default value is false.
com.corticon.designer.valuesets.compressLargeSetsUsingNot=false
Determines whether Conditional rule column value sets are automatically converted to their logically equivalent negated form upon Rulesheet collapse or compression. This is done in order to compress the value set down to a more manageable size. If the flag is set to true and a value set contains at least 2/3 of the possible Values for the condition then the system converts it to the negated form.
xmi.import.ecore.readonlyflag.default=true
January 13, 2012
Page 159
Determines whether Vocabulary property values are read-only when the Vocabulary is in edit mode. Read-only values are displayed with a light gray background to differentiate them from modifiable values. Read-only true means values are not modifiable. Read-only false means values are modifiable. Default value: true.
com.corticon.eclipse.platform.io.useuuids=false
Determines whether serialized versions of emf resources use Universally Unique IDs (UUIDs AKA GUIDs) or URI strings to reference other serialized elements. One reason to use UUIDs is to keep related resources in sync if they are moved to different locations. Use of URI strings will only work if the elements are always kept in the same relative locations. The value true means, yes, use UUIDs, while the value false means use URI strings. Default value: false.
com.corticon.tester.ccserver.maxdecisionservices=15
Specifies the max number of Decision Services generated through Tester API that can reside on the Server at one time. Default value is 15.
com.corticon.localize.expressions=true
Specifies whether the logic used to localize rule expressions will be invoked (true) or not (false). Default value is true.
com.corticon.tester.associations.includedomainandtype=true
Specifies whether test tree node association text will display domain and target entity type information. Default value is true.
com.corticon.studio.migration.datesubtype.default=Full DateTime
Specifies what current Date Data that will be mapped to a 4.1 Date Datatype, which doesn't contain a Subtype. Default value is Full DateTime. Other options include Date Only and Time Only.
com.corticon.eclipse.ui.dropdowns.visiblerows=10
Specifies the number of visible rows in a Drop Down Combo Box. Default value is 10.
com.corticon.studio.swt.virtualization=false
Specifies whether SWT virtualization will be enabled. SWT virtualization can improve the initial load times of larger Ruletest assets by deferring the creation of tree items until they are actually needed. Default value is false.
Page 160
com.corticon.designer.tested.xmlmessagingstyle=hier
This property sets the Studio Tests XML messaging style to one of the following: Hier (hierarchical) Flat Autodetect
These are exactly equivalent to the messaging styles selectable in the Deployment Descriptor file, described here.
com.corticon.crml.CrmlGraphVisualizer.fontname=arial.ttc com.corticon.crml.CrmlGraphVisualizer.fontsize=9
This properties set the font type and size used by the Graphic Visualizer. Default values are arial.ttc and 9, respectively.
com.corticon.eclipse.ui.completeness.check.autosize=true
Specifies whether columns added via the Completeness Checker will be automatically sized based on the data in the columns. Default value is true.
CORTICON SERVER PROPERTIES (CCSERVER.PROPERTIES)

Properties Used Solely by Business Rules Server
com.corticon.ccserver.sandboxDir=%CORTICON_HOME%/CcServerSandbox
Determines the path to an existing directory used exclusively by Server to persist and retrieve deployment assets. If the path does not exist, the Server attempts to automatically create it. If this fails then the Server is unable to startup. Default is %CORTICON_HOME%/CcServerSandbox
com.corticon.ccserver.serviceIntervals=30000
Server has a maintenance service that is tasked with keeping the state of the Decision Service pools upto-date. The serviceIntervals property determines the number milliseconds elapsed in between service cycles during which Server checks for: Changes in any .cdd loaded to Server by a loadFromCdd or loadFromCddDir call Changes in any .cdd file including new cdds within the directory of cdds from a loadFromCddDir call
January 13, 2012
Page 161
Changes in any of the Decision Services (.erf files) loaded to the server. This is done via a timestamp check.
If any changes are detected, Server's state is dynamically updated to reflect the changes. Note: The maintenance service can be shutdown and restarted using:
ICcServer.stopDynamicaUpdateMonitoringService() ICcServer.startDynamicUpdateMonitoringService()
Default for serviceIntervals is 30 secs (30000 ms)
com.corticon.ccserver.inactivity=60000
Amount of time (in milliseconds) that a Reactor can remain idle before it's eligible for reclamation by the JVMs garbage collection mechanism. Each Decision Service has pooling parameters for minimum & maximum pool sizes. The pool is initialized to the minimum number of Reactors and grows to meet demand until maximum pool size is reached. When the level of demand drops, any Reactors in the pool that remain idle for the specified period are removed from the pool until the minimum size is reached. This process releases resources and reduces the memory footprint of Corticon Server. Default is 60000 milliseconds (60 seconds).
com.corticon.ccserver.dynamicupdatemonitor.autoactivate=true
Determines whether the Dynamic Update Monitor Service should be started automatically when Server is initialized. Default is true (Starts the Update Monitor Service automatically).
com.corticon.ccserver.servermessages=false
Determines whether to display Server messages to System.out, reflecting the state of the Decision Service pools in Server at initialization and update times. The state of the "wait" queues as well as the Reactor allocations are also reflected. This is primarily a debugging property to be used under instructions from Progress technical support. Default is false (no messages).
com.corticon.ccserver.validateSchema=true
Determines whether the server will invoke the JPOX metadata validation service at Ruleset deployment time. If this property is set to true the service will compare the external JDO document with the database metadata and will prevent deployment if any discrepancies are detected. Default is true.
com.corticon.reactor.rulebuilder.maxloops=100
Set max loop interation. Determines what constitutes an endless loop. For .ers files with the Process Logical Loops setting on, it is necessary to have a safety net to prevent endless loops. This is done by designating the maximum number of iterations allowed for any loop. Default is 100.
Page 162
com.corticon.reactor.rulebuilder.exception=raise
Set maxloop exception handling {raise, bury}. Specifies whether the rule engine will raise a MaxLoopsExceededException if the maximum number of loop iterations is exceeded. Default value is raise.
com.corticon.ccserver.compiler.javahome.location=
Specifies the location of the JRE that will be used by the Server to compile the Ruleflows into Decision Services. If not specified, the Server will use the same JRE that started the Server by calling into System.getProperty("java.home"). Default value is looked up using System.getProperty("java.home").
com.corticon.cdolistener.collectionmapping=java.util.Vector com.corticon.cdolistener.listmapping=java.util.ArrayList com.corticon.cdolistener.setmapping=java.util.HashSet
Specify which implementation class to be used when a supported interface is used for an association inside the user's mapped Business Object. This is needed by the BusinessObject Listener class, which is compiled during Decision Service deployment. Supported interfaces include: java.util.Collection java.util.List java.util.Set
Default values are: java.util.Collection=java.util.Vector java.util.List=java.util.ArrayList java.util.Set=java.util.HashSet
com.corticon.server.compile.classpath.include.bos=true
Specify whether the Decision Service compile process should dynamically detect the location of the Jars where the Java Business Objects reside. Primary focus is to incorporate customer Java Business Objects in the Ant Classpath so that Listener Generation will succeed. Default value is true.
com.corticon.server.compile.classpath.include.alljarsunderccserver=false
Specify whether the Decision Service compile process should include all the Jars that are in the same directory as the CcServer.jar in the Ant Compile Classpath. This may need to be set to true dependent on the type of Application Server the Decision Services are deployed on. Primary focus is to incorporate customer Java Business Objects in the Ant Classpath so that Listener Generation will succeed. Default value is false.
Page 163
com.corticon.reactor.engine.CheckForAssociationDuplicates=true
Specifies whether the rule engine conducts an integrity check when adding to an existing association. This integrity check ensures that rules do not add redundant associations between the same two entities. Although, this is a rare that occurance, it is possible. The downside of this integrity check is that Decision Services that create a significant number of new associations can experience a performance degradation. Such Decision Services would require this configuration property to be set to false. Default value is true.
com.corticon.reactor.rulebuilder.UseLoopContainerStrategy=false
Specifies whether the rule engine uses Loop Container Strategy. Loop Container Strategy will create a Rule container object for rules that form a loop, just as when loops are enabled, so that when sequential rules are executed they are executed as if they are in a loop, but without looping. Default value is true.
com.corticon.BuildWaitTime=300000
Specifies the amount of time in milliseconds that the Ant build processor will wait before automatically timing out. Default value is 300000 (5 minutes).
com.corticon.ccserver.batch.retrieveCount=100000
Determines how many records will be retrieve at one time during batch process. The batch process retrieves Work Document Entity records from the database in increments of <batch.retrieveCount> and processes them one at a time. Batch process will continue to retrieve records using this property until all records have been retrieved and processed. Default value is 100000.
com.corticon.ccserver.batch.commitFrequency=100
Determines how frequently a transaction commit is performed during a batch process. The batch process retrieves Work Document Entity records from the database and processes them one at a time. After every <batch.commitFrequency> records a commit is performed. This frequency can be adjusted to achieve better performance and improve batch processing times. Default value is 100.
com.corticon.ccserver.tempdirectorypath=%corticonbase%/Temp/Server com.corticon.ccserver.tempdirectorycleanup=true
Server Temp Directory Settings. When Database Access is enabled, temp files need to be created to facilitate Tester execution using JPOX. The user will be able to specify the directory where these files are created. The user can also instruct the CcServer to cleanup all old Temp files out of the tempdirectorypath when it first gets initialized.
January 13, 2012
Page 164
Default for tempdirectorypath is %corticonbase%/Temp/Server Default for tempdirectorycleanup is true
com.corticon.server.monitoring.decisionservice.record.times=false com.corticon.server.monitoring.decisionservice.record.times.total=100
These properties are related to Decision Service/Version level monitoring.

com.corticon.server.monitoring.decisionservice.record.times specifies whether the
Server will auto-start recording time measurements. Note: The performance monitoring service can also be shutdown and restarted using the following methods, which will override this setting.
ICcServer.stopServerPerformanceMonitoringService() ICcServer.startServerPerformanceMonitoringService()
Default value is false

com.corticon.server.monitoring.decisionservice.record.times.total is the number
of execution times to be stored for each Decision Service/Version Default value is 100
com.corticon.server.monitoring.decisionservice.record.date=false com.corticon.server.monitoring.decisionservice.record.data.registration.deli miter=; com.corticon.server.monitoring.decisionservice.record.data.bucket.registrati on.delimiter=, com.corticon.server.monitoring.decisionservice.record.data.bucket.results.de limiter=:
Properties related to Decision Service/Version level monitoring.

com.corticon.server.monitoring.decisionservice.record.data specifies whether
Corticon Server will auto-start recording time measurements. Note: The data recording monitoring service can be shutdown and restarted using the following API methods, which will override this setting.
ICcServer.stopServerResultsDistributionMonitoringService() ICcServer.startServerResultsDistributionMonitoringService()
Default value is false.

com.corticon.server.monitoring.decisionservice.record.data.registration.deli miter specifies the delimiter to use when registering default Tracking Attributes. Default value is ;
January 13, 2012
Page 165
com.corticon.server.monitoring.decisionservice.record.data.bucket.registrati on.delimiter specifies the delimiter to use when registering range buckets for the monitoring service. Default value is , com.corticon.server.monitoring.decisionservice.record.data.bucket.results.de limiter specifies the delimiter to use between bucket definition and bucket counter when reporting results from the monitoring service. Default value is :
com.corticon.server.monitoring.decisionservice.interval.record.times=false com.corticon.server.monitoring.decisionservice.interval.record.sleep=10000 com.corticon.server.monitoring.decisionservice.interval.record.total=50
These properties control monitoring execution times of Decision Service/Versions over defined interval periods.
com.corticon.server.monitoring.decisionservice.interval.record.times specifies whether Corticon Server will auto-start recording time interval measurements. Note: The time interval monitoring service can be shutdown and restarted using the following API methods, which will override this setting. ICcServer.stopServerExecutionTimesIntervalService() ICcServer.startServerExecutionTimesIntervalService()
Default value is false

com.corticon.server.monitoring.decisionservice.interval.record.sleep indicates the number of milisconds that the interval results will be recorded. Default value is 10000 (10 seconds) com.corticon.server.monitoring.decisionservice.interval.record.total indicates the number of past intervals that will be stored in memory. Default value is 50
com.corticon.server.soap.collection.results.delimiter=;
Specifies the delimiter to be used when results from an RPC need to be converted from a Collection to a String. Default value is ;
com.corticon.ccserver.autoloaddir.enable=true com.corticon.ccserver.autoloaddir= Specify if and from where .cdd files get "auto loaded" into Corticon Server when it starts up. Note:
This property changed using following method, which will override this setting.
ICcServer.setDeploymentDescriptorDirectoryPath(String)
Default value: If autoloaddir.enable is true, then Corticon Server will automatically read the path specified in autoloaddir and attempt to reload any Decision Services referenced in any .cdd
January 13, 2012
Page 166
files it finds there. If false, Corticon Server will not try to reload Decision Services deployed via .cdd files. If autoloaddir is empty, the following path is used: <user.dir>\cdd where <user.dir> is the value of environment variable "user.dir" which in Windows and Unix returns the directory where the container application was started in.
com.corticon.ccserver.appendservertimes=false
Specifies whether the Server Execution start and stop times are appended to the CorticonResponse document after ICcServer.execute(String) or ICcServer.execute(Document) is performed. Default value is false.
com.corticon.ccserver.cloneAssociationHashSets=false
Determines whether CDO association accessor ("getter") methods will return clones of their association HashSets. Normally, an association getter will return a direct reference to the association HashSet. The default value (false) provides the best performance, because cloning an association HashSet can trigger unnecessary database I/O due to lazy-loading. You can use this property to overcome ConcurrentModificationException errors which may arise when a Rulesheet has two aliases assigned to the same association, and that Rulesheet contains action statements that modify the association collection. Note that this property only applies to many-to-many associations; for many-to-1 associations, the CDOs will always return a direct reference to the "singleton" HashMap. Default is false
com.corticon.server.serverstate.load=true
Determines whether Corticon Server will initially load the ServerState.xml file to restore the Corticon Server to its previous state. Default is true
com.corticon.server.serverstate.persistchanges=true
Determines whether Corticon Server will persist its state inside of the ServerState.xml. By default this feature is turned on. Default is true
com.corticon.reactor.rulebuilder.DisableNullCheckingOnExtensions=false
By default, attributes are checked for null values to prevent further rule evaluation. This property will disable the null checks on attributes used in an extension call out, thereby allowing null values to be passed into an extended operator call.
Page 167
January 13, 2012
Page 168
APPENDIX D: SAMPLE CODE SUMMARY

Corticon Business Rules Servers installation contains several sample code files that are useful starting points when building your own integrations. The sample code files are self-documented and can be found in the Samples directory of your Corticon installation directory. Folder
\Server\src
Sample Code file

CcServerApiTest.java
Usage Provides the source code used by testServer.bat to create a DOS menu interface on the Server API. Note: uses Corticon Server in the same JVM as the Java test code and can not be executed against Corticon Server inside the Tomcat server (you can, of course, write your own Java client using these APIs to operate against any deployment, including a Tomcat deployment). Shows how to control the Deployment Console via Java API calls. This is the source code used by testDeployConsole.bat to create a DOS menu interface for Server API. The source code used by axis.war, the sample SOAP wrapper shipped with Corticon Server.
\Server\src
CcDeployApiTest.java
\Samples\Server\ Containers\WAR\src
CcMessageHandler.java CcServerAxisTest.java CcServerMessagingAxis.java CcSoapException.java CcSoapSendException.java CcSoapServerInit.java CcSoapUtilities.java CcServerAdminHome.java CcServerAdminImplementation.java CcServerAdminInterface.java CcServerExecuteHome.java CcServerExecuteImplementation.java CcServerExecuteInterface.java
\Samples\Server\ Containers\EAR\src
The source code used by CcServer.ear, the sample Session EJB wrapper shipped with Corticon Server.
January 13, 2012

CcServerExecuteResultObject.java CcServerSessionBeanTest.java CcServerWeblogicSessionBean SimpleTest.java
Page 169
January 13, 2012
Page 170
APPENDIX E: CORTICON STUDIO AND SERVER 5.2 PRODUCT DOCUMENTATION

Rule Language Guide
January 13, 2012
Page 171
APPENDIX F: USING THE CORTICON BUSINESS RULES SERVER INSTALLER

CORTICON SERVER SETUP WIZARD
Corticon Server is packaged in a standard Windows installer application named Corticon_Server_Installer.exe . This installer application simply copies or unbundles Server files to a Windows directory structure, but there are no Windows-only files contained in the installer. If you would like to install these Server files on a non-Windows machine, first run the installer on a Windows machine, then copy/move the required files to your destination platform. To install Corticon Server software, insert the product CD in the CD-ROM drive of your computer or download the installation file from the designated website. Double-click on the Corticon_Server_Installer.exe file to open the Corticon Server Setup wizard. The installer contains: The Corticon Business Rules Server The Corticon Deployment Console Apache Tomcat web server and Servlet container Apache SOAP Java Runtime Environment, version 1.6 Sample code
The screens shown in this document were captured on computers using Windows XP and 7 as their operating systems.
SYSTEM REQUIREMENTS
Corticon Business Rules Server requirements include: All Java-supported processors 512 MB RAM recommended 10 MB disk space (core libraries) 150 MB disk space (full install) Java Runtime Engine, version 1.5.0 or higher
January 13, 2012
Page 172
New Installation or Upgrade?

If an older version of Corticon Server is installed on your machine, please proceed to Program Maintenance Remove Program section of this manual. Once removal of any earlier versions is complete, re-launch the Corticon_Server_Installer.exe, and follow instructions for a new installation. If no prior version of Server has been installed on your machine, or if a previous version has already been removed in accordance with the instructions in the Program Maintenance Remove Program section of this manual, please proceed:
Startup Screen
The first screen of the Server Installer Wizard appears briefly and requires no action on your part.
This is the Introduction screen of the Server Installer Wizard. Click Next to continue.
January 13, 2012
Page 173
License Agreement
This screen displays the Corticon Standard License Agreement. Use the scroll bar at the right of the screen to read through this agreement. When you are finished and agree to the terms, choose I accept the terms of the license agreement. Click Next to continue.
Choosing Installation Directory

To accept the default installation location, click Next. If you want to change the installation directory, click Choose and proceed to the next step.
If you are installing Corticon Server on Microsoft Vista or Windows 7, the default installation location may appear as C:\Corticon. Regardless of default, be sure to select an Install Folder for which you have full read and write access rights. If you have any doubt about your access rights to C:\Program Files, choose another installation directory outside C:\Program Files (such as C:\Corticon).
January 13, 2012
Page 174
Changing Installation Directory

To change the default installation directory, navigate to your preferred directory in this window, Click OK to continue.
January 13, 2012
Page 175
Install Set
Choose the install set, Complete, Minimum or Custom. The Complete option is selected by default. If you want a custom set, select or deselect any of the components from the list Click Next to continue.
Pre-Installation Summary
Verify your selections in the Pre-Installation Summary screen. Click Install to continue.
January 13, 2012
Page 176
Install Status
This screen displays a status bar as the necessary files are being copied to your computer.
Completing the Setup Wizard

Choose Done to complete the Server installation.
January 13, 2012
Page 177
Desktop Shortcut
The Installer does not place a Deployment Console shortcut to your desktop. If you would like to add a Deployment Console shortcut icon to your desktop, locate the DepConsole.exe file inside
<corticon_install_dir >\Server, and right-click to

select Send To>Desktop
(create shortcut)
PROGRAM MAINTENANCE
Once Corticon Server is installed, you can modify the program features; repair corrupt files, shortcuts and registry entries; or remove Corticon Server completely. Remove Corticon Server and rerun Corticon Server Installer to change installation.
Remove Program
An Uninstaller named Uninstall Corticon Business Rules Server.exe is available in <corticon_install_dir>\Uninstall_Corticon Business Rules Server. To remove Corticon Server, run this executable. Choose Uninstall to remove all Corticon Server software from your computer Personal files that you have already created will NOT be removed or overwritten during this process.
January 13, 2012
Server Integration & Deployment Guide 5.2 Uninstaller Status
Page 178
Uninstaller completion. If the Uninstaller program is unable to fully remove components, it will display messages in this window. In this case, \Samples were not removed because it is in use by Studio.
January 13, 2012
CORTICON
Business Rules Studio 5.2 Extensions User Guide
January 13, 2012
CONTENTS
Contents ..................................................................................................................................................................... 3 Supported Configurations ...................................................................................................................................... 4 Overview..................................................................................................................................................................... 5 Eclipse and RCP Usage Scenario............................................................................................................................. 6 Non-Eclipse Usage Scenario ................................................................................................................................... 6 Class Locator Files .................................................................................................................................................. 6 Java Class Conventions ............................................................................................................................................... 8 Attribute Extended Operators .................................................................................................................................... 9 Collection Extended Operators ................................................................................................................................ 11 Sequence Extended Operators ................................................................................................................................. 13 Stand-Alone Extended Operators............................................................................................................................. 16 Service Call-out Extensions....................................................................................................................................... 18 Service Call-out API .............................................................................................................................................. 19 Creating an Extension Plug-in ................................................................................................................................... 22 Setting Up Your Development Eclipse IDE ........................................................................................................... 22 Creating Your Plug-in Project ............................................................................................................................... 24 Creating the Extensions Locator File .................................................................................................................... 30 Creating an Extension Class ................................................................................................................................. 31 Coding Your Extension Class ................................................................................................................................ 34 Updating Your Plug-in Manifest ........................................................................................................................... 36 Organizing Imports............................................................................................................................................... 37 Exporting Your Plug-in.......................................................................................................................................... 38 Installing Your Plug-in .......................................................................................................................................... 39 Testing Your Extensions ....................................................................................................................................... 40 Troubleshooting Extensions ..................................................................................................................................... 55 Extension Plug-in Not Resolved By Eclipse .......................................................................................................... 56 Extension Locator File Not Set Up Correctly ........................................................................................................ 56 Extension Classes Not Implementing Marker Interfaces ..................................................................................... 57 Enabling Logging to Diagnose Extensions Issues ................................................................................................. 57 Documenting Your Extensions.................................................................................................................................. 59 Precompiling Ruleflows with Service Call-outs ........................................................................................................ 60 Appendix A: Corticon Studio and Server 5.2 Product Documentation .................................................................... 61
January 13, 2012
SUPPORTED CONFIGURATIONS
Software Component JDK Eclipse EMF GEF GMF Version 1.5.0 or higher Galileo (3.5.2 or higher) 2.5.0.v2009061510 or higher 3.5.1.v20090910 or higher 1.2.0.v20090615 or higher Certified on Version JDK 1.6.0_20 Galileo 3.5.2 2.2.3.v200705141058 3.2.2.v20070208 1.0.3.v20070202-1200
January 13, 2012
OVERVIEW
You can extend the set of operators available to your users by writing your own Java classes.
Extension Attribute Extended Operator Description Extensions that you invoke against attributes of a given type. For example, you can define an extension that can be invoked against String attributes. Extensions that operate on collections. For example, you can define an extension that can be invoked against a collection of String attributes. Extensions that operate on sequences. For example, you can define an extension that can be invoked against a sequence Decimal attributes. Function you can use in any Rulesheet expression. A StandAlone extension can take any number of input parameters returns a value. Extensions you can use in a Ruleflow. A Service Call-out is an extension that can directly access and update the universe of rule engine facts via the Service Callout application programming interfaces. Service Call-out Extension CreditLookup retrieves credit data from a consumer credit agency and updates rule engine facts accordingly. The system forwards the updated facts to Rulesheet AssessRisk for analysis. Example Invocation Customer.zip.characterAt(2) String Attribute Extended Operator characterAt returns a String consisting of the second character of Customer.zip. Order.uni=orditm.sku->uniqueCount Collection Extended Operator uniqueCount returns a count of the number of unique String values in collection orditem.sku. Trade.mavg=security.price-> sortedBy(marketDate)->mavg(30) Sequence Extended Operator mavg returns the moving average of a sequence of price values in security.price. Shape.circumference = SeMath.getCircumference(Shape.radius) Stand-Alone Extension SeMath.getCircumference converts Shape.radius to Shape.circumference.
Collection Extended Operator
Sequence Extended Operator
Stand-Alone Extended Operator
Service Callout Extension
There are several ways to add your extension classes to the system. The approach you use depends on whether you are using Corticon Studio for Eclipse, RCP or the Foundation APIs in a non-Eclipse setting.
January 13, 2012
ECLIPSE AND RCP USAGE SCENARIO

For Eclipse and RCP usage scenarios, you must create an Eclipse plug-in to encapsulate your extensions. Corticon Studio will automatically recognize an optional plug-in named:
com.corticon.eclipse.studio.operations.extended.core
Corticon Studio includes a sample implementation of this plug-in to guide your development efforts. This example plug-in includes Java classes plus an EMF file that documents the extensions (see Documenting your extensions on page 59).
NON-ECLIPSE USAGE SCENARIO

If you are using Corticon Foundation APIs outside of Eclipse, you add your extension classes to the system class path, either as individual class files, or combined into one or more Jar files.
CLASS LOCATOR FILES

To allow the system to locate your classes, you must place a locator file (CcExtensionsLocator.lc) in the root folder where your extension classes reside.1 If you choose to create an Eclipse plug-in to encapsulate your extensions, you should place CcExtensionsLocator.lc in your plug-in /src (source) folder. 2 If you chose to use Jar files outside of Eclipse, you must place CcExtensionsLocator.lc in the root of your Jar.
A locator file is an empty (0-byte) file that allows the system to locate your classes.
Normally, Eclipse will copy non-Java classes from your /src folder to your output classes directory when you build your project; however, we have seen cases where this did not occur. It is essential that your CcExtensionsLocator.lc be present in your output Jar root when your plug-in is exported (see Exporting Your Plug-in on page 36), so please double-check your plug-in Jar to ensure that the locator is present.
January 13, 2012
If you use class directories outside of Eclipse, you must place CcExtensionsLocator.lc in the root folder where your classes reside. For example, if your extension classes were located in V:/Extensions, you would place your locator in V:/Extensions:
You would then place your classes in folders under V:/Extensions:
January 13, 2012
JAVA CLASS CONVENTIONS

Your extension classes must conform to certain standards. Although you are free to choose any package and class names for your extensions, your classes must implement special marker interfaces to identify them as containers of extension logic:
Interface Name com.corticon.services.extensions.ICcStringExtension com.corticon.services.extensions.ICcDateTimeExtension Description Identifies your class as a container of String Attribute Extended Operators. Identifies your class as a container of Date, Time and/or DateTime Attribute Extended Operators. Identifies your class as a container of Decimal Attribute Extended Operators. Identifies your class as a container of Integer Attribute Extended Operators. Identifies your class as a container of Collection Extended Operators. Identifies your class as a container of Sequence Extended Operators. Identifies your class as a container of Stand-Alone Extended Operators Identifies your class as a container of Service Call-out Extensions.
com.corticon.services.extensions.ICcDecimalExtension com.corticon.services.extensions.ICcIntegerExtension com.corticon.services.extensions.ICcCollectionExtension com.corticon.services.extensions.ICcSequenceExtension com.corticon.services.extensions.ICcStandAloneExtension com.corticon.services.extensions.ICcServiceCalloutExtension
These marker interfaces can be found in:

Usage Scenario Eclipse or RCP Foundation API Location Eclipse plug-in com.corticon.services Corticon_eFoundation_API.jar
Corticon Studio is installed with source code examples that illustrate the proper implementation for each type of extension.3
Please refer to our source code examples in folders Extended Operators and Service Call-outs folders.
January 13, 2012
ATTRIBUTE EXTENDED OPERATORS

Attribute Extended Operators apply to specific attribute data types. Consider this example expression:
Customer.fullName = Customer.name.trimSpaces
Assuming that Customer.name is a String attribute, Attribute Extended Operator trimSpaces might perform the "trim" function on the value of attribute name, returning the trimmed value, which the rule engine will assign to Customer.fullname. To create an Attribute Extended Operator, you must code a Java class, and your class must implement the marker interface corresponding to the attribute type. For example, to create a String Attribute Extended Operator, your Java class must implement interface ICcStringExtension. Example:
package com.acme.extensions; import com.corticon.services.extensions.ICcStringExtension; public class S1String implements ICcStringExtension { public static String trimSpaces(String astrThis) { if (astrThis == null) { return null; } return astrThis.trim(); } }
Attribute Extended Operator methods must be declared public static. The first positional parameter will always be a reference to the attribute upon which the function is being performed. In this example, the rules engine will pass the current value of Customer.name to extension method trimSpaces as parameter astrThis; thus, astrThis must be declared as type String.
January 13, 2012
10
An Attribute Extended Operator may accept any number of additional parameters as needed. Consider the following Rulesheet expression:
Customer.initial = Customer.name.characterAt(1)
In this example, your Java method would return the first character of Customer.name:
public static String characterAt(String astrThis, BigInteger abiIndex) { if (abiIndex == null) { return null; } int liIndex = abiIndex.intValue() - 1; if (liIndex < 0 || liIndex >= astrThis.length()) { return null; } return astrThis.substring(liIndex, liIndex + 1); }
As always, the first positional parameter astrThis will contain a reference to the String upon which to operate (i.e., a reference to the value of Customer.name). The second parameter will contain the character index (i.e., literal 1). Your extension would return the character at the specified index as a String, and the rules engine will assign Customer.initial the value of your returned String. For Attribute Extended Operators, you must limit your parameter and return types to the following:
Java Type java.math.BigInteger java.math.BigDecimal java.lang.Boolean java.util.Date java.lang.String Corticon Type Integer Decimal Boolean Date, Time or DateTime String
Note that you may code any number of extension methods in a Java class, and you can supply one or more Java classes; regardless, the system will discover all of your methods via Java reflection.
January 13, 2012
11
COLLECTION EXTENDED OPERATORS

Collection Extended Operators process a collection of input attribute values and return a single value. Consider this example expression:
ord.asteriskFlag = orditem.sku->allContain(*)
Assuming that asteriskFlag is a Boolean attribute and orditem.sku refers to a collection of String attributes, Collection Extended Operator allContain will return a Boolean value true if all instances of String attribute sku contain an asterisk. To create a Collection Extended Operator, you must code a Java class, and your class must implement marker interface ICcCollectionExtension. Example:
package com.corticon.operations.extended.examples.operators.set1; import java.util.HashSet; import com.corticon.services.extensions.ICcCollectionExtension; public class S1Collection implements ICcCollectionExtension { public static Boolean allContain(String[] astrInputArray, String astrLookFor) { if (astrInputArray == null || astrInputArray.length == 0) return null; for (String lstrInput : astrInputArray) { if (lstrInput != null) { if (lstrInput.indexOf(astrLookFor) < 0) { return new Boolean(false); } } } return new Boolean(true); } }
Collection Extended Operator methods must be declared public static. In this example, the first positional parameter of method allContain is an array of String instances. The rules engine will populate this array with the String values in orditem.sku (i.e., the collection upon which the method operates). The example Java method analyzes this array and returns a Boolean value. The rules engine will then assign ord.asteriskFlag the Boolean return value.
12
Note that you cannot code Collection Extended Operators for entity instances, nor can you code extensions for Collections or Sequences of entity instances. For example, the following expression is not allowed:
orditem->allContain(*)
In other words, you can only code Collection Extended Operators to process collections of attribute values. When implementing Collection Extended Operators, you must limit your parameter and return types to the following:
The first positional parameter must be an array of one of these allowable types.
January 13, 2012
13
SEQUENCE EXTENDED OPERATORS

Sequence Extended Operators process a sequence (list) of input attribute values and return a single value. Consider this example expression:
Trade.mavg=security.price->sortedBy(marketDate)->mavg(30)
Assuming that Trade.mavg is a Decimal attribute, marketDate a Date attribute, and security.price refers to a collection of Decimal attributes, Sequence Extended Operator mavg might return a Decimal value that is the moving average of the first 30 instances of sequence security.price. To create a Sequence Extended Operator, you must code a Java class, and your class must implement marker interface ICcSequenceExtension. Example:
January 13, 2012
14
package com.corticon.operations.extended.examples.operators.set1; import java.math.BigDecimal; import java.math.BigInteger; import com.corticon.services.extensions.ICcSequenceExtension; public class S1Sequence implements ICcSequenceExtension { private static final int DECIMAL_SCALE = 4; public static BigDecimal mavg(BigDecimal[] abdInputArray, BigInteger abiElements) { if (abdInputArray == null || abiElements == null) { return new BigDecimal("0"); } int liElements = abiElements.intValue(); BigDecimal lbdSum = new BigDecimal("0").setScale(DECIMAL_SCALE); int liDenominator = 0; for (int liIndex = 0; liIndex < abdInputArray.length && liIndex < liElements; liIndex++) { lbdSum = lbdSum.add(abdInputArray[liIndex]); liDenominator++; } BigDecimal lbdDenominator = new BigDecimal(String.valueOf(liDenominator)); return lbdSum.divide(lbdDenominator, DECIMAL_SCALE, BigDecimal.ROUND_HALF_UP); } }
Sequence Extended Operator methods must be declared public static. In this example, the first positional parameter of method mavg is an array of BigDecimal instances. The rules engine will populate this array with the Decimal values in security.price 4 (i.e., the sequence upon which the method operates). The example Java method analyzes this array and returns a Decimal value. The rules engine will then assign Trade.mavg the Decimal return value. As with Collection Extended Operators, you cannot code Sequence Extended Operators for entity instances, nor can you code extensions for Collections or Sequences of entity instances.
4
Collection security.price has been sorted into marketDate sequence via built-in operator sortedBy.
January 13, 2012
15
When implementing Sequence Extended Operators, you must limit your parameter and return types to the following:
The first positional parameter must be an array of one of these allowable types.
January 13, 2012
16
STAND-ALONE EXTENDED OPERATORS

Stand-Alone extended operators define functions that can be used in Rulesheet expressions. Unlike Attribute Extended Operators, they are not tied to Vocabulary attributes and are not associated with any particular data type. Users invoke Stand-Alone extended operators by explicitly specifying a class name and method name in Rulesheet expressions.5 Stand Alone extension classes may contain any number of static methods. Consider this expression:
Circle.circumference = SeMath.getCircumference(Circle.radius)
Assuming Circle.circumference and Circle.radius are both Decimal attributes, Stand-Alone Extended Operator SeMath.getCircumference might convert the radius to circumference, which the rule engine will assign to Circle.circumference. To create Stand Alone Extended Operator, you must code a Java class, and your class must interface ICcStandAloneExtension. Example:
package com.corticon.operations.extended.examples.standalone.set1; import java.math.BigDecimal; import com.corticon.services.extensions.ICcStandAloneExtension; public class SeMath implements ICcStandAloneExtension { public static BigDecimal getCircumference(BigDecimal abdRadius) { BigDecimal lbdBigDecimal = abdRadius.multiply(new BigDecimal(2.0)); lbdBigDecimal = lbdBigDecimal.multiply(new BigDecimal(Math.PI)); return lbdBigDecimal; } }
Stand-Alone Extended Operator methods must be declared public static. Any number of parameters may be specified. The Rulesheet expression parameter list and return value must match the extension class method signature; otherwise, the Rulesheet expression will be flagged as invalid.
The user specifies the unqualified part of the class name, namely the class name without the package name. January 13, 2012
17
In this example, the rules engine will pass the current value of Circle.radius to class com.corticon.operations.extended.examples.standalone.set1.SeMath method getCircumference as parameter abdRadius; thus, abdRadius must be declared as type BigDecimal. Similarly to Attribute Extended Operators, you must limit parameter and return types to the following:
Note that you may code any number of extension methods in a Java class, and you can supply one or more Java classes; regardless, the system will discover all of your methods via Java reflection.
January 13, 2012
18
SERVICE CALL-OUT EXTENSIONS

Service Call-out Extensions are user-written functions that can be invoked in a Ruleflow. In a Ruleflow, the flow of control moves from Rulesheet to Rulesheet, with all Rulesheets operating on a common pool of facts. This common pool of facts is retained in the rule execution engines working memory for the duration of the transaction. Connection arrows on the diagram specify the flow of control. Each Rulesheet in the flow may update the fact pool. When you add a Service Call-out to a Ruleflow diagram, you effectively instruct the system to transfer control to your extension class a specific point in the flow. Your extension class can directly update the fact pool, and your updated facts are available to subsequent Rulesheets. Consider this example:
After the rule engine finishes processing Rulesheet SelectCandidates, it will transfer control to Service Call-out Extension class CreditLookup, method retrieveFICO. Using the Service Call-out API, class CreditLookup, method retrieveFICO can create, retrieve, update and remove facts. For example, it might look up a customers FICO score using an external web service, and update the facts accordingly. When CreditLookup.retrieveFICO finishes, the system will transfer control to the next Rulesheet in the Ruleflow. Downstream Rulesheets (e.g., AssessRisks) will evaluate and respond to new facts asserted by your Service Call-out.
January 13, 2012
19
SERVICE CALL-OUT API

Your Service Call-outs use an API to retrieve and update facts. The API is comprised of these Java interfaces:
Interface Purpose
com.corticon.services.dataobject.ICcDataObjectManager Provides access to the entire fact pool. Allows you to create, retrieve and remove entity instances. com.corticon.services.dataobject.ICcDataObject Provides access to a single entity instance. Allows you to update the entity instance, including setting attributes and creating and removing associations.
These interfaces can be found in:

Usage Scenario Eclipse or RCP Foundation API Location Eclipse plug-in com.corticon.services Corticon_eFoundation_API.jar
Your Service Call-out class must implement marker interface ICcServiceCalloutExtension. Example:
January 13, 2012
20
package com.corticon.operations.extended.examples.servicecallouts; import com.corticon.services.dataobject.ICcDataObject; import com.corticon.services.dataobject.ICcDataObjectManager; import com.corticon.services.extensions.ICcServiceCalloutExtension; public class SampleDataService implements ICcServiceCalloutExtension { public static void retrievePersonInfo(ICcDataObjectManager aDataObjMgr) { for (ICcDataObject lPerson : aDataObjMgr.getEntitiesByName("Person")) { String lstrName = "Tom"; Boolean lbMarried = new Boolean(true); lPerson.setAttributeValue("name", lstrName); lPerson.setAttributeValue("married", lbMarried); } } }
Service Call-out methods must be declared public static. The system will recognize your Service Call-out method if the method signature takes one parameter and that parameter is an instance of ICcDataObjectManager. Recognized classes and methods will appear in the Ruleflow Properties View/Service Name drop-down list when a Service Call-out shape is selected in the Ruleflow diagram:
January 13, 2012
21
Example SampleDataService.resetInfoCounter illustrates how a Service Call-out can use the supplied ICcDataObjectManager to find and update entity instances.
ICcDataObjectManager method getEntitiesByName allows you to retrieve a Set of all entity instances with a given name. Each element of the returned Set is an instance of ICcDataObject which
offers additional methods to access and update a specific entity instance. The example finds all Person entities then iterates over them to set attributes Person.name and Person.married using generic method ICcDataObject.setAttributeValue. The Service Call-out API provides your extension class complete access to the fact pool, allowing you to: Find entities in several ways Read and update entity attributes Create and remove entity instances Create and remove associations Post rule messages
Please refer to Service Call-out Java source code examples in your Corticon Studio /Samples/Extended Operators folder, and see the API Javadocs for more information.
January 13, 2012
22
CREATING AN EXTENSION PLUG-IN

For Eclipse and RCP deployment, you must create an Eclipse plug-in to encapsulate your extensions. The system will automatically recognize an optional plug-in named:
You can use your Eclipse IDE to create a plug-in project to develop your extensions and ultimately prepare them for deployment.
SETTING UP YOUR DEVELOPMENT ECLIPSE IDE

If you dont already have an Eclipse environment, download and install the Galileo Classic platform from www.eclipse.org. Install Corticon Studio into your Galileo Classic environment so that your new extensions plug-in will have access to extensions marker interfaces and Service Call-out APIs (see Corticon Studio Installation Instructions for Eclipse Galileo 3.5.2 for instructions). After installing Studio, start your Eclipse IDE and select: Help>About Eclipse SDK>Installation Details>Installed Software to verify that Corticon Studio has been successfully installed:
We recommend you develop plug-ins using an installed Java JDK as opposed to JRE. If you have not already done so, download the latest JDK from www.oracle.com then select: Windows>Preferences>Java>Installed JREs Navigate to your downloaded JDK and select it as your default JRE:
January 13, 2012
23
In order to successfully compile and test Rulesheets, you must copy tools.jar from your JDKs /lib directory into /jre/lib/ext as shown:
January 13, 2012
24
Creating Your Plug-in Project

Using the Java Perspective select: New>Project>Plug-in Project
January 13, 2012
25
January 13, 2012
26
Specify the Plug-in Project name com.corticon.eclipse.studio.operations.extended.core:
Press Next to proceed to the next wizard page.
January 13, 2012
27
The system will display the Content page allowing: 1. In the Version field, enter a version number for your plug-in. You should specify a version greater than the version of Studio you installed. For example, if you installed Studio Version 5.1.2, you might specify version 5.1.3. This will ensure that your plug-in supersedes our example plug-in. 2. Enter Extended Operators Core Plug-in in the Name field. 3. Enter your company name in the Provider field.
4. Uncheck Generate an activator.
5. Uncheck This plug-in will make contributions to the UI.
Press Finish to proceed.
January 13, 2012
28
The system will prompt to switch to the Plug-in Development perspective. Check Remember my decision:
Press Yes to proceed. The system will switch to Plug-in Development perspective and then create a new plug-in project in your workspace.
January 13, 2012
29
The system will automatically open file plug-in manifest (MANIFEST.MF) to allow you to configure your new plug-in:
Close the plug-in manifest editor for now.
January 13, 2012
30
CREATING THE EXTENSIONS LOCATOR FILE

Right click on the /src node in the Package Explorer and select New>File. The system will prompt for a new file name. Specify CcExtensionsLocator.lc as shown:
January 13, 2012
31
CREATING AN EXTENSION CLASS

Right click on the /src node in the Package Explorer and select New>Package. Specify the package name for your new extension classes:
January 13, 2012
32
Right-click on your new package and select New>Class:
Enter a name for your new Java class (e.g., HelloWorld) and press Finish. The system will create an empty class definition:
January 13, 2012
33
January 13, 2012
34
CODING YOUR EXTENSION CLASS

Code your extension class as shown:
package com.acme.extended.operators; public class HelloWorld implements ICcStringExtension { public static String getHelloWorld(String astrThis) { return "Hello World"; } }
Note that Eclipse cannot resolve interface ICcStringExtension:
January 13, 2012
35
January 13, 2012
36
UPDATING YOUR PLUG-IN MANIFEST

To correct build errors, open MANIFEST.MF 6 and select the MANIFEST.MF tab and update the manifest as shown in green below:
Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Extended Operators Core Plug-in Bundle-SymbolicName: com.corticon.eclipse.studio.operations.extended.core Bundle-Version: 5.1.3 Bundle-Vendor: Your Company Bundle-RequiredExecutionEnvironment: JavaSE-1.6 Require-Bundle: com.corticon.services, com.corticon.legacy Export-Package: ., com.acme.extended.operators Eclipse-RegisterBuddy: com.corticon.legacy
These changes will: Ensure that your plug-in has access to interface ICcStringExtension in
com.corticon.services
Ensure that your locator file CcExtensionLocator.lc and Java package com.acme.extended.operators are visible to the Corticon extensions subsystem Ensure that your plug-in is registered as a buddy with com.corticon.legacy to allow the Corticon class loader to find your extensions
Press Save to save your manifest changes.
The manifest resides in your new plug-in META-INF directory.
January 13, 2012
37
ORGANIZING IMPORTS
Activate the HelloWorld Java editor and press CTRL-SHIFT-O to organize imports. The system will add import com.corticon.services.extensions.ICcStringExtension allowing your class to build without errors:
January 13, 2012
38
EXPORTING YOUR PLUG-IN

Close all open editors, right-click your Project in the Package Explorer view and select: Export>Plug-in Development>Deployable plug-ins and fragments:
Navigate to any desired output directory then press Finish.
January 13, 2012
39
The system will create an installable plug-in in your output directory:
INSTALLING YOUR PLUG-IN

You can copy your exported plug-in into the target Eclipse environment /plugins directory. Remember to restart your target Eclipse environment whenever you update your plug-in. 7
You may have to use the clean command line option when you restart Eclipse to cause the system to rebuild the bundle cache, ensuring that your changes take effect.
January 13, 2012
40
TESTING YOUR EXTENSIONS

Create a Rule Project as a home for your Corticon test assets. First switch to Rule Modeling perspective by selecting: Window>Open Perspective>Other>Rule Modeling And press OK. The system will rearrange the editors and views as follows:
January 13, 2012
41
Right-click in the body of the Rule Project Explorer and select New>Rule Project
Enter HelloWorld in the Project name field and press Finish.
January 13, 2012
42
The system will create a new Rule Project visible in the Rule Project Explorer:
January 13, 2012
43
Right-click the HelloWorld project and select New>Rule Vocabulary:
Enter HelloWorld in the File name field and press Finish.
January 13, 2012
44
The system will create a new Vocabulary:
January 13, 2012
45
In the Vocabulary Editor, right-click the HelloWorld root node and select Add Entity to create a new entity Customer:
January 13, 2012
46
Right click Customer and select Add Attribute to create String attribute name:
Press Save to save your new Vocabulary.
January 13, 2012
47
Select the HelloWorld project in the Rule Project Explorer and select New>Rulesheet:
January 13, 2012
48
Press Next and then select the Vocabulary asset you created in the prior step:
Press Finish and the system will create a new empty Rulesheet.
January 13, 2012
49
Update your Rulesheet as shown:
Press Save to save your Rulesheet.
January 13, 2012
50
Right click on your HelloWorld project and select New>Ruletest. Specify HelloWorld in the File name field:
Press Next
January 13, 2012
51
Select your Rulesheet HelloWorld.ers as the Test Subject:
Press Finish and the system will create an empty Ruletest asset.
52
January 13, 2012
53
Drag entity Customer from the Vocabulary view to the Ruletest input tree:
Important: double-click Customer[1] name and enter value Test.
January 13, 2012
54
Select Ruletest>Testsheet>Run Test and you should see the following test results:
If you see Hello World in the output tree, congratulations! Your extensions are working properly.
January 13, 2012
55
TROUBLESHOOTING EXTENSIONS
If your extensions are not properly written or deployed, the system will color Rulesheet expressions red and will display validation messages in the Problems tab:
For Attribute Extended Operators, validation messages will indicate that your method is not a valid call on an attribute. There are several possible causes for this type of error.
January 13, 2012
56
EXTENSION PLUG-IN NOT RESOLVED BY ECLIPSE

Your plug-in might not be properly started and resolved by Eclipse. One quick way to check this is to select: Help>About Eclipse SDK>[Installation Details]>[Configuration] then check the Plug-in Registry to see the status of your extensions plug-in:
com.corticon.eclipse.server.core (5.1.2) "Corticon Server Core Plugin" [Starting] com.corticon.eclipse.studio.core (5.1.2) "Corticon Studio e Core Plug-in" [Starting] com.corticon.eclipse.studio.database.access.core (5.1.2) "Corticon Studio e Database Access Core Plug-in" [Starting] com.corticon.eclipse.studio.database.access.ui (5.1.2) "Corticon Studio Database Access UI Plug-in" [Starting] com.corticon.eclipse.studio.database.extendedpersistent.core (5.1.2) "Corticon Studio e Database Extended Persistent Core Plug-in" [Starting] com.corticon.eclipse.studio.database.extendedpersistent.ui (5.1.2) "Corticon Studio Database Extended Persistent UI Plug-in" [Starting] com.corticon.eclipse.studio.deployment.swing (5.1.2) "Corticon Studio Deployment Swing" [Starting] com.corticon.eclipse.studio.help.ui (5.1.2) "Corticon e Help Plugin" [Starting] com.corticon.eclipse.studio.importwizards.core (5.1.2) "Corticon e Import wizard core plug-in" [Starting] com.corticon.eclipse.studio.operations.core (5.1.2) "Corticon Studio Operations Core Plug-in" [Active] com.corticon.eclipse.studio.operations.extended.core (5.1.2) "Corticon Studio Operations Extended Core Plug-in" [Resolved] com.corticon.eclipse.studio.operations.extended.core (2.1.1) "Extended Operators Core Plug-in" [Resolved] com.corticon.eclipse.studio.rcp (5.1.2) "Corticon Studio RCP Application" [Starting] com.corticon.eclipse.studio.reports (5.1.2) "Corticon e Reporting Plugin" [Starting] com.corticon.eclipse.studio.rule.core (5.1.2) "Corticon Studio Rule Core Plug-in" [Starting] com.corticon.eclipse.studio.rule.optimizer.ambiguity.core (5.1.2) "Corticon Studio Rule Optimizer Ambiguity Core" [Active]
In this example, the plug-in has been installed and properly [Resolved]. If your plug-in is missing from this list, ensure that you have properly copied it into the Eclipse /plugins directory. Remember to start Eclipse with the clean command line option. This will cause the system to rebuild the bundle cache so that your new plug-in code is recognized. If your plug-in is present in the list but not marked as [Resolved] there may be some problem with the plug-in manifest. Carefully review MANIFST.MF to ensure all of your specifications are correct. Tips for troubleshooting bundle start failures can be found in various Eclipse online forums.
EXTENSION LOCATOR FILE NOT SET UP CORRECTLY

If your plug-in has been correctly [Resolved], ensure that your extension classes implement the correct marker interface(s) and that CcExtensionsLocator.lc is present in the root of your plug-in Jar. Also, review the MANIFEST.MF Export-Package clause carefully. It should appear as follows:
Export-Package: ., com.acme.extended.operators
January 13, 2012
57
Note that in the Export-Package clause, you must export period (.) to ensure that CcExtensionsLocator.lc is properly exported. If this specification is in error or missing, the system will fail to locate your classes.
EXTENSION CLASSES NOT IMPLEMENTING MARKER INTERFACES

Ensure that your classes implement the proper marker interfaces (e.g., ICcStringExtension); otherwise, the extensions subsystem will ignore your class.
ENABLING LOGGING TO DIAGNOSE EXTENSIONS ISSUES

You can enable INFO-level logging to help diagnose extensions discovery issues. Update com.corticon.configuration/CcCommon.properties to set loglevel to INFO:
loglevel=INFO
The extensions subsystem will log messages as it tries to locate your extension classes. You might see this type of output if your plug-in fails to properly export (.):
CcUtil.getAllLocationsOfFile() .. START CcUtil.getAllLocationsOfFile() .. astrResourceName = CcExtensionsLocator.lc com.corticon.extensions.CcExtensions|CcExtensions() loadClassesFromJars() == Start com.corticon.extensions.CcExtensions|CcExtensions() loadClassesFromJars() asetJarLocations == [] CcUtil|CcUtil.getAllLocationsOfFile() .. START com.corticon.extensions.CcExtensions|CcExtensions() loadClassesFromDirectories() == Start com.corticon.extensions.CcExtensions|CcExtensions() loadClassesFromDirectories() asetDirectoryLocations == []
n the log output above, the extensions subsystem is unable to find CcExtensionsLocator.lc either because it is missing or not properly exported.
January 13, 2012
58
In contrast, here is what you will see in the log if the extensions subsystem is able to find your locator and extension classes:
CcUtil.getAllLocationsOfFile() .. START CcUtil.getAllLocationsOfFile() .. astrResourceName = CcExtensionsLocator.lc CcUtil.getAllLocationsOfFile() .. lURLLocationPath = bundleresource://17.fwk25860399/CcExtensionsLocator.lc CcUtil.getAllLocationsOfFile() .. lstrProtocol = bundleresource CcUtil.getAllLocationsOfFile( AFTER RESOLVER ) .. lURLLocationPath = jar:file:/D:/GalileoClassic/eclipse/plugins/com.corticon.eclipse.studio.operations.extended.co re _5.1.3.jar!/CcExtensionsLocator.lc CcUtil.getAllLocationsOfFile(1) .. lstrPath = file:\D:\GalileoClassic\eclipse\plugins\com.corticon.eclipse.studio.operations.extended.core _5.1.3.jar!\CcExtensionsLocator.lc CcUtil.getAllLocationsOfFile(2) .. lstrPath = file:\D:\GalileoClassic\eclipse\plugins\com.corticon.eclipse.studio.operations.extended.core _5.1.3.jar!\CcExtensionsLocator.lc CcUtil|CcUtil.getAllLocationsOfFile() .. END = [file:\D:\GalileoClassic\eclipse\plugins\com.corticon.eclipse.studio.operations.extended.core _5.1.3.jar!\CcExtensionsLocator.lc] com.corticon.extensions.CcExtensions|CcExtensions() loadClassesFromDirectories() == Start com.corticon.extensions.CcExtensions|CcExtensions() loadClassesFromDirectories() asetDirectoryLocations == []
As shown above, getAllLocationsOfFile is able to find your extensions. This is a positive sign and if you see such output in the log, it is very likely that your extensions will work properly.
January 13, 2012
59
DOCUMENTING YOUR EXTENSIONS

In order for your extensions to be visible in the Rule Operators tree view, they must be properly documented in a special file named ExtendedOperators.operationsmodel. This file is in EMF/XMI format and can be maintained using either a text editor an EMF-generated editor supplied with Corticon Studio. Please refer to our example ExtendedOperators.operationsmodel file in:
During system initialization, the system will attempt to locate ExtendedOperators.operationsmodel on the Java class path; if the system finds this file, it will automatically merge the documented extended operators into the Rule Operators tree view.
ExtendedOperators.operationsmodel supports internationalization. The object model permits
localization of folder names, extended operator names, parameter names and tooltips. This is accomplished via EMF multi-valued attributes, which are essentially lists (arrays) of values. Each slot in the array contains a particular localization (i.e., a string expressed in one of the supported languages). The first localization in each slot is special and is referred to as the base localization. For class and method names, the base localizations must match the class and method names in your java extension classes. The root object of the model (ExtendedOperatorSet) contains a list of Java LanguageCode instances that defines the set of languages supported. The order of language codes is important and must match the order of localizations expressed elsewhere in the file. The system will merge typed extensions into the Rule Operator tree at the end of the built-in operators. For example, String Attribute Extended Operators will be appended to the "String" data type node of the Rule Operator tree after the built-in String operators. The system will append Stand Alone extensions to the end of the Rule Operator tree. The Stand Alone extensions will be contained within a special folder whose name is declared in ExtendedOperators.operationsmodel (see ExtendedOperatorSet.standAloneFolderName). In our example, the name of the Stand Alone extensions folder is simply Extended Operators. Our example ExtendedOperators.operationsmodel contains English descriptions of operators, and is set up to handle Japanese localizations as well, although the only Japanese localization specified is the Stand Alone folder name. Please refer to example ExtendedOperators.operationsmodel file as a guide documenting your own extensions.
January 13, 2012
60
PRECOMPILING RULEFLOWS WITH SERVICE CALL-OUTS

As described in the Deploying Corticon Ruleflows chapter of the Server Integration & Deployment Guide, you can pre-compile Ruleflows prior to deploying them. When pre-compiling Ruleflows with Service Call-outs, its important to ensure the following: 1. place the SCO JARs on the Deployment Consoles classpath. This is accomplished by editing the deployConsole.bat file located in <corticon_installation_directory>\Server (or your chosen installation directory). 2. Once the Ruleflow has been compiled to an .eds file using the Deployment Console, add your .eds file, along with any other JARs required by the SCO, to the Server directory which holds CcServer.jar. In the default Tomcat installation, this is <yourTomcatHome>\axis\WEBINF\lib.
January 13, 2012
61
APPENDIX A: CORTICON STUDIO AND SERVER 5.2 PRODUCT DOCUMENTATION

Rule Language Guide
January 13, 2012
2012 Progress Software Corporation and/or its subsidiaries or affiliates. All rights reserved. These materials and all Progress software products are copyrighted and all rights are reserved by Progress Software Corporation. The information in these materials is subject to change without notice, and Progress Software Corporation assumes no responsibility for any errors that may appear therein. The references in these materials to specific platforms supported are subject to change. Actional, Apama, Artix, Business Empowerment, Business Making Progress, Corticon, Corticon (and design), DataDirect (and design), DataDirect Connect, DataDirect Connect64, DataDirect Technologies, DataDirect XML Converters, DataDirect XQuery, DataXtend, Dynamic Routing Architecture, Empowerment Center, Fathom, Fuse Mediation Router, Fuse Message Broker, Fuse Services Framework, IONA, Making Software Work Together, Mindreef, ObjectStore, OpenEdge, Orbix, PeerDirect, Powered by Progress, PowerTier, Progress, Progress DataXtend, Progress Dynamics, Progress Business Empowerment, Progress Empowerment Center, Progress Empowerment Program, Progress OpenEdge, Progress Profiles, Progress Results, Progress Software Business Making Progress, Progress Software Developers Network, Progress Sonic, ProVision, PS Select, RulesCloud, RulesWorld, Savvion, SequeLink, Shadow, SOAPscope, SOAPStation, Sonic, Sonic ESB, SonicMQ, Sonic Orchestration Server, SpeedScript, Stylus Studio, Technical Empowerment, WebSpeed, Xcalia (and design), and Your Software, Our TechnologyExperience the Connection are registered trademarks of Progress Software Corporation or one of its affiliates or subsidiaries in the U.S. and/or other countries. AccelEvent, Apama Dashboard Studio, Apama Event Manager, Apama Event Modeler, Apama Event Store, Apama Risk Firewall, AppsAlive, AppServer, ASPen, ASP-ina-Box, BusinessEdge, Cache-Forward, CloudEdge, DataDirect Spy, DataDirect SupportLink, Fuse, FuseSource, Future Proof, GVAC, High Performance Integration, ObjectStore Inspector, ObjectStore Performance Expert, OpenAccess, Orbacus, Pantero, POSSE, ProDataSet, Progress Arcade, Progress CloudEdge, Progress Cloudware, Progress Control Tower, Progress ESP Event Manager, Progress ESP Event Modeler, Progress Event Engine, Progress RFID, Progress RPM, Progress Responsive Cloud, Progress Responsive Process Management, Progress Software, PSE Pro, SectorAlliance, SeeThinkAct, Shadow z/Services, Shadow z/Direct, Shadow z/Events, Shadow z/Presentation, Shadow Studio, SmartBrowser, SmartComponent, SmartDataBrowser, SmartDataObjects, SmartDataView, SmartDialog, SmartFolder, SmartFrame, SmartObjects, SmartPanel, SmartQuery, SmartViewer, SmartWindow, Sonic Business Integration Suite, Sonic Process Manager, Sonic Collaboration Server, Sonic Continuous Availability Architecture, Sonic Database Service, Sonic Workbench, Sonic XML Server, The Brains Behind BAM, WebClient, and Who Makes Progress are trademarks or service marks of Progress Software Corporation and/or its subsidiaries or affiliates in the U.S. and other countries. Java is a registered trademark of Oracle and/or its affiliates. Any other marks contained herein may be trademarks of their respective owners.
January 12, 2012
Third Party Acknowledgments: Progress Corticon Studio v5.2 incorporates Apache BCEL v5.1 from The Apache Software Foundation. Such technology is subject to the following terms and conditions: The Apache Software License, Version 1.1 Copyright (c) 2001 The Apache Software Foundation. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment: "This product includes software developed by the Apache Software Foundation (http://www.apache.org/)." Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear. 4. The names "Apache" and "Apache Software Foundation" and "Apache BCEL" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact apache@apache.org. 5. Products derived from this software may not be called "Apache", "Apache BCEL", nor may "Apache" appear in their name, without prior written permission of the Apache Software Foundation. THIS SOFTWARE IS PROVIDED `ÀS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This software consists of voluntary contributions made by many individuals on behalf of the Apache Software Foundation. For more information on the Apache Software Foundation, please see <http://www.apache.org/>. Progress Corticon Studio v5.2 incorporates Apache SOAP v2.3.1 from The Apache Software Foundation. Such technology is subject to the following terms and conditions: The Apache Software License, Version 1.1 Copyright (c) 1999 The Apache Software Foundation. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment: "This product includes software developed by the Apache Software Foundation (http://www.apache.org/)." Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear. 4. The names "SOAP" and "Apache Software Foundation" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact apache@apache.org. 5. Products derived from this software may not be called "Apache", nor may "Apache" appear in their name, without prior written permission of the Apache Software Foundation. THIS SOFTWARE IS PROVIDED `ÀS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This software consists of voluntary contributions made by many individuals on behalf of the Apache Software Foundation. For more information on the Apache Software Foundation, please see <http://www.apache.org/>. Progress Corticon Studio v5.2 incorporates Jaxen v1.3. Such technology is subject to the following terms and conditions: JAXEN License - $Id: LICENSE,v 1.3 2002/04/22 11:38:45 jstrachan Exp $ - Copyright (C) 2000-2002 bob mcwhirter & James Strachan. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions, and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the disclaimer that follows these conditions in the documentation and/or other materials provided with the distribution.
January 12, 2012
3. The name "Jaxen" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact license@jaxen.org. 4. Products derived from this software may not be called "Jaxen", nor may "Jaxen" appear in their name, without prior written permission from the Jaxen Project Management (pm@jaxen.org). In addition, we request (but do not require) that you include in the end-user documentation provided with the redistribution and/or in the software itself an acknowledgement equivalent to the following: "This product includes software developed by the Jaxen Project (http://www.jaxen.org/)." Alternatively, the acknowledgment may be graphical using the logos available at http://www.jaxen.org/. THIS SOFTWARE IS PROVIDED `ÀS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE Jaxen AUTHORS OR THE PROJECT CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This software consists of voluntary contributions made by many individuals on behalf of the Jaxen Project and was originally created by bob mcwhirter <bob@werken.com> and James Strachan <jstrachan@apache.org>. For more information on the Jaxen Project, please see <http://www.jaxen.org/>. Progress Corticon Studio v5.2 incorporates JDOM v1.0 GA. Such technology is subject to the following terms and conditions: $Id: LICENSE.txt,v 1.11 2004/02/06 09:32:57 jhunter Exp $ - Copyright (C) 2000-2004 Jason Hunter & Brett McLaughlin. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions, and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the disclaimer that follows these conditions in the documentation and/or other materials provided with the distribution. 3. The name "JDOM" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact <request_AT_jdom_DOT_org>. 4. Products derived from this software may not be called "JDOM", nor may "JDOM" appear in their name, without prior written permission from the JDOM Project Management <request_AT_jdom_DOT_org>. In addition, we request (but do not require) that you include in the end-user documentation provided with the redistribution and/or in the software itself an acknowledgement equivalent to the following: "This product includes software developed by the JDOM Project (http://www.jdom.org/)." Alternatively, the acknowledgment may be graphical using the logos available at http://www.jdom.org/images/logos. THIS SOFTWARE IS PROVIDED `ÀS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE JDOM AUTHORS OR THE PROJECT CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This software consists of voluntary contributions made by many individuals on behalf of the JDOM Project and was originally created by Jason Hunter <jhunter_AT_jdom_DOT_org> and Brett McLaughlin <brett_AT_jdom_DOT_org>. For more information on the JDOM Project, please see <http://www.jdom.org/>. Progress Corticon Studio v5.2 incorporates Saxpath v1.0. Such technology is subject to the following terms and conditions: Copyright (C) 2000-2002 werken digital. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions, and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the disclaimer that follows these conditions in the documentation and/or other materials provided with the distribution. 3. The name "SAXPath" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact license@saxpath.org. 4. Products derived from this software may not be called "SAXPath", nor may "SAXPath" appear in their name, without prior written permission from the SAXPath Project Management (pm@saxpath.org).
January 12, 2012
In addition, we request (but do not require) that you include in the end-user documentation provided with the redistribution and/or in the software itself an acknowledgement equivalent to the following: "This product includes software developed by the SAXPath Project (http://www.saxpath.org/)." Alternatively, the acknowledgment may be graphical using the logos available at http://www.saxpath.org/ THIS SOFTWARE IS PROVIDED `ÀS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE SAXPath AUTHORS OR THE PROJECT CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This software consists of voluntary contributions made by many individuals on behalf of the SAXPath Project and was originally created by bob mcwhirter <bob@werken.com> and James Strachan <jstrachan@apache.org>. For more information on the SAXPath Project, please see <http://www.saxpath.org/>. Progress Corticon Server v5.2 incorporates Apache BCEL v5.1 from The Apache Software Foundation. Such technology is subject to the following terms and conditions: The Apache Software License, Version 1.1 Copyright (c) 2001 The Apache Software Foundation. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment: "This product includes software developed by the Apache Software Foundation (http://www.apache.org/)." Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear. 4. The names "Apache" and "Apache Software Foundation" and "Apache BCEL" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact apache@apache.org. 5. Products derived from this software may not be called "Apache", "Apache BCEL", nor may "Apache" appear in their name, without prior written permission of the Apache Software Foundation. THIS SOFTWARE IS PROVIDED `ÀS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This software consists of voluntary contributions made by many individuals on behalf of the Apache Software Foundation. For more information on the Apache Software Foundation, please see <http://www.apache.org/>. Progress Corticon Server v5.2 incorporates Apache Commons Discovery v0.2 from The Apache Software Foundation. Such technology is subject to the following terms and conditions: The Apache Software License, Version 1.1 Copyright (c) 1999-2001 The Apache Software Foundation. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The end-user documentation included with the redistribution, if any, must include the following acknowlegement: "This product includes software developed by the Apache Software Foundation (http://www.apache.org/)." Alternately, this acknowlegement may appear in the software itself, if and wherever such third-party acknowlegements normally appear. 4. The names "The Jakarta Project", "Commons", and "Apache Software Foundation" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact apache@apache.org. 5. Products derived from this software may not be called "Apache" nor may "Apache" appear in their names without prior written permission of the Apache Group. THIS SOFTWARE IS PROVIDED `ÀS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE
January 12, 2012
FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This software consists of voluntary contributions made by many individuals on behalf of the Apache Software Foundation. For more information on the Apache Software Foundation, please see <http://www.apache.org/>. Progress Corticon Server v5.2 incorporates Apache SOAP v2.3.1 from The Apache Software Foundation. Such technology is subject to the following terms and conditions: The Apache Software License, Version 1.1 Copyright (c) 1999 The Apache Software Foundation. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment: "This product includes software developed by the Apache Software Foundation (http://www.apache.org/)." Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear. 4. The names "SOAP" and "Apache Software Foundation" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact apache@apache.org. 5. Products derived from this software may not be called "Apache", nor may "Apache" appear in their name, without prior written permission of the Apache Software Foundation. THIS SOFTWARE IS PROVIDED `ÀS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This software consists of voluntary contributions made by many individuals on behalf of the Apache Software Foundation. For more information on the Apache Software Foundation, please see <http://www.apache.org/>. Progress Corticon Server v5.2 incorporates Jaxen v1.3. Such technology is subject to the following terms and conditions: JAXEN License - $Id: LICENSE,v 1.3 2002/04/22 11:38:45 jstrachan Exp $ - Copyright (C) 2000-2002 bob mcwhirter & James Strachan. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions, and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the disclaimer that follows these conditions in the documentation and/or other materials provided with the distribution. 3. The name "Jaxen" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact license@jaxen.org. 4. Products derived from this software may not be called "Jaxen", nor may "Jaxen" appear in their name, without prior written permission from the Jaxen Project Management (pm@jaxen.org). In addition, we request (but do not require) that you include in the end-user documentation provided with the redistribution and/or in the software itself an acknowledgement equivalent to the following: "This product includes software developed by the Jaxen Project (http://www.jaxen.org/)." Alternatively, the acknowledgment may be graphical using the logos available at http://www.jaxen.org/. THIS SOFTWARE IS PROVIDED `ÀS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE Jaxen AUTHORS OR THE PROJECT CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This software consists of voluntary contributions made by many individuals on behalf of the Jaxen Project and was originally created by bob mcwhirter <bob@werken.com> and James Strachan <jstrachan@apache.org>. For more information on the Jaxen Project, please see <http://www.jaxen.org/>.
January 12, 2012
Progress Corticon Server v5.2 incorporates JDOM v1.0 GA. Such technology is subject to the following terms and conditions: $Id: LICENSE.txt,v 1.11 2004/02/06 09:32:57 jhunter Exp $ - Copyright (C) 2000-2004 Jason Hunter & Brett McLaughlin. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions, and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the disclaimer that follows these conditions in the documentation and/or other materials provided with the distribution. 3. The name "JDOM" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact <request_AT_jdom_DOT_org>. 4. Products derived from this software may not be called "JDOM", nor may "JDOM" appear in their name, without prior written permission from the JDOM Project Management <request_AT_jdom_DOT_org>. In addition, we request (but do not require) that you include in the end-user documentation provided with the redistribution and/or in the software itself an acknowledgement equivalent to the following: "This product includes software developed by the JDOM Project (http://www.jdom.org/)." Alternatively, the acknowledgment may be graphical using the logos available at http://www.jdom.org/images/logos. THIS SOFTWARE IS PROVIDED `ÀS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE JDOM AUTHORS OR THE PROJECT CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This software consists of voluntary contributions made by many individuals on behalf of the JDOM Project and was originally created by Jason Hunter <jhunter_AT_jdom_DOT_org> and Brett McLaughlin <brett_AT_jdom_DOT_org>. For more information on the JDOM Project, please see <http://www.jdom.org/>. Progress Corticon Server v5.2 incorporates Saxpath v1.0. Such technology is subject to the following terms and conditions: Copyright (C) 2000-2002 werken digital. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions, and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the disclaimer that follows these conditions in the documentation and/or other materials provided with the distribution. 3. The name "SAXPath" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact license@saxpath.org. 4. Products derived from this software may not be called "SAXPath", nor may "SAXPath" appear in their name, without prior written permission from the SAXPath Project Management (pm@saxpath.org). In addition, we request (but do not require) that you include in the end-user documentation provided with the redistribution and/or in the software itself an acknowledgement equivalent to the following: "This product includes software developed by the SAXPath Project (http://www.saxpath.org/)." Alternatively, the acknowledgment may be graphical using the logos available at http://www.saxpath.org/ THIS SOFTWARE IS PROVIDED `ÀS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE SAXPath AUTHORS OR THE PROJECT CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This software consists of voluntary contributions made by many individuals on behalf of the SAXPath Project and was originally created by bob mcwhirter <bob@werken.com> and James Strachan <jstrachan@apache.org>. For more information on the SAXPath Project, please see <http://www.saxpath.org/>.
January 12, 2012

Corticon - StudioHelp

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Corticon - StudioHelp

Hochgeladen von

Copyright:

Verfügbare Formate

Business Rules Modeling Studio 5.2 Quick Reference Guide

Studio 5.2 Quick Reference Guide

Studio 5.2 Quick Reference Guide

Studio 5.2 Quick Reference Guide

Studio 5.2 Quick Reference Guide

Studio 5.2 Quick Reference Guide

Copyright 2000-2012 Progress Software Corporation. All rights reserved.

January 13, 2012

Studio 5.2 Quick Reference Guide

CORTICON BUSINESS RULES MANAGEMENT PRODUCT DOCUMENTATION

Copyright 2000-2012 Progress Software Corporation. All rights reserved.

January 13, 2012

Studio 5.2 Quick Reference Guide

USING THE BUSINESS RULES MODELING STUDIO

Rulesheet has only one associated Vocabulary.

has only one associated Vocabulary.

Copyright 2000-2012 Progress Software Corporation. All rights reserved.

January 13, 2012

Studio 5.2 Quick Reference Guide

Copyright 2000-2012 Progress Software Corporation. All rights reserved.

January 13, 2012

Studio 5.2 Quick Reference Guide

Initial Menubar Options

Close All Save Save As

Save All Revert Move Rename Refresh

Copyright 2000-2012 Progress Software Corporation. All rights reserved.

January 13, 2012

Studio 5.2 Quick Reference Guide

Export Properties Recent File List

Copyright 2000-2012 Progress Software Corporation. All rights reserved.

January 13, 2012

Studio 5.2 Quick Reference Guide

Add Columns to End Move Up

Disable Find/Replace Project Menu Open Project Close Project

Copyright 2000-2012 Progress Software Corporation. All rights reserved.

Studio 5.2 Quick Reference Guide

The File Tab

Studio 5.2 Quick Reference Guide

The Active Studio Window

File Naming Restrictions

Studio 5.2 Quick Reference Guide

Importing Studio Files from Earlier Versions

Copyright 2000-2012 Progress Software Corporation. All rights reserved.

January 13, 2012

Studio 5.2 Quick Reference Guide

THE RULE PROJECT

CREATING A RULE PROJECT

on the toolbar and select Rule

Copyright 2000-2012 Progress Software Corporation. All rights reserved.

January 13, 2012

Studio 5.2 Quick Reference Guide

The Rule Project Explorer Window

Copyright 2000-2012 Progress Software Corporation. All rights reserved.

Studio 5.2 Quick Reference Guide

Copyright 2000-2012 Progress Software Corporation. All rights reserved.

January 13, 2012

Studio 5.2 Quick Reference Guide

Copyright 2000-2012 Progress Software Corporation. All rights reserved.

January 13, 2012

Studio 5.2 Quick Reference Guide

THE VOCABULARY WINDOW

Studio 5.2 Quick Reference Guide

Vocabulary Menubar Options