新しい投稿

検索

質問
· 2024年5月15日

End of File handling in Cache and IRIS

#InterSystems IRIS for Health

In Cache End of file throws error but in IRIS no indication of End of file. I have to do an explicit $ZOF. How are you handling/detecting End of File in IRIS?

In cache this line will throw End of file error -  F PREC=1:1 U FILE R REC  D SOMETHING

But in IRIS this goes to forever, has anyone noticed this behaviour in IRIS?

2 Comments
ディスカッション (2)2
続けるにはログインするか新規登録を行ってください
質問
· 2024年5月15日

Modification d'un objet dynamique provenant d'un JSON

#重要な質問 #InterSystems IRIS

Bonjour, 

Je souhaite réaliser une méthode générique pour modifier des propriétés d'une classe dynamique. Lorsque je fais un JSONImport() cela fonctionne très bien pour certains objet, or dans le cas d'un objet contenant une liste cela m'ajoute un élément en plus au lieu de la modifier. J'ai essayée de vérifier le type lors de l'itération du JSON afin de faire un Insert mais je n'arrive pas à utiliser les $METHOD sur le Insert ou même le %Set. 

Voici la classe : 

Class Epc.conf.poste Extends (%Persistent, %JSON.Adaptor)
{

Property NomPoste As %String(%JSONFIELDNAME = "NomPoste", MAXLEN = "");
Property tPrinter As list Of EpErp.conf.printer(%JSONFIELDNAME = "tPrinter", SQLPROJECTION = "table/column", STORAGEDEFAULT = "array");
}
Class EpErp.conf.printer Extends (%SerialObject, %JSON.Adaptor)
{

Property Service As %String(%JSONFIELDNAME = "NomService", MAXLEN = "");
Property Print As %String(%JSONFIELDNAME = "NomImprimante", MAXLEN = "");
}

Mes données actuelles : 

Le fichier que j'envoie afin de modifier ma liste, je souhaite donc modifier un des éléments de ma list  : 

{
	"NomPoste":"Poste",
	"tPrinter":
	[
		{
			"NomService":"Petite",
			"NomImprimante":"EPFR_12"
		},
		{
			"NomService":"Grande",
			"NomImprimante":"Modif"
		}
	]
}

Ma méthode de modification générique : 

ClassMethod update(){
    
set payload={}.%FromJSON(%request.Content)

 set itr           = payload.%GetIterator()  

 if ##class(%Dictionary.ClassDefinition).%ExistsId(className){
  set class = $CLASSMETHOD(className,"%OpenId",id)
   if $ISOBJECT(class){
       if payload '= ""{
          while itr.%GetNext(.prop,.val) {
              if prop.%IsA("%DynamicArray"){
                    ?                 
                }else{
                    Set $PROPERTY(class, prop) = val
                }
               
                  do class.%Save()
                 }
             }
        }
     }
}

Merci par avance pour votre aide. 

2 Comments
ディスカッション (2)2
続けるにはログインするか新規登録を行ってください
記事
· 2024年5月15日 3m read
Open Exchange

Demostración simple de LowCode que transforma mensajes HL7 SIU a Kafka y luego consume mensajes Kafka para almacenarlos en IRIS a través de SQL

#HL7 #相互運用性 #JDBC #SQL #InterSystems IRIS for Health

Gitter

Configuración de producción

Esta demostración tiene una producción de interoperabilidad con 16 elementos.

Configuración de producción HL7 + Kafka Producer

La primera parte de esta demostración consiste en enviar un archivo HL7 SIU que será transmitido a los otros 2 flujos HL7 (HTTP y TCP), y transformado y transmitido al servidor Kafka. Los flujos HTTP y TCP transformarán los mensajes HL7 del mismo modo antes de enviarlos también a Kafka.

  • 3 Servicios HL7
  • 1 Enrutador HL7
  • 2 Operaciones HL7
  • 1 Operación de Negocio que envía los mensajes transformados a Kafka

Reglas de negocio

La producción tiene un proceso de negocio con un enrutador HL7, que transforma y envía mensajes HL7 a Kafka.

Transformación de datos

Data Transformation Builder permite la edición de la definición de una transformación entre fuentes SIU HL7v2 en mensajes Kafka. Transformación de datos 

 

Visual Trace

Después de que se haya procesado un mensaje HL7, es decir, al copiar algunos mensajes de /data/HL7/test al directorio /data/HL7/in), podréis ver su seguimiento visual.

  

Podéis ver aquí el mensaje con I/O y el HL7 ACK

Kafka Manager

Luego, podéis verificar los mensajes en Kafka, usando la interfaz KafkaManager y obteniendo datos de los diferentes temas. 

 

Y el contenido de un tema:

Configuración de Producción Kafka Consumer + SQL IRIS

 

La segunda parte de esta demostración consiste en consumir mensajes Kafka y enrutarlos a tablas IRIS a través de componentes SQL.

  • 3 Servicios de Kafka que consumen 3 temas de Kafka
  • 1 Enrutador
  • 3 Operaciones SQL insertando datos en la base de datos IRIS

Reglas de negocio

La producción tiene un proceso de negocio con un enrutador Kafka, que envía mensajes Kafka a los componentes IRIS SQL. 

Visual Trace

Cada vez que se consume un tema de Kafka, se envía al proceso de enrutador de Kafka, que realiza el enrutamiento basado en contenido de los mensajes de Kafka, a las tablas SQL apropiadas en IRIS. Si observáis atentamente los mensajes, podréis notar que el mensaje se envía directamente a IRIS sin ser transformado (mismo ID de mensaje).

  

 

Podéis ver aquí el mensaje con I/O y el resultado de la inserción SQL.

SQL

Luego podréis ver los resultados dentro de la base de datos IRIS a través de consultas SQL.

  • TrakCare table

* Surg table

* Y gracias a la herencia, también podéis consultar todos los datos simplemente consultando la tabla raíz, aquí data.kafka

ClassExplorer

 

El Explorador de clases o ClassExplorer os permite ver el modelo de datos de las clases IRIS.

Ajustes predeterminados

Para simplificar el proceso de copiar una definición de producción de un entorno a otro y garantizar una separación perfecta entre los parámetros de los diferentes entornos, se recomienda establecer configuraciones fuera de la clase de producción, en la configuración predeterminada del sistema. 

Entonces veréis los ajustes en azul en la configuración de producción.

Pre requisitos

 

Aseguraos de tener git y Docker Desktop instalados.

Instalación: ZPM

Abrid el Espacio de nombres IRIS con la Interoperabilidad habilitada. Abrid Terminal y llamad: USER>zpm "install hl7v2-to-kafka"

Instalación: Docker

1. Clone/git extrae el repositorio a cualquier directorio local

$ git clone https://github.com/SylvainGuilbaud/hl7v2-to-kafka.git

2. Abrid la terminal en este directorio y ejecutad:

$ docker-compose build

3. Ejecutad el contenedor IRIS con vuestro proyecto:

$ docker-compose up -d

Cómo ejecutar la muestra

  1. copiad algunos mensajes HL7 de /data/HL7/test a /data/HL7/in
  2. comprobad en Visual Trace
  3. ved un seguimiento completo (full trace)
  4. Id a Kafka Manager y obtened datos de los diferentes temas.
ディスカッション (0)1
続けるにはログインするか新規登録を行ってください
質問
· 2024年5月15日

Embeded python : Can I create a dict from COS?

#Embedded Python #JSON #Python #Caché #InterSystems IRIS

Hi, I need to use some pythonic library from cos.
To use them I need a python dict with some python object in it
Ex in python:

obj = pythonObject("value1")
dict = {object : obj  ,key : "value2"}
result = pythonFunc(dict)

To do that I first tried to pass by dynamic object, to later convert them in dict from Json. But unfortunately the dynamic object doesn't accept python object inside it. And my pythonic function need to have an instance of my python object.
So I tried with the python built-in function dict() to create a python dictionary, but I'm not sure how to use it as in the python documentation I need to do dict(key1 = value1, key2 = value2).
Is it possible to create dict in COS using embeded python or if there is another way?

2 Comments
ディスカッション (2)1
続けるにはログインするか新規登録を行ってください
記事
· 2024年5月15日 4m read

IKO - Lecciones aprendidas (Parte 1 - Helm)

#デプロイ #Kubernetes #InterSystems IRIS #InterSystems IRIS for Health

La documentación de IKO es robusta. Una única página web, que consta de unas 50 páginas reales de documentación. Para los principiantes eso puede ser un poco abrumador. Como dice el refrán: ¿cómo se come un elefante? Mordisco a mordisco. Empecemos con el primer bocado: Helm.

¿Qué es Helm?

Helm es a Kubernetes lo que el InterSystems Package Manager (IPM, antes ObjectScript Package Manager - ZPM) es a IRIS.

Facilita la instalación de aplicaciones en la plataforma, de una forma adecuada para Kubernetes. Es decir, está desarrollado de tal manera que facilita la instalación según sus necesidades, ya sea un entorno de desarrollo, prueba o producción.

Proporcionamos en nuestra distribución de software WRC todo lo que necesitaréis en la pestaña IRIS Components - consiste en un .tar.gz. Extraedlo y obtendréis un .tar. Extraedlo de nuevo y veréis una carpeta iris_operator_<versión>. Aquí hay un README con instrucciones, así como 3 carpetas - una imagen del IKO (también podríais haberla obtenido del InterSystems Container Registry), un chart y ejemplos. Los ejemplos son sólo para ayudaros a crear vuestros archivos, pero en realidad no es necesario para la instalación IKO. El chart, sin embargo, es necesario. Echemos un vistazo.

chart
|
|-> iris-operator
               |
               | -> README.md
               | -> .helmignore
               | -> Chart.yaml
               | -> values.yaml
               | -> templates 
                      | -> _helpers.tpl
                      | -> apiregistration.yaml
                      | -> appcatalog-user-roles.yaml
                      | -> cleaner.yaml
                      | -> cluster-role.yaml
                      | -> cluster-role-binding.yaml
                      | -> deployment.yaml
                      | -> mutating-webhook.yaml
                      | -> NOTES.txt
                      | -> service.yaml
                      | -> service-account.yaml
                      | -> user-roles.yaml
                      | -> validating-webhook.yaml

Esta es la carne y las patatas (una forma divertida de decir ingredientes básicos) de la aplicación que vamos a instalar. No os preocupéis. Lo único que nos importa es el values.yaml. Todo lo demás sucede entre bastidores, gracias a Helm. ¡Uf! Pero es importante saber que aunque nuestro operador pueda parecer un pod ordinario, es mucho más que eso.

La mayoría de los contenidos del values.yaml también van a estar fuera del alcance de este artículo porque no tendréis que preocuparos por ellos. Sólo nos preocuparemos de 4 campos (vale, 5 como mucho).

Son operator.registry, operator.repository, operator.tag, imagePullSecrets.name[0] e imagePullPolicy.

¿Dónde está vuestra imagen IKO? ¿Vuestra organización utiliza un repositorio privado? ¿Estáis planeando extraerla del ICR? Especificad los detalles de vuestra imagen en los campos de registro, repositorio y etiqueta. Si estáis utilizando el ICR podéis dejarlo como está.

¿Cómo accederéis al ICR o al repositorio de su organización? Suponiendo que sea privado, tendréis que especificar los datos con los que podréis acceder a él para tirar de él. En el próximo artículo hablaré de cómo crear este secreto, que podemos llamar intersystems-pull-secret en lugar del dockerhub-secret estándar que es lo que hay actualmente si habéis descargado los archivos del WRC.

Finalmente para el imagePullPolicy podemos dejarlo como Always, o alternativamente cambiarlo a IfNotPresent o Never. Os remito a la documentación de Kubernetes si necesitáis aclaraciones - aquí. Yo suelo usar IfNotPresent.

¡Parece que estamos listos para ir (suponiendo que ya tenéis Helm instalado, si no instaladlo primero)! Vamos a instalar el IKO. Vamos a tener que decirle a helm donde está la carpeta con todas nuestras cosas (esa es la carpeta iris-operator que veis arriba). Si estuviéramos en el directorio chart podéis usar el comando

helm install intersystems iris-operator

pero quizá estáis trabajando en algún nivel superior. No hay problema. Supongamos que estáis en un repositorio con iris_operator_amd-3.6.7.100:

helm install intersystems iris_operator_amd-3.6.7.100/chart/iris-operator

Recibiréis un mensaje que os indicará que la instalación se ha realizado correctamente y podréis comprobar que la instalación se está ejecutando tal y como se indica en el mensaje y en nuestra documentación.

kubectl --namespace=default get deployments -l "release=intersystems, app=iris-operator"

En el próximo post pondremos en práctica InterSystems Kubernetes Operator.

ディスカッション (0)1
続けるにはログインするか新規登録を行ってください