Integrating Data from External Applications

Part 1

Welcome back!

Welcome back to our ongoing data migration series! (To view part one of the series click here and for part two, click here). Next up on the agenda? Integrating data from external applications using APEX REST. This post is designed to guide you through an integration using Apex REST API. More specifically, how it will receive data as a REST request from any external application and move it to any salesforce and salesforce.com objects. REST requests can be either XML or JSON format, however in this guide, we will consider JSON as the input.

What is REST API, anyway?

A REST API defines a set of functions through which developers can perform, request and receive responses via HTTP protocol such as GET and POST. Sounds easy enough, right? If not, don’t worry, we will take a deeper dive and unpack that a bit.

Development

Start the process by writing a REST class with URL mapping with a Rest Resource. Be sure to choose one that will receive lists of records in a method that has HTTP Post notation and will capture and return both errors and successes to the requester. This can be implemented using the Response Handler wrapper class and having the success flagged and a list of messages recorded.

What is JSON?

Before jumping into next steps, let’s make sure everyone is on board with what JSON is. JSON stands for JavaScript Object Notation. It is a very common data format that uses “human readable” text to transmit data objects. Got it? Great!

What next?

Now that we have begun the process with the correct Rest Resource and understand what JSON is, let’s look at JSON and object relationships in Salesforce. We will start by looking at Apex REST again, specifically as it relates to Salesforce objects. Good news, the Apex REST class can handle any object or objects with child objects in Salesforce! Next up, if you want to process multiple objects at once that have parent/child relationships, the JSON also needs to be formatted accordingly. You should consider having an external key, or combination key. That way you know what the request is for what you are receiving. You will also want to know the processed records using upsert operation to see if they exist or do not exist. Depending on whether they do or do not, you can use the external Id to update.

(*Helpful hint) Force.com supports Apex REST, which lets you create web services on Force.com using Apex.

 

Before we wrap up, let’s look at a few final considerations:

Global access: Use standard HTTP method call-outs (available in every language and on any platform) to make requests and retrieve information from Force.com.
Standards-based security: Utilize the OAuth protocol for authenticating your REST calls.
Data model: Gain access to the same data model and standard objects as those in SOAP-based Web services.
Flexible formats: Serialize data in either the XML or JSON format

 

Congratulations!

Congratulations, you have made through the first part of the process! Check back for part 2 of the series, where we will dive into the next part of the process, testing.

 

About Bala Sadayappan
Bala is a Technical Architect in Statera’s Salesforce CRM Practice. Bala has Eighteen years of experience in IT as a Technical Lead / Architect and maintains certifications in Salesforce.com (Administrator & Developer), Apttus Configure Price Quote (CPQ) and XAE.