Below are some of the best practces which can be followed while designing and developing a Process or other component in Boomi iPaaS.
👉 Create a Naming Conventions document and name the folders, Process and its related components, including the Properties (Process Property, Document Property, Dynamic Process Property, Dynamic Document Property), as per that document. The objective is to keep the names consistent across the account.
👉 Create a separate folder for the Connections and other common components, and use the components in the Processes from that folder only.
👉 Create a separate folder for POCs and create sub-folders inside this folder, with the folder name being the developer's name, for clear segregation.
👉 Reuse the components wherever possible.
👉 Select the appropriate Extensions of the Connector by clicking "Extensions → Connection Settings → Select required Connector from DropDownList", from the Process canvas ("Build" tab of Boomi platform). While performing this activity, if there's more than 1 connector present in the DropDownList, then look for the duplicate Connectors referenced in the Process, and remove them from the Process.
👉 Limit the usage of multiple Connector Call Lookups as much as possible.
👉 Write Display Name in the Shapes, especially when there are multiple Shapes of similar nature. This will help identifying the flow when debugging the process in Process Reporting → Process State.
👉 If the process is complex, it's recommended to write the Step Number (like 01, 02,...) in the Display Name, along with the above point.
👉 Use JavaScript/Groovy only when it's not possible to create the business logic using the out-of-box features. Write notes in JavaScript/Groovy code for easier understanding.
👉 For scripting, create a component (Process Script or Map Script) instead of "in-line" scripting, in both Data Process shapes and Map components.
👉 Prioritise Javascript for lightweight conditional logic and Groovy (2.4) for more complex requirements (leveraging classes).
👉 When using Groovy in custom scripts, use Groovy 2.4 and not Groovy 1.5 (now unsupported).
👉 Write notes in the process using Add Notes whenever there's a complex logic. It is also recommended to put the Notes on top of the Shape which it is meant for.
👉 Arrange the Shapes (using the Arrange button) in the Build canvas, so that the Process looks tidy.
👉 Set the Extensions for all the required components.
👉 Use Try/Catch Shape for error handling and retry wherever required. It's best to use at least 1 Try/Catch Shape in the Process and put a common error handling mechanism.
👉 Use the Parallel Processing feature of Flow Control Shape judiciously considering the data volume and runtime capacities.
👉 Use the Run each document individually feature of Flow Control Shape only when it's absolutely required.
👉 Use Add Description button to write a short description (preferably less than 100 words) on what the Process is doing.
👉 Use a Decision shape for simple/single routing decisions over a Business Rules shape.
👉 Check if multiple Decision Shapes can be replaced with a single Business Rules or Route Shape.
👉 If the number of Shapes in a Process is more, then consider grouping certain Shapes in sub-process(es) wherever possible/practical.
👉 Avoid adding components in the root folder, or someone else's project/POC folder. Put your components in the appropriate folder itself.
👉 Remove unused components from the main project folder, either by deleting them or by moving them to your POC folder.
👉 Set Tracking Fields in the process.
👉 Retain ability to "re-run" documents by avoiding "No Data" Start Shape in processes, wherever possible.
👉 When using Dynamic Process Properties, avoid enabling the "Persist this property" option unless necessary as this makes the process stateful and use additional I/O.
👉 In Exception Shape, avoid using “Current Data” as parameter within the message. Also, avoid using “Current Date/Time” and/or “Execution Id” as parameters within the message, as these are already captured by the system.
👉 In Notify Shape, avoid using “Current Data” as parameter within the message.
👉 Do not use an Exception shape and a Notify (Error) shape together, as this is redundant.
👉 Consolidate Set Property shapes when possible, by setting multiple properties at once.
👉 When opening a component or configuration with intention to only view the same, then don't click the "OK" or "Save" button when exiting them, instead use the "Cancel" or "X" button to exit them. This will ensure that you aren't accidentally saving any component/configuration.
👉 Plan for Load Testing, preferably in a dedicated Load Testing environment, for the integrations where high data volume is expected.
👉 Consider using Process Mode as Low Latency or Bridge for the real-time (API based) integrations involving high data volume, provided it's okay to capture no/limited logs in Boomi. However, ensure that the required logs are captured in some boundary system.