aelena.com

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

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

Una pequeña advertencia. En muchas ocasiones queremos llamar a una fuente de datos externa al abrir un formulario de InfoPath hospedado en MOSS, y puede ser que se nos ocurra hacer esta llamada desde dentro del evento InternalStartup del formulario.

En mi caso, se trata de un formulario diseñado originalmente en blanco y en el que las llamadas a los servicios web que actúan como fuentes externas de datos se realizan “manualmente” desde código en el proyecto VSTO asociado al formulario. No se trata de un formulario creado con conexión directa a servicios web ni nada.

Sin embargo, si hacemos uso del evento InternalStartup, tendremos problemas a la hora de subir el formulario a MOSS, que nos dará un par de mensajes de error, que aunque crípticos, como es habitual en MOSS, nos apunta un poco en la dirección correcta.

Los mensajes son:

No se admite esta operación en este momento, que no ayuda demasiado cuando no se sabe de qué se trata, y Error en el método InternalStartup del código del formulario, que si que apunta un poco mejor en la dirección de la naturaleza del error.

Así pues, la solución pasa por no hacer nada dentro de InternalStartup, cuya única función es enlazar controles con sus eventos, y hacer uso del evento Loading, manejado desde FormEvents_Loading para realizar nuestras llamadas manuales a fuentes externas de datos. Creamos el evento dentro del proyecto de código VSTO mediante el menú de Herramientas -> Programacion -> Evento Loading.

Dentro de ese evento, ya podemos realizar todas las llamadas que queramos a fuentes externas. Y si todo va bien, podremos subir el formulario a MOSS tranquilamente.

La curiosidad reside en que si lanzamos el formulario en local, es decir, lanzando en modo depuración el proyecto VSTO del formulario, el código residente en el evento InternalStartup se ejecutará sin problemas y sin advertencia alguna. El problema solamente se manifiesta a la hora de publicar en MOSS.

Saludos