Mes: noviembre 2007

Y no me refiero al Hotel Waldorf-Astoria, sino al proyecto “Codename Astoria” de Microsoft.

Se puede decir mucho sobre Microsoft, pero no se puede decir que se duermen sobre sus laureles. Constantemente están investigando nuevas cosas, y buscando nuevas soluciones, a veces para problemas inexistentes, pero hay que admitir (y de pronto admirar) la capacidad que la empresa tiene para tirar pa’lante.

El proyecto “Astoria” no es nuevo (desde hace unos seis meses es públicamente conocido), pero si es innovativo. Se trata de (traducido de la información de Microsoft sin su permiso) “permitir que aplicaciones expongan datos como un servicio de datos que pueden ser consumidos por clientes Web dentro de una intranet y/o a través de internet. El servicio de datos utiliza consultas HTTP, y operaciones HTTP estándar como GET, POST, PUT y DELETE para hacer operaciones dentro del servicio.”

Para los interesados, todo el software necesario se puede bajar desde el sitio de Microsoft (http://www.microsoft.com/downloads/details.aspx?FamilyId=1B6F85BC-8933-4D0E-A639-934EF85ADCE1&displaylang=en) y hay un sitio con información y ejemplos en http://astoria.mslivelabs.com/Default.aspx.

Si se desean leer toda la información les deseo muy buena suerte. Si no lo desean, de lo que se trata es de los siguiente: programamos una aplicación Web que utiliza el FrameWork de Astoria; detrás de ella hay una Base de Datos (o cualquier otro proveer de datos) que le entrega dinámicamente lo que se necesita mostrar; cómo mostrar estos datos no tiene importancia para Astoria (Ajax, SilverLight, HTML, lo que se les ocurra), todo el asunto se trata de bajar y subir datos. Desde el URL de la aplicación, usando uno de los ejemplos de Microsoft, si se quieren ver los usuarios en la tabla “Customers”, se puede hacer una llamada directamente a la Base de Datos de la forma:

http://myserver/data.svc/Customers

La respuesta del servidor es en forma de XML, más o menos en la forma:

 

<DataService xml:base=http://myserver/data.svc>

<Customers>

<Customer uri=Customers[ALFKI]”>

…

</Custormers>

<DataService>

 

y si se quieren ver los datos de un solo usuario:

http://myserver/data.svc/Customer[ALFKI]

De la misma manera, para ver los pedidos del usuario, almacenados en otra tabla relacionada, el URL será:

http://myserver/data.svc/Customer[ALFKI]/Orders

Y si lo que se quiere es parametrizar la consulta para ver solo los pedidos activos, será:

http://myserver/data.svc/Customer[ALFKI]/Orders[Active eq true]

y para ordenar los resultados se puede hacer:

http://myserver/data.svc/Customer[ALFKI]/Orders[Active eq true]?$orderby=OrderDate

Ya van cogiendo la idea… Ahora imagínense que la aplicación Web crea una grilla con todos los usuarios, cada uno con un vínculo con su propio URL creado dinámicamente para hacer un Drill-Down, y la cosa va tomando forma. Y si piensan que Astoria no solo se puede utilizar para bajar datos, sino también para modificarlos, es asunto se va poniendo más interesante… y peligroso…

Hay que recalcar aquí que Astoria está en una fase muy inicial, así que hay que verlo por el momento como un experimento que tal vez en algún momento veremos aplicado en la realidad. Y, por supuesto, si alguien lo quiere utilizar para código de producción, buena suerte, y que todos los Dioses le acompañen…

Pero bueno, la cosa es cómo podríamos utilizar algo así con SharePoint… que les parece si tenemos una Librería de Documentos en un sitio de SharePoint. Librerías (y Listas) las podríamos considerar como una tabla de una Base de Datos (de una u otra forma lo es), así que podríamos ver traer todos los documentos por medio de un URL:

http://myserver/data.svc/mysitio/mylibreria

y ver los metadatos de un documento en particular con un URL de la forma:

http://myserver/data.svc/mysitio/mylibreria[mydocumento]

o los documentos que se subieron hoy:

http://myserver/data.svc/mysitio/mylibreria[Date eq DateTime.Today]

Nuestra aplicación Web se tiene que encargar de mostrar los datos de una forma consecuente (de nuevo, se trata de tráfico de datos, no de presentación de ellos) y de una forma similar se podrían editar o eliminar elementos de la Lista o Librería.

Que opinan? De una u otra forma, ya tenemos diferentes mecanismos para hacer lo mismo, desde el muy sencillo QueryString hasta el viejo y confiable sistema de SOAP WebServices. Ganamos algo? Mejoramos algo? Lo empeoramos? Que piensan al respecto…

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

Los últimos tiempos no hago más que escribir negativamente sobre nuestro producto favorito (o, al menos, MI producto favorito), y nuestro monopolista favorito. Tal vez se deba al tiempo oscuro y lluvioso aquí en Lower Slobbovia, o a la falta de Appassionatta von Climax, o a haberme vuelto pesimista como algunos aseguran… así que ahora me he puesto a escribir algo de carácter alegre, optimista, lleno de esperanza en el futuro…

Visual Studio 2008 es el tema. Llevamos esperándolo años, confiando que las metidas de patas del Visual Studio 2005 (no poder crear proyectos Web “independientes”, por ejemplo, corregido con un par de Add-Ins y luego con el Service Pack 2) no se repitan. Y, sobre todo que Microsoft se haya acordado que Visual Studio no solamente es utilizado por programadores que hacen aplicaciones Windows y/o Web, sino también por los pobres mártires que programan para los servidores, SharePoint entre otros.

Con Visual Studio 2005, programar para SharePoint no es que fuera difícil, pero tenías siempre la impresión que Microsoft nunca pensó en que era nuestra herramienta de trabajo para trabajar con WSS (o para Exchange, o CRM, o cualquier otro de sus propios servidores): programando paginas aspx no tenias el soporte del diseñador grafico, depurar remotamente era entre trabajo de Vietnamitas e imposible, ningún soporte para paginas maestras… la lista continua y continua… Algunas cosas mejoraron con el Service Pack 2, como por ejemplo poder generar ensamblados de páginas Web de una forma decente, pero por el resto todo seguía igual (se acuerdan que instalar Visual Studio costaba una hora, e instalar el Service Pack costaba dos? Nunca he podido entender cómo podía ser posible…).

Finalmente, después de mucho esperar, hace un par de meses Microsoft nos entrego las “Extensiones de Visual Studio 2005 Para SharePoint”, con plantillas para hacer WebParts, Listas, Sitios, etc., y un Generador de Soluciones que aunque no era perfecto, nos aliviaba bastante el trabajo tedioso de crear plantillas para WSS/MOSS a pelo. Así que bajo la divisa “posting optimista, alegre, esperanzador” vamos a empezar con la instalacion de las Extensiones en Visual Studio 2008: no se pueden instalar…

Y nos quitaron el “Code Coverage”, asi que de regreso a soluciones Open Source para saber en dónde estamos metiendo las patas. Pero pusieron el “Unit Test” en la versión normal… (nota positiva: hay que resaltarla y remarcarla!). Y me da la impresión que instala y ejecuta bastante más rápido que el 2005, sobre todo que inicia mucho más rápido… lo ven, no todo es negativo…

Pero de regreso a las extensiones para SharePoint, simplemente no instalan. Asi que adiós plantillas para WebParts, Listas, etc. Muchas gracias Microsoft, nos entregan un juguete nuevo, y no lo quitan a los dos meses. Y en ninguna parte se oye nada sobre si tienen planeado hacer una nueva versión. A lo mejor el equipo de programación de Microsoft-SharePoint todavía no se ha enterado que el equipo de programación de Microsoft-Visual Studio ha hecho una nueva versión. O que quieren que nos pongamos a programar con Eclipse (que todos los dioses nos protejan, ese es aun peor).

Pero como hoy estoy de humor optimista, he pensado: a lo mejor puedo usar el “SharePoint Solution Generator”, que viene con las extensiones, de forma separada… brillante idea… lo saco de un servidor en donde funciona, lo copio en otro con VS 2008, lo ejecuto y… redoble de tambor… FUNCIONA! Asi que no todo es negativo, finalmente… Me deja hacer plantillas de todo lo que quiero, me produce las soluciones para Visual Studio como yo las quiero, estupendo. Ahora, continuando con la alegría de una mañana soleada después de tantos días oscuros, solo resta abrir la solución generada con nuestro nuevo Visual Studio 2008: la primera pantalla me dice que tiene que convertir el proyecto al nuevo formato… ningún problema, me parece razonable… la segunda pantalla me dice muy optimistamente:

Y el resumen de la conversión me acaba de hundir:

Y no lo puedo abrir. Para que no digan que no puedo ser optimista de vez en cuando…

Post Script: Un par de horas más tarde, continuamos optimistas…

1 – Al tratar de utilizar proyectos creados con Visual Studio 2005, el Visual Studio 2008 modifica los archivos de solución (.sln) y de proyecto (.csproj). Los cambios no son muchos, pero suficientes para no poder volver a abrir la solución o el proyecto con Visual Studio 2005 (“The selected file is a solution file, but was created by a newer versión of this application and cannot be opened”). Aquí hay un problema cuando trabajas en un solo proyecto con grupos de programadores regados por todas partes: si usas un depósito de código fuente (TFS, Source Safe, Subversion, etc) tienes tres opciones:

– Todos los programadores tienen que usar Visual Studio 2005, o

– Todos los programadores tienen que usar Visual Studio 2008, o

– No puedes guardar los archivos de solución y proyecto en Source Safe

2 – Abro con VS 2008 un proyecto de Flujos de Trabajo para SharePoint creado originalmente en VS 2005. Lo convierto a VS 2008, modifico y compilo sin problemas. Pero no hay forma de convencerlo para que haga depuración… intentes lo que intentes, se niega rotundamente… en VS 2005 depuraba sin problemas…

Hay que seguir sonriendo, siendo positivo, optimista… dentro de tres años y 2 Service Packs estarán todos los problemas solucionados… dos meses antes de que tengamos que empezar a usar Visual Studio 2011…

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

Flujos de Trabajo basados en el WorkFlow Foundation creados para SharePoint son algo entre maravilloso y la peor pesadilla de un desarrollador. Las posibilidades son inmensas, las ventajas de flexibilidad grandiosas y la información al respecto mínima.

Entiéndanme bien, me estoy refiriendo a Flujos de Trabajo de verdad, no los dos o tres ejemplos que Microsoft ha creado (y que vienen instalados por defecto en WSS y MOSS), o las chapuzas que se pueden hacer con el SharePoint Designer. Estoy hablando de Flujos de Trabajo para la vida real, para uso en procesos reales, no para los hipotéticos casos que uno u otro desarrollador de Microsoft se inventó en un momento de debilidad. Por ejemplo, según las especificaciones de Microsoft, a un flujo se le pueden colgar páginas Web para poderlos configurar al crearlos, al iniciarlos, para cambiarlos en medio de su funcionamiento o para que los usuarios interactúen con él. Las páginas pueden ser creadas con formularios InfoPath (la forma fácil, por supuesto con bastantes ejemplos regados por Internet y con todos los ejemplos que Microsoft proporciona), o con paginas aspx (la forma difícil, con un solo ejemplo proporcionado por Microsoft, y ningún ejemplo que se pueda encontrar en Internet). Pues bien, según Eilene Hao (Product Manager del WorkFlow Team de Microsoft, es decir, un Product Manager mas en el ejercito de PM’s de Microsoft), crear paginas aspx para interacción con usuarios en Flujos es “creating aspx forms is really just a matter creating an aspx form that makes a special workflow call. That Was Easy…Too Easy…”. La cosa es que lo fácil no es tan fácil, y nadie te cuenta cómo hacerlo, ni los problemas que te vas a encontrar. Cuando ya conoces el truco, después de días de sudor y lagrimas, de pronto tienes la tendencia a estar de acuerdo con ella, es fácil, tal vez demasiado fácil… si sabes cómo hacerlo…

El asunto es que cuando la interacción con el usuario es algo más que simplemente rellenar espacios con información, no puedes utilizar InfoPath, por sus limitadas posibilidades de programación. Validaciones complicadas, mostrar información dinámicamente dependiendo del estado del flujo, formateo especial de la pagina, todas son cosas que van entre difícil e imposibles de hacer con InfoPath. Así que en un flujo que va mas allá de preguntar el nombre y apellido, estás obligado a usar paginas aspx. Y todo se limita a crear un Tipo de Contenido de SharePoint, al que le cuelgas la pagina aspx, y al flujo le cuelgas el Tipo de Contenido… Suena sencillo, pero para que hacerlo fácil si es posible hacerlo difícil…

Luego te enfrentas a una buena cantidad de problemas de sincronización cuando el usuario guarda la información presente en el formulario aspx. Aquí la liga entre el formulario y el flujo se realiza por medio de la Lista de Tareas: en el momento que la información cambia, cambia también una tarea en la Lista, y esa es la señal para el Flujo de que algo tiene que suceder. El problema es que el formulario y el flujo trabajan en hilos separados (hilo == thread, la traducción nunca me ha sonado bien…), y puede suceder que los dos intenten “conversar” al mismo tiempo con la Lista de Tareas o con el elemento que está usando el flujo, así que los dos se pisan la soga, y el flujo se vuelve inestable. El mecanismo no está optimalizado en la Fundación o en su interacción con SharePoint, por lo que hay que poner timers por aquí y por allá para que el uno empiece a funcionar después de que el otro ha terminado, es decir, un Flujo de Trabajo para el Flujo de Trabajo… podría ser fácil, pero si se puede hacer difícil…

La actividad de Aplazamientos (“Delay Activity”) es otra maravilla. Microsoft ha tenido problemas con ella desde el principio de los tiempos, y después de dos Hot Fixes (“FIX: You experience various problems in Windows Workflow Foundation”, “A timer does not resume operation after a workflow is reloaded in Microsoft Windows Workflow Foundation”) y un Articulo KB (“A Microsoft Windows Workflow Foundation timer does not resume correctly after reloading a workflow”), funciona bien con cualquier tipo de Host para la Fundación, pero NO cuando SharePoint es el Host. Es decir, no funciona con SharePoint: el flujo llega hasta el Delay, lo comienza (dehidratación), pero nunca se recupera de el (rehidratación)… no produce ningún tipo de error, de señal de que algo no está bien, nada, nada, simplemente nunca despierta… Blanca Nieves a la que nunca le llega el Príncipe a darle el beso…

Finalmente, para no aburrirlos mas con este drama digno de una Telenovela, una perla de inconsecuencia: cuando quieres crear una Tarea acoplada al flujo, pero no desde el flujo mismo (obligatorio de hacer para poder solucionar el problema del Delay), tienes que contarle a la tarea cual es el Tipo de Contenido que tiene que usar (un formulario aspx en un flujo no es más que un Tipo de Contenido, se acuerdan?). Pues bien, creas la tarea programáticamente, en tu Lista de Tareas:

SPListItem myNewTask = myTasksList.Items.Add();

Anteriormente ya has encontrado el Tipo de Contenido de tu flujo en la Lista, y creado una instancia de él:

SPContentType myFlowContentType = null;

foreach (SPContentType myContentType in myTasksList.ContentTypes)

{

      if (myContentType.Name == «NombreDelFlujo»)

            myFlowContentType = myContentType;

}

Y simplemente le quieres decir a la nueva tarea que use ese Tipo de Contenido:

myNewTask.ContenType = myFlowContentType;

Sencillo, verdad? Pues no, por eso de lo que para que hacerlo fácil, etc., técnicas sencillas de Orientación a Objetos no funcionan en este caso… y después de mucho ensayar encuentras que lo tienes que hacer por medio de las propiedades de la Tarea:

myNewTask[«ContentTypeId»] = myFlowContentType.Id;

Lo que es cierto es que si sobrevives la tentación a suicidarte con un banano, los mal genios y depresiones, programar SharePoint nunca te aburre…

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

Esta semana, trabajando en un proyecto en el que estamos desarrollando WebParts paralelamente en equipos de 32 y 64 bits, me he encontrado un problema simpático: un colega crea un proyecto de Visual Studio 2005 en una maquina de 32 bits, lo sube al depósito de código fuente de TFS, yo lo bajo de allí con otro computador de 64 bits, lo intento abrir, y me sale un error “The project file bla-bla-bla cannot be opened. The Project is not supported by this installation”.

Después de insultar en toda clase de términos a mi colega por no hacer las cosas bien (por supuesto, siempre hay que echarle la culpa a los demás), intentar de todo sin resultados, escanear Google buscando una solución sin encontrar nada efectivo, me dio por leer el error con más cuidado, y mirar el archivo de solución de Visual Studio. Pues bien, allí se encuentra una sección llamada “ProjectTypeGuids”:

<ProjectTypeGuids>{9E5D3E2D-E4E2-418e-8D80-2F0DA9A94F9A};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

Después de buscar en el SDK de Visual Studio, resulta que:

• {FAE04EC0-301F-11D3-BF4B-00C04F79EFBC} = es un proyecto “Class Library”
• {9E5D3E2D-E4E2-418e-8D80-2F0DA9A94F9A} = es un proyecto “SharePoint Solution”

Mi colega estaba usando las plantillas de “Visual Studio Extensions para WSS”, que no se pueden instalar en Visual Studio 2005 bajo 64 bits (no me pregunten porque, no tengo ni idea, pero al intentar instalarlas, el instalador simplemente dice que no es posible), la que crea la clave «9E5D…». Como mi copia de Visual Studio no sabe que significa ese GUID, sale con el mensaje de error, y se niega funcionar.

Con modificar el archivo de solución quitándole el GUID “9E5D…”, se puede abrir y compilar el proyecto sin ningún otro problema.

Por el resto, después de probar en los sistemas de 64 bits compilaciones hechas con la opción “Platform target” puesta en “Any CPU” todo funciona bien en MOSS 32 y 64 bits, por lo que parece que no es necesario hacer compilaciones especiales para cada sistema (nota interesante por si alguna vez va a trabajar con MOSS 64 bits).

Ah! Y otra cosa curiosa: para los que usan Subversion como depósito de código fuente, Tortoise no funciona en equipos de 64 bits… (se puede instalar, pero después ni siquiera arranca a funcionar)

Esta entrada es más una manera rápida de guardar en algún lado algo que con toda seguridad mañana se me va a olvidar, pero que ha costado un par de horas de trabajo para encontrar la respuesta.

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…