Integración de Dynamics CRM 2013 con Microsoft Azure

Microsoft Dynamics CRM 2013 no debería funcionar como una plataforma aislada, sino como parte de un ecosistema donde debe tener algún nivel de integración con otros sistema como, por ejemplo, la plataforma de ERP de la organización que lo usa. Una forma de implementar dicha integración es cableando explícitamente los puntos de integración con cada uno de los otros sistemas, con el riesgo de tener que revisar todo cuando alguno de los sistemas cambie. Otra forma es aflojar el acoplamiento usando un intermediario cuya responsabilidad sea recibir actualizaciones del CRM (por ejemplo, se creó un nuevo caso, se desactivó una cuenta, se adicionó un contacto a una cuenta) y distribuirlas entre los componentes relevantes del ecosistema. Este es el mecanismo que discutiremos aquí a través de Microsoft Azure.

• Dos formas de integración con Microsoft Azure
• Extensiones de Azure para Microsoft Dynamics CRM
• Colas del Bus de servicios de Azure
• Colas de Azure

Dos formas de integración con Microsoft Azure

Hay varias formas de implementar la intermediación entre aplicaciones a través de Microsoft Azure. Aquí vamos a comparar dos enfoques diferentes: a través de las extensiones de Azure para Dynamics CRM y a través de colas del Bus de servicios de Azure. La diferencia fundamental es que el primer enfoque se basa en un plugin convencional que usa su contexto genérico para pasar información a Azure, mientras que el segundo envía peticiones REST de más bajo nivel a la cola de Azure con exactamente los datos que requiere la operación. 

La ventaja obvia del enfoque de las extensiones de Azure para Dynamics es que es más familiar para el desarrollador acostumbrado a usar plugins, lo que le permite salir a producción más rápido que si tiene que aprender a interactuar a más bajo nivel con Azure. Por otro lado, la ventaja de usar directamente las colas de Azure es que con grandes volúmenes de datos e interacciones frecuentes se va a obtener un mejor desempeño al tener mayor control sobre qué se envía, cómo y cuándo.

Extensiones de Azure para Microsoft Dynamics CRM

Microsoft Dynamics CRM 2013 (tanto Online como OnPremises) puede integrarse con Azure acoplando el flujo de ejecución de eventos del CRM al bus de servicios de Azure. Dicha conexión permite que los datos que están siendo procesados como parte de la operación actual del CRM puedan ser publicados en el bus. Las soluciones del bus de servicios de Azure que estén suscritas al CRM pueden estar alerta y, cuando lleguen publicaciones del CRM al bus, leer sus datos, que son almacenados en una instancia remota del contexto de ejecución pasado en tiempo real a los plugins asíncronos del CRM.

La operación arranca con un plugin, que puede ser de alguna de las dos clases de plugins asíncronos soportadas por la funcionalidad de integración: de caja (OOB o Out Of Box) o personalizados.

El CRM ya trae en la caja un plugin habilitado para Azure (Azure-aware), que se ejecuta con confianza total (full trust) en el CRM. La idea es incluir un paso en este plugin que identifique la entidad y mensaje de destino para que, una vez registrado en el CRM, el plugin pueda notificar al servicio asíncrono para que éste publique el contexto remoto de ejecución en el bus de servicios de Azure.

También es posible escribir plugins personalizados habilitados para Azure, los cuales se ejecutan con confianza parcial (partial trust) en entorno protegido (sandbox). Ver Write a custom Azure-aware plug-in.

Del otro lado, se necesita que al menos una solución conteniendo uno o más extremos de servicio (endpoints) esté escuchando en una cuenta de solución del bus de servicios de Azure. Si el contrato del extremo de servicio no es de cola, debe escuchar activamente, mientras que si es de cola no necesita hacerlo porque los mensajes se van almacenando hasta que sea el turno del extremo de servicio para procesarlos. 

Colas del Bus de servicios de Azure

El bus de servicios de Azure soporta dos esquemas de mensajería: el original síncrono por retransmisión (relayed messaging) y el actual asíncrono que es gestionado (brokered messaging). La principal desventaja del primer esquema es que exige que ambos participantes de la comunicación (emisor y receptor) estén en línea en el momento de la conexión, lo cual motivó la creación del esquema gestionado. Este último almacena los mensajes enviados por el emisor hasta que el receptor está disponible para procesarlos. La ventaja obvia es la nivelación de la carga, ya que el receptor no necesita reservar costosos recursos para estar en capacidad de procesar incluso las solicitudes que le envíen los emisores en un pico de mucha congestión, sino que el intermediador dosifica esas solicitudes a un ritmo que el destinatario puede procesar con menos recursos.  

Aquí es donde entran en escena las colas que a través de una política FIFO (First In, First Out) entregan mensajes, en el mismo orden en que llegaron, a uno o más receptores. Su longitud crece y se contrae en la medida en que la carga entrante varía. Este uso de las colas para mediar entre emisores de mensajes y consumidores brinda un bajo acoplamiento inherente entre los componentes, ya que al no conocer los detalles de los demás componentes, un receptor puede ser mejorados sin tener efecto alguno sobre los emisores (y viceversa).

En adición a las colas, el equema de mensajeria gestionado también ofrece suscripciones que permiten la comunicación uno-a-muchos en un patrón de "publicar/suscribirse". Es especialmente útil para escalar a un número muy grande de receptores, donde cada mensaje publicado queda disponible para cada suscriptor que se haya registrado en el "tema". Los mensajes son enviados a un tema y entregados a uno o más suscripciones asociadas, dependiendo de reglas de filtrado que se definen por cada suscripción. Las suscripciones pueden usar filtros adicionales para restringir los mensajes que quieren recibir. El emisor envía mensajes a un tema como si estuviera enviándolo a una cola. Las suscripciones actúan como colas virtuales que reciben copias de los mensajes que fueron enviados al tema (si pasan los filtros de la suscripción) y desde las cuales los receptores pueden consumir mensajes como lo harían con una cola.

Colas de Azure

Finalmente tenemos las colas de la infraestructura de almacenamiento de Azure, que estarían a más bajo nivel que las colas del bus de servicios de Azure. Éstas ofrecen una interfaz simple Get/Put/Peek basada en REST que implementa mensajería persistente y confiable dentro de un servicio o entre servicios. Las colas de Azure deberían usarse en lugar de las colas del bus de servicios cuando:

• Nuestro CRM debe almacenar más de 80G de mensajes en una cola, donde los mensajes deben persistir por menos de 7 días.
• Nuestro CRM hace seguimiento al avance en el procesamiento de un mensaje al interior de la cola. Esto es útil si el proceso que está trabajando en un mensaje fallece. El proceso que venga después puede usar esa información para retomar el trabajo donde el proceso anterior lo dejó.
• Nuestro CRM requiere registros de log del lado del servidor para todas las transacciones ejecutadas contra las colas.  

Reglas de enrutamiento en Microsoft Dynamics CRM 2013 SP1

Como ya vimos, la versión 2013 SP1 de Microsoft Dynamics CRM trae nuevas funcionalidades que se pueden instalar después de la actualización de junio de 2014. En esta ocasión nos concentramos en la definición paso a paso de reglas de enrutamiento de casos, que facilitan la definición de a quién se debe asignar un caso dependiendo de las condiciones en cada punto del proceso de atención.

1. Crear nuevo conjunto de reglas
2. Adicionar elementos de regla
3. Activar conjunto de reglas

Crear nuevo conjunto de reglas

Los conjuntos de reglas de enrutamiento se definen en soluciones. Hay que evitar en lo posible personalizar directamente la instancia del CRM o a través de la solución predeterminada, que es prácticamente lo mismo. En su lugar, recomiendo crear una nueva solución no administrada o modificar una ya existente:

Ir a CONFIGURACIÓN / Soluciones / Nuevo (o seleccionar una solución no administrada ya existente).

Ir a Conjuntos de reglas de enrutamiento y dar click en "Nuevo".

Se abre una nueva ventana para definir el nuevo conjunto de reglas. Llenar el nombre y la descripción para der una idea precisa de el alcance y la intención del conjunto de reglas a quienes deban hacer mantenimiento a los procesos del sistema en el futuro. Click en "GUARDAR" para grabar el registro y habilitar la asociación de subregistros.

Después de grabar, aparece en la sección "Elementos de regla" habilitado el botón "+". Click en el botón para adicionar un nuevo elemento de regla.

Adicionar elementos de regla

Se abre una nueva ventana para definir un elemento de regla. Llenar Nombre obligatoriamente para poder grabar el nuevo registro. Es muy recomendable llenar también la descripción para ubicar a quienes deban mantener el proceso a futuro aunque el campo no sea obligatorio.

Una vez definido el encabezado, ir a la sección "Condiciones If" de Criterios de Regla para llenar las condiciones. Estas condiciones se pueden agrupar en bloques "AND" y "OR".

Para cada condición se selecciona la entidad a la que corresponde el campo a evaluar. La selección está restringida a Caso (Incident) o a alguna entidad con la que Caso tenga una relación.

Una vez definida la entidad, seleccionar el campo, el operador y el valor. En este ejemplo, seleccionamos la entidad Caso, el campo "Tipo de Solicitud", el operador "Es igual a". Como el campo corresponde a una relación con una entidad personalizada, en la pantalla aparece un botón de búsqueda para seleccionar un valor específico. 

Aparece una ventana para buscar registros. Como se puede definir más de un registro como valor de la condición, además de marcar uno o más registros en el listado hay que dar click en el botón "Seleccionar" para incluir los registros resaltados en la sección de "Registros seleccionados". Una vez hemos definido al menos un valor, podemos dar click en el botón "Agregar".

Una vez se ha definido la primera condición, podemos definir otras condiciones adicionales (implícitamente se relacionan con la primera condición a través de un operador "AND"). En este ejemplo adicionamos una segunda condición con la entidad Caso, el campo personalizado "Estado de Documentación", el operador "Es igual a". Como este campo no corresponde a una relación con registros de otra entidad sino a una lista de opciones, la pantalla no muestra un botón de búsqueda sino uno de selección de valores:   

Para seleccionar un valor de una lista de opciones, dar click en un valor de la columna "Valores disponibles", click en el botón ">>" para pasar el valor resaltado a la columna "Valores seleccionados" (puede ser más de uno). Finalizamos con click en el botón "Aceptar".

Una vez definidas todas las líneas en la sección "Condiciones If", pasar a la sección "Condiciones Then". Seleccionar si el enrutamiento será a una Cola o a un Usuario/Grupo. Si es este último caso, solamente se pueden usar grupos propietarios, no de acceso.

Después de marcar el tipo de asignación, click en el botón de Búsqueda de registros. 

De la lista seleccionar un valor y dar click en el botón "Guardar" para grabar el nuevo elemento.

Activar conjunto de reglas

Una vez hayamos definido todos los elementos de regla para este nuevo Conjunto de reglas de enrutamiento, hay que activar el registro dando click en el botón "Activar" de la barra de comandos. El sistema pide confirmación y se responde con click en el botón "Activar" del diálogo emergente. 

Cuando el registro tenga su estado en "Activo" será evaluado por el sistema cada vez que se grabe un registro de la entidad Caso.

Como la definición de este Conjunto de reglas de enrutamiento se hizo sobre una solución no administrada, para que sea visible para los usuarios del sistema hay que publicar los cambios. Ir a la solución y dar click en el botón "Publicar todas las personalizaciones". 

Instalación y creación de SLA en Dynamics CRM 2013 SP1

Microsoft Dynamics 2013 SP1 trae nuevas funcionalidades interesantes, entre las que destaco en esta oportunidad la implementación nativa de contratos de niveles de servicio o SLA (Service Level Agreement). Vamos a ver cómo instalar y crear nuevos SLAs nativos paso a paso.

1. Instalación de la actualización de productos
2. Creación de nuevo SLA
3. Creación de condiciones del SLA

1. Instalación de la actualización de productos

Los SLA nativos no vienen predeterminadamente con el Service Pack. Es necesario pedir al administrador del servidor que active las actualizaciones de Windows Update para que Dynamics pueda encontrar y descargar los paquetes correspondientes (a partir de la versión 6.1.0.581). Una vez se ha hecho la actualización de la infraestructura, hay que instalar la actualización de productos:

Ir a CONFIGURACIÓN / Administración / Instalar actualizaciones de productos

En la siguiente pantalla, se puede encontrar más información sobre el contenido de las actualizaciones. Hay que tener en cuenta que una vez instalados los nuevos paquetes ya no hay vuelta atrás.

Ahora en el área de CONFIGURACIÓN aparece una nueva sección "Administración de servicios", que agrupa la configuración de varias de las funcionalidades usadas en el módulo de Servicio del CRM. Entre estos elementos encontramos dos nuevos: "Contratos de nivel de servicio" (SLA) y "Derechos". Este último lo estudiaremos en otra oportunidad.

2. Creación de nuevo SLA

El elemento de configuración  "Contratos de nivel de servicio" lleva a una vista de todos los registros existentes. Para crear uno nuevo, se da click en "+ NUEVO".

Aparece una pantalla con el formulario para crear el nuevo registro. Los datos mínimos a diligenciar son "Nombre" y "Aplicable desde". El título no se actualiza hasta que no se grabe el registro dando click en el botón "GUARDAR" de la barra de comandos.

3. Creación de condiciones del SLA

Una vez se ha grabado el registro del nuevo SLA, el formulario actualiza el título con el nombre que definimos en el paso anterior y permite la creación de nuevos subregistros de Elementos del SLA. Para hacerlo, dar click en el botón "+" en la esquina superior derecha de la sección "Detalles de SLA" del formulario.

Se abre una nueva ventana (verificar que el navegador no tiene bloqueadas las ventanas emergentes) donde podemos definir uno de varios elementos que componen la definición del SLA. En dicho elemento especificamos las siguientes características:

• General
• Aplicable cuando
• Criterios de éxito
• Error de elemento de SLA
• Acciones de error
• Advertencia de elemento de SLA
• Acciones de advertencia

General

Corresponde al nombre que identifica el elemento dentro del SLA y al campo de la entidad Caso (Incident) con el que se va a asociar este elemento en particular, que hace las veces de fuente para los KPI (Key Performance Indicators). Las opciones son: "Seguimiento para el", "Primera respuesta por" y "Resolver por". Una vez se ha grabado el elemento no es posible cambiar la opción que se seleccionó. 

Aplicable cuando

En esta sección se definen una o más condiciones que indican a Dynamics CRM cuándo se debe crear una nueva instancia del SLA asociada a un registro específico de la entidad Caso. Estas condiciones se pueden agrupar de manera muy similar a como se definen las condiciones de las Búsquedas Avanzadas. Estas condiciones se evalúan cada vez que cambia el campo del caso con el que se relacionó el elemento de SLA. En este ejemplo, el campo relacionado es "Resolver por" y cada vez que cambie de estado se evaluarán las condiciones de "Aplicable cuando".

Como lo advierte Microsoft en "How is the SLA applied?", cuando se crea un nuevo caso, se aplica el SLA (predeterminado o a través de un Derecho)y se actualizan los valores de los campos de Caso relacionados. Cuando el Caso es modificado y cambia el valor de alguno de los campos de Caso usados en las condiciones de "Aplicable cuando", el SLA de aplica otra vez.

Cuando el SLA se aplica de nuevo, todos los elementos de SLA se vuelven a evaluar con base en los campos actualizados del Caso y las acciones de error o de advertencia se disparan si el tiempo se cumplió. Esto ocurre incluso si las acciones de error o advertencia ya se habían disparado antes de que el caso fuera actualizado. Para prevenir esto se puede agregar campos personalizados a la entidad Caso (Incident) para marcar cuando ya se han disparado las acciones de error/advertencia e incluir dichos campos en las condiciones de tal manera que solo se cumplan la primera vez.

Cada condición tiene varios componentes, usualmente una entidad + campo + operador + valor. En este ejemplo usaremos la entidad Caso (Incident), el campo Prioridad, el operador "Es igual a" y seleccionamos un valor de una lista de opciones (Alta, Normal, Baja) dando click en el botón "...", aunque para otros campos que no estén asociados a una lista de opciones se puede definir un valor manualmente, como un número o una fecha. 

Criterios de éxito

En esta sección definimos una o más condiciones de manera idéntica a como se hizo en la sección anterior. Indican al CRM cuándo una instancia activa del SLA asociada a un registro específico de la entidad Caso debe desactivarse.

Error de elemento de SLA

Una vez definidas las condiciones que disparan una instancia del elemento de SLA (Aplicable cuando) para un registro de la entidad Caso y que cancelan dicha instancia (Criterios de éxito), definimos cuánto tiempo de plazo le damos al criterio de éxito antes de declarar el SLA como incumplido. Este tiempo se puede definir seleccionando un valor de una lista de varias opciones en minutos, horas o días. En este ejemplo definidos 30 minutos. 

Para poder seguir definiendo los demás subregistros del elemento de SLA hay que grabar con el botón "Guardar" de la parte superior izquierda de la ventana emergente. 

Acciones de error

Una vez grabado el nuevo elemento de SLA, aparece disponible la opción de "Agregar paso" donde se puede escoger entre: Enviar correo electrónico, Crear registro, Actualizar registro, Asignar registro y Cambiar estado.

Las acciones que se definan aquí se dispararán si ha transcurrido el tiempo definido en la sección "Error de elemento de SLA" desde el momento definido en "Aplica desde" del encabezado del SLA y no se ha cumplido todavía la condición definida en "Criterio de éxito".

Advertencia de elemento de SLA

De manera análoga a como lo hicimos en "Error de elemento de SLA", opcionalmente podemos definir cuánto tiempo de plazo le damos al criterio de éxito antes de disparar acciones de advertencia. Este tiempo se puede definir seleccionando un valor de una lista de varias opciones en minutos, horas o días. El valor debería ser menor que el tiempo de error, por lo que para este ejemplo definimos 15 minutos.  

Acciones de advertencia

Las acciones que se definan aquí se dispararán si ha transcurrido el tiempo definido en la sección "Advertencia de elemento de SLA" desde e evento definido en "Aplica cuando" y no se ha cumplido todavía la condición definida en "Criterio de éxito".

Flujos de Proceso de negocio en Dynamics 2013: ciclo de vida

Los Flujos de proceso de negocio (FPN) o Business Process Flows son uno de los cuatro tipos de procesos que soporta Microsoft Dynamics CRM y es nuevo para la versión 2013.
El ciclo de vida de un FPN es el siguiente:

• Creación de una instancia del flujo de proceso de negocio
• Cambio de la etapa activa del flujo de proceso de negocio

Creación de una instancia del flujo de proceso de negocio

Los flujos de procesos de negocio (FPN) por definición están asociados a una o más Entidades. Cuando el formulario de la Entidad inicial se abre con un registro ya existente, Dynamics abre la instancia del FPN asociada al registro y ubica al usuario en la etapa activa del proceso. Cuando se trata de un nuevo registro, se dispara el evento de creación de una instancia siempre y cuando:

• La Entidad tenga habilitado su uso en FPN.
• No haya una instancia previa de un FPN asociada a este registro en particular.
• Haya definido al menos un (pueden ser varios) FPN activado para esta Entidad y habilitado para uno de los roles de seguridad del usuario actual.

Dynamics entonces:

• Identifica el FPN al tope de la lista de los que el usuario puede usar y crea una nueva instancia de ese FPN.
• Asigna un nuevo ID que identifique de manera única esta instancia particular del FPN.
• Define cuál es la etapa del proceso. Como se está creando el registro de la Entidad, obviamente la etapa es la primera.
• Define la Entidad inicial y el ID del registro específico dentro de la Entidad.

Cambio de la etapa activa del flujo de proceso de negocio

Los FPN pueden ser usados en una o varias sesiones, es decir que el usuario puede grabar el registro, cerrar el formulario y volver nuevamente a abrirlo en otra ocasión para continuar con el proceso. Se puede avanzar hacia otra etapa del proceso durante la misma sesión inicial o en una sesión posterior. En cualquier caso, Dynamics actualiza la instancia del FPN así:

• Cambia la etapa activa del proceso por la etapa actual.

Si la nueva etapa está asociada a una Entidad diferente de la inicial, adicionalmente a lo anterior:

• Se da la opción al usuario de seleccionar un registro relacionado con el registro de la Entidad inicial o crear uno nuevo.
• Se adiciona el tipo de la nueva Entidad y se asigna el id del registro de la Entidad que el usuario creó o seleccionó.

Una vez un nuevo registro ha sido asociado a una etapa N, es posible cambiarlo devolviendo el proceso al paso anterior (N-1) y avanzando nuevamente a la etapa N para que el FPN pida que se seleccione o cree el registro. Si el proceso ya tenía registros asociados de Entidades diferentes en las etapas posteriores (N+1, N+2, etc.), éstas se actualizan a nulo en la instancia del FPN, ya que dichos registros dependían de la relación con el registro que ya no está en la etapa N.

Preparación para la certificación en Microsoft Dynamics CRM 2013

"Ustedes tan de buenas, yo no recibí capacitación". Seguramente hemos escuchado esto varias veces y me parece chévere compartir lo que hemos aprendido para facilitar la tarea a quienes vengan después o que aún no se han certificado.

• Configurar la instancia en inglés.
• Instalar el bloque de datos de ejemplo.
• Leer los materiales de entrenamiento.
• Desarrollar los laboratorios.
• Entrenarse para el examen con los simuladores.
• Preguntar a un amigo.

Configurar la instancia en inglés.

Nuestros clientes usan sus instancias en español, por lo que es muy importante estar familiarizado con la terminología del CRM como está traducida en la versión en español. Sin embargo, para quien apenas está conociendo los conceptos puede ser muy frustrante no encontrar una correspondencia lógica entre los nombres traducidos en español y el original que sale en la documentación (y en el examen de certificación).

Mi recomendación es instalar el idioma inglés en el CRM (CONFIGURACIÓN / Administración / Idiomas) y estar cambiando entre la configuración inglés/español según sea la necesidad (Piñón de opciones de la barra superior / Idiomas ).

Por ejemplo, las opciones de Soluciones solamente están disponibles en el idioma base, que en nuestras instancias es español.
Algunas equivalencias no tan evidentes:

Traducción a español	Original en la documentación y examen de certificación
Oferta	Quote
Cliente Potencial	Lead

Instalar el bloque de datos de ejemplo.

La documentación viene con abundantes referencias a datos de ejemplo que se usan en los laboratorios y demostraciones. Instálela en CONFIGURACIÓN / Administración de datos / Datos de ejemplo:

Leer los materiales de entrenamiento.

Hay videos y materiales disponibles en Introduction to Microsoft Dynamics CRM 2013
Tenga en cuenta que los materiales no son perfectos (hay secciones que son claramente un "copy & paste" de otras muy similares) y ante cualquier inconsistencia mejor pregunta a un amigo.

Desarrollar los laboratorios.

Parece obvio, pero a veces no basta con saber dónde están las opciones. Hacer el ejercicio manual ayuda a recordar qué opciones hay disponibles en cada contexto y cuáles no.

Entrenarse para el examen con los simuladores.

Hay simuladores pagados para entrenarse que pueden ser una opción. Tienen el aval del evaluador y las preguntas y respuestas son 100% consistentes con los exámenes. También los hay gratuitos, como los ofrecidos en http://www.examcollection.com/microsoft_exams.html , los cuales funcionan por crowdsourcing, es decir que los miembros de la comunidad aportan sus simuladores construidos con base en lo que recuerdan de los exámenes de certificación que ya presentaron. Hay que tener en cuenta que no son 100% confiables, pero ayudan a tener una idea de qué tan preparado está para presentar el examen real.

Preguntar a un amigo.

Yo tuve la fortuna de contar con el apoyo de un desarrollador experimentado para recorrer la documentación y resolver dudas. Si ese no es su caso, pregunte al vecino cuando no haya podido entender algo por sus propios medios. Muy posiblemente no sea su culpa sino algún error en la documentación, un malentendido causado por una traducción confusa o algún error fácil de detectar para el ojo entrenado.

Cómo instalar una instancia de prueba de la plataforma de edX paso a paso

El proyecto de edx-platform permite descargar e instalar una instancia de pruebas en una máquina virtual local. Este es el procedimiento recomendado para familiarizarse con la plataforma y sus requisitos de hardware y software antes de intentar una instalación real en un servidor de producción, lo cual puede ser una experiencia frustrante si se tropieza con errores cuya causa se desconoce.

1. Verificar características de la máquina local
2. Instalar cliente de Git
3. Instalar virtualBox
4. Instalar Vagrant
5. Configurar instancia de edx-platform
6. Usar edx-platform

1. Verificar características de la máquina local

Asegúrese de que la máquina local disponga de más de 1GB de espacio para descargar los instaladores, instalar las plataformas y desempaquetar la instancia de edX. Esta guía paso a paso se probó sobre Windows 7, pero el procedimiento general es el mismo para Mac OS y distribuciones populares de Linux para las cuales existan versiones de los instaladores.

2. Instalar cliente de Git

Como ya lo habíamos discutido en la entrega anterior, el código fuente de la plataforma de edX y las bibliotecas de funciones sobre las que está construido se pueden encontrar publicadas en GitHub. Para tener acceso al código fuente necesitamos instalar localmente un cliente de Git:

• Descargar cliente de git-scm.com/downloads.
• Abrir el instalador. Autorizar que haga cambios.
• Usar las opciones predeterminadas, excepto en "Configuring the line ending conversions" (seleccionar la tercera opción: "Checkout as-is, commit as-is").

Una nota sobre la última opción. En Windows y en Linux los archivos de texto tienen diferentes formatos para representar <ENTER>. En Windows, se usan dos caracteres: CR (Carriage Return, para volver a la primera columna de la pantalla) y LF (Line Feed, para pasar a la siguiente línea). En Linux se usa únicamente  LF.

Dado que GitHub puede ser usado desde múltiples plataformas, se asume que se debe traducir el formato del <ENTER> al formato de la plataforma local del cliente de Git. En nuestro caso, como estamos usando Windows 7, la traducción está predeterminada. Sin embargo, como los archivos de configuración van a ser usados en linux, no vamos a usar la traducción y en su lugar usamos la tercera opción que es dejar el fin de línea como está.

Adicionalmente hay que agregar tres macros a la configuración de Git con el fin de implementar en el sistema de archivos de Windows los enlaces simbólicos de Linux (symlinks). Abrir una terminal del cliente Git (Git Bash) y allí pegar estos comandos:

git config --global alias.add-symlink '!__git_add_symlink(){
    dst=$(echo "$2")/../$(echo "$1")
    if [ -e "$dst" ]; then
        hash=$(echo "$1" | git hash-object -w --stdin)
        git update-index --add --cacheinfo 120000 "$hash" "$2"
        git checkout -- "$2"
    else
        echo "ERROR: Target $dst does not exist!"
        echo "       Not creating invalid symlink."
    fi
}; __git_add_symlink "$1" "$2"'

git config --global alias.rm-symlink '!__git_rm_symlink(){
    git checkout -- "$1"
    link=$(echo "$1")
    POS=$'\''/'\''
    DOS=$'\''\\\\'\''
    doslink=${link//$POS/$DOS}
    dest=$(dirname "$link")/$(cat "$link")
    dosdest=${dest//$POS/$DOS}
    if [ -f "$dest" ]; then
        rm -f "$link"
        cmd //C mklink //H "$doslink" "$dosdest"
    elif [ -d "$dest" ]; then
        rm -f "$link"
        cmd //C mklink //J "$doslink" "$dosdest"
    else
        echo "ERROR: Something went wrong when processing $1 . . ."
        echo "       $dest may not actually exist as a valid target."
    fi
}; __git_rm_symlink "$1"'

git config --global alias.rm-symlinks '!__git_rm_symlinks(){
    for symlink in `git ls-files -s | grep -E "^120000" | cut -f2`; do
        git rm-symlink "$symlink"
        git update-index --assume-unchanged "$symlink"
    done
}; __git_rm_symlinks'

Esos tres pequeños scripts quedan grabados en la configuración de Git y pueden ser usados más adelante para adaptar a Windows los archivos de Linux que vamos a descargar.

3. Instalar VirtualBox

Virtualbox permite simular localmente el funcionamiento de otro computador. Es útil cuando se necesita ejecutar en el mismo computador físico un sistema operativo diferente, o cuando se requiere una configuración especial que no queremos o de la que no podemos disponer en nuestra máquina local.

En este caso, se trata de usar localmente una máquina virtual con una configuración que ya ha sido totalmente probada por los desarrolladores de edX. Una ventaja adicional es que tenemos la libertad de hacer ajustes dentro de la máquina virtual o instalar software adicional sin correr el riesgo de que se afecte nuestra máquina local. Todos los cambios quedan contenidos dentro de la máquina virtual.

• Descargar el instalador de www.virtualbox.org/wiki/Downloads
• Abrir el instalador. Autorizar que haga cambios.
• Usar las opciones predeterminadas. Puede omitirse "USB Support" porque no es necesaria para ejecutar la instancia de edX y además evitamos cambios en la configuración local que pueden tener efectos secundarios inesperados en los controladores USB, especialmente en máquinas que no son físicas sino virtualizadas. Tampoco se necesita instalar la opción "VirtualBox Python 2.x Support", pero si se desea se puede incluir como en este ejemplo.

El proceso de instalación del soporte para red requerirá que se reinicie el servicio de red. Hay que tener eso en cuenta porque si se está usando la máquina local a través de escritorio remoto o de un servicio de virtualización como el de Cytrix se perderá el control sobre la máquina. Si este es el caso:

• Suministre al administrador de infraestructura el nombre de la máquina y la IP fija.
• Ejecute el instalador con las opciones seleccionadas. 
• Cuando pierda comunicación con la máquina, pida al administrador de infraestructura que ingrese a ella por la consola del servidor de virtualización.
• Use su usuario y contraseña habituales para desbloquear la sesión.
• Vaya al Centro de Redes y Recursos Compartidos y deshabilite la Conexión de área local.
• Vuelva a habilitar la Conexión de área local.
• Cierre la consola del servidor de virtualización y vuelva a conectarse normalmente a la máquina.

En caso de ya estuviera instalado VirtualBox localmente, hay que asegurarse de que no exista ya una máquina virtual llamada "precise32". Este es el nombre predeterminado de la máquina virtual Ubuntu que creará Vagrant.

4. Instalar Vagrant

Vagrant es una herramienta que permite disponer de entornos de trabajo fáciles de configurar, reproducir y transportar, construidos sobre tecnología estardar de la industria y controlada por un procedimiento consistente. Esto garantiza que nuestra máquina virtual en VirtualBox va a tener exactamente la misma configuración y el mismo software instalado que la máquina donde los desarrolladores de edX la probaron.

• Descargar el instalador desde downloads.vagrantup.com/
• Abrir el instalador. Autorizar los cambios en el computador.
• Instalar con las opciones predeterminadas y reiniciar la máquina local.

Aunque Vagrant no necesita Python 2.7 para configurar la instancia de edX, si se desea se puede instalar:

• Descargar el instalador de la versión 2.7.x desde www.python.org/download/
• Instalar.
• Configurar las variables de entorno:
• Crear PYTHONPATH = C:\Python27
• Editar Path y agregar ";%PYTHONPATH%"

5. Configurar instancia de edx-platform

Como las intrucciones para que Vagrant configure la máquina virtual no están en el repositorio oficial del proyecto edx-platform, primero se descargan los archivos desde el repositorio del instalador.

• Abrir una terminal del cliente Git (Git Bash) como administrador.
• Descargar el código fuente con las instrucciones para Vagrant: $ git clone git://github.com/antoviaque/edx-platform.git
• Bajar a la carpeta del repositorio local: $ cd edx-platform
• Ejecutar la macro: $ git rm-symlinks

• Iniciar Vagrant: $ vagrant up.

Una vez ha concluido la creación y configuración de la máquina virtual (en este ejemplo tomó tres horas, pero el tiempo depende del alcho de banda y de la capacidad del procesador de la máquina física local).

Para apagar la máquina virtual cuando no vamos a usarla:

$ vagrant halt

Para volver a encenderla (sin pasar otra vez por todo el proceso de instalación):

$vagrant up --no-provision

6. Usar edx-platform

Se accede a la consola de la misma con el usuario y contraseña "vagrant":

$ ssh vagrant@127.0.0.1 -p 2222

Una vez dentro de la máquina virtualPara arrancar el LMS (plataforma de cursos como tal): $ rake lms[cms.dev,0.0.0.0:8000]

Desde la máquina física local se puede usar con un navegador en: http://localhost:9000/

Para arrancar Studio (herramienta de creación de cursos): $ rake cms[dev,0.0.0.0:8001]

Desde la máquina física local se puede usar con un navegador en: http://localhost:9001/

Esto es posible gracias a la redirección de puertos que fue configurada en la máquina virtual, la cual convierte las peticiones que se hagan a la máquina física por los puertos 9000/9001 en peticiones a la máquina virtual por los puertos 8000/8001.

Cómo colaborar con la plataforma MOOC de edX

• ¿Por qué edX?
• ¿Cómo funciona el proyexto?
• La arquitectura de edX-platform

¿Por qué edX?

edX es una iniciativa de prestigiosas universidades de NorteAmérica, Europa y Asia que han unido sus esfuerzos para poner a disposición del mundo una vasta biblioteca de cursos en línea usando su propia plataforma para MOOC (Massive Open Online Courses). Aunque es muy interesante su oferta de contenido (después de todo estamos hablando de clases que dan en Berkeley, Queensland, MIT, Harvard, entre otras), lo que llama especialmente la atención sobre edX frente a su competencia (por ejemplo Coursera o Udacity) es que han sido los primeros en abrir las entrañas de su plataforma a la comunidad del código abierto (open source).

¿Cómo funciona el proyecto? 

El proyecto edx-platform comprende dos componentes principales: la plataforma de gestión del aprendizaje (edX) y la herramienta de edición de contenidos (Studio).

El código fuente está escrito primordialmente en Python, aunque también hay partes escritas en Ruby y NodeJS. Los diferentes proyectos que integran la arquitectura están accesibles en repositorios alojados en GitHub, una especie de red social donde los participantes aportan al desarrollo de proyectos de software de código abierto. Este esquema fue favorecido por el consorcio detrás de edX para no limitarse a los recursos que ellos puedan aportar sino más bien aprovechar la iniciativa y creatividad de gente alrededor del mundo, siguiendo el ejemplo de iniciativas exitosas como la de Wikipedia.

La arquitectura de edX-platform

La plataforma está compuesta basicamente por:

• un repositorio de Cursos
• una interfaz con sistemas externos de calificación
• bibliotecas de código y módulos para calificación
• un entorno para ejecución de programas

Repositorio de cursos

Actualmente la plataforma del LMS (Learning Managenent sistema de gestión de aprendizaje) está basada en XModules (componentes de cursos), pero está siendo migrada a XBlock (arquitectura de componentes para construir cursos).

Configuration suministra una forma simple pero flexible de levantar una instancia de la plataforma edX completamente configurada y lista para usarse.

Interfaz con sistemas externos de calificación

XQueue define una interfaz entre el LMS y sistemas externos que provean la calificación de exámenes y trabajos enviados por los estudiantes. Esto permite que se usen los módulos de calificación que ya trae edX o que uno desarrolle o adapte su propio mecanismo personalizado de calificación y lo conecte con el LMS.

Calificación

Como la idea es que los cursos que se publiquen en esta plataforma estén abiertos para una comunidad enorme (alrededor de 100.000 participantes simultáneos) es necesario contar con mecanismos para calificar que no dependen de la intervención manual de uno o varios profesores. De esta manera, no solo se evalúan los típicos cuestionarios de selección única o múltiple, sino también respuestas abiertas. Para eso se cuenta con módulos como:

edx-ora (Open Response Assessor) recibe trabajos enviados desde el LMS a través de la interfaz XQueue, los pasa ya sea por un motor de calificación basado en aprendizaje automático, un sistema de calificación manual por pares o por profesores, según corresponda y devuelve el resultado al LMS.

Discern es un API que permite el uso de un motor de clasificación de textos basado en aprendizaje automático. Si uno quiere desarrollar su propio motor de calificación, debe implementarlo dentro de estar interfaz para comunicarse con el LMS. Una forma de hacerlo es basándose en bibliotecas de funciones como EASE.

EASE (Enhanced AI Scoring Engine) no es un módulo sino una biblioteca de funciones que permite alimentar mecanismos de clasificación de contenido textual basado en aprendizaje automático. Es útil para calificar exámenes que no se ajustan a un formulario de selección múltiple, como ensayos o preguntas de respuesta abierta. Suministra funciones que asignar una nota a texto arbitrario y predictores numéricos, buscando predecir objetivos a partir de valores arbitrarios de forma escalable y con alto desempeño.

Entorno para ejecución de programas

CodeJail gestiona la ejecución de programas en entornos seguros de prueba. Está diseñado en principio para ejecución de código Python, pero también se puede usar para otros lenguajes.

XServer recibe código fuente de programas enviados por los estudiantes desde el LMS y lo ejecuta usando sistemas de calificación, los cuales deben ser desarrollados aparte.