Reporte financiero con cuentas aplanadas en Power BI

Reporte financiero con cuentas aplanadas en Power BI

La representación de las jerarquías de cuentas contables resulta un elemento crítico a la hora de modelar una solución económico-financiera. Power BI, por defecto, visualiza las jerarquías en una matriz de manera que de cada padre se despliegan los hijos, a partir de estos los hijos de los hijos y así sucesivamente.
Sin embargo, no siempre se desea ese comportamiento, y es lo que nos ha sucedido hace poco trabajando con un cliente en un reporte contable. La petición era que querían ver las cuentas “hijo” por encima de las líneas de los padres. Lo que viene a ser la representación habitual de los libros de estudio dedicados a la materia

Además, nos pidió que aplanáramos la jerarquía para los niveles superiores. Por supuesto todo esto se tenía que conseguir sin generar nada estático, se debía mantener la posibilidad de análisis por todas las dimensiones relacionadas a los movimientos.
Disclaimer, no soy contable por lo que puede que mi vocabulario no sea del todo preciso o correcto, pero con las indicaciones del cliente ha quedado todo a su gusto
El resultado final ha sido el siguiente:

¿Quieres seguir leyendo este artículo? Pincha aquí y encuéntralo en Blog Visionarios, el blog de Verne Technology group dedicado a Data, Inteligencia Artificial, Sistemas y Soluciones de Gestión Empresarial.

Arquitecturas «Low Cost» con Power BI

Arquitecturas «Low Cost» con Power BI

En este post os queremos explicar cómo montar una solución de BI corporativa con muy pocos recursos, de ahí el título “low cost”. También nos va a servir para solucionar un problema muy común: ya estamos utilizando Power BI Service y tenemos muchos datasets repetidos o, peor aún, parecidos (ausencia de la única versión de la verdad). Para ello vamos hacer uso de la utilidad de “Shared Datasets” que nos ofrece Power BI desde Junio de 2019.

Cuando hablamos de solución de BI corporativa, nos referimos a que vamos a disponer de un datawarehouse, o repositorio donde tendremos centralizados los datos de nuestro negocio; y de un modelo analítico que contendrá los indicadores y KPI para que los usuarios de negocio (o IT según enfoque) puedan generar los informes y paneles. Este sería un diagrama de flujo de una arquitectura genérica para una solución de BI corporativa:

Lo que queremos conseguir es un modelo de datos centralizado, el cual vendría a suplir a un servidor de Analysis Services, y ponerlo a disposición de los diseñadores de informes en un portal de BI/reporting, Power BI Service en nuestro caso.

Shared Dataset

Con la utilidad de Shared dataset queremos lograr un dataset centralizado y que se establezca como único origen para todos los reports que se generen:

Sería el equivalente a un cubo en un servidor de Analysis Services.

Overview de la solución

Partimos de que ya tenemos un proceso ETL que carga un datawarehouse. Nos faltaría por implementar nuestro modelo analítico y publicarlo, de forma centralizada, en Power BI Service. En el siguiente diagrama mostramos las piezas que componen nuestra solución:

  1. Paso 1: Vamos a necesitar un usuario (data modeler) que construya el modelo de datos haciendo uso de Power BI Desktop.
  2. Paso 2: El usuario modelador de datos, publicará el dataset en un workspace y lo configurará para darle acceso a los usuarios que diseñen informes, tal y como podéis observar en la siguiente imagen:
  3. Paso 3: Un usuario encargado de diseñar informes y paneles, se conectará a este dataset y podrá publicar el informe en otro workspace, por ejemplo, Market Workspace; y finalmente, podrán compartirlo con usuarios finales haciendo uso de una App. Desde Power BI Desktop nos podremos conectar al shared dataset para diseñar el informe:

A continuación, podremos publicarlo en un workspace existente:

En el workspace sólo nos aparecerá el report, no habrá dataset. Sin embargo, si hacemos click en View lineage, podremos ver que el origen es el modelo de datos centralizado que hemos creado en los anteriores pasos:

A tener en cuenta

La solución de BI que acabamos de montar, necesita licencias Pro para todos los tipos de usuarios (data modeler, report creator y usuarios consumidores). Los recursos de procesamiento de datos y renderización de reports de nuestro tenant nos los asignará Microsoft. Estos recursos básicamente son:

  • Memoria RAM: donde estará alojado nuestro modelo analítico y llegarán las consultas que generen los gráficos. Si nuestro modelo analítico pesa 1Gb, ocupará ese tamaño en memoria.
  • Backend v-cores: encargados de resolver las consultas que se generen sobre el modelo de datos.
  • Frontend v-cores: encargados de “renderizar” los gráficos.

Si los recursos no son suficientes, por ejemplo, superamos la limitación del tamaño del dataset o el rendimiento es pobre porque hay muchos usuarios conectados, entonces tendremos que pensar en Power BI Premium y contratar la capacidad de acuerdo a los recursos que necesitemos: https://docs.microsoft.com/en-us/power-bi/admin/service-premium-what-is#capacity-nodes

En este enlace tenemos la tabla comparativa de Premium y Pro: https://powerbi.microsoft.com/es-es/pricing/#powerbi-comparison-table

También sería otra opción válida montar un Analysis Services on prem o contratar Azure Analysis Services como el motor analítico.

Conclusión

Podemos montar con pocos recursos una solución de BI corporativa utilizando el Servicio de Power BI.  como un servidor de Analysis Services y un portal de reporting simultáneamente. Esto atendiendo siempre al tamaño de la solución.

Hemos querido mostrar la agilidad y la potencia que tiene Power BI si entendemos bien las numerosas piezas que lo componen.

Finalmente, seguimos apostando por el datawarehouse y los modelos de datos centralizados como fuente única de los informes que se generen. En este blog hemos querido daros a entender que cualquier empresa, por pequeña que sea, puede montar una solución de BI corporativa.

Enlaces de interés

Mi compañera Marta ya nos explicó en un blog anterior como integrar en SSIS el refresco de un dataset tras la carga de un datawarehouse: https://blogs.solidq.com/es/sql-server/como-refrescar-un-dataset-de-power-bi-al-finalizar-el-proceso-de-etl/

Documentación oficial de Microsoft Get Data from Shared datasets: https://docs.microsoft.com/en-us/power-bi/connect-data/service-datasets-across-workspaces

 

 

PowerApps Portals (1): Una introducción

PowerApps Portals (1): Una introducción

Abra la puerta a sus clientes: PowerApps Portals

Microsoft, dentro de su suite Power Platform, nos ofrece la solución PowerApps Portals. Dentro de la filosofía de Power , Platform, Powerapps portals se trata de una plataforma que nos permite, utilizando un mínimo de código, montar una web para nuestros clientes. ¡Podemos tener nuestra web funcionando en cuestión de minutos!

Como PowerApps está asentado sobre una implementación de Common Data Service nos ofrece, además, una estructura especialmente amigable con la presentación de productos y la integración de cuentas de usuario. Podremos distinguir entre usuarios registrados y usuarios anónimos, permitiéndonos tener una web de cara al gran público y un sector privado donde mostremos información específica a clientes y colaboradores.

¿Quieres seguir leyendo este artículo? Pincha aquí y encuéntralo en Blog Visionarios, el blog de Verne Technology group dedicado a Data, Inteligencia Artificial, Sistemas y Soluciones de Gestión Empresarial.

In-Memory OLTP: Otra historia de corrupción y problemas de DMVs

In-Memory OLTP: Otra historia de corrupción y problemas de DMVs

El uso de la funcionalidad In-Memory OLTP sigue siendo una rareza en general entre nuestros clientes. Esta funcionalidad tiene un alto potencial para poder mejorar el rendimiento de aquellos sistemas con alto nivel de concurrencia y de transacciones por segundo y que estén limitados por esperas de tipo LATCH o bien por el uso de CPU.

Para poder habilitar dicha funcionalidad tenemos que crear un nuevo filegroup que acaba teniendo la estructura típica de un filegroup filestream en una carpeta. En dicha carpeta se almacenarán los distintos ficheros de datos y deltas que se generen durante la persistencia de las tablas en memoria de tipo schema_and_data.

Un nuevo problema que nos hemos encontrado es que la utilización de este tipo de filegroups pueden no ser reconocidos correctamente por algunos antivirus y éstos detecten algunos de los ficheros como posibles peligros.

¿Quieres seguir leyendo este artículo? Pincha aquí y encuéntralo en Blog Visionarios, el blog de Verne Technology group dedicado a Data, Inteligencia Artificial, Sistemas y Soluciones de Gestión Empresarial.

Auditando datos leídos en SQL Server

Auditando datos leídos en SQL Server

En más de una ocasión se nos ha preguntado cómo podemos crear una auditoría sobre los datos leídos en SQL Server. Esta necesidad surge especialmente cuando tenemos un entorno con unos requisitos de protección de datos elevada, como puede ser un centro hospitalario. Claramente es una necesidad que existe y actualmente SQL Server no ofrece una forma de auditoría adecuada para ello como sí ofrece para otras operaciones (INSERT, UPDATE, DELETE).

Que no esté implementada esta funcionalidad no significa que esta necesidad sea desconocida por Microsoft. En 2013 Microsoft Research presentó un whitepaper de investigación realizado sobre una implementación real de esta característica sobre SQL Server basada en triggers de SELECT, con benchmarks, etc. Desgraciadamente esa funcionalidad parece que no se ha implementado aún en el producto.

¿Quieres seguir leyendo este artículo? Pincha aquí y encuéntralo en Blog Visionarios, el blog de Verne Technology group dedicado a Data, Inteligencia Artificial, Sistemas y Soluciones de Gestión Empresarial.

 

Arquitecturas Power BI Premium

Arquitecturas Power BI Premium

En SolidQ, un tema que se nos plantea habitualmente en todos los proyectos es el diseño de la arquitectura. Como especialistas, una parte muy importante de nuestro trabajo es ayudar a los clientes a definir y construir una arquitectura óptima en función de las necesidades de cada proyecto, no solo para conseguir la mejor funcionalidad del mismo, sino también para construir una solución que sea escalable en el tiempo y se ajuste de la mejor forma posible al presupuesto y topología ya existente en el cliente.

Con la entrada en el mercado de Power BI, y las constantes mejoras que está recibiendo, no cabe duda de la gran apuesta que está haciendo Microsoft por este producto. Al tener una herramienta tan polivalente, en muchos casos no sabemos qué vía tomar para desarrollar un proyecto y/o cuál de ellas se ajustará mejor a nuestras necesidades a la hora del desarrollo. Por otro lado, muchos clientes están dando el salto a Power BI Premium por la necesidad de dar respuesta a algunas de las limitaciones con las que cuenta la capacidad compartida. Nos encontramos clientes que ya tienen Power BI Premium adquirido, que frente a la necesidad de evolucionar su sistema de BI/BA se plantean la duda de qué arquitectura deberían implementar.

En este artículo vamos a repasar las principales posibles arquitecturas que puede tomar un proyecto de BI, partiendo de un escenario en el que el cliente ya dispone de Power BI Premium y en el que principalmente el dato viene de orígenes ya estructurados, analizando las principales ventajas e inconvenientes de cada uno, para poder elegir siempre el mejor camino, en función de nuestras necesidades, previsión de evolución y coste.

¿Quieres seguir leyendo este artículo? Pincha aquí y encuéntralo en Blog Visionarios, el blog de Verne Technology group dedicado a Data, Inteligencia Artificial, Sistemas y Soluciones de Gestión Empresarial.

MigrAPPción a Azure con contenedores Docker

MigrAPPción a Azure con contenedores Docker

La utilización de contenedores Docker nos ha facilitado la vida en muchos ámbitos de desarrollo y devops en entornos de desarrollo, de testing y de producción también. Ahora también nos puede facilitar las cosas a la hora de pasar nuestras aplicaciones a la nube.

Tenemos herramientas que nos proporcionan un chequeo más o menos efectivo de nuestras aplicaciones para darnos una vista preliminar e incluso realizarnos la migración a Azure, como por ejemplo el App Service Migration Assistant, que escanea nuestra configuración en el Internet Information Server y nos verifica si la configuración que tenemos para una aplicación en el IIS es válida para ser llevada tal cual a una Web App en Azure.

La versión actual chequea 13 puntos de la configuración de IIS, pero, aunque obtengamos 13 OK esto no garantiza que nuestra aplicación vaya a funcionar tal y como la tenemos en on-premise como WebApp. Además de usar esta aplicación de migración, debemos repasar otros puntos y funcionalidades de la aplicación y comprobar que cumplan con los requisitos que una Web App en Azure supone.

Una de estas restricciones, es la de hacer un uso de aplicaciones instalables de terceros. Es decir, si nuestra aplicación para ejecutar una parte del código requiere instalaciones a nivel de sistema operativo, bien sean .msi, funcionalidades del SO, ejecutables, instalación de paquetes concretos de Linux, etc.
Si tenemos esto, habrá que revisar esas dependencias y ver si son ejecutables como WebApp o no, ya que no podremos instalar nada en el App Service donde tengamos alojada nuestra web app.

Para el ejemplo, supongamos que tenemos una aplicación web de reporting que hace uso del Crystal Reports de SAP en nuestro servidor IIS on-prem.

Al ejecutar el Migration Assistant tool en un servidor donde tengamos desplegada la aplicación web, nos da el siguiente resultado:

Por lo que nos dice que nuestra aplicación es migrable a una WebApp. Después de completar el asistente y especificarle la subscripción, grupo de recurso, App Service y nombre de la WebApp, el asistente crea los recursos necesarios y nos dice que nuestra web ha sido migrada correctamente.

Para el ejemplo que vamos a ver ahora, obviamos la parte de migración de SQL Server, que podemos o bien migrarla también a Azure, o activar el Hybrid Connection para acceder a nuestros datos on-prem desde la WebApp en Azure. Vamos a centrarnos en la correcta ejecución de Crystal Report.

Al intentar acceder a la URL de la webapp que hemos migrado, nos aparece un error de ejecución, que si profundizamos en él es una falta de dependencias al no tener instalado el runtime del CrystalReport y sus dependencias.

Tenemos dos posibles alternativas para llevar esta aplicación a Azure:

  • Modelo PaaS: Desplegar un contenedor Docker
  • Modelo IaaS: Desplegar la aplicación en una MV

Las ventajas de un modelo PaaS en cuanto a mantenimiento, costes, escalabilidad y disponibilidad frente a un modelo IaaS son evidentes, pero para una solución de este estilo hasta hace relativamente poco no teníamos otra opción que ir a morir a un modelo IaaS.

Ahora pudiendo desplegar una instancia de contenedor Docker con Azure Container Instance (ACI) o una web app que corra un contenedor Docker, tenemos más opciones.
¿Por qué una WebApp en vez de un ACI? Al desplegarse como WebApp nos permite gestionarlo como el resto de aplicaciones web que tengamos en nuestro entorno además de poder usar las funcionalidades que nos da para una webapp “estándar”.

Nos permite balancear la carga entre regiones, hacer uso de API Management, seguridad a nivel de webapp, despliegue en slots y configuración de slots, gestión de logs, monitorización de recursos etc…
Si estamos acostumbrados a trabajar con WebApp o vamos a lanzarnos a migrar nuestras aplicaciones web a Azure, podremos hacer una migración más homogénea al migrar nuestras aplicaciones en IIS a WebApps sin más conceptos nuevos.

Ahora bien, ¿cómo hacemos esto?

Vamos a ver como hacer esto de manera local paso a paso.

Visual Studio 2019 ya trae una opción para publicar una aplicación web como webapp basada en contenedor, pero vamos a ver cómo hacerlo paso a paso para comprender el proceso y poder automatizarlo e incluirlo en nuestro flujo de CI/CD.

Estos mismos pasos se podrían reproducir desde un pipeline y una release desde Azure DevOps con ligeras modificaciones a la hora de publicar los contenedores y los recursos. No sería necesario hacer un login interactivo si tenemos el grupo de recursos o la subscripción como Servicio conectado dentro de nuestra organización/proyecto.

 

1. Compilar la aplicación web para publicación.

Para la compilación usaremos un perfil de publicación al sistema de ficheros local generado desde Visual Studio

Esto en Azure DevOps lo haremos con una tarea de MSBuild.

 

2. Generar el Dockerfile

Para construir un contenedor personalizado se utiliza un Dockerfile, donde se define con una serie de instrucciones las acciones y capas que va a tener nuestro contenedor. Asi cuando se ejecute, nuestra aplicación funcionará correctamente. Siempre se parte de un contenedor base y puede ser Windows o Linux.

En nuestro ejemplo, nos basaremos en el contenedor Microsoft/iis ya que tenemos una aplicación web hecha en .Net Framework y usa el runtime de Crystal Report que está disponible para windows.
Los pasos a seguir serán los siguientes:

  • Obtener dlls necesarias de otra imagen de Windows que en nuestro caso son necesarias para la correcta ejecución de los informes de Crystal Report
  • Activar las features de Windows server para IIS
  • Instalación del runtime de Crystal Report
  • Publicación del código de la aplicación en el IIS del contenedor.

El contenido del Dockerfile final será el siguiente:

Para construir la imagen del contenedor que desplegaremos usamos la siguiente instrucción desde la carpeta raíz del proyecto. Para poder generar esta imagen tenemos que usar la versión de Windows de Docker y asegurarnos de tenerlo corriendo en modo Windows Containers o tendremos un error a la hora de descargar y usar las imágenes de Windows e IIS.

$ docker build . -t creportdemo

El punto de la orden anterior indica la ruta que le vamos a pasar al motor de Docker como contexto de la build, todas las rutas que usemos dentro del dockerfile de manera parcial tienen su origen en este path.
La salida de este comando será algo similar a esto:

Con esto ya tenemos una imagen de contenedor formada en local con el nombre creportdemo.

 

3. Crear un Azure Container Registry

Azure Container Registry (ACR) es un servicio que nos proporciona un repositorio de imágenes Docker privado. Podemos usar otros repositorios de imágenes como Docker Hub, pero están más enfocados a imágenes de contenedores públicas o privadas bajo el pago de una licencia Enterprise.

Si las imágenes las vamos a desplegar en Azure, ya sea con Kubernetes, con ACI o con web apps, la integración con el Azure Container Registry viene casi ya hecha, pero podemos utilizar otro registro.

Si ya tenemos un ACR podemos usarlo y crear una imagen nueva en el repositorio.
Si no lo tenemos, podemos crearlo o bien desde el portal o bien haciendo uso del Azure CLI

La URL de nuestro ACR será siempre <nombre-acr>.azurecr.io

Con este fragmento de código, podemos comprobar si ya existe un ACR con el nombre especificado en el grupo de recursos y si no existe crearlo y hacer el Docker login necesario para poder subir la imagen.

Esto mismo, podemos usarlo en los flujos de CI/CD tal cual lo estamos haciendo en local, pero lo ideal sería usar un template ARM para generar el recurso y asignarle permisos a nuestro pipeline para poder hacer push de imágenes.

 

4. Subir imagen del contenedor al ACR

Para poder desplegar la imagen que hemos formado a nuestro ACR, tendremos que hacer login a través de Docker. Esto se hace usando el comando Docker login tal y como se muestra en la última línea de fragmento de código del punto anterior.

Para poder subirlo, tenemos que nombrar la imagen que hemos compilado “creportdemo” con el nombre completo de nuestro ACR, nombre de la imagen y etiqueta.
La etiqueta nos vale para marcar la versión de la imagen, por si actualizamos la versión de software, algún componente instalado o correcciones. La etiqueta por defecto en todos los registros de contenedores es latest, cuando nosotros usamos Microsoft/iis, es como si usáramos Microsoft/iis:latest.

Es buena práctica que además de generar la versión latest que al subirla sustituirá a la actual, generar una etiqueta que identifique la versión, por ejemplo, si la compilación de la imagen es del 28 de octubre de 2020 podemos usar: 10.28.2020
Si queremos mantener versiones por entorno: prod, qa, dev… podemos usar estas etiquetas o generar “rutas” para una sola imagen. O dividir por carpetas si queremos mantener un solo ACR un poco más ordenado con las imágenes de varios proyectos.
Un ejemplo con todos estos atributos podría ser: 

gperezacr.azurecr.io/release/demos/docker/webapp/creportdemo:10.28.2020

Para hacer esto, desde la terminal usamos los siguientes comandos:

$ docker tag creportdemo gperezacr.azurecr.io/release/demos/docker/webapp/creportdemo:10.28.2020
$ docker push gperezacr.azurecr.io/release/demos/docker/webapp/creportdemo:10.28.2020


$ docker tag creportdemo gperezacr.azurecr.io/release/demos/docker/webapp/creportdemo:latest
$ docker push gperezacr.azurecr.io/release/demos/docker/webapp/creportdemo:latest

Para el ejemplo usaremos este:
$ docker tag creportdemo gperezacr.azurecr.io/release/demos/docker/webapp/creportdemo:latest
$ docker push gperezacr.azurecr.io/release/demos/docker/webapp/creportdemo:latest

Desde el portal se vería así:

 

 

 

 

 

 

 

La manera de verlo en el portal no ayuda demasiado a la organización, pero esta organización por URLs nos puede ayudar en la automatización de publicaciones además de saber exactamente con que imagen y entorno estamos usando.

 

5. Desplegar web app con ARM

Por último, nos falta crear la webapp vinculada a la imagen que hemos subido al ACR.
Las webapps que corren contenedores Docker funcionan sobre Application Service Plan al igual que una webapp en la que publicamos el código directamente.

Para poder ejecutar contenedores Windows requiere que el Service Plan sea de tier Premium y V3 con la opción de hyper-v activa. Esta opción desde el portal no podemos especificarla al crear un App Service Plan (de momento), debemos hacerlo con una plantilla ARM o bien con el Az CLI con el siguiente comando:

$ az appservice plan create --name $aspName --sku $aspSku --location $resourceGroupLocation --resource-group $resourceGroupName --hyper-v

Si no cumple estas condiciones, no podremos desplegar el contenedor. Para contenedores Linux, necesitamos un Service Plan Linux y en casi cualquier tier permite desplegar webapps sobre contenedores Docker.
La funcionalidad de ejecutar contenedores Docker basados en Windows como webapp, a dia de hoy (Octubre 2020) está en preview, de hecho si intentamos hacer el despliegue desde el portal accediendo al ACR e intentando desplegar una imagen como WebApp Windows tiene errores y no detecta correctamente los service plan. Sin embargo, si se hace desde dar de alta una nueva webapp si que permite hacerlo.

Algo similar pasa con la línea de comandos de Azure CLI ya que solo permite desplegar WebApps basadas en contenedores Linux dando errores si lo intentamos para imágenes basadas en Windows con un Service Plan Windows.
Haciendo uso del Azure CLI tampoco permite realizar un despliegue ARM donde se despliegue una webapp ejecutando un contenedor Windows.
Podemos automatizar el despliegue haciendo uso de las funciones Az de Powershell para desplegar un ARM con el siguiente recurso (el fichero completo aquí):
{
    "apiVersion": "2018-11-01",
    "name": "[parameters('name')]",
    "type": "Microsoft.Web/sites",
    "location": "[parameters('location')]",
    "tags": null,
    "dependsOn": [],
    «properties»: {
        «name»: «[parameters(‘name’)]»,
        «siteConfig»: {
            «appSettings»: [
                {
                    «name»: «DOCKER_REGISTRY_SERVER_URL»,
                    «value»: «[parameters(‘dockerRegistryUrl’)]»
                },
                {
                    «name»: «DOCKER_REGISTRY_SERVER_USERNAME»,
                    «value»: «[parameters(‘dockerRegistryUsername’)]»
                },
                {
                    «name»: «DOCKER_REGISTRY_SERVER_PASSWORD»,
                    «value»: «[parameters(‘dockerRegistryPassword’)]»
                },
                {
                    «name»: «WEBSITES_ENABLE_APP_SERVICE_STORAGE»,
                    «value»: «false»
                }
            ],
            «windowsFxVersion»: «[parameters(‘windowsFxVersion’)]»,
            «appCommandLine»: «[parameters(‘dockerRegistryStartupCommand’)]»,
            «alwaysOn»: «[parameters(‘alwaysOn’)]»
        },
        «serverFarmId»: «[concat(‘/subscriptions/’, parameters(‘subscriptionId’),’/resourcegroups/’, parameters(‘serverFarmResourceGroup’), ‘/providers/Microsoft.Web/serverfarms/’, parameters(‘hostingPlanName’))]»,
        «clientAffinityEnabled»: false
    }
}

Usando el siguiente bloque de código de powershell podemos hacer el despliegue de nuestra webapp con un contenedor Docker basado en Windows:

La salida de este comando debe ser la siguiente:

Y después de esto, ya tenemos nuestra webapp corriendo el contenedor Docker sobre Windows con el runtime de CrystalReport y sirviendo reports.

 

Conclusiones

Con esta nueva funcionalidad, conseguimos ser capaces de migrar aplicaciones on-prem a un modelo PaaS de WebApp que de otra manera tendríamos que llevar a un modo IaaS.
Además, podemos integrar aplicaciones legacy o con dependencias de nuestro entorno en una plataforma cloud que nos permitirá crecer tanto vertical como horizontalmente. De este modo, también estaremos preparados para ejecutar nuestras aplicaciones legacy en nuevas arquitecturas como Kubernetes con el servicio de Azure Kubernetes Service (AKS).
Ya tenemos cada vez menos stoppers para dar el salto a la nube sin tener que rehacer nuestras aplicaciones.

Código del artículo

En la siguiente URL https://github.com/SolidQES/AzureWebAppDockerContainerDemo encontrarás el proyecto de aplicación web, el Dockerfile para generar la imagen Docker y dos scripts powershell. createParameters.ps1 para introducir los datos de tu subscripción y establecer todos los datos para el despliegue y CreateAndDeployWebAppContainer.ps1 para crear desde el grupo de recursos hasta la webapp vinculado al conector ACR.

El instalador del runtime de Crystal Report requiere descargarlo con una cuenta gratuita. Lo puedes hacer aquí.
Descárgalo y cópialo en la carpeta de Resources para poder ejecutar todos los pasos del artículo.

 

Enlaces:

 

X Edición Executive Máster en BI & Advanced Analytics con Tecnologías Microsoft. Conviértete en un año en un experto en BI con un seguimiento personalizado de los mentores y MVPs de SolidQ y con el nuevo temario del máster en BI & Advanced Analytics , introduciendo Modern Data Warehouse, analítica y visualización avanzada.

¡Empezamos el 18 de febrero! Inscríbete ahora y aprovecha el descuento de 50% en la matrícula y 25% en el precio total que hay disponible hasta finales de diciembre. (Válido para las 10 primeras inscripciones desde en inicio de la oferta) Toda la información aquí.

Integración y entregas continuas en Azure Data Factory

Integración y entregas continuas en Azure Data Factory

Introducción

Una de las preocupaciones principales del desarrollador es la complejidad que existe realizar despliegues entre entornos.

En data Factory tenemos la opción de integración continua, en este artículo vamos a:

    • Configurar un repositorio en devops.
    • Configurar una plantilla de despliegue entre entornos de factorías de datos
    • Creación de una release para realizar el despliegue entre entornos.

Requisitos

    • Creación de una factoría de datos en entorno de desarrollo. Esta factoría se debe de configurar con GIT de Azure Devops

    • Creación de una factoría de datos para un entorno productivo. Esta no tiene que estar asociado a ningún control de código, ya que esta se actualizará con Azure Pipelines y bajo una plantilla de Resource Manager para cambiar parámetros, por ejemplo, el de conexión, nombres de bases de datos, etc….
    • Configuración de una versión en Azure Pipelines
    • Almacén de claves de Azure (azure key vault). No es necesario, pero si recomendable.

Una vez tenemos nuestras factorías de datos creadas, uno en un ambiente de desarrollo y otro de producción. Imaginemos que ya tenemos un cambio liberado para desplegar en el entorno productivo (es decir, subido a la rama de desarrollo y también publicado, en nuestro ejemplo, estará en adf_publish), el siguiente paso es crear una nueva versión mediante Azure Pipeline.

En la siguiente imagen se muestran los distintos pasos de un ciclo de entrega continua:

Img 2 Integración y entregas continuas en Azure Data Factory

X Edición Executive Máster en BI & Advanced Analytics con Tecnologías Microsoft. Conviértete en un año en un experto en BI con un seguimiento personalizado de los mentores y MVPs de SolidQ y con el nuevo temario del máster en BI & Advanced Analytics , introduciendo Modern Data Warehouse, analítica y visualización avanzada.

¡Empezamos el 18 de febrero! Inscríbete ahora y aprovecha el descuento de 50% en la matrícula y 25% en el precio total que hay disponible hasta finales de diciembre. (Válido para las 10 primeras inscripciones desde en inicio de la oferta) Toda la información aquí.

Azure Pipelines

A continuación, vamos a crear un pipeline para realizar un despliegue entre entornos de Azure Data Factory.

Para ello una vez dentro del proyecto de GIT, nos movemos hacia la siguiente pantalla:

Img 3 Integración y entregas continuas en Azure Data Factory

 

En el siguiente paso, tenemos que añadir el artefacto (Azure Repos GIT) y seleccionamos el proyecto de control de código y el repositorio (en nuestro ejemplo se llama ADF), a continuación, la rama por defecto (en nuestro caso adf_publish):

Img 4 Integración y entregas continuas en Azure Data Factory

Una vez añadido, vemos la siguiente imagen:

Img 5 Integración y entregas continuas en Azure Data Factory

Vamos a crear varios pasos a la hora de desplegar. Primero debemos de pulsar en Stage1 en «1 job, 0 taks». Primero damos nombre y a continuación agregamos una tarea al job pulsando sobre el +:

Img 5.1 Integración y entregas continuas en Azure Data Factory

Si es la primera vez con crear la tarea de despliegue sería suficiente, pero sucesivos despliegues sería bueno primero crear una tarea para parar los triggers y deshabilitarlos en el entorno productivo, a continuación, desplegar el data factory y después crear otra tarea para habilitar de nuevo los triggers.

Nosotros nos vamos a centrar en el primer despliegue, para los sucesivos despliegues y poder crear esos scripts en powerShell para los triggers, al final del artículo dejo una lista de referencias en la que explicará el proceso de creación.

Para ellos creamos una nueva tarea de ARM template deployment:

Img 6 Integración y entregas continuas en Azure Data Factory

Una vez dentro debemos de completarla de la siguiente forma:

Img 7 Integración y entregas continuas en Azure Data Factory

Cuando estemos en el template para el deploy, se debe de seleccionar el template que generar el ADF cuando hacemos una publicación y el template parameters son los parámetros que nosotros podemos modificar para obtener una personalización, que veremos en el siguiente apartado (Creación de parámetros personalizados con la plantilla de Resource Manager).

Una vez rellenado toda esta parte, ya podríamos crear nuestra primera release:

Img 8 Integración y entregas continuas en Azure Data Factory

Se puede ver en la siguiente captura:

Img 9 Integración y entregas continuas en Azure Data Factory

 

Para ejecutarlo, debemos de pulsar en deploy:

Img 10 Integración y entregas continuas en Azure Data Factory

Img 11 Integración y entregas continuas en Azure Data Factory

Y si la ejecución ha sido satisfactoria, aparecerá de la siguiente manera:

Img 12 Integración y entregas continuas en Azure Data Factory

Con ésto, tendríamos nuestro despliegue realizado desde el entorno de desarrollo hacia el de producción, con los parámetros de desarrollo, es decir sin mover bases de datos, runtimes, etc…

En la siguiente sección, vamos a ver esta personalización y además crear una librería donde van a estar guardados.

Creación de parámetros personalizados con la plantilla de Resource Manager

Al tener el data factory en git, se crea una fichero llamado arm-template-parameters-definition.json en la carpeta raíz de la rama de Git.

Al publicar los cambios en la rama que tenemos en este ejemplo adf_publish, Data Factory lee el archivo y usará la configuración que esté parametrizada.

Img 13 Integración y entregas continuas en Azure Data Factory

En la imagen anterior podemos ver como estamos en la rama master y tenemos la plantilla.

 

La sintaxis es la siguiente:

    • El establecimiento de un nombre de propiedad en * indica que quiere parametrizar todas las propiedades que incluye (solo en el primer nivel, no de forma recursiva). También puede proporcionar excepciones a esta configuración.
    • El establecimiento del valor de una propiedad como una cadena indica que quiere parametrizar la propiedad. Use el formato <action>:<name>:<stype>.
    • <action> puede ser uno de estos caracteres:
    • = significa que el valor actual debe conservarse como el valor predeterminado para el parámetro.
    • significa que no se debe conservar el valor predeterminado para el parámetro.
    • | es un caso especial para los secretos de Azure Key Vault para una cadena de conexión o claves.
    • <name> es el nombre del parámetro.
    • <stype> es el tipo del parámetro. Si <stype> está en blanco, el tipo predeterminado es string. Los valores admitidos son: string, bool, number, object y securestring.
    • De forma predeterminada, todas las cadenas seguras, como los secretos de Key Vault, las cadenas de conexión, las claves y los tokens, están parametrizadas.

 

Ejemplo de una plantilla:

{
    "Microsoft.DataFactory/factories/pipelines": {
        "properties": {
            "activities": [{
                "typeProperties": {
                    "integrationRuntime":{
                        "referenceName": "=::string"
                    },
                    "url": "=::string", 
                    "environmentPath": "=::string",
                    "connectVia": {
                        "referenceName": "=::string"
                    }
                }
            }]
        }
    },
    "Microsoft.DataFactory/factories/integrationRuntimes":{
        "name":"=",
        "properties": {
            "typeProperties": {
                "ssisProperties": {
                    "catalogInfo": {
                        "catalogServerEndpoint": "=",
                        "catalogAdminUserName": "=",
                        "catalogAdminPassword": {
                            "value": "-::secureString"
                        }
                    },
                    "customSetupScriptProperties": {
                        "sasToken": {
                            "value": "-::secureString"
                        }
                    }
                },
                "linkedInfo": {
                    "key": {
                        "value": "-::secureString"
                    },
                    "resourceId": "="
                }
            }
        }
    },
    "Microsoft.DataFactory/factories/triggers": {
        "properties": {
            "pipelines": [{
                    "parameters": {
                        "*": "="
                    }
                },  
                "pipelineReference.referenceName"
            ],
            "pipeline": {
                "parameters": {
                    "*": "="
                }
            },
            "typeProperties": {
                "scope": "="
            }
 
        }
    },
    "Microsoft.DataFactory/factories/linkedServices": {
        "*": {
            "properties": {
                "typeProperties": {
                    "accountName": "=",
                    "username": "=:-username:String",
                    "userName": "=:-userName:String",
                    "accessKeyId": "=",
                    "servicePrincipalId": "=",
                    "userId": "=",
                    "clientId": "=",
                    "clusterUserName": "=",
                    "clusterSshUserName": "=",
                    "hostSubscriptionId": "=",
                    "clusterResourceGroup": "=",
                    "subscriptionId": "=",
                    "resourceGroupName": "=",
                    "tenant": "=",
                    "dataLakeStoreUri": "=",
                    "baseUrl": "=",
                    "database": "=",
                    "serviceEndpoint": "=",
                    "batchUri": "=",
                    "databaseName": "=",
                    "systemNumber": "=",
                    "server": "=",
                    "url":"=",
                    "aadResourceId": "=",
                    "connectionString": "-:-connectionString:string",
                    "existingClusterId": "-"
                },
                "connectVia": {
                    "referenceName": "="
                },
                "dependsOn": "="
            }
        },
        "Odbc": {
            "properties": {
                "typeProperties": {
                    "userName": "=",
                    "connectionString": {
                        "secretName": "="
                    }
                }
            }
        }
    },
    "Microsoft.DataFactory/factories/datasets": {
        "*": {
            "properties": {
                "typeProperties": {
                    "folderPath": "=",
                    "fileName": "="
                }
            }
        }}
}

En la siguiente imagen nos ponemos en la rama adf_publish y tenemos el fichero creado a partir de la plantilla: ARMTemplateParametersForFactory.json

Img 14 Integración y entregas continuas en Azure Data Factory

Este fichero es el que hemos utilizado para el despliegue desde desarrollo a producción. Contiene generalmente cadenas de conexiones, password y cualquier otro elemento que hemos decidido parametrizar.

Un pequeño extracto del fichero:

Img 15 Integración y entregas continuas en Azure Data Factory

Este fichero podemos cambiar los valores a la hora de desplegar.

 

Para ellos debemos de volver otra vez a Pipilines y entrar en la opción Library:

Img 16 Integración y entregas continuas en Azure Data Factory

A continuación, podemos crear un nuevo grupo de variables, por ejemplo, a partir del extracto de arriba podemos crear el siguiente mapeo:

Img 17 Integración y entregas continuas en Azure Data Factory

A continuación, podemos hacer un mapeo en la tarea de despliegue del ARM:

Img 18 Integración y entregas continuas en Azure Data Factory

Img 19 Integración y entregas continuas en Azure Data Factory

 

Para ello el valor será el que hemos dado en la librería o podemos hacer que sea un parámetro de la librería, porque si cambia no tenemos que venir aquí a editar el valor. Tenemos que ponerle el símbolo del $ delante y entre paréntesis el nombre de la variable.

Referencias

https://docs.microsoft.com/es-es/azure/data-factory/source-control

https://azure.microsoft.com/es-es/services/key-vault/

https://docs.microsoft.com/es-es/azure/data-factory/continuous-integration-deployment

 

X Edición Executive Máster en BI & Advanced Analytics con Tecnologías Microsoft. Conviértete en un año en un experto en BI con un seguimiento personalizado de los mentores y MVPs de SolidQ y con el nuevo temario del máster en BI & Advanced Analytics , introduciendo Modern Data Warehouse, analítica y visualización avanzada.

¡Empezamos el 18 de febrero! Inscríbete ahora y aprovecha el descuento de 50% en la matrícula y 25% en el precio total que hay disponible hasta finales de diciembre. (Válido para las 10 primeras inscripciones desde en inicio de la oferta) Toda la información aquí.

Beneficios de contar con un Sistema Gestionado

Beneficios de contar con un Sistema Gestionado

En la actualidad las empresas cada vez son más conscientes del esfuerzo requerido para estar al día con las nuevas tecnologías y poder sacar así el máximo partido de sus infraestructuras tecnológicas.

Los departamentos de TI ya sobrecargados de por sí, en muchas ocasiones no son capaces de hacerse cargo de estas nuevas demandas, y a veces se encuentran ante la necesidad de incorporar a la plantilla nuevo personal especializado. Este personal, además, debe tener acceso continuo a formación debido a la creciente velocidad a la que cambia este mundo.

En este punto es donde entran en juego los conocidos como Servicios Gestionados, que corresponden con una nueva modalidad de negocio diseñados para resolver necesidades muy específicas, y que suponen la clave de la eficiencia empresarial a nivel tecnológico.

¿Quieres seguir leyendo este artículo? Pincha aquí y encuéntralo en Blog Visionarios, el blog de Verne Technology group dedicado a Data, Inteligencia Artificial, Sistemas y Soluciones de Gestión Empresarial.

 

Haz de Volume Shadow Copy Service (VSS) tu aliado y no tu enemigo

Haz de Volume Shadow Copy Service (VSS) tu aliado y no tu enemigo

A lo largo de los años podemos apreciar como el Volume Shadow Copy Service (VSS) es en general un servicio desconocido para muchos y en este post queremos mostrar su utilidad y posibilidades más allá del apoyo de las actividades de backup consistente a nivel de ficheros.

Comenzaremos por ejemplo hablando de snapshots de bases de datos. En SQL Server disponemos en la versión Enterprise (o desde SQL Server 2016 SP1+ en todas las versiones) de la funcionalidad Database Snapshots. Esta funcionalidad de snapshot no nos permite utilizar dichos snapshots en otras instancias ni locales ni remotas, por lo que estamos atados a la misma instancia que generó el snapshot.

¿Quieres seguir leyendo este artículo? Pincha aquí y encuéntralo en Blog Visionarios, el blog de Verne Technology group dedicado a Data, Inteligencia Artificial, Sistemas y Soluciones de Gestión Empresarial.