Come funzionano le integrazioni di sistema

Integrazioni di sistema in sintesi

AtroCore Integrations collega AtroPIM/AtroCore a ogni sistema che contiene o necessita dei vostri dati di prodotto, che si tratti di ERP, piattaforma di marketplace ed e-commerce, sistema multicanale e DAM, CMS e DXP, oppure PLM e PDM. Ogni scenario è personalizzato in base al vostro panorama di sistemi. Non è richiesta alcuna programmazione, ma solo configurazione. Ogni integrazione viene implementata individualmente in base ai vostri requisiti specifici e validata sui vostri dati prima del go-live, motivo per cui possiamo garantire una soluzione che funzioni nel vostro ambiente. Ecco i punti salienti di ciò che ottenete:

Scambio orchestrato secondo la vostra pianificazione

Lo scambio di dati è organizzato in Sincronizzazioni che vengono eseguite manualmente, secondo una pianificazione basata su cron fino a intervalli di un minuto, oppure in modo basato su eventi quando un record viene creato, aggiornato o raggiunge uno stato definito. Ogni tipo di dato mantiene la propria cadenza, così i dati anagrafici vengono trasferiti di notte mentre prezzi e giacenze si aggiornano ogni ora.

Qualsiasi sistema, qualsiasi metodo di trasporto

Le connessioni vengono stabilite tramite servizi web REST e SOAP, accesso diretto al database oppure scambio di file tramite SFTP, FTPS, HTTP(S) e condivisioni di rete, combinando più metodi dove risulta utile. Gli stessi meccanismi valgono on-premises, nel cloud e in panorami ibridi, con AtroCore che avvia le connessioni in uscita, così non è necessario aprire alcuna porta in entrata.

Bidirezionale e completo nella portata

I dati vengono estratti e inviati all'interno dello stesso scenario, coprendo ogni entità, attributo e relazione del sistema, incluse le vostre entità e i vostri campi personalizzati, i valori degli attributi per lingua e canale, i prezzi, le informazioni di giacenza e gli asset digitali con i relativi metadati.

Mappatura e trasformazione senza sviluppo

La mappatura a livello di campo, le impostazioni di formato per CSV, Excel, JSON e XML, i filtri, i tipi di azione, le trasformazioni di valori e gli script opzionali per la preparazione dei dati sono tutti configurazione anziché codice, così anche le strutture di origine insolite vengono gestite senza un progetto di sviluppo su misura.

Completamente trasparente per la vostra amministrazione

Tutte le configurazioni sono visualizzabili e modificabili nell'interfaccia di amministrazione, dalla Sincronizzazione fino alla mappatura di un singolo campo. La configurazione viene memorizzata come dati anziché come codice, il che la mantiene a prova di aggiornamento e consente al vostro amministratore di rispondere a una struttura di origine modificata senza un deployment né il coinvolgimento di uno sviluppatore.

Funzionamento affidabile con logging completo

I caricamenti delta e la corrispondenza dei record basata su chiavi mantengono le esecuzioni efficienti e ripetibili, i Sub-Job paralleli mantengono la velocità con grandi volumi di dati, e i tentativi automatici insieme ai file di errore risolvono la maggior parte dei problemi senza interventi manuali. Ogni esecuzione crea un Job con logging completo, monitorato tramite Widget di Dashboard e notifiche di errore.

Le sincronizzazioni orchestrano lo scambio di dati

Una Sincronizzazione è l'unità di orchestrazione di livello più alto. Definisce quali sistemi sono collegati, in quale direzione fluiscono i dati e quando viene eseguito ogni trasferimento. Ogni Sincronizzazione raggruppa i parametri di connessione, il metodo di trasporto e la logica di esecuzione di uno scenario di integrazione. Nulla è codificato in modo rigido e non è richiesto alcun prodotto middleware separato.

Configurata dal nostro team: durante il progetto di implementazione analizziamo le interfacce dei vostri sistemi, documentiamo gli endpoint, le tabelle e i formati di esportazione disponibili e concordiamo con voi quale sistema costituisce la fonte principale per ogni entità e ogni campo prima che venga costruito il primo Feed.
Tutto è visualizzabile e modificabile nell'amministrazione: tutte le configurazioni, dalla Sincronizzazione e dalla sua pianificazione fino alla mappatura di un singolo campo, vengono memorizzate come dati e gestite nell'interfaccia di amministrazione, dove un amministratore con le autorizzazioni corrispondenti può visualizzarle, modificarle ed estenderle in qualsiasi momento.
Nessun middleware aggiuntivo: il livello di integrazione fa parte della piattaforma AtroCore e viene eseguito sullo stesso server applicativo, quindi non esiste alcun prodotto ETL o iPaaS separato da licenziare, ospitare e monitorare, né un secondo punto in cui mantenere credenziali e mappature.
Esecuzione manuale, pianificata o basata su eventi: una Sincronizzazione viene avviata manualmente dall'interfaccia utente, eseguita secondo una pianificazione basata su cron fino a intervalli di un minuto, oppure attivata automaticamente quando un record viene creato, aggiornato o raggiunge uno stato definito (i trigger basati su eventi richiedono il modulo Workflows).
Cadenza indipendente per tipo di dato: ogni Sincronizzazione ha la propria pianificazione, così i dati anagrafici di prodotto vengono trasferiti di notte mentre i prezzi e i livelli di giacenza si aggiornano ogni ora, e i nuovi asset vengono prelevati non appena arrivano.
Bidirezionale per progettazione: i dati vengono estratti dal sistema collegato e inviati a esso all'interno dello stesso scenario di integrazione, incluse le entità personalizzate, i campi personalizzati e le relazioni specifiche della vostra attività.
Esecuzione basata su code: ogni esecuzione viene inviata alla coda dei job ed elaborata da worker in background, così i trasferimenti non bloccano mai le sessioni utente interattive; più Sincronizzazioni vengono eseguite contemporaneamente e il throughput viene scalato aggiungendo worker e risorse CPU anziché riprogettando l'interfaccia.

Connettività, autenticazione e topologia di rete

Il livello di trasporto viene configurato per ogni connessione e si adatta a ciò che il sistema all'altro capo offre effettivamente, che si tratti di un moderno servizio web, di un database o di un rilascio notturno di file. Le impostazioni di connessione, gli endpoint e i parametri di trasporto fanno parte della configurazione nell'interfaccia di amministrazione, così il vostro team sa sempre quale sistema viene contattato, in che modo e con quali credenziali.

Molteplici metodi di trasporto: servizi web REST e SOAP, accesso diretto al database (di norma tramite viste in sola lettura o uno schema di staging dedicato) e scambio di file tramite SFTP, FTPS, HTTP(S) o una condivisione di rete montata. I metodi vengono combinati all'interno di un'unica Sincronizzazione dove questa è l'opzione più affidabile.
Autenticazione e gestione delle credenziali: sono supportati i comuni meccanismi di autenticazione dei sistemi aziendali, tra cui chiave API, HTTP Basic e accesso basato su token, con il rinnovo automatico dei token in scadenza. Le credenziali appartengono alla connessione e non al singolo Feed, così un secret ruotato viene modificato in un unico punto.
Topologia compatibile con i firewall: AtroCore avvia normalmente la connessione in uscita, il che significa che nella vostra rete non è necessario aprire alcuna porta in entrata. Laddove il sistema esterno debba avviare la connessione, viene utilizzata la nostra API REST, protetta da un utente API dedicato, restrizioni ACL e, facoltativamente, una allowlist di IP, una VPN o il peering di rete privata.
On-premises, cloud o ibrido: gli stessi meccanismi si applicano indipendentemente dal fatto che AtroCore venga eseguito nel vostro data center, nel nostro hosting o in un panorama ibrido con servizi cloud da un lato e un ERP on-premises dall'altro.
Resiliente rispetto ai limiti del sistema remoto: la paginazione e l'elaborazione delle risposte restituite vengono configurate per ogni interfaccia, insieme ai timeout e ai tentativi automatici, così i rate limit delle API, le finestre di elaborazione batch e le brevi interruzioni sull'altro lato vengono gestiti senza intervento manuale.
Controllo degli accessi e contesto di esecuzione: l'esecuzione e la configurazione sono regolate dal sistema di ruoli e autorizzazioni, così gli operatori avviano un Job mentre solo gli amministratori designati modificano mappature, filtri o credenziali. Ogni Feed viene eseguito a nome del sistema oppure a nome dell'utente che lo avvia, il che determina le autorizzazioni applicate durante l'elaborazione.
Validato prima del go-live: le Sincronizzazioni vengono costruite e testate su un'istanza di staging con estratti reali dei vostri dati, quindi trasferite in produzione con i parametri di connessione scambiati, così la prima esecuzione produttiva non è la prima esecuzione.

Le sincronizzazioni si compongono di Feed di importazione ed esportazione

I Feed di importazione/esportazione sono i blocchi eseguibili di una Sincronizzazione. Ogni Feed definisce una direzione, un ambito di dati e un formato, e la sua configurazione completa rimane visualizzabile e modificabile nell'amministrazione. Una Sincronizzazione raggruppa tutti i Feed richiesti dallo scenario, ciascuno con una configurazione individuale e una posizione definita nell'ordine di esecuzione. È qui che diventa visibile quanta parte dell'integrazione controlla il vostro stesso team.

Un Feed per ambito di dati e direzione: una singola Sincronizzazione può contenere un Feed di importazione per le classificazioni da SAP Business One, un secondo per i dati anagrafici di prodotto e un Feed di esportazione che pubblica contenuti di prodotto arricchiti verso Microsoft Dynamics o il vostro negozio online.
Configurazione individuale per Feed: origine e destinazione, definizione dell'endpoint o del file, mappatura, filtri, tipo di azione, validazione e gestione degli errori vengono impostati per ogni Feed, così una modifica a un Feed lascia inalterato ogni altro Feed e può essere testata in isolamento.
Ordine di esecuzione deterministico: l'ordine di ordinamento all'interno della Sincronizzazione risolve le dipendenze in modo affidabile, ad esempio importando classificazioni e attributi prima dei corrispondenti valori degli attributi, oppure creando i prodotti prima che vengano scritte le loro relazioni e assegnazioni di asset.
Adapter con template di configurazione: per gli obiettivi di integrazione ricorrenti forniamo Adapter che incapsulano le definizioni degli endpoint, le strutture dati e la logica di elaborazione del sistema esterno, aggiungono tipi di feed dedicati e includono template preconfigurati per le impostazioni di connessione e mappatura, il che riduce la configurazione ed elimina un'ampia categoria di errori manuali.
Riutilizzabile e duplicabile: un Feed esistente viene duplicato e adattato anziché ricostruito, il che mantiene coerenti tra loro scenari comparabili come diversi canali di vendita, stabilimenti o filiali per paese.
La configurazione è dato, non codice: l'intera impostazione viene memorizzata nel database e gestita tramite l'interfaccia di amministrazione. Non esiste alcuna interfaccia compilata né alcun core modificato, così gli upgrade di versione lasciano intatta la vostra integrazione e, quando un sistema collegato acquisisce un nuovo campo, il vostro amministratore lo aggiunge alla mappatura senza alcun deployment e senza il coinvolgimento di uno sviluppatore.
Open source: al termine del progetto, la configurazione viene consegnata con mappature e pianificazioni. Il codice sorgente della piattaforma è aperto, così il vostro team può verificare esattamente cosa accade ai vostri dati anziché fidarsi di una scatola nera.

Qualsiasi struttura di dati, incluse le vostre estensioni

I Feed non sono limitati a un insieme predefinito di campi. Ogni entità, attributo e relazione del sistema può far parte di un trasferimento, incluso tutto ciò che avete aggiunto voi stessi. L'ambito di dati di ogni Feed viene definito nell'interfaccia di amministrazione e adattato ogni volta che il vostro modello di dati o un sistema collegato cambia.

Copertura completa delle entità: i Feed indirizzano qualsiasi entità del sistema, standard o personalizzata, inclusi prodotti, categorie, classificazioni, attributi, fornitori e qualsiasi ulteriore entità richiesta dal vostro scenario.
Valori specifici per lingua e canale: i valori degli attributi vengono trasferiti per lingua e per canale, così un catalogo multilingue e i contenuti specifici per canale vengono gestiti nello stesso Feed anziché richiedere un'interfaccia separata per ogni mercato.
Relazioni, prezzi e informazioni di giacenza: le relazioni di qualsiasi cardinalità, i dati di prezzo e giacenza e le assegnazioni di categoria o classificazione vengono trasferiti insieme ai dati anagrafici a cui appartengono.
Trasferimento di asset e binari: immagini, documenti e altri file vengono importati tramite URL o da un percorso del file system, elaborando metadati, tipi di asset e assegnazioni di prodotto nella stessa esecuzione.
Campi personalizzati senza sviluppo: le entità e i campi che aggiungete voi stessi nel pannello di amministrazione sono immediatamente disponibili come origini e destinazioni di mappatura in ogni Feed, così ampliare il modello di dati non significa riscrivere l'interfaccia.
Mappatura dei dati a livello di campo: le regole di mappatura vengono definite separatamente per ogni campo di entità e ogni attributo, inclusi la colonna di origine o il percorso API, il campo di destinazione, i valori predefiniti, i contrassegni di obbligatorietà e il comportamento per i valori vuoti.
La mappatura definisce l'ambito di una scrittura: vengono scritti solo i campi contenuti nella mappatura, così i campi gestiti in un altro sistema o arricchiti manualmente in AtroCore non vengono sovrascritti o svuotati da un'importazione che non ha motivo di gestirli.

Formati, logica di trasferimento e trasformazione dei dati

Le interfacce reali raramente forniscono i dati nella struttura che il sistema di destinazione si aspetta. La configurazione di un Feed colma questo divario senza un progetto di sviluppo su misura. Le impostazioni di formato, la modalità di trasferimento, i filtri e le trasformazioni vengono configurati per ogni Feed e rimangono completamente modificabili nell'interfaccia di amministrazione.

Trasferimenti completi e delta: i caricamenti completi vengono utilizzati per la migrazione iniziale e i piccoli set di dati di riferimento, i caricamenti delta per l'operatività quotidiana, basati su timestamp di modifica, contrassegni di variazione o la coda di esportazione del sistema di origine, il che mantiene il volume trasferito proporzionale alle modifiche effettive.
Corrispondenza deterministica dei record: i record vengono identificati tramite una chiave di business stabile come lo SKU, il numero articolo dell'ERP o un ID esterno persistito sul record di destinazione, così le esecuzioni ripetute aggiornano i dati esistenti anziché creare duplicati, e un trasferimento interrotto viene semplicemente ripetuto.
Configurazione specifica per formato: per CSV ed Excel, ciò comprende il delimitatore, il carattere di delimitazione del testo, la codifica dei caratteri, la riga di intestazione, il foglio di lavoro, i separatori decimale e delle migliaia, i formati di data e ora e il delimitatore per i campi a valori multipli. Per JSON e XML vengono invece configurati i percorsi dei nodi pertinenti.
Conversione consapevole del tipo: i valori in ingresso vengono convertiti nel tipo di dato di destinazione, il che comprende unità di misura, valute, notazioni booleane, enumerazioni mappate su opzioni di attributo e formati di numero e data specifici della locale.
Tipi di azione flessibili: inserire nuovi record, aggiornare quelli esistenti, inserire e aggiornare in un'unica passata, eliminare record, oppure qualsiasi combinazione di queste azioni, definita per ogni Feed.
Filtri avanzati: il set di dati trasferito viene limitato in base ai valori dei campi, ad esempio esportando solo i prodotti con stato rilasciato, solo gli articoli assegnati a uno specifico Marketing Channel, oppure solo i record modificati dall'esecuzione precedente.
Trasformazioni: le trasformazioni vengono eseguite prima che i dati vengano importati o esportati e comprendono tabelle di mappatura dei valori, come un codice colore dell'ERP tradotto in un'opzione di attributo, la conversione di unità e valute, le operazioni sulle stringhe e la concatenazione o la suddivisione dei campi.

Elaborazione, gestione degli errori e protocollazione completa

Ogni esecuzione di un Feed crea un Job che documenta cosa è stato trasferito, cosa è stato saltato e cosa è fallito, fino al livello del singolo record e campo. Questa è la parte con cui il vostro team lavora nell'operatività quotidiana, e risponde alla domanda su cosa sia accaduto durante l'esecuzione della notte precedente senza doverlo indovinare.

Script per la preparazione e l'elaborazione dei dati: laddove la configurazione standard non sia sufficiente, gli script vengono collegati a un Feed di importazione o esportazione per preparare o elaborare i dati prima che vengano importati o esportati, il che mantiene la logica specifica del caso all'interno della configurazione del Feed anziché distribuirla tra i sistemi collegati.
Validazione prima della scrittura dei dati: i campi obbligatori, i tipi di dato, le opzioni consentite e l'integrità referenziale vengono verificati durante l'elaborazione, così un record non valido viene rifiutato con un messaggio leggibile anziché degradare silenziosamente la qualità dei vostri dati.
Sub-Job paralleli: i payload di grandi dimensioni vengono suddivisi automaticamente in Sub-Job elaborati in parallelo dai worker della coda, il che mantiene i tempi di esecuzione prevedibili per set di dati come i record di prodotto con un elevato numero di valori di attributo.
Elaborazione degli errori ottimizzata: gli errori transitori come i timeout di rete o i blocchi dei record vengono ritentati automaticamente, un record in errore viene isolato anziché interrompere l'intera esecuzione, e un file di errori contenente solo le righe rifiutate insieme ai relativi messaggi può essere esportato, corretto e reimportato. I tentativi manuali sono disponibili per i Job principali e per i singoli Sub-Job.
Protocollazione completa: ogni Job memorizza l'ora di inizio e di fine, la durata, l'utente o il trigger che lo ha avviato, il numero di record creati, aggiornati, eliminati, saltati e falliti, oltre a voci per ogni record con il payload di origine e il messaggio risultante.
Monitoraggio e notifica tramite Dashboard: i Widget del Dashboard mostrano a colpo d'occhio lo stato e la cronologia dei Job recenti, e gli errori vengono segnalati tramite notifica in-app o e-mail, così un'esecuzione fallita viene notata il giorno stesso in cui si verifica anziché alla successiva revisione dei dati.
Housekeeping e conservazione: i Job, le voci di log e i file trasferiti sono soggetti a una conservazione configurabile, il che mantiene il database compatto e supporta i requisiti di protezione dei dati quando i dati trasferiti contengono informazioni personali.

FAQ

Come implementate un'integrazione?

Iniziamo analizzando le interfacce dei sistemi coinvolti e documentando quali endpoint, tabelle o formati di esportazione sono effettivamente disponibili, quindi concordiamo con voi quale sistema costituisce la fonte principale per ogni entità e ogni campo. Su questa base, configuriamo una o più Sincronizzazioni con i loro Feed di importazione/esportazione, definiamo l'ordine di esecuzione, le regole di mappatura, i filtri e la pianificazione, e validiamo il tutto su un'istanza di staging con estratti reali dei vostri dati prima del passaggio in produzione.

Quali dati possono essere sincronizzati?

Qualsiasi dato che i sistemi coinvolti possono fornire. Ciò comprende i dati anagrafici di prodotto con valori di attributo per lingua e canale, categorie e classificazioni, prezzi e livelli di giacenza, asset digitali con i relativi metadati, fornitori, clienti e ordini, oltre a ogni entità e ogni campo personalizzati che avete aggiunto voi stessi. I campi che create nel pannello di amministrazione sono immediatamente disponibili come origini e destinazioni di mappatura, così ampliare il vostro modello di dati non significa ricostruire l'interfaccia.

Come vengono sincronizzati i dati?

Tramite richieste alle API REST, SOAP e GraphQL, query dirette al database (di norma su viste in sola lettura o su uno schema di staging dedicato) oppure scambio di file tramite SFTP, FTPS, HTTP(S) e condivisioni di rete montate. Il metodo più adatto viene selezionato individualmente per ogni caso, e più metodi vengono combinati all'interno di un unico scenario dove questa è l'opzione più affidabile per i sistemi all'altro capo.

La sincronizzazione avviene in tempo reale?

Può avvenire in tempo quasi reale. Ogni Sincronizzazione viene eseguita manualmente, secondo una pianificazione basata su cron fino a intervalli di un minuto, oppure in modo basato su eventi quando un record viene creato, aggiornato o raggiunge uno stato definito, con i trigger basati su eventi che richiedono il modulo Workflows. La maggior parte dei progetti combina le modalità, ad esempio un'esportazione basata su eventi dei prodotti rilasciati verso il negozio più un'esecuzione di riconciliazione notturna.

Ho bisogno di middleware aggiuntivo per questo?

No. Il livello di integrazione fa parte della piattaforma AtroCore e viene eseguito sullo stesso server applicativo, quindi non esiste alcun prodotto ETL o iPaaS separato da licenziare, ospitare e monitorare, né un secondo punto in cui mantenere credenziali e regole di mappatura.

Posso modificare le configurazioni in un secondo momento?

Sì. Tutte le configurazioni sono visualizzabili e modificabili nell'interfaccia di amministrazione, dalla Sincronizzazione e dalla sua pianificazione fino alla mappatura di un singolo campo, e non è richiesta alcuna programmazione. Poiché la configurazione viene memorizzata come dati anziché nel codice, il vostro amministratore la adatta quando un sistema collegato aggiunge una colonna o cambia un formato, senza alcun deployment e senza il coinvolgimento di uno sviluppatore.

L'auto-integrazione è un'opzione?

Tecnicamente sì, dato che nulla è nascosto e la piattaforma è open source, ma richiede una solida conoscenza delle interfacce di entrambi i lati e della configurazione dei feed stessa. Consigliamo di lasciare che siamo noi a costruire e documentare lo scenario iniziale e a consegnarlo al vostro team, che poi lo mantiene ed estende in modo autonomo. È così che lavora la maggior parte dei nostri clienti; ad esempio, noi colleghiamo l'ERP e loro aggiungono da soli ulteriori feed per il proprio negozio e i propri marketplace.

Un aggiornamento di AtroCore/AtroPIM comprometterà la mia integrazione?

No. Le vostre Sincronizzazioni, i feed e le regole di mappatura risiedono nel database, e non è coinvolto alcun core modificato, così gli aggiornamenti di versione lasciano intatta la configurazione dell'integrazione.

Funziona anche se il mio ERP è on-premises e AtroCore è in hosting?

Sì. Gli stessi meccanismi si applicano on-premises, nel nostro hosting e negli ambienti ibridi. Quale lato avvia la connessione e quale metodo di trasporto viene utilizzato sono decisioni di configurazione che prendiamo insieme al vostro team IT durante il progetto.

Come vengono gestiti le credenziali e l'accesso alla rete?

Le credenziali appartengono alla connessione e non a un singolo Feed, così un secret ruotato viene modificato in un unico punto e i token in scadenza vengono rinnovati automaticamente. AtroCore avvia normalmente le connessioni in uscita, il che significa che nella vostra rete non è necessario aprire alcuna porta in entrata. Laddove il sistema remoto debba avviare la connessione, l'accesso avviene tramite la nostra API REST, limitata da un utente API dedicato, regole ACL e, facoltativamente, una allowlist di IP o una VPN. I diritti di configurazione e di esecuzione sono separati per ruolo, e ogni Feed viene eseguito a nome del sistema oppure a nome dell'utente che lo avvia.

Quanti dati possono essere trasferiti e quanto dura un'esecuzione?

Le esecuzioni vengono elaborate da worker in background nella coda dei job anziché in una sessione utente, e i payload di grandi dimensioni vengono suddivisi automaticamente in Sub-Job elaborati in parallelo, il che mantiene i tempi di esecuzione prevedibili per cataloghi con un elevato numero di valori di attributo. Il throughput scala con il numero di worker e le risorse CPU disponibili. I trasferimenti delta basati su timestamp di modifica o contrassegni di variazione mantengono il volume giornaliero proporzionale alle modifiche effettive anziché alle dimensioni del vostro catalogo.

Cosa succede se un'esecuzione fallisce o l'altro sistema non è disponibile?

I problemi transitori come i timeout di rete o i blocchi dei record vengono ritentati automaticamente, e un record in errore viene isolato anziché interrompere l'intera esecuzione. Le righe rifiutate vengono esportate come file di errori insieme ai relativi messaggi, corrette e reimportate, e sia i Job principali sia i singoli Sub-Job possono essere ritentati manualmente. Poiché i record vengono abbinati tramite una chiave di business stabile come lo SKU o un numero articolo ERP, ripetere un'esecuzione aggiorna i dati esistenti anziché creare duplicati.

Un'importazione può sovrascrivere dati che gestiamo manualmente?

Vengono scritti solo i campi contenuti nella mappatura, così i valori gestiti in un altro sistema o arricchiti manualmente in AtroCore non vengono sovrascritti o svuotati da un'importazione che non ha motivo di gestirli. Durante il progetto, definiamo per ogni entità e per ogni campo quale sistema è la fonte principale, il che impedisce a due sistemi di contendersi lo stesso valore.

Ottengo dei log?

Sì. Ogni esecuzione di un Feed crea un Job che registra l'ora di inizio e di fine, la durata, l'utente o il trigger che lo ha avviato e il numero di record creati, aggiornati, eliminati, saltati e falliti, fino al livello delle voci per ogni record con il payload di origine e il messaggio risultante. I Widget del Dashboard mostrano a colpo d'occhio lo stato e la cronologia dei Job recenti, e gli errori vengono segnalati tramite notifica in-app o e-mail.

Come vengono gestiti i dati personali nei file trasferiti e nei log?

I Job, le voci di log e i file trasferiti sono soggetti a una conservazione configurabile, così i dati contenenti informazioni personali non vengono conservati più a lungo di quanto necessario per l'analisi degli errori e la rielaborazione. Insieme all'accesso basato sui ruoli ai Job e alle configurazioni, ciò supporta gli obblighi di documentazione e cancellazione che vi competono ai sensi del GDPR.