Überblick über diesen Artikel
- Dieser Artikel befasst sich mit der Integration von Tulip in transaktionsorientierte Geschäftssysteme, z. B. ERP-Systeme.
- Ziel dieses Artikels ist es, Folgendes zu vermitteln:
- Einen allgemeinen Überblick über die Möglichkeiten.
- Wie eine ideale Integration aussieht.
- Welche anderen Integrationsmöglichkeiten es gibt, wenn eine ideale Integration nicht möglich oder nicht praktikabel ist.
Die Position von Tulip innerhalb eines Unternehmensdatenflusses
In der folgenden Abbildung sehen Sie einen allgemeinen Überblick über die typische Position von Tulip innerhalb eines Unternehmensdatenflusses. Tulip lässt sich in ein ERP-System oder andere transaktionsorientierte Geschäftssysteme integrieren – für alle Anwendungsfälle, die vom Fertigungsbetrieb als angemessen und relevant erachtet werden.
Artikel aus der Wissensdatenbank mit Anleitungen zur Planung einer Integration
- Planen Sie eine Integration zwischen Tulip und einem MES oder ERP{
target=_blank} - Erstellen Sie Ihre erste Systemintegration{
target=_blank}
Voraussetzungen und Grundsätze einer idealen Integration
Voraussetzungen und Grundsätze
- Sorgen Sie für eine einzige „Source of Truth“ bzw. ein einziges „System of Record“.
- Die Integration sollte einfach, aktuell und leistungsfähig sein.
Annahmen
- Die „Source of Truth“ verfügt über die aktuellsten und besten Informationen für den Bereich, für den das System als „Source of Truth“ dient.
- Die „Quelle der Wahrheit“ kann über HTTP-REST-APIs integriert werden.
- Die Architektur der „Source of Truth“ und die Integrationsanwendungsfälle ermöglichen eine „ideale“ Integrationsarchitektur.
Definition der idealen Integration
- Integration mit der „Source of Truth“ in Echtzeit über HTTP-Konnektoren
- Diese Option wird in der folgenden Erörterung als„Option 1“ aufgeführt.
Faktoren, die einer idealen Integration im Wege stehen können
Verschiedene Faktoren können einen Tulip-Kunden daran hindern, eine Integration in ein transaktionsbasiertes Geschäftssystem auf die oben beschriebene ideale Weise durchzuführen. Zu diesen Faktoren gehören unter anderem die folgenden:
- Die „Source of Truth“ weist wiederholt lange Ausfallzeiten aufgrund geplanter Wartungsarbeiten auf.
- Strenge geschäftliche Anforderungen, die vorschreiben, dass eine Fertigungslösung in keiner Weise von der Echtzeitverfügbarkeit der „Source of Truth“ abhängig ist, z. B. für den Fall, dass die „Source of Truth“ aufgrund einer unerwarteten Unterbrechung oder eines Ausfalls nicht verfügbar ist.
- Die Leistung der „Source of Truth“ macht die Ausführung bestimmter Integrationsanwendungsfälle (z. B. das Abrufen mehrerer hundert Komponenten für die Stückliste eines Auftrags) in Echtzeit unpraktikabel.
- Die IT-Führung verbietet direkte Integrationen in die „Source of Truth“
Typische Anwendungsfälle für die ERP/Tulip-Integration
Die folgende Abbildung veranschaulicht einige der häufigsten Anwendungsfälle, in denen Tulip typischerweise in ein ERP-System integriert wird. Diese Liste erhebt keinen Anspruch auf Vollständigkeit, sondern soll vielmehr als Beispiel für gängige Integrationen dienen und als Referenz für die weitere Diskussion in diesem Dokument.
Im Allgemeinen ist jeder dieser Befehle (z. B. „Get BoM“) mit einem bestimmten API-Endpunkt des ERP-Systems verknüpft. Für die API-Endpunkte, die für Ihre Integrationsanwendungsfälle relevant sind, würden Sie eine Connector-Funktion erstellen.
Optionen zur Integration von Tulip in transaktionale Geschäftssysteme
Das folgende Übersichtsdiagramm zeigt die große Vielfalt an Möglichkeiten, wie Tulip in ein transaktionales Geschäftssystem integriert werden kann. Die Zahlen auf der linken Seite geben die typische Reihenfolge der Empfehlungen wieder, spiegeln aber auch (in gewissem Maße) die Beliebtheit der verwendeten Optionen wider.
Optionales iPaaS
Hinweis: Die gelb gestrichelten iPaaS-Kästchen stellen eine architektonische Entscheidung dar. Ein iPaaS ist nicht immer erforderlich, könnte aber von einem Kunden aus verschiedenen Gründen als Teil der Architektur genutzt werden (z. B. automatische Wiederholung von Posts, bei denen eine Zeitüberschreitung auftritt, Middleware-Protokollierung usw.). Alternativ zu einem iPaaS könnte ein Kunde benutzerdefinierte Skripte (z. B. mit Python) verwenden oder im Fall von Architektur 1 eine direkte Integration in das Geschäftssystem ohne iPaaS vornehmen.
- Warum ein iPaaS nutzen?
- Um (mit kundenspezifischer Entwicklung) moderne API-Endpunkte bereitzustellen, falls diese im Geschäftssystem noch nicht vorhanden sind.
- Automatische Wiederholungsversuche bei API-Zeitüberschreitungen zu ermöglichen.
- API-Protokollierung (ermöglicht bei Bedarf eine bessere Fehlerbehebung).
- Welches iPaaS?
- Tulip gibt keine konkreten Empfehlungen hinsichtlich der Wahl eines iPaaS ab (Boomi und Mulesoft sind jedoch gängige Lösungen, die von unseren Kunden genutzt werden).
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{target=_blank}.
Option 1 – Echtzeit-Integration über HTTP-Konnektor
Die erste Zeile im Diagramm „Integrationsoptionen“ stellt die zuvor besprochene ideale Integrationsarchitektur dar und nutzt HTTP-Konnektoren. Dies ist bei weitem die gängigste Methode, mit der Tulip-Kunden eine Integration in transaktionale Geschäftssysteme wie ERPs vornehmen. Die Umsetzung einer solchen Integration über HTTP-Konnektoren wird an anderer Stelle in der Knowledge Base und der Tulip University ausführlich behandelt.
Wichtige Knowledge-Base-Ressourcen zur Integration über HTTP-Konnektoren
- Grundlagen zu „HTTP-Konnektoren“{
target=_blank} - Beschränkungen der Konnektoren{
target=_blank}
Kursmaterialien der Tulip University zu HTTP-Konnektoren
- Erstellen und Verwenden von HTTP-Konnektoren in Apps{
target=_blank}
Ideale Integration mit cloudbasierten Geschäftssystemen
Das folgende Diagramm geht etwas näher auf diese ideale Integration ein. Es zeigt einen einzelnen Connector und eine Connector-Funktion, die bei einer bestimmten Trigger-Aktion zum Einsatz kommen.
Option 2 – Echtzeit-Integration über den SQL-Konnektor
Wenn alle folgenden Punkte zutreffen, ist die Integration über den SQL-Konnektor oft die nächstbeste Option:* Im Geschäftssystem sind keine HTTP-REST-APIs verfügbar.* Der SQL-Konnektor von Tulip unterstützt die Anbindung an die Datenbank des Geschäftssystems{target=_blank}.* Die IT-Abteilung des Kunden ermöglicht die Anbindung an die Datenbank über SQL-Anweisungen oder gespeicherte Prozeduren.
Grundlegende Materialien in der Wissensdatenbank und der University für Option 2
- SQL-Konnektoren{
target=_blank} - Einschränkungen der Konnektoren{
target=_blank} - Tulip University – SQL-Konnektoren{
target=_blank}
Option 3 – Asynchrone Integration über Tulip-Tabelleneinträge
Die dritte Zeile in unserem Diagramm „Integrationsoptionen“ zeigt eine asynchrone Integration zwischen einem Geschäftssystem und Tulip über Tulip-Tabelleneinträge unter Verwendung der Tulip-Tabellen-APIs.
Dies erfolgt in der Regel über eine iPaaS-Lösung oder benutzerdefinierte Skripte, bei denen integrationsrelevante Inhalte (z. B. neu freigegebene Arbeitsaufträge) regelmäßig – idealerweise so nah wie möglich an der Echtzeit – in die entsprechenden Tulip-Tabellen übertragen werden. Kunden können dies möglicherweise ereignisgesteuert umsetzen, wobei die Freigabe eines Auftrags im ERP-System einen iPaaS-Workflow auslöst, der die Daten sofort in Tulip überträgt.
Die andere Seite der Integration besteht darin, dass das iPaaS oder das benutzerdefinierte Skript regelmäßig Inhalte aus den Tulip-Tabellen (ebenfalls über die Tulip-Tabellen-APIs) abruft und diese Inhalte anschließend wieder an das Ziel-Business-System überträgt.
Eine gängige Vorgehensweise, um den Überblick über die erfolgreich in das Geschäftssystem zurückgesynchronisierten Daten zu behalten.
Stellen Sie sich eine Tulip-Tabelle vor, die den Verbrauch von Rohstoffchargen darstellt. * Verwenden Sie eine Spalte vom Typ „Boolean“ mit einer Bezeichnung wie „Erfolgreich mit ERP synchronisiert“.* Wenn die Tulip-Anwendung(en) neue Datensätze in dieser Tabelle anlegen, kann diese Spalte den Wert „NULL“ oder „False“ annehmen.* Wenn die iPaaS-Plattform den Datensatz abruft und bestätigt, dass die Daten erfolgreich an das Geschäftssystem zurückgesendet wurden, aktualisiert die iPaaS-Plattform diese Spalte von NULL/False auf True. * Dadurch kann die iPaaS ihre Abstimmungsaktivitäten für die „Synchronisierung zurück zum ERP“ auf genau jene Datensätze in der Tulip-Tabelle beschränken, bei denen die Spalte „Erfolgreich zurückgesendet“ den Wert NULL oder „False“ aufweist.
Grundlegende Materialien in der Wissensdatenbank und der University für Option 3
- Tulip-Tabellen-API-Handbuch{
target=_blank} - Tulip Table API-Limits{
target=_blank} - Tulip University – Detailansicht der Funktionen: Table-API{
target=_blank}
Option 4 – Asynchrone Integration über eine Datenbank eines Drittanbieters und einen SQL-Konnektor
Die vierte Zeile in unserem Diagramm „Integrationsoptionen“ zeigt eine asynchrone Integration zwischen einem Geschäftssystem und Tulip über eine Datenbank eines Drittanbieters und einen SQL-Konnektor.
- Ähnlich wie bei anderen Optionen kann dies je nach Entscheidung der Datenarchitekten des Kunden den Einsatz einer iPaaS-Lösung oder von Datenbankskripten erfordern.
- Hinsichtlich der Synchronisierungshäufigkeit gelten dieselben Grundsätze: Die Datensynchronisierung sollte so nah wie möglich an der Echtzeit erfolgen.
Grundlegende Materialien in der Wissensdatenbank und der University für Option 4
- SQL-Konnektoren{
target=_blank} - Konnektor-Beschränkungen{
target=_blank} - Tulip University – SQL-Konnektoren{
target=_blank}
Option 5 – Asynchrone Integration über Data Lake/House
Die letzte Zeile in unserem Diagramm „Integrationsoptionen“ zeigt eine selten genutzte asynchrone Integration zwischen einem Geschäftssystem und Tulip über einen Data Lake/House.* Hinsichtlich der Synchronisierungshäufigkeit gelten dieselben Grundsätze wie bei den Optionen 3 und 4 – die Datensynchronisation sollte so nah wie möglich an der Echtzeit erfolgen.
Grundlegende Materialien in der Wissensdatenbank und der University für Option 5
- SQL-Konnektoren{
target=_blank} - Konnektor-Beschränkungen{
target=_blank} - Tulip University – SQL-Konnektoren{
target=_blank}
Weitere Informationen
- Tulip University – Integration in Unternehmensanwendungen{
target=_blank}