Intégration de l’IA
Indexation vectorielle native et requêtes vectorielles plus rapides
La version 4D 21 R5 introduit l’indexation vectorielle native pour les champs « 4D.Vector », offrant pour la première fois dans 4D une indexation dédiée aux données représentées sous forme de vecteurs.
Cela améliore les performances des recherches par similarité à mesure que les ensembles de données s’étoffent, ce qui s’avère particulièrement utile pour la recherche sémantique, les systèmes de recommandation, le RAG et d’autres workflows pilotés par l’IA. Les requêtes sur les champs vectoriels indexés renvoient les mêmes résultats que les requêtes non indexées, mais plus rapidement.
Vous pouvez configurer les index cosinus, dot et euclidien directement dans l’éditeur de structure, tandis que l’index automatique existant reste disponible pour les vecteurs nuls. Chaque index peut être activé indépendamment, ce qui vous permet de ne conserver que ceux que votre application utilise réellement.
Les champs vectoriels indexés peuvent également être utilisés avec des opérations de tri, ce qui permet de classer les résultats des requêtes en fonction de la similarité des vecteurs tout en tirant parti du nouvel index.
Les index vectoriels sont intégrés au cycle de vie standard de la base de données, notamment la réindexation, la sauvegarde, la vérification MSC et la réparation.
Pour les applications qui stockent déjà des représentations vectorielles dans des champs de type 4D.Vector, cela vous offre un moyen direct d’accélérer la recherche vectorielle sans modifier la manière dont vos données sont modélisées ni les résultats renvoyés par vos requêtes.
Gestion programmatique des index vectoriels
4D 21 R5 ajoute également la gestion programmatique de l’indexation vectorielle, ce qui vous permet de créer, d’inspecter et de gérer des index vectoriels directement depuis le code, sans avoir à recourir uniquement à l’éditeur de structure.
Les commandes CREATE INDEX et SET INDEX prennent en charge les index cosinus, scalaires et euclidiens, tandis que ` DataClass.getIndexes() ` vous permet de vérifier les index disponibles sur une classe de données lors de l’exécution. Cela s’avère particulièrement utile lors de la validation de déploiements ou de la création d’outils de diagnostic, car vous pouvez ainsi vous assurer que les index attendus sont bien présents sans avoir à ouvrir manuellement la structure de la base de données.
Le stockage vectoriel est également plus flexible. 4D.Vector.new() utilise désormais une précision de 32 bits par défaut, ce qui contribue à réduire les besoins en stockage, tandis que la précision de 64 bits reste disponible lorsque votre cas d’utilisation l’exige.
Ensemble, ces changements facilitent l’utilisation de la recherche vectorielle au-delà de la phase de développement : vous pouvez configurer les index visuellement lors de la conception de la base de données, puis les valider et les gérer par programmation une fois l’application déployée.
Invalidation automatique des embeddings dans 4D Embedding Studio
4D Embedding Studio facilite la synchronisation des embeddings avec les données métier. Lorsque les données sources changent, 4D peut désormais identifier les vecteurs qui ne représentent plus l’entité actuelle, au lieu de laisser en place des embeddings obsolètes.
Si un attribut utilisé pour construire une phrase d’encodage est modifié, le vecteur associé est automatiquement invalidé. Lorsque vous utilisez un champ booléen « dirty » correspondant, 4D peut marquer le vecteur pour qu’il soit régénéré tout en conservant la valeur actuelle disponible. Sinon, le vecteur est effacé.
La même protection s’applique lorsque la configuration de l’encodage change. La mise à jour de la phrase peut déclencher un workflow de recalcul plus large, tandis que la modification du modèle d’encodage empêche la réutilisation des vecteurs créés avec le modèle précédent.
Cela élimine une grande partie du suivi manuel et réduit le risque que les fonctionnalités de recherche sémantique, de RAG ou de recommandation fonctionnent avec des embeddings obsolètes à mesure que vos données et votre configuration IA évoluent.
Sécurité
Signature S/MIME pour SMTP Transporter
Les e-mails sortants peuvent désormais être signés numériquement avec S/MIME directement via SMTP Transporter, ce qui permet aux destinataires de vérifier à la fois l’identité de l’expéditeur et de s’assurer que le contenu n’a pas été modifié après la signature.
Cette fonctionnalité est particulièrement utile pour les factures, les validations, les rapports, les notifications et autres communications professionnelles où l’authenticité est essentielle.
La signature s’intègre au flux de travail SMTP existant. Vous fournissez un certificat contenant la clé privée, soit directement sous forme de fichier ou de Blob via certificate, soit en référence à partir du magasin de certificats du système avec certificateName. Les certificats protégés par mot de passe sont également pris en charge.
La signature s’effectuant au sein de l’API SMTP Transporter standard, vous pouvez renforcer la sécurité des flux de travail de messagerie fiables sans avoir à introduire un outil de signature distinct ni une couche d’intégration personnalisée.
OpenSSL 4 pour NGTCP2 et QUIC
La pile réseau utilisée par les fonctionnalités liées à QUIC, WebSocket et TLS s’appuie désormais sur OpenSSL 4 au lieu de BoringSSL, ce qui modernise les fondements de la sécurité tout en conservant en grande partie le comportement des applications existantes.
Pour la plupart des applications, la mise à niveau est transparente. Le principal point à vérifier concerne votre configuration TLS : SET DATABASE PARAMETER ne prend désormais en charge que les versions TLS 1.2 et TLS 1.3 comme versions TLS minimales, et la version par défaut du serveur est TLS 1.3.
Ce changement concerne également les opérations basées sur OpenSSL, telles que le chiffrement, la génération de certificats, la génération de clés, le fournisseur OpenSSL et le pilote ODBC.
Aucune étape d’activation ou de migration n’est requise, mais les applications qui dépendent encore d’anciennes versions de TLS doivent vérifier leur configuration avant le déploiement.
SERVEUR HTTP
Limitation de débit intégrée pour le serveur Web 4D
4D Web Server peut désormais limiter les charges de travail excessives avant qu’elles n’affectent le reste de l’application, ce qui vous offre un meilleur contrôle sur la répartition des ressources du serveur.
Vous pouvez définir des limites pour le volume de requêtes, les données entrantes et sortantes, les sessions actives, les sessions invitées et les ensembles d’entités. Ces limites peuvent s’appliquer à l’ensemble du serveur ou à des sessions individuelles, ce qui permet d’éviter qu’un client ou une charge de travail ne consomme une part disproportionnée de la capacité.
Lorsqu’une limite est atteinte, la requête est rejetée prématurément avec le code HTTP 429 « Too Many Requests », avant même qu’un processus Web ne soit créé. Les clients peuvent également recevoir une valeur « Retry-After » le cas échéant, ce qui leur indique clairement quand réessayer.
Les quotas peuvent être configurés au démarrage, chargés à partir du fichier HTTPQuotas.json ou mis à jour en cours d’exécution via WEB Server().quotas. Par défaut, rien ne change ; les applications existantes conservent donc leur comportement actuel jusqu’à ce que les quotas soient explicitement configurés.
Cette fonctionnalité ne remplace pas un proxy inverse, un pare-feu ou un WAF. Elle ajoute au contraire une protection adaptée aux applications au sein même de 4D, aidant ainsi les applications de production à rester plus réactives lors de pics de trafic ou d’utilisations inappropriées.
BASE DE DONNÉES
Modernisation de Windows Installer et déploiement compatible CI
L’installation de 4D sous Windows est désormais plus simple pour les utilisateurs individuels et beaucoup plus facile à automatiser pour les équipes gérant des environnements de build ou de déploiement.
Toutes les langues prises en charge sont installées par défaut, ce qui évite d’avoir à choisir des packs linguistiques lors de l’installation et prévient les problèmes liés à l’absence de certaines langues par la suite.
Le même programme d’installation prend en charge 4D, 4D Server, 4D Volume Desktop et 4D Components. Tous les éléments sont sélectionnés par défaut, tout en vous permettant d’installer uniquement ce dont vous avez besoin.
Pour l’intégration continue (CI) et le déploiement automatisé, le programme d’installation peut s’exécuter en mode silencieux depuis la ligne de commande grâce aux options d’Inno Setup. Cela facilite la préparation des agents de compilation, des machines de test ou des environnements de déploiement sans intervention manuelle.
Le programme d’installation est désormais exclusivement en version x64, ce qui simplifie la matrice de déploiement et s’aligne sur les environnements Windows pris en charge. Un lien vers le programme d’installation du Windows App SDK est également disponible à la fin de l’installation lorsque ce runtime est nécessaire.
Il en résulte un processus d’installation sous Windows plus prévisible, que vous configuriez un seul poste de travail ou que vous automatisiez des dizaines d’environnements.
Composant 4D
Compiler des composants directement à partir du projet hôte
Les composants peuvent désormais être compilés directement à partir du projet hôte, ce qui facilite grandement la synchronisation entre l’application et les versions des composants utilisées par une build.
La fenêtre Compilateur affiche le projet hôte ainsi que les composants compatibles, ce qui vous permet de compiler, de vérifier la syntaxe ou d’effacer le code compilé sans avoir à ouvrir chaque composant séparément. Vous pouvez également accéder directement au Compilateur depuis l’Explorateur pour un composant sélectionné.
Un composant est éligible lorsque son code source est disponible localement, qu’il n’est pas packagé au format .4dz ni issu du cache du Gestionnaire de dépendances, et qu’il utilise le typage direct.
Chaque composant utilise toujours ses propres paramètres de compilation, tandis que les journaux de compilation sont centralisés dans le projet hôte. Les erreurs et les avertissements identifient également le composant dont ils proviennent, ce qui accélère considérablement le dépannage dans les projets qui dépendent de plusieurs modules réutilisables.
Concrètement, cela se traduit par un processus de build plus fiable. Vous passez moins de temps à gérer séparément les composants compilés et réduisez le risque de livrer une application contenant une version obsolète d’un composant.
Découvrez plus rapidement les composants avec 4D Corner
La recherche de composants réutilisables fait désormais partie intégrante du workflow de gestion des dépendances. 4D Corner peut être ouvert directement depuis l’interface « Dépendances du projet » ou depuis la fenêtre « Ajouter une dépendance ».
De là, vous pouvez parcourir les composants partagés par 4D et la communauté, copier la dépendance dont vous avez besoin et l’intégrer à votre projet sans avoir à effectuer de recherche séparée dans les référentiels.
Cela facilite la découverte de solutions existantes avant de développer vous-même une fonctionnalité et clarifie considérablement le parcours entre la recherche d’un composant et son ajout effectif à une application.
Interface utilisateur
Prise en charge de Fluent UI pour les formulaires de liste
Les formulaires de liste peuvent désormais utiliser le même rendu « Fluent UI » que le reste de votre interface Windows, ce qui élimine l’une des incohérences les plus visibles dans les applications qui utilisaient déjà l’apparence moderne de WinUI.
Lorsque Fluent UI est activé, les formulaires de liste ouverts via des commandes telles que DISPLAY SELECTION et MODIFY SELECTION, ainsi que les sous-formulaires de liste, conservent leur mise en page et leur comportement existants tout en adoptant le rendu moderne.
Cela signifie également que les formulaires de liste suivent désormais le même thème Windows clair ou sombre que les formulaires de détail et les boîtes de dialogue. Les utilisateurs ne passent plus d’une interface moderne sombre à un formulaire de liste classique qui semble provenir d’une autre application.
Aucune refonte n’est nécessaire. Les formulaires de liste existants bénéficient automatiquement du nouveau rendu, tandis que la propriété « Widget Appearance » vous permet toujours de contrôler le comportement de chaque formulaire.
Pour les applications comportant un grand nombre de formulaires de liste existants, cela rend la transition complète vers l’interface Fluent UI bien plus pratique.
Stylisation plus flexible des boutons, boutons radio et cases à cocher
La personnalisation simple de l’interface ne nécessite plus de créer des ressources graphiques pour chaque bouton ou contrôle.
Les boutons, boutons radio et cases à cocher personnalisés peuvent désormais utiliser une couleur d’arrière-plan, une couleur de bordure, une largeur de bordure et un rayon de coin directement depuis l’éditeur de formulaires, via CSS ou du code 4D.
Pour les boutons, les nouvelles propriétés sont disponibles via le style de bordure personnalisé; les formulaires existants conservent ainsi leur apparence actuelle, sauf si vous choisissez d’utiliser le nouveau style. Les boutons radio et les cases à cocher exposent directement les mêmes propriétés visuelles.
Les images d’arrière-plan peuvent toujours être combinées avec une couleur d’arrière-plan, et les coins arrondis découpent automatiquement l’arrière-plan de manière correcte.
Cela vous offre davantage de liberté pour créer une identité visuelle cohérente sur les thèmes clairs et sombres, tout en réduisant le nombre d’éléments graphiques que vous devez créer, gérer et maintenir.
Les nouvelles options de mise en forme s’appliquent au mode projet et ne sont pas prises en charge dans les bases de données binaires.
Alignement vertical et espacement des objets texte
Le placement du texte dans les formulaires est désormais plus facile à contrôler sans avoir à redimensionner les objets ni à recourir à des solutions de contournement visuelles.
Les objets « Zone de texte » et « Champ de saisie » peuvent utiliser un alignement vertical en haut, au milieu, en bas ou par défaut, ainsi qu’un espacement latéral indépendant de chaque côté. Cela facilite grandement le maintien d’un équilibre visuel entre les libellés, les champs et les zones de saisie plus grandes.
Vous pouvez configurer ces valeurs depuis l’éditeur de formulaire, le JSON du formulaire, le CSS ou directement dans le code. Les nouvelles commandes « OBJECT SET PADDING » et « OBJECT GET PADDING » permettent un contrôle à l’exécution, tandis que les commandes d’alignement vertical existantes fonctionnent désormais également avec les objets « Text Area » et « Input ».
La prise en charge de l’espacement s’étend également aux listes box, avec un espacement symétrique horizontal et vertical.
Les formulaires existants conservent leur rendu actuel jusqu’à ce que vous commenciez à utiliser les nouvelles propriétés ; vous pouvez ainsi améliorer progressivement les mises en page sans avoir à repenser les écrans existants.
Extension Visual Studio Code
Flux de travail fluide entre l’IDE 4D et VS Code
Passer de l’IDE 4D à VS Code ne signifie plus qu’il faille parcourir les dossiers du projet pour trouver la bonne méthode ou la bonne classe.
Une nouvelle préférence de l’éditeur de code vous permet de choisir si c’est 4D ou VS Code qui doit ouvrir le code par défaut, tandis que la touche Alt vous donne un accès rapide à l’autre éditeur lorsque cela est nécessaire. Vous pouvez également conserver le comportement actuel et toujours utiliser l’éditeur de code 4D.
Cette préférence s’applique à l’ensemble de l’IDE 4D, y compris l’Explorateur, l’Éditeur de formulaires, le débogueur, les boîtes de dialogue d’erreurs d’exécution et les actions « Aller à la définition ». Lorsque VS Code est sélectionné, 4D ouvre le fichier de méthode ou de classe correspondant et fournit à VS Code le dossier du projet comme espace de travail.
Cela s’avère particulièrement utile pour les méthodes de formulaires et d’objets, où la recherche manuelle du fichier correspondant peut impliquer des numéros de table et des dossiers profondément imbriqués. 4D résout désormais ce chemin d’accès pour vous et crée la méthode au préalable si nécessaire.
Il en résulte un flux de travail mixte IDE beaucoup plus fluide. Vous pouvez continuer à utiliser l’IDE 4D pour les formulaires, le débogage et la navigation dans le projet, tout en basculant directement vers VS Code lorsque vous avez besoin des outils Git, des extensions ou du développement assisté par l’IA.
Cette intégration s’applique au mode projet. Les bases de données binaires continuent d’utiliser l’éditeur de code 4D.