Od FileMaker do chmury: jak SchallOS łączy oprogramowanie biznesowe ze sztuczną inteligencją, środowiskiem uruchomieniowym i aktualizacjami

Podczas tworzenia aplikacji biznesowej na początku skupia się na zadaniach widocznych na pierwszy rzut oka. Tworzy się tabele, definiuje relacje, projektuje formularze wprowadzania danych i automatyzuje procesy operacyjne. Gdy tylko pierwsi użytkownicy mogą zacząć korzystać z rozwiązania, wydaje się, że znaczna część projektu została zakończona. Jednak w praktyce rozpoczyna się wtedy faza, która w dłuższej perspektywie jest bardziej wymagająca. Aplikacja biznesowa wymaga konserwacji, rozbudowy i dostosowywania do nowych wymagań. Zmiany muszą być dokumentowane, nowe wersje wdrażane, a istniejące dane bezpiecznie przenoszone. Do tego dochodzą różne uprawnienia użytkowników, tworzenie kopii zapasowych danych, analiza błędów oraz kwestia wyboru, czy rozwiązanie ma być uruchamiane lokalnie, na własnym serwerze, czy w chmurze.

Wiele platform programistycznych skupia się przede wszystkim na tworzeniu samej aplikacji. W późniejszym etapie dodaje się dodatkowe narzędzia i indywidualne procedury dotyczące aktualizacji, dokumentacji, wdrażania i eksploatacji. Z czasem powstaje środowisko techniczne złożone z wielu oddzielnych elementów, których spójność można utrzymać jedynie przy znacznym nakładzie pracy. Dlatego SchallOS stosuje bardziej kompleksowe podejście. Platforma ma towarzyszyć aplikacji biznesowej nie tylko na etapie jej powstawania, ale przez cały jej cykl życia: od rozwoju, przez dokumentację i wdrożenie, aż po aktualizacje i długoterminową eksploatację.

Kwestie społeczne teraźniejszości

Traktat Dwa Plus Cztery, NATO i Bundeswehra: co obowiązuje do dziś?

Traktat Dwa Plus Cztery, NATO i Bundeswehra: co obowiązuje do dziś?

Przydatność do wojny, pobór i odmowa: co robić w nagłych wypadkach?

Przydatność do wojny, pobór i odmowa: co robić w nagłych wypadkach?

Szczelinowanie, LNG i polityka energetyczna: trzeźwa analiza ryzyka, możliwości i rzeczywistości

Szczelinowanie, LNG i polityka energetyczna: trzeźwa analiza ryzyka, możliwości i rzeczywistości

Teoria gier wyjaśnia 25 lat geopolityki: jak Europa straciła swoją strategiczną rolę

Teoria gier wyjaśnia 25 lat geopolityki: jak Europa straciła swoją strategiczną rolę

Najnowsze wiadomości dotyczące SchallOS Studio

12.08.2026: Prace nad systemem SchallOS postępują. W międzyczasie Warstwa sztucznej inteligencji i wiedzy Platforma została w znacznej mierze ukończona i głęboko zintegrowana ze środowiskiem programistycznym. Dzięki temu SchallOS dysponuje samouczącą się warstwą wiedzy, która przyswaja doświadczenia zdobyte podczas praktycznego programowania i z czasem potrafi dostosować się do stylu programowania oraz preferowanych rozwiązań danego programisty.

Dzięki otwartemu systemowi adapterów można podłączyć dowolne lokalne i oparte na chmurze modele sztucznej inteligencji zintegrować. Dla danego dostawcy lub modelu można zapisać nawet kilka kont dostępu lub kluczy API. Kilka modeli można wykorzystywać równolegle i dobierać je do różnych zadań na podstawie ich możliwości, szybkości działania oraz dotychczasowych wyników. Wybór modelu odbywa się automatycznie za pomocą zintegrowanego narzędzia Composer – programista nie musi podczas tworzenia oprogramowania martwić się o to, który model jest odpowiedni do danego zadania. Znane i sprawdzone rozwiązania można ponownie wykorzystać z warstwy wiedzy, dzięki czemu nie każde zadanie musi być od nowa w całości przetwarzane przez model sztucznej inteligencji.

Dostępne bezpośrednio w studiu SchallOS wyspecjalizowane agenty oparte na sztucznej inteligencji do różnych zadań związanych z rozwojem. Należą do nich: Agent Formuły do obliczeń i wzorów, jeden Agent kontenerów funkcyjnych do programowania kontenerów funkcji oraz Agent ds. układu graficznego do pracy nad interfejsami użytkownika. Kontenery funkcji można ponadto edytować bezpośrednio za pomocą ich obiektów układu oraz programować za pomocą sztucznej inteligencji. Nadrzędny Agent systemowy może koordynować pracę wyspecjalizowanych agentów, na przykład w przypadku, gdy mają zostać opracowane zupełnie nowe moduły lub bardziej rozbudowane funkcje.

Warstwę sztucznej inteligencji uzupełnia Studio adapterów w SchallOS Control. Dzięki temu programiści mogą tworzyć własne adaptery sieciowe i danych, na przykład w celu podłączenia zewnętrznych systemów ERP, baz danych lub platform korporacyjnych, takich jak SAP i Oracle. Niezbędna do tego wiedza, profile modeli oraz doświadczenie związane z konkretnymi rozwiązaniami są zarządzane w ramach architektury wiedzy z podziałem na wersje. W ten sposób SchallOS coraz bardziej ewoluuje z klasycznego środowiska programistycznego w kierunku platformy, na której programiści, warstwa wiedzy i różne modele sztucznej inteligencji wspólnie pracują nad rozwiązaniem programowym.

Warstwa wiedzy również dla użytkowników oraz wiedza firmowa

Dziedzina wiedzy nie ogranicza się jednak wyłącznie do tworzenia oprogramowania. Dotyczy ona również Poziom rozwiązania Aplikacje mogą posiadać własne agenty AI, które wspierają użytkownika w codziennych procesach roboczych – na przykład podczas tworzenia faktur, analizowania danych lub wykonywania innych powtarzających się zadań w ramach danego rozwiązania programowego. Rozwiązanie może przy tym gromadzić własną wiedzę i udostępniać ją swoim agentom.

W przyszłości obszar ten ma zostać znacznie rozszerzony. Planuje się między innymi pozyskiwanie wiedzy z różnych źródeł zewnętrznych, na przykład z systemów poczty elektronicznej, dokumentów i danych przedsiębiorstwa, a także poprzez standardowe formaty wymiany danych, takie jak Open Knowledge Format (OKF) firmy Google oraz grafy wiedzy, np. Neo4j. W ten sposób wiedza rozwiązania SchallOS ma w perspektywie długoterminowej pochodzić nie tylko z jego bazy danych, ale również z różnych źródeł informacji w przedsiębiorstwie.

Od migracji z FileMaker do własnej platformy

Początkowym punktem wyjścia dla projektu SchallOS była migracja istniejących rozwiązań opartych na platformie FileMaker. Przez dziesięciolecia platforma FileMaker sprawdziła się jako wydajne środowisko dla indywidualnych aplikacji bazodanowych. Zwłaszcza ścisłe powiązanie modelu danych, układu i logiki programu umożliwia szybkie i praktyczne tworzenie oprogramowania.

W pełni rozwinięte rozwiązanie FileMaker składa się jednak z znacznie więcej elementów niż tylko tabel i widocznych masek. Zawiera obliczenia, skrypty, uprawnienia użytkowników, układy wydruku, interfejsy oraz liczne specjalne przypadki operacyjne. Odpowiednia platforma następcza musi uwzględniać te powiązania, a następnie być w stanie samodzielnie je kontynuować.

W ramach tego zadania SchallOS stopniowo przekształciło się w samodzielną platformę. Istniejące rozwiązania FileMaker powinny dać się przenieść, a jednocześnie w SchallOS można od razu tworzyć nowe aplikacje. Po zakończeniu pełnej migracji FileMaker nie będzie już potrzebne do pracy produkcyjnej.

Rozwój, środowisko uruchomieniowe i eksploatacja pozostają oddzielnymi procesami

Platforma rozwojowa SchallOS składa się z kilku obszarów o jasno określonych zadaniach.

• SchallOS Studio to środowisko programistyczne. To właśnie tam powstają struktury danych, układy, formuły, funkcje, języki i wersje. Do Studio należy również asystent migracji dla istniejących rozwiązań FileMaker.
• Środowisko uruchomieniowe SchallOS uruchamia opublikowane aplikacje. Zapewnia interfejs użytkownika oraz niezbędną logikę programu, nie udostępniając przy tym automatycznie wszystkich narzędzi programistycznych.
• SchallOS Control zarządza celami wdrożenia, połączeniami z bazami danych, profilami środowiska uruchomieniowego, aktualizacjami i kontrolami technicznymi.
• SchallOS Cloud udostępnia aplikacje w formie scentralizowanej usługi internetowej. Nie ma przy tym na celu stworzenia odrębnej platformy chmurowej. Instalacje lokalne, oparte na serwerach oraz w chmurze wykorzystują tę samą podstawową architekturę rozwiązania.

Takie rozdzielenie zapobiega niekontrolowanemu mieszaniu się procesów rozwoju, wdrażania i administracji. Jednocześnie wszystkie obszary pozostają ze sobą technicznie zharmonizowane.

Rozwiązanie dla różnych modeli operacyjnych

Aplikacja biznesowa może zaczynać się na małą skalę, a później się rozwijać. Na początku wystarczy być może pojedyncze stanowisko lokalne. Później dołączą kolejni pracownicy, centralny serwer lub kilka lokalizacji. Dlatego SchallOS ma zapewniać to samo podstawowe rozwiązanie dla różnych form działania: lokalnie w przeglądarce, jako aplikacja dla systemów Windows lub macOS, z bazą danych SQLite lub PostgreSQL, a także jako rozwiązanie SaaS w chmurze.

Nie każda forma działania charakteryzuje się takimi samymi właściwościami technicznymi. Lokalna baza danych stawia inne wymagania niż scentralizowany system obsługiwany przez wielu użytkowników. Kluczowe jest jednak to, że układy, funkcje i model danych nie muszą być opracowywane od podstaw dla każdego konkretnego zastosowania.

Cykl życia stanowi część architektury

W SchallOS dokumentacja, logi zdarzeń i aktualizacje nie są dodawane do gotowej aplikacji dopiero po jej ukończeniu. Stanowią one część podstawowej architektury. Struktura i dane produkcyjne są zarządzane oddzielnie. Zmiany wprowadzane w trakcie rozwoju można rejestrować i grupować w wersje. Aktualizacje można weryfikować, wdrażać, a w razie problemów – w kontrolowany sposób przywracać poprzedni stan. Zintegrowana sztuczna inteligencja wspiera nie tylko tworzenie formuł i funkcji, ale także dokumentację oraz komunikację z klientami.

W ten sposób SchallOS łączy obszary, które w klasycznych projektach są często traktowane oddzielnie. Opracowanie aplikacji nie stanowi już zakończenia procesu technicznego, lecz pierwszy etap długoterminowo zaplanowanego cyklu życia.

SSC i SSD jako przenośne kontenery strukturalne i kontenery danych

Wiele aplikacji bazodanowych przechowuje strukturę, interfejs użytkownika, logikę programu oraz dane operacyjne w ściśle powiązanej całości. Na początku jest to wygodne, ale utrudnia późniejsze aktualizacje, migracje i stosowanie różnych trybów pracy. Gdy tylko pojawia się większa liczba klientów, większe zbiory danych lub indywidualne rozszerzenia, wymiana całego pliku aplikacji szybko staje się problematyczna.

Dlatego też SchallOS zasadniczo oddziela opis rozwiązania od danych biznesowych. Aplikacja składa się zasadniczo z dwóch powiązanych ze sobą kontenerów: SSC, przeznaczonego dla struktury, oraz SSD, przeznaczonego dla danych operacyjnych.

Oba kontenery razem tworzą kompletne rozwiązanie, ale pełnią różne funkcje. Kontener SSC opisuje strukturę i działanie aplikacji. Kontener SSD zawiera treści powstające podczas korzystania z aplikacji.

SSC opisuje sposób stosowania

Plik SSC stanowi przenośny kontener strukturalny rozwiązania SchallOS. Zawiera on między innymi:

• Definicje tabel i pól
• Relacje
• Układy i obiekty układu
• Wzory i własne funkcje
• Kontener funkcyjny
• Wyzwalacze i nawigacja
• Informacje dotyczące języków i tłumaczeń
• Dokumentacja
• Informacje o wersji i wydaniu

SSC nie zawiera zatem samych danych dotyczących klientów, artykułów, zamówień ani faktur. Określa on, jakie struktury danych istnieją, w jaki sposób są one przedstawiane oraz jakie funkcje z nimi współpracują. W tym kontenerze znajduje się również znaczenie semantyczne rozwiązania. Pole może posiadać, oprócz nazwy technicznej, opis merytoryczny, tłumaczenia, reguły walidacji oraz wskazówki dla warstwy sztucznej inteligencji. Dzięki temu struktura staje się nie tylko czytelna dla maszyn, ale także bardziej zrozumiała dla programistów, w dokumentacji oraz podczas migracji.

W ten sposób SSC stanowi przenośny model aplikacji, który można dalej rozwijać i publikować niezależnie od konkretnego zbioru danych.

Dysk SSD zawiera dane operacyjne

Plik SSD stanowi kontener danych rozwiązania. Zawiera on rekordy danych powstające w ramach codziennej działalności, na przykład dane klientów, oferty, zlecenia, faktury, ruchy magazynowe czy terminy. Ponadto można w nim przechowywać historie biznesowe i zdarzenia związane z danymi. Obejmują one między innymi zmiany statusu, zatwierdzenia, importy lub modyfikacje szczególnie istotnych pól. Termin „SSD” nie odnosi się tutaj do fizycznego nośnika danych, lecz do logicznej warstwy danych aplikacji. Sposób technicznego przechowywania tych danych zależy od wybranego wdrożenia i adaptera bazy danych.

W przypadku lokalnej aplikacji jednoosobowej można wykorzystać IndexedDB. Aplikacja desktopowa może korzystać z SQLite, natomiast większe aplikacje wieloużytkownikoweinstall wykorzystują PostgreSQL. We wszystkich przypadkach dysk SSD pozostaje merytorycznym nośnikiem danych, nawet jeśli sposób ich technicznego przechowywania się różni.

Dwa kontenery muszą bez wątpienia stanowić jedną całość

Rozdzielenie struktury od danych nie może prowadzić do dowolnego łączenia ze sobą kontenerów. SchallOS musi mieć możliwość sprawdzenia, czy dany SSC i SSD rzeczywiście należą do tego samego rozwiązania oraz czy ich wersje są ze sobą zgodne. W tym celu można wykorzystać identyfikatory rozwiązania, identyfikatory kontenerów, wersje struktur, sumy kontrolne i podpisy. Dzięki temu przed uruchomieniem lub aktualizacją można ustalić, czy kombinacja jest prawidłowa i czy przeprowadzono już niezbędną migrację danych.

Kontrola ta zapobiega na przykład przypadkowemu otwarciu kontenera strukturalnego innej aplikacji zawierającego dane produkcyjne. Chroni ona również przed aktywacją nowej wersji SSC, mimo że SSD nie został jeszcze przygotowany do obsługi wymaganej struktury danych.

Przenoszalność między różnymi formami działalności

Rozdzielenie SSC i SSD stanowi podstawę do uruchamiania aplikacji w różnych środowiskach. Nie ma potrzeby ponownego opracowywania układów, formuł i logiki funkcji dla każdego adaptera bazy danych.

Rozwiązaniem może być rozpoczęcie od lokalnej bazy danych IndexedDB, a następnie przeniesienie jej do SQLite i, w miarę wzrostu liczby użytkowników, przejście na PostgreSQL. Możliwe jest również przejście do środowiska chmurowego.

Taka zmiana pozostaje kontrolowanym procesem technicznym. Różne bazy danych mają swoje własne możliwości i ograniczenia. Dlatego dane nie są po prostu przenoszone do innego systemu za pomocą jednego przycisku. Należy wyraźnie przeprowadzić operacje przeniesienia, sprawdzenia i, w razie potrzeby, cofnięcia zmian.

Architektura zapewnia jednak, że zmiana sposobu przechowywania danych nie wymaga automatycznie przebudowy całej aplikacji.

Aktualizacje bez wymiany danych klientów

Istotna zaleta tego rozdzielenia ujawnia się w przypadku nowych wersji. Zmiany często dotyczą układów, formuł, funkcji lub modelu danych. Istniejące dane biznesowe powinny przy tym pozostać niezmienione.

Dlatego programista może opublikować nową wersję SSC, podczas gdy SSD klienta pozostaje w miejscu instalacji. Jeśli potrzebne są nowe pola lub tabele, są one dodawane w ramach zdefiniowanych etapów migracji. Przed aktualizacją można wykonać kopię zapasową aktualnego stanu. Następnie sprawdzana jest struktura, migracja danych oraz poprawność działania. Dopiero gdy SSC i SSD ponownie osiągną spójny stan, aktualizacja uznaje się za zakończoną.

Ta możliwość aktualizacji nie jest przeznaczona wyłącznie dla samego systemu SchallOS. Jest ona również dostępna dla rozwiązań klienckich opracowanych w oparciu o system SchallOS.

Warianty dostosowane do potrzeb klienta pozostają łatwe do prześledzenia

Indywidualne oprogramowanie biznesowe często ewoluuje w różny sposób u poszczególnych klientów. Jeden klient potrzebuje własnych pól, inny – dodatkowych układów lub specjalnego interfejsu. Bez jasnej struktury szybko powstają w ten sposób różniące się od siebie kompletne kopie, które trudno jest wspólnie utrzymywać. Natomiast w SSC ogólne elementy produktu oraz rozszerzenia dostosowane do potrzeb klienta mogą być w przejrzysty sposób wersjonowane i dokumentowane.

Architektura nie podejmuje za programistę decyzji, które dostosowanie powinno zostać włączone do ogólnego produktu. Zapewnia jednak, że pochodzenie i zależności danej zmiany pozostają widoczne.

W połączeniu z protokołami rozwoju i wydaniami pozwala to podczas późniejszych aktualizacji łatwiej rozpoznać, które elementy należy zastąpić, uzupełnić lub zachować.

Wielojęzyczność stanowi część struktury przenośnej

Również warstwa językowa jest zintegrowana z systemem SSC. Nazwy nie są zapisywane wyłącznie w postaci stałych wartości w poszczególnych obiektach układu, lecz mogą odwoływać się do wpisów semantycznych zawierających wiele wersji językowych.

Dzięki temu pole takie jak „Numer faktury“ może być wyświetlane w różnych językach bez konieczności tworzenia zupełnie nowego układu dla każdego języka. Przeniesione rozwiązanie FileMaker może zostać automatycznie dostosowane do wielu języków i przetłumaczone w trakcie migracji.

Automatyczne tłumaczenie nie zastępuje weryfikacji merytorycznej. Szczególnie terminy prawnicze i branżowe wymagają sprawdzenia. Architektura systemu gwarantuje jednak, że wielojęzyczność jest od samego początku częścią rozwiązania i nie trzeba jej później mozolnie wdrażać w każdym formularzu.

Podstawa długoterminowej łatwości konserwacji

SSC i SSD na pierwszy rzut oka wydają się prostym podziałem na aplikację i dane. W rzeczywistości stanowią one jednak podstawę przenośności, aktualizacji, różnych adapterów baz danych, oddzielnych kopii zapasowych oraz różnych modeli operacyjnych.

SSC opisuje, czym jest rozwiązanie i jak działa. SSD zawiera informacje, które powstają w trakcie korzystania z niego i które muszą zostać trwale zachowane dla danej firmy.

Dzięki temu wyraźnemu rozdzieleniu aplikacja może się dalej rozwijać bez konieczności wymiany całego zbioru danych przy każdej nowej wersji. Jednocześnie struktura przechowywania danych technicznych może się rozszerzać lub zmieniać bez konieczności całkowitej przebudowy układów i logiki biznesowej.

SchallOS Studio jako zintegrowane środowisko programistyczne

SchallOS Studio to obszar platformy, w którym powstają nowe aplikacje biznesowe oraz gdzie przeprowadza się migrację lub dalszy rozwój istniejących rozwiązań FileMaker. W tym obszarze zarządza się tabelami, polami, relacjami, układami, formułami, funkcjami, językami i wersjami w ramach jednego wspólnego środowiska.

Dla programistów korzystających z FileMaker sposób pracy powinien wydawać się znajomy. Zmiany nie są wprowadzane wyłącznie w abstrakcyjnych plikach kodu źródłowego, lecz pozostają powiązane z widocznymi elementami aplikacji. Programista może edytować układ, wybrać pole, zmienić jego właściwości i natychmiast sprawdzić, jak ta zmiana wpływa na aplikację.

SchallOS nie próbuje jednak w pełni odtworzyć FileMaker. Przejęto przede wszystkim sprawdzone podstawowe założenia: szybki rozwój, natychmiastową informację zwrotną oraz ścisły związek między modelem danych, interfejsem użytkownika a logiką biznesową. Natomiast podstawy techniczne zostały zreorganizowane i ukierunkowane na struktury przenośne, programowanie oparte na sztucznej inteligencji, dokumentację oraz kontrolowane wydania.

Układy, obiekty i właściwości

Istotnym elementem programu SchallOS Studio jest tryb układu. To właśnie w nim tworzone są formularze, listy, okna dialogowe, obszary nawigacyjne oraz inne elementy interfejsu użytkownika danego rozwiązania.

Do potencjalnych obiektów układu należą między innymi pola, teksty, przyciski, obiekty listowe, obszary zakładek, okienka wyskakujące, kontenery i elementy nawigacyjne. Obiekty te można zaznaczać, pozycjonować i konfigurować za pomocą inspektora.

Obiekt układu zawiera nie tylko informacje dotyczące rozmiaru, położenia i wyglądu. Może być dodatkowo powiązany ze źródłami danych, wyzwalaczami, formułami, funkcjami i oznaczeniami semantycznymi. Obiekt pola odnosi się na przykład do pola w modelu danych, może otrzymać etykietę zależną od języka oraz wyzwalać określone funkcje przy wejściu lub wyjściu.

Ponieważ każdy obiekt stanowi część SSC, zmiany układu można wersjonować, dokumentować, a następnie celowo wdrażać za pomocą aktualizacji. Interfejs użytkownika nie pozostaje zatem odizolowaną warstwą graficzną, lecz stanowi ustrukturyzowaną część całej aplikacji.

Model danych i opisy semantyczne

Tabele, pola i relacje są również tworzone i edytowane w programie SchallOS Studio. Można tam w całości tworzyć nowe aplikacje. W przypadku migracji FileMaker asystent migracji przejmuje istniejące struktury w miarę możliwości, a następnie udostępnia je do dalszej edycji.

W systemie SchallOS pole to nie tylko nazwa techniczna i typ danych. Może ono dodatkowo zawierać opis merytoryczny, reguły walidacji, wartości domyślne, tłumaczenia oraz uwagi dokumentacyjne.

Informacje te służą kilku celom. Ułatwiają innym programistom zrozumienie rozwiązania, wspomagają automatyczne tworzenie dokumentacji oraz dostarczają zintegrowanej sztucznej inteligencji lepszego kontekstu. Zamiast jedynie rozpoznawać, że pole nosi nazwę „Status“, platforma może na przykład wiedzieć, czy chodzi o status zlecenia, status płatności czy wewnętrzny status przetwarzania.

Można również opisać relacje między tabelami i udokumentować je w kontekście biznesowym. Dzięki temu mniej wiedzy pozostaje ukryte wyłącznie w głowie pierwotnego twórcy.

Wzory z obliczeniami w czasie rzeczywistym

SchallOS posiada własne środowisko do tworzenia wzorów. Wzory tworzy się w edytorze wzorów, a podczas edycji są one obliczane w czasie rzeczywistym. Dzięki temu zmiany wprowadzone w wyrażeniu można natychmiast sprawdzić przy użyciu odpowiednich wartości testowych lub aktualnego zestawu danych.

Język formuł obsługuje typowe obliczenia wymagane w aplikacjach biznesowych. Obejmują one operacje matematyczne, przetwarzanie tekstu, obliczenia dotyczące daty i czasu, warunki logiczne, odwołania do pól, zmienne oraz wyrażenia zagnieżdżone.

Zakres dostępnych poleceń jest początkowo mniejszy niż zbiór funkcji systemu FileMaker, który rozwijał się przez dziesięciolecia. System SchallOS nie musi bez zmian odtwarzać każdego historycznego polecenia z systemu FileMaker. Ważniejsze jest posiadanie jasno ustrukturyzowanego i rozszerzalnego środowiska formuł.

W razie potrzeby można później dodać dodatkowe polecenia, jeśli będą one wymagane do realizacji konkretnych rozwiązań lub migracji. W tym zakresie pomocna może być również wbudowana sztuczna inteligencja, która pozwala przenieść istniejące obliczenia lub opracować brakującą funkcję dostosowaną do architektury SchallOS.

Funkcje niestandardowe do obliczeń wielokrotnego użytku

Oprócz wbudowanych poleceń system SchallOS obsługuje funkcje niestandardowe. Przyjmują one parametry, wykonują zdefiniowane obliczenia i zwracają wynik. Dzięki temu można zarządzać powtarzającymi się regułami w jednym centralnym miejscu. Przykładami są obliczenia cen, ustalanie terminów, formatowanie, sprawdzanie zakresów numerów lub przetwarzanie zaimportowanych wartości.

Funkcje niestandardowe są również obliczane w czasie rzeczywistym i można je natychmiast przetestować w edytorze formuł. Jeśli funkcja zostanie później poprawiona lub rozszerzona, zmiany te będą miały wpływ na wszystkie formuły, w których jest ona wykorzystywana.

Ponadto można opisywać i dokumentować własne funkcje. Dzięki temu parametry, wartość zwracana, przykłady i znane przypadki błędów pozostają przejrzyste. Zbiór funkcji danego rozwiązania przekształca się w bibliotekę, z której można ponownie korzystać, zamiast składać się z licznych skopiowanych pojedynczych obliczeń.

Kontenery funkcyjne do bardziej złożonych procesów

W SchallOS bardziej złożone procesy biznesowe są organizowane za pomocą kontenerów funkcyjnych. Można za ich pomocą na przykład tworzyć rekordy danych, sprawdzać wartości, sterować oknami dialogowymi, generować dokumenty lub komunikować się z interfejsami zewnętrznymi. Kontener funkcji zawiera nie tylko kod wykonywalny. Obejmuje on również opis merytoryczny, parametry wejściowe, wartości zwracane, zależności, dozwolone uprawnienia oraz operacje wyraźnie wykluczone.

Kilka obiektów układu może korzystać z tego samego kontenera funkcji. Dzięki temu nie trzeba za każdym razem od nowa tworzyć funkcji służącej do wystawiania faktury dla każdego przycisku lub każdego układu.

W przypadku rozwiązań poddanych migracji istniejące skrypty FileMaker mogą pozostać w tle jako warstwa edukacyjna i referencyjna. Pomagają one zrozumieć pierwotny zamysł i dotychczasowy przebieg procesu. Nowy kod wykonywalny jest jednak generowany zgodnie z architekturą SchallOS.

Migracja i tworzenie nowych aplikacji w tym samym środowisku

SchallOS Studio nie jest przeznaczone wyłącznie dla istniejących rozwiązań FileMaker. Nowe aplikacje mogą powstawać w całości w ramach tej platformy.

Podczas migracji kreator najpierw przejmuje istniejące tabele, pola, relacje, układy i inne rozpoznawalne elementy. Następnie programiści mogą sprawdzić zaimportowaną strukturę, uporządkować ją i stopniowo przenieść do nowej architektury funkcjonalnej.

Nie ma to na celu stworzenia niezmienionej kopii wszystkich wcześniejszych specyficznych elementów. Wykształcone historycznie obejścia można poddać weryfikacji i zastąpić je bardziej przejrzystymi strukturami. Jednocześnie zachowana zostanie wiedza merytoryczna zawarta w dotychczasowym rozwiązaniu.

Nowe i przeniesione aplikacje korzystają następnie z tych samych narzędzi, kontenerów i kanałów publikacji.

Zmiany stają się kontrolowanymi wydaniami

Zmiana wprowadzona w studiu nie przekłada się automatycznie na aktualizację produkcyjną. W trakcie prac rozwojowych mogą występować niedokończone układy, tymczasowe formuły lub funkcje, które nie zostały jeszcze przetestowane.

Powiązane zmiany można zatem rejestrować w sesjach zmian (Change Sessions), a następnie przypisywać je do danego wydania. Dopiero po sprawdzeniu i zatwierdzeniu powstaje opublikowana wersja SSC.

Oprócz nowej struktury wydanie może również obejmować niezbędną migrację danych, informacje o wersji, zależności, etapy testowania oraz dokumentację. W ten sposób sam proces rozwoju pozostaje wyraźnie oddzielony od wdrażania na produkcyjnych instancjach środowiska uruchomieniowego.

SchallOS Studio stanowi zatem nie tylko miejsce, w którym projektuje się i programuje aplikację. Łączy ono tworzenie interfejsu użytkownika, model danych, formuły, funkcje, dokumentację oraz publikację w jednym wspólnym środowisku.

Zachowana zostaje bliska więź między programistą a widoczną aplikacją. Jednocześnie powstaje podstawa techniczna, dzięki której rozwiązania można dalej rozwijać w sposób przenośny, przejrzysty i umożliwiający długoterminową konserwację.

Sztuczna inteligencja tam, gdzie powstają wzory i funkcje

W wielu środowiskach programistycznych sztuczna inteligencja jest dotychczas udostępniana głównie za pośrednictwem dodatkowego okna czatu. Programista opisuje problem, kopiuje kod źródłowy lub formuły do okna czatu, a następnie przenosi wynik z powrotem do projektu. W tym procesie modelowi językowemu często brakuje ważnych informacji dotyczących tabel, pól, relacji oraz merytorycznego znaczenia aplikacji.

W związku z tym SchallOS bezpośrednio integruje sztuczną inteligencję z narzędziami programistycznymi. Jest ona dostępna tam, gdzie edytuje się wzory, funkcje niestandardowe i kontenery funkcji. Dzięki temu otrzymuje nie tylko pojedyncze pytanie, ale także aktualny kontekst rozwiązania.

W edytorze formuł sztuczna inteligencja zna na przykład edytowane wyrażenie, dostępne pola oraz oczekiwany typ wyniku. W ramach kontenera funkcji ma ona dodatkowo dostęp do jego opisu, parametrów, możliwości i zależności.

Dzięki temu sztuczna inteligencja nie staje się odrębnym programem pomocniczym, lecz integralną częścią samego środowiska programistycznego.

Pomoc w edytorze formuł

Formuły sterują wieloma procesami w aplikacji biznesowej. Obliczają ceny, sprawdzają warunki, określają terminy lub wpływają na wygląd obiektów układu. Zintegrowana sztuczna inteligencja może między innymi w edytorze formuł:

• wyjaśnić istniejącą formułę
• zbadanie ewentualnych błędów
• Uzupełnij warunki
• uproszczenie wyrażenia
• przenieść wzór FileMaker
• lub sporządzić nowe obliczenia na podstawie opisu technicznego.

Programista mógłby na przykład określić, że zlecenia o wartości netto przekraczającej określoną kwotę wymagają dodatkowego zatwierdzenia, o ile nie istnieje umowa ramowa. Sztuczna inteligencja może na tej podstawie wygenerować wzór, korzystając z pól dostępnych w rozwiązaniu. Wynik pozostaje widoczny jako zwykła formuła. Można go odczytać, zmodyfikować i obliczyć w czasie rzeczywistym. Sztuczna inteligencja nie tworzy zatem żadnego ukrytego procesu, którego działanie byłoby trudne do zrozumienia.

Jeśli brakuje jakiegoś potrzebnego polecenia, sztuczna inteligencja może również pomóc w stworzeniu odpowiedniej funkcji niestandardowej lub rozszerzenia środowiska formuł. Dzięki temu początkowo ograniczony zakres poleceń SchallOS można rozszerzać.

Funkcje niestandardowe oparte na wytycznych merytorycznych

Powtarzające się obliczenia można centralnie zarządzać jako funkcje niestandardowe. Sztuczna inteligencja może na podstawie opisu wygenerować funkcję z jednoznacznymi parametrami, wartością zwracaną i udokumentowanym zachowaniem.

Taka funkcja mogłaby na przykład obliczać terminy skonta, sprawdzać zakresy numerów lub ujednolicać zaimportowane wartości. Oprócz samego wydruku można również generować wartości testowe, przykłady oraz potencjalne przypadki błędów.

Ułatwia to nie tylko wstępne programowanie. W przypadku późniejszych zmian sztuczna inteligencja potrafi rozpoznać, jakie znaczenie ma dana funkcja i w jakich miejscach jest ona wykorzystywana.

W ten sposób anonimowe obliczenia stają się udokumentowanym i nadającym się do ponownego wykorzystania elementem rozwiązania.

Kontener funkcji jako opisana logika programu

Bardziej złożone procesy są w SchallOS organizowane za pomocą kontenerów funkcyjnych. Kontener funkcyjny może na przykład tworzyć rekordy danych, sprawdzać dane wejściowe, sterować oknami dialogowymi, generować dokumenty lub wywoływać interfejsy zewnętrzne. Podstawą jest ustrukturyzowany opis. Może on określać:

• jaką funkcję pełni ta funkcja
• jakie parametry są przekazywane
• jakiego wyniku się oczekuje
• do których tabel i pól można uzyskać dostęp
• jakie inne funkcje są wykorzystywane
• oraz jakie czynności są wyraźnie wykluczone.

Na podstawie tych wytycznych sztuczna inteligencja generuje kod wykonywalny kontenera funkcji. Dzięki temu programista nie musi już składać sekwencji operacji wyłącznie z wielu pojedynczych kroków skryptu. Jego zadanie polega w większym stopniu na dokładnym opisaniu pożądanej funkcji, określeniu jej ograniczeń oraz przeprowadzeniu końcowej weryfikacji.

Wygenerowany kod pozostaje jednak widoczny. Można go przeczytać, przetestować, zmodyfikować oraz porównać różne wersje. Możliwe jest również zachowanie wcześniejszych wersji i przywrócenie ich w razie potrzeby. Sztuczna inteligencja przejmuje zatem zadania związane z programowaniem, ale nie ponosi odpowiedzialności merytorycznej.

Skrypty FileMaker jako warstwa edukacyjna

W przypadku przeniesionych rozwiązań FileMaker istniejące skrypty często zawierają znaczną część logiki biznesowej, która powstała na przestrzeni lat. Pokazują one, które pola zostały zmienione, jakie warunki zostały sprawdzone oraz jakie dalsze procesy zostały wywołane.

Skrypty te nie są na stałe przenoszone do SchallOS jako warstwa wykonawcza. Spowodowałoby to jedynie przeniesienie wielu wcześniejszych zależności technicznych i obejść do nowego systemu. Zamiast tego oryginalny skrypt FileMaker może pozostać w tle odpowiedniego kontenera funkcji. Służy on sztucznej inteligencji jako warstwa uczenia się, odniesienia i zrozumienia.

Sztuczna inteligencja może na tej podstawie wywnioskować merytoryczny cel dotychczasowego przebiegu procesu. Następnie programuje nowy kod dostosowany do architektury SchallOS. Historyczne rozwiązania, takie jak częste zmiany układu, pola globalne czy skrypty pomocnicze zależne od kontekstu, nie muszą być przejmowane bez zmian. Są one kontynuowane tylko wtedy, gdy są rzeczywiście niezbędne dla właściwego procesu biznesowego.

Pierwotny skrypt pozostaje jednak źródłem wiedzy. W razie późniejszych pytań można sprawdzić, w jaki sposób pierwotnie rozwiązano dany proces w rozwiązaniu FileMaker.

Umiejętności i ograniczenia są wyraźnie określone

Kontener funkcyjny nie powinien mieć dostępu do dowolnych obszarów aplikacji wyłącznie na podstawie ogólnego opisu. Dlatego też można wyraźnie określić dozwolone uprawnienia i wyłączenia.

Funkcja może na przykład mieć uprawnienia do odczytu i modyfikacji rekordów w określonej tabeli, nie mając jednocześnie możliwości wykonywania operacji usuwania ani wprowadzania zmian w konfiguracji systemu. Jeśli wygenerowany kod wykorzystuje nieautoryzowaną funkcję, SchallOS może to wykryć i zablokować jego wykonanie lub publikację.

Opis kontenera funkcji służy zatem nie tylko do celów dokumentacyjnych. Staje się on częścią modelu testowego i bezpieczeństwa. To ograniczenie jest szczególnie ważne w przypadku kodu generowanego przez sztuczną inteligencję. Model językowy otrzymuje jasno określony zakres działania, podczas gdy platforma sprawdza, czy wygenerowana funkcja mieści się w tych ramach.

Odpowiedni kontekst poprawia wyniki

Jakość funkcji wygenerowanej przez sztuczną inteligencję nie zależy wyłącznie od wielkości zastosowanego modelu językowego. Decydujące znaczenie ma to, czy model otrzymuje niezbędne informacje. SchallOS potrafi złożyć kontekst z kilku poziomów:

1. aktualnego pytania
2. w otwartym edytorze
3. wybranym polu lub kontenerze funkcji
4. w odnośnych tabelach i powiązaniach
5. istniejące wzory i funkcje
6. opisy semantyczne
7. Dokumentacja i historia zmian
8. a także, w przypadku migracji, pierwotnego skryptu FileMaker.

Dzięki temu sztuczna inteligencja może działać znacznie dokładniej niż w przypadku pojedynczego zapytania w ogólnym czacie.

Jednocześnie nie w każdym zadaniu konieczne jest podanie pełnego rozwiązania. Kontekst można ograniczyć do informacji, które są faktycznie potrzebne do wykonania danej funkcji.

Modele wymienne zamiast stałego zobowiązania

Warstwa sztucznej inteligencji nie powinna być trwale uzależniona od jednego modelu lub dostawcy. Różne zadania stawiają różne wymagania dotyczące jakości, szybkości, kosztów i ochrony danych.

Złożona migracja może wymagać zastosowania szczególnie wydajnego modelu. Proste wyjaśnienie lub dostosowanie wzoru można ewentualnie przeprowadzić przy użyciu mniejszego modelu. W przypadku wrażliwych lub zamkniętych środowisk w perspektywie długoterminowej można również wykorzystać modele działające lokalnie.

Trwała baza wiedzy nie znajduje się zatem w modelu językowym, lecz w rozwiązaniu SchallOS: w opisach, strukturach, odwołaniach do skryptów, kodzie, testach i dokumentacji. Model sztucznej inteligencji pozostaje wymiennym narzędziem, które na podstawie tego kontekstu generuje kod wykonywalny lub zrozumiałe propozycje.

Przejrzysty proces rozwoju oparty na sztucznej inteligencji

SchallOS łączy bezpośrednią pracę z aplikacjami biznesowymi z programowaniem opartym na sztucznej inteligencji. Formuły można bezpośrednio wyjaśniać i generować. Funkcje niestandardowe powstają na podstawie powtarzalnych specyfikacji biznesowych. Kontenery funkcji łączą opisy semantyczne z widocznym i weryfikowalnym kodem.

W przypadku rozwiązań poddanych migracji skrypty FileMaker pozostają jako dodatkowa warstwa edukacyjna. Pomagają one zrozumieć istniejące procesy biznesowe bez konieczności trwałego utrzymywania wcześniejszych zależności technicznych.

Rola programisty nie znika przez to. Ulega ona zmianie. Precyzyjne wymagania, przemyślana architektura, testy i kontrola merytoryczna stają się ważniejsze niż ręczne wprowadzanie każdego pojedynczego kroku programu. Zwłaszcza w przypadku oprogramowania o kluczowym znaczeniu dla działalności ta odpowiedzialność pozostaje nieodzowna.

Aktualne badanie dotyczące korzystania z lokalnych systemów AI

Dokumentacja i logi zdarzeń jako część aplikacji

Dokumentacja aplikacji biznesowej jest często sporządzana dopiero po zakończeniu prac programistycznych. W obliczu presji czasu praca skupia się najpierw na nowych polach, układach, formułach i funkcjach. Opis zmian ma zostać dodany później.

Jednak wraz z upływem czasu coraz trudniej jest odtworzyć pierwotne decyzje. Często nie wiadomo już dokładnie, dlaczego dodano daną funkcję, jakie obiekty były nią objęte i jakie przypadki szczególne należało uwzględnić. Dlatego SchallOS nie traktuje dokumentacji jako dodatkowego zadania wykonywanego po fakcie. Istotne zmiany są rejestrowane jako zdarzenia już na etapie rozwoju i powiązane z odpowiednimi elementami rozwiązania.

Na podstawie tych informacji można następnie generować dokumentację techniczną, informacje o aktualizacjach, raporty dla klientów lub protokoły wydajności. Dokumentacja ta nie opiera się zatem wyłącznie na wspomnieniach lub ręcznie sporządzonych notatkach, lecz na faktycznie wprowadzonych zmianach.

Wydarzenia na wielu płaszczyznach

Rozwiązanie SchallOS nie opiera się wyłącznie na jednym, ogólnym protokole. Platforma rozróżnia różne poziomy zdarzeń, z których każdy ma swoje własne zadania.

• The Protokół strukturalny rejestruje zmiany w SSC. Obejmują one na przykład nowe tabele i pola, dostosowane układy, zmienione formuły lub nowe kontenery funkcji.
• The Rejestr zdarzeń danych należy do systemu SSD. W tym systemie rejestrowane są procesy istotne z punktu widzenia działalności operacyjnej, zachodzące podczas użytkowania produkcyjnego, takie jak zmiany statusu, zatwierdzenia, anulowania lub modyfikacje ważnych rekordów danych.
• Do tego dochodzą Zdarzenia operacyjne z Runtime i SchallOS Control. Obejmują one między innymi wdrażanie, aktualizacje, testy, tworzenie kopii zapasowych oraz operacje przywracania.

Obszary te pozostają oddzielne, ale można je ze sobą połączyć. Protokół rozwoju nie powinien stać się nieczytelny z powodu codziennych zmian w rekordach danych klientów. Z drugiej strony wewnętrzne szczegóły techniczne nie powinny automatycznie znajdować się w historii merytorycznej faktury lub zlecenia.

Protokół strukturalny przedstawia rozwój rozwiązania

Zmiany w tabelach, polach, układach, formułach i kontenerach funkcji można zapisać jako zdarzenia ustrukturyzowane. Wpis może zawierać informacje o tym, który obiekt został zmodyfikowany, jaki był jego poprzedni stan oraz jaki jest jego nowy stan. Dodatkowo można zarejestrować nazwisko autora, datę i godzinę, uzasadnienie merytoryczne, powiązane zlecenie oraz planowaną wersję wydania.

Jeśli na przykład wprowadzony zostanie nowy proces zatwierdzania zleceń, może to pociągać za sobą szereg zmian technicznych. Utworzone zostanie pole statusu, rozszerzony zostanie układ, dostosowana zostanie formuła oraz zaprogramowany zostanie nowy kontener funkcji.

Protokół strukturalny rejestruje te poszczególne zdarzenia. Jednocześnie można je połączyć w ramach jednego zadania merytorycznego. Dzięki temu widać, że kilka zmian technicznych razem tworzy nowy proces biznesowy.

Sesje „Change” grupują powiązane ze sobą prace

Zadanie programistyczne często składa się z wielu małych kroków. Czysto chronologiczna lista poszczególnych zmian nie oddałaby w wystarczającym stopniu rzeczywistego kontekstu.

Dlatego SchallOS może grupować powiązane zadania w ramach sesji zmian. Sesja zmian opisuje konkretne zadanie, rozszerzenie lub poprawkę błędu i gromadzi wszystkie powiązane z nią zdarzenia. Może ona na przykład zawierać:

• opis obowiązków służbowych
• dotyczy to tabel i układów
• zmienione wzory i funkcje
• przeprowadzone testy
• kwestie do wyjaśnienia
• a także przypisanie do klienta lub zlecenia.

Kilka sesji zmian można później przypisać do danej wersji. W ten sposób powstaje przejrzysty związek między zleceniem rozwojowym, zmianami technicznymi a opublikowaną wersją.

Sztuczna inteligencja przedstawia zdarzenia techniczne w przystępny sposób

Warstwa dokumentacyjna jest połączona ze zintegrowaną sztuczną inteligencją systemu SchallOS. Dzięki temu zarejestrowane zdarzenia mogą być automatycznie przetwarzane z myślą o różnych grupach docelowych.

Raport techniczny dla programistów zawiera inne informacje niż komunikat dla klienta. Podczas gdy programista chce zapoznać się z konkretnymi nazwami pól, kontenerami funkcji i migracjami danych, klienta interesuje przede wszystkim to, jaka funkcja została dodana i jakie korzyści ona zapewnia. Sztuczna inteligencja może zatem podsumować te same zdarzenia w różnych formach:

• jako wewnętrzna dokumentacja techniczna
• jako zrozumiała informacja dla klientów
• jako informacje o wydaniu
• jako sprawozdanie z projektu
• lub jako dowód wykonania usługi do faktury.

Teksty nie powstają swobodnie na podstawie ogólnego opisu. Są one wyprowadzane z sesji zmian, semantycznych opisów obiektów oraz faktycznych zmian strukturalnych.

Wygenerowany tekst pozostaje przy tym powiązany ze swoimi źródłami. Programista może sprawdzić, na jakich zdarzeniach opiera się dane stwierdzenie, a następnie skorygować lub zatwierdzić sformułowanie przed jego wykorzystaniem.

Protokoły wydajności dla programistów i klientów

Dla twórców oprogramowania na zamówienie dokumentacja ma również znaczenie ekonomiczne. Usługi muszą być w zrozumiały sposób wyjaśnione klientowi i często rozliczane według czasu lub pakietu prac.

W praktyce takie protokoły usług są często sporządzane dopiero na krótko przed wystawieniem faktury. Wymaga to przeszukiwania wiadomości e-mail, notatek i przypomnień.

SchallOS może przypisać faktycznie zarejestrowane zdarzenia związane z rozwojem do klienta, projektu lub zlecenia. Sztuczna inteligencja generuje na tej podstawie odpowiednie wpisy do protokołu wykonania. Na przykład kilka zmian technicznych można połączyć w jedną zrozumiałą pozycję:

Rozszerzenie systemu zarządzania zleceniami o dwuetapowy proces zatwierdzania, obejmujący sprawdzanie statusu, uprawnienia użytkowników oraz dostosowanie formularza wprowadzania danych.

Podstawowe procesy techniczne pozostają nadal widoczne. Opis dla klienta stanowi jedynie zrozumiałe streszczenie. Ostateczny wybór należy do programisty. Nie każde zdarzenie techniczne podlega automatycznie rozliczeniu, a wewnętrzne testy lub poprawki nie muszą być wykazywane osobno na fakturze.

Zdarzenia na poziomie danych

Również podczas pracy produkcyjnej można rejestrować wszystkie przewidziane zdarzenia związane z danymi. Obejmują one tworzenie i modyfikowanie rekordów danych, zmiany statusu, zatwierdzenia, importy, eksporty oraz procesy wykonywane automatycznie. Wpis może zawierać następujące informacje:

• który użytkownik lub proces zainicjował tę czynność
• który rekord danych był objęty zmianą
• które wartości zostały zmienione
• która funkcja została wykonana
• oraz czy operacja została pomyślnie zakończona.

To właśnie dane rozwiązanie określa, jakie zdarzenia są zapisywane i na jakim poziomie szczegółowości. Niewielka poprawka w tekście ma inne znaczenie niż zmiana faktury, która została już zatwierdzona. Protokół zdarzeń danych stanowi zatem historię operacyjną systemu SSD. Wspiera on obsługę techniczną, analizę błędów oraz zapewnienie śledzalności ważnych procesów biznesowych.

Taki protokół może również stanowić podstawę dla wymagań audytowych. Należy jednak sprawdzić w każdym konkretnym przypadku, czy spełnia on wszystkie wymogi prawne lub branżowe.

Dokumentacja towarzyszy również wydaniom i aktualizacjom

Zarejestrowane zmiany w rozwoju są jednocześnie wprowadzane do procesu wydawania nowych wersji i aktualizacji. W przypadku opublikowania nowej wersji SchallOS może automatycznie zestawić, które funkcje zostały dodane, które błędy naprawiono i które struktury danych uległy zmianie. Na tej podstawie tworzone są listy zmian technicznych, wskazówki dla użytkowników oraz informacje dotyczące migracji.

Po instalacji można sprawdzić, która wersja została zainstalowana na konkretnej instancji środowiska uruchomieniowego oraz jakie zmiany zawierała.

Dokumentowane są również zdarzenia operacyjne, takie jak tworzenie kopii zapasowych, testy czy ewentualne przywrócenie poprzedniej wersji. Dzięki temu można później ustalić nie tylko, co zostało opracowane, ale także kiedy i z jakim wynikiem dana zmiana została wdrożona do środowiska produkcyjnego.

Rosnąca baza wiedzy

Połączenie dziennika zdarzeń, opisów semantycznych i wsparcia sztucznej inteligencji pozwala w dłuższej perspektywie stworzyć bazę wiedzy dotyczącą całego rozwiązania. W przypadku późniejszych zmian nie trzeba ograniczać się wyłącznie do analizy aktualnego kodu. Można również ustalić, kiedy dana funkcja została wprowadzona, jakie były tego przyczyny biznesowe oraz jakie inne obszary miały wówczas z tym związek.

Wiedza ta ma kluczowe znaczenie zwłaszcza w przypadku aplikacji biznesowych, które rozwijały się przez wiele lat. Pozornie zbędny przypadek szczególny może mieć ważne uzasadnienie historyczne. Bez dokumentacji istnieje ryzyko, że zostanie on przypadkowo usunięty podczas późniejszej modyfikacji. Dlatego SchallOS przechowuje nie tylko stan techniczny, ale także historię rozwoju i związane z nią decyzje.

W ten sposób dokumentacja staje się aktywnym elementem aplikacji. Wspiera ona procesy rozwoju, komunikacji z klientami, rozliczeń, wsparcia technicznego, wprowadzania nowych wersji oraz długoterminowej konserwacji – w oparciu o zdarzenia, które faktycznie miały miejsce w systemie.

Systemowy proces aktualizacji obejmujący platformę i aplikacje

Oprogramowanie biznesowe rzadko pozostaje niezmienione przez dłuższy czas. Nowe wymagania, zmiany prawne, poprawki błędów i dalszy rozwój techniczny regularnie prowadzą do pojawiania się nowych wersji. Nie wystarczy przy tym jedynie wymienić pliki. Przed każdą aktualizacją należy sprawdzić, która wersja jest aktualna, czy konieczne jest dostosowanie struktur danych oraz w jaki sposób można przywrócić poprzedni stan w przypadku wystąpienia błędu.

W przypadku wielu indywidualnych zastosowań takie procedury powstają dopiero w późniejszym etapie. Aktualizacje są wówczas wdrażane za pomocą instrukcji ręcznych, kopii zapasowych i skryptów dostosowanych do potrzeb klienta. Z każdą kolejną instalacją rośnie ryzyko pojawienia się różnych wersji i rozwiązań niestandardowych.

W związku z tym SchallOS traktuje aktualizacje jako funkcję obejmującą całą platformę. Za pomocą tego samego podstawowego procesu aktualizowane są zarówno sam system SchallOS, jak i rozwiązania dla klientów opracowane w ramach tej platformy.

Dzięki temu programista nie musi od razu opracowywać własnej procedury aktualizacji dla nowej aplikacji. Zarządzanie wersjami, testowanie, dystrybucja i rejestrowanie stanowią od samego początku część wspólnej architektury.

Rozdzielenie SSC i SSD zapewnia ochronę danych operacyjnych

Możliwość aktualizacji jest bezpośrednio związana z rozdzieleniem struktury od danych. SSC zawiera układy, formuły, kontenery funkcji, definicje językowe oraz model danych aplikacji. SSD zawiera operacyjne dane biznesowe danej firmy.

W związku z tym w przypadku nowej wersji nie zastępuje się całej aplikacji wraz ze wszystkimi danymi klientów. Zamiast tego można opublikować nowy SSC, podczas gdy istniejący SSD pozostaje w miejscu wdrożenia.

Jeśli nowa struktura wymaga dodatkowych pól, tabel lub zmian formatów danych, wykonywane są w tym celu wyraźnie określone etapy migracji. Dane produkcyjne są w kontrolowany sposób dostosowywane do nowej struktury i nie są niezauważalnie zastępowane innym zbiorem danych.

To wyraźne rozdzielenie pozwala na dalszy rozwój aplikacji przez wiele lat bez konieczności przenoszenia wszystkich danych biznesowych do nowego, kompletnego pliku przy każdej aktualizacji.

Od etapu rozwoju do wydania

Nie każda zmiana wprowadzona w programie SchallOS Studio nadaje się od razu do użytku produkcyjnego. W trakcie prac rozwojowych mogą występować tymczasowe układy, niekompletne funkcje lub formuły, które nie zostały jeszcze przetestowane.

Związane ze sobą zmiany są zatem najpierw rejestrowane w sesjach zmian i przypisywane do planowanego wydania. Dopiero po sprawdzeniu i zatwierdzeniu powstaje na tej podstawie opublikowana wersja. Wydanie może zawierać między innymi:

• jednoznaczny numer wersji
• zaktualizowany SSC
• niezbędne migracje na dyski SSD
• wymagania techniczne
• Zależności od środowiska uruchomieniowego lub adapterów
• Etapy kontroli i testów
• Informacje o wydaniu
• a także informacje dotyczące ewentualnego przywrócenia poprzedniej wersji.

Warstwa dokumentacyjna stanowi w tym zakresie podstawę. Na podstawie zarejestrowanych zdarzeń związanych z rozwojem można automatycznie generować listy zmian technicznych oraz zrozumiałe wskazówki dla użytkowników.

Wersja nie składa się zatem wyłącznie ze zmienionych plików. Zawiera ona również opis tego, co zostało zmienione, jakie są wymagania oraz w jaki sposób należy sprawdzić instalację.

SchallOS Control steruje dystrybucją

SchallOS Control przejmuje operacyjne zarządzanie aktualizacjami. W tym module widać, jakie instancje są dostępne, które wersje zostały poddane procesowi installier oraz jakie aktualizacje są gotowe do zainstalowania. Przed instalacją Control może między innymi sprawdzić:

• czy instancja docelowa jest dostępna
• jakiej wersji środowiska uruchomieniowego i SSC używana jest
• który adapter bazy danych jest aktywny
• czy można utworzyć odpowiednie zabezpieczenie
• oraz czy spełnione są wszystkie warunki wydania.

Dzięki temu zapobiega się przeprowadzeniu aktualizacji na instalacji, która nie spełnia wymagań technicznych lub nie została odpowiednio przygotowana.

Ponadto aktualizacja nie musi być wdrażana jednocześnie we wszystkich systemach. Można ją najpierw zastosować w środowisku testowym lub w wybranych instalacjach. Dopiero po pomyślnym przetestowaniu następuje szersze wdrożenie.

W tym celu można przewidzieć różne kanały aktualizacji, na przykład stabilne wersje produkcyjne, wersje wstępne, testy wewnętrzne lub wersje dostosowane do potrzeb klienta.

Sygnatury i jednoznaczne numery wersji

Pakiety aktualizacji mogą być opatrzone sumami kontrolnymi i podpisami cyfrowymi. Dzięki temu SchallOS Control rozpoznaje, czy pakiet jest kompletny, pochodzi z przewidzianego źródła oraz czy został zmodyfikowany od momentu jego opublikowania.

Dodatkowo sprawdzane jest, czy dana wersja rzeczywiście należy do danego rozwiązania. Nie wolno przypadkowo połączyć nowego SSC z SSD innej aplikacji.

Unikalne identyfikatory rozwiązań, wersje struktury i wersje modelu danych zapewniają, że stan wdrożenia install pozostaje przejrzysty. Możliwe jest również zidentyfikowanie niezbędnych etapów pośrednich. Na przykład instalacja nie może przejść bezpośrednio z bardzo starej wersji na najnowszą, jeśli wcześniej konieczne jest przeprowadzenie migracji danych.

Tworzenie kopii zapasowych, migracja i weryfikacja

Przed aktualizacją strukturalną należy wykonać kopię zapasową aktualnego stanu. Konkretny sposób wykonania kopii zapasowej zależy od używanego adaptera bazy danych. Lokalna instalacja IndexedDB lub SQLite wymaga innych procedur niż serwer PostgreSQL.

Następnie sprawdzany jest pakiet aktualizacji, wdrażana jest nowa struktura install oraz, w razie potrzeby, przeprowadzana jest migracja danych. Po aktywacji następuje weryfikacja. W ramach tej weryfikacji SchallOS może na przykład sprawdzić:

• czy wszystkie oczekiwane tabele i pola są dostępne,
• czy migracja danych została przeprowadzona w całości,
• czy liczby rekordów i sumy kontrolne są prawidłowe,
• oraz czy ważne funkcje działają prawidłowo.

Dopiero po pomyślnym zakończeniu tych testów aktualizacja uznaje się za wdrożoną w wersji 1TP12. Samo przesłanie plików nie wystarczy. Decydujące znaczenie ma to, aby struktura, dane i środowisko uruchomieniowe ponownie stanowiły spójną i sprawnie działającą całość.

Cofnięcie zmian w przypadku nieudanych aktualizacji

Pomimo starannego przygotowania aktualizacja może się nie powieść. Nieoczekiwane stare dane, nieprawidłowa migracja lub nieuwzględniona zależność mogą spowodować, że nie będzie można bezpiecznie aktywować nowej wersji. W takich przypadkach procedurę aktualizacji uzupełnia przywrócenie poprzedniej wersji. Polega to na przywróceniu wcześniejszej wersji SSC, zapisanego stanu SSD oraz poprzedniej konfiguracji.

Nie każdą aktualizację można jednak cofnąć na dowolnie długi okres. Jeśli po instalacji przetworzono już nowe dane operacyjne zgodnie ze zmienionymi regułami, całkowity powrót do poprzedniego stanu może być problematyczny. W związku z tym w wydaniu należy określić, na jakich warunkach możliwe jest cofnięcie aktualizacji.

W niektórych przypadkach bardziej sensowna jest kolejna aktualizacja korygująca niż przywrócenie starszego zestawu danych. Platforma zapewnia ramy techniczne, jednak konkretna decyzja zależy od danej zmiany i jej znaczenia merytorycznego.

Również sam SchallOS korzysta z tego potoku

Proces aktualizacji nie jest przeznaczony wyłącznie dla rozwiązań klienckich. Również SchallOS Studio, Runtime, Control i inne komponenty platformy są aktualizowane za pomocą tych samych podstawowych mechanizmów. Nowe wersje platformy mogą zawierać rozszerzenia środowiska formuł, ulepszenia warstwy sztucznej inteligencji, nowe adaptery baz danych lub poprawki bezpieczeństwa. Również w tym przypadku wymagane są numery wersji, zależności, sygnatury i testy.

W ten sposób infrastruktura jest wykorzystywana i na bieżąco testowana w ramach bieżącej eksploatacji samej platformy. Aplikacje opracowane przy użyciu SchallOS korzystają z tych samych procedur.

W ten sposób programista otrzymuje nie tylko teoretycznie przewidzianą funkcję aktualizacji, ale także proces, który stanowi integralną część zarówno eksploatacji, jak i dalszego rozwoju całego systemu.

Planowana ścieżka rozwoju dla przyszłych wersji

Siła procesu aktualizacji nie polega wyłącznie na automatycznym dystrybuowaniu nowych plików. Kluczowe znaczenie ma połączenie prac związanych z rozwojem, dokumentacją, tworzeniem kopii zapasowych, migracją, testowaniem i przywracaniem poprzedniej wersji w ramach jednego wspólnego procesu.

Sam system SchallOS oraz aplikacje w nim opracowane korzystają z tej samej podstawowej infrastruktury. Rozdzielenie SSC i SSD pozwala na dalszy rozwój struktury, przy jednoczesnej ochronie danych produkcyjnych i ich kontrolowanym dostosowywaniu.

Rozwiązanie opracowane przy użyciu SchallOS ma zatem od samego początku zaplanowaną ścieżkę rozwoju dla przyszłych wersji. Zwłaszcza w przypadku oprogramowania biznesowego, które ma być używane przez wiele lat, ta możliwość aktualizacji nie jest dodatkową funkcją, lecz niezbędnym warunkiem zapewnienia długotrwałej konserwacji i niezawodnego działania.

Środowisko uruchomieniowe, interfejs użytkownika i chmura dla różnych modeli operacyjnych

Środowisko programistyczne wymaga szerokich możliwości. Programiści muszą mieć możliwość modyfikowania struktur, projektowania układów, edytowania formuł oraz publikowania nowych funkcji. Natomiast w codziennej eksploatacji gotowej aplikacji biznesowej narzędzia te zazwyczaj nie są potrzebne.

W związku z tym SchallOS dzieli procesy tworzenia, uruchamiania i zarządzania na odrębne obszary. SchallOS Studio służy do tworzenia aplikacji. SchallOS Runtime uruchamia opublikowane aplikacje. SchallOS Control zarządza ich wdrożeniem technicznym. SchallOS Cloud oferuje tę samą podstawową architekturę w formie scentralizowanej usługi internetowej.

W ten sposób nie powstają od siebie niezależne aplikacje. Wszystkie obszary korzystają z tych samych struktur SSC i SSD. Tryb działania określa się za pomocą wdrożenia, adaptera bazy danych i profilu środowiska uruchomieniowego.

SchallOS Runtime uruchamia opublikowane rozwiązania

SchallOS Runtime łączy SSC aplikacji z odpowiednim dyskiem SSD i udostępnia zdefiniowane w nim układy, formuły oraz funkcje. W czasie wykonywania obejmuje to między innymi wyświetlanie i obsługę układów, odczyt i edycję rekordów danych, obliczanie formuł i funkcji niestandardowych, wykonywanie kontenerów funkcji, nawigację i sterowanie oknami dialogowymi, obsługę wielu języków, a także połączenie z przeznaczonym adapterem bazy danych.

Runtime nie zawiera jednak automatycznie wszystkich narzędzi SchallOS Studio. Nie umożliwia tworzenia nowych par rozwiązań SSC/SSD i nie posiada asystenta migracji dla rozwiązań FileMaker.

W ten sposób dostarczona aplikacja klienta pozostaje wyraźnie oddzielona od właściwego środowiska programistycznego.

Profile określają możliwości środowiska uruchomieniowego

Nie każda instalacja wymaga takiego samego zakresu funkcji. Aplikacja przeznaczona wyłącznie dla użytkowników końcowych może mieć za zadanie jedynie wykonywanie opublikowanych układów i procesów biznesowych. Instalacja wewnętrzna może wymagać dodatkowych funkcji administracyjnych lub diagnostycznych.

W tym celu SchallOS wykorzystuje profile środowiska uruchomieniowego i profile możliwości. Określają one, jakie możliwości techniczne posiada konkretna instancja.

Profil może na przykład określać, czy tryb układu jest dostępny, czy można importować lub eksportować dane, czy wyświetlane są okna dialogowe administracyjne, czy można zmieniać ustawienia lokalne lub czy można korzystać z określonych interfejsów.

Profile te uzupełniają uprawnienia użytkowników w ramach samego rozwiązania. Uprawnienia użytkowników określają, jakie czynności merytoryczne dana osoba może wykonywać. Natomiast profil środowiska uruchomieniowego określa, jakie możliwości techniczne zasadniczo zapewnia dana instalacja.

Dzięki temu ta sama platforma uruchomieniowa może być wykorzystywana dla różnych grup klientów i różnych zastosowań, bez konieczności opracowywania osobnej wersji programu dla każdego wariantu.

Od lokalnego komputera pojedynczego użytkownika po środowisko serwerowe

Rozwiązanie SchallOS może być wdrażane w różnych trybach pracy. Na przykład w przypadku lokalnej stacji roboczej dane mogą być przechowywane na dysku SSD w bazie IndexedDB. Aplikacja desktopowa typu install może korzystać z bazy danych SQLite. W przypadku większych rozwiązań wieloużytkownikowych przewidziano centralną bazę danych, taką jak PostgreSQL.

Modele operacyjne mają różne cechy. IndexedDB nadaje się przede wszystkim do lokalnych aplikacji przeglądarkowych. SQLite stanowi sprawdzoną podstawę dla aplikacji lokalnych i niewielkich instalacji. PostgreSQL sprawdza się w scentralizowanych systemach wieloużytkownikowych z profesjonalnym zarządzaniem serwerami.

SchallOS nie traktuje tych technologii jako całkowicie zamiennych nośników danych. Zmiana adaptera wymaga kontrolowanego transferu danych, weryfikacji oraz, w razie potrzeby, przywrócenia poprzedniego stanu. Wspólna architektura SSC/SSD gwarantuje, że układy, formuły i logika biznesowa nie muszą być opracowywane od nowa dla każdego adaptera bazy danych.

Aplikacje komputerowe i praca w przeglądarce

Rozwiązania SchallOS powinny działać zarówno w przeglądarce, jak i jako aplikacje instalowane na systemach Windows i macOS. Środowisko uruchomieniowe na komputerze stacjonarnym może ściślej integrować się z danym systemem operacyjnym, kontrolować dostęp do plików lokalnych oraz, przy odpowiedniej konfiguracji, pracować czasowo w trybie offline. Może ono przechowywać dane lokalnie za pomocą IndexedDB lub SQLite albo uzyskiwać dostęp do centralnej bazy danych PostgreSQL.

W przeglądarce aplikacja jest wyświetlana przez własne środowisko uruchomieniowe SchallOS. Nie jest do tego potrzebny ani serwer FileMaker, ani FileMaker WebDirect. Przeniesione rozwiązanie FileMaker nie działa więc już po migracji w tle na pliku FileMaker. Układy, formuły i logika funkcji są realizowane w ramach architektury SchallOS.

SchallOS Control zarządza instancjami

SchallOS Control stanowi operacyjne centrum sterowania platformy. To właśnie tam zarządza się tym, które rozwiązanie działa na danym systemie docelowym oraz jakie są wymagania techniczne. Control może między innymi wyświetlać:

• jakie pary SSC/SSD zostały udostępnione
• która wersja środowiska uruchomieniowego to installiert
• który adapter bazy danych jest używany
• który profil zdolności ma zastosowanie
• jakie aktualizacje są dostępne
• oraz kiedy dana instancja została sprawdzona po raz ostatni.

Celem wdrożenia może być na przykład lokalna aplikacja dla systemu Windows, środowisko uruchomieniowe macOS, własny serwer PostgreSQL, środowisko testowe lub instancja w chmurze.

Dane operacyjne, takie jak adresy serwerów, dostęp do baz danych, licencje czy powiązania z urządzeniami lokalnymi, nie powinny znajdować się w przenośnym pliku SSC. Są one zarządzane w chronionej konfiguracji danej instancji.

Rozwiązania z podpisem cyfrowym i kontrolowana dystrybucja

Przenośne kontenery rozwiązań nie mogą oznaczać, że każdą aplikację można dowolnie modyfikować lub uruchamiać na systemach, do których nie została przeznaczona. Opublikowane pakiety SSC/SSD można zatem powiązać z identyfikatorami rozwiązań, sumami kontrolnymi, podpisami i informacjami o instancjach. Środowisko uruchomieniowe może podczas uruchamiania sprawdzić, czy plik SSC jest niezmieniony i posiada ważny podpis, czy plik SSD należy do właściwego rozwiązania, czy obie wersje są ze sobą kompatybilne oraz czy dostępny jest ważny profil wdrożeniowy.

W zależności od modelu licencji udostępnienie może być powiązane z instancją, serwerem, urządzeniem lub określoną grupą użytkowników. SchallOS Control zarządza przy tym również niezbędnymi zmianami, takimi jak zmiana serwera, ponowna aktywacja lub przywrócenie instalacji.

SchallOS Cloud jako model operacyjny SaaS

SchallOS Cloud udostępnia aplikacje jako centralnie zarządzaną usługę online. Chmura nie wykorzystuje jednak własnego, odrębnego formatu rozwiązania. Aplikacja opracowana w SchallOS Studio może zostać przypisana do instancji w chmurze i udostępniona za pośrednictwem przeglądarki. Środowisko uruchomieniowe, baza danych, kopie zapasowe, monitorowanie i aktualizacje są zarządzane centralnie. Dla programistów i klientów oznacza to model SaaS, bez konieczności ponownego tworzenia aplikacji specjalnie dla odrębnej platformy chmurowej.

Zasadnicza przenośność pozostaje zachowana. Rozwiązanie można w późniejszym czasie przenieść na własny serwer lub do innego obsługiwanej platformy, o ile pozwalają na to ilość danych, funkcje i wymagania techniczne. Zmiana ta pozostaje kontrolowaną migracją, ale nie wymaga całkowitego przebudowywania aplikacji.

Rozwiązanie może rozwijać się wraz z rosnącymi wymaganiami

Nową aplikację można najpierw opracować lokalnie i przetestować przy użyciu niewielkiego zbioru danych. Później można ją udostępnić jako wewnętrzne środowisko uruchomieniowe, przenieść na bazę danych SQLite lub PostgreSQL, a na koniec opublikować jako rozwiązanie serwerowe lub w chmurze. Tabele, układy, formuły, kontenery funkcji, tłumaczenia i dokumentacja pozostają przy tym częścią tej samej struktury rozwiązania.

Nie każdy prototyp staje się bez wprowadzania zmian pełnoprawną aplikacją korporacyjną. Należy nadal starannie zaplanować obsługę wielu użytkowników, bezpieczeństwo, wydajność i tworzenie kopii zapasowych. Platforma ta zapobiega jednak sytuacji, w której rozwój wiązałby się z koniecznością całkowitej zmiany technologii.

W ten sposób Runtime, Control i Cloud łączą różne modele operacyjne w ramach jednej wspólnej architektury. Aplikacja jest tworzona tylko raz, a następnie udostępniana w sposób kontrolowany do konkretnego zastosowania – lokalnie, na własnym serwerze lub jako SaaS w chmurze.

Z przyjemnością. Umieściłbym ten fragment bezpośrednio po rozdziale poświęconym sztucznej inteligencji lub jako uzupełnienie rozdziału 4. Porusza on ważną kwestię: sztuczna inteligencja nie jest ściśle powiązana z konkretnym dostawcą, lecz jest traktowana – podobnie jak adaptery baz danych – jako infrastruktura, którą można dowolnie wymieniać.

Adaptery AI zamiast uzależnienia od producenta

SchallOS celowo oddziela właściwą warstwę sztucznej inteligencji od wykorzystywanych modeli językowych. Platforma nie opiera się wyłącznie na jednym dostawcy ani na konkretnym środowisku uruchomieniowym. Zamiast tego można konfigurować różne adaptery sztucznej inteligencji i zarządzać nimi centralnie.

Adaptery te stanowią połączenie między SchallOS a używanymi modelami językowymi. Dzięki temu właściwe środowisko programistyczne pozostaje niezależne od tego, czy zapytanie jest wysyłane do modelu lokalnego, czy do usługi w chmurze.

W ten sposób sztuczna inteligencja staje się wymiennym elementem platformy – podobnie jak adaptery baz danych dla IndexedDB, SQLite czy PostgreSQL.

Centralne zarządzanie w SchallOS Control

Konfiguracja sztucznej inteligencji odbywa się centralnie za pośrednictwem SchallOS Control. W tym miejscu można tworzyć i zarządzać dowolną liczbą adapterów sztucznej inteligencji. Obsługiwane są zarówno modele lokalne, jak i usługi w chmurze.

Modele lokalne można na przykład zintegrować za pomocą Ollama lub LM Studio. W przypadku wielu zadań programistycznych wystarczy już kompaktowy model lokalny, który jest w całości uruchamiany na własnym komputerze.

Ponadto można skonfigurować modele chmurowe, takie jak ChatGPT, Claude lub inne kompatybilne usługi. Każdy adapter posiada własną konfigurację, obejmującą na przykład dane dostępowe, punkty końcowe, nazwy modeli lub inne ustawienia techniczne. Dzięki temu uzyskuje się centralny przegląd wszystkich dostępnych systemów sztucznej inteligencji w ramach jednej instalacji SchallOS.

Wystarczy skonfigurować raz, a będzie dostępne wszędzie

Dużą zaletą tej architektury jest to, że raz skonfigurowany adapter AI nie jest wykorzystywany tylko w jednym miejscu. Gdy adapter zostanie skonfigurowany w SchallOS Control, staje się dostępny dla całej platformy. Można go na przykład wykorzystać:

• w edytorze formuł
• w ramach kontenerów funkcyjnych
• do automatycznej dokumentacji
• podczas migracji rozwiązań FileMaker
• w Adapter Studio
• lub w przyszłych narzędziach projektowych opartych na sztucznej inteligencji.

Dlatego programista nie musi wielokrotnie konfigurować danych dostępowych ani modeli. Zarządzanie odbywa się centralnie, a poszczególne komponenty wybierają jedynie żądany adapter.

Odpowiedni model do danego zadania

Nie każde zadanie programistyczne wymaga takiej samej mocy obliczeniowej. Do krótkiego wyjaśnienia wzoru często wystarczy niewielki model lokalny. Natomiast w przypadku rozległych migracji lub złożonych zadań programistycznych warto skorzystać z wydajniejszego modelu w chmurze.

Dlatego też SchallOS umożliwia wybór różnych adapterów w zależności od konkretnego zastosowania. Programista może na przykład ustalić, że prosta dokumentacja będzie zasadniczo tworzona lokalnie, podczas gdy szczególnie obszerne zadania będą przekazywane do modelu zewnętrznego. Pozwala to na lepsze zrównoważenie szybkości, ochrony danych i kosztów.

Otwarte na przyszłe modele

Rozwój w dziedzinie sztucznej inteligencji przebiega niezwykle szybko. Nowe modele pojawiają się w krótkich odstępach czasu, a istniejące systemy są stale ulepszane. Dlatego też SchallOS nie wiąże się na stałe z jednym dostawcą. Decydujące znaczenie ma nie nazwa konkretnego modelu, lecz znormalizowany interfejs adaptera.

Dzięki temu w przyszłości będzie można dodawać nowe lokalne lub oparte na chmurze systemy sztucznej inteligencji bez konieczności wprowadzania zmian w samym środowisku programistycznym. Ta otwartość jest zgodna z podstawową architekturą SchallOS. Podobnie jak w przypadku adapterów baz danych, adaptery AI również powinny pozostać wymienne, podczas gdy Studio, środowisko uruchomieniowe i sama aplikacja mogą nadal działać bez zmian.

W ten sposób sztuczna inteligencja stanie się trwale zintegrowaną funkcją platformy – niezależnie od tego, jakie modele lub dostawcy zdobędą przewagę na rynku w nadchodzących latach.

Warstwa sztucznej inteligencji z funkcją samouczenia się zamiast statycznych podpowiedzi

Istotnym osiągnięciem SchallOS jest to, że zintegrowana sztuczna inteligencja nie opiera się już wyłącznie na statycznych podpowiedziach systemowych. Zamiast tego powstaje samoucząca się warstwa sztucznej inteligencji, która nieustannie udoskonala swoje działanie w oparciu o rzeczywiste projekty programistyczne.

Każde uruchomienie programowe kontenera funkcyjnego może – o ile programista sobie tego życzy – dostarczać zanonimizowane dane dotyczące jakości. Dodatkowo dostępne są powtarzalne testy porównawcze, w ramach których rzeczywiste kontenery funkcyjne danego rozwiązania są automatycznie testowane przy użyciu różnych lokalnych i chmurowych modeli sztucznej inteligencji. SchallOS ocenia przy tym nie tylko szybkość, ale przede wszystkim jakość generowanych wyników, wykryte błędy, cykle naprawcze oraz zgodność z zdefiniowanymi umowami programistycznymi.

Na podstawie tych danych automatycznie tworzone są wersjonowane profile modeli, wzorce uczenia się oraz antywzorce. Platforma uczy się zatem nie tylko, które polecenie działa lepiej, ale także, które strategie faktycznie sprawdziły się w przypadku określonych rodzin modeli, zadań i sytuacji błędów.

Poziomy kwalifikacji w zakresie sztucznej inteligencji od L1 do L4

SchallOS wprowadza wieloetapową klasyfikację stosowanych modeli sztucznej inteligencji. Zamiast ogólnie klasyfikować każdy model jako „odpowiedni“ lub „nieodpowiedni“, ocena odbywa się w oparciu o różne obszary zastosowań. Model może na przykład osiągnąć najwyższy poziom kwalifikacji w przypadku migracji FileMaker, podczas gdy w przypadku nowych rozwiązań semantycznych jest początkowo zalecany jedynie w ograniczonym zakresie. Klasyfikacja nie opiera się na informacjach podanych przez producenta, lecz wyłącznie na powtarzalnych testach porównawczych i rzeczywistych przebiegach produkcyjnych.

Dzięki temu SchallOS może automatycznie określić, który model ma największe szanse powodzenia w przypadku konkretnego zadania oraz kiedy warto zastosować model o większej mocy obliczeniowej lub alternatywny.

Inteligentne profile modelowe zamiast klasycznych poleceń

Każdy obsługiwany model sztucznej inteligencji otrzyma w przyszłości własny profil modelu z numerem wersji. Opis ten nie tylko przedstawia samą instrukcję systemową, ale zawiera również doświadczenia zdobyte podczas praktycznego stosowania właśnie tego modelu.

W tym kontekście SchallOS będzie w przyszłości rozróżniać między innymi profile dla:

• kontenery funkcji semantycznych
• Migracje FileMaker
• późniejsze migracje do Microsoft Access, 4D lub Oracle
• oraz inne systemy źródłowe

Profile te są uzupełniane o edytowalne teksty podstawowe, które programista może dostosować lub które mogą być dalej rozwijane w ramach automatycznych kampanii optymalizacyjnych. Dzięki temu SchallOS może w ciągu nocy przetestować różne warianty i automatycznie wdrożyć strategie, które okazały się najbardziej skuteczne.

Możliwości rozwiązania jako inteligentny interfejs branżowy

Oprócz możliwości technicznych platformy (Platform Capabilities) firma SchallOS wprowadzi w przyszłości możliwości rozwiązań (Solution Capabilities). Opisują one funkcjonalne możliwości konkretnej aplikacji i stanowią publiczny interfejs między sztuczną inteligencją a logiką biznesową. Przykładami takich funkcji są:

• Utwórz klienta
• Sporządź ofertę
• Przejmij zlecenie
• Wygeneruj fakturę
• Zaksięgować płatność

Sztuczna inteligencja może wchodzić w interakcję z rozwiązaniem wyłącznie za pośrednictwem tych udostępnionych funkcji. Celowo wykluczono bezpośredni dostęp do wewnętrznych kontenerów funkcji. Dzięki temu w każdej chwili można sprawdzić, jakie działania sztuczna inteligencja faktycznie może wykonywać.

Programista może w wygodny sposób definiować własne możliwości rozwiązania (Solution Capabilities) i tworzyć ich wersje. Są one przechowywane wraz z rozwiązaniem w SSC i są dostępne zarówno dla sztucznej inteligencji zajmującej się rozwojem, jak i – w późniejszym czasie – dla użytkowników końcowych.

Uczenie się na podstawie rzeczywistych projektów

Zintegrowany silnik testów porównawczych nie wykorzystuje sztucznych programów przykładowych, lecz – na życzenie – wykorzystuje jako podstawę testową rzeczywiste kontenery funkcyjne danego rozwiązania. W ten sposób dla każdej aplikacji powstaje indywidualna ocena AI, która jest dokładnie dostosowana do własnego stylu programowania, wykorzystywanych obiektów biznesowych oraz istniejących kontenerów funkcyjnych.

Im dłużej dane rozwiązanie jest wykorzystywane i udoskonalane, tym bardziej rozbudowane stają się jego wzorce uczenia się, a tym samym SchallOS może coraz precyzyjniej dobierać odpowiednie modele, unikać błędów i automatycznie generować nowe funkcje.

W związku z tym prawdziwa inteligencja nie tkwi już wyłącznie w samym modelu językowym, lecz w coraz większym stopniu w samym rozwiązaniu i jego stale rosnącej wiedzy opartej na doświadczeniu.

Adapter Studio jako uniwersalna platforma integracyjna

Dzięki nowemu adapterowi Studio SchallOS przekształca się w otwartą platformę integracyjną. W przyszłości systemy zewnętrzne będą mogły być integrowane za pomocą standardowych adapterów – niezależnie od tego, czy chodzi o bazy danych, usługi w chmurze, interfejsy REST czy systemy sztucznej inteligencji.

Dzięki temu nie powstają już sztywne, zastrzeżone integracje. Zamiast tego programiści mogą łączyć dowolne systemy zewnętrzne ze swoją aplikacją za pomocą funkcji Solution Capabilities. W ten sposób można w elegancki sposób koordynować nawet złożone rozwiązania hybrydowe, w których równolegle działa kilka systemów ERP. Sztuczna inteligencja korzysta przy tym wyłącznie z zdefiniowanych funkcji i nie musi znać ani wewnętrznych struktur danych, ani szczegółów technicznych podłączonych systemów.

Wiedza staje się prawdziwym kapitałem

Wraz z pojawieniem się SchallOS punkt ciężkości współczesnego tworzenia oprogramowania wyraźnie się przesuwa. Największą wartością aplikacji nie jest już sam kod programu, lecz uporządkowana wiedza na jego temat. SchallOS wspiera również nowe Format OKF, które firma Google opublikowała w czerwcu 2026 roku, aby w przyszłości umożliwić przenoszenie i udostępnianie wiedzy.

Kontenery funkcyjne, warstwa wiedzy, wzorce uczenia się, umowy dotyczące zdolności, wyniki benchmarków oraz profile zoptymalizowane pod kątem modelu stanowią wspólnie element rozwiązania i mogą być wraz z nim przenoszone, wersjonowane oraz stale udoskonalane.

Dzięki temu każda aplikacja SchallOS z czasem rozwija własną, coraz lepszą kompetencję w zakresie sztucznej inteligencji, która pozostaje bezpośrednio powiązana z danym rozwiązaniem.

Od migracji FileMaker do niezależnej platformy oprogramowania

SchallOS powstał w wyniku wieloletniej współpracy z firmą FileMaker. Wiele podstawowych założeń platformy opiera się na doświadczeniach związanych z indywidualnymi rozwiązaniami w zakresie baz danych i systemów ERP, które przez lata rozwijały się wraz z wymaganiami operacyjnymi tych firm.

FileMaker wyróżnia się szczególnymi zaletami w zakresie szybkiego tworzenia oprogramowania. Model danych, układy ekranów i logika programu są ze sobą ściśle powiązane, zmiany są natychmiast widoczne, a pierwsze działające rozwiązania można stworzyć stosunkowo szybko.

W systemie SchallOS ma zostać zachowana ta bliskość między programistą, danymi a interfejsem użytkownika. Podstawy techniczne zostaną jednak zbudowane od nowa. SchallOS wykorzystuje własne środowisko uruchomieniowe, własne kontenery strukturalne i danych, warstwę funkcjonalną opartą na sztucznej inteligencji, a także własną infrastrukturę do obsługi dokumentacji, wdrażania i aktualizacji.

FileMaker pozostaje zatem ważnym punktem wyjścia i potencjalnym źródłem istniejących rozwiązań. Nie jest jednak już niezbędny do dalszej eksploatacji.

Migracja to coś więcej niż tylko import układu

W pełni rozwinięte rozwiązanie FileMaker to nie tylko tabele, pola i widoczne maski. Znaczna część wiedzy biznesowej zawarta jest w formułach, skryptach, wyzwalaczach, relacjach, listach wartości i licznych przypadkach szczególnych.

Skuteczna migracja musi uwzględnić te powiązania i przenieść je do nowej architektury. Tabele, pola, relacje i układy można przy tym w znacznej mierze przejąć w zachowanej strukturze. Formuły i funkcje niestandardowe są przenoszone do środowiska formuł SchallOS lub dostosowywane.

W przypadku skryptów FileMaker na pierwszym planie znajduje się przede wszystkim zrozumienie ich zadania merytorycznego. Mogą one pozostać jako warstwa edukacyjna i referencyjna w tle nowych kontenerów funkcyjnych. Kod wykonywalny zostanie jednak przeprogramowany przez sztuczną inteligencję zgodnie z architekturą SchallOS. Dzięki temu w nowym systemie nie powstanie środowisko uruchomieniowe FileMaker. Istniejące rozwiązanie będzie stopniowo przekształcane w samodzielną aplikację SchallOS.

Niezależne działanie po migracji

Po zakończeniu pełnej migracji nie będą już potrzebne ani FileMaker Pro, ani FileMaker Server, ani WebDirect. Nowa aplikacja wykorzystuje środowisko uruchomieniowe SchallOS, SSC jako kontener strukturalny oraz SSD do przechowywania danych produkcyjnych. Formuły, kontenery funkcji, obsługa wielu języków, dokumentacja, dzienniki zdarzeń i aktualizacje są udostępniane przez platformę SchallOS.

W zależności od wymagań rozwiązanie może być uruchamiane lokalnie, jako aplikacja dla systemu Windows lub macOS, na własnym serwerze lub jako usługa SaaS w chmurze SchallOS.

W ten sposób znika uzależnienie od jednego, zastrzeżonego środowiska uruchomieniowego. Nie oznacza to jednak całkowitego wyeliminowania zależności technicznych – każde nowoczesne oprogramowanie wymaga systemów operacyjnych, baz danych i usług serwerowych. Struktura, logika biznesowa i dane pozostają jednak przenośne i mogą być obsługiwane za pomocą udokumentowanych adapterów oraz ścieżek wdrażania.

Nowe możliwości dla programistów FileMaker

Dla programistów FileMaker system SchallOS nie powinien oznaczać całkowitego zerwania z dotychczasowym sposobem pracy. Wiedza na temat modeli danych, projektowania układów graficznych oraz procesów operacyjnych nadal będzie cenna.

Zmiany dotyczą przede wszystkim sposobu realizacji logiki programu. Długie łańcuchy skryptów zastępują kontenery funkcji opisane semantycznie. Sztuczna inteligencja generuje kod wykonywalny na podstawie zdefiniowanych zadań, parametrów i ograniczeń. Programista sprawdza wynik i pozostaje odpowiedzialny za architekturę oraz poprawność merytoryczną.

Większy nacisk kładzie się również na historię rozwoju. Zmiany mogą być automatycznie rejestrowane, dokumentowane i grupowane w wersje. Ten sam proces aktualizacji, za pomocą którego aktualizowany jest sam system SchallOS, jest również dostępny dla własnych rozwiązań klientów.

W ten sposób praca częściowo przenosi się z ręcznego wprowadzania poszczególnych etapów programu na precyzyjne opisywanie, weryfikację i porządkowanie procesów biznesowych.

Nie tylko dla aplikacji przeniesionych

Migracja FileMaker pozostaje ważnym elementem systemu SchallOS, ale nie jest to jedyne jego zastosowanie. Nowe aplikacje można w całości tworzyć w programie SchallOS Studio.

W dłuższej perspektywie możliwe byłoby również dodanie obsługi kolejnych systemów źródłowych. Takie rozszerzenie wymaga jednak w każdym przypadku własnych procedur analitycznych i migracyjnych. Różne platformy programistyczne mają własne koncepcje, których nie da się sensownie odzwierciedlić za pomocą powierzchownego, uniwersalnego importu.

Doświadczenia zdobyte podczas migracji z systemu FileMaker stanowią w tym zakresie podstawę. Jednak głównym celem systemu SchallOS jest tworzenie i obsługa niezależnych aplikacji biznesowych.

Planowane rozpoczęcie jesienią 2026 roku

Publiczna premiera SchallOS jest zaplanowana na jesień 2026 roku. Do tego czasu kluczowe obszary platformy będą dalej integrowane, testowane i przygotowywane do pierwszych wdrożeń produkcyjnych. Nie każda z funkcji planowanych w perspektywie długoterminowej będzie w pełni gotowa już w momencie premiery. Kluczowe znaczenie ma solidny rdzeń, na którym w kontrolowany sposób będą mogły być rozbudowywane kolejne adaptery baz danych, funkcje sztucznej inteligencji, opcje migracji oraz modele operacyjne.

Najpierw... Oprogramowanie ERP gFM-NEXT firmy gofilemaker.de zostanie opublikowany na nowej platformie SchallOS prawdopodobnie we wrześniu 2026 roku. Uruchomienie platformy rozwojowej SchallOS nieco później, jesienią 2026 roku, nie powinno zatem oznaczać zakończenia prac rozwojowych, lecz początek praktycznego wdrożenia.

Pełny cykl życia aplikacji

Projekt SchallOS rozpoczął się od pytania, w jaki sposób istniejące rozwiązania FileMaker można przenieść do nowoczesnego środowiska. W ten sposób powstała platforma, która uwzględnia nie tylko migrację i rozwój, ale także dokumentację, wdrażanie, przechowywanie danych, aktualizacje oraz długoterminową eksploatację. Studio, Runtime, Control i Cloud pełnią w ramach wspólnej architektury wyraźnie rozdzielone zadania. Celem nie jest zatem jedynie zastąpienie FileMaker innym narzędziem programistycznym. SchallOS ma połączyć sprawdzoną bliskość między programistą, danymi i interfejsem użytkownika z przenośnymi kontenerami, programowaniem opartym na sztucznej inteligencji oraz spójnym modelem operacyjnym.

Punktem wyjścia jest DNA FileMaker. Celem jest stworzenie niezależnej platformy, na której będzie można w perspektywie długoterminowej rozwijać, obsługiwać i utrzymywać zarówno istniejące, jak i nowe aplikacje biznesowe.

Aktualne artykuły na temat sztucznej inteligencji

Nowe unijne przepisy dotyczące cenzury: Co oznaczają Chatcontrol, DSA, EMFA i ustawa o sztucznej inteligencji?

Nowe unijne przepisy dotyczące cenzury: Co oznaczają Chatcontrol, DSA, EMFA i ustawa o sztucznej inteligencji?

Kiedy rozmawiałem przez telefon z robotem - jak sztuczna inteligencja podbija telefony i jak ją rozpoznać

Kiedy rozmawiałem przez telefon z robotem - jak sztuczna inteligencja podbija telefony i jak ją rozpoznać

Jak zwierzęta postrzegają czas - i co to oznacza dla przyszłości sztucznej inteligencji?

Jak zwierzęta postrzegają czas - i co to oznacza dla przyszłości sztucznej inteligencji?

Przejrzystość w kryzysie: jak sztuczna inteligencja otwiera nowe perspektywy

Przejrzystość w kryzysie: jak sztuczna inteligencja otwiera nowe perspektywy

Często zadawane pytania

1. Czym dokładnie jest SchallOS i czym różni się od klasycznej aplikacji bazodanowej?
   SchallOS to platforma służąca do tworzenia, uruchamiania i zarządzania indywidualnym oprogramowaniem biznesowym. Obejmuje ona nie tylko tabele, układy i funkcje, ale także programowanie oparte na sztucznej inteligencji, dokumentację, dzienniki zdarzeń, wdrażanie i aktualizacje. SchallOS Studio służy do tworzenia oprogramowania, Runtime uruchamia gotowe aplikacje, Control zarządza instalacjami, a Cloud udostępnia rozwiązania w modelu SaaS. Dzięki temu platforma towarzyszy aplikacji od momentu jej powstania aż po długoterminową eksploatację.
2. Dla jakich programistów i firm przeznaczony jest SchallOS?
   SchallOS jest skierowany przede wszystkim do programistów FileMaker, firm programistycznych oraz twórców indywidualnych aplikacji biznesowych. Również przedsiębiorstwa korzystające z istniejących rozwiązań FileMaker zyskują możliwość stopniowego przenoszenia swoich aplikacji do niezależnego środowiska. Ponadto nowe rozwiązania mogą być tworzone w całości w ramach SchallOS. Dla dyrektorów zarządzających i osób odpowiedzialnych za decyzje techniczne szczególnie interesujące jest to, że rozwój, eksploatacja, dokumentacja, aktualizacje oraz różne formy wdrażania są zorganizowane w ramach jednej wspólnej platformy.
3. Czy SchallOS to przede wszystkim zamiennik modelu FileMaker?
   FileMaker stanowi ważny punkt wyjścia, ale nie jest trwałą podstawą techniczną systemu SchallOS. Przejmowane są sprawdzone rozwiązania, takie jak programowanie wizualne oraz ścisłe powiązanie danych, układów graficznych i funkcji. Jednak środowisko uruchomieniowe, przechowywanie danych, logika funkcjonalna oraz infrastruktura aktualizacji są tworzone od podstaw. SchallOS może migrować istniejące rozwiązania oparte na FileMaker, ale nadaje się również do nowych aplikacji. Po zakończeniu pełnej migracji FileMaker nie jest już potrzebne do pracy produkcyjnej.
4. Czy moje obecne rozwiązanie FileMaker można przenieść w sposób całkowicie automatyczny?
   Tabele, pola, relacje, układy i inne zdefiniowane struktury można w znacznym stopniu przenieść automatycznie. W przypadku złożonej logiki biznesowej konieczna jest jednak dodatkowa weryfikacja. Skrypty FileMaker często zawierają zmiany układów, zmienne globalne, wtyczki lub specjalne przypadki powstałe w przeszłości. Sztuczna inteligencja może analizować te procesy i tworzyć na ich podstawie nowe kontenery funkcji. Kompleksowe rozwiązanie powinno jednak zostać sprawdzone przez programistę i w razie potrzeby skorygowane. Migracja znacznie zmniejsza nakład pracy ręcznej, ale nie zastępuje merytorycznego zrozumienia aplikacji.
5. Co stanie się z istniejącymi skryptami FileMaker po migracji?
   Skrypty mogą pozostać w tle nowych kontenerów funkcyjnych jako warstwa szkoleniowa i referencyjna. Nie są one jednak wykonywane w niezmienionej postaci. Sztuczna inteligencja analizuje, jakie zadanie merytoryczne realizuje skrypt, z jakich pól korzysta i jakie warunki są sprawdzane. Następnie programuje nowy kod wykonywalny dostosowany do architektury SchallOS. Oryginalny skrypt pozostaje zachowany jako historyczne źródło wiedzy i może być nadal brany pod uwagę w przypadku późniejszych pytań lub rozszerzeń.
6. Czym są SSC i SSD i dlaczego dane rozwiązanie wymaga dwóch kontenerów?
   SSC zawiera strukturę aplikacji, w tym tabele, pola, układy, formuły, kontenery funkcji, języki i dokumentację. SSD zawiera dane operacyjne, takie jak klienci, artykuły, zamówienia czy faktury. Oba kontenery stanowią całość, ale pełnią różne zadania. To rozdzielenie umożliwia tworzenie nowych wersji struktury w ramach 1TP12 bez konieczności wymiany całego zbioru danych. Ponadto można modyfikować sposób przechowywania danych, kopie zapasowe i modele operacyjne bez konieczności całkowitego przeprojektowywania aplikacji.
7. Jakie korzyści płyną z rozdzielenia struktury i danych?
   Dzięki temu aktualizacje, tworzenie kopii zapasowych i migracje można przeprowadzać w znacznie bardziej kontrolowany sposób. Nowy SSC może zostać opublikowany, podczas gdy SSD z danymi klientów pozostaje nienaruszony. Niezbędne zmiany struktury są realizowane poprzez zdefiniowane migracje danych. SSC można ponadto analizować bez poufnych danych biznesowych lub przekazać innemu programiście. Ułatwione jest również przejście z IndexedDB na SQLite, PostgreSQL lub do chmury, ponieważ nie ma potrzeby odtwarzania układów i logiki funkcjonalnej od nowa.
8. Czy to samo rozwiązanie może działać lokalnie, na serwerze oraz w chmurze?
   Zasadniczo tak. Rozwiązanie SchallOS może działać lokalnie w przeglądarce, jako aplikacja dla systemu Windows lub macOS, z wykorzystaniem bazy danych SQLite, na serwerze PostgreSQL lub jako usługa SaaS w chmurze SchallOS Cloud. Sposób użytkowania pozostaje przy tym taki sam. Różne tryby działania mają jednak własne wymagania dotyczące pracy wieloużytkownikowej, tworzenia kopii zapasowych, wydajności i administracji. Przejście między nimi odbywa się zatem w sposób kontrolowany poprzez transfer danych i weryfikację. Architektura SSC/SSD zapobiega konieczności utrzymywania całkowicie nowego projektu dla każdego celu.
9. Czy po pomyślnej migracji nadal będę potrzebować FileMaker lub serwera FileMaker?
   Nie. Po zakończeniu pełnej migracji aplikacja będzie uruchamiana przez środowisko uruchomieniowe SchallOS. Również do pracy w przeglądarce nie są wymagane ani serwer FileMaker, ani WebDirect. Poprzedni system FileMaker może zostać zachowany jako punkt odniesienia lub archiwum, ale nie stanowi warunku koniecznego do pracy produkcyjnej. Układy, formuły, funkcje, dostęp do danych, aktualizacje i wdrażanie są przejmowane przez SchallOS. Dzięki temu znikają również dotychczasowe zależności migrowanej aplikacji od środowiska uruchomieniowego FileMaker.
10. W jaki sposób sztuczna inteligencja jest zintegrowana z systemem SchallOS?
    Sztuczna inteligencja jest dostępna bezpośrednio w edytorze formuł, w funkcjach niestandardowych, kontenerach funkcji oraz w warstwie dokumentacji. Zna nie tylko aktualne pytanie, ale także powiązane pola, tabele, opisy i zależności. W przypadku rozwiązań poddanych migracji dodatkową wiedzą podstawową może być oryginalny skrypt FileMaker. Sztuczna inteligencja potrafi wyjaśniać formuły, generować kod, analizować błędy oraz tworzyć dokumentację. Modele powinny zasadniczo pozostać wymienne, aby można było uwzględnić kwestie jakości, kosztów i ochrony danych.
11. Czy sztuczna inteligencja rzeczywiście programuje kod kontenerów funkcji?
    Tak. Programista opisuje zadanie, parametry, oczekiwany wynik oraz dozwolone funkcje. Na tej podstawie sztuczna inteligencja generuje kod wykonywalny. Kod ten pozostaje widoczny, podlega weryfikacji i można go wersjonować. Programista może zgłaszać zmiany, przeprowadzać testy oraz porównywać lub przywracać wcześniejsze wersje. Sztuczna inteligencja przejmuje w ten sposób znaczną część pracy programistycznej, ale nie ponosi odpowiedzialności merytorycznej. Zwłaszcza w przypadku procesów o kluczowym znaczeniu dla działalności firmy wymagania, uprawnienia i potencjalne skutki uboczne muszą być nadal starannie kontrolowane.
12. Jakie możliwości oferuje edytor formuł?
    Edytor formuł obsługuje typowe obliczenia matematyczne, logiczne, tekstowe, a także obliczenia dotyczące daty i czasu. Formuły i funkcje niestandardowe są obliczane w czasie rzeczywistym i można je natychmiast przetestować. Początkowy zakres poleceń jest mniejszy niż zgromadzony przez lata zbiór funkcji programu FileMaker. Środowisko formuł można jednak rozszerzać. Brakujące funkcje można uzupełnić lub zastąpić własnymi funkcjami niestandardowymi. Również w tym przypadku zintegrowana sztuczna inteligencja może przenosić istniejące formuły FileMaker lub opracowywać nowe obliczenia.
13. Co SchallOS dokumentuje automatycznie?
    Na poziomie struktury rejestrowane są zmiany dotyczące tabel, pól, układów, formuł i kontenerów funkcji. Na poziomie danych można protokołować zmiany rekordów, zmiany statusu, zatwierdzenia, importy oraz inne zdarzenia biznesowe. Do tego dochodzą zdarzenia operacyjne, takie jak wdrożenia, aktualizacje i tworzenie kopii zapasowych. Powiązane prace programistyczne można grupować w sesjach zmian (Change Sessions), a następnie przypisywać je do konkretnej wersji. W ten sposób powstaje przejrzysta historia aplikacji, a nie tylko zbiór notatek sporządzonych po fakcie.
14. Czy SchallOS może na tej podstawie tworzyć raporty dotyczące klientów i wyników?
    Tak. Zintegrowana sztuczna inteligencja może na podstawie zarejestrowanych zdarzeń generować dokumentację techniczną, raporty dla klientów, informacje o aktualizacjach lub zestawienia osiągnięć. Wiele zmian technicznych można w ten sposób podsumować w postaci zrozumiałego opisu korzyści biznesowych. Zdarzenia, na których opiera się dokumentacja, pozostają widoczne, dzięki czemu programista może sprawdzić sformułowania. Nie każda zmiana podlega automatycznemu rozliczeniu. Wybór, ocena i zatwierdzenie ostatecznego protokołu wykonania pozostają zatem w gestii programisty.
15. Jak działa proces aktualizacji?
    Zmiany są najpierw gromadzone w sesjach zmian (Change Sessions) i łączone w jedną wersję (release). Wersja może zawierać nowy SSC, niezbędne migracje SSD, wymagania wstępne, sygnatury, testy oraz informacje dotyczące przywracania do poprzedniego stanu. SchallOS Control sprawdza instancję docelową, tworzy kopię zapasową, a następnie przeprowadza aktualizację. Po instalacji sprawdzane jest, czy struktura, dane i kluczowe funkcje odpowiadają oczekiwanemu stanowi. Ten sam podstawowy proces jest stosowany zarówno w przypadku samego SchallOS, jak i rozwiązań dla klientów opracowanych w oparciu o ten system.
16. Czym różnią się Runtime, Control i Cloud?
    SchallOS Runtime uruchamia opublikowane aplikacje oraz udostępnia układy, formuły i kontenery funkcji. SchallOS Control zarządza instancjami, adapterami baz danych, profilami środowiska uruchomieniowego, aktualizacjami i kontrolami technicznymi. SchallOS Cloud oferuje środowisko uruchomieniowe i przechowywanie danych jako scentralizowaną usługę SaaS. SchallOS Studio pozostaje właściwym środowiskiem programistycznym. Wszystkie obszary wykorzystują te same podstawowe struktury SSC i SSD, ale pełnią wyraźnie oddzielone od siebie zadania w ramach cyklu życia aplikacji.
17. W jaki sposób chronione są prawa, instalacje i dane wrażliwe?
    Uprawnienia użytkowników określają, jakie czynności merytoryczne dana osoba może wykonywać w ramach rozwiązania. Profile uruchomieniowe i profile możliwości dodatkowo określają, jakie funkcje techniczne posiada dana instalacja. Pakiety SSC i SSD można zabezpieczyć za pomocą identyfikatorów, sum kontrolnych i podpisów. Można również ograniczyć kontekst sztucznej inteligencji, tak aby nie przetwarzano automatycznie wszystkich danych klientów. W przypadku szczególnie wrażliwych środowisk można wykorzystać własne serwery lub, w przyszłości, również lokalne modele sztucznej inteligencji. Konkretna konfiguracja zabezpieczeń zależy od danego przypadku zastosowania.
18. Kiedy ma być dostępny SchallOS?
    Publiczne uruchomienie planowane jest na jesień 2026 roku. Na początku uwaga skupi się na Studio i Runtime, rozdzieleniu SSC i SSD, migracji istniejących struktur FileMaker, formułach, funkcjach niestandardowych, kontenerach funkcji programowanych przez sztuczną inteligencję, dokumentacji, protokołach zdarzeń, wdrażaniu i aktualizacjach. Również SchallOS Control odegra kluczową rolę w zarządzaniu instalacjami. Nie każda funkcja planowana w perspektywie długoterminowej musi być w pełni rozwinięta już w momencie uruchomienia. Na początek decydujące znaczenie ma niezawodny rdzeń dla pierwszych aplikacji produkcyjnych.

Aktualne artykuły na temat sztuki i kultury

Jak wyglądała Syria przed wojną? Kto rządzi dzisiaj? Co to oznacza dla uchodźców w Niemczech?

Jak wyglądała Syria przed wojną? Kto rządzi dzisiaj? Co to oznacza dla uchodźców w Niemczech?

Dieter Bohlen prostym językiem: Dlaczego Niemcy upadają z powodu własnej biurokracji?

Dieter Bohlen prostym językiem: Dlaczego Niemcy upadają z powodu własnej biurokracji?

Teoria gier wyjaśnia 25 lat geopolityki: jak Europa straciła swoją strategiczną rolę

Teoria gier wyjaśnia 25 lat geopolityki: jak Europa straciła swoją strategiczną rolę

Tatarzy Krymscy - historia, pochodzenie i teraźniejszość zapomnianego ludu

Tatarzy Krymscy - historia, pochodzenie i teraźniejszość zapomnianego ludu