Qualification objects are used to test data. You can compare the data to a table entry, a literal, or another piece of data. The results of the qualification determine whether transaction production runs an input transaction through a specific production object, rule object, or rule component object.
At the production object level, use qualification objects in environments where an input transaction contains specific types of data in a given 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, all input transactions associated to a set of production objects may have the same format, but contain different data depending on the ID code field. The current production object should only process transactions that have an ID code of 10. You can 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 non-optional qualification objects before the production object begins processing the transaction.
Qualification objects can be attached to field objects in two positions. The first position, candidacy, determines whether or not the field object should attempt to parse the next part of the transaction. Candidacy is a method for using earlier data to dictate the use of later data. For example, an input transaction could contain different data depending on the contents of the first field. If an input transaction contained this data:
1234|John Doe|Acctg
you could set up five field objects:
ID – the first field
NameNum – the second field if ID is numeric
NameAlph – the second field if ID is alphabetic
DeptNum – the third field if ID is numeric
DeptAlph – the third field if ID is alphabetic
Using candidacy in the name and department fields allows more precise processing of input transactions.
Once a field object receives the data, you can use qualification to determine if the transaction should be processed. If the transaction does not pass this level of qualification, transaction production passes the input transaction to the next production object if the input transaction’s transaction ID is “ENGINE.” If the transaction is routed to only one production object and the transaction fails qualification, the transaction is sent to the unrouteable log file.
At the rule or rule component level, use qualification objects when the input transaction may or may not contain data the rule or rule component needs to act upon. For example, a qualification object can check for the existence of an optional field object. When the production object contains optional field objects, if data for those field objects is not present in the input transaction, then transaction production should not run the transaction through rules or rule components designed to act on that specific piece of the input transaction. If an input transaction does not pass all of a rule or component object’s non-optional qualification objects, then transaction production does not process the transaction through that specific rule or rule component.
Figure 1-4 illustrates a more complex production object that uses qualification and filter objects in addition to field and rule objects.
Figure 1-4: Complex production object
Field objects contain input transaction data and can place that data into datalink objects. DataLink objects allow you to change the content of a piece of data and use the changed data within other TRAN-IDE objects. The data retains its original content in the field object.
A qualification object determines if transaction production should continue processing the transaction through the TRAN-IDE object that the qualification object is attached to. You can attach a qualification object to a field object, production object, rule object, and rule component object.
A rule object is a logical container for the rule components and their filters that generate the pieces of the output transaction. A rule component determines which pieces of the data (that is, which field objects) to manipulate and place into the rule object’s output message area.
Filter objects perform further and more complex data manipulation on the piece of the input transaction that its parent object is processing.
| Copyright © 2005. Sybase Inc. All rights reserved. |
|
|
