TIBCO Archives - Page 3 Of 4 - Alexandre Vazquez

Deploying Flogo App on OpenFaaS

2022-05-072019-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

2022-05-072019-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!

Flogo Configuration: How To Master It In 5 Minutes?

2022-09-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.

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!

2022-09-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.

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.

Prometheus TIBCO Monitoring for Containers

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!

2022-09-142019-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:

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

2022-09-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.

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.

Flogo Performance: How performant can be your services with Flogo? (Flogo vs Python)

2022-09-152019-07-01 by Alexandre Vazquez

Table Of Contents

Introduction
Scenario
Results and Conclusions
Conclusions
Resources
- GitHub – alexandrev/flogo-vs-python-medium

Introduction

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

To be able to share some real data the best thing we can do is to do our test. To do our test we’re going to compare our Flogo development versus the same one using Python.

You could ask why we’re comparing Flogo developments and Python developments and the answer is very simple. Python is now one of the most trending languages, recently added as the 3rd top language in the TIOBE Index and the main language when we talked about data science scripting:

Scenario

Test 1

We’d like to test both technologies but also see how they compared with the new reality for microservices and be able to integrate with Cloud Services and we think the best fit for this test will be using Amazon S3 to be able to see how both technologies perform.

So, we’re going to upload files to Amazon S3 and see how both technologies perform. And we select the following tests:

File A: small 138 KB. Number of iterations, 1, 10, 50.
File B medium 7 MB. Number of iterations 1, 10, 50.
File C: big 50MB. Number of iterations 1, 10, 50.

We’re using the following Python script for test the S3 integration:

import boto3

import time

import sys

import psutil

from botocore.exceptions import NoCredentialsError

ACCESS_KEY = 'XXXXXXXXXXXXXXXXX'

SECRET_KEY = 'XXXXXXXXXXXXXXXXXXXXXXXXXXX'

def upload_to_aws(local_file, bucket, s3_file):

       s3 = boto3.client('s3', aws_access_key_id=ACCESS_KEY,

       aws_secret_access_key=SECRET_KEY)

       try:

           s3.upload_file(local_file, bucket, s3_file)

          print("Upload Successful")

          return True

       except FileNotFoundError:

          print("The file was not found")

          return False

       except NoCredentialsError:

          print("Credentials not available")

          return False

def launch():

    start = time.time()

    for x in range(0, int(sys.argv[1])):

    uploaded = upload_to_aws('D:/Data/Downloads/export.sql', 'testflogovspython', 'export.sql')

    end = time.time()

    print("Time: " +  str(end - start))

launch()

And we’re going to use the following Flogo Application (several flows for each of cases we’d like to check)

Test 2

Now, as this is going to be to build microservices or applications in a cloud world let’s see how both perform doing a simple Hello World REST API. For the python part we’re going to use Flask to create the web service and the following snippet:

from flask import Flask

app = Flask(__name__)

@app.route("/")

def hello():

    return "Hello World!"

if __name__ == '__main__':

    app.run(debug=True)

NOTE: We keep the debug=True to make it equivalent to the INFO default level system in Flogo Application

And for Flogo a simple REST Hello World like this:

Results and Conclusions

Test 1

We’re getting the following numbers as you can see in the graph below:

Even in this quite simple code sample, the performance of the Flogo application is too incredible to be compared with another well-performed language like Python.

We’re talking like an average of more than 50% faster the Flogo development vs the Python one, and even more when the size of the file is small and more important is how the language and the platforms are handling things because they percentage of time regarding bandwidth is not big enough to make that all the values depend on the connection you have available at that moment.

If we talk about memory consumptions data are pretty much stable for both languages what is a very good sign on how memory is handled for those platforms. But in this battle also Flogo wins because if we use the last one the biggest one, Flogo is stable at 22,7 MB vs 55 MB from Python, also more than 50% better once again.

Test 2

For the REST API service results are pretty similar to the ones from the first TEST, and we’re seeing the following results regarding TPS and Response time:

As we can see first of all the response time is always smaller from the Flogo API (and remember that this is a default test, with no special tuning or something similar) and also the response time is performing better in Flogo being able to keep stable almost until 4 threads and then being able to control the increase while Python REST service after 2 threads the response time increase more than twice with each test.

The same thing happens regarding TPS wherein the Flogo case all the values are better than the previous one. Of course, some kind of limit is reached at 8 threads but in the case of Python this root is reached at 2 threads and after that point all the values and worse than the previous one.

Regarding memory, consumption is pretty similar like the previous test both of the solutions keep memory usage quite low and stable. In this case, python is always stable at 20.3 MB and Flogo starts at 15 MB but reaches its peak at 21.8 and then go back to 18.8 MB. So as I said they’re pretty similar regarding memory usage in this test

Conclusions

So, the conclusion is clear, no matter how well you think your logic is executing in Python, you should give it a try to do it using Flogo because, in this time where each MB and each msec counts to make smaller your Infrastructure bill, Flogo is going to be your best tool to squeeze all the power of your infrastructure.

Resources

You can find all the code I’ve used for these tests in the GitHub repository shown below:

GitHub – alexandrev/flogo-vs-python-medium

Contribute to alexandrev/flogo-vs-python-medium development by creating an account on GitHub.

Flogo Error Handling

2022-09-152019-06-24 by Alexandre Vazquez

Table Of Contents

Introduction
Error Handler
Error Condition
Throw Error Activity

Introduction

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

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

Error Handler

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

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

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

Error Condition

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

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

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

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

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

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

Throw Error Activity

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

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

Flogo Subflows: Boosting the Manteniability of Your Software

2022-09-152019-06-17 by Alexandre Vazquez

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

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

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

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

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

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

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

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

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

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

OpenTracing support in TIBCO BusinessWorks Container Edition

2022-05-092019-06-10 by Alexandre Vazquez

The past month during the KubeCon 2019 Europe in Barcelona OpenTracing announces its merge with OpenCensus project to create a new standard named OpenTelemetry that is going to be live in September 2019.

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

So, I think that would be awesome to take a look at the capabilities regarding OpenTracing we have available in TIBCO BusinessWorks Container Edition

Today’s world is too complex in terms of how our architectures are defined and managed. New concepts in the last years like containers, microservices, service mesh, give us the option to reach a new level of flexibility, performance, and productivity but also comes with a cost of management we need to deal with.

Years ago architectures were simpler, service was a concept that was starting out, but even then a few issues begin to arise regarding monitoring, tracing, logging and so on. So, in those days everything was solved with a Development Framework that all our services were going to include because all of our services were developed by the same team, same technology, and in that framework, we can make sure things were handled properly.

Now, we rely on standards to do this kind of things, and for example, for Tracing, we rely on OpenTracing. I don’t want to spend time talking about what OpenTracing is where they have a full medium account talking themselves much better than I could ever do, so please take some minutes to read about it.

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

The only statement I want to do here is the following one:

Tracing is not Logging, and please be sure you understand that.

Tracing is about sampling, it’s like how flows are performing and if everything is worked but it is not about a specific request has been done well for customer ID whatever… that’s logging, no tracing.

So OpenTracing and its different implementations like Jaeger or Zipkin are the way we can implement tracing today in a really easy way, and this is not something that you could only do in your code-based development language, you can do it with our zero-code tools to develop cloud-native applications like TIBCO BusinessWorks Container Edition and that’s what I’d like to show you today. So, let the match, begin…

First thing I’d like to do is to show you the scenario we’re going to implement, and this is going to be the one shown in the image below:

You are going to have two REST service that is going to call one to each other, and we’re going to export all the traces to Jaeger external component and later we can use its UI to analyze the flow in a graphical and easy way.

So, the first thing we need to do is to develop the services that as you can see in the pictures below are going to be quite easy because this is not the main purpose of our scenario.

Once, we have our docker images based on those applications we can start, but before we launch our applications, we need to launch our Jaeger system you can read all info about how to do it in the link below:

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

But at the end we only to run the following command:

docker run -d --name jaeger -e COLLECTOR_ZIPKIN_HTTP_PORT=9411  -p 5775:5775/udp  -p 6831:6831/udp  -p 6832:6832/udp  -p 5778:5778  -p 16686:16686  -p 14268:14268  -p 9411:9411  jaegertracing/all-in-one:1.8

And now, we’re ready to launch our applications and the only things we need to do in our developments because as you could see we didn’t do anything strange in our development and it was quite straightforward is to add the following environment variables when we launch our container

BW_JAVA_OPTS=”-Dbw.engine.opentracing.enable=true” -e JAEGER_AGENT_HOST=jaeger -e JAEGER_AGENT_PORT=6831 -e JAEGER_SAMPLER_MANAGER_HOST_PORT=jaeger:5778

And… that’s it, we launch our containers with the following commands and wait until applications are up & running

docker run -ti -p 5000:5000 — name provider -e BW_PROFILE=Docker -e PROVIDER_PORT=5000 -e BW_LOGLEVEL=ERROR — link jaeger -e BW_JAVA_OPTS=”-Dbw.engine.opentracing.enable=true” -e JAEGER_AGENT_HOST=jaeger -e JAEGER_AGENT_PORT=6831 -e JAEGER_SAMPLER_MANAGER_HOST_PORT=jaeger:5778 provider:1.0

docker run — name consumer -ti -p 6000:6000 -e BW_PROFILE=Docker — link jaeger — link provider -e BW_JAVA_OPTS=”-Dbw.engine.opentracing.enable=true” -e JAEGER_AGENT_HOST=jaeger -e JAEGER_AGENT_PORT=6831 -e JAEGER_SAMPLER_MANAGER_HOST_PORT=jaeger:5778 -e CONSUMER_PORT=6000 -e PROVIDER_HOST=provider consumer:1.0

Once they’re running, let’s generate some requests! To do that I’m going to use a SOAPUI project to generate some stable load for 60 secs, as you can see in the image below:

And now we’re going to go to the following URL to see the Jaeger UI and we can see the following thing as soon as you click in the Search button

And then if we zoom in some specific trace:

That’s pretty amazing but that’s not all, because you can see if you search in the UI about the data of this traces, you can see technical data from your BusinessWorks Container Edition flows as you can see in the picture below:

But… what if you want to add your custom tags to those traces? You can do it as well!! Let me explain to you how.

Since BusinessWorks Container Edition 2.4.4 you are going to find a new tab in all your activities named “Tags” where you can add the custom tags that you want this activity to include, for example, a custom id that is going to be propagated through the whole process we can define it as you can see here.

And if you take a look at the data we have in the system, you can see all of these traces has this data:

You can take a look at the code in the following GitHub repository:

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