Salut,

En effet, j'ai rajouté la variable d'environnement un peu de partout sur les différents services docker ainsi que dans mon environnement debian et j'ai pu accéder avec kong_admin à l'interface et je peux inviter de nouveaux admins. Merci !

ça a l'air de marcher, est-ce que tu as une idée sur l'impact des performances avec cette solution ? Il peut arriver qu'il y ait environ 170 000 insertions à faire dans ce flux.

On est en train d'essayer en utilisant des variables d'environnement système pour le nom d'utilisateur et le mot de passe. Nous avons encore des problèmes en production (localhost:1972 n'a pas l'air de fonctionner)

Bonjour @Guillaume Rongier 

J'ai continué à chercher dans le code et voici la cause actuelle des messages de warning ET de la tâche bloquée :

create_engine(f'iris+emb:///{namespace}')

J'ai remplacé par :

create_engine(f"iris://_SYSTEM:SYS@localhost:1972/{namespace}")

Et ça marche parfaitement.

Cela reste cependant un gros problème pour l'utilisation en production car cette ligne ne marchera pas. 

Bonjour @Lorenzo Scalese 
 

Merci pour ta réponse, en effet le TCOMMIT n'est pas à 0 cependant comme écrit dans le warning, le commit s'effectue automatiquement. En réalité j'ai un problème plus conséquent sur mon flux mais pensant que cela venait de là, je n'en avais pas parlé.

Lorsque mon flux passe une seule fois, ces warnings apparaissent et mon flux devient bloqué car il y a une tâche qui n'arrive pas à se terminer sans l'aide d'une commande pour la kill.

Voilà les détails de cette tâche qui vient visiblement du CSP Gateway :

Ce n'est plus le même sujet mais si tu as une idée je suis preneur.

Cordialement,

Cyril

Bonjour @Sylvain Guilbaud 

J'importais du code SQLAlchemy que j'avais moi-même créé, le code source est un peu long mais la partie importante est visible sur ce post: https://fr.community.intersystems.com/post/acc%C3%A9der-%C3%A0-une-reco…

Après une recherche avec toute l'équipe intéropérabilité, nous avons fait cette commande et nous avons même essayé d'installer toutes les libraries contenues dans notre requirement pip avec irispip (en utilisant les même arguments que la commande ci-dessus). Cependant nous avons toujours l'erreur. SQLAlchemy n'étant pas utilisé dans le fichier PostFusionIntervention (import inutile), nous l'avons enlevé mais nous avons toujours le problème sur Windows. Je pense qu'il s'agit à nouveau d'un problème administrateur sur la machine.

Bonjour @Lorenzo Scalese ,

Le problème de ces credentials, c'est qu'on ne peut les utiliser qu'avec un Adapter, cependant, les adapters que je connais ne sont pas présents sur un Business Process.

Je pensais utiliser ces credentials pour le stocker mais je souhaite pouvoir y accéder depuis le code directement.

Salut,

%Service.Callin était activé cependant comme pour faire fonctionner le terminal IRIS, il fallait cocher la case Système d'exploitation, et en effet ça marche mieux maintenant.

Merci !

J'ai demandé à Jean-Charles qui a des droits d'accès en administrateur à la machine, il a défini manuellement les variables d'environnement et la commande marche.

Quid par contre pour la commande iop, ce n'est pas dérangeant mais il faudra qu'on y pense dans l'exécution des commandes.

PS E:\InterSystems> python -m grongier.pex._cli
Traceback (most recent call last):
  File "C:\Program Files\Python39\lib\runpy.py", line 188, in _run_module_as_main
    mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
  File "C:\Program Files\Python39\lib\runpy.py", line 111, in _get_module_details
    __import__(pkg_name)
  File "C:\Users\Cyril.Grosjean\AppData\Roaming\Python\Python39\site-packages\grongier\pex\__init__.py", line 1, in <module>
    from grongier.pex._business_service import _BusinessService
  File "C:\Users\Cyril.Grosjean\AppData\Roaming\Python\Python39\site-packages\grongier\pex\_business_service.py", line 2, in <module>
    from grongier.pex._business_host import _BusinessHost
  File "C:\Users\Cyril.Grosjean\AppData\Roaming\Python\Python39\site-packages\grongier\pex\_business_host.py", line 9, in <module>
    import iris
  File "C:\Users\Cyril.Grosjean\AppData\Roaming\Python\Python39\site-packages\iris\__init__.py", line 10, in <module>
    raise Exception("""Cannot find InterSystems IRIS installation directory
Exception: Cannot find InterSystems IRIS installation directory
    Please set IRISINSTALLDIR environment variable to the InterSystems IRIS installation directory

Faut-il définir la variable d'environnement sur Windows ? Sur Linux je n'ai pas besoin.

Ah mais dans le cas où on a plusieurs namespaces et qu'on veut déployer des productions sur des différents namespaces ça ne sera pas possible du coup ?

Nous avons une production par namespace actuellement, pour un total de 17 productions (et namespaces), devoir tout mettre sur le même namespace même si c'est faisable, ça ne sera pas toléré par mon entreprise malheureusement.

Alors j'ai trouvé, il m'a mis dans le namespace USER, cependant, je voudrais qu'il soit dans le namespace TEST comment faire ? Je pense qu'il a prit le namespace par défaut.

En faisant la commande iris session IRIS sur mon terminal, j'accède au namespace USER par défaut.

En faisant un point en vocal, nous en avons conclu que l'utilisation du SNMP n'est pas judicieux. Il est préférable d'utiliser l'API du monitor (représentée par la route /api/monitor/metrics si l'API est activée sur IRIS).

Il est possible d'activer le monitoring des productions sur cette API.

Merci, j'ai pas encore eu le temps d'essayer à nouveau pour le service snmpd, nous utilisons PRTG dans notre entreprise mais comme les messages en général d'InterSystems ne prennent pas en compte l'UTF-8, nous étions en train également de tester via une API pour savoir ce que l'on récupère mais aussi pour rendre plus lisible les informations.
Le statut des productions par exemple c'est: Arrêté mais depuis le SNMP, InterSystems renvoie: "ArrÃ@tÃ@"

Bonjour,

Merci de votre réponse, je vais essayer de faire en sorte que le fichier de config snmpd soit similaire à celui que vous avez envoyé pour voir si cela corrige le problème, car actuellement lorsque je regarde le statut du service après l'avoir normalement lancé, il est toujours considéré comme inactif.

Je reviens vers vous. Merci !

En poursuivant les tests, j'ai ouvert en UDP les ports 161 et 162 sur le docker d'InterSystems. Cependant j'ai toujours ce problème de timeout.

J'ai remarqué que j'avais cependant une erreur au bout d'environ 2 minutes après avoir activé le service monitor comme expliqué dans le post. Voici l'erreur :

J'en déduis qu'il n'arrive pas à ouvrir en TCP le port 705, cependant ce port est précisé et est bien ouvert dans mon docker compose. Je suis donc bloqué.

J'ai suivi ces informations sur la documentation d'InterSystems : https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cl…

Mais il est impossible pour moi de démarrer le service snmpd.

Parfait ! Je suis connecté sans avoir à rentrer un username et un password au terminal, j'ai donc essayé de lancer la pipeline avec la commande runw pour avoir le script comme avant et tout fonctionne, la compilation s'est bien passée !

Merci beaucoup !

Un simple saut à la ligne a réglé mon souci, le script marche mais je suis confronté à un autre souci:

Le script n'est pas exécuté dans le job automatique sur Gitlab. Il y a un scp avant qui copie les fichiers contenus dans gitlab vers le serveur, puis la connexion ssh sur le screen.

J'ai bien vérifié sur le serveur si les fichiers étaient compilés, mais ils ne le sont pas. J'ai mis des pauses dans le script pour être sûr qu'il ne s'agit pas d'un problème de temps mais ce n'est pas le cas.

Je viens d'essayer, ça fonctionne cependant j'ai un petit soucis :

Mon fichier inputs.txt contient ceci:

Write"HI!"halt

A savoir donc 2 lignes vides et les instructions.

Je n'ai pas enlevé l'accès en non authentifié pour la console afin de ne pas avoir à rentrer d'identifiants dans un fichier brut car cela ne sera pas toléré par l'entreprise.

Cependant, j'ai un problème sur l'output qui a l'air de faire n'importe quoi :

Dans mon script compile.bat je n'ai rien de plus que la ligne irissession IRIS -U TEST < inputs.txt. Cela me force donc à forcer l'arrêt pour éviter que ma console crash (et de la redémarrer car le prompt crash, ça ressemble fortement à un core dump)

Faut-il que ce script soit aussi encodé LF et non CRLF ? Est-ce qu'il manque une instruction pour éviter ce problème ? 

Malheureusement avec les modifications apportées, je suis toujours contraint à devoir entrer un nom d'utilisateur et un mot de passe (ne pas tenir compte de la saisie, ce ne sont pas les bons identifiants utilisés)

EDIT: Je viens de remarquer qu'en faisant 2 fois entrée sans mettre un user et un password, j'étais bien dans le terminal iris, mais j'ai toujours cette demande d'input que je dois bypass sur la CI/CD sur une connexion ssh sur un serveur windows

Bonjour @Lorenzo Scalese 

Merci pour cette approche.

L'utilisateur est déjà activé, cependant, aucune permission ne lui est accordé, quelle permission doit-on lui donner pour qu'il puisse exécuter une routine depuis un terminal IRIS ?

Cordialement