Integrating MES with an ERP system is one of the most common requirements in our projects. Clients often approach us with a familiar goal:

“We need MES to communicate seamlessly and securely with our ERP.”

The biggest challenges lie in authentication and scalability - ensuring that communication is not only functional but also compliant with the customer’s security protocols.

So, how do we build a solution that satisfies both simple and high-security authentication requirements, without adding unnecessary complexity?

Find out our solution!

🧩 Introduction

In many projects, MES–ERP integration follows a standard client-server model. MES acts as either the client or the server, sending and receiving information such as production orders, material data, or inventory updates.

While the integration logic itself is usually straightforward, authentication often becomes the differentiator between a quick setup and a complex implementation.

➡️ Some customers operate in closed networks or controlled environments where Basic Authentication - a simple username and password - meets all needs.

➡️ Others, especially those with stricter corporate security standards or integrations with cloud-based systems, require OAuth 2.0, which enables token-based authentication and tighter control over identity and access.

Both scenarios are valid and frequently encountered in real projects.

That’s why our solution was designed to support multiple authentication mechanisms, allowing each customer to choose what best fits their policies, and once chosen, it can always go back and configure differently without requiring architectural changes or additional complexity.

In the next sections, we will look at the project requirement, what was the challenge mid its design, and the final solution. We will focus on the architecture and also walk through a few examples of Basic and OAuth Authentication.

We believe sharing this experience can help others structure or improve their integrations solution design, and by hearing your feedback, on what we could have done different, learn new things!

📋 Requirement and Context

At the beginning of the project, the client requested multiple ERP integrations to be handled within our MES system — to receive and send data.

Initially, all integrations were designed to use Basic Authentication, a straightforward and widely supported method for secure communication.

However, as the project evolved, the client introduced a new requirement — integration with Boomi. Boomi it would require OAuth 2.0 authentication to send data, and the current designed solution did not support it.

❓ Authentication Challenge in Boomi Integrations

Because Boomi does not support Basic Authentication, this limitation quickly created a roadblock.

The integrations from MES to Boomi/Oracle would not function as expected, revealing how authentication plays a critical role when designing ERP integrations.

This challenge drove us to rethink and redesign the solution to seamlessly support both Basic and OAuth authentication.

🚀 Extending Support for OAuth Authentication

We introduced several enhancements to make the solution more flexible and maintainable:

• 1️⃣ Authentication Lookup Table: to reference the authentication method.
• 2️⃣ Integration Handler Resolution Extra Configurations: to allow the system dynamically know what authentication mechanism to apply.

With these improvements, the final solution:

• ✅ Became flexible and scalable: capable of supporting diverse authentication requirements across different clients and projects.
• ✅ Ensured future readiness: for upcoming integrations and evolving security needs.

🏗️ Solution Design and Architecture

To address the authentication requirement, we enhanced our out of the box (OOB) functionalities with new custom artifacts.

The following elements compose the final solution:

1️⃣ Smart Table — IntegrationHandlerResolution (OOB)

What it does?

• When an Integration Entry is created, the system resolves this table to determine which DEE should be triggered to process the corresponding request.

How we use it?

• In our solution, whenever MES needs to send or receive data from the ERP, an integration entry is generated.
  • When receiving data, through the API, a new Integration Entry is created, and for each different context, a new custom DEE was also created to handle it.
  • But for sending data, a exclusive DEE “ReportToERPHandler” (Custom) was created to be always defined in the table.

2️⃣ MES Configurations (Custom)

How we use it?

• All sensitive data such as credentials are managed through MES Configurations.

Why we used configurations?

• ✅ Built-in security:
  • Leverage the existing secure string mechanism to safely store and manage confidential values like passwords.
• ✅ Simplified maintenance:
  • Reuse the same configuration path (e.g., user or password) across multiple integrations, and centralize updates in one place.
  • Clean or update table entries without losing credentials value.

3️⃣ Lookup Table — AuthType (Custom)

Initialized with the values BASIC and BASIC_APIKEY_AUTH to classify supported authentication methods.

4️⃣ Smart Table — ExternalIntegrationHandlerResolution (Custom)

Example

What it does?

• The custom smart table provides an additional configuration layer when handling integrations to send data, giving us even more flexibility to configure these requests.

How we use it?

• As it was mentioned before, whenever MES needs to send data to the ERP, an Integration Entry (IE) is created. Before the IE creation, a new utility was implemented to resolve this table first, allowing the system to determine — based on the IsSync field — whether the IE should be created and executed synchronously, or simply created and executed by the system asynchronously.
• Afterwards, already at the handler of this request, the DEE “ReportToERPHandler” (Custom), configured in the first table, uses this table again to determine how to construct and send the request:
  • The AuthType field defines which authentication protocol to apply: BASIC or BASIC_APIKEY_AUTH.
  • The Endpoint field specifies the target endpoint for the request.

Note: We had to extend the Config Paths fields length to 512 characters to support longer configuration paths.

🔐 Basic Authentication

The BASIC credentials are stored in the respective configurations, where the path fields are:

• EndpointUserConfigPath: Username.
• EndpointPasswordConfigPath: Password.

The DEE retrieves these values at runtime and applies them directly in the request header.

🔐 API Key Authentication

For BASIC_APIKEY_AUTH, a Bearer Token must first be created.

How to generate the token?

• Call the endpoint specified in EndpointAuthConfigPath.
• Use Basic Authentication with credentials from:
  • EndpointUserConfigPath
  • EndpointPasswordConfigPath
• Request the token using the client_credentials grant type.
• The resulting bearer token is then applied to subsequent API requests.

Therefore, additional new configuration paths are necessary because different authentication methods (Basic, API Key, OAuth) require different sets of credentials and parameters:

• EndpointAuthConfigPath: Introduced to store OAuth-specific authentication details (e.g., client ID, client secret, token endpoint).
• EndpointAPIKeyConfigPath: Added to handle APIs that require an API key instead of username/password or OAuth.
• EndpointAPIVersionConfigPath: Provided a way to manage API versioning for external systems, ensuring integrations remain stable even if endpoints evolve.

The API request includes the Bearer Token and the proper headers from the three configuration paths — ensuring secure, versioned, and authenticated communication.

🔍 Architectural Overview Summary

The diagram below illustrates the overall architecture:

Authors

Hi! My name is Diogo Domingues. ✌️

I’m a Software Engineer at Critical Manufacturing, working in the Solution Delivery area.

You can find me on LinkedIn.

Hi! My name is Ana Rita Santos. ✌️

I’m a Software Engineer at Critical Manufacturing, working in the Solution Delivery area.

You can find me on LinkedIn.