Kevin Montalbo

Hello listeners, welcome to 2021 and our very first interview episode of the year. You're listening to Coding over cocktails by Toro Cloud. My name is Kevin Montalbo. In this episode, we'll be talking about connectors and how connectors are used as a way to facilitate connections with integration platforms. We will look at the disadvantages in using connectors to maintain integrations. How you can leverage the use of APIs for your organization, how integrating with and consuming APIs is made easier through API schemas and how you can learn more about the Toro cloud platform, a digital transformation platform as a service. After listening to this podcast, make sure to visit our website at www.torocloud.com for the transcript of this episode and blog posts related to this topic. Joining us today for cocktails Historic Cloud con founder David Brown. Hi, David. Good to have you on Kevin. All right. And joining us as well. Historic Clouds product architect, Vivien Jovet all the way from France. Hi, Vivien.

Vivien Jovet

Hi, Kevin.

Kevin Montalbo

All right. Let's begin this podcast. Vivien, can you tell us how connectors work in the context of enterprise application integration platforms. What are these so called connectors?

Vivien Jovet

Yeah. So a connector is a piece of code, a piece of software that wraps the necessary logic to communicate, to make requests to an external API. So we often call them SDK or client library and basically they contain methods that can allow you to make a request to the operations of an API.

Kevin Montalbo

All right. What can you say are the disadvantages of connectors when we're trying to integrate these with APIs?

Vivien Jovet

Yeah. So one of the main disadvantage of connectors is that they get out of date. really often The reason is thatAPIs publishers make changes to their APIs and they, they don't necessarily warn you about the, the breaking changes or what exactly are the changes that they are making. And you will only discover that your connector doesn't work when you get the, the errors. So when you rely on integration platform for your, your connectors, you actually rely first that they would have the connector for your APIthat they are monitoring the APIs for changes and things like that and that they will actually update quickly the, the connector so that it works with the latest version of the API. And the reason why it's, it's, it's not good is that often the the connectors are maintained by developers by hand. So it's time consuming process to create update and of course, it's prone to error. So the you can imagine that for an integration platform to maintain hundreds of API it's, it's really not scalable to do it that way.

Kevin Montalbo

Do you have that experience, David? Do you observe, are you able to observe that kind of experience from the industry?

David Brown

Yeah, I mean, that's why we developed Martini as a connector integration platform. Because to be honest, we started out to the same as pretty much every other integration platform out there in that we built connectors and you'd largely build these connectors by hand. Like Vivien is saying so pretty much every integration platform in the market today still uses connectors. The problem with them as Vivien explained is it's a very laborious process and we, we found that ourselves, you know, we got up to a couple of 100 connectors and just keeping pace with the number of APIs available and all the changes to those APIs just meant that it wasn't scalable for us. We had to find a better way of doing it. And so a connector approach means that you bypass this software which sits in between the integration platform and the API and the integration platform connects directly to the API instead.

Kevin Montalbo

So now that we've established that we needed to kill the connector because it's not scalable, what should take their place. David

David Brown

Well, it was, it was at the time we were building these connectors. API schemers were evolving and API schemers, there was a number of competing formats for those schema as well. But those scheme a wars were largely resolved as we were trying to find a better solution. And swagger and open API its successor became the winner of those wars. And everyone is sort of consolidated for restful APIs on the open API specification. So that meant that if a API provider or publisher provided an open API schema, an open API, schema is a machine readable format, it's human readable as well, but a machine can read the schema and interpret it run through all the operations, the security required by the API and the like and machine generate the services that are required to interface with that API. So that the integration platform is now speaking the same language as the connector or the services to interface to that API. So it bypasses the concept of the connector completely. The issue of course is not, not all API providers provide a schema. And so and so the you know, whilst we encourage API publishers to make their APIs discoverable by providing an API schema in any format, whether it be open API and in some cases, it's beneficial to provide it in multiple formats including postman. Many don't and yeah, many will in the very least provide some basic web-based documentation. And so what we did is we realized quickly that if we're going to rely on schemers in a to provide a connector, less experience to consume an API, then we also needed a way so that end users could build an open API scheme if one didn't already exist. And so we built a tool which was able to basically scrape web-based documentation and it builds those a PNR A and API schemes for you. It's literally just a case of pointing and clicking at the documentation. And it, it API documentation tends to be templated with consistent CSS styles and classes. And so the the crawler leverages that concept and will crawl the documentation and build out of that a a compliant open API schema. And so as a result, we were able to do that ourselves. When we launched this concept, we were able to go through from 200 odd connectors which were a nightmare to maintain to 2000 open API schemers in our marketplace overnight. And even if in that marketplace, there isn't an open API scheme up to consume. you can always create one yourself. Of course, with Martini, you can create, you can consume any ad hoc operation without a schemer as well. The advantage of a schemer is that every single operation from that publisher is is available to you automatically. So if you're looking at salesforce, for example, you might want to have a get contact operation, an update, contact operation. yeah, various operations for different sort of services you want to perform in an API scheme will generate the hundreds of operations that are available in that API machine, generate them for you automatically. If you just need to get contact operation, you can do that ad hoc but just running through a wizard to, to build a service to consume that one operation. You don't need the API schema. API schemers just make it extremely convenient to consume an API and all of the operations with it. Now, what the other advantage is here is when the API changes because once the schema is defined And particularly once that if you've, if you've mapped it to the documentation, you can just rerun that mapping and build the schema again. Or if the publisher provides one, they provide you with a new version of the schema and you can machine generate those services within seconds and you're now ready to consume the new, new API as well. So it's a totally different landscape.

Kevin Montalbo

Yeah. So you've already like given us like an overview of how we can be able to consume an API using an API schema. But Vivien can you walk us through the process technically of how you can do this with Martini. How can we consume APIs using these API schemas?

Vivien Jovet

Yeah. So there is two main ways to consume API with Martini, the first is to use our wizard. So we have a wizard to P an API. It's very simple. You start the wizard, it's gonna be asking you for basically the, the specification. So it's gonna be either a file or URL in any format. So we support like they say we support mini API specific format like swagger, open API. So you fill up that the the wizard page click finish and then, then it's going to be generating all the services that are mapping to the operations of the API. And then you're done, you can already start using the, the API. Then if you're looking for an API, but you don't yet have the, the file or the URL for it, You can look in the Toro marketplace. So from Martini, you can browse the, the marketplace for the, the API just select it, install it and then it's gonna do the same process, generate the services for you and then you can, you can start using it already. And the, the third solution like David mentioned is to use the docs to open API tool that we, that we developed. So it's a chrome extension that you can use. you basically open documentation website. You start looking at what the documentation is made. Where are the operation defined, the response, the request. You map it using the tool. It's just a simple click on the element and then it's, it's gonna map it for you. Then you, you run it, it's gonna generate the API schema based on that. And then you can either download it use it in the wizard or even publish it to the marketplace to contribute to it.

David Brown

And it's worth noting that Chrome extension which we've made freely available in the Chrome store is available to anyone. You don't need to use it with Martini. So if you're an API publisher and you haven't provided a schemer to your consumers of your API, download the Chrome extension and, and just map your own documentation and build a schema from it. There's a whole bunch of stuff you can do that. Once you've got the open API scheme, you can build machine generated services and the like and then start doing API first design using that API schemer and the like and using tool sets which support us including Martini. But in the very least you can use the tool to create a schema and provide it to your end users so that your API becomes easier to consume.

Kevin Montalbo

All right. So Martini is just one part of the puzzle in the entire to cloud suite, entire to cloud platform. And the last time we spoke,we didn't have this Toro cloud platform yet. But now in 2021 we're, we're, we're, we're starting the year strong with the Toro cloud platform. So I want to talk about the Toro cloud platform. David, what is the Toro cloud platform?

David Brown

Well, it's an entire ecosystem to facilitate digital transformation. So, yeah, digital transformation. whilst a cultural change also typically requires technology and there are certain projects which revolve around digital transformation and in particular data and the and the management of data monetizing data and the flow of data. And so you typically use certain technology solutions to facilitate all this and and to become this new agile organization which can respond quickly to the market and develop and consume digital services. And so when you're wanting to do that, when you want to becoming an agile organization, you have to change your it processes and you have to change the way you build applications, the way you consume applications and importantly CRE creating an ecosystem out of your applications so that your end users, be it, your employees, your business partners or your customers get a cohesive seamless experience between them as well. And so when you're embarking on those type of projects, you're typically looking at the very least an integration platform. And so that's where we started. 

Martini is an integration platform as a service and it does stuff like application integration, getting all of your applications, talking to each other, your CRM system, talking with your accounting or er P system, talking with your order management system and inventory systems, even your line of business applications or custom applications you've written in house or and or databases. So the application integration part of the puzzle we've solved now for a few years with Martini, it also does things like APIs management, creation of APIs and the deployment of APIs. And so we facilitated API first approach to application integration and development and this is a new way of a a services orientated architecture thinking about the way people are going to consume your services before you start building. And so by designing the interface first, by designing your API, you're enabling those stakeholders that are going to be consuming that service to have a say in the way it's designed and what they want to see to be consumed out of it. They also as a result of that process, have some sort of ownership because they are involved in the process and are probably much more likely to, to use it. And so we have a process by which you can do API first design, you can create these APIs and you can publish them, you can secure them and then you can start creating digital products and services out of them, you can monetize them. 

So for example, so we facilitate monetization of APIs. And that means monetization of data, that means unleashing data, which is locked up in data silos be it databases or legacy systems or whatever your proprietary processes are APIs enable you to create digital products out of those processes or data that you may have. And that's evolving your business into a new digital business. You're now digitally dealing with customers and employees and other stakeholders. Digitally, you're creating a cohesive experience for them by having this seamless flow of data between your systems. But then the next thing, the final piece in the puzzle which we solved more recently was a full blown application development. So what we started with with Martini enabled you to build low code microservices and with a particular emphasis on integration. So these were low code in the respect that they were used like lego block type mentality where you drag and drop lego blocks to build out a service. And often in case you can build a service with zero code at all. But in fact, we enable you to write code if and when you need it, enabling full enterprise class functionality for that service, but you basically end up with a service with far fewer lines of code than you otherwise would. So maybe a service might consist of two or three lines or six or seven lines instead of several 100 lines of code. So they become much more manageable, they become microservices and maybe have API interfaces by default, they have restful interfaces by default like a microservice would have a known interface. And so we already had this backend w which enabled you to build these backend services with these restful APIs. And what we were missing was the front end to be able to complete the application development life cycle of building the end user experience. 

And so more recently, we deployed that an application called Bellini, which facilitates a low code application development of the, particularly the the user front end. It has a unique take on user application development. So it is also a drag and drop user ID to to develop an environment. And as part of that, you drag and drop components onto a canvas and you bind those components to an API. So those components may be for example, a a form and you want to populate that form with contact details from your sales force database and the ability to edit that that contact record and then post it back to the Salesforce database, for example. So you're able to drag a form onto your canvas and then bind that component that form component to the get contact operation of the salesforce API. And then when you click the button of that form. It's binding that button operation to the update, contact record operation of the salesforce API. And so this mentality of everything being api centric, we are a low code api centric digital transformation platform which enables you to build applications, integrate applications, create APIs transform, data, manage, data, integrate data and automate workflows and build, you know, either synchronous or asynchronous workflows which may require human intervention or just occur as they're invoked. And so all of this tool set completes creates a complete product tool set which encompasses a lot of projects associated with digital transformation. And so we call Toro Cloud a, a digital transformation platform.

Kevin Montalbo

All right. That's a wrap for this episode of Coding over cocktails. Thank you very much, Vivien for joining us. 

Vivien Jovet

Thank you for having me. 

Kevin Montalbo

All right. And thank you as well, David. We'll join up again soon in the next episode of Coding over cocktails. 

David Brown

Always a pleasure, Kevin.

Kevin Montalbo

All right, to our listeners. What did you think of this podcast episode? Any thoughts on going connector list with APIs? Let us know in the comments section from the podcast platform. You're listening to. Also please visit our website at www.torocloud.com for a transcript of this episode as well as our blogs and our products. We're also on social media, Facebook, LinkedIn, Youtube, Twitter and Instagram, talk to us there because we listen, just look for Toro Cloud Thank you very much for listening to us today. This has been Vivien Jovet, David Brown and of course, Kevin Montalbo at your service for coding over cocktails. Cheers.