blog counter
May 2008 - Artículos - SkunkWorks

May 2008 - Artículos

BizTalk Services y SharePoint

Hace un par de semanas Microsoft ha liberado el “Microsoft BizTalk Services”. Según el boletín de prensa de Microsoft mismo, “...The new BizTalk Relay Services facilitate the traversal and bridging of physical networks, enabling high-fidelity interconnection between cooperating systems for cross-organizational messaging behind firewalls...” ... lo que en realidad son 26 palabras que no dicen nada...

Veamos: BizTalk Services viene del “BizTalk Labs” (http://biztalk.net/) que es tres cosas: Identity Services para poder identificar quien es quien y arreglar otras cosas de identificación internamente (con AD, por ejemplo), Connectivity Services para manejar “mensajes” a lo largo de redes y el BizTalk Labs SDK para podernos enterar como ponerlo todo junto.

Como dice el sitio del BizTalk Labs, esta es una pieza del “Bus de Servicios de Internet” (http://biztalk.net/Overview.aspx) que no es más que una manera para interconectar aplicaciones distribuidas... ya nos vamos entendiendo...

BizTalk ha sido siempre el servidor “negociador” de Microsoft: si es necesario conectar un sistema cualquiera con otro sistema cualquiera, BizTalk es el pegante que los puede llevar a que conversen juntos, y, sobre todo, a que se entiendan. Personalmente, BizTalk es como el primer amor de juventud, del que siempre sigues enamorado, pero que desafortunadamente nunca funciono como debería. No es que no ame a SharePoint, ese el amor con el que vivo cotidianamente, sino que BizTalk siempre me ha gustado poderosamente sin que nunca haya tenido la oportunidad de hacer proyectos serios con él. Y ese el drama de BizTalk también: hasta ahora ha sido un servidor muy poderoso, pero también muy difícil de implementar y programar, que necesita recursos físicos demasiado grandes (12 Bases de Datos, si no me acuerdo mal, para una instalación por defecto), y que siempre ha sido demasiado costoso. Todo eso junto significa que mientras hay clientes haciendo fila para crear sistemas con SharePoint, BizTalk hay que metérselo por las narices a la fuerza a nuestros clientes para que lo acepten...

A ver si BizTalk Services alivia los problemas. BizTalk Services (http://www.microsoft.com/biztalk/en/us/soa.aspx) nos permiten usar BizTalk sin tener que hacerle el hosting, sin tener problemas de uso en ambientes mezclados (intranet-extranet, problema que siempre se tiene con una instalación propia de BizTalk, la que cuesta infinita cantidad de problemas para hacerla pasar a través de FireWalls) y sin tenernos que preocupar por instalación, mantenimiento y todas esas cosas que nosotros, los pobres pica-código, no tenemos ganas ni paciencia para hacer (ni, la verdad sea dicha, los conocimientos técnicos para hacerlo bien hecho).

Todo funciona por medio de SOA, es decir, por medio de WebServices. Un sistema en cualquier parte del mundo (o al lado de nuestro escritorio, qué más da) necesita datos de otro sistema en cualquier otra parte del mundo (o en el mismo servidor, da igual), los procesa y se los entrega a otro sistema, ustedes ya saben en donde... El problema es que cada uno de los sistemas espera/entrega los datos de una manera diferente... BizTalk es el “negociador” que convierte los datos de un sistema para que el otro los entienda, y luego recoge los datos procesados para “trasladarlos” en la forma que el siguiente proceso también pueda hacer algo con ellos, y el siguiente, y el siguiente. Y entre proceso y proceso se queda esperando pacientemente, manteniendo el estado de todas las transacciones, enviando mensajes si es necesario, preparando café y desayuno cada mañana, avisando a qué hora es la próxima cita con el dentista, etc... (Bueno, las dos últimas cosas pueden ser un poquito exageradas, pero ustedes ya entienden por donde va el agua al molino).

Y todo esto es simplemente estupendo para SharePoint. Con los Flujos de Trabajo del WorkFlow Foundation y el Business Data Catalog se pueden hacer un montón de cosas bonitas, pero una de las limitaciones que SharePoint siempre ha tenido (aunque la situación ha mejorado notablemente con la versión 2007) es que es un servidor terriblemente egocéntrico: toda su información tiene que estar en sí mismo, y conectarlo con el mundo exterior nunca ha sido fácil. Con un sistema de BizTalk que no sea costoso ni difícil de utilizar se pueden mejorar radicalmente los rasgos autistas de SharePoint, y hacerlo comunicar con todo ese mundo de datos que existen fuere de él. Las posibilidades son múltiples: sistemas Back-Office con datos de cualquier tipo que se pueden presentar en el Portal, automatización de flujos de documentos e información (en lo que SharePoint es grande) proveniente del mundo externo, envío de datos contenidos en SharePoint a sistemas fuera de el, el cielo es el limite... de pronto el primer amor se junta con el amor cotidiano en un trío incestuoso...

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

Publicado por Gustavo Velez con 3 comment(s)
Archivado en:

La pesadilla de SPWebConfigModification, o como perder el sueño debido a SharePoint

Para un proyecto en el que estoy trabajando en el momento, es necesario modificar diferentes configuraciones del archivo web.config de una manera automatizada. El problema es que un administrador de sistemas podría eventualmente hacer las modificaciones, pero no se le puede pedir a nadie que haga los mismos cambios una y otra y otra vez en toda una granja de servidores sin cometer errores involuntarios y sin que la persona se frustre tan terriblemente que comience a cometer errores voluntariamente...

El modelo de objetos de SharePoint 2007 nos ofrece una excelente posibilidad para solucionar el problema: la clase SPWebConfigModification. En principio, con un par de renglones de código es posible hacer modificaciones de cualquier sección (inclusive agregar nuevas secciones) en el archivo web.config de SharePoint, con la ventaja adicional de que cuando el código ejecuta, SharePoint propaga los cambios en todos los servidores de la granja, sin tener que hacerlo uno por uno manualmente. En el caso en el que yo lo utilizo, los cambios son realizados dinámicamente desde una aplicación, pero el sistema es ideal para realizar modificaciones en la instalación de componentes, pues el código se puede agregar al evento de una Característica, de tal forma que los nuevos componentes se encarguen de hacer las modificaciones en el web.config por sí mismos.

Pues bien, el primer “inconveniente” es que Microsoft ofrece información mínima (SDK) sobre la clase y su utilización. Pero siguiendo el sencillo ejemplo que el SDK nos da, se pueden hacer algunas cosas pequeñas, como agregar un “SafeControl” en el web.config (tomado del SDK):

 

SPWebService myService = SPWebService.ContentService;

SPWebConfigModification myModification = new SPWebConfigModification();

myModification.Path = "configuration/SharePoint/SafeControls";

myModification.Name = "SafeControl[@Assembly='MyCustomAssembly'][@Namespace='MyCustomNamespace'][@TypeName='*'][@Safe='True']";

myModification.Sequence = 0;

myModification.Owner = WebConfigModificationFeatureReceiver.OwnerId;

myModification.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode;

myModification.Value = "<SafeControl Assembly='MyCustomAssembly' Namespace='MyCustomNamespace' TypeName='*' Safe='True' />";

myService.WebConfigModifications.Add(myModification);

myService.Update();

myService.ApplyWebConfigModifications();

 

Aquí se usan un par de propiedades, “Sequence” (probablemente para indicar la posición en la modificación) y “Type” que no están documentadas. La segunda es una enumeración (“EnsureChildNode”, “EnsureAttribute” y “EnsureSection”) que probablemente tiene que ver con el tipo de “Node” en el XML de la web.config. Pero después de experimentar un montón, se puede ver que tiene otra función: cualquiera de los tres valores se puede usar para crear entradas, pero si se crean con “EnsureSection” es imposible después eliminarlas, lo que sí se puede hacer si se usa “EnsureChildNode”.

Por otra parte, secciones se pueden crear fácilmente, pero no es posible eliminarlas (o por lo menos yo no pude encontrar como), por lo que lo único que se puede hacer es crear la sección, luego crear la entrada dentro de la sección, y esta ultima si se puede eliminar, dejando la sección vacía.

Otro problema al crear secciones es que frecuentemente son creadas dobles, inclusive si el código ejecuta una sola vez. Después de mucho pelear con el asunto parece que se debe al método “Update”: si se elimina, la sección es creada correctamente, de otra forma es creada doble. A pesar de lo que el SDK diga, parece que este método no es necesario para nada, y se puede quitar sin problemas.

Uno más: el método “ApplyWebConfigModifications” se puede llamar desde dos clases, “miAplicacionWeb.Farm.Services.GetValue<SPWebService>().ApplyWebConfigModifications();” (en donde “miAplicacionWeb” es un objeto creado anteriormente, del tipo “SPWebApplication”) o “SPFarm.Local.Services.GetValue< SPWebService>().ApplyWebConfigModifications();”. Por una u otra razón que solamente Microsoft conoce (o no), los dos métodos funcionan perfectamente igual en una granja de un solo servidor, pero solamente el primero en granjas con más de un servidor (es decir, las modificaciones no son propagadas utilizando el segundo método); tiene que ver con lo de “Local”? ... ni idea... yo pensaba que se trataba de la “granja local”, no del “servidor local”... Increíble, pero encontrar algo así ha costado horas de sudor y lagrimas: después de crear el software en una maquina de desarrollo (un solo servidor) y probarlo y requeteprobarlo, se pasa a usarlo en una granja y no funciona... y vete tú a saber porque...

Finalmente, algo que te dan ganas de reír (aunque solo sea porque me he quedado sin lagrimas después del fin de semana): el método “se cansa” de trabajar. Por alguna razón de esas que probablemente se quedaran entre los misterios nunca descifrados, como la existencia de UFOs, o el tamaño de la nariz de Cleopatra, después de crear cientos de versiones del código y probarlas miles de veces en un computador de desarrollo, el archivo web.config simplemente se rebeló y no aceptó ningún otro tipo de modificaciones, incluso utilizando versiones del software que una hora antes habían funcionado perfectamente. Y no hay forma de que vuelva a funcionar, iisreset, reset completo del servidor, eliminar el web.config y volverlo a crear, nada, nada hace que el asunto vuelva a funciona... simplemente el programa no le da la gana de funciona más. Mi sospecha es que los cambios son guardados en alguna parte en la Base de Datos de SharePoint (en la de configuración?), y después de realizar unos cuantos cientos de cambios, el record (o buffer, o lo que sea) se llena, y no deja crear más modificaciones. Esto no es un gran problema si la modificación del web.config solamente tiene que ocurrir una vez, o un par de veces en toda la vida productiva del Portal. Pero mi programa necesita hacer modificaciones relativamente frecuentes, así que si el “buffer” es de unos cuantos cientos de modificaciones, el software dejara de funcionar en el Portal en donde se va a utilizar dentro de unos cuantos meses...

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

Publicado por Gustavo Velez con 2 comment(s)
Archivado en:

SharePoint en la Educación

Hace una semana se realizó el primer encuentro de partners de Microsoft LATAM para la Educación. Más de 200 participantes estuvieron (estuvimos, yo fui el encargado de las conferencias técnicas sobre SharePoint) discutiendo sobre el tema y viendo y analizando las iniciativas de Microsoft en la Educación para definir nuevas estrategias y mercados.

Lo que me llamo más la atención es el poco uso que los partners de Microsoft en LATAM le están dando a SharePoint como herramienta de información en la Educación. Muy pocos de los participantes están realizando proyectos en el momento al respecto e, inclusive, aunque todo el mundo conocía a SharePoint y sus posibilidades, no muchos lo están utilizando en su vida comercial cotidiana. La mayoría de las preguntas que me dirigieron a mí particularmente estaban más encaminadas a la utilización/implementación/beneficios de SharePoint en general, que sobre su uso para la Educación.

Microsoft tiene cuatro iniciativas principales sobre Educación:

live@edu (http://get.liveatedu.com/Education/Connect/ ): un servicio de hosting de Microsoft que proporciona a instituciones educativas toda la infraestructura necesaria para E-mail (Exchange) y espacios colaborativos (SharePoint) sin necesidad de tener que manejar problemas técnicos ni administrativos. Ideal para colegios o cualquier otro tipo de institución educativa con hasta algunos cientos de usuarios, por un precio realmente competitivo.

Learning Gateway (http://www.microsoft.com/Education/LearningGateway.mspx ): parecido a live@edu, incluyendo el uso de portales basados en SharePoint, pero para instituciones con mayor cantidad de usuarios, y que incluye todas las herramientas necesarias para incrementar la participación de no solo estudiantes y profesores, sino los padres de los estudiantes y la administración de la institución.

SharePoint Learning Kit (SLK) (http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=art&itm=524 y http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=art&itm=525 ): un Add-In para SharePoint que permite el manejo de paquetes educativos según el estándar SCORM, y permite el control de parte de profesores sobre el avance de sus estudiantes en cada materia. El SLK es un proyecto Open Source, completamente gratis y del que incluso se puede descargar el código fuente si se desea.

Grava (https://connect.microsoft.com/Grava?wa=wsignin1.0 ): es un editor y visor de contenido para la educación de Microsoft, que existe desde hace algún tiempo, pero que todavía está en Beta y no ha sido comercializado aun.

De los cuatro, solamente Grava no está (todavía) integrado o usa intrínsecamente a SharePoint. De allí la sorpresa que les comentaba. Durante horas y horas (de hecho, durante tres días seguidos), estuvimos discutiendo sobre las oportunidades sociales y comerciales que estos productos ofrecen, y, por mi parte, intentando recalcar constantemente que SharePoint es el centro de todo, por lo que si no se tienen conocimientos sobre SharePoint, se pueden perder oportunidades muy valiosas.

Aunque estamos hablando sobre Latinoamérica en particular, lo mismo se puede decir sobre España, Portugal y el sur de Europa: las oportunidades para utilizar a SharePoint en la Educación son prácticamente infinitas, por una gran parte aun no descubiertas o inventadas, y, por supuesto, increíblemente subutilizadas... si solamente pensamos que con un servidor de un par de cientos de dólares, y otros cuantos cientos en software se puede crear todo un ambiente de WSS para colaboración, correo electrónico y acceso a Internet para una escuela de educación básica de unos cientos de estudiantes, nos podemos imaginar muy bien lo que puede hacer un sistema más grande para una universidad o escuela superior...

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

Publicado por Gustavo Velez con 1 comment(s)
Archivado en: