No desenvolvimento de uma aplicação empresarial, o foco recai inicialmente nas tarefas visíveis. São criadas tabelas, definidas relações, concebidos formulários de introdução de dados e automatizados os processos operacionais. Assim que os primeiros utilizadores conseguem trabalhar com a solução, parece que grande parte do projeto está concluída. No entanto, é na utilização prática que se inicia a fase mais exigente a longo prazo. Uma aplicação utilizada para fins empresariais tem de ser mantida, ampliada e adaptada a novos requisitos. As alterações têm de ser documentadas, as novas versões distribuídas e os dados existentes transferidos de forma segura. A isto acrescentam-se os diferentes direitos de utilizador, as cópias de segurança, as análises de erros e a questão de saber se uma solução deve ser operada localmente, num servidor próprio ou na nuvem.
Muitas plataformas de desenvolvimento concentram-se sobretudo na criação da própria aplicação. Para atualizações, documentação, implementação e operação, são posteriormente adicionadas ferramentas adicionais e procedimentos específicos. Com o tempo, surge um ambiente técnico composto por muitos componentes separados entre si, que só pode ser mantido coeso com um esforço considerável. Por isso, a SchallOS adota uma abordagem mais abrangente. A plataforma pretende acompanhar uma aplicação empresarial não só durante a sua criação, mas ao longo de todo o seu ciclo de vida: desde o desenvolvimento, passando pela documentação e implementação, até às atualizações e à operação contínua.
Da migração do FileMaker para a nossa própria plataforma
O ponto de partida inicial do SchallOS foi a migração das soluções FileMaker existentes. Ao longo de décadas, o FileMaker provou ser um ambiente eficaz para aplicações de bases de dados específicas. Em particular, a estreita ligação entre o modelo de dados, o layout e a lógica do programa permite um desenvolvimento rápido e orientado para a prática.
No entanto, uma solução FileMaker já consolidada é muito mais do que tabelas e máscaras visíveis. Inclui cálculos, scripts, direitos de utilizador, layouts de impressão, interfaces e inúmeros casos operacionais específicos. Uma plataforma sucessora viável tem de integrar estas interligações e, posteriormente, ser capaz de as gerir de forma independente.
A partir desta tarefa, o SchallOS evoluiu gradualmente para se tornar uma plataforma autónoma. Deverá ser possível migrar as soluções FileMaker existentes e, ao mesmo tempo, desenvolver novas aplicações diretamente no SchallOS. Após a migração completa, o FileMaker deixará de ser necessário para o funcionamento em produção.
O desenvolvimento, o tempo de execução e a operação permanecem separados
A plataforma de desenvolvimento SchallOS é composta por várias áreas com funções bem definidas.
- SchallOS Studio é o ambiente de desenvolvimento. É aí que são criadas estruturas de dados, layouts, fórmulas, funções, linguagens e versões. O assistente de migração para soluções FileMaker existentes também faz parte do Studio.
- SchallOS Runtime executa aplicações publicadas. Fornece a interface do utilizador e a lógica de programa necessária, sem disponibilizar automaticamente todas as ferramentas de desenvolvimento.
- SchallOS Control gere os destinos de implementação, as ligações à base de dados, os perfis de execução, as atualizações e as verificações técnicas.
- SchallOS Cloud fornece aplicações como um serviço online gerido centralmente. Não se pretende, com isso, criar um formato de nuvem separado. As instalações locais, baseadas em servidor e baseadas na nuvem utilizam a mesma arquitetura de solução de base.
Esta separação impede que o desenvolvimento, a aplicação e a administração se misturem de forma descontrolada. Ao mesmo tempo, todas as áreas permanecem tecnicamente coordenadas entre si.
Uma solução para diferentes modelos operacionais
Uma aplicação empresarial pode começar em pequena escala e crescer posteriormente. Inicialmente, poderá bastar um único computador local. Mais tarde, serão adicionados mais colaboradores, um servidor central ou várias localizações. Por isso, o SchallOS deve poder fornecer a mesma solução básica para diferentes modalidades de funcionamento: localmente no navegador, como aplicação para Windows ou macOS, com SQLite ou PostgreSQL, bem como como solução SaaS na nuvem.
Nem todos os tipos de exploração possuem as mesmas características técnicas. Uma base de dados local apresenta requisitos diferentes dos de um sistema centralizado multiutilizador. No entanto, o que é fundamental é que os layouts, as funções e o modelo de dados não tenham de ser totalmente desenvolvidos de novo para cada objetivo.
O ciclo de vida faz parte da arquitetura
No SchallOS, a documentação, os registos de eventos e as atualizações não são simplesmente adicionados posteriormente a uma aplicação já concluída. Fazem parte da arquitetura básica. A estrutura e os dados produtivos são geridos separadamente. As alterações de desenvolvimento podem ser registadas e agrupadas em versões. As atualizações podem ser verificadas, distribuídas e, em caso de problemas, revertidas de forma controlada. A IA integrada não só presta apoio nas fórmulas e funções, como também na documentação e na comunicação com os clientes.
Desta forma, o SchallOS integra áreas que, em projetos tradicionais, são frequentemente tratadas separadamente. O desenvolvimento de uma aplicação já não é o fim do processo técnico, mas sim a primeira fase de um ciclo de vida planeado a longo prazo.
SSC e SSD como contentores portáteis de estrutura e dados
Muitas aplicações de bases de dados armazenam a estrutura, a interface do utilizador, a lógica do programa e os dados produtivos numa unidade estreitamente interligada. Isto é prático no início, mas dificulta atualizações posteriores, migrações e diferentes modos de funcionamento. Assim que surgem vários clientes, bases de dados de maior dimensão ou extensões personalizadas, a substituição de um ficheiro de aplicação completo torna-se rapidamente problemática.
Por isso, o SchallOS separa, por princípio, a descrição de uma solução dos seus dados empresariais. Uma aplicação é constituída, na sua essência, por dois contentores interligados: o SSC, para a estrutura, e o SSD, para os dados produtivos.
Ambos os contentores constituem, em conjunto, a solução completa, mas desempenham funções diferentes. O SSC descreve a estrutura e o funcionamento da aplicação. O SSD contém os conteúdos que são gerados durante a sua utilização.
O SSC descreve a aplicação
O ficheiro SSC é o contentor de estrutura portátil de uma solução SchallOS. Nele encontram-se, entre outros:
- Definições de tabelas e campos
- Relações
- Layouts e objetos de layout
- Fórmulas e funções personalizadas
- Contenedor funcional
- Acionadores e navegação
- Informações sobre idiomas e tradução
- Documentação
- Informações sobre versões e lançamentos
O SSC não contém, portanto, os próprios clientes, artigos, encomendas ou faturas. Define quais as estruturas de dados existentes, como são apresentadas e quais as funções que com elas trabalham. O significado semântico de uma solução também faz parte deste contentor. Além do seu nome técnico, um campo pode incluir uma descrição funcional, traduções, regras de validação e indicações para a camada de IA. Desta forma, a estrutura torna-se não só legível por máquinas, mas também mais compreensível para os programadores, para a documentação e para a migração.
O SSC constitui, assim, um modelo de aplicação portátil, que pode ser aperfeiçoado e publicado independentemente de um conjunto de dados específico.
O SSD contém os dados operacionais
O ficheiro SSD é o contentor de dados da solução. Contém os registos de dados gerados no funcionamento diário, por exemplo, clientes, propostas, encomendas, faturas, movimentos de armazém ou compromissos. Além disso, é possível armazenar aí históricos específicos e eventos de dados. Entre estes contam-se, por exemplo, alterações de estado, aprovações, importações ou alterações em campos particularmente importantes. A designação SSD não se refere a um suporte físico de dados, mas sim ao nível lógico de dados da aplicação. A forma como estes dados são tecnicamente armazenados depende da implementação e do adaptador de base de dados selecionados.
Para um computador individual local, pode utilizar-se o IndexedDB. Uma aplicação de secretária pode funcionar com o SQLite, enquanto as aplicações multiutilizador de maior dimensão utilizam o PostgreSQL. Em todos os casos, o SSD continua a ser o contentor de dados funcional, mesmo que o armazenamento técnico seja diferente.
Dois contentores têm de pertencer claramente ao mesmo conjunto
A separação entre estrutura e dados não deve levar à combinação arbitrária de contentores entre si. O SchallOS deve poder verificar se um SSC e um SSD pertencem efetivamente à mesma solução e se as respetivas versões são compatíveis entre si. Para tal, podem ser utilizados identificadores de solução, identificadores de contentor, versões de estrutura, somas de verificação e assinaturas. Desta forma, antes do arranque ou de uma atualização, é possível determinar se a combinação é válida e se as migrações de dados necessárias já foram realizadas.
Esta verificação impede, por exemplo, que o contentor de estrutura de outra aplicação seja aberto acidentalmente com um conjunto de dados em produção. Além disso, evita que uma nova versão do SSC seja ativada, mesmo que o SSD ainda não tenha sido preparado com a estrutura de dados necessária para o efeito.
Portabilidade entre diferentes formas de exploração
A separação entre SSC e SSD cria as bases para a execução de uma aplicação em diferentes ambientes. Não é necessário desenvolver de novo layouts, fórmulas e lógica funcional para cada adaptador de base de dados.
Uma solução pode começar localmente com o IndexedDB, ser posteriormente transferida para o SQLite e, à medida que o número de utilizadores for aumentando, ser migrada para o PostgreSQL. É igualmente possível a transição para um ambiente na nuvem.
Essa transição continua a ser um processo técnico controlado. As diferentes bases de dados têm as suas próprias possibilidades e limitações. Por isso, os dados não são simplesmente transferidos para outro sistema com um simples clique. A transferência, a verificação e, se for caso disso, a reversão têm de ser realizadas de forma explícita.
No entanto, a arquitetura garante que uma mudança no modelo de armazenamento de dados não implique automaticamente a recriação de toda a aplicação.
Atualizações sem substituição dos dados dos clientes
Uma vantagem essencial desta separação torna-se evidente nas novas versões. As alterações dizem frequentemente respeito a layouts, fórmulas, funções ou ao modelo de dados. Os dados empresariais existentes devem, no entanto, permanecer inalterados.
Um programador pode, por isso, lançar uma nova versão do SSC, enquanto o SSD do cliente permanece no local de instalação. Se forem necessários novos campos ou tabelas, estes são adicionados através de etapas de migração definidas. Antes da atualização, é possível efetuar uma cópia de segurança do estado atual. Em seguida, são verificadas a estrutura, a migração de dados e a funcionalidade. Só quando o SSC e o SSD voltarem a apresentar um estado consistente é que a atualização é considerada concluída.
Esta capacidade de atualização não se destina apenas ao próprio SchallOS. Está também disponível para as soluções personalizadas desenvolvidas com o SchallOS.
As variantes personalizadas mantêm-se rastreáveis
O software empresarial personalizado evolui frequentemente de forma diferente consoante os clientes. Um cliente necessita de campos próprios, outro de layouts adicionais ou de uma interface específica. Sem uma estrutura clara, isso leva rapidamente à criação de cópias completas que divergem entre si, as quais se tornam difíceis de manter em conjunto. No SSC, por outro lado, os componentes gerais do produto e as extensões específicas do cliente podem ser versionados e documentados de forma rastreável.
A arquitetura não tira ao programador a responsabilidade de decidir qual a adaptação que deve ser integrada no produto geral. No entanto, garante que a origem e as dependências de uma alteração permaneçam visíveis.
Juntamente com os protocolos de desenvolvimento e as versões lançadas, é mais fácil identificar, em atualizações posteriores, quais os componentes que têm de ser substituídos, complementados ou mantidos.
O multilinguismo faz parte da estrutura portátil
A camada linguística também está integrada no SSC. As designações não são armazenadas exclusivamente de forma fixa em objetos de layout individuais, mas podem remeter para entradas semânticas com várias versões linguísticas.
Um campo como „Número da fatura“ pode, assim, ser apresentado em diferentes idiomas, sem ser necessário criar um layout totalmente novo para cada idioma. Uma solução FileMaker migrada pode ser automaticamente adaptada para vários idiomas e traduzida durante a migração.
A tradução automática não substitui uma revisão especializada. É precisamente necessário verificar os termos jurídicos e específicos do setor. No entanto, a arquitetura do sistema garante que o multilinguismo faça parte da solução desde o início e não tenha de ser incorporado posteriormente, com grande esforço, em cada máscara.
Base para a manutenção a longo prazo
À primeira vista, o SSC e o SSD parecem ser apenas uma simples divisão entre a aplicação e os dados. Na realidade, porém, constituem a base para a portabilidade, as atualizações, os diferentes adaptadores de bases de dados, as cópias de segurança separadas e os diversos modelos operacionais.
O SSC descreve o que é uma solução e como funciona. O SSD contém o que é gerado durante a sua utilização e que deve ser conservado de forma permanente para a respetiva empresa.
Graças a esta separação clara, a aplicação pode continuar a evoluir sem que seja necessário substituir toda a base de dados a cada nova versão. Ao mesmo tempo, a gestão técnica dos dados pode expandir-se ou sofrer alterações sem que seja necessário reconstruir completamente os layouts e a lógica de negócio.
O SchallOS Studio como ambiente de desenvolvimento integrado
O SchallOS Studio é a área da plataforma onde são criadas novas aplicações empresariais e onde as soluções FileMaker existentes são migradas ou aperfeiçoadas. É aí que são geridas tabelas, campos, relações, layouts, fórmulas, funções, idiomas e versões, num ambiente comum.
Para os programadores FileMaker, o modo de funcionamento básico deverá parecer-lhes familiar. As alterações não são efetuadas exclusivamente em ficheiros de código-fonte abstratos, mas permanecem ligadas aos componentes visíveis da aplicação. Um programador pode editar um layout, selecionar um campo, alterar as suas propriedades e verificar imediatamente o impacto dessa alteração na aplicação.
No entanto, o SchallOS não pretende reproduzir o FileMaker na íntegra. São adotadas, sobretudo, as ideias básicas que já deram provas da sua eficácia: desenvolvimento rápido, feedback imediato e uma ligação estreita entre o modelo de dados, a interface do utilizador e a lógica de negócio. A base técnica, por outro lado, é reorganizada e orientada para estruturas portáteis, programação apoiada por IA, documentação e publicações controladas.
Disposições, objetos e propriedades
Uma componente essencial do SchallOS Studio é o modo de layout. É aí que são criados os formulários de introdução de dados, as listas, as caixas de diálogo, as áreas de navegação e outros elementos da interface de uma solução.
Entre os possíveis objetos de layout encontram-se, entre outros, campos, textos, botões, objetos de lista, áreas de separadores, popovers, contentores e elementos de navegação. Os objetos podem ser selecionados, posicionados e configurados através de um inspetor.
Um objeto de layout não contém apenas informações sobre tamanho, posição e apresentação. Pode também estar associado a fontes de dados, gatilhos, fórmulas, funções e designações semânticas. Um objeto de campo, por exemplo, remete para um campo no modelo de dados, pode receber um rótulo dependente do idioma e acionar determinadas funções ao ser selecionado ou ao deixar de estar selecionado.
Uma vez que cada objeto faz parte do SSC, as alterações de layout podem ser versionadas, documentadas e, posteriormente, distribuídas de forma seletiva através de uma atualização. A interface do utilizador não se mantém, assim, como um nível gráfico isolado, mas sim como uma componente estruturada de toda a aplicação.
Modelo de dados e descrições semânticas
As tabelas, os campos e as relações também são criados e editados no SchallOS Studio. É possível criar aplicações novas na íntegra nesta plataforma. Numa migração FileMaker, o assistente de migração importa as estruturas existentes, na medida do possível, e disponibiliza-as posteriormente para edição posterior.
No SchallOS, um campo não se resume apenas a um nome técnico e a um tipo de dados. Pode ainda incluir uma descrição funcional, regras de validação, valores predefinidos, traduções e notas de documentação.
Estas informações têm várias finalidades. Facilitam a compreensão da solução por parte de outros programadores, apoiam a documentação automática e fornecem um melhor contexto à IA integrada. Em vez de se limitar a reconhecer que um campo se chama „Estado“, a plataforma pode, por exemplo, saber se se trata do estado de uma encomenda, do estado de um pagamento ou de um estado de processamento interno.
É também possível descrever as relações entre tabelas e documentá-las no seu contexto funcional. Desta forma, há menos conhecimento que fica exclusivamente na mente do programador original.
Fórmulas com cálculo em tempo real
O SchallOS dispõe de um ambiente próprio para fórmulas. As fórmulas são criadas no editor de fórmulas e calculadas em tempo real durante a edição. Desta forma, as alterações numa expressão podem ser verificadas imediatamente com valores de teste adequados ou com o conjunto de dados atual.
A linguagem de fórmulas suporta os cálculos típicos necessários nas aplicações empresariais. Entre estes incluem-se operações matemáticas, processamento de texto, cálculos de data e hora, condições lógicas, referências a campos, variáveis e expressões aninhadas.
O conjunto de comandos disponível é, numa primeira fase, mais reduzido do que o conjunto de funções do FileMaker, que foi sendo ampliado ao longo de décadas. O SchallOS não tem de reproduzir, na íntegra, todos os comandos históricos do FileMaker. O mais importante é dispor de um ambiente de fórmulas claramente estruturado e expansível.
Podem ser adicionados comandos adicionais posteriormente, caso sejam necessários para determinadas soluções ou migrações. A IA integrada também pode ajudar a transferir um cálculo existente ou a desenvolver uma função em falta, de forma adequada à arquitetura do SchallOS.
Funções personalizadas para cálculos reutilizáveis
Para além dos comandos integrados, o SchallOS suporta funções personalizadas. Estas aceitam parâmetros, executam um cálculo definido e devolvem um resultado. Desta forma, é possível gerir regras recorrentes num único local central. Exemplos disso são cálculos de preços, determinação de prazos, formatações, verificações de séries numéricas ou o processamento de valores importados.
As funções personalizadas também são calculadas em tempo real e podem ser testadas imediatamente no editor de fórmulas. Se uma função for corrigida ou ampliada posteriormente, todas as fórmulas que a utilizam beneficiam dessa alteração.
Além disso, é possível descrever e documentar funções próprias. Desta forma, os parâmetros, o valor de retorno, os exemplos e os casos de erro conhecidos permanecem compreensíveis. O conjunto de funções de uma solução transforma-se numa biblioteca reutilizável, em vez de consistir em inúmeros cálculos individuais copiados.
Contenedores funcionais para processos mais complexos
Os processos empresariais mais complexos são organizados no SchallOS através de contentores de funções. É possível, por exemplo, criar registos de dados, verificar valores, controlar caixas de diálogo, gerar documentos ou aceder a interfaces externas. Um contentor de funções não contém apenas o código executável. Inclui também uma descrição técnica, parâmetros de entrada, valores de retorno, dependências, capacidades permitidas e operações expressamente excluídas.
Vários objetos de layout podem utilizar o mesmo contentor de funções. Desta forma, não é necessário criar de novo uma função para emitir uma fatura para cada botão ou layout.
No caso de soluções migradas, os scripts FileMaker existentes podem ser mantidos em segundo plano como uma camada de aprendizagem e referência. Ajudam a compreender a intenção original e o fluxo de trabalho anterior. No entanto, o novo código executável é gerado de acordo com a arquitetura do SchallOS.
Migração e desenvolvimento de novas funcionalidades no mesmo ambiente
O SchallOS Studio não se destina exclusivamente a soluções FileMaker já existentes. É possível criar novas aplicações inteiramente dentro da plataforma.
Durante uma migração, o assistente começa por importar as tabelas, campos, relações, layouts e outros componentes identificáveis existentes. Posteriormente, os programadores podem verificar a estrutura importada, corrigi-la e transferi-la gradualmente para a nova arquitetura funcional.
O objetivo não é criar uma cópia inalterada de todas as particularidades anteriores. Os desvio que surgiram ao longo do tempo podem ser revistos e substituídos por estruturas mais claras. Ao mesmo tempo, o conhecimento técnico da solução existente é preservado.
As aplicações novas e as que foram migradas utilizam, posteriormente, as mesmas ferramentas, contentores e canais de publicação.
As alterações são transformadas em versões controladas
Uma alteração no estúdio não se traduz automaticamente numa atualização produtiva. Durante o desenvolvimento, podem existir layouts inacabados, fórmulas provisórias ou funcionalidades ainda não testadas.
As alterações relacionadas podem, por isso, ser registadas em «Change Sessions» e posteriormente atribuídas a uma versão. Só após a verificação e aprovação é que se obtém uma versão SSC publicada.
Além da nova estrutura, uma versão pode incluir as migrações de dados necessárias, informações sobre a versão, dependências, etapas de verificação e documentação. Desta forma, o desenvolvimento propriamente dito permanece claramente separado da implementação em instâncias de tempo de execução produtivas.
O SchallOS Studio não é, portanto, apenas o local onde uma aplicação é concebida e programada. Ele integra o desenvolvimento visual, o modelo de dados, as fórmulas, as funções, a documentação e a publicação num único ambiente.
A proximidade familiar entre o programador e a aplicação visível mantém-se. Ao mesmo tempo, cria-se uma base técnica sobre a qual as soluções podem continuar a ser desenvolvidas de forma portátil, compreensível e com capacidade de manutenção a longo prazo.
A IA na origem das fórmulas e funções
Até agora, em muitos ambientes de desenvolvimento, a inteligência artificial tem sido disponibilizada principalmente através de uma janela de chat adicional. O programador descreve um problema, copia o código-fonte ou fórmulas para o chat e, em seguida, transfere o resultado de volta para o projeto. Nesse processo, faltam frequentemente ao modelo de linguagem informações importantes sobre tabelas, campos, relações e o significado técnico da aplicação.
Por isso, o SchallOS integra a IA diretamente nas ferramentas de desenvolvimento. Esta fica disponível nos locais onde se editam fórmulas, funções personalizadas e contentores de funções. Desta forma, não recebe apenas uma única pergunta, mas também o contexto atual da solução.
No editor de fórmulas, por exemplo, a IA conhece a expressão que está a ser editada, os campos disponíveis e o tipo de resultado esperado. Dentro de um contentor de funções, pode ainda aceder à sua descrição, parâmetros, capacidades e dependências.
A IA não se torna, assim, um programa auxiliar independente, mas sim parte integrante do próprio ambiente de desenvolvimento.
Suporte no editor de fórmulas
As fórmulas controlam inúmeros processos de uma aplicação empresarial. Calculam preços, verificam condições, determinam prazos ou influenciam a apresentação de objetos de layout. A IA integrada pode, no editor de fórmulas, entre outras coisas:
- explicar uma fórmula existente
- analisar possíveis erros
- Complementar as condições
- simplificar uma expressão
- transferir uma fórmula FileMaker
- ou criar um novo cálculo a partir de uma descrição técnica.
Um programador poderia, por exemplo, definir que as encomendas acima de um determinado valor líquido necessitem de uma aprovação adicional, desde que não exista um contrato-quadro. A IA pode criar uma fórmula a partir disso, recorrendo aos campos existentes na solução. O resultado permanece visível como uma fórmula normal. Pode ser lido, alterado e calculado em tempo real. A IA não cria, assim, nenhum processo oculto cujo comportamento fosse difícil de compreender.
Se faltar um comando necessário, a IA também pode ajudar a criar uma função personalizada adequada ou uma extensão do ambiente de fórmulas. Desta forma, o conjunto de comandos do SchallOS, inicialmente mais reduzido, mantém-se expansível.
Funções personalizadas com base em especificações técnicas
Os cálculos recorrentes podem ser geridos de forma centralizada como funções personalizadas. A IA pode criar, a partir de uma descrição, uma função com parâmetros únicos, um valor de retorno e um comportamento documentado.
Uma função deste tipo poderia, por exemplo, calcular prazos de desconto, verificar intervalos de números ou uniformizar valores importados. Para além da impressão propriamente dita, também é possível criar valores de teste, exemplos e possíveis casos de erro.
Isso não facilita apenas a programação inicial. No caso de uma alteração posterior, a IA consegue identificar qual é o significado da função e em que pontos é utilizada.
Assim, um cálculo anónimo passa a ser uma componente documentada e reutilizável da solução.
Contentores de funções como lógica de programa descrita
No SchallOS, os processos mais complexos são organizados através de contentores de funções. Um contentor de funções pode, por exemplo, criar registos de dados, verificar entradas, controlar caixas de diálogo, gerar documentos ou aceder a interfaces externas. A base é constituída por uma descrição estruturada. Esta pode definir:
- qual é a função que essa função desempenha
- quais os parâmetros que são passados
- qual é o resultado esperado
- a que tabelas e campos é permitido aceder
- quais as outras funções que são utilizadas
- e quais os procedimentos que estão expressamente excluídos.
Com base nestas especificações, a IA programa o código executável do contentor de funções. Assim, o programador já não precisa de compor o fluxo de trabalho exclusivamente a partir de inúmeras etapas individuais de script. A sua tarefa passa a centrar-se mais na descrição precisa da função pretendida, nos seus limites e na verificação subsequente.
No entanto, o código gerado permanece visível. Pode ser lido, testado, revisto e comparado entre diferentes versões. As versões anteriores também podem ser guardadas e recuperadas, se necessário. A IA assume, assim, a programação, mas não a responsabilidade técnica.
Os guiões FileMaker como base de aprendizagem
No caso de soluções FileMaker migradas, os scripts existentes contêm frequentemente uma grande parte da lógica de negócio desenvolvida ao longo dos anos. Estes mostram quais os campos que foram alterados, quais as condições que foram verificadas e quais os outros processos que foram acionados.
Estes scripts não são incorporados de forma permanente no SchallOS como uma camada de execução. Isso faria com que muitas dependências técnicas e soluções alternativas anteriores fossem simplesmente transferidas para o novo sistema. Em vez disso, o script FileMaker original pode ser mantido em segundo plano no contentor de funções correspondente. Este serve à IA como camada de aprendizagem, referência e compreensão.
A IA consegue, a partir disso, deduzir a intenção funcional do fluxo de trabalho anterior. Em seguida, programa o novo código de acordo com a arquitetura do SchallOS. Estruturas históricas, como mudanças frequentes de layout, campos globais ou scripts auxiliares dependentes do contexto, não têm de ser adotadas tal como estão. Só serão mantidas se forem efetivamente necessárias para o processo de negócio propriamente dito.
No entanto, o script original continua a ser uma fonte de conhecimento. Em caso de dúvidas futuras, é possível compreender como um processo foi inicialmente resolvido na solução FileMaker.
As capacidades e os limites são definidos de forma explícita
Um contentor de funções não deve poder aceder a quaisquer áreas da aplicação apenas com base numa descrição geral. Por isso, é possível definir expressamente as capacidades permitidas e as exclusões.
Uma função pode, por exemplo, ter permissão para ler e alterar registos numa determinada tabela, sem poder, ao mesmo tempo, efetuar eliminações ou alterações nas configurações do sistema. Se o código gerado utilizar uma capacidade não autorizada, o SchallOS pode detetar isso e bloquear a execução ou a publicação.
A descrição de um contentor de funções não serve, portanto, apenas para fins de documentação. Torna-se parte integrante do modelo de verificação e segurança. Esta limitação é especialmente importante no caso do código gerado por IA. O modelo de linguagem dispõe de uma margem de manobra clara, enquanto a plataforma verifica se a função gerada se mantém dentro desse quadro.
O contexto adequado melhora os resultados
A qualidade de uma função gerada por IA não depende apenas do tamanho do modelo de linguagem utilizado. O que é decisivo é se o modelo recebe as informações necessárias. O SchallOS consegue compor o contexto a partir de vários níveis:
- a questão atual
- no editor aberto
- no campo ou no contentor de funções selecionado
- as tabelas e relações envolvidas
- fórmulas e funções existentes
- descrições semânticas
- Documentação e histórico de alterações
- bem como, no caso de migrações, o script FileMaker original.
Desta forma, a IA consegue funcionar com muito mais precisão do que no caso de uma consulta isolada num chat geral.
Ao mesmo tempo, não é necessário fornecer a solução completa em todas as tarefas. O contexto pode limitar-se às informações que são efetivamente necessárias para a função em questão.
Modelos intercambiáveis em vez de um compromisso permanente
A camada de IA não deve depender permanentemente de um único modelo ou fornecedor. Tarefas diferentes impõem requisitos distintos em termos de qualidade, velocidade, custos e proteção de dados.
Uma migração complexa pode exigir um modelo particularmente potente. Uma explicação simples ou um ajuste de fórmula podem, eventualmente, ser realizados com um modelo mais pequeno. Para ambientes sensíveis ou fechados, também é possível utilizar, a longo prazo, modelos operados localmente.
A base de conhecimento permanente não reside, portanto, no modelo de linguagem, mas sim na solução SchallOS: nas descrições, estruturas, referências a scripts, código, testes e documentação. O modelo de IA continua a ser uma ferramenta substituível que gera, a partir deste contexto, código executável ou sugestões compreensíveis.
Desenvolvimento compreensível e apoiado pela IA
O SchallOS combina o trabalho direto com aplicações empresariais com a programação apoiada por IA. As fórmulas podem ser explicadas e geradas diretamente. As funções personalizadas são criadas a partir de especificações técnicas reutilizáveis. Os contentores de funções associam descrições semânticas a código visível e verificável.
Nas soluções migradas, os scripts FileMaker são mantidos como uma camada adicional de aprendizagem. Ajudam a compreender os processos empresariais existentes, sem perpetuar dependências técnicas anteriores.
O papel do programador não desaparece por isso. Simplesmente muda. Requisitos precisos, uma arquitetura bem concebida, testes e controlo técnico tornam-se mais importantes do que a introdução manual de cada passo do programa. Especialmente no caso de software crítico para o negócio, esta responsabilidade continua a ser indispensável.
Inquérito atual sobre a utilização de sistemas locais de IA
Documentação e registos de eventos como parte da aplicação
A documentação de uma aplicação empresarial é frequentemente redigida apenas depois de o desenvolvimento já estar concluído. Sob pressão de tempo, o trabalho concentra-se inicialmente em novos campos, layouts, fórmulas e funções. A descrição das alterações deve ser feita posteriormente.
No entanto, à medida que o tempo passa, torna-se mais difícil compreender as decisões iniciais. Muitas vezes, já não se sabe exatamente por que razão uma determinada função foi adicionada, quais os objetos afetados e quais os casos especiais que tiveram de ser tidos em conta. Por isso, o SchallOS não trata a documentação como uma tarefa adicional posterior. As alterações relevantes são registadas como eventos já durante o desenvolvimento e associadas aos componentes afetados da solução.
A partir destas informações, é possível gerar documentação técnica, notas de lançamento, relatórios de clientes ou registos de desempenho. A documentação não se baseia, assim, apenas em recordações ou notas tomadas manualmente, mas sim nas alterações efetivamente realizadas.
Eventos a vários níveis
Uma solução SchallOS não dispõe apenas de um único protocolo geral. A plataforma distingue vários níveis de eventos, cada um com as suas próprias tarefas.
- O Protocolo estrutural regista as alterações no SSC. Estas incluem, por exemplo, novas tabelas e campos, layouts ajustados, fórmulas alteradas ou novos contentores de funções.
- O Registo de eventos de dados Faz parte do SSD. Aí são registados os processos relevantes do ponto de vista técnico durante a utilização em produção, tais como alterações de estado, aprovações, anulações ou alterações a registos de dados importantes.
- A isto acrescentam-se Eventos operacionais do Runtime e do SchallOS Control. Entre estas funções contam-se, nomeadamente, implementações, atualizações, verificações, cópias de segurança e operações de reversão.
Estas áreas permanecem separadas, mas podem ser interligadas. Um registo de desenvolvimento não deve tornar-se confuso devido a alterações quotidianas nos registos de dados dos clientes. Por outro lado, os pormenores técnicos internos não devem, automaticamente, fazer parte do histórico funcional de uma fatura ou de uma encomenda.
O protocolo estrutural mostra a evolução da solução
As alterações em tabelas, campos, layouts, fórmulas e contentores de funções podem ser guardadas como eventos estruturados. Um registo pode indicar qual o objeto que foi alterado, qual era o estado anterior e qual o novo estado resultante. Além disso, é possível registar o nome do responsável, a data, a justificação técnica, a ordem de trabalho associada e a versão de lançamento prevista.
Se, por exemplo, for adicionado um novo processo de aprovação para encomendas, poderão surgir várias alterações técnicas. É criado um campo de estado, um layout é ampliado, uma fórmula é ajustada e é programado um novo contentor de funções.
O registo estrutural guarda estes eventos individuais. Ao mesmo tempo, estes podem ser agrupados sob uma tarefa técnica comum. Desta forma, fica claro que várias alterações técnicas, em conjunto, constituem um novo processo de negócio.
As «Change Sessions» agrupam trabalhos relacionados entre si
Uma tarefa de desenvolvimento consiste frequentemente em muitos pequenos passos. Uma lista meramente cronológica de alterações individuais não representaria de forma adequada o contexto real.
Por isso, o SchallOS pode agrupar tarefas relacionadas em «Change Sessions». Uma «Change Session» descreve uma tarefa concreta, uma extensão ou uma correção de erros e reúne todos os eventos associados. Pode incluir, por exemplo:
- a descrição das funções técnicas
- tabelas e layouts afetados
- fórmulas e funções alteradas
- testes realizados
- questões pendentes
- bem como a atribuição a um cliente ou a uma encomenda.
Várias sessões de alterações podem ser atribuídas posteriormente a uma versão. Desta forma, cria-se uma ligação clara entre a tarefa de desenvolvimento, as alterações técnicas e a versão publicada.
A IA apresenta os eventos técnicos de forma compreensível
A camada de documentação está ligada à IA integrada do SchallOS. Desta forma, os eventos registados podem ser automaticamente adaptados para diferentes grupos-alvo.
Um relatório técnico de desenvolvimento requer informações diferentes das de um comunicado ao cliente. Enquanto o programador pretende ver nomes de campos concretos, contentores de funções e migrações de dados, o cliente está principalmente interessado em saber que função foi adicionada e quais são os benefícios que esta oferece. Por isso, a IA pode resumir os mesmos acontecimentos de diferentes formas:
- como documentação técnica interna
- como informação compreensível para os clientes
- como notas de lançamento
- como relatório de projeto
- ou como comprovativo de pagamento de uma fatura.
Os textos não são criados livremente a partir de uma descrição geral. São derivados das «Change Sessions», das descrições semânticas dos objetos e das alterações estruturais efetivas.
O texto gerado mantém-se ligado às suas fontes. O programador pode verificar em que acontecimentos se baseia uma afirmação e corrigir ou aprovar a formulação antes da sua utilização.
Relatórios de desempenho para programadores e clientes
Para os programadores de software personalizado, a documentação também é importante do ponto de vista económico. Os serviços têm de ser explicados de forma compreensível ao cliente e, frequentemente, são faturados com base no tempo ou no pacote de trabalho.
Na prática, esses registos de prestação de serviços são frequentemente elaborados apenas pouco antes da emissão da fatura. Para tal, é necessário pesquisar e-mails, notas e lembretes.
O SchallOS pode atribuir os eventos de desenvolvimento efetivamente registados a um cliente, projeto ou encomenda. A IA gera, a partir disso, registos adequados para um relatório de prestação de serviços. Várias alterações técnicas podem, por exemplo, ser agrupadas numa única prestação de serviços compreensível:
Ampliação da gestão de encomendas com um processo de aprovação em duas etapas, incluindo verificação do estado, direitos de utilizador e personalização do formulário de introdução de dados.
Os processos técnicos subjacentes continuam a estar disponíveis para consulta. A descrição do cliente constitui apenas um resumo compreensível. A escolha final cabe ao programador. Nem todos os eventos técnicos são automaticamente faturáveis, e os testes ou correções internas não têm de constar individualmente numa fatura.
Eventos ao nível dos dados
Mesmo em ambiente de produção, é possível registar todos os eventos de dados previstos. Entre estes incluem-se a criação e a alteração de registos de dados, mudanças de estado, autorizações, importações, exportações ou processos executados automaticamente. Um registo pode indicar:
- qual o utilizador ou processo que desencadeou a ação
- qual foi o registo afetado
- quais os valores que foram alterados
- qual a função que foi executada
- e se o processo foi concluído com sucesso.
A solução em questão determina quais os eventos que são armazenados e com que nível de detalhe. Uma pequena correção de texto tem um significado diferente da alteração de uma fatura já emitida. O registo de eventos de dados constitui, assim, o histórico técnico do SSD. Este registo apoia o apoio técnico, a análise de erros e a rastreabilidade de processos empresariais importantes.
Um protocolo deste tipo pode também servir de base para requisitos de auditoria. No entanto, é necessário verificar, para cada caso específico, se cumpre todas as exigências legais ou específicas do setor.
A documentação acompanha também os lançamentos e as atualizações
Os eventos de desenvolvimento registados são simultaneamente integrados no pipeline de lançamentos e atualizações. Quando é lançada uma nova versão, o SchallOS consegue identificar automaticamente quais as funcionalidades que foram adicionadas, quais os erros que foram corrigidos e quais as estruturas de dados que foram alteradas. A partir daí, são geradas listas de alterações técnicas, notas para os utilizadores e informações de migração.
Após a instalação, é possível verificar qual a versão que foi instalada numa determinada instância de tempo de execução e quais as alterações que essa versão continha.
Também são documentados eventos operacionais, como backups, testes ou uma eventual reversão. Desta forma, mais tarde é possível determinar não só o que foi desenvolvido, mas também quando e com que resultado uma alteração foi implementada em produção.
Uma base de conhecimentos em expansão
A combinação entre o registo de eventos, as descrições semânticas e o apoio da IA cria, a longo prazo, uma base de conhecimento sobre toda a solução. No caso de uma alteração posterior, não se terá de considerar apenas o código atual. Fica também claro quando uma função foi introduzida, qual foi a razão empresarial subjacente e que outras áreas foram afetadas na altura.
Este conhecimento é decisivo, sobretudo no caso de aplicações empresariais que foram sendo desenvolvidas ao longo de muitos anos. Um caso específico aparentemente supérfluo pode ter uma razão histórica importante. Sem documentação, existe o risco de que seja acidentalmente removido numa revisão posterior. Por isso, o SchallOS não só preserva os estados técnicos, como também o histórico de desenvolvimento e as decisões a ele associadas.
A documentação torna-se, assim, uma componente ativa da aplicação. Apoia o desenvolvimento, a comunicação com os clientes, a faturação, o apoio técnico, os lançamentos e a manutenção a longo prazo – com base nos eventos que ocorreram efetivamente no sistema.
Um fluxo de atualizações a nível de todo o sistema para a plataforma e as aplicações
O software empresarial raramente permanece inalterado durante longos períodos de tempo. Novos requisitos, alterações legislativas, correções de erros e desenvolvimentos técnicos conduzem regularmente ao lançamento de novas versões. Nesse contexto, não basta limitar-se a trocar ficheiros. Antes de cada atualização, é necessário verificar qual é a versão atual, se as estruturas de dados precisam de ser adaptadas e como é possível restaurar o estado anterior em caso de erro.
Em muitas aplicações específicas, esses procedimentos só são criados posteriormente. As atualizações são então distribuídas através de instruções manuais, cópias de segurança e scripts específicos para cada cliente. A cada nova instalação, aumenta o risco de surgirem versões diferentes e soluções específicas.
Por isso, o SchallOS trata as atualizações como uma funcionalidade da plataforma a nível de todo o sistema. Tanto o próprio SchallOS como as soluções para clientes desenvolvidas com a plataforma são atualizadas através do mesmo fluxo de trabalho básico.
Assim, um programador não precisa de criar um processo de atualização próprio para uma nova aplicação. A gestão de versões, a verificação, a distribuição e o registo fazem parte da arquitetura comum desde o início.
A separação entre SSC e SSD protege os dados produtivos
A capacidade de atualização está diretamente relacionada com a separação entre estrutura e dados. O SSC contém layouts, fórmulas, contentores de funções, definições de linguagem e o modelo de dados da aplicação. O SSD contém os dados empresariais produtivos da respetiva empresa.
Por isso, numa nova versão, não é substituída toda a aplicação, incluindo todos os dados dos clientes. Em vez disso, pode ser publicado um novo SSC, enquanto o SSD existente permanece no local de implantação.
Caso a nova estrutura exija campos adicionais, tabelas ou formatos de dados alterados, serão executados passos de migração expressamente definidos para o efeito. Os dados produtivos serão adaptados à nova estrutura de forma controlada e não serão substituídos por outro conjunto de dados sem que se dê por isso.
Esta separação clara permite continuar a desenvolver as aplicações ao longo de muitos anos, sem ter de transferir todos os dados empresariais para um novo ficheiro completo a cada atualização.
Da fase de desenvolvimento ao lançamento
Nem todas as alterações no SchallOS Studio são imediatamente adequadas para utilização em ambiente de produção. Durante o desenvolvimento, podem existir layouts provisórios, funcionalidades incompletas ou fórmulas ainda não testadas.
Por isso, as alterações relacionadas são, numa primeira fase, registadas em «Change Sessions» e atribuídas a um lançamento planeado. Só após verificação e aprovação é que se concretiza uma versão publicada. Um lançamento pode incluir, entre outros:
- um número de versão único
- o SSC atualizado
- Migrações necessárias para SSD
- requisitos técnicos
- Dependências de tempo de execução ou adaptadores
- Etapas de verificação e teste
- Notas de lançamento
- bem como informações para uma eventual reversão.
A camada de documentação fornece a base para isso. A partir dos eventos de desenvolvimento registados, é possível gerar automaticamente listas de alterações técnicas e instruções de utilização claras.
Assim, uma versão não consiste apenas em ficheiros alterados. Descreve também o que foi alterado, quais são os pré-requisitos e como se deve verificar a instalação.
O SchallOS Control controla a distribuição
O SchallOS Control encarrega-se da gestão operacional das atualizações. Nessa plataforma, é possível ver quais as instâncias existentes, quais as versões que foram submetidas ao processo de installier e quais as atualizações disponíveis. Antes da instalação, o Control pode, entre outras coisas, verificar:
- se a entidade de destino está acessível
- qual é a versão do Runtime e do SSC utilizada
- qual é o adaptador de base de dados ativo
- se é possível criar uma cópia de segurança adequada
- e se todos os requisitos da versão estão preenchidos.
Isto impede que seja executada uma atualização numa instalação tecnicamente inadequada ou que não tenha sido devidamente preparada.
Além disso, uma versão não tem de ser distribuída simultaneamente a todos os sistemas. Pode ser implementada, numa primeira fase, num ambiente de teste ou em instalações selecionadas. Só após uma verificação bem-sucedida é que se procede à implementação em maior escala.
Para tal, podem ser previstos diferentes canais de atualização, por exemplo, versões estáveis de produção, versões preliminares, testes internos ou versões específicas para cada cliente.
Assinaturas e versões únicas
Os pacotes de atualização podem incluir somas de verificação e assinaturas digitais. Desta forma, o SchallOS Control consegue determinar se um pacote está completo, se provém da fonte prevista e se sofreu alterações desde a sua publicação.
Além disso, verifica-se se a versão pertence efetivamente à solução em questão. Um novo SSC não pode ser ligado acidentalmente ao SSD de outra aplicação.
Identificadores únicos de soluções, versões de estrutura e versões de modelo de dados garantem que o estado da implementação em fases install permaneça rastreável. Também é possível identificar as etapas intermédias necessárias. Por exemplo, uma instalação não pode passar diretamente de uma versão muito antiga para a versão mais recente se for necessário efetuar previamente uma migração de dados.
Cópia de segurança, migração e verificação
Antes de uma atualização estrutural, o estado atual é guardado. A forma concreta em que isso é feito depende do adaptador de base de dados utilizado. Uma instalação local do IndexedDB ou do SQLite requer procedimentos diferentes dos de um servidor PostgreSQL.
Em seguida, o pacote de atualização é verificado, a nova estrutura install é implementada e, caso seja necessário, é efetuada a migração de dados. Após a ativação, segue-se a verificação. Nesse contexto, o SchallOS pode, por exemplo, verificar:
- se todas as tabelas e campos esperados estão presentes,
- se a migração de dados foi concluída na íntegra,
- se o número de registos e as somas de verificação estão corretos,
- e se as funções importantes estão a ser executadas corretamente.
Só depois de estas verificações terem sido concluídas com sucesso é que a atualização é considerada installiert. A simples transferência de ficheiros não é, portanto, suficiente. O que é decisivo é que a estrutura, os dados e o runtime voltem a constituir, posteriormente, um estado consistente e funcional.
Revertimento em caso de falhas nas atualizações
Apesar de uma preparação cuidadosa, uma atualização pode falhar. Dados antigos inesperados, uma migração com erros ou uma dependência não considerada podem impedir que uma nova versão seja ativada com segurança. Para esses casos, o processo de atualização inclui um rollback. Nesse processo, são restauradas a versão anterior do SSC, o estado do SSD guardado e a configuração anterior.
No entanto, nem todas as atualizações podem ser revertidas por um período ilimitado. Se, após a instalação, já tiverem sido processados novos dados produtivos de acordo com regras alteradas, um retorno completo pode revelar-se problemático. Por isso, uma versão deve definir em que condições é possível efetuar uma reversão.
Em alguns casos, é mais aconselhável efetuar uma atualização corretiva subsequente do que restaurar um conjunto de dados mais antigo. A plataforma disponibiliza o quadro técnico necessário; no entanto, a decisão concreta depende da alteração em questão e da sua relevância técnica.
O próprio SchallOS também utiliza este fluxo de trabalho
O processo de atualização não se destina apenas às soluções dos clientes. O SchallOS Studio, o Runtime, o Control e outros componentes da plataforma também são atualizados através dos mesmos mecanismos básicos. As novas versões da plataforma podem incluir extensões do ambiente de fórmulas, melhorias na camada de IA, novos adaptadores de bases de dados ou correções de segurança. Também neste caso são necessárias informações sobre versões, dependências, assinaturas e verificações.
Desta forma, a infraestrutura é utilizada e testada continuamente durante o funcionamento da própria plataforma. As aplicações desenvolvidas com o SchallOS beneficiam dos mesmos processos.
O programador não recebe, assim, uma função de atualização meramente teórica, mas sim um fluxo de trabalho que faz parte, simultaneamente, do funcionamento e do desenvolvimento contínuo de todo o sistema.
Um caminho previsto para versões futuras
O ponto forte do pipeline de atualizações não reside apenas na distribuição automática de novos ficheiros. O que é decisivo é a integração do desenvolvimento, da documentação, do backup, da migração, da verificação e da reversão num único processo comum.
O próprio SchallOS e as aplicações desenvolvidas com ele utilizam a mesma infraestrutura básica. A separação entre o SSC e o SSD garante que a estrutura possa continuar a evoluir, ao mesmo tempo que os dados produtivos são protegidos e adaptados de forma controlada.
Uma solução desenvolvida com o SchallOS dispõe, assim, desde o início, de um caminho previsto para versões futuras. Especialmente no caso do software empresarial, que se destina a ser utilizado durante muitos anos, esta capacidade de atualização não é uma funcionalidade adicional, mas sim um requisito essencial para uma manutenção duradoura e um funcionamento fiável.
Runtime, Control e Cloud para diferentes modelos operacionais
Um ambiente de desenvolvimento requer funcionalidades abrangentes. Os programadores têm de poder alterar estruturas, criar layouts, editar fórmulas e publicar novas funcionalidades. Por outro lado, no funcionamento quotidiano de uma aplicação empresarial já concluída, estas ferramentas não são, na maioria das vezes, necessárias.
Por isso, o SchallOS divide o desenvolvimento, a execução e a gestão em áreas distintas. O SchallOS Studio destina-se ao desenvolvimento. O SchallOS Runtime executa as aplicações publicadas. O SchallOS Control gere a sua implementação técnica. O SchallOS Cloud disponibiliza a mesma arquitetura básica como um serviço online gerido centralmente.
Neste contexto, não são criadas aplicações independentes umas das outras. Todas as áreas funcionam com as mesmas estruturas SSC e SSD. O modo de funcionamento é definido através da implementação, do adaptador de base de dados e do perfil de tempo de execução.
O SchallOS Runtime executa as soluções publicadas
O SchallOS Runtime liga o SSC de uma aplicação ao SSD correspondente e disponibiliza os layouts, fórmulas e funções nele definidos. O ambiente de execução inclui, entre outros aspetos, a apresentação e o manuseamento dos layouts, a leitura e edição de registos de dados, o cálculo de fórmulas e funções personalizadas, a execução de contentores de funções, a navegação e o controlo de caixas de diálogo, o suporte multilingue, bem como a ligação ao adaptador de base de dados previsto.
No entanto, o Runtime não inclui automaticamente todas as ferramentas do SchallOS Studio. Não permite criar novos pares de soluções SSC/SSD e não dispõe de um assistente de migração para soluções FileMaker.
Desta forma, uma aplicação do cliente já entregue permanece claramente separada do ambiente de desenvolvimento propriamente dito.
Os perfis determinam as capacidades de um ambiente de execução
Nem todas as instalações necessitam do mesmo conjunto de funcionalidades. Uma aplicação destinada exclusivamente ao utilizador final poderá ter de executar apenas layouts e processos de negócio publicados. Uma instalação interna poderá necessitar de funcionalidades adicionais de gestão ou diagnóstico.
Para tal, o SchallOS utiliza perfis de tempo de execução e de capacidades. Estes definem quais as capacidades técnicas de que uma instância concreta dispõe.
Um perfil pode, por exemplo, determinar se o modo de layout está disponível, se é permitido importar ou exportar dados, se são apresentadas caixas de diálogo administrativas, se é possível alterar as definições locais ou se é permitido utilizar determinadas interfaces.
Estes perfis complementam os direitos de utilizador no âmbito da solução propriamente dita. Os direitos de utilizador determinam o que uma pessoa pode fazer do ponto de vista funcional. O perfil de tempo de execução, por sua vez, define quais as possibilidades técnicas que a respetiva instalação disponibiliza, em princípio.
Desta forma, é possível utilizar a mesma base de tempo de execução para diferentes grupos de clientes e casos de utilização, sem ter de desenvolver uma versão do programa específica para cada variante.
Desde um computador individual local até ao funcionamento em servidor
Uma solução SchallOS pode ser implementada em diferentes modos de funcionamento. Para um computador individual local, por exemplo, o SSD pode ser armazenado no IndexedDB. Uma aplicação de ambiente de trabalho em install pode utilizar o SQLite. Para soluções multiutilizador de maior dimensão, está prevista uma base de dados central, como o PostgreSQL.
Os modelos de funcionamento apresentam características diferentes. O IndexedDB é especialmente adequado para aplicações locais de navegador. O SQLite é uma base comprovada para aplicações locais e instalações de dimensão reduzida. O PostgreSQL é ideal para sistemas centrais multiutilizador com gestão profissional de servidores.
O SchallOS não trata estas tecnologias como locais de armazenamento totalmente intercambiáveis. A mudança de adaptador requer uma transferência controlada de dados, uma verificação e, se necessário, uma reversão. A arquitetura conjunta SSC/SSD garante que os layouts, as fórmulas e a lógica de negócio não tenham de ser totalmente redesenvolvidos para cada adaptador de base de dados.
Aplicações de secretária e navegação na Internet
As soluções SchallOS devem poder ser executadas tanto no navegador como em aplicações instaláveis para Windows e macOS. Um ambiente de execução para computador pode integrar-se mais profundamente no respetivo sistema operativo, utilizar ficheiros locais de forma controlada e, com a configuração adequada, funcionar temporariamente offline. Pode armazenar os seus dados localmente com o IndexedDB ou o SQLite, ou aceder a uma base de dados PostgreSQL central.
No navegador, a aplicação é apresentada pelo próprio SchallOS Runtime. Para tal, não é necessário nem o servidor FileMaker nem o FileMaker WebDirect. Assim, após a migração, uma solução FileMaker já não funciona com base num ficheiro FileMaker em segundo plano. Os layouts, as fórmulas e a lógica funcional são executados no âmbito da arquitetura SchallOS.
O SchallOS Control gere as instâncias
O SchallOS Control constitui o centro de controlo operacional da plataforma. É aí que se gere qual a solução que está a ser executada em cada sistema de destino e quais os requisitos técnicos aplicáveis. O Control pode, entre outras coisas, apresentar:
- quais os pares SSC/SSD que foram disponibilizados
- qual é a versão do Runtime installiert
- qual o adaptador de base de dados que está a ser utilizado
- qual é o perfil de competências aplicável
- quais são as atualizações disponíveis
- e quando uma instância foi verificada pela última vez.
Um destino de implementação pode ser, por exemplo, uma aplicação Windows local, um ambiente de execução macOS, um servidor PostgreSQL próprio, um ambiente de teste ou uma instância na nuvem.
As informações operacionais, tais como endereços de servidores, acessos a bases de dados, licenças ou associações a dispositivos locais, não devem ser incluídas no SSC portátil. Estas são geridas na configuração protegida da respetiva instância.
Soluções assinadas e distribuição controlada
Os contentores de soluções portáteis não devem permitir que qualquer aplicação seja alterada arbitrariamente ou executada em sistemas não previstos. Por conseguinte, os pacotes SSC/SSD publicados podem ser associados a identificadores de solução, somas de verificação, assinaturas e informações de instância. O ambiente de execução pode verificar, no momento do arranque, se o SSC se encontra inalterado e devidamente assinado, se o SSD pertence à solução correta, se ambas as versões são compatíveis entre si e se existe um perfil de implementação válido.
Dependendo do modelo de licença, a atribuição pode estar vinculada a uma instância, a um servidor, a um dispositivo ou a um conjunto definido de utilizadores. O SchallOS Control gere também as alterações necessárias, tais como a mudança de servidor, uma reativação ou a restauração de uma instalação.
SchallOS Cloud como modelo operacional SaaS
O SchallOS Cloud disponibiliza aplicações como um serviço online gerido centralmente. No entanto, a nuvem não utiliza um formato de solução próprio e distinto. Uma aplicação desenvolvida no SchallOS Studio pode ser atribuída a uma instância na nuvem e disponibilizada através do navegador. O ambiente de execução, a base de dados, as cópias de segurança, a monitorização e as atualizações são geridos centralmente. Para os programadores e clientes, isto resulta num modelo SaaS, sem que seja necessário desenvolver de novo a aplicação especificamente para uma plataforma de nuvem separada.
A portabilidade de base mantém-se. Uma solução pode ser posteriormente transferida para um servidor próprio ou para outro ambiente de execução suportado, desde que o volume de dados, as funcionalidades e os requisitos técnicos o permitam. A mudança continua a ser uma migração controlada, mas não requer a recriação completa da aplicação.
Uma solução pode acompanhar a evolução das suas necessidades
Uma nova aplicação pode, numa primeira fase, ser desenvolvida localmente e testada com um pequeno conjunto de dados. Posteriormente, pode ser disponibilizada como ambiente de execução interno, migrada para o SQLite ou o PostgreSQL e, por fim, publicada como solução de servidor ou na nuvem. As tabelas, os layouts, as fórmulas, os contentores de funções, as traduções e a documentação continuam a fazer parte da mesma estrutura da solução.
Nem todos os protótipos se transformam, sem adaptações, numa grande aplicação empresarial. O funcionamento com vários utilizadores, a segurança, o desempenho e a proteção continuam a ter de ser cuidadosamente planeados. No entanto, a plataforma evita que o crescimento implique necessariamente uma mudança completa de tecnologia.
O Runtime, o Control e a Cloud combinam, assim, diferentes modelos operacionais no âmbito de uma arquitetura comum. A aplicação é desenvolvida uma única vez e, posteriormente, disponibilizada de forma controlada para a respetiva utilização – localmente, num servidor próprio ou como SaaS na nuvem.
Com todo o gosto. Eu inseriria esta secção logo a seguir ao capítulo sobre IA ou como complemento ao capítulo 4. Ela aborda uma ideia importante: a IA não está ligada de forma fixa a um fornecedor, mas é tratada como infraestrutura intercambiável, tal como os adaptadores de bases de dados.
Adaptador de IA em vez de dependência do fabricante
A SchallOS separa deliberadamente a camada de IA propriamente dita dos modelos de linguagem utilizados. A plataforma não funciona exclusivamente com um único fornecedor ou com um ambiente de execução específico. Em vez disso, é possível configurar e gerir centralmente vários adaptadores de IA.
Estes adaptadores estabelecem a ligação entre o SchallOS e os modelos de linguagem utilizados em cada caso. Desta forma, o ambiente de desenvolvimento propriamente dito permanece independente, quer uma solicitação seja enviada para um modelo local, quer para um serviço na nuvem.
A IA torna-se assim uma componente substituível da plataforma – à semelhança dos adaptadores de bases de dados para o IndexedDB, o SQLite ou o PostgreSQL.
Gestão centralizada no SchallOS Control
A configuração da IA é efetuada de forma centralizada através do SchallOS Control. Aí é possível criar e gerir quantos adaptadores de IA forem necessários. São suportados tanto modelos locais como serviços na nuvem.
Os modelos locais podem ser integrados, por exemplo, através do Ollama ou do LM Studio. Para muitas tarefas de desenvolvimento, basta um modelo local compacto, que seja executado na íntegra no próprio computador.
Além disso, é possível configurar modelos na nuvem, como o ChatGPT, o Claude ou outros serviços compatíveis. Cada adaptador possui a sua própria configuração, como dados de acesso, pontos finais, nomes de modelos ou outras definições técnicas. Isto permite obter uma visão geral centralizada de todos os sistemas de IA disponíveis numa instalação do SchallOS.
Configurado uma vez, disponível em qualquer lugar
Uma grande vantagem desta arquitetura reside no facto de um adaptador de IA, uma vez configurado, não ser utilizado apenas num único local. Assim que um adaptador é configurado no SchallOS Control, fica disponível para toda a plataforma. Pode ser utilizado, por exemplo:
- no editor de fórmulas
- dentro de contentores de funções
- para a documentação automática
- na migração de soluções FileMaker
- no Adapter Studio
- ou em futuras ferramentas de desenvolvimento baseadas em IA.
Por conseguinte, o programador não precisa de configurar repetidamente os dados de acesso ou os modelos. A gestão é feita de forma centralizada, enquanto os componentes individuais se limitam a selecionar o adaptador pretendido.
O modelo adequado para cada tarefa
Nem todas as tarefas de desenvolvimento requerem a mesma capacidade de processamento. Para uma breve explicação de uma fórmula, basta frequentemente um pequeno modelo local. Por outro lado, migrações de grande envergadura ou tarefas de programação complexas podem beneficiar de um modelo na nuvem mais potente.
Por isso, o SchallOS permite a seleção de diferentes adaptadores consoante o caso de utilização. Um programador pode, por exemplo, definir que a documentação simples seja, por princípio, criada localmente, enquanto as tarefas particularmente extensas sejam transferidas para um modelo externo. Desta forma, é possível conciliar melhor a velocidade, a proteção de dados e os custos.
Aberto a futuros modelos
O desenvolvimento na área da inteligência artificial está a avançar a um ritmo extraordinariamente rápido. Surgem novos modelos a intervalos curtos, enquanto os sistemas existentes são continuamente aperfeiçoados. Por isso, o SchallOS não se vincula de forma permanente a um único fornecedor. O que é decisivo não é o nome de um modelo específico, mas sim a interface de adaptador padronizada.
Desta forma, será possível integrar posteriormente novos sistemas de IA locais ou baseados na nuvem, sem ter de alterar o ambiente de desenvolvimento propriamente dito. Esta abertura está em consonância com a arquitetura fundamental do SchallOS. Tal como acontece com os adaptadores de bases de dados, os adaptadores de IA devem também permanecer intercambiáveis, enquanto o Studio, o Runtime e a própria aplicação podem continuar a funcionar sem alterações.
Desta forma, a inteligência artificial torna-se uma funcionalidade permanentemente integrada na plataforma – independentemente dos modelos ou fornecedores que venham a impor-se no mercado nos próximos anos.
Da migração do FileMaker para a plataforma de software independente
O SchallOS surgiu do trabalho de longa data com a FileMaker. Muitas das ideias fundamentais da plataforma baseiam-se em experiências com soluções individuais de bases de dados e ERP, que evoluíram ao longo dos anos em conjunto com as necessidades operacionais das empresas.
O FileMaker apresenta vantagens específicas no que diz respeito ao desenvolvimento rápido. O modelo de dados, os layouts e a lógica do programa estão intimamente interligados, as alterações tornam-se visíveis de imediato e é possível criar as primeiras soluções funcionais com relativa rapidez.
Esta proximidade entre o programador, os dados e a interface do utilizador deverá ser mantida no SchallOS. No entanto, a base técnica será reconstruída. O SchallOS utiliza um ambiente de execução próprio, os seus próprios contentores de estrutura e de dados, uma camada funcional baseada em IA, bem como uma infraestrutura própria para documentação, implementação e atualizações.
O FileMaker continua, assim, a ser um ponto de partida importante e uma possível fonte de soluções existentes. No entanto, já não é necessário para o funcionamento posterior.
A migração é mais do que uma importação de layout
Uma solução FileMaker já consolidada não se resume apenas a tabelas, campos e máscaras visíveis. Grande parte do seu conhecimento especializado está contido em fórmulas, scripts, gatilhos, relações, listas de valores e inúmeros casos especiais.
Uma migração eficaz deve identificar estas interligações e transpor-nas para uma nova arquitetura. As tabelas, os campos, as relações e os layouts podem, em grande medida, ser transferidos de forma estruturada. As fórmulas e as funções personalizadas são transferidas para o ambiente de fórmulas do SchallOS ou adaptadas.
No que diz respeito aos scripts FileMaker, o foco inicial recai na compreensão da sua função técnica. Estes podem ser mantidos como uma camada de aprendizagem e referência em segundo plano nos novos contentores de funções. No entanto, o código executável é reprogramado pela IA de forma a adequar-se à arquitetura do SchallOS. Desta forma, não existe um tempo de execução FileMaker dentro de um novo sistema. A solução existente transforma-se gradualmente numa aplicação SchallOS autónoma.
Funcionamento autónomo após a migração
Após uma migração completa, não serão necessários nem o FileMaker Pro, nem o FileMaker Server, nem o WebDirect. A nova aplicação utiliza o SchallOS Runtime, o SSC como contentor de estrutura e o SSD para os dados produtivos. Fórmulas, contentores de funções, multilinguismo, documentação, registos de eventos e atualizações são fornecidos pela plataforma SchallOS.
Dependendo dos requisitos, a solução pode ser executada localmente, como aplicação para Windows ou macOS, num servidor próprio ou como serviço SaaS na SchallOS Cloud.
Isto põe fim à dependência de um único ambiente de execução proprietário. As dependências técnicas não desaparecem totalmente – qualquer software moderno necessita de sistemas operativos, bases de dados e serviços de servidor. No entanto, a estrutura, a lógica de negócio e os dados permanecem portáteis e podem ser executados através de adaptadores e vias de implementação documentados.
Novas possibilidades para os programadores FileMaker
Para os programadores do FileMaker, o SchallOS não deve representar uma ruptura total com a forma de trabalhar até agora. Os conhecimentos sobre modelos de dados, conceção de layouts e processos operacionais continuam a ser valiosos.
A principal alteração diz respeito à implementação da lógica do programa. As longas cadeias de scripts são substituídas por contentores de funções descritos semanticamente. A IA programa o código executável com base em tarefas, parâmetros e limites definidos. O programador verifica o resultado e continua a ser responsável pela arquitetura e pela correção técnica.
A história do desenvolvimento passa também a ser tida mais em conta. As alterações podem ser registadas, documentadas e agrupadas em versões de forma automática. O mesmo fluxo de atualizações, através do qual o próprio SchallOS é atualizado, está também disponível para as soluções personalizadas dos clientes.
Assim, o trabalho passa, em parte, da introdução manual de passos individuais do programa para a descrição, verificação e estruturação precisas dos processos empresariais.
Não apenas para aplicações migradas
A migração FileMaker continua a ser uma componente importante do SchallOS, mas não é a sua única finalidade. É possível desenvolver novas aplicações na íntegra no SchallOS Studio.
A longo prazo, poderão também ser suportados outros sistemas de origem. No entanto, cada uma dessas ampliações requer os seus próprios procedimentos de análise e migração. As diferentes plataformas de desenvolvimento têm os seus próprios conceitos, que não podem ser reproduzidos de forma adequada através de uma importação universal superficial.
A experiência adquirida com a migração do FileMaker constitui uma base para tal. No entanto, o verdadeiro objetivo do SchallOS reside no desenvolvimento e na exploração de aplicações empresariais independentes.
Lançamento previsto para o outono de 2026
O lançamento público do SchallOS está previsto para o outono de 2026. Até lá, as áreas fundamentais da plataforma continuarão a ser integradas, testadas e preparadas para os primeiros casos de utilização em produção. Nem todas as funcionalidades planeadas a longo prazo estarão totalmente desenvolvidas já no momento do lançamento. O essencial é um núcleo robusto, sobre o qual se possam desenvolver de forma controlada novos adaptadores de bases de dados, funções de IA, opções de migração e modelos operacionais.
Em primeiro lugar, a Software ERP gFM-NEXT da gofilemaker.de a ser publicado na nova plataforma SchallOS, previsivelmente em setembro de 2026. O lançamento da plataforma de desenvolvimento SchallOS, um pouco mais tarde, no outono de 2026, não deverá, portanto, marcar o fim do desenvolvimento, mas sim o início da sua utilização prática.
O ciclo de vida completo de uma aplicação
O SchallOS começou por se questionar como é que as soluções FileMaker existentes poderiam ser transpostas para um ambiente moderno. Daí surgiu uma plataforma que tem em conta não só a migração e o desenvolvimento, mas também a documentação, a implementação, a gestão de dados, as atualizações e a operação a longo prazo. O Studio, o Runtime, o Control e a Cloud assumem tarefas claramente diferenciadas no âmbito de uma arquitetura comum. O objetivo não é, portanto, substituir o FileMaker simplesmente por outra ferramenta de desenvolvimento. O SchallOS pretende aliar a comprovada proximidade entre o programador, os dados e a interface do utilizador a contentores portáteis, programação apoiada por IA e um modelo de operação contínuo.
O DNA FileMaker constitui o ponto de partida. O objetivo é uma plataforma independente na qual as aplicações empresariais existentes e novas possam ser desenvolvidas, operadas e mantidas a longo prazo.
Perguntas mais frequentes
- O que é exatamente o SchallOS e em que se diferencia de uma aplicação clássica de base de dados?
O SchallOS é uma plataforma para o desenvolvimento, execução e gestão de software empresarial personalizado. Inclui não só tabelas, layouts e funções, mas também programação assistida por IA, documentação, registos de eventos, implementação e atualizações. O SchallOS Studio destina-se ao desenvolvimento, o Runtime executa aplicações concluídas, o Control gere as instalações e o Cloud disponibiliza soluções como SaaS. Desta forma, a plataforma acompanha uma aplicação desde a sua criação até à sua operação a longo prazo. - A quem se destina o SchallOS: a que programadores e empresas?
O SchallOS destina-se, em particular, a programadores FileMaker, empresas de software e programadores de aplicações empresariais personalizadas. As empresas que já dispõem de soluções FileMaker têm também a possibilidade de migrar gradualmente as suas aplicações para um ambiente independente. Além disso, é possível criar novas soluções inteiramente no SchallOS. Para os diretores executivos e responsáveis técnicos, é particularmente interessante o facto de o desenvolvimento, a operação, a documentação, as atualizações e as diversas formas de implementação serem organizados numa plataforma comum. - O SchallOS é, essencialmente, um substituto do FileMaker?
O FileMaker é um ponto de partida importante, mas não constitui a base técnica duradoura do SchallOS. São adotadas ideias comprovadas, como o desenvolvimento visual e a estreita ligação entre dados, layouts e funções. No entanto, o ambiente de execução, a gestão de dados, a lógica funcional e a infraestrutura de atualizações são desenvolvidos de forma independente. O SchallOS pode migrar soluções FileMaker existentes, mas é igualmente adequado para novas aplicações. Após uma migração completa, o FileMaker deixa de ser necessário para o funcionamento em produção. - É possível migrar a minha solução FileMaker atual de forma totalmente automática?
Tabelas, campos, relações, layouts e outras estruturas definidas podem ser transferidas de forma amplamente automatizada. No entanto, no caso de uma lógica de negócio complexa, é necessária uma verificação adicional. Os scripts FileMaker contêm frequentemente alterações de layout, variáveis globais, plugins ou casos especiais que surgiram ao longo do tempo. A IA pode analisar estes processos e criar novos contentores de funções a partir deles. No entanto, uma solução abrangente deve ser verificada por um programador e, se necessário, corrigida. A migração reduz consideravelmente o trabalho manual, mas não substitui o conhecimento técnico da aplicação. - O que acontece aos scripts FileMaker existentes após a migração?
Os scripts podem ser mantidos no fundo dos novos contentores de funções como camada de aprendizagem e de referência. No entanto, não são executados tal como estão. A IA analisa qual a tarefa técnica que um script desempenha, quais os campos utilizados e quais as condições verificadas. Em seguida, programa o novo código executável de acordo com a arquitetura do SchallOS. O script original é mantido como fonte de conhecimento histórico e pode continuar a ser tido em conta em caso de questões ou ampliações futuras. - O que são SSC e SSD, e por que razão uma solução necessita de dois contentores?
O SSC contém a estrutura da aplicação, incluindo tabelas, campos, layouts, fórmulas, contentores de funções, idiomas e documentação. O SSD contém os dados produtivos, tais como clientes, artigos, encomendas ou faturas. Ambos os contentores estão interligados, mas têm funções diferentes. Esta separação permite criar novas versões da estrutura para 1TP12 sem ter de substituir toda a base de dados. Além disso, é possível alterar a gestão de dados, as cópias de segurança e os modelos operacionais sem ter de desenvolver a aplicação de raiz. - Quais são as vantagens da separação entre estrutura e dados?
Desta forma, as atualizações, cópias de segurança e migrações podem ser realizadas de forma muito mais controlada. É possível publicar um novo SSC, mantendo o SSD com os dados do cliente. As alterações estruturais necessárias são executadas através de migrações de dados definidas. Além disso, o SSC pode ser analisado ou entregue a outro programador sem incluir dados comerciais confidenciais. A transição do IndexedDB para o SQLite, o PostgreSQL ou para a nuvem também é facilitada, uma vez que não é necessário reconstruir os layouts nem a lógica funcional. - É possível utilizar a mesma solução localmente, num servidor e na nuvem?
Em princípio, sim. Uma solução SchallOS pode ser executada localmente no navegador, como aplicação para Windows ou macOS, com SQLite, num servidor PostgreSQL ou como SaaS na SchallOS Cloud. A aplicação funcional permanece a mesma. No entanto, os diferentes modos de funcionamento apresentam requisitos próprios em termos de utilização por múltiplos utilizadores, cópias de segurança, desempenho e administração. Por isso, a transição é efetuada de forma controlada, através da transferência e verificação de dados. A arquitetura SSC/SSD evita que seja necessário gerir um projeto totalmente novo para cada destino. - Após uma migração bem-sucedida, continuarei a precisar do FileMaker ou do servidor FileMaker?
Não. Após uma migração completa, a aplicação é executada pelo SchallOS Runtime. Também para o funcionamento no navegador não são necessários nem o servidor FileMaker nem o WebDirect. O antigo sistema FileMaker pode ser mantido como referência ou arquivo, mas não é um pré-requisito para o funcionamento em produção. Os layouts, fórmulas, funções, acesso aos dados, atualizações e implementação são assumidos pelo SchallOS. Assim, as dependências de tempo de execução do FileMaker existentes para a aplicação migrada deixam de ser necessárias. - Como é que a inteligência artificial está integrada no SchallOS?
A IA está disponível diretamente no editor de fórmulas, nas funções personalizadas, nos contentores de funções e na camada de documentação. Não só conhece a questão atual, como também os campos, tabelas, descrições e dependências em causa. No caso de soluções migradas, o script FileMaker original pode, além disso, servir como conhecimento de base. A IA pode explicar fórmulas, gerar código, analisar erros e redigir documentação. Os modelos devem, em princípio, permanecer intercambiáveis, para que a qualidade, os custos e a proteção de dados possam ser tidos em conta. - Será que a IA programa realmente o código dos contentores de funções?
Sim. O programador descreve a tarefa, os parâmetros, o resultado esperado e as capacidades permitidas. Com base nisso, a IA gera o código executável. Este permanece visível, verificável e sujeito a controlo de versões. O programador pode solicitar alterações, realizar testes e comparar ou restaurar versões anteriores. A IA assume, assim, uma grande parte do trabalho de programação, mas não a responsabilidade técnica. Especialmente no caso de processos críticos para o negócio, os requisitos, os direitos e os possíveis efeitos secundários devem continuar a ser cuidadosamente controlados. - Que funcionalidades oferece o editor de fórmulas?
O editor de fórmulas suporta cálculos matemáticos, lógicos e relacionados com texto, bem como cálculos de data e hora. As fórmulas e as funções personalizadas são avaliadas em tempo real e podem ser testadas imediatamente. O conjunto inicial de comandos é mais reduzido do que o conjunto de funções do FileMaker, que tem vindo a crescer ao longo dos anos. No entanto, o ambiente de fórmulas é expansível. As funções em falta podem ser adicionadas ou substituídas por funções personalizadas próprias. Também neste caso, a IA integrada pode transferir fórmulas existentes do FileMaker ou desenvolver novos cálculos. - O que é que o SchallOS regista automaticamente?
Ao nível da estrutura, são registadas alterações em tabelas, campos, layouts, fórmulas e contentores de funções. Ao nível dos dados, podem ser registadas alterações nos registos, mudanças de estado, aprovações, importações e outros eventos específicos da área de negócio. A isto acrescentam-se eventos operacionais, como implementações, atualizações e cópias de segurança. Os trabalhos de desenvolvimento relacionados podem ser agrupados em «sessões de alteração» e posteriormente atribuídos a uma versão. Desta forma, cria-se um histórico rastreável da aplicação, em vez de apenas uma coleção de notas redigidas a posteriori. - O SchallOS consegue criar relatórios de clientes e de desempenho a partir desses dados?
Sim. A IA integrada pode gerar documentação técnica, relatórios para clientes, notas de lançamento ou comprovativos de desempenho a partir dos eventos registados. Várias alterações técnicas podem ser resumidas numa descrição compreensível dos benefícios comerciais. Os eventos subjacentes continuam disponíveis para consulta, para que o programador possa verificar as formulações. Nem todas as alterações são automaticamente faturáveis. Por isso, a seleção, avaliação e aprovação do relatório de desempenho final continuam a ser da responsabilidade do programador. - Como funciona o processo de atualização?
As alterações são inicialmente reunidas em «Change Sessions» e agrupadas numa versão. Uma versão pode incluir um novo SSC, migrações necessárias de SSD, pré-requisitos, assinaturas, verificações e informações de reversão. O SchallOS Control verifica a instância de destino, cria uma cópia de segurança e, em seguida, executa a atualização. Após a instalação, verifica-se se a estrutura, os dados e as funções importantes correspondem ao estado esperado. Este mesmo fluxo de trabalho básico é utilizado tanto para o próprio SchallOS como para as soluções de clientes desenvolvidas com base nele. - Em que é que o Runtime, o Control e a Cloud diferem?
O SchallOS Runtime executa as aplicações publicadas e disponibiliza layouts, fórmulas e contentores de funções. O SchallOS Control gere instâncias, adaptadores de bases de dados, perfis de tempo de execução, atualizações e verificações técnicas. O SchallOS Cloud oferece o tempo de execução e o armazenamento de dados como um serviço SaaS gerido centralmente. O SchallOS Studio continua a ser o ambiente de desenvolvimento propriamente dito. Todas as áreas utilizam as mesmas estruturas básicas SSC e SSD, mas assumem tarefas claramente diferenciadas entre si no âmbito do ciclo de vida de uma aplicação. - Como é que os direitos, as instalações e os dados sensíveis são protegidos?
Os direitos de utilizador determinam quais as ações específicas que uma pessoa pode realizar no âmbito da solução. Os perfis de tempo de execução e de capacidades definem, além disso, quais as funções técnicas de que uma instalação dispõe. Os pacotes SSC e SSD podem ser protegidos com identificadores, somas de verificação e assinaturas. O contexto da IA também pode ser limitado, de modo a que nem todos os dados dos clientes sejam processados automaticamente. Para ambientes particularmente sensíveis, podem ser utilizados servidores próprios ou, no futuro, também modelos de IA locais. A configuração de segurança concreta depende do caso de utilização específico. - Quando é que o SchallOS estará disponível?
O lançamento público está previsto para o outono de 2026. Inicialmente, o foco incidirá no Studio e no Runtime, na separação entre SSC e SSD, na migração das estruturas FileMaker existentes, nas fórmulas, nas funções personalizadas, nos contentores de funções programados por IA, na documentação, nos registos de eventos, na implementação e nas atualizações. O SchallOS Control também assumirá um papel central na gestão das instalações. Nem todas as funcionalidades planeadas a longo prazo têm de estar totalmente desenvolvidas já no lançamento. O mais importante, numa primeira fase, é dispor de um núcleo robusto para as primeiras aplicações produtivas.
