lunedì 21 settembre 2026

Free PlyxSQL© - 1.0.0.101 Super ETL

 Free PlyxSQL© - 1.0.0.101 Super ETL

POSTED BY Giuliano pagnini, 21 SETT 2026

Free DOWNLOAD Clicca qui Info https://pgsoft.it/plyxhtml


Expression Engine 2: il nuovo motore che trasforma l’ETL in intelligenza operativa



Nel mondo dell’integrazione dati non basta più spostare informazioni da una tabella a un’altra. Oggi un processo ETL deve interpretare, normalizzare, validare e classificare i dati secondo regole di business sempre più articolate.

È da questa esigenza che nasce Expression Engine 2: il nuovo motore di espressioni progettato per portare l’ETL oltre il semplice mapping, trasformandolo in una piattaforma dichiarativa, estensibile e pronta per scenari professionali.

Dal mapping alle decisioni

Un mapping tradizionale risolve un’esigenza semplice:

SOURCE.COGNOME → DEST.COGNOME

Ma i dati reali raramente arrivano già pronti per essere utilizzati.

Un cognome può contenere spazi superflui, differenze di maiuscole e minuscole, formati non uniformi o valori mancanti. In questi casi non serve soltanto copiare un campo: serve applicare una trasformazione.

SOURCE.COGNOME
        ↓
      TRIM
        ↓
     PROPER
        ↓
DEST.COGNOME

Oppure può essere necessario assegnare una classificazione in base al contenuto di uno o più campi:

SOURCE.STATO
        ↓
      CASE
        ↓
DEST.DESCRIZIONE_STATO

Expression Engine 2 nasce proprio per questo: permettere di combinare funzioni, confronti, condizioni e regole direttamente nella configurazione ETL, senza dover scrivere codice specifico per ogni singolo caso.

Un vero motore di espressioni

La differenza principale rispetto a un sistema basato su funzioni isolate è l’architettura.

Expression Engine 2 segue un flusso concettuale chiaro:

Expression
    ↓
Lexer
    ↓
Parser
    ↓
AST
    ↓
Evaluator
    ↓
Result

L’espressione non viene più gestita come una semplice stringa da analizzare con controlli successivi. Viene interpretata, trasformata in una struttura interna e poi valutata in modo coerente.

Il cuore di questa evoluzione è l’AST, Abstract Syntax Tree: un albero che rappresenta la struttura logica dell’espressione.

Per esempio, una regola come:

{STATO} = "A" AND {IMPORTO} >= 1000

può essere rappresentata internamente così:

AND
├── EQ
│   ├── FIELD(STATO)
│   └── "A"
│
└── GE
    ├── FIELD(IMPORTO)
    └── 1000

Questo approccio rende il motore più robusto, più leggibile e soprattutto più semplice da estendere nel tempo. Nuove funzioni, operatori e controlli possono essere introdotti senza riscrivere continuamente il nucleo del parser.

La nuova logica ETL

Una delle novità più importanti di Expression Engine 2 è la famiglia di funzioni logiche:

IF
AND
OR
NOT
EQ
NE
GT
GE
LT
LE

Non si tratta di una semplice raccolta di comandi. È un vero sistema per costruire regole decisionali direttamente nei flussi di trasformazione.

Il modello è semplice ma potente:

DATI
CONFRONTO
TRUE / FALSE
LOGICA
IF / CASE
RISULTATO

Le funzioni di confronto producono condizioni booleane. Le funzioni logiche combinano tali condizioni. IF e CASE trasformano il risultato in un valore concreto utilizzabile nella pipeline ETL.

IF: quando il dato diventa una decisione

La sintassi di base è:

IF(condizione; valore_se_vero; valore_se_falso)

Esempio:

IF(
   EQ({STATO};"A");
   "ATTIVO";
   "NON ATTIVO"
)

Il motore confronta il valore di STATO con "A".

  • Se il confronto è vero, restituisce ATTIVO
  • Se il confronto è falso, restituisce NON ATTIVO

Questa è la differenza tra una trasformazione meccanica e una trasformazione intelligente: il processo ETL non si limita a trasferire dati, ma applica una regola di business.

Confronti chiari e dichiarativi

FunzioneSignificatoEsempio
EQUguale aEQ({STATO};"A")
NEDiverso daNE({STATO};"A")
GTMaggiore diGT({IMPORTO};1000)
GEMaggiore o ugualeGE({ETA};18)
LTMinore diLT({IMPORTO};1000)
LEMinore o ugualeLE({ETA};18)

Un esempio immediato:

IF(
   GE({ETA};18);
   "MAGGIORENNE";
   "MINORENNE"
)

Oppure:

IF(
   GT({IMPORTO};1000);
   "IMPORTO ALTO";
   "IMPORTO NORMALE"
)

Queste espressioni consentono di trasformare soglie, regole e classificazioni in configurazioni riutilizzabili, anziché in logica C++ dispersa nel codice applicativo.

Regole complesse senza codice dedicato

Il vero valore non è nella singola funzione, ma nella possibilità di combinarle.

Immaginiamo una regola operativa: se il record è attivo e l’importo è almeno 1.000, classificalo come prioritario. In tutti gli altri casi, classificalo come normale.

IF(
   AND(
      EQ({STATO};"A");
      GE({IMPORTO};1000)
   );
   "PRIORITARIO";
   "NORMALE"
)

Oppure, quando il numero di scenari cresce, con CASE:

CASE(
   AND(
      EQ({STATO};"A");
      GE({IMPORTO};10000)
   );
   "PRIORITARIO";

   AND(
      EQ({STATO};"A");
      GE({IMPORTO};1000)
   );
   "NORMALE";

   EQ({TIPO};"URGENTE");
   "URGENTE";

   "STANDARD"
)

Questa espressione rappresenta una vera regola di business:

  • Attivo con importo pari o superiore a 10.000: PRIORITARIO
  • Attivo con importo pari o superiore a 1.000: NORMALE
  • Tipo urgente: URGENTE
  • Tutti gli altri casi: STANDARD

Il vantaggio è enorme: la regola può essere letta, modificata, testata e configurata senza creare codice speciale per ogni flusso.

Normalizzazione, NULL e Data Quality

Nei progetti ETL più complessi, il problema non è soltanto capire quale valore sia presente. È capire se il valore è davvero utilizzabile.

Expression Engine 2 integra il ragionamento logico con funzioni dedicate ai valori mancanti e alla normalizzazione:

ISNULL
ISEMPTY
ISBLANK
COALESCE
TRIM
UPPER
LENGTH

Esempio: assegnare un CAP predefinito quando il valore è assente, vuoto o composto solo da spazi.

IF(
   ISBLANK({CAP});
   "00000";
   {CAP}
)

Oppure scegliere il primo identificativo disponibile:

COALESCE(
   {CODICE_FISCALE};
   {PARTITA_IVA};
   {CODICE};
   "N/D"
)

Le funzioni possono anche essere composte per ottenere confronti affidabili:

EQ(
   UPPER(TRIM({COMUNE}));
   "RICCIONE"
)

In questo modo valori come riccione, RICCIONE e Riccione vengono normalizzati prima del confronto, riducendo errori e anomalie nei dati in ingresso.

La base per un Data Quality Engine

La logica introdotta da Expression Engine 2 apre la strada a una vera gestione della qualità del dato.

Per esempio, è possibile verificare che un codice sia presente e abbia una lunghezza precisa:

AND(
   NOT(ISBLANK({CODICE}));
   EQ(LENGTH({CODICE});16)
)

Oppure controllare in modo dichiarativo la presenza e la validità di un indirizzo email:

AND(
   NOT(ISBLANK({EMAIL}));
   REGEXMATCH({EMAIL};"...")
)

Il risultato di queste espressioni può essere utilizzato per:

  • Validare un record prima dell’importazione
  • Assegnare uno stato di qualità
  • Generare warning o segnalazioni
  • Inviare record incompleti in un flusso alternativo
  • Separare dati validi, incompleti e da verificare
  • Preparare processi di deduplicazione e normalizzazione
SOURCE
TRANSFORM
NORMALIZE
VALIDATE
DATA QUALITY
LOOKUP
DEDUP
DESTINATION

Expression Engine 2 non è quindi solo un componente di trasformazione: può diventare il livello decisionale dell’intera pipeline dati.

Sintassi per persone, wizard e AI

L’architettura è stata progettata per supportare sia una sintassi funzionale esplicita sia, in prospettiva, una sintassi più naturale basata su operatori.

La forma funzionale:

AND(
   EQ({STATO};"A");
   GE({IMPORTO};1000)
)

è ideale per generatori automatici, wizard visuali, configurazioni strutturate, sistemi AI che producono regole e validazioni automatiche delle espressioni.

La forma espressiva:

{STATO} = "A" AND {IMPORTO} >= 1000

può invece risultare più immediata per utenti tecnici, analisti e sviluppatori.

L’obiettivo è fare in modo che le due sintassi confluiscano nello stesso AST interno. In questo modo il motore può offrire semplicità a chi configura e solidità a chi sviluppa.

Prestazioni e crescita futura

Una vera struttura logica permette anche di introdurre meccanismi evoluti come lo short-circuit evaluation.

In una condizione AND, se una parte della regola è già falsa, il motore può evitare calcoli non necessari. In una condizione OR, se una condizione è già vera, le altre potrebbero non essere valutate.

Su grandi quantità di record, questo può fare la differenza.

L’architettura di Expression Engine 2 prepara inoltre il terreno per funzionalità future:

  • Operatori matematici e relazionali
  • Precedenza degli operatori e parentesi
  • Funzioni definite dall’utente
  • Diagnostica dettagliata degli errori
  • Validazione semantica delle formule
  • Autocompletamento e Expression Wizard
  • Preview delle trasformazioni
  • Test automatici delle regole
  • Data Lineage
  • Funzioni dedicate ai dati italiani
  • Generazione di espressioni mediante AI

Non si tratta quindi soltanto di aggiungere funzioni. Si tratta di costruire un linguaggio dichiarativo specializzato per l’ETL, capace di evolvere insieme alle esigenze applicative.

Expression Engine 2 segna il passaggio da un sistema di mapping a una piattaforma capace di rappresentare vere regole di business.

Con funzioni come IF, AND, OR, NOT, EQ, NE, GT, GE, LT e LE, un processo ETL può analizzare i dati, prendere decisioni e produrre risultati coerenti direttamente nella configurazione della trasformazione.

DATI
NORMALIZZAZIONE
CONFRONTO
CONDIZIONE
LOGICA
DECISIONE
TRASFORMAZIONE
DESTINAZIONE

Expression Engine 2 non è semplicemente una nuova versione di un motore esistente.

È la base per portare nell’ETL regole di business, Data Quality, validazione, automazione e intelligenza configurabile — direttamente dove i dati vengono trasformati.

#SQL #database #ETL #DataEngineering #plyxSQL #FireDAC #PGSOFT

venerdì 18 settembre 2026

Free PlyxSQL© Beta - 1.0.0.99 Super ETL

Free PlyxSQL© Beta - 1.0.0.99 Super ETL

POSTED BY Giuliano pagnini, 18 SETT 2026

Free DOWNLOAD Clicca qui Info https://pgsoft.it/plyxhtml


SUPER ETL con PLYXSQL: il motore di mapping diventa ancora più potente

Trasformare dati non significa soltanto spostarli da una tabella a un’altra. Significa riconoscere formati diversi, pulire testi, classificare valori, intercettare anomalie, rispettare le dimensioni dei campi e garantire che una singola riga problematica non blocchi un’intera importazione.

Con gli ultimi aggiornamenti, PlyxSQL evolve in modo deciso: il suo motore ETL diventa più espressivo, più guidato e più resistente agli errori reali che si incontrano ogni giorno tra CSV, Excel, archivi legacy, gestionali esterni e basi dati di destinazione.

Il risultato è un sistema di mapping ancora più completo, capace di gestire logiche condizionali articolate senza scrivere codice e di rendere più sicure anche le importazioni più complesse.

CASE: la logica condizionale entra nel mapping

Una delle novità più importanti è la funzione CASE, disponibile nell’Assistente Espressione.

Fino a poco tempo fa, per realizzare una logica del tipo “se il valore è questo fai una cosa, se è un altro fai un’altra cosa, altrimenti usa un valore predefinito”, era necessario combinare più regole:

  • Una regola con valore costante.
  • Una condizione “Esegui regola solo se”.
  • Un ramo alternativo.
  • Ulteriori annidamenti per coprire più casi.

Era un approccio funzionale, ma quando le condizioni diventavano tre, quattro o dieci, la configurazione rischiava di diventare difficile da leggere, verificare e mantenere.

Ora tutta la logica può essere espressa in una sola formula:

CASE(Permanenti;2;Temporanei;3;1)

Il significato è immediato:

Valore in ingresso Risultato
Permanenti 2
Temporanei 3
Qualsiasi altro valore 1

L’ultimo parametro rappresenta il valore di default: ciò che PlyxSQL deve usare quando nessuna delle condizioni precedenti è soddisfatta.

Questa funzione è particolarmente utile nei mapping di anagrafiche, classificazioni, stati, tipologie contrattuali, codici di provenienza, ruoli, categorie tributarie e valori provenienti da archivi non standardizzati.

Confronti diretti e regex

Ogni condizione di CASE può essere scritta come confronto testuale diretto. Il confronto è case-insensitive, quindi non distingue tra maiuscole e minuscole.

CASE(Residente;R;Non Residente;N;Da verificare)

In questo caso, Residente, RESIDENTE e residente vengono gestiti nello stesso modo.

Quando serve maggiore flessibilità, è possibile usare un pattern regex anteponendo il carattere ~.

CASE(~mq5;1;6)

Questa espressione assegna:

  • 1 a tutti i valori che contengono mq5.
  • 6 a tutti gli altri valori.
Codice sorgente Risultato
mq5 1
abc_mq5_01 1
MQ5 1
mq6 6
altro_codice 6

La funzione CASE consente quindi di concentrare una logica di classificazione completa direttamente nella trasformazione del singolo campo, evitando la proliferazione di regole separate.

Compositore CASE: tutta la potenza, senza sintassi da imparare


Scrivere espressioni manualmente è utile per chi conosce bene regex e logiche di trasformazione. Tuttavia, un motore ETL efficace deve essere accessibile anche a chi vuole configurare mapping complessi senza ricordare sintassi, parentesi, separatori o caratteri speciali.

Per questo PlyxSQL  introduce il Compositore CASE.

Il funzionamento è guidato passo per passo:

  1. Si sceglie il tipo di confronto da un menu.
  2. Si inserisce il valore da cercare.
  3. Si definisce il risultato da restituire.
  4. Si preme “Aggiungi caso”.
  5. Si ripete l’operazione per tutte le condizioni necessarie.
  6. Si definisce il valore finale di default.

I tipi di confronto disponibili rendono immediata la costruzione delle regole più comuni:

  • Inizia con.
  • Contiene.
  • Finisce con.
  • Uguale a.
  • Vuoto.
  • Non vuoto.

Mentre l’utente compone i casi, PlyxSQL  genera in tempo reale l’espressione CASE(...) corrispondente.

L’anteprima live permette di capire subito quale formula verrà applicata al campo, senza dover scrivere manualmente la funzione e senza il rischio di errori formali.

Una logica che prima richiedeva esperienza tecnica può ora essere configurata con pochi click, rimanendo comunque trasparente, verificabile e modificabile in qualsiasi momento.

Tre nuove funzioni per pulire i dati

I dati provenienti da Excel, CSV, esportazioni gestionali e archivi storici raramente sono già pronti per essere scritti nella base dati di destinazione. Nomi in minuscolo, codici incompleti, descrizioni non uniformi e caratteri da sostituire sono problemi ricorrenti.

Per affrontarli direttamente nel mapping, PLYXSQL aggiunge tre nuove funzioni di trasformazione testo.

PROPER: nomi e descrizioni più ordinati

La funzione PROPER trasforma la prima lettera di ogni parola in maiuscola.

PROPER(mario rossi)

Risultato:

Mario Rossi

È ideale per normalizzare campi come nominativi, ragioni sociali, città, indirizzi, descrizioni, titoli e denominazioni.

Valore sorgente Espressione Risultato
mario rossi PROPER(...) Mario Rossi
comune di bologna PROPER(...) Comune Di Bologna
via giuseppe garibaldi PROPER(...) Via Giuseppe Garibaldi

Per nomi con particelle, acronimi o convenzioni particolari, il risultato può essere ulteriormente raffinato con regole dedicate. Per la normalizzazione iniziale dei dati importati, però, PROPER elimina rapidamente una delle anomalie più comuni.

REPLACE: sostituzioni semplici, senza regex

La funzione REPLACE(testo;sostituto) esegue una sostituzione letterale di tutte le occorrenze di un testo.

REPLACE(-;/)

Può essere usata, ad esempio, per uniformare separatori, eliminare prefissi, correggere abbreviazioni o sostituire caratteri non desiderati.

A differenza delle espressioni regolari, REPLACE non interpreta i caratteri come operatori speciali. Questo la rende particolarmente comoda quando serve una sostituzione diretta e prevedibile, senza dover effettuare escape di parentesi, punti, barre, trattini o altri simboli.

Valore sorgente Trasformazione Risultato
BO-2026-00125 Sostituisce - con / BO/2026/00125
Via Roma n. 12 Sostituisce n. con numero Via Roma numero 12
Cod. Fisc. Sostituisce Cod. con Codice Codice Fisc.

PAD: codici sempre della lunghezza corretta

La funzione PAD(n;carattere) completa il valore a sinistra fino a raggiungere una lunghezza fissa.

PAD(5;0)

Applicata al valore 123, produce:

00123

Questa funzione è essenziale quando un sistema sorgente esporta codici numerici perdendo gli zeri iniziali, mentre il sistema di destinazione richiede una lunghezza precisa.

Gli utilizzi tipici comprendono CAP, matricole, codici cliente, codici prodotto, numeri protocollo, identificativi territoriali e codici di classificazione a lunghezza fissa.

Valore sorgente Regola Risultato
123 PAD(5;0) 00123
45 PAD(4;0) 0045
7 PAD(3;0) 007

Stop agli overflow: PlyxSQL  protegge l’importazione

Uno degli errori più frustranti nelle operazioni ETL è il classico:

Variable length column overflow

Accade quando un valore proveniente dalla sorgente supera la lunghezza massima del campo testuale nella tabella di destinazione.

In un’importazione tradizionale, anche una singola descrizione troppo lunga, una ragione sociale estesa o un indirizzo anomalo possono interrompere l’intera elaborazione. Il risultato è tempo perso, importazioni incomplete e necessità di analizzare manualmente record che spesso sono pochi rispetto al volume totale.

Con il nuovo comportamento di PLYXSQL, il motore controlla automaticamente la dimensione delle colonne testuali di destinazione.

Se il valore generato dalla regola supera la lunghezza prevista:

  1. Il valore viene troncato automaticamente.
  2. L’importazione prosegue senza blocchi.
  3. Al termine, PLYXSQL produce un riepilogo.
  4. Il riepilogo indica quanti valori sono stati troncati.
  5. Il riepilogo mostra su quali campi è avvenuto il troncamento.

Questo approccio rispecchia una filosofia precisa: un dato anomalo deve essere segnalato, non deve bloccare il lavoro.

La qualità del dato rimane sotto controllo grazie al log finale, ma il processo ETL non viene fermato da un’unica eccezione. È un vantaggio particolarmente rilevante nelle importazioni massive, nei caricamenti periodici e nelle migrazioni da archivi storici.

Nuova condizione: “Contiene una data valida”

Le date sono tra i campi più delicati in assoluto. Possono essere assenti, scritte in modo incompleto, invertite, esportate come testo oppure contaminate da valori non validi.

PLYXSQL aggiunge una nuova condizione per “Esegui regola solo se”:

Contiene una data valida

L’utente indica il formato atteso, per esempio:

dd/mm/yyyy

La condizione verifica che il valore del campo sia realmente interpretabile come una data valida nel formato indicato.

Questo permette di separare due operazioni che spesso vengono confuse:

  • Verificare che il valore sia una data corretta.
  • Convertire quel valore nel formato richiesto dalla destinazione.

La validazione viene applicata prima della trasformazione vera e propria. Solo se il campo supera il controllo, è possibile eseguire una regola come:

DATE(dd/mm/yyyy)
Valore sorgente Condizione “data valida” Conversione DATE Esito
15/09/2026 Superata Eseguita Data importata
31/02/2026 Non superata Non eseguita Riga gestita separatamente
abc Non superata Non eseguita Nessuna conversione errata
Valore vuoto Non superata Non eseguita Campo vuoto o valore predefinito

Regex anche nelle condizioni

PLYXSQL dispone già di un catalogo di pattern pronti all’uso per funzioni come:

REGEXMATCH
REGEXEXTRACT
REGEXREPLACE

Con questo aggiornamento, il catalogo è disponibile anche direttamente nel pannello delle condizioni quando si seleziona:

Corrisponde al pattern regolare

Questo rende più semplice costruire controlli robusti senza dover ricordare o riscrivere ogni volta le espressioni regolari.

Tra i pattern disponibili rientrano controlli per:

  • CAP.
  • Città.
  • Codici fiscali.
  • IBAN.
  • Date.
  • Numeri.
  • Indirizzi con civico.
  • Indirizzi con interno.
  • Indirizzi con scala.
  • Strutture testuali ricorrenti.

Le regex non sono più uno strumento riservato a chi conosce nel dettaglio la sintassi dei pattern. Diventano una risorsa configurabile dall’interfaccia, utile per validare e classificare i dati prima di eseguire il mapping.

Deduplica completamente localizzata

Anche gli interventi apparentemente meno visibili contribuiscono alla qualità complessiva dell’esperienza.

La finestra di configurazione della funzione Elimina Duplicati e i relativi messaggi di log, che in precedenza contenevano alcune parti hardcoded, sono stati completamente riportati nel sistema di traduzione dell’applicazione.

Il risultato è un’interfaccia più coerente con il resto di PLYXSQL e pronta per supportare future localizzazioni senza dover intervenire sulla logica della funzione.

Per chi utilizza il prodotto in contesti internazionali, distribuisce procedure a più operatori o realizza soluzioni verticali multilingua, questa è una base importante: non una semplice traduzione di etichette, ma una gestione più ordinata e scalabile dell’interfaccia.

Un piccolo fix che elimina un grande fastidio

L’ultimo miglioramento riguarda l’albero di selezione dei campi.

In alcune situazioni, facendo click su un nodo, poteva accadere che una checkbox già selezionata venisse deselezionata accidentalmente. Il problema dipendeva da un’area sensibile al click troppo ampia attorno alla casella di selezione.

È uno di quei difetti piccoli sulla carta, ma fastidiosi nel lavoro reale: soprattutto quando si configurano mapping con molti campi, una selezione modificata involontariamente può causare errori difficili da individuare.

Ora l’area di rilevamento del click si adatta dinamicamente al testo effettivo del nodo. Il comportamento è quindi più preciso, affidabile e coerente con ciò che l’utente vede nell’interfaccia.

Un motore ETL progettato per il lavoro reale

Esigenza operativa Nuova soluzione PLYXSQL
Classificare più valori con logica “se/altrimenti” Funzione CASE
Creare CASE senza ricordare sintassi o regex Compositore CASE guidato
Normalizzare nomi e descrizioni PROPER
Sostituire testo senza complessità regex REPLACE
Ripristinare zeri iniziali e lunghezze fisse PAD
Evitare blocchi per campi troppo lunghi Troncamento automatico con riepilogo finale
Validare date prima della conversione Condizione “Contiene una data valida”
Usare pattern pronti nelle condizioni Assistente regex
Preparare l’interfaccia a più lingue Localizzazione completa della deduplica
Ridurre errori di selezione nell’interfaccia Correzione dell’area click delle checkbox


Con queste evoluzioni, PlyxSQL consolida il proprio ruolo di motore per l’integrazione e la trasformazione dei dati: una soluzione pensata per chi deve configurare importazioni, conversioni e mapping complessi in modo visuale, controllato e senza dover sviluppare script dedicati per ogni eccezione.

La funzione CASE elimina gran parte degli annidamenti necessari per le classificazioni multiple. Il Compositore CASE rende questa potenza disponibile anche a chi non vuole scrivere espressioni a mano. Le nuove funzioni PROPER, REPLACE e PAD affrontano operazioni quotidiane di pulizia e normalizzazione.

I controlli automatici sulle dimensioni dei campi evitano interruzioni inutili, mentre la validazione delle date e il supporto regex nelle condizioni rendono il mapping più solido già in fase di configurazione.

In una parola: SUPER ETL.

Perché un processo di importazione affidabile non deve solo trasferire dati. Deve saperli interpretare, correggere, validare e accompagnare fino alla destinazione, anche quando la sorgente non è perfetta.

#SQL #database #ETL #DataEngineering #plyxSQL #FireDAC #PGSOFT

Server REST in C++Builder per VueLityx

Server REST in C++Builder per VueLityx© 

POSTED BY GIULIANO PAGNINI, 18 SETT 2026 




Server REST in C++Builder: una libreria professionale per creare API robuste, sicure e performanti

Trasformare C++Builder in un vero server REST

Realizzare un server REST moderno con C++Builder non significa necessariamente partire da zero.

La libreria REST Server nasce proprio con questo obiettivo: fornire agli sviluppatori C++Builder una base solida e riutilizzabile per realizzare API REST professionali, integrate direttamente con FireDAC e progettate per lavorare con database relazionali e applicazioni web moderne.

L'idea è semplice:

C++Builder + FireDAC + REST API + Connection Pooling = backend completo e performante.

La libreria è pensata per applicazioni gestionali, software per enti pubblici, sistemi ERP, applicazioni web, servizi desktop e architetture in cui un frontend Vue, Nuxt o qualsiasi altro client deve comunicare con un backend centralizzato.


Un'architettura pensata per la produzione

Uno dei principali vantaggi della libreria è la separazione delle responsabilità.

Il server è organizzato in componenti specializzati per:

  • gestione delle richieste REST;

  • autenticazione;

  • autorizzazione;

  • gestione utenti;

  • query database;

  • configurazione;

  • crittografia;

  • connection pooling;

  • logging;

  • gestione degli errori;

  • CORS e security headers.

Questo permette di evitare il classico problema dei server REST sviluppati rapidamente all'interno di un'unica unità di codice.

Ogni componente ha un compito preciso e può essere evoluto indipendentemente.


FireDAC come motore database

La libreria sfrutta direttamente FireDAC, evitando livelli di astrazione inutili e mantenendo tutte le potenzialità dell'ambiente C++Builder.

Questo significa poter utilizzare database come:

  • Firebird;

  • InterBase;

  • Oracle;

  • Microsoft SQL Server;

  • PostgreSQL;

  • MySQL;

  • SQLite.

La possibilità di utilizzare FireDAC direttamente è particolarmente importante nelle applicazioni gestionali dove query, transazioni e caratteristiche specifiche del database hanno un ruolo centrale.


Connection Pooling: il cuore delle prestazioni

Uno degli elementi più importanti della libreria è il connection pool.

Creare e distruggere continuamente connessioni database durante le richieste HTTP può diventare costoso, soprattutto quando il numero di richieste aumenta.

Il connection pool mantiene invece un insieme di connessioni pronte per essere utilizzate.

Ad esempio, con:

PoolSize = 8

il server può gestire contemporaneamente più richieste utilizzando un numero controllato di connessioni database.

Il meccanismo comprende:

  • checkout della connessione;

  • timeout di acquisizione;

  • riconsegna automatica;

  • rollback delle transazioni non concluse;

  • invalidazione delle connessioni problematiche;

  • ricostruzione automatica delle connessioni;

  • gestione dello shutdown;

  • protezione da accessi concorrenti.

Il risultato è un backend molto più adatto a scenari con numerose richieste simultanee.


Una connessione per richiesta

Un principio importante dell'architettura è il concetto di lease della connessione.

Una richiesta acquisisce una connessione dal pool e la mantiene per tutta la durata dell'operazione.

Al termine:

  • la connessione viene restituita al pool;

  • oppure viene invalidata se si è verificato un problema;

  • eventuali transazioni rimaste aperte vengono gestite correttamente.

Questo approccio rende più semplice mantenere una corretta gestione delle transazioni e riduce il rischio di lasciare connessioni in stati inconsistenti.


Transazioni Firebird e database relazionali

Le API REST non devono limitarsi a eseguire semplici SELECT.

In una vera applicazione gestionale è spesso necessario eseguire operazioni atomiche:

  1. inserimento di un documento;

  2. aggiornamento di più tabelle;

  3. registrazione di un movimento;

  4. aggiornamento di una situazione contabile;

  5. commit dell'intera operazione.

La libreria permette quindi di utilizzare le normali transazioni FireDAC.

Un esempio concettuale è:

Connection->StartTransaction();

try
{
    // INSERT
    // UPDATE
    // DELETE

    Connection->Commit();
}
catch (...)
{
    Connection->Rollback();
    throw;
}

In questo modo l'API può mantenere la stessa affidabilità delle applicazioni desktop tradizionali.


API REST per frontend moderni

Il backend può essere utilizzato come motore per applicazioni realizzate con:

  • Vue.js;

  • Nuxt;

  • React;

  • Angular;

  • applicazioni mobile;

  • Electron;

  • software desktop;

  • altri client HTTP.

Il frontend non deve conoscere la struttura interna del database.

Comunica semplicemente attraverso endpoint REST.

Un'architettura tipica può quindi essere:

                 ┌──────────────────┐
                 │   Vue / Nuxt     │
                 │    Frontend      │
                 └────────┬─────────┘
                          │ HTTPS
                          ▼
                 ┌──────────────────┐
                 │    REST API      │
                 │   C++Builder     │
                 └────────┬─────────┘
                          │
                   Connection Pool
                          │
                          ▼
                 ┌──────────────────┐
                 │     FireDAC      │
                 └────────┬─────────┘
                          │
                          ▼
                 ┌──────────────────┐
                 │ Firebird/Oracle  │
                 │   SQL Server...  │
                 └──────────────────┘

È una soluzione particolarmente interessante per trasformare applicazioni gestionali tradizionali in piattaforme web moderne.


Sicurezza integrata nell'architettura

Un server REST destinato alla produzione deve considerare la sicurezza fin dall'inizio.

La libreria è progettata per gestire diversi livelli di protezione:

  • autenticazione;

  • token JWT;

  • API Key;

  • gestione utenti;

  • autorizzazione;

  • CORS;

  • security headers;

  • request ID;

  • logging controllato;

  • protezione delle informazioni sensibili.

Un altro principio importante è evitare di inserire nei log informazioni che non dovrebbero essere registrate, come password, token o interi payload sensibili.


HTTPS e Reverse Proxy

In un'installazione professionale il server C++Builder può essere collocato dietro un reverse proxy.

L'architettura può quindi essere:

Internet
   │
   │ HTTPS
   ▼
Reverse Proxy
   │
   │ HTTP interno
   ▼
C++Builder REST Server
   │
   ▼
FireDAC / Database

Il reverse proxy può occuparsi della terminazione TLS, mentre il server REST rimane focalizzato sulla gestione delle API e del database.

Questa configurazione è particolarmente adatta a server Windows e infrastrutture aziendali.


Timeout e protezione dalla saturazione

Un problema frequente nei server database è la saturazione delle risorse.

La libreria utilizza timeout specifici per evitare che una richiesta possa rimanere indefinitamente in attesa.

Tra i parametri più importanti troviamo:

CheckoutTimeoutMs

Definisce per quanto tempo una richiesta può attendere una connessione libera dal pool.

CommandTimeoutSec

Limita il tempo concesso alle operazioni database.

DestroyTimeoutMs

Permette di controllare la fase di chiusura del pool durante lo shutdown.

Questi parametri diventano particolarmente importanti sotto carico elevato.


Progettata pensando alla concorrenza

Una API REST deve essere progettata per gestire richieste contemporanee.

La libreria utilizza meccanismi di sincronizzazione per proteggere le strutture condivise del connection pool e permettere a più richieste di lavorare contemporaneamente.

Un server configurato con:

PoolSize = 8

può essere sottoposto a test con:

20 richieste concorrenti
50 richieste concorrenti
100 richieste concorrenti
200 richieste concorrenti

Questi test permettono di verificare concretamente:

  • saturazione del pool;

  • timeout di checkout;

  • tempi medi di risposta;

  • percentili P50/P90/P95/P99;

  • errori database;

  • invalidazione delle connessioni;

  • comportamento delle transazioni;

  • capacità di recupero dopo un errore.

Non basta quindi dire che un server è "veloce": è necessario misurarne il comportamento sotto carico.


Connection invalidation e autoriparazione

In ambiente reale una connessione database può diventare inutilizzabile.

Può accadere, ad esempio, dopo:

  • una disconnessione di rete;

  • un restart del database;

  • un errore del server;

  • una connessione rimasta in uno stato non valido.

Invece di lasciare che una connessione guasta rimanga nel pool, la libreria permette di invalidarla.

Il pool può quindi creare una nuova connessione e, quando configurato per farlo, utilizzare un meccanismo di auto-healing.

Questo rende il server più resiliente agli errori temporanei.


Non solo CRUD

Una libreria REST professionale non deve essere limitata alle classiche operazioni CRUD.

Può diventare il livello applicativo attraverso cui esporre funzionalità molto più complesse:

GET     /api/comuni
GET     /api/tributi/2026
POST    /api/tributi
PUT     /api/tributi/123
DELETE  /api/tributi/123
POST    /api/login
POST    /api/token/refresh

Il database rimane dietro il server.

Il client vede esclusivamente le API definite dall'applicazione.

Questo permette di evolvere il database senza dover modificare necessariamente tutti i client.


Una base ideale per software gestionali

Uno degli scenari più interessanti è la trasformazione di un'applicazione gestionale C++Builder esistente in una piattaforma ibrida.

Il database Firebird può continuare a rappresentare il cuore del sistema mentre il nuovo backend REST diventa il punto di accesso per:

  • applicazioni web;

  • portali;

  • dashboard;

  • applicazioni mobile;

  • integrazioni con software esterni;

  • servizi automatici;

  • import/export;

  • sistemi di autenticazione centralizzati.

In questo modo non è necessario riscrivere immediatamente tutta l'applicazione esistente.


C++Builder diventa anche un backend moderno

Per molti anni C++Builder è stato associato principalmente allo sviluppo desktop Windows.

L'utilizzo di FireDAC, WebBroker e di una moderna architettura REST dimostra invece come sia possibile utilizzare C++Builder anche per costruire backend server moderni e ad alte prestazioni.

Il vantaggio principale è poter riutilizzare competenze, codice e infrastrutture già presenti nell'ecosistema C++Builder.

Non è quindi necessario introdurre un nuovo linguaggio esclusivamente per realizzare il backend.


Una libreria pensata per chi vuole controllo

La filosofia della libreria è diversa da quella dei framework che nascondono completamente il funzionamento del database e del server.

Qui lo sviluppatore mantiene il controllo su:

  • connessioni;

  • transazioni;

  • SQL;

  • timeout;

  • autenticazione;

  • pool;

  • gestione degli errori;

  • configurazione;

  • logging.

È un approccio particolarmente adatto a software gestionali e applicazioni professionali dove il database rappresenta una componente fondamentale dell'architettura.


Dal desktop al cloud senza riscrivere tutto

Uno dei vantaggi più interessanti è la possibilità di costruire gradualmente una nuova architettura.

Un'applicazione esistente può continuare a funzionare mentre il server REST espone progressivamente nuove funzionalità.

Ad esempio:

                 APPLICAZIONE DESKTOP
                         │
                         ▼
                    FIREBIRD
                         ▲
                         │
                  REST SERVER
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
        WEB            MOBILE        INTEGRATION
      Vue/Nuxt          App             API

Questo consente una migrazione progressiva verso il web senza dover affrontare una riscrittura completa del software.



La libreria REST Server per C++Builder nasce con un obiettivo preciso: offrire una base professionale per sviluppare API REST direttamente nell'ecosistema C++Builder, sfruttando FireDAC e mantenendo un controllo completo sull'accesso ai database.

Connection pooling, gestione delle transazioni, timeout, autenticazione, invalidazione delle connessioni e supporto alla concorrenza sono elementi fondamentali per trasformare un semplice endpoint HTTP in un vero backend applicativo.

#REST #CBUILER #VUELITIX

mercoledì 26 agosto 2026

VueLityx© DataModule e DataSource in Vue.js

VueLityx© DataModule e DataSource in Vue.js 

POSTED BY GIULIANO PAGNINI, 28 AGO 2026 


Un DataSource per governarli tutti: come abbiamo portato il DataModule di RadStudio dentro un'app Vue.js

Chi viene dal mondo Delphi©/C++Builder© lo conosce bene: il DataModule. Quel posto, spesso l'unico in tutto il progetto, dove sai di trovare ogni TDataSource, ogni TTable, ogni TQuery dell'applicazione. Non devi cercarlo form per form. Non devi capire quale schermata "possiede" quale connessione. È lì, centralizzato, e ogni form ci si aggancia semplicemente impostando una proprietà.

Chi invece viene dal mondo frontend moderno conosce fin troppo bene il problema opposto: dati sparsi ovunque. Una fetch qui, uno state locale là, una prop passata attraverso quattro livelli di componenti solo per far arrivare un valore da un punto A a un punto B. Funziona, finché il progetto è piccolo. Poi smette di funzionare.

Con l'ultimo aggiornamento di VueLityX abbiamo deciso di prendere il meglio dei due mondi — e il risultato ci sta piacendo più di quanto immaginassimo.

Il problema: ogni vista, il suo piccolo regno

Fino a poco fa, ogni schermata della nostra suite gestionale dichiarava i propri dati per conto suo. La vista Anagrafe Comuni caricava i suoi comuni. La vista Portfolio caricava i suoi investimenti. Funzionava, ma con due conseguenze scomode:

  • Duplicazione: la stessa logica di caricamento, ripetuta vista dopo vista.
  • Nessuna vista d'insieme: per sapere "quali fonti dati usa questa applicazione" dovevi aprire ogni singolo file e cercare.

Se hai mai lavorato su un progetto Delphi©/C++Builder© senza DataModule — con le TTable/TQuery sparse form per form — sai esattamente di cosa parliamo. È lo stesso identico dolore, solo in salsa JavaScript.

La soluzione: un TDataModule, per davvero

Abbiamo introdotto un componente TDataModule, montato una sola volta all'avvio dell'applicazione — non dentro una vista specifica, ma a livello di app, esattamente come un vero DataModule Delphi©/C++Builder© non appartiene a nessuna form in particolare.

Al suo interno, un elenco centralizzato di tutte le TDataSource disponibili: cosa sono, da dove arrivano i dati, come vanno filtrati e ordinati. Un solo posto. Una sola fonte di verità.

Le viste non dichiarano più nulla: si limitano a referenziare un id.

<TNavigator datasource="dsComuni" />
<TDataGrid datasource="dsComuni" storage-id="anagrafe-comuni" />

Esattamente come in Delphi©/C++Builder© imposti DataSource := DataModule1.dsComuni su una TDBGrid senza doverla ricreare, qui basta il nome. Il resto — caricamento, cache, stato — vive nel DataModule, condiviso e coerente ovunque venga usato.

Il vero salto: un DataSource che non sa (né gli importa) da dove vengono i dati

Qui arriva la parte che ci entusiasma di più. Ogni TDataSource è agnostica rispetto all'origine. La stessa identica interfaccia — stessi metodi di navigazione, stesso ciclo Insert/Edit/Post/Cancel, stessa integrazione con griglie e form — funziona indifferentemente su:

  • Array locali in memoria, per prototipare in un attimo
  • File JSON statici, per dati semi-fissi
  • API REST, per collegarsi a un vero backend
  • IndexedDB, per persistenza locale offline-first

Cambiare l'origine di un datasource — da un mock locale a un'API REST vera — non richiede toccare una sola riga delle viste che lo usano. Griglie, form, navigatori: tutti continuano a funzionare, perché parlano con l'astrazione, mai con l'origine concreta.

È la stessa filosofia dei TDataSet di Delphi©/CBuilder© (TTable, TQuery, TClientDataSet...) applicata al web: il codice applicativo non dovrebbe mai sapere — né interessarsene — se dietro c'è un file, un database o una chiamata di rete.

Ispezionabile, modificabile, senza scrivere una riga di codice

E qui il cerchio si chiude con l'altro pilastro di VueLityX: l'Object Inspector nativo. Ogni TDataSource registrata nel DataModule è visibile, in tempo reale, dal nostro tool di ispezione C++Builder — proprietà, stato, record caricati, tutto a colpo d'occhio, proprio come ispezioneresti un componente Delphi/C++Builder a design-time.

Vuoi cambiare l'origine dati di una griglia mentre l'app gira? Selezioni il componente, apri il Wizard, scegli la nuova fonte. Nessun redeploy. Nessuna riga di codice.

Perché conta, davvero

Non è (solo) nostalgia per chi viene da Delphi©/C++Builder©. È una scelta architetturale che paga concretamente:

  • Manutenzione più semplice: un solo posto dove capire "che dati usa questa app".
  • Refactoring senza paura: cambiare fonte dati non tocca la UI.
  • Sviluppo più veloce: prototipa con un array locale, passa a REST quando il backend è pronto, senza riscrivere nulla.
  • Debug immediato: ispeziona ogni datasource dal vivo, senza console.log sparsi ovunque.

Il DataModule non è mai stato "solo" una comodità per pigri. Era — ed è — un modo maturo di pensare all'architettura dei dati. Portarlo su Vue.js, con tutta la reattività e la flessibilità del frontend moderno, è esattamente il tipo di ponte che VueLityX vuole costruire tra due mondi che, a conti fatti, hanno sempre avuto più cose in comune di quanto sembrasse.

#Delphi #VueJS #CPPBuilder #LowCode #WebDevelopment #VueLityX

giovedì 20 agosto 2026

Free PlyxSQL - 1.0.0.95 Beta

Free PlyxSQL© Beta - 1.0.0.95

POSTED BY Giuliano pagnini, 20 AGO 2026

Free DOWNLOAD Clicca qui Info https://pgsoft.it/plyxhtml


Basta copia-incolla tra Excel: ora i tuoi dati parlano tra loro

Quante volte hai dovuto rispondere a una domanda semplice — "quanti dei nostri clienti hanno anche interagito col blog?" — e ti sei ritrovato ad aprire due programmi diversi, esportare due file, e incollarli a mano in un foglio Excel sperando di non sbagliare una riga?

Con la nuova Area di lavoro multi-connessione, quel rito è finito.

Un solo posto per dati che oggi vivono separati

Il database di produzione. L'archivio storico. Il blog aziendale. Il CRM. La casella email. Ognuno di questi mondi parla la sua lingua e vive sulla sua macchina — e finora, se volevi incrociarli, dovevi arrangiarti fuori dallo strumento.

Ora basta un click destro su una tabella, qualunque sia la sua origine, e la scelta "Aggiungi a Area di lavoro". In pochi secondi quella tabella è pronta, affiancata alle altre, disponibile per una normale query SQL — con tutti i JOIN che vuoi, come se fosse sempre stata lì.

Non serve imparare niente di nuovo: se sai scrivere una query, sai già usare l'Area di lavoro.

Cosa puoi fare da subito

  • Incrociare fonti diverse in un attimo — database e connettori esterni (blog, email, fogli condivisi) nella stessa interrogazione.
  • Verificare i dati prima di fidarti — confronta produzione e test, o due periodi diversi, senza spostare un solo file.
  • Provare un'idea prima di costruirla — abbozza la logica di una analisi complessa qui, e solo quando funziona la trasformi in una pipeline vera.
  • Rispondere alle domande "solo per oggi" — quelle richieste al volo che non giustificano un progetto, ma che meritano comunque una risposta precisa.

E non finisce qui

Quello che vedi oggi è solo il punto di partenza. Stiamo già guardando avanti verso:

  • aggiornamenti automatici e pianificati, così le tabelle raccolte restano sempre fresche senza bisogno di rifare il click ogni volta;
  • una Area di lavoro che sopravvive anche dopo aver chiuso il programma, come un piccolo magazzino dati personale sempre a disposizione;
  • un'integrazione ancora più profonda con i moduli ETL e Analytics, per trasformare quello che oggi è un aiuto estemporaneo in un vero e proprio passaggio delle tue pipeline di dati.

Il bello? Non hai dovuto aspettare una versione nuova

Questa funzionalità si è inserita nello strumento che già usi ogni giorno senza stravolgere nulla: stessa interfaccia, stesse abitudini, un solo nuovo click da imparare. A volte le funzionalità più utili sono anche le più semplici da adottare — e questa è nata per essere invisibile finché non ne hai bisogno, e indispensabile nel momento in cui ce l'hai.

Provala oggi stesso su una delle tue tabelle preferite: bastano dieci secondi per vedere la differenza.

#TextToSQL #AI #DatabaseLegacy #SQL #Firebird #CodeGeneration #SoftwareArchitecture #DataEngineering #LLM #PromptEngineering #DigitalTransformation #PubblicaAmministrazione #SoftwareDevelopment #TechInnovation #PlyxSQL

mercoledì 19 agosto 2026

Free PlyxSQL ETL - 1.0.0.94 Beta

Free PlyxSQL© Beta - 1.0.0.94 - ETL  

POSTED BY Giuliano pagnini, 19 AGO 2026

Free DOWNLOAD Clicca qui Info https://pgsoft.it/plyxhtml




PlyxSQL: l’integrazione dati diventa configurazione, non sviluppo

Ogni azienda accumula dati in strumenti diversi: CRM, gestionali, piattaforme di pagamento, fogli di calcolo, servizi cloud e applicazioni interne. Il vero problema non è solo collegarli una volta, ma mantenere queste integrazioni nel tempo senza trasformarle in un progetto di sviluppo continuo.

Con i nuovi connettori, PlyxSQL rende l’integrazione dati più rapida, governabile e vicina al modo in cui lavorano database designer e sviluppatori: si descrive la sorgente, si configura l’accesso e si costruisce la pipeline ETL, senza dover creare ogni volta un’integrazione software su misura.

Un connettore, non un nuovo progetto

In PlyxSQL un connettore è definito da un file JSON: una descrizione dichiarativa dell’autenticazione, degli endpoint disponibili e, quando necessario, delle risorse da selezionare. Il motore interpreta questa configurazione e genera automaticamente interfaccia, autorizzazione e tabelle disponibili per l’elaborazione dati.

Questo significa che collegare un servizio REST non richiede necessariamente intervenire sul motore applicativo. Un nuovo provider può essere aggiunto tramite una “ricetta” configurabile, invece di richiedere un modulo dedicato, codice personalizzato e manutenzione aggiuntiva.

Per chi sviluppa soluzioni gestionali, verticali aziendali o progetti di data integration, è un cambio di prospettiva importante: meno tempo speso nella meccanica di ogni API, più tempo dedicato a dati, regole e processi.

Nuovi connettori per pipeline ETL reali

I connettori PlyxSQL sono progettati per affrontare scenari concreti di integrazione: piattaforme SaaS, CRM, servizi finanziari, project management, e-commerce e strumenti collaborativi.

Il sistema supporta tre modalità di autenticazione diffuse:

  • OAuth2, incluso il supporto a PKCE per applicazioni desktop.
  • API Key, in header HTTP o query string.
  • Basic Authentication, spesso utilizzata con account e token API.

In questo modo è possibile gestire sia i servizi che richiedono un consenso via browser, sia quelli che diventano operativi semplicemente configurando una chiave o un token.

Anche la paginazione è trattata in modo nativo. PlyxSQL gestisce i principali modelli presenti nelle API REST: token in query string, URL della pagina successiva e cursori inviati tramite chiamate POST. Il risultato è una base più solida per trasformare endpoint remoti in tabelle navigabili e utilizzabili nei flussi ETL.

Excel e OpenCalc, senza Excel o LibreOffice

Tra le novità più rilevanti c’è l’accesso nativo ai file Microsoft Excel e OpenCalc / OpenDocument Spreadsheet.

PlyxSQL può leggere e utilizzare direttamente file Excel e fogli di calcolo in formato OpenDocument senza richiedere l’installazione di Microsoft Excel, LibreOffice o OpenOffice. Questo elimina una dipendenza spesso scomoda nelle procedure automatiche, nei server, nelle postazioni operative e nelle distribuzioni desktop controllate.

Il vantaggio è concreto:

  • Importare fogli Excel e OpenCalc in pipeline ETL senza automazione COM o applicazioni esterne.
  • Usare fogli di calcolo come sorgenti dati affidabili per importazioni, controlli e consolidamenti.
  • Ridurre problemi di versioni, licenze e installazioni locali.
  • Automatizzare flussi eseguibili anche in ambienti dove Office o LibreOffice non sono presenti.
  • Integrare file ricevuti da clienti, fornitori e uffici amministrativi direttamente nei processi dati.

Un file .xlsx o .ods smette quindi di essere un allegato da aprire manualmente: diventa una sorgente dati utilizzabile all’interno di una procedura ripetibile, tracciabile e configurabile.

Dalla sorgente alla destinazione

PlyxSQL non si limita a leggere dati esterni. Un endpoint può essere configurato anche come destinazione ETL, permettendo di inviare il risultato dell’elaborazione verso servizi remoti.

Il modello è volutamente chiaro: al termine della fase ETL, PlyxSQL invia lo stato completo della tabella locale verso la destinazione configurata. Non si tratta di una sincronizzazione differenziale implicita, ma di una scrittura “a specchio”, ideale quando la pipeline deve pubblicare un dataset completo e coerente.

Questo approccio favorisce processi prevedibili: il database locale resta il punto in cui dati e trasformazioni vengono governati, mentre le destinazioni esterne ricevono il risultato finale della pipeline.

76 connettori pronti all’uso, e molti altri in roadmap

PlyxSQL mette già a disposizione una raccolta di 76 connettori pronti all’uso, organizzati per area funzionale e progettati per portare dati da servizi cloud, piattaforme SaaS e strumenti collaborativi direttamente nelle pipeline ETL.

Ogni connettore rappresenta un servizio o una specifica integrazione, con le proprie regole di autenticazione, paginazione e accesso ai dati. L’obiettivo è consentire a sviluppatori, software house e aziende di collegare rapidamente le fonti più utilizzate, mantenendo al tempo stesso una configurazione trasparente e governabile.

Produttività, note e progetti

Airtable · Asana · Basecamp · ClickUp · Linear · Monday.com · Notion · Smartsheet · Todoist · Zoho Projects

Google Workspace

Gmail · Google Sheets · Google Calendar · Google Drive · Google Analytics

Microsoft

Microsoft Dynamics 365 · Microsoft Teams / OneDrive (Microsoft Graph) · Outlook Mail · Azure DevOps

Sviluppo software e issue tracking

GitHub · GitHub con Personal Access Token · GitLab · Bitbucket · Jira / Confluence (Atlassian) · Jira Cloud con email e API token · Sentry · Figma

CRM e vendite

Salesforce · HubSpot · Pipedrive · Zoho CRM · Bitrix24

E-commerce e pagamenti

Shopify · Stripe · Square · eBay · Coinbase · Tradier

Marketing, email e survey

Mailchimp · Klaviyo · Twilio SendGrid · Typeform · SurveyMonkey · DocuSign

Contabilità e finanza

Xero · Zoho Books · Wave Financial

Comunicazione e collaborazione

Slack · Discord · Twilio · Zoom · Calendly · Help Scout · Zendesk · ServiceNow

Social e contenuti

Facebook · Instagram · LinkedIn · Twitter / X · TikTok · Pinterest · Reddit · YouTube · Twitch · Vimeo · Spotify · Blogger / Blogspot · WordPress.com

Cloud storage e file

Dropbox · Box

Salute e fitness

Fitbit · Strava

Altri servizi

Patreon

Per ciascun connettore, la raccolta documenta il tipo di autenticazione utilizzato — OAuth2, API Key oppure Basic Authentication —, lo stile di paginazione supportato e le eventuali limitazioni note. Queste informazioni sono fondamentali già nella fase di progettazione: permettono di capire in anticipo come verranno letti i dati, quali volumi sono gestibili e come strutturare una pipeline robusta.

La raccolta continuerà a crescere: molti altri connettori sono già in roadmap. L’architettura dichiarativa di PlyxSQL consente infatti di ampliare il catalogo senza dover modificare il motore dell’applicazione, aggiungendo nuove integrazioni attraverso configurazioni JSON mirate.

Più velocità, più controllo

Il valore dei nuovi connettori non è soltanto tecnico. Per aziende e software house significa diminuire il costo di integrazione tra sistemi che, fino a ieri, richiedevano sviluppo dedicato o procedure manuali.

Con PlyxSQL puoi costruire flussi come:

  • Importazione di listini Excel o OpenCalc verso Firebird e altri database.
  • Consolidamento di dati provenienti da servizi cloud e fogli di calcolo.
  • Estrazione da API REST, trasformazione SQL e pubblicazione verso una destinazione remota.
  • Automazione di importazioni ricorrenti da file inviati da clienti o collaboratori.
  • Preparazione di dataset per analisi, controllo di gestione e reporting operativo.

PlyxSQL porta un principio semplice nel mondo ETL: descrivere l’integrazione invece di riscriverla ogni volta. I connettori configurabili, il supporto alle API moderne e l’accesso nativo a Excel e OpenCalc permettono di trasformare fonti eterogenee in dati pronti per essere elaborati, controllati e distribuiti.

Quando i dati iniziano a fluire senza interventi manuali, il software smette di rincorrere l’operatività quotidiana e torna a generare valore.

https://pgsoft.it/plyxhtml

#TextToSQL #AI #DatabaseLegacy #SQL #Firebird #CodeGeneration #SoftwareArchitecture #DataEngineering #LLM #PromptEngineering #DigitalTransformation #PubblicaAmministrazione #SoftwareDevelopment #TechInnovation #PlyxSQL

martedì 18 agosto 2026

Free PlyxSQL ETL - 1.0.0.92

 Free PlyxSQL© Beta - 1.0.0.92 - ETL  

POSTED BY Giuliano pagnini, 18 AGO 2026

Free DOWNLOAD Clicca qui Info https://pgsoft.it/plyxhtml

Free PlyxSQL ETL: pianifica e pubblica automaticamente post per blog e social

PlyxSQL introduce nuove funzionalità ETL pensate per automatizzare un flusso concreto e ripetibile: leggere contenuti da una tabella database, elaborarli e creare post pianificati per il blog o per i canali collegati.

In questo esempio viene realizzato un processo di pubblicazione database-first: i post sono gestiti in una tabella, elaborati da PlyxSQL ETL e creati come contenuti pubblicati o come bozze. Al termine dell’elaborazione, il record viene aggiornato automaticamente, evitando duplicazioni e consentendo una gestione tracciabile dell’intero ciclo editoriale. L’obiettivo è automatizzare la pubblicazione dei contenuti programmati. Il progetto ETL legge dalla tabella sql-blogpost i record previsti per la giornata, crea il post nella destinazione configurata e aggiorna lo stato del record quando l’operazione è completata. Questo approccio permette di gestire il calendario editoriale direttamente nel database, centralizzare i contenuti e ridurre le attività manuali ripetitive.


Il primo passo consiste nel configurare e autorizzare la connessione al servizio di destinazione. Dopo aver completato l’autorizzazione, è possibile creare e salvare la connessione in PlyxSQL ETL.

Configura e autorizza poi Crea connessione





Successivamente, si configura la connessione alla tabella che contiene i contenuti da pubblicare. Nell’esempio viene utilizzata una tabella dedicata ai post, con le informazioni necessarie per titolo, contenuto HTML, data di pubblicazione e stato di elaborazione.

Connessione alla tabella dei post:





La vista calendario consente di visualizzare e pianificare i contenuti programmati. Ogni record del database può corrispondere a un post da pubblicare in una data specifica: il database diventa quindi il punto centrale della pianificazione editoriale.

Vista calendario:





PlyxSQL include un editor HTML integrato per creare, modificare e verificare il contenuto del post prima dell’invio. È possibile gestire testo, formattazione, collegamenti e codice HTML direttamente all’interno del processo.

Editor HTML integrato


Creare il progetto ETL

Crea un nuovo progetto ETL e seleziona la destinazione più adatta al flusso desiderato:

  • NuovoPost per creare e pubblicare il contenuto.

  • NuovoPostBozza per creare il contenuto come bozza, lasciando la revisione o la pubblicazione finale a un momento successivo.

Come origine, configura una query sulla tabella blogpost che selezioni esclusivamente i post previsti per la data corrente e non ancora elaborati.




Impostare la query finale dopo esecuzione fase in modo da aggiornare lo stato del post a evaso.


Mappare i campi origine e destinazione

Collega i campi dell’origine con quelli della destinazione mediante una regola diretta. Per esempio, i campi Titolo, ContenutoHTML, DataPubblicazione e gli eventuali metadati possono essere trasferiti dalla tabella di origine al nuovo post.

La mappatura visuale rende il processo più trasparente e manutenibile, anche quando sono necessari controlli o trasformazioni aggiuntive.

Eseguire o pianificare il progetto

Il progetto può essere eseguito manualmente, utile durante i test, oppure salvato e pianificato per l’esecuzione automatica tramite il servizio.

Con la pianificazione, PlyxSQL ETL può controllare periodicamente la tabella dei contenuti, individuare i post programmati e completare il flusso di pubblicazione in autonomia.


Automazione editoriale database-first

Con PlyxSQL ETL, il database non è soltanto un archivio: diventa il motore del processo editoriale.

Puoi gestire contenuti, date, stati, regole di selezione e pubblicazioni programmate in un unico flusso visuale, controllato e riutilizzabile. Il risultato è un processo più affidabile, tracciabile e scalabile, ideale per software house, team tecnici, enti e organizzazioni che desiderano integrare la pubblicazione dei contenuti nei propri sistemi informativi.




Schedulare il progetto per il servizio


https://pgsoft.it/plyxhtml

#TextToSQL #AI #DatabaseLegacy #SQL #Firebird #CodeGeneration #SoftwareArchitecture #DataEngineering #LLM #PromptEngineering #DigitalTransformation #PubblicaAmministrazione #SoftwareDevelopment #TechInnovation #PlyxSQL