How is an integration between OpenBOM and ERP established? Part 3 of a 3 Part Blog Series

/

The previous two (2) blogs have talked about the “why” and the “what” of integrating OpenBOM with enterprise resource planning (ERP) solutions.  The inquiring minds reading this series have no doubt been clamoring the question “but how … pray tell me … how is this achieved?” Fortunately for you, that is the subject of this third blog post.

This is part 3 of a 3 part blog series.

OpenBOM leverages Nexus as the “environment bonding” platform to exchange data with ERP and other enterprise platforms such as enterprise content management (ECM), manufacturing execution systems (MES), and maintenance, repair, and operations (MRO).  Nexus is published by the vdR Group, Inc. and is a true SaaS platform facilitated by its no-code integration capabilities.

There are three primary techniques that can be used to support the integration between OpenBOM and ERP.  They include …

  • webhooks

  • polling

  • embedding activation code

The first two options represent Nexus’ no-code integration capabilities.  This is an exciting approach in that it significantly reduces the implementation period from weeks or months to literally a few days.  In turn, the user benefits by accelerating their time-to-value coupled with a much lower cost of ownership.  The third option considers the reality that in some cases OpenBOM will be integrated with older systems that have minimal API (application programming interface) capabilities.  As such, some level of development within the target application may be required. 

Webhooks

Webhooks are software code within OpenBOM and other applications that affect an action based on specified events.  For example, if during an engineering change (EC) process, the “release” stage is reached, then a webhook would be used to trigger a signal to a preconfigured end-point.  In this case, the end-point is Nexus and the “signal” is the unique ID to the EC.   

Nexus in turn “wakes up” and activates a series of what are called “transaction templates.”  These templates are preconfigured workflow steps to retrieve, process and/or submit data leveraging REST (REpresentational State Transfer) APIs of the respective applications.  APIs typically support Create, Read, Update, and Delete (CRUD) data capabilities.

In the above example, the first template uses the unique ID of the Change Order to collect the needed information from OpenBOM that includes the list of parts on the change request, their meta data, relationships and potentially design artifacts such as documents, images or even 3D formats.  Once the data is collected, it triggers the second transaction template.  In this case, the template is a part/bill of materials (BOM) release operation that processes the data and then delivers it to the target ERP solution.  Both transaction templates are comprised of significant “bookkeeping” operations. 

Polling Services

The second option is similar to the previous process … except it does not require a webhook.  The activating event is built into Nexus via its polling engine.  The polling engine is configured to “wake up” a transaction template in predefined time increments.  The time increment is based on establishing an acceptable “latency” between the two applications.  For example, keeping a synchronized BOM structure between OpenBOM and ERP might be viewed as critical for a high-volume manufacturing organization.  Hence a five (5) minute latency may be established.  However, for compliance data that may only change a few times a year, a 24-hour latency may be more than adequate.

For the polling approach, an additional transaction template is required.  This template would be activated by the polling service and query the target application for any changes that may have occurred to a specific “item type” within the latency period.  The item types can be a change process, parts, documents, requirements, etc.  For example, in the previous example, the “release” state of a change process activated the webhook telling Nexus a release of data is ready to be transferred from OpenBOM to ERP.  Now, via the polling approach, the first transaction template would be activated and look for a “release” state on an engineering change process.  If a change is detected, then the same two transaction templates used for the webhook approach would be used.

It is important to note that if a latency period is an acceptable option, then the polling approach becomes a very attractive alternative in that it completely eliminates the need for embedded functionality such as a webhook.  It is a true no-code integration.

Embedded Functionality

A common prerequisite of the two previous options are the availability of REST APIs.  Although this type of API has been around for a couple of decades, their utility has exploded in recent years.  As a result, there will be target applications in use today that do not support REST APIs.  These are typically characterized as on-premise solutions using an older software framework and architecture.

As such, there are various options that will facilitate the needed exchange of data.  These options are ultimately based on leveraging customized scripts and/or code embedded in the application.  As part of the process, the data needed for the transfer is gathered, processed, and delivered as a file to an end-point.  Activating this process is part of the embedded script or code.  The end-point can be a file folder or the Nexus platform.  Regardless of the approach, an investment has been and/or needs to be made to support this option.  This in turn requires knowledge and expertise in the tools available to support the needs of an integration and downstream maintenance requirements. 

As a true software-as-a-service (SaaS) solution, OpenBOM is ideally positioned to operate as a critical “node” in the digital thread. As noted above, the use of webhooks and/or polling services to support various integrations significantly accelerates the “time-to-value” which inherently helps to reduce the cost of quality.