Recientemente he tenido que hacer algunas customizaciones para MOSS con jQuery, y he acabado conociendo la existencia de una interesante librería que combina ambos mundos. Es la jQuery Library for SharePoint Web Services que podemos encontrar en CodePlex.
La descripción lo dice todo:
This is a jQuery library which abstracts SharePoint’s Web Services and makes them easier to use. It also includes functions which use the various Web Service operations to provide more useful (and cool) capabilities. It works entirely client side and requires no server install.
Una herramienta muy interesante a tener en cuenta en el futuro.
Si quereis depurar un workflow de MOSS que despierta al recibirse un correo en la biblioteca a la que el workflow está asociado, debereis adjuntar el depurador de Visual Studio no contra w3wp.exe sino contra el timer de MOSS, OWSTimer.exe. Y es que aunque MOSS corra sobre la infraestructura de ASP.Net, este proceso es el encargado de enviar notificaciones y realizar tareas programadas para Windows SharePoint Services, y se ve que la gente del equipo de desarrollo de MOSS decidió programar una tarea cuando llega un correo y correr con w3wp.exe cuando se cargan elementos a mano en una biblioteca.
Es decir, según la funcionalidad que queramos probar (1. Un WF que arranca con un correo y 2. un WF que arranca al añadir manualmente un nuevo elemento en una biblioteca), el escenario de depuración será diferente, ya que la forma de ejecutar estas tareas será distinta.
Además esto implica que si queremos leer parámetros de configuracion de un web.config como estamos acostumbrados a hacer desde una webpart o un desarrollo web normal, esta operación fallará cuando el encargado de despertar el WF sea OWSTimer.exe, ya que este proceso no sabe nada del web.config que tengamos en el directorio de nuestra aplicación web o site. De manera que no queda otra que tener la configuración en un XML aparte, o base de datos, u otra alternativa, como un servicio web quizás, para hacer nuestro escenario un poquito más SOA y desacoplado.
Eso sí, de vez en cuando el Visual Studio decidirá cerrarse. Supongo que para que esto de desarrollar para MOSS no se convierta en algo demasiado agradable o cómodo. ;P
Es posible además que cuando esto ocurra, luego el proceso no aparezca, y es porque se habrá caído el propio servicio de MOSS. Entonces, abrimos las Herramientas Administrativas, vamos a Servicios, y buscamos Windows SharePoint Services Timer. Lo volvemos a levantar y a depurar de nuevo.
Saludos
Algunas alternativas más baratas a MOSS y que pueden servir para pequeños grupos de trabajo que no necesiten todas las capacidades de este producto:
Otra cosa es que cada uno encuentre lo que busca en cada una de estas ofertas y cómo de complicado sea customizarlos y hacer que estos productos se ajusten a las necesidades de cada empresa, que variarán mucho en función de tamaño, necesidades documentales, requisitos legales, etc.
El equipo de MOSS nos detalla y concreta los updates para una actualización completa de un entorno MOSS. Los distintos paquetes y el orden en el que deben ser actualizados. Igualmetne tienen el detalle de indicar el número de versión resultante (12.0.6504.5000), muy útil para conciliar problemas que pueda haber con operaciones de backup / restore.
El artículo aquí.
Para acceder al XML de una lista de MOSS del navegador tenemos que introducir una ruta como esta:
http://miservidor/[sitio]/_vti_bin/owssvr.dll?Cmd=Display&List={GUID de la LISTA}&XMLDATA=TRUE
Para poder lanzar esta ruta primero necesitamos averiguar el GUID de la lista. Esto lo podemos hacer desde la propia administración de SharePoint o también con un programilla que consulte el modelo de objetos de MOSS.
Vamos a ver la primera opción.
Nos dirigimos a la página de configuración donde tenemos las listas de nuestro sitio. Elegimos aquella cuyo XML queramos ver. En la siguiente pantalla, la de administración de la propia lista, pinchamos con el botón derecho en el enlace que dice “Título, descripción y exploración” y copiamos la URL.
De esa URL nos tenemos que quedar con todo lo que venga detrás del parámetro List del QueryString. Ahi tenemos el GUID, pero está codificado (htmlencoded). Afortunadamente, hay muchas páginas como esta para descodificar el GUID. Descodificamos el GUID y copiamos el resultado.
Con eso ya podemos lanzar la URL del principio y ya tenemos con un simple HTTP GET, el XML de nuestra lista.
Adicionalmente, tenemos también un parámetro llamado Query que nos permite indicar qué campos queremos retornar en el XML independientemente de la definición de la lista. Si por ejemplo, solo queremos traer los campos Titulo y Estado, añadiríamos esos campos separados por espacios (y debidamente codificados -urlencoded-) tal que así “&Query=Titulo%20Estado“.
Más en URL Protocol o en Using the URL Protocol en el MSDN.
Hoy estaba escribiendo una webpart que inyecta codigo html “normal y corriente,” es decir, estático y no asp.net ni nada, y estaba intentando hacer uso de un atributo usemap para crear un mapa de imágen. Como sabeis, este atributo indica el mapa a usar de la siguiente manera:
USEMAP="#map1"
Pues bien, al estar acumulando todo el codigo que iba a inyectar en el evento Render (protected override void Render) en un StringBuilder, cuando finalmente la webpart mostraba el contenido, la almohadilla, o hash, había quedado sustituída por el clásico “&”, con lo que evidentemente no me funcionaba el mapa de la imagen.
Así que la cosa está clara, no se debe usar un StringBuilder sino hacer uso de los métodos como write propios del HtmlTextWriter que nos brinda el evento Render, para evitar este tipo de problemas. Hacer uso de HtmlEncode o del código # no sirve de nada.
Saludos
Un buen día vais a mirar algo en los logs de texto de MOSS y os encontrais que solamente hay entradas como esta:
02/18/2009 13:01:17.03 wsstracing.exe (0x0900) 0x0934 ULS Logging Unified Logging Service uls1 Monitorable Tracing Service lost trace events. Current value 35.
Son cosas de nuestro adorado MOSS, a veces deja de registrar los eventos y los pierde. En ocasiones estos mensajes son un preludio al cese total de la actividad de registro de eventos.
La solución pasa por reiniciar el servicio de tracing de MOSS, bien desde la consola de servicios de las Herramientras Administrativas, bien mediante línea de comando:
net stop “Windows SharePoint Services Tracing”
net stop “Windows SharePoint Services Tracing”
Con esto, la cosa debería quedar resuelto salvo que os encontreis con esta respuesta al intentar hacer el stop:
No se puede controlar el servicio en su estado actual.
Puede obtener más ayuda con el comando NET HELPMSG 2189.
En este caso, lo más recomendable es reiniciar la máquina, sobre todo si pasados unos minutos, como reza el mensaje 2189, la problemática persiste. Eso, o buscar la causa del bloqueo, que puede llegar a ser como buscar una aguja en el clásico pajar.
Saludos
Ayer en el blog del SharePoint Product Group se anunciaba la disponibilidad de la CTP de las extensiones para Sharepoint para Visual Studio 2008, descargable desde aqui. Para no repetirnos, las mejoras que aportará este CTP se pueden ver en el anuncio original del blog del SharePoint Product Group.
Saludos