Other integration vendors offer “connectors,” which are just thin wrappers over an endpoint API spec and don’t offer much more than basic authentication and data mapping. Connectors are old-school, and they don’t really help you all that much.
In the Cloud Elements Integration platform, we call our smart connectors “Elements” because the term "connector" doesn’t do them justice, given that it's so much smarter and way more useful than the old-school ones. Elements are the new school.
Elements
An Element is a prebuilt API integration that enables a connection into a specific cloud application or cloud service endpoint (e.g., Netsuite, Dynamics, Box, Salesforce, etc.). Our Elements provide a variety of advanced, built-in features, including normalized authentication, discovery APIs, search capabilities, event handling, unified error handling, and so much more—all the nasty stuff that you would still have to do on your own if you used the old-school connectors typically found in the platforms available today.
Because we’ve done much of the integration work for you, our Elements save you development time by keeping your integrations consistent and uniform. They provide a common, uniform integration interface for your developers to interact with. Thus, your integrations are done faster and are more reliable, more scalable, and easier to maintain.
We have 160+ Elements in our public catalog today, ready for you to use out of the box!
Your Question:
“That is awesome, but what happens if you don’t have an Element that I need?”
Our Answer:
“Element Builder, of course!” (There are other options as well—contact us).
Element Builder
The Cloud Elements platform provides powerful, self-guided tooling that allows anyone to build a new Element and add it to their integration ecosystem. Appropriately called Element Builder, it can be used to both create new and modify existing Elements. In fact, it is the same tooling that our Element designers use when crafting new Elements destined for our public catalog. Element Builder is also used for the private Elements that are customer-specific or created in support of a prospect’s POC; in fact, we have hundreds of these we will soon expose as starters and learning examples!
If you are thinking, “So what’s the big deal? Why do you need specialized tooling to make a simple connector?”
Elements are not simple, but are full of functionality—all in a uniform, easy to understand standard using REST and JSON—even if the endpoint you are integrating to is based on SOAP. Without tooling like Element Builder that allows you to create new Elements normalized to Cloud Elements’ uniformity standards, it would take months to build one from scratch. And, because the Element Builder does so much of the work for you by stepping you through the process, adding a fully baked new Element to your private catalog can be done in as little as a few hours to a few weeks depending on, of course, the complexity of the endpoint’s API spec.
Integrating is Hard
Don’t believe me? Want proof? Here ya go:
-
Twitter Element build example: Shows building the essentials of the Twitter Element; connecting to Twitter and sending a tweet in under two minutes
-
MailChimp Element build example: Shows building a usable MailChimp Element from scratch, ending to end—including eventing and other features—in under 30 minutes
Recently, I was notified that an SAP Global System Integrator commented within an SAP blog that "It took exactly less than an hour to build this connector on SAP Open Connectors platform without any prior skills on this platform." BTW, Cloud Elements is rebranded within SAP's platform as "Open Connectors."
Think about it. How long would it take you to get your product or your data sync application integrated into MailChimp, Twitter, or any other endpoint? Whatever your guess is, I’ll bet you that it is at least 10x that.
Why? Because what I’ve seen is that with integrations, connecting is easy, but integrating is hard. It is all that stuff that is below the proverbial integration iceberg that you haven’t accounted for that gets ya—things like polling and bulk frameworks, authentication nuances, access token refreshing, error code mapping, query language differences, and so forth. Read this before you take my 10x bet—it outlines all these items and how they can delay your integration deliverables.
Let's get back to the Element Builder.
Essentially, it is designed to take those aspects that make integrating hard and simplify them into a uniform, predictable, prebuilt set of API resources based on REST with JSON, yet still have all the intelligence needed to translate that uniformity to a given endpoint’s API uniqueness—and each endpoint IS unique...trust me on that one.
Technical Details
If you are hungry for the technical details regarding Element Builder, read on—otherwise, skip to Wrap Up.
For endpoint services like Pinterest that authenticate using OAuth 2, the Element Builder sets it all up for you. All you need to get connected is the Client ID and Secret for your registered app at Pinterest and the Call Back URL that points to your app. Pagination is normalized to a common method by selecting the appropriate drop down.
No coding required.
Next, just add the REST resources, parameters, pagination, etc.—BTW, most of this is automatically generated for you and takes only a few clicks to get these items functional. In fact, Element Builder will flesh out the complete set of methods as required for each object: GET, POST, PATCH, PUT, DELETE—and even normalize any common methods by category or Hub (e.g. CRM, Marketing, Finance).
The Element Builder provides so much more integration technology: way too much to cover in this blog. But I promise that I’ll create a few sub-blogs, covering more of the awesome details— like “How do you accommodate for Pinterest’s OAuth nuances?” and “How do you configure the Event Poller given that Pinterest doesn’t provide webhooks or a native eventing framework?”
TO Wrap Up
Elements are the essence of the Cloud Elements platform. They are the new school of connectors, way more powerful and way easier to use. An Element’s purpose in life is to save you time, increase reliability, and lessen the maintenance associated with your integrations. They do this by doing most of the work for you already and, in some cases, making up for functionality that you need for your use case that the endpoint doesn’t provide natively.
Elements are built using Element Builder by you, or Cloud Elements, or virtually anyone who wants to get integrated quickly and reliably, making short work of it. So, I guess if that is true, then the Element Builder makes short work of making your integration work shorter? Something like that.
Still want to take my 10x bet? I’m game.
To dive deeper into the features of an Element, download a copy of our eBook The Anatomy of an Element by clicking below.
Aloha!