Fearless Boomi Integration - Tips for using Boomi and a new system
In working with Boomi Developers, the question often comes up - “how do you get started building an integration to a platform that you don’t know?” It is a good question, because it happens all the time to me, as well.
If you are a Boomi Developer working in either a consulting or an in-house role, almost every project has something new or unknown. Either a target system that you have nearer seen before, or an unfamiliar aspect of a well-known cloud platform.
I have done a lot of Netsuite integration, for instance, and almost every project has something new - here the Fulfillment object, there the Credit Memo. So it is appropriate to share how I go about building an integration into the unknown.
19 Steps For Fearless Boomi Integration
Here is how I get started in an unfamiliar environment:
Review the Statement of work, requirements, or documentation. There may not be much - but it is your starting point.
Review the Boomi environment, and find the connectors to the endpoints that you need. One or both may not exist. Make some folders for your project and processes
Create the connectors you need - at minimum a login and a password/token to the platform, sometimes more.
Test the connectors by doing an import in a connector operation, and verify the the connector is pulling back metadata from the end-point system
Pick the first integration process to do - the first in the business process sequence, or a master data integration, or the easiest
Log into the 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 you really need to know how to minimize the risk to production data and operations.
Create a 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.
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 its 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.
Log into the target system as a user, and find a record like the one you are trying to make. Take a look at it. See if the fields are familiar from the source record.
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 thru the UI. Walk thru 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.
Create another two-step test process, this time pull the target object from the target system.
Run it in test using the ID of the object you just made in the UI - pull down the record, and put it in you editor and look at it.
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?
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.
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.
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.
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 bootcamp, you should be able to follow the above steps. If the above looks daunting or completely impossible, see the link below.
As an aside - this is one aspect of why 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. I like the challenge - but you have to be fearless.
So be fearless, log into unfamiliar systems, pull down objects and study them, make a map, and build the process. You will be way ahead of where you will be if you take the first two weeks to read the 300 page API documentation. If you are not so fearless, or are in a hurry, or want to minimize your project risk, drop us a line here at Kitepipe - we will get you started on the road to Fearless Boomi Integration.