Boomi Best Practices & Process Design Guidelines

As an enterprise-class integration platform providing massively scalable and flexible solutions for interconnecting business processes, Boomi is rapidly becoming one of the core technologies that high-performing organizations look to leverage when implementing a digital transformation strategy. As with any technology that provides such a broad set of capabilities, Boomi implementations can go awry if project conventions and best practices are not established at the outset. Establishing and following these project standards ensures that you have a system that is maintainable and extensible, and that new project team members can onramp quickly and efficiently. Here at XTIVIA, we have compiled a set of guidelines and best practices that will smooth your adoption of the Boomi platform, ultimately setting you up for success.

Overall Design Guidelines

• Use native Boomi functionality when possible, avoid Java/Groovy unless it is the only option. This improves overall performance and maintainability for your application.
• Use Built-In Boomi Connectors (such as Salesforce, Netsuite, or Workday Connectors) whenever possible.
• Use common framework components (such as Connections, Cross Reference tables, Map Functions) when possible; this keeps your process clean and reduces overall maintenance costs.
• Utilize common reusable processes as sub-processes in your design for functions such as error handling or sending emails or notifications.
• Enable connector level extensions in every process; extensions are very useful and can be shared among processes in different environments such as Dev, Sandbox, and Production environments.
• Utilize tracked fields for unique document identifiers when possible; this helps with logging and debugging at the record level.
• Utilize label fields in components and description fields in processes to document the purpose of the Boomi process and/or component.

Establish Folder Structure Guidelines

It is critical to establish a common folder structure across all parts of the project; the guidelines below provide some suggestions based on past Boomi projects.

• Use a common folder for connections, create a connections folder under the <organizations> root folder, to avoid duplication of connections and to promote connection reusability, and misusing of licenses. For example, if you have multiple connections created in different folders for a single endpoint and when you deploy your process, each connection will consume separate Boomi license while connecting to the same endpoint.
• Create a separate folder for each operation/API in order to clearly define the separation of duties, such as differentiating getting a customer from Netsuite from updating a customer in Netsuite.
• Consider folders as units of work that you can copy to promote component reuse for a faster implementation.
• Avoid deeply nested folders as they can create confusion over time and require higher maintenance.
• Try to keep folder names concise, matching them with the endpoints that the integration process will be connecting with.
• Organize common folders at the highest possible level.

Establish Component Naming Guidelines

Consistency in component naming is an important consideration when starting any project, and Boomi projects are no exception. Always try to provide a short, understandable name that accurately represents the purpose of the component. Below are some examples of different Boomi components:

Process Name ex: [source system] + function + type of data + action performed [destination system]

For example, a process that Inserting payments into Zuora from Netsuite.

“NS Insert Payments to Zuora Process”

Connector Name: Netsuite Connector

Connection: Netsuite: Netsuite Customer Connection

Operation: Netsuite Operation: Customer Query by InternalID

Database Connector:

Connection: Database: Master DM (MySQL)

Operation: Database Operation: Query Customer by Date

Map Component, Mapping data from Netsuite to SQL server

Map Component: Map: Netsuite to SQL Map

Define Web services Naming Convention

By the same token, web services should also be consistently named according to a scheme determined at project inception. Some guidelines for web service naming conventions are as follows:

• Web service names should clearly indicate what they do from a client’s point of view.
• The HTTP GET method should only be used for data reads; it should not be used for calls that update or change the state of data.
• Use query parameters to provide filtering, sorting, and paging if possible.
• Make sure to version your API, using the URL for the API versioning starting with the letter “v”. Example: /ucm/account/api/v1
• Make sure to handle errors using appropriate HTTP status codes; for example, for situations where a request is submitted with inadequate or invalid query data, be sure to return an HTTP 400 response code.

Establish Labeling Guidelines

Proper labeling of entities within Boomi provides implicit documentation regarding the purpose of an entity as such, and establishing a comprehensive policy regarding the labeling of processes and components is critical for both the development and maintenance teams. The benefits of establishing a standard labeling process include the following:

1. Determining document flow via the process logs will be more clearly defined.
2. Documenting processes will be easier by defining what each component does based on the assigned label.
3. The description field in the process should be utilized to define an overall description of the integration process. Also, if an internal documentation system (such as a Wiki) is being utilized for documenting the integration process, a link to the documentation should be included within the description field.

Process Development Checklist

The Development checklist helps avoid omission of steps in the process and saves surprises at the staging or production deployment.

• Are all shapes/steps connected?
  • There should be no red connector endpoints.
• Are the appropriate connector(s) assigned?
  • Make sure there are no BROWSING ONLY connectors assigned.
• Have the extensions been enabled in the process?
  • Verify that the correct connector fields have been extended.
  • Verify the appropriate process properties/dynamic process properties have been extended.
• Have the shapes/steps been properly labeled?
• Have the correct Process Options been set?
  • Purge data immediately should be set for any processes that contain sensitive data.
• Are error handling shapes/steps configured?
• Has the process been successfully unit tested?
• Were the design guidelines followed?

Establish Accountability/Maintainability Guidelines

Here are some basic principles to keep in mind, that will help you in the overall development and maintenance lifecycle of the process;

• The Boomi document tracking feature should be used.
• Implement appropriate error handling, notification, and logging.
• Use appropriate filenames (when using disk or FTP connector).
• When possible, pass internal keys from the source system to a field in the destination system. Optionally, you may also want to write keys from the destination system back to a field in the source system.
• In most cases, going directly to a Stop shape from a Route, Decision, Try/Catch, or Business Rules is discouraged. If any documents go down this branch, it will be difficult to trace after the execution is finished.
• Terminate your branches with Stop shapes, even if it will not change the results of the process. This will communicate your intentions to whoever may need to maintain your process in the future.

Guidelines for Maintainability

As a rule, there are a number of considerations to take into account that will improve the overall maintainability of your Boomi implementation. Consider the following suggestions during your implementation phase to minimize maintenance issues once your digital transformation project is live:

• Maintain a proper folder structure.
• Utilize a sensible process layout.
• Use of the notes feature is encouraged for implicit documentation.
• Make certain to use sub-processes where appropriate.
• Do not filter on minus ‘n’ days in Connector Call.
• Eliminate redundant copies of components, especially Connections.
• Ideally, use a single Connection component per endpoint for deployment (and possibly 1 more for browsing). For example, a single component for Netsuite. Use environments/extensions to point the component to sandbox/QA/production service instances.
• Keep components out of the root folder. For small accounts, putting shared Connections in the root folder is acceptable.
• Avoid using personal logins for endpoints. For example, configure your Netsuite connection to use Boomi Integration.
• Use shared components where appropriate. Keep shared components together in a shared folder.
• Ideally, have only a single copy of your process; maintaining “test copies” of your processes is discouraged.
• Changes should be done in your single process, unit tested in test mode, deployed to a test or QA environment for further testing, then promoted to production.
• If you are planning extensive changes to a process, a v2 of your process is acceptable.

General Process Guidelines

The following guidelines apply to situations that are commonly encountered during a Boomi implementation; they are intended as pointers for things to watch for during project implementation.

• Appropriate use of Options in the build tab. For example, do you want to allow simultaneous executions? Is your listener process set to Low Latency?
• The process should be designed to be re-runnable (for example, should handle Upserts rather than just Creates). This helps when re-running a process after a partially failed execution.
• Date handling in Maps. Where possible, define as a true date in both profiles, and avoid the “date convert” function.
• Decoupling process flow when appropriate (e.g., JMS or atom queues).
• Using the Business Rules shape is preferable to a group of Decision shapes.
• Using multiple Disk Connection components should be avoided. Directories can be specified in a Set Properties shape or Connector Parameters tab.
• If possible, use sync flags to select source data instead of using lastSuccessfulRunDate.
• If you need to use date for source data selection, store and use the highest date from the source system instead of using lastSuccessfulRunDate.
• Split the Document, if necessary, before a Document Cache shape.

Establish Performance Guidelines

As integration workload increases, performance and scalability become critical for organizations. Here are some guidelines to follow when designing and developing integration processes which always scale to meet performance requirements.

• Minimize Connector Calls.
• Pull data together when possible (e.g., use joins on DB selects or SaaS queries when available).
• Cache documents where appropriate.
• Use the function cache where appropriate.
• Avoid making repeated Connector or Database Calls on a per-document basis where possible. Consider caching or other techniques.
• Minimize or eliminate the use of “run each document individually” feature for high-volume processes. Batching where possible.
• Parallel processing, if needed and appropriate.
• When writing to Netsuite, consider using external ids to avoid having to look up internals. Use this logic whenever applicable.
• Eliminate the use of “map function ordering” if it is not needed.
• How many records per unit of time is this process expected to handle?
• Has it been tested at the expected volume? If high volume, is this process set up appropriately for high volume (caching, parallelism, etc.)?

Final Checks

Finally few key points to consider before deploying the integration process to production and handing it over to the support team.

• Verify that the process is tested and documented.
• High volume processes should be performance tested.
• Be sure execution instructions are documented. What should a user do if this process fails? Retry docs? Re-run process? Any resetting of flags or dates?
• Identify who will monitor executions, and how.
• Verify that proper User Management is in place.
• On bidirectional sync, be sure “ping-ponging” has been avoided. For example, if accounts are synced from system A to system B in one process, and then system B back to system A in another process, and if both processes are run using “last mod date” logic, a record could bounce indefinitely between one system and the other.

Follow these guidelines to set your Boomi project on the path to success! If you have questions on how you can best leverage Boomi and/or need help with your Boomi implementation, please engage with us via comments on this blog post, or reach out to us.