Mes: abril 2012

Cuando desde SharePoint designer queremos trabajar con cadenas de URLs complejas que emplean múltiples parámetros es necesario tener en cuenta el siguiente TIP:

Los parámetros en una URL son incorporados mediante el símbolo «&«, si nosotros construímos una URL empleado el símbolo «&» obtendremos un mensaje de error en nuestro Dataview, para resolverlo debemos concatener nuestra URL reemplazando «&» por «&«. Este problema es frecuente cuando construímos URLs complejas con la de un Formulario de InfoPath Forms Services.

Aquí les presente un ejemplo de una URL de InfoPath Forms Services:

«<a href=»{concat(‘http://intranet.contoso.com/soluciones/gestiondocumental/_layouts/FormServer.aspx?XsnLocation=http://intranet.contoso.com/soluciones/gestiondocumental/FormServerTemplates/DRTransmittalsReceived.xsn’, ‘&amp;’ , ‘SaveLocation=http%3A%2F%2Fintranet%2Econtoso%2Ecom%2Fsoluciones%2Fgestiondocumental%2FPlantillas%20de%20Relaciones’, ‘&amp;’ , ‘ClientInstalled=true’, ‘&amp;’ , ‘Source=’, @RutaAcceso , ‘&amp;’ , ‘DefaultItemOpen=1’, ‘&amp;’ , ‘docCode=’, @Document_x0020_Code, ‘&amp;’ , ‘docPath=’ , @RutaAcceso)}»>Relacionar</a>»

 Espero les haya sido de ayuda!

Cuando trabajamos con InfoPath y múltiples conexiones de datos, a veces es necesario enviar cierta información del formulario hacia una lista separada sin tener que enviar todo el formulario completo, esto podría ser empleado como una especie de log.

Para lograr esto, es necesario implementar código mediante VSTA. Una guía paso a paso la podrán encontrar en el siguiente enlace:

http://www.bizsupportonline.net/infopath2007/how-to-submit-items-rows-repeating-table-infopath-sharepoint-list.htm

 Muchas veces cuando trabajamos con site columns aplicados a listas o bibliotecas y sobre esta se aplican workflows, hay ciertos campos requeridos por el workflow para consulta o actualización que no deberían mostrarse a los usuarios en los formularios de «Nuevo registro» o «Actualización» de un elemento.

Si es que nosotros configuramos un campo para que este sea oculto, no se resuelve el problema debido a que a través del workflow no es posible acceder a estos campos.

Una solución práctica es incorporar una lógica de javascript sobre nuestro formularios, que oculte los campos a la vista del usuario.

En el siguiente enlace se explica paso a paso como lograr este resultado.

http://sharepointsherpa.com/2008/08/26/sharepoint-2007-hiding-fields-on-newformaspx-and-editformaspx-the-easy-way/

El javascript es el siguiente:

<script language=«javascript» type=«text/javascript»>

_spBodyOnLoadFunctionNames.push(«hideFields»);

function findacontrol(FieldName) {

   var arr = document.getElementsByTagName(«!»);
   // get all comments
   for (var i=0;i < arr.length; i++ ) { // now match the field name
      if (arr[i].innerHTML.indexOf(FieldName) > 0)
      {         return arr[i];      }
   }
}

function hideFields() {

   var control = findacontrol(«Title»);
   control.parentNode.parentNode.style.display=«none»;
   control = findacontrol(«Document Link»);
   control.parentNode.parentNode.style.display=«none»;
   control = findacontrol(«PublishDate»);
   control.parentNode.parentNode.style.display=«none»;

}
</script>

El javascript se debe insertar entre las etiquetas <asp:Content ContentPlaceHolderId=»PlaceHolderMain» runat=»server»> y </asp:Content>

Un procedimiento muy común cuando trabajamos en proyectos de SharePoint 2007 es el realizar backups diarios de lo trabajado. Cuando expecíficamente trabajamos con subsites de nuestra colección de sitios no existe un comando específico de backup, el proceso es en realidad llamado «Exportación» y la restauración es llamada «Importación».

Por lo tanto para ejecutar backups y restores de nuestros sitios de MOSS 2007 deberemos ejecutar los siguiente comandos:

Para exportar el sitio:

STSADM.EXE –o export –url “http://miurlsitio” –filename “mirutabackup.cmp”.

Para importar el sitio:

STSADM.EXE –o import –url “http://miurlsitio” –filename “mirutabackup.cmp” 

 

Debido a la gran acogida que ha tenido la nueva versión de SharePoint «SharePoint 2010», muchas empresas han decido adquirir esta plataforma de soluciones, mientras que muchas otras que ya venían trabajando con la versión 2007 han decidio ir migrando progresivamente sus soluciones con la finalidad de poder aprovechar las nuevas y variadas ventajas que ofrece la última versión.

Existen 2 formas de migrar la plataforma MOSS 2007 hacia SP 2010: In-Place Upgrade y Database Attach Upgrade.

La mas ordenada y recomendada por mí es el procedimiento de Database Attach Upgrade que consiste en los siguientes pasos:

1. Implementar una nueva granja de servidores de SharePoint 2010 (Previo dimensionamiento).

2. Realizar un inventario de las soluciones implementadas sobre MOSS 2007 y limpiar los sitios y contenido que «basura».

3. Ejecutar un backup de Base de datos de el/los site collection(s) que deseemos migrar.

4. Restaurar el backup en la nueva granja.

5. Ejecutar comando de migración y LISTO!.

No es muy complicado pero es recomendable realizar este procedimiento con cuidado. La ventaja es que sigues mantenimiento tu granja MOSS 2007 sin alterarla y trabajas con una copia separada de tu contenido para migrarlo.

Algunos enlaces interesantes que los guiarán paso a paso en el procedimiento:

http://community.bamboosolutions.com/blogs/sharepoint-2010/archive/2010/11/02/sharepoint-2010-cookbook-migrate-a-sharepoint-2007-site-to-sharepoint-2010.aspx

http://www.social-point.com/migrating-a-sharepoint-2007-blog-to-2010-part-1

Cuando implementamos soluciones sobre SharePoint y nos vemos en la necesidad de construir funcionalidad que requiere de extender la plataforma mediante código, se nos presenta la problemática del despliegue de estas soluciones hacia un ambiente productivo.

Cuando desarrollamos sobre SharePoint 2010, necesitamos que en nuestro ambiente de desarrollo tengamos instalado Visual Studio 2010 y al desarrollar componentes como WebParts o Workflows se generán una serie de archivos, entre ellos el Feature y el archivo de solución .wsp.

Al ver la carpeta de nuestra solución vemos una serie de subcarpetas. Las que nos interesan son la carpeta Features y la carpeta bin

En la carpeta Features veremos a los archivos de características, estos se instalan directamente en nuestros servidores de SharePoint para habilitar la funcionalidad requerida sobre los site collections.

 Dentro de la carpeta bin en la subcarpeta Debug encontraremos el archivo que realmente necesitamos llevar a nuestro ambiente productivo. Este archivo es el .wsp que puede ser desplegado a nivel de granja o solo para un site collection específico (sandbox) esto depende de como hallamos desarrollado nuestra solución.

 Cuando instalemos la solución en Producción solo nos quedará activar la característica asociada y Listo!!! trasladamos nuestra solución al nuevo ambiente.

Si nuestra solución incluía workflows estos aparecerán en la lista para reutilizarlos.

Una queja muy común que tenemos cuando implementamos una granja de SharePoint 2010 es que al iniciar el día cuando los usuarios consultan el portal este se demora mucho en cargar. Esto es común debido a que automáticamente el IIS reinicia el application pool cada cierto tiempo con la finalidad de liberar recursos de nuestros web front ends.

Dado que es algo que no deberíamos cambiar pues es una buena práctica que se reciclen los application pools, una recomendación es utilizar scripts que inicien en cache las URLs que especifiquemos y de esta manera no se notará la lentitud que se experimente generalmente.

Les aconsejo leer este artículo que los proporciona inclusive el script y los pasos de configuración: http://www.bybugday.com/Lists/Posts/Post.aspx?ID=24

Aquí les comparto un excelente enlace para aprender paso a paso a desarrollar workflows sobre SharePoint 2010 mediante Visual Studio 2010:

http://sergeluca.wordpress.com/2011/01/06/step-by-step-tutorial-creating-workflows-for-sharepoint-2010-step-115/

Podrán seguir un total de 15 tutoriales para construir workflows para aquellos que recién están empezando, totalmente recomendable.