Essential Strategies for iPaaS Integrations with Boomi

“I have done a lot of Boomi integration builds, and almost every project has something new - here the Fulfillment object, there the Credit Memo. So it might be helpful to share how I go about building an integration into the unknown.” Larry Cone, CEO and Founder of Kitepipe. 

Entering the world of data integration, particularly with iPaaS solutions as dynamic as Boomi, can often feel like navigating uncharted territory. For people who know Boomi, know that it is a powerful integration tool. For Boomi developers, whether you're consulting or in-house, each project presents its unique set of unknowns - be it an unfamiliar target system or a new aspect of a well-known cloud platform. IT professionals can fall into traps and make common integration mistakes. This article aims to demystify the process, offering a step-by-step approach to fearless Boomi and iPaaS integration, ensuring you start on solid ground.

Here are some considerations for getting started on Boomi integrations or iPaaS integrations in an unfamiliar environment:

Step 1: Understanding Your Project

Initial Review: Getting started with Boomi should begin with a thorough examination of the statement of work, requirements, or any available documentation. This sets your foundation. 

Boomi Environment Familiarization: Identify the necessary connectors and endpoints and organize your project with well-structured folders. One way to do this is through a Boomi Assessment with a professional. 

Step 2: Connector Configuration

Before configuring connectors, you need to determine what you need to connect Boomi with. This should be relatively easy depending on your business requirements. Some popular connectors could be, NetSuite, Salesforce, SAP, Workday, etc.

Creating Connectors: Ideally you will be using Boomi “named”, or pre-configured connectors.  There are now 300+ available in the Boomi builder.  Establish the essential connections with at least a login and a password/token. Additional configurations may be required.

Testing Connectors:  Test the connectors by doing an import in a connector operation, and verify the connector is pulling back metadata from the end-point system.

Step 3: Integration Planning

Choosing Your First Process: Decide on the integration process to tackle first, based on the business process sequence or its complexity. You can also decide on it based on the first in the business process sequence, or a master data integration, or the easiest.

Source System Analysis: Log into the TEST source system as a user, and identify a test source record for the integration.  Get someone to show you if you don’t know the system.  Look at the data in the UI, record its ID.  Of course, you need permission, and access to a Sandbox or a Test system.  New integrations can be built in production environments, but this is not advised, as you really need to know how to minimize the risk to production data and operations.

Step 4: Process Creation and Testing

Building a Test Process: Create a basic two-step process (Start Connector and Stop) Make a connector operation that queries the source record for your integration. Use the ID as the parameter.

Record Examination: Run a test and pull down the record.  View and download the document.  Put it in an editor and take a good look at it. If it's XML, use a tool like notepad++ with the XML plugin.  Compare it to what you saw in the UI.  This is the starting point of your Integration.

Step 5: Target System Integration

Target System Exploration: Investigate the target system for a record like your integration goal, understanding the required fields and structures.

Record Creation: Using the UI, make one of the records that the integration will make.  Integrations create objects in the target system - that is what they do.  Almost always, there is a manual way to do this through the UI.  Walk through the steps in the UI, and make the target record.  Get someone to show you if you can’t figure it out.  Note what fields are required, and what connections are made to reference objects - you will have to make these, as well.  Try to fill in the absolute minimum of fields - only what is required.  Note the ID of the record you created.

An alternative way to do this is with a CSV file upload to the platform - you can gain insights into what fields are required, and the mappings this way, as well.

Step 6: Process Development

Building a Process: Create another two-step test process, this time pull the target object you just created from the target system.

Iterative Mapping and Testing: Run it in a test using the ID of the object you just made in the UI - pull down the record, and put it in your editor and look at it.

Reviewing Created Objects: Review it carefully - line by line.  Note the internal IDs (foreign keys) to child or parent objects.  Particularly note the header-line structure, if present.  What is in the line and what is in the header?

First Process Version: Now you are ready to build the first version of your process - make a separate folder for it, under your project folder.  The previous test processes belong in a z-dev folder within your project folder.  But, Boomi folder structure is a whole separate topic. The Start shape is the same as your first test.  The third step is a connector that does a Create, Update or Upsert to the target system and object. The middle step is a map with the source profile on the left and the target profile on the right.

Mapping and Test Runs: Now start an iterative process of mapping and test runs.  You may be tempted to map as many fields as seem to match.  In fact, you want to map the minimum set of fields needed to create the new object.  This is where the art comes in - map a few fields, run a test, look at the error message about a missing field, and map the field that causes the error. Repeat until you can create a new object in the target system.

Step 7: Enhanced Integration Process

Complexity and Test Case Expansion: Log into the target system, and look at the new Object in the UI.  Does it look like the others?  Anything missing?  You map the minimum fields to start with for several reasons:  With few fields, it is easier to find errors.  Fields often require foreign keys that you may not know how to find yet.  Many fields are filled with defaults, which you want to use until you are told otherwise.  And, some systems (notably Netsuite) create different types of objects based on the fields that are filled, or not.  So start at the minimum.

After this start, it is an iterative process - more complexity and test cases in the source, and looking up or locating the fields you need to fully populate the target object.  Plus your query and handshake strategy, validation and error handling, and of course the exception conditions.

Ready to Embrace Fearless Integrations? 

Although there are variations, the above process works well for most cloud-based targets with XML profiles, where there can be many hundreds of fields, and you don’t have a detailed mapping document.  If you have been through Boomi training, you should be able to follow the above steps.

Integration is not easy. Something is always unfamiliar, the instance has a unique configuration, and the customer’s business processes are a little different, or very different.  That is why integration is an area of risk for most projects, and is not for everyone. With the right support, you can ensure fearless integrations. 

Contact Kitepipe for seamless integrations and support on your next project.