Full integration to Salesforce with Red Hat Integration (Part 2)

Full integration to Salesforce with Red Hat Integration (Part 2)

This article is the second in a series of three articles about Red Hat Integration. The first article described how the new Red Hat Integration bundle allows citizen integrators to quickly provide an API through tools that make creating an API in five simple steps effortless, and we implemented a demo showing the full API lifecycle on Red Hat Integration. The demo was about providing wine labeling and ranking info via APIs.

In this article, I am going to take you further by implementing a real business transaction with Salesforce. We will create an event-driven integration solution with no code on Red Hat Integration.

The idea of this demo is to receive an order from the client web application through a gated, secured API that will then process the order and forward the needed data to the corresponding Salesforce modules. From there, Salesforce will take care of the order content.

Creating an event-driven integration solution with no code on Red Hat Integration

 

If you would like to know how the API is built and implemented, please check the first article. In this article, I will be focusing on how to integrate with Salesforce using an event-driven approach.

Integrating with Salesforce using an event-driven approach

Creating an order in Salesforce requires many steps. The first is to set up an account for every user and define the contract of each user. After that, we are ready to create the order, but the details of the order need to be handled separately to associate it with price book entries. Each step I describe requires the output of previous steps. So we should build our application in an asynchronous way to avoid long-hanging processes. To set up for the event-driven system, we need a medium of some sort to hold and distribute the events; it could be a messaging broker or a streaming platform. Here, I will just use a broker for the sake of simplicity.

Basically, we will be using the broker to gather all the events calls from the API, handle returning the result from Salesforce, and pass the result on to the next step. If we break the entire process down, this is what is happening:

1. Receive incoming request.

2. Wait for incoming request and create an account in Salesforce with the username.

3. Wait for successful account creation and then create a contract in Salesforce using the account ID.

4. Wait for successful contract creation and then create an order using both the account ID and the contract ID.

5. After the order has been created, add a product order entry to the order

So if we implement this event-driven integration solution, we will have five perfectly modularized integration microservices running and ready to handle the events, as shown in the following diagram.

Five perfectly modularized micro-integration services to handle the events

In addition to placing the order in Salesforce, we also want to notify the customer via email when the order is done. A template can be used in Red Hat Fuse Online to make sure the format of the email is consistent. To apply the data from the integration solution into the template, we can use the placeholder along with static boilerplate text for the email.

Watch this video to see how I created the integration solution. And here is the link to my repo that contains everything you need to re-create the demo.

Have fun!

Everything you need to grow your career.

With your free Red Hat Developer program membership, unlock our library of cheat sheets and ebooks on next-generation application development.

SIGN UP

To learn more, visit our Linux containers or microservices pages.

Join Red Hat Developer and get access to handy cheat sheets, free books, and product downloads that can help you with your microservices and container application development.

Download and learn more about Red Hat Fuse, a modular, cloud-ready architecture. Fuse is Java EE 7 certified and features high-availability clustering, distributed caching, messaging, transactions, and a full web services stack.

Share