Při vývoji podnikové aplikace se pozornost nejprve soustředí na viditelné úkoly. Vytvářejí se tabulky, definují se vztahy, navrhují se vstupní formuláře a automatizují se provozní procesy. Jakmile mohou první uživatelé s řešením pracovat, zdá se, že velká část projektu je dokončena. V praxi však teprve tehdy začíná fáze, která je z dlouhodobého hlediska náročnější. Aplikace používaná v podniku musí být udržována, rozšiřována a přizpůsobována novým požadavkům. Změny je třeba dokumentovat, nové verze distribuovat a stávající data bezpečně převést. K tomu přibývají různá uživatelská oprávnění, zálohování dat, analýzy chyb a otázka, zda má být řešení provozováno lokálně, na vlastním serveru nebo v cloudu.
Mnoho vývojových platforem se soustředí především na tvorbu samotné aplikace. Pro aktualizace, dokumentaci, nasazení a provoz se později doplňují další nástroje a individuální postupy. Postupem času tak vzniká technické prostředí složené z mnoha vzájemně oddělených částí, které lze udržet pohromadě pouze s velkým úsilím. SchallOS proto uplatňuje komplexnější přístup. Platforma má doprovázet podnikovou aplikaci nejen při jejím vzniku, ale po celou dobu jejího životního cyklu: od vývoje přes dokumentaci a nasazení až po aktualizace a trvalý provoz.
Aktuální novinky o SchallOS Studio
12.08.2026: Vývoj systému SchallOS pokračuje. Mezitím byla Úroveň umělé inteligence a znalostí Platforma je již z velké části dokončena a hluboce integrována do vývojového prostředí. SchallOS tak disponuje samoučící se znalostní vrstvou, která shromažďuje zkušenosti z praktického vývoje a dokáže se postupem času přizpůsobit programovacímu stylu a preferovaným způsobům řešení daného vývojáře.
Díky otevřenému systému adaptérů lze připojit libovolné lokální a cloudové modely umělé inteligence propojit. Pro jednoho poskytovatele nebo model lze uložit i více přístupů, resp. API klíčů. Lze používat více modelů souběžně a využívat je pro různé úkoly na základě jejich schopností, rychlosti a dosavadních výsledků. Výběr modelu probíhá automaticky prostřednictvím integrovaného nástroje Composer – vývojář se tak během vývoje nemusí zabývat tím, který model je pro daný úkol vhodný. Již známá a osvědčená řešení lze znovu použít ze znalostní vrstvy, takže není nutné, aby každý úkol byl znovu kompletně zpracován modelem umělé inteligence.
Přímo ve studiu SchallOS specializovaní agenti umělé inteligence pro různé vývojové úkoly. Mezi ně patří například Agent pro vzorce pro výpočty a vzorce, jeden Agent funkčních kontejnerů pro programování funkčních kontejnerů a také Agent pro rozvržení pro práci s uživatelskými rozhraními. Funkční kontejnery lze navíc upravovat přímo prostřednictvím jejich objektů rozvržení a programovat pomocí umělé inteligence. Nadřazený Systémový agent může koordinovat práci specializovaných agentů, například když je třeba vyvinout zcela nové moduly nebo rozsáhlejší funkce.
Tuto vrstvu umělé inteligence doplňuje Adapter Studio v SchallOS Control. Díky tomu mohou vývojáři vytvářet vlastní síťové a datové adaptéry, například pro připojení externích ERP systémů, databází nebo podnikových platforem, jako jsou SAP a Oracle. Potřebné znalosti, profily modelů a zkušenosti specifické pro dané řešení jsou spravovány v rámci znalostní architektury a jsou verzovány. SchallOS se tak postupně mění z klasického vývojového prostředí na platformu, na které vývojáři, znalostní vrstva a různé modely umělé inteligence společně pracují na softwarovém řešení.
Znalostní vrstva také pro uživatele a firemní znalosti
Oblast znalostí se však neomezuje pouze na vývoj softwaru. Také v oblasti Úroveň řešení Aplikace mohou mít vlastní agenty umělé inteligence, kteří uživateli pomáhají při každodenních pracovních postupech – například při vystavování faktur, vyhodnocování dat nebo při jiných opakujících se úkolech v rámci softwarového řešení. Řešení si dabei může budovat vlastní znalosti a zpřístupňovat je svým agentům.
Tato oblast má být v budoucnu ještě výrazně rozšířena. Předpokládá se mimo jiné přebírání znalostí z různých externích zdrojů, například z e-mailových systémů, dokumentů a podnikových dat, jakož i prostřednictvím standardizovaných formátů pro výměnu dat, jako je Open Knowledge Format (OKF) od Googlu, a znalostních grafů, jako je například Neo4j. Tímto způsobem by se znalostní základna řešení SchallOS měla v dlouhodobém horizontu skládat nejen z jeho vlastní databáze, ale také z různých informačních zdrojů dané společnosti.
Od migrace na platformu FileMaker k vlastní platformě
Původním výchozím bodem projektu SchallOS byla migrace stávajících řešení FileMaker. FileMaker se po desetiletí osvědčilo jako výkonné prostředí pro individuální databázové aplikace. Zejména úzká provázanost datového modelu, rozvržení a programové logiky umožňuje rychlý a prakticky orientovaný vývoj.
Plně rozvinuté řešení FileMaker však zahrnuje mnohem více než jen tabulky a viditelné masky. Obsahuje výpočty, skripty, uživatelská oprávnění, tisková rozvržení, rozhraní a četné speciální provozní případy. Vhodná nástupnická platforma musí tyto souvislosti převzít a následně je schopna je samostatně dále rozvíjet.
Z tohoto úkolu se SchallOS postupně vyvinulo v samostatnou platformu. Stávající řešení FileMaker by měla být migrovatelná, zároveň je možné v SchallOS přímo vyvíjet nové aplikace. Po dokončení migrace již nebude FileMaker pro produkční provoz potřebné.
Vývoj, provozní doba a provoz zůstávají oddělené
Vývojová platforma SchallOS se skládá z několika oblastí s jasně vymezenými úkoly.
- SchallOS Studio je vývojové prostředí. Právě zde vznikají datové struktury, rozvržení, vzorce, funkce, jazyky a verze. Součástí Studia je také průvodce migrací pro stávající řešení FileMaker.
- SchallOS Runtime spouští zveřejněné aplikace. Poskytuje uživatelské rozhraní a potřebnou programovou logiku, aniž by automaticky zpřístupňovala všechny vývojové nástroje.
- SchallOS Control spravuje cíle nasazení, připojení k databázím, profily běhu, aktualizace a technické kontroly.
- SchallOS Cloud poskytuje aplikace jako centrálně spravovanou online službu. Cílem přitom není vytvořit samostatný cloudový formát. Lokální, serverové i cloudové instalace využívají stejnou základní architekturu řešení.
Toto oddělení zabraňuje nekontrolovanému prolínání vývoje, provozu a správy. Zároveň zůstávají všechny oblasti technicky vzájemně sladěny.
Řešení pro různé provozní modely
Obchodní aplikace může začínat v malém měřítku a později se rozšiřovat. Zpočátku může stačit lokální stanice pro jednoho uživatele. Později přibudou další zaměstnanci, centrální server nebo více poboček. SchallOS by proto měl být schopen poskytovat stejné základní řešení pro různé provozní režimy: lokálně v prohlížeči, jako aplikace pro Windows nebo macOS, s SQLite nebo PostgreSQL, stejně jako jako řešení SaaS v cloudu.
Ne každý typ provozu má stejné technické vlastnosti. Lokální databáze klade jiné požadavky než centrální provoz s více uživateli. Rozhodující však je, že rozvržení, funkce a datový model není nutné pro každý cíl vyvíjet zcela od začátku.
Životní cyklus je součástí architektury
Dokumentace, protokoly událostí a aktualizace nejsou v systému SchallOS pouze dodatečně připojovány k hotové aplikaci. Jsou součástí základní architektury. Struktura a produkční data jsou spravovány odděleně. Změny ve vývoji lze protokolovat a sdružovat do jednotlivých verzí. Aktualizace lze testovat, distribuovat a v případě problémů kontrolovaně vrátit zpět. Integrovaná umělá inteligence pomáhá nejen při práci s vzorci a funkcemi, ale také při tvorbě dokumentace a komunikaci se zákazníky.
SchallOS tak propojuje oblasti, které se v klasických projektech často řeší odděleně. Vývoj aplikace již není koncem technického procesu, ale první fází dlouhodobě plánovaného životního cyklu.
SSC a SSD jako přenosné kontejnery struktur a dat
Mnoho databázových aplikací ukládá strukturu, uživatelské rozhraní, programovou logiku a produkční data do úzce propojeného celku. To je zpočátku pohodlné, ale ztěžuje pozdější aktualizace, migrace a různé provozní režimy. Jakmile přibude více zákazníků, větší datové soubory nebo individuální rozšíření, stává se výměna kompletního souboru aplikace rychle problematickou.
SchallOS proto zásadně odděluje popis řešení od jeho obchodních dat. Aplikace se v zásadě skládá ze dvou souvisejících kontejnerů: SSC pro strukturu a SSD pro produkční data.
Oba kontejnery společně tvoří ucelené řešení, plní však různé úkoly. SSC popisuje, jak je aplikace sestavena a jak funguje. SSD obsahuje obsah, který vzniká během jejího používání.
SSC popisuje použití
Soubor SSC je přenosný strukturální kontejner řešení SchallOS. Obsahuje mimo jiné:
- Definice tabulek a polí
- Vztahy
- Rozvržení a objekty rozvržení
- Vzorce a vlastní funkce
- Funkční kontejner
- Spouštěče a navigace
- Informace o jazycích a překladech
- Dokumentace
- Údaje o verzích a vydáních
SSC tedy neobsahuje samotné zákazníky, položky, objednávky ani faktury. Stanovuje, jaké datové struktury existují, jak jsou zobrazeny a jaké funkce s nimi pracují. Do tohoto kontejneru patří také sémantický význam řešení. Pole může kromě svého technického názvu obsahovat také odborný popis, překlady, validační pravidla a pokyny pro vrstvu umělé inteligence. Díky tomu je struktura nejen strojově čitelná, ale také srozumitelnější pro vývojáře, dokumentaci a migraci.
SSC tak představuje přenosný aplikační model, který lze dále rozvíjet a zveřejňovat nezávisle na konkrétním datovém souboru.
SSD obsahuje produkční data
Soubor SSD je datový kontejner tohoto řešení. Obsahuje datové záznamy, které vznikají v rámci každodenního provozu, například zákazníky, nabídky, zakázky, faktury, skladové pohyby nebo termíny. Kromě toho lze v něm ukládat i odborné historie a datové události. Mezi ně patří například změny stavu, schválení, importy nebo změny v obzvláště důležitých polích. Označení SSD zde neznamená fyzický datový nosič, ale logickou datovou vrstvu aplikace. Způsob technického uložení těchto dat závisí na zvoleném nasazení a databázovém adaptéru.
Pro lokální jednouživatelské prostředí lze použít IndexedDB. Desktopová aplikace může pracovat s SQLite, zatímco větší víceuživatelské aplikace využívají PostgreSQL. SSD zůstává ve všech případech odborným datovým kontejnerem, i když se technické úložiště liší.
Dva kontejnery musí jednoznačně patřit k sobě
Oddělení struktury a dat nesmí vést k tomu, že by se libovolné kontejnery kombinovaly mezi sebou. Systém SchallOS musí být schopen ověřit, zda SSC a SSD skutečně patří ke stejnému řešení a zda se jejich verze navzájem shodují. K tomu lze použít identifikátory řešení, identifikátory kontejnerů, verze struktur, kontrolní součty a podpisy. Před spuštěním nebo aktualizací lze tak zjistit, zda je daná kombinace platná a zda již byly provedeny nezbytné migrace dat.
Tato kontrola například zabraňuje tomu, aby byl omylem otevřen strukturální kontejner jiné aplikace s produkčními daty. Chrání také před aktivací nové verze SSC v případě, že SSD ještě nebyl připraven na příslušnou datovou strukturu.
Přenositelnost mezi různými formami provozu
Oddělení SSC a SSD vytváří základ pro provozování aplikace v různých prostředích. Rozvržení, vzorce a logiku funkcí není nutné vyvíjet znovu pro každý databázový adaptér.
Řešení lze nejprve zavést lokálně s využitím IndexedDB, později přejít na SQLite a s rostoucím počtem uživatelů přejít na PostgreSQL. Stejně tak je možný přechod do cloudového prostředí.
Taková změna zůstává řízeným technickým procesem. Různé databáze mají své vlastní možnosti a omezení. Proto se data nepřevádějí do jiného systému pouhým stisknutím tlačítka. Přenos, kontrola a případně vrácení zpět musí být provedeny výslovně.
Architektura však zajišťuje, že změna způsobu ukládání dat nevyžaduje automaticky vytvoření zcela nové aplikace.
Aktualizace bez výměny údajů o zákaznících
Zásadní výhoda tohoto oddělení se projevuje u nových verzí. Změny se často týkají rozvržení, vzorců, funkcí nebo datového modelu. Stávající obchodní data by přitom měla zůstat zachována.
Vývojář proto může vydat novou verzi SSC, zatímco SSD zákazníka zůstává na místě nasazení. Jsou-li zapotřebí nová pole nebo tabulky, doplní se prostřednictvím definovaných migračních kroků. Před aktualizací lze zálohovat stávající stav. Následně se zkontroluje struktura, migrace dat a funkčnost. Teprve když SSC a SSD opět tvoří konzistentní stav, považuje se aktualizace za dokončenou.
Tato možnost aktualizace není určena pouze pro samotný systém SchallOS. Je k dispozici také pro zákaznická řešení vyvinutá na platformě SchallOS.
Varianty přizpůsobené požadavkům zákazníků zůstávají přehledné
Individuální podnikový software se u různých zákazníků často vyvíjí odlišným způsobem. Jeden zákazník potřebuje vlastní pole, jiný zase další rozvržení nebo speciální rozhraní. Bez jasné struktury tak rychle vznikají navzájem odlišné kompletní kopie, které se pak jen těžko spravují společně. V SSC lze naopak obecné součásti produktu a rozšíření specifická pro jednotlivé zákazníky přehledně verzovat a dokumentovat.
Architektura sice vývojáři nebere možnost rozhodnout, která úprava patří do celkového produktu, zajišťuje však, aby původ a závislosti dané změny zůstaly viditelné.
Spolu s vývojovými protokoly a verzemi je při pozdějších aktualizacích snazší rozpoznat, které součásti je třeba nahradit, doplnit nebo zachovat.
Vícejazyčnost je součástí přenositelné struktury
V systému SSC je zakotvena i jazyková vrstva. Názvy nejsou uloženy výhradně jako pevné hodnoty v jednotlivých objektech rozvržení, ale mohou odkazovat na sémantické záznamy s více jazykovými verzemi.
Díky tomu lze pole jako „Číslo faktury“ zobrazit v různých jazycích, aniž by bylo nutné pro každý jazyk vytvářet zcela nové rozvržení. Migrované řešení FileMaker lze během migrace automaticky převést do vícejazyčné podoby a přeložit.
Automatický překlad nenahrazuje odbornou kontrolu. Zejména právní a oborově specifické pojmy je třeba zkontrolovat. Architektura systému však zajišťuje, že vícejazyčnost je součástí řešení již od samého počátku a není nutné ji později pracně začleňovat do jednotlivých masek.
Základ pro dlouhodobou udržovatelnost
SSC a SSD se na první pohled jeví jako jednoduché rozdělení na aplikaci a data. Ve skutečnosti však tvoří základ pro přenositelnost, aktualizace, různé databázové adaptéry, oddělené zálohy a různé provozní modely.
SSC popisuje, co je to řešení a jak funguje. SSD obsahuje to, co vzniká během jeho používání a co musí být pro danou společnost trvale uchováno.
Díky tomuto jasnému oddělení se aplikace může dále vyvíjet, aniž by bylo nutné při každé nové verzi vyměnit celý datový fond. Zároveň se může technická správa dat rozšiřovat nebo měnit, aniž by bylo nutné zcela přepracovávat rozvržení a obchodní logiku.
SchallOS Studio jako integrované vývojové prostředí
SchallOS Studio je část platformy, ve které vznikají nové obchodní aplikace a kde se migrují nebo dále vyvíjejí stávající řešení FileMaker. Zde se v rámci společného prostředí spravují tabulky, pole, vztahy, rozvržení, vzorce, funkce, jazyky a verze.
Pro vývojáře FileMaker by měl být základní způsob práce intuitivní. Změny se neprovádějí výhradně v abstraktních souborech zdrojového kódu, ale zůstávají propojeny s viditelnými částmi aplikace. Vývojář může upravit rozvržení, vybrat pole, změnit jeho vlastnosti a okamžitě zkontrolovat, jak se tato úprava projeví v aplikaci.
SchallOS se nicméně nesnaží o úplnou replikaci systému FileMaker. Převzaty jsou především osvědčené základní myšlenky: rychlý vývoj, okamžitá zpětná vazba a úzké propojení mezi datovým modelem, uživatelským rozhraním a obchodní logikou. Technický základ je naopak nově uspořádán a zaměřen na přenositelné struktury, programování podporované umělou inteligencí, dokumentaci a kontrolované vydávání.
Rozvržení, objekty a vlastnosti
Nezbytnou součástí programu SchallOS Studio je režim rozvržení. Právě v něm vznikají vstupní masky, seznamy, dialogová okna, navigační oblasti a další prvky uživatelského rozhraní daného řešení.
Mezi možné objekty rozvržení patří mimo jiné pole, texty, tlačítka, seznamy, záložky, vyskakovací okna, kontejnery a navigační prvky. Objekty lze vybrat, umístit a nakonfigurovat pomocí inspektoru.
Objekt rozvržení přitom neobsahuje pouze údaje o velikosti, poloze a zobrazení. Může být navíc propojen s datovými zdroji, spouštěči, vzorci, funkcemi a sémantickými označeními. Objekt pole například odkazuje na pole v datovém modelu, může mít popisek závislý na jazyku a při vstupu do něj nebo opuštění může spustit určité funkce.
Jelikož je každý objekt součástí SSC, lze změny rozvržení verzovat, dokumentovat a později cíleně distribuovat prostřednictvím aktualizace. Uživatelské rozhraní tak nezůstává izolovanou grafickou vrstvou, ale je strukturovanou součástí celé aplikace.
Datový model a sémantické popisy
Tabulky, pole a vztahy se rovněž vytvářejí a upravují v SchallOS Studio. Nové aplikace lze v tomto prostředí kompletně sestavit. Při migraci z FileMaker migrační asistent v maximální možné míře převezme stávající struktury a následně je připraví k další úpravě.
Pole v systému SchallOS se neskládá pouze z technického názvu a datového typu. Může navíc obsahovat odborný popis, validační pravidla, výchozí hodnoty, překlady a poznámky k dokumentaci.
Tyto informace slouží k několika účelům. Usnadňují ostatním vývojářům pochopení řešení, podporují automatickou dokumentaci a poskytují integrované umělé inteligenci lepší kontext. Místo toho, aby platforma pouze rozpoznala, že pole se jmenuje „Status“, může například vědět, zda se jedná o stav objednávky, stav platby nebo interní stav zpracování.
Lze také popsat vztahy mezi tabulkami a zdokumentovat je v jejich oborovém kontextu. Díky tomu zůstává méně znalostí skryto výhradně v hlavě původního vývojáře.
Vzorce s výpočtem v reálném čase
SchallOS disponuje vlastním prostředím pro vzorce. Vzorce se vytvářejí v editoru vzorců a během úpravy se vypočítávají v reálném čase. Změny ve vzorci lze tak okamžitě ověřit pomocí vhodných testovacích hodnot nebo aktuálního souboru dat.
Jazyk vzorců podporuje typické výpočty, které jsou potřebné v podnikových aplikacích. Patří mezi ně matematické operace, práce s textem, výpočty data a času, logické podmínky, odkazy na pole, proměnné a vnořené výrazy.
Dostupný rozsah příkazů je zpočátku menší než soubor funkcí systému FileMaker, který se rozvíjel po celá desetiletí. Systém SchallOS nemusí bez změn kopírovat každý historický příkaz systému FileMaker. Důležitější je jasně strukturované a rozšiřitelné prostředí pro vzorce.
Další příkazy lze doplnit později, pokud budou potřebné pro konkrétní řešení nebo migrace. Integrovaná umělá inteligence může v tomto případě pomoci převést stávající výpočet nebo vyvinout chybějící funkci tak, aby odpovídala architektuře SchallOS.
Vlastní funkce pro opakovaně použitelné výpočty
Kromě integrovaných příkazů podporuje SchallOS také vlastní funkce. Ty přijímají parametry, provádějí definovaný výpočet a vracejí výsledek. Díky tomu lze opakující se pravidla spravovat na jednom centrálním místě. Příkladem jsou výpočty cen, stanovení termínů, formátování, kontrola číselných řad nebo úprava importovaných hodnot.
Vlastní funkce se rovněž vypočítávají v reálném čase a lze je okamžitě otestovat v editoru vzorců. Pokud je funkce později opravena nebo rozšířena, projeví se to ve všech vzorcích, které ji používají.
Kromě toho lze popsat a zdokumentovat vlastní funkce. Parametry, návratová hodnota, příklady a známé případy chyb tak zůstávají přehledné. Soubor funkcí daného řešení se tak stává knihovnou, kterou lze znovu použít, namísto toho, aby se skládal z mnoha zkopírovaných jednotlivých výpočtů.
Funkční kontejnery pro složitější procesy
Rozsáhlejší obchodní procesy jsou v SchallOS organizovány pomocí funkčních kontejnerů. Můžete například vytvářet datové záznamy, kontrolovat hodnoty, řídit dialogová okna, generovat dokumenty nebo komunikovat s externími rozhraními. Funkční kontejner neobsahuje pouze spustitelný kód. Součástí je také odborný popis, vstupní parametry, návratové hodnoty, závislosti, povolené funkce a výslovně vyloučené operace.
Stejný funkční kontejner může využívat více objektů rozvržení. Díky tomu není nutné funkci pro vytvoření faktury vytvářet znovu pro každé tlačítko nebo každé rozvržení.
U migrovaných řešení mohou stávající skripty FileMaker zůstat zachovány na pozadí jako výuková a referenční vrstva. Pomáhají pochopit původní záměr a dosavadní průběh. Nový spustitelný kód se však generuje tak, aby odpovídal architektuře SchallOS.
Migrace a nový vývoj ve stejném prostředí
SchallOS Studio není určeno výhradně pro stávající řešení FileMaker. Nové aplikace lze vytvářet zcela v rámci této platformy.
Při migraci asistent nejprve převezme stávající tabulky, pole, vztahy, rozvržení a další rozpoznatelné prvky. Následně mohou vývojáři importovanou strukturu zkontrolovat, vyčistit a postupně převést do nové funkční architektury.
Cílem není vytvořit nezměněnou kopii všech dřívějších specifik. Historicky vzniklé okliky lze prověřit a nahradit jasnějšími strukturami. Zároveň se zachovají odborné znalosti stávajícího řešení.
Nové i migrované aplikace pak využívají stejné nástroje, kontejnery a způsoby publikace.
Změny se stávají kontrolovanými verzemi
Změna ve studiu se automaticky nestane produktivní aktualizací. Během vývoje se mohou vyskytovat nedokončené rozvržení, předběžné vzorce nebo dosud neotestované funkce.
Související změny lze proto zaznamenat v rámci změnových relací a později je přiřadit k určité verzi. Teprve po kontrole a schválení z nich vznikne zveřejněná verze SSC.
Kromě nové struktury může vydání obsahovat také nezbytné migrace dat, informace o verzích, závislosti, kontrolní kroky a dokumentaci. Tímto způsobem zůstává samotný vývoj jasně oddělen od nasazení do produkčních instancí běhového prostředí.
SchallOS Studio tak není pouze místem, kde se aplikace navrhuje a programuje. Propojuje vizuální vývoj, datový model, vzorce, funkce, dokumentaci a publikaci v jednom společném prostředí.
Zachovává se důvěrná blízkost mezi vývojářem a viditelnou aplikací. Zároveň vzniká technický základ, na kterém lze řešení dále rozvíjet tak, aby byla přenositelná, srozumitelná a dlouhodobě udržovatelná.
Umělá inteligence tam, kde vznikají vzorce a funkce
Umělá inteligence je dosud v mnoha vývojových prostředích nabízena především prostřednictvím samostatného okna chatu. Vývojář popíše problém, zkopíruje zdrojový kód nebo vzorce do chatu a výsledek poté znovu přenese do projektu. Jazykovému modelu přitom často chybí důležité informace o tabulkách, polích, vztazích a odborném významu aplikace.
SchallOS proto integruje umělou inteligenci přímo do vývojových nástrojů. Je k dispozici tam, kde se upravují vzorce, vlastní funkce a kontejnery funkcí. Díky tomu nedostává pouze jednotlivou otázku, ale také aktuální kontext řešení.
V editoru vzorců zná umělá inteligence například upravovaný výraz, dostupná pole a očekávaný typ výsledku. V rámci kontejneru funkcí má navíc přístup k jeho popisu, parametrům, schopnostem a závislostem.
Umělá inteligence se tak nestane samostatným pomocným programem, ale součástí samotného vývojového prostředí.
Podpora v editoru vzorců
Vzorce řídí řadu procesů v podnikové aplikaci. Vypočítávají ceny, kontrolují podmínky, určují lhůty nebo ovlivňují zobrazení objektů rozvržení. Integrovaná umělá inteligence dokáže v editoru vzorců mimo jiné:
- vysvětlit stávající vzorec
- prošetřit možné chyby
- Doplnit podmínky
- zjednodušit výraz
- přenést vzorec FileMaker
- nebo na základě technického popisu vytvořit nový výpočet.
Vývojář by například mohl stanovit, že zakázky nad určitou čistou hodnotou vyžadují dodatečné schválení, pokud neexistuje rámcová smlouva. Umělá inteligence z toho může vygenerovat vzorec a přitom využít pole dostupná v řešení. Výsledek zůstává viditelný jako běžný vzorec. Lze jej číst, upravovat a počítat v reálném čase. Umělá inteligence tak nevytváří žádný skrytý proces, jehož chování by bylo obtížně sledovatelné.
Pokud chybí potřebný příkaz, může AI pomoci i s vytvořením vhodné vlastní funkce nebo rozšíření prostředí pro vzorce. Díky tomu lze původně omezený rozsah příkazů SchallOS dále rozšiřovat.
Vlastní funkce podle odborných zadání
Opakující se výpočty lze centrálně spravovat jako vlastní funkce. Umělá inteligence dokáže na základě popisu vytvořit funkci s jednoznačnými parametry, návratovou hodnotou a zdokumentovaným chováním.
Taková funkce by mohla například vypočítávat lhůty pro slevy, kontrolovat číselné řady nebo sjednotit importované hodnoty. Kromě samotného výpisu lze také vytvořit testovací hodnoty, příklady a možné případy chyb.
To usnadňuje nejen počáteční programování. Při pozdější změně dokáže umělá inteligence rozpoznat, jaký význam má daná funkce a v jakých místech se používá.
Anonymní výpočet se tak stává zdokumentovanou a opakovaně použitelnou součástí řešení.
Funkční kontejner jako popsaná programová logika
Složitější procesy jsou v systému SchallOS organizovány pomocí funkčních kontejnerů. Funkční kontejner může například vytvářet datové záznamy, kontrolovat zadávané údaje, řídit dialogová okna, generovat dokumenty nebo volat externí rozhraní. Základem je strukturovaný popis. Ten může stanovit:
- jakou úlohu tato funkce plní
- jaké parametry se předávají
- jaký výsledek se očekává
- k kterým tabulkám a polím je povolen přístup
- jaké další funkce se používají
- a které úkony jsou výslovně vyloučeny.
Na základě těchto zadání umělá inteligence naprogramuje spustitelný kód funkčního kontejneru. Vývojář tak již nemusí sestavovat postup výhradně z mnoha jednotlivých kroků skriptu. Jeho úkol se více přesouvá k přesnému popisu požadované funkce, jejích omezení a následné kontrole.
Vygenerovaný kód však zůstává viditelný. Lze jej číst, testovat, upravovat a porovnávat mezi různými verzemi. I starší verze lze uchovat a v případě potřeby obnovit. Umělá inteligence tak přebírá programování, nikoli však odbornou odpovědnost.
Skripty FileMaker jako výuková vrstva
U migrovaných řešení FileMaker obsahují stávající skripty často velkou část obchodní logiky, která vznikala v průběhu let. Ukazují, která pole byla změněna, které podmínky byly zkontrolovány a které další procesy byly vyvolány.
Tyto skripty nejsou v systému SchallOS trvale převzaty jako spustitelná vrstva běhu. Tím by se totiž mnoho dřívějších technických závislostí a oklikech pouze přesunulo do nového systému. Místo toho může původní skript FileMaker zůstat zachován na pozadí příslušného funkčního kontejneru. Slouží umělé inteligenci jako vrstva pro učení, referenci a porozumění.
Umělá inteligence z toho dokáže odvodit funkční záměr dosavadního postupu. Následně naprogramuje nový kód tak, aby odpovídal architektuře SchallOS. Historické konstrukce, jako jsou časté změny rozvržení, globální pole nebo kontextově závislé pomocné skripty, nemusí být přitom převzaty beze změny. Budou zachovány pouze v případě, že jsou pro samotný obchodní proces skutečně nezbytné.
Původní skript však zůstává zachován jako zdroj informací. V případě pozdějších dotazů lze tak zjistit, jak byl daný postup v řešení FileMaker původně vyřešen.
Schopnosti a omezení jsou výslovně definovány
Funkční kontejner by neměl mít přístup k libovolným částem aplikace pouze na základě obecného popisu. Proto lze výslovně stanovit povolené funkce a výjimky.
Funkce může například mít oprávnění číst a měnit záznamy v určité tabulce, aniž by zároveň mohla provádět mazání nebo změny v konfiguraci systému. Pokud vygenerovaný kód využívá oprávnění, které nebylo povoleno, SchallOS to dokáže rozpoznat a zablokovat jeho spuštění nebo zveřejnění.
Popis funkčního kontejneru tedy neslouží pouze k dokumentaci. Stává se součástí testovacího a bezpečnostního modelu. Právě u kódu generovaného umělou inteligencí je toto omezení důležité. Jazykový model získává jasný prostor pro působení, zatímco platforma kontroluje, zda se vygenerovaná funkce pohybuje v rámci tohoto rámce.
Správný kontext zlepšuje výsledky
Kvalita funkce generované umělou inteligencí nezávisí pouze na velikosti použitého jazykového modelu. Rozhodující je, zda model obdrží potřebné informace. SchallOS dokáže sestavit kontext z několika úrovní:
- aktuální otázka
- v otevřeném editoru
- vybraném poli nebo funkčním kontejneru
- v příslušných tabulkách a vztazích
- stávající vzorce a funkce
- sémantické popisy
- Dokumentace a historie změn
- a při migracích také původnímu skriptu FileMaker.
Díky tomu může umělá inteligence pracovat podstatně přesněji než v případě izolovaného dotazu v běžném chatu.
Zároveň není nutné u každého úkolu poskytovat kompletní řešení. Kontext lze omezit na informace, které jsou pro danou funkci skutečně potřebné.
Vyměnitelné modely namísto trvalého závazku
VRSTVA UMÍ NESMÍ BÝT TRVALE ZÁVISLÁ NA JEDINÉM MODELU NEBO POSKYTOVATELI. Různé úkoly kladou odlišné požadavky na kvalitu, rychlost, náklady a ochranu osobních údajů.
Složitá migrace může vyžadovat obzvláště výkonný model. Jednoduché vysvětlení nebo úpravu vzorce lze případně provést pomocí menšího modelu. V citlivých nebo uzavřených prostředích lze z dlouhodobého hlediska využít i lokálně provozované modely.
Trvalá znalostní základna proto nespočívá v jazykovém modelu, ale v řešení SchallOS: v popisech, strukturách, odkazech na skripty, kódu, testech a dokumentaci. Model umělé inteligence zůstává vyměnitelným nástrojem, který z tohoto kontextu generuje spustitelný kód nebo srozumitelné návrhy.
Prehledný vývoj podporovaný umělou inteligencí
SchallOS propojuje přímou práci s podnikovými aplikacemi s programováním podporovaným umělou inteligencí. Vzorce lze přímo vysvětlovat a generovat. Vlastní funkce vznikají na základě opakovaně použitelných oborových specifikací. Kontejnery funkcí propojují sémantické popisy s viditelným a ověřitelným kódem.
U migrovaných řešení zůstávají skripty FileMaker zachovány jako doplňková vzdělávací vrstva. Pomáhají porozumět stávajícím obchodním procesům, aniž by trvale zachovávaly dřívější technické závislosti.
Role vývojáře tím nezmizí. Pouze se mění. Přesné požadavky, smysluplná architektura, testování a odborná kontrola nabývají na důležitosti více než ruční zadávání každého jednotlivého programového kroku. Zejména u softwaru kritického pro chod podniku zůstává tato odpovědnost nepostradatelná.
Aktuální průzkum používání místních systémů umělé inteligence
Dokumentace a protokoly událostí jako součást aplikace
Dokumentace k podnikové aplikaci se často sepíše až poté, co je vývoj již dokončen. Vzhledem k časové tísni se práce zpočátku soustředí na nová pole, rozvržení, vzorce a funkce. Popis změn má následovat později.
S rostoucím časovým odstupem je však stále obtížnější pochopit původní rozhodnutí. Často již není přesně známo, proč byla určitá funkce doplněna, kterých objektů se to týkalo a jaké zvláštní případy bylo třeba zohlednit. SchallOS proto nepovažuje dokumentaci za dodatečný úkol. Relevantní změny jsou zaznamenávány již během vývoje jako události a propojovány s příslušnými součástmi řešení.
Na základě těchto informací lze následně vytvořit technickou dokumentaci, poznámky k nové verzi, zprávy pro zákazníky nebo protokoly o provedených úkonech. Dokumentace tak nevychází pouze z paměti nebo ručně psaných poznámek, ale ze skutečně provedených změn.
Události na několika úrovních
Řešení SchallOS nemá pouze jeden obecný protokol. Platforma rozlišuje různé úrovně událostí s vlastními úkoly.
- Na stránkách Protokol o struktuře zaznamenává změny v SSC. Patří sem například nové tabulky a pole, upravená rozvržení, změněné vzorce nebo nové kontejnery funkcí.
- Na stránkách Protokol událostí je součástí SSD. Tam se během produkčního provozu zaznamenávají procesy relevantní z odborného hlediska, jako jsou změny stavu, schválení, zrušení nebo úpravy důležitých datových záznamů.
- K tomu je třeba připočítat Provozní události z Runtime a SchallOS Control. Patří sem mimo jiné nasazení, aktualizace, kontroly, zálohování a operace vrácení do předchozího stavu.
Tyto oblasti zůstávají oddělené, lze je však propojit. Protokol vývoje by neměl být nepřehledný kvůli každodenním změnám v záznamech o zákaznících. Naopak interní technické detaily nepatří automaticky do věcné historie faktury nebo zakázky.
Strukturální protokol znázorňuje vývoj řešení
Změny v tabulkách, polích, rozvrženích, vzorcích a kontejnery funkcí lze uložit jako strukturované události. Záznam může zaznamenat, který objekt byl změněn, jaký byl předchozí stav a jaký nový stav vznikl. Dále lze zaznamenat vývojáře, čas, odborné zdůvodnění, příslušnou zakázku a plánovanou verzi vydání.
Pokud se například doplní nový proces schvalování zakázek, může to vést k několika technickým změnám. Vytvoří se pole stavu, rozšíří se rozvržení, upraví se vzorec a naprogramuje se nový funkční kontejner.
Strukturální protokol uchovává tyto jednotlivé události. Zároveň je lze seskupit pod společný odborný úkol. Díky tomu je zřejmé, že několik technických změn společně tvoří nový obchodní proces.
Change Sessions sdružují související práce
Vývojový úkol se často skládá z mnoha malých kroků. Čistě chronologický seznam jednotlivých změn by skutečnou souvislost zachytil jen nedostatečně.
SchallOS proto dokáže seskupit související práce do tzv. „Change Sessions“. „Change Session“ popisuje konkrétní úkol, rozšíření nebo opravu chyby a shromažďuje všechny související události. Může například obsahovat:
- popis odborných úkolů
- dotčené tabulky a rozvržení
- upravené vzorce a funkce
- provedené testy
- nevyřešené otázky
- a přiřazení k zákazníkovi nebo zakázce.
Několik změn lze později přiřadit k jedné verzi. Tímto způsobem vzniká jasná souvislost mezi vývojovým zadáním, technickými změnami a vydanou verzí.
Umělá inteligence srozumitelně zpracovává technické události
Dokumentační vrstva je propojena s integrovanou umělou inteligencí systému SchallOS. Díky tomu lze zaznamenané události automaticky zpracovávat pro různé cílové skupiny.
Technická zpráva vývojáře vyžaduje jiné informace než sdělení pro zákazníka. Zatímco vývojář chce vidět konkrétní názvy polí, kontejnery funkcí a migrace dat, zákazníka zajímá především to, jaká funkce byla doplněna a jaký přínos nabízí. Umělá inteligence proto dokáže shrnout stejné události v různých formách:
- jako interní technická dokumentace
- jako srozumitelné informace pro zákazníky
- jako poznámky k vydání
- jako zpráva o projektu
- nebo jako doklad o plnění k faktuře.
Texty nevznikají volně na základě obecného popisu. Odvozují se z „Change Sessions“, sémantických popisů objektů a skutečných změn struktury.
Vytvořený text přitom zůstává propojený se svými zdroji. Vývojář může zkontrolovat, na jakých událostech se dané tvrzení zakládá, a před jeho použitím formulaci opravit nebo schválit.
Protokoly o výkonu pro vývojáře a zákazníky
Pro vývojáře individuálního softwaru má dokumentace také ekonomický význam. Služby je třeba zákazníkovi srozumitelně vysvětlit a často se účtují podle času nebo podle pracovních balíčků.
V praxi se takové protokoly o poskytnutých službách často sestavují až těsně před vystavením faktury. K tomu je nutné prohledávat e-maily, poznámky a připomenutí.
SchallOS dokáže přiřadit skutečně zaznamenané vývojové události k zákazníkovi, projektu nebo zakázce. Umělá inteligence na jejich základě vygeneruje vhodné záznamy pro protokol o provedených pracích. Například několik technických změn lze shrnout do jedné srozumitelné položky:
Rozšíření správy zakázek o dvoustupňový schvalovací proces včetně kontroly stavu, uživatelských oprávnění a přizpůsobení vstupního formuláře.
Podkladové technické procesy zůstávají i nadále přehledné. Popis pro zákazníka představuje pouze srozumitelné shrnutí. Konečné rozhodnutí zůstává na vývojáři. Ne každá technická událost je automaticky fakturovatelná a interní testy či opravy nemusí být na faktuře uváděny jednotlivě.
Události na úrovni dat
I v produkčním provozu lze zaznamenávat všechny předem stanovené datové události. Patří sem vytváření a úpravy datových záznamů, změny stavu, schválení, importy, exporty nebo automaticky prováděné procesy. Zápis může zaznamenávat:
- který uživatel nebo proces akci spustil
- který záznam byl dotčen
- které hodnoty byly změněny
- jaká funkce byla provedena
- a zda byl proces úspěšně dokončen.
Konkrétní řešení určuje, které události se ukládají a v jaké úrovni detailnosti. Drobná oprava textu má jiný význam než změna již schválené faktury. Protokol událostí tak tvoří odbornou historii systému SSD. Slouží k podpoře technické podpory, analýze chyb a sledovatelnosti důležitých obchodních procesů.
Takový protokol může také sloužit jako základ pro požadavky na audit. Je však třeba v konkrétním případě ověřit, zda jsou tímto způsobem splněny všechny právní nebo odvětvové předpisy.
Dokumentace doprovází také nové verze a aktualizace
Zaznamenané vývojové události se zároveň promítají do procesu vydávání nových verzí a aktualizací. Při vydání nové verze dokáže SchallOS automaticky sestavit přehled toho, které funkce byly doplněny, které chyby byly opraveny a které datové struktury byly změněny. Na tomto základě vznikají seznamy technických změn, pokyny pro uživatele a informace o migraci.
Po instalaci je možné zjistit, která verze byla nainstalována na konkrétní instanci runtime a jaké změny v ní byly obsaženy.
Zaznamenávají se také provozní události, jako jsou zálohy, testy nebo případný rollback. Díky tomu lze později zjistit nejen to, co bylo vyvinuto, ale také kdy a s jakým výsledkem byla změna nasazena do produkčního prostředí.
Rozšiřující se znalostní základna
Kombinace protokolu událostí, sémantických popisů a podpory umělé inteligence vytváří v dlouhodobém horizontu znalostní základnu týkající se celého řešení. V případě pozdější změny není možné posuzovat pouze aktuální kód. Je také možné zjistit, kdy byla daná funkce zavedena, jaký obchodní důvod k tomu vedl a jaké další oblasti to v té době ovlivnilo.
Právě u podnikových aplikací, které se vyvíjely po mnoho let, jsou tyto znalosti rozhodující. I zdánlivě nadbytečný zvláštní případ může mít důležitý historický důvod. Bez dokumentace hrozí, že bude při pozdější revizi omylem odstraněn. SchallOS proto uchovává nejen technické stavy, ale také historii vývoje a s ní související rozhodnutí.
Dokumentace se tak stává aktivní součástí aplikace. Podporuje vývoj, komunikaci se zákazníky, fakturaci, technickou podporu, vydávání nových verzí a dlouhodobou udržovatelnost – a to na základě událostí, které se v systému skutečně odehrály.
Systémová aktualizační pipeline pro platformu a aplikace
Podnikový software málokdy zůstává po delší dobu beze změn. Nové požadavky, změny v legislativě, opravy chyb a technický vývoj pravidelně vedou k vydávání nových verzí. Přitom nestačí pouze vyměnit soubory. Před každou aktualizací je třeba zkontrolovat, která verze je aktuální, zda je třeba upravit datové struktury a jak lze v případě chyby obnovit předchozí stav.
U mnoha individuálních aplikací vznikají takové postupy až dodatečně. Aktualizace se pak distribuují pomocí ručních pokynů, záložních kopií a skriptů přizpůsobených konkrétním zákazníkům. S každou další instalací roste riziko, že dojde k rozdílu ve verzích a vzniku speciálních řešení.
SchallOS proto považuje aktualizace za systémovou funkci platformy. Prostřednictvím stejného základního procesu se aktualizuje jak samotný SchallOS, tak i zákaznická řešení vyvinutá na této platformě.
Vývojář tak nemusí pro novou aplikaci nejprve navrhovat vlastní postup aktualizace. Správa verzí, kontrola, distribuce a protokolování jsou od samého počátku součástí společné architektury.
Oddělení SSC a SSD chrání produkční data
Možnost aktualizace přímo souvisí s oddělením struktury a dat. SSC obsahuje rozvržení, vzorce, kontejnery funkcí, definice jazyků a datový model aplikace. SSD obsahuje produkční obchodní data dané společnosti.
Při zavedení nové verze se proto nenahrazuje celá aplikace včetně všech zákaznických dat. Místo toho lze vydat nový SSC, zatímco stávající SSD zůstane v místě nasazení zachován.
Pokud nová struktura vyžaduje další pole, tabulky nebo změněné formáty dat, provedou se za tímto účelem výslovně definované migrační kroky. Produkční data se kontrolovaně přizpůsobí nové struktuře a nedojde k jejich nepozorované výměně za jiný datový soubor.
Toto jasné oddělení umožňuje další vývoj aplikací po mnoho let, aniž by bylo nutné při každé aktualizaci přenášet veškerá obchodní data do nového kompletního souboru.
Od fáze vývoje až po vydání
Ne každá změna v programu SchallOS Studio je okamžitě vhodná pro produkční použití. Během vývoje se mohou vyskytovat předběžná rozvržení, neúplné funkce nebo dosud neotestované vzorce.
Související změny se proto nejprve zaznamenávají v rámci „Change Sessions“ a přiřazují se k plánovanému vydání. Teprve po kontrole a schválení z nich vznikne zveřejněná verze. Vydání může mimo jiné obsahovat:
- jednoznačné číslo verze
- aktualizovaný SSC
- nezbytné migrace na SSD
- technické předpoklady
- Závislosti na běhovém prostředí nebo adaptérech
- Kontrolní a testovací kroky
- Poznámky k vydání
- a také informace pro případný návrat k předchozí verzi.
Základem pro to je dokumentační vrstva. Z zaznamenaných událostí vývoje lze automaticky generovat seznamy technických změn a srozumitelné pokyny pro uživatele.
Verze tedy neobsahuje pouze upravené soubory. Současně popisuje, co bylo změněno, jaké jsou předpoklady a jak má být instalace zkontrolována.
SchallOS Control řídí rozvod
SchallOS Control zajišťuje operativní správu aktualizací. Zde je možné zjistit, jaké instance jsou k dispozici, které verze prošly fázemi 1TP12 a jaké aktualizace jsou připraveny. Před instalací může Control mimo jiné zkontrolovat:
- zda je cílový subjekt dostupný
- jaká verze Runtime a SSC se používá
- který databázový adaptér je aktivní
- zda lze vytvořit vhodnou pojistku
- a zda jsou splněny všechny podmínky pro vydání.
Tím se zabrání provedení aktualizace na technicky nevhodné nebo nedostatečně připravené instalaci.
Verze navíc nemusí být distribuována současně do všech systémů. Nejprve ji lze nasadit v testovacím prostředí nebo na vybraných instalacích. Teprve po úspěšném otestování dojde k širšímu nasazení.
K tomuto účelu lze vymezit různé kanály aktualizací, například stabilní produkční verze, předběžné verze, interní testy nebo verze přizpůsobené konkrétním zákazníkům.
Signatury a jednoznačné verze
Aktualizační balíčky mohou být opatřeny kontrolními součty a digitálními podpisy. Díky tomu systém SchallOS Control rozpozná, zda je balíček úplný, zda pochází z určeného zdroje a zda byl od svého vydání změněn.
Dále se ověřuje, zda daná verze skutečně patří k příslušnému řešení. Nový SSC nesmí být omylem propojen s SSD jiné aplikace.
Jednoznačné identifikátory řešení, verze struktur a verze datových modelů zajišťují, že stav install zůstává sledovatelný. Lze také identifikovat nezbytné mezikroky. Instalace například nemůže přejít přímo ze velmi staré verze na nejnovější verzi, pokud je předtím nutné provést migraci dat.
Zálohování, migrace a ověření
Před strukturální aktualizací se provede záloha stávajícího stavu. Konkrétní způsob zálohování závisí na použitém databázovém adaptéru. Lokální instalace IndexedDB nebo SQLite vyžaduje jiné postupy než server PostgreSQL.
Následně se zkontroluje aktualizační balíček, nastaví se nová struktura 1TP12 a provede se případná migrace dat. Po aktivaci následuje ověření. Při tom může systém SchallOS například zkontrolovat:
- zda jsou k dispozici všechny očekávané tabulky a pole,
- zda byla migrace dat dokončena,
- zda počty záznamů a kontrolní součty souhlasí,
- a zda jsou důležité funkce prováděny správně.
Teprve po úspěšném dokončení těchto testů se aktualizace považuje za installiert. Pouhý přenos souborů tedy nestačí. Rozhodující je, aby struktura, data a runtime následně opět tvořily konzistentní a funkční celek.
Vrácení změn v případě neúspěšných aktualizací
I přes pečlivou přípravu může aktualizace selhat. Neočekávané staré údaje, chybná migrace nebo nezohledněná závislost mohou vést k tomu, že novou verzi nelze bezpečně aktivovat. Pro takové případy je součástí aktualizačního postupu vrácení do předchozího stavu. Při tom se obnoví předchozí verze SSC, zálohovaný stav SSD a předchozí konfigurace.
Ne každou aktualizaci však lze vrátit zpět na libovolně dlouhou dobu. Pokud již po instalaci byla podle změněných pravidel zpracována nová produkční data, může být úplný návrat problematický. Verze proto musí stanovit, za jakých podmínek je vrácení zpět možné.
V některých případech je vhodnější provést opravnou následnou aktualizaci než obnovit starší verzi dat. Platforma poskytuje technický rámec, konkrétní rozhodnutí však závisí na dané změně a jejím odborném významu.
I samotný SchallOS tento proces využívá
Pipeline aktualizací není určena pouze pro zákaznická řešení. Stejnými základními mechanismy se aktualizují také SchallOS Studio, Runtime, Control a další komponenty platformy. Nové verze platformy mohou obsahovat rozšíření prostředí pro vzorce, vylepšení vrstvy umělé inteligence, nové databázové adaptéry nebo opravy zabezpečení. I v tomto případě jsou vyžadovány informace o verzích, závislostech, signaturách a kontrolách.
Díky tomu se infrastruktura využívá a průběžně testuje přímo v rámci běžného provozu platformy. Aplikace vyvinuté pomocí SchallOS těží ze stejných postupů.
Vývojář tak nezískává pouze teoreticky plánovanou funkci aktualizace, ale proces, který je nedílnou součástí provozu i dalšího vývoje celého systému.
Plánovaný směr pro budoucí verze
Síla procesu aktualizací nespočívá pouze v automatickém distribuování nových souborů. Rozhodující je propojení vývoje, dokumentace, zálohování, migrace, testování a vrácení změn v rámci jednoho společného procesu.
Samotný SchallOS i aplikace vyvinuté na jeho základě využívají stejnou základní infrastrukturu. Oddělení SSC a SSD zajišťuje, že se struktura může dále rozvíjet, zatímco produkční data jsou chráněna a upravována pod kontrolou.
Řešení vyvinuté pomocí SchallOS tak má již od samého počátku naplánovanou cestu pro budoucí verze. Zejména u podnikového softwaru, který má být používán po mnoho let, není tato možnost aktualizace pouze doplňkovou funkcí, ale zásadním předpokladem pro dlouhodobou udržovatelnost a spolehlivý provoz.
Runtime, Control a Cloud pro různé provozní modely
Vývojové prostředí vyžaduje rozsáhlé možnosti. Vývojáři musí mít možnost měnit struktury, navrhovat rozvržení, upravovat vzorce a publikovat nové funkce. V každodenním provozu hotové podnikové aplikace se však tyto nástroje většinou nepoužívají.
SchallOS proto rozděluje vývoj, provoz a správu do různých oblastí. SchallOS Studio slouží k vývoji. SchallOS Runtime spouští zveřejněné aplikace. SchallOS Control spravuje jejich technické nasazení. SchallOS Cloud nabízí stejnou základní architekturu jako centrálně provozovaná online služba.
Při tom nevznikají žádné navzájem nezávislé aplikace. Všechny oblasti pracují se stejnými strukturami SSC a SSD. Režim provozu se nastavuje prostřednictvím nasazení, databázového adaptéru a profilu běhu.
SchallOS Runtime spouští zveřejněná řešení
SchallOS Runtime propojuje SSC aplikace s příslušným SSD a poskytuje v něm definovaná rozvržení, vzorce a funkce. Součástí běhu jsou mimo jiné zobrazení a ovládání rozvržení, čtení a úprava datových záznamů, výpočet vzorců a vlastních funkcí, spouštění funkčních kontejnerů, navigace a ovládání dialogových oken, vícejazyčná podpora a připojení k určenému databázovému adaptéru.
Runtime však automaticky neobsahuje všechny nástroje SchallOS Studio. Nelze v něm vytvářet nové páry řešení SSC/SSD a neobsahuje průvodce migrací pro řešení FileMaker.
Díky tomu zůstává nasazená zákaznická aplikace jasně oddělena od samotného vývojového prostředí.
Profily určují schopnosti běhového prostředí
Ne každá instalace vyžaduje stejný rozsah funkcí. Čistě koncová aplikace by měla případně provádět pouze zveřejněná rozvržení a obchodní procesy. Interní instalace může vyžadovat další správní nebo diagnostické funkce.
SchallOS k tomu využívá profily běhu a schopností. Ty určují, jaké technické schopnosti má konkrétní instance.
Profil může například určovat, zda je k dispozici režim rozvržení, zda je možné importovat nebo exportovat data, zda se mají zobrazovat administrativní dialogová okna, zda lze měnit místní nastavení nebo zda je možné používat určitá rozhraní.
Tyto profily doplňují uživatelská oprávnění v rámci samotného řešení. Uživatelská oprávnění určují, co smí daná osoba z odborného hlediska dělat. Profil běhu naopak určuje, jaké technické možnosti daná instalace zásadně poskytuje.
Díky tomu lze stejnou runtimeovou základnu použít pro různé skupiny zákazníků a různé případy použití, aniž by bylo nutné pro každou variantu vyvíjet samostatnou verzi programu.
Od lokálního samostatného počítače až po provoz na serveru
Řešení SchallOS lze nasadit v různých provozních režimech. Pro lokální jednouživatelské prostředí lze například SSD uložit do IndexedDB. Vícevrstvá desktopová aplikace může využívat SQLite. Pro rozsáhlejší řešení s více uživateli je určena centrální databáze, jako je PostgreSQL.
Tyto provozní modely mají různé vlastnosti. IndexedDB se hodí především pro lokální prohlížečové aplikace. SQLite je osvědčeným základem pro lokální aplikace a přehledné instalace. PostgreSQL je vhodný pro centrální víceuživatelské systémy s profesionální správou serverů.
SchallOS nepovažuje tyto technologie za zcela zaměnitelné úložiště. Výměna adaptéru vyžaduje řízený přenos dat, kontrolu a případně vrácení změn. Společná architektura SSC/SSD zajišťuje, že rozvržení, vzorce a obchodní logiku není nutné pro každý databázový adaptér vyvíjet zcela od začátku.
Aplikace pro stolní počítače a práce v prohlížeči
Řešení SchallOS by měla být provozovatelná jak v prohlížeči, tak jako aplikace pro Windows a macOS. Desktopové runtime prostředí se může lépe integrovat do příslušného operačního systému, kontrolovaně využívat lokální soubory a při vhodné konfiguraci pracovat dočasně v režimu offline. Data může ukládat lokálně pomocí IndexedDB nebo SQLite, případně přistupovat k centrální databázi PostgreSQL.
V prohlížeči je aplikace zobrazena prostřednictvím vlastního runtime prostředí SchallOS. K tomu není zapotřebí ani server FileMaker, ani FileMaker WebDirect. Migrované řešení FileMaker tedy po přenosu již neběží na pozadí na souboru FileMaker. Rozvržení, vzorce a funkční logika se provádějí v rámci architektury SchallOS.
SchallOS Control spravuje instance
SchallOS Control představuje provozní řídicí centrum platformy. Zde se spravuje, které řešení běží na kterém cílovém systému a jaké jsou technické požadavky. Control může mimo jiné zobrazovat:
- jaké páry SSC/SSD byly nasazeny
- která verze runtime je installiert
- jaký databázový adaptér se používá
- který profil schopností platí
- jaké aktualizace jsou k dispozici
- a kdy byla instance naposledy zkontrolována.
Cílem nasazení může být například lokální aplikace pro Windows, runtime pro macOS, vlastní server PostgreSQL, testovací prostředí nebo cloudová instance.
Provozní údaje, jako jsou adresy serverů, přístupy k databázím, licence nebo vazby na lokální zařízení, do přenosného SSC nepatří. Tyto údaje se spravují v chráněné konfiguraci příslušné instance.
Podepsaná řešení a kontrolované šíření
Přenosné kontejnery řešení nesmí znamenat, že každou aplikaci lze libovolně měnit nebo spouštět na systémech, pro které nebyla určena. Zveřejněné balíčky SSC/SSD proto mohou být spojeny s identifikátory řešení, kontrolními součty, podpisy a informacemi o instancích. Runtime může při spuštění ověřit, zda je SSC nezměněný a platně podepsaný, zda SSD patří ke správnému řešení, zda jsou obě verze vzájemně kompatibilní a zda je k dispozici platný profil nasazení.
V závislosti na licenčním modelu může být poskytnutí licence vázáno na instanci, server, zařízení nebo určitou skupinu uživatelů. SchallOS Control přitom spravuje i nezbytné změny, jako je například výměna serveru, nová aktivace nebo obnovení instalace.
SchallOS Cloud jako provozní model SaaS
SchallOS Cloud poskytuje aplikace jako centrálně spravovanou online službu. Cloud však nepoužívá žádný vlastní, odlišný formát řešení. Aplikaci vyvinutou v SchallOS Studio lze přiřadit k cloudové instanci a zpřístupnit ji prostřednictvím prohlížeče. Runtime, databáze, zálohy, monitorování a aktualizace jsou spravovány centrálně. Pro vývojáře a zákazníky z toho vyplývá model SaaS, aniž by bylo nutné aplikaci speciálně přepracovávat pro samostatnou cloudovou platformu.
Základní přenositelnost zůstává zachována. Řešení lze později převést na vlastní server nebo do jiného podporovaného provozního režimu, pokud to umožňují objem dat, funkce a technické předpoklady. Přechod zůstává řízenou migrací, nevyžaduje však kompletní přestavbu aplikace.
Řešení, které dokáže růst spolu s vašimi požadavky
Novou aplikaci lze nejprve vyvinout lokálně a otestovat ji s malým objemem dat. Později ji lze nasadit jako interní runtime, přejít na SQLite nebo PostgreSQL a nakonec ji zveřejnit jako serverové nebo cloudové řešení. Tabulky, rozvržení, vzorce, kontejnery funkcí, překlady a dokumentace přitom zůstávají součástí stejné struktury řešení.
Ne každý prototyp se bez úprav stane velkou podnikovou aplikací. Je třeba i nadále pečlivě plánovat provoz s více uživateli, bezpečnost, výkon a zálohování. Platforma však zabraňuje tomu, aby růst nutně vyžadoval kompletní změnu technologie.
Runtime, Control a Cloud tak propojují různé provozní modely v rámci společné architektury. Aplikace se vyvine jednou a poté se řízeným způsobem nasadí pro konkrétní použití – lokálně, na vlastním serveru nebo jako SaaS v cloudu.
Rád. Tuto část bych zařadil hned za kapitolu o umělé inteligenci nebo jako doplněk ke kapitole 4. Zachycuje totiž důležitou myšlenku: umělá inteligence není pevně vázána na konkrétního poskytovatele, ale je, podobně jako databázové adaptéry, považována za zaměnitelnou součást infrastruktury.
Adaptér pro umělou inteligenci namísto vázání na konkrétního výrobce
SchallOS záměrně odděluje samotnou vrstvu umělé inteligence od použitých jazykových modelů. Platforma nepracuje výhradně s jedním poskytovatelem ani s konkrétním runtime prostředím. Místo toho lze nastavit různé adaptéry umělé inteligence a centrálně je spravovat.
Tyto adaptéry zajišťují propojení mezi SchallOS a příslušnými jazykovými modely. Díky tomu zůstává samotné vývojové prostředí nezávislé na tom, zda je dotaz odeslán do lokálního modelu, nebo do cloudové služby.
Umělá inteligence se tak stává zaměnitelnou součástí platformy – podobně jako databázové adaptéry pro IndexedDB, SQLite nebo PostgreSQL.
Centrální správa v SchallOS Control
Nastavení KI se provádí centrálně prostřednictvím SchallOS Control. Tam lze vytvořit a spravovat libovolný počet adaptérů KI. Podporovány jsou jak lokální modely, tak cloudové služby.
Lokální modely lze například integrovat prostřednictvím nástrojů Ollama nebo LM Studio. Pro mnoho vývojových úkolů postačí již kompaktní lokální model, který se spouští výhradně na vlastním počítači.
Kromě toho lze nastavit cloudové modely, jako jsou ChatGPT, Claude nebo další kompatibilní služby. Každý adaptér má přitom svou vlastní konfiguraci, například přihlašovací údaje, koncové body, názvy modelů nebo další technická nastavení. Tím vzniká centrální přehled o všech dostupných systémech umělé inteligence v rámci jedné instalace SchallOS.
Stačí nastavit jednou a je to k dispozici kdekoli
Velkou výhodou této architektury je, že jednou nastavený adaptér AI se nepoužívá pouze na jednom místě. Jakmile je adaptér nastaven v SchallOS Control, je k dispozici pro celou platformu. Lze jej například použít:
- v editoru vzorců
- v rámci funkčních kontejnerů
- pro automatickou dokumentaci
- při migraci řešení FileMaker
- v Adapter Studio
- nebo v budoucích vývojových nástrojích využívajících umělou inteligenci.
Vývojář proto nemusí přístupové údaje ani modely konfigurovat opakovaně. Správa probíhá centrálně, zatímco jednotlivé komponenty pouze vybírají požadovaný adaptér.
Vhodný model pro daný úkol
Ne každý vývojový úkol vyžaduje stejný výpočetní výkon. K krátkému vysvětlení vzorce často postačí malý lokální model. Rozsáhlé migrace nebo složité programátorské úkoly mohou naopak těžit z výkonnějšího cloudového modelu.
SchallOS proto umožňuje výběr různých adaptérů v závislosti na konkrétním použití. Vývojář může například nastavit, že jednoduchá dokumentace se bude vždy vytvářet lokálně, zatímco obzvláště rozsáhlé úkoly budou předávány externímu modelu. Tím lze lépe sladit rychlost, ochranu osobních údajů a náklady.
Otevřeno pro budoucí modely
Vývoj v oblasti umělé inteligence probíhá mimořádně rychlým tempem. Nové modely se objevují v krátkých intervalech, zatímco stávající systémy se neustále vylepšují. SchallOS se proto trvale nevazuje na jediného dodavatele. Rozhodující není název konkrétního modelu, ale standardizované adaptérové rozhraní.
Díky tomu lze později doplnit nové lokální nebo cloudové systémy umělé inteligence, aniž by bylo nutné měnit samotné vývojové prostředí. Tato otevřenost odpovídá základní architektuře SchallOS. Stejně jako u databázových adaptérů by i adaptéry umělé inteligence měly zůstat zaměnitelné, zatímco Studio, Runtime a samotná aplikace mohou pokračovat v práci beze změn.
Díky tomu se umělá inteligence stane trvale integrovanou funkcí platformy – bez ohledu na to, jaké modely nebo poskytovatelé se v příštích letech prosadí na trhu.
Samoučící se vrstva umělé inteligence namísto statických podnětů
Zásadním pokrokem systému SchallOS je to, že integrovaná umělá inteligence již nepracuje výhradně se statickými systémovými pokyny. Místo toho vzniká samoučící se vrstva umělé inteligence, která na základě reálných vývojových projektů neustále zdokonaluje svůj způsob fungování.
Každé spuštění funkčního kontejneru může – pokud si to vývojář přeje – poskytnout anonymizované údaje o kvalitě. K dispozici jsou navíc reprodukovatelné benchmarkové testy, při nichž jsou skutečné funkční kontejnery daného řešení automaticky testovány s různými lokálními a cloudovými modely umělé inteligence. SchallOS přitom hodnotí nejen rychlost, ale především kvalitu generovaných výsledků, rozpoznané chyby, opravy a dodržování definovaných programovacích smluv.
Z těchto dat se automaticky generují profilované modely, vzory učení a antivzory. Platforma se tak učí nejen to, který prompt funguje lépe, ale také to, které strategie se skutečně osvědčily pro konkrétní rodiny modelů, úkoly a chybové situace.
Kvalifikace v oblasti umělé inteligence od úrovně L1 po L4
Společnost SchallOS zavádí vícestupňovou kvalifikaci používaných modelů umělé inteligence. Namísto paušálního zařazení každého modelu jako „vhodného“ či „nevhodného“ se provádí hodnocení podle různých oblastí použití. Model může například dosáhnout nejvyšší úrovně kvalifikace pro migrace FileMaker, zatímco pro nové sémantické vývojové projekty je zpočátku doporučován pouze s omezením. Klasifikace není založena na údajích výrobce, ale výhradně na reprodukovatelných benchmarkových testech a reálných produkčních cyklech.
Díky tomu může SchallOS automaticky rozhodnout, který model má pro daný úkol nejvyšší pravděpodobnost úspěchu a kdy je vhodné použít výkonnější nebo alternativní model.
Inteligentní modelové profily namísto klasických pokynů
Každý podporovaný model umělé inteligence bude v budoucnu mít vlastní profil modelu s verzí. Ten popisuje nejen samotný systémový pokyn, ale obsahuje také zkušenosti získané při praktickém použití právě tohoto modelu.
Systém SchallOS bude v budoucnu rozlišovat mimo jiné mezi profily pro:
- kontejnery sémantických funkcí
- Migrace FileMaker
- pozdější migrace do Microsoft Access, 4D nebo Oracle
- a další zdrojové systémy
Tyto profily jsou doplněny o editovatelné základní texty profilů, které může vývojář přizpůsobit nebo dále vylepšit pomocí automatických optimalizačních kampaní. Díky tomu může SchallOS přes noc otestovat různé varianty a automaticky převzít ty nejúspěšnější strategie.
Možnosti řešení jako inteligentní oborové rozhraní
Kromě technických schopností platformy (Platform Capabilities) zavede SchallOS v budoucnu také schopnosti řešení (Solution Capabilities). Ty popisují funkční schopnosti konkrétní aplikace a tvoří veřejné rozhraní mezi umělou inteligencí a obchodní logikou. Příkladem jsou funkce jako:
- Vytvořit zákazníka
- Vytvořit nabídku
- Převzít zakázku
- Vytvořit fakturu
- Zaúčtovat platbu
Umělá inteligence smí s řešením komunikovat výhradně prostřednictvím těchto schválených funkcí. Přímý přístup k interním funkčním kontejnerům je záměrně vyloučen. Díky tomu je vždy možné dohledat, jaké akce smí umělá inteligence skutečně provádět.
Vývojář může snadno definovat a verzovat vlastní funkce řešení. Ty se ukládají společně s řešením v SSC a jsou k dispozici jak vývojové AI, tak později i koncovým uživatelům.
Učení se na základě reálných projektů
Integrovaný benchmarkový modul nepracuje s umělými ukázkovými programy, ale na přání využívá jako testovací základ skutečné funkční kontejnery daného řešení. Tím vzniká pro každou aplikaci individuální hodnocení umělé inteligence, které je přesně přizpůsobeno danému stylu programování, použitým obchodním objektům a stávajícím funkčním kontejnerům.
Čím déle se řešení používá a dále vyvíjí, tím rozsáhlejší jsou jeho vzorce učení a tím přesněji dokáže SchallOS vybírat vhodné modely, předcházet chybám a automaticky generovat nové funkce.
Skutečná inteligence tedy již nespočívá výhradně v samotném jazykovém modelu, ale stále více v řešení a v jeho neustále se rozšiřujících zkušenostních znalostech.
Adapter Studio jako univerzální integrační platforma
Díky novému adaptéru Studio se SchallOS stává otevřenou integrační platformou. Externí systémy bude možné v budoucnu propojit prostřednictvím standardizovaných adaptérů – ať už se jedná o databáze, cloudové služby, rozhraní REST nebo systémy umělé inteligence.
Díky tomu již nevznikají žádné rigidní, proprietární integrace. Místo toho mohou vývojáři prostřednictvím Solution Capabilities propojit se svou aplikací libovolné externí systémy. I komplexní hybridní řešení, u nichž běží souběžně několik ERP systémů, lze takto elegantně koordinovat. Umělá inteligence přitom přistupuje výhradně k definovaným funkcím a nemusí znát ani interní datové struktury, ani technické detaily připojených systémů.
Znalosti se stávají skutečným kapitálem
Díky SchallOS se těžiště moderního vývoje softwaru výrazně posouvá. Největší hodnotu aplikace již netvoří samotný programový kód, ale strukturované znalosti o něm. SchallOS podporuje také nový Formát OKF, které společnost Google zveřejnila v červnu 2026 s cílem umožnit v budoucnu také přenosnou integraci či sdílení znalostí.
Funkční kontejnery, znalostní vrstva, vzory učení, smlouvy o schopnostech, výsledky benchmarkingu a profily optimalizované pomocí modelů se společně stávají součástí řešení a lze je spolu s ním přenášet, verzovat a průběžně dále rozvíjet.
Díky tomu si každá aplikace SchallOS v průběhu času vyvíjí vlastní, stále se zlepšující schopnosti v oblasti umělé inteligence, které zůstávají přímo propojeny s daným řešením.
Od migrace na platformu FileMaker k nezávislé softwarové platformě
SchallOS vzešel z dlouholeté spolupráce se společností FileMaker. Mnohé základní myšlenky této platformy vycházejí ze zkušeností s individuálními databázovými a ERP řešeními, která se v průběhu let vyvíjela společně s jejich provozními požadavky.
FileMaker vyniká zejména v oblasti rychlého vývoje. Datový model, rozvržení a programová logika jsou navzájem úzce propojeny, změny jsou okamžitě viditelné a první funkční řešení lze vytvořit relativně rychle.
Tato úzká provázanost mezi vývojáři, daty a uživatelským rozhraním by měla být v systému SchallOS zachována. Technický základ však bude vybudován zcela nově. Systém SchallOS využívá vlastní runtime, vlastní strukturální a datové kontejnery, funkční vrstvu podporovanou umělou inteligencí a vlastní infrastrukturu pro dokumentaci, nasazení a aktualizace.
FileMaker tak zůstává důležitým výchozím bodem a možným zdrojem stávajících řešení. Pro budoucí provoz však již není nezbytný.
Migrace je víc než jen import rozvržení
Existující řešení FileMaker se neskládá pouze z tabulek, polí a viditelných masek. Velká část odborných znalostí je ukryta ve vzorcích, skriptech, triggerech, vztazích, seznamech hodnot a četných zvláštních případech.
Úspěšná migrace musí tyto souvislosti zachytit a převést je do nové architektury. Tabulky, pole, vztahy a rozvržení lze přitom převzít z velké části ve stejné struktuře. Vzorce a vlastní funkce se přenesou do prostředí vzorců SchallOS nebo se přizpůsobí.
U skriptů FileMaker je v první řadě klíčové pochopení jejich odborného účelu. Mohou zůstat zachovány jako výuková a referenční vrstva v pozadí nových funkčních kontejnerů. Spustitelný kód je však pomocí umělé inteligence přeprogramován tak, aby odpovídal architektuře SchallOS. Tím pádem v rámci nového systému nevzniká žádné prostředí FileMaker. Stávající řešení se postupně promění v samostatnou aplikaci SchallOS.
Nezávislý provoz po migraci
Po dokončení migrace již nebude zapotřebí ani FileMaker Pro, ani FileMaker Server, ani WebDirect. Nová aplikace využívá SchallOS Runtime, SSC jako strukturální kontejner a SSD pro produkční data. Vzorce, kontejnery funkcí, vícejazyčnost, dokumentace, protokoly událostí a aktualizace jsou poskytovány platformou SchallOS.
V závislosti na požadavcích lze řešení provozovat lokálně, jako aplikaci pro Windows nebo macOS, na vlastním serveru nebo jako službu SaaS v SchallOS Cloud.
Tím končí závislost na jediném proprietárním běhovém prostředí. Technické závislosti tím sice zcela nezmizí – každý moderní software potřebuje operační systémy, databáze a serverové služby. Struktura, obchodní logika a data však zůstávají přenositelné a lze je provozovat prostřednictvím zdokumentovaných adaptérů a způsobů nasazení.
Nové možnosti pro vývojáře FileMaker
Pro vývojáře FileMaker by SchallOS neměl znamenat úplný odklon od dosavadního způsobu práce. Znalosti o datových modelech, návrhu rozvržení a provozních procesech zůstávají i nadále cenné.
Změna se týká především implementace programové logiky. Místo dlouhých řetězců skriptů se používají sémanticky popsané kontejnery funkcí. Umělá inteligence programuje spustitelný kód na základě definovaných úkolů, parametrů a omezení. Vývojář výsledek zkontroluje a nadále nese odpovědnost za architekturu a odbornou správnost.
Větší pozornost se věnuje také historii vývoje. Změny lze automaticky zaznamenávat, dokumentovat a seskupovat do jednotlivých verzí. Stejný proces aktualizací, prostřednictvím kterého se aktualizuje samotný SchallOS, je k dispozici i pro vlastní zákaznická řešení.
Díky tomu se práce částečně přesouvá od ručního zadávání jednotlivých programových kroků k přesnému popisu, kontrole a strukturování obchodních procesů.
Nejen pro migrované aplikace
Migrace FileMaker zůstává důležitou součástí systému SchallOS, není však jeho jediným účelem. Nové aplikace lze vyvíjet zcela v prostředí SchallOS Studio.
V dlouhodobém horizontu by mohla být podporována i další zdrojová systémy. Takové rozšíření však v každém jednotlivém případě vyžaduje vlastní postupy analýzy a migrace. Různé vývojové platformy mají své vlastní koncepce, které nelze smysluplně zohlednit pomocí povrchního univerzálního importu.
Základem pro to jsou zkušenosti z migrace FileMaker. Skutečným účelem systému SchallOS je však vývoj a provoz nezávislých podnikových aplikací.
Plánované zahájení na podzim roku 2026
Veřejné spuštění SchallOS je plánováno na podzim roku 2026. Do té doby budou klíčové části platformy dále sjednocovány, testovány a připravovány pro první produkční nasazení. Ne všechny funkce plánované z dlouhodobého hlediska budou již při spuštění plně vyvinuty. Rozhodující je spolehlivé jádro, na kterém lze kontrolovaně budovat další databázové adaptéry, funkce umělé inteligence, možnosti migrace a provozní modely.
Nejprve se Software gFM-NEXT ERP od společnosti gofilemaker.de bude pravděpodobně zveřejněn na nové platformě SchallOS v září 2026. Spuštění vývojové platformy SchallOS o něco později na podzim 2026 by proto nemělo znamenat konec vývoje, ale začátek praktického nasazení.
Celý životní cyklus aplikace
Projekt SchallOS vycházel z otázky, jak lze stávající řešení FileMaker převést do moderního prostředí. Výsledkem je platforma, která zohledňuje nejen migraci a vývoj, ale také dokumentaci, nasazení, správu dat, aktualizace a dlouhodobý provoz. Studio, Runtime, Control a Cloud přitom přebírají jasně oddělené úkoly v rámci společné architektury. Cílem tedy není pouze nahradit FileMaker jiným vývojovým nástrojem. SchallOS má propojit osvědčenou blízkost mezi vývojářem, daty a uživatelským rozhraním s přenositelnými kontejnery, programováním podporovaným umělou inteligencí a jednotným provozním modelem.
Výchozím bodem je DNA FileMaker. Cílem je vytvořit nezávislou platformu, na které bude možné dlouhodobě vyvíjet, provozovat a udržovat stávající i nové podnikové aplikace.
Často kladené otázky
- Co přesně je SchallOS a v čem se liší od klasické databázové aplikace?
SchallOS je platforma pro vývoj, spouštění a správu individuálního podnikového softwaru. Zahrnuje nejen tabulky, rozvržení a funkce, ale také programování s podporou umělé inteligence, dokumentaci, protokoly událostí, nasazení a aktualizace. SchallOS Studio slouží k vývoji, Runtime spouští hotové aplikace, Control spravuje instalace a Cloud poskytuje řešení jako SaaS. Platforma tak doprovází aplikaci od jejího vzniku až po dlouhodobý provoz. - Pro jaké vývojáře a společnosti je SchallOS určen?
SchallOS je určen zejména vývojářům FileMaker, softwarovým firmám a vývojářům individuálních podnikových aplikací. I společnosti s existujícími řešeními FileMaker získávají možnost postupně převést své aplikace do nezávislého prostředí. Navíc lze v SchallOS vytvářet zcela nová řešení. Pro jednatele a technické rozhodovací činitele je zajímavé především to, že vývoj, provoz, dokumentace, aktualizace a různé formy nasazení jsou organizovány v rámci jedné společné platformy. - Je SchallOS především náhradou za FileMaker?
FileMaker je důležitým výchozím bodem, ale není trvalým technickým základem systému SchallOS. Osvědčené koncepty, jako je vizuální vývoj a úzké propojení dat, rozvržení a funkcí, jsou převzaty. Runtime, správa dat, funkční logika a infrastruktura pro aktualizace jsou však budovány samostatně. SchallOS dokáže migrovat stávající řešení FileMaker, ale hodí se stejně tak i pro nové aplikace. Po dokončení migrace již nebude FileMaker pro produkční provoz potřebné. - Je možné moje stávající řešení FileMaker zcela automaticky migrovat?
Tabulky, pole, vztahy, rozvržení a další definované struktury lze převzít z velké části automatizovaně. V případě složité obchodní logiky je však nutná dodatečná kontrola. Skripty FileMaker často obsahují změny rozvržení, globální proměnné, pluginy nebo historicky vzniklé zvláštní případy. Umělá inteligence dokáže tyto procesy analyzovat a na jejich základě vytvořit nové funkční kontejnery. Komplexní řešení by však měl přesto zkontrolovat vývojář a v případě potřeby jej upravit. Migrace výrazně snižuje manuální náročnost, nenahrazuje však odborné porozumění aplikaci. - Co se stane se stávajícími skripty FileMaker po migraci?
Skripty mohou zůstat v pozadí nových funkčních kontejnerů jako výuková a referenční vrstva. Nebudou však spouštěny beze změn. Umělá inteligence analyzuje, jaký odborný úkol skript plní, která pole používá a jaké podmínky jsou kontrolovány. Následně naprogramuje nový spustitelný kód tak, aby odpovídal architektuře SchallOS. Původní skript zůstává zachován jako historický zdroj znalostí a lze jej i nadále zohlednit v případě pozdějších dotazů nebo rozšíření. - Co jsou SSC a SSD a proč řešení vyžaduje dva kontejnery?
SSC obsahuje strukturu aplikace, včetně tabulek, polí, rozvržení, vzorců, kontejnerů funkcí, jazyků a dokumentace. SSD obsahuje produkční data, jako jsou zákazníci, položky, objednávky nebo faktury. Oba kontejnery k sobě patří, mají však odlišné úkoly. Toto oddělení umožňuje vytvářet nové verze struktury pro 1TP12, aniž by bylo nutné vyměnit celý datový fond. Kromě toho lze měnit správu dat, zálohování a provozní modely, aniž by bylo nutné aplikaci kompletně přepracovat. - Jaké výhody přináší oddělení struktury a dat?
Díky tomu lze aktualizace, zálohování a migrace provádět mnohem kontrolovaněji. Nový SSC lze zveřejnit, zatímco SSD s daty zákazníků zůstává zachován. Nezbytné strukturální změny se provádějí prostřednictvím definovaných migrací dat. SSC lze navíc analyzovat nebo předat jinému vývojáři bez důvěrných obchodních údajů. Usnadňuje se také přechod z IndexedDB na SQLite, PostgreSQL nebo do cloudu, protože není nutné znovu vytvářet rozvržení a funkční logiku. - Lze toto řešení provozovat lokálně, na serveru i v cloudu?
V zásadě ano. Řešení SchallOS lze provozovat lokálně v prohlížeči, jako aplikaci pro Windows nebo macOS, s SQLite, na serveru PostgreSQL nebo jako SaaS v SchallOS Cloud. Funkční použití zůstává přitom stejné. Různé provozní režimy však kladou vlastní požadavky na provoz s více uživateli, zálohování, výkon a správu. Přechod se proto provádí kontrolovaně prostřednictvím přenosu dat a ověření. Architektura SSC/SSD zabraňuje tomu, aby bylo nutné pro každý cíl spravovat zcela nový projekt. - Budu i po úspěšné migraci nadále potřebovat FileMaker nebo server FileMaker?
Ne. Po dokončení migrace bude aplikace spouštěna prostřednictvím SchallOS Runtime. Ani pro provoz v prohlížeči není zapotřebí ani server FileMaker, ani WebDirect. Původní systém FileMaker lze ponechat jako referenci nebo archiv, není však podmínkou pro produkční provoz. Rozvržení, vzorce, funkce, přístup k datům, aktualizace a nasazení přebírá SchallOS. Tím pádem odpadají i dosavadní závislosti migrované aplikace na běhovém prostředí FileMaker. - Jak je umělá inteligence integrována do systému SchallOS?
Umělá inteligence je k dispozici přímo v editoru vzorců, v uživatelských funkcích, kontejneru funkcí a v dokumentační vrstvě. Zná nejen aktuální dotaz, ale také příslušná pole, tabulky, popisy a závislosti. U migrovaných řešení může navíc jako podkladové znalosti sloužit původní skript FileMaker. Umělá inteligence dokáže vysvětlovat vzorce, generovat kód, analyzovat chyby a formulovat dokumentaci. Modely by měly zůstat zásadně zaměnitelné, aby bylo možné zohlednit kvalitu, náklady a ochranu osobních údajů. - Opravdu umělá inteligence programuje kód funkčních kontejnerů?
Ano. Vývojář popíše úkol, parametry, očekávaný výsledek a povolené funkce. Na tomto základě umělá inteligence vygeneruje spustitelný kód. Ten zůstává viditelný, ověřitelný a lze jej verzovat. Vývojář může požadovat změny, provádět testy a porovnávat či obnovovat předchozí verze. Umělá inteligence tak přebírá velkou část programátorské práce, nikoli však odbornou odpovědnost. Zejména u procesů kritických pro chod podniku je třeba i nadále pečlivě kontrolovat požadavky, oprávnění a možné vedlejší účinky. - Jaké možnosti nabízí editor vzorců?
Editor vzorců podporuje typické matematické, logické a textové výpočty, jakož i výpočty data a času. Vzorce a vlastní funkce jsou vyhodnocovány v reálném čase a lze je okamžitě otestovat. Počáteční rozsah příkazů je menší než dlouhodobě rozšiřovaná sada funkcí systému FileMaker. Prostředí pro práci s vzorci je však rozšiřitelné. Chybějící funkce lze doplnit nebo nahradit vlastními uživatelskými funkcemi. I v tomto případě může integrovaná umělá inteligence převést stávající vzorce FileMaker nebo vyvinout nové výpočty. - Co SchallOS automaticky zaznamenává?
Na strukturální úrovni se zaznamenávají změny v tabulkách, polích, rozvrženích, vzorcích a kontejnery funkcí. Na datové úrovni lze protokolovat změny záznamů, změny stavu, schválení, importy a další oborové události. K tomu se přidávají provozní události, jako jsou nasazení, aktualizace a zálohy. Související vývojové práce lze sdružit do změnových relací a později přiřadit k určité verzi. Tím vzniká přehledná historie aplikace, nikoli pouze sbírka dodatečně sepsaných poznámek. - Může SchallOS na jejich základě vytvářet zprávy o zákaznících a výkonech?
Ano. Integrovaná umělá inteligence dokáže ze zaznamenaných událostí generovat technickou dokumentaci, zprávy pro zákazníky, poznámky k vydání nebo přehledy výkonů. Přitom lze několik technických změn shrnout do srozumitelného popisu obchodního přínosu. Základní události zůstávají i nadále k nahlédnutí, takže vývojář může znění zkontrolovat. Ne každá změna je automaticky fakturovatelná. Výběr, vyhodnocení a schválení konečného protokolu o výkonu proto zůstávají na vývojáři. - Jak funguje proces aktualizací?
Změny se nejprve shromažďují v rámci tzv. „Change Sessions“ a následně se sdružují do jedné verze (release). Jedna verze může obsahovat nový SSC, nezbytné migrace SSD, předpoklady, podpisy, kontroly a informace o vrácení změn. SchallOS Control zkontroluje cílovou instanci, vytvoří zálohu a poté provede aktualizaci. Po instalaci se zkontroluje, zda struktura, data a důležité funkce odpovídají očekávanému stavu. Stejný základní postup se používá jak pro samotný systém SchallOS, tak pro zákaznická řešení vyvinutá na jeho základě. - V čem se liší Runtime, Control a Cloud?
SchallOS Runtime spouští publikované aplikace a poskytuje rozvržení, vzorce a kontejnery funkcí. SchallOS Control spravuje instance, databázové adaptéry, profily běhového prostředí, aktualizace a technické kontroly. SchallOS Cloud nabízí běhové prostředí a správu dat jako centrálně provozovanou službu SaaS. SchallOS Studio zůstává samotným vývojovým prostředím. Všechny oblasti využívají stejné základní struktury SSC a SSD, avšak v rámci životního cyklu aplikace plní jasně oddělené úkoly. - Jak jsou chráněna práva, instalace a citlivá data?
Uživatelská oprávnění určují, jaké odborné úkony smí daná osoba v rámci řešení provádět. Profily běhu (Runtime) a schopností (Capability) navíc definují, jaké technické funkce daná instalace vůbec obsahuje. Balíčky SSC a SSD lze chránit identifikátory, kontrolními součty a podpisy. Omezit lze také kontext umělé inteligence, takže nedochází k automatickému zpracování všech zákaznických dat. Pro obzvláště citlivá prostředí lze použít vlastní servery nebo v budoucnu také lokální modely umělé inteligence. Konkrétní bezpečnostní konfigurace se odvíjí od daného případu použití. - Kdy by měl být SchallOS k dispozici?
Veřejné spuštění je plánováno na podzim 2026. Zpočátku se pozornost zaměří na Studio a Runtime, oddělení SSC a SSD, migraci stávajících struktur FileMaker, vzorce, vlastní funkce, funkční kontejnery naprogramované pomocí AI, dokumentaci, protokoly událostí, nasazení a aktualizace. Také SchallOS Control převezme klíčovou roli při správě instalací. Ne každá dlouhodobě plánovaná funkce musí být již při spuštění plně vyvinuta. Rozhodující je v první řadě spolehlivé jádro pro první produkční aplikace.
