Impossible d'appeler des méthodes de classes en embeded python dans certains namespaces

Question

Question

Cyril Grosjean · Oct 11, 2023

#Embedded Python #Interopérabilité #InterSystems IRIS for Health

Bonjour,

J'ai un soucis depuis quelques jours que je n'arrive pas à régler après pas mal de recherche sur le forum communautaire français et anglais, ainsi que la documentation InterSystems. J'ai deux namespaces : "TEST" et "SUPPLY_CHAIN" ainsi qu'une fonction en python identique compilée dans les deux namespaces :

ClassMethod testPython() As %Status [ Language = python ]

{

    print("Ok")

}

Lorsque j'appelle depuis le terminal iris cette fonction comme ceci:

do ##class(TEST.maclasse).testPython()

Cela me retourne bien "ok"

Cependant depuis le namespace SUPPLY_CHAIN, en faisant l'appel depuis le terminal IRIS, j'ai ceci:

<OBJECT DISPATCH> *python object not found

Est-ce un problème d'autorisation pour accéder à Python ? Python est-il bien installé sur le namespace SUPPLY_CHAIN ?

J'ai essayé d'ouvrir un shell python depuis le namespace SUPPLY_CHAIN avec la commande

do ##class(%SYS.Python).Shell()

et ça marche bien.

Merci pour votre aide,

Cordialement

Cyril

Version du produit: IRIS 2023.2

$ZV: IRIS for UNIX (Ubuntu Server LTS for x86-64 Containers) 2023.3 (Build 233U) Tue Sep 19 2023 15:25:13 EDT

Discussion (7)1

Connectez-vous ou inscrivez-vous pour continuer

Cyril Grosjean · Oct 11, 2023

Alors je viens de comprendre le problème, cependant je le trouve illogique. Je m'explique :

Les classes ont été crées avec de l'ObjectScript par défaut, puis cloné depuis gitlab et compilé sur un docker-compose, le fichier n'inclus pas python, cependant, lorsque je crée un nouveau fichier avec un nom de classe différent mais pourtant avec le même code ET une fonction en python, ça marche.

Je pense qu'il s'agit d'un bug

0 0

score 0 · Answer 1 · 2023-10-11T03:53:14-04:00

Bonjour,

Juste pour préciser, vous ne l'appelez pas comme

do ##class(SUPPLY_CHAIN.maclasse).testPython()

Vous changez le namespace et appelez comme avant

set $namespace = "SUPPLY_CHAIN"
do ##class(TEST.maclasse).testPython()

score 1 · Answer 2 · 2023-10-11T03:56:44-04:00

Bonjour,

Oui je change de namespace avant et le nom du package juste avant n'est plus TEST mais SUPPLYCHAIN :

do ##class(SUPPLYCHAIN.maclasse).testPython()

Sur le namespace TEST je l'appelle comme ceci :

do ##class(TEST.maclasse).testPython()

Evidemment, les deux fichiers existent et sont bien compilés

score 0 · Answer 3 · 2023-10-11T05:11:11-04:00

Irène Mykhailova · Oct 11, 2023

@Guillaume Rongier ?

0 0

score 0 · Answer 4 · 2023-10-11T07:47:36-04:00

Bonjour @Cyril Grosjean,

Je ne suis pas sur de comprendre le problème, il me manque peut-etre informations.

De ce que j'ai compris :

Vous avez deux namespaces :
- TEST
- SUPPLY_CHAIN
Vous avez une meme classe dans les deux namespaces :
- nom de la classe : TEST.maclasse
- Elle a la définition ci-dessous :

Class TEST.maclasse Extends %RegisteredObject
{
ClassMethod testPython() As %Status [ Language = python ]

{

    print("Ok")

}
}

Cette classe est compilée dans les deux namespaces par CI/CD à partir d'un fichier .cls dans git.

Le problème :

Lorsque vous appelez la méthode testPython() dans le namespace TEST, cela fonctionne.

TEST>do ##class(TEST.maclasse).testPython()
Ok

Lorsque vous appelez la méthode testPython() dans le namespace SUPPLY_CHAIN, cela ne fonctionne pas.

SUPPLY_CHAIN>do ##class(TEST.maclasse).testPython()
<OBJECT DISPATCH> *python object not found

Est-ce que j'ai bien compris ?

Si oui :

Je n'arrive pas à reproduire le problème.
Il y a peut etre un problème avec la CI/CD qui ne compile pas la classe dans le namespace SUPPLY_CHAIN.
Il y a peut un problème au niveau de la configuration du namespace SUPPLY_CHAIN.
Il me faut plus de détail

Si non :

Pouvez-vous me donner plus de détail sur le problème ?

score 0 · Answer 5 · 2023-10-11T10:37:58-04:00

Bonjour @Guillaume Rongier

Alors j'ai deux namespaces mais j'ai 2 fichiers distincts ayant la même fonction:

Class TEST.maclasse Extends %RegisteredObject
{
ClassMethod testPython() As %Status [ Language = python ]

{

    print("Ok")

}
}

ET

Class SUPPLYCHAIN.maclasse Extends %RegisteredObject
{
ClassMethod testPython() As %Status [ Language = python ]

{

    print("Ok")

}
}

Ces fichiers étaient créés avant de lancer le docker pour lancer iris. Ce docker compile automatiquement les fichiers dans les bons namespaces (SUPPLYCHAIN est le dossier pour le namespace SUPPLY_CHAIN et TEST est le dossier pour le namespace TEST).

Par la suite j'appelle via un terminal IRIS dans les bons namespaces, les méthodes:

TEST>do ##class(TEST.maclasse).testPython()
Ok

ET

SUPPLY_CHAIN>do ##class(SUPPLYCHAIN.maclasse).testPython()
<OBJECT DISPATCH> *python object not found

Après avoir posté ce matin ma question j'ai recherché de mon côté et il s'avère que lorsqu'on crée une nouvelle classe dans SUPPLY_CHAIN avec le même code et que je l'importe moi même, je retrouve ceci:

SUPPLY_CHAIN>do ##class(SUPPLYCHAIN.test.maclasse).testPython()
Ok

Alors en effet, le fichier du côté SUPPLY_CHAIN a une fonction OnProcessInput en ObjectScript mais en faisant vraiment un copier/coller du fichier, l'appel à la fonction python marche parfaitement, mais sur le fichier d'origine j'ai toujours un python object not found, c'est là où je pense que c'est un bug

En espérant vous avoir aidé à mieux comprendre,

Cordialement

score 0 · Answer 6 · 2023-10-12T03:18:27-04:00

est-il possible d'avoir un extrait de votre dockefile + des scripts de compilation ?

une possible solution peut etre de s'assurer que la compliation est lieu dans le même layer docker :

ARG IMAGE=intersystemsdc/irishealth-community:latest

FROM $IMAGE

USER root

# Update package and install sudo
RUN apt-get update && apt-get install -y \
	nano \
	python3-pip \
	python3-venv \
	sudo && \
	/bin/echo -e ${ISC_PACKAGE_MGRUSER}\\tALL=\(ALL\)\\tNOPASSWD: ALL >> /etc/sudoers && \
	sudo -u ${ISC_PACKAGE_MGRUSER} sudo echo enabled passwordless sudo-ing for ${ISC_PACKAGE_MGRUSER}

# create dev directory
WORKDIR /opt/irisapp
RUN chown ${ISC_PACKAGE_MGRUSER}:${ISC_PACKAGE_IRISGROUP} /opt/irisapp
USER ${ISC_PACKAGE_MGRUSER}

# Copy source files to image
COPY . /opt/irisapp

# load demo stuff
RUN iris start IRIS \
	&& iris session IRIS < /opt/irisapp/iris.script.test \
	&& iris session IRIS < /opt/irisapp/iris.script.supply \
	&& iris stop IRIS quietly

iris.script.test :

    zn "TEST"
    // Load ObjectScript source files
    zw $SYSTEM.OBJ.ImportDir("/opt/irisapp/src/test", "*.cls", "cubk", .tErrors, 1)
    // exit script
    h

iris.script.supply :

    zn "SUPPLY_CHAIN"
    // Load ObjectScript source files
    zw $SYSTEM.OBJ.ImportDir("/opt/irisapp/src/supply", "*.cls", "cubk", .tErrors, 1)

dans l'example ci-dessus dans le dockerfile, les derniers lignes sont exécutées sur le meme layer docker avec deux scripts differents pour des questions de maintenabilité.

Il est déconseillé de faire comme ci-dessous :

ARG IMAGE=intersystemsdc/irishealth-community:latest

USER root

# Update package and install sudo
RUN apt-get update && apt-get install -y \
	nano \
	python3-pip \
	python3-venv \
	sudo && \
	/bin/echo -e ${ISC_PACKAGE_MGRUSER}\\tALL=\(ALL\)\\tNOPASSWD: ALL >> /etc/sudoers && \
	sudo -u ${ISC_PACKAGE_MGRUSER} sudo echo enabled passwordless sudo-ing for ${ISC_PACKAGE_MGRUSER}

# create dev directory
WORKDIR /opt/irisapp
RUN chown ${ISC_PACKAGE_MGRUSER}:${ISC_PACKAGE_IRISGROUP} /opt/irisapp
USER ${ISC_PACKAGE_MGRUSER}

# Copy source files to image
COPY . /opt/irisapp

# load class test
RUN iris start IRIS \
	&& iris session IRIS < /opt/irisapp/iris.script.test \
	&& iris stop IRIS quietly

# load class supply	
RUN iris start IRIS \
	&& iris session IRIS < /opt/irisapp/iris.script.supply \
	&& iris stop IRIS quietly

car ici, vous demarrez deux fois iris dans deux layers differents, vous allez avoir une image plus volumineuse et peut etre des confics aux niveaux des droits dans les bases de données.