Exposing Boomi Sync Process over REST & SOAP Using API Component

Boomi API Management provides a scalable, cloud-based platform to centrally manage and enrich API interactions through their entire lifecycle. Using Boomi, users can quickly create and publish any endpoint as an API on-premise or in the cloud, as well as manage and control APIs.

Here is one scenario on how Boomi can be used to expose existing Boomi processes as APIs (over REST or SOAP).

Scenario

Our Boomi process has been exposed as an API using API component. We trigger the process via API using an http client. The sync process then pulls required records from SaaS Salesforce and inserts them into the MySql database.

Process 1: When API executes our process 1, it will get the department name from request data and sends this data to Salesforce connector which is going to retrieve the department’s employees. Once SF returns some data to the process, it will enqueue this data into ATOM Queue and returns the same data in API response as well. Individual records are enqueued to queue in a batch of 5 records at a time.

If no records returned from salesforce it will return No id found message in response.

Process 1

Process 2: Once the data is placed in the Atom Queue, the 2nd process listening on queue fetches the data from Queue and inserts it into the MySQL database.

Process 2

Boomi API Component:

API components are deployable components used to expose sets of REST, SOAP, or OData API endpoints for logical groups of APIs.

We define the API Component and deploy to our local atom.

In the definition, we import Boomi Process 1 as EndPoint so it automatically sets Rest and SOAP Configuration.

API Component

Validate Input Request

In process 1 “Web Service Server Component” we define Expected Input Request Profile. If input request is validated against defined profile, process will further execute and return the response.

Below is the Expected Request Input which we send it.

Input Request

Validate Response

In process 1 “Web Service Server Component” we define Expected Response Profile. We fill the response message as per defined profile structure only.

Below is the sample Expected Response:

Response

No Records founds Validation Response

When Process 1 has been successfully executed and if there is no matching data found during the execution, it will also follow the same Response Profile to return response that we defined earlier. It copies the Department name which we are passing from input request and sets the flag “No, ids found” inside the element.

Below is the snapshot of No Records found validation response.

No Ids Found Response

MySQL Database Insertion

Once records are enqueued in ATOM Queue, the 2nd Process gets executed and fetches data from the Queue and inserts them into MySQL Database with a defined mapping profile.

Below is the snap of the inserted data.

MySQL Database

API Monitoring Dashboard

Using Dell Boomi, we can view APIs usage analytics using API Analytic Dashboard. Monitoring Widgets list are as follows:

  • API Usage History

  • API Usage Trends

  • Average Response Time

API Usage History

In this widget, we can analyze the usage history of API on a specific time period (Day, Week, Month and Year).

API Usage History Widget

API Usage Trends

In Trends widget, we can check 5 most frequent API calls within a specific time period (Day, Week and Month).

API Usage Trends Widget

Average Response Time

In the Average Response Time widget, we can analyze the API response within a specific time period (Day, Week, Month and Year).

API Average Response Time Widget

Royal Cyber can provide practical development strategies and configuration tips. For any additional questions or clarifications you can email us at [email protected] or visit www.royalcyber.com.

Leave a Reply