Da FileMaker al cloud: come SchallOS integra software aziendale con IA, runtime e aggiornamenti

Nello sviluppo di un’applicazione aziendale, l’attenzione si concentra inizialmente sulle attività visibili: si creano tabelle, si definiscono relazioni, si progettano maschere di inserimento dati e si automatizzano i processi aziendali. Non appena i primi utenti sono in grado di utilizzare la soluzione, gran parte del progetto sembra essere completata. Nell’uso pratico, tuttavia, ha inizio la fase più impegnativa nel lungo periodo. Un’applicazione aziendale deve essere gestita, ampliata e adattata alle nuove esigenze. Le modifiche devono essere documentate, le nuove versioni distribuite e i dati esistenti trasferiti in modo sicuro. A ciò si aggiungono i diversi diritti utente, i backup dei dati, le analisi degli errori e la questione se una soluzione debba essere gestita localmente, su un server proprio o nel cloud.

Molte piattaforme di sviluppo si concentrano principalmente sulla creazione dell’applicazione vera e propria. Per gli aggiornamenti, la documentazione, la distribuzione e la gestione operativa vengono poi aggiunti in un secondo momento strumenti aggiuntivi e procedure personalizzate. Con il passare del tempo si crea un ambiente tecnico composto da numerosi elementi separati tra loro, che possono essere tenuti insieme solo con un notevole dispendio di risorse. SchallOS adotta quindi un approccio più completo. La piattaforma non solo accompagna un’applicazione aziendale nella sua fase di creazione, ma ne copre l’intero ciclo di vita: dallo sviluppo alla documentazione e alla distribuzione, fino agli aggiornamenti e alla gestione a lungo termine.

Problemi sociali del presente

Johann Sebastian Bach - l'ordine, l'atteggiamento e il fondamento della nostra musica

Johann Sebastian Bach - l'ordine, l'atteggiamento e il fondamento della nostra musica

Dipendenza digitale: come abbiamo perso la nostra autodeterminazione a favore del cloud

Dipendenza digitale: come abbiamo perso la nostra autodeterminazione a favore del cloud

Com'era la Siria prima della guerra? Chi governa oggi? Cosa significa questo per i rifugiati in Germania?

Com'era la Siria prima della guerra? Chi governa oggi? Cosa significa questo per i rifugiati in Germania?

Il pericolo silenzioso dei wearable: quando la comodità diventa sorveglianza

Il pericolo silenzioso dei wearable: quando la comodità diventa sorveglianza

Ultime notizie su SchallOS Studio

12.08.2026: Lo sviluppo di SchallOS prosegue. Nel frattempo è stata Intelligenza artificiale e livello di conoscenza La piattaforma è stata in gran parte completata e profondamente integrata nell'ambiente di sviluppo. SchallOS dispone così di un livello di conoscenza ad autoapprendimento, in grado di assimilare le esperienze acquisite durante lo sviluppo pratico e di adattarsi nel tempo allo stile di programmazione e alle soluzioni preferite del singolo sviluppatore.

Grazie a un sistema di adattatori modulare è possibile collegare qualsiasi modelli di IA locali e basati sul cloud integrare. Per un fornitore o un modello è possibile memorizzare anche più accessi o chiavi API. È possibile utilizzare più modelli in parallelo e ricorrervi per compiti diversi in base alle loro capacità, velocità e risultati ottenuti finora. La scelta del modello avviene automaticamente tramite il Composer integrato: durante lo sviluppo, lo sviluppatore non deve preoccuparsi di stabilire quale modello sia adatto a quale attività. Le soluzioni già note e collaudate possono essere riutilizzate dal livello di conoscenza, in modo che non sia necessario elaborare nuovamente ogni attività per intero tramite un modello di IA.

Sono disponibili direttamente in SchallOS Studio agenti specializzati basati sull'intelligenza artificiale per diversi compiti di sviluppo. Tra questi vi è un Agente di Formula per calcoli e formule, un Agente contenitore funzionale per la programmazione dei contenitori di funzioni, nonché un Agente di layout per lo sviluppo di interfacce utente. I contenitori di funzioni possono inoltre essere modificati direttamente tramite i relativi oggetti di layout e programmati tramite IA. Un elemento di livello superiore Agente di sistema può coordinare gli agenti specializzati, ad esempio quando occorre sviluppare moduli completamente nuovi o funzionalità più complesse.

Il livello di IA è integrato dal Adapter-Studio in SchallOS Control. Ciò consente agli sviluppatori di creare i propri adattatori di rete e dati, ad esempio per il collegamento a sistemi ERP esterni, database o piattaforme aziendali come SAP e Oracle. Le conoscenze necessarie a tal fine, i profili dei modelli e le esperienze specifiche relative alle soluzioni vengono gestiti con un sistema di controllo delle versioni all’interno dell’architettura della conoscenza. SchallOS si sta quindi trasformando sempre più da un classico ambiente di sviluppo a una piattaforma in cui sviluppatori, livello di conoscenza e diversi modelli di IA collaborano alla realizzazione di una soluzione software.

Livello di conoscenza anche per gli utenti e le conoscenze aziendali

Il settore della conoscenza, tuttavia, non si limita solo allo sviluppo di software. Anche nel campo di Livello della soluzione Le applicazioni possono disporre di propri agenti di intelligenza artificiale che assistono l'utente nelle attività quotidiane, ad esempio nella creazione di fatture, nell'analisi dei dati o in altre attività ricorrenti all'interno di una soluzione software. In questo modo, una soluzione può sviluppare conoscenze proprie e metterle a disposizione dei propri agenti.

In futuro, questo ambito sarà notevolmente ampliato. Si prevede, tra l’altro, di integrare conoscenze provenienti da diverse fonti esterne, ad esempio da sistemi di posta elettronica, documenti e dati aziendali, nonché tramite formati di scambio standardizzati come l’Open Knowledge Format (OKF) di Google e grafi di conoscenza come, ad esempio, Neo4j. In questo modo, a lungo termine, le conoscenze di una soluzione SchallOS non saranno più limitate al proprio database, ma attingeranno da diverse fonti informative di un’azienda.

Dalla migrazione FileMaker alla piattaforma propria

Il punto di partenza iniziale di SchallOS è stata la migrazione delle soluzioni FileMaker esistenti. Nel corso dei decenni, FileMaker si è dimostrato un ambiente efficiente per applicazioni di database personalizzate. In particolare, la stretta integrazione tra modello di dati, layout e logica di programma consente uno sviluppo rapido e orientato alla pratica.

Una soluzione FileMaker consolidata, tuttavia, non si limita a tabelle e maschere visibili. Comprende calcoli, script, diritti utente, layout di stampa, interfacce e numerosi casi operativi particolari. Una piattaforma successiva valida deve essere in grado di integrare queste interrelazioni e di gestirle in modo autonomo.

Partendo da questo incarico, SchallOS si è gradualmente evoluto fino a diventare una piattaforma autonoma. Le soluzioni FileMaker esistenti dovranno poter essere migrate, mentre al contempo sarà possibile sviluppare nuove applicazioni direttamente in SchallOS. Una volta completata la migrazione, FileMaker non sarà più necessario per il funzionamento in produzione.

Sviluppo, esecuzione e funzionamento rimangono separati

La piattaforma di sviluppo SchallOS è composta da diverse aree con compiti ben definiti.

• SchallOS Studio è l'ambiente di sviluppo. È qui che vengono creati strutture di dati, layout, formule, funzioni, linguaggi e versioni. Anche l'assistente di migrazione per le soluzioni FileMaker esistenti fa parte di Studio.
• SchallOS Runtime Esegue le applicazioni pubblicate. Fornisce l'interfaccia utente e la logica di programma necessaria, senza rendere automaticamente disponibili tutti gli strumenti di sviluppo.
• SchallOS Control gestisce le destinazioni di distribuzione, le connessioni al database, i profili di runtime, gli aggiornamenti e i controlli tecnici.
• SchallOS Cloud Fornisce applicazioni sotto forma di servizio online gestito centralmente. In questo contesto non è prevista la creazione di un formato cloud separato. Le installazioni locali, basate su server e basate su cloud utilizzano tutte la stessa architettura di base.

Questa separazione impedisce che sviluppo, applicazione e amministrazione si mescolino in modo incontrollato. Allo stesso tempo, tutti i settori rimangono tecnicamente coordinati tra loro.

Una soluzione per diversi modelli operativi

Un'applicazione aziendale può partire in piccolo e crescere in seguito. All'inizio potrebbe essere sufficiente una singola postazione locale. In seguito si aggiungeranno altri collaboratori, un server centrale o più sedi. SchallOS deve quindi essere in grado di fornire la stessa soluzione di base per diverse modalità operative: localmente nel browser, come applicazione Windows o macOS, con SQLite o PostgreSQL, nonché come soluzione SaaS nel cloud.

Non tutte le modalità operative presentano le stesse caratteristiche tecniche. Un database locale presenta requisiti diversi rispetto a un sistema centralizzato multiutente. È tuttavia fondamentale che i layout, le funzioni e il modello di dati non debbano essere sviluppati ex novo per ogni destinazione.

Il ciclo di vita fa parte dell'architettura

In SchallOS, la documentazione, i registri degli eventi e gli aggiornamenti non vengono semplicemente aggiunti a posteriori a un’applicazione già pronta, ma fanno parte dell’architettura di base. La struttura e i dati produttivi vengono gestiti separatamente. Le modifiche apportate durante lo sviluppo possono essere registrate e raggruppate in release. Gli aggiornamenti possono essere verificati, distribuiti e, in caso di problemi, ripristinati in modo controllato. L’intelligenza artificiale integrata non solo supporta la gestione di formule e funzioni, ma anche la documentazione e la comunicazione con i clienti.

In questo modo, SchallOS collega ambiti che nei progetti tradizionali vengono spesso trattati separatamente. Lo sviluppo di un’applicazione non rappresenta più la conclusione del processo tecnico, bensì la prima fase di un ciclo di vita pianificato a lungo termine.

SSC e SSD come contenitori portatili di strutture e dati

Molte applicazioni di database memorizzano struttura, interfaccia utente, logica di programma e dati operativi in un’unica entità strettamente integrata. Ciò risulta comodo all’inizio, ma complica gli aggiornamenti successivi, le migrazioni e le diverse modalità operative. Non appena si aggiungono più clienti, grandi quantità di dati o estensioni personalizzate, la sostituzione di un file applicativo completo diventa rapidamente problematica.

SchallOS separa quindi sistematicamente la descrizione di una soluzione dai relativi dati aziendali. Un’applicazione è costituita essenzialmente da due container correlati: l’SSC per la struttura e l’SSD per i dati operativi.

Entrambi i container costituiscono insieme la soluzione completa, ma svolgono funzioni diverse. L'SSC descrive la struttura e il funzionamento dell'applicazione. L'SSD contiene i contenuti generati durante il suo utilizzo.

L'SSC descrive l'applicazione

Il file SSC è il contenitore strutturale portatile di una soluzione SchallOS. Al suo interno si trovano, tra l’altro:

• Definizioni di tabelle e campi
• Relazioni
• Layout e oggetti di layout
• Formule e funzioni personalizzate
• Contenitore funzionale
• Trigger e navigazione
• Informazioni sulla lingua e sulla traduzione
• Documentazione
• Informazioni sulla versione e sul rilascio

L'SSC non contiene quindi i clienti, gli articoli, gli ordini o le fatture in sé. Definisce quali strutture di dati sono presenti, come vengono rappresentate e quali funzioni operano su di esse. Anche il significato semantico di una soluzione rientra in questo contenitore. Oltre al proprio nome tecnico, un campo può contenere una descrizione funzionale, traduzioni, regole di convalida e indicazioni per il livello di intelligenza artificiale. In questo modo, la struttura non solo diventa leggibile da una macchina, ma anche più comprensibile per gli sviluppatori, ai fini della documentazione e della migrazione.

L'SSC costituisce quindi un modello applicativo portatile che può essere ulteriormente sviluppato e pubblicato indipendentemente da un determinato insieme di dati.

L'SSD contiene i dati operativi

Il file SSD è il contenitore di dati della soluzione. Contiene i record generati durante l’attività quotidiana, ad esempio clienti, offerte, ordini, fatture, movimenti di magazzino o appuntamenti. Inoltre, vi possono essere memorizzati cronologie operative ed eventi relativi ai dati. Tra questi figurano, ad esempio, i cambiamenti di stato, le approvazioni, le importazioni o le modifiche apportate a campi particolarmente importanti. Il termine SSD non si riferisce a un supporto dati fisico, bensì al livello logico dei dati dell’applicazione. Le modalità tecniche di archiviazione di questi dati dipendono dalla distribuzione scelta e dall’adattatore del database.

Per un singolo utente locale è possibile utilizzare IndexedDB. Un’applicazione desktop può funzionare con SQLite, mentre le applicazioni multiutente su larga scala utilizzano PostgreSQL. In tutti i casi, l’SSD rimane il contenitore tecnico dei dati, anche se la modalità di archiviazione tecnica varia.

I due container devono chiaramente appartenere allo stesso carico

La separazione tra struttura e dati non deve comportare la possibilità di combinare tra loro contenitori qualsiasi. SchallOS deve poter verificare se un SSC e un SSD appartengano effettivamente alla stessa soluzione e se le loro versioni siano compatibili tra loro. A tal fine è possibile utilizzare identificatori di soluzione, identificatori di container, versioni della struttura, somme di controllo e firme. In questo modo, prima dell’avvio o di un aggiornamento, è possibile verificare se la combinazione è valida e se le migrazioni dei dati necessarie sono già state eseguite.

Questo controllo impedisce, ad esempio, che venga aperto per errore il contenitore strutturale di un’altra applicazione con un set di dati di produzione. Inoltre, impedisce che venga attivata una nuova versione SSC, qualora l’SSD non sia ancora stato preparato con la struttura dati necessaria a tal fine.

Portabilità tra diverse forme di gestione

La separazione tra SSC e SSD costituisce la base per l'esecuzione di un'applicazione in ambienti diversi. Non è necessario sviluppare ex novo layout, formule e logica funzionale per ogni adattatore di database.

Una soluzione potrebbe partire a livello locale con IndexedDB, per poi passare a SQLite e, con l'aumentare del numero di utenti, migrare a PostgreSQL. È inoltre possibile il passaggio a un ambiente cloud.

Un trasferimento di questo tipo rimane un’operazione tecnica controllata. I diversi database presentano caratteristiche e limitazioni specifiche. Per questo motivo, i dati non vengono semplicemente trasferiti su un altro sistema con un semplice clic. È necessario eseguire espressamente le operazioni di trasferimento, verifica e, se necessario, rollback.

L'architettura garantisce tuttavia che un cambiamento nella gestione dei dati non comporti automaticamente la necessità di ricostruire l'intera applicazione.

Aggiornamenti senza sostituzione dei dati dei clienti

Un vantaggio fondamentale della separazione emerge quando vengono rilasciate nuove versioni. Le modifiche riguardano spesso il layout, le formule, le funzioni o il modello di dati. I dati aziendali esistenti devono invece rimanere invariati.

Uno sviluppatore può quindi pubblicare una nuova versione dell'SSC, mentre l'SSD del cliente rimane in uso presso la sede operativa. Se sono necessari nuovi campi o tabelle, questi vengono aggiunti tramite fasi di migrazione definite. Prima dell’aggiornamento è possibile eseguire un backup dello stato attuale. Successivamente vengono verificati la struttura, la migrazione dei dati e il corretto funzionamento. Solo quando SSC e SSD tornano a formare uno stato coerente, l’aggiornamento si considera completato.

Questa possibilità di aggiornamento non è prevista solo per SchallOS stesso, ma è disponibile anche per le soluzioni personalizzate sviluppate con SchallOS.

Le varianti personalizzate rimangono tracciabili

Il software aziendale personalizzato spesso si evolve in modo diverso a seconda dei clienti. Un cliente ha bisogno di campi personalizzati, un altro di layout aggiuntivi o di un’interfaccia specifica. Senza una struttura chiara, si finiscono rapidamente per ottenere copie complete tra loro divergenti, che diventano difficili da gestire in modo coordinato. Nell’SSC, invece, sia i componenti generali del prodotto che le estensioni specifiche per il cliente possono essere versionati e documentati in modo tracciabile.

L'architettura non sottrae allo sviluppatore la responsabilità di decidere quale modifica debba essere integrata nel prodotto generale. Tuttavia, garantisce che la provenienza e le dipendenze di una modifica rimangano visibili.

Insieme ai protocolli di sviluppo e alle versioni, ciò consente di individuare più facilmente, in occasione di aggiornamenti successivi, quali componenti debbano essere sostituiti, integrati o mantenuti.

Il multilinguismo fa parte della struttura portatile

Anche il livello linguistico è integrato nell’SSC. Le denominazioni non vengono memorizzate esclusivamente in modo fisso nei singoli oggetti di layout, ma possono fare riferimento a voci semantiche con più versioni linguistiche.

In questo modo, un campo come „Numero fattura“ può essere visualizzato in diverse lingue senza dover creare un layout completamente nuovo per ciascuna lingua. Una soluzione FileMaker sottoposta a migrazione può essere automaticamente resa multilingue e tradotta durante il processo di migrazione.

La traduzione automatica non sostituisce una revisione specialistica. Proprio i termini giuridici e specifici del settore devono essere verificati. L'architettura garantisce tuttavia che il multilinguismo sia parte integrante della soluzione fin dall'inizio e non debba essere integrato successivamente con grande fatica in ogni maschera.

Base per una manutenzione a lungo termine

A prima vista, SSC e SSD sembrano una semplice suddivisione tra applicazioni e dati. In realtà, però, costituiscono la base per la portabilità, gli aggiornamenti, i diversi adattatori di database, i backup separati e i vari modelli operativi.

L'SSC descrive che cos'è una soluzione e come funziona. L'SSD contiene ciò che viene generato durante il suo utilizzo e che deve essere conservato in modo permanente per la rispettiva azienda.

Grazie a questa chiara separazione, l'applicazione può continuare a evolversi senza che sia necessario sostituire l'intero database ad ogni nuova versione. Allo stesso tempo, la struttura tecnica dei dati può espandersi o cambiare senza che sia necessario ricostruire completamente i layout e la logica di business.

SchallOS Studio come ambiente di sviluppo integrato

SchallOS Studio è l'area della piattaforma in cui vengono sviluppate nuove applicazioni aziendali e in cui le soluzioni FileMaker esistenti vengono migrate o ulteriormente sviluppate. In questa area vengono gestiti tabelle, campi, relazioni, layout, formule, funzioni, lingue e versioni all'interno di un ambiente comune.

Per gli sviluppatori FileMaker, il modo di lavorare dovrebbe risultare familiare. Le modifiche non vengono apportate esclusivamente in file di codice sorgente astratti, ma rimangono collegate alle componenti visibili dell’applicazione. Uno sviluppatore può modificare un layout, selezionare un campo, modificarne le proprietà e verificare immediatamente l’effetto della modifica sull’applicazione.

SchallOS non cerca tuttavia di riprodurre integralmente FileMaker. Vengono ripresi soprattutto i principi fondamentali che si sono dimostrati efficaci: sviluppo rapido, feedback immediato e uno stretto legame tra modello di dati, interfaccia utente e logica di business. La base tecnica, invece, viene riorganizzata e orientata verso strutture portabili, programmazione supportata dall’intelligenza artificiale, documentazione e rilasci controllati.

Layout, oggetti e proprietà

Una componente fondamentale di SchallOS Studio è la modalità Layout. È qui che vengono creati i moduli di inserimento dati, gli elenchi, le finestre di dialogo, le aree di navigazione e altre interfacce di una soluzione.

Tra i possibili oggetti di layout figurano, tra l’altro, campi, testi, pulsanti, oggetti elenco, schede, popover, contenitori ed elementi di navigazione. Gli oggetti possono essere selezionati, posizionati e configurati tramite un ispettore.

Un oggetto di layout non contiene solo informazioni relative a dimensioni, posizione e visualizzazione. Può inoltre essere collegato a fonti di dati, trigger, formule, funzioni e etichette semantiche. Un oggetto campo, ad esempio, fa riferimento a un campo nel modello di dati, può ricevere un'etichetta specifica per la lingua e attivare determinate funzioni all'entrata o all'uscita.

Poiché ogni oggetto fa parte dell'SSC, le modifiche al layout possono essere sottoposte a controllo di versione, documentate e successivamente distribuite in modo mirato tramite un aggiornamento. L'interfaccia utente non rimane quindi un livello grafico isolato, ma una componente strutturata dell'intera applicazione.

Modello dei dati e descrizioni semantiche

Anche le tabelle, i campi e le relazioni vengono creati e modificati in SchallOS Studio. Qui è possibile sviluppare interamente nuove applicazioni. In caso di migrazione FileMaker, l’assistente alla migrazione riprende, per quanto possibile, le strutture esistenti e le rende disponibili per l’ulteriore elaborazione.

In SchallOS un campo non è costituito solo da un nome tecnico e da un tipo di dati. Può inoltre contenere una descrizione funzionale, regole di convalida, valori predefiniti, traduzioni e note di documentazione.

Queste informazioni hanno diverse finalità. Aiutano gli altri sviluppatori a comprendere meglio la soluzione, favoriscono la documentazione automatica e forniscono un contesto più chiaro all’IA integrata. Anziché limitarsi a riconoscere che un campo si chiama „Stato“, la piattaforma può, ad esempio, sapere se si tratta dello stato di un ordine, dello stato di un pagamento o di uno stato di elaborazione interno.

È inoltre possibile descrivere le relazioni tra le tabelle e documentarle nel loro contesto funzionale. In questo modo, una minore quantità di conoscenze rimane nascosta esclusivamente nella mente dello sviluppatore originale.

Formule con calcolo in tempo reale

SchallOS dispone di un proprio ambiente per le formule. Le formule vengono create nell'editor di formule e calcolate in tempo reale durante la modifica. In questo modo, le modifiche apportate a un'espressione possono essere verificate immediatamente utilizzando valori di prova adeguati o il set di dati corrente.

Il linguaggio delle formule supporta i calcoli tipici richiesti nelle applicazioni aziendali. Tra questi figurano operazioni matematiche, elaborazione di testo, calcoli relativi a date e orari, condizioni logiche, riferimenti ai campi, variabili ed espressioni annidate.

La gamma di comandi disponibili è inizialmente più ridotta rispetto al set di funzioni di FileMaker, che si è ampliato nel corso di decenni. SchallOS non deve necessariamente riprodurre ogni singolo comando storico di FileMaker senza modifiche. È più importante disporre di un ambiente di formule chiaramente strutturato ed espandibile.

In seguito sarà possibile aggiungere ulteriori comandi, qualora fossero necessari per determinate soluzioni o migrazioni. In questo contesto, l’IA integrata può aiutare a trasferire un calcolo esistente o a sviluppare una funzione mancante in linea con l’architettura di SchallOS.

Funzioni personalizzate per calcoli riutilizzabili

Oltre ai comandi integrati, SchallOS supporta le funzioni personalizzate. Queste accettano parametri, eseguono un calcolo definito e restituiscono un risultato. Ciò consente di gestire le regole ricorrenti in un unico punto centrale. Ne sono un esempio il calcolo dei prezzi, la determinazione delle scadenze, la formattazione, la verifica delle serie numeriche o l’elaborazione dei valori importati.

Anche le funzioni personalizzate vengono calcolate in tempo reale e possono essere testate immediatamente nell'editor di formule. Se una funzione viene successivamente corretta o ampliata, tutte le formule che la utilizzano ne trarranno vantaggio.

Inoltre, è possibile descrivere e documentare le proprie funzioni. In questo modo, i parametri, il valore di ritorno, gli esempi e i casi di errore noti rimangono facilmente tracciabili. L'insieme delle funzioni di una soluzione si trasforma in una libreria riutilizzabile, anziché essere costituito da numerosi calcoli singoli copiati.

Contenitori funzionali per processi più complessi

I processi aziendali più complessi vengono organizzati in SchallOS tramite contenitori di funzioni. È possibile, ad esempio, creare record di dati, verificare valori, gestire finestre di dialogo, generare documenti o interagire con interfacce esterne. Un contenitore di funzioni non contiene solo il codice eseguibile, ma comprende anche una descrizione tecnica, i parametri di input, i valori di ritorno, le dipendenze, le funzionalità consentite e le operazioni espressamente escluse.

Diversi oggetti di layout possono utilizzare lo stesso contenitore di funzioni. In questo modo, non è necessario ricreare da capo una funzione per la creazione di una fattura per ogni pulsante o layout.

Nel caso di soluzioni migrate, gli script FileMaker esistenti possono essere mantenuti in background come livello di apprendimento e di riferimento. Essi aiutano a comprendere l'intento originale e il flusso di lavoro precedente. Il nuovo codice eseguibile viene tuttavia generato in modo da adattarsi all'architettura di SchallOS.

Migrazione e nuovo sviluppo nello stesso ambiente

SchallOS Studio non è destinato esclusivamente alle soluzioni FileMaker già esistenti. È possibile sviluppare nuove applicazioni interamente all’interno della piattaforma.

Durante una migrazione, la procedura guidata importa innanzitutto le tabelle, i campi, le relazioni, i layout e gli altri elementi riconoscibili già presenti. Successivamente, gli sviluppatori possono verificare e ripulire la struttura importata, per poi trasferirla gradualmente nella nuova architettura funzionale.

L'obiettivo non è quello di creare una copia identica di tutte le peculiarità precedenti. Le deviazioni maturate nel corso del tempo possono essere riviste e sostituite con strutture più chiare. Allo stesso tempo, le conoscenze tecniche della soluzione esistente vengono preservate.

Le applicazioni nuove e quelle migrate utilizzano quindi gli stessi strumenti, container e canali di distribuzione.

Le modifiche vengono trasformate in versioni controllate

Una modifica apportata in studio non si traduce automaticamente in un aggiornamento produttivo. Durante lo sviluppo possono essere presenti layout non definitivi, formule provvisorie o funzioni non ancora testate.

Le modifiche correlate possono quindi essere registrate nelle "Change Sessions" e successivamente assegnate a una release. Solo dopo la verifica e l'approvazione si ottiene una versione SSC pubblicata.

Oltre alla nuova struttura, una release può includere anche le migrazioni dei dati necessarie, le informazioni sulla versione, le dipendenze, le fasi di verifica e la documentazione. In questo modo, lo sviluppo vero e proprio rimane chiaramente separato dalla distribuzione alle istanze di runtime in produzione.

SchallOS Studio non è quindi solo il luogo in cui viene progettata e programmata un'applicazione. Esso integra lo sviluppo visivo, il modello di dati, le formule, le funzioni, la documentazione e la pubblicazione in un unico ambiente.

Si mantiene la stretta interazione tra lo sviluppatore e l'applicazione visibile. Allo stesso tempo, si crea una base tecnica su cui è possibile sviluppare ulteriormente soluzioni portabili, tracciabili e gestibili nel lungo periodo.

L'intelligenza artificiale alla base della creazione di formule e funzioni

In molti ambienti di sviluppo, l’intelligenza artificiale è stata finora offerta principalmente tramite una finestra di chat aggiuntiva. Lo sviluppatore descrive un problema, copia il codice sorgente o le formule nella chat e successivamente riporta il risultato nel progetto. In questo modo, al modello linguistico mancano spesso informazioni importanti relative a tabelle, campi, relazioni e al significato tecnico dell’applicazione.

SchallOS integra quindi l'IA direttamente negli strumenti di sviluppo. È disponibile proprio dove vengono modificate formule, funzioni personalizzate e contenitori di funzioni. In questo modo non riceve solo una singola domanda, ma anche il contesto attuale della soluzione.

Nell'editor di formule, ad esempio, l'IA conosce l'espressione modificata, i campi disponibili e il tipo di risultato atteso. All'interno di un contenitore di funzioni, può inoltre accedere alla sua descrizione, ai parametri, alle funzionalità e alle dipendenze.

L'intelligenza artificiale non diventa quindi un programma ausiliario a sé stante, ma parte integrante dell'ambiente di sviluppo vero e proprio.

Supporto nell'editor di formule

Le formule controllano numerose operazioni di un'applicazione aziendale. Calcolano i prezzi, verificano le condizioni, determinano le scadenze o influenzano la visualizzazione degli oggetti di layout. L'intelligenza artificiale integrata, nell'editor delle formule, è in grado, tra l'altro, di:

• spiegare una formula esistente
• analizzare i possibili errori
• Aggiungere le condizioni
• semplificare un'espressione
• trasferire una formula FileMaker
• oppure elaborare un nuovo calcolo sulla base di una descrizione tecnica.

Uno sviluppatore potrebbe, ad esempio, specificare che gli ordini superiori a un determinato valore netto richiedono un’ulteriore approvazione, a meno che non sia in vigore un contratto quadro. L’IA è in grado di generare una formula basandosi sui campi presenti nella soluzione. Il risultato rimane visibile come una normale formula. Può essere letto, modificato e calcolato in tempo reale. L’IA non genera quindi alcun processo nascosto il cui funzionamento sarebbe difficile da comprendere.

Se manca un comando necessario, l’IA può aiutare anche a creare una funzione personalizzata adeguata o un’estensione dell’ambiente delle formule. In questo modo, il set di comandi di SchallOS, inizialmente limitato, rimane espandibile.

Funzioni personalizzate basate su specifiche tecniche

I calcoli ricorrenti possono essere gestiti centralmente come funzioni personalizzate. L'IA è in grado di generare, a partire da una descrizione, una funzione con parametri univoci, un valore di ritorno e un comportamento documentato.

Una funzione di questo tipo potrebbe, ad esempio, calcolare i termini di sconto, verificare gli intervalli di numeri o uniformare i valori importati. Oltre alla stampa vera e propria, è possibile generare anche valori di prova, esempi e possibili casi di errore.

Questo non solo semplifica la programmazione iniziale. In caso di modifiche successive, l’IA è in grado di riconoscere il significato della funzione e in quali punti viene utilizzata.

Un calcolo anonimo diventa così una componente documentata e riutilizzabile della soluzione.

Contenitori di funzioni come logica di programma descritta

In SchallOS, i processi più complessi vengono organizzati tramite contenitori di funzioni. Un contenitore di funzioni può, ad esempio, creare record di dati, verificare gli input, gestire finestre di dialogo, generare documenti o richiamare interfacce esterne. Alla base vi è una descrizione strutturata, che può specificare:

• quale funzione svolge
• quali parametri vengono passati
• quale risultato ci si aspetta
• a quali tabelle e campi è consentito accedere
• quali altre funzioni vengono utilizzate
• e quali operazioni sono espressamente escluse.

Sulla base di queste specifiche, l’IA programma il codice eseguibile del contenitore di funzioni. Lo sviluppatore non deve quindi più comporre il flusso di lavoro esclusivamente a partire da numerose singole fasi di script. Il suo compito si concentra maggiormente sulla descrizione precisa della funzione desiderata, dei suoi limiti e della successiva verifica.

Il codice generato rimane comunque visibile. Può essere letto, testato, modificato e confrontato tra diverse versioni. Anche le versioni precedenti possono essere conservate e, se necessario, ripristinate. L’IA si occupa quindi della programmazione, ma non della responsabilità tecnica.

Gli appunti FileMaker come base di apprendimento

Nel caso delle soluzioni FileMaker migrate, gli script esistenti contengono spesso gran parte della logica di business sviluppatasi nel corso degli anni. Essi indicano quali campi sono stati modificati, quali condizioni sono state verificate e quali ulteriori processi sono stati avviati.

Questi script non vengono integrati in modo permanente in SchallOS come livello di runtime eseguibile. Ciò comporterebbe semplicemente il trasferimento di molte dipendenze tecniche e soluzioni alternative preesistenti nel nuovo sistema. Invece, lo script FileMaker originale può essere mantenuto in background nel contenitore di funzioni corrispondente. Esso funge da livello di apprendimento, riferimento e comprensione per l’IA.

L'IA è in grado di dedurne l'intento funzionale del flusso di lavoro precedente. Successivamente, programma il nuovo codice in modo che sia compatibile con l'architettura di SchallOS. Le strutture storiche, quali frequenti cambiamenti di layout, campi globali o script ausiliari contestuali, non devono necessariamente essere riprese tali e quali. Verranno mantenute solo se effettivamente necessarie per il processo aziendale vero e proprio.

Lo script originale rimane comunque una fonte di informazioni. In caso di ulteriori domande, è possibile ricostruire come un processo fosse stato originariamente risolto nella soluzione FileMaker.

Le capacità e i limiti vengono definiti in modo esplicito

Un contenitore di funzioni non deve poter accedere a qualsiasi area dell'applicazione sulla base di una semplice descrizione generica. Per questo motivo è possibile definire espressamente le funzionalità consentite e le esclusioni.

Una funzione può, ad esempio, essere autorizzata a leggere e modificare i record di una determinata tabella, senza poter al contempo eseguire operazioni di cancellazione o modifiche alle configurazioni di sistema. Se il codice generato utilizza una funzionalità non autorizzata, SchallOS è in grado di rilevarlo e di bloccarne l'esecuzione o la pubblicazione.

La descrizione di un contenitore di funzioni non serve quindi solo a fini di documentazione, ma diventa parte integrante del modello di verifica e sicurezza. Questa limitazione è particolarmente importante nel caso del codice generato dall’IA. Al modello linguistico viene concesso un chiaro margine di manovra, mentre la piattaforma verifica che la funzione generata rimanga entro tali limiti.

Il contesto giusto migliora i risultati

La qualità di una funzione generata dall'IA non dipende esclusivamente dalle dimensioni del modello linguistico utilizzato. È fondamentale che il modello riceva le informazioni necessarie. SchallOS è in grado di ricostruire il contesto a più livelli:

1. la questione attuale
2. nell'editor aperto
3. il campo o il contenitore di funzioni selezionato
4. le tabelle e le relazioni coinvolte
5. formule e funzioni esistenti
6. descrizioni semantiche
7. Documentazione e cronologia delle modifiche
8. nonché, in caso di migrazioni, lo script FileMaker originale.

In questo modo, l'IA può operare con una precisione notevolmente maggiore rispetto a quella che otterrebbe con una richiesta isolata in una chat generica.

Allo stesso tempo, non è necessario fornire la soluzione completa per ogni esercizio. Il contesto può essere limitato alle informazioni effettivamente necessarie per la rispettiva funzione.

Modelli intercambiabili anziché un vincolo permanente

Lo strato di IA non deve dipendere in modo permanente da un unico modello o fornitore. Compiti diversi comportano requisiti diversi in termini di qualità, velocità, costi e protezione dei dati.

Una migrazione complessa può richiedere un modello particolarmente potente. Una semplice spiegazione o un adeguamento della formula possono essere effettuati, eventualmente, con un modello più piccolo. Per ambienti sensibili o chiusi, a lungo termine è possibile ricorrere anche a modelli gestiti localmente.

La base di conoscenza permanente non risiede quindi nel modello linguistico, bensì nella soluzione SchallOS: nelle descrizioni, nelle strutture, nei riferimenti agli script, nel codice, nei test e nella documentazione. Il modello di IA rimane uno strumento intercambiabile che, partendo da questo contesto, genera codice eseguibile o suggerimenti comprensibili.

Sviluppo trasparente basato sull'intelligenza artificiale

SchallOS combina il lavoro diretto sulle applicazioni aziendali con la programmazione basata sull'intelligenza artificiale. Le formule possono essere spiegate e generate direttamente. Le funzioni personalizzate nascono da specifiche di business riutilizzabili. I contenitori di funzioni uniscono descrizioni semantiche a codice visibile e verificabile.

Nelle soluzioni migrate, gli script FileMaker vengono mantenuti come ulteriore livello di apprendimento. Essi aiutano a comprendere i processi aziendali esistenti senza perpetuare le precedenti dipendenze tecniche.

Il ruolo dello sviluppatore non scompare per questo. Si trasforma. Requisiti precisi, un’architettura ben strutturata, i test e il controllo tecnico assumono maggiore importanza rispetto all’inserimento manuale di ogni singola fase del programma. Soprattutto nel caso di software critico per l’azienda, questa responsabilità rimane indispensabile.

Indagine in corso sull'uso dei sistemi di intelligenza artificiale locali

Documentazione e registri degli eventi come parte integrante dell'applicazione

La documentazione di un'applicazione aziendale viene spesso redatta solo a sviluppo completato. A causa dei tempi ristretti, il lavoro si concentra inizialmente su nuovi campi, layout, formule e funzioni. La descrizione delle modifiche verrà aggiunta in un secondo momento.

Con il passare del tempo, tuttavia, diventa più difficile ricostruire le decisioni iniziali. Spesso non è più chiaro perché sia stata aggiunta una determinata funzione, quali oggetti fossero coinvolti e quali casi particolari dovessero essere presi in considerazione. SchallOS non considera quindi la documentazione come un’attività aggiuntiva a posteriori. Le modifiche rilevanti vengono registrate come eventi già durante lo sviluppo e collegate alle componenti della soluzione interessate.

Da queste informazioni è poi possibile generare documentazione tecnica, note di rilascio, rapporti dei clienti o verbali delle prestazioni. La documentazione non si basa quindi solo su ricordi o appunti redatti manualmente, ma sulle modifiche effettivamente apportate.

Eventi su più livelli

Una soluzione SchallOS non dispone solo di un unico protocollo generale. La piattaforma distingue diversi livelli di eventi, ciascuno con le proprie funzioni.

• Il Protocollo strutturale registra le modifiche apportate all'SSC. Tra queste figurano, ad esempio, nuove tabelle e campi, layout modificati, formule modificate o nuovi contenitori di funzioni.
• Il Registro degli eventi relativi ai dati Fa parte dell'SSD. In tale sistema vengono registrati gli eventi rilevanti dal punto di vista tecnico che si verificano durante l'utilizzo operativo, quali cambiamenti di stato, approvazioni, annullamenti o modifiche di record di dati importanti.
• A ciò si aggiungono Eventi operativi da Runtime e SchallOS Control. Tra queste figurano, tra l’altro, le operazioni di distribuzione, aggiornamento, verifica, backup e rollback.

Questi ambiti rimangono distinti, ma possono essere collegati tra loro. Un registro di sviluppo non deve diventare confuso a causa delle modifiche quotidiane apportate ai record dei clienti. Viceversa, i dettagli tecnici interni non devono essere automaticamente inclusi nella cronologia operativa di una fattura o di un ordine.

Il protocollo strutturale mostra l'evoluzione della soluzione

Le modifiche apportate a tabelle, campi, layout, formule e contenitori di funzioni possono essere salvate come eventi strutturati. Una voce può registrare quale oggetto è stato modificato, quale stato precedente era presente e quale nuovo stato è stato creato. Inoltre, è possibile registrare lo sviluppatore, la data e l'ora, la motivazione tecnica, l'ordine associato e la versione di rilascio prevista.

Se, ad esempio, viene aggiunto un nuovo processo di approvazione per gli ordini, potrebbero rendersi necessarie diverse modifiche tecniche. Viene creato un campo di stato, viene ampliato un layout, viene adattata una formula e viene programmato un nuovo contenitore di funzioni.

Il protocollo strutturale conserva questi singoli eventi. Allo stesso tempo, essi possono essere raggruppati sotto un unico compito tecnico. In questo modo rimane evidente che diverse modifiche tecniche, considerate nel loro insieme, costituiscono un nuovo processo aziendale.

Le "Change Sessions" raggruppano lavori correlati

Un progetto di sviluppo è spesso costituito da tanti piccoli passaggi. Un elenco puramente cronologico delle singole modifiche non renderebbe adeguatamente il contesto effettivo.

SchallOS può quindi raggruppare le attività correlate in "Change Sessions". Una "Change Session" descrive un compito specifico, un'estensione o una correzione di un errore e raccoglie tutti gli eventi ad essa correlati. Può contenere, ad esempio:

• la descrizione delle mansioni tecniche
• tabelle e layout interessati
• formule e funzioni modificate
• test effettuati
• questioni in sospeso
• nonché l'assegnazione a un cliente o a un ordine.

È possibile associare in un secondo momento diverse sessioni di modifica a una release. In questo modo si crea un collegamento tracciabile tra l'incarico di sviluppo, le modifiche tecniche e la versione pubblicata.

L'intelligenza artificiale presenta gli eventi tecnici in modo comprensibile

Il livello di documentazione è collegato all'intelligenza artificiale integrata di SchallOS. Ciò consente di elaborare automaticamente gli eventi registrati per diversi gruppi target.

Un rapporto tecnico di sviluppo richiede informazioni diverse rispetto a una comunicazione al cliente. Mentre lo sviluppatore desidera vedere nomi di campi specifici, contenitori di funzioni e migrazioni di dati, il cliente è interessato soprattutto a sapere quale funzione è stata aggiunta e quali vantaggi offre. L’IA è quindi in grado di riassumere gli stessi eventi in forme diverse:

• come documentazione tecnica interna
• come informazione chiara per i clienti
• come note di rilascio
• come relazione di progetto
• oppure come prova di pagamento di una fattura.

I testi non nascono liberamente da una descrizione generica, ma vengono ricavati dalle Change Sessions, dalle descrizioni semantiche degli oggetti e dalle effettive modifiche strutturali.

Il testo generato rimane collegato alle sue fonti. Lo sviluppatore può verificare su quali eventi si basi un’affermazione e correggere o approvare la formulazione prima del suo utilizzo.

Rapporti sulle prestazioni per sviluppatori e clienti

Per gli sviluppatori di software personalizzato, la documentazione riveste un’importanza anche dal punto di vista economico. I servizi devono essere spiegati al cliente in modo comprensibile e spesso vengono fatturati in base al tempo impiegato o ai pacchetti di lavoro.

Nella pratica, tali registri delle prestazioni vengono spesso redatti solo poco prima dell'emissione della fattura. A tal fine è necessario cercare tra e-mail, appunti e promemoria.

SchallOS è in grado di associare gli eventi di sviluppo effettivamente registrati a un cliente, a un progetto o a un ordine. L'intelligenza artificiale genera quindi le voci appropriate per un registro delle prestazioni. Ad esempio, è possibile raggruppare diverse modifiche tecniche in un'unica prestazione comprensibile:

Ampliamento della gestione degli ordini con l'introduzione di un processo di approvazione in due fasi, comprensivo di verifica dello stato, diritti utente e personalizzazione della maschera di inserimento dati.

I processi tecnici sottostanti rimangono comunque consultabili. La descrizione fornita al cliente costituisce semplicemente una sintesi di facile comprensione. La scelta finale spetta allo sviluppatore. Non tutti gli eventi tecnici sono automaticamente fatturabili e le prove interne o le correzioni non devono necessariamente figurare singolarmente in fattura.

Eventi a livello di dati

Anche durante il funzionamento operativo è possibile registrare tutti gli eventi relativi ai dati previsti. Tra questi figurano la creazione e la modifica di record, i cambiamenti di stato, le autorizzazioni, le importazioni, le esportazioni o i processi eseguiti automaticamente. Una voce può riportare:

• quale utente o processo ha avviato l'azione
• quale record è stato interessato
• quali valori sono stati modificati
• quale funzione è stata eseguita
• e se l'operazione è stata completata con successo.

La soluzione adottata determina quali eventi vengono memorizzati e a quale livello di dettaglio. Una piccola correzione nel testo ha un significato diverso rispetto alla modifica di una fattura già approvata. Il registro degli eventi relativi ai dati costituisce quindi la cronologia operativa dell’SSD. Esso supporta l’assistenza tecnica, l’analisi degli errori e la tracciabilità dei processi aziendali più importanti.

Un protocollo di questo tipo può anche costituire una base per i requisiti di audit. Tuttavia, occorre verificare, per ogni singolo caso d’uso, se esso soddisfi tutte le disposizioni legali o specifiche del settore.

La documentazione accompagna anche le versioni e gli aggiornamenti

Gli eventi di sviluppo registrati confluiscono contemporaneamente nella pipeline di rilascio e aggiornamento. Quando viene pubblicata una nuova versione, SchallOS è in grado di individuare automaticamente quali funzioni sono state aggiunte, quali errori sono stati corretti e quali strutture di dati sono state modificate. Da ciò derivano elenchi delle modifiche tecniche, note per gli utenti e informazioni sulla migrazione.

Dopo l'installazione, è possibile verificare quale versione sia stata installata su una determinata istanza di runtime e quali modifiche essa contenga.

Vengono documentati anche gli eventi operativi quali i backup, i controlli o un eventuale rollback. In questo modo, in seguito sarà possibile non solo stabilire cosa è stato sviluppato, ma anche quando e con quale risultato una modifica è stata implementata in produzione.

Una base di conoscenze in continua espansione

La combinazione tra registro degli eventi, descrizioni semantiche e supporto dell'intelligenza artificiale crea, nel lungo periodo, una base di conoscenze relativa all'intera soluzione. In caso di modifiche successive, non sarà possibile limitarsi a esaminare il codice attuale: sarà infatti possibile risalire a quando una funzione è stata introdotta, quale motivazione aziendale ne fosse alla base e quali altri ambiti fossero stati interessati all'epoca.

Proprio nel caso di applicazioni aziendali sviluppatesi nel corso di molti anni, questa conoscenza è fondamentale. Un caso particolare apparentemente superfluo può avere un'importante motivazione storica. Senza documentazione, si corre il rischio che venga accidentalmente rimosso in occasione di una successiva revisione. SchallOS conserva quindi non solo gli stati tecnici, ma anche la cronologia dello sviluppo e le decisioni ad essa correlate.

La documentazione diventa così una componente attiva dell'applicazione. Supporta lo sviluppo, la comunicazione con i clienti, la fatturazione, l'assistenza, il rilascio delle versioni e la manutenibilità a lungo termine, sulla base degli eventi che si sono effettivamente verificati nel sistema.

Una pipeline di aggiornamento a livello di sistema per la piattaforma e le applicazioni

I software aziendali raramente rimangono invariati per lunghi periodi. Nuove esigenze, modifiche normative, correzioni di errori e sviluppi tecnici portano regolarmente al rilascio di nuove versioni. In questi casi, non è sufficiente limitarsi a scambiare i file. Prima di ogni aggiornamento è necessario verificare quale versione sia quella di riferimento, se sia necessario adeguare le strutture dei dati e come sia possibile ripristinare lo stato precedente in caso di errore.

In molte applicazioni personalizzate, tali procedure vengono sviluppate solo in un secondo momento. Gli aggiornamenti vengono quindi distribuiti tramite istruzioni manuali, copie di backup e script personalizzati. Con ogni nuova installazione aumenta il rischio che si creino versioni diverse e soluzioni ad hoc.

SchallOS considera quindi gli aggiornamenti come una funzionalità della piattaforma a livello di sistema. Attraverso la stessa pipeline di base vengono aggiornati sia SchallOS stesso sia le soluzioni dei clienti sviluppate con la piattaforma.

Uno sviluppatore non deve quindi progettare da zero una propria procedura di aggiornamento per una nuova applicazione. La gestione delle versioni, il controllo, la distribuzione e la registrazione fanno parte dell'architettura comune fin dall'inizio.

La separazione tra SSC e SSD protegge i dati produttivi

La possibilità di aggiornamento è direttamente correlata alla separazione tra struttura e dati. L'SSC contiene layout, formule, contenitori di funzioni, definizioni linguistiche e il modello di dati dell'applicazione. L'SSD contiene i dati aziendali operativi della rispettiva impresa.

Con una nuova versione, quindi, non viene sostituita l'intera applicazione, compresi tutti i dati dei clienti. È invece possibile pubblicare un nuovo SSC, mentre l'SSD esistente rimane in funzione sul posto.

Qualora la nuova struttura richieda campi aggiuntivi, tabelle o formati di dati modificati, vengono eseguite procedure di migrazione espressamente definite a tal fine. I dati di produzione vengono adattati alla nuova struttura in modo controllato e non vengono sostituiti con un altro set di dati senza che ciò venga notato.

Questa netta separazione consente di continuare a sviluppare le applicazioni nel corso di molti anni senza dover trasferire, ad ogni aggiornamento, tutti i dati aziendali in un nuovo file completo.

Dallo stadio di sviluppo al rilascio

Non tutte le modifiche apportate in SchallOS Studio sono immediatamente adatte all'uso in produzione. Durante la fase di sviluppo possono essere presenti layout provvisori, funzioni incomplete o formule non ancora testate.

Le modifiche correlate vengono quindi inizialmente registrate nelle "Change Sessions" e assegnate a una release pianificata. Solo dopo la verifica e l'approvazione si ottiene una versione pubblicata. Una release può includere, tra l'altro:

• un numero di versione univoco
• l'SSC aggiornato
• migrazioni necessarie verso SSD
• Requisiti tecnici
• Dipendenze relative al runtime o agli adattatori
• Fasi di verifica e collaudo
• Note di rilascio
• nonché informazioni relative a un eventuale rollback.

Il livello di documentazione fornisce la base necessaria a tal fine. Dagli eventi di sviluppo registrati è possibile generare automaticamente elenchi delle modifiche tecniche e istruzioni d'uso chiare.

Una versione non è quindi costituita solo da file modificati. Descrive anche quali modifiche sono state apportate, quali sono i prerequisiti e come deve essere verificata l'installazione.

SchallOS Control gestisce la distribuzione

SchallOS Control si occupa della gestione operativa degli aggiornamenti. In questa sezione è possibile visualizzare quali istanze sono presenti, quali versioni sono state sottoposte a installier e quali aggiornamenti sono disponibili. Prima dell'installazione, Control può verificare, tra l'altro:

• se l'entità di destinazione è raggiungibile
• quale versione di Runtime e SSC viene utilizzata
• quale adattatore di database è attivo
• se sia possibile creare un backup adeguato
• e se tutti i requisiti per il rilascio siano stati soddisfatti.

In questo modo si evita che un aggiornamento venga eseguito su un'installazione tecnicamente non idonea o preparata in modo incompleto.

Inoltre, una versione non deve necessariamente essere distribuita contemporaneamente a tutti i sistemi. Può essere inizialmente implementata in un ambiente di test o su installazioni selezionate. Solo dopo aver superato con successo i test si procede alla distribuzione su più ampia scala.

A tal fine è possibile prevedere diversi canali di aggiornamento, ad esempio versioni stabili per l'ambiente di produzione, versioni preliminari, test interni o release personalizzate per i clienti.

Firme e numeri di versione univoci

I pacchetti di aggiornamento possono essere corredati di checksum e firme digitali. In questo modo, SchallOS Control è in grado di verificare se un pacchetto è completo, proviene dalla fonte prevista e se è stato modificato dopo la sua pubblicazione.

Inoltre, viene verificato se la versione appartiene effettivamente alla soluzione in questione. Un nuovo SSC non deve essere collegato per errore all'SSD di un'altra applicazione.

Identificatori univoci delle soluzioni, versioni della struttura e versioni del modello di dati garantiscono che lo stato a install rimanga tracciabile. È inoltre possibile individuare le fasi intermedie necessarie. Ad esempio, un’installazione non può passare direttamente da una versione molto vecchia a quella più recente se prima è necessario eseguire una migrazione dei dati.

Backup, migrazione e verifica

Prima di procedere a un aggiornamento strutturale, viene eseguito il backup dello stato attuale. La modalità concreta di esecuzione del backup dipende dall'adattatore di database utilizzato. Un'installazione locale di IndexedDB o SQLite richiede procedure diverse rispetto a un server PostgreSQL.

Successivamente, viene verificato il pacchetto di aggiornamento, viene implementata la nuova struttura 1TP12 e, se necessario, viene eseguita la migrazione dei dati. Dopo l'attivazione segue la verifica. In questa fase, SchallOS può ad esempio controllare:

• se tutte le tabelle e i campi previsti sono presenti,
• se la migrazione dei dati sia stata completata,
• se il numero di record e i totali di controllo corrispondono,
• e se le funzioni importanti vengono eseguite correttamente.

Solo una volta superati con successo questi test, l'aggiornamento viene considerato installiert. Il semplice trasferimento dei file non è quindi sufficiente. È fondamentale che la struttura, i dati e il runtime tornino a costituire un insieme coerente e funzionante.

Rollback in caso di aggiornamenti non riusciti

Nonostante un'attenta preparazione, un aggiornamento può fallire. Dati preesistenti imprevisti, una migrazione errata o una dipendenza non considerata possono impedire l'attivazione sicura di una nuova versione. In questi casi, il rollback fa parte della procedura di aggiornamento. In questo modo vengono ripristinati la versione precedente di SSC, lo stato salvato di SSD e la configurazione precedente.

Tuttavia, non tutti gli aggiornamenti possono essere ripristinati a una versione precedente per un periodo illimitato. Se, dopo l'installazione, sono già stati elaborati nuovi dati operativi in base a regole modificate, un ritorno completo alla versione precedente può risultare problematico. Una release deve quindi specificare a quali condizioni è possibile effettuare un rollback.

In alcuni casi è più opportuno effettuare un aggiornamento correttivo successivo piuttosto che ripristinare un set di dati precedente. La piattaforma fornisce il quadro tecnico di riferimento, ma la decisione concreta dipende dalla modifica in questione e dalla sua rilevanza dal punto di vista tecnico.

Anche SchallOS stesso utilizza questa pipeline

La pipeline di aggiornamento non è destinata solo alle soluzioni dei clienti. Anche SchallOS Studio, Runtime, Control e altri componenti della piattaforma vengono aggiornati tramite gli stessi meccanismi di base. Le nuove versioni della piattaforma possono includere estensioni dell’ambiente delle formule, miglioramenti del livello di intelligenza artificiale, nuovi adattatori per database o correzioni di sicurezza. Anche in questo caso sono necessari numeri di versione, dipendenze, firme e verifiche.

In questo modo, l'infrastruttura viene utilizzata e testata costantemente durante il funzionamento della piattaforma stessa. Le applicazioni sviluppate con SchallOS beneficiano delle stesse procedure.

Lo sviluppatore non riceve quindi una funzione di aggiornamento prevista solo a livello teorico, bensì una pipeline che fa parte sia del funzionamento che dell'ulteriore sviluppo dell'intero sistema.

Una direzione prevista per le versioni future

Il punto di forza della pipeline di aggiornamento non risiede solo nella distribuzione automatica dei nuovi file. È fondamentale l'integrazione di sviluppo, documentazione, backup, migrazione, verifica e rollback all'interno di un unico flusso di lavoro.

Sia SchallOS che le applicazioni sviluppate con esso utilizzano la stessa infrastruttura di base. La separazione tra SSC e SSD garantisce che la struttura possa continuare a evolversi, mentre i dati di produzione vengono protetti e adattati in modo controllato.

Una soluzione sviluppata con SchallOS dispone quindi, fin dall'inizio, di un percorso prestabilito per le versioni future. Proprio nel caso dei software aziendali, destinati a essere utilizzati per molti anni, questa possibilità di aggiornamento non è una funzione aggiuntiva, ma un requisito essenziale per una manutenzione duratura e un funzionamento affidabile.

Runtime, Control e Cloud per diversi modelli operativi

Un ambiente di sviluppo richiede funzionalità estese. Gli sviluppatori devono poter modificare le strutture, progettare i layout, elaborare le formule e pubblicare nuove funzioni. Nella gestione quotidiana di un’applicazione aziendale già pronta, invece, questi strumenti non sono solitamente necessari.

SchallOS suddivide quindi lo sviluppo, l'esecuzione e la gestione in aree distinte. SchallOS Studio è dedicato allo sviluppo. SchallOS Runtime esegue le applicazioni pubblicate. SchallOS Control ne gestisce la distribuzione tecnica. SchallOS Cloud offre la stessa architettura di base sotto forma di servizio online gestito centralmente.

In questo modo non vengono create applicazioni indipendenti l'una dall'altra. Tutti i moduli utilizzano le stesse strutture SSC e SSD. La modalità operativa viene definita tramite il deployment, l'adattatore di database e il profilo di runtime.

SchallOS Runtime esegue le soluzioni pubblicate

SchallOS Runtime collega l'SSC di un'applicazione all'SSD corrispondente e mette a disposizione i layout, le formule e le funzioni ivi definiti. Il runtime comprende, tra l'altro, la visualizzazione e la gestione dei layout, la lettura e la modifica dei record, il calcolo delle formule e delle funzioni personalizzate, l'esecuzione dei contenitori di funzioni, la navigazione e il controllo delle finestre di dialogo, il supporto multilingue e la connessione all'adattatore di database previsto.

Tuttavia, il runtime non include automaticamente tutti gli strumenti di SchallOS Studio. Non è in grado di creare nuove coppie di soluzioni SSC/SSD e non dispone di un assistente di migrazione per le soluzioni FileMaker.

In questo modo, un'applicazione cliente distribuita rimane chiaramente separata dall'ambiente di sviluppo vero e proprio.

I profili determinano le funzionalità di un runtime

Non tutte le installazioni richiedono le stesse funzionalità. Un'applicazione destinata esclusivamente agli utenti finali potrebbe dover eseguire solo layout e processi aziendali pubblicati. Un'installazione interna potrebbe invece richiedere ulteriori funzioni amministrative o diagnostiche.

A tal fine, SchallOS utilizza profili di runtime e di capacità. Questi profili definiscono quali capacità tecniche possiede una specifica istanza.

Un profilo può, ad esempio, determinare se la modalità di layout è disponibile, se è possibile importare o esportare dati, se vengono visualizzate le finestre di dialogo amministrative, se è possibile modificare le impostazioni locali o se è consentito utilizzare determinate interfacce.

Questi profili integrano i diritti utente all'interno della soluzione vera e propria. I diritti utente determinano quali operazioni una persona è autorizzata a svolgere dal punto di vista funzionale. Il profilo di runtime, invece, definisce quali funzionalità tecniche sono disponibili in linea di principio nella rispettiva installazione.

In questo modo è possibile utilizzare la stessa base di runtime per diversi gruppi di clienti e casi d'uso, senza dover sviluppare una versione del programma specifica per ogni variante.

Dal singolo computer locale all'ambiente server

Una soluzione SchallOS può essere implementata in diverse modalità operative. Ad esempio, per una postazione singola locale, l’SSD può essere salvato in IndexedDB. Un’applicazione desktop a install può utilizzare SQLite. Per soluzioni multiutente di dimensioni maggiori è previsto l’uso di un database centrale come PostgreSQL.

I modelli operativi presentano caratteristiche diverse. IndexedDB è particolarmente indicato per le applicazioni browser locali. SQLite è una base collaudata per applicazioni locali e installazioni di dimensioni contenute. PostgreSQL è indicato per sistemi centralizzati multiutente con gestione professionale dei server.

SchallOS non considera queste tecnologie come supporti di archiviazione completamente intercambiabili. Il cambio di adattatore richiede un trasferimento controllato dei dati, una verifica e, se necessario, un rollback. L’architettura combinata SSC/SSD garantisce che layout, formule e logica di business non debbano essere sviluppati ex novo per ogni adattatore di database.

Applicazioni desktop e navigazione web

Le soluzioni SchallOS devono poter funzionare sia nel browser sia come applicazioni installabili su Windows e macOS. Un runtime desktop può integrarsi più profondamente nel rispettivo sistema operativo, utilizzare i file locali in modo controllato e, con una configurazione adeguata, funzionare temporaneamente offline. Può memorizzare i propri dati localmente con IndexedDB o SQLite oppure accedere a un database PostgreSQL centrale.

Nel browser, l'applicazione viene visualizzata tramite il runtime SchallOS. A tal fine non sono necessari né il server FileMaker né FileMaker WebDirect. Una soluzione FileMaker migrata, quindi, dopo il trasferimento non viene più eseguita in background su un file FileMaker. Layout, formule e logica funzionale vengono eseguiti all’interno dell’architettura SchallOS.

SchallOS Control gestisce le istanze

SchallOS Control costituisce la centrale operativa della piattaforma. È qui che viene gestito quale soluzione viene eseguita su quale sistema di destinazione e quali sono i requisiti tecnici applicabili. Control è in grado, tra l’altro, di visualizzare:

• quali coppie SSC/SSD sono state messe a disposizione
• quale versione di runtime è la installiert
• quale adattatore di database viene utilizzato
• quale profilo di capacità si applica
• quali aggiornamenti sono disponibili
• e quando è stata effettuata l'ultima verifica di un'istanza.

Una destinazione di distribuzione può essere, ad esempio, un'applicazione Windows locale, un runtime macOS, un server PostgreSQL autonomo, un ambiente di test o un'istanza cloud.

Le informazioni operative quali indirizzi dei server, accessi ai database, licenze o associazioni a dispositivi locali non devono essere incluse nell'SSC portatile. Queste vengono gestite nella configurazione protetta della rispettiva istanza.

Soluzioni firmate e distribuzione controllata

I contenitori di soluzioni portatili non devono implicare che ogni applicazione possa essere modificata a piacimento o avviata su sistemi non previsti. I pacchetti SSC/SSD pubblicati possono quindi essere associati a identificativi di soluzione, somme di controllo, firme e informazioni sull’istanza. Al momento dell’avvio, il runtime può verificare se l’SSC è integro e firmato in modo valido, se l’SSD appartiene alla soluzione corretta, se entrambe le versioni sono compatibili tra loro e se è presente un profilo di distribuzione valido.

A seconda del modello di licenza, l’assegnazione può essere vincolata a un’istanza, a un server, a un dispositivo o a un determinato gruppo di utenti. SchallOS Control gestisce anche le modifiche necessarie, come ad esempio il cambio di server, una nuova attivazione o il ripristino di un’installazione.

SchallOS Cloud come modello operativo SaaS

SchallOS Cloud fornisce applicazioni sotto forma di servizio online gestito centralmente. Il cloud, tuttavia, non utilizza un proprio formato di soluzione diverso da quello standard. Un’applicazione sviluppata in SchallOS Studio può essere assegnata a un’istanza cloud e resa disponibile tramite browser. Runtime, database, backup, monitoraggio e aggiornamenti sono gestiti centralmente. Per sviluppatori e clienti ne deriva un modello SaaS, senza che sia necessario sviluppare ex novo l’applicazione per una piattaforma cloud separata.

La portabilità di base rimane garantita. Una soluzione può essere trasferita in un secondo momento su un server proprio o in un altro ambiente supportato, purché il volume dei dati, le funzioni e i requisiti tecnici lo consentano. Il passaggio rimane una migrazione controllata, ma non richiede una completa ricostruzione dell'applicazione.

Una soluzione in grado di adattarsi alle esigenze in continua evoluzione

Una nuova applicazione può essere inizialmente sviluppata in locale e testata con un piccolo set di dati. Successivamente, può essere distribuita come runtime interno, migrata su SQLite o PostgreSQL e infine pubblicata come soluzione server o cloud. Tabelle, layout, formule, contenitori di funzioni, traduzioni e documentazione rimangono parte integrante della stessa struttura della soluzione.

Non tutti i prototipi si trasformano in una grande applicazione aziendale senza necessità di adeguamenti. Il funzionamento multiutente, la sicurezza, le prestazioni e il backup devono comunque essere pianificati con cura. La piattaforma, tuttavia, evita che la crescita comporti inevitabilmente un cambio completo di tecnologia.

Runtime, Control e Cloud integrano così diversi modelli operativi all’interno di un’architettura comune. L’applicazione viene sviluppata una sola volta e successivamente resa disponibile in modo controllato per il rispettivo utilizzo: in locale, su un server proprio o come SaaS nel cloud.

Volentieri. Inserirei questa sezione subito dopo il capitolo sull’IA oppure come integrazione al capitolo 4. Essa riprende un concetto importante: l’IA non è vincolata in modo rigido a un fornitore, ma viene trattata, come gli adattatori di database, come un’infrastruttura intercambiabile.

Adattatori per l'IA anziché vincoli con i produttori

SchallOS separa volutamente il livello di IA vero e proprio dai modelli linguistici utilizzati. La piattaforma non opera esclusivamente con un unico fornitore o con un determinato ambiente di esecuzione. È invece possibile configurare e gestire centralmente diversi adattatori di IA.

Questi adattatori fungono da collegamento tra SchallOS e i modelli linguistici utilizzati. In questo modo, l'ambiente di sviluppo vero e proprio rimane indipendente dal fatto che una richiesta venga inviata a un modello locale o a un servizio cloud.

L'IA diventa così una componente intercambiabile della piattaforma, proprio come gli adattatori di database per IndexedDB, SQLite o PostgreSQL.

Gestione centralizzata in SchallOS Control

La configurazione dell'IA avviene a livello centrale tramite SchallOS Control. In questa piattaforma è possibile creare e gestire un numero illimitato di adattatori IA. Sono supportati sia i modelli locali che i servizi cloud.

I modelli locali possono essere integrati, ad esempio, tramite Ollama o LM Studio. Per molte attività di sviluppo è sufficiente un modello locale compatto, eseguito interamente sul proprio computer.

Inoltre, è possibile configurare modelli cloud come ChatGPT, Claude o altri servizi compatibili. Ogni adattatore dispone di una propria configurazione, che comprende ad esempio credenziali di accesso, endpoint, nomi dei modelli o altre impostazioni tecniche. In questo modo si ottiene una panoramica centralizzata di tutti i sistemi di IA disponibili all’interno di un’installazione di SchallOS.

Una volta configurato, è disponibile ovunque

Uno dei principali vantaggi di questa architettura è che, una volta configurato, un adattatore IA non viene utilizzato solo in un unico punto. Non appena un adattatore viene configurato in SchallOS Control, è disponibile per l'intera piattaforma. Può essere utilizzato, ad esempio:

• nell'editor di formule
• all'interno dei contenitori di funzioni
• per la documentazione automatica
• nella migrazione delle soluzioni FileMaker
• nell'Adapter Studio
• o nei futuri strumenti di sviluppo basati sull'intelligenza artificiale.

Lo sviluppatore non deve quindi configurare più volte i dati di accesso o i modelli. La gestione avviene a livello centrale, mentre i singoli componenti si limitano a selezionare l'adattatore desiderato.

Il modello più adatto per ogni specifica attività

Non tutti i compiti di sviluppo richiedono la stessa potenza di calcolo. Per una breve spiegazione di una formula è spesso sufficiente un piccolo modello locale. Le migrazioni di grandi dimensioni o i compiti di programmazione complessi possono invece trarre vantaggio da un modello cloud più potente.

SchallOS consente quindi di scegliere diversi adattatori a seconda del caso d’uso. Uno sviluppatore può, ad esempio, stabilire che la documentazione semplice venga sempre creata localmente, mentre i compiti particolarmente complessi vengano affidati a un modello esterno. In questo modo è possibile conciliare meglio velocità, protezione dei dati e costi.

Aperto a modelli futuri

Lo sviluppo nel campo dell'intelligenza artificiale procede a un ritmo straordinariamente rapido. Nuovi modelli vengono lanciati a brevi intervalli, mentre i sistemi esistenti vengono continuamente migliorati. Per questo motivo, SchallOS non si lega in modo permanente a un singolo fornitore. Ciò che conta non è il nome di un determinato modello, bensì l'interfaccia di adattamento standardizzata.

In questo modo sarà possibile integrare in un secondo momento nuovi sistemi di IA locali o basati su cloud senza dover modificare l’ambiente di sviluppo vero e proprio. Questa apertura è in linea con l’architettura di base di SchallOS. Come nel caso degli adattatori per database, anche gli adattatori di IA devono rimanere intercambiabili, mentre Studio, il runtime e l’applicazione vera e propria possono continuare a funzionare senza modifiche.

In questo modo, l'intelligenza artificiale diventerà una funzionalità integrata in modo permanente nella piattaforma, indipendentemente dai modelli o dai fornitori che si affermeranno sul mercato nei prossimi anni.

Un livello di IA ad autoapprendimento anziché prompt statici

Uno dei principali progressi di SchallOS consiste nel fatto che l'IA integrata non opera più esclusivamente con prompt di sistema statici. Si crea invece un livello di IA ad autoapprendimento che migliora continuamente il proprio funzionamento sulla base di progetti di sviluppo reali.

Ogni esecuzione di programmazione di un contenitore di funzioni può fornire – se lo sviluppatore lo desidera – dati di qualità anonimizzati. Sono inoltre disponibili test di benchmark riproducibili, in cui i contenitori di funzioni reali di una soluzione vengono testati automaticamente con diversi modelli di IA locali e su cloud. SchallOS valuta non solo la velocità, ma soprattutto la qualità dei risultati generati, gli errori rilevati, i cicli di correzione e il rispetto dei contratti di programmazione definiti.

Da questi dati vengono generati automaticamente profili di modelli con versione, modelli di apprendimento e anti-modelli. La piattaforma apprende così non solo quale prompt funziona meglio, ma anche quali strategie si sono effettivamente dimostrate efficaci per determinate famiglie di modelli, compiti e situazioni di errore.

Livelli di competenza nell'IA da L1 a L4

SchallOS introduce una classificazione a più livelli dei modelli di IA utilizzati. Anziché classificare ogni modello in modo generico come „idoneo“ o „non idoneo“, la valutazione viene effettuata in base a diverse aree di applicazione. Un modello può, ad esempio, raggiungere il massimo livello di qualificazione per le migrazioni FileMaker, mentre per i nuovi sviluppi semantici viene inizialmente raccomandato solo in misura limitata. La classificazione non si basa sulle specifiche del produttore, ma esclusivamente su benchmark riproducibili e cicli di produzione reali.

In questo modo, SchallOS è in grado di determinare automaticamente quale modello abbia la maggiore probabilità di successo per una determinata attività e quando sia opportuno utilizzare un modello più potente o alternativo.

Profili di modelli intelligenti al posto dei classici prompt

In futuro, ogni modello di IA supportato avrà un proprio profilo di modello con numero di versione. Questo non solo descrive le istruzioni effettive del sistema, ma contiene anche le esperienze acquisite nell'uso pratico proprio per quel modello specifico.

In futuro, SchallOS distinguerà, tra l’altro, tra profili per:

• contenitori di funzioni semantiche
• Migrazioni FileMaker
• successive migrazioni a Microsoft Access, 4D o Oracle
• nonché altri sistemi sorgente

Questi profili sono integrati da testi di base modificabili, che possono essere adattati dallo sviluppatore o perfezionati tramite campagne di ottimizzazione automatiche. In questo modo, SchallOS è in grado di testare diverse varianti durante la notte e di adottare automaticamente le strategie più efficaci.

Le funzionalità della soluzione come interfaccia specialistica intelligente

Oltre alle capacità tecniche della piattaforma (Platform Capabilities), SchallOS introdurrà in futuro le capacità delle soluzioni (Solution Capabilities). Queste descrivono le funzionalità specifiche di un’applicazione concreta e costituiscono l’interfaccia pubblica tra l’intelligenza artificiale e la logica di business. Ne sono un esempio funzioni quali:

• Crea cliente
• Crea un'offerta
• Accetta l'incarico
• Generare una fattura
• Registrare il pagamento

L'IA può interagire con una soluzione esclusivamente tramite queste funzionalità autorizzate. Gli accessi diretti ai contenitori di funzioni interni sono volutamente esclusi. In questo modo è sempre possibile verificare quali azioni l'IA sia effettivamente autorizzata a eseguire.

Lo sviluppatore può definire e gestire comodamente le proprie Solution Capabilities, assegnando loro una versione. Queste vengono salvate insieme alla soluzione nell'SSC e sono a disposizione sia dell'IA di sviluppo che, in seguito, degli utenti finali.

Imparare da progetti reali

Il motore di benchmark integrato non utilizza programmi di esempio artificiali, ma, su richiesta, impiega come base di test i contenitori funzionali reali della rispettiva soluzione. In questo modo, per ogni applicazione viene generata una valutazione dell’IA personalizzata, perfettamente adattata allo stile di programmazione specifico, agli oggetti di business utilizzati e ai contenitori funzionali disponibili.

Più a lungo una soluzione viene utilizzata e perfezionata, più i suoi modelli di apprendimento diventano completi e più SchallOS è in grado di selezionare modelli adeguati, evitare errori e generare automaticamente nuove funzioni.

L'intelligenza vera e propria non risiede quindi più esclusivamente nel modello linguistico stesso, ma sempre più nella soluzione e nel suo bagaglio di conoscenze acquisite attraverso l'esperienza, in continua crescita.

Adapter Studio come piattaforma di integrazione universale

Con il nuovo adattatore Studio, SchallOS si evolve in una piattaforma di integrazione aperta. In futuro sarà possibile integrare sistemi esterni tramite adattatori standardizzati, indipendentemente dal fatto che si tratti di database, servizi cloud, interfacce REST o sistemi di intelligenza artificiale.

In questo modo non si creano più integrazioni rigide e proprietarie. Gli sviluppatori possono invece collegare qualsiasi sistema esterno alla propria applicazione tramite le Solution Capabilities. Anche soluzioni ibride complesse, in cui vengono gestiti in parallelo più sistemi ERP, possono essere orchestrate in modo elegante. L’IA accede esclusivamente alle funzionalità definite e non deve conoscere né le strutture interne dei dati né i dettagli tecnici dei sistemi collegati.

La conoscenza diventa il vero e proprio capitale

Con SchallOS, il fulcro dello sviluppo software moderno si sposta in modo significativo. Non è più il codice di programmazione in sé a costituire il valore principale di un’applicazione, bensì la conoscenza strutturata che ne deriva. SchallOS supporta anche il nuovo Formato OKF, pubblicato da Google nel giugno 2026, al fine di poter integrare o condividere le conoscenze in modo portatile in un secondo momento.

I contenitori funzionali, il livello di conoscenza, i modelli di apprendimento, i contratti di capacità, i risultati dei benchmark e i profili ottimizzati tramite modelli diventano parte integrante della soluzione e possono essere trasferiti, sottoposti a controllo delle versioni e sviluppati continuamente insieme ad essa.

In questo modo, ogni applicazione SchallOS sviluppa nel tempo una propria competenza in materia di IA, in costante miglioramento, che rimane direttamente collegata alla soluzione.

Dalla migrazione FileMaker alla piattaforma software indipendente

SchallOS è nato dalla pluriennale collaborazione con FileMaker. Molte delle idee alla base della piattaforma si fondano sulle esperienze maturate con soluzioni personalizzate di database ed ERP, che nel corso degli anni si sono evolute di pari passo con le esigenze aziendali.

FileMaker offre particolari vantaggi in termini di rapidità di sviluppo. Il modello di dati, i layout e la logica di programma sono strettamente integrati tra loro, le modifiche sono immediatamente visibili ed è possibile realizzare le prime soluzioni funzionanti in tempi relativamente brevi.

In SchallOS si intende mantenere questa vicinanza tra sviluppatori, dati e interfaccia utente. La base tecnica, tuttavia, verrà ricostruita ex novo. SchallOS utilizza un proprio runtime, contenitori di struttura e dati propri, un livello funzionale basato sull’intelligenza artificiale e un’infrastruttura dedicata alla documentazione, alla distribuzione e agli aggiornamenti.

FileMaker rimane quindi un importante punto di partenza e una possibile fonte di soluzioni esistenti. Tuttavia, non è più necessario per il funzionamento successivo.

La migrazione è molto più di una semplice importazione del layout

Una soluzione FileMaker consolidata non è costituita solo da tabelle, campi e maschere visibili. Gran parte delle conoscenze specialistiche è racchiusa in formule, script, trigger, relazioni, elenchi di valori e numerosi casi particolari.

Una migrazione efficace deve cogliere queste interrelazioni e trasferirle in una nuova architettura. Tabelle, campi, relazioni e layout possono essere trasferiti in modo ampiamente strutturato. Le formule e le funzioni personalizzate vengono trasferite nell'ambiente formule di SchallOS oppure adattate.

Per quanto riguarda gli script FileMaker, l’attenzione si concentra innanzitutto sulla comprensione della loro funzione tecnica. Possono essere mantenuti come livello di apprendimento e di riferimento in background dei nuovi contenitori funzionali. Il codice eseguibile, tuttavia, viene riprogrammato dall’IA in modo da adattarsi all’architettura SchallOS. In questo modo non si crea alcun ambiente di esecuzione FileMaker all’interno di un nuovo sistema. La soluzione esistente si trasforma gradualmente in un’applicazione SchallOS autonoma.

Funzionamento autonomo dopo la migrazione

Una volta completata la migrazione, non saranno più necessari né FileMaker Pro né FileMaker Server né WebDirect. La nuova applicazione utilizza SchallOS Runtime, l’SSC come contenitore strutturale e l’SSD per i dati di produzione. Formule, contenitori di funzioni, multilinguismo, documentazione, registri degli eventi e aggiornamenti sono forniti dalla piattaforma SchallOS.

A seconda delle esigenze, la soluzione può essere utilizzata in locale, come applicazione per Windows o macOS, su un server proprio o come servizio SaaS su SchallOS Cloud.

In questo modo si pone fine alla dipendenza da un unico ambiente di esecuzione proprietario. Le dipendenze tecniche non scompaiono del tutto: ogni software moderno necessita infatti di sistemi operativi, database e servizi server. La struttura, la logica di business e i dati rimangono tuttavia portabili e possono essere gestiti tramite adattatori e percorsi di distribuzione documentati.

Nuove opportunità per gli sviluppatori FileMaker

Per gli sviluppatori FileMaker, SchallOS non dovrebbe rappresentare una rottura totale con il modo di lavorare precedente. Le conoscenze relative ai modelli di dati, alla progettazione del layout e ai processi aziendali continuano ad essere preziose.

Il cambiamento riguarda soprattutto l'implementazione della logica del programma. Le lunghe catene di script vengono sostituite da contenitori di funzioni descritti semanticamente. L'intelligenza artificiale programma il codice eseguibile sulla base di compiti, parametri e limiti definiti. Lo sviluppatore verifica il risultato e rimane responsabile dell'architettura e della correttezza tecnica.

Si tiene conto in misura maggiore anche della cronologia dello sviluppo. Le modifiche possono essere registrate, documentate e raggruppate automaticamente in release. La stessa pipeline di aggiornamento utilizzata per aggiornare SchallOS è disponibile anche per le soluzioni personalizzate dei clienti.

In questo modo, il lavoro si sposta in parte dall'inserimento manuale delle singole fasi del programma alla descrizione, alla verifica e alla strutturazione precise dei processi aziendali.

Non solo per le applicazioni migrate

La migrazione FileMaker rimane una componente importante di SchallOS, ma non ne costituisce l'unico scopo. Le nuove applicazioni possono essere sviluppate interamente in SchallOS Studio.

A lungo termine, potrebbero essere supportati anche altri sistemi di origine. Tuttavia, un’estensione di questo tipo richiede procedure di analisi e migrazione specifiche per ciascun caso. Le diverse piattaforme di sviluppo hanno approcci propri che non possono essere riprodotti in modo adeguato tramite un’importazione universale superficiale.

Le esperienze acquisite con la migrazione da FileMaker costituiscono una base in tal senso. Lo scopo vero e proprio di SchallOS risiede tuttavia nello sviluppo e nella gestione di applicazioni aziendali indipendenti.

Lancio previsto per l'autunno del 2026

Il lancio pubblico di SchallOS è previsto per l’autunno del 2026. Fino ad allora, le aree portanti della piattaforma continueranno a essere integrate, testate e preparate per i primi casi d’uso produttivi. Non tutte le funzionalità previste a lungo termine saranno già completamente sviluppate al momento del lancio. È fondamentale disporre di un nucleo solido su cui possano integrarsi in modo controllato ulteriori adattatori di database, funzioni di intelligenza artificiale, opzioni di migrazione e modelli operativi.

In primo luogo, viene Software ERP gFM-NEXT di gofilemaker.de sarà pubblicato, presumibilmente, nel settembre 2026 sulla nuova piattaforma SchallOS. Il lancio della piattaforma di sviluppo SchallOS, previsto poco più tardi nell’autunno del 2026, non segnerà quindi la fine dello sviluppo, bensì l’inizio dell’utilizzo pratico.

Il ciclo di vita completo di un'applicazione

SchallOS è partito dalla domanda su come le soluzioni FileMaker esistenti potessero essere trasferite in un ambiente moderno. Da ciò è nata una piattaforma che tiene conto non solo della migrazione e dello sviluppo, ma anche della documentazione, dell’implementazione, della gestione dei dati, degli aggiornamenti e della gestione a lungo termine. Studio, Runtime, Control e Cloud assumono compiti chiaramente distinti all’interno di un’architettura comune. L’obiettivo non è quindi semplicemente quello di sostituire FileMaker con un altro strumento di sviluppo. SchallOS mira a coniugare la comprovata vicinanza tra sviluppatore, dati e interfaccia utente con container portabili, programmazione basata sull’intelligenza artificiale e un modello operativo end-to-end.

Il DNA FileMaker costituisce il punto di partenza. L'obiettivo è una piattaforma indipendente sulla quale sia possibile sviluppare, gestire e mantenere nel lungo periodo applicazioni aziendali esistenti e nuove.

Articoli attuali sull'intelligenza artificiale

MLX su Apple Silicon come AI locale rispetto a Ollama & Co.

MLX su Apple Silicon come AI locale rispetto a Ollama & Co.

gFM-Business e il futuro dell'ERP: intelligenza locale anziché dipendenza dal cloud

gFM-Business e il futuro dell'ERP: intelligenza locale anziché dipendenza dal cloud

Quando ero al telefono con un robot: come l'intelligenza artificiale sta conquistando il telefono e come riconoscerla

Quando ero al telefono con un robot: come l'intelligenza artificiale sta conquistando il telefono e come riconoscerla

Dal contenuto alla sostanza: come nascono i sistemi digitali che non possono essere copiati

Dal contenuto alla sostanza: come nascono i sistemi digitali che non possono essere copiati

Domande frequenti

1. Che cos’è esattamente SchallOS e in cosa si differenzia da una classica applicazione di database?
   SchallOS è una piattaforma per lo sviluppo, l'esecuzione e la gestione di software aziendali personalizzati. Comprende non solo tabelle, layout e funzioni, ma anche programmazione basata sull'intelligenza artificiale, documentazione, registri degli eventi, distribuzione e aggiornamenti. SchallOS Studio serve allo sviluppo, Runtime esegue le applicazioni pronte all’uso, Control gestisce le installazioni e Cloud fornisce soluzioni in modalità SaaS. In questo modo, la piattaforma accompagna un’applicazione dalla sua creazione fino al funzionamento a lungo termine.
2. A quali sviluppatori e aziende è destinato SchallOS?
   SchallOS si rivolge in particolare agli sviluppatori FileMaker, alle aziende di software e agli sviluppatori di applicazioni aziendali personalizzate. Anche le aziende che dispongono già di soluzioni FileMaker hanno la possibilità di trasferire gradualmente le proprie applicazioni in un ambiente indipendente. Inoltre, è possibile sviluppare nuove soluzioni interamente all’interno di SchallOS. Per gli amministratori delegati e i responsabili tecnici è particolarmente interessante il fatto che sviluppo, gestione, documentazione, aggiornamenti e diverse modalità di distribuzione siano organizzati all’interno di un’unica piattaforma comune.
3. SchallOS è principalmente un sostituto di FileMaker?
   FileMaker rappresenta un importante punto di partenza, ma non costituisce la base tecnica definitiva di SchallOS. Vengono riprese idee collaudate come lo sviluppo visivo e lo stretto collegamento tra dati, layout e funzioni. Il runtime, la gestione dei dati, la logica funzionale e l’infrastruttura di aggiornamento vengono tuttavia sviluppati in modo autonomo. SchallOS è in grado di migrare le soluzioni FileMaker esistenti, ma è adatto anche per nuove applicazioni. Una volta completata la migrazione, FileMaker non sarà più necessario per il funzionamento in produzione.
4. È possibile migrare in modo completamente automatico la mia soluzione FileMaker attuale?
   Tabelle, campi, relazioni, layout e altre strutture definite possono essere trasferiti in modo ampiamente automatizzato. In caso di logica di business complessa, tuttavia, è necessaria un’ulteriore verifica. Gli script FileMaker contengono spesso modifiche al layout, variabili globali, plugin o casi particolari derivanti da sviluppi storici. L’intelligenza artificiale è in grado di analizzare questi processi e di creare nuovi contenitori funzionali sulla base di essi. Una soluzione di ampia portata dovrebbe comunque essere verificata da uno sviluppatore e, se necessario, perfezionata. La migrazione riduce notevolmente il lavoro manuale, ma non sostituisce la comprensione tecnica dell’applicazione.
5. Cosa succede agli script FileMaker esistenti dopo la migrazione?
   Gli script possono essere conservati nel background dei nuovi contenitori di funzioni come livello di apprendimento e di riferimento. Tuttavia, non vengono eseguiti così come sono. L'intelligenza artificiale analizza quale compito specifico svolge uno script, quali campi utilizza e quali condizioni vengono verificate. Successivamente, programma il nuovo codice eseguibile in modo adeguato all'architettura di SchallOS. Lo script originale viene conservato come fonte storica di conoscenza e può continuare a essere preso in considerazione in caso di domande o estensioni successive.
6. Cosa sono SSC e SSD, e perché una soluzione richiede due container?
   L'SSC contiene la struttura dell'applicazione, tra cui tabelle, campi, layout, formule, contenitori di funzioni, lingue e documentazione. L'SSD contiene i dati operativi quali clienti, articoli, ordini o fatture. Entrambi i contenitori sono correlati, ma hanno funzioni diverse. Questa separazione consente di creare nuove versioni della struttura senza dover sostituire l’intero set di dati. Inoltre, è possibile modificare la gestione dei dati, i backup e i modelli operativi senza dover riprogettare completamente l’applicazione.
7. Quali vantaggi offre la separazione tra struttura e dati?
   In questo modo è possibile eseguire aggiornamenti, backup e migrazioni in modo molto più controllato. È possibile pubblicare un nuovo SSC, mentre l’SSD contenente i dati dei clienti rimane inalterato. Le modifiche strutturali necessarie vengono eseguite tramite migrazioni dei dati predefinite. L’SSC può inoltre essere analizzato o trasferito a un altro sviluppatore senza dati aziendali riservati. Anche il passaggio da IndexedDB a SQLite, PostgreSQL o al cloud risulta semplificato, poiché non è necessario ricostruire i layout e la logica funzionale.
8. È possibile utilizzare la stessa soluzione in locale, su un server e nel cloud?
   In linea di massima sì. Una soluzione SchallOS può essere eseguita localmente nel browser, come applicazione Windows o macOS, con SQLite, su un server PostgreSQL o come SaaS nel SchallOS Cloud. L’applicazione funzionale rimane la stessa. Le diverse modalità operative presentano tuttavia requisiti specifici in termini di funzionamento multiutente, backup, prestazioni e amministrazione. Il passaggio avviene quindi in modo controllato tramite trasferimento dei dati e verifica. L’architettura SSC/SSD evita di dover gestire un progetto completamente nuovo per ogni destinazione.
9. Dopo una migrazione riuscita, avrò ancora bisogno di FileMaker o di un server FileMaker?
   No. Una volta completata la migrazione, l’applicazione verrà eseguita tramite SchallOS Runtime. Anche per l’esecuzione tramite browser non sono necessari né il server FileMaker né WebDirect. Il precedente sistema FileMaker può essere mantenuto come riferimento o archivio, ma non costituisce un prerequisito per l’operatività produttiva. Layout, formule, funzioni, accesso ai dati, aggiornamenti e distribuzione vengono gestiti da SchallOS. In questo modo vengono meno anche le precedenti dipendenze di runtime di FileMaker per l’applicazione migrata.
10. In che modo l'intelligenza artificiale è integrata in SchallOS?
    L'IA è immediatamente disponibile nell'editor di formule, nelle funzioni personalizzate, nei contenitori di funzioni e nel livello di documentazione. Non solo conosce la domanda attuale, ma anche i campi, le tabelle, le descrizioni e le dipendenze interessati. Nel caso di soluzioni migrate, lo script FileMaker originale può inoltre fungere da base di riferimento. L’IA è in grado di spiegare le formule, generare codice, analizzare gli errori e redigere la documentazione. I modelli devono rimanere fondamentalmente intercambiabili, in modo da poter tenere conto di qualità, costi e protezione dei dati.
11. L'IA programma davvero il codice dei contenitori di funzioni?
    Sì. Lo sviluppatore descrive il compito, i parametri, il risultato atteso e le funzionalità consentite. Su questa base, l’IA genera il codice eseguibile. Questo rimane visibile, verificabile e gestibile in termini di versioni. Lo sviluppatore può richiedere modifiche, eseguire test e confrontare o ripristinare versioni precedenti. L’IA si fa così carico di gran parte del lavoro di programmazione, ma non della responsabilità tecnica. Soprattutto nei processi critici per l’azienda, i requisiti, i diritti e i possibili effetti collaterali devono continuare a essere controllati con attenzione.
12. Quali possibilità offre l'editor di formule?
    L'editor di formule supporta i tipici calcoli matematici, logici, relativi al testo, nonché quelli relativi a data e ora. Le formule e le funzioni personalizzate vengono valutate in tempo reale e possono essere testate immediatamente. Il numero iniziale di comandi è inferiore al set di funzioni di FileMaker, che si è ampliato nel corso degli anni. L’ambiente delle formule è tuttavia espandibile. Le funzioni mancanti possono essere integrate o sostituite con funzioni personalizzate. Anche in questo caso, l’intelligenza artificiale integrata può trasferire le formule FileMaker esistenti o sviluppare nuovi calcoli.
13. Cosa documenta automaticamente SchallOS?
    A livello strutturale vengono registrate le modifiche apportate a tabelle, campi, layout, formule e contenitori di funzioni. A livello di dati è possibile registrare modifiche ai record, cambiamenti di stato, approvazioni, importazioni e altri eventi funzionali. A ciò si aggiungono eventi operativi quali implementazioni, aggiornamenti e backup. Le attività di sviluppo correlate possono essere raggruppate in «sessioni di modifica» e successivamente assegnate a una release. In questo modo si crea una cronologia tracciabile dell’applicazione, anziché una semplice raccolta di note redatte a posteriori.
14. SchallOS può generare rapporti sui clienti e sulle prestazioni sulla base di questi dati?
    Sì. L’IA integrata è in grado di generare, a partire dagli eventi registrati, documentazione tecnica, rapporti per i clienti, note di rilascio o attestati di prestazione. È possibile riassumere diverse modifiche tecniche in una descrizione chiara dei vantaggi aziendali. Gli eventi sottostanti rimangono comunque consultabili, in modo che lo sviluppatore possa verificare le formulazioni. Non tutte le modifiche sono automaticamente fatturabili. La selezione, la valutazione e l’approvazione del verbale definitivo delle prestazioni rimangono quindi di competenza dello sviluppatore.
15. Come funziona la pipeline di aggiornamento?
    Le modifiche vengono inizialmente raccolte nelle "Change Sessions" e raggruppate in una release. Una release può contenere un nuovo SSC, le migrazioni SSD necessarie, i prerequisiti, le firme, i controlli e le informazioni relative al rollback. SchallOS Control verifica l’istanza di destinazione, crea un backup e quindi esegue l’aggiornamento. Dopo l’installazione, viene verificato che la struttura, i dati e le funzioni principali corrispondano allo stato previsto. La stessa pipeline di base viene utilizzata sia per SchallOS stesso che per le soluzioni dei clienti sviluppate con esso.
16. In cosa si differenziano Runtime, Control e Cloud?
    SchallOS Runtime esegue le applicazioni pubblicate e mette a disposizione layout, formule e contenitori di funzioni. SchallOS Control gestisce le istanze, gli adattatori di database, i profili di runtime, gli aggiornamenti e i controlli tecnici. SchallOS Cloud offre il runtime e la gestione dei dati come servizio SaaS gestito centralmente. SchallOS Studio rimane l’ambiente di sviluppo vero e proprio. Tutti i moduli utilizzano le stesse strutture di base SSC e SSD, ma svolgono compiti chiaramente distinti all’interno del ciclo di vita di un’applicazione.
17. In che modo vengono protetti i diritti, le installazioni e i dati sensibili?
    I diritti utente determinano quali azioni specifiche una persona è autorizzata a eseguire all’interno della soluzione. I profili di runtime e di capacità definiscono inoltre quali funzioni tecniche sono effettivamente disponibili in un’installazione. I pacchetti SSC e SSD possono essere protetti con identificativi, checksum e firme. È possibile limitare anche il contesto dell’IA, in modo che non vengano elaborati automaticamente tutti i dati dei clienti. Per ambienti particolarmente sensibili è possibile utilizzare server dedicati o, in futuro, anche modelli di IA locali. La configurazione di sicurezza concreta dipende dal caso d’uso specifico.
18. Quando sarà disponibile SchallOS?
    Il lancio pubblico è previsto per l'autunno del 2026. L'attenzione si concentrerà inizialmente su Studio e Runtime, sulla separazione tra SSC e SSD, sulla migrazione delle strutture FileMaker esistenti, sulle formule, sulle funzioni personalizzate, sui contenitori di funzioni programmati tramite IA, sulla documentazione, sui registri degli eventi, sul deployment e sugli aggiornamenti. Anche SchallOS Control assumerà un ruolo centrale nella gestione delle installazioni. Non tutte le funzionalità pianificate a lungo termine devono essere già completamente sviluppate al momento del lancio. In una prima fase è fondamentale disporre di un nucleo solido per le prime applicazioni produttive.

Articoli attuali su arte e cultura

Cancellare la cultura in Occidente: sport, università, esercito e sanzioni UE

Cancellare la cultura in Occidente: sport, università, esercito e sanzioni UE

Dieter Bohlen in parole povere: perché la Germania sta fallendo a causa della sua stessa burocrazia

Dieter Bohlen in parole povere: perché la Germania sta fallendo a causa della sua stessa burocrazia

Apple in transizione: primi dispositivi, esperienze personali e una mostra all'OCM

Apple in transizione: primi dispositivi, esperienze personali e una mostra all'OCM

La suite grafica Affinity diventa gratuita: Cosa devono sapere gli utenti professionali

La suite grafica Affinity diventa gratuita: Cosa devono sapere gli utenti professionali