The behavior of scenario, scenario suite, and simulation execution is controlled by a configuration file, defined in XML files according to a schema (XSD), located in <InstallDir>/doc/schemas.

Configurations are structured in a hierarchy, with possible configuration files at each of the simulation, scenario suite, and scenario levels. At least one configuration must be defined, with the configuration at the most granular level taking precedence over any others.

A configuration provides:

The following is an example configuration that will be analyzed in the following sections:

<configuration>
  <name>loan validation configuration XML</name>
  <description>Configuration for scenarios in loanvalidation-xom</description>
  <precision>
    <double>1E-2</double>
    <string>0</string>
    <date>1</date>
  </precision>
  <executor>
    <class>ilog.rules.ras.core.executor.IlrDefaultExecutor</class>
    <url></url>
    <!--<class>ilog.rules.ras.core.executor.IlrHTTPExecutorImpl</class>
    <url>http://localhost:8080/ssp</url>-->
  </executor>
  <databinding-in>
    <input>
      <class>ilog.rules.ras.binding.xml.impl.IlrXMLInOutParametersImpl</class>
      <url>./data/scenario/inputs/xml</url>
    </input>
    <subcomponent>
      <class>ilog.rules.ras.binding.xml.impl.IlrXMLRSMBindingObjectImpl</class>
      <url>./data/scenario</url>
    </subcomponent>
    <baseline-report>
      <class>ilog.rules.ras.binding.xml.impl.IlrXMLDataReportImpl</class>
      <url>./data/scenario/reports/xml</url>
    </baseline-report>
  </databinding-in>
  <databinding-out>
    <output>
      <class>ilog.rules.ras.binding.xml.impl.IlrXMLInOutParametersImpl</class>
      <url>./data/</url>
    </output>
    <working-memory>
      <class>ilog.rules.ras.binding.xml.impl.IlrXMLInOutParametersImpl</class>
      <url>./data/scenario/reports/xml</url>
    </working-memory>
    <report>
      <class>ilog.rules.ras.binding.xml.impl.IlrXMLDataReportImpl</class>
      <url>./data/scenario/reports/xml</url>
    </report>
  </databinding-out>
</configuration>

Name and Description

Each configuration definition includes a name for the configuration, which is required to identify it in scenario, scenario suite, and simulation definitions. The name can be any string, avoiding special characters. For example:

<name>loan validation configuration XML</name>

You can also provide a short description for the configuration, although this is optional. For example:

<description>Configuration for scenarios in loanvalidation-xom</description>

Precision

The precision of data in tests determines the degree of accuracy in their comparisons. In a configuration, you can set the precision for three types of data: double integers, strings, and dates, as follows:

For example:

<precision>
  <double>1E-2</double>
  <string>0</string>
  <date>1</date>
</precision>

Executor Class

The executor is a Java class that acts as a proxy in the execution of a scenario. It determines if the execution is performed locally (Java SE environments) or via the HTTP protocol (Java EE environments) through a Rule Execution Server. The executor is specified by giving its class path and name and its URL in the configuration.

Rule Scenario Manager supplies an HTTP executor class that can be used to execute scenarios on a remote or local SSP deployment:

ilog.rules.ras.core.executor.IlrHTTPExecutorImpl

Its URL must be the same as the SSP URL:

http://hostname:port/[ssp-deployment-name]

The default executor executes the scenarios in the local VM. This requires that the rule engine is part of the local VM. The default executor is:

ilog.rules.ras.core.executor.IlrDefaultExecutor

For example:

<executor>
  <class>ilog.rules.ras.core.executor.IlrDefaultExecutor</class>
  <url></url>
  <!--<class>ilog.rules.ras.core.executor.IlrHTTPExecutorImpl</class>
  <url>http://localhost:8080/ssp</url>-->
</executor>

New executor classes can be defined and implemented by developers.

Input Databinding

The input data that the ruleset is executed on must first be mapped from its input format to Java objects. This is done by a databinding mechanism, defined by Java classes. Standard databinding maps input data from XML or Excel formats, but developers can create new databinding classes as required.

An input databinding class is specified in configuration files within the <databinding-in> element, by way of its classname and the location (URL) of the input data source files. This location acts as the path for the input data files declared in scenario definitions. For example:

<input>
  <class>ilog.rules.ras.binding.xml.impl.IlrXMLInOutParametersImpl</class>
  <url>./data/scenario/inputs/xml</url>
</input>

Subcomponent Databinding

The definitions of the constituent scenarios of a scenario suite, and of the constituent scenario suites of a simulation, must be mapped by a databinding mechanism during the execution of the owning suite or simulation. This databinding of the "subcomponent" definitions is performed by Java classes, either Rule Scenario Manager-supplied or newly created by developers.

A subcomponent databinding class is specified in configuration files within the <databinding-in> element, by way of its classname and the location (URL) of the subcomponent definition source files. This location acts as the path for the subcomponent files declared in scenario suite and simulation definitions. For example:

<subcomponent>
  <class>ilog.rules.ras.binding.xml.impl.IlrXMLRSMBindingObjectImpl</class>
  <url>./data/scenario</url>
</subcomponent>

The default Rule Scenario Manager subcomponent databinding is from XML data.

Baseline Report Databinding

A given scenario report can be used as a reference in tests defined in subsequent scenario executions. The values contained in this baseline report are extracted and used as the test values in the new tests, allowing regression testing on a changing ruleset.

Baseline reports are specified in scenario definitions, but they must also be associated with a databinding mechanism to map the baseline report's data during the scenario execution. This databinding is performed by Java classes, either Rule Scenario Manager-supplied or newly created by developers.

A baseline report databinding class is specified in configuration files within the <databinding-in> element, by way of its classname and the location (URL) of the baseline report source files. This location acts as the path for baseline report files declared in scenario definitions. For example:

<baseline-report>
  <class>ilog.rules.ras.binding.xml.impl.IlrXMLDataReportImpl</class>
  <url>./data/scenario/reports/xml</url>
</baseline-report>

Output Databinding

The output data that results from the execution of rules must be translated by a databinding mechanism to provide it in human-readable form. This databinding is performed by Java classes, either Rule Scenario Manager-supplied or newly created by developers.

An output databinding class is specified in configuration files within the <databinding-out> element, by way of its classname and the location (URL) where the output data is placed. This location acts as the path for output data files created during scenario executions. For example:

<output>
  <class>ilog.rules.ras.binding.xml.impl.IlrXMLInOutParametersImpl</class>
  <url>./data/</url>
</output>

Working Memory Databinding

The contents of the working memory can be included in the execution trace of a ruleset execution, but the data must first be mapped by a databinding mechanism to provide it in human-readable form. This databinding is performed by Java classes, either Rule Scenario Manager-supplied or newly created by developers.

A working memory databinding class is specified in configuration files within the <databinding-out> element, by way of its classname and the location (URL) where the working memory data is placed. This location acts as the path for working memory data files created during scenario executions. For example:

<working-memory>
  <class>ilog.rules.ras.binding.xml.impl.IlrXMLInOutParametersImpl</class>
  <url>./data/scenario/reports/xml</url>
</working-memory>

Report Databinding

At the end of a scenario, scenario suite, or simulation execution, a report is produced containing the results of the execution, including execution traces and test results. A databinding mechanism is required to map the report data to a human-readable form, such as XML. This databinding is performed by Java classes, either Rule Scenario Manager-supplied or newly created by developers.

A report databinding class is specified in configuration files within the <databinding-out> element, by way of its classname and the location (URL) where the reports are placed. This location acts as the path for report files created during scenario, scenario suite, and simulation executions. For example:

<report>
  <class>ilog.rules.ras.binding.xml.impl.IlrXMLDataReportImpl</class>
  <url>./data/scenario/reports/xml</url>
</report>

Examples of Scenario Suite Databinding

In the basics-javabinding sample, the class myPackage.userDefined.CustomSuiteExcelBinding shows how to use the Rule Scenario Manager API to override the default scenario suite binding. A use case of this binding is shown in the myPackage.MyCustomSuiteJUnit sample class. This new databinding allows a scenario suite to be defined as an Excel spreadsheet that contains multi-input scenarios. An example of such an Excel spreadsheet is provided with the basics-javabinding/data/scenario/customsuite/MySuite.xls file.

Related Concepts

Related Tasks

Related Reference

Related Samples