Bonjour @Julia Pertin 

pour tester un objet dynamique vide tu peux utiliser la méthode d'instance %Size() qui renverra 0

IRISAPP>set monobjet={}

IRISAPP>write monobjet.%Size()
0
IRISAPP>zw monobjet
monobjet={}  ; <DYNAMIC OBJECT>

IRISAPP>set monobjet.data="une valeur"

IRISAPP>write monobjet.%Size()
1
IRISAPP>zw monobjet
monobjet={"data":"une valeur"}  ; <DYNAMIC OBJECT>

Bonjour Cécile,

L'erreur "BP completion cleanup error deleting BP instance" dans InterSystems IRIS survient généralement lors de la suppression d'une instance de Business Process (BP) après son exécution.
Si le BP est configuré avec PoolSize=0, l'action de suppression des instances peut échouer car le système ne peut pas contrôler tous les threads simultanés.

As-tu plus d'informations dans l'Event Log :  Interoperability > Event Log  ?

Dans InterSystems IRIS, le choix entre un seul namespace ou plusieurs dépend des besoins en isolation, sécurité, gestion du code et performances.

Si tous les flux sont homogènes d'un point de vue métier, il n'est pas nécessaire de recourir à plusieurs namespaces (plusieurs client utilisent en production des centaines ou des milliers de flux dans un seul namespace).

L'utilisation de plusieurs namespaces offre cependant plusieurs avantages, notamment liés à la sécurité et à l'isolation des processus et données, dès l'instant où vous avez des flux répondant à des besoins métiers hétérogènes ou à des utilisations spécifiques.

Avantages d'utiliser plusieurs namespaces

1. Isolation des environnements Chaque namespace peut être dédié à un usage spécifique (développement, test, production). Cela réduit les risques de conflits entre configurations.
2. Sécurité renforcée Les mappings contrôlent précisément l'accès aux données et au code. Un namespace peut restreindre l'accès à certaines bases de données via des règles de mapping global/routine.
3. Gestion modulaire
   • Configuration indépendante pour chaque flux d'intégration (interopérabilité)
   • Mise à jour/redéploiement partiel sans impacter l'ensemble du système

Inconvénients de multiples namespaces

1. Complexité accrue de l’administration Plus il y a de namespaces, plus la gestion des mappings, des bases de données associées, des configurations de sécurité, des accès utilisateurs et des stratégies de sauvegarde devient complexe. Chaque namespace nécessite une configuration propre (databases, mappings, sécurité), ce qui multiplie les tâches d’administration et augmente le risque d’erreurs humaines lors des modifications ou migrations.
2. Gestion des sauvegardes et restaurations La multiplication des namespaces entraîne une augmentation du nombre de fichiers IRIS.DAT à sauvegarder et restaurer. Cela peut rallonger les temps de sauvegarde/restauration et compliquer la gestion des versions et des points de reprise, car il faut garantir la cohérence entre plusieurs bases de données et namespaces.
3. Verrouillage et contention Les locks sur les globals sont globaux à la base de données : si plusieurs namespaces accèdent à la même base de données via des mappings, ils peuvent se retrouver en concurrence sur les mêmes verrous, ce qui peut générer des contentions inattendues et compliquer le diagnostic des problèmes.
4. Mise à jour et déploiement Mettre à jour du code ou des configurations dans plusieurs namespaces nécessite de répéter les opérations, ce qui augmente le risque d’incohérences entre environnements et la charge de travail pour les équipes DevOps.
5. Surcoût de maintenance Chaque namespace ajoute des tâches de maintenance (monitoring, logs, gestion des utilisateurs, etc.). À grande échelle, cela peut devenir difficile à suivre et à automatiser sans outils adaptés
6. Difficulté de suivre une trace complète dans Visual Trace : un inconvénient majeur de l’utilisation de plusieurs namespaces, lorsque les flux métier sont liés. Visual Trace ne permet de visualiser que les messages et les transactions d’un seul namespace à la fois. Si un flux métier traverse plusieurs productions réparties sur différents namespaces, il n’est pas possible de visualiser le parcours global du message ou de la transaction dans une seule vue Visual Trace. L’opérateur ou le développeur doit ouvrir séparément chaque namespace dans le Management Portal, puis rechercher manuellement les messages correspondants (souvent avec des identifiants différents ou des métadonnées partielles), ce qui rend le diagnostic et l’analyse chronologique beaucoup plus complexes. Il n’existe pas de corrélation automatique des traces entre namespaces : chaque Visual Trace est limité à l’espace de noms courant, sans suivi transversal natif. Dès lors que des flux d’intégration sont distribués sur plusieurs namespaces, la traçabilité globale via Visual Trace devient morcelée, ce qui complique considérablement le support, la maintenance et l’investigation des incidents métier.

Isolation des processus 

L’isolation des processus dans chaque espace de noms (namespace) InterSystems IRIS est un sujet important pour la sécurité, la stabilité et la gestion de vos applications. Voici une explication détaillée :

1. Qu’est-ce qu’un namespace dans IRIS ?

Un namespace est un environnement logique qui regroupe :

• Une ou plusieurs bases de données (globals, routines)
• Des mappings de code et de données
• Des configurations spécifiques (services, productions, etc.)

2. Isolation des processus : ce qui est isolé

a. Espace d’adressage des données

• Chaque namespace a ses propres mappings de bases de données.
• Les globals et routines sont isolés par défaut : un processus dans le namespace A n’accède pas aux données du namespace B (sauf si mapping explicite).

b. Contexte d’exécution

• Les processus lancés dans un namespace (par exemple, un job d’intégration, une session terminal, un service REST) s’exécutent dans le contexte de ce namespace.
• Les variables système, le $namespace courant, et les paramètres de session sont propres à chaque processus et à chaque namespace.

c. Productions d’interopérabilité

• Les productions (Ensemble/IRIS Interoperability) sont isolées par namespace : chaque namespace a sa propre production, ses propres Business Services, Processes et Operations.
• Les queues, logs, et messages sont séparés.

d. Sécurité

• Les droits d’accès (Rôle, Ressource) peuvent être définis par namespace.
• Les utilisateurs peuvent être limités à certains namespaces via la configuration des applications web/services.

3. Ce qui n’est PAS isolé

• Processus système : Les processus système (ex : le démon d’écriture, le garbage collector) sont globaux à l’instance IRIS.
• Caches partagés : Le cache de routines et de données est partagé entre tous les namespaces.
• Mémoire partagée (gmheap) : Les structures internes sont communes.
• Journalisation (Write Image Journal, Journaux d’audit) : Certains fichiers de journalisation sont globaux.

4. Exemple pratique

• Si vous lancez un job dans le namespace A, il ne voit que les données et le code de A (sauf mapping).
• Si un processus dans le namespace B plante, il n’impacte pas directement les jobs du namespace A.
• Les productions d’interopérabilité ne partagent pas leurs queues ou messages.

5. Limites de l’isolation

• Processus : Tous les processus sont visibles dans la vue système (^%SS, Management Portal), quel que soit leur namespace d’origine.
• Ressources système : Les processus de tous les namespaces consomment la même mémoire, CPU et I/O disque.

6. Résumé

L’isolation des processus dans chaque namespace est forte sur le plan applicatif (données, code, productions), mais partielle sur le plan système (ressources partagées). Pour une isolation maximale, il faut combiner la séparation par namespace avec des politiques de sécurité et, si nécessaire, des instances IRIS séparées.

En conclusion, une architecture multi-namespaces est préférable pour des flux hétérogènes nécessitant une isolation forte, malgré une complexité opérationnelle accrue. Pour des flux homogènes, un namespace unique avec scaling vertical (CPU/mémoire) peut suffire.

@Corentin Blondeau, c'est la nature des 20 flux qui doit être considérée pour décider du nombre de namespaces.

Si les 20 flux sont tous liés entre eux d'un point de vue métier, un seul namespace est recommandé. 
Si parmi ces 20 flux, une vraie séparation métier existe, il est recommandé de les séparer dans plusieurs namespaces, même si certains d'entre eux ne reçoivent qu'un flux, la séparation offrira plus de souplesse dans l'administration et la gestion opérationnelle. 

L'impact sur la consommation mémoire est marginal ; seuls les processus Ens.Actor, Ens.Alarm, Ens.Alert, Ens.MonitorService, Ens.ProductionMonitorService, Ens.ScheduleHandler seront  dupliqués pour chaque nouveau namespace. 

Chaque instance IRIS pouvant supporter jusqu'à 2048 namespaces, il ne faut pas s'en priver dès l'instant où le bénéfice de l'isolation est au rendez-vous 😉