"Cascading Parameters" en SSRS 2005 integrado con MOSS 2007

Si están trabajando con Reporting Services 2005 (SSRS) integrado con Sharepoint 2007 (MOSS) probablemente hayan notado problemas al ejecutar un reporte con “cascading parameters” (un parámetro que es filtro para los datos del siguiente parámetro). El problema se manifiesta en que en este tipo de reportes si usted selecciona el primer parámetro, el segundo NO se “refresca” automáticamente sino hasta darle click al botón “Aplicar” a cada uno de estos parámetros.

José Rivera y Edwin Torres, compañeros míos aquí en Nagnoi, Inc. nos contaron de su experiencia con ese problema y luego de hacer mucha investigación acerca de personas que hayan experimentado síntomas similares, nos recomendaron instalar el Cumulative Update 6 (CU6) de SQL Server 2005 SP2 para solucionar este problemita. Aparentemente desde el CU4 podemos obtener beneficio para reparar este comportamiento de SSRS y MOSS, pero pueden irse a la segura para reparar este “bug” y probablemente otros más con la última versión. Puede ver más detalles del CU6 y las cosas que repara aquí http://support.microsoft.com/kb/946608. No está disponible para descarga directamente sino deben escribir al email que se muestra en la página para que la gente de Microsoft les envíe el link para hacer la descarga.

Hasta la próxima.

Alan.

Novedades en SQL Server 2008 Parte 3 – Reporting Services

Después de casi ya 2 meses desde mi último post, estoy de vuelta para concluir la serie acerca de las novedades en SQL Server 2008. Recuerden que hasta este momento todo lo escrito aplica a la última versión disponible que es el CTP de Febrero. Como lo comentamos al inicio de esta serie, Reporting Services 2008 es el que más a “sufrido” (para beneficio nuestro) cambios a nivel de su arquitectura, tanto a los procesos y servicios del motor de proceso de los informes como en la herramienta del usuario para crear dichos informes.

Algunos de los principales cambios en la arquitectura son los siguientes:

• Eliminación de dependencia de Internet Information Services (IIS) de la arquitectura: Para muchos DBAs, el tener que instalar un IIS para poder habilitar los servicios de Reporting Services 2005 era toda una complicación, ya que los fantasmas de seguridad siempre han asechado a IIS y por tanto las políticas de TI les previenen que el tener que instalar IIS y SQL Server en la misma caja puede ser un riesgo. Por otro lado para el equipo de desarrollo de producto de SQL Server también fue complicado la inter-operabilidad con el equipo de desarrollo de IIS para planificar temas tan importantes como el manejo de los recursos compartidos como la memoria. Para nosotros como usuarios comunes también teníamos nuestra cuota de complicación. Cuándo tenemos algún reporte o reportes corriendo en SSRS 2005 que tiene pobre desempeño, es bastante complicado tratar de determinar en cuál de las capas está el cuello de botella: ¿será a nivel de la metadata en SQL?, ¿será el problema con los WebServices de SSRS?, ¿será el problema con IIS?, ¿será el problema con ASP .NET?, etc. ¿Qué indicadores (performance counters) puedo usar para monitorear el desempeño de mi SSRS: SQL, SSRS, IIS, ASP.NET??? (y cada uno tiene una decena de indicadores o más). Obviamente como ya habrán podido notar (o tal vez no), SSRS funciona muy bien para reportes relativamente cortos, pero se vuelve un problema para reportes más largos o extensos.
  Bueno al final del túnel siempre hay una luz, y en este caso la luz le llegó al equipo de desarrollo de SSRS removiendo la dependencia con IIS. Los principales beneficios de esta estrategia son:
  
  
  a) Configuración más fácil: nos evitamos los posibles conflictos con otras aplicaciones instaladas en IIS: Sharepoint, Proclarity PAS, etc.
  
  b) Mejor administración de recursos: Ahora el equipo de SSRS tiene el control completo y por tanto puede controlar mejor el uso de los recursos como la memoria. Por ejemplo uno de las limitaciones que se tenía desde el inicio era que IIS había sido diseñado para presentar páginas estáticas o dinámicas de HTML pero no para la ejecución de reportes extensos como los que podemos tener en SSRS.
  
  En SSRS 2008 se ha implementado un HTTP Listener que usa el módulo HTTP.SYS directamente del sistema operativo (y se evita así toda la plomería de IIS), aceptando directamente todas las peticiones que se hagan en el URL y puerto pre-establecido en la configuración de SSRS. Las tareas de autenticación también están bajo el HTTP Listener de SSRS trabajando con los mismos mecanismos que brinda IIS (Windows, Basic y Anónima).
  

• Reservas de URL: El cambio anterior implica que ahora debemos decirle también a la configuración de SSRS dónde queremos que “escuche” las peticiones (URL Reservations), que pueden ser más de una para la misma aplicación (Report Manager, ReportServer).
  
  Las opciones son:
  

Tipo	Ejemplo	Resultado
Todas	http://+:80/reports	Todas las llamadas al directorio virtual Reports en el puerto 80
Específica	http://adventureworks.com:80/reports	Llamada específica al directorio virtual Reports en el puerto 80 de adventureworks.com
Todas las NO asignadas	http://*:80/reports	Las llamadas no manejadas por otras aplicaciones en el puerto 80 para el directorio virtual Reports

Figura 1. Pantalla para la configuración del Web Service URL


Figura 2. Creación de un "EndPoint" adicional para el Web Service URL



Figura 3. Ahora nuestro SSRS está listo para atender solicitudes en los 2 URL configurados

• Cambios al Motor de Reportes (Report Engine): El mecanismo de procesamiento sobre demanda de los reportes (o sea cuando el usuario inicia llamada), ha sido mejorado para minimizar los tiempos de repuesta. En la versión 2005 si teníamos un reporte bastante grande e intentábamos mostrarlo, podríamos esperar probablemente varios minutos antes de poder ver la primera página del mismo, ya que el mecanismo de procesamiento hacía su trabajo para TODAS las páginas del informe (que podían ser 100, 1000 ó 10000) a pesar que el usuario tal vez quería ver sólo la primera o alguna de ellas. Con las mejoras en el Report Engine el tiempo de respuesta de cada una de las páginas se ha optimizado y busca ser constante en cada una. Además está preparado para escalabilidad. Si tenemos muchos usuarios viendo distintos reportes a la vez, el Report Engine ya no va a procesar TODAS las páginas y ponerlas en memoria, sino lo hará según sean requeridas.
  La arquitectura del rendering ha sido totalmente re-escrita. En 2005 existía una extensión individual para cada tipo por ejemplo Excel y HTML. En la versión 2008 se encapsulado todos los procesos comunes del rendering para que luego cada una de las extensiones consuma sus datos de una manera estándar sin tener que repetir trabajo. Probablemente este cambio en las extensiones de rendering no sean percibidas por el usuario final, pero para el equipo de producto significó la posibilidad de estandarizar esa parte del código de SSRS y posibilitar la escritura de nuevas extensiones con menos esfuerzo.
  Con la versión 2008 también se incluye la extensión de rendering para Microsoft Word y la de Microsoft Excel ha sido mejorada. Ambas extensiones son para la versión 97-2003 y no de la nueva versión (2007). Es bastante probable que las extensiones para Word y Excel 2007 se incluyan como un Technical Refresh después que la versión RTM salga al mercado.
  
  
• Políticas para Administración de Memoria: Con el propósito de asegurar el funcionamiento correcto de SSRS bajo alta demanda, se han implementado políticas para el manejo de la memoria. En este caso el componente Memory Broker de SSRS es el encargado de monitorear el uso de la memoria y de disparar eventos que cambien las funciones de SSRS según el escenario de uso de memoria que esté ocurriendo.
  La tabla siguiente muestra los 3 estados que SSRS identifica con respecto al uso de memoria y las funciones o comportamiento que tomará de acuerdo al estado:
  
  

  Estado	Comportamiento
  Low Memory Preasure (bajo uso de memoria)	* Solicitudes actuales continúan * Nuevas solicitudes se aceptan * Procesamiento “background” de baja prioridad
  Medium Memory Preasure (uso de memoria intermedia)	* Solicitudes actuales continúan * Nuevas solicitudes podrían ser aceptadas * Se reducen las asignaciones de memoria para todas las aplicaciones * Reducción sustancial del procesamiento en “background”
  High Memory Preasure (uso de memoria alta)	* Solicitudes actuales lentas * Nuevas solicitudes se rechazan * Se reducen aun más las asignaciones de memoria * Uso de memoria virtual (memory swap)

  
  Para controlar estos 3 estados de la memoria el archivo de configuración del ReportServer contiene las siguientes variables: WorkingSetMaximum, MemoryThreshold, MemorySafetyMargin and WorkingSetMinimum. Para más detalles sobre el manejo de memoria y la configuración de estas variables referirse a los Books On Line (BOL).

• Cambios en la herramienta de configuración - Configuration Manager: El primer cambio que van a notar aquí es que ya no tenemos los colores verde, amarillo y rojo que más que ayudarnos en la configuración hacían confundir al usuario. Las pantallas de configuración ha sufrido algunos cambios y ahora muestra un workflow más intuitivo para el usuario.
  
  

Figura 4: La nueva versión del Reporting Services Configuration Manager
sin los colores de estatus

Figura 5: Conexión a SSRS 2005 desde el Management Studio

Figura 6: Conexión a SSRS 2008 desde el Management Studio.
Noten que ya no está el folder Home y ahora está el folder Jobs.

Esto es todo por esta entrega, hasta la próxima.



Alan

Novedades en SQL Server 2008 Parte 2 - SSAS

Hola de nuevo,

En mi última entrega estuvimos hablando de algunas de las novedades que la versión de SQL 2008 nos trae con respecto al mundo de BI y tocamos las nuevas características y/o mejoras en la parte del motor relacional (SQL) e Integration Services (SSIS). En esta entrega estaremos revisando algunas de las principales novedades en Analysis Services. Aqui vamos:

Generalmente hablando no hay cambios radicales en la manera de crear las dimensiones y cubos, pero sí muchas mejoras en la experiencia del usuario, en el rendimiento o performance del motor y en la parte de monitoreo y administración.

• Dimension Wizard: Anteriormente el mismo asistente para la creación de dimensiones (Dimension Wizard) nos "empujaba" a tener un mal diseño de las dimensiones con respecto a performance. En esta nueva versión el asistente se enfoca en ayudarnos a tener un mejor diseño desde el inicio y por tanto evitar o reducir los problemas de baja performance en el entorno de producción.
  Una de las nuevas posibilidades con el asistente es que ahora se incluye una nueva columna en donde le podemos indicar al asistente si un atributo es "browsable" o mejor dicho, si dicho atributo está diseñado para poder ser incluido en alguno de los ejes (fila, columna, etc) de una consulta y por tanto la posibilidad de crear agregaciones por dicho atributo.
  
  A continuación cito un ejemplo. Si tenemos una dimensión Reseller (Distribuidor), para cualquiera de los informes o consultas del usuario, el atributo Teléfono no debiera ser usado por si sólo sin tener el nombre del Reseller (no tendría mucho valor tener las ventas según número de teléfono sin tener información del Reseller a quien pertenece dicho teléfono y venta). En este caso en el paso del asistente llamado "SELECT DIMENSION ATTRIBUTES" vamos a dejar de marcar el check box de la columna "Enable Browsing" para dicho atributo. De este modo Analysis Services no permitirá que el atributo sea usado directamente sin el cliente en una consulta en específico, sino tendrá como una propiedad del atributo al que esté relacionado, por ejemplo "Reseller Name".
  
  

  Figura 1. El atributo teléfono es el único que no se ha marcado como "Enable Browsing" ya que debe ser tratado como una propiedad del Reseller y no permitir consultas ni crear agregaciones usando este atributo directamente.
  
  
  

Figura 2. El asistente ahora nos permite también indicar el tipo de atributo como se muestra en la figura. Por ejemplo el atributo "English Month Name" lo marcamos como de tipo "Month" dentro del grupo "Calendar".

• Mejores Prácticas: Algu súper interesante que se ha agregado a los diseñadores son las recomendaciones de diseño, producto de las mejores prácticas en el desarrollo con SSAS. Estas recomendaciones nos dan advertencias o sugerencias a través de líneas curvas de color azul (similares a las que usa Word para corregir la ortografía) o en la ventana de Errores, con respecto al diseño del atributo, dimensión, jerarquía o cubo en el que se esté trabajando.
  Lo bueno además es que podemos personalizar estas recomendaciones habilitándolas/deshabilitándolas o agregándole comentarios para efectos de documentación o auditoría. Estas recomendaciones se pueden personalizar a nivel de todo el proyecto (base de datos de SSAS) o a nivel de una dimensión o cubo.
  

Figura 3. Analysis Services sugiere que creemos al menos una jerarquía para la dimensión.

Figura 4. Al hacer deployment de la dimensión, SSAS muestra 2 advertencias: "Evite la duplicidad de atributos ocultando los atributos que ya existen en jerarquías" (Categoría, Sub Categoría y Producto); y "Defina las relaciones entre los atributos como 'Rígidas' donde aplique". En este caso si el mismo producto no cambia nunca de categoría, podríamos definirlo como Rígido, lo mismo para la relación entre Sub Categoría y Categoría.

Figura 5. Podemos indicarle a SSAS que no queremos considerar alguna de las recomendaciones que nos ofrece para una dimensión en específico o para toda la base de datos.




Figura 6. Para efectos de documentación y auditoría podemos ingresar comentarios cuando queremos deshabilitar algunas de las recomendaciones.


• Relaciones entre Atributos de Manera Gráfica: Wow, creo que esta de las mejoras que deseábamos muchos. Y es que una de las claves para obtener mejores tiempos de respuesta cuando el usuario consulte los cubos se basa en cómo definimos las relaciones entre atributos de una dimensión. El caso típico es la relación entre los atributo de una dimensión de Tiempo como: Año, Trimestre, Mes y Día. En esta caso en orden de izquierda a derecha, cada atributo es padre del otro. Para este caso tenemos un nuevo "tab" en diseñador de dimensiones que nos permite hacer las relaciones entre atributos de manera gráfica mediante "drag and drop". Esto es mil veces más fácil que hacerlo desde la ventana de propiedades.

Figura 7: La pantalla para definir las relaciones entre los atributos de manera gráfica con simples "drag and drop".

Figura 8: Además de definir las relaciones entre los atributos de la dimensión de Tiempo en la figura, podemos definir si las relaciones entre atributos son flexibles o rígidas. Rígidas en el caso de la dimensión de tiempo.

• DYNAMIC SET: Se agregó una nueva extensión al lenguaje MDX para incluir ahora los SETs (conjuntos) Dinámicos. Por si no lo notaron, la versión 2005 nos permitía crear SETS (usando CREATE SET) pero éstos sólo se calculaban al hacer deployment del cubo (como parte de los "Calculations"). Es decir, si creabamos una función para devolver los 5 principales clientes según ventas, esto funcionará bien solamente si no incluimos ningún filtro o cláusula WHERE que seleccione a un miembro distinto a "ALL" (Todos) de cualquiera de los atributos.
  Por ejemplo si a mi consulta donde utilizo el NAMED SET para devolver los TOP 5 clientes según ventas le agregamos un WHERE que filtre el Año igual a 2001, obtendremos resultados incorrectos, ya que SSAS no vuelve a calcular el NAME SET nuevamente (sólo sirve cuando se use el Named Set sin filtro alguno).
  Aquí es donde aparecen los DYNAMIC SET (CREATE DYNAMIC SET) al rescate. Y es que con sólo agregar la palabra DYNAMIC a nuestra sintaxis de creación del SET anterior, tendremos el conjunto de los 5 clientes principales funcionando como queríamos incluso incluyendo distintos filtros para cualquiera de los demás atributos.



• DYNAMIC MANAGEMENT VIEWS (DMV): Esta es la mejor ayuda que el administrador de base de datos puede haber deseado. Y es que ahora SSAS soporta el uso de Dynamic Management Views similares a los que tenemos en SQL 2005 relacional para monitorear toda la actividad del servidor de Analysis Services, como las conexiones, sesiones, usuarios, consultas que se estén ejecutando, estadísticas con respecto a la consulta, etc. Estas vistas pueden ser consultadas de forma simple como un "SELECT * FROM $system.discover_connections" sobre un conexión a SSAS usando un DMX query. aunque el SELECT se ve idéntico a un query de SQL relacional, esta consulta se ejecuta sobre el motor de Analysis Services gracias a que se incluyó esta nueva extensión al lenguaje MDX para aceptar este tipo de consultas de igual manera a como las utilizamos sobre SQL.
  Lo mejor de todo es que podemos usar estas consultas a los DMV para generar nuestras propias gráficas estadísticas en Reporting Services o cualquier otra herramienta para monitoreo. Es bastante probable que posterior al lanzamiento oficial de la versión final de SQL 2008, Microsoft publique algunas extensiones que incluyan una serie de reportes para monitorear SSAS usando los DMV, mientras tanto podemos hacerlo nosotros mismos sin relativamente muchas complicaciones.
  
  

Figura 9: Consulta usando las extensiones de MDX hacia los DMV. En la figura se muestra cómo saber cuáles son todos los DMVs existentes.

Figura 10: Consulta para obtener las conexiones existentes a SSAS.

Figura 11: Consulta para obtener las sesiones abiertas.

Además de todas estas mejoras el motor de consultas de Analysis Services ha sido mejorado para responder mucho más rápido cuanto tengamos miembros calculados sin mayores cambios a nuestro código MDX. Otra de las mejoras más importantes desde mi punto de vista es el "Aggregation Wizard" o "Asistente de Agregaciones" el cual ha sido rediseñado totalmente, entre las características más importantes es que ahora podemos tener más de un diseño de agregación y podemos asignarlos a nuestras particiones según su uso. Más adelante espero dedicar un post completo a este tema.

Esto ha sido todo por hoy, en la próxima entrega revisaremos las principales mejoras a Reporting Services 2008.

Alan.

Novedades en SQL Server 2008 Parte 1

La semana pasada tuve la oportunidad de participar en el evento de lanzamiento de SQL 2008 en Puerto Rico, así que tuve que sacar tiempo de donde no había para comenzar a explorar las novedades de esta nueva versión que según dicen, tendremos la versión final para el 3er trimestre de este año.

La versión con la que estuve trabajando es el CPT de Febrero y a continuación voy a comentar las principales novedades para la parte de BI.

Lo primero que debo decir es que no hay mayores cambios a nivel de arquitectura del producto tal como existió de la versión 2000 a la 2005, eso es muy bueno para nosotros porque nos demuestra que el producto sigue madurando y no require hacerlo de nuevo desde cero. Por tanto todos los que están ya trabajando con 2005 o los que están recién empezando con esta versión no deben sentirse "mal" debido a que ya nos viene una nueva versión y habría que volver a empezar.

Motor Relacional

Específicamente para BI se han agregado nuevas características al lenguaje T-SQL como la inclusión de STAR JOIN, comando para relacionar nuestras dimensiones y fact tables de manera optimizada cuando creemos nuestras consultas (queries). El comando MERGE es otra novedad el cuál nos permite hacer inserciones o actualizaciones de una manera transparente entre dos tablas. Esto es bastante utilizado cuando tenemos que actualizar nuestras dimensiones o facts.

Otras nuevas características son:

• Change Data Capture (CDC): Básicamente CDC nos permite guardar en una segunda tabla los cambios realizadas a la primera, de manera que para realizar actualizaciones a nuestras dimensiones o facts dentro del DW, no tengamos que leer nuevamente toda la data de la tabla fuente (que puede tener millones de registros) para hacer preguntas acerca de cuál es la data que cambió o se insertó (que pueden ser sólo unas decenas o centenas pero seguramente mucho menor que toda la tabla fuente).
  
  Lo más interesante de esto es que el motor relacional hace todo el trabajo del CDC a través de un proceso que monitorea el Log y busca las inserciones, actualizaciones o eliminaciones que se realizaron a la tabla que se está monitoreando, logrando de esta manera el mínimo impacto con respecto a utilización de recursos del servidor.
  
  Para utilizar CDC primero hay que activarlo a nivel de la base de datos (se requiere tener rol de SysAdmin para poder hacer esto). Luego de ejecutar el Stored Procedure para la activación de CDC podrán notar que se crean nuevas tablas dentro del database schema llamado CDC (nombre reservado en SQL ahora para este propósito). A continuación debemos activar el CDC para las tablas específicas que necesitamos monitorear. Si vemos de nuevo las tablas existentes en nuestra base de datos podremos notar que ahora tenemos otras nuevas bajo el schema de CDC y también nuevas funciones de tipo tabla (Table Value Functions).
  
  La forma en que el CDC guarda la información de los cambios las tablas recientemente creadas se basa en el LSN (Log Sequence Number) que es el ID del log dónde guardó el o los cambios a nuestra tabla. Si revisamos las tabla CDC creada para monitoriar los cambios de nuestra tabla origen (cdc.[nombre_tabla]_CT), notaremos que hay varias columnas de metadata que empiezan con "_$" como las que muestran el LSN de inicio y de fin, así como una columna "_$Operation", que indica que tipo de operación fue la realizada con esa data (inserción, antes de actualización, después de actualización, eliminación). Para leer la información de nuestra tabla CDC podemos hacer uso de las funciones creadas automáticamente que nos permiten obtener los cambios filtrando los mismos por fecha.
  
  Leyendo la data que ha sido creada/modificada desde las tablas CDC para realizar actualizaciones en el DW disminuye el trabajo que hay que realizar en los paquetes a la misma vez que el tiempo de procesamiento puede mejorar sustancialmente.
  

SSIS

Con respecto a SSIS se han realizado mejoras al engine para maximizar el uso de varios procesadores creando procesos paralelos, lo cual aumenta la escalabilidad y permite distribuir la carga.

Una de las mejoras ampliamente solicitadas fue la de incluir C# como parte del lenguaje para crear Script Components. Además cuando trabajemos con este componetne ahora tenemos mayor integración con el IDE de Visual Studio, podemos referenciar assemblies externos de una manera más fácil permitiendo que nuestros paquetes sean más extensibles usando el poder del .NET Framework.

Otras características importantes son:

• Data Profiling Component: Súper útil para ayudarnos a conocer más la data con la que tenemos que trabajar. Este componente permite realizar hasta 8 disitintos tipo de análisis sobre la tabla completa o sobre las columnas que nos interesan. Alguno de los tipos de análisis que podemos realizar son: cantidad de NULLs, tamaño Min/Max, Primary Key (para determinar si una columna puede ser primary key), data inclussion (para determinar si todos los valores de una columna están contenidos dentro de otra - foreign keys - lookups).
  La salida (output) de este control es un archivo en formato XML que puede ser visualizado con una nueva herramienta dentro del folder de SSIS llamada Data Profiler Viewer.
  
• Lookup Cache: Realizar lookups en nuestros paquetes para obtener el Surrogate Key a partir de un Business Key, es una tarea común. El tema se complica cuando la tabla contra la que tenemos que realizar los lookups tiene millones de records y más aún si debemos realizar dicho lookup más de una vez dentro del mismo paquete o en varios paquetes diferentes. Esta complicación se da debido a que en 2005 SSIS necesita leer TOOODA la data de la tabla lookup en memoria antes de comenzar a procesar las tareas del data flow y por tanto, mientras más records, más lento es el proceso (si no les arroja primero algún error por falta de memoria).
  
  La buena nueva es que en 2008 podemos guardar la data del lookup en Cache, ya sea en memoria o físicamente en el disco, de manera que podamos cargar ese cache por adelantado y reutilizarlo en los distintos lookups según sea requerido, ya sea en el mismo o en otros paquetes. Bastante simple pero excelente mejora.
  
  Otras mejoras al lookup component existente es la posibilidad de dar un tratamiento distinto a los records que no existan en nuestra tabla lookup (antes sólo teníamos la opción de enviarla al output de error). Para esto se ha agregado un nuevo tipo de output al componente de Lookup.

En la próximo post continuaremos revisando algunas de las nuevas características de SQL 2008 para BI. Alguno de ellos serán:

SSAS

• Dimension Wizard
• Diseño más intuitivo

SSRS

• IIS Independent
• Report Designer
• Tablix
• Nuevos controles

Nos vemos,

Alan

Microsoft BI Conference 2008 & PASS Summit 2008

Microsoft vuelve al ataque con la segunda conferencia anual de BI de Microsoft la cual será nuevamente en Seattle del 6 al 8 de octubre del 2008. Obviamente el tema central de la conferencia será SQL Server 2008, así que eso va a estar súper bueno. Estén atentos a http://www.microsoftbiconference.com/ para mayores detalles.

Al mes siguiente también está pautada la conferencia anual del PASS (Professional Association for SQL Server) del 19 al 21 de Noviembre en el mismo lugar (Washintong Convention Center en Seattle) http://www.sqlpass.org/, así que para los que puedan, tienen 2 buenas excusas para ir a Seattle, conocer a los gurús de SQL y BI, si se puede una vueltita por Microsoft en Redmond y obviamente aprender muchas…muchas cosas interesantes.

Alan.