Overview of This Article
- The scope of this article discusses integration of Tulip with transactional business systems, e.g. ERPs.
- The purpose of this article is to provide the following:
- A high-level overview of what is possible.
- What an ideal integration looks like.
- What other integration options exist when an ideal integration is not possible or practical.
Tulip's Position Within an Enterprise Data Flow
In the image below you will see at a high level Tulip's position within an enterprise data flow. Tulip can integrate to an ERP or other transactional business systems for whatever use cases determined to be appropriate and relevant by manufacturing operations.
Knowledge Base Articles with Guidance on Planning an Integration
Premises & Principles of an Ideal Integration
Premises & Principles
- Maintain a single Source of Truth / System of Record.
- Keep the integration: Simple, Current, and Performant.
Assumptions
- The Source of Truth has the latest and greatest information for that which the system is the Source of Truth.
- The Source of Truth can be integrated via HTTP REST APIs.
- The Source of Truth's architecture and integration use case(s) allow for an "ideal" integration architecture.
Ideal Integration Defined
- Integrate with the Source of Truth in real-time via HTTP Connectors
- This option is listed as 'Option 1' in the discussion below.
Factors That May Prevent an Ideal Integration
Various factors can prevent a Tulip customer from integrating to a transactional business system in the aforementioned Ideal way. These factors include and are not limited to the following:
- The Source of Truth has recurring long downtimes for scheduled maintenance.
- Hard business requirements mandating a manufacturing solution is not in any way dependent on real-time availability of Sources of Truth, e.g. in case the Source of Truth is unavailable due to an unexpected interruption/outage.
- The performance of the Source of Truth makes certain integration use cases (e.g. fetching several hundred components for an Order's BOM) impractical to execute in real time.
- I.T. leadership disallows direct integrations to the Source of Truth
Typical ERP/Tulip Integration Use Cases
The image below illustrates some of the most common use cases in which Tulip is typically integrated with an ERP. This is by no means an exhaustive list but rather meant to be representative of common integrations and a reference for further discussion herein.
Generally each of these posts (e.g. 'Get BoM') is correlated with a given API endpoint of the ERP. For the API endpoints relevant to your integration use case(s) you would build a Connector Function.
Options to Integrate Tulip to Transactional Business Systems
The following high-level diagram shows the broad variety of options with which Tulip can be integrated to a transactional business system. The numbers on the left represent the typical order of recommendation but also (somewhat) the popularity of the options used.
Optional iPaaS
Note: the yellow dashed iPaaS boxes represent an architectural choice. An iPaaS is not always necessary but could be used by a customer as part of the architecture for various reasons (e.g. automatic retry of posts that time out, middleware logging, etc...). Alternatively to an iPaaS a customer might use custom scripting (e.g. with Python) or in the case of Architecture 1, integrate directly to the Business System without an iPaaS.
- Why use an iPaaS?
- To provide (with custom development) modern API endpoints if the Business System does not have those already available.
- Enable automated retries on API timeouts.
- API logging (enables better debugging when needed).
- Which iPaaS?
- Tulip does not have any specific recommendations regarding which iPaaS (but Boomi & Mulesoft are common choices used by our customers).
Tulip consistently recommends Option 1 whenever possible.
The purpose of this article is to provide high-level guidance on the art of the possible. Tulip can offer some guidance and advisement on the various options discussed herein, however ultimately it is up to a Tulip Customer to determine which of these architecture options is practical and sensible based on various factors, including the Factors That May Prevent an Ideal Integration, a customer's own resource availability and internal expertise thereof, and limits of the Tulip platform.
Option 1 - Real-Time Integration via HTTP Connector
The first row in the 'Options to Integrate' diagram represents the Ideal Integration architecture discussed earlier and uses HTTP Connectors. This is by far the most common method with which Tulip customers integrate to transactional business systems such as ERPs. The implementation of such an integration via HTTP Connectors is discussed at great length elsewhere in Knowledge Base and Tulip University.
Key Knowledge Base Resources Relevant to Integration via HTTP Connectors
Tulip University Courseware on HTTP Connectors
Ideal Integration with Cloud-Based Business System
The below diagram dives a little deeper into this ideal integration. This shows an individual Connector and Connector Function in use on a given Trigger Action.
Option 2 - Real-Time Integration via SQL Connector
If all of the following apply, integration via SQL Connector is often the next best option:
- HTTP REST APIs are not available in the Business System.
- Tulip's SQL Connector supports connectivity to the Business System's database.
- A Customer's I.T. allows connectivity to the database via SQL statements or stored procedures.
Fundamental Materials in Knowledge Base & University for Option 2
Option 3 - Asynchronous Integration via Tulip Table Records
The third row in our 'Options to Integrate' diagram shows an asynchronous integration between a Business System and Tulip via Tulip Table records using the Tulip Table APIs.
This commonly involves an iPaaS or custom scripting wherein integration-relevant content (e.g. newly-released Work Orders) are posted into their corresponding Tulip Table(s) on a regular basis - ideally as close to real-time as possible. Customers may be able to implement this in an event-driven way wherein an order being released in ERP triggers an iPaaS workflow that immediately posts data into Tulip.
The other side of the integration involves the iPaaS or custom scripting fetching content from the Tulip Tables (again via Tulip Table APIs) on a frequent basis, and then posting the content back to the destination Business System.
A common practice to keep track of data successfully sychronized back into the Business System.
Consider a Tulip Table that represents consumption of raw material lots.
- Use a Boolean-type column called something like 'Successfully Synched to ERP'
- When the Tulip app(s) create new records into this table, that column can be NULL or False.
- When the iPaaS fetches the record, and confirms the data successfully POSTed back to the Business System, the iPaaS would update that column from NULL/False to True.
- This allows the iPaaS to narrow down its 'synch back to ERP' reconciliation activities to just those Tulip Table records wherein the 'Successfully Posted Back' column is NULL or False.
Fundamental Materials in Knowledge Base & University for Option 3
Option 4 - Asynchronous Integration via 3rd-Party Database & SQL Connector
The fourth row in our 'Options to Integrate' diagram shows an asynchronous integration between a Business System and Tulip via a third-party database and a SQL Connector.
- Similar to other options, this may involve an iPaaS or database scripting as determined by the Customer's data architects.
- Regarding synchronization frequency, the same principles apply - keep the data synchronization as close to real time as possible.
Fundamental Materials in Knowledge Base & University for Option 4
Option 5 - Asynchronous Integration via Data Lake/House
The last row in our 'Options to Integrate' diagram shows a rarely used asynchronous integration between a Business System and Tulip via a Data Lake/House.
- Regarding synchronization frequency, the same principles apply as Options 3 and 4 - keep the data synchronization as close to real time as possible.
.gif)