Data Transformations: How-Not-To Block API Integrations

By Travis McChesney in GET/technical Posted Feb 26, 2015

Getting Started with API Integration: A Series

When apps and cloud technologies work together, with pre-built, pre-orchestrated integrations, that’s cooperation. Buyers are choosing what services they want to use based on their level of connectivity. In other words, those lines of businesses are looking for cooperative apps — apps that can instantly share data with other applications. These apps play nicely with others, they are more than apps that are connected. They share data and seamlessly communicate with other applications. This series on Getting Started with API Integrations is designed to guide you (and your app) towards a world of connectivity.

Getting Started with API Integrations

So why does all that matter to you, as an application developer? Well, the burden sits on your shoulders. The cloud integration responsibility is moving from IT departments to application developers/providers. With that responsibility, comes a set of challenges we have covered in the Cooperative App Series, including Data Transformation.

Data Transformation

Data Transformation
 is the processing of data from one format, such as XML or SOAP, or even currencies and time formats, into another. You have invested time and money into configuring the data to flow into your app in a very specific way. That doesn’t mean that the other apps that are on your integration roadmap have the data formatted in the same manner as you do.




You will always have your data structure that your app uses on a regular basis. Your business objects have been defined. You know how the data flows throughout. When it comes to data transformation, it’s vital to consider how you will bring data in and how you will flow it out. This exchange of data, as a concept, is a great first step when considering best ways to handle transforming objects from one format to the next.


Abstraction Layer


When you bring a foreign layer into your app, you want to write the code that accepts new formats of data, reviews the mapping of the objects and transforms the data into the proper format that can be relayed to your app. For example:

Date and time handlers in transformation services are easiest to relate to. A date-object can come in, in multiple formats: 02/15/2015, 2/15/15, Feb 15, 2015, etc. The transformation service is designed to handle the variety of numbers and formats, syncing all the data into a common format that your app can understand.

“Cloud Elements has created an approach to this process: a transformation service within the API Integration. The purpose behind this service is to relieve developers from the burden of data transformations. . With our transformation services, you can define what you want your application’s objects to look like and use our drag and drop interface to map the fields the endpoint. . By using a consistent object in your application, your developers don’t have to worry about unique code for each individual endpoint,” Vineet Joshi, CTO at Cloud Elements.

Cloud Services and technologies deal with a variety of payloads, including XML, SOAP, JSON, etc, which means that there will be a variety of formats coming in with the different data objects. You have to understand each individual payload structure in order to connect to the different endpoints.

Cloud Elements removed the various languages, so when you connect your app to our API Integrations, all you will see is JSON. We also provide discovery APIs so you can find the objects you’re looking for.

The work around requires finding good documentation and understand each individual endpoint’s data model.


Next in the series, we’ll determine the methods your app needs to execute against each data object CRUD(S): CREATE, RETRIEVE, UPDATE, DELETE, SEARCH. Consider which app will be mastering the data vs. consuming the data to avoid conflicts.

Until then, if you need help creating a killer cooperative app, view our online integration guide