Alexandre Vazquez, Author At Alexandre Vazquez

Welcome to the AsyncAPI Revolution!

2022-10-052020-04-25 by Alexandre Vazquez

We’re living in an age where technologies are switching standards are changing all the time. You forget to read Medium/Stackoverflow/Reddit and you found there are at least five (5) new industry standards that are taking the place of the existing ones that you know (those that have been releasing something like a year ago 🙂 ).

Do you still remember the old ages when SOAP was the unbeatable format? How much time did we spend building our SOAP Services in our enterprises? REST replace it as the new standard.. but just a few years and we’re back in a new battle just for synchronous communication: gRPC, GraphQL, are here to conquer everything again. It is crazy, huh?

But the situation is similar to asynchronous communication. Asynchronous communication has been here for a long time. Even, a long time before the terms Event-Driven Architecture or Streaming was really a “cool” term or a thing you be aware of.

We’ve been using these patterns for so long in our companies. Big enterprises have been using this model into their enterprise integrations for so long. Pub/Sub based protocols and technologies like TIBCO Rendezvous has been using since the late 90, and then we also incorporate more standards approaches like JMS using a different kind of servers to have all these event-based communications.

But now with the cloud-native revolution, the need for distributed computing, more agility, more scalability, centralized solutions are not valid anymore, and we’ve seen an explosion in the number of options to communicate based on these patterns.

You could think that this is the same situation as we were discussing at the beginning of this article regarding REST predominance and new cutting-edge technologies trying to replace it, but this is something quite different. Because experience has told us that a single size doesn’t fit all.

You cannot find a single technology or component that can provide all the communication needs that you need for all your use-cases. You can name any technology or protocol that you want: Kafka, Pulsar, JMS, MQTT, AMQP, Thrift, FTL, and so on.

Think about each of them and you probably will find some use-cases that one technology plays better than the others, so it makes no sense to just trying to find a single technology solution to cover all the needs. What it is needed is more a polyglot approach when you have different technologies that play well together and use the one that works best for your use case (the right tool for the right job approach) as we’re doing for the different technologies we’re deploying in our cluster.

Probably we’re not going to use the same technology to do a Machine Learning based Microservice, than a Streaming Application, right? The same principle applies here.

But the problem here when we try to talk about different technologies playing together is about standardization. If we think about REST, gRPC, or GraphQL even that they’re different they play based some common grounds. They rely on the same base HTTP protocol for a standard so it is easy to support all of them in the same architecture.

But this is not true with the technologies about Asynchronous Communication. And I’d like to focus on standardization and specification today. And that’s what AsyncAPI Initiative is trying to solve. And to define what AsyncAPI is I’d like to use their own words from their official website:

AsyncAPI is an open source initiative that seeks to improve the current state of Event-Driven Architectures (EDA). Our long-term goal is to make working with EDA’s as easy as it is to work with REST APIs. That goes from documentation to code generation, from discovery to event management. Most of the processes you apply to your REST APIs nowadays would be applicable to your event-driven/asynchronous APIs too.

So, their goal is to provide a set of tools to have a better world in all those EDA architectures that all companies have or starting to have at this moment and everything pivots around one thing: The OpenAPI Specification.

Similar to the OpenAPI specification it allows us to define a common interface for our EDA Interfaces and the most important part is that this is multi-channel. So the same specification can be used for your MQTT-based API or your Kafka API. Let’s take a look at how it looks like this AsyncAPI Specification:

As you can see it is very similar to the OpenAPI 3.0 and they already done that with the purpose to ease the transition between OpenAPI 3.0 and AsyncAPI and also to try to join both worlds together: It is more about just API, no matter if they’re synchronous or asynchronous and provide the same benefits regarding the ecosystem from one to the other.

Show me the code!!

But let’s stop talking and let’s start coding and to do that I’d like to use one of the tools that in my view has the greater support for AsyncAPI, and that’s it Project Flogo.

Probably you remember some of the different posts I’ve been done regarding Project Flogo and TIBCO Flogo Enterprise as a great technology to use for your microservices development (low-code/all-code approach, Golang based, a lot of connectors and open source extensions as well).

But today we’re going to use it to create our first AsyncAPI compliant microservice. And we’re going to rely on that because it provides a set of extensions to support the AsyncAPI initiative as you can see here:

GitHub – project-flogo/asyncapi: Flogo extensions to support AsyncAPI

Flogo extensions to support AsyncAPI. Contribute to project-flogo/asyncapi development by creating an account on GitHub.

So the first thing that we’re going to do is to create our AsyncAPI definition and to do it simpler, we’re going to use the sample one that we have available in the OpenAsync API with a simple change: We’re going to change from AMQP protocol to Kafka protocol because this is cool these days, isn’t it? 😉

asyncapi: '2.0.0'
info:
  title: Hello world application
  version: '0.1.0'
servers:
  production:
    url: broker.mycompany.com
    protocol: kafka
    description: This is "My Company" broker.
    security:
      - user-password: []
channels:
  hello:
    publish:
      message:
        $ref: '#/components/messages/hello-msg'
  goodbye:
    publish:
      message:
        $ref: '#/components/messages/goodbye-msg'
components:
  messages:
    hello-msg:
      payload:
        type: object
        properties:
          name:
            type: string
          sentAt:
            $ref: '#/components/schemas/sent-at'
    goodbye-msg:
      payload:
        type: object
        properties:
          sentAt:
            $ref: '#/components/schemas/sent-at'
  schemas:
    sent-at:
      type: string
      description: The date and time a message was sent.
      format: datetime
  securitySchemes:
    user-password:
      type: userPassword

As you can see something simple. Two operations “hello” and “goodbye” with easy payload:

name: Name that we’re going to use for the greeting.
sentAt: The date and time a message was sent.

So the first thing we’re going to do is to create a Flogo Application that complies to that AsyncAPI specification:

git clone https://github.com/project-flogo/asyncapi.git
cd asyncapi/
go install

Now we have the generator installer so we only need to execute and provide our YML as the input in the following command:

asyncapi -input helloworld.yml -type flogodescriptor

And we will create a HelloWorld application for us, that we need to tweak a little bit. Only to make you be up & running quickly, I’m just sharing the code in my GitHub repository that you can borrow from them (But I really encourage you to take the time to take a look at the code to see the beauty of the Flogo App Development 🙂 )

https://github.com/project-flogo/asyncapi

Now, that we already have the app, we have just a simple dummy application that allows us to receive the message that complies with the specification, and in our case just log the payload, which can be our starting point to build our new Event-Driven Microservices compliant with AsyncAPI.

So, let’s try it but to do so, we need a few things. First of all, we need a Kafka server running and to do that in a quick way we’re going to leverage on the following docker-compose.yml file:

version: '2'

services:

  zookeeper:

    image: wurstmeister/zookeeper:3.4.6

    expose:

    - "2181"

  kafka:

    image: wurstmeister/kafka:2.11-2.0.0

    depends_on:

    - zookeeper

    ports:

    - "9092:9092"

    environment:

      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092

      KAFKA_LISTENERS: PLAINTEXT://0.0.0.0:9092

      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181

And to run that we just need to fire the following command from the same folder we have this file named as docker-compose.yml:

docker-compose up -d

And after doing that, we just need a sample application and what better that use Flogo again to create it but this time, let’s use the Graphical Viewer to create it right away:

So we need just to configure the Publish Kafka activity to provide the broker (localhost:9092), the topic (hello) and the message :

"name": "hello world",

"sentAt": "2020-04-24T00:00:00"

And that’s it! Let’s run it!!!:

First we start the AsyncAPI Flogo Microservice:

And then we just launch the tester, that is going to send the same message each minute, as you can see in the picture below:

And each time we sent that message, is going to be received in our Async API Flogo Microservice:

So, I hope this first introduction to the AsyncAPI world has been of the interest of you, but don’t forget to take a look at more resources in their own website:

GitHub – project-flogo/asyncapi: Flogo extensions to support AsyncAPI

Flogo extensions to support AsyncAPI. Contribute to project-flogo/asyncapi development by creating an account on GitHub.

GitHub – alexandrev/asyncapi-flogo-test: This is the material that supports the post on Medium regarding “Welcome to the AsyncAPI Revoluton” and provide the flogo code needed to run the same sample that is being shown in the article

This is the material that supports the post on Medium regarding "Welcome to the AsyncAPI Revoluton" and provide the flogo code needed to run the same sample that is being shown in the art…

Kubernetes Batch Processing using TIBCO BW

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

Table Of Contents

Batch Managed by TIBCO
Cron-Job Kubernetes API
Pros and Cons of each approach

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

But we should be aware that most of the enterprises that are today adopting these technologies are not green-field opportunities. They have a lot of systems already running that all new developments in the new cloud-native architectures need to interact so the rules become more complex and there are a lot of shades of gray when we’re creating our Kubernetes application.

And based on my experience when we are talking with the customer is the new cloud architecture most of them bring the batch pattern here. They know this is not a best practice anymore, that they cannot continue to build their systems in a batch fashion trying to do by night what were should be doing in real-time. But, most of the time they need to co-exist with the systems they already have and could be needed this kind of procedure. So we need to find a way to provide Kubernetes Batch Processing.

Also for customers that already have their existing applications using that pattern and they like to move to the new world is better for them that they can do it without needing to re-architect their existing application. Something that probably they will end up doing but at their own pace.

Batch processing patterns in TIBCO development is a quite used pattern and we have customers all over the world with this kind of development used in production for many years. You know, this kind of process that is executed at a specific moment in time (weekly on Monday, each day at 3 PM .. or just each hour to do some regular job).

It’s a straightforward pattern here. Simply add a timer that you can configure when it will be launched and add your logic. That’s it. As simple as that:

But, how this can be translated into a Kubernetes approach? How we can create applications that work with this pattern and still be managed by our platform? So, fortunately, this is something that can be done, and you have also different ways of doing it depending on what you want to achieve.

Mainly today we are going to describe two ways to be able to do that and try to explain the main differences between one and the other so you can know which one you should use depending on your use case. Those two methods I’m going to call it this way: Batch managed by TIBCO Kubernetes and Cron Job API approach

Batch Managed by TIBCO

This is the simplest one. It is exactly the same approach you have in your existing on-premises BusinessWorks application just deployed into the Kubernetes cluster.

So, you don’t need to change anything in your logic you only will have an application that is started by a Timer with their configuration regarding the scheduling inside the scope of the BusinessWorks application and that’s it.

You only need to provide the artifacts needed to deploy your application into Kubernetes like any other TIBCO BusinessWorks app and that’s it. That means that you’re creating a Deployment to launch this component and you will always have a running pod evaluating when the condition is true to launch the process as you have in your on-premises approach.

Cron-Job Kubernetes API

The batch processing pattern is something that is already covered out of the box by the Kubernetes API and that’s why we have the Cron-Job concept. You probably remind the Cron Jobs that we have in our Linux machines. If you’re a developer or a system administrator I’m sure you’ve played with these cronjobs to schedule tasks or commands to be executed at a certain time. If you’re a Windows-based person, this is the Linux equivalent of your Windows Task Scheduler Jobs. Same approach.

And this is very simple, you only need to create a new artifact using this Cron Job API that mainly says the job to execute and the schedule of that job similar of what we’ve done in the past with the cronjob in our Linux machine:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

The jobs that we can use here should be compliant with a single rule that also applied in the Unix cron jobs as well: The command should end when the job is done.

And this is something that is critical, which means that our container should exit when the job is done to be able to be used inside this approach. That means that we cannot use a “server approach” as we’re doing in the previous approach because in that case, the pod is never-ending. Does that mean that I cannot use a TIBCO BusinessWorks application as part of a Kubernetes Cron Job? Absolutely Not! Let’s see how you can do it.

So, we should focus on two things, the business logic should be able to run as soon as the process start and the container should end as soon as the job is done. Let’s start with the first one.

The first one is easy. Let’s use our previous sample: Simple batch approach that writes a log trace each minute. We need to make it start as soon as the process started but this is pretty Out of the box (OOTB) with TIBCO BusinessWorks we only need to configure that timer to run only once and that’s going to start as soon as the application is running:

So, we already have the first requirement fixed, let’s see with the other one.

We should be able to end the container completely as the process ends and that’s challenging because BusinessWorks application doesn’t behave that way. They’re supposed to be always running. But this also can be sorted.

The only thing that we need is to make use of command at the end of the flow. It’s like an exit command in our shell script or Java code to end the process and the container. To do that, we should add an “Execute External Command” Activity and simply configure it to send a signal to the BusinessWorks process running inside the container.

The signal that we’re going to send is SIGINT that is the similar one that we send when we press CTRL+C in a Terminal to require the process to stop. We’re are going to do the same. To do that we’re going to use the command kill that is shipped in all Unix machines and most of the docker base images as well. And the command kill requires two arguments:

kill -s <SIGNAL_NAME> <PID>

SIGNAL_NAME: We already cover that part and we’re going to use the Singal named SIGINT.
PID: Regarding the PID we need to provide the PID of the BusinessWorks process running inside container.

The part of finding the PID for that process running BusinessWorks inside the container can be difficult to locate but if you see the running processes inside a BusinessWorks container you can see that this is not so complicated to find:

If we enter inside a running container of a BusinessWorks application we will check that this PID is always the number 1. So we already have everything ready to configure the activity as it is shown below:

And that’s it with these two changes we are able to deploy this using the CronJob API and use it as part of your toolset of application patterns.

Pros and Cons of each approach

As you can imagine there is not a single solution about when to use one of the other because it is going to depend on your use case and your requirements. So I’ll try to enumerate here the main differences between both approaches so you can choose better when it is on your hand:

TIBCO Managed approach is faster because the pod is already running and as soon as the condition is met the logic started. Using the Cron Job API requires a warm-up period because the pod starts when the condition is met so some delay can be applied here.
TIBCO Managed approach requires the pod to be running all the time so it uses more resources when the condition is not reached. So in case you’re running stateless containers like AWS Fargate or similar Cron JOB API is a better fit.
CronJob API is a standard Kubernetes API that means that integrated completely with the ecosystem, rather TIBCO Managed is managed by TIBCO using application configuration settings.
TIBCO Managed approach is not aware of other instances of the same application running so you managed to keep a single instance running to avoid running the same logic many times. In the case of the Cron Job API, this is managed by the Kubernetes platform itself.

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 Flogo App on OpenFaaS

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

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.

[visual-link-preview encoded=”eyJ0eXBlIjoiZXh0ZXJuYWwiLCJwb3N0IjowLCJwb3N0X2xhYmVsIjoiIiwidXJsIjoiaHR0cHM6Ly9naXRodWIuY29tL29wZW5mYWFzL2ZhYXMiLCJpbWFnZV9pZCI6LTEsImltYWdlX3VybCI6Imh0dHBzOi8vb3BlbmdyYXBoLmdpdGh1YmFzc2V0cy5jb20vOWQzNTgwNDQyZjhlODA2ZjdiYTAwZmVlZDg3ZDRkNWY3ODY2OWZjMzZjY2IwMjVhODhlMDNmYTZiY2RlODNmNi9vcGVuZmFhcy9mYWFzIiwidGl0bGUiOiJHaXRIdWIgLSBvcGVuZmFhcy9mYWFzOiBPcGVuRmFhUyAtIFNlcnZlcmxlc3MgRnVuY3Rpb25zIE1hZGUgU2ltcGxlIiwic3VtbWFyeSI6Ik9wZW5GYWFTIC0gU2VydmVybGVzcyBGdW5jdGlvbnMgTWFkZSBTaW1wbGUuIENvbnRyaWJ1dGUgdG8gb3BlbmZhYXMvZmFhcyBkZXZlbG9wbWVudCBieSBjcmVhdGluZyBhbiBhY2NvdW50IG9uIEdpdEh1Yi4iLCJ0ZW1wbGF0ZSI6InVzZV9kZWZhdWx0X2Zyb21fc2V0dGluZ3MifQ==”]

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:

[visual-link-preview encoded=”eyJ0eXBlIjoiZXh0ZXJuYWwiLCJwb3N0IjowLCJwb3N0X2xhYmVsIjoiIiwidXJsIjoiaHR0cHM6Ly9zaGFsaXRoYXN1cmFuZ2EubWVkaXVtLmNvbS9ydW5uaW5nLXNlcnZlcmxlc3MtZnVuY3Rpb25zLW9uLXByZW1pc2VzLXVzaW5nLW9wZW5mYWFzLXdpdGgta3ViZXJuZXRlcy02YzdhNjVhZWRiNWIiLCJpbWFnZV9pZCI6LTEsImltYWdlX3VybCI6Imh0dHBzOi8vbWlyby5tZWRpdW0uY29tL21heC8xMjAwLzAqUFlnTUltMm1fQnJLbUd5VCIsInRpdGxlIjoiUnVubmluZyBzZXJ2ZXJsZXNzIGZ1bmN0aW9ucyBvbiBwcmVtaXNlcyB1c2luZyBPcGVuRmFhcyB3aXRoIEt1YmVybmV0ZXMiLCJzdW1tYXJ5IjoiRWFybGllciBtb3N0IG9mIGNvbXBhbmllcyBoYWQgbW9ub2xpdGhpYyBhcmNoaXRlY3R1cmUgZm9yIHRoZWlyIGNsb3VkIGFwcGxpY2F0aW9ucyAoYWxsIHRoZSB0aGluZ3MgaW4gYSBzaW5nbGUgcGFja2FnZSkuIE5vd2FkYXlzIGNvbXBhbmllc+KApiIsInRlbXBsYXRlIjoidXNlX2RlZmF1bHRfZnJvbV9zZXR0aW5ncyJ9″]

[visual-link-preview encoded=”eyJ0eXBlIjoiZXh0ZXJuYWwiLCJwb3N0IjowLCJwb3N0X2xhYmVsIjoiIiwidXJsIjoiaHR0cHM6Ly9oYWNrZXJub29uLmNvbS9hbi1pbnRyb2R1Y3Rpb24tdG8tc2VydmVybGVzcy1kZXZvcHMtd2l0aC1vcGVuZmFhcy1iOTc4YWIwZWIyYiIsImltYWdlX2lkIjotMSwiaW1hZ2VfdXJsIjoiaHR0cHM6Ly9jZG4uaGFja2Vybm9vbi5jb20vaG4taW1hZ2VzLzEqZEczQnZqU0gwYmFWUXVPV2JHR0hPZy5wbmciLCJ0aXRsZSI6IkFuIEludHJvZHVjdGlvbiB0byBTZXJ2ZXJsZXNzIERldk9wcyB3aXRoIE9wZW5GYWFTIHwgSGFja2VyTm9vbiIsInN1bW1hcnkiOiJEZXZPcHMgaXNu4oCZdCBhYm91dCBqdXN0IGRvaW5nIENJL0NELiBCdXQgYSBDSS9DRCBwaXBlbGluZSBoYXMgYW4gaW1wb3J0YW50IHJvbGUgaW5zaWRlIERldk9wcy4gSeKAmXZlIGJlZW4gaW52ZXN0aW5nIG15IHRpbWUgb24gcmVjZW50bHkgYW5kIGFzIEkgc3RhcnRlZCBjcmVhdGluZyBtdWx0aXBsZSBmdW5jdGlvbnMsIEkgd2FudGVkIGFuIGVhc3kgdG8gdXNlIGFuZCBhY2Nlc3NpYmxlIGRldmVsb3BtZW50IGFuZCBkZWxpdmVyeSBmbG93LCBpbiBvdGhlciB3b3JkcyBhIENJL0NEIHBpcGVsaW5lLiBPcGVuRmFhUyBPbmUgZGF54oCmIiwidGVtcGxhdGUiOiJ1c2VfZGVmYXVsdF9mcm9tX3NldHRpbmdzIn0=”]

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:

[visual-link-preview encoded=”eyJ0eXBlIjoiZXh0ZXJuYWwiLCJwb3N0IjowLCJwb3N0X2xhYmVsIjoiIiwidXJsIjoiaHR0cHM6Ly9naXRodWIuY29tL29wZW5mYWFzL29mLXdhdGNoZG9nIiwiaW1hZ2VfaWQiOi0xLCJpbWFnZV91cmwiOiJodHRwczovL29wZW5ncmFwaC5naXRodWJhc3NldHMuY29tLzcyZjgyODQxNWI1ZjVlYjJkMDY2ODRjMjIwMDNhYWZiMDliMDFjNjE2OWFhODMxOTJiOGFmZTljZjQzNThjNmMvb3BlbmZhYXMvb2Ytd2F0Y2hkb2ciLCJ0aXRsZSI6IkdpdEh1YiAtIG9wZW5mYWFzL29mLXdhdGNoZG9nOiBSZXZlcnNlIHByb3h5IGZvciBTVERJTyBhbmQgSFRUUCBtaWNyb3NlcnZpY2VzIiwic3VtbWFyeSI6IlJldmVyc2UgcHJveHkgZm9yIFNURElPIGFuZCBIVFRQIG1pY3Jvc2VydmljZXMuIENvbnRyaWJ1dGUgdG8gb3BlbmZhYXMvb2Ytd2F0Y2hkb2cgZGV2ZWxvcG1lbnQgYnkgY3JlYXRpbmcgYW4gYWNjb3VudCBvbiBHaXRIdWIuIiwidGVtcGxhdGUiOiJ1c2VfZGVmYXVsdF9mcm9tX3NldHRpbmdzIn0=”]

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:

[visual-link-preview encoded=”eyJ0eXBlIjoiZXh0ZXJuYWwiLCJwb3N0IjowLCJwb3N0X2xhYmVsIjoiIiwidXJsIjoiaHR0cHM6Ly9hd3MuYW1hem9uLmNvbS9ibG9ncy9vcGVuc291cmNlL2RlcGxveS1vcGVuZmFhcy1hd3MtZWtzLyIsImltYWdlX2lkIjotMSwiaW1hZ2VfdXJsIjoiaHR0cHM6Ly9kMjkwOHEwMXZvbXFiMi5jbG91ZGZyb250Lm5ldC9jYTM1MTJmNGRmYTk1YTAzMTY5YzVhNjcwYTRjOTFhMTliMzA3N2I0LzIwMTgvMDkvMTIvb3BlbmZhYXMtZWtzLmpwZyIsInRpdGxlIjoiRGVwbG95IE9wZW5GYWFTIG9uIEFtYXpvbiBFS1MgfCBBbWF6b24gV2ViIFNlcnZpY2VzIiwic3VtbWFyeSI6Ildl4oCZdmUgdGFsa2VkIGFib3V0IEZhYVMgKEZ1bmN0aW9ucyBhcyBhIFNlcnZpY2UpIGluIFJ1bm5pbmcgRmFhUyBvbiBhIEt1YmVybmV0ZXMgQ2x1c3RlciBvbiBBV1MgVXNpbmcgS3ViZWxlc3MgYnkgU2ViYXN0aWVuIEdvYXNndWVuLiBJbiB0aGlzIHBvc3QsIEFsZXggRWxsaXMsIGZvdW5kZXIgb2YgdGhlIE9wZW5GYWFTIHByb2plY3QsIHdhbGtzIHlvdSB0aHJvdWdoIGhvdyB0byB1c2UgT3BlbkZhYVMgb24gQW1hem9uIEVLUy4gT3BlbkZhYVMgaXMgb25lIG9mIHRoZSBtb3N0IHBvcHVsYXIgdG9vbHMgaW4gdGhlIEZhYVPigKYiLCJ0ZW1wbGF0ZSI6InVzZV9kZWZhdWx0X2Zyb21fc2V0dGluZ3MifQ==”]

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)

[visual-link-preview encoded=”eyJ0eXBlIjoiZXh0ZXJuYWwiLCJwb3N0IjowLCJwb3N0X2xhYmVsIjoiIiwidXJsIjoiaHR0cHM6Ly9naXRodWIuY29tL2FsZXhhbmRyZXYvZmxvZ28tb3BlbmZhYXMtbWVkaXVtIiwiaW1hZ2VfaWQiOi0xLCJpbWFnZV91cmwiOiJodHRwczovL29wZW5ncmFwaC5naXRodWJhc3NldHMuY29tLzI1MjI1N2FhYTNjNmUxYzVkY2QxNTJlMzQyMDJkZWQzNzcyMzQ4OGFmM2Y5MDk4NjU1Yjk2NGUzZjBlZDZlYmYvYWxleGFuZHJldi9mbG9nby1vcGVuZmFhcy1tZWRpdW0iLCJ0aXRsZSI6IkdpdEh1YiAtIGFsZXhhbmRyZXYvZmxvZ28tb3BlbmZhYXMtbWVkaXVtOiBFeGFtcGxlIEZsb2dvIEFwcGxpY2F0aW9uIGZvciBEZXBsb3lpbmcgb24gT3BlbkZhYVMiLCJzdW1tYXJ5IjoiRXhhbXBsZSBGbG9nbyBBcHBsaWNhdGlvbiBmb3IgRGVwbG95aW5nIG9uIE9wZW5GYWFTIC0gR2l0SHViIC0gYWxleGFuZHJldi9mbG9nby1vcGVuZmFhcy1tZWRpdW06IEV4YW1wbGUgRmxvZ28gQXBwbGljYXRpb24gZm9yIERlcGxveWluZyBvbiBPcGVuRmFhUyIsInRlbXBsYXRlIjoidXNlX2RlZmF1bHRfZnJvbV9zZXR0aW5ncyJ9″]

Using Statistics in your favor to detect bottlenecks in TIBCO BusinessWorks Container Edition

2026-01-152019-08-12 by Alexandre Vazquez

Usually, when you’re developing or running your container application you will get to a moment when something goes wrong. But not in a way you can solve with your logging system and with testing.

A moment when there is some bottleneck, something that is not performing as well as you want, and you’d like to take a look inside. And that’s what we’re going to do. We’re going to watch inside.

Because our BusinessWorks Container Edition provides so great features to do it that you need to use it into your favor because you’re going to thank me for the rest of your life. So, I don’t want to spend one more minute about this. I’d like to start telling you right now.

The first thing we need to do, we need to go inside the OSGi console from the container. So, the first thing we do is to expose the 8090 port as you can see in the picture below

Now, we can expose that port to your host, using the port-forward command

kubectl port-forward deploy/phenix-test-project-v1 8090:8090

And then we can execute an HTTP Request to execute any info using commands like this:

curl -v http://localhost:8090/bw/framework.json/osgi?command=<command>

And we’re are going to execute first the activation of the process statistics like this:

curl -v http://localhost:8090/bw/framework.json/osgi?command=startpsc

And as you can see it says that statistics has been enabled for echo application, so using that application name we’re going to gather the statistics at the level

curl -v http://localhost:8090/bw/framework.json/osgi?command=lpis%20echo

And you can see the statistics at the process level where you can see the following metrics:

Process metadata (name, parent process and version)
Total instance by status (create, suspended, failed and executed)
Execution time (total, average, min, max, most recent)
Elapsed time (total, average, min, max, most recent)

And we can get the statistics at the activity level:

And with that, you can detect any bottleneck you’re facing into your application and also be sure which activity or which process is responsible for it. So you can solve it in a quick way.

Have fun and use the tools at your disposal!

Kubernetes Service Discovery for Prometheus

2026-01-142019-08-05 by Alexandre Vazquez

In previous posts, we described how to set up Prometheus to work with your TIBCO BusinessWorks Container Edition apps, and you can read more about it here. [visual-link-preview encoded=”eyJ0eXBlIjoiaW50ZXJuYWwiLCJwb3N0IjoxMTEsInBvc3RfbGFiZWwiOiJQb3N0IDExMSAtIFByb21ldGhldXMgTW9uaXRvcmluZyBmb3IgTWljcm9zZXJ2aWNlcyB1c2luZyBUSUJDTyIsInVybCI6IiIsImltYWdlX2lkIjoyNjI4LCJpbWFnZV91cmwiOiJodHRwOi8vYWxleGFuZHJlLXZhenF1ZXouY29tL3dwLWNvbnRlbnQvdXBsb2Fkcy8yMDIyLzAxLzEtNmIyS25hQWNtME9TSVpySFJwcFRnLnBuZyIsInRpdGxlIjoiUHJvbWV0aGV1cyBNb25pdG9yaW5nIGZvciBNaWNyb3NlcnZpY2VzIHVzaW5nIFRJQkNPIiwic3VtbWFyeSI6Ildl4oCZcmUgbGl2aW5nIGEgd29ybGQgd2l0aCBjb25zdGFudCBjaGFuZ2VzIGFuZCB0aGlzIGlzIGV2ZW4gbW9yZSB0cnVlIGluIHRoZSBFbnRlcnByaXNlIEFwcGxpY2F0aW9uIHdvcmxkLiBJ4oCZbGwgbm90IHNwZW5kIG11Y2ggdGltZSB0YWxraW5nIGFib3V0IHRoaW5ncyB5b3UgYWxyZWFkeSBrbm93LCBidXQganVzdCBzYXkgdGhhdCB0aGUgbWljcm9zZXJ2aWNlcyBhcmNoaXRlY3R1cmUgYXBwcm9hY2ggYW5kIHRoZSBQYWFTIHNvbHV0aW9ucyBoYXZlIGJlZW4gYSBnYW1lLWNoYW5nZXIgZm9yIGFsbCBlbnRlcnByaXNlIGludGVncmF0aW9uIHRlY2hub2xvZ2llcy4gVGhpcyB0aW1lIEnigJlkIGxpa2UgdG8gWyZoZWxsaXA7XSIsInRlbXBsYXRlIjoidXNlX2RlZmF1bHRfZnJvbV9zZXR0aW5ncyJ9″] In that post, we described that there were several ways to update Prometheus about the services that ready to monitor. And we choose the most simple at that moment that was the static_config configuration which means:

Don’t worry Prometheus, I’ll let you know the IP you need to monitor and you don’t need to worry about anything else.

And this is useful for a quick test in a local environment when you want to test quickly your Prometheus set up or you want to work in the Grafana part to design the best possible dashboard to handle your need. But, this is not too useful for a real production environment, even more, when we’re talking about a Kubernetes cluster when services are going up & down continuously over time. So, to solve this situation Prometheus allows us to define a different kind of ways to perform this “service discovery” approach. In the official documentation for Prometheus, we can read a lot about the different service discovery techniques but at a high level these are the main service discovery techniques available: [visual-link-preview encoded=”eyJ0eXBlIjoiZXh0ZXJuYWwiLCJwb3N0IjowLCJwb3N0X2xhYmVsIjoiIiwidXJsIjoiaHR0cHM6Ly9wcm9tZXRoZXVzLmlvL2RvY3MvcHJvbWV0aGV1cy9sYXRlc3QvY29uZmlndXJhdGlvbi9jb25maWd1cmF0aW9uLyIsImltYWdlX2lkIjotMSwiaW1hZ2VfdXJsIjoiaHR0cHM6Ly9wcm9tZXRoZXVzLmlvL2Fzc2V0cy9mYXZpY29ucy9hbmRyb2lkLWNocm9tZS0xOTJ4MTkyLnBuZyIsInRpdGxlIjoiQ29uZmlndXJhdGlvbiB8IFByb21ldGhldXMiLCJzdW1tYXJ5IjoiQW4gb3Blbi1zb3VyY2UgbW9uaXRvcmluZyBzeXN0ZW0gd2l0aCBhIGRpbWVuc2lvbmFsIGRhdGEgbW9kZWwsIGZsZXhpYmxlIHF1ZXJ5IGxhbmd1YWdlLCBlZmZpY2llbnQgdGltZSBzZXJpZXMgZGF0YWJhc2UgYW5kIG1vZGVybiBhbGVydGluZyBhcHByb2FjaC4iLCJ0ZW1wbGF0ZSI6InVzZV9kZWZhdWx0X2Zyb21fc2V0dGluZ3MifQ==”]

azure_sd_configs: Azure Service Discovery
consul_sd_configs: Consul Service Discovery
dns_sd_configs: DNS Service Discovery
ec2_sd_configs: EC2 Service Discovery
openstack_sd_configs: OpenStack Service Discovery
file_sd_configs: File Service Discovery
gce_sd_configs: GCE Service Discovery
kubernetes_sd_configs: Kubernetes Service Discovery
marathon_sd_configs: Marathon Service Discovery
nerve_sd_configs: AirBnB’s Nerve Service Discovery
serverset_sd_configs: Zookeeper Serverset Service Discovery
triton_sd_configs: Triton Service Discovery
static_config: Static IP/DNS for the configuration. No Service Discovery.

And even, it all these options are not enough for you and need something more specific you have an API available to extend the Prometheus capabilities and create your own Service Discovery technique. You can find more info about it here: [visual-link-preview encoded=”eyJ0eXBlIjoiZXh0ZXJuYWwiLCJwb3N0IjowLCJwb3N0X2xhYmVsIjoiIiwidXJsIjoiaHR0cHM6Ly9wcm9tZXRoZXVzLmlvL2Jsb2cvMjAxOC8wNy8wNS9pbXBsZW1lbnRpbmctY3VzdG9tLXNkLyIsImltYWdlX2lkIjotMSwiaW1hZ2VfdXJsIjoiaHR0cHM6Ly9wcm9tZXRoZXVzLmlvL2Fzc2V0cy9mYXZpY29ucy9hbmRyb2lkLWNocm9tZS0xOTJ4MTkyLnBuZyIsInRpdGxlIjoiSW1wbGVtZW50aW5nIEN1c3RvbSBTZXJ2aWNlIERpc2NvdmVyeSB8IFByb21ldGhldXMiLCJzdW1tYXJ5IjoiQW4gb3Blbi1zb3VyY2UgbW9uaXRvcmluZyBzeXN0ZW0gd2l0aCBhIGRpbWVuc2lvbmFsIGRhdGEgbW9kZWwsIGZsZXhpYmxlIHF1ZXJ5IGxhbmd1YWdlLCBlZmZpY2llbnQgdGltZSBzZXJpZXMgZGF0YWJhc2UgYW5kIG1vZGVybiBhbGVydGluZyBhcHByb2FjaC4iLCJ0ZW1wbGF0ZSI6InVzZV9kZWZhdWx0X2Zyb21fc2V0dGluZ3MifQ==”] But this is not our case, for us, the Kubernetes Service Discovery is the right choice for our approach. So, we’re going to change the static configuration we had in the previous post:

- job_name: 'bwdockermonitoring'
  honor_labels: true
  static_configs:
    - targets: ['phenix-test-project-svc.default.svc.cluster.local:9095']
      labels:
        group: 'prod'

For this Kubernetes configuration

- job_name: 'bwce-metrics'
  scrape_interval: 5s
  metrics_path: /metrics/
  scheme: http
  kubernetes_sd_configs:
  - role: endpoints
    namespaces:
      names:
      - default
  relabel_configs:
  - source_labels: [__meta_kubernetes_service_label_app]
    separator: ;
    regex: (.*)
    replacement: $1
    action: keep
  - source_labels: [__meta_kubernetes_endpoint_port_name]
    separator: ;
    regex: prom
    replacement: $1
    action: keep
  - source_labels: [__meta_kubernetes_namespace]
    separator: ;
    regex: (.*)
    target_label: namespace
    replacement: $1
    action: replace
  - source_labels: [__meta_kubernetes_pod_name]
    separator: ;
    regex: (.*)
    target_label: pod
    replacement: $1
    action: replace
  - source_labels: [__meta_kubernetes_service_name]
    separator: ;
    regex: (.*)
    target_label: service
    replacement: $1
    action: replace
  - source_labels: [__meta_kubernetes_service_name]
    separator: ;
    regex: (.*)
    target_label: job
    replacement: 1
    action: replace
  - separator: ;
    regex: (.*)
    target_label: endpoint
    replacement: $1
    action: replace

As you can see this is quite more complex than the previous configuration but it is not as complex as you can think at first glance, let’s review it by different parts.

- role: endpoints
    namespaces:
      names:
      - default

It says that we’re going to use role for endpoints that are created under the default namespace and we’re going to specify the changes we need to do to find the metrics endpoints for Prometheus.

scrape_interval: 5s
 metrics_path: /metrics/
 scheme: http

This says that we’re going to execute the scrape process in a 5 seconds interval, using http on the path /metrics/ And then, we have a relabel_config section:

- source_labels: [__meta_kubernetes_service_label_app]
    separator: ;
    regex: (.*)
    replacement: $1
    action: keep
  - source_labels: [__meta_kubernetes_endpoint_port_name]
    separator: ;
    regex: prom
    replacement: $1
    action: keep

That means that we’d like to keep that label for prometheus:

- source_labels: [__meta_kubernetes_namespace]
    separator: ;
    regex: (.*)
    target_label: namespace
    replacement: $1
    action: replace
  - source_labels: [__meta_kubernetes_pod_name]
    separator: ;
    regex: (.*)
    target_label: pod
    replacement: $1
    action: replace
  - source_labels: [__meta_kubernetes_service_name]
    separator: ;
    regex: (.*)
    target_label: service
    replacement: $1
    action: replace
  - source_labels: [__meta_kubernetes_service_name]
    separator: ;
    regex: (.*)
    target_label: job
    replacement: 1
    action: replace
  - separator: ;
    regex: (.*)
    target_label: endpoint
    replacement: $1
    action: replace

That means that we want to do a replace of the label value and we can do several things:

Rename the label name using the target_label to set the name of the final label that we’re going to create based on the source_labels.
Replace the value using the regex parameter to define the regular expression for the original value and the replacement parameter that is going to express the changes that we want to do to this value.

So, now after applying this configuration when we deploy a new application in our Kubernetes cluster, like the project that we can see here: Automatically we’re going to see an additional target on our job-name configuration “bwce-metrics”

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.

Flogo Configuration: How To Master It In 5 Minutes?

2026-01-152019-07-29 by Alexandre Vazquez

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.

Prometheus TIBCO Monitoring for Containers: Quick and Simple in 5 Minutes!

2026-01-152019-07-22 by Alexandre Vazquez

Prometheus is becoming the new standard for Kubernetes monitoring and today we are going to cover how we can do Prometheus TIBCO monitoring in Kubernetes.

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

We’re living in a world with constant changes and this is even more true in the Enterprise Application world. I’ll not spend much time talking about things you already know, but just say that the microservices architecture approach and the PaaS solutions have been a game-changer for all enterprise integration technologies.

This time I’d like to talk about monitoring and the integration capabilities we have of using Prometheus to monitor our microservices developed under TIBCO technology. I don’t like to spend too much time either talking about what Prometheus is, as you probably already know, but in a summary, this is an open-source distributed monitoring platform that has been the second project released by the Cloud Native Computing Foundation (after Kubernetes itself) and that has been established as a de-facto industry standard for monitoring K8S clusters (alongside with other options in the market like InfluxDB and so on).

Prometheus has a lot of great features, but one of them is that it has connectors for almost everything and that’s very important today because it is so complicated/unwanted/unusual to define a platform with a single product for the PaaS layer. So today, I want to show you how to monitor your TIBCO BusinessWorks Container Edition applications using Prometheus.

Most of the info I’m going to share is available in the bw-tooling GitHub repo, so you can get to there if you need to validate any specific statement.

bw-tooling/prometheus-integration at master · TIBCOSoftware/bw-tooling

Collection of tools designed to simplify deployment and management of TIBCO BusinessWorks applications – bw-tooling/prometheus-integration at master · TIBCOSoftware/bw-tooling

Ok, are we ready? Let’s start!!

I’m going to assume that we already have a Kubernetes cluster in place and Prometheus installed as well. So, the first step is to enhance the BusinessWorks Container Edition base image to include the Prometheus capabilities integration. To do that we need to go to the GitHub repo page and follow these instructions:

Download & unzip the prometheus-integration.zip folder.

Open TIBCO BusinessWorks Studio and point it to a new workspace.
Right-click in Project Explorer → Import… → select Plug-ins and Fragments → select Import from the directory radio button

Browse it to prometheus-integration folder (unzipped in step 1)

Now click Next → Select Prometheus plugin → click Add button → click Finish. This will import the plugin in the studio.

Now, to create JAR of this plugin so first, we need to make sure to update com.tibco.bw.prometheus.monitor with ‘.’ (dot) in Bundle-Classpath field as given below in META-INF/MANIFEST.MF file.

Right-click on Plugin → Export → Export…

Select type as JAR file click Next

Now Click Next → Next → select radio button to use existing MANIFEST.MF file and browse the manifest file

Click Finish. This will generate prometheus-integration.jar

Now, with the JAR already created what we need to do is include it in your own base image. To do that we place the JAR file in the <TIBCO_HOME>/bwce/2.4/docker/resources/addons/jar

And we launch the building image command again from the <TIBCO_HOME>/bwce/2.4/docker folder to update the image using the following command (use the version you’re using at the moment)

docker build -t bwce_base:2.4.4 .

So, now we have an image with Prometheus support! Great! We’re close to the finish, we just create an image for our Container Application, in my case, this is going to be a very simple echo service that you can see here.

And we only need to keep these things in particular when we deploy to our Kubernetes cluster:

We should set an environment variable with the BW_PROMETHEUS_ENABLE to “TRUE”
We should expose the port 9095 from the container to be used by Prometheus to integrate.

Now, we only need to provide this endpoint to the Prometheus scrapper system. There are several ways to do that, but we’re going to focus on the simple one.

We need to change the prometheus.yml to add the following job data:

- job_name: 'bwdockermonitoring'
  honor_labels: true
  static_configs:
    - targets: ['phenix-test-project-svc.default.svc.cluster.local:9095']
      labels:
        group: 'prod'

And after restarting Prometheus we have all the data indexed in the Prometheus database to be used for any dashboard system.

In this case, I’m going to use Grafana to do quick dashboard.

Each of these graph components is configured based on the metrics that are being scraped by Prometheus TIBCO exporter.

Flogo Test: Learn How To Master Tests in Flogo!

2026-01-152019-07-15 by Alexandre Vazquez

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.

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:

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:

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:

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

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

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

Flogo JWT Support

2026-01-152019-07-08 by Alexandre Vazquez

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.

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:

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.

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”

Set the following App Client Settings as shown in the image below with the following details:

Cognito User Pool selected as Enable Identity Provider
Client credentials used as Allowed OAuth Flows
http://flogo.test1/echo selected as an enabled scope

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:

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:

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:

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

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:

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:

Test

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

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

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:

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

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:

Resources

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.