TIBCO Archives - Page 2 Of 4 - Alexandre Vazquez

#TIBFAQS Enabling Remote Debugging for TIBCO BusinessWorks Application on Kubernetes

2026-01-152021-05-11 by Alexandre Vazquez

Provide more agility to your troubleshooting efforts by debugging exactly where the error is happening using Remote Debugging techniques

Container revolution has provided a lot of benefits, as we have been discussed in-depth in other articles, and at the same time, it has also provided some new challenges that we need to tackle.

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

All agility that we have now in the hands of our developers needs to be also extended to the maintenance work and fixing things. We need to be agile as well. We know some of the main issues that we have regarding this: It works on my environment, with the data set that I have, I couldn’t see the issue, or I couldn’t reproduce the error, are just sentences that we listen to over and over and delay the resolution of some errors or improvements even when the solution is simple we struggle in getting a real scenario to test.

And here is where Remote Debugging comes in. Remote Debugging is, just as its own name clearly states, to be able to debug something that is not local that is remote. It has been focused since its conception in Mobile Development because it doesn’t matter how good the simulator is. You will always need to test in a real device to make sure everything is working properly.

So this is the same concept but applicable to a container, so that means that I have a TIBCO BusinessWorks application running on Kubernetes. We want to debug it as it has been running locally, as shown in the image before. To be able to do that, we need to follow these steps:

Enabling the Remote Debugging in the pod

The first step is to enable the remote debug option in the application and to do that, we need to use the internal API that the BusinessWorks provides, and to do that, we need to execute from inside the container:

curl -XPOST http://localhost:8090/bw/bwengine.json/debug/?interface=0.0.0.0&port=5554&engineName=Main

In case that we do not have any tool like curl or wget to hit a URL inside the container, you can always use the port-forward strategy to make the 8090 port from the pod accessible to enable the debug port using a command similar to the one below:

kubectl port-forward hello-world-test-78b6f9b4b-25hss 8090:8090

And then, we can hit it from our local machine to enable remote debugging

Make the Debug Port accessible to the Studio

To do the remote debugging, we need to be able to connect our local TIBCO BusinessStudio to this specific pod that is executing the load and, to do that, we need to have access to the Debug port. To get this, we have mainly two options that are the ones shown in the subsections below: Expose the port at the pod level and port-forwarding option.

Expose the port at the Pod Level

We need to have the debug port opened in our pod. To do that, we need to define another port that is not in use by the application, and it is not the default administration port (8090) to the one to be exposed. For example, in my case, I will use 5554 as the debug port, and to do that, I define another port to be accessed.

Port-Forwarding Option

Another option if we do not want to expose the debug port all the time, even if this is not going to be used unless we’re executing the remote debug, we have another option to do a port-forward to the debug port in our local.

kubectl port-forward hello-world-test-78b6f9b4b-cctgh 5554:5554

Connection to the TIBCO Business Studio

Now that we have everything ready, we need to connect our local TIBCO Business Studio to the pod, and to do that, we need to follow these steps:

Run → Debug Configurations, and we select the Remote BusinessWorks

And now we need to provide the connection details. For this case, we will use the localhost and port 5554 and click on the Debug button.

After that moment, we will establish a connection between both environments: the pod running on our Kubernetes cluster and our local TIBCO BusinessStudio. And as soon as we hit the container, we can see the execution in our local environment:

Summary

I hope you find this interesting, and if you are one of those facing this issue now, you have information not to be stopped by this one. If you would like to submit your questions feel free to use one of the following options:

Twitter: You can send me a mention at @alexandrev on Twitter or a DM or even just using the hashtag #TIBFAQS that I will monitor.
Email: You can send me an email to alexandre.vazquez at gmail.com with your question.
Instagram: You can send me a DM on Instagram at @alexandrev

How to Check TIBCO BusinessWorks Configuration at Runtime (OSGi lcfg Command)

2026-01-162021-03-23 by Alexandre Vazquez

Discover how the OSGI lcfg command can help you be sure which is the configuration at runtime.

Knowing the TIBCO BW configuration at runtime is became critical as you always need to know if the latest changes has been applied or just want to check the specific value for a Module Property as part of your development.

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

When we are talking about applications deployed on the cloud one of the key things is Configuration Management. Especially if we include into the mix things like Kubernetes, Containers, External Configuration Management System things got tricky.

Usual configuration when we are talking about a Kubernetes environment for configuration management is the use of Config Maps or Spring Cloud Config.

When you can upload the configuration in a separate step as deploying the application, you can get into a situation where you are not sure about what is the running configuration that a BusinessWorks application has.

To check TIBCO BW configuration there is an easy way to know exactly the current values:

We just need to get inside the container to be able to access the internal OSGI console that allows us to execute administrative commands.
We have spoken other times about that API but in case you would like to take a deeper look you just need to check this link:

And one of the commands is lcfg that allows knowing which configuration is being used by the application that is running:

curl localhost:8090/bw/framework.json/osgi?command=lcfg

With an output similar to this:

Summary

Twitter: You can send me a mention at @alexandrev on Twitter or a DM or even just using the hashtag #TIBFAQs that I will monitor.
Email: You can send me an email to alexandre.vazquez at gmail.com with your question.
Instagram: You can send me a DM on Instagram at @alexandrev

How to Fix TIBCO BusinessWorks Impaired Status (Root Causes & Troubleshooting Guide)

2026-01-162021-02-15 by Alexandre Vazquez

Learn the main reasons behind an Impaired status and how you can perform troubleshooting to identify and solve the error.

#TIBFAQS: TIBCO BW Impaired Status: How to solve it? — Photo by Charles Deluvio on Unsplash

This is another post of the #TIBFAQS series. To remind you what all this about is, you can submit your questions regarding TIBCO developing issues or doubts and try to provide an answer here to try to help the community of TIBCO developers out there.

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

So, today I am going to start with one of the most common issues when we work with BusinessWorks, and it is when I am going to deploy my application or test it locally, and I get this log trace and nothing after that: TIBCO BW Impaired Status.

This is one of the usual situations for a BusinessWorks junior developer and one of the reasons you have more time spent doing troubleshooting. Let’s get some tricks today, so this message will never again stop you in your journey to production.

What is the cause of this error?

This error means that the BusinessWorks runtime is not able to meet all the dependencies among the components to be able to start. As you probably know, BusinessWorks each of the applications’ components is managed independently, and they are referencing each other.

For example, the Application depends on the Application Module and the Shared Module. The Application module can have a dependency on a JMS Connection and so on.

Situations that can raise this error

Let’s take a look now at the situation that can raise this error and solve it.

1.- Missing module or incompatible versions

One usual situation that can lead to this problem is missing modules or incompatible versions of the modules. In that case, the referencable component will wait for a module or a specific version of a module to be started. Still, this module is missing, or it is starting another version.

2.- Not valid shared connections

Another option can be if some of the components are required to establish the connection with other technologies such as JDBC connections, JMS connections, KAFKA connections, or another one of the more than 200 connectors available.

3.- Missing Starter component in the Module Descriptors

The last of the usual suspects here is when you have a Stater component in the Module Descriptors, but this process is not available inside the EAR file that you are deploying. That dependency is never satisfied, and that leads to unlimited Impaired status.

How to detect what component is missing?

To help you in the process of detecting in which situation you are, you have an incredible tool at your disposal which is the command la from the OSGi Console Interface.

This command helps us list the applications deployed in this specific AppNode or container and give us the details of them, including the reason for an Impaired situation.

How to run the OSGi console depends on your deployment model, but you can read all the information about it in the link below:

403 Forbidden

Summary

I hope you find this interesting to solve your TIBCO BW Impaired status on your apps, and if you are one of those facing this issue now, you have information not to be stopped by this one. If you would like to submit your questions feel free to use one of the following options:

Twitter: You can send me a mention at @alexandrev on Twitter or a DM or even just use the hashtag #TIBFAQs that I will monitor.
Email: You can send me an email to alexandre.vazquez at gmail.com with your question.
Instagram: You can send me a DM on Instagram at @alexandrev

How to Fix “Failed to Read Profile from /tmp/tmp/pcf.substvar” in TIBCO BWCE

2026-01-162021-01-18 by Alexandre Vazquez

This is another post of the #TIBFAQS series and only to remind you what all this about is that you can submit your questions regarding TIBCO developing issues or doubts and I try to provide an answer here to try to help the community of TIBCO developers out there.

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

So, today I am going to start with one of the I think most common issues when we work with BusinessWorks Container Edition and we are deploying into our target environment and it is a trace similar to this one:

Error trace regarding I am not able to read the profile

What is the cause of this error?

This error means that the BusinessWorks runtime is not able to read and process the properties file to start the application. So that means that your error is regarding the configuration of the application and not the application itself. So, the good news here: your code seems to be fine at this point.

As probably you know all the TIBCO BW applications use for a very long time an XML file to have the configuration values to start with. This is the file that in the case of BusinessWokrks Container Edition is stored at /tmp/tmp/pcf.substvar and it is populated for several sources depending on how to manage your configuration.

As you know you have several options to manage your configuration in Cloud base environments: Environment variables, Config Maps, Configuration Management Systems such as Spring Cloud Config or Consul.. So it is important that you have a clear understanding of what are you using.

So the error is that the file has something in its content that is not valid, because it is wrong or because it is not able to understand it.

Situations that can raise this error

Let’s take a look now at the situation that can raise this error and how we can solve it.

1.- Incompatible BW-runtime vs EAR versions

Usually, EAR files are compatible with different BusinessWorks runtimes, but this is true when the runtime is more current than the EAR. So I mean, if I generate my application with BWCE 2.5.0 I can run it with runtime 2.5.0, or 2.5.3 or 2.6.0 without any issue, but if I try to run it with an older version like 2.4.2 I can get this error because the EAR file has some “new things” that the runtime is not able to understand.

So it is important to validate that the runtime version that you are using is the expected one and updated it if that is not the case.

2.- XML special characters that need to be escaped

This situation is only true in versions before 2.5.0, but in case you are running an older version, you can also get this error because your property value has an XML character that needs to be escaped. Characters like ‘<’ or ‘&’ and the most used ones to generate this error. If you are using a more updated version you don’t need to escape it because they are automatically escaped.

So depending on the version that you are using update your property’s value accordingly.

Summary

I hope you find this interesting and if you are one of those facing this issue now you have information to not be stopped by this one. If you would like to submit your questions feel free to use one of the following options:

Twitter: You can send me a mention at @alexandrev on Twitter or a DM or even just using the hashtag #TIBFAQs that I will monitor.
Email: You can send me an email to alexandre.vazquez at gmail.com with your question.
Instagram: You can send me a DM on Instagram at @alexandrev

#TIBFAQS: Failed to read profile from [/tmp/tmp/pcf.substvar]

TIBCO Development FAQs, Solutions & Best Practices

2026-01-162021-01-04 by Alexandre Vazquez

Improve your knowledge about TIBCO technology and also solve the issues that you are facing in your daily development tasks

Table Of Contents

Improve your knowledge about TIBCO technology and also solve the issues that you are facing in your daily development tasks

TIBFAQS is here! This new year I would like to start several initiatives, and I hope you can walk with me during this journey. As you may know, I am a TIBCO Architect, so in my daily activities, I got a lot of questions and inquiries about how to do different things with TIBCO technology from TIBCO BusinessWorks to TIBCO EMS or TIBCO Spotfire.

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

I have noticed that some of these questions are similar from one customer to another, so I would like to use this platform to share all this knowledge to benefit in our daily activities and use the technology most efficiently.

1.- How is this going to work?

I will use some of the common topics that I am aware of in terms of TIBCO development questions and create a periodic article covering it with detail and with a sample application showing the problem and the solution. All the code will be available in my GitHub repository to use for your own reference.

https://github.com/alexandrev

2.- Can I send you my questions?

Yes, sure!! That should be amazing! As I said, I would like to create an engaging community around these posts so we all can benefit from there. So I would like to see your questions and to send them to me you can do it in the following ways:

Twitter: You can send me a mention at @alexandrev on Twitter or a DM or even just using the hashtag #TIBFAQs that I will monitor.
Email: You can send me an email to alexandre.vazquez at gmail.com with your question.
Instagram: You can send me a DM on Instagram at @alexandrev

3.- Where is this going to start?

This will start in late January. The idea is to have at least an article in a bi-weekly periodicity, but that will depend a lot on this initiative’s engagement. The more you share and talk about this initiative to your peers, and the more questions you send to me, the more articles I will create.

4.- What is next?

Since today you can start sending your questions and sharing your feedback about this initiative, and you can follow this blog to wait for the articles to come! Let’s do it together!

Why Visual Diff Is Essential for Low-Code Development and Team Collaboration

2026-01-162020-12-10 by Alexandre Vazquez

Helping you excel using low code in distributed teams and parallel programming

Most enterprises are exploring low-code/no-code development now that the most important thing is to achieve agility on the technology artifacts from different perspectives (development, deployment, and operation).

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

The benefits of this way of working make this almost a no-brainer decision for most companies. We already covered them in a previous article. Take a look if you have not read it yet.

But we know that all new things come with their own challenges that we need to address and master in order to unleash the full benefits that these new paradigms or technologies are providing. Much like with cloud-native architecture, we need to be able to adapt.

Sometimes it is not the culture that we need to change. Sometimes the technology and the tools also need to evolve to address those challenges and help us on that journey. And this is how Visual Diff came into life.

When you develop using a low-code approach, all the development process is easier. You need to combine different blocks that do the logic you need, and everything is simpler than a bunch of code lines.

Example of low-code development — Low-code development approach using TIBCO BusinessWorks.

But we also need to manage all these artifacts in a repository whereby all of them are focused on source code development. That means that when you are working with those tools at the end, you are not working with a “low-code approach” but rather a source code approach. Things like merging different branches and looking to the version history to know the changes are complex.

And they are complex because they are performed by the repository itself, which is focused on the file changes and the source code that changes. But one of the great benefits of low-code development is that the developer doesn’t need to be aware of the source code generated as part of the visual, faster activity. So, how can we solve that? What can we use to solve that?

Low-code technologies need to advance to take the lead here. For example, this is what TIBCO BusinessWorks has done with the release of their Visual Diff capability.

So, you still have your integration with your source code repository. You can do all the processes and activities you usually need to do in this kind of parallel distributed development. Still, you can also see all those activities from a “low-code” perspective.

That means that when I am taking a look at the version history, I can see the visual artifacts that have been modified. The activities added or deleted are shown there in a meaningful way for low-code development. That closes the loop about how low-code developments can take all the advantages of the modern source code repositories and their flows (GitFlow, GitHub Flow, One Flow, etc.) as well as the advantages of the low-code perspective.

Let’s say there are two options with which you can see how an application has been changed. One is the traditional approach and the other uses the Visual Diff:

Same processes but with a Text Comparision approach — Option B: Same processes but with a Text Comparison approach

So, based on this evidence, what do you think is easier to understand? Even if you are a true coder as I am, we cannot deny the ease and benefits of the low-code approach for massive and standard development in the enterprise world.

Summary

No matter how fast we are developing with all the accelerators and frameworks that we have, a well-defined low-code application will be faster than any of us. It is the same battle that we had in the past with the Graphical Interfaces or mouse control versus the keyboard.

We accept that there is a personal preference to choose one or the other, but when we need to decide what is more effective and need to rely on the facts, we cannot be blind to what is in front of us.

I hope you have enjoyed this article. Have a nice day!

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

2026-01-162020-05-01 by Alexandre Vazquez

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:

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:

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!

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:

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

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.

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:

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:

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:

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:

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

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!

Kubernetes Batch Processing with TIBCO BusinessWorks: Jobs, Patterns, and Use Cases

2026-01-162020-04-19 by Alexandre Vazquez

Table Of Contents

Add a header to begin generating the table of contents

We all know that in the rise of the cloud-native development and architectures, we’ve seen Kubernetes based platforms as the new standard all focusing on new developments following the new paradigms and best practices: Microservices, Event-Driven Architectures new shiny protocols like GraphQL or gRPC, and so on and so forth.

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 –>

Prometheus Monitoring in TIBCO Cloud Integration

2022-05-072019-12-19 by Alexandre Vazquez

In previous posts, I’ve explained how to integrate TIBCO BusinessWorks 6.x / BusinessWorks Container Edition (BWCE) applications with Prometheus, one of the most popular monitoring systems for cloud layers. Prometheus is one of the most widely used solutions to monitor your microservices inside a Kubernetes cluster. In this post, I will explain steps to leverage Prometheus for integrating with applications running on TIBCO Cloud Integration (TCI).

TCI is TIBCO’s iPaaS and primarily hides the application management complexity of an app from users. You need your packaged application (a.k.a EAR) and manifest.json — both generated by the product to simply deploy the application.

Isn’t it magical? Yes, it is! As explained in my previous post related to Prometheus integration with BWCE, which allows you to customize your base images, TCI allows integration with Prometheus in a slightly different manner. Let’s walk through the steps.

TCI has its own embedded monitoring tools (shown below) to provide insights into Memory and CPU utilization, plus network throughput, which is very useful.

While the monitoring metrics provided out-of-the-box by TCI are sufficient for most scenarios, there are hybrid connectivity use-cases (application running on-prem and microservices running on your own cluster that could be on a private or public cloud) that might require a unified single-pane view of monitoring.

Step one is to import the Prometheus plugin from the current GitHub location into your BusinessStudio workspace. To do that, you just need to clone the GitHub Repository available here: https://github.com/TIBCOSoftware/bw-tooling OR https://github.com/alexandrev/bw-tooling

Import the Prometheus plugin by choosing Import → Plug-ins and Fragments option and specifying the directory downloaded from the above mentioned GitHub location. (shown below)

Step two involves adding the Prometheus module previously imported to the specific application as shown below:

Step three is just to build the EAR file along with manifest.json.

NOTE: If the EAR doesn’t get generated once you add the Prometheus plugin, please follow the below steps:

Export the project with the Prometheus module to a zip file.
Remove the Prometheus project from the workspace.
Import the project from the zip file generated before.

Before you deploy the BW application on TCI, we need to enable an additional port on TCI to scrape the Prometheus metrics.

Step four Updating manifest.json file.

By default, a TCI app using the manifest.json file only exposes one port to be consumed from outside (related to functional services) and the other to be used internally for health checks.

For Prometheus integration with TCI, we need an additional port listening on 9095, so Prometheus server can access the metrics endpoints to scrape the required metrics for our TCI application.

Note: This document does not cover the details on setting the Prometheus server (it is NOT needed for this PoC) but you can find the relevant information on https://prometheus.io/docs/prometheus/latest/installation/

We need to slightly modify the generated manifest.json file (of BW app) to expose an additional port, 9095 (shown below) .

Also, to tell TCI that we want to enable Prometheus endpoint we need to set a property in the manifest.json file. The property is TCI_BW_CONFIG_OVERRIDES and provide the following value: BW_PROMETHEUS_ENABLE=true, as shown below:

We also need to add an additional line (propertyPrefix) in the manifest.json file as shown below.

Now, we are ready to deploy the BW app on TCI and once it is deployed we can see there are two endpoints

If we expand the Endpoints options on the right (shown above), you can see that one of them is named “prometheus” and that’s our Prometheus metrics endpoint:

Just copy the prometheus URL and append it with /metrics (URL in the below snapshot) — this will display the Prometheus metrics for the specific BW app deployed on TCI.

Note: appending with /metrics is not compulsory, the as-is URL for Prometheus endpoint will also work.

In the list you will find the following kind of metrics to be able to create the most incredible dashboards and analysis based on that kind of information:

JVM metrics around memory used, GC performance and thread pools counts
CPU usage by the application
Process and Activity execution counts by Status (Started, Completed, Failed, Scheduled..)
Duration by Activity and Process.

With all this available the information you can create dashboards similar to the one shown below, in this case using Spotfire as the Dashboard tool:

But you can also integrate those metrics with Grafana or any other tool that could read data from Prometheus time-series database.

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

2026-01-162019-08-26 by Alexandre Vazquez

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.

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:

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…

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:

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.

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:

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:

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:

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:

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)

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