Reroutes

In the engine, a message is taken from the pre-xlate queue and routed to translation details using a TrxID. The details translate the message and send it on to the destination protocol thread.

Chains and branched chains only modify how and what the details do after routing; they do not permit a dynamic route after their translations.

Reroute adds this ability to specify another TrxID route after some translations of a message have taken place.

Routing happens when a message is taken from the pre-xlate queue. A reroute specifies that the output of a translation is placed in the front of the pre-xlate queue.

The action is the same as if a new message had come from the source thread and "went to the head of the processing line."

Optionally, you can also state a TrxID to be used when the rerouted message undergoes routing.

No rerouted message are routed to the static route TrxID.

Unlike single details, chains, and branched chains, reroutes are user-controlled using the post-xlate TPS procedure. There are no controls in the IDE for setting up the reroute.

Set the reroute in a TPS procedure or in the translation. Usually, if TPS is used, then it is expected that you use the post-xlate TPS to avoid errors.

Each message is checked to see if the user has requested a reroute after the translation of a detail has finished. If selected, then the message or a copy of the message is placed in the pre-xlate queue. Then, it undergoes routing in the normal manner.

If the recovery database is specified, then the message is placed in the database as if it were a new message from the source thread.

Generated routes can never use chains or branched chains but they may use the reroute feature.

Previously, a translation error in any detail would cause all translated messages under the active TrxID to be deleted.

This action is unchanged by the addition of chains, branched chains, or message reroutes. This also applies to reroutes that happen between the links of chains. They are placed in the partial queue and rerouted after all requested translations have been finished.

If the recovery database is enabled and there is an engine panic, then rerouted messages can be found in the database. This database is marked for the partial queue of the xlate thread or sub-thread.

These messages might have their reroute key as REROUTED, depending on how far processing has progressed at the time of the panic.

On the recovery during engine restart, all partially rerouted messages are processed as if the panic had not happened.

Rerouted messages that are in the database for the pre-xlate queue (state 5) have the reroute key REROUTED. They are recovered as if they were new messages from the source thread.

Reroutes happen at the end of each translation detail, after the post xlate TPS.

This permits a chain to produce several messages and a message to the destination protocol thread.

For example, a chain is "A" to "B" to "C" to "destination." Rerouting between "A" and "B" and between "B" and "C" results in two messages that are placed at the head of the pre-xlate queue (stage 5). The output of the "C" translation goes to the destination.

Both forms of setting reroute on a message require a key value. This value is used as the TrxID for routing of the message as it leaves the pre-xlate queue.

  • This value can be a single TrxID or a Tcl list of TrxIDs.
  • If the message is to undergo the normal TrxID determination set up for the source thread, then use the special value NULL_REROUTE_TRXID as the key value.
  • This TrxID should never be specified for normal routes for the source thread.
  • When this value is not used, the message is routed using the key’s value. It does not use the normal TrxID determination processing.
  • Using the key value for the TrxID improves performance by removing the overhead of its determination during routing.

A rerouted message is not processed by any static route specified for the message’s source thread. To have a rerouted message routed by the static routes, use the normal static route TrxID, _HCI_static_route_ as the reroute key’s value.

When the number of xlate sub-threads for the process is nonzero, rerouted messages are processed according to the threaded xlate setup.

If the recovery database is in use and a recovery happens, then all actions are the same as normal processing.

That is, the reroute keys are saved as part of the metadata in the recovery database.

If a TPS procedure is used to set reroute on a message, then use the disposition of the same form as the other available dispositions. For example, KILL or CONTINUE. Similar to the existing dispositions, the reroute takes a message list, and each message must have a transaction ID.

Disposition form

The general form of the existing dispositions for more than one message is:

lappend displist "CONTINUE {$mh1 $mh2}"

Brackets are used when there is more than one message. The reroute follows this general form but requires a more complex list structure as follows.

To reroute one message with a given TrxID:

lappend dispList "REROUTE {{$mh trxid_A}}"

To reroute two messages each with their own TrxID:

lappend dispList "REROUTE {{$mh1 trxid_A} {$mh2 trxid_B}}"

Double brackets are used at the start of the message list.

As indicated, these are used even when the disposition is being set on a single message.

The TrxID cannot be defaulted.

Messages that are given the reroute disposition are not continued past the translation detail where it is set. To reroute a message and continue the message, you must make a copy of the message and set the correct dispositions.

Reroutes within the translation

Messages can also be rerouted during the translation using the SEND action. Because this is accomplished without adding a new action to the translations, it is controlled by a uniquely named local variable.

This example shows the form doing reroutes within the translation:

---- diddle fields ----
COMMENT Do reroute with trxid
=REROUTE trxid_A COPY @MSG_METADATA_REROUTE
SEND
---- diddle fields ----
COMMNET Do normal send operation
SEND
---- diddle fields ----
COMMENT Do reroute with two trxids
=REROUTE trxid_B trxid_C COPY @MSG_METADATA_REROUTE
SEND
--- diddle fields ----
COMMENT exit with a reroute using a trixid
=REROUTE trxid_D COPY @MSG_METADATA_REROUTE
--- diddle fields ----
COMMENT message exits translation in normal manner

The variable is reset when the SEND that is a reroute is completed.

In general, set the variable next to the SEND so that it is clear that it is not a normal SEND.

At least one TrxID should follow the word REROUTE in the string value of the variable MSG_METADATA_REROUTE.

As in the TPS form, if a message is to undergo normal routing then the TrxID should be set to the value NULL_REROUTE_TRXID.

Caution: 
Reroutes can form a closed loop. The engine cannot detect this condition.