Impossible d'appeler des méthodes de classes en embeded python dans certains namespaces
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
Comments
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()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
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
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 ?
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()
OkET
SUPPLY_CHAIN>do##class(SUPPLYCHAIN.maclasse).testPython()
<OBJECT DISPATCH> *python object not foundAprè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()
OkAlors 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
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 sudoRUN 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 directoryWORKDIR /opt/irisapp
RUN chown ${ISC_PACKAGE_MGRUSER}:${ISC_PACKAGE_IRISGROUP} /opt/irisapp
USER ${ISC_PACKAGE_MGRUSER}
# Copy source files to imageCOPY . /opt/irisapp
# load demo stuffRUN 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 fileszw$SYSTEM.OBJ.ImportDir("/opt/irisapp/src/test", "*.cls", "cubk", .tErrors, 1)
// exit scripthiris.script.supply :
zn"SUPPLY_CHAIN"// Load ObjectScript source fileszw$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 sudoRUN 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 directoryWORKDIR /opt/irisapp
RUN chown ${ISC_PACKAGE_MGRUSER}:${ISC_PACKAGE_IRISGROUP} /opt/irisapp
USER ${ISC_PACKAGE_MGRUSER}
# Copy source files to imageCOPY . /opt/irisapp
# load class testRUN 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.