How To Plan an Integration Between Tulip and an MES or ERP
  • 02 Jul 2024
  • 8 Minutes to read
  • Contributors

How To Plan an Integration Between Tulip and an MES or ERP


Article summary

Learn which questions you need to ask in order to determine the best way to integrate with your MES/ERP

Tulip has integrated with a variety of MES and ERP systems.

However, since there are many ERP and MES products on the market, it is difficult to say how easily Tulip can connect to your particular ERP or MES. It depends on:

  • The ERP/MES product itself
  • The complexity of your company’s IT environment
  • Your IT team’s capabilities around working with the ERP/MES system
NOTE

In this example, we focus on an ERP or MES system, but this information is applicable to most software systems including CRM, QMS, LMS, and BOM management systems.

Questionnaire

Many customers find that they are able to take the information in this article alone and build an integration themselves. Should you want help from Tulip with an integration to a service, providing answers to these questions is the first step to a successful project.

Strategy Questions

  1. What is the goal of the integration?

It's important to establish early on what the short-term and long-term goals for the project are. Do you need all information shared between two systems? Or does it make more sense to focus in on a few high-value exchanges at first?

  1. Who are the key stakeholders within your organization

Who is the end-customer for this integration? Who is most familiar with the service to which you would like Tulip to connect? Who will be able to organize access to the service?
Stakeholders can include, but aren't limited to:

  • Citizen Developers
  • Operations ‘Owners’ of Integrated Systems
  • IS/IT Engineering
  • Shop Floor Users Served by Solution
  1. What documentation does your service provide?

Many enterprise software customers provide documentation for their services only to paying customers. This means that Tulip will not be able to access this documentation. Obtaining access to as much documentation about your software helps scope the work required for an integration.

  1. What transactions need to be made between Tulip and the service to be successful?

Here we try to be very specific. Some examples are:

  • Get information about a work order given a work order ID.
  • Mark a work order as completed given a work order ID.
  • Find all of the open work orders assigned to a station given a station ID.
  1. Who will maintain this integration?

As new use cases are uncovered, who in your organization will be tasked with being the subject-matter expert for the integration? In some organizations, this is a 3rd party integrator or contractor.

Technical Questions

In order to determine the details of an integration, here are some questions that can guide the process:

General ERP Information

  • What ERP application and version?
  • Is the ERP deployed on-premise or in a private cloud environment?
  • Is the Tulip on-premise connector host (OPCH) able to connect to your ERP environment in its current location (i.e. there exists a network path between the OPCH and ERP?
  • Is your ERP management, development and configuration done by a partner or in-house?

ERP to Tulip Connection

  • Will Tulip be integrating directly with the ERP? Is there a middleware used to integrate other applications with the ERP (for example Mulesoft)?
  • Are there web services / API endpoints available Tulip could hit via an HTTP connector that cover the applicable use cases
  • If no API endpoints available that cover the desired Tulip to ERP transactions... is there a team that could develop these for us (either in a middleware platform or in the ERP system itself?
  • If there are web services available.. what authentication do these web services use (i.e. OAuth 2.0, HTTP Basic Auth etc)? Are service accounts used?
  • If there are web services available, what data format is returned in the response bodies (JSON (preferred) or XML?)
  • Will different environment configurations need to be setup (i.e. DEV and PROD)?
    • If so, are the host names different for each of the environments or are the environments determined by URL parameters?

Tulip to ERP Connection

  • What fields will be sent from ERP to Tulip Tables via the API?
  • How many table records at once will be posted to Tulip from ERP?
  • For a ERP to Tulip communication, this will require custom development and the use of Tulip's Table API. Is there a team that could develop this middleware?
  • For a ERP to Tulip communication, data is flowing out of the ERP... what format is it in (XML or JSON?) The Tulip Table API requires a request body in JSON format.

Tulip vs. ERP Systems - Assumed Systems of Record (Sources of Truth)

A best practice is to interact with an object's (e.g. Workorder's) system of record in real-time (typically via HTTP Connector Functions in JSON format).

The table below provides recommended do's and dont's for ERP integrations:

DoDon't
Transact with a source of truth in real-time. Ensure your shop floor is using the latest/greatest information.Cache data from a source of truth into Tulip tables that may quickly go out of date. (E.g. current on-hand inventory should live in its source of truth, and Tulip should interact with it in real-time)
Store Tulip-Centric Context in Tulip. A workorder’s source of truth may be your ERP, but certain data is relevant mainly to Tulip (e.g. non-conformances logged in Tulip against a workorder).Use Tulip for use cases that are best executed in your ERP (e.g. order planning & scheduling).
Augment operators' execution of simple ERP/WMS-centric use cases with composable integrated Tulip Apps. (E.g. Intuitive Tulip app using a tablet’s camera as a barcode scanner for common Inventory Management use cases)Use SQL Connectors if HTTP APIs are an option.

Below is a comparison of ERP systems and Tulip, and generally for what common items each system is assumed to be the system of record.
Tulip vs ERP - assumed systems of record.png

Connection Background

Generally, Tulip connects to external software systems via one of three methods:

  1. HTTP API (which includes REST and SOAP)
  2. OPC UA
  3. SQL queries

HTTP API

If your ERP/MES has an HTTP (including REST and SOAP) API, Tulip can initiate requests that can send or retrieve data through those endpoints. Tulip, with its HTTP connectors, can consume the web services exposed by an ERP system and bring the data within Tulip to be consumed by applications in real time.

Note that Tulip will need to initiate the connection as opposed to your ERP/MES when using Tulip Connectors. If the ERP/MES needs to initiate the connection to Tulip, use the Tulip Tables API

You may be able to configure the API from the administrator interface of your system. This information will be available on the software provider’s website.

SQL Database

If your ERP/MES is sharing data with a SQL database, then Tulip can also access that database and share data. This may require you to write some new queries within your ERP/MES in order to access the new data from Tulip.

If the SQL database is strictly deployed on-premises, then Tulip can deploy a Connector Host on-premises that allows the database to work with Tulip’s cloud platform.

Additionally, some organizations store their ERP/MES data in a sensitive database that is not accessible to third parties, but they still want to share data with Tulip. So, they set up a new database where they can share specific data from their software systems, and Tulip can share data without any security concerns.

Industrial Protocols

If your ERP/MES shares data via an industrial protocol, like Modbus, MTConnect and OPC UA, then Tulip can connect via a server that is running the Tulip Connector Host.

In this case, your ERP/MES will be acting like a "machine" within Tulip. Check out our Introduction to Machine Monitoring article for more details.

One-Way Data Sharing

Some ERP/MES systems have built-in methods for taking in data from external systems, but it is difficult to send their own data into other systems.

If this is the case, you may need to choose whether one-way data transfer is acceptable or if you want to invest more time and energy into finding a way to make two-way data transfer possible.

For example, you may be satisfied with making Tulip your primary system for collecting data on the shop floor. Then, after sending the data into your MES/ERP system, you can align shop floor data with the existing data in the system.

Typical Use Cases

Listed below are common scenarios that make a third-party integration optimal:

  1. Provide the Shop Floor with the latest/greatest information from each source of truth. Example from ERP: latest released orders (AND schedule), latest BOM, latest inventory, etc…
  2. Mitigate management of redundant data (e.g. the data above)
  3. Keep on-hand inventory up to date in real time: avoid rush hours of more raw materials
  4. Improved dispatching in ERP based on real-time manufacturing workcenter statuses (i.e., what workcenters are available?)
  5. ERP Orders + Tulip Unit-Level Traceability: Rapidly identify the universe of potentially defective finished products.

Further Reading


Did you find what you were looking for?

You can also head to community.tulip.co to post your question or see if others have faced a similar question!


Was this article helpful?