Relative to release 410
Workstation Event Driven Messaging
| Point in Time
| Message Group Type
| Route
|
| After Central System Load
| BAT_LOADED
BAT_SNAP_NEW | <Archive>
<Archive> |
| Before Payment
| BAT_SNAP_PAY
| <Archive>
|
| After Remittance
| BAT_SNAP_REMIT
| <Archive>
|
| After Batch Closed
| BAT_CLOSED
| <Archive>
|
Example
In a typical scenario, Trax will map a batch, run rules, and then transfer the batch to the customer for final exception processing and payment. In this case, the life of a batch may look like this:
| Workgroup
| Point in Time
| Message Group Type
| Route
| Process
|
| Trax
| After Trax has run rules
| BAT_TRANSFER
BAT_ARCHIVE | Customer X
<Archive> | Manual
Piggybacked |
| Customer X
| After Transfer Load
| BAT_POD
| <Originator>
| Automatic
|
| Customer X
| Before Payment
| BAT_SNAP_PAY
| <Archive>
| Automatic
|
| Customer X
| After Remittance
| BAT_SNAP_REMIT
| <Archive>
| Automatic
|
| Customer X
| After Batch Closed
| BAT_CLOSED
| <Archive>
| Automatic
|
| Workgroup
| Point in Time
| Message Group Type
| Route
| Process
|
| Trax
| After Trax has run rules
| BAT_TRANSFER
BAT_SNAP_ARCHIVE | Customer X
<Archive> | Automatic
Piggybacked |
| Customer X
| After Transfer Load
| BAT_POD
| <Originator>
| Automatic
|
| Customer X
| Before Payment
| BAT_UPDATE
BAT_SNAP_PAY | <Originator>
<Archive> | Automatic
Piggybacked |
| Customer X
| After Remittance
| BAT_UPDATE
BAT_SNAP_REMIT | <Originator>
<Archive> | Automatic
Piggybacked |
| Customer X
| After Batch Closed
| BAT_CLOSED
| <Originator>
| Automatic
|
BAT_SNAP_ARCHIVEs are always retained in the Archive at the site where they
are generated. If the customer does not want to keep Archives locally, then they
can simply remove the <Archive> route and no local Archives will be generated.
All messages, after being loaded are moved to the <Archive> directory so a
complete copy of the history will exist at Trax regardless of the customer
A manual component may well remain, at least on the Trax side if we are to
manually review bills (but not necessarily clear them) prior to Transfering the
batch to the customer.
BAT_SNAP_PAY and BAT_SNAP_REMIT messages can now be thought of just as special
instances of the generic BAT_SNAP_ARCHIVE. Although BAT_SNAP_ARCHIVE is
sufficient, BAT_SNAP_PAY and BAT_SNAP_REMIT will be left in place since they will
ease manual recovery situations.
This is just one possible scenario. Many different scenarios exist.
The New Model
A more flexible model allows for configuration at each workgroup of what kinds of messages are sent, at what time, and to whom. As a side effect, all snapshot type messages (this includes Transfers and Updates) will have BAT_SNAP_ARCHIVEs piggybacked so that effective backup is a byproduct of the message transfers.
In this model, many events will be defined at which time it may be desirable to send a message group. The majority of these events will not be used, but they will be defined nonetheless for completeness and flexibility. These events are:
| Event
| System Default Group Type
| System Default Route
|
| AfterCentralSystemLoad
| BAT_SNAP_NEW
| <Archive>
|
| AfterPostingToHistory
|
|
|
| AfterRulesExecution
|
|
|
| BeforeRulesError
|
|
|
| AfterRulesError
|
|
|
| BeforePrecedence
|
|
|
| AfterPrecedence
|
|
|
| BeforeMapping
|
|
|
| AfterMapping
|
|
|
| BeforeDuplicate
|
|
|
| AfterDuplicate
|
|
|
| BeforeFinancial
|
|
|
| AfterFinancial
|
|
|
| BeforeCostAllocation
|
|
|
| AfterCostAllocation
|
|
|
| AfterExceptionReturn
|
|
|
| BeforePayment
| BAT_SNAP_PAY
| <Archive>
|
| AfterRemittance
| BAT_SNAP_REMIT
BAT_CLOSED | <Archive>
<Originator> otherwise <Archive> |
While it may appear that events such as AfterFinancial and BeforeCostAllocation are one in the same, they are not. For instance, if only an AfterFinancial was defined, a batch leaving Financial and going to Cost Allocation would get a message group whereas a batch returning from Payment to Cost Allocation would not. However, if the event were defined as a BeforeCostAllocation event, then a message group would be generated in each case.
If a customer chooses to deal with all manual exceptions themselves, then it would seem appropriate to define a BeforeDuplicates, BeforeFinancial, and BeforeCostAllocation event as a transfer to the customer. This is in fact the case. A BeforePayment event should also be defined in case the batch goes straight to payment.
As a batch passes each event type, each event which is defined will
“Register Intent” to generate the configured message group. Obviously it would be entirely superfluous (and a waste of resources) to generate a Transfer at BeforeDuplicates, BeforeFinancial, BeforeCostAllocation, and BeforePayment for a batch which goes straight to Payment. Instead, each of these configured events will be “Registered” in the persistent queue (the QUEUE table). Then, the last responsibility of the initiating process will be to process those registered events, examine the sum total, and then choose the appropriate message group(s) to be generated. This will have the effect of economizing the generated groups.MSG_EVNT Type Parameter Replacements Within EXPR_COND
While these configurations will be maintained per Owner_Key, it may be desirable to have different behavior for different carriers within an Owner_Key. EXPR_CONDs will be defined that expose several fields within INV_BAT for all MSG_EVNTs. The following table summarizes parameter replacements which are valid for each MSG_EVNT type when constructing an EXPR_COND.
| Parameter
| Possible Values
| Allowable MSG_EVNTs
|
| <VEND_LABL>
<BAT_KEY> <BAT_STAT> <BAT_TYPE> <BAT_CREAT_DTM> <BAT_DUE_DTM> <BAT_FB_CNT> <BAT_AMT> <BAT_APP_AMT> <BAT_SNAP_CNT> <BAT_MSG_CTRL_STAT> <MSG_GRP_ORIG_HIST> | Values found in the INV_BAT table at the point in time that Message generation
is requested
| All
|
| <Old_EX_BAT_KEY_TYPE>
and <New_EX_BAT_KEY_TYPE> | “”
"Rules Error" "Precedence" "Mapping" "Duplicate" "Financial" "Cost Alloc" | All except the following:
AfterCentralSystemLoad AfterRulesExecution AfterRemittance |
The MSG_EVNT table (part of ROUTING.MDB, introduced in 381) holds customer defined Message Group Events. Its description is as follows:
| Field Name
| Data Type
| Description
|
| OBJ_CLASS
| Text
| The class of object to whom this MSG_EVNT applies. For invoice batches, “INV_BAT” will be used.
|
| MSG_EVNT
| Text
| The name of an event which is defined as being in the life of an object such
as an INV_BAT.
|
| OWNER_KEY
| Text
| The Owner_Key to whom this Message Event belongs, or 000-0000 if used for all
Owners
|
| MSG_SEQ_NUM
| Number
| A sequence number which control execution order when multiple entries exist
for a given MSG_EVNT
|
| IN_USE_FLAG
| Yes/No
| A flag, which must be true if this record is to be used
|
| EXPR_COND
| Memo
| An optional expression which when present will be evaluated using <expr>
replacement appropriate to the context of use. If the expression exists, it must
evalute to True for FUNC_MEMO to be executed
|
| FUNC_MEMO
| Memo
| An expression which contains a function to be executed in response to this
particular event.
|
Register_Standard_Message ( <OBJ_CLASS>
, <OBJ_ID>
, <MSG_GRP_TYPE>
, <Route>
, <Mandatory>
, <Priority>
)
where:
| <OBJ_CLASS>
| As of R393, it must be “INV_BAT”.
|
| <OBJ_ID>
| The INV_BAT_ID of the batch for which this call is for. This will be filled
in using parameter replacement.
|
| <MSG_GRP_TYPE>
| The type of message group to be generated. Customer configurable types are “BAT_SNAP_ARCHIVE”, “BAT_TRANSFER”, and “BAT_SNAP_UPDATE”.
|
| <Route>
| Any valid entry in the ROUTING table.
|
| <Mandatory>
| True if this message must be generated, regardless of the other registered
messages, or False, if the workstation is allowed to choose the appropriate
type(s) of message group(s) to generate based on all currently registered entries.
This will typically be False.
|
| <Priority>
| If Mandatory if False, a Priority (from 0 to 100), where 100 is the highest
priority, which assists the workstation in deciding which of the currently
registered entries should be generated. It is strongly recommended that this be left
at 0.
|