Flogo Use-Case - REST API Integration

Preface

TIBCO Integration consists of a broad range of capabilities served by several products. Namely, TIBCO BusinessWorks 5, TIBCO BusinessWorks 6/CE/X and TIBCO Flogo. Each of these products by itself can handle a broad range of use-cases. It should not be a surprise that each use-cases could also be implemented in multiple of these products. However, there are reasons why these products are in the stack as each do optimally serve certain use-cases better than the other. We should understand when to use which. In this series of articles, we will deep dive into some of the best use-cases best suited for TIBCO Flogo. Some of the use-cases includes Web API-based Integration, Messaging/Event-based Integration, Data-as-a-Service Architecture, Simple Event Processing, Stream Event Processing, Standard Protocol-based IoT Integration, Edge Processing, API Ecosystem for Mobile/Web, and Mobile/Web Event-driven Integration.

REST API Integration

The focus of this article is on Web API-based integration.There are many different types of API whether it is using different protocols or different messaging types. In the context of Web API-based, the most popular these days are REST based services.

Flogo is extremely well suited for these REST based services for several reasons. 

• REST based services typically use JSON as the message type. Flogo native message type is JSON thereby it comes with a lot of capabilities to manage the data in this format.
• Flogo is extremely lightweight which falls very much inline with one of REST based services benefits.
• Flogo provides the activities needed to implement logic in REST based services as well as various connectors to back end systems. 

To illustrate the implementation of a REST based services in Flogo, we take a use-case of a retail company providing a REST service to manage customers. This service provides different REST methods for managing the customers as described in details below together with implementation notes. 

For the persistent store, we will mimic a database in the EntityDBOp_subflow using the SharedData capability of Flogo so that we do not have any external dependencies for this application to run and thereby focusing on the implementation of the REST based portion. The detail of the EntityDBOp_subflow is outside the scope of this article. Do note that EntityDBOp_subflow provides a simplistic, non-thread-safe behavior of a database and should not be used for production level implementation.

Additionally, we have set the environment variable FLOGO_EXPOSE_SWAGGER_EP to true so that we can use the swagger specification in the swagger ui for testing.

Get Customers

This operation gets a list of customers. It is implemented in the flow Get_Customers_flow. As you can see, the implementation of the flow is relatively simple. It uses a ReceiveHTTPMessage trigger. In this trigger, the port is configured to 9999 with the method set to GET and path set to /customer. Do note that although the best practice is to use App Properties for properties that can change during deployment, we have used the literal value in this application to keep things simple and so that we can see the value configured for it without needing additional screenshots.

Given that Get Customers does not have additional input parameters needed, our Output Settings has nothing configured. The mapping from Trigger to flow input is just the regular HTTP information.

We configure the reply to return an array of customers.

This array of customers is mapped from the flow output. In mapping this, we first determine if the array of customers is defined.

Only if the array of customers exists. We use iterate on to map it. If we do not check for the existence of the array of customers, we run the risk of iterating on a null element hence a potential for exception.

For this method (and subsequent methods), it is implemented simply with a LogStart, followed by a database operation (DBSelect in this case), followed by a LogEnd and a Return to the HTTP request. The Return activity is what maps the values into the flow output which in turn is mapped to the Trigger Outputs.

One other thing to note is that if everything is successful, we set the return code to be 200.

However, if we do encounter an error which is handled in the ErrorHandler path (as oppose to the Main Flow path), we set the return code to 500.

Post Customer

This operation creates a customer. The method for this is set to POST with the path /customer. The rest of the implementation is similar to the previous method except for a few differences which are pointed out below. 

It is important to note that when we implement this second and subsequent methods for the customer entity, we should not use a new ReceiveHTTPMessage trigger. This is because we are really using the same endpoint but with a different method and path. To achieve this, we reuse the trigger that was used in the first flow. This trigger will appear under the heading “Add Existing Triggers”. 

When this flow receives a request, it will execute DBInsert to insert a new customer into the database.

A successful execution of this will result in the return of the code 200 and a boolean value of success. In the database, a new customer will be created with a new identifier or {id}. Note that this {id} is required to be used for the subsequent methods below.

Get Customer

This operation gets a customer. This uses the get method and a path of /customer/{id}. Just as previously explained, this {id} is the identifier created during the Create Customer operation. This operation also uses a DBSelect but instead of returning multiple customers, this will return a single customer.

Put Customer

This operation replaces a customer. It uses a Put method and also the /customer/{id} path. A DBReplace is executed. Do note that a replacement can only happen if it is attempting to replace an existing {id} or customer. If a customer does not exists, it will result in a failure of this execution.

Patch Customer

This operation updates the value of the provided keys for a customer. It uses the method Patch and the path of /customer/{id}. This operation is similar to the put except that instead of replacing the entire customer, it will only replace the value of the provided keys. This means that if I provide a partial list of keys for the customer, only the value of those keys will be updated. The value of the other keys will be retained. 

Delete Customer

This operation deletes a customer. It uses the method Delete and the path of /customer/{id}. This operation will execute a database delete on the customer {id} provided. Since this is an idempotent operation, it will still succeed if the customer {id} did not exist.

Now that we have implemented all the different REST methods, to test this, we can use the public swagger editor. Do note that when we enabled FLOGO_EXPOSE_SWAGGER_EP, when we start this flogo app, we will see a line in the output similar to the below. This means that the swagger specification is available at http://localhost:9999/api/v2/swagger.json (at the configured trigger port).

To get to the public swagger editor using this swagger specification, we simply start a web browser and go to the following URL

https://editor.swagger.io/?url=http://localhost:9999/api/v2/swagger.json

Application Workload Observation

Below are additional workload observations when we build and deploy this specific Flogo application.

Image Size: 61.3MB

* For this build, we use the google distroless base image gcr.io/distroless/base-nossl-debian12.

Startup Time: 11.63445ms

CPU Usage: 1.00m

Memory Usage: 10.23Mi

* No performance testing was done on this project but we wanted to illustrate how much less resource is needed to run this Flogo App.

The code written in Flogo  2.24.0 using the Visual Studio Code Extension is provided below for your reference.

CustomerAPI_v1.0.0.flogo