Buscar

¿Usas Office 365 y Teams en tu organización? Si es así, estás de suerte, te voy a enseñar cómo crear un agente para Copilot que te permitirá buscar información directamente en la documentación de IRIS. Es un proceso rápido y sencillo que te ayudará a agilizar tus búsquedas. Además, la nueva versión de Office 365 incluye una versión gratuita de Copilot que puedes descargar y anclar fácilmente en Teams. Ve al menú Aplicaciones, busca Copilot y haz clic en Agregar. En ese momento comenzará la instalación de Copilot dentro de Teams. En la imagen verás el botón Abrir, ya que en mi caso Copilot ya está instalado. En este momento, ya tienes tu Copilot activo y listo para usar. También puedes encontrarlo con el nombre de Copilot Chat, ya que utiliza el modelo GPT-4 de OpenAI, concretamente la versión GPT-4-turbo. Haz clic derecho sobre el ícono de Copilot y selecciona Anclar para tenerlo siempre disponible cada vez que abras Teams. Si te preocupa la seguridad, no te preocupes: este Copilot está protegido mediante lo que Microsoft denomina protección de datos de empresa. Todos los documentos que subas, así como las consultas que realices, no se utilizan para entrenar el modelo. Además, todos los archivos adjuntos se almacenan exclusivamente en tu cuenta de OneDrive. Te dejo el enlace a la documentación oficial para que puedas consultarlo con más detalle y quedarte más tranquilo: https://learn.microsoft.com/en-us/copilot/microsoft-365/enterprise-data-protection Puede que Copilot no sea tu IA favorita, y que pienses que hay otras más potentes para ciertas tareas. Es una discusión larga y con muchos matices: está claro que las IAs han evolucionado y se han especializado mucho, pero para el caso de uso que voy a explicar, esta versión de Copilot Chat es más que suficiente. Lo mejor de todo es que aprovecha las herramientas que ya tienes en tu organización, sin necesidad de contratar ni configurar nada adicional. Ya sabes: Si la vida te da limones, crea un agente con la documentación de Intersystems. Y si lo que quieres es un gin-tonic, tu IA favorita estará encantada de que pases por caja y te dé exactamente lo que necesitas. Ahora vamos a generar nuestro propio agente para acceder a la documentación de Intersystems. En la parte derecha de la pantalla verás una barra de herramientas que muestra los agentes activos. Si es la primera vez que accedes, lo más probable es que esta lista esté vacía. Tendrás dos opciones: - Obtener agentes - Crear agente Usaremos esta segunda opción, ya que actualmente no existe un agente específico para Intersystems. Date una vuelta por los agentes predefinidos; seguramente encontrarás alguno muy interesante de alguna aplicación que ya estés utilizando, como Jira o Confluence. Estos agentes son versiones especializadas de Copilot, diseñadas para interactuar con aplicaciones o servicios específicos. Cada agente está configurado para: Conectarse a una fuente de datos o aplicación concreta (por ejemplo, Jira, Confluence, etc.). Entender el contexto y el lenguaje específico de esa aplicación (como términos como “ticket”, “issue”, “repositorio”, etc.). Ejecutar acciones dentro de esa plataforma, como crear tareas, buscar información o generar informes. Os pongo unos ejemplos prácticos de los dos agentes que tengo actualmente en mi Copilot: uno obtenido directamente de los predefinidos y otro que os enseñaré a crear para Intersystems. Agente Jira Cloud: Entiende términos como “sprint”, “backlog” e “issue”. Puede buscar tareas asignadas a ti. Puede crear un nuevo ticket con solo una instrucción en lenguaje natural. Agente Intersystems Docs: Busca la documentación técnica de Intersystems. Puede responder preguntas como “¿cómo se configura un namespace?” o “¿qué es un global?”. _____________________________________ Ahora, empecemos a generar nuestro agente. Dentro del apartado Copilot en Teams, nos dirigimos a la sección Crear Agente. En ese momento aparecerá un menú donde podrás generar tu agente simplemente indicándole, con una breve descripción, qué quieres que haga Con tres sencillas propuestas, Copilot nos genera nuestro agente, mostrando a la derecha cómo va quedando nuestro prompt Si en lugar de utilizar la pestaña “Describir” vamos a la pestaña “Configurar”, podremos realizar estos pasos manualmente y modificar aspectos como el icono o las solicitudes de inicio de nuestro prompt. Cuando ya tengas todo a tu gusto, presiona el botón Crear y automáticamente se generará tu nuevo agente. Inicialmente, este agente será solo para tu uso, pero podrás configurarlo para que esté disponible para usuarios específicos de tu organización o para todos. Al finalizar el proceso, ya tendrás tu agente disponible en la barra de herramientas de la derecha. Solo queda validar que funciona correctamente. Para ello, selecciona la propuesta: “¿Me puedes decir los parámetros de la función $ZDT?” Si todo está configurado correctamente, el agente te mostrará la información correspondiente de la documentación y, además, te propondrá un enlace directo a la documentación oficial de Intersystems de donde ha obtenido la información. Y así, puedes hacer tantas consultas como se te ocurran, por ejemplo: “¿Cómo se genera un nuevo namespace?” También puedes pedirle que te proporcione instrucciones de código, pero ten cuidado: la IA siempre te devolverá una respuesta, aunque no siempre sea correcta. Es fundamental que revises y valides todo lo que te diga; nunca des por válida una respuesta sin comprobarla previamente. Este agente está pensado para ahorrarte tiempo buscando en toda la documentación, pero no siempre acierta, especialmente cuando se trata de generar código. En particular, el ObjectScript todavía le cuesta un poco. A partir de aquí, ya tienes tu agente para buscar en la documentación de Intersystems. Pero no te quedes solo con la documentación oficial: puedes añadir más enlaces donde buscar información. Por ejemplo, puedes incluir: La URL de la comunidad de Intersystems para consultar artículos. La página de aprendizaje, donde encontrarás información sobre los cursos disponibles relacionados con tus dudas. El Open Exchange. El portal de ideas. Añade todo lo que consideres que realmente te puede ayudar. Eso sí, empieza con las fuentes que de verdad vas a utilizar. No siempre “más es mejor”, ya que las IA pueden confundirse si les das demasiada información. Ponle las cosas fáciles al principio y ve añadiendo más fuentes a medida que veas que esta versión de Copilot resuelve tus dudas sobre Intersystems de manera efectiva. Para concluir, crear tu propio agente Copilot en Teams para consultar la documentación de Intersystems es una forma práctica y eficiente de aprovechar las herramientas que ya tienes a tu alcance. No olvides que la clave está en personalizar tu agente con las fuentes que realmente te sean útiles y validar siempre la información que recibes. Con un poco de práctica, verás cómo agilizas tu trabajo diario y resuelves dudas mucho más rápido. ¡Anímate a experimentar y a sacarle el máximo provecho a esta tecnología que tienes a tu disposición!

Hey Community! Here are the bonuses for participants' articles that take part in InterSystems Tech Article Contest: Python Edition: Article Topic (5) Video (3) Discussion (1) Translation (1) New member (3) Total points Working with Globals in Embedded Python + + + + 10 Accessing Management Portal System Dashboard information and display cache table data on the web page with the help of embedded python + + 6 IRIS Climate Change application that shows how temperature is increasing worldwide as a proof of global warming + + 6 Time zone conversion utility using embedded python + + + 9 IRIS Embedded Python with Azure Service Bus (ASB) use case + + 8 Create Stored Procedures using Embedded Python + 5 Getting known with Django + + 6 Getting known with Django part 2 + 5 Introduction to Web Scraping with Python - lets Extract some Job Data + + 8 Dealing with large content in Python Native API + + 8 Bonuses are subject to change upon the update. Please claim your bonuses here in the comments below!

Todo el mundo tiene un entorno para realizar pruebas. Algunas personas tienen la suerte de tener un entorno totalmente separado para Producción. -- Anónimo . En esta serie de artículos, me gustaría presentar y discutir varios métodos posibles para el desarrollo de software, con las tecnologías de InterSystems y GitLab. Trataré temas como: Git 101 Git flow (development process) Instalación de GitLab Flujo de trabajo de GitLab GitLab CI/CD (Integración Continua/Entrega Continua) CI/CD (Integración Continua/Entrega Continua) con contenedores En esta primera parte se abordará la piedra angular del desarrollo de software moderno - el sistema de control de las versiones de Git y varios flujos de Git. Git 101 Aunque el tema principal que discutiremos es sobre el desarrollo de software, en general, y cómo GitLab puede ayudarnos en ese esfuerzo, Git utiliza conceptos de alto nivel en lugar de varios conceptos subyacentes en su diseño, los cuales son importantes para mejorar la compresión de los conceptos que veremos posteriormente. Dicho esto, Git es un sistema de control de versiones, basado en estas ideas (existen muchas más, aunque estas son las más importantes): Desarrollo no lineal: significa que mientras nuestro software es resultado del lanzamiento de la versión 1 a la 2 y después a la 3, sin que nos demos cuenta, el paso de la versión 1 a la 2 se realiza en paralelo, y varios desarrolladores se ocupan de un número de características/correcciones de errores simultáneamente Desarrollo distribuído significa que el desarrollador es independiente de un servidor central o de otros desarrolladores, y puede establecerse en su propio entorno fácilmente Fusión - las dos ideas anteriores nos llevan a una situación donde existen muchas versiones diferentes de la verdad, simultáneamente, y necesitamos unirlas de nuevo en un estado completo No estoy diciendo que Git inventó estos conceptos. No. Más bien Git hizo que fueran fáciles y populares, y junto con varias innovaciones relacionadas, por ejemplo, la infraestructura definida por código y/o la colocación en contenedores, cambiaron la manera en que se desarrolla el software. Principales términos de Git Repositorio es un proyecto que almacena datos y meta-información sobre los datos. "físicamente" es un directorio que se encuentra en un disco almacena archivos y directorios también almacena un historial completo de los cambios que hubo en cada archivo El repositorio se puede almacenar: Localmente, en nuestro propio equipo De forma remota, en un servidor remoto Pero no existe ninguna diferencia particular entre los repositorios locales y remotos, desde el punto de vista de git. Commit es un estado fijo del repositorio. Obviamente, si cada commit almacenara el estado completo del repositorio, nuestro repositorio crecería mucho y muy rápidamente. Por lo que un commit almacena un diff , que es una diferencia entre el commit actual y su commit padre. Diferentes commits pueden tener un número distinto de padres: 0 - el primer commit en el repositorio no tiene padres 1 - lo más habitual - nuestro commit cambió algo en el repositorio a como estaba durante el commit padre 2 - cuando tenemos dos estados diferentes en el repositorio podemos unirlos en un estado nuevo. Y tanto ese estado, como ese commit tendrían dos padres. >2 - puede suceder cuando unimos más de 2 estados diferentes del repositorio en uno nuevo. Esto no debería ser particularmente importante para nuestra discusión, pero existe Ahora, en el caso de un padre, cada commit que sea diferente de él se llama un commit hijo. Cada commit padre puede tener un número ilimitado de commits hijos. La rama es una referencia (o puntero) para un commit. Así es como se ve: En esta imagen puede verse el repositorio con dos commits (círculos grises), el segundo es la cabeza de la rama maestra. Después de agregar más commits, nuestro repositorio comienza a verse así: Este es el caso más sencillo. Un desarrollador trabaja en un cambio a la vez. Sin embargo, normalmente existen muchos desarrolladores trabajando simultáneamente en diferentes características y necesitamos un árbol de commit para mostrar lo que sucede en nuestro repositorio. Árbol de commit Empezaremos desde el mismo punto de partida. Este es el repositorio con dos commits: Pero en este momento, dos desarrolladores están trabando al mismo tiempo y para que no se interfieran el uno con el otro, ambos trabajan en ramas separadas: Después de un tiempo necesitan unir los cambios realizados y para ello crean una solicitud de fusión (también llamada pull request), que es exactamente lo que parece, es una solicitud para unir dos estados diferentes del repositorio (en nuestro caso queremos fusionar la rama de desarrollo dentro de la rama maestra) en un nuevo estado. Una vez que se revisó y aprobó correctamente, nuestro repositorio se ve de la siguiente manera: Y el desarrollo continúa: Git 101 - Resumen Conceptos principales: Git es un sistema de control distribuido (no lineal) de las versiones Repositorio almacena datos y meta-información sobre los datos Commit es un estado fijo del repositorio La rama (Branch) es una referencia hacia un commit Solicitud de fusión (también llamada pull request) - es una solicitud para unir dos estados diferentes del repositorio en uno nuevo. Si desea leer más sobre Git, aquí puede encontrar varios libros sobre Git. Flujos de Git Ahora que el lector se familiarizó con los términos y conceptos básicos de Git, hablaremos de cómo se puede administrar parte del desarrollo del ciclo de vida del software utilizando Git. Existe una serie de prácticas (llamada flujos) que describen el proceso de desarrollo utilizando Git, pero únicamente examinaremos dos de ellas: Flujo de GitHub Flujo de GitLab Flujo de GitHub El flujo de GitHub puede describirse con la frase "más fácil imposible". Aquí está: Cree una rama desde el repositorio Utilice commit para mover los cambios hacia su nueva rama Envíe una solicitud pull request desde su rama con los cambios propuestos para iniciar una discusión Utilice commit para añadir más cambios en su rama según sea necesario. Su solicitud pull request se actualizará automáticamente Fusione la solicitud pull request una vez que la rama esté lista para fusionarse Existen varias reglas que debemos seguir: La rama maestra siempre esta en punto de desplegarse (¡y funciona!) No existe ningún desarrollo que vaya directamente a la rama maestra El desarrollo se realiza en las ramas de las funciones Maestro == entorno* de producción** Necesita implementarlo para la producción tan frecuentemente como sea posible * El entorno es un sitio configurado donde se ejecuta su código- podría ser un servidor, una máquina virtual o incluso un contenedor. ** No confundir con "Producciones de Ensemble". Aquí "producción" significa EN VIVO. Así es como se ve: Puede aprender más sobre el flujo de GitHub aquí>>. O en esta guía>>. El flujo de GitHub es bueno para proyectos pequeños y para probarlo si apenas comienza a familiarizarse con los flujos de Git. GitHub los utiliza, no obstante, también puede ser una opción válida para proyectos grande. Flujo de GitLab Si no está listo para implementarlo en producción inmediatamente, el flujo de GitLab ofrece el flujo de GitHub + entornos. Así es como funciona: se desarrolla en las ramas de las funciones, según lo definido anteriormente, se fusiona en la rama maestra pero aquí hay un cambio: la rama maestra solo equivale al entorno de prueba. Además, tiene "ramas de entorno", las cuales se enlazan con los otros entornos que pueda tener. Por lo general, existen tres entornos (se pueden crear más si se necesitan): Entorno de prueba == rama maestra Entorno de preproducción == rama de preproducción Entorno de producción == rama de producción El código que llega a una de las ramas del entorno debe moverse inmediatamente al entorno correspondiente, lo cual puede hacerse: Automáticamente (se hará en las partes 2 y 3) Semiautomáticamente (igual que en la forma automática, excepto que debe presionarse un botón que autorice la implementación) Manualmente El proceso completo es así: La función se desarrolla en la rama de las funciones La rama de la función pasa por una revisión y se fusiona con la rama maestra Después de un tiempo (una vez que se fusionaron varias funciones) la rama maestra se fusiona con la preproducción Poco después (pruebas de usuario, etc.), la preproducción se fusiona con la producción Mientras realizábamos las fusiones y las pruebas, varias funciones nuevas se desarrollaron y fusionaron en la rama maestra, por lo tanto VAYA al paso Así es como se ve: Puede aprender más sobre el flujo de GitLab aquí>> Conclusión Git es un sistema distribuido (no lineal) de control de versiones El flujo de Git puede utilizarse como una guía para el ciclo de desarrollo del software, existen varios flujos para elegir Enlaces Libro sobre Git Flujo de GitHub Flujo de GitLab Flujo de Driessen (flujo más completo, como comparación) Código para este artículo Preguntas para debatir ¿Utiliza algún flujo de git? ¿Cuál? ¿Cuántos entornos tiene para un proyecto de tamaño medio? Continuará... En la siguiente parte, veremos: Cómo instalar GitLab Hablaremos sobre algunas modificaciones recomendadas Debatiremos sobre le flujo de trabajo con GitLab Workflow (no confundirse con el flujo de GitLab). ¡Manténganse informado!

¡Hola a tod@s! Os invitamos a un nuevo webinar en español: "Desarrollar y gestionar APIs con InterSystems IRIS Data Platform" el 15 de octubre, a las 16:00 CET. ¿Eres desarrollador de backend o técnico relacionados con integraciones de sistemas? Si es así…¡este es tu webinar! ¿Qué vas a aprender? Desarrollaremos una API REST a partir de especificaciones OpenAPI (Swagger) y veremos de forma práctica cómo exponer en formato JSON los objetos que tenemos almacenados en nuestra base de datos Hablaremos de cómo gestionamos nuestra API, tratando aspectos como la gestión de tokens para consumidores de la API, monitorización de la actividad, cómo establecer controles para restringir el uso de la API por tráfico o cómo introducir nuevas versiones. Y, por supuesto, todo orientado a que sea lo más práctico posible, publicaremos los ejemplos en GitHub y utilizaremos imágenes Docker y Visual Studio Code. ¡Te esperamos! Regístrate aquí >> Muchas gracias Alberto y David. Ha sido muy instructivo y habeis contado cosas que me han servido de mucho. Nota: El dedo mágico de David no existe... lo que si son mágicos solo los dedos de Alberto al teclado Hola, ¿publicarán algo para los que no alcanzamos? Saludos Sí, por supuesto. Dejaremos el link por aquí cuando esté disponible. ¡Hola @Richard.Medina! Ya se puede ver el vídeo completo del webinar en este enlace: https://es.community.intersystems.com/post/nuevo-v%C3%ADdeo-desarrollar-y-gestionar-apis-con-intersystems-iris-data-platform Quedamos a su disposición para lo que necesite. Un saludo. Esther

¡Hola Comunidad! La versión 2019.1.1 de InterSystems IRIS e IRIS for Health ya está disponible. Son versiones de mantenimiento, en el flujo (Extended Maintenance). Los cambios se recogen en la documentación de la versión 2019.1, disponible online, e incluye un nuevo "look" con una disposición tipo "card-style". El número de compilación de esta versión es 2019.1.1.612.0. Un set completo de kits y contenedores para ambos productos está disponible en el Centro de Soporte Internacional, incluyendo las ediciones "community" de InterSystems IRIS e IRIS for Health. Esta versión también incluye soporte para Red Hat Enterprise Linux 8, que se añade a las plataformas ya soportadas, detalladas en el Documento de plataformas soportadas 2019.1. InterSystems IRIS Data Platform 2019.1.1 incluye actualizaciones de mantenimiento en una serie de áreas, como se describe en la documentación online. También incluye tres nuevas funcionalidades, descritas aquí: Support for the InterSystems API Manager X12 element validation. In-place conversion from Caché and Ensemble to InterSystems IRIS IRIS for Health 2019.1.1 incluye actualizaciones de mantenimiento en una serie de áreas, como se describe en la documentación online. También incluye dos nuevas funcionalidades, descritas aquí: Support for the InterSystems API Manager X12 element validation

Hola a tod@s. El equipo certificación hemos recibido algunas preguntas de los desarrolladores de Caché que piensen tomar el exam InterSystems IRIS Core Solutions Developer. Pensé que ahora sería un buen momento para aclarar algunas dudas que la comunidad pueda tener. Incluso si Ud. aún no ha trabajado con InterSystems IRIS, el examen puede ser apto para usted si ya tiene experiencia en Caché. Si miramos los Exam Details veremos que solo hay un tema específico de IRIS. Nuestros diseñadores de exámenes hicieron esto a propósito porque sabíamos que muchos de nuestros socios y clientes estaban solamente considerando o empezando con IRIS mientras estábamos desarrollando el examen. Sabíamos que la mayoría de nuestros desarrolladores no se beneficiarían de un examen centrado únicamente en las nuevas funciones de IRIS. Por lo tanto, casi todo el examen se basa en funcionalidad que Uds. ya puedan conocer. Sin embargo, este examen no es un examen de Caché porque los temas del examen representan como un desarrollador usaría InterSystems IRIS hoy en día. Aquellos de ustedes que han estado utilizando la tecnología InterSystems por más tiempo sabrán que InterSystems ha desarrollado una rica selección de funcionalidades entre las que los desarrolladores pueden elegir. Entonces, cuando trabajamos con nuestros expertos internos y de la comunidad para diseñar el examen, nos aseguramos de seleccionar las áreas y características de IRIS que favorecen el desarrollo de aplicaciones contemporáneas. Esa no fue una tarea fácil porque sabemos que muchos desarrolladores de InterSystems tienen sus maneras de programar favoritas o que su equipo ya tiene estándares de codificación preestablecidos que hacen que usen las tecnologías de InterSystems de una manera muy específica. En cualquier caso, hemos considerado estas (y varias otras) ideas y pensamos que lo hemos hecho bien. Por lo tanto, si usted es un desarrollador de Caché y desea saber si el examen InterSystems IRIS Core Solutions Developer es apto para usted, le invitamos a leer el Exam Content and Topics en los Exam Details. También le recomendamos que revise las sample questions para ver el estilo y los enfoques de los temas. Es posible que también desee buscar algunos temas en nuestra documentación. Finalmente, nuestro equipo de certificación está aquí para responder cualquier pregunta que pueda tener sobre este o cualquier otro examen en certificacion@intersystems.com Gracias y un saludo, James Kantor – Certification Manager, InterSystems P.D. Y para mis compañeros hispanoparlantes, quiero mencionar que nuestros exámenes, por el momento, los ofrecemos únicamente en ingles. No es completamente fuera de la cuestión tener exámenes en otros idiomas en el futuro, pero para ahora no lo tenemos previsto. Afortunadamente, este examen en particular consiste mayormente de ejemplos de código entonces espero que no presente ninguna inconveniencia para Uds.

Desde InterSystems IRIS 2020.1, la versión mínima requerida para AIX es AIX 7.1 TL4. El instalador de InterSystems IRIS detectará si están instalados los IBM XL C filesets requeridos, antes de seguir con la instalación.

¡Hola Desarrolladores! Os dejamos un nuevo video en formato "coding talk" ("Charlas sobre programación"), especialmente realizado por @Evgeny.Shvarov para el Concurso para Desarrolladores de InterSystems: ⏯ Cómo crear y enviar una aplicación al Concurso para Desarrolladores de InterSystems En este video, aprenderás cómo crear tu aplicación ObjectScript sobre InterSystems IRIS ejecutable en Docker. Y verás cómo enviarla a Open Exchange y cómo participar con la aplicación en el Concurso para Desarrolladores de InterSystems. Echa un vistazo a la plantilla de proyecto de GitHub para aplicaciones ObjectScript sobre InterSystems. ¡Esperamos que os resulte útil!

Estoy encantado de anunciar que InterSystems se unirá a la comunidad de código abierto (open source) en el proyecto de Extensión de Visual Studio Code para InterSystems ObjectScript. A principios de este año Raj Singh publicó que emprendíamos un viaje para redefinir el futuro de nuestra estrategia en relación al IDE, y llegamos a la conclusión de que es Visual Studio Code el IDE que puede soportar ese futuro. Es rápido, estable, rico en funcionalidad, y construido sobre una arquitectura tecnológica moderna que nos da la posibilidad de ofrecerte una funcionalidad como nunca antes para tu trabajo con ObjectScript, particularmente en el área de DevOps, desarrollo continuo y programación colaborativa. La comunidad de desarrolladores coincide con nosotros, ya que por primera vez desde que yo recuerdo, un producto ha captado más de la mitad del mercado de IDEs de propósito general. La historia con otros lenguajes es incluso más llamativa, con VS Code siendo utilizado exponencialmente más que cualquier otro IDE. Aparte de Java, que esta repartido de forma muy uniforme, el resto de comunidades de desarrolladores han elegido VS Code. La innovación sólo tiene lugar donde hay una comunidad para soportarla, y cada año más y más, ese lugar es VS Code. Además de decidir sobre VS Code como plataforma, hemos tomado también una decisión significativa, en lugar de crear nuestra propia extensión desde cero, nos hemos unido a la comunidad de código abierto para impulsar el proyecto ya existente creado por @Dmitry.Maslennikov, que ha realizado un increible trabajo construyendo una herramienta con la cual muchos están ya haciendo un trabajo muy productivo con ObjectScript. Nuestro misión para el proyecto es desarrollar el soporte en VS Code para flujos de trabajo basados en servidor que sean familiares para los clientes que llevan ya muchos años trabajando con InterSystems, a la vez que ofrecer un paradigma de flujo de trabajo centrado en cliente, más en linea con la forma de pensar y trabajar de la mayoría de programadores de hoy en día. Para ser claros, todavía no estamos ahí, y llevar la herramienta actual a ese punto llevará tiempo. Pero esperamos entregar una versión de la extensión de VS Code para ObjectScript, con calidad de producción y soportada por InterSystems, hacia finales de año. Otro punto importante es que Studio continuará teniendo un lugar importante en nuestros planes de IDE por muchos años. Si Studio cubre tus necesidades, no tienes de qué preocuparte. Sigue siendo la herramienta de elección para aquellos con los requerimientos más sofisticados. Pero nuestros esfuerzos de desarrollo se centrarán en VS Code. ¿Qué sucede ahora? Lo primero es dejarte que lo pruebes y nos des feedback. Con el fin de hacerlo más sencillo trabajaremos duro para hacer mejoras frecuentes de documentación en la Wiki del proyecto en GitHub. Si encuentras algo que no funciona, o una característica que te gustaría tener, por favor añádelo al Panel de temas de GitHub (GitHub issues board). Sé que muchos usuarios no están familiarizados con GitHub, por lo que hablaremos un poco sobre eso aquí en las siguientes semanas. Esto es código abierto Probablemente habrás notado que el feedback y las comunicaciones sobre este producto se hacen de forma abierta. Esto seguira siendo software de código abierto, con InterSystems como una voz importante en la comunidad, pero para nada la única voz. Los principios del código abierto serán la base de todas las actividades alrededor de este proyecto, estructurado por los principios formales de governanza destacados en el fichero governance.md en el repositorio GitHub. Por remarcar algunos: Cualquiera puede publicar un asunto (issue) – que puede ser un error (bug) or una petición de funcionalidad Cualquiera puede enviar una petición de inclusión (pull request - PR) para añadir una funcionalidad, corregir un error o mejorar la documentación Los committers (quienes aceptan finalmente los cambios) pueden aprovar PRs El Comite de Gestión del proyecto (Project Management Committee - PMC) aprueba los committers y prioriza la lista de asuntos, y por lo tanto establece la hoja de ruta del proyecto El PMC está presidido por @Dmitry.Maslennikov e incluye a 2 miembros de InterSystems y a @John.Murray El PMC se esforzará por buscar el consenso pero requiere sólo mayoría simple Qué es lo siguiente Prueba VS Code e incluye tus apreciaciones, plantea tus issues. Procesaremos esa información durante las próximas semanas para trabajar en una hoja de ruta que nos llevará a la versión 1.0 de la release de producción que InterSystems soportará formalmente a través de los canales normales. Aprende más acerca de este trabajo y las prácticas de desarrollo modernas en general. CaretDev, presentando @Dmitry.Maslennikov, ofreció un webinar el 14 de Abril, e InterSystems realizará un webinar dentrado en IDEs a mediados de Mayo. También publicaremos artículos aquí sobre varios temas relacionados con los IDE, tales como integración continua y pruebas, aprovechamiento de la nube con servicios como Azure DevOps, y gestión de proyectos multi-lenguaje. Va a ser un año muy excitante para el desarrollo de herramientas en esta comunidad, y ¡estamos deseando ayudarte a llevar tu negocio a nuevos niveles! Enlaces importantes Instalación: https://marketplace.visualstudio.com/items?itemName=daimor.vscode-objectscript Documentación: https://github.com/intersystems-community/vscode-objectscript/wiki Issues: https://github.com/intersystems-community/vscode-objectscript/issues

Ya está disponible la primera versión oficial (v1.0) de InterSystems System Alerting and Monitoring (InterSystems SAM) InterSystems SAM v1.0 proporciona una solución moderna de monitorización para productos basados en InterSystems IRIS. Permite vistas a alto nivel de grupos de instancias (clusters) así como la visualización de métricas bajando al nivel de nodos individuales, todo ello junto con la notificación de alertas. Esta primera versión permite visualizar más de 100 métricas del kernel de InterSystems IRIS, y los usuarios pueden extender la plantilla de Grafana que se incluye por defecto para adaptarla a sus gustos y necesidades. La v1.0 se ha concebido para ser un punto de referencia sencillo e intuitivo. ¡Ayúdanos a mejorarla probándola y enviándonos feedback! SAM puede mostrar información de instancias de IRIS a partir de la versión 2020.1 SAM sólo está disponible en formato contenedor. Necesitarás un contenedor con el SAM Manager junto a un pequeño conjunto de componentes adicionales de código abierto (Prometheus and Grafana) que son añadidos automáticamente por el fichero de composición al instalar/arrancar SAM. Los componentes de SAM y el SAM Manager Community Edition están disponibles en: la página de componentes del WRC como “SAM Components”, y la página de contenedores del WRC como “SAM Manager” externamente vía el repositorio de componentes Github y en la página de contenedor de Docker Hub Podéis encontrar la documentación aquí.

¡Hola desarrolladores! Os invitamos a un nuevo webinar en español: "Desarrolla un chatbot con Google Dialogflow, Telegram e InterSystems IRIS", el martes 2 de febrero, a las 4:00 PM (CET). En este webinar: aprenderás a desarrollar un chatbot que permita a los usuarios interactuar con un sistema de citas. Para ello, coordinaremos con InterSystems IRIS los servicios de Google Dialogflow y Telegram y el backend del sistema de citas conocerás cómo puedes plantear añadir un chatbot para ayudar a los usuarios a utilizar tus servicios de una forma más inteligente repasaremos los conceptos necesarios para poner en marcha un chatbot, qué necesitas preparar y cómo puedes diseñar la coordinación de diferentes servicios externos ¡Os esperamos a todos! ➡️ Podéis registraros aquí >> ¡Recordad que el webinar es el próximo martes día 2! Por si aún no os habéis apuntado :D El webinar empieza en 45 minutos. Podréis seguirlo aquí: ➡️ Acceso al webinar ¡Os esperamos!

¡Hola Comunidad! ¿No pudistéis ver el webinar que hicimos la semana pasada? Por si os lo perdisteis o lo queréis volver a ver, ya está disponible la grabación completa. ⏯ Webinar: Desarrolla un chatbot con Google DialogFlow, Telegram e InterSystems IRIS Por cierto... ¿habéis entrado al Canal de YouTube de la Comunidad de Desarrolladores en español? En él podéis ver todos los webinars que hemos realizado (¡ya llevamos ocho!), varios tutoriales y otros vídeos. Y si os suscribís al canal, podréis ver nuestros vídeos directamente en vuestro muro de "Suscripciones" cuando entréis en YouTube ¡Esperamos que os resulte útil!

Esta publicación es la traducción de un artículo que publicó mi compañero Murray hace un tiempo. Durante mi trabajo en soporte la he recomendado muchas veces, pues lo que aquí se explica es bastante común y los ejemplos que se dan pueden ayudar a muchos de vosotros. En esta publicación muestro estrategias para realizar copias de seguridad de Caché utilizando un Backup externo, con ejemplos de integración con soluciones basadas en snapshots. La mayoría de soluciones que veo hoy en día se implementan en Linux con VMware, por lo que gran parte de este artículo muestra, como ejemplos, cómo las soluciones integran la tecnología snapshot de VMware. Backup de Caché El backup online de Caché se incluye de forma predeterminada con la instalación de Caché, lo que permite la creación continua de copias de seguridad de las bases de datos de Caché. Pero hay soluciones de backup más eficientes, que se deberían considerar conforme se escalan los sistemas. El backup externo, integrado con tecnologías snapshot, es la solución recomendada para hacer copias de seguridad de sistema, incluyendo las bases de datos de Caché. Consideraciones para los backups externos En la documentación sobre los Backups externos están todos los detalles. Una consideración importante es: "Para asegurar la integridad del snapshot, Caché ofrece métodos para bloquear las escrituras en la bases de datos mientras se crea el snapshot. Solo las escrituras físicas en los archivos de la base de datos se bloquean durante la creación del snapshot, lo que permite que los procesos sigan realizando actualizaciones en la memoria, sin interrupciones". También es importante tener en cuenta que parte del proceso de snapshot en los sistemas virtualizados causa una breve pausa en la máquina virtual de la que se está haciendo la copia de seguridad, lo que a menudo se llama "stun time" (tiempo de parálisis). Esto normalmente tarda menos de un segundo, por lo que los usuarios no lo notan ni tiene un efecto sobre el funcionamiento del sistema. Sin embargo, en algunos casos la parálisis puede durar más. Si la parálisis dura más que el tiempo de inactividad permitido por el QoS para mirroring de Caché, entonces el nodo del backup creerá que ha ocurrido un fallo en el primario y tomará el control. Más adelante en este artículo explicaré cómo se pueden revisar los stun times en caso de que se necesite hacer cambios en el tiempo de inactividad de mirroring en el QoS. Aquí puedes ver un listado con el resto de publicaciones de esta serie sobre Plataformas de datos InterSystems y su rendimiento. Para este artículo, también debes revisar la documentación de Caché: Guía de copias de seguridad y restauración. Opciones de backup Solución de backup mínima: Backup Online de Caché Si no se tiene otra opción, este viene incluido de forma predeterminada con la plataforma de datos InterSystems, y permite realizar copias de seguridad sin interrupción del servicio. Recuerda que el backup online de Caché solo hace una copia de seguridad de los archivos de la base de datos de Caché, en la que captura todos los bloques de las bases de datos que están asignados para datos, y escribe la salida en un archivo secuencial. El backup online de Caché admite copias de seguridad acumulativas e incrementales. En el contexto de VMware, un backup online de Caché es una solución de copia de seguridad "in-guest" (para el sistema operativo invitado). Como otras soluciones "in-guest", las operaciones de la copia de seguridad online de Caché son esencialmente las mismas tanto si la aplicación está virtualizada como si se ejecuta directamente en un equipo. El backup online de Caché debe coordinarse con un backup del sistema, y así copiar el archivo de salida del backup online (.cbk) a una unidad de backup, junto con otros archivos del sistema que esté usando tu aplicación. Como mínimo, una copia de seguridad del sistema debe incluir el directorio de instalación, los directorios de journal y alternate journal , los archivos de aplicación y cualquier otro directorio que contenga archivos externos usados por la aplicación. El backup online de Caché debe considerarse como una opción básica para sitios menores que desean implementar una solución económica, únicamente para crear copias de seguridad de bases de datos de Caché o copias de seguridad específicas. Es útil, por ejemplo, en la configuración de mirroring. Sin embargo, conforme las bases de datos aumentan en tamaño, y como Caché normalmente es solo una parte del ecosistema de datos de un cliente, se recomienda usar backups externos junto con tecnologías snapshot y utilidades de terceros. Esta es la práctica recomendada, que presenta ventajas como incluir el backup de archivos que no son bases de datos, menores tiempos de restauración, visión de los datos de toda la empresa y mejores herramientas de catalogación y administración. Solución de backup recomendada: Backup Externo Utilizando VMware como ejemplo, la virtualización en VMware añade funciones y opciones adicionales para proteger máquinas virtuales completas. Una vez que has virtualizado una solución, has encapsulado tu sistema eficazmente (incluyendo el sistema operativo, la aplicación y los datos), todo dentro de archivos .vmdk (y algunos otros). Cuando es necesario, es muy fácil administrar estos archivos y usarlos para recuperar un sistema completo. Esta misma situación es muy distinta en un sistema físico, en el que debes recuperar y configurar los componentes por separado: sistema operativo, drivers, aplicaciones de terceros, base de datos y archivos de base de datos, etc. Snapshot de VMware La aplicación vSphere Data Protection (VDP) de VMware y otras soluciones de terceros para realizar backups de máquinas virtuales, como Veeam o Cmmvault, aprovechan las funciones de los snapshots de VMware para crear copias de seguridad. A continuación, explicaré en detalle los snapshots de VMware. Para obtener más información, consulta la documentación de VMware. Es importante recordar que los snapshots se aplican a toda la máquina virtual y que el sistema operativo y cualquier aplicación o el motor de la base de datos no saben que se están haciendo los snapshots. Recuerda también que: > ¡Por sí mismos, los snapshots de VMware no son copias de seguridad! Los snapshots permiten a las aplicaciones de backup crear copias de seguridad, pero no son copias de seguridad en sí mismas. VDP y otras soluciones para backups de terceros usan el proceso de snapshots de VMware, junto con la aplicación de backup, para gestionar la creación y, lo que es muy importante, la eliminación de los snapshots. El proceso y secuencia de eventos para la creación de una copia de seguridad externa con snapshots de VMware es el siguiente: Un software de backup solicita al host ESXi crear un snapshot de VMware. Los archivos .vmdk de una máquina virtual se ponen en un estado de solo lectura y se crea un archivo delta vmdk secundario para cada archivo .vmdk. Se usa una copia en modo escritura con todos los cambios para la máquina virtual escritos en los archivos delta. Todas las lecturas se hacen primero desde el archivo delta. El software de backup gestiona la copia de los archivos .vmdk principales de solo lectura en el backup de destino. Cuando se completa la copia de seguridad, el snapshot se confirma (los discos de la máquina virtual retoman las escrituras y los bloques actualizados en los archivos delta se escriben en el controlador). Ahora se elimina el snapshot de VMware. Las soluciones de backup también usan otras funciones como Change Block Tracking (CBT) para realizar copias de seguridad incrementales o acumulativas, para mejorar la velocidad y eficiencia (especialmente importante para ahorrar espacio) y en general también agregan otras funciones importantes como la deduplicación y compresión de datos, planificación, montaje de máquinas virtuales con direcciones IP cambiadas para verificaciones de integridad, etc., restauraciones totales de máquina virtual y a nivel de archivo y administración de catálogo. Los snapshots de VMware que no se gestionan correctamente o se dejan funcionando durante un largo tiempo pueden ocupar un espacio de almacenamiento excesivo (si cada vez más datos cambian, los archivos delta siguen creciendo) y también ralentizar las máquinas virtuales. Debes pensar con cuidado antes de ejecutar un snapshot manual sobre una instancia de producción. ¿Por qué quieres hacer esto? ¿Qué pasará si vuelves atrás en el tiempo al momento en que se creó el snapshot? ¿Qué les sucederá a todas las transacciones de aplicación entre el momento de creación y el momento de volver atrás? Está bien si tu software de backup crea y elimina un snapshot. El snapshot solo debería existir por un corto plazo. Y una parte clave de tu estrategia de backup será elegir un momento en que el sistema tenga baja carga, para minimizar el impacto sobre los usuarios y el rendimiento. Consideraciones de la base de datos de Caché para snapshots Antes de ejecutar el snapshot, la base de datos se debe poner en modo inactivo, de forma que todas las escrituras pendientes se confirmen y la base de datos quede en un estado consistente. Caché cuenta con métodos y una API para confirmar y luego detener (freeze) las escrituras a las bases de datos durante el breve periodo en el que se crea el snapshot. De esta forma, sólo las escrituras físicas en los archivos de la base de datos se paran durante la creación del snapshot, lo que permite que los procesos sigan realizando actualizaciones en la memoria de forma ininterrumpida. Una vez que se active el snapshot, las escrituras en la base de datos se reinician (thaw) y el backup sigue copiando datos a la unidad física. El tiempo entre el freeze y el thaw debe ser muy breve (unos pocos segundos). Además de pausar las escrituras, el freeze de Caché también gestiona el cambio de los archivos de registro (journals) y escribe un marcador de backup en el fichero de journal. Los journals se seguirán escribiendo normalmente mientras que las escrituras a la base de datos física están detenidas. Si el sistema sufriese un fallo mientras las escrituras en la base de datos física están detenidas, los datos se recuperarían de los journals durante el arranque. El siguiente diagrama muestra el freeze y el thaw con los pasos del snapshot de VMware para crear una de copia de seguridad con una imagen consistente de la base de datos. Fíjate en el poco tiempo entre freeze y thaw - apenas el tiempo necesario para crear el snapshot, no el tiempo para copiar el padre de solo lectura en el destino del backup. Integración de freeze y thaw de Caché vSphere permite invocar automáticamente un script de cualquier lado de la creación del snapshot. Este es el momento en el que se invoca el freeze y thaw de Caché. Nota: para que esta funcionalidad funcione correctamente, el host ESXi requiere que el sistema operativo invitado desactive los discos a través de VMware Tools. Las herramientas VMware Tools deben instalarse en el sistema operativo invitado. Los scripts deben cumplir estrictas reglas de nomenclatura y ubicación. También deben definirse los permisos de archivo. Para VMware en Linux, los nombres de los scripts son: # /usr/sbin/pre-freeze-script # /usr/sbin/post-thaw-script A continuación, se muestran ejemplos de scripts de freeze y thaw que nuestro equipo usa con el backup Veeam para nuestras instancias de pruebas internas en laboratorio, pero estos scripts también deberían funcionar con otras soluciones. Estos ejemplos fueron probados y usados en vSphere 6 y Red Hat 7. > Aunque es posible usar estos scripts como ejemplos y para ilustrar el método, ¡debes validarlos para tus propios entornos! Ejemplo de script pre-freeze: #!/bin/sh # # Script invocado por VMWare inmediatamente antes de la toma del snapshot para el backup. # Tested on Red Hat 7.2 # LOGDIR=/var/log SNAPLOG=$LOGDIR/snapshot.log echo >> $SNAPLOG echo "`date`: Pre freeze script started" >> $SNAPLOG exit_code=0 # Only for running instances for INST in `ccontrol qall 2>/dev/null | tail -n +3 | grep '^up' | cut -c5- | awk '{print $1}'`; do echo "`date`: Attempting to freeze $INST" >> $SNAPLOG # Detailed instances specific log LOGFILE=$LOGDIR/$INST-pre_post.log # Freeze csession $INST -U '%SYS' "##Class(Backup.General).ExternalFreeze(\"$LOGFILE\",,,,,,1800)" >> $SNAPLOG $ status=$? case $status in 5) echo "`date`: $INST IS FROZEN" >> $SNAPLOG ;; 3) echo "`date`: $INST FREEZE FAILED" >> $SNAPLOG logger -p user.err "freeze of $INST failed" exit_code=1 ;; *) echo "`date`: ERROR: Unknown status code: $status" >> $SNAPLOG logger -p user.err "ERROR when freezing $INST" exit_code=1 ;; esac echo "`date`: Completed freeze of $INST" >> $SNAPLOG done echo "`date`: Pre freeze script finished" >> $SNAPLOG exit $exit_code Ejemplo de script thaw: #!/bin/sh # # Script called by VMWare immediately after backup snapshot has been created # Tested on Red Hat 7.2 # LOGDIR=/var/log SNAPLOG=$LOGDIR/snapshot.log echo >> $SNAPLOG echo "`date`: Post thaw script started" >> $SNAPLOG exit_code=0 if [ -d "$LOGDIR" ]; then # Only for running instances for INST in `ccontrol qall 2>/dev/null | tail -n +3 | grep '^up' | cut -c5- | awk '{print $1}'`; do echo "`date`: Attempting to thaw $INST" >> $SNAPLOG # Detailed instances specific log LOGFILE=$LOGDIR/$INST-pre_post.log # Thaw csession $INST -U%SYS "##Class(Backup.General).ExternalThaw(\"$LOGFILE\")" >> $SNAPLOG 2>&1 status=$? case $status in 5) echo "`date`: $INST IS THAWED" >> $SNAPLOG csession $INST -U%SYS "##Class(Backup.General).ExternalSetHistory(\"$LOGFILE\")" >> $SNAPLOG$ ;; 3) echo "`date`: $INST THAW FAILED" >> $SNAPLOG logger -p user.err "thaw of $INST failed" exit_code=1 ;; *) echo "`date`: ERROR: Unknown status code: $status" >> $SNAPLOG logger -p user.err "ERROR when thawing $INST" exit_code=1 ;; esac echo "`date`: Completed thaw of $INST" >> $SNAPLOG done fi echo "`date`: Post thaw script finished" >> $SNAPLOG exit $exit_code Recuerda definir los permisos: # sudo chown root.root /usr/sbin/pre-freeze-script /usr/sbin/post-thaw-script # sudo chmod 0700 /usr/sbin/pre-freeze-script /usr/sbin/post-thaw-script Prueba de freeze y thaw Para probar que los scripts están funcionando correctamente, puedes ejecutar un snapshot manualmente sobre una máquina virtual y verificar la salida del script. La siguiente captura de pantalla muestra el cuadro de diálogo "Take VM Snapshot" y sus opciones. Deselecciona- "Snapshot de la memoria de la máquina virtual". Selecciona- "Desactivar sistema de archivos invitado (Necesita VMware Tools instalado)" para pausar los procesos en ejecución en el sistema operativo invitado para que los contenidos del sistema de archivos estén en un estado conocido consistente al tomar el snapshot. ¡Importante! ¡¡¡Después de realizar la prueba, recuerda eliminar el snapshot!!! Si la marca de "quiesce" está activa y la máquina virtual está encendida cuando se realiza el snapshot, se usará VMware Tools para desactivar el sistema de archivos en la máquina virtual. Desactivar un sistema de archivos es el proceso de llevar los datos en disco a un estado adecuado para hacer una copia de seguridad. Este proceso podría incluir operaciones como pasar los búferes sucios desde el caché en memoria del sistema operativo hasta el disco duro. La siguiente salida muestra los contenidos del archivo de registro $SNAPSHOT definido en los scripts del ejemplo anterior para freeze/thaw, después de ejecutar una copia de seguridad que incluye snapshot como parte de su operación. Wed Jan 4 16:30:35 EST 2017: Pre freeze script started Wed Jan 4 16:30:35 EST 2017: Attempting to freeze H20152 Wed Jan 4 16:30:36 EST 2017: H20152 IS FROZEN Wed Jan 4 16:30:36 EST 2017: Completed freeze of H20152 Wed Jan 4 16:30:36 EST 2017: Pre freeze script finished Wed Jan 4 16:30:41 EST 2017: Post thaw script started Wed Jan 4 16:30:41 EST 2017: Attempting to thaw H20152 Wed Jan 4 16:30:42 EST 2017: H20152 IS THAWED Wed Jan 4 16:30:42 EST 2017: Completed thaw of H20152 Wed Jan 4 16:30:42 EST 2017: Post thaw script finished Este ejemplo muestra que pasaron 6 segundos entre freeze y thaw (16:30:36 a 16:30:42). Las operaciones del usuario NO se interrumpen durante este periodo. Deberás recoger métricas de tus propios sistemas, pero para dar un poco de contexto, este ejemplo proviene de un sistema que ejecuta una aplicación benchmark sobre una máquina virtual sin cuellos de botella de E/S y un promedio de más de 2 millones de Glorefs/seg, 170 000 Gloupds/seg y una media de 1 100 lecturas físicas/seg y 3 000 escrituras por ciclo de daemon de escritura. Recuerda que la memoria no es parte del snapshot, por lo que, al reiniciar, la máquina virtual se reiniciará y se recuperará. Los ficheros de la base de datos serán consistentes. No se quiere "reanudar" una copia de seguridad, sino que se quiere obtener una copia en un punto determinado en el tiempo. Luego se podrán aplicar los journals y otros pasos de recuperación necesarios para la consistencia tanto de aplicaciones como de transacciones, una vez que se han recuperado los ficheros. Para una protección adicional de los datos, también se puede realizar un cambio de journal por sí mismo y se puede realizar una copia de seguridad de los journals o replicarlos en otra ubicación, por ejemplo, cada hora. A continuación se muestra el resultado de $LOGFILE en los scripts de freeze/thaw de los ejemplos anteriores, que muestran los detalles del registro para el snapshot. 01/04/2017 16:30:35: Backup.General.ExternalFreeze: Suspending system Journal file switched to: /trak/jnl/jrnpri/h20152/H20152_20170104.011 01/04/2017 16:30:35: Backup.General.ExternalFreeze: Start a journal restore for this backup with journal file: /trak/jnl/jrnpri/h20152/H20152_20170104.011 Journal marker set at offset 197192 of /trak/jnl/jrnpri/h20152/H20152_20170104.011 01/04/2017 16:30:36: Backup.General.ExternalFreeze: System suspended 01/04/2017 16:30:41: Backup.General.ExternalThaw: Resuming system 01/04/2017 16:30:42: Backup.General.ExternalThaw: System resumed STUN TIMES de máquina virtual En el momento de creación de un snapshot de máquina virtual y después de completar la copia de seguridad y de confirmar el snapshot, la máquina virtual debe detenerse por un breve lapso. A este breve freeze a menudo se le llama "stunning" de la máquina virtual. Aquí puedes leer un buen artículo sobre los stun times. A continuación, resumo los detalles y los pongo en el contexto de la base de datos Caché. Del artículo sobre los stun times: “Para crear un snapshot de una máquina virtual, la máquina virtual se "paraliza" para (i) serializar el estado del dispositivo al disco y (ii) cerrar el disco en ejecución actual y crear un punto de snapshot.… Al consolidar, la máquina virtual se "paraliza" para cerrar los discos y ponerlos en un estado adecuado para la consolidación.” El stun time es normalmente de unos pocos centenares de milisegundos. Sin embargo, es posible que si hay una actividad muy elevada de escritura en disco durante la fase de confirmación, el tiempo de stun time puede ser de varios segundos. Si la máquina virtual es un miembro Primario o de Backup que participa en el mirroring de la base de datos Caché y el stun time es mayor que el tiempo de espera del mirror de calidad de servicio (QoS), el mirror reportará un fallo de la máquina virtual donde esté el nodo primario y se producirá un failover de mirror al nodo backup o secundario. Actualización marzo de 2018: Mi colega Peter Greskoff me indicó que un miembro mirror del backup podría iniciar el sistema de emergencia en un tiempo tan breve como solo un poco más de la mitad del tiempo de espera de QoS durante la parálisis de una máquina virtual o en cualquier otro momento que el miembro mirror primario no esté disponible. Para una descripción detallada de las consideraciones de QoS y escenarios de tolerancia a fallos, puedes consultar este recomendable artículo: Guía de tiempo de espera de calidad de servicio para Mirroring. La versión resumida sobre los stun times de la máquina virtual y la QoS es la siguiente: Si el mirror de la copia de seguridad no recibe mensajes del mirror primario dentro de la mitad del tiempo de espera de la QoS, enviará un mensaje para comprobar que el primario sigue funcionando. Luego, la copia de seguridad espera una respuesta de la máquina primaria durante una mitad adicional del tiempo de QoS. Si no recibe respuesta del primario, asume que no está activo y la copia de seguridad toma el control. En un sistema con carga, se envían journals continuamente desde el mirror primario al mirror de backup, y la copia de seguridad no necesitará verificar si el primario sigue activo. Sin embargo, durante un tiempo de poca actividad (cuando es más probable que se realicen copias de seguridad), si la aplicación está inactiva es posible que no haya mensajes entre el mirror primario y la de copia de seguridad durante más de la mitad del tiempo de QoS. Este es el ejemplo de Peter: piensa en este rango de tiempo para un sistema inactivo con un tiempo de espera de QoS de :08 segundos y un stun time de máquina virtual de :07 segundos: :00 el primario envía un mensaje keepalive al árbitro, el árbitro responde inmediatamente :01 un miembro de la copia de seguridad envía un mensaje keepalive al primario. El primario responde inmediatamente :02 :03 comienza el stun de la máquina virtual :04 el primario intenta enviar un mensaje de keepalive al árbitro, pero no llega a destino hasta que finalice el stun :05 el miembro de la copia de seguridad envía un ping al primario, cuando haya vencido la mitad del QoS :06 :07 :08 el árbitro no ha recibido nada del primario durante un tiempo de espera completo de QoS, por lo que cierra la conexión :09 la copia de seguridad no ha obtenido respuesta del primario, y confirma con el árbitro que también perdió la conexión, por lo que asume el control :10 finaliza el stun de la máquina virtual, ¡¡demasiado tarde!! Lee también la sección, "Obstáculos y preocupaciones al configurar el tiempo de espera de calidad de servicio" en la publicación indicada más arriba, para entender el equilibrio para tener QoS solo durante el tiempo necesario. Tener QoS durante demasiado tiempo, especialmente más de 30 segundos, puede causar problemas. Fin de la actualización marzo de 2018: Para tener más información sobre el mirroring de QoS, consulta también esta documentación. Algunas estrategias para reducir el stun time al mínimo, son crear copias de seguridad cuando la actividad de la base de datos es baja y tener un almacenamiento bien configurado. Como se indicó más arriba al crear un snapshot, hay varias opciones que se pueden especificar- una de ellas es incluir el estado de la memoria en la snapshot. Recuerda: el estado de la memoria NO se necesita para realizar copias de seguridad de la bases de datos Caché. Si se elije la marca de memoria, se incluye en el snapshot una copia de datos del estado interno de la máquina virtual. Lleva mucho más tiempo crear los snapshots de memoria. Los snapshots de memoria se usan para permitir la reversión a un estado de una máquina virtual en funcionamiento tal como estaba al momento del snapshot. Esto NO es necesario para realizar una copia de seguridad de archivos de una base de datos. Al tomar un snapshot de la memoria, se paralizará todo el estado completo de la máquina virtual. El stun time es variable. Como se explicó antes, para copias de seguridad se debe marcar la opción de "quiesce" para hacer snapshots manuales o que las tome el software de backup, para garantizar así una copia de seguridad consistente y utilizable. Análisis de los stun time en registros de VMware A partir de ESXi 5.0, los stun time por snapshot se registran en el archivo de registro de cada máquina virtual (vmware.log), con mensajes como estos: 2017-01-04T22:15:58.846Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 38123 us Los stun time están en microsegundos, por lo que en el ejemplo anterior 38123 us es 38123/1,000,000 segundos o 0.038 segundos. Para asegurarse de que los stun time están dentro de los límites aceptables, o para resolver problemas si sospechas que los stun times prolongados generan problemas, puedes descargar y consultar los archivos vmware.log de la carpeta de la máquina virtual que te interesa. Una vez descargados, puedes extraer y ordenar el registro, por ejemplo usando los siguientes comandos de Linux. Ejemplo de descarga de archivos vmware.log Hay varias formas de descargar registros de soporte, incluyendo crear un paquete de soporte de VMware a través de la consola de gestión de vSphere, o desde la línea de comando del host ESXi. Consulta la documentación de VMware para obtener más detalles, pero a continuación ofrecemos un sencillo método para crear y recoger un paquete de soporte mucho más reducido, que incluye el archivo vmware.log para que puedas revisar los stun times. Necesitarás el nombre largo del directorio donde se encuentran los archivos de la máquina virtual. Inicia sesión en el host ESXi donde se ejecuta la máquina virtual de la base de datos que utiliza ssh y usa el comando: vim-cmd vmsvc/getallvms para enumerar los archivos vmx y los nombres largos únicos asociados con ellos. Por ejemplo, el nombre largo para la máquina virtual de la base de datos del ejemplo usado en esta publicación sale como: 26 vsan-tc2016-db1 [vsanDatastore] e2fe4e58-dbd1-5e79-e3e2-246e9613a6f0/vsan-tc2016-db1.vmx rhel7_64Guest vmx-11 A continuación, ejecuta el comando para recoger y agrupar en un paquete únicamente los archivos de registro: vm-support -a VirtualMachines:logs. El comando replicará la ubicación del paquete de soporte, por ejemplo: Para ver los archivos recolectados, revisa '/vmfs/volumes/datastore1 (3)/esx-esxvsan4.iscinternal.com-2016-12-30--07.19-9235879.tgz'. Ahora puedes usar sftp para transferir el archivo hacia fuera del host para su posterior procesamiento y revisión. En este ejemplo, después de descomprimir el paquete de soporte, ve hacia la ruta correspondiente al nombre largo de la máquina virtual de base de datos. Por ejemplo, en este caso: /vmfs/volumes//e2fe4e58-dbd1-5e79-e3e2-246e9613a6f0. Ahí podrás ver varios archivos de registro numerados. El archivo de registro más reciente no tiene número, es decir vmware.log. Puede que el registro sea de unos pocos cientos de KB, pero contiene mucha información. Sin embargo, solo nos importan los stun/unstun times, que son fáciles de encontrar con grep. Por ejemplo: $ grep Unstun vmware.log 2017-01-04T21:30:19.662Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 1091706 us --- 2017-01-04T22:15:58.846Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 38123 us 2017-01-04T22:15:59.573Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 298346 us 2017-01-04T22:16:03.672Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 301099 us 2017-01-04T22:16:06.471Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 341616 us 2017-01-04T22:16:24.813Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 264392 us 2017-01-04T22:16:30.921Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 221633 us Podemos ver dos grupos de stun times en el ejemplo, uno de la creación de la snapshot, y el segundo creado 45 minutos después para cada disco cuando la snapshot se elimina/consolida (por ejemplo, después de que el software de backup haya terminado de copiar el archivo vmx de solo lectura). En el ejemplo anterior, podemos ver que la mayoría de los stun times son de menos de un segundo, si bien el tiempo de parálisis inicial es de apenas más de un segundo. Los stun times cortos son imperceptibles para un usuario final. Sin embargo, procesos del sistema como el Mirroring de la base de datos Caché supervisan continuamente si una instancia está "viva". Si el stun time supera el tiempo de espera de QoS de mirroring, entonces el nodo podrá considerarse como no contactable y "muerto", y se activará una tolerancia de fallos. Consejo: para revisar todos los registros o para resolver problemas, un comando útil es hacer un grep de todos los archivos vmware*.log y buscar valores atípicos o instancias en las que el stun time se aproxime al tiempo de espera de QoS. El siguiente comando canaliza la salida a awk para formatearla: grep Unstun vmware* | awk '{ printf ("%'"'"'d", $8)} {print " ---" $0}' | sort -nr Resumen Deberías supervisar tu sistema con frecuencia durante su funcionamiento normal, para entender los stun times y cómo pueden impactar sobre el tiempo de espera de QoS para aplicaciones de alta disponibilidad como mirroring. Como se indicó anteriormente, algunas estrategias para reducir los stun/unstun times al mínimo son crear copias de seguridad cuando la actividad de la base de datos y del almacenamiento es baja y tener un almacenamiento bien configurado. Para una supervisión constante, es posible procesar los registros usando VMware Log insight u otras herramientas. En futuras publicaciones volveré a tratar las operaciones de backup y restauración para las plataformas de datos InterSystems. Pero por ahora, si tienes algún comentario o sugerencia basada en los flujos de trabajo de tus sistemas, compártelos en la sección de comentarios de abajo.

Soporte te está ayudando a resolver una incidencia con un informe y necesitan reproducir el problema en su sistema local. ¡Es una pena que no puedan ejecutar el informe porque la conexión JDBC al origen de datos fallará! O... ¿hay alguna forma? Hay una forma de ejecutar un informe offline sin acceso a la base de datos origen. Debes proporcionar los resultados de una query cacheada exportada desde Designer. Es un fichero que contiene los datos de la query. Soporte lo usará para evitar el origen de datos del informe. Cuando ejecuten el informe, cogerá los datos del fichero, no de la conexión JDBC. Aclaración Esto no tiene nada que ver con IRIS BI query cache. IRIS BI query cache Globals usados por el motor de consultas de BI para mejorar el rendimiento. InterSystems Reports cached query result Un fichero que permite ejecutar un informe offline, sin acceso a la base de datos origen. El informe recupera los datos del fichero, no de la conexión JDBC habitual. Cómo enviar informes con registros de queries cacheadas. 1. Comprime y envía la carpeta "Catalog" completa. Indica qué informe estás probando. 2. Abre tu informe en Designer. En el panel "Data" a la izquierda, haz clic con el botón derecho en el conjunto de datos y elige Create Cached Query Result. Si el informe tiene varios conjuntos de datos, hazlo en cada uno. Envía los archivos exportados. Descargo de responsabilidad ¡Ojo! No envíes registros de queries cacheadas que contenga datos confidenciales. Documentación Logi Cached Query documentation (v18)

¡Hola Comunidad! Estamos encantados de anunciar que vuelven los webinars de la Comunidad! Os invitamos al webinar Cómo escalar el servidor FHIR de InterSystems en Amazon Web Services con ECP. ⏱ Fecha: Jueves 18 de agosto, 14:00 (CEST)👨‍🏫 Ponente: @Ron.Sweeney1582, Full Stack Architect en Integration Required➡️ El webinar será en inglés No os perdáis esta oportunidad de aprender más sobre FHIR, ECP y AWS y cómo mezclarlo todo! >> REGISTRO AQUÍ <<