Secondary Rendezvous Request to an Inbox, Tertiary FTL Reply
A Rendezvous reply to an inbox could itself be a secondary request in a longer chain of point-to-point messages. The adapter detects this situation because the secondary message meets all of these criteria.
- The adapter receives the secondary message at an adapter inbox, so the message must be a Rendezvous reply to an FTL request.
- The reply subject of the secondary Rendezvous message contains a Rendezvous inbox name, so the sender must be awaiting a tertiary reply.
The adapter repurposes the reply field from the primary request so an FTL program can send a tertiary reply to the secondary Rendezvous request. The reply field is an FTL field name, specified as the value of the of the configuration tag, which is the same tag that governed translation of the primary FTL request message.
- The adapter gets the reply subject, namely, the Rendezvous inbox name where the requestor awaits a reply.
- The adapter maps that Rendezvous inbox to an FTL inbox within the adapter, called the reply inbox.
- In the FTL translation of the secondary request message, the adapter stores the reply inbox in the reply field.
- Later, when an FTL program sends its tertiary reply to the reply inbox, the adapter receives it, translates it to a Rendezvous message, and forwards it to the reply subject. That reply subject is the Rendezvous inbox where the secondary requestor awaits the tertiary reply.
Because you have already configured the adapter to translate the primary request, you do not need any additional configuration to forward the secondary request, nor to forward the tertiary reply. (See Primary FTL Request Secondary Rendezvous Reply to an Inbox.)
Nonetheless, if the format of the tertiary reply differs from the format of the primary request, you must configure a separate tag to translate that format. This case has the same form as the configuration for the primary request.