De FileMaker a la nube: cómo SchallOS combina el software empresarial con la IA, el entorno de ejecución y las actualizaciones

Al desarrollar una aplicación empresarial, en un primer momento la atención se centra en las tareas visibles: se crean tablas, se definen relaciones, se diseñan formularios de entrada y se automatizan los procesos operativos. En cuanto los primeros usuarios pueden empezar a trabajar con la solución, parece que una gran parte del proyecto ha concluido. Sin embargo, en la práctica es entonces cuando comienza la fase más exigente a largo plazo. Una aplicación de uso empresarial debe mantenerse, ampliarse y adaptarse a los nuevos requisitos. Es necesario documentar los cambios, distribuir las nuevas versiones y transferir los datos existentes de forma segura. A esto se suman los distintos derechos de usuario, las copias de seguridad, los análisis de errores y la cuestión de si la solución debe ejecutarse de forma local, en un servidor propio o en la nube.

Muchas plataformas de desarrollo se centran principalmente en la creación de la aplicación propiamente dicha. Para las actualizaciones, la documentación, la implementación y el funcionamiento, se añaden posteriormente herramientas adicionales y procedimientos específicos. Con el tiempo, se crea un entorno técnico compuesto por numerosos componentes independientes entre sí, que solo puede mantenerse unificado con un esfuerzo considerable. Por ello, SchallOS adopta un enfoque más integral. La plataforma no solo debe acompañar a una aplicación empresarial durante su creación, sino a lo largo de todo su ciclo de vida: desde el desarrollo, pasando por la documentación y la puesta en marcha, hasta las actualizaciones y el funcionamiento continuo.

Cuestiones sociales de actualidad

Dependencia digital: cómo hemos perdido nuestra autodeterminación en favor de la nube

Dependencia digital: cómo hemos perdido nuestra autodeterminación en favor de la nube

Coche eléctrico, híbrido y e-scooter: una visión realista más allá de la ideología

Coche eléctrico, híbrido y e-scooter: una visión realista más allá de la ideología

Rusia, la OTAN y el miedo a la guerra: lo que se puede demostrar y lo que no

Rusia, la OTAN y el miedo a la guerra: lo que se puede demostrar y lo que no

Protección del clima con visión de túnel: electromovilidad, grupos de presión y costes ocultos

Protección del clima con visión de túnel: electromovilidad, grupos de presión y costes ocultos

De la migración de FileMaker a nuestra propia plataforma

El punto de partida inicial de SchallOS fue la migración de las soluciones FileMaker existentes. A lo largo de décadas, FileMaker ha demostrado ser un entorno eficaz para aplicaciones de bases de datos específicas. En particular, la estrecha relación entre el modelo de datos, el diseño y la lógica del programa permite un desarrollo rápido y orientado a la práctica.

Sin embargo, una solución FileMaker consolidada es mucho más que tablas y máscaras visibles. Incluye cálculos, scripts, derechos de usuario, diseños de impresión, interfaces y numerosos casos especiales operativos. Una plataforma sucesora viable debe poder integrar estas interrelaciones y, posteriormente, gestionarlas de forma independiente.

A partir de esta tarea, SchallOS se fue convirtiendo poco a poco en una plataforma independiente. Se pretende que las soluciones existentes de FileMaker puedan migrarse, al tiempo que se puedan desarrollar nuevas aplicaciones directamente en SchallOS. Una vez completada la migración, FileMaker ya no será necesario para el funcionamiento en producción.

El desarrollo, la ejecución y el funcionamiento siguen estando separados

La plataforma de desarrollo SchallOS se compone de varias áreas con funciones bien definidas.

• SchallOS Studio Es el entorno de desarrollo. En él se crean estructuras de datos, diseños, fórmulas, funciones, lenguajes y versiones. El asistente de migración para soluciones FileMaker existentes también forma parte de Studio.
• SchallOS Runtime Ejecuta las aplicaciones publicadas. Proporciona la interfaz de usuario y la lógica de programa necesaria, sin habilitar automáticamente todas las herramientas de desarrollo.
• SchallOS Control gestiona los destinos de implementación, las conexiones a bases de datos, los perfiles de tiempo de ejecución, las actualizaciones y las comprobaciones técnicas.
• SchallOS Cloud Ofrece aplicaciones como un servicio en línea gestionado de forma centralizada. Con ello no se pretende crear un formato de nube independiente. Las instalaciones locales, basadas en servidor y basadas en la nube utilizan la misma arquitectura básica de la solución.

Esta separación evita que el desarrollo, la aplicación y la administración se mezclen de forma incontrolada. Al mismo tiempo, todas las áreas siguen estando coordinadas entre sí desde el punto de vista técnico.

Una solución para distintos modelos de funcionamiento

Una aplicación empresarial puede empezar siendo pequeña y crecer más adelante. Al principio, quizá baste con un único puesto de trabajo local. Más adelante se incorporarán más empleados, un servidor central o varias sedes. Por ello, SchallOS debe poder ofrecer la misma solución básica para diferentes modalidades de funcionamiento: de forma local en el navegador, como aplicación para Windows o macOS, con SQLite o PostgreSQL, así como en forma de solución SaaS en la nube.

No todas las modalidades de funcionamiento presentan las mismas características técnicas. Una base de datos local plantea requisitos distintos a los de un sistema centralizado multiusuario. Sin embargo, lo fundamental es que no sea necesario desarrollar desde cero los diseños, las funciones y el modelo de datos para cada objetivo.

El ciclo de vida forma parte de la arquitectura

En SchallOS, la documentación, los registros de eventos y las actualizaciones no se añaden a posteriori a una aplicación ya terminada, sino que forman parte de la arquitectura básica. La estructura y los datos productivos se gestionan por separado. Los cambios de desarrollo pueden registrarse y agruparse en versiones. Las actualizaciones pueden comprobarse, distribuirse y, en caso de problemas, revertirse de forma controlada. La IA integrada no solo ayuda con las fórmulas y las funciones, sino también con la documentación y la comunicación con los clientes.

De este modo, SchallOS integra ámbitos que, en los proyectos tradicionales, suelen tratarse por separado. El desarrollo de una aplicación ya no es el final del proceso técnico, sino la primera fase de un ciclo de vida planificado a largo plazo.

SSC y SSD como contenedores portátiles de estructuras y datos

Muchas aplicaciones de bases de datos almacenan la estructura, la interfaz de usuario, la lógica del programa y los datos operativos en una unidad estrechamente interrelacionada. Esto resulta cómodo al principio, pero complica las actualizaciones posteriores, las migraciones y los distintos modos de funcionamiento. En cuanto se incorporan varios clientes, grandes volúmenes de datos o ampliaciones personalizadas, la sustitución de un archivo de aplicación completo se convierte rápidamente en un problema.

Por ello, SchallOS separa siempre la descripción de una solución de sus datos de negocio. Una aplicación se compone, en esencia, de dos contenedores relacionados entre sí: el SSC, para la estructura, y el SSD, para los datos productivos.

Ambos contenedores conforman en conjunto la solución completa, pero cumplen funciones diferentes. El SSC describe cómo está estructurada y cómo funciona la aplicación. El SSD contiene los contenidos que se generan durante su uso.

El SSC describe su uso

El archivo SSC es el contenedor de estructura portátil de una solución SchallOS. En él se encuentran, entre otras cosas:

• Definiciones de tablas y campos
• Relaciones
• Maquetaciones y objetos de maquetación
• Fórmulas y funciones propias
• Contenedor funcional
• Desencadenantes y navegación
• Información sobre idiomas y traducción
• Documentación
• Información sobre versiones y lanzamientos

Por lo tanto, el SSC no contiene los datos de clientes, artículos, pedidos o facturas en sí. Establece qué estructuras de datos existen, cómo se representan y qué funciones operan con ellas. El significado semántico de una solución también forma parte de este contenedor. Además de su nombre técnico, un campo puede incluir una descripción funcional, traducciones, reglas de validación e indicaciones para la capa de IA. De este modo, la estructura no solo es legible por máquina, sino que también resulta más comprensible para los desarrolladores, la documentación y la migración.

De este modo, el SSC constituye un modelo de aplicación portátil que puede seguir desarrollándose y publicándose independientemente de un conjunto de datos concreto.

El SSD contiene los datos operativos

El archivo SSD es el contenedor de datos de la solución. Contiene los registros que se generan durante el funcionamiento diario, como clientes, ofertas, pedidos, facturas, movimientos de almacén o citas. Además, en él se pueden almacenar historiales específicos y eventos de datos. Entre ellos se incluyen, por ejemplo, los cambios de estado, las autorizaciones, las importaciones o las modificaciones en campos especialmente importantes. El término «SSD» no hace referencia a un soporte físico de datos, sino al nivel lógico de datos de la aplicación. La forma en que se almacenan técnicamente estos datos depende de la implementación y del adaptador de base de datos seleccionados.

Para un puesto de trabajo local individual se puede utilizar IndexedDB. Una aplicación de escritorio puede funcionar con SQLite, mientras que las aplicaciones multiusuario de mayor envergadura utilizan PostgreSQL. En todos los casos, el SSD sigue siendo el contenedor de datos funcional, aunque el almacenamiento técnico sea diferente.

Dos contenedores deben pertenecer claramente al mismo conjunto

La separación entre estructura y datos no debe dar lugar a que se combinen entre sí contenedores cualquiera. SchallOS debe poder comprobar si un SSC y un SSD pertenecen realmente a la misma solución y si sus versiones son compatibles entre sí. Para ello, se pueden utilizar identificadores de solución, identificadores de contenedor, versiones de estructura, sumas de comprobación y firmas. De este modo, antes de la puesta en marcha o de una actualización, se puede determinar si la combinación es válida y si ya se han llevado a cabo las migraciones de datos necesarias.

Esta comprobación evita, por ejemplo, que se abra por error el contenedor de estructura de otra aplicación con un conjunto de datos en producción. Además, impide que se active una nueva versión de SSC aunque el SSD aún no se haya preparado con la estructura de datos necesaria para ello.

Portabilidad entre diferentes modalidades de funcionamiento

La separación entre SSC y SSD sienta las bases para ejecutar una aplicación en distintos entornos. No es necesario volver a desarrollar los diseños, las fórmulas y la lógica funcional para cada adaptador de base de datos.

Una solución puede comenzar a nivel local con IndexedDB, pasar posteriormente a SQLite y, a medida que aumente el número de usuarios, migrar a PostgreSQL. También es posible el cambio a un entorno en la nube.

Este tipo de cambio sigue siendo un proceso técnico controlado. Las distintas bases de datos tienen sus propias posibilidades y limitaciones. Por eso, los datos no se transfieren a otro sistema simplemente pulsando un botón. La transferencia, la comprobación y, en su caso, la reversión deben realizarse de forma explícita.

Sin embargo, la arquitectura garantiza que un cambio en el almacenamiento de datos no implique automáticamente tener que reconstruir toda la aplicación.

Actualizaciones sin modificar los datos de los clientes

Una ventaja fundamental de la separación se hace patente en las nuevas versiones. Los cambios suelen afectar a los diseños, las fórmulas, las funciones o el modelo de datos. Los datos empresariales existentes deben mantenerse sin cambios.

Por lo tanto, un desarrollador puede publicar una nueva versión de SSC mientras el SSD del cliente permanece en su ubicación original. Si se necesitan nuevos campos o tablas, estos se añaden mediante pasos de migración definidos. Antes de la actualización, se puede realizar una copia de seguridad del estado actual. A continuación, se comprueban la estructura, la migración de datos y el funcionamiento. La actualización solo se considerará completada cuando el SSC y el SSD vuelvan a estar en un estado coherente.

Esta capacidad de actualización no está pensada únicamente para el propio SchallOS. También está disponible para las soluciones de los clientes desarrolladas con SchallOS.

Las variantes específicas para cada cliente siguen siendo trazables

El software empresarial personalizado suele evolucionar de forma diferente según el cliente. Un cliente necesita campos propios, otro, diseños adicionales o una interfaz específica. Sin una estructura clara, esto da lugar rápidamente a copias completas que difieren entre sí y que resultan difíciles de mantener de forma conjunta. En el SSC, en cambio, los componentes generales del producto y las ampliaciones específicas para cada cliente pueden versionarse y documentarse de forma trazable.

La arquitectura no exime al desarrollador de decidir qué adaptación debe incluirse en el producto general. Sin embargo, garantiza que el origen y las dependencias de un cambio sigan siendo visibles.

Junto con los protocolos de desarrollo y las versiones, esto permite identificar mejor, en actualizaciones posteriores, qué componentes deben sustituirse, completarse o mantenerse.

El multilingüismo forma parte de la estructura portátil

La capa lingüística también está integrada en el SSC. Los nombres no se almacenan exclusivamente de forma fija en objetos de maquetación individuales, sino que pueden hacer referencia a entradas semánticas con varias versiones lingüísticas.

De este modo, un campo como „Número de factura“ puede mostrarse en diferentes idiomas sin necesidad de crear un diseño completamente nuevo para cada idioma. Una solución FileMaker migrada puede adaptarse automáticamente a varios idiomas y traducirse durante el proceso de migración.

La traducción automática no sustituye a una revisión por parte de un experto. Es precisamente necesario revisar los términos jurídicos y específicos del sector. Sin embargo, la arquitectura del sistema garantiza que el multilingüismo forme parte de la solución desde el principio y no tenga que incorporarse posteriormente con gran esfuerzo en cada pantalla.

Base para un mantenimiento a largo plazo

A primera vista, SSC y SSD parecen una simple división entre la aplicación y los datos. Sin embargo, en realidad constituyen la base para la portabilidad, las actualizaciones, los distintos adaptadores de bases de datos, las copias de seguridad independientes y los diferentes modelos operativos.

El SSC describe qué es una solución y cómo funciona. El SSD recoge lo que se genera durante su uso y que debe conservarse de forma permanente para la empresa en cuestión.

Gracias a esta clara separación, la aplicación puede seguir desarrollándose sin que sea necesario sustituir toda la base de datos en cada nueva versión. Al mismo tiempo, la estructura técnica de los datos puede ampliarse o modificarse sin que sea necesario rediseñar por completo los diseños y la lógica de negocio.

SchallOS Studio como entorno de desarrollo integrado

SchallOS Studio es el área de la plataforma en la que se crean nuevas aplicaciones empresariales y se migran o se perfeccionan las soluciones FileMaker existentes. En ella se gestionan tablas, campos, relaciones, diseños, fórmulas, funciones, idiomas y versiones dentro de un entorno común.

Para los desarrolladores de FileMaker, el modo de trabajo básico les resultará familiar. Los cambios no se realizan exclusivamente en archivos de código fuente abstractos, sino que permanecen vinculados a los componentes visibles de la aplicación. Un desarrollador puede editar un diseño, seleccionar un campo, modificar sus propiedades y comprobar al instante cómo afecta el cambio a la aplicación.

No obstante, SchallOS no pretende reproducir FileMaker al completo. Se adoptan sobre todo las ideas básicas que han demostrado su eficacia: desarrollo rápido, retroalimentación inmediata y una estrecha conexión entre el modelo de datos, la interfaz de usuario y la lógica de negocio. La base técnica, por el contrario, se reorganiza y se orienta hacia estructuras portables, programación basada en IA, documentación y publicaciones controladas.

Diseños, objetos y propiedades

Un componente esencial de SchallOS Studio es el modo de diseño. En él se crean los formularios de entrada, las listas, los cuadros de diálogo, las áreas de navegación y otros elementos de la interfaz de una solución.

Entre los posibles objetos de diseño se incluyen, entre otros, campos, textos, botones, objetos de lista, áreas de pestañas, ventanas emergentes, contenedores y elementos de navegación. Los objetos se pueden seleccionar, colocar y configurar mediante un inspector.

Un objeto de diseño no solo contiene información sobre el tamaño, la posición y la presentación. Además, puede estar vinculado a fuentes de datos, desencadenantes, fórmulas, funciones y etiquetas semánticas. Un objeto de campo, por ejemplo, hace referencia a un campo del modelo de datos, puede recibir una etiqueta en función del idioma y activar determinadas funciones al entrar o salir de él.

Dado que cada objeto forma parte del SSC, los cambios en el diseño pueden versionarse, documentarse y distribuirse posteriormente de forma selectiva mediante una actualización. De este modo, la interfaz de usuario no es un nivel gráfico aislado, sino un componente estructurado de toda la aplicación.

Modelo de datos y descripciones semánticas

Las tablas, los campos y las relaciones también se crean y editan en SchallOS Studio. Allí se pueden desarrollar aplicaciones nuevas de principio a fin. En una migración de FileMaker, el asistente de migración adopta las estructuras existentes en la medida de lo posible y, a continuación, las pone a disposición para su posterior edición.

En SchallOS, un campo no se compone únicamente de un nombre técnico y un tipo de datos. Además, puede incluir una descripción funcional, reglas de validación, valores por defecto, traducciones e indicaciones de documentación.

Esta información tiene varios fines. Facilita a otros desarrolladores la comprensión de la solución, contribuye a la documentación automática y proporciona un mejor contexto a la IA integrada. En lugar de limitarse a reconocer que un campo se llama „Estado“, la plataforma puede saber, por ejemplo, si se trata del estado de un pedido, del estado de un pago o de un estado de tramitación interno.

También se pueden describir las relaciones entre tablas y documentarlas en su contexto funcional. De este modo, se evita que gran parte del conocimiento quede oculto exclusivamente en la mente del desarrollador original.

Fórmulas con cálculo en tiempo real

SchallOS cuenta con su propio entorno de fórmulas. Las fórmulas se crean en el editor de fórmulas y se calculan en tiempo real mientras se editan. De este modo, los cambios realizados en una expresión pueden comprobarse inmediatamente con valores de prueba adecuados o con el conjunto de datos actual.

El lenguaje de fórmulas permite realizar los cálculos típicos que se necesitan en las aplicaciones empresariales. Entre ellos se incluyen operaciones matemáticas, procesamiento de texto, cálculos de fecha y hora, condiciones lógicas, referencias a campos, variables y expresiones anidadas.

El conjunto de comandos disponible es, en un primer momento, más reducido que el conjunto de funciones de FileMaker, que ha ido creciendo a lo largo de décadas. SchallOS no tiene por qué reproducir sin modificaciones todos los comandos históricos de FileMaker. Es más importante contar con un entorno de fórmulas claramente estructurado y ampliable.

Más adelante se podrán añadir comandos adicionales si son necesarios para determinadas soluciones o migraciones. La IA integrada también puede ayudar a transferir un cálculo ya existente o a desarrollar una función que falte, adaptándola a la arquitectura de SchallOS.

Funciones personalizadas para cálculos reutilizables

Además de los comandos integrados, SchallOS admite funciones personalizadas. Estas aceptan parámetros, realizan un cálculo definido y devuelven un resultado. De este modo, es posible gestionar reglas recurrentes desde un único punto central. Algunos ejemplos son los cálculos de precios, la determinación de plazos, el formato de datos, la comprobación de rangos de números o el procesamiento de valores importados.

Las funciones personalizadas también se calculan en tiempo real y se pueden probar directamente en el editor de fórmulas. Si posteriormente se corrige o amplía una función, todas las fórmulas que la utilicen se beneficiarán de ello.

Además, se pueden describir y documentar funciones propias. De este modo, los parámetros, el valor de retorno, los ejemplos y los casos de error conocidos quedan claramente documentados. El conjunto de funciones de una solución se convierte así en una biblioteca reutilizable, en lugar de consistir en numerosos cálculos individuales copiados.

Contenedores funcionales para procesos más complejos

En SchallOS, los procesos empresariales más complejos se organizan mediante contenedores de funciones. Por ejemplo, permiten crear registros de datos, comprobar valores, controlar cuadros de diálogo, generar documentos o interactuar con interfaces externas. Un contenedor de funciones no solo contiene el código ejecutable, sino que también incluye una descripción técnica, parámetros de entrada, valores de retorno, dependencias, capacidades permitidas y operaciones expresamente excluidas.

Varios objetos de diseño pueden utilizar el mismo contenedor de funciones. De este modo, no es necesario crear de nuevo una función para generar una factura para cada botón o cada diseño.

En el caso de las soluciones migradas, los scripts FileMaker existentes pueden conservarse en segundo plano como base de aprendizaje y referencia. Ayudan a comprender la intención original y el flujo de trabajo anterior. Sin embargo, el nuevo código ejecutable se genera de acuerdo con la arquitectura de SchallOS.

Migración y nuevo desarrollo en el mismo entorno

SchallOS Studio no es únicamente un destino para las soluciones FileMaker ya existentes. Las nuevas aplicaciones pueden desarrollarse íntegramente dentro de la plataforma.

Durante una migración, el asistente se encarga en primer lugar de transferir las tablas, los campos, las relaciones, los diseños y otros componentes identificables existentes. A continuación, los desarrolladores pueden revisar la estructura importada, depurarla e integrarla gradualmente en la nueva arquitectura funcional.

Con ello no se pretende crear una copia sin modificaciones de todas las particularidades anteriores. Los rodeos que se han ido acumulando a lo largo del tiempo pueden revisarse y sustituirse por estructuras más claras. Al mismo tiempo, se conserva el conocimiento técnico de la solución actual.

Las aplicaciones nuevas y las migradas utilizan a partir de entonces las mismas herramientas, contenedores y vías de publicación.

Los cambios se convierten en versiones controladas

Un cambio realizado en el estudio no se convierte automáticamente en una actualización productiva. Durante el desarrollo, pueden aparecer diseños sin terminar, fórmulas provisionales o funciones que aún no se han comprobado.

Por lo tanto, los cambios relacionados pueden registrarse en sesiones de cambio y asignarse posteriormente a una versión. Solo tras su revisión y aprobación se genera una versión SSC publicada.

Además de la nueva estructura, una versión puede incluir las migraciones de datos necesarias, las indicaciones de versión, las dependencias, los pasos de verificación y la documentación. De este modo, el desarrollo propiamente dicho queda claramente separado de la entrega a las instancias de tiempo de ejecución en producción.

De este modo, SchallOS Studio no es solo el lugar donde se diseña y programa una aplicación. Combina el desarrollo visual, el modelo de datos, las fórmulas, las funciones, la documentación y la publicación en un único entorno.

Se mantiene la estrecha relación entre el desarrollador y la aplicación visible. Al mismo tiempo, se crea una base técnica sobre la que se pueden seguir desarrollando soluciones que sean portables, comprensibles y fáciles de mantener a largo plazo.

La IA, allí donde surgen las fórmulas y las funciones

Hasta ahora, en muchos entornos de desarrollo, la inteligencia artificial se ofrece principalmente a través de una ventana de chat adicional. El desarrollador describe un problema, copia el código fuente o las fórmulas en el chat y, a continuación, vuelve a introducir el resultado en el proyecto. Sin embargo, al modelo de lenguaje a menudo le falta información importante sobre tablas, campos, relaciones y el significado técnico de la aplicación.

Por eso, SchallOS integra la IA directamente en las herramientas de desarrollo. Está disponible allí donde se editan fórmulas, funciones personalizadas y contenedores de funciones. De este modo, no solo recibe una pregunta concreta, sino que también conoce el contexto actual de la solución.

En el editor de fórmulas, por ejemplo, la IA conoce la expresión que se está editando, los campos disponibles y el tipo de resultado esperado. Dentro de un contenedor de funciones, además, puede acceder a su descripción, parámetros, capacidades y dependencias.

De este modo, la IA no se convierte en un programa auxiliar independiente, sino en una parte integrante del propio entorno de desarrollo.

Ayuda en el editor de fórmulas

Las fórmulas controlan numerosos procesos de una aplicación empresarial. Calculan precios, comprueban condiciones, determinan plazos o influyen en la presentación de los objetos de diseño. La IA integrada puede, entre otras cosas, en el editor de fórmulas:

• explicar una fórmula ya existente
• analizar los posibles errores
• Completar las condiciones
• simplificar una expresión
• transferir una fórmula FileMaker
• o elaborar un nuevo cálculo a partir de una descripción técnica.

Un desarrollador podría, por ejemplo, establecer que los pedidos que superen un determinado valor neto requieran una autorización adicional, siempre que no exista un contrato marco. La IA puede generar una fórmula a partir de ello, utilizando los campos disponibles en la solución. El resultado permanece visible como una fórmula normal. Se puede leer, modificar y calcular en tiempo real. De este modo, la IA no genera ningún proceso oculto cuyo comportamiento resultara difícil de comprender.

Si falta un comando necesario, la IA también puede ayudar a crear una función personalizada adecuada o una ampliación del entorno de fórmulas. De este modo, el conjunto de comandos de SchallOS, inicialmente más reducido, sigue siendo ampliable.

Funciones personalizadas a partir de especificaciones técnicas

Los cálculos recurrentes se pueden gestionar de forma centralizada como funciones personalizadas. La IA puede generar, a partir de una descripción, una función con parámetros únicos, un valor de retorno y un comportamiento documentado.

Una función de este tipo podría, por ejemplo, calcular los plazos de descuento, comprobar los rangos de números o armonizar los valores importados. Además de la impresión propiamente dicha, también se pueden generar valores de prueba, ejemplos y posibles casos de error.

Esto no solo facilita la programación inicial. En caso de que se produzca un cambio posterior, la IA puede reconocer cuál es la función de esa función y en qué puntos se utiliza.

De este modo, un cálculo anónimo se convierte en un componente documentado y reutilizable de la solución.

Contenedores de funciones como lógica de programa descrita

En SchallOS, los procesos más complejos se organizan mediante contenedores de funciones. Un contenedor de funciones puede, por ejemplo, crear registros, comprobar entradas, controlar cuadros de diálogo, generar documentos o acceder a interfaces externas. La base la constituye una descripción estructurada. Esta puede especificar:

• qué función cumple
• qué parámetros se pasan
• qué resultado se espera
• a qué tablas y campos se puede acceder
• qué otras funciones se utilizan
• y qué operaciones quedan expresamente excluidas.

A partir de estas especificaciones, la IA programa el código ejecutable del contenedor de funciones. De este modo, el desarrollador ya no tiene que componer el flujo de trabajo exclusivamente a partir de numerosos pasos de script individuales. Su tarea se centra ahora más en la descripción precisa de la función deseada, sus límites y la comprobación posterior.

No obstante, el código generado sigue siendo visible. Se puede leer, probar, revisar y comparar entre diferentes versiones. También es posible conservar versiones anteriores y recuperarlas si es necesario. De este modo, la IA se encarga de la programación, pero no de la responsabilidad técnica.

Los guiones de FileMaker como recurso didáctico

En el caso de las soluciones FileMaker migradas, los scripts existentes suelen contener gran parte de la lógica de negocio desarrollada a lo largo de los años. Muestran qué campos se modificaron, qué condiciones se comprobaron y qué otros procesos se ejecutaron.

Estos scripts no se incorporan de forma permanente en SchallOS como una capa ejecutable en tiempo de ejecución. De hacerlo, muchas de las dependencias técnicas y soluciones provisionales anteriores simplemente se trasladarían al nuevo sistema. En su lugar, el script FileMaker original puede conservarse en segundo plano dentro del contenedor de funciones correspondiente. Sirve a la IA como capa de aprendizaje, referencia y comprensión.

La IA puede deducir a partir de ello la intención funcional del proceso anterior. A continuación, programa el nuevo código adaptándolo a la arquitectura de SchallOS. No es necesario mantener sin cambios elementos históricos del diseño, como los cambios frecuentes de diseño, los campos globales o los scripts auxiliares dependientes del contexto. Estos solo se conservarán si son realmente necesarios para el proceso de negocio propiamente dicho.

No obstante, el script original se conserva como fuente de información. En caso de consultas posteriores, permite comprender cómo se resolvió inicialmente un proceso en la solución FileMaker.

Las capacidades y los límites se definen de forma explícita

Un contenedor de funciones no debe poder acceder a cualquier área de la aplicación basándose únicamente en una descripción general. Por ello, es posible definir de forma explícita las capacidades permitidas y las exclusiones.

Por ejemplo, una función puede tener permiso para leer y modificar registros de una tabla concreta, sin poder, al mismo tiempo, realizar operaciones de eliminación ni modificar la configuración del sistema. Si el código generado utiliza una capacidad no autorizada, SchallOS puede detectarlo y bloquear su ejecución o publicación.

Por lo tanto, la descripción de un contenedor de funciones no sirve únicamente como documentación, sino que forma parte del modelo de verificación y seguridad. Esta limitación es especialmente importante en el caso del código generado por IA. Al modelo de lenguaje se le asigna un margen de maniobra claro, mientras que la plataforma comprueba si la función generada se mantiene dentro de ese marco.

El contexto adecuado mejora los resultados

La calidad de una función generada por IA no depende únicamente del tamaño del modelo de lenguaje utilizado. Lo decisivo es si el modelo recibe la información necesaria. SchallOS puede reconstruir el contexto a partir de varios niveles:

1. la pregunta actual
2. en el editor abierto
3. el campo o contenedor de funciones seleccionado
4. las tablas y relaciones implicadas
5. fórmulas y funciones existentes
6. descripciones semánticas
7. Documentación e historial de cambios
8. así como, en caso de migraciones, el script FileMaker original.

De este modo, la IA puede trabajar con mucha mayor precisión que en el caso de una consulta aislada en un chat general.

Al mismo tiempo, no es necesario proporcionar la solución completa en cada ejercicio. El contexto puede limitarse a la información que realmente se necesita para la función en cuestión.

Modelos intercambiables en lugar de un compromiso permanente

La capa de IA no debe depender de forma permanente de un único modelo o proveedor. Las diferentes tareas plantean distintos requisitos en cuanto a calidad, velocidad, costes y protección de datos.

Una migración compleja puede requerir un modelo especialmente potente. Es posible que una explicación sencilla o un ajuste de fórmulas se puedan llevar a cabo con un modelo más pequeño. En entornos sensibles o cerrados, también se pueden utilizar a largo plazo modelos que se ejecuten localmente.

Por lo tanto, la base de conocimiento permanente no reside en el modelo lingüístico, sino en la solución SchallOS: en descripciones, estructuras, referencias a scripts, código, pruebas y documentación. El modelo de IA sigue siendo una herramienta intercambiable que, a partir de este contexto, genera código ejecutable o sugerencias comprensibles.

Desarrollo transparente basado en la inteligencia artificial

SchallOS combina el trabajo directo con aplicaciones empresariales con la programación basada en IA. Las fórmulas se pueden explicar y generar directamente. Las funciones personalizadas se crean a partir de especificaciones técnicas reutilizables. Los contenedores de funciones combinan descripciones semánticas con código visible y verificable.

En el caso de las soluciones migradas, los scripts FileMaker se conservan como una capa de aprendizaje adicional. Ayudan a comprender los procesos de negocio existentes sin mantener de forma permanente las dependencias técnicas anteriores.

Esto no significa que el papel del desarrollador vaya a desaparecer. Simplemente cambia. Los requisitos precisos, una arquitectura adecuada, las pruebas y el control técnico cobran más importancia que la introducción manual de cada paso del programa. Precisamente en el caso del software crítico para el negocio, esta responsabilidad sigue siendo indispensable.

Encuesta actual sobre el uso de sistemas locales de IA

Documentación y registros de eventos como parte de la aplicación

La documentación de una aplicación empresarial suele redactarse solo una vez finalizado el desarrollo. Ante la presión del tiempo, el trabajo se centra inicialmente en los nuevos campos, diseños, fórmulas y funciones. La descripción de los cambios se deja para más adelante.

Sin embargo, a medida que pasa el tiempo, resulta cada vez más difícil comprender las decisiones originales. A menudo ya no se sabe con exactitud por qué se añadió una función concreta, qué objetos se vieron afectados y qué casos especiales hubo que tener en cuenta. Por eso, SchallOS no considera la documentación como una tarea adicional a posteriori. Los cambios relevantes se registran como eventos ya durante el desarrollo y se vinculan a los componentes afectados de la solución.

A partir de esta información se pueden generar posteriormente documentaciones técnicas, notas de versión, informes de clientes o registros de rendimiento. De este modo, la documentación no se basa únicamente en recuerdos o notas tomadas a mano, sino en los cambios realmente realizados.

Acontecimientos en varios niveles

Una solución SchallOS no cuenta únicamente con un único protocolo general. La plataforma distingue entre distintos niveles de eventos, cada uno con sus propias tareas.

• En Protocolo estructural registra los cambios realizados en el SSC. Entre ellos se incluyen, por ejemplo, nuevas tablas y campos, diseños modificados, fórmulas modificadas o nuevos contenedores de funciones.
• En Registro de eventos de datos Forma parte del SSD. En él se registran los procesos relevantes desde el punto de vista técnico que tienen lugar durante el uso productivo, como cambios de estado, autorizaciones, anulaciones o modificaciones de registros importantes.
• A esto hay que añadir Incidentes operativos de Runtime y SchallOS Control. Entre ellas se incluyen, entre otras cosas, las implementaciones, las actualizaciones, las comprobaciones, las copias de seguridad y los procesos de reversión.

Estas áreas permanecen separadas, pero pueden conectarse entre sí. Un registro de desarrollo no debe volverse confuso debido a los cambios cotidianos en los registros de los clientes. Por el contrario, los detalles técnicos internos no deben incluirse automáticamente en el historial funcional de una factura o un pedido.

El protocolo de estructura muestra la evolución de la solución

Los cambios en tablas, campos, diseños, fórmulas y contenedores de funciones pueden guardarse como eventos estructurados. Una entrada puede registrar qué objeto se ha modificado, cuál era su estado anterior y cuál es su nuevo estado. Además, se pueden registrar los desarrolladores, la fecha y hora, la justificación técnica, el encargo correspondiente y la versión de lanzamiento prevista.

Si, por ejemplo, se añade un nuevo proceso de autorización para los pedidos, es posible que se produzcan varios cambios técnicos. Se crea un campo de estado, se amplía un diseño, se adapta una fórmula y se programa un nuevo contenedor de funciones.

El protocolo estructural conserva estos eventos individuales. Al mismo tiempo, pueden agruparse bajo una tarea técnica común. De este modo, queda claro que varias modificaciones técnicas conforman, en conjunto, un nuevo proceso de negocio.

Las sesiones «Change» agrupan trabajos relacionados entre sí

Una tarea de desarrollo suele constar de muchos pequeños pasos. Una lista meramente cronológica de los cambios individuales no reflejaría adecuadamente el contexto real.

Por ello, SchallOS puede agrupar las tareas relacionadas en «Change Sessions». Una «Change Session» describe una tarea concreta, una ampliación o una corrección de errores, y recopila todos los eventos relacionados. Por ejemplo, puede incluir:

• la descripción de las funciones profesionales
• tablas y diseños afectados
• Fórmulas y funciones modificadas
• pruebas realizadas
• cuestiones pendientes
• así como la asignación a un cliente o a un pedido.

Más adelante, se pueden asignar varias sesiones de cambios a una versión. De este modo, se establece una relación clara entre el encargo de desarrollo, los cambios técnicos y la versión publicada.

La IA presenta los incidentes técnicos de forma comprensible

La capa de documentación está conectada a la IA integrada de SchallOS. De este modo, los eventos registrados pueden adaptarse automáticamente a los distintos grupos destinatarios.

Un informe técnico de desarrollo requiere información diferente a la de un comunicado al cliente. Mientras que el desarrollador desea ver nombres de campos concretos, contenedores de funciones y migraciones de datos, al cliente le interesa sobre todo qué función se ha añadido y qué ventajas ofrece. Por ello, la IA puede resumir los mismos acontecimientos de diferentes formas:

• como documentación técnica interna
• como información clara para los clientes
• como notas de la versión
• como informe del proyecto
• o como justificante de pago de una factura.

Los textos no se generan libremente a partir de una descripción general. Se derivan de las sesiones de cambio, las descripciones semánticas de los objetos y los cambios estructurales reales.

El texto generado sigue vinculado a sus fuentes. El desarrollador puede comprobar en qué acontecimientos se basa una afirmación y corregir o aprobar la redacción antes de su uso.

Informes de rendimiento para desarrolladores y clientes

Para los desarrolladores de software a medida, la documentación también reviste importancia desde el punto de vista económico. Los servicios deben explicarse al cliente de forma comprensible y, a menudo, facturarse por tiempo o por paquete de trabajo.

En la práctica, estos informes de servicios suelen elaborarse a menudo justo antes de emitir la factura. Para ello, hay que revisar correos electrónicos, notas y recordatorios.

SchallOS puede asignar los eventos de desarrollo registrados realmente a un cliente, un proyecto o un encargo. A partir de ellos, la IA genera las entradas adecuadas para un informe de prestaciones. Por ejemplo, se pueden agrupar varias modificaciones técnicas en una única prestación comprensible:

Ampliación de la gestión de pedidos con un proceso de autorización en dos fases que incluye la comprobación del estado, los derechos de usuario y la personalización del formulario de introducción de datos.

Los procesos técnicos subyacentes siguen estando disponibles para su consulta. La descripción del cliente constituye únicamente un resumen comprensible. La decisión final recae en el desarrollador. No todos los eventos técnicos son facturables automáticamente, y las pruebas internas o las correcciones no tienen por qué aparecer individualmente en una factura.

Eventos a nivel de datos

También durante el funcionamiento en producción se pueden registrar todos los eventos de datos previstos. Entre ellos se incluyen la creación y modificación de registros, los cambios de estado, las autorizaciones, las importaciones, las exportaciones o los procesos ejecutados automáticamente. Una entrada puede registrar:

• qué usuario o proceso ha desencadenado la acción
• qué registro se vio afectado
• qué valores se han modificado
• qué función se ha ejecutado
• y si el proceso se ha completado con éxito.

La solución elegida determina qué eventos se almacenan y con qué nivel de detalle. Una pequeña corrección en el texto tiene un significado distinto al de la modificación de una factura ya emitida. El registro de eventos de datos constituye, por tanto, el historial técnico del SSD. Sirve de apoyo al servicio de asistencia, al análisis de errores y a la trazabilidad de los procesos empresariales importantes.

Un protocolo de este tipo también puede servir de base para los requisitos de auditoría. No obstante, es necesario comprobar, en cada caso concreto, si con él se cumplen todas las disposiciones legales o específicas del sector.

La documentación también acompaña a los lanzamientos y las actualizaciones

Los eventos de desarrollo registrados se incorporan al mismo tiempo al proceso de lanzamiento y actualización. Cuando se publica una nueva versión, SchallOS puede recopilar automáticamente qué funciones se han añadido, qué errores se han corregido y qué estructuras de datos se han modificado. A partir de ahí se generan listas de cambios técnicos, notas para los usuarios e información sobre la migración.

Tras la instalación, se puede comprobar qué versión se ha instalado en una instancia de tiempo de ejecución concreta y qué cambios incluía.

También se documentan los eventos operativos, como las copias de seguridad, las comprobaciones o una posible reversión. De este modo, más adelante no solo se puede determinar qué se ha desarrollado, sino también cuándo y con qué resultado se ha implementado un cambio en producción.

Una base de conocimientos cada vez mayor

La combinación del registro de eventos, las descripciones semánticas y el apoyo de la inteligencia artificial crea, a largo plazo, una base de conocimientos sobre la solución en su conjunto. En caso de que se produzca un cambio posterior, no solo se podrá examinar el código actual, sino que también quedará claro cuándo se introdujo una función, cuál fue el motivo empresarial que la motivó y qué otras áreas se vieron afectadas en aquel momento.

Este conocimiento resulta decisivo, sobre todo en el caso de las aplicaciones empresariales que se han ido desarrollando a lo largo de muchos años. Un caso especial que pueda parecer superfluo puede tener una razón histórica importante. Sin documentación, existe el riesgo de que se elimine por error durante una revisión posterior. Por eso, SchallOS no solo conserva los estados técnicos, sino también el historial de desarrollo y las decisiones relacionadas con él.

De este modo, la documentación se convierte en un componente activo de la aplicación. Sirve de apoyo al desarrollo, la comunicación con los clientes, la facturación, la asistencia técnica, las versiones y el mantenimiento a largo plazo, basándose en los eventos que realmente han tenido lugar en el sistema.

Un proceso de actualización para toda la plataforma y las aplicaciones

El software empresarial rara vez permanece inalterado durante mucho tiempo. Los nuevos requisitos, los cambios legislativos, las correcciones de errores y los avances técnicos dan lugar periódicamente a nuevas versiones. En este contexto, no basta con limitarse a intercambiar archivos. Antes de cada actualización, hay que comprobar qué versión está en uso, si es necesario adaptar las estructuras de datos y cómo se puede restaurar el estado anterior en caso de error.

En muchas aplicaciones específicas, estos procedimientos se desarrollan a posteriori. Las actualizaciones se distribuyen entonces mediante instrucciones manuales, copias de seguridad y scripts personalizados para cada cliente. Con cada nueva instalación aumenta el riesgo de que surjan versiones diferentes y soluciones específicas.

Por ello, SchallOS considera las actualizaciones como una función de la plataforma a nivel de todo el sistema. Tanto el propio SchallOS como las soluciones para clientes desarrolladas con la plataforma se actualizan a través del mismo proceso básico.

De este modo, un desarrollador no tiene que diseñar primero un proceso de actualización propio para una nueva aplicación. La gestión de versiones, las comprobaciones, la distribución y el registro forman parte de la arquitectura común desde el principio.

La separación entre SSC y SSD protege los datos productivos

La capacidad de actualización está directamente relacionada con la separación entre la estructura y los datos. El SSC contiene diseños, fórmulas, contenedores de funciones, definiciones de lenguaje y el modelo de datos de la aplicación. El SSD contiene los datos empresariales operativos de la empresa en cuestión.

Por lo tanto, al lanzar una nueva versión, no se sustituye toda la aplicación, incluidos todos los datos de los clientes. En su lugar, se puede publicar un nuevo SSC, mientras que el SSD existente permanece en el lugar de implementación.

Si la nueva estructura requiere campos adicionales, tablas o formatos de datos modificados, se ejecutarán los pasos de migración definidos expresamente para ello. Los datos productivos se adaptarán de forma controlada a la nueva estructura y no se sustituirán de forma inadvertida por otro conjunto de datos.

Esta clara separación permite seguir desarrollando las aplicaciones a lo largo de muchos años sin tener que transferir todos los datos empresariales a un nuevo fichero completo con cada actualización.

Desde la fase de desarrollo hasta el lanzamiento

No todos los cambios introducidos en SchallOS Studio son aptos de inmediato para su uso en entornos productivos. Durante la fase de desarrollo, pueden aparecer diseños provisionales, funciones incompletas o fórmulas que aún no se han comprobado.

Por ello, los cambios relacionados se registran inicialmente en sesiones de cambios y se asignan a una versión planificada. Solo tras su revisión y aprobación se convierte en una versión publicada. Una versión puede incluir, entre otras cosas:

• un número de versión único
• el SSC actualizado
• migraciones necesarias a SSD
• Requisitos técnicos
• Dependencias de Runtime o de adaptadores
• Pasos de comprobación y prueba
• Notas de la versión
• así como información para una posible reversión.

La capa de documentación proporciona la base para ello. A partir de los eventos de desarrollo registrados, se pueden generar automáticamente listas de cambios técnicos e instrucciones claras para el usuario.

Por lo tanto, una versión no solo consta de archivos modificados. También describe qué se ha cambiado, cuáles son los requisitos previos y cómo debe comprobarse la instalación.

SchallOS Control controla la distribución

SchallOS Control se encarga de la gestión operativa de las actualizaciones. En esta herramienta se puede ver qué instancias hay, qué versiones se han clasificado en 1TP12 y qué actualizaciones están disponibles. Antes de la instalación, Control puede comprobar, entre otras cosas:

• si se puede acceder a la instancia de destino
• qué versión de Runtime y de SSC se utiliza
• qué adaptador de base de datos está activo
• si es posible crear una copia de seguridad adecuada
• y si se cumplen todos los requisitos de la versión.

De este modo se evita que se lleve a cabo una actualización en una instalación que no cumpla los requisitos técnicos o que no esté debidamente preparada.

Además, no es necesario distribuir una versión a todos los sistemas al mismo tiempo. En un primer momento, puede implementarse en un entorno de prueba o en instalaciones seleccionadas. Solo tras superar con éxito las pruebas se lleva a cabo el despliegue a mayor escala.

Para ello, se pueden establecer diferentes canales de actualización, como, por ejemplo, versiones estables en producción, versiones preliminares, pruebas internas o lanzamientos específicos para cada cliente.

Firmas y números de versión únicos

Los paquetes de actualización pueden incluir sumas de comprobación y firmas digitales. De este modo, SchallOS Control detecta si un paquete está completo, procede de la fuente prevista y si ha sido modificado desde su publicación.

Además, se comprueba si la versión pertenece realmente a la solución en cuestión. No se debe conectar por error un nuevo SSC al SSD de otra aplicación.

Los identificadores únicos de soluciones, las versiones de estructura y las versiones de modelo de datos garantizan que el estado de la implementación install siga siendo trazable. También se pueden identificar los pasos intermedios necesarios. Por ejemplo, una instalación no puede pasar directamente de una versión muy antigua a la más reciente si antes es necesario llevar a cabo una migración de datos.

Copia de seguridad, migración y verificación

Antes de realizar una actualización estructural, se realiza una copia de seguridad del estado actual. La forma concreta de realizar dicha copia de seguridad depende del adaptador de base de datos utilizado. Una instalación local de IndexedDB o SQLite requiere procedimientos distintos a los de un servidor PostgreSQL.

A continuación, se comprueba el paquete de actualización, se implementa la nueva estructura 1TP12 y se lleva a cabo la migración de datos que sea necesaria. Tras la activación, se procede a la verificación. En este proceso, SchallOS puede comprobar, por ejemplo:

• si están presentes todas las tablas y campos previstos,
• si la migración de datos se ha llevado a cabo en su totalidad,
• si el número de registros y las sumas de comprobación son correctos,
• y si las funciones importantes se llevan a cabo correctamente.

Solo cuando estas comprobaciones se hayan completado con éxito, la actualización se considerará de nivel 1TP12. Por lo tanto, no basta con una simple transferencia de archivos. Lo fundamental es que, tras el proceso, la estructura, los datos y el tiempo de ejecución vuelvan a constituir un conjunto coherente y operativo.

Restauración en caso de actualizaciones fallidas

A pesar de una preparación minuciosa, una actualización puede fallar. La presencia inesperada de datos antiguos, una migración defectuosa o una dependencia no tenida en cuenta pueden impedir que se active de forma segura una nueva versión. Para estos casos, el procedimiento de actualización incluye una reversión. En ella se restablecen la versión anterior de SSC, el estado guardado de SSD y la configuración anterior.

Sin embargo, no todas las actualizaciones pueden revertirse durante un periodo de tiempo ilimitado. Si, tras la instalación, ya se han procesado nuevos datos productivos según las reglas modificadas, volver completamente a la versión anterior puede resultar problemático. Por lo tanto, cada versión debe especificar en qué condiciones es posible realizar una reversión.

En algunos casos, resulta más conveniente realizar una actualización correctiva posterior que restaurar un conjunto de datos anterior. La plataforma proporciona el marco técnico necesario, pero la decisión concreta depende del cambio en cuestión y de su relevancia técnica.

El propio SchallOS también utiliza este proceso

El proceso de actualización no está destinado únicamente a las soluciones de los clientes. SchallOS Studio, Runtime, Control y otros componentes de la plataforma también se actualizan mediante los mismos mecanismos básicos. Las nuevas versiones de la plataforma pueden incluir ampliaciones del entorno de fórmulas, mejoras en la capa de IA, nuevos adaptadores de bases de datos o correcciones de seguridad. En este caso también se requieren números de versión, dependencias, firmas y comprobaciones.

De este modo, la propia plataforma utiliza y pone a prueba continuamente la infraestructura durante su funcionamiento. Las aplicaciones desarrolladas con SchallOS se benefician de los mismos procedimientos.

De este modo, el desarrollador no recibe una función de actualización meramente teórica, sino un proceso que forma parte tanto del funcionamiento como del desarrollo continuo de todo el sistema.

Una vía prevista para futuras versiones

El punto fuerte del proceso de actualización no radica únicamente en la distribución automática de nuevos archivos. Lo decisivo es la integración del desarrollo, la documentación, las copias de seguridad, la migración, las pruebas y la reversión en un único proceso.

Tanto SchallOS como las aplicaciones desarrolladas con él utilizan la misma infraestructura básica. La separación entre SSC y SSD garantiza que la estructura pueda seguir evolucionando, al tiempo que los datos productivos quedan protegidos y se adaptan de forma controlada.

Una solución desarrollada con SchallOS cuenta, por tanto, desde el principio con una vía prevista para futuras versiones. Precisamente en el caso del software empresarial, que está destinado a utilizarse durante muchos años, esta capacidad de actualización no es una función adicional, sino un requisito esencial para garantizar un mantenimiento a largo plazo y un funcionamiento fiable.

Entorno de ejecución, control y nube para distintos modelos operativos

Un entorno de desarrollo requiere amplias posibilidades. Los desarrolladores deben poder modificar estructuras, diseñar maquetaciones, editar fórmulas y publicar nuevas funciones. Sin embargo, en el funcionamiento diario de una aplicación empresarial ya terminada, estas herramientas no suelen ser necesarias.

Por ello, SchallOS divide el desarrollo, la ejecución y la gestión en distintas áreas. SchallOS Studio se encarga del desarrollo. SchallOS Runtime ejecuta las aplicaciones publicadas. SchallOS Control gestiona su implementación técnica. SchallOS Cloud ofrece la misma arquitectura básica como servicio en línea gestionado de forma centralizada.

De este modo, no se crean aplicaciones independientes entre sí. Todas las áreas funcionan con las mismas estructuras SSC y SSD. El modo de funcionamiento se define mediante el despliegue, el adaptador de base de datos y el perfil de tiempo de ejecución.

SchallOS Runtime ejecuta las soluciones publicadas

SchallOS Runtime conecta el SSC de una aplicación con el SSD correspondiente y pone a disposición los diseños, fórmulas y funciones definidos en él. El tiempo de ejecución incluye, entre otras cosas, la visualización y el manejo de los diseños, la lectura y edición de registros, el cálculo de fórmulas y funciones personalizadas, la ejecución de contenedores de funciones, la navegación y el control de los cuadros de diálogo, la multilingüidad, así como la conexión con el adaptador de base de datos previsto.

Sin embargo, el Runtime no incluye automáticamente todas las herramientas de SchallOS Studio. No puede crear nuevos pares de soluciones SSC/SSD y no dispone de un asistente de migración para soluciones FileMaker.

De este modo, una aplicación de cliente entregada queda claramente separada del entorno de desarrollo propiamente dicho.

Los perfiles determinan las capacidades de un entorno de ejecución

No todas las instalaciones requieren el mismo conjunto de funciones. Es posible que una aplicación destinada exclusivamente al usuario final solo tenga que ejecutar diseños y procesos de negocio publicados. Una instalación interna puede necesitar funciones adicionales de administración o diagnóstico.

Para ello, SchallOS utiliza perfiles de tiempo de ejecución y de capacidades. Estos definen las capacidades técnicas de las que dispone una instancia concreta.

Un perfil puede determinar, por ejemplo, si el modo de diseño está disponible, si se pueden importar o exportar datos, si se muestran los cuadros de diálogo administrativos, si se pueden modificar los ajustes locales o si se pueden utilizar determinadas interfaces.

Estos perfiles complementan los derechos de usuario dentro de la propia solución. Los derechos de usuario determinan qué acciones profesionales puede realizar una persona. Por su parte, el perfil de tiempo de ejecución establece qué posibilidades técnicas ofrece, en principio, la instalación en cuestión.

De este modo, se puede utilizar la misma base de tiempo de ejecución para diferentes grupos de clientes y casos de uso, sin tener que desarrollar una versión del programa específica para cada variante.

Desde un ordenador individual local hasta un entorno de servidor

Una solución SchallOS puede implementarse en diferentes modalidades de funcionamiento. Por ejemplo, para un puesto de trabajo local individual, el SSD puede almacenarse en IndexedDB. Una aplicación de escritorio de 1TP12 puede utilizar SQLite. Para soluciones multiusuario de mayor envergadura, se prevé el uso de una base de datos centralizada como PostgreSQL.

Los modelos operativos presentan características diferentes. IndexedDB es especialmente adecuado para aplicaciones locales de navegador. SQLite es una base consolidada para aplicaciones locales e instalaciones de tamaño reducido. PostgreSQL resulta ideal para sistemas centralizados multiusuario con una gestión profesional de los servidores.

SchallOS no considera estas tecnologías como ubicaciones de almacenamiento totalmente intercambiables. El cambio de adaptador requiere una transferencia controlada de datos, una comprobación y, en su caso, una reversión. La arquitectura conjunta SSC/SSD garantiza que no sea necesario desarrollar desde cero los diseños, las fórmulas y la lógica de negocio para cada adaptador de base de datos.

Aplicaciones de escritorio y uso del navegador

Las soluciones de SchallOS deben poder ejecutarse tanto en el navegador como en forma de aplicaciones instalables para Windows y macOS. Un entorno de ejecución de escritorio puede integrarse más estrechamente en el sistema operativo correspondiente, utilizar archivos locales de forma controlada y, con la configuración adecuada, trabajar temporalmente sin conexión. Puede almacenar sus datos localmente con IndexedDB o SQLite, o acceder a una base de datos central de PostgreSQL.

En el navegador, la aplicación se muestra mediante el propio entorno de ejecución de SchallOS. Para ello, no se necesita ni el servidor FileMaker ni FileMaker WebDirect. Por lo tanto, una solución FileMaker migrada ya no se ejecuta en segundo plano a partir de un archivo FileMaker tras la migración. Los diseños, las fórmulas y la lógica funcional se ejecutan dentro de la arquitectura de SchallOS.

SchallOS Control gestiona las instancias

SchallOS Control constituye el centro de control operativo de la plataforma. Desde allí se gestiona qué solución se ejecuta en cada sistema de destino y cuáles son los requisitos técnicos aplicables. Control puede mostrar, entre otras cosas:

• qué pares de SSC/SSD se han habilitado
• ¿Cuál es la versión de Runtime installiert?
• qué adaptador de base de datos se utiliza
• ¿Qué perfil de capacidades se aplica?
• qué actualizaciones hay disponibles
• y cuándo se comprobó por última vez una instancia.

Un destino de implementación puede ser, por ejemplo, una aplicación local de Windows, un entorno de ejecución de macOS, un servidor PostgreSQL propio, un entorno de pruebas o una instancia en la nube.

Los datos operativos, como las direcciones de los servidores, los accesos a las bases de datos, las licencias o las vinculaciones a dispositivos locales, no deben incluirse en el SSC portátil. Estos se gestionan en la configuración protegida de la instancia correspondiente.

Soluciones firmadas y distribución controlada

Los contenedores de soluciones portátiles no deben implicar que cualquier aplicación pueda modificarse a voluntad o ejecutarse en sistemas no previstos. Por ello, los paquetes SSC/SSD publicados pueden asociarse a identificadores de solución, sumas de comprobación, firmas e información de instancia. El entorno de ejecución puede comprobar, al iniciarse, si el SSC no ha sido modificado y cuenta con una firma válida, si el SSD pertenece a la solución correcta, si ambas versiones son compatibles entre sí y si existe un perfil de implementación válido.

En función del modelo de licencia, la asignación puede vincularse a una instancia, un servidor, un dispositivo o un conjunto determinado de usuarios. SchallOS Control gestiona también los cambios necesarios, como un cambio de servidor, una reactivación o la restauración de una instalación.

SchallOS Cloud como modelo operativo SaaS

SchallOS Cloud ofrece aplicaciones como un servicio en línea gestionado de forma centralizada. Sin embargo, la nube no utiliza un formato de solución propio ni diferente al habitual. Una aplicación desarrollada en SchallOS Studio puede asignarse a una instancia en la nube y ponerse a disposición a través del navegador. El entorno de ejecución, la base de datos, las copias de seguridad, la supervisión y las actualizaciones se gestionan de forma centralizada. Para los desarrolladores y los clientes, esto se traduce en un modelo SaaS sin necesidad de tener que volver a desarrollar la aplicación específicamente para una plataforma en la nube independiente.

Se mantiene la portabilidad básica. Una solución puede trasladarse posteriormente a un servidor propio o a otro entorno compatible, siempre que el volumen de datos, las funciones y los requisitos técnicos lo permitan. El cambio sigue siendo una migración controlada, pero no requiere una reconstrucción completa de la aplicación.

Una solución puede adaptarse a medida que aumentan tus necesidades

Una nueva aplicación puede desarrollarse inicialmente de forma local y probarse con un pequeño conjunto de datos. Posteriormente, se puede implementar como entorno de ejecución interno, migrarla a SQLite o PostgreSQL y, finalmente, publicarla como solución de servidor o en la nube. Las tablas, los diseños, las fórmulas, los contenedores de funciones, las traducciones y la documentación siguen formando parte de la misma estructura de la solución.

No todos los prototipos se convierten en una gran aplicación empresarial sin necesidad de adaptaciones. El funcionamiento multiusuario, la seguridad, el rendimiento y las copias de seguridad deben seguir planificándose cuidadosamente. Sin embargo, la plataforma evita que el crecimiento implique necesariamente un cambio tecnológico completo.

De este modo, Runtime, Control y Cloud combinan diferentes modelos operativos dentro de una arquitectura común. La aplicación se desarrolla una sola vez y, a continuación, se pone a disposición de forma controlada para cada uso concreto: de forma local, en un servidor propio o como SaaS en la nube.

Por supuesto. Yo incluiría este apartado justo después del capítulo sobre IA o como complemento del capítulo 4. Plantea una idea importante: la IA no está vinculada de forma fija a un proveedor concreto, sino que se trata, al igual que los adaptadores de bases de datos, como una infraestructura intercambiable.

Adaptadores de IA en lugar de dependencia de un fabricante

SchallOS separa deliberadamente la capa de IA propiamente dicha de los modelos de lenguaje utilizados. La plataforma no trabaja exclusivamente con un único proveedor ni con un entorno de ejecución concreto. En su lugar, permite configurar y gestionar de forma centralizada distintos adaptadores de IA.

Estos adaptadores sirven de enlace entre SchallOS y los modelos de lenguaje que se utilicen en cada caso. De este modo, el entorno de desarrollo propiamente dicho no depende de si la consulta se envía a un modelo local o a un servicio en la nube.

De este modo, la IA se convierte en un componente intercambiable de la plataforma, de forma similar a los adaptadores de bases de datos para IndexedDB, SQLite o PostgreSQL.

Gestión centralizada en SchallOS Control

La configuración de la IA se realiza de forma centralizada a través de SchallOS Control. En esta plataforma se pueden crear y gestionar tantos adaptadores de IA como se desee. Se admiten tanto modelos locales como servicios en la nube.

Los modelos locales pueden integrarse, por ejemplo, a través de Ollama o LM Studio. Para muchas tareas de desarrollo basta con un modelo local compacto que se ejecute íntegramente en el propio ordenador.

Además, se pueden configurar modelos en la nube como ChatGPT, Claude u otros servicios compatibles. Cada adaptador cuenta con su propia configuración, como datos de acceso, puntos finales, nombres de modelos u otros ajustes técnicos. De este modo, se obtiene una visión general centralizada de todos los sistemas de IA disponibles dentro de una instalación de SchallOS.

Una vez configurado, disponible en cualquier lugar

Una gran ventaja de esta arquitectura es que, una vez configurado, un adaptador de IA no se utiliza únicamente en un único punto. En cuanto se configura un adaptador en SchallOS Control, queda disponible para toda la plataforma. Se puede utilizar, por ejemplo:

• en el editor de fórmulas
• dentro de contenedores de funciones
• para la documentación automática
• en la migración de soluciones FileMaker
• en Adapter Studio
• o en futuras herramientas de desarrollo basadas en la inteligencia artificial.

Por lo tanto, el desarrollador no tiene que configurar varias veces los datos de acceso ni los modelos. La gestión se realiza de forma centralizada, mientras que los distintos componentes solo tienen que seleccionar el adaptador deseado.

El modelo adecuado para cada tarea

No todas las tareas de desarrollo requieren la misma potencia de cálculo. Para explicar brevemente una fórmula, suele bastar con un pequeño modelo local. En cambio, las migraciones de gran envergadura o las tareas de programación complejas pueden beneficiarse de un modelo en la nube más potente.

Por ello, SchallOS permite seleccionar diferentes adaptadores en función de cada caso concreto. Un desarrollador puede, por ejemplo, establecer que la documentación sencilla se cree siempre de forma local, mientras que las tareas especialmente extensas se transfieran a un modelo externo. De este modo, es posible equilibrar mejor la velocidad, la protección de datos y los costes.

Abierto a futuros modelos

El desarrollo en el ámbito de la inteligencia artificial avanza a un ritmo extraordinariamente rápido. Aparecen nuevos modelos a intervalos cortos, mientras que los sistemas existentes se mejoran continuamente. Por ello, SchallOS no se vincula de forma permanente a un único proveedor. Lo decisivo no es el nombre de un modelo concreto, sino la interfaz de adaptador estandarizada.

De este modo, más adelante se podrán incorporar nuevos sistemas de IA locales o basados en la nube sin tener que modificar el entorno de desarrollo propiamente dicho. Esta apertura se ajusta a la arquitectura básica de SchallOS. Al igual que ocurre con los adaptadores de bases de datos, los adaptadores de IA también deben seguir siendo intercambiables, mientras que Studio, el entorno de ejecución y la propia aplicación pueden seguir funcionando sin cambios.

De este modo, la inteligencia artificial se convierte en una función integrada de forma permanente en la plataforma, independientemente de los modelos o proveedores que se impongan en el mercado en los próximos años.

De la migración de FileMaker a una plataforma de software independiente

SchallOS es fruto de muchos años de trabajo con FileMaker. Muchas de las ideas fundamentales de la plataforma se basan en la experiencia adquirida con soluciones individuales de bases de datos y ERP, que han ido evolucionando a lo largo de los años junto con las necesidades operativas de las empresas.

FileMaker destaca especialmente por su rapidez de desarrollo. El modelo de datos, los diseños y la lógica del programa están muy próximos entre sí, los cambios se ven de inmediato y se pueden crear soluciones funcionales iniciales con relativa rapidez.

En SchallOS se mantendrá esta proximidad entre el desarrollador, los datos y la interfaz de usuario. Sin embargo, se reconstruirá la base técnica. SchallOS utiliza su propio entorno de ejecución, sus propios contenedores de estructura y de datos, una capa funcional basada en IA, así como su propia infraestructura para la documentación, la implementación y las actualizaciones.

Por lo tanto, FileMaker sigue siendo un punto de partida importante y una posible fuente de soluciones existentes. Sin embargo, ya no es necesario para el funcionamiento posterior.

La migración es más que una simple importación de diseño

Una solución FileMaker consolidada no se compone únicamente de tablas, campos y máscaras visibles. Gran parte de su conocimiento funcional se encuentra en fórmulas, scripts, disparadores, relaciones, listas de valores y numerosos casos especiales.

Una migración eficaz debe tener en cuenta estas interrelaciones y trasladarlas a una nueva arquitectura. Las tablas, los campos, las relaciones y los diseños pueden transferirse de forma estructurada en gran medida. Las fórmulas y las funciones personalizadas se transfieren al entorno de fórmulas de SchallOS o se adaptan a él.

En el caso de los scripts FileMaker, lo primordial es, en primer lugar, comprender su función técnica. Pueden conservarse como capa de aprendizaje y referencia en segundo plano de los nuevos contenedores de funciones. Sin embargo, el código ejecutable se reprogramará mediante IA para adaptarlo a la arquitectura de SchallOS. De este modo, no se generará un tiempo de ejecución de FileMaker dentro de un nuevo sistema. La solución existente se convertirá gradualmente en una aplicación independiente de SchallOS.

Funcionamiento autónomo tras la migración

Tras una migración completa, ya no se necesitarán ni FileMaker Pro, ni FileMaker Server, ni WebDirect. La nueva aplicación utiliza SchallOS Runtime, el SSC como contenedor de estructuras y el SSD para los datos productivos. Las fórmulas, los contenedores de funciones, el multilingüismo, la documentación, los registros de eventos y las actualizaciones son proporcionados por la plataforma SchallOS.

En función de las necesidades, la solución puede ejecutarse de forma local, como aplicación para Windows o macOS, en un servidor propio o como servicio SaaS en SchallOS Cloud.

De este modo, se pone fin a la dependencia de un único entorno de ejecución propietario. Las dependencias técnicas no desaparecen por completo —todo software moderno necesita sistemas operativos, bases de datos y servicios de servidor—. Sin embargo, la estructura, la lógica de negocio y los datos siguen siendo portables y pueden ejecutarse mediante adaptadores y vías de implementación documentadas.

Nuevas posibilidades para los desarrolladores de FileMaker

Para los desarrolladores de FileMaker, SchallOS no supone una ruptura total con la forma de trabajar habitual hasta ahora. Los conocimientos sobre modelos de datos, diseño de maquetación y procesos operativos siguen siendo muy valiosos.

El cambio principal se produce en la aplicación de la lógica del programa. Las largas cadenas de scripts se sustituyen por contenedores de funciones descritos semánticamente. La IA programa el código ejecutable basándose en tareas, parámetros y límites definidos. El desarrollador comprueba el resultado y sigue siendo responsable de la arquitectura y de la corrección técnica.

También se tiene más en cuenta el historial de desarrollo. Los cambios pueden registrarse, documentarse y agruparse automáticamente en versiones. El mismo proceso de actualización que se utiliza para actualizar el propio SchallOS también está disponible para las soluciones personalizadas de los clientes.

De este modo, el trabajo pasa, en parte, de la introducción manual de pasos individuales del programa a la descripción, verificación y estructuración precisas de los procesos empresariales.

No solo para aplicaciones migradas

La migración FileMaker sigue siendo un componente importante de SchallOS, pero no es su único uso. Las nuevas aplicaciones se pueden desarrollar íntegramente en SchallOS Studio.

A largo plazo, también se podrían admitir otros sistemas de origen. Sin embargo, cada ampliación de este tipo requiere sus propios procedimientos de análisis y migración. Las distintas plataformas de desarrollo tienen sus propios conceptos, que no pueden reproducirse de forma adecuada mediante una importación universal superficial.

La experiencia adquirida con la migración de FileMaker sienta las bases para ello. Sin embargo, el objetivo real de SchallOS es el desarrollo y la gestión de aplicaciones empresariales independientes.

Inicio previsto para el otoño de 2026

El lanzamiento público de SchallOS está previsto para el otoño de 2026. Hasta entonces, se seguirán integrando, comprobando y preparando los componentes fundamentales de la plataforma para los primeros casos de uso en producción. No todas las funciones previstas a largo plazo estarán completamente desarrolladas en el momento del lanzamiento. Lo fundamental es contar con un núcleo robusto sobre el que puedan integrarse de forma controlada otros adaptadores de bases de datos, funciones de IA, opciones de migración y modelos operativos.

En primer lugar, se... Software ERP gFM-NEXT de gofilemaker.de Se prevé que se publique en la nueva plataforma SchallOS en septiembre de 2026. Por lo tanto, el lanzamiento de la plataforma de desarrollo SchallOS, previsto para algo más tarde, en otoño de 2026, no marcará el final del desarrollo, sino el inicio de su uso práctico.

El ciclo de vida completo de una aplicación

SchallOS partió de la pregunta de cómo se podían trasladar las soluciones FileMaker existentes a un entorno moderno. De ahí surgió una plataforma que no solo tiene en cuenta la migración y el desarrollo, sino también la documentación, la implementación, la gestión de datos, las actualizaciones y el funcionamiento a largo plazo. Studio, Runtime, Control y Cloud asumen tareas claramente diferenciadas dentro de una arquitectura común. Por lo tanto, el objetivo no es simplemente sustituir FileMaker por otra herramienta de desarrollo. SchallOS pretende combinar la probada proximidad entre el desarrollador, los datos y la interfaz de usuario con contenedores portátiles, programación basada en IA y un modelo operativo integral.

El ADN de FileMaker constituye el punto de partida. El objetivo es crear una plataforma independiente en la que se puedan desarrollar, gestionar y mantener a largo plazo tanto las aplicaciones empresariales existentes como las nuevas.

Artículos de actualidad sobre inteligencia artificial

IA para principiantes: cómo iniciarse en la inteligencia artificial sin conocimientos previos

IA para principiantes: cómo iniciarse en la inteligencia artificial sin conocimientos previos

FileMaker Conferencia 2025: IA, comunidad y un incidente inesperado

FileMaker Conferencia 2025: IA, comunidad y un incidente inesperado

La IA en la nube como directora: por qué el futuro del trabajo pasa por la IA local

La IA en la nube como directora: por qué el futuro del trabajo pasa por la IA local

La propiedad digital explicada - Cómo se crean activos sostenibles en línea

La propiedad digital explicada - Cómo se crean activos sostenibles en línea

Preguntas más frecuentes

1. ¿Qué es exactamente SchallOS y en qué se diferencia de una aplicación de base de datos clásica?
   SchallOS es una plataforma para el desarrollo, la ejecución y la gestión de software empresarial personalizado. No solo incluye hojas de cálculo, diseños y funciones, sino también programación basada en inteligencia artificial, documentación, registros de eventos, implementación y actualizaciones. SchallOS Studio sirve para el desarrollo, Runtime ejecuta las aplicaciones ya creadas, Control gestiona las instalaciones y Cloud ofrece soluciones en formato SaaS. De este modo, la plataforma acompaña a una aplicación desde su creación hasta su funcionamiento a largo plazo.
2. ¿A qué desarrolladores y empresas va dirigido SchallOS?
   SchallOS está dirigido especialmente a desarrolladores de FileMaker, empresas de software y desarrolladores de aplicaciones empresariales personalizadas. Las empresas que ya cuentan con soluciones FileMaker también tienen la posibilidad de migrar sus aplicaciones de forma gradual a un entorno independiente. Además, se pueden crear nuevas soluciones íntegramente en SchallOS. Para los directores generales y los responsables técnicos, resulta especialmente interesante que el desarrollo, la explotación, la documentación, las actualizaciones y las distintas formas de implementación se organicen dentro de una plataforma común.
3. ¿SchallOS es principalmente un sustituto de FileMaker?
   FileMaker es un punto de partida importante, pero no constituye la base técnica permanente de SchallOS. Se adoptan ideas que han demostrado su eficacia, como el desarrollo visual y la estrecha integración entre datos, diseños y funciones. Sin embargo, el entorno de ejecución, el almacenamiento de datos, la lógica funcional y la infraestructura de actualizaciones se desarrollan de forma independiente. SchallOS puede migrar soluciones FileMaker existentes, pero también es adecuado para nuevas aplicaciones. Tras una migración completa, FileMaker ya no será necesario para el funcionamiento en producción.
4. ¿Se puede migrar de forma totalmente automática mi solución FileMaker actual?
   Las tablas, los campos, las relaciones, los diseños y otras estructuras definidas pueden importarse de forma prácticamente automatizada. Sin embargo, en el caso de una lógica de negocio compleja, es necesario realizar una comprobación adicional. Los scripts FileMaker suelen contener cambios de diseño, variables globales, complementos o casos especiales que se han ido acumulando a lo largo del tiempo. La IA puede analizar estos procesos y crear a partir de ellos nuevos contenedores de funciones. No obstante, una solución de gran envergadura debería ser revisada por un desarrollador y, en caso necesario, corregida. La migración reduce considerablemente el trabajo manual, pero no sustituye al conocimiento técnico de la aplicación.
5. ¿Qué ocurre con los scripts FileMaker existentes tras la migración?
   Los scripts pueden conservarse en segundo plano en los nuevos contenedores de funciones como capa de aprendizaje y referencia. Sin embargo, no se ejecutan sin modificaciones. La IA analiza qué tarea específica realiza un script, qué campos utiliza y qué condiciones comprueba. A continuación, programa el nuevo código ejecutable adaptándolo a la arquitectura de SchallOS. El script original se conserva como fuente de conocimiento histórico y puede seguir teniéndose en cuenta en caso de dudas o ampliaciones posteriores.
6. ¿Qué son SSC y SSD, y por qué una solución necesita dos contenedores?
   El SSC contiene la estructura de la aplicación, incluyendo tablas, campos, diseños, fórmulas, contenedores de funciones, idiomas y documentación. El SSD contiene los datos productivos, como clientes, artículos, pedidos o facturas. Ambos contenedores van de la mano, pero tienen funciones diferentes. Esta separación permite crear nuevas versiones de la estructura para 1TP12 sin tener que sustituir todo el conjunto de datos. Además, se pueden modificar el almacenamiento de datos, las copias de seguridad y los modelos operativos sin tener que volver a desarrollar la aplicación por completo.
7. ¿Qué ventajas ofrece la separación entre estructura y datos?
   De este modo, las actualizaciones, las copias de seguridad y las migraciones pueden llevarse a cabo de forma mucho más controlada. Se puede publicar un nuevo SSC mientras se mantiene el SSD con los datos de los clientes. Los cambios estructurales necesarios se llevan a cabo mediante migraciones de datos definidas. Además, el SSC puede analizarse o transferirse a otro desarrollador sin que se vean afectados los datos confidenciales de la empresa. También se facilita el cambio de IndexedDB a SQLite, PostgreSQL o a la nube, ya que no es necesario reconstruir los diseños ni la lógica funcional.
8. ¿Se puede utilizar la misma solución de forma local, en un servidor y en la nube?
   En principio, sí. Una solución SchallOS puede ejecutarse localmente en el navegador, como aplicación de Windows o macOS, con SQLite, en un servidor PostgreSQL o como SaaS en SchallOS Cloud. La aplicación funcional sigue siendo la misma. Sin embargo, los distintos modos de funcionamiento tienen sus propios requisitos en cuanto al uso multiusuario, las copias de seguridad, el rendimiento y la administración. Por ello, el cambio se lleva a cabo de forma controlada mediante la transferencia y la verificación de datos. La arquitectura SSC/SSD evita que sea necesario gestionar un proyecto completamente nuevo para cada objetivo.
9. ¿Seguiré necesitando FileMaker o FileMaker Server tras una migración satisfactoria?
   No. Tras una migración completa, la aplicación se ejecuta mediante SchallOS Runtime. Tampoco se necesita ni el servidor FileMaker ni WebDirect para el funcionamiento en el navegador. El antiguo sistema FileMaker puede conservarse como referencia o archivo, pero no es un requisito previo para el funcionamiento en producción. SchallOS se encarga de los diseños, las fórmulas, las funciones, el acceso a los datos, las actualizaciones y la implementación. De este modo, también desaparecen las dependencias de tiempo de ejecución de FileMaker que existían hasta ahora para la aplicación migrada.
10. ¿Cómo se integra la inteligencia artificial en SchallOS?
    La IA está disponible directamente en el editor de fórmulas, en las funciones personalizadas, en los contenedores de funciones y en la capa de documentación. No solo conoce la pregunta actual, sino también los campos, las tablas, las descripciones y las dependencias en cuestión. En el caso de las soluciones migradas, el script FileMaker original puede servir además como conocimiento de fondo. La IA puede explicar fórmulas, generar código, analizar errores y redactar documentación. En principio, los modelos deben seguir siendo intercambiables, de modo que se puedan tener en cuenta la calidad, los costes y la protección de datos.
11. ¿Programa realmente la IA el código de los contenedores de funciones?
    Sí. El desarrollador describe la tarea, los parámetros, el resultado esperado y las capacidades permitidas. Partiendo de esta base, la IA genera el código ejecutable. Este sigue siendo visible, verificable y se puede versionar. El desarrollador puede solicitar modificaciones, realizar pruebas y comparar o restaurar versiones anteriores. De este modo, la IA asume gran parte del trabajo de programación, pero no la responsabilidad técnica. Precisamente en los procesos críticos para el negocio, es necesario seguir controlando cuidadosamente los requisitos, los derechos y los posibles efectos secundarios.
12. ¿Qué posibilidades ofrece el editor de fórmulas?
    El editor de fórmulas admite cálculos matemáticos, lógicos y relacionados con el texto, así como cálculos de fecha y hora. Las fórmulas y las funciones personalizadas se evalúan en tiempo real y pueden probarse de inmediato. El conjunto inicial de comandos es más reducido que el conjunto de funciones de FileMaker, que ha ido creciendo a lo largo de los años. No obstante, el entorno de fórmulas es ampliable. Las funciones que falten pueden añadirse o sustituirse por funciones personalizadas propias. En este sentido, la IA integrada también puede transferir fórmulas existentes de FileMaker o desarrollar nuevos cálculos.
13. ¿Qué datos registra automáticamente SchallOS?
    A nivel estructural, se registran los cambios en tablas, campos, diseños, fórmulas y contenedores de funciones. A nivel de datos, se pueden registrar los cambios en los registros, los cambios de estado, las validaciones, las importaciones y otros eventos funcionales. A ello se suman eventos operativos como implementaciones, actualizaciones y copias de seguridad. Los trabajos de desarrollo relacionados pueden agruparse en «sesiones de cambio» y asignarse posteriormente a una versión. De este modo, se crea un historial trazable de la aplicación, en lugar de una mera recopilación de notas redactadas a posteriori.
14. ¿Puede SchallOS generar a partir de ello informes de clientes y de rendimiento?
    Sí. La IA integrada puede generar documentación técnica, informes para clientes, notas de lanzamiento o certificados de rendimiento a partir de los eventos registrados. De este modo, es posible resumir varias modificaciones técnicas en una descripción clara de los beneficios empresariales. Los eventos subyacentes siguen estando disponibles, de modo que el desarrollador puede revisar la redacción. No todos los cambios son automáticamente facturables. Por lo tanto, la selección, la evaluación y la aprobación del informe de prestaciones definitivo siguen siendo responsabilidad del desarrollador.
15. ¿Cómo funciona el proceso de actualización?
    Los cambios se recopilan inicialmente en «Change Sessions» y se agrupan en una versión. Una versión puede incluir un nuevo SSC, las migraciones SSD necesarias, los requisitos previos, las firmas, las comprobaciones y la información de reversión. SchallOS Control comprueba la instancia de destino, crea una copia de seguridad y, a continuación, ejecuta la actualización. Tras la instalación, se comprueba si la estructura, los datos y las funciones importantes se ajustan al estado esperado. Este mismo proceso básico se utiliza tanto para el propio SchallOS como para las soluciones de clientes desarrolladas con él.
16. ¿En qué se diferencian Runtime, Control y Cloud?
    SchallOS Runtime ejecuta las aplicaciones publicadas y proporciona diseños, fórmulas y contenedores de funciones. SchallOS Control gestiona instancias, adaptadores de bases de datos, perfiles de tiempo de ejecución, actualizaciones y comprobaciones técnicas. SchallOS Cloud ofrece el tiempo de ejecución y el almacenamiento de datos como un servicio SaaS gestionado de forma centralizada. SchallOS Studio sigue siendo el entorno de desarrollo propiamente dicho. Todas las áreas utilizan las mismas estructuras básicas SSC y SSD, pero asumen tareas claramente diferenciadas entre sí dentro del ciclo de vida de una aplicación.
17. ¿Cómo se protegen los derechos, las instalaciones y los datos sensibles?
    Los derechos de usuario determinan qué acciones específicas puede realizar una persona dentro de la solución. Los perfiles de tiempo de ejecución y de capacidades establecen, además, de qué funciones técnicas dispone realmente una instalación. Los paquetes SSC y SSD pueden protegerse con identificadores, sumas de comprobación y firmas. También es posible limitar el contexto de la IA, de modo que no se procesen automáticamente todos los datos de los clientes. Para entornos especialmente sensibles, se pueden utilizar servidores propios o, en el futuro, también modelos de IA locales. La configuración concreta de seguridad depende de cada caso concreto.
18. ¿Cuándo estará disponible SchallOS?
    El lanzamiento público está previsto para el otoño de 2026. En un primer momento, la atención se centrará en Studio y Runtime, la separación entre SSC y SSD, la migración de las estructuras FileMaker existentes, las fórmulas, las funciones personalizadas, los contenedores de funciones programados con IA, la documentación, los registros de eventos, la implementación y las actualizaciones. SchallOS Control también desempeñará un papel fundamental en la gestión de las instalaciones. No es necesario que todas las funciones previstas a largo plazo estén completamente desarrolladas en el momento del lanzamiento. Lo decisivo, en un primer momento, es contar con un núcleo robusto para las primeras aplicaciones productivas.

Artículos de actualidad sobre arte y cultura

Dieter Bohlen en lenguaje llano: Por qué Alemania fracasa por culpa de su propia burocracia

Dieter Bohlen en lenguaje llano: Por qué Alemania fracasa por culpa de su propia burocracia

Johann Sebastian Bach: orden, actitud y fundamento de nuestra música

Johann Sebastian Bach: orden, actitud y fundamento de nuestra música

Los tártaros de Crimea: historia, origen y presente de un pueblo olvidado

Los tártaros de Crimea: historia, origen y presente de un pueblo olvidado

Cancelar La cultura en Occidente: deporte, universidades, ejército y sanciones de la UE analizadas

Cancelar La cultura en Occidente: deporte, universidades, ejército y sanciones de la UE analizadas