MOR-PROC-008 Version 1 (WIP) Last Review Date: August, 2024
1. Boomi Design Principles
1.1. Common-first Approach
A key design principle of the MoreCore Boomi environment is the concept of 'common first'. This refers to the design practice of prefering the use of common components wherever possible over components that work only in the context of specific integration. When a large pool of common sub-components exists, the implementation of new integrations becomes a plug-and-play scenario, greatly reducing effort.
This allows us to:
- Maintain a consistent approach to Boomi integration design.
- Reduce effort and improve efficiency.
- Perform updates accross multiple integrations more efficiently.
Examples of this include:
- Using a common sub-process for generating an Authentication token.
- Using common profiles
- Implementing common sub-processes for repititve tasks, such as error logging and error emailing.
1.1.1. Rules
The following design rules apply when building common sub-processes:
- Common sub-processes should never reference variables or components that belong to any other integration, except the base 'COMMON' integration.
- When calling a common sub-process, the general concept is to populate the required common inputs in the specific integration process first, so the common process doesn't require any integration-specific values.
- Common sub-processes should set key outputs as common variables, which the calling integration-specific process can then read and apply to integration-specific variables where necessary.
2. Documentation
By producing high-quality documentation, we provide ourselves the following benefits:
- Consistency
- Easier debugging
- More efficient onboarding of new team members
- Knowledge sharing
2.1. Component Log
A tabulated list of components used within the Boomi platform. When creating new components and variables in Boomi, a reference to this should be added to the
The Component Log is to include:
| FIELD | DESCRIPTION |
|---|---|
| Type | The Boomi Component type, such as Process, Operation, or Profile. |
| Component ID | Part 2 and Part 3 of the name of the component. See Naming Convention below. |
| Common? | Indicates whether the component is a common Component, or not (i.e. it belongs to a specific integration). |
| Folder | The folder in which the Component is stored. |
| Name | The name of the component, as per Part 4 of the Naming Convention below. |
| Boomi Component Name | The full component name according to the below Naming Convention. In the example Component Log, this is an Excel formula that creates the four-part name for you. |
| Purpose | A brief desciption of what the component does. |
| Notes | Other useful information about the Component, such as valid values or other technical details. |
| Used In | A list of Processes that use the component. |
| Design Status | Indicates if the component has been specified in documentation prior to buidling. |
| Test Status | Indicates whether the component has been added to a test harness and tested. |
| Build Status | Indicates at what stage of. Options: 'Not Commenced', 'In Progress', 'Complete' |
2.2. Process Flow
Each process needs to be documented in full, prefereably in advance as a build plan, and followed up with a review post implementation to ensure the Process flow remains accurate.
Documentation is to include the following:
- Process ID / Name
- Description of each step in the Process.
- Notes the shape and/or purpose.
- Related Components for each step/shape.
- Notes each component and variable used in the step
- This is a critical element for debugging, as otherwise it is very difficult to identify where a variable has been used.
- Build status for each step/shape.
- Indicates at what stage of implementation the step is in.
- Values: Not Commenced, In Progress, Ready for Testing, Complete.
Examples of Prcess Flow documentation is available in Teams.
3. Naming Conventions
Each component created within Boomi is to be named according to this naming convention. This provides:
- Consistency
- Identifyable scope
- Identifyable purpose
- Searchability in documentation
Example component name:
** COMMON-CMMS.SP-01.[CMMS] Generate Auth Token **
| Part 1 | Part 2 | Part 3 | Part 4 | |||
|---|---|---|---|---|---|---|
| COMMON-CMMS | . | SP | - | 01 | . | [CMMS] Generate Auth Token |
We can see in this example that the related integration is 'COMMON-CMMS', indicating this component is a re-usable component related to CMMS. 'SP' indicates that it is a Sub-Process. '01' indicates it is the first 'COMMON-CMMS' sub-process, and part 4 shows it relates to CMMS with a purpose of generating an auth token.
3.1. Part 1 - Integration ID
| INTEGRAION ID | DESCRIPTION |
|---|---|
| COMMON | Common platform components shared across any integration. Platform agnostic. |
| COMMON-CMMS | Common components usable in any CMMS integration. |
| COMMON-MEX | Common components usable in any MEX integration. |
| COMMON-SC | Common components usable in any ServiceChannel integration. |
| SC-CMMS | Components specific to the ServiceChannel-CMMS integration. |
| MEX-CMMS | Components specific to the MEX-CMMS integration. |
3.2. Part 2 - Component Type
| CODE | COMPONENT TYPE |
|---|---|
| CON | Connection |
| DDP | Dynamic Document Property |
| DPP | Dynamic Process Property |
| M | Map |
| MF | Map Function |
| OP | Operation |
| PF | Profile |
| PP | Process Property |
| PR | Process |
| SP | Sub-process |
| TP | Test Process |
3.3. Part 3 - ID
An incremental and unique number. Two digits should be used as a minimum, i.e. 1 should be 01.
This number should be unique in the scope of integration code and component type, meaning the below are valid:
- COMMON-CMMS.SP-01
- COMMON-CMMS.PF-01
3.4. Part 4 - Name
This field is made up of two sections, [platform] and 'description', The first part is included when the component is platform specific. Section 1 is a reference to the integration not to the platform as it appears in Part 1.
Section 2 is a short description of the purpose.
Examples of Part 4:
- [CMMS] Certificate (Prod)
- [CMMS] Authenticate
- [CMMS] Modified Work Orders GET
- [SC] (Webhook) Work Order Note Added
- [Log]Error_Message