FTL Request Reply

FTL Request Reply is an asynchronous activity that is used to send a request to an FTL application endpoint and wait for a response.

General

The General tab has the following fields.

Field Literal Value/Module Property Description
Name No The name to be displayed as label of the activity in the application.
FTL Realm Server Connection Yes The shared resource containing information for connecting to TIBCO FTL Realm Server. See FTL Realm Server Connection for more details.
Endpoint Yes TIBCO FTL application endpoint which is an abstraction for the underlying transports on which the FTL Request Reply activity sends messages. The FTL Request Reply activity has two endpoints:
  • Request Endpoint - This is used to send the request message and is a required field.
  • Reply Endpoint - This is used to receive the reply message and is a optional field.
Note: These additional endpoints are provided to support cases where one might need separate request and reply paths on to different endpoints/transports. If request and reply paths don't need to be separate, then request endpoint will be used to send request and receive reply or reply endpoint should be configured to the same endpoint as request endpoint.

The endpoint can have more than one transport.

Click the Browse button to locate the endpoints defined on the TIBCO FTL Realm Server.

Request Format No Defines the set of fields in the message that is sent by the FTL Request Reply activity. The form of each FTL message (its field names and their value datatypes) is governed by a format. The supported formats are:
  • Custom: can be defined by using the Input Editor. The Input Editor is enabled only for the Custom format option.
  • Predefined: is already defined in the TIBCO FTL Realm Server for the FTL application. The Predefined format requires a format name and this can be obtained from the TIBCO FTL Realm Server using the Browse button.

Selecting the Custom field, enables the Input Editor.

Request Format Name Yes

The name of the Predefined or Custom format.

In addition, selecting the Predefined format enables the Browse button. Click the Browse button to obtain the predefined formats from the TIBCO FTL Realm Server.

Reply Format Yes Defines the set of fields in the message that is sent by the FTL Request Reply activity. The form of each FTL message (its field names and their value datatypes) is governed by a format. The supported formats are:
  • Custom: can be defined by using the Input Editor. The Input Editor is enabled only for the Custom format option.
  • Keyed Opaque: is a built-in format that contains a text key field and a binary (opaque) data field.
  • Opaque: is a built-in format that contains a binary (opaque) data field.
  • Predefined: is already defined in the TIBCO FTL Realm Server for the FTL application. The Predefined format requires a format name and this can be obtained from the TIBCO FTL Realm Server using the Browse button.
Reply Format Name Yes The name of the Predefined or Custom format.

This field is displayed when the Custom or Predefined format is selected.

In addition, selecting the Predefined format enables the Browse button. Click the Browse button to obtain the predefined formats from TIBCO FTL Realm Server.

Description

Provide a short description of the activity here.

Advanced

The Advanced tab has the following field.

Field Literal Value/Process Property/Module Property Description
Activity Timeout (msec) Yes It is the amount of time FTL Request Reply activity waits to get the reply from the FTL Subscriber.
Important: If the FTL Request Reply activity is configured to be Default Timeout, then the timeout value equates to "3" minutes by default. However this default value (3 minutes) can be modified to be a different value by setting the AppSpace config.ini property bw.engine.activity.async.waitTime.
Note: When the FTL Request Reply activity timesout, the in-line subprocess instance called by the FTL Request Reply activity can be cancelled before the subprocess instance completes. Hence, the business logic in the cancelled process instance may not be executed to its entirety.
Retry Duration Yes

This field specifies the retry duration for reconnecting to a persistent server.

The value is in seconds.

When the persistent server does not get accessed (because of network failure or quorum unavailability), retrying to connect to the server can be configured with this field. The value of this property determines the retry behavior. The supported values are:
  • 0: No retry. This call raises an exception. This is thedefault behavior.
  • 1: Synchronously retry the interaction until it succeeds. This call returns only upon success.
  • n (Any positive double value): Retry the interaction for n seconds. Return upon success or raise an exception after timeout.

Input Editor

The Input Editor gets enabled only when Custom format is chosen in the General tab. The schema must match the schema of the input for the activity shown on the Input tab.

Note: Input Schema does not support anyType element.

Output Editor

The Output Editor tab defines the schema to use for reply messages. This tab gets enabled only when you select the Custom format.

Input

The input for the activity depends on the Format you select in the General tab. If you select Custom format, the input is a data element defined in the Input Editor tab.

Output

Shows the output reply message. For example, if you select Predefined as a Reply Format, the output shows the Predefined message with the message metadata and reply message.

Fault

The Fault tab lists the possible exceptions thrown by this activity.

Fault Thrown When...
FTLRequestReplyActivityFault The FTL Request Reply activity fails due to a runtime error.
FTLCreateRequestMessageFault The FTL request message could not be created.
FTLSendRequestMessageFault The FTL request message could not be published.
FTLProcessReplyMessageFault The FTL reply message could not be processed.
ActivityTimedOutException The timeout is reached.