TIBCO Flogo® Enterprise

(1)

Activities, Triggers, and Connections

Version 2.13.0 May 2021

(2)

Contents 2

General Category Triggers, Activities, and Connections 6

Triggers 6

Timer Trigger 7

REST Trigger - ReceiveHTTPMessage 8

GraphQL Trigger 15

Receive Lambda Invocation 16

AWS API Gateway Lambda Trigger 18

S3 Bucket Event Lambda Trigger 21

gRPC Trigger 22

Activities 24

ConfigureHTTPResponse 24

Execute JavaScript 25

GRPC Invoke 28

InvokeLambdaFunction 29

InvokeRESTService 31

LogMessage 40

Mapper 41

ParseJSON 42

ReplyToHTTPMessage (Supported for backward compatibility only) 43

SendMail 44

SharedData 46

Sleep 48

Connections 50

HTTP Client Authorization Configuration 50

Apache Avro 53

Overview 53

(3)

Avro Serialize 53

Avro Deserialize 54

Apache Kafka 55

Overview 55

Configuring a Kafka Client Connection 55

Kafka Client Configuration Details 56

Connecting to TIBCO Cloud Messaging - Kafka 59

Kafka Consumer Trigger 59

Kafka Producer 63

Kafka Offset Commit 67

Apache Pulsar 68

Overview 68

Creating an Apache Pulsar Connection 68

Apache Pulsar Connection Details 69

Connecting to TIBCO Cloud Messaging - Apache Pulsar 71

Apache Pulsar Consumer Trigger 72

Apache Pulsar Producer Activity 75

Apache Pulsar Message Ack Activity 78

Microsoft SQL Server 79

Overview 79

Creating a Microsoft SQL Server Connection 79

Microsoft SQL Server Connection Details 79

SQLServer Query 82

SQLServer Insert 84

SQLServer Update 87

SQLServer Delete 89

Manually Configuring Metadata 91

MQTT 92

Overview 92

(4)

Creating the MQTT Connection 92

MQTT Connection Details 93

Rules for Application Property 94

MQTT Subscriber Trigger 94

MQTT Publish Activity 97

Oracle MySQL 100

Overview 100

Creating an Oracle MySQL Connection 100

Oracle MySQL Connection Details 101

MySQL Query 104

MySQL Insert 107

MySQL Update 110

MySQL Delete 112

Manually Configuring Metadata 113

PostgreSQL 115

Overview 115

Creating a PostgreSQL Connection 115

PostgreSQL Connection Details 116

PostgreSQL Query 119

PostgreSQL Insert 121

PostgreSQL Update 124

PostgreSQL Delete 126

Manually Configuring Metadata 128

TIBCO Cloud Messaging 129

Overview 129

Creating a TIBCO Cloud Messaging Connection 129

TIBCO Cloud Messaging Connection Details 130

MessageSubscriber Trigger 131

TCMMessagePublisher 135

(5)

TCMMessageAck 136

Websocket 138

Overview 138

Websocket Server Trigger 138

Websocket Subscriber Trigger 142

Websocket Client Activity 144

Websocket Write Data Activity 147

TIBCO Documentation and Support Services 149

Legal and Third-Party Notices 151

(6)

General Category Triggers, Activities, and Connections

The General category is available by default in all flows. It consists of activities, triggers, and connections that may be commonly used by any flow in the app. A trigger initiates the flow in which it appears. An activity is used to perform a task. A connection is used to connect an app to various services.

Triggers

In addition to the triggers available for general use, Flogo supports triggers that were originally created in Project Flogo. Such triggers are marked with an

OSS

tag on them. This allows for a seamless import of apps that were created in Project Flogo.

If you are creating an app in Flogo, it is preferable to use the general purpose triggers (the triggers that do not have an

OSS

tag on them) as they have richer functionality.

Refer to

https://github.com/project-flogo/contrib for details on the triggers that are

marked with an

OSS

tag.

Trigger configuration fields are grouped into Trigger Settings and Handler Settings. A single trigger can be associated with multiple handlers.

^l

Trigger Settings - these settings are common to the trigger across all flows that use that trigger. When Trigger Settings are changed, the change applies to all flows that are attached to the trigger. A warning message is displayed asking you to confirm the changes before they are committed.

^l

Handler Settings - these settings are applicable to a specific flow attached to the trigger. Hence, each flow can set its own values for the Handler Settings fields in the trigger. To do so, open the flow and click on the trigger to open its configuration dialog. Click the Settings tab and edit the fields in the Handler Settings section.

Note: You cannot create a flow branch from a trigger.

(7)

Note: You can create the trigger at the time of flow creation or create a blank flow to begin with and attach the flow to one or more triggers at a later time after the flow has been created. If you anticipate that you might need to attach the flow to multiple triggers, be sure to create a blank flow and attach it to the triggers as needed.

For triggers that have an output, the output from the trigger becomes the input to the flow. Likewise, the output from the flow becomes the reply from the trigger.

When using the Lambda, S3, or Gateway triggers, keep the following in mind:

^l

You can only have one trigger. The Lambda trigger supports only one handler per trigger, it can have only one flow attached to it. The S3 and Gateway triggers support multiple handlers (flows), so you can have multiple flows in the app that are

attached to the same S3 or Gateway trigger.

^l

An app that has one of these triggers cannot contain any other trigger.

^l

You can also have blank flows in the app, which can serve as subflows for the flows that are attached to the one of these triggers.

Timer Trigger

Use the Timer Trigger as a process starter when creating flows designed to be activated without external input. It is useful when you want your flows to run at certain time intervals. You can configure the Timer Trigger to activate the flow multiple times at a specified interval.

Field Description

Handler Settings

Repeating

True

: Select the

True

radio button to run the flow at periodic intervals.

False

: Select the

False

radio button if you want the flow to run only once.

If

Repeating

is set to

True

and a

Time Interval

and

Interval Unit

is specified, the flow is triggered at the exact same time as the first run. For example, if the flow was run at 1:00 pm on Monday and the

Interval Unit

is specified as week with the

Time Interval

as 2, the flow be run at 1:00 pm on every other Monday.

(8)

Field Description Time

Interval

An integer indicating the number of units specified in the

Interval Unit

field. For example, if you enter

1

as the Time Interval and select

Hour

in the

Interval Unit

drop down menu, the Timer trigger activates the flow every hour. If you enter

2

as the time interval and specify

Week

as the

Interval Unit

, the flow is run every other week.

Interval Unit

The unit of time to use with the

Time Interval

field to determine how often to run the flow. The units can be:

Second

,

Minute

,

Hour

,

Day

, and

Week

.

REST Trigger - ReceiveHTTPMessage

Use the ReceiveHTTPMessage REST trigger when creating flows that are going to be invoked by an external REST call. The ReceiveHTTPMessage trigger exposes your flow as an API, making it accessible by other apps running on either TIBCO Cloud™ or elsewhere.

This trigger must be configured to set up the fields for a request that the server receives from a REST client.

Note: If you make changes to the trigger such as add or delete path or query parameters, be sure to click Sync for the changes to be propagated to the flow input schema.

Trigger Settings

Trigger Settings

Port By default, the trigger listens on the port 9999. You can change this to use another port that is open.

Important: If the app has multiple triggers that require a port to be

specified, specify a unique port number for each trigger. Two triggers in the same app cannot run on the same port.

(9)

Field Description Configure

Using API Specs

While creating a REST trigger, you can configure it by uploading an API specification file. If the API specification changes, you can merge the changes into an existing app by uploading the specification file again.

To do this, click

True

and specify the following:

^l

API Spec

: Click

Browse

and then select the specification file to be used for configuring the trigger. Supported specifications are Swagger

Specification 2.0 and OpenAPI Specification 3.0.

Default: False

Secure

Connection

By default, it is set to

False

. If you set this field to

True

, you can create a secure endpoint by providing

Server Key

and

CA or Server Certificate

.

Server Key

- A PEM encoded private key file

CA or Server Certificate

- A PEM encoded CA or self-signed server certificate file

Handler Settings

Method The REST operation which the flow implements, for example GET, PUT, POST, or DELETE.

Request Type

This field appears only when

Method

is POST or PUT. Select one of the following types from the drop-down list:

^l application/json

^l application/x-www-form-urlencoded ^l multipart/form-data

Default:

application/json

Note: If you create a Flogo app using an API specification file having

Request Type

as application/x-www-form-urlencoded or

multipart/form-data, then you must click the

Sync

button to update the request parameters with the Flow Input.

Path The resource path for the operation. If you upload an API specification file, select

(10)

a path from the drop-down list.

By default, the path displayed here is the resource path you had entered when you created the flow. The

Path

field is editable if you have not uploaded an API specification file. For example, if you want to add a path parameter for a GET operation, you can do so by editing the resource path in the GET flow. If you edit the path in the Path field for a particular REST operation flow, the edited resource path is applicable only to the flow in which it was edited.

Two resource paths with same base path should not contain path parameters at the same location. For example, you cannot have the following paths in the same application:

^l /books/{ISBN}/Author/{releaseDate} and /books/

{ISBN}/Author/releaseDate is considered the same from a routing perspective.

In these two paths, since the ISBN value is dynamic, it causes a conflict during path resolution.

^l /books/{ISBN}/{releaseDate} and /books/{ISBN}/Author in the same application is not supported.

Although the two paths appear to be different, when a message comes in, the router mechanism cannot know which path to call (the one with parameter or the one without) since the actual value has been substituted for the parameter.

^l Resource path with two different path parameters at the same URL sub- section. For example, /0.6/api/account/{account}/orderhistory/

{orderhistory}/branch/{branch} and /0.6/api/account/

{AccountKey}/Price?ProductList={ProductList}

In these paths even though the paths differ after the base path

(/0.6/api/account/), there is a conflict when resolving the {account}

and {AccountKey} values.

^l Multiple REST resources with same base path and same number of path parameters. For example, /resource/{id} and /resource/{id1}

^l

/messages/{messageid}/comments/{commentid} and /messages/

{messageid}/likes/{likeid}

(11)

where the paths differ after {messageid}. Output

Validation

When set to

True

, the incoming data (body, headers, and query parameters) is validated against the configured JSON schema.

Default: False

Output Settings

Field Description Query

Parameters

Query parameters to be appended to the path. To add the query parameters, click the button and press

Enter

to save your changes.

^l

parameterName:

Name of the query parameter

^l

type:

The data type of the query parameter. Supported types are string, number, and boolean.

^l

repeating:

Set to

True

if more than one value is expected for the query parameter.

^l

required:

Set to

True

if query parameter is a required configuration. The trigger reports an error if no values are provided to the required query parameter.

Path

Parameters

Path parameters that are appended to the path.

Headers Header values for the trigger. To add the header parameters, click the button and press

Enter

^l

parameterName:

Name of the header parameter.

^l

type:

The data type of the header parameter. Supported types are string, number, and boolean.

^l

repeating:

Set to

True

if more than one value is expected for the HTTP header.

(12)

^l

required:

Set to

True

if header parameter is a required configuration. The trigger reports an error if no values are provided to the required header parameter.

Request Schema

Request schema for the trigger. Be sure to use straight quotes for element names and values in the schema.

Multipart Data

This field is displayed in place of the

Request Schema

field if you select multipart/form-data as the

Request Type

in the Trigger Settings. Click the

Add row

button to add the parameters.

^l

Name:

Name of the parameter.

^l

Type:

Supported types are string, object, and filecontent. ^l

Required:

Check the box if the parameter is a required configuration.

^l

Schema:

Enter the JSON schema in this field if the

Type

is object.

Map to Flow Inputs

This tab allows you to map the trigger output to flow input.

Reply Settings

Response Codes

Allows you to configure response codes.

Default: False

(See "Reply Data Schema" in this table.)

To specify a response code, select

True

and click the button. Enter the following details:

^l

Code

: Enter the response code.

^l

Type

: Select the type of response expected for the

Code

. Supported types are

String

and

Object

.

^l

Response Body

: If

Object

is selected as the

Type

, enter the JSON schema

(13)

in the

Response Body

column. For

String

, you need not enter anything in the

Response Body

column.

^l

Response Headers

: The header parameters for the reply in JSON data format.

^l

Actions

: The actions displayed change based on the type of the response code.

^o

Edit

,

Delete

: For an

Object

type of response, you can edit the details or cancel it.

^o

Save

,

Cancel

: For a

String

type of response, you can save or cancel the changes.

The response codes appear in the Map from Flow Outputs tab.

Note: The REST reply data type is by default set to data type any. To configure the reply to an explicit data type, see "Configuring the REST Reply" section in the TIBCO Flogo^® Enterprise User's Guide.

For multiple response codes, use the

ConfigureHTTPResponse

activity in the flow to map

Response Body

and

Response Headers

from the REST trigger with the

Input

in the activity. To configure

ConfigureHTTPResponse

activity, see ConfigureHTTPResponse.

The image shows the

Reply Settings

with multiple response codes.

(14)

Caution: If you modify the response code schema in the table, the

corresponding

ConfigureHTTPResponse

activities within that flow do not change appropriately. This happens specifically when removing fields from the

Reply Settings

tab. Redo the mappings for the

ConfigureHTTPResponse

activities.

Reply Data Schema

Note: This field appears only when

Configure Response Codes

is set to

False

.

The schema used for the reply data of the trigger. Be sure to use straight quotes for element names and values in the schema.

Map from Flow Outputs

Map the flow output to the trigger reply on this tab.

Note: To update these settings for a trigger configured from Swagger 2.0 or

OpenAPI 3.0 specification, make changes in the API specification file and upload

it in the Trigger Settings. Do not update the settings as manual updates are

removed.

(15)

GraphQL Trigger

The GraphQL Trigger lets the Flogo app act as the GraphQL server. To use this trigger, you simply upload your GraphQL schema and Flogo Enterprise automatically creates the flows corresponding to each query or mutation field in your schema.

Trigger Settings

Port The port on which the trigger listens to requests. By default, it is set to 7879. You can change this to use any other port that is open. This field can also be set using an application property.

Important: If the app has multiple triggers that require a port to be specified, make sure that the port number is unique for each trigger. Two triggers in the same app cannot run on the same port.

Path The HTTP resource path for the operation. By default, it is set to /graphql, but you can change it to any string that is meaningful to you. It is the single endpoint that GraphQL queries and mutations use to access data from the multiple resources on the server. This field can also be set using an application property.

GraphQL Schema File

The file that contains the GraphQL schema used to create the flow. The file has a .gql or .graphql extension.

Note: If you have made changes to the GraphQL schema file that you

uploaded when creating the flow or trigger, you must propagate the changes to the flow input and flow output. To do this, after you select the updated schema file in this field, click the

Sync

button on the top right corner.

Secure Connection

False

True

Server Key

and

CA or Server Certificate

.

Server Key

CA or Server Certificate

(16)

Handler Settings

GraphQL

Operation

The type of Graphql operation the flow should represent. You can select either

Query

or

Mutation

Resolver for

This field is populated based on the type of

GraphQL Operation

that you

selected. If you selected

Query

, the

Resolver For

lists the field names under the query type in the schema. If you select

Mutation

, the drop down menu lists the field names under the mutation type in the schema.

This tab allows you to map the trigger output to flow input. The tab contains an element,

arguments

, which contains a list of fields or objects that match the input arguments of the Resolver For field in the GraphQL schema.

Map the flow output to the trigger reply in this tab. The tab contains a child element,

data

, which contains either a simple type or an object that match the output type of the

Resolver For field in the GraphQL schema. If the output type of the field is an

interface

type, the data contains a single field of type

any

.

Receive Lambda Invocation

Use the Receive Lambda Invocation trigger for AWS to start your flow as a Lambda

function. The Receive Lambda Invocation trigger can be configured only in blank flows. It must not be used with flows that are created with another trigger.

Note: An app can contain only one Lambda trigger. An app that has a Lambda trigger cannot contain any other triggers including another Lambda trigger.

Also, as the Lambda trigger supports only one handler per trigger, it can have

only one flow attached to it. However, the apps that contain a Lambda trigger

can contain blank flows that can serve as subflows for the flow attached to the

Lambda trigger.

(17)

Field Description AWS

Connection Name

Name of the AWS connector connection you want to use for the flow.

Execution Role Name

(optional) ARN of the role to be used to execute the function on your behalf. The role must be assumable by Lambda and must have CloudWatch logs permission execution role.

Output Settings

Enter the payload schema for the request received on the Lambda function invocation on AWS.

This tab allows you to map the trigger output to flow input.

Function Information about the Lambda function Context Envelope information about this invocation Identity Identity for the invoking users

ClientApp Metadata about the calling app API

Gateway Request

Displays the elements in the payload schema that you entered in the

Output Settings

tab. The elements are displayed in a tree format.

Reply Settings

Enter a schema for the trigger reply in the Reply Data text box.

Map the flow output to the trigger reply in this tab.

(18)

AWS API Gateway Lambda Trigger

Use the AWS API Gateway Lambda trigger to start your flow as a Lambda function using an API Gateway.

Note: You can have only one Gateway trigger in an app. An app that has a Gateway trigger cannot contain any other triggers including another Gateway trigger. The Gateway trigger supports multiple handlers (flows), so you can have multiple flows in the app that are attached to the same Gateway trigger. You can also have blank flows in the app, which can serve as subflows for the flows that are attached to the Gateway trigger.

Connection Name

(Mandatory) Name of the AWS connection that you want to use for deploying the flow as a Lambda connection.

Execution Role Name

Permission of the Lambda function to execute. The role must be assumable by Lambda and must have CloudWatch logs permission execution role. A default role with the AWS predefined AWSLambdaBasicExecutionRole permission is created if you do not specify anything in this field.

By default, Cloud watching is enabled.

API Deploy Stage

Name of the API Gateway deployment stage.

Note: Spaces or special characters are not allowed.

You can use this field to create different deployment stages such as Testing, Production, and so on. You can also create this stage on the AWS console after deployment.

Method The operation which the flow implements. For example - GET, PUT, POST, or DELETE. You can select only one method at a time.

Path The resource path for the operation. By default, the path displayed here is the

(19)

resource path you had entered when you created the flow.

Output Validation

When set to

True

, the incoming data (body, headers, and query parameters) is validated against the configured JSON schema.

Default: False

Output Settings

Parameters

Query parameters to be appended to the path. To add the query parameters, click the ( ) button and press

Enter

parameterName:

Name of the query parameter

type:

The data type of the query parameter. Supported types are string, number, or boolean.

repeating:

Set to

True

if more than one value is expected for the query parameter.

required:

Set to

True

if query parameter is a required configuration. The trigger reports an error if no value(s) are provided to the required query parameter.

Note: By default, query parameters are not mandatory. When you create an API Gateway, you must explicitly navigate to the API Gateway console and change the settings.

Path

Parameters

Path parameters are appended to the resource path. Add the path parameters by using '{ }' in the

Path

field in the trigger configuration as follows:

/path/{pathparam1}/{pathparam2}

Path parameters are of the string data type only.

Headers Header values for the trigger. To add the header parameters, click the button and press

Enter

(20)

parameterName:

type:

The data type of the header parameter. Supported types are string, number, or boolean.

repeating:

Set to

True

if more than one value is expected for the HTTP header.

required:

Set to

True

if header parameter is a required configuration. The trigger reports an error if no value(s) are provided to the required header parameter.

Note: By default, header parameters are not mandatory. When you create an API Gateway, you must explicitly navigate to the API Gateway console and change the settings.

This tab allows you to map the trigger output to flow input.

ClientApp Metadata about the calling app API Gateway

Request

API Gateway default schema which can be mapped with the schema of AWS API Gateway Lambda trigger

Reply Settings

Field Description Reply Data

Schema

The schema used for the reply data of the trigger. Be sure to use straight quotes for element names and values in the schema.

(21)

Map the flow output to the trigger reply in this tab.

code HTTP code body Body of the reply

S3 Bucket Event Lambda Trigger

Use the S3 Bucket Event Lambda trigger to trigger a Lambda function when a supported event occurs on the associated S3 bucket.

Note: Creating a new event or updating an existing event in the S3 Bucket Event Lambda trigger and re-pushing the app deletes existing Events on AWS S3.

Note: You can have only one S3 trigger in an app. An app that has an S3 trigger cannot contain any other triggers including another S3 trigger. The S3 trigger supports multiple handlers (flows), so you can have multiple flows in the app that are attached to the same S3 trigger. You can also have blank flows in the app which can serve as subflows for the flows that are attached to the S3 trigger.

Connection Name

(Mandatory) Name of the AWS connection that you want to use for deploying the flow.

Execution Role Name

Permission of the Lambda function to execute. The role must be assumable by Lambda and must have CloudWatch logs permission execution role.

By default, Cloud watching is enabled.

(22)

Bucket Name of the S3 bucket with which the trigger is to be associated. This bucket must be an existing one.

Event name Name of the S3 bucket event notification.

Event list A list of operations to be performed on the S3 bucket. Supported operations are POST, PUT, COPY, and DELETE.

Object prefix filter

(Optional) The prefix to be used to filter the S3 bucket.

For example, images/

Object suffix filter

(Optional) The suffix to be used to filter the S3 bucket.

For example, .jpg

Map the flow output to the trigger reply in this tab. The tab displays the following fields.

ClientApp Metadata about the calling app

S3Event Default schema of S3 bucket event trigger. It can be mapped with the flow input to pass the key values to the flow.

gRPC Trigger

The gRPC trigger acts as a server to gRPC clients.

(23)

Trigger Settings

Port The port on which the trigger listens to requests. You can use any port that is open. This field can also be set using an application property.

Proto File A file with .proto extension that contains the methods and service(s) definition which Flogo Enterprise uses to create the flows. Currently, importing a .proto file into another .proto file is not supported.

Note:

^l The gRPC trigger and gRPC activity does not support options in the .proto file. If your .proto file contains any options, be sure to remove the options in .proto file before using it.

^l You must not use the same gRPC .proto file for a gRPC trigger and gRPC activities in the same app. The package names for the gRPC trigger and gRPC activities must be unique.

Secure Connection

False

True

Server Key

and

CA or Server Certificate

.

Server Key

CA or Server Certificate

Handler Settings

Service Name

Name of the service defined in the .proto file. You must create one gRPC trigger for any specific .proto file. Any subsequent gRPC triggers using the same

.proto file can select the service and method they need from the dropdowns.

Method Name of RPC method in the .proto file. Each method in the .proto file is represented by a separate flow and attached to the same gRPC trigger.

This tab allows you to map the trigger output to flow input. The tab displays fields from

your selected method.

(24)

Map the flow output to the trigger reply in this tab.

Activities

In addition to the activities available for general use, Flogo Enterprise supports activities that were originally created in Project Flogo. Such activities are marked with an

OSS

tag on them. This allows for a seamless import of apps that were created in Project Flogo. The Project Flogo activities are placed under the Default category.

If you are creating an app in Flogo Enterprise, it is preferable to use the general purpose activities (the activities that do not have an

OSS

tag on them), as they have richer

functionality.

Refer to

https://github.com/TIBCOSoftware/flogo-contrib for details on the activities that

are marked with an

OSS

tag.

The available activities are placed under the following categories:

^l

Default

^l

General

You can create a flow branch from any activity except the Return activity.

ConfigureHTTPResponse

This activity is used to configure HTTP response codes that you want to use in your REST reply.

Settings

Field Description Trigger

Name

The list of triggers to which this flow is attached. This field is displayed only when the flow it attached to multiple REST triggers. Select a trigger in which the code you want to use is configured.

Code List of response codes that you have configured in the selected trigger. Select a response code you want to use.

(25)

Input

Displays the schema for the code that you selected in the Settings tab. Map the elements in the schema in the mapper or manually enter the values that you want to send as a response.

Note: For multiple response codes in the

ReceiveHTTPMessage REST trigger,

map the Response Body and Response Headers from the trigger with the Input in this activity. The image shows the Input with headers and body mapped from the REST trigger response codes.

Output

Displays the schema for the code in a read-only tree format.

Loop

Refer to the section on "Using the Loop Feature in an Activity" in the TIBCO Flogo

^® Enterprise User's Guide for information on the

Loop tab.

Execute JavaScript

This activity executes a JavaScript code using the specified input parameters and returns

the result in the output.

(26)

Note: This activity supports only ECMAScript 5-compatible functions. For more information about these functions, see https://www.w3schools.com/js/js_

es5.asp.

You may see some code suggestions in the editor that are not ECMAScript 5 compatible. We recommend that you do not implement the suggestions. If you implement them, the activity may return some errors.

You can use this activity to easily write complex logic in JavaScript which may not be straightforward to achieve using the Flogo Enterprise mapper. For example, you can easily filter arrays based on some conditions or looping through arrays using

forEach

and other useful JavaScript functions.

Settings

Field Description Javascript

Code

Specify the JavaScript code to be executed in the following format:

var result, parameters

Where:

^l The result variable must be defined for the output of the JavaScript.

^l The parameters variable must be defined for the input of the JavaScript.

Set the input parameters on the

Input Settings

tab. Set the output parameters on the

Output Settings

tab.

Input Settings

Script Input Parameters

Configure a schema for one or more input parameters to the JavaScript.

The elements of this schema are available for mapping on the

Input

tab.

Use app-level schema:

Click this button and select a schema that you might have defined earlier.

(27)

Change:

To change the schema, click

Change

.

Syntax to access the input parameter value defined in the Javascript code:

parameters.<parameter_name>

For example, if you have defined the input parameter as foo in the JavaScript code, use the following syntax to access the value:

parameters.foo

Input

The Input tab displays the schema that you entered in the Input Settings tab in a tree format. Map the elements in the schema using the mapper or manually enter the value for the element in the mapper.

Output Settings

Script Output Configure a schema for one or more output parameters of the JavaScript.

Use app-level schema:

Click this button and select a schema that you might have defined earlier.

Change:

To change the schema, click

Change

.

Syntax for setting the value of the output parameter in the Javascript code:

result.<parameter_name>

Example:

result.foo = bar

(28)

Output

The Output tab displays the output parameters from the schema you entered in the Output Settings tab. The output parameters are displayed in the

result

object in a tree format.

error Flag indicating whether an error occurred while executing the JavaScript.

errorMessage The error message.

result The output of the JavaScript code, indicating a successful execution of the JavaScript.

GRPC Invoke

The gRPC Invoke activity is an implementation of a gRPC client. Use this activity to make outbound gRPC calls.

Settings

Host URL URL used to connect to the gRPC server. The name or IP address of the host on which your .proto file resides. Be sure to append the port number on which the service is running.

Secure Connection

False

True

Server Key

and

CA or Server Certificate

.

Server Key

CA or Server Certificate

- A PEM encoded CA or self-signed server certificate file Proto File A file with .proto extension that contains the methods and service(s) definition

which Flogo Enterprise uses to create the flows. Each flow corresponds to one method in the .proto file. Currently, importing a .proto file into another

(29)

.proto file is not supported.

Note:

^l The gRPC trigger and gRPC activity does not support options in the .proto file. If your .proto file contains any options, be sure to remove the options in .proto file before using it.

^l You must not use the same gRPC .proto file for a gRPC trigger and gRPC activities in the same app. The package names for the gRPC trigger and gRPC activities must be unique.

Service Name

Name of the service you want to invoke. The service is defined in the .proto file that you have selected.

Method Name of RPC method in the selected .proto file. Each method in the .proto file is a gRPC request which is represented by a separate flow and attached to the same gRPC trigger.

Input

Field Description Activity

Input

The

Input

tab lists the parameters for the method that you chose in the

Settings

tab so that you can either enter or map their values in the mapper.

Output

The Output tab displays a read-only schema of the activity output (the response that is configured for the selected method).

Iterator

For details on using the iterator, see the "Using the Iterator in an Activity" section in the

TIBCO Flogo^® Enterprise User's Guide.

InvokeLambdaFunction

Use this activity to invoke a specific Lambda function.

(30)

Settings

Connection Name

Select an AWS connection.

ARN (Optional)

Amazon Resource Name.

Note:

^l You can also specify the ARN in the

Input

tab. If you specify the ARN in both the tabs, the ARN in the

Input

tab is used.

^l You must specify the ARN in at least one tab; otherwise the activity returns an error at runtime.

Input Settings

Field Description Payload

Schema

Enter a JSON request schema for your payload that is used to invoke the Lambda function.

Input

The payload schema that you entered in the Input Settings tab is displayed in a tree format in the Input tab. Map the elements in the schema using the mapper or

alternatively, enter values for the element by manually typing the value in the mapper.

LambdaARN Amazon Resource Name.

(31)

Note:

^l You can also specify the ARN in the

Settings

tab. If you specify the ARN in both the tabs, the ARN in the

Input

tab is used.

^l You must specify the ARN in at least one tab; otherwise the activity returns an error at runtime.

Output Settings

Field Description Result

Schema

The schema for the result that is expected from the Lambda function invoke request

Output

The Output tab displays the result schema you entered in the Output Settings tab in a tree format.

InvokeRESTService

This activity is used to make a request to a REST service; it also accepts the reply returned by the service.

Settings

API Spec (Optional) Click

Browse

and browse to the file location on the machine.

Select a JSON file.

Supported specifications are Swagger Specification 2.0 and OpenAPI Specification 3.0.

(32)

Field Description Resource Path

Note: This field is only displayed if you upload a JSON file in the

API Spec

field.

All resource paths available in the JSON file (that is, the Swagger 2.0 or OpenAPI 3.0 specification file you uploaded) are listed in the drop-down.

Depending on the resource path you select, the supported operations are listed in the

Method

field.

Enable

Authentication

Select

True

if you want to enable authentication and authorization for your applications using the HTTP Client Authorization Configuration connection.

Default: False

Authentication

Connection Note: This field is displayed only if the

Enable Authentication

field is set to

True

.

Select a connection that you have set up from the drop-down list.

For information on setting up a connection, refer to HTTP Client Authorization Configuration.

Method Select an operation for the request. For example: GET, POST, PUT, DELETE, or PATCH.

URL An absolute path to the REST service that you want to invoke. For example:

http://acme.com or https://acme.com. If you enter an absolute path beginning with https://, the

Use certificate for verification

section appears.

If your connection requires an SSL certificate, select

True

. Otherwise, select

False

. To add a certificate, under

Server Certificate

, click

Browse

and browse to the certificate location on the machine.

Note: If you upload an OpenAPI 3.0 JSON specification file in the

API

Spec

field, the

URL

is a drop down menu. This lists the server URLs mentioned in the JSON file. Select a server URL from the list.

(33)

Tip: To dynamically override the path provided in the URL, you can enter the URL as:

http://<host-url>:port/{path}

Here, {path} is the parameter which can be modified. You can map this parameter in the

Input

section and assign values to it from the previous activities or the app properties.

Timeout Specify the timeout period (in milliseconds) for invoking a service. If a timeout value is specified, the activity waits for the specified time. If a response is not received by the specified time, the request expires with an error.

Default:

0 milliseconds (that is, there is no timeout for invoking a service) Request Type Note: This field is displayed only for the POST, PUT, and PATCH methods.

The Request content type of the REST service. The following content-type are supported:

^l text/plain

^l application/json

^l application/x-www-form-urlencoded ^l multipart/form-data

Note: If you select application/x-www-form-urlencoded, the default schema is set in the

Request Schema

field of the

Input Settings

tab.

You can edit the default schema or specify your own schema. If you specify your own schema, it must be a name-value string pair.

Proxy Specify the URL to the HTTP proxy server. If a proxy URL is specified, the request to the REST service (specified in the

URL

field) is routed via this proxy URL.

Note: A secure connection to the proxy server is not supported.

Default:

Proxy URL is disabled.

(34)

Input Settings

Note: If you upload a JSON file in the API Spec field, the fields in Input Settings are automatically populated according to the Resource Path you select.

Params

Query parameters to be appended to the path. To add the query parameters, click the button and press

Enter

^l

parameterName:

Name of the query parameter.

^l

type:

The data type of the query parameter. Supported types are string, number, or boolean.

^l

required:

Set to

True

if query parameter is a required configuration. The trigger reports an error if no values are provided to the required query parameter.

Path Params

Path parameters that are appended to the path. This is a non-editable field.

^l

parameterName:

Name of the path parameter. This is the parameter specified in between { } in the

Resource Path

field or the

URL

field in

Settings.

^l

type:

The data type of the path parameter. Supported type is string. Request

Headers

Header values for the InvokeRESTService activity. To add the header parameters, click the button and press

Enter

^l

parameterName:

^l

type:

The data type of the header parameter. Supported types are string, number, and boolean.

^l

required:

Set to

True

if header parameter is a required configuration. The trigger reports an error if no values are provided to the required header parameter.

(35)

Field Description Request

Schema

Enter a request schema here. This field is visible only if you selected the POST, PUT, or PATCH method in the

Settings

tab.

Note: If you selected application/x-www-form-urlencoded as the

Request Type

in the

Settings

tab, the default schema is set here. You can edit the default schema or specify your own schema. If you specify your own schema, it must be a name-value string pair.

Multipart Data

This field is displayed in place of the

Request Schema

field if you select

multipart/form-data as the

Request Type

in the

Settings

tab. Click the

Add row

button to add the parameters.

^l

Name:

Name of the parameter.

^l

Type:

Supported types are string, object, and filecontent. For file types such as images and PDF files, convert your file to Base64 format and pass the encoded value as the Input.

^l

Required:

Check the box if the parameter is a required configuration.

^l

Schema:

Enter the JSON schema in this field if the

Type

is object.

Input

Note: If you upload a JSON file in the API Spec field, the Input fields are automatically populated according to the Resource Path and Method you select.

host Specify the value which must override the hostname:port value specified in the URL at runtime with the value specified in this configuration. Enter a value in the form hostname[:port] where [:port] is optional.

queryParams Provide a value to the query parameters configured on the

Input Settings

section. This field is visible only if you selected the POST or PUT method in the

(36)

Settings

tab.

pathParams Provide a value to path parameters defined as part of URL in the

Settings

tab.

This field is visible only if you selected the POST or PUT method in the

Settings

tab.

headers Header values for the activity. These values can be manually entered or mapped to the output of the trigger or any preceding activity.

body Request Schema values for the activity. These values can be manually entered or mapped to the output of the trigger or any preceding activity. This field is visible only if you selected the POST or PUT method in the

Settings

tab.

Output Settings

Note: If you upload a JSON file in the API Spec field, the fields in Output Settings are automatically populated according to the Resource Path you select.

Response Codes

Allows you to configure response codes.

Default:

False (See "Response Schema" and "Response Type" in this table.) To specify a response code, select

True

and click the button. Enter the following details:

^l

Code

: Enter a specific response code or configure a single schema for a category of response codes. For example, if all the status codes are similar (such as 501, 502, 503, and so on), you can define a single schema (as 5xx) for them. Defining a single schema saves you time and effort as you do not need to configure each status code separately in the activity.

(37)

Note: If the status code is provided as a range (5xx in the above example) and also an absolute format (501 in the above example), the status code in the absolute format is given priority. In the above example, status code 501 is given priority over 5xx at runtime.

^l

Type

: Select the type of response expected for the

Code

. Supported types are

String

and

Object

.

^l

Response Body

: If

Object

is selected as the

Type

, enter the JSON schema in the

Response Body

column. For

String

, you need not enter anything in the

Response Body

column.

^l

Response Headers

: Specify the response header corresponding to the response code.

^l

Actions

: The actions displayed change based on the type of the response code.

^o

Edit

,

Delete

: For an

Object

type of response, you can edit the details or cancel it.

^o

Save

,

Cancel

: For a

String

type of response, you can save or cancel the changes.

The response codes appear in the Output tab.

Response

Schema Note: This field is displayed only when

Configure Response Codes

is set to

False

.

The schema for the reply that the server sends.

Response

Type Note: This field is displayed only when

Configure Response Codes

is set to

False

.

The content type of the REST service. The following content-types are supported:

^l application/json ^l application/xml ^l text/plain

(38)

^l other

Default:

application/json

Note: JSON to XML conversion is not supported by the REST activity. Any service that requires data in XML format cannot be invoked after providing data in the JSON format using REST activity.

Output

Format Note: This field appears only when the

Response Type

is set as application/xml.

The format of the request content for the application/xml response type. The following formats are supported:

^l JSON Object ^l XML String Response

Schema

Sample JSON schema for the response that the REST service returns.

The JSON schema in this field is editable for the following settings only:

^l When the

Response Type

is set as application/json

^l When the

Response Type

is set as application/xml and the

Output Format

is set as JSON Object

Response Headers

The header parameters for the reply.

Tip: If you want to fetch a cookie coming with a response, add a new row with Set-Cookie as the parameter. You can also map this parameter to subsequent activities in the flow.

Output

The Output tab displays the headers and response body configured for both the request

and the response in a tree format.

(39)

Loop

Refer to the section on "Using the Loop Feature in an Activity" in the TIBCO Flogo®

Enterprise User's Guide for information on the Loop tab.

Retry on Error

This tab allows you to set the number of times the flow should try to execute the activity if it encounters a retriable error (such as waiting for a server to start, intermittent

connection failures, or connection timeout) during the activity execution.

Map the elements in the schema using the mapper or alternatively, enter values for the element by manually typing the value in the mapper. See the section on "Using the Mapper" in TIBCO Flogo® Enterprise User's Guide for details on how to map elements.

Count The number of times the flow should attempt to execute the activity.

Interval The time (in milliseconds) to wait in between each attempt to execute the activity.

Note: To update these settings for an activity configured from Swagger 2.0 or OpenAPI 3.0 specification, make changes in the API specification file and upload it in Settings. Do not update the activity settings as manual updates are

removed.

Using SSL

If you choose to set up SSL authentication for the InvokeRESTService activity, you must have a self-signed server certificate that you must upload when setting up the activity.

Note: Use Self-signed PEM certificate for secure connection.

To set up SSL authentication:

Before you begin

You must have the self-signed server certificate handy on your machine.

(40)

Procedure

1. On the flow page, click the Invoke REST Service tile to open its properties.

2. In the Settings tab, under Use certificate for verification, select the True radio button.

This exposes the Browse button. The SSL verification is turned off when Use certificate for verification is set to False.

3. Use the Browse button to navigate to the location of the server certificate.

Once the server certificate is uploaded successfully, the connection uses the certificate to authenticate.

LogMessage

LogMessage is an activity that writes a message to the log. For each app, there is a log file.

You can view the logs in the Log tab.

Settings

The Settings tab has the following fields.

Log Level Select one of the following log levels:

^l

Info

: logs informational messages highlighting the application progress.

^l

Warning

: is the warning message of an unexpected error when running the flow.

^l

Error

: logs error conditions and messages.

^l

Debug

: can be used for debug-level messages.

Add Flow Details

Appends Flow Instance ID, Flow Name and Activity Name to the log message.

By default, this field is set to

False

.

Input

Provide the following input for this activity.

(41)

Input Item Description

message The message to be displayed in the log.

Loop

Refer to the section on "Using the Loop Feature in an Activity" in the TIBCO Cloud™

Integration - Flogo^® User's Guide for information on the

Loop tab.

Mapper

Use this activity to define a schema to get the desired data. This activity is particularly useful to define a schema for an object of type

any

. In the flow, you place the Mapper activity preceding an activity whose input requires an object of data type

any

. This allows you to map the object of type

any

to the output from the Mapper activity. An advantage of using this activity is that you can construct the data for the

any

data type within the flow instead of fetching it from outside.

Input Settings

Field Description Input

Schema

Enter the JSON schema that is used as the input for this activity. The elements of this schema are available for mapping in the

Input

tab and are mappable to the output from any preceding activity, trigger, or the flow input.

The Mapper activity outputs the elements from this schema, so they are also displayed in the

Output

tab in a tree format. This makes them available for mapping in the following activities.

Input

The Input tab displays the schema you entered in the Input Settings tab in a tree format.

You can map these elements to the output from any preceding activity, trigger, or the flow input.

Output

The Output tab displays the elements from the schema you entered in the Input Settings

tab.

(42)

Loop

Refer to the section on "Using the Loop Feature in an Activity" in the TIBCO Flogo

^® Enterprise User's Guide for information on the

Loop tab.

ParseJSON

This activity takes a stringified JSON data as input and converts it into a JSON object, which can then be accessed by the downstream activities that follow. You provide the input to the activity either by entering the stringified JSON data manually in the Input tab or saving it in a file and entering the file path in the Input tab. The activity supports output validation if you opt to validate the input JSON data against the output schema that you configure in the Output Settings tab.

Settings

Field Description Output

Validation

True

: Select

True

to validate that the JSON data in your input string matches the schema that you configure in the

Output Settings

tab of the activity.

False

: Select

False

if you do not want to validate the JSON data in your input string against the schema you configured.

This field can be configured with an application property.

Input

jsonString The string containing the JSON data that you want to parse. This activity creates a JSON object with the parsed JSON data. Enter the string manually or map it to an element from the output of the trigger, flow input, or one of the preceding activities.