Batch Processor Output

Batch Processor output

Go to:

Value formats for csv output

Value formats for database output

Coverage output

Test case output

Sessions output

Include inferred entities in Batch Processor output

Value formats for csv output

When the Batch Processor writes out csv output it writes them in the following manner:

Input values (those provided in the input csv) are written as they were provided (that is, input format is unchanged)
Output values are written in a format depending on their value type; the formats are outlined in the following table:

Value Type	Output Format	Uncertain or Unknown
Number and Currency	Numeric values written as decimal numbers with a period as the decimal separator. The number is formatted up to 15 significant decimal places; for example: 3.123456789876543	Both written as blank
String	String values are written as is.	Both written as blank
Boolean	Boolean are always written as "true" or "false"	Both written as blank
Date	Date values are always written in the format "yyyy-MM-dd" where: yyyy is the four-digit year. MM is the two-digit month, including leading zero for values below 10. dd is the two-digit day, including leading zero for values below 10.	Both written as blank
DateTime	Date time are always written in the format "yyyy-MM-dd HH:mm:ss" where: yyyy is the four-digit year. MM is the two-digit month. dd is the two-digit day. HH is the two-digit 24-hour hour value. mm is the two-digit minute value. ss is the two-digit seconds value.	Both written as blank
Time	Time are always written in the format "HH:mm:ss" where: HH is the two-digit 24-hour hour value. mm is the two-digit minute value. ss is the two-digit seconds value.	Both written as blank

Value formats for database output

Batch Processor results are written to the database using JDBC. It is recommended that where possible, the output column in the database matches the Oracle Policy Automation attribute (date and datetime, numbers and so on).

When writing date or datetime attributes to the database, the resulting value will depend on the data type of the table column to which it is being written:

If an Oracle Policy Automation date or datetime attribute is written to a text field, the resulting value will depend on the default formatting for dates and times for that database; the resulting value will be the date, formatted by the database as a string. The formatting of this date must be controlled by the formatting in the database; it is recommended that you consult your database documentation for further information.
If an Oracle Policy Automation number or currency value is written to a text field, the resulting value will, as mentioned above, depend on database formatting.

For boolean values, a global boolean format is provided to control the value written to the database; see the topic Specify the global boolean format.

Null values are always treated as uncertain; except for string types which will produce output ofempty string.

Coverage output

When the output of the batch processor is set to coverage (--coverage <coverage file>) the result is a single file which can be imported into Oracle Policy Modeling as follows:

Select Analyze coverage file from the Reports menu.
Select the coverage file generated by the batch processor and click on the Open button; the coverage file will be imported into Oracle Policy Modeling.

For more information see the Oracle Policy Modeling User's Guide.

Test case output

When the output of the Batch Processor is set to test cases (--exporttsc <filename>), the result is a single file which can be imported into Oracle Policy Modeling as follows:

In the Project explorer, right-click and choose "Import existing file".
Select the test case file generated by the Batch Processor and click on the Open button; the test cases file will be imported into Oracle Policy Modeling.

For more information see the Oracle Policy Modeling User's Guide.

Sessions output

When the output of the Batch Processor is set to sessions (--export <export dir>) the result is a set of OPA sessions, generated as XML files. There will be one session file generated for each case.

A session XML file can be used in Oracle Policy Modeling debugger. To load an individual session file into an active debugger session in Oracle Policy Modeling as follows:

Start the debugger.
In the Data tab of the debugger click on the Import button.
Select the session file to import and click on OK; the session data will be imported into the active debugger session.

Include inferred entities in Batch Processor output

The Batch Processor supports the ability to include inferred entities as output when writing to DB tables or CSV data files. The output will include the containment relationships of the inferred entities, but will not include any other inferred relationship details. Inferred entity output is only supported for database output or test script output; other output types such as session data, do not include inferred entities.

Output mapping

To include instances of an inferred entity in the output, the CSV input directory must include a data file that the Batch Processor can match to the inferred entity. The data file mapping rules are the same as those for non-inferred entities:

Using an XML configuration file, an inferred entity name can be explicitly mapped to a CSV data file by using a <mapping> element.
If an explicit mapping is not provided, the inferred entity name is implicitly mapped to a CSV data file matching the public name of the inferred entity.

As with non-inferred entities, implicit mappings are supported when reading from CSV data files. When reading from a database, a configuration file with explicit mappings is required. If no explicit or implicit mapping can be found for an inferred entity, instances of the inferred entity will not be included in the output.

Output assumptions

When writing inferred entity output, the Batch Processor will apply the following assumptions:

Assumption
The output destination is empty	Before the Batch Processor is run with inferred entity output, the output destination for the inferred entity output should be empty For CSV output, the input file is used to define the structure of the output file only. Any data rows in the input file will be ignored, and will not be included in the output file. For DB output, the Batch Processor will attempt to insert the inferred entity instances as new rows in the database table. If the Batch Processor is generating the primary key values and the output table is not empty, key violations may occur. If a key violation occurs, the entire block of case output will be rolled back and the Batch Processor will stop. If the database is generating the primary key values and the output table is not empty, the new output rows will be inserted with the existing output rows from previous runs of the batch processor. The data written out does not include an easy way of separating the output from multiple Batch Processor runs.
All output attributes are identified	Every attribute to be included in the output of an inferred entity must be identified as an output attribute. Attributes identified as input, or not identified in the implicit or explicit mapping will be excluded from the output. For implicit mappings, the column names, including the '#' identity column, must be marked as output using parenthesis characters; for example: (column_name) For explicit mappings, the field configuration must include the output="true" attribute; for example: <attribute name="attr_1" field="field_1 output="true" />

Assumption

The output destination is empty

Before the Batch Processor is run with inferred entity output, the output destination for the inferred entity output should be empty

For CSV output, the input file is used to define the structure of the output file only. Any data rows in the input file will be ignored, and will not be included in the output file.
For DB output, the Batch Processor will attempt to insert the inferred entity instances as new rows in the database table.
- If the Batch Processor is generating the primary key values and the output table is not empty, key violations may occur. If a key violation occurs, the entire block of case output will be rolled back and the Batch Processor will stop.
- If the database is generating the primary key values and the output table is not empty, the new output rows will be inserted with the existing output rows from previous runs of the batch processor. The data written out does not include an easy way of separating the output from multiple Batch Processor runs.

All output attributes are identified

Every attribute to be included in the output of an inferred entity must be identified as an output attribute. Attributes identified as input, or not identified in the implicit or explicit mapping will be excluded from the output.

For implicit mappings, the column names, including the '#' identity column, must be marked as output using parenthesis characters; for example: (column_name)
For explicit mappings, the field configuration must include the output="true" attribute; for example: <attribute name="attr_1" field="field_1 output="true" />

Generating Primary Key values

When writing inferred entity output, the Batch Processor is creating new rows in the table which require unique primary key values. If writing to a database table that includes an auto-generating primary key, setting the primary-key-auto attribute to true in the entity configuration instructs the Batch Processor to allow the database to provide the primary key values when new rows are inserted:

If the primary-key-auto attribute is set to false, is excluded, or the Batch Processor is writing output to CSV files, then the Batch Processor will attempt to generate the primary key values. If the generated key causes a key violation with existing data when writing new rows with generated keys, the entire block of cases will be rolled back and the Batch Processor will stop and report the error.

Examples

The following are simple examples of how instances of the inferred Benefit entity can be included in the output, using explicit configuration and implicit configuration. The examples are based on the Inferred Benefits example rulebase provided with Oracle Policy Automation and located at: examples\rulebases\InferredBenefits.zip.

Explicit configuration

The CSV input directory contains a CSV file named benefit-mapped.csv. This file contains a row of column headings only and contains no data. The column headings are not marked as output, and do not match the public names of the inferred entity attributes:

The XML configuration file contains a <mapping> element for the benefit entity:

...
  <mapping entity="benefit" table="benefit-mapped" primary-key="#" >
    <attribute name="benefit_name" field="b-name" output="true" />
    <attribute name="benefit_total_eligible" field="b-total" output="true" />
    <relationship name="all-benefits" source-entity="global" foreign-key="g-key" />
  </mapping>
...

The explicit mapping instructs the Batch Processor to map the inferred benefit entity to the benefit-mapped.csv file with the identified output columns for the entity attributes.

Implicit Configuration

The CSV input directory contains a CSV file named benefit.csv, matching the public name of the benefit entity from the rulebase; no explicit mapping is provided. The file contains a row of column headings only and no data. The column headings are marked as output and match the public names of the inferred entity attributes:

In the absence of an explicit mapping provided by a configuration file, the Batch Processor will match the benefit.csv _file name to the public name of the _benefit entity. The identified output columns will be mapped to the entity attributes with matching public names.