Nueva publicación

検索

Artículo
· 2 mayo, 2025 Lectura de 3 min

Mini-astuce du jour : Préchargement de la licence dans l'image Docker IRIS

Qui n'a jamais développé un bel exemple avec une image IRIS Docker et vu la génération de l'image échouer dans le Dockerfile parce que la licence sous laquelle l'image a été créée ne comportait pas certains privilèges ?

Dans mon cas, je déployais dans Docker une petite application utilisant le type de données Vector. Avec la version Community, ce n'est pas un problème, car elle inclut déjà la recherche et le stockage vectoriels. Cependant, lorsque j'ai remplacé l'image IRIS par une image IRIS classique (latest-cd), j'ai constaté que la compilation de l'image, y compris des classes générées, renvoyait l'erreur suivante :

9.505 ERROR #15806: Vector Search not permitted with current license
9.505   > ERROR #5030: An error occurred while compiling class 'Inquisidor.Object.LicitacionOS'
9.505 Compiling class Inquisidor.Object.Licitacion
9.505 ERROR #15806: Vector Search not permitted with current license
9.505   > ERROR #5030: An error occurred while compiling class 'Inquisidor.Object.Licitacion'
9.538 Compiling class Inquisidor.Message.LicitacionResponse

Cette erreur m'a laissé perplexe, car moi, en tant que personne obéissante, j'avais défini dans mon docker-compose.yml le paramètre qui indique où se trouve ma licence valide :

  iris:
    init: true
    container_name: iris
    build:
      context: .
      dockerfile: iris/Dockerfile
    ports:
      - 52774:52773
      - 51774:1972
    volumes:
    - ./iris/shared:/iris-shared
    environment:
    - ISC_DATA_DIRECTORY=/iris-shared/durable
    command: --check-caps false --ISCAgent false --key /iris-shared/iris.key

Il m'a fallu un certain temps pour comprendre que le problème venait de l'image originale que j'utilisais, et non de la licence. Comme vous pouvez le constater, je ne suis pas très doué en la matière.

Le problème est survenu au moment où j'ai importé mes classes dans l'image IRIS par défaut :

RUN \
zn "%SYS" \
do ##class(SYS.Container).QuiesceForBundling() \
do ##class(Security.Users).UnExpireUserPasswords("*") \
set sc=##class(%SYSTEM.OBJ).Load("/opt/irisapp/DemoSetup.Utilities.cls","ck") \
set helper=##class(DemoSetup.Utilities).%New() \ 
do helper.EnableSSLSuperServer() \
do ##class(Security.Applications).Import("/ApplicationInquisidor.xml",.n) \
zn "INQUISIDOR" \
set sc = $SYSTEM.OBJ.LoadDir("/opt/irisapp/src/Inquisidor", "ck", , 1) \
set production = "Inquisidor.Production" \
set ^Ens.Configuration("csp","LastProduction") = production \
do ##class(Ens.Director).SetAutoStart(production) \

La compilation du code renvoyait l'erreur précédente. Que faire pour la corriger ? C'était très simple : j'ai dû envoyer la nouvelle licence à l'image IRIS initiale et lui demander de la mettre à jour dès la première ligne des commandes que j'utilisais.

La première étape consiste à déplacer la nouvelle licence vers le répertoire /mgr de l'installation, ce que j'ai fait avec ce code :

COPY --chown=$ISC_PACKAGE_MGRUSER:$ISC_PACKAGE_IRISGROUP /iris/iris.key /usr/irissys/mgr
RUN chmod +x /usr/irissys/mgr/iris.key

Le chemin d'installation d'IRIS sur notre image est /usr/irissys/mgr, et le chemin /iris/iris.key correspond à mon répertoire local. Avec la licence dans l'image IRIS, il me suffisait de demander à IRIS de la mettre à jour. J'ai donc modifié les commandes précédentes en ajoutant l'instruction suivante :

RUN \
zn "%SYS" \
do ##class(%SYSTEM.License).Upgrade() \

Et voilà ! J'ai maintenant mon image IRIS avec ma licence chargée avant l'importation et la compilation de mes classes. Plus d'erreurs de compilation.

J'espère que cela vous sera utile !

Comentarios (0)1
Inicie sesión o regístrese para continuar
Pregunta
· 2 mayo, 2025

SQLCODE: -99 when executing dynamic SQL on specific properties

Hi, I am unsure how to remove this restriction; when I am performing dynamic SQL using ##class(%SQL.Statement).%ExecDirectNoPriv(, .query, args...)

It works fine, but the moment I add specific properties from the persistent class I am performing the select on into the WHERE clause, I get: ERROR #5540: SQLCODE: -99 Message: User UnknownUser is not privileged for the operation. Despite using %ExecDirectNoPriv, I've tried with prepared statement as well, exact same situation.

I have read that it is possible to set privileges on individual properties on a persistent class, but I have no clue where to remove or change these privileges; the only solution I found is to add the role %All to UnknownUser, but that is not a fix but despite attempting to add full privileges for the persistent class for UnknownUser, I keep getting this privilege error.

5 comentarios
Comentarios (5)3
Inicie sesión o regístrese para continuar
Pregunta
· 2 mayo, 2025

IRIS Multiple Instance on a single Linux VM - status

I have a Linux server that has multiple instances installed on it (according to my documentation).

What is the best command to show:

- what instance are installed?

- what instances are running?

I did run 'iris list' but it shows only one instance.

3 comentarios
Comentarios (3)1
Inicie sesión o regístrese para continuar
Pregunta
· 2 mayo, 2025

is this possible to call routines(.mac) directly in java?

Hello, we are currently using the Cache Database released in January 2018.

There are no specific classes or SQL mappings in the namespaces where data is stored.

Only a few routines(.mac) and stored data are in the global area.

In this case, when accessing the Cache DB through Java, is it essential to write SQL mappings or wrapper classes? The reason I ask is that our team doesn't have advanced developers who specialize in Cache.

Alternatively, is it possible to directly call pre-existing routines from Java?

I apologize for the translation;

2 comentarios
Comentarios (2)3
Inicie sesión o regístrese para continuar
Pregunta
· 1 mayo, 2025

What does S $ZT="^%ETSDK" mean in MUMPS / InterSystems ObjectScript?

Hi all,

I'm reviewing an older Cache routine and came across this line of code: from file ^ZDBKCRON

S $ZT="^%ETSDK"

Error trap

/home/oper/script/cache_db_backup -t        # Daily CacheDB Backup

 produced the following output:

 <NOROUTINE> *%ETSDK
<ERRTRAP>

-----------

From what I understand, this is setting up an error trap, but I'm not entirely clear on how it works, especially in modern InterSystems IRIS environments.

Could someone please help explain:

  1. What exactly does this line do?
  2. Is %ETSDK a standard system routine? I can't find it in our environment.
  3. What is the best practice for error trapping now — should we be using $ETRAP instead of $ZT?
  4. How can I safely replace or modernize this code?

Any guidance is appreciated!

2 comentarios
Comentarios (2)2
Inicie sesión o regístrese para continuar