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.
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
Uno de los problemas más frecuentes al realizar backups y restores de sitios y/o aplicaciones de Sharepoint son los debidos a los parches, actualizaciones y demás sutiles diferencias que puedan existir entre nuestros entornos. Estos mensajes de error siempre contienen un número de versión, del estilo de 12.0.0.6129, por ejemplo, que nos indica el mínimo de elementos que debemos tener instalados en el entorno de despliegue, incluyendo service packs, hotfixes y demás actualizaciones.
En estos dos enlaces, podemos ver información actualizada sobre los números de versión. Una ayuda inestimable para descifrar el número del error y saber qué tenemos que instalar para que la restauración tenga éxito.
How to find the level of SharePoint you are running
http://blogs.msdn.com/josrod/archive/2008/11/03/latest-patches-11-2008.aspx
En cualquier caso, lo bueno es que a partir de hace un mes todos los Cumulative Updates incluirán un paquete con todos los hotfixes publicados hasta la fecha, de manera que si creamos un nuevo servidor de MOSS, con integrar el service pack más reciente, el último Cumulative Update de WSS y el Cumulative Update más reciente deMOSS, estaremos completamente actualizados.
O eso al menos dice la teoría.
960010 - Windows SharePoint Services 3.0 cumulative update package (WSS uber-package): December 16, 2008 (download here)
960011 - SharePoint Server 2007 cumulative update package (MOSS uber-package): December 16, 2008 (download here)
Saludos