Skip to content

Alexandre Vazquez

Kubernetes Architect | Integration Expert | TIBCO Guru

  • Kubernetes Architecture & Production Best Practices
  • Helm Charts Package Management
  • TIBCO Integration Platform: Patterns & Best Practices

Flogo

Running TIBCO Flogo Apps as Azure Functions (Serverless Custom Handlers Guide)

2026-01-162020-05-01 by Alexandre Vazquez
Running TIBCO Flogo Apps as Azure Functions (Serverless Custom Handlers Guide)

Serverless is already here. We know that. Even for companies that are starting their cloud journey moving to container-based platforms, they already know that serverless is in their future view at least for some specific use cases.

Its simplicity without needed to worry about anything related to the platform just focuses on the code and also the economics that comes with them makes this computing model a game-changer.

The mainstream platform for this approach at this moment is AWS Lambda from Amazon, we have read and heard a lot of AWS Lamba, but all the platforms are going to that path. Google with its Google Functions, Microsoft with its Azure. This is not just a thing for public cloud providers, also if you’re running on a private cloud approach you can use this deployment mode using frameworks like KNative or OpenFaaS. If you need more details about it, also we had some articles about this topic:

Running TIBCO Flogo Apps as Azure Functions (Serverless Custom Handlers Guide)
Deploying Flogo App on OpenFaaS
OpenFaaS is an alternative to enable the serverless approach in your infrastructure when you’re not running in the public cloud and you don’t have available those other options like AWS Lambda Functions or Azure Functions or even in public cloud, you’d like the features and customizations option it provides. OpenFaaS® (Functions as a Service) is […]

All of these platforms are updating and enhancing its option to execute any kind of code that you want on it, and this is what Azure Function just announced some weeks ago, the release of a Custom Handler approach to support any kind of language that you could think about:

Running TIBCO Flogo Apps as Azure Functions (Serverless Custom Handlers Guide)
Azure Functions custom handlers
Learn to use Azure Functions with any language or runtime version.

And we’re going to test that doing what we’d like best ………..

…. Run a Flogo Application on top of it!

So, let’s start working!

Running TIBCO Flogo Apps as Azure Functions (Serverless Custom Handlers Guide)
Photo by Serghei Trofimov on Unsplash

The first thing we need to do is to create our Flogo Application. I’m going to use Flogo Enterprise to do that, but you can do the same using the Open Source version as well:

We’re going to create a simple application just a Hello World REST service. As you can see here:

Running TIBCO Flogo Apps as Azure Functions (Serverless Custom Handlers Guide)

The JSON file of the Flogo Application you can find it in the GitHub repository shown below:

Running TIBCO Flogo Apps as Azure Functions (Serverless Custom Handlers Guide)
GitHub - alexandrev/flogo-azure-function: Sample of Flogo Application running as a Azure Function
Sample of Flogo Application running as a Azure Function - GitHub - alexandrev/flogo-azure-function: Sample of Flogo Application running as a Azure Function

But the main configurations are the following ones:

  • Server will listen on the port specified by the environment variable FUNCTIONS_HTTPWORKER_PORT
  • Server will listen for a GET request on the URI /hello-world
  • Response will be quite simple “Invoking a Flogo App inside Azure Functions”

Now, that we have the JSON file, we only need to start creating the artifacts needed to run an Azure Function.

We will need to install the npm package for the Azure Functions. To do that we need to run the following command:

npm i -g azure-functions-core-tools@3 --unsafe-perm true

It is important to have the “@3” because that way we reference the version that has this new Custom Handler logic to be able to execute it.

We will create a new folder call flogo-func and run the following command inside that folder:

func init --docker

Now we should select node as the runtime to be used and javascriptas the language. That could be something strange because we are going to use neither node, nor dotnet or pythonor powershell. But we will select that to keep it simple as we just try to focus on the Docker approach to do that.

After that we just need to create a new function, and to do that we need to type the following command:

func new

In the CLI-based interface that the Azure Function Core Tools shows us, we just need to select HTTP trigger and provide a name.

Running TIBCO Flogo Apps as Azure Functions (Serverless Custom Handlers Guide)

In our case, we will use hello-world as the name to keep it similar to what we defined as part of our Flogo Application. We will end up with the following folder structure:

Running TIBCO Flogo Apps as Azure Functions (Serverless Custom Handlers Guide)

Now we need to open the folder that is has been created and we need to do several things:

  • First of all, we need to remove the index.js file because we don’t need that file as this will not be a node JS function.
  • We need to copy the HelloWorld.json (our Flogo application) to the root folder of the function.
  • We need to change the host.json file to the following content:
{
  "version": "2.0",
  "httpWorker": {
     "description": {
            "arguments": ["-app"],
            "defaultExecutablePath": "engine-windows-amd64.exe",
            "defaultWorkerPath": "HelloWorld.json"
      }
   }
}

Now, we need to generate the engine-windows-amd64.exe and to be able to do that we need to go to the FLOGO_HOME in our machine and go to the folder FLOGO_HOME/flogo/<VERSION>/bin and launch the following command:

./builder-windows-amd64.exe build

And you should get the engine-windows-amd64.exe as the output as you can see in the picture below:

Running TIBCO Flogo Apps as Azure Functions (Serverless Custom Handlers Guide)

Now, you just need to copy that file inside the folder of your function, and you should have the following folder structure as you can see here:

Running TIBCO Flogo Apps as Azure Functions (Serverless Custom Handlers Guide)

And once you have that, you just need to run your function to be able to test it locally:

func start

After running that command you should see an output similar to the one shown below:

Running TIBCO Flogo Apps as Azure Functions (Serverless Custom Handlers Guide)

I’d just like to highlight the startup time for our Flogo application around 15 milliseconds!!! Now, you only need to test it using any browser and just go to the following URL:

http://localhost:7071/api/hello-world
Running TIBCO Flogo Apps as Azure Functions (Serverless Custom Handlers Guide)

This has been just the first step on our journey but it was the steps needed to be able to run our Flogo application as part of your serverless environment hosted by Microsoft Azure platform!

Categories TIBCO, Uncategorized Tags Flogo, TIBCO

Deploying a TIBCO Flogo Application on OpenFaaS (Serverless on Kubernetes)

2026-01-162019-08-26 by Alexandre Vazquez
Deploying a TIBCO Flogo Application on OpenFaaS (Serverless on Kubernetes)

OpenFaaS is an alternative to enable the serverless approach in your infrastructure when you’re not running in the public cloud and you don’t have available those other options like AWS Lambda Functions or Azure Functions or even in public cloud, you’d like the features and customizations option it provides.

OpenFaaS® (Functions as a Service) is a framework for building serverless functions with Docker and Kubernetes which has first-class support for metrics. Any process can be packaged as a function enabling you to consume a range of web events without repetitive boiler-plate coding.

Deploying a TIBCO Flogo Application on OpenFaaS (Serverless on Kubernetes)
GitHub - openfaas/faas: OpenFaaS - Serverless Functions Made Simple
OpenFaaS - Serverless Functions Made Simple. Contribute to openfaas/faas development by creating an account on GitHub.

There is good content on medium about OpenFaaS so I don’t like to spend so much time on this, but I’d like to leave you here some links for reference:

Deploying a TIBCO Flogo Application on OpenFaaS (Serverless on Kubernetes)
Running serverless functions on premises using OpenFaas with Kubernetes
Earlier most of companies had monolithic architecture for their cloud applications (all the things in a single package). Nowadays companies…
Deploying a TIBCO Flogo Application on OpenFaaS (Serverless on Kubernetes)
An Introduction to Serverless DevOps with OpenFaaS | HackerNoon
DevOps isn’t about just doing CI/CD. But a CI/CD pipeline has an important role inside DevOps. I’ve been investing my time on recently and as I started creating multiple functions, I wanted an easy to use and accessible development and delivery flow, in other words a CI/CD pipeline. OpenFaaS One day…

We already have a lot of info about how to run a Flogo Application as a Lambda Function as you can see here:

https://www.youtube.com/watch?v=TysuwbXODQI

But.. what about OpenFaaS? Can we run our Flogo application inside OpenFaaS? Sure! Let me explain to you how.

OpenFaaS is a very customize framework to build zero-scaled functions and it could need some time to get familiar with concepts. Everything is based on watchdogs that are the components listening to the requests are responsible for launching the forks to handle the requests:

We’re going to use the new watchdog named as of-watchdog that is the one expected to be the default one in the feature and all the info is here:

Deploying a TIBCO Flogo Application on OpenFaaS (Serverless on Kubernetes)
GitHub - openfaas/of-watchdog: Reverse proxy for STDIO and HTTP microservices
Reverse proxy for STDIO and HTTP microservices. Contribute to openfaas/of-watchdog development by creating an account on GitHub.

This watchdog provides several modes, one of them is named HTTP and it is the default one, and is based on some HTTP Forward to the internal server running in the container. That fits perfectly with our Flogo application and means that the only thing we need is to deploy an HTTP Receive Request trigger in our Flogo Application and that’s it.

Deploying a TIBCO Flogo Application on OpenFaaS (Serverless on Kubernetes)

The only things you need to configure is the method (POST) and the Path (/) to be able to handle the requests. In our case we’re going to do a simple Hello World app as you can see here:

Deploying a TIBCO Flogo Application on OpenFaaS (Serverless on Kubernetes)

To be able to run this application we need to use several things, and let’s explain it here:

First of all, we need to do the installation of the OpenFaaS environment, I’m going to skip all the details about this process and just point to you to the detailed tutorial about it:

Deploying a TIBCO Flogo Application on OpenFaaS (Serverless on Kubernetes)
Deploy OpenFaaS on Amazon EKS | Amazon Web Services
We’ve talked about FaaS (Functions as a Service) in Running FaaS on a Kubernetes Cluster on AWS Using Kubeless by Sebastien Goasguen. In this post, Alex Ellis, founder of the OpenFaaS project, walks you through how to use OpenFaaS on Amazon EKS. OpenFaaS is one of the most popular tools in the FaaS…

Now we need to create our template and to do that, we are going to use a Dockerfile template. To create it we’re going to execute:

faas-cli new --lang dockerfile

We’re going to name the function flogo-test. And now we’re going to update the Dockerfile to be like this:

Deploying a TIBCO Flogo Application on OpenFaaS (Serverless on Kubernetes)

Most of this content is common for any other template using the new of-watchdog and the HTTP mode.

I’d like to highlight the following things:

We use several environment variables to define the behavior:

  • mode = HTTP to define what we’re going to use this method
  • upstream_url = URL that we are going to forward the request to
  • fprocess = OS command that we need to execute, in our case means to run the Flogo App.

Other things are the same as you should do in case you want to run flogo apps in Docker:

  • Add the engine executable for your platform (UNIX in most cases as the image base is almost always a Linux based)
  • Add the JSON file of the application that you want to use.

We also need to change the yml file to look like this:

version: 1.0
provider:
  name: openfaas
  gateway: http://abc59586cc33f11e9941b069251daa7b-1114483165.eu-west-2.elb.amazonaws.com:8080
functions:
  flogo-test:
    lang: dockerfile
    handler: ./flogo-test
    image: alexandrev/flogo-test:1.7

And that’s it! Now, we only need to execute the following command:

faas-cli up -f .\flogo-test.yml

And the function is going to be deployed to your environment and we can run it using the OpenFaas portal directly:

Deploying a TIBCO Flogo Application on OpenFaaS (Serverless on Kubernetes)

All the code is available here (the only thing left is the Flogo Enterprise Engine that you need to use to be able to build and upload it)

Deploying a TIBCO Flogo Application on OpenFaaS (Serverless on Kubernetes)
GitHub - alexandrev/flogo-openfaas-medium: Example Flogo Application for Deploying on OpenFaaS
Example Flogo Application for Deploying on OpenFaaS - GitHub - alexandrev/flogo-openfaas-medium: Example Flogo Application for Deploying on OpenFaaS
Categories TIBCO, Uncategorized Tags Flogo, Openfaas, Serverless, TIBCO

TIBCO Flogo Configuration Explained: Master Internal Settings in 5 Minutes

2026-01-162019-07-29 by Alexandre Vazquez
TIBCO Flogo Configuration Explained: Master Internal Settings in 5 Minutes

Flogo Enterprise is so great platform to build your microservices and Out of the box, you’re going to reach an incredible performance number.

This article is part of my comprehensive TIBCO Integration Platform Guide where you can find more patterns and best practices for TIBCO integration platforms.

!– /wp:paragraph –>

But, even with that, we’re working in a world where each milliseconds count and each memory MB count so it is important to know the tools that we have in our hands to tune at a finer-grained level our Flogo Enterprise application.

As you already know, Flogo is built in top of Go programing language, so we are going to differentiate the parameters that belong to the programing language itself, then other parameters that are Flogo specifics.

All these parameters have to be defined as environment variables, so the way to apply these are going to rely on how you set environment variables in your own target platform (Windows, Linux, OSX, Docker, etc…)

Flogo OSS Specific Parameters

You can check all the parameters and it is default values at the Flogo documentation:

Performance Related Settings

  • FLOGO_LOG_LEVEL: Allows to set at start-up level the log level you want to use for the application execution. The default value is set to “INFO” and it can be increased to DEBUG to do some additional troubleshooting or analysis and set to “WARN” or “ERROR” for production applications that need most performance avoiding printing additional traces.
  • FLOGO_RUNNER_TYPE: Allows to set at the start-up level the type of the runner and the default value is POOLED.
  • FLOGO_RUNNER_WORKERS: Allows to set at the start-up level the number of Flogo workers that are going to be executing logic. The default value is 5 and can be increased when you’re running on powerful hardware that has better parallelism capabilities.
  • FLOGO_RUNNER_QUEUE: Allows to set up at the start-up level the size of the runner queue that is going to keep in memory the requests that are going to be handled by the workers. The default value is 50 and when the number is high it will be also high the memory consumption but the access form the workers to the task will be faster.

Other Settings

  • FLOGO_CONFIG_PATH: Sets the path of the config JSON file that is going to be used to run the application in case it is not embedded in the binary itself. The default value is flogo.json
  • FLOGO_ENGINE_STOP_ON_ERROR: Set the behavior of the engine when an internal error occurs. By default is set to true and means that engine will stop as soon as the error occurs.
  • FLOGO_APP_PROP_RESOLVERS: Set how application properties are going to be gathered for the application to be used. The value is property resolver to use at runtime. By default is None and additional information is included in application properties documentation section.
  • FLOGO_LOG_DTFORMAT: Set how the dates are going to be displayed in the log traces. The default value is “2006–01–02 15:04:05.000”.

Flogo Enterprise Specific Parameters

Even when all the Project Flogo properties are supported by Flogo Enterprise, the enterprise version includes additional properties that can be used to set additional behaviors of the engine.

FLOGO_HTTP_SERVICE_ PORT: This property set the port where the internal endpoints will be hosted. This internal endpoint is used for healthcheck endpoint as well as metrics exposition and any other internal access that is provided by the engine.

FLOGO_LOG_FORMAT: This property allows us to define the notation format for our log traces. TEXT is the default value but we can use JSON to make our traces to be generated in JSON, for example, to be included in some kind of logging ingestion platform

Go Programing Language Specific Parameters

  • GOMAXPROCS: Limits the number of operating system threads that can execute user-level Go code simultaneously. There is no limit to the number of threads that can be blocked in system calls on behalf of Go code; those do not count against the GOMAXPROCS limit.
  • GOTRACEBACK: Controls the amount of output generated when a Go program fails due to an unrecovered panic or an unexpected runtime condition. By default, a failure prints a stack trace for the current goroutine, eliding functions internal to the run-time system and then exits with exit code 2. The failure prints stack traces for all goroutines if there is no current goroutine or the failure is internal to the run-time. GOTRACEBACK=none omits the goroutine stack traces entirely. GOTRACEBACK=single (the default) behaves as described above. GOTRACEBACK=all adds stack traces for all user-created goroutines. GOTRACEBACK=system is like “all” but adds stack frames for run-time functions and shows goroutines created internally by the run-time. GOTRACEBACK=crash is like “system” but crashes in an operating system-specific manner instead of exiting.
  • GOGC: Sets the initial garbage collection target percentage. A collection is triggered when the ratio of freshly allocated data to live data remaining after the previous collection reaches this percentage. The default is GOGC=100. Setting GOGC=off disables the garbage collector entirely.
Categories TIBCO, Uncategorized Tags Flogo, Hacks, TIBCO

TIBCO Flogo Testing Explained: How to Automate and Master Tests in CI/CD

2026-01-162019-07-15 by Alexandre Vazquez
TIBCO Flogo Testing Explained: How to Automate and Master Tests in CI/CD

Flogo Test is one of the main steps in your CI/CD lifecycle if you are using Flogo. You probably have done it previously in all your other developments like Java developments or even using BusinessWorks 6 using the bw6-maven-plugin:

This article is part of my comprehensive TIBCO Integration Platform Guide where you can find more patterns and best practices for TIBCO integration platforms.

TIBCO Flogo Testing Explained: How to Automate and Master Tests in CI/CD
GitHub – TIBCOSoftware/bw6-plugin-maven: Plug-in Code for Apache Maven and TIBCO ActiveMatrix BusinessWorks™
Plug-in Code for Apache Maven and TIBCO ActiveMatrix BusinessWorks™ – GitHub – TIBCOSoftware/bw6-plugin-maven: Plug-in Code for Apache Maven and TIBCO ActiveMatrix BusinessWorks™

So, you’re probably wondering… How this is going to be done by Flogo? Ok!! I’ll tell you.

First of all, you need to keep in mind that Flogo Enterprise is a product that was designed with all those aspects in mind, so you don’t need to worry about it.

Regarding testing, when we need to include inside a CI/CD lifecycle approach, these testing capabilities should meet the following requirements:

  • It should be defined in some artifacts.
  • It should be executed automatically
  • It should be able to check the outcome.

Flogo Enterprise includes by default Testing capabilities in the Web UI where you can not only test your flows using the UI from a debug/troubleshooting perspective but also able to generate the artifacts that are going to allow you to perform more sophisticated testing

So, we need to go to our Web UI and when we’re inside a flow we have a “Start Testing” button:

TIBCO Flogo Testing Explained: How to Automate and Master Tests in CI/CD

And we can see all our Launch Configuration change and most important part for this topic be able to export it and download it to your local machine:

TIBCO Flogo Testing Explained: How to Automate and Master Tests in CI/CD

Once everything is downloaded and we have the binary for our application we can execute the tests in an automatic way from the CLI using the following command

.\FlogoJWTEcho-windows_amd64.exe' -test -flowin .\MainFlow_Launch_Configuration_1.json -flowout MainFlow_out.json

This is going to generate an output file with the output of the execution test:

TIBCO Flogo Testing Explained: How to Automate and Master Tests in CI/CD

And if we open the file we will get the exact same output the flow is returned so we can perform any assert on it

TIBCO Flogo Testing Explained: How to Automate and Master Tests in CI/CD

That was easy, right? Let’s do some additional tweaks to avoid your need to go to the Web UI. You can generate the launch configuration using only the CLI.

To do that, you only need to execute the following command:

.\FlogoJWTEcho-windows_amd64.exe' -test -flowdata MainFlow
TIBCO Flogo Testing Explained: How to Automate and Master Tests in CI/CD

But, how do you know the flows in your application without going to the Flogo Web UI? Just with the following command:

.\FlogoJWTEcho-windows_amd64.exe' -test  -flows
TIBCO Flogo Testing Explained: How to Automate and Master Tests in CI/CD
Categories TIBCO, Uncategorized Tags Flogo, Testing, TIBCO

JWT Authentication in TIBCO Flogo Enterprise with OAuth 2.0 (AWS Cognito Example)

2026-01-162019-07-08 by Alexandre Vazquez
JWT Authentication in TIBCO Flogo Enterprise with OAuth 2.0 (AWS Cognito Example)

OAuth 2.0 and JWT Introduction

OAuth 2.0

OAuth 2.0 is a protocol that allows users to authorize third-parties to access their info without needing to know the user credentials. It usually relies on an additional system that acts as Identity Provider where the user is going to authenticate against, and then once authenticate you are provided with some secure piece of information with the user privileges and you can use that piece to authenticate your requests for some period.

This article is part of my comprehensive TIBCO Integration Platform Guide where you can find more patterns and best practices for TIBCO integration platforms.

JWT Authentication in TIBCO Flogo Enterprise with OAuth 2.0 (AWS Cognito Example)
OAuth v2.0 Authentication Flow Sample

OAuth 2.0 also defines a number of grant flows to adapt to different authentication needs. These authorization grants are the following ones:

  • Client Credentials
  • Authorization Code
  • Resource Owner Password Credentials

The decision to choose one flow or another depends on the needs of the invocation and of course, it is a customer personal decision but as a general way, the approximation showed in the Auth0 documentation is the usual recommendation:

JWT Authentication in TIBCO Flogo Enterprise with OAuth 2.0 (AWS Cognito Example)
Decision Graph to choose the Authorization Grant to use

These grants are based on JSON Web Token to transmit information between the different parties.

JWT

JSON Web Token is an industry standard for a token generation defined in the RFC 7519 standard. it defines a secure way to submit info between parties like a JSON object.

It is composed of three components (Header, Payload, and Signature) and can be used by a symmetric cipher or with a public/private key exchange mode using RSA or ECDSA.

JWT Authentication in TIBCO Flogo Enterprise with OAuth 2.0 (AWS Cognito Example)
JWT Composition Sample

Use Case Scenario

So, OAuth V2 and JWT are the usual way to authenticate requests in Microservice world, so it is important to have this standard supported in your framework, and this is perfectly covered in Flogo Enterprise as we’re going to see in this test.

AWS Cognito Setup

We’re going to use AWS Cognito as the Authorization Server, as this is quite easy to set up and it is one of the main actors in this kind of authentication. In Amazon words themselves:

Amazon Cognito lets you add user sign-up, sign-in, and access control to your web and mobile apps quickly and easily. Amazon Cognito scales to millions of users and supports sign-in with social identity providers, such as Facebook, Google, and Amazon, and enterprise identity providers via SAML 2.0.

In our case, we’re going to do a pretty straightforward setup and the steps down are shown below:

  • Create a User Pool named “Flogo”
  • Create an App Client with a generated secret named “TestApplication”
  • Create a Resource Server named “Test” with identifier “http://flogo.test1” and with a scope named “echo”
JWT Authentication in TIBCO Flogo Enterprise with OAuth 2.0 (AWS Cognito Example)
Resource Server Configuration
  • Set the following App Client Settings as shown in the image below with the following details:
  1. Cognito User Pool selected as Enable Identity Provider
  2. Client credentials used as Allowed OAuth Flows
  3. http://flogo.test1/echo selected as an enabled scope
JWT Authentication in TIBCO Flogo Enterprise with OAuth 2.0 (AWS Cognito Example)
App Client Setting Configuration

And that’s all the configuration needed at the Cognito level, and now let’s go back to Flogo Enterprise Web UI.

Flogo Set-up

Now, we are going to create a REST Service and we’re going to skip all steps regarding how to create a REST service using Flogo but you can take a look at the detailed steps in the flow below:

JWT Authentication in TIBCO Flogo Enterprise with OAuth 2.0 (AWS Cognito Example)
Building your First Flogo Application
In the previous post, we introduce Flogo technology like one of the things in the cloud-native development industry and now we’re going to build our first Flogo Application and try to cover all the options that we describe in the previous post. NOTE .- If you’re new to Flogo and you didn’t read the previous post […]

We’re going to create an echo service hosted at localhost:9999/hello/ that received a path parameter after the hello that is the name we’d like to greet, and we’re going to establish the following restrictions:

  • We’re going to check the presence of a JWT Token
  • We’re going to validate the JWT Token
  • We’re going to check that the JWT included the http://flogo.test1/echo

In case, everything is OK, we’re going to execute the service, in case some prerequisite is not meet we’re going to return a 401 Unauthorized error.

We’re going to create two flows:

  • Main flow that is going to have the REST Service
  • Subflow to do all the validations regarding JWT.

MainFlow is quite straightforward is going to receive the request, execute the subflow and depending on their output is going to execute the service or not:

JWT Authentication in TIBCO Flogo Enterprise with OAuth 2.0 (AWS Cognito Example)

So, all important logic is inside the other flow that is going to do all the JWT Validation, and its structure is the one showed below:

JWT Authentication in TIBCO Flogo Enterprise with OAuth 2.0 (AWS Cognito Example)

We’re going to use the JWT activity hosted in GitHub available at the link shown below:

JWT Authentication in TIBCO Flogo Enterprise with OAuth 2.0 (AWS Cognito Example)
flogo-components/activity/jwt at master · ayh20/flogo-components
Contribute to ayh20/flogo-components development by creating an account on GitHub.

NOTE: If you don’t remember how to install a Flogo Enterprise extension take a look at the link below:

JWT Authentication in TIBCO Flogo Enterprise with OAuth 2.0 (AWS Cognito Example)
Installing Extensions in Flogo Enterprise
In previous posts, we’ve talked about capabilities of Flogo and how to build our first Flogo application, so at this moment if you’ve read both of them you have a clear knowledge about what Flogo provides and how easy is to create applications in Flogo. But in those capabilities, we’ve spoken about that one of […]

And after that, the configuration is quite easy, as the activity allows you to choose the action you want to do with the token. In our case, “Verify” and we provided the token, the algorithm (in our case “RS256”) and the public key we’re going to use for validating the signature of the token:

JWT Authentication in TIBCO Flogo Enterprise with OAuth 2.0 (AWS Cognito Example)
JWT Authentication in TIBCO Flogo Enterprise with OAuth 2.0 (AWS Cognito Example)

Test

Now, we’re going to launch the Flogo Enterprise Application from the binary generated:

JWT Authentication in TIBCO Flogo Enterprise with OAuth 2.0 (AWS Cognito Example)

And now, if we try to do an execution to the endpoint without providing any token we get the expected 401 code response

JWT Authentication in TIBCO Flogo Enterprise with OAuth 2.0 (AWS Cognito Example)

So, to get the access token first thing we need to do is to send a request to AWS Cognito endpoint (https://flogotest.auth.eu-west-2.amazoncognito.com/oauth2/token) using our app credentials:

JWT Authentication in TIBCO Flogo Enterprise with OAuth 2.0 (AWS Cognito Example)

And this token has all the info from the client and its permission, you can check it in the jwt.io webpage:

JWT Authentication in TIBCO Flogo Enterprise with OAuth 2.0 (AWS Cognito Example)

And to finally test it, we only need to add it to the first request we tried as we can see in the picture below:

JWT Authentication in TIBCO Flogo Enterprise with OAuth 2.0 (AWS Cognito Example)

Resources

JWT Authentication in TIBCO Flogo Enterprise with OAuth 2.0 (AWS Cognito Example)
GitHub – alexandrev/flogo-jwt-sample-medium: JWT Support in Flogo Enterprise Post Resource
JWT Support in Flogo Enterprise Post Resource. Contribute to alexandrev/flogo-jwt-sample-medium development by creating an account on GitHub.
Categories TIBCO, Uncategorized Tags Flogo, Jwt, Security, TIBCO

TIBCO Flogo Performance Benchmark: How Fast Are Services Compared to Python?

2026-01-162019-07-01 by Alexandre Vazquez
TIBCO Flogo Performance Benchmark: How Fast Are Services Compared to Python?
Table Of Contents
  1. Introduction

Introduction

In previous posts, we’ve talked a lot about all the capabilities of Flogo and how to do different kinds of things with Flogo, and one message was always underlined there: performance, performance, performance… but how flogo performance is compared with other modern programming languages?

This article is part of my comprehensive TIBCO Integration Platform Guide where you can find more patterns and best practices for TIBCO integration platforms.

– /wp:paragraph –>

Categories TIBCO, Uncategorized Tags Flogo, Performance, TIBCO

TIBCO Flogo Error Handling Explained: Designing Reliable and Resilient Flows

2026-01-162019-06-24 by Alexandre Vazquez
TIBCO Flogo Error Handling Explained: Designing Reliable and Resilient Flows
Table Of Contents
  1. Introduction
  2. Error Handler
  3. Error Condition
  4. Throw Error Activity

Introduction

We’ve covered the basics of Flogo Enterprise development in the previous articles, but there is an important topic that hasn’t been discussed for now, and this is flogo error handling. We always think everything is going to work the way we plan to, and everything is going to go down the green path, but most of the time they’re not, so you need to prepare your flows to be ready to handle these situations.

This article is part of my comprehensive TIBCO Integration Platform Guide where you can find more patterns and best practices for TIBCO integration platforms.

/wp:paragraph –>

If you’re used to TIBCO BusinessWorks Development you’re going to get used to it because most of the ways to do things are pretty much the same, so any kind of logic you apply to your developments can be applied here. Let’s cover the basics first.

Error Handler

A flogo error handler is the main way Flogo developers handle the issues that happen in development and this has been this way for all versions from the first one until Flogo Enterprise 2.6.0 because until that moment it was the only way to do it.

The error handler is a different error flow that is going to be invoked when something is wrong similar to a catch flow in TIBCO BusinessWorks development. When you click the Error Handler button you’re going to enter into a new flow with a predefined starter named error as you can see in the picture below:

TIBCO Flogo Error Handling Explained: Designing Reliable and Resilient Flows

Data that is going to be starting this flow is the activity name that failed and failing message, and then you can do any handle logic you need to do until the flow is returned. Activities that you could use and logic is exactly the same you can use in your main flow

Error Condition

Since Flogo Enterprise 2.6.0 a new way to handle error has been included, as we said until that point any error generates an invocation of the error handler, but this doesn’t cover every use case scenario when an error happens.

As Flogo Enterprise starts with a simple microservice use-case scenario error handle was enough to handle it, but now as the power and features Flogo provides have been increasing new methods to catch and act when an error happens are needed to cover these new scenarios. So, now when you create a branch condition you can choose three options: Success, Success with Condition, and Error.

To do that, you only need to click on the engine button that appears in the branch creation from the activity that is generating the error:

TIBCO Flogo Error Handling Explained: Designing Reliable and Resilient Flows

And you could choose one of the three situations as you can see in the image below:

TIBCO Flogo Error Handling Explained: Designing Reliable and Resilient Flows

As branches are accumulative we can have an activity with different branches of different types:

TIBCO Flogo Error Handling Explained: Designing Reliable and Resilient Flows

But you can only add one Error Type branch for each activity if you try to add another field is going to be disabled so you can not go to be able to do it:

TIBCO Flogo Error Handling Explained: Designing Reliable and Resilient Flows

Throw Error Activity

All this content has been focused on how to handle errors when it happens, but you can also need the other way around to be able to detect something do some checks and decide that this should be handled as an error.

To do that you have the Throw Error Activity where you can pass the data of the error you want to handle in a two-key element interface one for the error message and another for error data as you can see in the picture below:

TIBCO Flogo Error Handling Explained: Designing Reliable and Resilient Flows
Categories TIBCO, Uncategorized Tags Flogo, Hacks, TIBCO

TIBCO Flogo Subflows Explained: Improve Reusability and Maintainability

2026-01-162019-06-17 by Alexandre Vazquez
TIBCO Flogo Subflows Explained: Improve Reusability and Maintainability

Reuse is one of the most important capabilities in Application Development and this is something that has been implemented so great in Flogo Enterprise that you’re going to be amazed how great it is. Let’s take a look at Flogo Subflows

This article is part of my comprehensive TIBCO Integration Platform Guide where you can find more patterns and best practices for TIBCO integration platforms.

!– /wp:paragraph –>

In Flogo it doesn’t exist the concept of Subflow when you create an application, you only can create flows. If you remember Flow was created based on Triggers and Actions:

So, what is subflow in Flogo? A Flow without the triggers. That simple. So, it means that I need to create a new flow, but removing any trigger or using a special trigger so this could be reused in a different flow? No. Not needed.

Any flow can be reused as subflows as is. Only change when you invoke it as a subflow the triggers are not going to be executed. That simple. So, yes, you can reuse any flow you’ve created without doing anything at all. Let’s see how

Remember the application that we’ve created in the past post about GraphQL:

We have a flow named Mutation_asignUser where we need to gather the info from the user and the company, the same thing we were already doing in the following flows Query_currentUser and Query_company. So, how easy is to reuse them? Let’s take a look at Mutation_asignUser in more detail:

TIBCO Flogo Subflows Explained: Improve Reusability and Maintainability
Mutation_asignUser with highlighted subflows usage

In the activities with the red box around is where we’re calling our “subflows” and this is so easy as include an activity called “Start a SubFlow”

TIBCO Flogo Subflows Explained: Improve Reusability and Maintainability

This activity is going to ask for the flow, that it could be any flow you have in your application (not flows from other applications can be included as subflow)

TIBCO Flogo Subflows Explained: Improve Reusability and Maintainability

And once you select the flow, input and output are going to be populated based on the flow interface. So easy, right?

Let’s hack it! and start creating more Flogo apps!!!!

Categories TIBCO, Uncategorized Tags Flogo, TIBCO

GraphQL Support in TIBCO Flogo: Build APIs from GraphQL Schemas

2026-01-162019-06-03 by Alexandre Vazquez
GraphQL Support in TIBCO Flogo: Build APIs from GraphQL Schemas

With the recent release of Flogo Enterprise 2.6 (please take your time to take a look at the release notes to know all the news that have been released), it has been included support to GraphQL.

I don’t want to make a full article about what GraphQL is and the advantages that include comparing with REST and so. Especially when you have so many articles in medium about that topic, so please take a look at the following ones:

GraphQL Support in TIBCO Flogo: Build APIs from GraphQL Schemas
A Beginner’s Guide to GraphQL
One of the most commonly discussed terms today is the API. A lot of people don’t know exactly what an API is. Basically, API stands for…

So, in summary, GraphQL it’s a different protocol to define your API interfaces with another approach in mind. So, let’s see how can include this kind of interfaces in our Flogo flows. We’re going to play with the following GraphQL Schema that is going to define our API

If this is the first time you see a GraphQL schema, let me give you some clarifications:

  • Schema is split into three parts: Queries, Mutations, and Model
  • Queries are GET-style request to get information. In our case, we have two queries currentUser and company.
  • Mutations are POST/PUT-style request to modify information. In our case, we have three mutations: registerUser, registerCompany, asignUser.
  • Model is the different objects and types our queries and mutations interact with.

So, now we are going to do the hard work in Flogo Environment, and we start creating a new application that we’re going to call GraphQL_Sample_1

GraphQL Support in TIBCO Flogo: Build APIs from GraphQL Schemas
Creation form of the new app named GraphQL_Sample_V1

Now, we have an empty application. Until this point it wasn’t hard, right? Ok, let’s see how it goes. Now we are going to create a new flow, and we can choose between three options:

  • Empty flow
  • Swagger specification
  • GraphQL Schema
GraphQL Support in TIBCO Flogo: Build APIs from GraphQL Schemas

So we choose the option from GraphQL Schema and we upload the file and it generates a skeleton of all the flows needed to support this specification. A new flow is going to be generated for each of the queries and each of the mutations we’ve defined, as we have two (2) queries and three (3) mutations, so five (5) flows in total as you can see in the picture below:

GraphQL Support in TIBCO Flogo: Build APIs from GraphQL Schemas
Autogenerated flows based on GraphQL schema

As you can see flows have been generated following the following naming convention:

<TYPE>_<name>

Where <TYPE> can be either Mutation or Query and <name> is the name this component has in the GraphQL Schema.

Now, everything is done regarding GraphQL part, and we only need to provide content to each of the flows. In this sample, I’m going to rely on a PostgreSQL database to store all the info regarding users and companies, but the content is going to be very straight forward.

  • Query_currentUser: This flow is going to ask for the customer data to the PostgreSQL to return its data and the company he belongs to. In case he doesn’t belong to anyone, we gather only the data user and in case it is not present to return an empty object.
GraphQL Support in TIBCO Flogo: Build APIs from GraphQL Schemas
Query_currentUser flow
  • Query_company: This flow is going to ask for the company data to the PostgreSQL to return and in case it is not present to return an empty object.
GraphQL Support in TIBCO Flogo: Build APIs from GraphQL Schemas
  • Mutation_registerUser: This flow is going to insert a user in the database and in case its mail already exists is going to return the existing data to the consumer.
GraphQL Support in TIBCO Flogo: Build APIs from GraphQL Schemas
  • Mutation_registerCompany: This flow is going to insert a company in the database and in case its name already exists is going to return the existing data to the consumer.
GraphQL Support in TIBCO Flogo: Build APIs from GraphQL Schemas
  • Mutation_asignUser: This flow is going to assign a user into the company to do that is going to return the user data based on its email and same thing with the company and update the PostgreSQL activities based on that situation.
GraphQL Support in TIBCO Flogo: Build APIs from GraphQL Schemas

Ok, now we have our app already built, let’s see how we can test it and play with the GraphQL API we’ve built. So…its show-time!!!!!

GraphQL Support in TIBCO Flogo: Build APIs from GraphQL Schemas
Photo by Yvette de Wit on Unsplash

First, we’re going to build the app. As you probably know you can choose for different kinds of builts: docker image or OS-based package. In my case, I’m going to generate a Windows build to ease all the process, but you can choose whatever feels good to you.

To do that we go to the menu app and click in the Build and choose the Windows option:

GraphQL Support in TIBCO Flogo: Build APIs from GraphQL Schemas
Build option to windows

And once the built has done we’re going to have a new EXE file in our Download folder. Yes, that easy! And now, how to launch it? Even easier… just execute the EXE file and … it’s done!!

GraphQL Support in TIBCO Flogo: Build APIs from GraphQL Schemas
GraphQL Flogo app running in Windows console

As you can see in the picture above we’re listening requests in port 7879 in the /graphql path. So, let’s open a Postman client and start sending requests to it!!

And we’re going to start with the queries and to be able to return data I’ve inserted in the database a sample record with test@test.com email so, If now I try to recover it, I can do this:

{
 “query” : “query($email: String!) { currentUser( email: $email) { id firstName email } }”,
 “variables” : {“email” : “test@test.com” }
}
GraphQL Support in TIBCO Flogo: Build APIs from GraphQL Schemas
Postman Execution of GraphQL

Only a few highlights about our GraphQL query:

  • We can choose the amount of attributes the query is going to recover, and thats the last part of the query, so If I change it, let’s see what happens:
{
 “query” : “query($email: String!) { currentUser( email: $email) { id } }”,
 “variables” : {“email” : “test@test.com” }
}

And now, we’re getting only this output:

GraphQL Support in TIBCO Flogo: Build APIs from GraphQL Schemas
GraphQL output with only returning id
Categories TIBCO, Uncategorized Tags Flogo, GraphQL, TIBCO

Installing Flogo Extensions in TIBCO Flogo Enterprise (UI and CLI Guide)

2026-01-162019-05-27 by Alexandre Vazquez
Installing Flogo Extensions in TIBCO Flogo Enterprise (UI and CLI Guide)

In previous posts, we’ve talked about capabilities of Flogo and how to build our first Flogo application, so at this moment if you’ve read both of them you have a clear knowledge about what Flogo provides and how easy is to create applications in Flogo.

But in those capabilities, we’ve spoken about that one of the strengths from Flogo is how easy is to extend the default capabilities Flogo provides. Flogo Extensions allows increasing the integration capabilities from the product as well as the compute capabilities and they’re built using Go. You can create a different kind of extensions:

  • Triggers: Mechanism to activate a Flogo flow (usually known as Starters)
  • Activities/Actions: Implementation logic that you can use inside your Flogo flows.
Installing Flogo Extensions in TIBCO Flogo Enterprise (UI and CLI Guide)

There are different kinds of extensions depending on how they’re provided and the scope they have.

  • TIBCO Flogo Enterprise Connectors: These are the connectors provided directly from TIBCO Software for the customers that are using TIBCO Flogo Enterprise. They are release using TIBCO eDelivery like all the other products and components from TIBCO.
  • Flogo Open Source Extensions: These are the extensions developed by the Community and that is usually stored in GitHub repositories or any other control version system that is publicly available.
  • TIBCO Flogo Enterprise Custom Extensions: These are the equivalent extensions to Flogo OpenSource Extensions but build to be used in TIBCO Flogo Enterprise or TIBCO Cloud Integration (iPaaS from TIBCO) and that follows the requirements defined by Flogo Enterprise Documentation and provides a little more configuration options about how this is displayed in UI.

Installation using TIBCO Web UI

We’re going to cover in this article how to work with all of them in our environment and you’re going to see that the procedure is pretty much the same but the main difference is how to get the deployable object.

We need to install some extension and for our case, we’re going to use both kinds of extensions possible: A connector provided by TIBCO for connecting to GitHub and an open source activity build for the community to manage the File operations.

First, we’re going to start with the GitHub connector and we’re going to use the Flogo Connector for GitHub, that is going to be downloaded through TIBCO eDelivery as you did with Flogo Enterprise. Once you have the ZIP file, you need to add it to your installation and to do that, we’re going to go to the Extensions page

Installing Flogo Extensions in TIBCO Flogo Enterprise (UI and CLI Guide)

And we’re going to click in Upload and provide the ZIP file we’ve downloaded with the GitHub connector

Installing Flogo Extensions in TIBCO Flogo Enterprise (UI and CLI Guide)

We click on the button “Upload and compile” and wait until the compilation process finishes and after that, we should notice that we have an additional trigger available as you can see in the picture below:

Installing Flogo Extensions in TIBCO Flogo Enterprise (UI and CLI Guide)

So, we already have our GitHub trigger, but we need our File activities and now we’re going to do the same exercise but with a different connector. In this case, we’re going to use an open source activity that is hosted in the Leon Stigter GitHub repository. And we’re going to download the full flogo-components repository and upload that ZIP file to the Extensions page as we did before:

Installing Flogo Extensions in TIBCO Flogo Enterprise (UI and CLI Guide)

We’re going to extract the full repository and go to the path activity and generate a zip file from the folder named “writetofile” and that is the ZIP file that we’re going to upload it to our Extension page:

Installing Flogo Extensions in TIBCO Flogo Enterprise (UI and CLI Guide)

Repository structure is pretty much the same for all this kind of open source repositories, they usually have the name flogo-components and inside they have two main folders:

  • activity: Folder that is grouping all different activities that are available in this repository.
  • trigger: Folder that is grouping all different triggers that are available in this repository.
Installing Flogo Extensions in TIBCO Flogo Enterprise (UI and CLI Guide)

Each of these folders is going to have a folder for each of the activities and triggers that are being implemented in this repository like you can see in the picture below:

Installing Flogo Extensions in TIBCO Flogo Enterprise (UI and CLI Guide)

And each of them is to have the same structure:

  • activity.json: That is going to describe the model of the activity (name, description, author, input settings, output settings)
  • activity.go: Holds all the programming code in Go to build the capability the activity exposes.
  • activity_test.go : Holds all tests the activity has to be ready to be used by other developers and users.

NOTE: Extensions for TIBCO Flogo Enterprise have an additional file named activity.ts that is a TypeScript file that defines UI validations that it should be done for the activity.

And once we have the file we can upload it the same way we did with the previous extension.

Using CLI to Install

Also, If we’re using the Flogo CLI we can still install it using directly the URL to the activity folder without needed to provide the zip file. To do that we need to enable Installer Manager using the following command:

<FLOGO_HOME>/tools/installmgr.bat

And that is going to build a Docker image that represents a CLI tool with the following commands:

Installing Flogo Extensions in TIBCO Flogo Enterprise (UI and CLI Guide)
Installer Manager usage menu
  • Install: Install Flogo Enterprise, Flogo Connectors, Services, etc in the current installation directory.
  • Uninstall: Uninstall Flogo Enterprise, Flogo Connectors, Services from the current installation directory.
Installing Flogo Extensions in TIBCO Flogo Enterprise (UI and CLI Guide)
TIBCO Connector installation using Install Manager CLI

And this process can be used with an official Connector as well as an OSS Extension

Installing Flogo Extensions in TIBCO Flogo Enterprise (UI and CLI Guide)
OSS Extension Installation using Install Manager CLI
Categories TIBCO, Uncategorized Tags Flogo, Hacks, TIBCO
Older posts
Page1 Page2 Next →
© 2026 Alexandre Vazquez • Built with GeneratePress