Hace varios años, estaba enseñando los conocimientos básicos de nuestro framework %UnitTest durante la clase de Fundamentos de Caché (ahora llamada Developing Using InterSystems Objects and SQL). Un alumno preguntó si era posible recoger estadísticas de rendimiento mientras se ejecutan pruebas unitarias. Unas semanas más tarde, añadí un código adicional a los ejemplos de %UnitTest para responder a esa pregunta. Ahora lo comparto con la Comunidad.

¡Hola desarrolladores!

Me gustaría compartir con vosotros un truco útil para presentar código de ObjectScript en ficheros Script en VSCode.

Los ficheros Script son simplemente ficheros con líneas de ObjectScript que introducimos en cualquier sitio, por ejemplo en IRIS durante el procedimiento Docker baking.

Caso de uso típico - este es el Scriptfile

este es el Dockerfile donde lo introducimos.

Y así es como se ve normalmente en VSCode:

Podría ser más elegante, ¿verdad?

Gracias a las últimas mejoras al soporte de Python en IRIS y al continuo trabajo en el soporte a la DB-API de Python por parte de InterSystems, he implementado el soporte de IRIS en el proyecto Django, en el que la DB-API de Python se usa para trabajar con otras bases de datos.

Vamos a probar una sencilla aplicación en Django, que almacena sus datos en IRIS.

Al igual que los servidores hardware, los servidores virtuales en nubes públicas y privadas pueden generar cuellos de botella en los recursos, según aumentan las cargas de trabajo. Si utilizas y administras instancias de InterSystems IRIS implementadas en nubes públicas o privadas, es posible que te hayas encontrado la situación en la que para solucionar problemas de rendimiento o de otro tipo se requiere aumentar la capacidad del servidor de una instancia (es decir, escalar verticalmente).

¡Hola desarrolladores!

Solo quiero compartir una antigua pero muy relevante buena práctica en el cambio de namespaces que @Dmitry Maslennikov compartió conmigo.

Consideremos el método:

classmethod DoSomethingInSYS() as %Status

{

set sc=$$$OK

set ns=$namespace

zn "%SYS"

// try-catch in case there will be an error

try {

// do something, e.g. config change

}

catch {}

 zn ns    ; returning back to the namespace we came in the routine

return sc

}

Durante una actualización a una versión principal (major) es aconsejable recompilar las clases y rutinas de todos tus namespaces (ver Tareas tras la instalación de una versión major).

do $system.OBJ.CompileAllNamespaces("u")

do ##Class(%Routine).CompileAllNamespaces()

Para automatizar esta tarea de administración y mantener un registro de cualquier error, os muestro un ejemplo de una clase para importar y compilar en el namespace USER, que puedes usar después de cada actualización: admin.utils.cls

En este artículo, me gustaría hablar sobre el enfoque spec-first para el desarrollo de una API REST.

Mientras que el desarrollo tradicional code-first de una API REST es así:

• Escribir el código
• Habilitarlo en REST
• Documentarlo (como una API REST)

Spec-first sigue los mismos pasos, pero a la inversa. Comenzamos con una especificación, — que también actúa como documentación — , generamos el código base de la aplicación REST a partir de ella, y finalmente escribimos la lógica de negocio concreta que nos haga falta.

Esto ofrece varias ventajas:

Servir el café: Cómo crear y programar una tarea

¿No te gustaría que una taza de café caliente te esperara justo al llegar a la oficina? ¡Vamos a automatizar eso!

Cache e IRIS incorporan un Administrador de tareas, que debería resultar familiar a quienes estén acostumbrados a utilizar el programador de tareas de Windows o a usar cron en Linux. Tu cuenta de usuario requerirá tener acceso al recurso %Admin_Task para utilizarlo, y puedes acceder a él desde el portal de administración en System Operation -> Task Manager. Cuando se instala por primera vez, hay aproximadamente 20 tipos de tareas que puedes programar.

Si quieres añadir tus propias tareas, empieza creando una clase que extienda %SYS.Task.Definition. Como mínimo, debes sobreescribir el método OnTask, que tiene una firma de Method OnTask() As %Status. El código de ese método se ejecutará cada vez que se lance la tarea. De hecho, si tu tarea arroja "Error #5003: No implementado (Error #5003: Not Implemented)" cada vez que se ejecuta, es porque este método no se sobreescribió correctamente. De manera muy básica, podría ser:

¡Hola desarrolladores!

Solo quiero compartir con vosotros mi conocimiento, es decir, experiencia en algo que os puede hacer ahorrar unas cuantas horas algún día.

Si estás creando una REST API con IRIS que contiene más de un nivel de "/", por ejemplo: '/patients/all', no te olvides de añadir el parámetro 'recurse=1' en tu script de despliegue en %Installer. Si no, todas las entradas de nivel secundario y de mayor profundidad no funcionarán. Y todas las entradas de nivel primario funcionarán.

/patients

- funcionará, pero

/patients/all

- no funcionará.

Este es un ejemplo de sección CSPApplication que arregla el problema y que puede que quieras usar en tu clase %Installer:

    <CSPApplication Url="${CSPAPP}"
      Recurse="1"
      Directory="${CSPAPPDIR}"
      Grant="${RESOURCE},%SQL"
      AuthenticationMethods="96"
      />

Publicación Original por: Anton Umnikov
Arquitecto Senior de soluciones en la nube en InterSystems
AWS CSAA, GCP CACE

AWS Glue es un proceso ETL (extraer, transformar y cargar) completamente gestionado, que hace sencillo y rentable clasificar los datos, limpiarlos, enriquecerlos y moverlos de forma fiable entre diferentes almacenes de datos.

En el caso de InterSystems IRIS, AWS Glue permite mover grandes cantidades de datos a IRIS desde fuentes de datos tanto en la nube como en las propias instalaciones (on-premise). Las fuentes de datos potenciales incluyen, pero no se limitan a, bases de datos on-prem, archivos CSV, JSON, Parquet y Avro que residen en buckets S3, bases de datos nativas en la nube como AWS Redshift y Aurora, y muchas otras.

A veces es necesario transferir o migrar datos y esquemas de datos de Postgres a IRIS. Actualmente hay varias opciones para hacerlo, pero las dos más populares son DBeaver y SQLGateway. Ésta última es descrita por Robert Cemper en este excelente artículo: DB Migration using SQLgateway (Migración de base de datos usando SQLgateway).

Yo describiré en este artículo cómo realizar la migración utilizando DBeaver:

Introducción

Si resuelves problemas complejos en ObjectScript, probablemente tienes mucho código que funciona con los valores de %Status. Si has interactuado con clases persistentes desde una perspectiva de objetos (%Save, %OpenId, etc.), casi seguro que las ha visto.

Un %Status proporciona una envoltura alrededor de un mensaje de error localizable en las plataformas de InterSystems. Un estado OK ($$$OK) simplemente es igual a 1, mientras que un mal estado ($$$ERROR(errorcode,arguments...)) se representa como un 0 seguido de un espacio seguido de una lista $ListBuild con información estructurada sobre el error.

Este artículo describe un diseño arquitectónico de complejidad intermedia para DeepSee. Al igual que en el ejemplo anterior, esta implementación incluye bases de datos separadas para almacenar la información, la implementación y la configuración de DeepSee. También presenta dos nuevas bases de datos: la primera para almacenar los globals necesarios para la sincronización, la segunda para almacenar tablas de hechos e índices.

ObjectScript no incluye ningún método por defecto para añadir un array JSON a otro. Este es un fragmento de código que utilizo y que es equivalente al método concat() de JavaScript.

Puedes llamarlo con cualquier número de argumentos para concatenarlos en un nuevo array. Si un argumento es un array dinámico, sus elementos serán añadidos. Si no, el argumento en sí será añadido.