Buscar

¡Hola Comunidad! Os traemos un nuevo vídeo del Global Summit de este año, disponible en el canal de YouTube de la Comunidad de Desarrolladores en inglés: ⏯ InterSystems IRIS y la memoria Intel Optane Optane es una nueva clase de memoria de Intel, que permite acelerar el rendimiento de los discos duros. En este vídeo, se muestran los beneficios en rendimiento de utilizar la memoria Intel Optane con InterSystems IRIS y se describen varios casos de uso con memoria y almacenamiento Optane. Aprendo: Conocer los beneficios de utilizar la tecnología Optane de Intel con InterSystems IRISPonente: @Mark.Bolinsky, Senior Technology Architect, InterSystems Suscríbete a nuestro canal de YouTube para estar al día. ¡Esperamos que os resulte útil

¡Hola Comunidad! El gestor de paquetes InterSystems Package Manager (ZPM) es una gran herramienta, pero es aún mejor si la puedes usar directamente en lugar de tener que instalarla. Hay varias formas de hacer esto, a continuación veremos una forma de tener un contenedor IRIS con ZPM instalado a través del Dockerfile. Hemos preparado un ejemplo con algunas líneas en el Dockerfile que se ocupan de la descarga e instalación de la última versión de ZPM. Añade estas líneas a tu Dockerfile estándar que utiliza el IRIS Community y tendrás ZPM instalado y listo para usar. Para descargar la última versión del cliente ZPM: RUN mkdir -p /tmp/deps \ && cd /tmp/deps \ && wget -q https://pm.community.intersystems.com/packages/zpm/latest/installer -O zpm.xml para instalar ZPM en IRIS: " Do \$system.OBJ.Load(\"/tmp/deps/zpm.xml\", \"ck\")" \ Para probar ZPM con este repositorio, tienes que hacer lo siguiente: $ git clone https://github.com/intersystems-community/objectscript-zpm-template.git Compila y ejecuta el repositorio: $ docker-compose up -d Open IRIS terminal: $ docker-compose exec iris iris session iris USER> Llama a ZPM: USER>zpm zpm: USER> Instala webterminal: zpm: USER>install webterminal webterminal] Reload START [webterminal] Reload SUCCESS [webterminal] Module object refreshed. [webterminal] Validate START [webterminal] Validate SUCCESS [webterminal] Compile START [webterminal] Compile SUCCESS [webterminal] Activate START [webterminal] Configure START [webterminal] Configure SUCCESS [webterminal] Activate SUCCESS zpm: USER> ¡Pruébalo! Y echa un vistazo al proceso completo en este gif:

Hola Estoy trabajando con un equipo de desarrolladores que quieren dar el salto a InterSystems 2019.4, actualmente utilizan Object Script para sus desarrollos, y no utilizan ningún tipo de sistema de control de versiones. Yo desconozco como funciona todo este entorno, por lo que he creído que sería buena idea solicitar ayuda en la comunidad, ya que parece bastante activa, y así asegurarnos de seguir buenas prácticas. Actualmente, se trabaja sobre distintos Namespace en la misma plataforma en producción. Cada desarrollador debe tener una imagen Docker donde trabajar en su local, y crear clases/funciones/etc con objectScrip y en VS Code. El problema nos ha surgido al no saber como gestionar el código de los distintos NameSpace en un solo repositorio, y no hemos encontrado documentación que nos oriente respecto a esto... ¿Alguna idea sobre como deberíamos trabajar? Hola Jorge, Me surgen varias dudas. Si trabajáis con diferentes Namespaces es porque son proyectos diferentes o ¿cómo están relacionados?. En principio lo lógico es que cada Namespace disponga de un Repo diferente. También podría estar todo junto si no hay solapamiento entre nombres de paquetes y clases. Ya que la idea es que cada desarrollador tenga un entorno aislado y por lo tanto el que toque clases de un Namespace normalmente no tocará las otras y esas no molestan. Sin embargo es muy importante que los despliegues en el servidor en producción se hagan de manera controlada y mediante paquetes de despliegue que se construyan ex-profeso para el mismo. No se si me he explicado bien... Pero en resumen, una cosa es como se organiza el código en el desarrollo y otra diferente es como repartas las clases en el despliegue Hola David, Primero agradecerte tu rápida respuesta. Creo que los diferentes NameSpaces referencian distintos proyectos, si.(disculpa mi desconocimiento, como aquel que dice acabo de incorporarme a este mundo). Entiendo que la forma correcta sería tener un repo para el código de cada NameSpace y ¿quizá otro para el código que sea común a todos los Namespaces? Sí claro, eso tiene mucho sentido. Lo único es que os toca gestionar varios Repos. Pero será muy práctico ir identificando funcionalidad común y llevarlo al Repo común. Luego las clases comunes gestionarlos como librerías independientes. Si el esquema que tenéis se despliega todo en la misma instancia entonces también podéis hacer mapeos de clases entre Namespaces. Hola Jorge. Bienvenido a la comunidad. En mi empresa tenemos varios proyectos separados por NAMESPACES y cada proyecto tiene un repositorio independiente. Pero a lo mejor te podría servir la forma que lo tenemos distribuido, luego tener el mismo repositorio (GIT, TFS, etc..) para todo el conjunto: 1) Crear un directorio común con todos los namespaces, cada namespace tendrá su propia carpeta 2) Guardar en el directorio principal (Healthshare) el area de trabajo, pero cada carpeta que no sea visible (luego explico el por qué) { "folders": [ { "path": "." }, { "name": "Common", "path": "./COMMON" }, { "name": "Customers", "path": "./CUSTOMERS" }, { "name": "Documents", "path": "./DOCUMENTS" }, { "name": "Hospital", "path": "./HOSPITAL" } ], "settings": { "files.exclude": { "**/.git": true, "Common": true, "Customers": true, "Documents": true, "Hospital": true } }} Quedará el siguiente aspecto en VSCode 3) Configuramos el VSCode ObjectScript de @Dmitry.Maslennikov de la siguiente forma: en MyWork.code-workspace. Esta sería la configuración general de conexión con el servidor de Ensemble / ObjectScript "settings": { "files.exclude": { "**/.git": true, "Common": true, "Customers": true, "Documents": true, "Hospital": true }, "objectscript.conn": { "active": true, "host": "localhost", "port": 57772, "username": "_SYSTEM", "password": "SYS", "https": false, "links": {} } 4) En cada uno de los directorios, añadimos una configuración por carpeta con el nombre del namespace que esté trabajando cada subconjunto { "objectscript.conn": { "ns": "COMMON" }} De esta forma cada workspace trabajará con su conexión correspondiente A la hora de subir el repositorio, se sube en Git como cualquier otro fichero, incluso se tendría el equipo totalmente actualizado dado que se podría sincronizar los otros NAMESPACE a la vez y tener actualizado el entorno de desarrollo. Espero que esta forma de distribuición te sirva como nos está sirviendo a nosotros. Un saludo, Francisco López Hola David, gracias de nuevo! ¿Cómo funciona el mapeo de clases entre Namespaces? No he visto referencias a esto en la documentación. Bueno, el nombre correcto es Package Mapping, cierto que son paquetes lo que se mapea pero coloquialmente hablo de clases: https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GOBJ_packages#GOBJ_packages_mapping ¿Habría alguna forma de realizar este mapeado en el código? Entiendo que cuando desarrollamos en local sobre distintos NameSpaces, si lo subimos todo a un mismo repositorio para desde ahí desplegar en producción, tendríamos que remapear, ¿cierto? Por otro lado, Francisco nos ha dejado otra posibilidad para trabajar con esto, ¿crees que sería una buena solución? Hola Francisco, Muchas gracias por tu respuesta, realmente es algo muy similar a lo que buscamos, ya que hemos estado trabajando con entornos muy antiguos donde no podíamos llegar a trabajar así. Respecto a los despliegues, ¿como los gestionais? Los despliegues lo gestionamos utilizando la exportación de producción y añadiendo todos los elementos que queremos incluir en la instalación. Para incluir mas cosas en la instalación utilizamos un fichero Installer.class extendiendo de %Projection.AbstractProjection Lo que @Francisco.López1549 te ha presentado con detalle es lo que te decía en la primera respuesta: También podría estar todo junto si no hay solapamiento entre nombres de paquetes y clases. Como ellos ya lo han hecho han elegido la forma que mejor les ha funcionado. Por lo que desde luego es una buena solución. El uso de mapeo de paquetes es util para no tener que duplicar clases (y código) en diferentes Namespaces. Pero es un mecanismo asociado a la operación/despliegue pero no al desarrollo. Son cuestiones diferentes. Puedo desarrollar un paquete de forma común y luego repartirlo entre varios namespaces (como una librería) o puedo ponerlo en un lugar accesible por varios (aka mapeo). Pero lo haga de una manera o de otra no me afecta a como lo desarrollo. Hola Francisco Tu respuesta nos está siendo de mucha ayuda para estructurar nuestro repo, estoy realizando pruebas y me he encontrado con un problema. He creado un workspace similar al que tu has compartido: Sin embargo, y como se ve en la parte inferior de la imagen, el namespace siempre es 'USER'. Dentro de cada carpeta correspondiente al namespace he incluido el archivo setting.json: { "objectscript.conn": { "ns": "NAME" } } ¿Es posible que esté realizando algo mal? Dentro de mi local host existen ambos namespace Entiendo que el setting.config de cada uno de los folders contiene el nombre del namespace a que se quiere desarrollar. Por defecto siempre se carga en namespace "USER", si no puede conectarse con el servidor y no encuentra el namespace indicado se conecta al namespace por defecto. Como comentas, tienes un namespace con ese nombre. Prueba a seleccionar el folder "scr" e intenta crear un fichero (prueba.cls) y ver que te cambia el namespace correcto Así es, en el setting.json tenemos el nombre del namespace correspondiente, pero he realizado la prueba que me dices y no tengo respuesta, sigue sin modificar el namespace sobre el cual se trabaja. EDIT: el archivo es settingS.json, me faltaba esa S, por lo que no estaba cogiendo esa configuración.... Ahora ya parece que funciona Me alegro que haya sido una tontería, si te digo la verdad, ni me había fijado que era settings.json :( Un saludo y happy coding!!!

¡Hola desarrolladores! Os traemos un nuevo vídeo sobre "InterSystems Open Exchange", el marketplace de InterSystems. El vídeo está disponible en el canal de YouTube de la Comunidad de Desarrolladores en inglés. ⏯ Cómo publicar una aplicación en InterSystems Open Exchange En el vídeo, presentado por @Evgeny.Shvarov, aprenderás: ➡️ Cómo publicar una nueva aplicación en Open Exchange ➡️ Cómo hacer una nueva versión ➡️ Cómo cambiar la descripción de la aplicación Así que... ¡dejad que el mundo conozca vuestras soluciones y subid vuestras aplicaciones a Open Exchange, el "marketplace" de InterSystems! Esperamos que os resulte útil 👍🏼

¡Hola Comunidad! Las empresas necesitan crecer y administrar sus infraestructuras informáticas globales de forma rápida y eficiente, al mismo tiempo que optimizan y administran la manera en que invierten y gastan sus fondos. Los servicios de computación y de almacenamiento de Amazon Web Services (AWS) y Elastic Compute Cloud (EC2) satisfacen las necesidades de las aplicaciones más exigentes basadas en InterSystems IRIS, al proporcionar una infraestructura informática global sumamente sólida.La infraestructura de Amazon EC2 permite que las empresas se provean rápidamente de la capacidad de computación y/o aumenten de forma rápida y flexible la infraestructura con la que cuentan en sus instalaciones, dentro de la nube. AWS proporciona un amplio conjunto de servicios y de robustos mecanismos para seguridad, establecimiento de redes, computación y almacenamiento. En el centro de AWS está Amazon EC2. Una infraestructura informática en la nube, que es compatible con una gran variedad de sistemas operativos y configuraciones (por ejemplo, CPU, RAM, red). AWS proporciona imágenes de máquinas virtuales (VM) configuradas previamente, conocidas como Amazon Machine Images, o AMI, con sistemas operativos invitados, incluyendo varias distribuciones y versiones de Linux® y de Windows. Pueden tener programas adicionales, usados como base para las instancias virtuales que se ejecutan en AWS. Puedes utilizar estas AMIs como punto de partida para crear instancias e instalar, o configurar software adicional, datos, etc. con la finalidad de generar otras AMI para aplicaciones o cargas de trabajo específicas. Al igual que con cualquier plataforma o modelo de implementación, es necesario ser cuidadoso, a fin de garantizar que se tengan en cuenta todos los elementos que conforman el entorno de una aplicación, como el rendimiento, la disponibilidad, las operaciones y la administración de los procesos. En este documento se tratarán aspectos específicos de cada una de las siguientes áreas: Instalación y configuración de la red. En esta sección se habla de la configuración de la red para las aplicaciones basadas en InterSystems IRIS dentro de AWS, incluidas las subredes que soportan los grupos de servidores lógicos para las diferentes capas y funciones que están dentro de la arquitectura de referencia. Instalación y configuración del servidor. Esta sección comprende los servicios y recursos que participan en el diseño de los distintos servidores para cada capa. También incluye la arquitectura para una mayor accesibilidad en todas las zonas disponibles. Seguridad. Esta sección trata sobre los mecanismos de seguridad en AWS, incluyendo cómo configurar la seguridad de la instancia y de la red para habilitar las autorizaciones de acceso a las soluciones globales, así como entre las capas e instancias. Implementación y administración. En esta sección se proporcionan detalles sobre empaquetado, implementación, supervisión y administración. Escenarios de arquitectura e implementación En este documento se proporcionan varias arquitecturas de referencia dentro de AWS como ejemplos para proporcionar aplicaciones robustas, de alto rendimiento y disponibilidad, basadas en las tecnologías de InterSystems, incluyendo InterSystems IRIS, HealthShare, TrakCare y tecnologías embebidas asociadas, como DeepSee, iKnow, CSP, Zen y Zen Mojo. Para entender cómo InterSystems IRIS y sus componentes asociados pueden alojarse en AWS, primero revisaremos la arquitectura y los componentes de una implementación típica en InterSystems IRIS, y analizaremos algunos escenarios y topologías frecuentes. Análisis de la arquitectura de InterSystems IRIS La plataforma de datos de InterSystems evoluciona continuamente para proporcionar un sistema avanzado de administración de bases de datos y un entorno de programación de aplicaciones que sea rápido, con la finalidad de lograr avances en el procesamiento y análisis de modelos de datos complejos, así como en el desarrollo de aplicaciones web y para dispositivos móviles. Se trata de una nueva generación de tecnología de bases de datos, que proporciona múltiples formas de acceder a los datos. Los datos solamente se describen una vez en un único diccionario de datos integrado y están disponibles inmediatamente, utilizando el acceso para objetos, un SQL de alto rendimiento y un potente acceso multidimensional - todos ellos pueden acceder simultáneamente a los mismos datos. Los servicios y las capas de componentes de la arquitectura de alto nivel de InterSystems IRIS que están disponibles se muestran en la Figura 1. Estas capas generales también aplican a los productos TrakCare y HealthShare de InterSystems. Figura-1: Capas de los componentes de alto nivel Escenarios más frecuentes para la implementación Existen numerosas combinaciones posibles para la implementación, sin embargo, en este documento se incluirán dos escenarios: un modelo híbrido y un modelo completo de alojamiento en la nube. Modelo híbrido En este escenario, una empresa quiere aprovechar tanto los recursos empresariales que se encuentran en su infraestructura como los recursos de AWS EC2, tanto para la recuperación en caso de desastres, como para las contingencias que surjan durante el mantenimiento interno, las iniciativas de reconfiguración o el aumento de sus capacidades a corto/largo plazo cuando sea necesario. Este modelo puede ofrecer un alto nivel de disponibilidad para la continuidad de negocio y la recuperación en caso de desastres, alojando en EC2 membro(s) de un mirror manteniendo los demás en el centro de datos de la empresa. La conectividad para este modelo, en este escenario, depende de la presencia de un túnel VPN entre la implementación en las instalaciones y la/s zona/s donde AWS está disponible para presentar sus recursos como una extensión del centro de datos de la empresa. Existen otros métodos de conectividad como AWS Direct Connect, que no están incluídos en este documento. Puedes obtener más información sobre AWS Direct Connect aquí. Los detalles para configurar este ejemplo de Amazon Virtual Private Cloud (VPC), para soportar la recuperación en caso de desastres en las instalaciones de su centro de datos, se pueden consultar aquí. Figura-2: Modelo híbrido usando AWS VPC para la recuperación en caso de desastres en las instalaciones físicas En el ejemplo anterior se muestran un par de réplicas en un procedimiento contra fallos, que operan en las instalaciones del centro de datos con una conexión VPN hacia su VPC de AWS. En la imagen del VPC se presentan varias subredes en zonas con doble disponibilidad para una cierta región AWS. Para proporcionar resiliencia, existen dos miembros "mirror" para la Recuperación en caso de desastres asíncrona (uno en cada zona de disponibilidad). Modelo alojado en la nube En este escenario, tu aplicación basada en InterSystems, incluyendo tanto las capas de datos como de presentación se mantiene completamente en la nube de AWS utilizando diversas zonas de disponibilidad dentro de una única región de AWS. También están disponibles el mismo túnel VPN, AWS Direct Connect, e incluso modelos de conectividad a Internet en estado puro. Figura-3: Modelo alojado en la nube que soporta una carga de trabajo a plena producción En el ejemplo anterior, en la Figura 3, se muestra un modelo que soporta una implementación de producción completa de la aplicación en tu VPC. Este modelo aprovecha las dos zonas de disponibilidad mediante la replicación síncrona entre las zonas de disponibilidad, junto con el balanceo de carga en los servidores web y los servidores de aplicaciones que están asociados como clientes ECP. Cada nivel está aislado en un grupo de seguridad separado para los controles de seguridad de la red. Las direcciones IP y los rangos de los puertos solo se abren cuando es necesario, en función de las necesidades de tu aplicación. Almacenamiento y recursos computacionales Almacenamiento Existen varios tipos de opciones de almacenamiento disponibles. Para el propósito de esta arquitectura de referencia se discuten los volúmenes de almacenamiento del Almacén elástico de bloques de Amazon (Amazon EBS) y del Almacén de instancias de Amazon EC2 (también llamadas unidades efímeras) para varios casos posibles de uso. Puedes encontrar información adicional sobre las diferentes opciones de almacenamiento aquí y aquí. Almacenamiento elástico de bloques (EBS) EBS ofrece almacenamiento persistente a nivel de bloques para utilizarlo con las instancias de Amazon EC2 (máquinas virtuales), las cuales pueden formatearse y organizarse como sistemas de archivos tradicionales, tanto en Linux como en Windows y, lo más importante, es que los volúmenes se almacenan fuera de la instancia, por lo que se mantienen independientemente de cuál sea la vida útil de una única instancia en Amazon EC2, y este es un aspecto importante para los sistemas de bases de datos. Además, Amazon EBS oferece la capacidad de crear capturas, de un momento en el tiempo, de los volúmenes, que se mantienen en Amazon S3. Estas capturas se pueden utilizar como punto de partida para nuevos volúmenes en Amazon EBS y para proteger los datos con el fin de que permanezcan a largo plazo. La misma captura puede usarse para crear instancias de tantos volúmenes como se quieran. Estas capturas también se pueden copiar entre las distintas regiones de AWS, haciendo más sencillo aprovechar varias regiones de AWS para expansiones geográficas, migración entre centros de datos y recuperación en caso de desastres. El tamaño de los volúmenes de Amazon EBS varía desde 1 GB hasta 16 TB, y se asignan en incrementos de 1 GB. Amazon EBS cuenta con tres tipos diferentes: Volúmenes magnéticos, de uso general (SSD) y de IOPS provisionadas (SSD). En las siguientes secciones ofrezco una breve descripción de cada uno de ellos. Volúmenes magnéticos Los volúmenes magnéticos ofrecen un almacenamiento rentable para aquellas aplicaciones que tengan requisitos de E/S moderados o por ráfagas. Los volúmenes magnéticos están diseñados para realizar aproximadamente 100 operaciones de entrada/salida por segundo (IOPS) en promedio, con una gran capacidad para alcanzar ráfagas de cientos de IOPS. Los volúmenes magnéticos también están muy bien adaptados para utilizarse como volúmenes de arranque, donde la capacidad de las ráfagas proporciona tiempos de inicio rápidos para las instancias. De uso general (SSD) Los volúmenes de uso general (SSD) ofrecen un almacenamiento rentable que resulta ideal para una gran variedad de cargas de trabajo. Estos volúmenes realizan latencias de milisegundos de un solo dígito, tienen la capacidad de producir ráfagas de hasta 3.000 IOPS durante largos periodos de tiempo y un rendimiento de referencia de 3 IOPS/GB, pero puede alcanzar un máximo de hasta10,000 IOPS (a 3.334 GB). Los volúmenes de uso general (SSD) pueden variar en tamaño desde 1 GB hasta 16 TB. De IOPS provisionadas (SSD) Los volúmenes IOPS provisionados (SSD) están diseñados para ofrecer un alto rendimiento predecible para cargas de trabajo de E/S intensivas, como las cargas de trabajo para bases de datos que son sensibles al rendimiento del almacenamiento y a la consistencia en el rendimiento de acceso aleatorio mediante el E/S. Cuando creas un volumen, especificas una tasa de IOPS y después Amazon EBS lo entrega con un 10 por ciento del rendimiento de IOPS provisionado el 99.9 por ciento del tiempo, durante un año determinado. Un volumen de IOPS provisionado (SSD) puede variar en tamaño desde 4 GB hasta 16 TB, y puedes aprovisionar hasta 20,000 IOPS por volumen. La proporción de IOPS provisionados con respecto al tamaño del volumen solicitado puede ser como máximo de 30. Por ejemplo, un volumen con 3,000 IOPS debe tener al menos 100 GB de tamaño. Los volúmenes de IOPS provisionados (SSD) tienen un rango límite de rendimiento de 256 KB por cada IOPS provisionado, hasta un máximo de 320 MB/segundo (a 1,280 IOPS). Las arquitecturas comentadas en este documento utilizan volúmenes EBS, ya que son los más adecuados para las cargas de trabajo de producción que requieren poca latencia y que además sea predecible en las operaciones de entrada/salida por segundo (IOPs) y en el rendimiento. Cuando se selecciona un tipo de Máquina virtual (VM) en particular, se debe tener cuidado, porque no todos los tipos de instancia EC2 pueden tener acceso al almacenamiento EBS. Nota: Debido a que los volúmenes de Amazon EBS son dispositivos conectados a la red, otra red de E/S desarrollada por una instancia de Amazon EC2, y también la carga total de la red compartida, pueden afectar el rendimiento de los volúmenes individuales de Amazon EBS. Para permitir que tus instancias de Amazon EC2 utilicen completamente los IOPs Provisionados en un volumen de Amazon EBS, puedes ejecutar los tipos de instancias seleccionadas en Amazon EC2 como instancias optimizadas de Amazon EBS. Los detalles sobre los volúmenes de EBS se pueden ver aquí. Almacenamiento de instancias EC2 (unidades efímeras) El almacenamiento de instancias EC2 consiste en bloques de almacenamiento en un disco, el cual se configuró e instaló previamente en el mismo servidor físico que aloja la instancia operativa de Amazon EC2. La cantidad que se proporciona para el almacenamiento en el disco varía según el tipo de instancia en Amazon EC2. En las familias de instancias Amazon EC2 que proporcionan almacenamiento de instancias, las instancias más grandes tienden a proporcionar más volúmenes y una mayor capacidad de almacenamiento. En las familias de Amazon EC2, existen instancias de almacenamiento optimizado (I2) y de almacenamiento intensivo (D2), que proporcionan almacenamiento de instancias que tienen un propósito especial, que están orientadas a casos de uso específicos. Por ejemplo, las instancias I2 brindan almacenamiento muy rápido en discos duros sólidos (SSD), capaces de mantener más de 365,000 IOPS de lectura aleatoria y 315,000 IOPS de escritura, con modelos a precios muy atractivos. A diferencia de los volúmenes EBS, el almacenamiento no es permanente y solo se puede utilizar durante el tiempo de vida útil de la instancia, además no se puede separar o adjuntar a otra instancia. El almacenamiento de instancias está pensado para el almacenamiento temporal de la información que cambia constantemente. En el ámbito de las tecnologías y los productos de InterSystems, el uso de InterSystems IRIS o Health Connect como un Bus de servicios empresariales (ESB), los servidores de aplicaciones que utilizan Enterprise Cache Protocol (ECP), o el uso de servidores web con Web/CSP Gateway son excelentes ejemplos en los que podría utilizarse este tipo de almacenamiento. Además, las instancias que se optimizaron para este tipo de almacenamiento, junto con el uso de las herramientas para el aprovisionamiento y la automatización simplifican su eficacia y son compatibles con su elasticidad. Los detalles sobre los volúmenes de volúmenes de almacenamiento de instancias se pueden ver aquí. Cómputo Instancias EC2 Existen numerosos tipos de instancias disponibles que están optimizadas para utilizarse en diferentes casos. Los tipos de instancia permiten combinaciones variadas de CPU, memoria, almacenamiento y networking, lo que permite formar una infinidad de combinaciones para dimensionar de forma correcta los recursos necesarios para tu aplicación. En este documento, haré referencia a los tipos de instancias M4 de uso general en Amazon EC2 como maneras para ajustar el tamaño de un entorno, ya que estas instancias proporcionan capacidades y optimizaciones del volumen EBS. Las alternativas son posibles en función de los requerimientos de capacidad y el precio de los modelos de tu aplicación. Las instancias M4 son la generación más reciente de las instancias de uso general . Esta familia proporciona un equilibrio entre cómputo, memoria y recursos de red, y es una buena opción para muchas aplicaciones. El rango de sus capacidades varía desde 2 hasta 64 procesadores virtuales y desde 8 hasta 256 GB de memoria, con el correspondiente ancho de banda dedicado a EBS. Además de los tipos de instancias individuales, también existen clasificaciones por niveles como los Host dedicados, las instancias de Spot, las instancias reservadas y las instancias dedicadas, cada una de ellas con diferentes rangos de precio, rendimiento e independencia. Se puede confirmar la disponibilidad y los detalles de las instancias disponibles actualmente aquí. Disponibilidad y Operaciones Balance de carga en servidores web/aplicaciones Puede ser necesario equilibrar la carga en los servidores web externos e internos para tus aplicaciones basadas en InterSystems IRIS. Los balanceadores de carga externos se utilizan para acceder a Internet o a las redes de área extensa (como VPN o Direct Connect) y los balanceadores de carga internos se utilizan potencialmente para el tráfico interno. El balance de carga elástico de AWS ofrece dos tipos de balanceadores: el de carga para aplicaciones y el de carga clásico. Balanceador de carga clásico El balanceador de carga clásico enruta el tráfico basado en la información a nivel de la aplicación o de la red, y es perfecto para balancear las cargas simples de tráfico a lo largo de varias instancias EC2 donde se necesite de una alta disponibilidad, escalado automático y seguridad robusta. Los detalles y las características específicas pueden encontrarse aquí. Balanceador de carga para aplicaciones Un Balanceador de carga para aplicaciones es una opción adicional para el servicio que proporciona el Balanceador de carga elástico, que opera en la capa de la aplicación y permite definir reglas de enrutamiento basadas en el contenido de varios servicios o en los contenedores que se ejecutan en una o más instancias de Amazon EC2. Además, hay soporte para WebSockets y HTTP/2. Los detalles y las características específicas pueden encontrarse aquí. Ejemplo En el siguiente ejemplo, se define un conjunto de tres servidores web con una zona de disponibilidad separada para cada uno, a fin de que proporcionen los niveles más altos de disponibilidad. Los balanceadores de carga del servidor web deben estar configurados con Sesiones sticky para permitir la capacidad de fijar las sesiones del usuario en instancias específicas de EC2 utilizando cookies. El tráfico se enrutará hacia las mismas instancias conforme el usuario continúe accediendo a tu aplicación. En el siguiente diagrama, la Figura 4 muestra un ejemplo simple del Balanceador de Carga Clásico dentro de AWS. Figura 4: Ejemplo de un Balanceador de Carga Clásico Mirroring de la bases de datos Cuando se hace la implementación de InterSystems IRIS con base en las aplicaciones de AWS, proporcionar una alta disponibilidad para el servidor de la plataforma de datos requiere que se haga un mirror sincrónico de la base de datos, con la finalidad de ofrecer una alta disponibilidad en una región principal de AWS dada, y potencialmente, un mirror asincrónico de la base de datos para replicar datos hacia un modo de espera activa (hot standby) en una región secundaria de AWS para la recuperación en caso de desastre, pero esto dependerá de los requisitos del contrato de servicio durante el tiempo de funcionamiento. Un mirror de la base de datos consiste en una agrupación lógica de dos sistemas de base de datos, conocidos como miembros de respuesta ante fallos. Son sistemas físicamente independientes que están conectados solamente por una red. Después de mediar entre los dos sistemas, el mirror designa automáticamente a uno de ellos como el sistema principal, mientras que el otro miembro se convierte automáticamente en el sistema de backup. Las estaciones de trabajo externas de los clientes u otros equipos se conectan a la réplica mediante la IP virtual (VIP) de la réplica, que se especifica durante la configuración. El mirror VIP se une automáticamente a una interfaz en el sistema principal del mirror. Nota: En AWS, no es posible configurar el mirror VIP de la forma tradicional, por lo que se diseñó una solución alternativa. Sin embargo, el mirroring es compatible con todas las subredes. La recomendación actual para implementar un mirror de la base de datos en AWS es configurar tres instancias (la primaria, la de bakcup y la de mediación) en la misma Red virtual privada en la nube (VPC) a través de tres zonas diferentes de disponibilidad. Esto asegura que, en cualquier momento, AWS garantizará la conectividad externa mediante al menos dos de estas máquinas virtuales con un SLA del 99.95%. Esto proporciona la independencia necesaria y la redundancia de los datos en la misma base de datos. Se puede encontrar información detallada sobre los contratos de servicio (SLA) para AWS EC2 aquí. No hay un límite superior estricto para la latencia de la red entre los miembros de respuesta ante fallos. El impacto que tenga aumentar la latencia difiere según la aplicación. Si el tiempo de ida y vuelta entre los miembros de respuesta ante fallos es similar al tiempo de servicio de escritura en el disco, no se espera que haya ningún impacto. Sin embargo, el tiempo de ida y vuelta puede ser una preocupación cuando la aplicación debe esperar a que los datos se vuelvan persistentes (a veces conocido como registro de sincronización). Más detalles sobre el mirroring de la base de datos y la latencia de la red pueden encontrarse aquí. Dirección IP Virtual IP y Sistema automático de respuesta ante fallos La mayoría de los proveedores de IaaS en la nube carecen de la capacidad para proporcionar una dirección IP virtual (VIP), que es la que normalmente se utiliza en los diseños de respuesta ante fallos para las bases de datos. Para solucionar este problema, varios de los métodos de conectividad que se utilizan más frecuentemente, específicamente para los clientes ECP y Web Gateway, han sido mejorados dentro de InterSystems IRIS y HealthShare para que ya no dependan de las capacidades de la VIP, de manera que puedan darse cuenta del mirror. Los métodos de conectividad como xDBC, sockets TCP/IP directos, u otros protocolos de conexión directa, aún requieren el uso de una VIP. Para solucionar estos problemas, la tecnología de mirroring de bases de datos de InterSystems permite ofrecer una respuesta automática ante fallos para esos métodos de conectividad dentro de AWS. Todo esto lo hace posible utilizando las API para interactuar con un Balanceador de carga elástico (ELB) de AWS, con el fin de lograr una funcionalidad que sea similar a la de una VIP, brindando así un diseño completo, robusto y de alta disponibilidad en AWS. Además, AWS introdujo recientemente un nuevo tipo de ELB llamado Balanceador de carga de aplicaciones. Este tipo de balanceador se ejecuta en el Layer 7 y admite el enrutamiento basado en el contenido, además de las aplicaciones que se ejecutan en contenedores. El enrutamiento basado en el contenido es especialmente útil para los proyectos de tipo Big Data que utilizan el particionamiento de los datos o aquellos datos en los que se implementó la técnica de sharding. Al igual que con la IP virtual, este es un cambio abrupto en la configuración de la red y no implica ninguna lógica en las aplicaciones para informar a los clientes que ya existen y están conectados al miembro "mirror" principal que falló, o sea que se produjo un failover. Dependiendo de la naturaleza del fallo, esas conexiones pueden terminar como consecuencia del fallo en sí, debido al tiempo de espera o por error de la aplicación, como resultado de que la nueva instancia principal obliga a la vieja instancia principal a dejar de funcionar, o por el vencimiento del temporizador TCP keep-alive utilizado por el cliente. Como consecuencia, es posible que los usuarios tengan que volver a conectarse e iniciar sesión. El funcionamiento que tenga tu aplicación es el que determinaría este comportamiento. Los detalles acerca de los diferentes tipos de ELB que están disponibles pueden encontrarse aquí. Llamada de la instancia en AWS EC2 para el método del balanceador de carga elástico de AWS En este modelo, el ELB puede tener un grupo de servidores definido ya sea por miembros mirror que participan en un procedimiento contra fallos, como por miembro(s) mirror asíncronos que se utilizan potencialmente durante la Recuperación en caso de desastres (DR) con solo una de las entradas activas, que es el miembro principal actual, o solo un grupo de servidores con una única entrada para el miembro mirror activo. Figura 5: Método de la API para interactuar con el Balanceador de Carga Elástico (interno) Cuando un miembro mirror se convierte en el miembro mirror principal, se emite una llamada de la API desde su instancia de EC2 hacia el AWS ELB para ajustar/dar instrucciones al ELB del nuevo miembro mirror principal. Figura 6: Respuesta ante fallos de un Miembro B usando una API con el Balanceador de Carga Este mismo modelo se aplica a la promoción de un miembro (asincrónico) de recuperación en caso de desastres (DR) en caso de que no estén disponibles tanto el miembro mirror principal como el de backup. Figura-7: Promoción del miembro DR Asincrónico (DR) a miembro primário mediante API del Balanceador Según el procedimiento estándar de DR recomendado, en la Figura 6 anterior, la promoción del miembro de DR implica una decisión humana debido a la posibilidad de pérdida de datos por la replicación asincrónica. Sin embargo, una vez que se toma esa acción, no se requiere ninguna acción administrativa en el ELB. Enruta automáticamente el tráfico una vez que se llama a la API durante la promoción. Detalles de la API Esta API para llamar al recurso del balanceador de carga de AWS se define en la rutina ^ ZMIRROR específicamente como parte de la llamada al procedimiento: $$CheckBecomePrimaryOK^ZMIRROR() Dentro de este procedimiento, inserte cualquier lógica de API o métodos que elija usar desde la API REST de AWS ELB, la interfaz de línea de comandos, etc. Una forma efectiva y segura de interactuar con ELB es usar roles de AWS Identity and Access Management (IAM) para que pueda no tiene que distribuir credenciales a largo plazo a una instancia EC2. El rol de IAM proporciona permisos temporales que InterSystems IRIS puede usar para interactuar con AWS ELB. Los detalles para usar las funciones de IAM asignadas a sus instancias EC2 se pueden encontrar aquí. Método de sondeo de AWS Elastic Load BalancerUn método de sondeo que utiliza la página mirror_status.cxw de Web Gateway se puede utilizar como método de sondeo en el monitor de estado de ELB para cada miembro agregado al grupo de servidores de ELB. Solo el miembro primario responderá "Éxito", dirigiendo así el tráfico de red solo al miembro primario activo. Este método no requiere que se agregue ninguna lógica a ^ ZMIRROR. Hay que tener en cuenta que la mayoría de los dispositivos de red de balanceo de carga tienen un límite en la frecuencia de ejecución de la verificación de estado. Normalmente, la frecuencia más alta no es inferior a 5 segundos, lo que suele ser aceptable para admitir la mayoría de los acuerdos de nivel de servicio de tiempo de actividad. Una solicitud HTTP para el siguiente recurso probará el estado de miembro mirror de la configuración LOCAL de InterSystems IRIS. /csp/bin/mirror_status.cxw Para todos los demás casos, la ruta a estas solicitudes de estado Mirror debe resolverse en el servidor y NameSpace apropiados utilizando el mismo mecanismo jerárquico que se utiliza para solicitar páginas CSP reales. Ejemplo: para probar el estado del Mirror de las aplicaciones de servicio de configuración en la ruta /csp/user/: /csp/user/mirror_status.cxw Nota: No se consumen licencias CSP al invocar la revisión del Mirror Status. Dependiendo de si la instancia de destino es el miembro principal activo o no, el Gateway devolverá una de las siguientes respuestas de CSP: ** Éxito (Miembro Primário) =============================== HTTP/1.1 200 OK Content-Type: text/plain Connection: close Content-Length: 7 SUCCESS ** Fallo (No es el Miembro Primário) =============================== HTTP/1.1 503 Service Unavailable Content-Type: text/plain Connection: close Content-Length: 6 FAILED ** Fallo (El servidor no soporta la petición Mirror_Status.cxw) =============================== HTTP/1.1 500 Internal Server Error Content-Type: text/plain Connection: close Content-Length: 6 FAILED Las siguientes figuras ilustran los distintos escenarios de uso del método de sondeo. Figura-8: Sondeo a todos los miembros del mirror Como muestra la Figura 8 anterior, todos los miembros están operativos y solo el miembro principal está devolviendo "Éxito" al balanceador de carga, por lo que el tráfico de red se dirigirá solo a este miembro. Figura-9: Failover al Miembro B por medio del sondeo El siguiente diagrama demuestra la promoción de miembros asíncronos de recuperación ante desastres en el grupo con balanceo de carga, esto normalmente supone que el mismo dispositivo de red con balanceo de carga está dando servicio a todos los miembros (los escenarios divididos geográficamente se tratan más adelante en este artículo). Según el procedimiento estándar de DR recomendado, la promoción del miembro de DR implica una decisión humana debido a la posibilidad de pérdida de datos por a la replicación asincrónica. Sin embargo, una vez que se toma esa acción, no se requiere ninguna acción administrativa en el ELB. Descubre automáticamente el nuevo primario. Figura-10: Failover y Promoción del DR Asincrónico mediante sondeo Backup y Restore Hay varias opciones disponibles para las operaciones de backup. Las siguientes tres opciones son viables para su implementación de AWS con productos InterSystems. Las dos primeras opciones incorporan un procedimiento de tipo snapshot que implica suspender las escrituras de la base de datos en el disco antes de la creación del snapshot y luego reanudar las actualizaciones una vez que se haya realizado correctamente. Se toman los siguientes pasos de alto nivel para crear una copia de seguridad limpia utilizando cualquiera de los métodos de snapshot: Pausar las escrituras en la base de datos mediante la llamada a la API Freeze de la base de datos. Cree snapshots del sistema operativo + discos de datos. Reanudar las escrituras a través de la llamada API de la base de datos. Copia del backup a la ubicación de la copia de seguridad Se pueden agregar pasos adicionales, como verificaciones de integridad, en un intervalo periódico para garantizar una copia de seguridad limpia y consistente. Los puntos de decisión sobre qué opción utilizar dependen de los requisitos operativos y las políticas de su organización. InterSystems está disponible para discutir las diversas opciones con más detalle. EBS Snapshots Los snapshots de EBS son formas muy rápidas y eficientes de crear una imagen en un momento determinado en un almacenamiento de Amazon S3 de alta disponibilidad y menor costo. Los snapshots de EBS junto con las capacidades de API de congelación y descongelación externas de InterSystems permiten una verdadera resistencia operativa 24x7 y la garantía de copias de seguridad regulares limpias. Existen numerosas opciones para automatizar el proceso utilizando los servicios proporcionados por AWS, como Amazon CloudWatch Events o soluciones de terceros disponibles en el mercado, como Cloud Ranger o N2W Software Cloud Protection Manager, por nombrar algunos. Además, puede crear mediante programación su propia solución de copia de seguridad personalizada mediante el uso de llamadas API directas de AWS. Los detalles sobre cómo aprovechar las API están disponibles aquí y aquí. Nota: InterSystems no respalda ni valida explícitamente ninguno de estos productos de terceros. Las pruebas y la validación dependen del cliente. Logical Volume Manager Snapshots Alternativamente, muchas de las herramientas de copia de seguridad de terceros disponibles en el mercado pueden utilizarse mediante la implementación de agentes de copia de seguridad individuales dentro de la propia máquina virtual y aprovechando las copias de seguridad a nivel de archivo junto con las instantáneas de Linux Logical Volume Manager (LVM) o el Servicio de Snapshots de Volumen de Windows (VSS). Uno de los principales beneficios de este modelo es la capacidad de tener restauraciones a nivel de archivo de instancias basadas en Linux y Windows. Un par de puntos a tener en cuenta con esta solución; Dado que AWS y la mayoría de los demás proveedores de nube de IaaS no proporcionan medios de cinta, todos los repositorios de respaldo están basados ​​en disco para el archivado a corto plazo y tienen la capacidad de aprovechar el almacenamiento de bajo costo de Amazon S3 y, finalmente, Amazon Glacier para la retención a largo plazo (LTR). Si utiliza este método, se recomienda encarecidamente utilizar un producto de respaldo que admita tecnologías de deduplicación para hacer el uso más eficiente de los repositorios de respaldo basados ​​en disco. Algunos ejemplos de estos productos de respaldo con soporte en la nube incluyen, entre otros: Commvault, EMC Networker, HPE Data Protector y Veritas Netbackup. Nota: InterSystems no respalda ni valida explícitamente ninguno de estos productos de terceros. Las pruebas y la validación dependen del cliente Copia de Seguridad en Línea Para implementaciones pequeñas, la función integrada de backup en línea también es una opción viable. La utilidad de backup en línea de la base de datos de InterSystems respalda los datos en los archivos de la base de datos capturando todos los bloques en las bases de datos y luego escribe la salida en un archivo secuencial. Este mecanismo de backup patentado está diseñado para no causar tiempo de inactividad a los usuarios del sistema de producción. En AWS, una vez finalizada la copia de seguridad en línea, el archivo de salida de la copia de seguridad y todos los demás archivos en uso por el sistema deben copiarse en un EC2 que actúa como un recurso compartido de archivos (CIFS/NFS). Este proceso debe programarse y ejecutarse dentro de la máquina virtual. La copia de seguridad en línea es el enfoque de nivel de entrada para los sitios más pequeños que desean implementar una solución de bajo costo para la copia de seguridad. Sin embargo, a medida que las bases de datos aumentan de tamaño, las copias de seguridad externas con tecnología de instantáneas se recomiendan como una mejor práctica con ventajas que incluyen la copia de seguridad de archivos externos, tiempos de restauración más rápidos y una vista de los datos y herramientas de administración de toda la empresa. Recuperación ante Desastres (DR) Al implementar una aplicación basada en InterSystems IRIS en AWS, se recomienda que los recursos de recuperación ante desastres, incluida la red, los servidores y el almacenamiento, estén en una región de AWS diferente o en zonas de disponibilidad separadas como mínimo. La capacidad requerida en la región DR AWS designada depende de las necesidades de su organización. En la mayoría de los casos, se requiere el 100% de la capacidad de producción cuando se opera en modo DR; sin embargo, se puede aprovisionar menor capacidad hasta que se necesite más como modelo elástico. La menor capacidad puede presentarse en forma de menos servidores web y de aplicaciones y, potencialmente, incluso se puede utilizar un tipo de instancia EC2 más pequeño para el servidor de base de datos y, tras la promoción, los volúmenes de EBS se adjuntan a un tipo de instancia EC2 grande. La duplicación de bases de datos asincrónica se utiliza para replicar continuamente en las instancias EC2 de la región DR AWS. La duplicación utiliza journals de transacciones de la base de datos para replicar las actualizaciones a través de una red TCP / IP de una manera que tiene un impacto mínimo en el rendimiento del sistema principal. Se recomienda encarecidamente configurar la compresión y el cifrado de archivos de journals con estos miembros asíncronos de DR. Todos los clientes externos en la Internet pública que deseen acceder a la aplicación serán enrutados a través de Amazon Route53 como un servicio DNS adicional. Amazon Route53 se utiliza como conmutador para dirigir el tráfico al centro de datos activo actual. Amazon Route53 realiza tres funciones principales: Registro de dominio: Amazon Route53 le permite registrar nombres de dominio como example.com. Servicio de sistema de nombres de dominio (DNS): Amazon Route53 traduce nombres de dominios sencillos como www.example.com en direcciones IP como 192.0.2.1. Amazon Route53 responde a las consultas de DNS mediante una red global de servidores DNS autorizados, lo que reduce la latencia. Verificación de estado: Amazon Route53 envía solicitudes automatizadas a través de Internet a su aplicación para verificar que sea accesible, disponible y funcional. Los detalles de estas funciones se pueden encontrar aquí. A los efectos de este documento, se analizarán la conmutación por error de DNS y la verificación del estado de Route53. Los detalles de la supervisión de Health Check y la conmutación por error de DNS se pueden encontrar aquí y aquí. Route53 funciona realizando solicitudes regulares a extremo y luego verificando la respuesta. Si un extremo no proporciona una respuesta válida, ya no se incluye en las respuestas de DNS, que en su lugar devolverá un extremo alternativo disponible. De esta manera, el tráfico de usuarios se dirige lejos de los extremos que fallan y hacia los extremos que están disponibles. Usando los métodos anteriores, el tráfico solo se permitirá a una región específica y un miembro específico. Esto está controlado por la definición de extremo, que es una página mirror_status.cxw discutida anteriormente en este artículo presentado desde InterSystems Web Gateway. Solo el miembro principal informará "Éxito" como HTTP 200 de la verificación de estado. El siguiente diagrama muestra a alto nivel la política de enrutamiento de conmutación por error. Los detalles de este método y otros se pueden encontrar aquí. Figura-11: Política de Rutina de Conmutación por Error de Amazon Route53 En un momento dado, solo una de las regiones informará el monitoreo del extremo en tiempo real. Esto asegura que el tráfico solo fluya a una región en un momento dado. No se necesitan pasos adicionales para la conmutación por error entre las regiones, ya que la supervisión del punto de conexión detectará que la aplicación en la región de AWS primaria designada está inactiva y la aplicación ahora está activa en la región de AWS secundaria. Esto se debe a que el miembro asíncrono de DR se ha promovido manualmente a primario, lo que permite que Web Gateway informe de HTTP 200 a la supervisión del extremo de Elastic Load Balancer. Existen muchas alternativas a la solución descrita anteriormente y se pueden personalizar según los requisitos operativos de su organización y los acuerdos de nivel de servicio. Monitorización Amazon CloudWatch está disponible para brindar servicios de monitoreo para todos sus recursos en la nube de AWS y sus aplicaciones. Amazon CloudWatch se puede utilizar para recopilar y rastrear métricas, recopilar y monitorear archivos de registro, configurar alarmas y reaccionar automáticamente a los cambios en los recursos de AWS. Amazon CloudWatch puede monitorear recursos de AWS como Amazon EC2 Instancias, así como métricas personalizadas generadas por sus aplicaciones y servicios, y cualquier archivo de registro que generen sus aplicaciones. Puede utilizar Amazon CloudWatch para obtener visibilidad de todo el sistema sobre la utilización de recursos, el rendimiento de las aplicaciones y el estado operativo. Detalles pueden ser encontrados aqui. Aprovisionamiento automatizado Actualmente, existen numerosas herramientas disponibles en el mercado, incluidas Terraform, Cloud Forms, Open Stack y CloudFormation de Amazon. El uso de estos y el acoplamiento con otras herramientas como Chef, Puppet, Ansible y otros pueden proporcionar DevOps completo de soporte de infraestructura como código o simplemente iniciar su aplicación de una manera completamente automatizada. Los detalles de Amazon CloudFormation se pueden encontrar aquí. Conectividad de Red Según los requisitos de conectividad de la aplicación, hay varios modelos de conectividad disponibles mediante Internet, VPN o un enlace dedicado mediante Amazon Direct Connect. El método a elegir dependerá de la aplicación y las necesidades del usuario. El uso de ancho de banda para cada uno de los tres métodos varía, y es mejor consultar con su representante de AWS o con la Consola de administración de Amazon para confirmar las opciones de conectividad disponibles para una región determinada. Seguridad Se debe tener cuidado al decidir implementar una aplicación en cualquier proveedor público de nube IaaS. Se deben seguir las políticas de seguridad estándar de tu organización, o las nuevas desarrolladas específicamente para la nube. También deberá comprender la soberanía de los datos, que es relevante cuando los datos de una organización se almacenan fuera de su país y están sujetos a las leyes del país en el que residen los datos. Las implementaciones en la nube tienen el riesgo adicional de que los datos estén ahora fuera de los centros de datos de los clientes y del control de seguridad física. Se recomienda encarecidamente uso de cifras. Tanto para la base de datos y journals para datos en reposo como para los datos en tránsito (comunicaciones de red) mediante cifrado AES y SSL/TLS respectivamente. Al igual que con toda la administración de claves de cifrado, los procedimientos adecuados deben documentarse y seguirse de acuerdo con las políticas de tu organización para garantizar la seguridad de los datos y evitar el acceso no deseado a los datos o las violaciones de seguridad. Amazon proporciona una amplia documentación y ejemplos para proporcionar un entorno operativo altamente seguro para sus aplicaciones basadas en tecnologia InterSystems. Asegúrese de revisar Identity Access Management (IAM) para conocer los diversos temas de discusión que se encuentran aquí. Ejemplos de Diagramas de Arquitectura El diagrama siguiente ilustra una instalación típica de produtos InterSystems que proporcionan alta disponibilidad en forma de duplicación de base de datos (tanto conmutación por error síncrona - failover - como DR asincrónica), servidores de aplicaciones que utilizan ECP y varios servidores web con equilibrio de carga. Ejemplo de TrakCare El siguiente diagrama ilustra una implementación típica de TrakCare con varios servidores web con balanceo de carga, dos servidores de impresión como clientes ECP y una configuración de mirror de base de datos. La dirección IP virtual solo se usa para la conectividad no asociada con ECP o Web Gateway. Los clientes de ECP y Web Gateway son compatibles con el mirror y no requieren una VIP. Si está utilizando Direct Connect, hay varias opciones que incluyen múltiples circuitos y acceso a múltiples regiones que se pueden habilitar para escenarios de recuperación de desastres. Es importante trabajar con los proveedores de telecomunicaciones para comprender los escenarios de alta disponibilidad y recuperación ante desastres que admiten. El siguiente diagrama de arquitectura de referencia de muestra incluye alta disponibilidad en la región activa o primaria y recuperación ante desastres en otra región de AWS si la región primaria de AWS no está disponible. También dentro de este ejemplo, los miembros del mirror de la base de datos contienen los namespaces de TrakCare DB, TrakCare Analytics e Integration, todo dentro de ese único mirror. Figura-12: TrakCare AWS Diagrama de Arquitectura de Referencia – Arquitectura Física Además, se proporciona el siguiente diagrama que muestra una vista más lógica de la arquitectura con los productos de software de alto nivel asociados instalados y su propósito funcional. Figura-13: TrakCare Diagrama de Arquitectura de Referencia – Arquitectura Lógica Ejemplo de HealthShare El siguiente diagrama ilustra una implementación típica de HealthShare con varios servidores web con balanceo de carga, con varios productos de HealthShare incluidos: Information Exchange, Patient Index, Personal Community, Health Insight y Health Connect. Cada uno de esos productos respectivos incluye un par de réplicas de bases de datos para alta disponibilidad dentro de múltiples zonas de disponibilidad. La dirección IP virtual solo se usa para la conectividad no asociada con ECP o Web Gateway. Las puertas de enlace Web utilizadas para las comunicaciones de servicios web entre los productos HealthShare son compatibles con el mirror y no requieren un VIP. El siguiente diagrama de arquitectura de referencia de muestra incluye alta disponibilidad en la región activa o primaria, y recuperación ante desastres en otra región de AWS si la región principal no está disponible. Figura-14: HealthShare AWS Diagrama de Arquitectura de Referencia – Arquitectura Física Además, se proporciona el siguiente diagrama que muestra una vista más lógica de la arquitectura con los productos de software de alto nivel asociados instalados, los requisitos y métodos de conectividad y el propósito funcional respectivo. Figura-15: HealthShare AWS Diagrama de Arquitectura de Referencia – Arquitectura Lógica

Introducción: nuestra pequeña pero muy ambiciosa empresa llamada “Black Mushroom Studio” tuvo una idea para desarrollar un proyecto de comercio electrónico, y una aplicación móvil que permitiría a los usuarios pagar por ciertos bienes/servicios mediante un agregador de pagos. Lo que teníamos inicialmente: un esqueleto para la aplicación en Android que, por supuesto, prefería la comunicación mediante HTTP y JSON, y un sistema de pago con una API, es decir, servicios web con contenido SOAP. Objetivo: hacer que todo funcionara de manera conjunta. Los siguientes factores influyeron para elegir la tecnología del stack: la velocidad de desarrollo y la capacidad para reaccionar rápidamente ante los cambios. Se suponía que el producto tendría un éxito inmediato. Mientras los competidores seguían haciendo estimaciones, nosotros queríamos lanzar el producto. Mientras nuestros competidores buscaban a los desarrolladores adecuados, se suponía que nosotros estaríamos contando nuestras primeras ganancias. Con este factor restrictivo en curso, todavía necesitábamos una estrategia formal para trabajar, pues todo giraba en torno al dinero de los inversores y eso es algo que requiere una atención especial. Podríamos pasar mucho tiempo hablando de las ventajas y las desventajas de ciertas tecnologías de proveedores específicos y de los beneficios que aportan los productos de código abierto. Después de analizar varios productos (este tema por sí mismo merece que redactemos otro artículo), concluimos que InterSystems Ensemble era la mejor opción para satisfacer nuestras necesidades. Solo uno de nuestros desarrolladores tenía experiencia desarrollando con Caché ObjectScript, pero nadie sabía cómo utilizar Ensemble. Sin embargo, logramos implementar la compleja lógica empresarial de nuestro producto con Ensemble en solo un par de semanas. Qué fue lo que nos ayudó: 1. Ensemble es un producto completo, que combina un Sistema de gestión de bases de datos (DBMS), un servidor para aplicaciones, un bus de servicios empresariales, un sistema para la gestión de procesos empresariales (BMP) y una tecnología para el desarrollo de aplicaciones analíticas con Inteligencia empresarial (BI). No es necesario conocer varias soluciones e integrarlas 2. Un modelo de almacenamiento basado en objetos. Si queremos guardar un objeto en una base de datos, simplemente lo guardamos en una base de datos 3. Un método muy sencillo de integración con sistemas externos/internos basado en diversos protocolos, gracias a que cuenta con una biblioteca de adaptadores que puede ampliarse Una solución de primer nivel Un cliente envía una solicitud con contenido JSON a través del protocolo HTTP hacia un puerto del servidor. Este puerto recibe la información mediante la “caja negra” de Ensemble. El cliente recibe una respuesta sincronizada cuando finaliza el proceso. ¿Qué hay en su interior? Entre los beneficios de utilizar Ensemble se encuentra la implementación de una producción (una solución de integración en Ensemble) que consiste en tres partes: los servicios empresariales, los procesos empresariales y las operaciones empresariales (de ahora en adelante, utilizaré estos términos sin el sufijo “empresarial” para facilitar la lectura). Un servicio en Ensemble es un componente que permite recibir solicitudes mediante diversos protocolos; un proceso es la lógica de las aplicaciones; y una operación es un componente que permite enviar solicitudes salientes hacia sistemas externos. Toda la interacción dentro de Ensemble se basa en filas de mensajes. Un mensaje es el objeto de una clase que se heredó desde Ens.Message, la cual permite utilizar y transmitir datos desde una parte de la producción hacia otra. En nuestro caso, el servicio utiliza un adaptador HTTP que se heredó desde EnsLib.HTTP.InboundAdapter, el cual recibe una solicitud enviada por un cliente, la convierte en un “mensaje” y la envía hacia el proceso. El proceso empresarial responde con un “mensaje” que contiene los resultados del proceso y los convierte en una respuesta para el cliente. Así es como se ve en nuestra solución: Method OnProcessInput(pInput As %Library.AbstractStream, Output pOutput As %Stream.Object) As %Status { Set jsonstr = pInput.Read() // Convirtámoslo en un mensaje Set st = ##class(%ZEN.Auxiliary.jsonProvider).%ConvertJSONToObject(jsonstr,"invoices.Msg.Message",.tApplication) Throw:$$$ISERR(st) ##class(%Exception.StatusException).CreateFromStatus(st) // Algo de lógica para el llenado de mensajes con los datos, // característica de nuestras consultas // Instanciamos un proceso de negocio Set outApp=##class(invoices.Msg.Resp).%New() Set st =..SendRequestSync("Processing",tApplication,.outApp) Quit:$$$ISERR(st) st // Convertimos la respuesta a JSON Set json="" Do ##class(invoices.Utils).ObjectToJSON(outApp,,,"aeloqu",.json) // Ponemos el JSON en la respuesta Set pOutput=##class(%GlobalBinaryStream).%New() Do pOutput.SetAttribute("Content-Type","application/json") Do pOutput.Write(json) Quit st } Un proceso empresarial es una implementación de la lógica empresarial de nuestra aplicación. Contiene una secuencia con las acciones que deben realizarse para enviar una respuesta al cliente. Por ejemplo: guardar/actualizar los datos del cliente, añadir un nuevo servicio que pueda rastrearse, solicitar el estado de un servicio, pagar por un servicio. Sin una plataforma integrada, tendríamos que escribir una gran cantidad de código. Qué necesitamos realizar en Ensemble: construir un proceso empresarial en un editor gráfico a partir de diferentes elementos. Los procesos empresariales se describen en el Lenguaje del Proceso Empresarial (BPL, por sus siglas en inglés). Los elementos incluyen asignaciones simples (y no tan simples), conversión de datos, llamadas al código, procesos síncronos y asíncronos y llamadas a las operaciones (hablaremos de esto más adelante). La conversión de datos también es muy conveniente y es compatible con el mapeo de datos sin la necesidad de escribir líneas de código: Como resultado, obtuvimos lo siguiente en lugar de un montón de código en cierto momento: Ahora os comento algunas cosas sobre las operaciones. Esta entidad nos permite enviar una solicitud hacia un sistema externo mediante algún protocolo. Cómo lo hicimos: utilizamos una extensión incorporada en studio para importar el WSDL proporcionado por el sistema de pago desde el WSDL de Caché Studio: Especificamos la ubicación del WSDL: Durante la importación, marcamos la casilla “Create an operation”: Como resultado, obtuvimos un código que ya está listo para realizar solicitudes y procesar las respuestas desde nuestro sistema de pago. Vamos a configurar una operación en el portal y especificaremos su clase: Ahora instalaremos la configuración SSL (debe crearse previamente mediante el Portal de Administración del Sistema desde la ruta: Administración - Seguridad- Configuraciones SSL/TLS): ¡Hecho! Lo único que debemos hacer ahora es llamar a la operación desde un proceso empresarial. En nuestro caso, tenemos dos de estas operaciones: la parte de la información y la parte correspondiente al pago. Al final, no tuvimos que escribir ni una sola línea de código para interactuar con el sistema de pago. Listo, se completó la integración. Sin embargo, también existe un proceso distinto que se utiliza para enviar notificaciones PUSH mediante las herramientas incorporadas en Ensemble, un proceso diferente para obtener registros SFTP desde el sistema de pago para generar recibos, y otro un proceso para generar recibos PDF, pero todos ellos merecen la redacción de otro artículo. Como resultado, solo dedicamos un par de semanas para la implementación de todo esto (incluido el tiempo necesario para familiarizarnos con la nueva tecnología). Por supuesto, este producto de InterSystems no es perfecto (nada es perfecto). Cuando trabajamos en nuestras implementaciones, nos enfrentamos a muchas dificultades, y la falta de documentación de apoyo para Ensemble no nos ayudó en absoluto. Sin embargo, en nuestro caso, la tecnología demostró ser eficiente y funcionó bastante bien para nuestros objetivos. Me gustaría felicitar a la empresa por apoyar a los desarrolladores jóvenes y ambiciosos, y por su buena disposición para ayudarnos. Definitivamente planeamos lanzar nuevos productos basados en esta tecnología. Ya lanzamos una aplicación con esta tecnología y la versión web está en preparación.

Los sistemas de bases de datos tienen requisitos muy específicos para las copias de seguridad ("backups") que, en entornos empresariales, necesitan una previsión y planificación. En el caso de los sistemas de bases de datos, el objetivo de una copia de seguridad es crear una copia de los datos en un estado equivalente a cuando la aplicación se apaga de forma correcta. Las copias de seguridad consistentes con las aplicaciones cumplen estos requisitos, y Caché ofrece un conjunto de APIs que facilitan la integración con soluciones externas para lograr este nivel de consistencia en las copias de seguridad. Estas APIs son ExternalFreeze y ExternalThaw. ExternalFreeze detiene de forma temporal la escritura en el disco y durante este periodo Caché almacena los cambios en la memoria. Durante este periodo, debe completarse la operación de backup y debe ir seguida por una llamada a ExternalThaw. Esta llamada involucra a los demonios de escritura para que escriban el caché actualizado en el grupo de búfer de los globals (base de datos de Caché) en el disco y reanuda las operaciones normales del demonio de escritura de la base de datos de Caché. Este proceso es transparente para los procesos del usuario con Caché. Los métodos específicos para las clases de las API son: ##Class(Backup.General).ExternalFreeze() ##Class(Backup.General).ExternalThaw() Estas API, junto con la nueva funcionalidad de Azure Backup de ejecutar un script antes y después de la ejecución de una operación snapshot, ofrecen una completa solución de backup para implementaciones de Caché en Azure. La funcionalidad de pre/post scripting de Azure Backup solo está disponible en las máquinas virtuales de Linux. Requisitos previos En el nivel más alto, hay que realizar tres pasos antes de que puedas hacer una copia de seguridad de una máquina virtual mediante Azure Backup: Crear un almacén de Servicios de Recuperación Instalar la última versión del agente de la máquina virtual. Verifique el acceso de red a los servicios de Azure desde su máquina virtual. El almacén ("vault") de servicios de recuperación gestiona los objetivos, políticas y elementos de la copia de seguridad que se deben proteger. Puedes crear un almacén de servicios de recuperación a través del Portal Azure o mediante los scripts que se utilizan en PowerShell. Azure Backup requiere de una extensión que se ejecuta en tu máquina virtual, se controla por el agente de máquina virtual de Linux, y también se necesita la última versión del agente. La extensión interactúa con puntos de conexión externos HTTPS endpoints de Azure Storage y del almacén de Servicios de Recuperación. El acceso seguro a esos servicios desde la máquina virtual se puede configurar mediante un proxy y las normas que rigen la red en un grupo de seguridad en la red de Azure. Para obtener más información sobre estos pasos, ve a: Prepara tu entorno para hacer una copia de seguridad de las máquinas virtuales implementadas por el Administrador de Recursos. Configuración previa y posterior a la creación de scripts En la última versión de la extensión de Azure Backup (Microsoft.Azure.RecoveryServices.VMSnapshotLinux) se incluye la capacidad de llamar a un script antes y después de la operación de backup. Para más información sobre cómo instalar la extensión, consulte la documentación. De forma predeterminada, la extensión incluye, de prueba, scripts previos y posteriores, que se ubican en tu máquina virtual de Linux en: /var/lib/waagent/Microsoft.Azure.RecoveryServices.VMSnapshotLinux-1.0.9110.0/main/tempPlugin Y debe copiarse en las siguientes ubicaciones respectivamente. /etc/azure/prescript.sh /etc/azure/postScript.sh También se puede descargar la plantilla del script desde GitHub. Para Caché, el postScript.sh y el script prescript.sh en el que se puede implementar una llamada a la API de ExternalFreeze deben contener la implementación que ejecuta ExternalThaw. La siguiente es una implementación de muestra de *prescript.sh* para Caché. #!/bin/bash # variables used for returning the status of the script success=0 error=1 warning=2 status=$success log_path="/etc/preScript.log" #path of log file printf "Logs:\n" > $log_path # TODO: Replace <CACHE INSTANCE> with the name of the running instance csession <CACHE INSTANCE> -U%SYS "##Class(Backup.General).ExternalFreeze()" >> $log_path status=$? if [ $status -eq 5 ]; then echo "SYSTEM IS FROZEN" printf "SYSTEM IS FROZEN\n" >> $log_path elif [ $status -eq 3 ]; then echo "SYSTEM FREEZE FAILED" printf "SYSTEM FREEZE FAILED\n" >> $log_path status=$error csession <CACHE INSTANCE> -U%SYS "##Class(Backup.General).ExternalThaw()" fi exit $status La siguiente es una implementación de muestra de *postScript.sh* para Caché. #!/bin/bash # variables used for returning the status of the script success=0 error=1 warning=2 status=$success log_path="/etc/postScript.log" #path of log file printf "Logs:\n" > $log_path # TODO: Replace <CACHE INSTANCE> with the name of the running instance csession <CACHE INSTANCE> -U%SYS "##class(Backup.General).ExternalThaw()" status=$? if [ $status req 5]; then echo "SYSTEM IS UNFROZEN" printf "SYSTEM IS UNFROZEN\n" >> $log_path elif [ $status -eq 3 ]; then echo "SYSTEM UNFREEZE FAILED" printf "SYSTEM UNFREEZE FAILED\n" >> $log_path status=$error fi exit $status Cómo ejecutar una copia de seguridad En el Portal Azure se puede activar la primera copia de seguridad cuando navega hacia el Servicio de Recuperación. Piensa que el tiempo necesario para consolidar snapshots de máquina virtual debería ser de unos pocos segundos, independientemente de la primera copia de seguridad o de las posteriores. La transferencia de datos de la primera copia de seguridad tardará más tiempo, pero la transferencia de datos comenzará después de ejecutar la edición posterior del script para llamar la base de datos de Thaw y no debería tener ningún impacto en el tiempo entre la edición previa & la posterior del script. Es muy recomendable que restaures frecuentemente tu copia de seguridad en un entorno que no esté en producción y realices revisiones sobre la integridad de la base de datos, para asegurar que tus operaciones de protección de datos son eficaces. Para tener más información sobre cómo activar la copia de seguridad y otros temas como programar la copia de seguridad, puedes consultar Cómo realizar un backup de las máquinas virtuales de Azure en una Bóveda de servicios de recuperación.

¡Hola Comunidad! La Convención Anual de InterSystems (Global Summit) será virtual este año y estará abierta a todo el mundo (previa inscripción). El evento pasa a llamarse "Virtual Summit 2020" y se celebrará durante tres semanas! entre finales de octubre y principios de noviembre. Regístrate aquí para recibir todas las novedades >> El tema general de la Convención virtual es Interacción & Información, porque la interacción entre profesionales y la información técnica han sido siempre los mayores beneficios de asistir al Global Summit anual de InterSystems. Este año no podemos vernos en persona, pero vamos a hacer todos los esfuerzos necesarios para transmitir esos beneficios virtualmente. Estamos en un nuevo escenario mundial, pero si esta pandemia nos ha enseñado algo es adaptabilidad. Y casualmente ese es el tema de las primeras conferencias del Virtual Summit - "Cómo crear una organización flexible". Ponentes provenientes de empresas flexibles compartirán sus mejores prácticas, líderes de opinión nos explicarán hacia donde nos dirigimos y varios directivos de InterSystems mostrarán lo que la compañía tiene preparado para los próximos meses. Además, habrá sesiones técnicas ("Focus sessions"), sobre mejores prácticas, nuevas tecnologías y hojas de ruta de todos nuestros productos. (La mayoría de estas sesiones se celebrarán más de una vez, para adaptarnos a los diferentes husos horarios). Como otros años, ofreceremos a los asistentes encuentros virtuales privados ("Ask the Experts") con jefes de producto y con miembros de los equipos de formación, desarrollo de producto y soporte de InterSystems. Por último, tendremos aulas prácticas ( "Experience Labs") con soporte virtual y hasta cuatro aulas prácticas bajo pedido. Regístrate para recibir alertas sobre el inicio del período de registro y todas las actualizaciones.

¡Hola Comunidad! Os traemos un nuevo vídeo, disponible en el canal de YouTube de la Comunidad de Desarrolladores en inglés: ⏯ Descarga InterSystems IRIS del Docker Store En el vídeo, os mostramos cómo acceder al listado de productos de InterSystems disponibles en el Docker Store y cómo descargar la imagen de la "Community Edition". ⬇️ InterSystems IRIS Community Edition en Docker Esperamos que os resulte útil 👍🏼

¡Hola Comunidad! Os traemos un nuevo vídeo, que muestra cómo crear una API REST con InterSystems IRIS en solo cinco minutos, usando contenedores Docker: ⏯ Cómo crear una API REST con InterSystems IRIS Esperamos que os resulte útil Podéis suscribiros al canal de YouTube de la Comunidad de Desarrolladores en inglés para manteneros formados e informados.

¡Hola Comunidad! Todos los miembros de la Comunidad de Desarrolladores estáis invitados a uniros a Global Masters, el Programa de Fidelización de InterSystems. Una vez registrados, obtendréis puntos cada vez que participéis en la Comunidad. Y también podréis participar en retos, estar informados de novedades... ¡y conseguir premios! Seguid leyendo para saber cómo uniros a Global Masters y conocer todo lo que ofrece... ▶️ ¿Qué es Global Masters? Global Masters es una plataforma de "gamification", en la que se pueden ganar puntos tanto por participar en la Comunidad, como por completar retos (tareas) relacionados con la tecnología de InterSystems. Los puntos se pueden canjear por regalos; y también permiten conseguir insignias e ir subiendo niveles, haciendo que se pueda optar a mejores regalos. Cada semana se publican entre 5 y 10 retos nuevos, en los que se promocionan los artículos más interesantes publicados en la Comunidad, prácticas recomendadas, vídeos, noticias de InterSystems, formación... y también retos divertidos y entretenidos. ¡Es una excelente forma de estar al día!▶️ ¿Cómo funciona? Aquí tenéis ejemplos de retos y premios: ▶️ Niveles, Insignias y privilegios En Global Masters hay 6 niveles. Estar en los niveles más altos permite obtener mejores premios y privilegios. Cuanto más participes en la Comunidad de Desarrolladores, en Open Exchange o en Global Masters, más puntos conseguirás y más niveles alcanzarás! Estos son todos los niveles de Global Masters y las insignias que se pueden conseguir en cada nivel. ▶️ ¿Cómo unirse a Global Masters? Ve a globalmasters.intersystems.com, haz clic en el botón "SIGN IN with your InterSystems login" ("REGISTRARSE con las credenciales de InterSystems"). Después de iniciar sesión, encuentra el reto "Customize your program! START HERE!" (Personaliza tu programa! EMPIEZA AQUÍ!). Este reto inicial desbloquea los premios y los nuevos desafíos que se publican cada semana. Así que...¡no te saltes este reto para poder disfrutar de Global Masters! ¡Esperamos veros a todos en Global Masters! Y siempre estamos disponibles para recibir vuestros comentarios e ideas. ¡No dudéis en contactar con nosotros! 😉

¡Hola desarrolladores! Os traemos un nuevo vídeo, que muestra cómo usar el generador de DTL en InterSystems IRIS para crear una transformación de datos: ⏯ Cómo usar el generador de DTL en InterSystems IRIS ¡Esperamos que os resulte útil! 👉🏼 Recordad que podéis suscribiros al canal de YouTube de la Comunicad de Desarrolladores en inglés para manteneros formados e informados.

¡Hola desarrolladores! Ya está lista la edición especial del concurso para crear soluciones de código abierto utilizando InterSystems IRIS. 🏆 Gran Premio del Concurso de Programación de InterSystems 🏆 Estará activo durante cuatro semanas: del 8 de febrero al 7 de marzo de 2021. Total en premios: $16,000 Premios ¡Hemos aumentado el valor de los premios! Hay dos categorías: 1. Nominación de los expertos - los ganadores serán elegidos por un jurado especialmente formado para el concurso. Los premios serán: 🥇 1er puesto - $6,000 🥈 2º puesto - $3,000 🥉 3er puesto - $2,000 2. Nominación de la Comunidad - ganará la aplicación que obtenga el mayor número total de votos. Los premios serán: 🥇 1er puesto - $3,000 🥈 2º puesto - $1,500 🥉 3er puesto - $500 Si dos o más participantes obtienen la misma cantidad de votos, todos serán considerados ganadores y el dinero del premio se repartirá entre todos. ¿Quién puede participar? Cualquier miembro registrado en la Comunidad de Desarrolladores de cualquier país puede participar en el concurso, excepto los empleados de InterSystems. Regístrate aquí en la Comunidad si aún no tienes una cuenta. Duración del concurso Lo habéis pedido – ¡y ya está aquí! Hemos ampliado la duración del concurso. Así que ahora: 🛠 Del 8 al 28 de febrero: Tres semanas para desarrollar la aplicación y registrarla (durante este período, también se pueden modificar los proyectos). ✅ Del 1 al 7 de marzo: Una semana de votaciones. 🎉 8 de marzo: anuncio de los ganadores. Tema del concurso 💡 InterSystems IRIS applications 💡 Desarrollo de una aplicación que utilice InterSystems IRIS como backend (API o base de datos), con cualquier tipo de API o modelo de datos de InterSystems IRIS. Podéis mejorar las aplicaciones que presentásteis a los concursos de InterSystems del año pasado y presentarlas al "Grand Prix". O podéis presentar una aplicación 100% nueva. La aplicación debe funcionar en IRIS Community Edition o IRIS for Health Community Edition o IRIS Advanced Analytics Community Edition. La aplicación debe ser Open Source y publicarse en GitHub. Recursos útiles Aplicaciones de ejemplo: objectscript-docker-template rest-api-contest-template native-api-contest-template integratedml-demo-template PythonGateway-template iris-fhir-template iris-fullstack-template iris-interoperability-template iris-analytics-template Cómo presentar una aplicación a los concursos: How to publish an application on Open Exchange How to submit an application for the contest Jurado Consulta los Criterios del Jurado y las Reglas sobre los votos aquí. Así que... Ready. Set. Code. ¡Suerte a todos! ❗️ Echad un vistazo a los Términos oficiales del concurso.❗️ Bonus tecnológicos para el concurso >> ¡Ya se han presentado un buen puñado de aplicaciones a la Edición Especial del Concurso para Desarrolladores! ¿Queréis echarles un vistazo? Apps presentadas >> Si os animais, el plazo termina el domingo 28 de febrero 💪

¡Hola desarrolladores! Ya podéis ver otra sesión del Virtual Summit 2020 en el canal de YouTube de la Comunidad de Desarrolladores en inglés: 🏆 Las mejores Aplicaciones de los Concursos de Programación de InterSystems 🏆 Descubriréis algunas de las aplicaciones ganadoras en los concursos para programadores de InterSystems - los ganadores compartieron sus experiencias como participantes en los concursos y mostraron demos de sus proyectos ganadores. Proyectos ganadores:⬇️ IRIS-History-Monitor⬇️ IRIS4Health-FHIR-Analytics⬇️ SQL-Builder⬇️ BlocksExplorer⬇️ IRIS-ML-Suite Ponentes: 🗣 @Anastasia.Dyubaylo, Community Manager, InterSystems 🗣 @Henrique.GonçalvesDias, System Management Specialist / Database Administrator, Sao Paulo Federal Court🗣 @José.Pereira, Business Intelligence Developer, Shift Consultoria e Sistemas Ltda🗣 @Henry.HamonPereira, System Analyst, BPlus Tecnologia🗣 @Dmitry.Maslennikov, Co-founder, CTO and Developer Advocate, CaretDev Corp🗣 @Renato.Banzai, Machine Learning Engineer Coordinator, Itaú Unibanco ¡Un fuerte aplauso a todos! ¡Grandes programadores y grandes aplicaciones! Esperamos que los concursos de programación de 2020 os resultaran interesantes. Seguiremos con ellos durante 2021. Muchas gracias, Esther! 😍

¡Hola desarrolladores! Os traemos un nuevo vídeo, grabado por @Benjamin.DeBoe, y disponible en el canal de YouTube de la Comunidad de Desarrolladores en inglés: ⏯ Programa en cualquier lenguaje con InterSystems IRIS @Benjamin.DeBoe, Product Manager de InterSystems, nos explica cómo puedes combinar tus herramientas y lenguajes favoritos cuando desarrollas aplicaciones en InterSystems IRIS. Prueba InterSystems IRIS: https://www.intersystems.com/try ¡Esperamos que os resulte útil! 👍🏼 Y... podéis suscribiros al canal de YouTube de la Comunidad de Desarrolladores en inglés para manteneros formados e informados.