Cómo saber a que DLL corresponde un Hosted Control

Existe un método muy sencillo y que no requiere de ninguna instalación especial para conocer el namespace y el tipo de cada uno de los hosted controls que hay definidos en la configuración de USD en CRM.

Muchas veces necesitaremos en nuestro código hacer referencia a uno de estos objetos especiales para modificar algún atributo o para captar un evento. Estos ojbetos especiales son los que aparecen listados en la configuración de USD cuando creamos un nuevo hosted control, en el campo USD Component Type.

Tipos de hosted controls predefinidos

Tipos de hosted controls predefinidos

Como ya hemos visto en otras entradas a veces necesitamos hacer referencia a alguno de estos objetos (en esta entrada al Debugger por ejemplo). Para capturar la instancia del objeto necesitamos dos cosas: el nombre del hosted control y el tipo. El nombre es el que elijamos en la configuración del USD en CRM. El tipo es en principio desconocido.

Bien pues vamos a ver cómo consultar el tipo de la manera más sencilla. Lo primero de todo es irnos a la configuración del USD en CRM y crear un nuevo hosted control (como en la imagen de arriba).

Luego en el desplegable de USD Component Type seleccionamos el objeto que queremos averiguar. En nuestro caso queremos averiguar por ejemplo la DLL y el tipo del objeto Debugger:

Selección de Hosted Control Debugger

Selección de Hosted Control Debugger

A continuación lo único que deberemos hacer es volver a pinchar sobre el campo USD Component Type y seleccionar la opción USD Hosted Control. Como veremos cuando hagamos esto, aparecerán debajo dos campos: Assembly URI y Assembly Type. Además aparecerán rellenos con el tipo del objeto que hayamos seleccionado en primer lugar (en nuestro caso el objeto Debugger).

Selección de USD Hosted Control

Selección de USD Hosted Control

Una vez que conocemos el tipo, en nuestro Custom Hosted Control podremos obtener la instancia del objeto del siguiente modo:

Con esto ya somos capaces de modificar cualquier atributo de la instancia cargada en nuestro USD de este objeto.

El motivo por el que ocurre esto es que al seleccionar cualquier tipo especial en el campo USD Component Type los campos Assembly URI y Assembly Type se auto rellenan y además se ocultan. El fallo está en que al cambiar el desplegable no se resetean estos valores.

Unified Service Desk (USD): Utilizar debugger para trazas

Todos los que hemos tenido que desarrollar un USD sabemos que es una tarea bastante engorrosa. Algunos motivos son que no somos dueños del proyecto y por lo tanto no podemos añadir trazas donde queramos. Otro motivo es que el USD tiene unos tiempos de inicialización bastante grandes y todo lo que sea evitar cerrar la aplicación es bienvenido.

Para facilitarnos un poco la vida, en Microsoft desarrollaron un objeto llamado Debugger. Este objeto se añade por configuración a nuestro USD mediante un Hosted Control de tipo Debugger. Lo ideal sería ponerlo en el MainPanel como se muestra en la imagen:

Declaración de Debugger en configuración del USD en CRM

Declaración de Debugger en configuración del USD en CRM

Ya hemos hablado sobre las bondades del Debugger y cómo configurarlo en nuestra aplicación para poder acceder a él en esta otra entrada. En este caso nos centraremos en una de las pestañas, la de Resultados de Depuración:

Pestaña de Resultados de Depuración del Debugger

Pestaña de Resultados de Depuración del Debugger

Dentro de esta pestaña tenemos dos objetos: un Textbox multiline y un Botón para borrar el contenido. En general en este campo de texto se añadirán algunos resultados de depuración así como errores referentes a hosted controls. Este Textbox es el que voy a utilizar para monitorizar nuestras variables.

Para acceder a este Textbox vamos a utilizar la librería Reflection (System.Reflection).  Con esta librería seremos capaces de acceder a atributos privados de objetos para instancias previamente creadas. Básicamente nos permite saltarnos la decisión de un programador de declarar un objeto private o public. Es importante entender que si un programador decidió poner un objeto como private existiría un buen motivo por lo que este procedimiento es totalmente desaconsejable para entornos de producción.

No obstante antes de llegar al entorno de producción pasaremos por muchas etapas en nuestro USD en entornos de laboratorio, de desarrollo o incluso de pre producción. Con esta idea seremos capaces de obtener muestreo de datos en ejecución de un modo sencillo y que pueda ser invocado desde cualquier elemento del USD.

Dicho esto, vamos a pasar a ver el código.

La idea es introducir unas lineas de código en cualquiera de nuestros Custom Hosted Control (o hosted control creados por código). A mi personalmente me gusta tener siempre un hosted control global, situado en el HiddenPanel que sirva de controlador central de funciones, FireActions y en general de gestionar la interacción con el usuario. En el ejemplo llamaré a este hosted control como Controlador Central.  No obstante podemos declarar la función en cualquier otro hosted control que hayamos programado.

En este hosted control vamos a añadir unas lineas al DesktopReady y una UIAction en la función DoAction.

Recordar que para que funcione esta UIAction es necesario declararla en la configuración del USD en CRM para el hosted control Controlador Central.

Para probar que funciona correctamente podremos hacerlo de dos modos: mediante una ActionCall declarada en la configuración del USD en CRM que apunte al hosted control “Controlador Central”, la UIAction “addTraza” y como datos “Prueba traza”; o ejecutando en nuestro código un FireRequestAction como el siguiente:

El resultado será el siguiente:

Resultado al ejecutar el FireRequestAction

Resultado al ejecutar el FireRequestAction

Como vemos ya tenemos acceso libre a este TextBox para introducir lo que deseemos (variables, respuestas de servicios, estado de conexion etc) y poder consultar en cualquier momento de la ejecución del USD.