Are your Boomi integrations performing less than optimally? You are not alone; this is a scenario we often find when we are asked to optimize Boomi Integrations for our SuccessFactors clients. Based on our knowledge of best practices, here are three things we have identified that you should avoid if you want your integrations to perform at their highest efficiency.
Querying more information than necessary: In other words, just query the information you need. It’s a simple concept that is often overlooked. We frequently find that a lot of Boomi users have set the Boomi/SuccessFactors query operation to pull all the fields available in the selected template/object.
In the first screenshot below of a Boomi Connector Operation, all the fields in the SuccessFactors Candidate Profile are being retrieved. Most likely this operation was not initially set up this way, but when a template is refreshed (to add new fields), those new fields get added and selected by default. As a result, you will end up with selected fields that are not used in the integration. This results in using a greater percentage of network overhead and increasing changes to get duplicate records in your returned query set.
A better approach is to only include those fields in the connector operation that are needed by the integration. In the revised connector operation below, only the address-related fields are being retrieved. This approach will result in faster performance, and will also be less likely to generate errors.
Making similar calls within the same integration: This usually happens when there is a need to do a picklist lookup, which may be performed multiple times within the same integration. To avoid repeating lookups, you can use a cache object to temporarily store results. Before you make your next picklist lookup, check if the item is already stored in the cache object. If it is, pull it from the cache, it’s much faster!
This practice is not limited to picklist items, but can apply to other types of data used repeatedly in the process. In terms of performance, async queries (such as ad hoc) are the slowest, and each call may take 90 seconds or more. The use of standard objects, such as application, requisition or candidate, to retrieve a specific record using an index value will also be faster, but pulling data from a cache is more efficient and is typically done in a fraction of a second. System performance will increase dramatically as the number of calls to the cache are increased while calls to the database decrease. For example, if a process makes 30 ad hoc query calls, it can take up to an hour to complete. If the data is already stored in the cache, this can be accomplished in under 5 minutes.
Below is a screenshot of a process that checks the cache before making the actual call to the SuccessFactors database.
Excessive logging for production integrations: During development or troubleshooting, you probably set up detailed logging to identify errors and troubleshoot issues more quickly. However, once the integration has been proven to work properly (usually after the first full year in production), we recommend that you reduce logging. You can continue to maintain error logging, but you don’t need to log every single record transaction and successful integration run.
These are three simple things you can stop doing or change today to optimize your Dell Boomi and SuccessFactors integration. We selected these three because they will likely not require structural changes to your integration. We have additional recommendations and best practices that will have an even bigger impact on processing time, but may require more investment in development and testing. We’ll cover some of these in future posts.
For more information, read our other posts on integrations.