In 2016 TIBCO announced Project Flogo as an ultra lightweight integration engine. It is the lightest way to connect IoT devices being up to 20 to 50 times lighter than Node.js and Java® Dropwizard. Project Flogo was made available as Open Source Software because TIBCO believes there is a better way to integrate IoT devices. With it being Open Source and easily extensible, you want to make sure that the activities you build remain working after each check in on GitHub. These are a lot of words to say “How can I test my activities every time code is pushed to Git”?

Over the past few weeks I’ve gotten many questions on how to use Basic Authentication with the new Web Integrator in TIBCO Cloud Integration. It is really easy to do that!

In the age of large monolithic apps and app servers, it was not too difficult to monitor the status of your application as well as some more detailed monitoring of transactions. In today’s age of microservices, that whole monitoring thing is getting more and more complex. You not only have to deal with a bunch of more servers, you also have to deal with more (micro)services. You have different options depending on what you want to monitor. For example, you can use Nagios, Zabbix or Prometheus. My personal preference goes out to Greek deity that stole fire from Mount Olympus and brought it to us.

In 2002 Jeff Bezos issued a mandate that would change the world forever. At the very least it brought a massive change to how data is reused on the Internet. The mandate from Jeff Bezos was:

• All teams will henceforth expose their data and functionality through service interfaces.

• Teams must communicate with each other through these interfaces.
• There will be no other form of inter-process communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
• It doesn’t matter what technology they use.
• All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
• Anyone who doesn’t do this will be fired. Thank you; have a nice day!

That mandate started a great deal of what we see as the API economy today. Many of the worlds’ enterprises have APIs available that can deliver data so you can focus on building value, rather than worrying about how to get the data. Having said all that, most APIs that are out there are documented but don’t have a swagger.json that you can import in your code. The Web Integrator in TIBCO Cloud Integration gives you the ability to copy and paste the sample messages that those APIs do have and use that as the base to invoke REST APIs.

You shouldn’t have to be a Swagger expert to get started with designing and building your new API. Creating an API from scratch can be a difficult task, so what if you could create API without writing a line of code?

Have you ever had that feeling you wanted to capture data and just send that data to just about anywhere? Google Forms gives you an easy way to create personalized surveys with the style that you want. So we got the first requirement down with that one, but what about sending the data elsewhere? That is where TIBCO Cloud Integration comes in.

Communication in our daily life is incredibly important, so why should that be any different when you’re building integration processes? Sending emails is still considered an important part of day to day operations. For example when errors occur in your integration flows, you might want to send an email. In this tutorial I’ll walk you through sending an email, and in my case I’ll use Gmail as provider.

Probably the most common version control system, used by developers today is git. Whether that is a self hosted server (like Gogs), a bare repo (git init) or with GitHub, most developers intuitively seem to choose for git as their version control system of choice. I try to store all my projects in local git repos and some of them make it to GitHub, while many of them don’t. When it comes to deployment of apps to TIBCO Cloud Integration, I do many updates per day so I wanted an easy way to not only store my latest source but deploy them right after.

As you’ve probably guessed by my previous two articles I love writing (about) Node.js. What isn’t great, however, is creating deployment artifacts every time you check something in to GitHub and want to deploy. To make that process a little easier there are many tools available, and of of those is Jenkins, the friendly butler. In this “How-to” I’ll walk you through using Jenkins with the tibcli utility to deploy Node.js apps to TIBCO Cloud Integration every time updates are pushed to GitHub.

I’ve just updated the Microsoft Visual Studio Code extension to help develop and deploy Node.js apps to TIBCO Cloud Integration. Apart from a whole bunch of restructuring, it now has the ability to create a new Node.js app (if you don’t want to start from an API spec) and it makes use of the .env files to work with process.env context.