検索

記事
· 2024年8月29日 2m read

WebTerminal no funciona en IRIS 2024.2

Incluyo este post para ayudar a los usuarios de WebTerminal que han actualizado a la versión IRIS 2024.2 -- (Build 247U) Tue Jul 16 2024 09:52:30 EDT -- liberada recientemente o están considerando hacerlo.

Esa versión 2024.2 contiene un cambio (DP-432503) que precisa que el usuario a través del cual se conecta inicialmente el Web Gateway (normalmente CSPSystem) deba tener permisos de lectura (READ) sobre la base de datos en la que se encuentra la clase de dispatching de la aplicación web de tipo REST.

Para los casos en que eso no es así, se genera un error, pero retorna un estado HTTP 404 a quien hace la petición en lugar del esperado HTTP 401.

En principio el problema se solucionará en la 2024.3, referencia DP-432898 / ALI048 : REST Login endpoints to return 401 HTTP error instead of 404, pero, al ser la 2024.2 una versión de tipo Continuous Delivery (CD), no se incluirá esta corrección.

Un workaround posible es adaptar CSPSystem para que tenga permiso de lectura (READ) sobre la base de datos del namespace en el que instalaste el WebTerminal (ej. WEBTERMINAL).

Así es como yo lo he hecho:

  1. Crea un nuevo recurso de seguridad %DB_WEBTERMINAL y asignáselo a la base de datos WEBTERMINAL en lugar el %DB_%DEFAULT.
  2. Crea un role %DB_WEBTERMINAL que otorgue al poseedor del role de acceso RW al recurso %DB_WEBTERMINAL.
  3. Crea otro role (yo le he llamado DBread_WEBTERMINAL) que da al poseedor del role acceso de solo lectura (R) a ese recurso.
  4. Da al usuario CSPSystem el role DBread_WEBTERMINAL. Esto permite sortear el bug de la 2024.2.
  5. Edita la aplicación web /terminalsocket y añádele el role %DB_WEBTERMINAL en la ficha de Roles de Aplicación. Este paso es necesario porque WebTerminal inicialmente ejecuta su proceso de websocket como UnknownUser y necesita modificar la información de estado en su base de datos incluso antes de que cambia a ejecutarse como un usuario autenticado.

Una técnica más sencilla pero menos segura sería:

  1. Crea un nuevo recurso %DB_WEBTERMINAL con privilegios RW, y asígnalo a la base de datos WEBTERMINAL para que lo use en lugar de %DB_%DEFAULT.

Más detalles en https://github.com/intersystems-community/webterminal/issues/155

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

TestCoverage: Python integrado e interfaz de usuario

Dos grandes cambios para la herramienta de código abierto TestCoverage: Compatibilidad con Python integrado y una nueva interfaz de usuario.

Python integrado

Anteriormente, TestCoverage solo podía rastrear la cobertura de pruebas unitarias para el código escrito en ObjectScript. Ignoraba el código escrito en otros lenguajes como Python en las estadísticas de cobertura.

 

A medida que se escribe cada vez más código de aplicaciones IRIS en Python Embebido, en lugar de solo ObjectScript, es crucial que TestCoverage pueda incluir los resultados de cobertura para el código en Python Embebido. Los clientes (a través de los issues en GitHub de TestCoverage) y otros en InterSystems han expresado interés en ver soporte para Python Embebido.

 

El usuario sigue instalando y ejecutando TestCoverage de la misma manera que antes, tal como se describe en el GitHub de TestCoverage. Los resultados de cobertura para el código en Python Embebido ahora se incluyen en las estadísticas de cobertura agregada, así como en el coloreado individual de líneas, tal como se muestra en el ejemplo anterior.

En el fondo, la cobertura de Python Embebido se rastrea utilizando el rastreador sys.settrace de Python, independientemente del %Monitor.System.LineByLine de ObjectScript, y luego los resultados se combinan y se muestran juntos. Esto puede causar discrepancias muy menores en cuanto a qué líneas se marcan como ejecutables (es decir, que se pueden ejecutar). Por ejemplo, en la imagen anterior, Python considera la declaración elif como ejecutable, pero ObjectScript no considera la declaración ElseIf como ejecutable. Al final, cualquier línea de código marcada en rojo no fue cubierta, y cualquier línea de código marcada en verde sí fue cubierta; esto solo afecta ligeramente qué líneas de código ignoramos, lo cual no causa ningún problema.

Nueva interfaz de usuario de TestCoverage

La interfaz de usuario anterior de TestCoverage era una antigua interfaz Zen que no mostraba muchas de las estadísticas útiles que TestCoverage rastrea. Además, TestCoverage solo podía ejecutarse desde la línea de comandos.

Para resolver estos problemas, se ha creado una nueva interfaz de usuario en Angular, basada en `isc.perf.ui`, la interfaz existente para interactuar con el Monitor Line-By-Line (`^%SYS.MONLBL`). La aplicación web viene con una API REST y una conexión WebSocket para recuperar datos del servidor IRIS. También corrige la autenticación de usuario anterior para `isc.perf.ui`, de modo que ahora utiliza el inicio/cierre de sesión estándar de IRIS. Esto también está disponible públicamente en Open Exchange, bajo el nombre `isc-perf-ui`. A continuación, se presentan algunas de las características y usos de la nueva interfaz de usuario.

Instalación

Hay algunos pasos adicionales para instalar `isc.perf.ui` si queréis utilizar las nuevas funciones de TestCoverage. Solo en Windows, es necesario habilitar el protocolo WebSocket en IIS. En cualquier sistema operativo, debéis otorgar a un usuario específico (normalmente `CSPSystem`) un permiso de recurso (usualmente `%DB_User`) en el portal de administración de IRIS. Estos pasos se describen en la página de GitHub de `isc-perf-ui`.

Página de Test Coverage

En la página Test Coverage, podéis seleccionar los parámetros con los que deseáis ejecutar TestCoverage en vuestras pruebas unitarias.

  

Las explicaciones de los parámetros incluyen descripciones de lo que controla cada uno de estos parámetros. También podéis hacer clic en un cuadro de entrada para ver un valor de ejemplo, y hay una validación de entrada para asegurar que vuestros datos estén en un formato válido.

Después de presionar submit, o enviar, se iniciará la llamada para ejecutar TestCoverage, y veréis el progreso en tiempo real de vuestras pruebas unitarias en el registro en la parte inferior de la página.

 

Después de que las pruebas hayan terminado de ejecutarse, el menú desplegable a la derecha debería abrirse con una lista de combinaciones de rutina y ruta de prueba, así como el porcentaje de cobertura general de vuestro código y el enlace a los resultados de las pruebas unitarias.

 

Haced clic en cualquiera para ser llevados a la página de resultados de cobertura para esa rutina bajo ese directorio de pruebas unitarias.

Aquí podéis ver qué líneas de código fueron cubiertas por vuestras pruebas unitarias según TestCoverage. También hay métricas adicionales como TotalTime, que rastrea la cantidad de tiempo que el código pasó en una determinada línea desde su inicio hasta su finalización.

 

Podéis ordenar aún más en orden ascendente o descendente haciendo clic en las flechas junto a los encabezados; esta es una forma útil de ver cuáles líneas de código tardan más tiempo.

 

Finalmente, el botón Show Methods, o Mostrar Métodos, abre una tabla con la complejidad ciclomática de cada uno de vuestros métodos, mostrando cuáles son los métodos más complejos y vulnerables a errores.

 

Cuando hayáis terminado, podéis hacer clic en el botón de retroceso para volver a la página de lanzamiento. El botón Borrar Resultados en rojo os permite borrar todas las ejecuciones de cobertura de pruebas.

Página de Cobertura Histórica

Después de hacer clic en un ID de ejecución pasado específico, podéis ver los resultados de cobertura a nivel de clase (cobertura de líneas, cobertura de métodos, tiempos) para todas las clases en esa ejecución. Estos datos son los mismos que los de la página de resultados principal de TestCoverage. Esta tabla también se puede ordenar por cada columna. 

 

Una vez más, ambas herramientas están disponibles en el InterSystems Open Exchange (isc-perf-ui y TestCoverage Tool) y en GitHub. ¡Buenas pruebas a todos!

  

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

第十章 创建和使用策略 - 在运行时添加证书

第十章 创建和使用策略 - 在运行时添加证书

在运行时添加证书

如果 Web 服务或客户端必须以编程方式选择并包含证书,请使用以下过程:

  1. 检索 %SYS.X509Credentials 的实例,如以编程方式检索凭据集中所述。

例如:

 set credset=##class(%SYS.X509Credentials).GetByAlias(alias,password)

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

COMPARE ROUTINES

IS IT POSSIBLE TO COMAPRE TWO ROUTINES ACCROSS INHOUSE NETWORK AND IF SO THEN WHAT IS THE PROPER SYNTAX TO USE?

SAMPLE:

K ^RICH D ##class(%Library.Routine).RoutineCompare("\\IP\C$\.......\$NAMESPACE","RTN","\\LOCALHOST\..........\$NAMESPACE","RTN","^RICH")

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