InterSystems Package Manager (IPM): una herramienta para implementar los paquetes y soluciones en InterSystems IRIS con dependencias.
Descargar el cliente de Package Manager.
¡Bienvenidos, estimados miembros de la Comunidad!
En este artículo vamos a presentar un ejemplo de un proyecto de implementación de una solución basada en FHIR. Este proyecto se basará en el proyecto nacional (nacional de España), conocido como ÚNICAS.
Usando sus propias palabras:
Hola!
Recientemente he estado probando a crear nuestro propio repositorio de paquetes con IPM. He podido crearlo sin problemas, y he visto que, al final, nuestro repositorio IPM no deja de ser una instancia de IRIS. En el ejemplo del que he partido, utiliza la versión community. Y mi pregunta es, para tener nuestro repositorio disponible para toda la compañía, ¿podemos seguir con la versión community, o debe ser una versión enterprise con licencia?
Y ya que estoy, ¿hay alguna forma de saber qué paquetes se han descargado, y por quién?
Muchas gracias!
¡Hola, compañeros desarrolladores en InterSystems IRIS!
A menudo me preguntan, especialmente en relación con los bonus técnicos que incentivamos en cada concurso de Open Exchange, por qué siempre damos bonus por Docker, IPM y por aprobar ObjectScript Quality.
En realidad, es muy fácil de responder.
Hemos lanzado IPM 0.9.0. Anteriormente hablé sobre algunos de los antecedentes y la lógica detrás de esto; para resumir, este es un lanzamiento importante por dos razones: representa una reunificación muy esperada entre nuestro trabajo interno y el impulsado por la comunidad en torno a la gestión de paquetes de ObjectScript centrada en IRIS, y porque tiene algunas incompatibilidades con versiones anteriores. Hay varias incompatibilidades necesarias en nuestro plan a futuro, y las hemos agrupado; esto no será algo habitual.
Monitoread los cambios incrementales en la base de datos mediante tareas programadas, mostrad las tendencias de cambio a través de gráficos, estableced umbrales de alarma y escribid la información en el archivo messages.log.
Docker o ZPM.Aseguraos de tener instalados git y Docker Desktop.
git clone https://github.com/Sara771dev/Database-Size-Monitoring.git
docker-compose build
docker-compose up -d
Abrid la terminal para ejecutar:
zpm "install databasesizemonitoring"
| Tipo | Descripción |
|---|---|
| AlarmSize | Alarma de tamaño de la base de datos |
| DayActualSize | Aumento diario del tamaño del volumen de alarma |
| IncrementalSize | Aumento total actual del tamaño del volumen de alarma |
Si el tamaño de la base de datos cambia por más del valor especificado, se escribirá información adicional en messages.log.
Al mismo tiempo, podéis contar las tendencias incrementales de la base de datos. Podéis visitar la siguiente página:
http://127.0.0.1:52773/csp/user/DataBases.Page.Chart.cls
tip: Si no podéis acceder a la página, es posible que tengáis que ajustar la aplicación web y cambiar el archivo del servidor de /csp/user a always y cache.
Con IRIS 2024+, los usuarios podéis alojar aplicaciones WSGI utilizando Security.Applications. Como ejemplo, un usuario puede hacer algo como esto
zn "%SYS"
Kill props
Set props("Description") = "Sample WSGI Application"
Set props("MatchRoles") = ":%All"
Set props("WSGIAppLocation") = "/path/to/flaskapp"
Set props("WSGIAppName") = "myapp"
Set props("WSGICallable") = "app"
Set props("DispatchClass") = "%SYS.Python.WSGI" // important, otherwise will be recognized as CSP application
Set sc = ##class(Security.Applications).Create("/flask", .props)
zw sc
donde el directorio /path/to/flaskapp contiene un archivo myapp.py que dice
from flask import Flask
app = Flask(__name__)
@app.route("/")
def index():
return "Hello, WSGI!"
Ahora, id a la URL http(s)://<host>:<port>/<optional-prefix>/flask/. Debería mostrar "¡Hello, WSGI!" en texto sin formato.
Si la URL http(s)://
Además, cuando se ejecuta por primera vez, flask necesita ser instalado para python embebido (no su intérprete python local a nivel de SO). Comprobad que la instalación se ha realizado correctamente accediendo al intérprete de python embebido y ejecutando import flask.
Finalmente, se debe conceder permiso de lectura, para /path/to/flaskapp/myapp.py y todas las carpetas superiores, al usuario del SO con que se esté ejecutando IRIS .
Si el error sigue sin resolverse, comprobad si hay entradas en messages.log. También podéis poneros en contacto con nosotros a través de posting an issue
IPM facilita el proceso:
requirements.txt.Aquí hay un ejemplo que puede instalarse fácilmente donde quiera que IPM (v0.6.3+) esté instalado en IRIS 2024+. Clonad este paquete a un <PACKAGE_ROOT> adecuado, e iniciad un terminal IRIS
zn "%SYS"
zpm "load <PACKAGE_ROOT>"
Tras la instalación, deberíais poder visitar http(s)://<host>:<port>/<optional-instance-prefix>/my/flask/demo/. En mi caso, la URL es http://localhost:8080/iris-ml-wsgi/my/flask/demo/ y se lee:
This is a sample WSGI application using Flask!
Sugerencia: necesitáis instalar zpm siguiendo las instrucciones aquí primero para que el comando zpm funcione.
El module.xml del repositorio anterior también está listado aquí para una referencia rápida
<?xml version="1.0" encoding="UTF-8"?>
<Export generator="Cache" version="25">
<Document name="flask-demo.ZPM">
<Module>
<Name>flask-demo</Name>
<Version>1.0.0</Version>
<Description>This is a demo of a flask application</Description>
<Keywords>flask</Keywords>
<Author>
<Person>Shuheng Liu</Person>
<Organization>InterSystems</Organization>
<CopyrightDate>2024</CopyrightDate>
<License>MIT</License>
<Notes>notes</Notes>
</Author>
<Packaging>module</Packaging>
<SystemRequirements Version=">=2024.1" />
<SourcesRoot>src</SourcesRoot>
<FileCopy Name="src/python/flaskapp/" Target="${libdir}flask-demo/flaskapp/"/>
<SystemSetting Name="CSP.DefaultFileCharset" Value="UTF-8"/>
<WSGIApplication
Url="/my/flask/demo"
UnauthenticatedEnabled="1"
Description="Sample WSGI application using Flask"
MatchRoles=":${dbrole}"
WSGIAppLocation="${libdir}flask-demo/flaskapp/"
WSGIAppName="app"
WSGICallable="app"
/>
<AfterInstallMessage>Module installed successfully!</AfterInstallMessage>
</Module>
</Document>
</Export>
¡Hola, amigos!
A menudo, cuando desarrollamos soluciones comerciales, existe la necesidad de desplegar soluciones sin código fuente, por ejemplo, para preservar la propiedad intelectual.
Una de las formas de conseguirlo es utilizar InterSystems Package Manager.
Aquí he pedido a Midjourney que pinte una propiedad intelectual de software:
¿Cómo se puede lograr esto con IPM?
De hecho, es muy sencillo; basta con añadir la cláusula Deploy="true" en el elemento Resource del manifiesto module.xml. Ver Documentación.
He decidido pasaros el ejemplo más simple posible para ilustrar cómo funciona y también para daros una plantilla de entorno de desarrollo que os permita empezar a construir y desplegar vuestros propios módulos sin código fuente. ¡Allá vamos!
Cada vez es más común ver coloridas insignias o badges en el archivo README.MD, con información útil sobre un proyecto en repositorios como GitHub, GitLab y otros.
Por ejemplo:
Incluso la iniciativa sobre calidad del código que está en marcha en la comunidad actualmente también ofrece su propia insignia. Esta insignia muestra el estado de validación de código del proyecto.
Para incluirla, debes añadir la siguiente línea en el README.MD:
[](https://community.objectscriptquality.com/dashboard?id=intersystems_iris_community%2Fappmsw-zpm-shields)
Y en el directorio del proyecto en GitHub /.github/workflows/, añadir el archivo objectscript-quality.yml. Tras eso, podrás ver esta insignia:
Existen diferentes servicios que otorgan estas insignias.
Un ejemplo es Shield.io
Simplifica la creación de enlaces, incluyendo Markdown
Aquí tenéis ejemplos de insignias excelentes que se han utilizado en algunos proyectos.
A medida que el proyecto del gestor de paquetes ZPM crece, los recursos necesarios para almacenar los módulos de los diferentes paquetes también crecen.
Cada vez es más frecuente que necesites información detallada de un paquete sin tener que abrir los archivos del proyecto, preferiblemente visible de forma sencilla en la primera página. Datos como:
Todo esa información se puede consultar con insignias a través del servicio shields.io.
Se puede complicar el enlace añadiendo la posibilidad de hacer click para abrir el archivo correspondiente module.xml:
[](https://raw.githubusercontent.com/sergeymi37/zapm/master/module.xml)
Ejemplo de un enlace con una solicitud de un servicio:
[](https://pm.community.intersystems.com/packages/zapm)
Por ejemplo, un link para abrir el fichero docker-compose.yml:
[](https://raw.githubusercontent.com/sergeymi37/zapm/master/docker-compose.yml)
Sin embargo, para métricas más complejas o sus combinaciones, e incluso para proyectos dentro de una red local privada, se ha decidido crear este servicio REST, que muestra la versión del módulo ZPM desde el archivo del repositorio y desde https://pm.community.intersystems.com/
Tras la instalación, se tiene un servicio zpm-shields al que hay que proporcionar acceso sin autenticación.
Por ejemplo:
donde los valores del parámetro son:
zpm-shields/repo - extracción desde el archivo module.xml para obtener la versión
module - enlace al repositorio
color - por ejemplo #00987
donde los valores del parámetro son:
zpm-shields/registry - obtener la versión por petición desde el servicio
project - nombre del proyecto
donde los valores del parámetro son:
zpm-shields/both - extracción desde el archivo module.xml, obtiene la versión desde el servicio
project - nombre del proyecto
module - enlace al repositorio
El servicio también se puede usar para recursos ZPM locales. Para hacerlo, hay que utilizar la ruta completa del repositorio local y un registro privado.
A mí me gustan mucho estas insignias. Y creo que también podrían seros útiles a vosotros.
¡Hola Comunidad!
Me gustaría compartir con vosotros un ejercicio que he hecho para crear "mi propio" chat con ChatGPT en Telegram.
Ha sido posible gracias a dos componentes de Open Exchange: Telegram Adapter, de @Nikolay Solovyev e IRIS Open-AI, de @Kurro Lopez 
Así que con este ejemplo podréis configurar vuestro propio chat con ChatGPT en Telegram.
¡Veamos cómo hacerlo funcionar!
ZPM está diseñado para funcionar con aplicaciones y módulos de InterSystems IRIS. Está formado por dos componentes: el Cliente ZPM, que es un CLI para gestionar módulos; y El Registro, que es una base de datos de módulos y meta-información. Podemos utilizar ZPM para buscar, instalar, actualizar, eliminar y publicar módulos. Con ZPM se pueden instalar clases de ObjectScript, aplicaciones Frontend, producciones de Interoperabilidad, soluciones de BI de IRIS, conjuntos de datos de IRIS o cualquier otro archivo, como paquetes wheel de Python Embebido.
En este artículo repasaremos tres secciones:
InterSystems anuncia que el componente central de InterSystems Supply Chain Orchestrator™, la versión 2023.1 de InterSystems IRIS for Supply Chain, está disponible de manera general (GA).
InterSystems Supply Chain Orchestrator está construido sobre InterSystems IRIS®, nuestra plataforma de datos más completa para entornos on-premise, en nube e híbridos, que posibilita una arquitectura de smart data fabric para hacer más fácil la creación e implementación de aplicaciones de alto rendimiento, que hacen uso de técnicas de machine learning y que permiten conectar silos de aplicaciones y datos. Combina la potencia de InterSystems IRIS con aceleradores y frameworksespecíficos de la cadena de suministro, para ofrecer soluciones optimizadas para la orquestación de la cadena de suministro, percepción de demanda y previsión, compleción de ordenes y reempaquetado de productos que han de moverse rápidamente.
¡Hola Comunidad!
Me gustaría presentaros una nueva utilidad para importar CSV a IRIS - ¡csvgenpy!
Instalación
USER>zpm "install csvgenpy"
Uso:
do ##class(shvarov.csvgenpy.csv).Generate("file or url","table","schema")Ejemplo:
USER>do ##class(shvarov.csvgenpy.csv).Generate("https://raw.githubusercontent.com/datasciencedojo/datasets/master/titanic.csv","titanic","data")Esto creará la tabla y la clase data.titanic en IRIS y a continuación cargará los datos. Podéis probarlo con:
¡Hola Comunidad!
Recientemente tuve que configurar un servidor FHIR local usando IRIS for Health y creo que encontré la forma más sencilla y simple de hacerlo.
Simplemente ejecuta estas dos líneas en el terminal:
docker run --rm --name my-iris -d --publish 9091:1972 --publish 9092:52773 intersystemsdc/irishealth-communityy
docker exec -it my-iris iris session iris -U "USER" '##class(%ZPM.PackageManager).Shell("install fhir-server")'Y tendrás un servidor FHIR ejecutándose localmente en http://localhost:9092/fhir/r4.
¡Y eso es todo!
El servidor FHIR usará la última versión de InterSystems IRIS for Health Community Edition y desplegará el servidor FHIR desde esta app a través del paquete IPM en el namespace FHIRSERVER.
Si estás desarrollando soluciones en IRIS y quieres utilizar Git, ¡es genial! Sólo tienes que utilizar VSCode con un repositorio git local y enviar los cambios al servidor, así de fácil.
Pero qué sucede si:
En ese caso no era tan sencillo... hasta finales del año pasado, cuando lanzamos Git para Entornos de Desarrollo Compartidos (Open Exchange / GitHub).
Puedes descargar esta extensión mediante InterSystems Package Manager:
zpm "install git-source-control"
Antes de esto, las opciones para controlar las fuentes con Git eran una antigua extensión de Git, principalmente para Windows, y sólo para entornos de desarrollo local y un proyecto más reciente de Open Exchange basado en él pero más sencillo. También está Port, que únicamente maneja archivos y es independiente del sistema de control de versiones.
¿Qué tiene git-source-control que no tienen estos paquetes?
Todo esto funciona desde VSCode:
Y Studio:
Para que tengas el control y la visión de tu repositorio de git:
.png)
.png)
Esperamos que esto permita desarrollar con éxito las soluciones basadas en IRIS.
¡Agradecemos vuestros comentarios!
NOTA: Para ver la presentación del lanzamiento en el Global Summit de 2021, consultad este artículo: https://community.intersystems.com/post/video-git-gitlab-shared-development-environments
¡Hola desarrolladores!
Supón que tienes una clase persistente con datos y quieres tener una interfaz de usuario Angular sencilla, para ver los datos y llevar a cabo operaciones CRUD.
En este artículo describíamos cómo desarrollar una interfaz de usuario Angular para InterSystems IRIS utilizando RESTForms2.
A continuación vamos a explicar cómo conseguir una interfaz de usuario Angular sencilla que permita realizar operaciones CRUD y ver automáticamente los datos de tu clase de InterSystems IRIS en menos de 5 minutos.
¡Vamos!
Necesitarás:
Utilizaré como ejemplo la clase Data.Countries que generé e importé a través de csvgen, utilizando este comando:
.png)
.png)
d ##class(community.csvgen).GenerateFromURL("https://raw.githubusercontent.com/datasciencedojo/datasets/master/WorldDBTables/CountryTable.csv",",","Data.Countries"
Para crear una interfaz de usuario Angular necesitamos exponer una API REST para esta clase, que dará servicio a las operaciones CRUD.
Vamos a utilizar el módulo restforms2 para esto.
Este comando en dockerfile instala restforms2 en el contenedor IRIS:
zpm "install restforms2" \
Para añadir una API REST, necesitamos hacer que nuestra clase de ejemplo herede de Form.Adaptor:
Class Data.Countries Extends (%Library.Persistent, Form.Adaptor)
Añade los parámetros restforms2 a la clase persistente para gestionar el comportamiento general: ordenación, visualización, etc:
// Form name, not a global key so it can be anything
Parameter FORMNAME = "Countries";
/// Default permissions
/// Objects of this form can be Created, Read, Updated and Deleted
/// Redefine this parameter to change permissions for everyone
/// Redefine checkPermission method (see Form.Security) for this class
/// to add custom security based on user/roles/etc.
Parameter OBJPERMISSIONS As %String = "CRUD";
/// Property used for basic information about the object
/// By default getObjectDisplayName method gets its value from it
Parameter DISPLAYPROPERTY As %String = "name";
Perfecto. A continuación, podemos utilizar la sintaxis de restforms2 para hacerle saber qué propiedades de la clase queremos exponer a la API CRUD. Puedes hacerlo añadiendo el atributo "DISPLAYNAME =" a las propiedades que quieras exponer en restforms2-ui. Por ejemplo:
Property code As %Library.String(MAXLEN = 250) [ SqlColumnNumber = 2 ];
Property name As %Library.String(DISPLAYNAME = "Name", MAXLEN = 250) [ SqlColumnNumber = 3 ];
Property continent As %Library.String(DISPLAYNAME = "Continent", MAXLEN = 250) [ SqlColumnNumber = 4 ];
Property region As %Library.String(DISPLAYNAME = "Region", MAXLEN = 250) [ SqlColumnNumber = 5 ];
Property surfacearea As %Library.Integer(DISPLAYNAME = "Surface Area", MAXVAL = 2147483647, MINVAL = -2147483648) [ SqlColumnNumber = 6, SqlFieldName = surface_area ];
Property independenceyear As %Library.Integer(DISPLAYNAME = "Independence Year", MAXVAL = 2147483647, MINVAL = -2147483648) [ SqlColumnNumber = 7, SqlFieldName = independence_year ];
¡Genial! Ahora vamos a introducir la capa de interfaz de usuario. Este comando en dockerfile instala restforms2-ui, que es la interfaz de usuario Angular para Restform2:
zpm "install restforms2-ui" \
¡Y ya está! Vamos a echarle un vistazo a la interfaz de usuario de nuestra clase de ejemplo, que puedes encontrar en la URL server:port/restforms2-ui:
RESTForms incluye las clases de prueba Person y Company, y se pueden utilizar para examinar las características de restfomsUI. Actualmente, puedes editar campos de cadenas de texto, numéricos, booleanos, de fecha y búsqueda.
Puedes probar todo esto en tu portátil, si clonas y construyes este repositorio:
docker-compose up -d --build
Y, a continuación, abres la URL:
localhost:port/restforms2-ui/index.html
o si usas VSCode, selecciona este elemento del menú:
¡Happy coding!
Me alegra anunciar un nuevo hito en el ciclo de vida de ObjectScript Package Manager (ZPM). El gestor de paquetes ha ofrecido a los desarrolladores la posibilidad de empaquetar de forma clara y sencilla el código de ObjectScript y la configuración de sus parámetros de despliegue, así como la información de la versión. Durante los últimos años ha evolucionado mucho, convirtiéndose en una parte fundamental de muchos workflows de desarrollo.
¡Hola desarrolladores!
Cuando desarrollas con ObjectScript Package Manager, un aspecto crucial es la versión del paquete, que situamos en el fichero module.xml. Cuando añadimos cambios al paquete y estamos listos para publicar una nueva versión del paquete en el registro, también necesitamos aumentar el número de versión. Esto está claro, pero es un poco molesto, y a menudo podemos olvidarnos de hacerlo.
Este breve artículo os ayudará a automatizar ese proceso.
¡Hola Comunidad!
@Joan Pérez publicó una reseña en la que comentó que no está muy claro qué aplicaciones están disponibles para InterSystems Package Manager. ¡Gracias por tu pregunta, Joan! De hecho, la respuesta merece una publicación.
Existen al menos dos formas de conocer las aplicaciones con ZPM:
1. Ejecutar el comando find en zpm:
Si tuvieras la oportunidad de cambiar algo en el Visualizador de Mensajes de Interoperabilidad en IRIS, ¿qué harías?
¡Hola desarrolladores!
En Docker Hub hay publicadas imágenes para los contenedores de InterSystems IRIS Community Edition e InterSystems IRIS Community for Health.
¿Qué es esto?
Hay un repositorio en que se publican estás imágenes (que, de hecho, son las mismas que las imágenes de IRIS Community Edition que tienes en el Registro de Contenedores de InterSystems a las que se les ha pre-cargado el cliente del ObjectScript Package Manager).
Así que si ejecutas este contenedor con IRIS CE o IRIS CE for Health puedes empezar a usar ZPM inmediatamente e instalar paquetes desde el Registro de la Comunidad o cualquier otro.
¿Que significa esto para ti?
Hola desarrolladores!
Este es otro artículo para simplificar la vida de los desarrolladores. Hablamos de hacer que GitHub ejecute tus pruebas unitarias (unittest) con cada push que hagas a tu repositorio simplemente añadiendo un fichero. Gratis :). En GitHub Cloud. Suena genial, ¿no?
Es factible, y además muy sencillo. El mérito es para @Dmitry Maslennikov (y su repo), el gestor de paquetes ZPM y las GitHub Actions. Vamos a ver cómo funciona todo en conjunto.
¡Hola Comunidad!
Este artículo muestra cómo crear Pacientes y Recursos de Observación de Pacientes mediante el uso de la aplicación iris-fhir-client.
Recomiendo leer mi primer artículo sobre esta aplicación y ver el vídeo de Youtube antes de continuar.
¡Empezamos!
¡Hola comunidad!
Esta publicación es una introducción a mi aplicación iris-fhir-client en Open Exchange.
Usando Python embebido y con la ayuda de la librería fhirpy, iris-fhir-client puede conectarse a cualquier servidor FHIR abierto.
Obten información de recursos por terminal y mediante el uso de la aplicación web CSP.
Con el lanzamiento de InterSystems IRIS 2021.2 Preview y la nueva funcionalidad LOAD DATA, los conjuntos de datos se pueden añadir con Objectscript Package Manager (ZPM)
Medical Datasets contiene los siguientes 12 conjuntos de datos. Para tablas de conjuntos de datos y detalles de datos, echa un vistazo a la Demo online, usando SuperUser | SYS
| ID | Dataset Name | Tables | Licence |
|---|---|---|---|
| 1 | Synthetic Medical Data | 11 | Public Domain |
| 2 | Health Care Analytics - 1 | 8 | Public Domain |
| 3 | Global Suicide Data | 7 | Public Domain |
| 4 | COVID-19 Polls1 | 7 | CC-BY |
| 5 | Cancer Rates by U.S. State | 2 | Public Domain |
| 6 | Opioid Overdose Deaths | 2 | Public Domain |
| 7 | Heart Disease Prediction | 1 | Public Domain |
| 8 | Yellowpages medical services dataset | 1 | Public Domain |
| 9 | Hospital ratings | 1 | Public Domain |
| 10 | Heart Failure Prediction | 1 | (CC BY 4.0) |
| 11 | Diabetes Dataset | 1 | Public Domain |
| 12 | Chronic Kidney Disease | 1 | Public Domain |
He desarrollado una aplicación para importar de forma dinámica 12 conjuntos de datos junto con 43 tablas usando el comando LOAD DATA, que carga los datos de una fuente a una tabla SQL de IRIS.
Lista de los conjuntos de datos
Se recomienda leer la documentación relacionada LOAD DATA (SQL).
Utiliza el siguiente comando para importar un conjunto de datos en particular al introducir su ID o utiliza 999 para importar todos los conjuntos de datos
do ##class(dc.data.medical.utility).ImportDS(1)
A continuación se muestra el script principal para crear la tabla de forma dinámica y cargar los datos mediante la función LOAD DATA. Ten en cuenta que la tabla se crea de forma dinámica
//Get file name
SET filename=tRS.Get("Name")
//Remove .csv from the file name
SET tableName=$REPLACE("dc_data_"_ds_"."_tRS.Get("ItemName"),".csv","")
//Get columns based on the header row of csv file
Do ##class(dc.data.medical.utility).GetColTypes(filename,.coltype)
//Dynamically create table based on tablename and column types
SET qry = "CREATE TABLE "_tableName_" ("_coltype_")"
SET rset = ##class(%SQL.Statement).%ExecDirect(,qry)
//Check if table created successfully
IF rset.%SQLCODE
{
WRITE "ERROR : ",rset.%Message,!
}
ELSE
{
//Dynamically construct LOAD DATA statement
SET qry = "LOAD DATA FROM FILE '"_filename_"' INTO "_tableName_ " "_"USING {""from"":{""file"":{""header"":""1""}}}"
SET rset = ##class(%SQL.Statement).%ExecDirect(,qry)
// Check result set sqlcode, In case of error write resultset message
IF rset.%SQLCODE
{
WRITE "ERROR Table : " _tableName_" IMPORT FAILED: ",rset.%Message,!
}
ELSE
{
WRITE "SUCCESS table : " _tableName_" created and "_rset.%ROWCOUNT_" Rows Imported Successfully",!
}
}Utiliza el siguiente comando para eliminar un conjunto de datos en particular al introducir su ID o utiliza 999 para eliminar todos los conjuntos de datos
do ##class(dc.data.medical.utility).RemoveDS(1)
A continuación se muestra el script principal para eliminar la tabla de forma dinámica
//Get file name
SET filename=tRS.Get("Name")
//Remove .csv from file name
SET tableName=$REPLACE("dc_data_"_ds_"."_tRS.Get("ItemName"),".csv","")
//Drop table
SET qry = "DROP TABLE "_tableName
SET rset = ##class(%SQL.Statement).%ExecDirect(,qry)
//Check if table deleted successfully
IF rset.%SQLCODE
{
WRITE "ERROR : ",rset.%Message,!
}
ELSE
{
WRITE "Table "_tableName_" deleted successfully",!
}
Si el conjunto de datos no está instalado, el botón "Install DataSet" estará visible y si el conjunto de datos está instalado, el botón "Remove Dataset" estará visible.
Solo hay que hacer clic en el botón adecuado para instalar o eliminar cualquier conjunto de datos.png)
Ve a la página View Datasets http://localhost:52773/csp/datasets/datasets.csp
Selecciona un conjunto de datos específico y después una tabla de la lista. Haz clic en el botón Excel, CSV o PDF para exportar los datos.
.png)
Espero que os resulte útil.
¡Hola desarrolladores!
El Administrador de paquetes ZPM se está haciendo muy popular y por ello la librería de paquetes está creciendo.
Así, algunas soluciones o muestras pueden crearse con InterSystems IRIS y uno o dos paquetes instalados.
Me gustaría compartir con vosotros iris-docker-zpm-usage-template - una plantilla que se puede utilizar exactamente con esa finalidad.
¡Hola desarrolladores!
Como sabéis, es muy fácil publicar un paquete en el repositorio de la Comunidad de Desarrolladores.
Pero, ¿cómo se puede probar antes de publicarlo? ¿Cómo se puede garantizar que todo lo que se introdujo en module.xml funciona correctamente?
¡Seguid leyendo las instrucciones que os detallo a continuación!
¡Hola desarrolladores!
Hace un tiempo lanzamos InterSystems Package Manager - ZPM. Uno de los objetivos de ZPM es permitir empaquetar soluciones y enviarlas al registro de ZPM para que su implementación sea tan sencilla como el comando "install tu-paquete".
Para ello es necesario introducir el archivo module.xml en tu repositorio, que describe en qué consiste tu paquete de InterSystems IRIS.
En este artículo se describen las diferentes partes de module.xml, que te ayudarán a configurar el tuyo.
Comenzaré por el paquete samples-objectscript, que instala en IRIS la aplicación Sample ObjectScript y se puede instalar mediante:
zpm: USER>install samples-objectscript
Este es probablemente el paquete más sencillo y aquí está el archivo module.xml, que describe el paquete:
<?xml version="1.0" encoding="UTF-8"?>
<Export generator="Cache" version="25">
<Document name="samples-objectscript.ZPM">
<Module>
<Name>samples-objectscript</Name>
<Version>1.0.0</Version>
<Packaging>module</Packaging>
<SourcesRoot>src</SourcesRoot>
<Resource Name="ObjectScript.PKG"/>
</Module>
</Document>
</Export>
Vamos a revisar el documento detalladamente.
<Export generator="Cache" version="25">
El archivo module.xml pertenece a la familia de documentos de Cache/IRIS xml, por lo que en esta línea se establece la relación para que las librerías internas reconozcan el documento.
La siguiente sección es <Document>
<Document name="samples-objectscript.ZPM">
Tu paquete debe tener un nombre. El nombre puede contener letras en minúscula y el signo "-". Por ejemplo, samples-objectscript en este caso. Coloca el nombre de tu paquete en la cláusula name de la etiqueta Document con la extensión .ZPM.
Los elementos internos de Document son:
<Name> - el nombre de tu paquete. En este caso:
<Name>samples-objectscript</Name>
<Version> - la versión del paquete. En este caso:
<Version>1.0.0</Version>
<Packaging>module</Packaging> - el tipo de paquete. Coloca aquí el parámetro del módulo.
<Packaging>module</Packaging>
<SourcesRoot> - una carpeta, donde ZPM buscará a ObjectScript para su importación.
En este caso, te aconsejamos que busques ObjectScript en la carpeta /src:
<SourcesRoot>src</SourcesRoot>
<Resource Name> - los elementos de ObjectScript que se importarán. Pueden ser paquetes, clases, inclusiones, globals, dfi, etc.
La estructura en la carpeta SourceRoot puede ser la que se genera con el VS Code al trabajar con ObjectScript por defecto.
Aunque también puedes utilizar la versión clásica que tenía esta forma:
/cls - todas las clases de ObjectScript en formato Folder=Package, Class=file.cls. Los subpaquetes son subcarpetas.
/inc - todos los archivos incluidos en formato file.inc.
/mac - todas las rutinas en mac.
/int - todas las rutinas "intermedias" (alias "otro" código, el resultado de una compilación de código mac, u ObjectScirpt sin clases ni macro).
/gbl - todos los globals en formato xml de exportación.
/dfi - todos los archivos DFI en formato xml de exportación. Cada tabla dinámica se incluye en el archivo pivot.dfi, y todos los paneles de control se incluyen en el archivo dashboard.dfi.
Por ejemplo, aquí importaremos la página de ObjectScript. Esto indicará a ZPM que busque la carpeta /src/cls/ObjectScript y que importe todas las clases procedentes de ella:
<Resource Name="ObjectScript.PKG"/>
Así que para preparar tu solución para el empaquetado, coloca las clases de ObjectScript en alguna carpeta de tu repositorio dentro de la carpeta /cls y pon todos los paquetes y clases en package=folder, class=file.cls.
Rutinas para empaquetar con mac
Esto es muy similar a las clases. Basta con colocar las rutinas en la carpeta /mac. Por ejemplo:
<?xml version="1.0" encoding="UTF-8"?>
<Export generator="Cache" version="25">
<Document name="DeepSeeButtons.ZPM">
<Module>
<Name>DeepSeeButtons</Name>
<Version>0.1.7</Version>
<Packaging>module</Packaging>
<SourcesRoot>src</SourcesRoot>
<Resource Name="DeepSeeButtons.mac"/>
</Module>
</Document>
</Export>
Otros elementos
También hay elementos opcionales como:
<Author>
Que pueden contener elementos como <Organization> y <CopyrightDate>.
Por ejemplo:
<Author>
<Organization>InterSystems</Organization>
<CopyrightDate>2019</CopyrightDate>
</Author>
Empaquetado de aplicaciones CSP/Web
ZPM también puede implementar aplicaciones web.
Para que funcione, introduce el elemento CSPApplication con las cláusulas de los parámetros de la aplicación CSP.
Por ejemplo, observa la etiqueta CSPApplication de module.xml en DeepSeeWeb:
<CSPApplication
Url="/dsw"
DeployPath="/build"
SourcePath="${cspdir}/dsw"
ServeFiles="1"
Recurse="1"
CookiePath="/dsw"
/>
Esta configuración creará una aplicación web con el nombre /dsw y copiará todos los archivos de la carpeta /build del repositorio a la carpeta ${cspdir}****/dsw, una carpeta que se encuentra debajo del directorio IRIS csp.
Aplicación API REST
Si se trata de una aplicación API-REST, el elemento CSPApplication contendrá la clase dispatch y podría ser similar al módulo MDX2JSON.xml:
<CSPApplication
Path="/MDX2JSON"
Url="/MDX2JSON"
CookiePath="/MDX2JSON/"
PasswordAuthEnabled="1"
UnauthenticatedEnabled="1"
DispatchClass="MDX2JSON.REST"
/>
Dependencias
Tu módulo podría esperar la presencia de otro módulo que esté instalado en el sistema de destino. Esto se podría describir mediante el elemento <Dependencies> situado dentro del elemento <Document>, que podría contener varios elementos <ModuleReference>, cada uno de los cuales tiene <Name> y <Version> y que indican qué otros módulos, con qué versión deberían instalarse antes que la tuya. Esto hará que ZPM verifique si los módulos están instalados y, en caso contrario, realice la instalación.
Este es un ejemplo de dependencia del módulo DSW en el módulo MDX2JSON:
<Dependencies>
<ModuleReference>
<Name>MDX2JSON</Name>
<Version>2.2.0</Version>
</ModuleReference>
</Dependencies>
Otro ejemplo, donde ThirdPartyPortlets depende de Samples BI (holefoods):
<Dependencies>
<ModuleReference>
<Name>holefoods</Name>
<Version>0.1.0</Version>
</ModuleReference>
</Dependencies>
Además hay opciones para ejecutar tu código de forma arbitraria para configurar los datos y el entorno, pero hablaremos sobre esto en los siguientes artículos.
Cómo crear tu propio paquete
¡Muy bien! Una vez que tengas un module.xml, puedes intentar crear el paquete y probar si la estructura de module.xml es acertada.
Puedes probarlo por medio del cliente zpm. Instala ZPM en un sistema IRIS y carga el código del paquete con el comando load:
zpm: NAMESPACE>load path-to-the-project
La ruta indica la carpeta que contiene los recursos correspondientes para el paquete y tiene el module.xml en la carpeta raíz.
Por ejemplo, puedes probar el paquete creando este proyecto. Compruébalo y crea un contenedor con docker-compose-zpm.yml.
Abre el terminal en el namespace SAMPLES y llama a ZPM:
zpm: SAMPLES>
zpm: SAMPLES>load /iris/app
[samples-objectscript] Reload START
[samples-objectscript] Reload SUCCESS
[samples-objectscript] Module object refreshed.
[samples-objectscript] Validate START
[samples-objectscript] Validate SUCCESS
[samples-objectscript] Compile START
[samples-objectscript] Compile SUCCESS
[samples-objectscript] Activate START
[samples-objectscript] Configure START
[samples-objectscript] Configure SUCCESS
[samples-objectscript] Activate SUCCESS
La ruta es "/iris/app" porque en docker-compose-zpm.yml indicamos que mapeamos la raíz del proyecto en la carpeta /iris/app en el contenedor. Por tanto, podemos utilizar esta ruta para indicar a ZPM desde dónde cargar el proyecto.
¡El proyecto se cargó correctamente! Esto significa que module.xml podría utilizarse para enviar un paquete al repositorio de la Comunidad de Desarrolladores.
Ahora ya sabes cómo crear un archivo module.xml adecuado para tu aplicación.
Cómo enviar la solicitud al repositorio de la Comunidad de InterSystems
Tu aplicación debe estar en Open Exchange
Al dar de alta tu aplicación, simplemente marca el checkbox Publish in Package Manager. A continuación simplemente espera a que pase el proceso de aprobación para que se publique.
¡Y deberías tener un module.xml funcionando correctamente!
Se ha publicado una nueva versión del ZPM - ZPM 0.3.2.
Novedades en esta versión:
En este artículo describiré los procesos para ejecutar pruebas unitarias mediante ObjectScript Package Manager (consulta https://openexchange.intersystems.com/package/ObjectScript-Package-Manager-2), incluyendo el cálculo de la Cobertura de pruebas (mediante https://openexchange.intersystems.com/package/Test-Coverage-Tool).
Ya hay mucha documentación sobre cómo escribir pruebas unitarias en ObjectScript, por lo que no repetiré nada de eso. Puedes consultar el Tutorial de Pruebas Unitarias aquí: https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=TUNT_preface
La práctica recomendada es incluir las pruebas Unitarias en algún lugar/carpeta separada en la estructura de fuentes, ya sea simplemente "/pruebas" o algo más sofisticado. Dentro de InterSystems, terminamos usando /internal/testing/unit_tests/ como nuestro estándar de facto, lo que tiene sentido porque las pruebas son internas/no distribuibles y hay otros tipos de pruebas además de las unitarias, pero esto podría ser un poco complejo para proyectos sencillos de código abierto. Puedes ver esta estructura en algunos de nuestros repositorios de GitHub.
Desde el punto de vista del flujo de trabajo, esto es súper fácil en VSCode: solo hay que crear el directorio y colocar las clases allí. Con enfoques más antiguos centrados en el servidor para el control de la fuente (los utilizados en Studio), tendrás que mapear este paquete de manera apropiada, y el enfoque para eso varía según la extensión del control de la fuente.
Desde la perspectiva de los nombres de clases para las pruebas unitarias, mi preferencia personal (y la práctica recomendada de mi grupo) es:
UnitTest.<package/class being tested>[.<method/feature being tested>]
Por ejemplo, si las pruebas unitarias son para el Método Foo en la clase MyApplication.SomeClass, la clase de la prueba unitaria se llamaría UnitTest.MyApplication.SomeClass.Foo; si las pruebas fueran para la clase en su totalidad, simplemente sería UnitTest.MyApplication.SomeClass.
¡Hacer que ObjectScript Package Manager esté informado de tus pruebas unitarias es sencillo! Basta con añadir una línea como la siguiente a module.xml (tomada de https://github.com/timleavitt/ObjectScript-Math/blob/master/module.xml, una bifurcación del excelente paquete matemático de @Peter Steiwer de Open Exchange, el cual utilizo como un simple ejemplo inspirador):
<Module><br> ...<br> <UnitTest Name="tests" Package="UnitTest.Math" Phase="test"/><br></Module>
Lo que todo esto significa es:
Con las pruebas unitarias definidas como se explicó anteriormente, el administrador de paquetes ofrece algunas herramientas realmente útiles para ejecutarlas. Todavía puedes configurar ^UnitTestRoot, como lo harías normalmente con %UnitTest.Manager, pero probablemente encontrarás las siguientes opciones mucho más fáciles, especialmente si estás trabajando en varios proyectos en el mismo entorno.
Puedes probar todos estas opciones clonando el repositorio objectscript-math enumerado anteriormente y luego cargarlo con zpm "load /path/to/cloned/repo/", o en tu propio paquete reemplazando "objectscript-math" con los nombres de tus paquetes (y nombres de prueba).
Para recargar el módulo y luego ejecutar todas las pruebas unitarias:
zpm "objectscript-math test"
Para simplemente ejecutar las pruebas unitarias (sin recargar):
zpm "objectscript-math test -only"
Para simplemente ejecutar las pruebas unitarias (sin recargar) y proporcionar una salida detallada:
zpm "objectscript-math test -only -verbose"
Para ejecutar un conjunto de pruebas en particular (es decir, un directorio de pruebas, en este caso, todas las pruebas en UnitTest/Math/Utils) sin recargar, y proporcionar una salida detallada:
zpm "objectscript-math test -only -verbose -DUnitTest.Suite=UnitTest.Math.Utils"
Para ejecutar un caso particular de prueba (en este caso, UnitTest.Math.Utils.TestValidateRange) sin recargar y proporcionar una salida detallada:
zpm "objectscript-math test -only -verbose -DUnitTest.Case=UnitTest.Math.Utils.TestValidateRange"
O, si solo estás resolviendo los problemas de un único método de prueba:
zpm "objectscript-math test -only -verbose -DUnitTest.Case=UnitTest.Math.Utils.TestValidateRange -DUnitTest.Method=TestpValueNull"
Cálculo de la Cobertura de pruebas mediante ObjectScript Package Manager
Así que tienes algunas pruebas unitarias, pero ¿son buenas? Calcular la cobertura de pruebas no responderá completamente a esa pregunta, pero al menos ayuda. Presenté esto en la Convención anual (Global Summit) de InterSystems, allá por el año 2018 - aquí puedes ver el vídeo: https://youtu.be/nUSeGHwN5pc .
Lo primero que tendrás que hacer es instalar el paquete de cobertura de pruebas:
zpm "install testcoverage"
Ten en cuenta que esto no requiere la instalación/ejecución de ObjectScript Package Manager; puedes encontrar más información en Open Exchange: https://openexchange.intersystems.com/package/Test-Coverage-Tool
Dicho esto, puedes aprovechar al máximo la herramienta de cobertura de pruebas si también utilizas ObjectScript Package Manager.
Antes de ejecutar pruebas, debes especificar qué clases/rutinas esperas que cubran tus pruebas. Esto es importante porque, en las bases de código muy grandes (por ejemplo, HealthShare), calcular y recopilar la Cobertura de pruebas para todos los archivos del proyecto puede requerir más memoria de la que tiene tu sistema. (Específicamente, gmheap para un análisis por linea de código, si tienes curiosidad).
La lista de archivos se incluye en un archivo llamado cover.list, que está dentro de la raíz de la prueba unitaria. Diferentes subdirectorios (conjuntos) de pruebas unitarias pueden tener su propia copia de esto para anular las clases/rutinas que se rastrearán mientras se ejecuta el conjunto de pruebas.
Para ver un ejemplo sencillo con objectscript-math, consulta: https://github.com/timleavitt/ObjectScript-Math/blob/master/tests/UnitTest/coverage.list. La guía de usuario para la Herramienta de cobertura de pruebas incluye más detalles.
Para ejecutar las pruebas unitarias con el cálculo de la Cobertura de pruebas habilitado, solo hay que añadir un argumento más al comando, especificando que se debe utilizar TestCoverage.Manager en vez de %UnitTest.Manager para ejecutar las pruebas:
zpm "objectscript-math test -only -DUnitTest.ManagerClass=TestCoverage.Manager"
La salida (incluso en el modo resumido) incluirá una URL donde podrás ver qué líneas de tus clases/rutinas estaban cubiertas por las pruebas unitarias, así como algunas estadísticas agregadas.
¿Qué sucede con la automatización de todo esto en CI? ¿Qué sucede con los reportes de resultados de las pruebas unitarias y las puntuaciones/diffs de cobertura? ¡También puedes hacer eso! Para ver un ejemplo sencillo usando Docker, Travis CI y codecov.io, consulta https://github.com/timleavitt/ObjectScript-Math. Estoy planeando escribir esto en un artículo futuro que analice algunos enfoques diferentes.