Es un pájaro! … NO!… Es un Bug! … NO!… Es: SuperPoint!

Una semana más de vida y una semana más de luchas con/contra SharePoint. Lo menos que se puede decir es que la vida de un pica-código no es excitante, James Bond es un guía turístico de picnics de monjitas en comparación.

Después de un par de “issues” que les comentaré más adelante, me he puesto a pensar cuál es la diferencia entre un bicho/“Bug”, una Interferencia/“Glitch” y un IND (“Issue Not Documented”)? A ver: un Bug es claramente una metida de pata, un Glitch es un “Upsss” que no debería haber pasado y que viene de vez en cuando y un IND es “By Design” siempre que nos pregunten, aunque para nosotros mismos es un enorme bicho… de acuerdo?

Veamos algunos ejemplos en nuestro bien amado SharePoint:

1 – Situación: Una Lista en donde tienes que cambiar programáticamente los derechos de cada elemento. Como el usuario no tiene derechos para cambiar la autorización, usamos “ElevatedRights” (método delegado “CodeToRunElevated” de la clase “SPSecurity”), y necesitamos romper la herencia de derechos de la Lista utilizando el método “BreakRoleInheritance” de la clase “SPListItem”. Para que todo funcione, necesitamos además utilizar la propiedad “AllowUnsafeUpdates” de la clase “SPWeb”. Más claro no canta una gallina…


miWeb.AllowUnsafeUpdates = true;

SPList miLista = miWeb.Lists[«unaLista»];

miLista.BreakRoleInheritance(false);


Problema: Ya tenemos nuestra Lista con sus propios derechos, magnifico. Ahora hay que darle derechos diferentes a uno de sus elementos:


SPListItem miElemento = miLista.GetItemById(1);

SPRoleAssignment AsignacionRole = new SPRoleAssignment(@»NombreServidorNombreUsuario», «a@b.com», «NombreUsuario», «ninguna nota»);

SPRoleDefinition DefinicionRole = miWeb.RoleDefinitions.GetByType(SPRoleType.Contributor);

AsignacionRole.RoleDefinitionBindings.Add(DefinicionRole);

miElemento.RoleAssignments.Add(AsignacionRole);

miElemento.Update();


Creamos el elemento, creamos el role que hay que darle, le asignamos el role al elemento y lo refrescamos. Perfecto… no funciona… error que dice que “Hay que refrescar la pagina” o algo por el estilo.

Workaround: después de una hora de sudor y lagrimas resulta que por una u otra razón desconocida, al llamar el “BreakRoleInheritance” el “AllowUnsafeUpdates” se regresa a “false” solito. Así que volviéndole a meter otra vez el renglón y poniéndolo en “true” antes de hacer el update, todo funciona a la perfección. Bug, Glitch o IND? Ustedes deciden

2 – Situación: De nuevo tenemos nuestra Lista y elemento del punto 1. Ahora queremos agregarle programáticamente un Content Type. Pan comido:


SPList miLista = miWeb.Lists[«unaLista»];

SPListItem miElemento = miLista.GetItemById(1);

SPContentType miTipo = miWeb.ContentTypes[«GustavoCT»];

miElemento.ContentTypes = miTipo;


el compilador lo acepta todo, pues la propiedad espera un set del tipo “SPContentType”, que es precisamente lo que le estoy entregando…

Problema: puedes compilar pero no ejecutar. Después de maldecir como un cosaco me acorde que ya me había pasado anteriormente, y que tenía que usar las propiedades:

Workaround:


miElemento[«ContentTypeId»] = miTipo.Id;


3 – Situación: Usando las pantallas de Configuración del sitio creas un Content Type propio. Ningún problema. Creas un Field Type propio. Ningún problema. Finalmente le conectas tu Content Type y tu Field Type a una Lista existente. Ningún problema.

Problema: Ahora queremos hacer que el Content Field sea incluido en el Content Type programáticamente:


SPContentType miTipo = miWeb.ContentTypes[«GustavoCT»];

SPField miCampo = miWeb.Fields[«GustavoFT»];

miTipo.Fields.Add(miCampo);


SharePoint pega un grito de aquí al otro lado: “Esta funcionalidad no está disponible para colecciones de campos que no están asociadas a una lista”… perdón? Lo último que hice fue conectar el Content Type a una Lista… pero bueno, un Glitch tal vez… a ver lo hago manualmente usando la Configuración del sito. Ningún problema… hmmm…

Workaround: Hasta ahora no he encontrado ninguno. Y si no me equivoco, este problema existe desde que SharePoint estaba en beta…

4 – Situación: Un usuario necesita conocer algunas propiedades de otro usuario que se encuentran en la Base de Datos de Perfiles de MOSS. Usuarios tienen derechos muy limitados para este tipo de búsquedas (solo pueden ver el nombre, E-mail y algo mas), así que hay que usar un impersonador.

Problema: Ni siquiera con un impersonador que utilice derechos de administrador es posible ver la información buscada, SharePoint devuelve cada vez un “No autorizado”.

Workaround: Desde la pantalla de Administración de Servicios Compartidos del servicio que contiene la Base de Datos de Perfiles que queremos utilizar, vaya a “Permisos de servicios de personalización” y agregue el grupo de usuarios “NT AUTHORITYusuarios autenticados” con los permisos “Crear un sitio personal”, “Utilizar características personales” y “Administrar los perfiles de usuario”. Significa esto un riesgo de seguridad? Parece que no según las últimas pruebas, pero que es un Bug/Glitch/IND, de eso no cabe duda.

Como dicen que la mala suerte viene en rachas de a tres, pues mi semana me ha agotado mi provisión de errores por un buen tiempo. Espero. También hay que ser justos y decir que en los miles y miles de renglones de código del Modelo de Objetos de SharePoint son muy pocas las situaciones que se encuentran como las que les comento. Y también decir que no es muy común de hacer lo que estaba intentando hacer aquí arriba (nunca le asignas un ContentType a un elemento de una lista, por ejemplo, se lo asignas a la lista completa). Ya me desearía yo escribir código que funcione con tan pocos problemas…

Ya se nos viene otra semana nuevecita y sin estrenar… a ver que nos trae…

 


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

Yo clodeo, tu clodeas, el clodea, todos SharePointiamos

Otro termino de moda: “Cloud Computing”. Lo ves por todas partes, todo el mundo está haciendo “Cloud Computing” de la noche a la mañana. Google (por supuesto), Amazon, eBay… Microsoft lo llama de otra forma: “Software plus Services”, pero es una pura redefinición de la realidad…

Computación Nebulosa, Computando en las Nubes, Nubes Computables, como lo queramos llamar en español, no se refiere más que a una enorme batería de servidores que hacen algo, y con los que nosotros podemos “conversar” a distancia. Algo nuevo? No lo creo, pero como desde la invención del transistor no nos hemos inventado nada nuevo, tampoco era de esperar… lo único novedoso es que es el termino de moda…

Buscando una definición de “Cloud Computing” me he encontrado en la Wikipedia que es “un paradigma en donde la capacidad de cálculo se mueve desde los computadores personales o aplicaciones individuales a una “nube” de computadores. Usuarios de la “nube” solamente están interesados en obtener respuestas, y les deja de lado como se obtienen” (traducción libre). Algo nuevo? Por supuesto que no, estamos hablando de aplicaciones cliente/servidor, en donde el lado del servidor esta por ahí, en alguna parte, y hablamos con el remotamente… lo estamos haciendo desde tiempos inmemorables…

A lo que más se refiere el término, pienso yo, es que sistemas “cerrados” se están abriendo, de tal forma que nosotros, los pobres pica-código, podamos utilizarlos para conectarlos a nuestros propios sistemas. Amazon, por ejemplo, tiene probablemente la mayor Base de Datos del mundo sobre publicaciones, y ha abierto el sistema al público por medio de WebServices, de tal forma que podamos buscar y encontrar información en su sistema (http://developer.amazonwebservices.com/connect/index.jspa). Google también lo hace, eso sí, pagando (http://www.google.com/coop/cse/). Y eBay por medio de su “Developers Program” (http://developer.ebay.com/businessbenefits/aboutus/ ). Alguna vez han oído hablar de SalesForce.com (http://www.salesforce.com/platform/ )? Es una empresa (la más grande del mundo, según ellos mismos) que ofrece CRM (Customer Relationship Management) on-line; pues bien, ellos también se han unido a la nube por medio de su Developer.SalesForce (http://www.salesforce.com/developer/ ); como remarca fuera de tema, siempre me ha llamado la atención que a alguien se le ocurra poner todos los datos de sus clientes y negocios en un servidor que no es suyo, en un país que no es el suyo… imagínense que un buen día se le ocurre al presidente de Norte América que este tipo de compañías tienen que abrirle sus Bases de Datos (si es que ya no lo han hecho)… toda la información de su compañía cae así no mas en las manos de alguien a quien conoces y de quien no confías… pesadilla…

Y que hace Microsoft al respecto? Toda la familia de productos “Live”, Windows Live, Office Live, Xbox Live. Si, por supuesto, todo está muy verde todavía, pero algún día funcionaran. En Live, Microsoft mantiene los servidores (el “Cloud”, la nube vaga flotando por todas partes, las Bases de Datos llenas de información), y nos da una serie de servicios (“Windows Live Web Services”) que nos permiten crear nuestras propias interfaces (http://dev.live.com/ ). Y cuál es la relación con SharePoint? Pues bien, a nuestro SharePoint lo podríamos llamar la madre de todas las nubes…

Desde antes de que SharePoint se llamara así, cuando todavía andábamos peleando con Site Server, ya teníamos a nuestra disposición un Modelo de Objetos para charlar con el sistema. Lo concedo, no era la octava maravilla del mundo… no, en realidad era bastante primitivo… mejor dicho, era totalmente inservible, pero era algo que podríamos llamar un Modelo de Objetos… basado en COM, que por aquellos tiempos era tecnología de punta, y como la Red todavía no existía, pues no había SOAP, y todos andábamos mirando que se podía hacer con XML… que tiempos aquellos… pero bueno, SharePoint 2001 hizo algo al respecto, pero seguía siendo más o menos del mismo nivel técnico… ya me entienden: totalmente inútil. Con SharePoint 2003 la cosa cambio para mejorar: todo un API hecho y derecho e, inclusive, todo un sistema de WebServices por defecto y la posibilidad de crear los nuestros propios cuando lo quisiéramos. SharePoint 2007 ha seguido por el mismo camino, es más una evolución que una revolución en ese aspecto. Pero el punto aquí es que desde hace ya años disponemos de nuestra propia “nube”, el SharePoint que se encarga de mantener los datos, indexarlos, darnos la autenticación y autorización, de tal forma que nosotros, desde afuera, podamos crear nuestras interfaces como las necesitemos y conectar la información con otros sistemas. Que, por esas cosas de la vida, la mayoría de los sistemas SharePoint usan la interface por defecto, no es la culpa de SharePoint, es nuestra propia incapacidad que no nos deja usar la “Cloud” de una forma creativa, imaginativa…

Ah! Se me olvidaba… alguna vez les había contado que Microsoft Office Live Small Business está basado sobre SharePoint WSS 3.0?… creo que si… (http://geeks.ms/blogs/gvelez/archive/2007/04/27/microsoft-office-live-developer-portal.aspx )

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

Cuidado se electrocuta: Volta versus SharePoint

Rebuscando en la caja de sorpresas de Microsoft, me he encontrado algo intrigante: Volta. Según la descripción de Microsoft, la tecnología de Volta es “un conjunto de herramientas para desarrolladores que permiten construir aplicaciones Web multi-capa utilizando paternas y tecnologías familiares. Primero diseñe y construya su aplicación como una aplicación cliente de .NET (una aplicación Windows, con otras palabras), luego asigne las porciones de la aplicación que deben ejecutar en el servidor y en el cliente en el proceso de desarrollo. El compilador crea JavaScript (cross-browser) para la capa de cliente, servicios Web para la capa de servidor y código para comunicación, serialización, sincronización y seguridad para conectar las capas entre sí. Desarrolladores pueden crear software para navegadores Web o para el CLR, y Volta maneja la complexidad de la separación de capas para usted.”

Mejor dicho, software para perezosos. Perdón, no lo debería haber dicho. En fin, en cualquier caso es uno de los numerosos experimentos que Microsoft está haciendo en su laboratorio (http://labs.live.com/volta/ ). Lo primero que se me ocurrió cuando lo vi, fue: están preparando la cosa para eliminar del todo aplicaciones Windows… lo que tiene sentido. Desde cuando empezamos a crear aplicaciones Web, hace ya… ufffff… 13, 14 años, cada vez la balanza se inclina más y mas hacia que todo el software se ejecute remotamente desde aplicaciones Web y menos a aplicaciones Windows. Si, si, es cierto, aplicaciones Windows están muy lejos de estar muertas, y continuarán aquí por muchos años, pero si miro en mi propio computador, las aplicaciones Windows que tengo, y sin las que no podría trabajar, son Office y un editor de graficas; por el resto, si me dan equivalentes Web, quito lo que sobra para que no estorbe.

Y Office dentro de poco tampoco será necesario, Google ya tiene un equivalente on-line (malito, malito, pero es el principio), y Microsoft mismo esta intentándolo desde hace años, pero todavía no se deciden a matar a la gallina de los huevos de oro que es Office, así que probablemente se demoren todavía algún tiempo. Pero Microsoft Live va por ese camino. Me puedo imaginar muy bien que Microsoft se ha encontrado con el problema de qué hacer con todos los desarrolladores que hacen aplicaciones Windows cuando estas aplicaciones desaparezcan, y por eso empezó el proyecto Volta. Aunque suene chistoso, la mayor riqueza de Microsoft no son los usuarios que usan todas las aplicaciones Windows sino los desarrolladores que las hacen. Miren el problema de Apple, que por su tecnología cerrada no creo una base de desarrolladores amplia, y como consecuencia se quedo sin usuarios (ya estoy viendo a los tres usuarios de Macs que leen esto… nunca más van a volverme a leer…). Así que es de vital importancia que los desarrolladores Windows se conviertan en desarrolladores Web, y Volta puede hacer el milagro.

Pero como me han obligado a escribir en este sitio solamente sobre cosas que tengan relación con SharePoint, en que afecta esto a nuestra aplicación favorita?… a primera vista en nada: SharePoint ya es una aplicación Web (aunque se puede ampliar como aplicación de escritorio, que es lo que hace Groove, entre otros), es super-multi-capa, y los desarrolladores que trabajamos con él, o nos defendemos bien pensando y programando en tecnologías multi-capa, o nos dedicamos a hacer aplicaciones Windows y esperar a que Volta aparezca y nos haga el trabajo gratis… ups… otra cosa que no debería haber dicho, perdón…

Lo interesante del asunto es que SharePoint va tirando por el camino de Volta desde hace ya algún tiempo. Han visto como funciona el servidor de InfoPath (cuando funciona), de tal forma que los usuarios no tengan que tener la aplicación Windows para rellenar formularios? Y que me dicen del servidor Excel que viene con MOSS, desde el que no necesitas Excel localmente para manejar hojas de cálculo? Y no nos olvidemos de Project Server, que se ha convertido en realidad en un “Add-in” para SharePoint, y que ya no necesita un cliente Windows?. En los tres ejemplos tenemos un “pero”, pero pero’s siempre existen: tanto para crear los formularios de InfoPath, como las hojas originales de cálculo de Excel y en mucho del trabajo administrativo de Project Server tenemos que usar las versiones Windows de las aplicaciones. Pero estoy seguro que es una estrategia económica y no técnica de Microsoft: todo lo que hace InfoPath Windows, Excel Windows o Project Professional es posible de ser programado en aplicaciones Web.

Y además SharePoint tiene algo fantástico que entre muy pocas personas y nadie ha utilizado: el servidor de conversión de documentos. Este servicio es una de las cosas que más me ha gustado de MOSS desde cuando lo descubrí, aunque, como todo el mundo, nunca he hecho nada útil con él. Con la conversión simplemente se pueden crear traductores de un tipo de contenido a otro, por ejemplo, de archivos de texto a HTML, de tal forma que se puedan ver y utilizar on-line. Es otra puntada mas en dirección a abandonar las aplicaciones Windows y sus miles de formatos hacia un tipo de aplicación único (Web) y un formato único (HTML, XML, ML-lo que sea)?

Como empezar el año dramáticamente: SharePoint y el WorkFlow Foundation

Pues bien, nuevo año, nuevos desafíos, como diría mi jefe… Algo que ya había comentado en alguna oportunidad el año pasado fue sobre (“Porque hacerlo fácil si se puede hacer difícil… SharePoint Tipos de Contenido, Flujos de Trabajo y cosas de esas”) la Fundación de Flujos de Trabajo funcionando con SharePoint. Allí, entre otras cosas, les contaba sobre algunos problemas cuando se desarrollan Flujos de Trabajo utilizando Visual Studio 2005 y SharePoint como Host.

El WorkFlow Foundation es una de esas maravillas que a veces nos sorprenden de Microsoft: una compañía que mete las patas de vez en cuando (mas “en cuando” que “de vez”), y que no para de sorprendernos con cosas brillantes otras veces. La Fundación es simplemente brillante. Un FrameWork unificado para flujos de trabajo, un sueño hecho realidad. Recuerdo muy bien cuando vi la primera demostración, ya hace casi cuatro años, que no podía para de pensar en el asunto por días y días… y que apenas le pude poner las manos encima al primer Beta, que no podía parar de intentar hacer cosas con ella. Pero bueno, vamos haciéndonos viejos, más sabios y cautelosos, y la realidad de vez en cuando nos pega golpes feos a mansalva…

Primero que todo, ayer Rolf Eleveld (http://rolfeleveld.spaces.live.com/default.aspx) uno de esos buenos amigos que andan por ahí regados en el mundo ancho y ajeno de la programación, me llamo la atención sobre un posting de Eilene Hao, uno de los innumerables Program Manager de Microsoft, encargada del SharePoint WorkFlow (http://blogs.msdn.com/sharepoint/archive/2008/01/04/issues-with-the-delay-activity-in-sharepoint-workflows-we-need-your-help.aspx), en donde, finalmente, acepta Microsoft que la actividad “Delay” simplemente no funciona cuando se usa dentro de un Flujo de Trabajo de SharePoint. Finalmente… después de que Microsoft lo ha negado por arriba y por abajo… y, lo peor de todo es que nos echa la culpa a nosotros porque las cosas no salen como deberían: primero nos cuenta que tienen un fix para el problema (“..We currently have a fix that makes things better for the issues that have been reproduced internally..”), luego nos dice que el fix no nos lo quieren soltar para que lo probemos (“..This fix is not yet available through our Customer Support Services channel, so please don’t call them to ask for it just yet..”) y luego nos echa la culpa porque no lo hemos probado (“..we don’t have enough information on customer reported issues to know if the fix will address all of them..”)… brillantemente Microsofiano, Kafka estaría orgulloso de trabajar allí…

Luego, por eso de recordar buenos viejos tiempos y para no aburrirme me ha dado por ver cómo funciona Visual Studio 2008 y el Service Pack 1 de SharePoint con el asunto de los Flujos. Si se instalan las herramientas para Office con Visual Studio 2008, se instalan automáticamente dos plantillas para crear Flujos (una para Secuenciales y otra para Estado de Maquina). Lo simpático es que las plantillas también pueden configurar la versión local de SharePoint para usar el nuevo Flujo:

  

Idealmente… el campo “local site” esta (casi) bien: la plantilla encuentra el nombre del servidor sin problemas, pero la Librería “Docs” no existe… el trabajo ha sido casi bien hecho… por supuesto, al intentar usar la librería por defecto sale un mensaje de error (porque no usar la Librería “Documentos Compartidos” que siempre está instalada?)… en fin, luego de corregir el asunto, la plantilla muestra una pantalla con las Librerías presentes… (entonces para que era el “Docs”?). Lo malo de la nueva pantalla es que la lista de Librerías no está filtrada para NO mostrar las Librerías invisibles (“Hidden”), así que podríamos asociar el Flujo a la “List template Gallery”, o a la “Web part Gallery”, etc.

Pero bueno, escogemos una de las Librerías correctas, el código se genera, produce inclusive el código para la Característica, así que sin agregar nada nuevo intentamos compilar… error… era casi de esperarse… la plantilla incluye una referencia al “Microsoft.Office.Workflow.Tasks” dll, que (parece que Microsoft no se ha dado cuenta) es un compilado de MOSS, no de WSS… así que la plantilla está hecha para MOSS, y los que trabajan con WSS que se j… perdón, se me escapó…

Bueno, no hay problema, el año está empezando, y todos estamos de buen genio (o no), así que quitamos la referencia equivocada, arreglamos el código y lo ponemos bonito para que compile bien, y, en efecto, podemos generar el compilado. Luego, para aprovechar la Característica creada automáticamente, vamos a las propiedades del proyecto -> “Deploy” y… redoble de tambor… error… casi que lo estábamos esperando… el mensaje de error es claro: “Could not load file or assembly ‘Microsoft.Office.Workflow.Feature, Version blablabla or one of its dependencies”… sh… perdón, se me volvió a escapar… por una u otra razón incomprensible, al genio que creó la plantilla no le contaron que existe WSS, y le pareció muy bonito utilizar un “ReceiverAssembly” y “ReceiverClass” de MOSS en la declaración de la Feature, totalmente innecesaria si lo único que queremos es instalar el (mal)bendito Flujo en una Librería…

Bueno, empezamos bien el año, con optimismo y esperanzas. Aunque todavía me sigo preguntando porque el creador de una cosa tan brillante ha hecho que la plantilla compile para el FrameWork 3.5… si no me equivoco, SharePoint, aun después del SP 1 sigue funcionando con el 3.0… con seguridad una pequeña equivocación…

PS: Uno de mis promesas para el nuevo año ha sido ser más cariñoso y comprensivo, y menos duro con lo que escribo sobre Microsoft. Como han visto, yo siempre cumplo lo que prometo.


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