Transaction production objects

Transaction production uses the following types of objects, which you create and configure using TRAN-IDE.

A production object is a logical container for other TRAN-IDE objects. Production objects describe the relationship between an input transaction and the processing a transaction’s data must go through to produce the output transaction.

A production object may contain any number of objects, but must contain at least one input object (input field), one rule object (output rule), and one rule component object (rule component).

The production object’s name is used to identify the production object when you configure an SFM in the Impact Configurator. See the e-Biz Impact Configuration Guide.

Production objects can include:

Input objects Input objects (input fields) are required for each piece of data in the input transaction that the production object needs to manipulate or place into the output transaction. For example, if an incoming transaction contained the following data, you would build an input field object for each discrete piece of data—first_name, last_name, street, and so on.

first_name|last_name|street|city|state|zipcode

Build input field objects to define all of a transaction’s data before you build any other objects.

Rule objects Rule objects are a logical container for the components and filters that manipulate a piece of the input transaction to produce a part of the output transaction. Once you place the input data into input field objects, transaction production starts with the first rule object in the production object and continues through each rule in the list.

Each rule object contains:

One or more rule component objects, which operate on individual input field objects. Component objects are executed in serial order.
A storage area, called a blob, where the output from the rule components is assembled. As the output of each rule component is generated, it is appended to the blob.
One or more filters, which operate on the blob after all rule components have finished processing.

Subrule (rule component) objects Each rule component object generates a piece of the output transaction by manipulating the data in an input field object with a filter object, or by defining a literal value to place into the output transaction.

A rule component object can also manipulate a rule object’s blob, affecting the output transaction up to and including its own contribution to the blob.

Filter objects Filter objects perform further and more complex data manipulation on the piece of an input transaction that its parent object is processing.

Filter object changes can add, change, or remove characters, compare the data to a table or database, or substitute a different piece of data. When an input field object is operated on by a rule object to generate an output transaction, filter objects are most often the means of creating the new data from the old.

You can use filter objects within rule component objects, or rule objects, working on data either before or after it has been processed by an object. The data that the filter object acts upon depends on which object contains the filter object and where the filter object is placed in that object.

Table objects Table objects contain one or more columns of data that specify data that should go into the output transaction. Field data that matches a value in the designated search column of the table is replaced with the corresponding values in the specified columns.

You can use table objects in filter or qualification objects. When you use them in a filter object, specify within the filter the table column to search for data that matches the data passed to the filter. You can also specify which columns’ corresponding values to put in the output transaction when data matches on the search column.

When you use table objects in a qualification object, specify which table column to search for data that matches the data passed to the qualification object. If the data does not match, the qualification object fails.

Variable (datalink) objects A datalink defines a data variable used to hold a copy of data from an input field object, results of a calculation, or any other data for which a variable field is useful. Datalinks objects are optional.

When you attach a datalink to an input field object, transaction production places a copy of the input field object’s data into the datalink after the transaction has been parsed and before it undergoes field and production object qualification. You can use datalink objects in a qualification function to access the contents of other input field objects.

You can also use datalinks to reference an input field object’s data in an object that does not work directly with the current field. For example, a rule object may check for an age range before allowing a senior citizen discount to go through.

Qualification objects Qualification objects are used to test data. The data can be compared to a table entry, a literal value, or another piece of data. Qualification results determine whether or not transaction production should run an input transaction through a specific production object, rule object, or rule component object.

At the production object level, use qualification objects when an input transaction contains specific types of data in a field (like a transaction code, date, or state) and you want to process only certain forms of the transaction with the current production object. For example, if a production object’s input transactions have the same format, but contain different data depending on the ID code field, the production object could process only transactions that have an ID code of “10”. You have a qualification object check for an ID code of “10” to determine if a transaction should be processed. An input transaction must pass all of a production object’s required qualification objects before the transaction begins processing.

You can attach qualification objects to input field objects in two positions. The first position, candidacy, determines whether the field object should try to parse the next part of the transaction. Candidacy is a way to use earlier data to dictate the use of later data.

At the rule or rule component level, use qualification objects when the input transaction may contain data that the rule or rule component needs to act upon. If an input transaction does not pass all of a rule or component object’s required qualification objects, transaction production does not process the transaction through that specific rule or rule component.

Function objects ODL functions are user-written functions that perform data validation or manipulation. ODL function objects are used to perform any type of data manipulation or validation not available through other TRAN-IDE objects. ODL function code is developed using MSG-IDE.

You can build several types of ODL functions and attach them to different TRAN-IDE objects. ODL functions have a specific purpose, receive specific arguments, and transaction production executes them at pre-determined points when processing a transaction.

You can also build generic ODL functions directly in the TRAN-IDE tool. Generic ODL functions have a slightly different format than other functions because they do not have a specific purpose determined by a TRAN-IDE object, and because you determine what arguments to pass to them. Generic ODL functions cannot be attached to a TRAN-IDE object; they must be called from within other functions attached to TRAN-IDE objects.