Pretty much all the large cloud platforms provide not only a great visual interface to get things done, they also have a great command line interface. As much as I like a great UI when browsing the web, I tend to favor the command line when I’m focused on building things.
In 2016 TIBCO announced Project Flogo as an ultra lightweight integration engine — up to 20 to 50 times lighter than Node.js and Java Dropwizard. It’s open source and easily extensible, which means you want to make sure the activities you build keep working after each check-in. The question is straightforward: how do you test your activities every time code is pushed to Git?
I’ve gotten a lot of questions about using Basic Authentication with the Web Integrator in TIBCO Cloud Integration. Turns out it’s pretty straightforward.
In the age of monolithic apps and app servers, monitoring was relatively straightforward. With microservices, you’re dealing with more servers and more services, and monitoring gets complex fast. You have options — Nagios, Zabbix, or Prometheus. My preference goes to the 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:
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 kicked off a lot of what we now call the API economy. Many enterprises have APIs that deliver data so you can focus on building value rather than figuring out how to get the data. That said, most APIs out there are documented but don’t have a swagger.json you can import directly. The Web Integrator in TIBCO Cloud Integration lets you paste sample messages from API docs and use those as the basis for invoking REST APIs.
You shouldn’t have to be a Swagger expert to design and build an API. Creating an API from scratch can be a difficult task, so what if you could do it without writing a line of code?
Ever wanted to capture data from a form and send it somewhere useful? Google Forms handles the collection side well, but what about routing that data to an API? That’s where TIBCO Cloud Integration comes in.
Sending emails is still a core part of many integration flows — error notifications, confirmations, alerts. This tutorial walks through setting up the Send Mail activity in TIBCO Cloud Integration’s Web Integrator, using Gmail as the 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 choose git. 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 deploying 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 it right after.
