This example describes most of the steps that occur as a transaction passes through each object in a production object. Processing at the rule component level is quite detailed and is covered in “Rule component processing example”.
This example also introduces the blob work areas attached to rule component objects, rule objects, and production objects. The blobs are where transaction production assembles the pieces of the output transaction as it processes the input transaction through the production object. Whenever processing enters a rule or rule component, the object’s blob is initially empty.
The component’s blob contains the data you choose to manipulate in that component. The component’s filters act upon the data in this blob and concatenate the results into the rule’s blob. The rule’s blob contains all of the output from its components. When the rule is done processing, it concatenates the contents of its blob into the production object’s blob. The production object’s blob contains all of the output from its rule objects. When processing through all of a production object’s rules is complete, that production object’s blob contains the final output transaction.
In this example, the input transaction contains a name, address, and age. The examples given with the various object descriptions refer to different pieces of this transaction and will not relate sequentially. For a step-by-step example of the objects needed to produce an output transaction from specific input transaction data, see the examples in “Building production objects”.
Whenever transaction production encounters a processing error in this example, it stops processing the transaction and does one of the following:
If the SFM receives the transaction with route_vprod, it writes the transaction to the unrouteable log file and starts processing the next transaction.
If the SFM receives the transaction with route_vrec, it passes the transaction to the next production object associated with the SFM and begins this processing sequence again.
If the SFM receives the transaction with route_recx and the Options argument contains RO_ BYPRODNAME, it performs the same actions as for route_vprod. Otherwise, it performs the same actions as for route_vrec.
Figure 1-7: General processing example
Input transaction – the SFM receives the transaction with the route_vprod routing function command or with the route_recx routing function command that contains RO_BYPRODNAME in the Options argument. Transaction production passes the transaction to the production object listed in the routing function.
or
The SFM receives the transaction with a Tran ID of “ENGINE” in the route_vrec routing function or with the route_recx routing function that contains RO_BYENGINENAME in the Options argument or with the route_vprod function specifying an engine grouping containing this production object. Transaction production passes the transaction to the first production object associated with the SFM.
Field objects – transaction production parses the contents of the input transaction into the field objects and performs data type validation. If parsing or validation fail, transaction production stops processing the transaction through this production object.
If the transaction passes parsing and validation, the object populates any datalink objects attached to the field objects.
Qf – executes any qualification objects attached to the field objects. If any required (the “Optional” preference is not selected) qualification objects fail, processing through this production object stops.
The purpose of a qualification object attached to a field object is to determine if the input transaction contains the data that the field objects should receive. This should be a broader check than that done in a production object’s qualification object, since all of the production objects in a project share the same field objects.
For example, for a field object that contains an age value, check that the value is between 21 and 55. Then individual production objects can check for an exact ages within that range.
Qp – executes any qualification objects attached to the production object. If any required (the “Optional” preference is not selected) qualification objects fail, then stop processing through this production object.
The purpose of a qualification object attached to a production object is to determine if the production object should process the transaction. Often, several input transactions contain the type of data that passes field object parsing, validation, and qualification, but you want the production object to process only those transactions that have a specific value in a part of the data.
For example, a piece of the input transactions may contain any value in the range between 21and 55. However, this production object should process only those transactions with that piece of data in the range 35 to 45, so the qualification object checks for that range.
Qr – executes any qualification objects attached to the rule object. If any required (the “Optional” preference is not selected) qualification objects fail, processing stops through this rule object.
The purpose of a qualification object attached to a rule object is to determine if the rule object should process the transaction. Often, an input transaction may contain data that a particular rule object does not need to act upon.
For example, part of the input transaction is a zip code. This rule object should run only when the zip code is “94553,” so the qualification object checks the zip code data for that value.
R – enters the rule object.
A rule object is a logical container for the components and filters that manipulate a piece of the input transaction to produce a part of the output transaction.
Qc – executes any qualification objects attached to the component object. If any required (the “Optional” preference is not selected) qualification objects fail, then stop processing through this component object.
The purpose of a qualification object attached to a component object is to determine if the component object should process the transaction. Often, a rule object has one or more components that you want to run only when the data is in a specific form or when a specific piece of data is present in the input transaction.
For example, the component contains a filter that truncates the first name data to ten characters. If the first name is less than ten characters, then you do not want to enter the component and run that filter, so the qualification object checks the length of the first name data.
C – copies the data in the selected field object, literal, group, or datalink object into the component’s blob.
A component object defines the piece of the input transaction to manipulate and place into the output transaction. A component object is also a logical container for filters.
Fc – runs the component’s filters on the data in the component’s blob. Once all data manipulation is finished, concatenates the contents of the component’s blob into the rule’s blob. Processing through a component’s filters is very detailed. See “Rule component processing example” more information.
A component’s filters perform additional data manipulation on the piece of the input transaction defined by the component. Use filters to perform any action necessary when processing the input transaction into the required output transaction. Use of filters is optional. When filters are not present in the component, then the data that the component defines is placed unchanged into the output transaction.
For example, the component’s blob contains a first name. The destination only needs the first ten characters of the name, so this filter runs the truncL built-in filter function on the component’s blob data.
Fr – runs the rule’s post-filters on the data in the rule’s blob. Once all data manipulation is finished, concatenates the contents of the rule’s blob into the production object’s blob.
A rule’s post-filters perform additional data manipulation on the final output of all of the rule’s component objects.
For example, the destination needs a separator pattern added to the piece of the output transaction that the components just built, so one of the rule’s post-filters appends “|*|*|” onto the rule’s blob data.
Fp – runs the production object’s post-filters on the data in the production object’s blob.
A production object’s post-filters perform additional data manipulation on the final output of all rule objects. For example, the destination needs the entire output transaction in upper case letters, so one of the production object’s post-filters runs the ToUpper built-in filter function on the production object’s blob data.
Output transaction – the SFM sends the output transaction to its destinations as configured in the e-Biz Impact Configurator.
| Copyright © 2005. Sybase Inc. All rights reserved. |
|
|
