Come usare RPA per caricare 300.000 record su FileMaker Cloud in 35 minuti circa

Updated: Mar 24, 2020


Navetta dati in tempo reale
Coda RPA

Benvenuti al nostro primo post multilingue, che viene da voi in italiano, inglese, spagnolo, e "digitale". Oggi discutiamo su come eseguire upload, aggiornamenti ed eliminazioni di massa di oltre 300.000 record in FileMaker Cloud / FileMaker Server in 35 minuti circa, in modo sicuro e senza incorrere in tempi di inattività. Resisti ai tuoi cappelli, questo è sicuramente per i "pioli quadrati nei fori rotondi".


Il problema

Sia in locale o nel cloud, la maggior parte dei database multiutente spesso richiedono l'aggiornamento o lo scaricamento di routine dei dati di grandi dimensioni. Spesso i feed dati hanno origine in altri sistemi ed esistono come un file flat, sia .csv oppure ASCII a lunghezza fissa. Il metodo di scelta per tali aggiornamenti è portare il database offline ed eseguire tutte le importazioni di massa in modalità utente singolo, ma cosa succede se questa non è un'opzione?


Alcune applicazioni sono "Sempre attive", 24 ore al giorno. In sittuazini in cui ci sono tre turni di lavoro che accedono all'applicazione 24 ore su 24, il tempo di inattività massimo disponibile può essere inferiore a una (1) ora, a volte anche a meno di 30 minuti. In alcuni scenari estremi, i tempi di fermo potrebbero non essere un'opzione.


Invece di eseguire un'importazione massiva, abbiamo deciso di CREARE i record (uno per uno) utilizzando l'istruzione di "Esegui script su server" (PSoS). Il risultato è stato di grande successo, poiché siamo stati in grado di popolare in modo rapido e sicuro il nostro tavolo da 34 campi con 300.000 record circa in poco più di 33 minuti (anche da un iPad!).


Quali sono le sfide poste dai tipici processi di importazione? Ci sono diversi fattori da considerare:


1. Un'importazione blocca la tabella

Operazioni come l'importazione di record o l'esecuzione di valori "sostituisci tutto" in un campo posizionano un blocco esclusivo sull'intera tabella. Su un'importazione di 300.000 record, ciò può significare che la tabella rimarrà bloccata per un periodo di tempo prolungato fino al completamento dell'importazione.


2. Le importazioni simultanee verranno effettivamente rallentate

Se ci sono più importazioni così grandi da eseguire in diverse tabelle in un periodo di tempo limitato, non è consigliabile eseguire due o più importazioni simultanee per risparmiare tempo, poiché le prestazioni per ogni singola importazione potrebbero effettivamente risentirne. Potrebbero esserci anche conseguenze non intenzionali causate da dipendenze sconosciute come unioni tra le tabelle (come campi inseriti automaticamente / di calcolati che verrano popolati con informazioni errate a causa di calcoli incompleti).


3. Un'importazione può danneggiare i registri di ripristino all'avvio

Ad aggravare il problema è il tema dei registri delle transazioni utilizzati dal server di database per il ripristino dell'avvio. Quando si esegue un'importazione di grandi dimensioni, Claris consiglia di disabilitare la registrazione delle transazioni per evitare il potenziale danneggiamento del database. Sfortunatamente questa disabilitazione richiede un riavvio graduale del motore di database, che vanifica lo scopo di evitare i tempi di inattività del server.


4. Uno script di importazione sul lato server impiega troppo tempo

Sebbene sia una pratica più sicura, nei nostri test un'importazione pianificata lato server di oltre 300.000 record può richiedere fino a 48 ore per il completamento, anche per una tabella ristretta di meno di 40 campi. Se hai tre di queste tabelle da popolare (circa 1 milione di record da caricare) e una finestra di tempo limitata in cui farlo, quella matematica semplicemente non si somma.


5. Il tempo potrebbe essere essenziale

Mentre risultati simili possono essere ottenuti usando alcune tecniche come la commutazione della tabella "finestra scorrevole" (ottenibile tramite la manipolazione del grafico della tabella e il modello di separazione), per qualsiasi sistema OLTP sotto vincoli della finestra di manutenzione, il collo di bottiglia continua ad essere il tempo necessario per caricare i dati nel server. Per situazioni in cui i dati devono essere online "adesso", è necessario un certo sollevamento di carichi pesanti.


La soluzzione

Implementa una coda di script PSoS sul lato client usando batch e pause


Usando questo approccio, siamo in grado di eseguire l'equivalente di un "import" massivo di record dal vivo e senza interruzioni (nessun blocco della tabella, nessun file offline, ecc.). Il processo è anche ad alte prestazioni, con numerosi test su diversi server FileMaker producendo una media costante di 145-150 record al secondo.


Per funzionalità di manutenzione più complete, abbiamo esteso gli script di loop della nostra coda RPC per includere AGGIORNAMENTO selettivo, CANCELLAZIONI selettive e, facoltativamente, TRUNCA tabella. Sulla base dei nostri test, gli aggiornamenti totali e le eliminazioni totali di ogni riga nell'intera tabella hanno richiesto appena un po 'più tempo rispetto alle operazioni originali di inserimento di tutte le righe.


Ecco una panoramica delle tecniche che utilizziamo

  • Leggi da file dati: abbiamo utilizzato il passaggio Leggi da file dati per leggere l'intero file dati e salvarlo in un campo di testo globale in una tabella di lavoro.

  • Chunking/Batching: abbiamo scritto calcoli e istruzioni di script per tagliare il file dati in più batch più piccoli che possono essere inviati al server come parametro dello script.

  • Loop: per accelerare l'elaborazione dei record, un Loop si ripete da 1 al numero massimo di blocchi di dati, attivando in sequenza rapida uno script PSoS per blocco.

  • Esegui script su server: sul server, un pedice scorre il batch di dati ricevuto tramite il parametro script, elaborando un record alla volta. Il server può eseguire contemporaneamente più di queste sessioni Esegui script su server.

  • Limitazione: per evitare arresti anomali del motore di script del server o sovraccaricare le risorse del server, abbiamo sviluppato un meccanismo di autoregolazione sul lato client per mettere in pausa e riprendere la coda.

  • Vuotare tabella: per situazioni in cui è necessario cancellare la tabella e ricaricare tutti i record da zero, lo script può facoltativamente vuotare la tabella.

  • Interrompibilità: se necessario, sul lato client la coda degli script può essere messa in pausa permanente, ripresa o interrotta.

  • Automazione robotizzata di processi: oltre all'esecuzione di attività su richiesta, usando "Installa script SuTimer" abilitiamo anche l'esecuzione di attività basate su intervalli di tempo. Ciò trasforma il tuo dispositivo FileMaker in un "robot" di base per l'esecuzione di attività automatizzate (RPA).

Ora per i dettagli:


Leggi da file dati Se il file dati di origine è stato recapitato come documento in un campo Contenitore, il file viene prima esportato nella cartella Documenti sul computer, da cui può quindi essere riletto in un campo di testo (come testo normale) utilizzando l'istruzioni di script File. La lettura effettiva del file dati e l'inserimento in un campo globale di testo richiede meno di 30 secondi.

Chunking/Batching Quando si tratta di eseguire script sul server per insiemi di dati di grandi dimensioni, è necessario "alimentarlo con cucchiaio", in morsi più piccoli o il server si strozzerà nel tentativo di elaborare l'intera cosa in un solo colpo. La suddivisione dei dati è una soluzione di batch comunemente usata per sincronizzazione dei dati.

La lunghezza massima del parametro per il comando FileMaker 'Esegui script su server' è di 1 milione di caratteri. Per sicurezza e gestibilità, le dimensioni batch / chunk create dalla nostra sceneggiatura sono limitate a 560.000 caratteri, appena al di sopra del 50% di max.

Esegui script su server Conosciute anche come stored procedure, la maggior parte delle piattaforme di database supporta l'esecuzione di script su server. FileMaker Server Script Engine (FMSE), implementa questa funzionalità nell'intera linea di prodotti del server e può essere richiamato tramite Esegui script su server.

Fare la coda Il pezzo mancante del puzzle sulla piattaforma FileMaker (almeno per ora) è stato l'accodamento RPC. Sia sul lato client che sul lato server, attualmente non esiste supporto nativo sulla piattaforma FileMaker per la creazione su richiesta e la gestione di un elenco di sessioni "Esegui script su server". La programmazione delle operazioni di administrazine è disponibile, ma non è la stessa cosa di una coda PSoS.

La coda di script che noi progettiamo è autocontrollata e interrompibile. Poiché è più semplice impostare, monitorare, gestire e annullare (se necessario), questa soluzione implementa la coda lato client. Ciò significa che per eseguire questi processi di aggiornamento delle tabelle bisogna una workstation FileMaker dedicata (uno Bot FileMaker).

Monitoraggio del carico e auto-limitazione Regolando automaticamente la pausa dello script per periodi più o meno lunghi, la nostra coda di script gestisce il carico posizionato sul server nel miglior modo possibile. Sui server che supportano versione 2 dello FileMaker Admin API, la durata della pausa viene determinata monitorando l'elenco di script PSoS in sospeso. Sugli host che non supportano o non sono configurati per accettare chiamate API di amministrazione (ovvero non dispongono di certificato SSL), la durata della pausa dello script viene calcolata in base alla dimensione dei blocchi di dati.