Nozioni di base sull’architettura per l’integrazione di Tulip in un sistema aziendale transazionale

Panoramica dell’articolo

• L’ambito di questo articolo riguarda l’integrazione di Tulip con i sistemi aziendali transazionali, ad esempio gli ERP.
• Lo scopo di questo articolo è fornire quanto segue:
  • Una panoramica di alto livello delle possibilità offerte.
  • Come si presenta un’integrazione ideale.
  • Quali altre opzioni di integrazione esistono quando un'integrazione ideale non è possibile o praticabile.

La posizione di Tulip all’interno del flusso di dati aziendale

Nell’immagine sottostante è possibile osservare, a livello generale, la posizione tipica di Tulip all’interno del flusso di dati aziendale. Tulip può integrarsi con un sistema ERP o con altri sistemi aziendali transazionali per qualsiasi caso d’uso ritenuto appropriato e rilevante dalle operazioni di produzione.

Articoli della Knowledge Base con indicazioni sulla pianificazione di un'integrazione

• Pianificare un'integrazione tra Tulip e un sistema MES o ERP{target=_blank}
• Realizza la tua prima integrazione di sistema{target=_blank}

Premesse e principi di un'integrazione ideale

Premesse e principi

• Mantenere un'unica fonte di verità / sistema di registrazione.
• Garantire che l’integrazione sia: semplice, aggiornata e performante.

Presupposti

• La fonte di verità dispone delle informazioni più recenti e complete relative a ciò per cui il sistema funge da fonte di verità.
• La fonte di verità può essere integrata tramite API REST HTTP.
• L’architettura della fonte di verità e i relativi casi d’uso di integrazione consentono di realizzare un’architettura di integrazione “ideale”.

Definizione di integrazione ideale

• Integrazione con la Fonte della Verità in tempo reale tramite connettori HTTP
• Questa opzione è indicata come«Opzione 1» nella discussione riportata di seguito.

Fattori che possono impedire un'integrazione ideale

Diversi fattori possono impedire a un cliente Tulip di integrarsi con un sistema aziendale transazionale nel modo "ideale" sopra descritto. Tali fattori includono, a titolo esemplificativo ma non esaustivo, quanto segue:

• La fonte di verità subisce lunghi periodi di inattività ricorrenti per manutenzione programmata.
• Rigidi requisiti aziendali che impongono che una soluzione di produzione non dipenda in alcun modo dalla disponibilità in tempo reale delle Fonti di Verità, ad esempio nel caso in cui la Fonte di Verità non sia disponibile a causa di un'interruzione o un guasto imprevisto.
• Le prestazioni della "fonte di verità" rendono impraticabile l’esecuzione in tempo reale di determinati casi d’uso di integrazione (ad esempio, il recupero di diverse centinaia di componenti per la distinta base di un ordine).
• La direzione IT non consente integrazioni dirette con la fonte di verità

Casi d’uso tipici di integrazione tra ERP e Tulip

L’immagine sottostante illustra alcuni dei casi d’uso più comuni in cui Tulip viene tipicamente integrato con un ERP. Non si tratta affatto di un elenco esaustivo, ma piuttosto di un esempio rappresentativo delle integrazioni più comuni e di un riferimento per ulteriori approfondimenti nel presente documento.

In generale, ciascuna di queste operazioni (ad es. «Get BoM») è correlata a un determinato endpoint API dell’ERP. Per gli endpoint API rilevanti per i propri casi d’uso di integrazione, si dovrebbe creare una funzione di connettore.

Opzioni per integrare Tulip con i sistemi aziendali transazionali

Il seguente diagramma di alto livello mostra l’ampia varietà di opzioni con cui Tulip può essere integrato in un sistema aziendale transazionale. I numeri a sinistra rappresentano l’ordine tipico di raccomandazione, ma anche (in parte) la popolarità delle opzioni utilizzate.

iPaaS opzionale

Nota: i riquadri gialli tratteggiati iPaaS rappresentano una scelta architettonica. Un iPaaS non è sempre necessario, ma potrebbe essere utilizzato da un cliente come parte dell’architettura per vari motivi (ad esempio, il ritentativo automatico di invii che vanno in timeout, la registrazione nel middleware, ecc...). In alternativa a un iPaaS, un cliente potrebbe utilizzare script personalizzati (ad esempio con Python) o, nel caso dell’Architettura 1, integrarsi direttamente con il sistema aziendale senza un iPaaS.

• Perché utilizzare un iPaaS?
  • Per fornire (tramite sviluppo personalizzato) endpoint API moderni qualora il sistema aziendale non ne disponga già.
  • Per abilitare i tentativi automatici in caso di timeout delle API.
  • Registrazione delle API (consente un debug più efficace quando necessario).
• Quale iPaaS?
  • Tulip non ha raccomandazioni specifiche riguardo a quale iPaaS scegliere (ma Boomi e Mulesoft sono scelte comuni tra i nostri clienti).

Opzione 1 - Integrazione in tempo reale tramite connettore HTTP

La prima riga del diagramma "Opzioni di integrazione" rappresenta l’architettura di integrazione ideale discussa in precedenza e utilizza i connettori HTTP. Questo è di gran lunga il metodo più comune con cui i clienti di Tulip si integrano con i sistemi aziendali transazionali come gli ERP. L’implementazione di tale integrazione tramite connettori HTTP è trattata in modo approfondito in altre sezioni della Knowledge Base e della Tulip University.

Risorse chiave della Knowledge Base relative all’integrazione tramite connettori HTTP

• Nozioni fondamentali sui "connettori HTTP"{target=_blank}
• Limiti dei connettori{target=_blank}

Materiale didattico della Tulip University sui connettori HTTP

• Creazione e utilizzo dei connettori HTTP nelle app{target=_blank}

Integrazione ideale con un sistema aziendale basato su cloud

Il diagramma riportato di seguito approfondisce ulteriormente questa integrazione ideale. Mostra un singolo connettore e una funzione del connettore in uso su una determinata azione di trigger.

Opzione 2 - Integrazione in tempo reale tramite connettore SQL

Se si verificano tutte le seguenti condizioni, l’integrazione tramite connettore SQL rappresenta spesso la soluzione migliore:* Le API REST HTTP non sono disponibili nel sistema aziendale.* Il connettore SQL di Tulip supporta la connettività al database del sistema aziendale{target=_blank}.* Il reparto IT del cliente consente la connettività al database tramite istruzioni SQL o procedure memorizzate.

Materiale di riferimento nella Knowledge Base e nell’Università per l’Opzione 2

• Connettori SQL{target=_blank}
• Limiti dei connettori{target=_blank}
• Tulip University - Connettori SQL{target=_blank}

Opzione 3 - Integrazione asincrona tramite record delle tabelle Tulip

La terza riga del nostro diagramma "Opzioni di integrazione" mostra un'integrazione asincrona tra un sistema aziendale e Tulip tramite i record delle tabelle Tulip utilizzando le API delle tabelle Tulip.

Ciò comporta solitamente l’uso di una piattaforma iPaaS o di script personalizzati, in cui i contenuti rilevanti per l’integrazione (ad esempio, gli ordini di lavoro appena rilasciati) vengono pubblicati nelle tabelle Tulip corrispondenti a intervalli regolari, idealmente il più vicino possibile al tempo reale. I clienti possono implementare questa soluzione in modo event-driven, in cui l’emissione di un ordine nell’ERP attiva un flusso di lavoro iPaaS che invia immediatamente i dati a Tulip.

L’altro aspetto dell’integrazione prevede che l’iPaaS o lo scripting personalizzato recuperi frequentemente i contenuti dalle tabelle di Tulip (sempre tramite le API di Tulip Table) e li invii nuovamente al sistema aziendale di destinazione.

Una pratica comune per tenere traccia dei dati sincronizzati con successo nel sistema aziendale.

Si consideri una tabella di Tulip che rappresenta il consumo dei lotti di materie prime. * Utilizzare una colonna di tipo booleano denominata, ad esempio, «Sincronizzazione riuscita con l’ERP»* Quando le app di Tulip creano nuovi record in questa tabella, tale colonna può essere NULL o False.* Quando l’iPaaS recupera il record e conferma che i dati sono stati inviati con successo al sistema aziendale tramite POST, l’iPaaS aggiorna quella colonna da NULL/False a True. * Ciò consente all’iPaaS di restringere le proprie attività di riconciliazione relative alla “risincronizzazione con l’ERP” esclusivamente a quei record della tabella Tulip in cui la colonna “Inviato con successo” è NULL o False.

Risorse fondamentali nella Knowledge Base e nell’Università per l’Opzione 3

• Guida all’API di Tulip Table{target=_blank}
• Limiti dell’API di Tulip Table{target=_blank}
• Approfondimento sulle funzionalità di Tulip University: API Table{target=_blank}

Opzione 4 - Integrazione asincrona tramite database di terze parti e connettore SQL

La quarta riga del nostro diagramma "Opzioni di integrazione" mostra un'integrazione asincrona tra un sistema aziendale e Tulip tramite un database di terze parti e un connettore SQL.

• Analogamente alle altre opzioni, ciò può comportare l’uso di una piattaforma iPaaS o di script di database, a discrezione degli architetti dei dati del cliente.
• Per quanto riguarda la frequenza di sincronizzazione, valgono gli stessi principi: mantenere la sincronizzazione dei dati il più possibile in tempo reale.

Materiali fondamentali nella Knowledge Base e nell’Università per l’Opzione 4

• Connettori SQL{target=_blank}
• Limiti dei connettori{target=_blank}
• Tulip University - Connettori SQL{target=_blank}

Opzione 5 - Integrazione asincrona tramite Data Lake/House

L'ultima riga del nostro diagramma "Opzioni di integrazione" mostra un'integrazione asincrona, utilizzata raramente, tra un sistema aziendale e Tulip tramite un Data Lake/House.* Per quanto riguarda la frequenza di sincronizzazione, valgono gli stessi principi delle Opzioni 3 e 4: mantenere la sincronizzazione dei dati il più possibile in tempo reale.

Materiale fondamentale nella Knowledge Base e nell’Università per l’Opzione 5

• Connettori SQL{target=_blank}
• Limiti dei connettori{target=_blank}
• Tulip University - Connettori SQL{target=_blank}

Approfondimenti aggiuntivi

• Tulip University - Integrazione con le applicazioni aziendali{target=_blank}