jump to navigation

Navegar por el modelo de objetos de SharePoint 06/22/2007

Posted by dquirozo in SharePoint.
2 comments

Inspirado en mis dudas sobre que es un sitio, un subsitio, una colección de sitios, una lista, etc., etc., dentro del modelo de objetos de SharePoint expongo a continuación mi idea de la relación de estos elementos con los diferentes objetos del modelo (basado en la V3 de SharePoint Services).

El codigo se centra en bajar jerárquicamente a través del modelos de objetos y obtener:

1. Los nombres de cada Sitio dentro de una Colección de Sitios
2. Las Listas conteniddas en cada Sitio
3. Los Items contenidos en cada Lista

Comenzamos.

// Especificamos la dirección URL de la:
// COLECCION DE SITIOS

SPSite ColeccionDeSitios =
new SPSite(http://sharepoint.portal.com);

// De nuestra colección de sitios obtnemos el :
// SITIO DE NIVEL SUPERIOR

SPWeb SitioNivelSuperior = ColeccionDeSitios.OpenWeb();

// Para acceder a cada Web (Sitio) de nuestra colección,
// añadimos los Webs a una :
// COLECCIÓN DE SITIOS WEB
SPWebCollection ColeccionDeWebs = SitioNivelSuperior.Webs;

// Mostramos en pantalla los nombres de las Webs
// dentro de la colección
foreach (SPWeb Webs in ColeccionDeWebs)
{
     Console.WriteLine(” – SITIO : ” + Webs.Name);

     // Creamos un objeto independiente para cada Web
     // de la colección y obtenemos así un :
     // SITIO WEB

     SPWeb UnSitio =
     ColeccionDeSitios.OpenWeb(“/” + Webs.Name);

     // Para acceder a cada List (Lista) de nuestro sitio,
     // añadimos las listas a una :
     // COLECCIÓN DE LISTAS
     SPListCollection ColeccionDeListas = UnSitio.Lists;

     foreach (SPList Listas in ColeccionDeListas)
     {
          Console.WriteLine(” ***** LISTA : “ + Listas.Title);

          // Creamos un objeto independiente para cada Lista
          // de la colección y obtenemos así una :
          // LISTA
          SPList UnaLista = ColeccionDeListas[Listas.Title];

          // Para acceder a cada Item (Elemento) de nuestr Lista,
          // añadimos los Items a una :
          // COLECCIÓN DE ITEMS
          SPListItemCollection ColeccionItems = UnaLista.Items;

          foreach (SPListItem Item in ColeccionItems)
          {
               Console.WriteLine(” ………. ITEM : “ +
               Item.Name);
          }
          Console.Read();
     }
     Console.Read();
}

Y obtenemos algo similiar a:

 Lista de Items

Definir propiedades de WebParts en MOSS 06/19/2007

Posted by dquirozo in WebParts.
2 comments

Apoyándome en el libro “Programación con SharePoint 2007” os expondré a continuación como definir una propiedad personalizada en MOSS.

Las WebParts pueden utilizar propiedades como cualquier otra clase de .NET, con la particularidad de estas propiedades serán accesibles por el usuario desde la sección de propiedades de la WebPart dentro de la interfaz misma de SharePoint.

Como cualquier otra propiedad en .NET podemos hacer uso de atributos los cuales determinarán el comportamiento de la propiedad.

Este es el código necesario para definir una propiedad al momento de crear una WebPart:

private const string destinatarioDefault = teo@wordpress.com;
private string destinatario = destinatarioDefault;

[Personalizable(PersonalizationScope.Shared),
WebBrowsable(true),
WebDisplayName(“Destinatario de los mensajes categorizados como : QUEJAS”),
WebDescription(“Especifica una dirección de e-mail”)]
public string Destinatario
{
     get { return destinatario; }
     set { destestinatario = value; }
}

Un atributo interesante es el Personalizable, ya que aqui definimos si el dato que almacena la propiedad será almacenado en un repositorio común para todos los usuarios o en uno individual. 

Y el resultado dentro de la interfaz de SharePoint sería:

 WebPart Property

 Si os preguntáis de donde salen las demás propiedades (Apariencia, Distribución y Avanzado) no olvidéis que al estar creando nuestra clase estamos heredando de la clase base WebPart la cual ya contiene estas propiedades.

public class Comentarios : WebPart
{

     //Definición de propiedades, código adicional
}

Se aceptan comentarios ……

Crear una Webpart e instalarla en MOSS 2007 (Súper básico): 06/14/2007

Posted by dquirozo in WebParts.
3 comments

Iniciamos creando una proyecto en Visual Studio, yo personalmente renombro el proyecto para no tener el mismo nombre que la solución (solución creada : SolucionWebPart, proyecto y namespace renombrado a: Personal.AdiosMundo)

Le damos un nombre mas significativo a la clase. (clase renombrada a : AdiosMundo).

Como este post es para mostrar como crear una webPart ultra básica solo es necesario agregar una referencia a System.Web.dll y los siguientes namespaces:

System.Web.UI;
System.Web.UI.WebControls.WebParts;

En este momento dentro de nuestro explorador de soluciones debemos tener algo así:

Explorador de Soluciones 1

La clase, para ser una WebPart debe de heredar de la clase WebPart, entonces simpremente la heredamo.

El método público que utilizaremos para esta WebPart es el RenderControl el cual genera contenido hacia la pantalla de salida.

namespace Personal.AdiosMundo
{
     class AdiosMundo : WebPart
     {
          protected override void Render(HtmlTextWriter writer)
          {
               writer.Write(“Adios mundo, hay que triste.”);
          }
     }
}

Y listo, hacemos clic sobre nuestro proyecto en el explorador de soluciones y damos clic en propiedades, en la sección de firma marcamos la opción “Firmar Ensamblado”, creamos una firma y guardamos los cambios. (firma creada : key)

En este momento dentro de nuestro explorador de soluciones debemos tener algo así:

Explorador de Soluciones 2

Generamos la solución, ATENCION!! : cogemos y arrastramos la dll resultante a la carpeta de c:\Windows\Asemmbly del servidor de MOSS, esto comúnmente lo llaman: registrar el ensamblado en el Global Assembly Cache (GAC).

Posteriormente es necesario crear una entrada en el web.config (sección SafeControl) de la aplicación Web para la cual estará disponible nuestra WebPart. Esto se hace agregando una línea como la siguiente:

<SafeControl Assembly=”Personal.AdiosMundo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=8ed7dec7d9ad7c9f” Namespace=”Personal.AdiosMundo” TypeName=”*” Safe=”True” />

Fijaos qué solo se agrega el nombre del ensamblado (sin dll), el namespace, que para este caso es el mismo, la key y la versión (al agregar el dll al GAC haciendo clic derecho sobre ella en las propiedades obtenemos la key y la versión).

Un iisreset /noforce y listoooooo.

Es todo, vamos al sitio web en cuestión, en la configuración del sitio dentro de la sección de galerías vamos a “Elementos Web” y hacemos clic en nuevo, aquí localizaremos nuestra WebPart por el namespace + el nombre de la clase que hemos creado, en este caso:

Listado de WebParts

Le damos clic al botón de llenar galería, ahora identificamos nuestra WebPart con el nombre de la clase mas la extensión .webpart.

Galeria de Webparts

El resultado se muestra a continuación:

Resultado

Crear un Tema personalizado para MOSS 2007 (css) 06/11/2007

Posted by dquirozo in SharePoint.
2 comments

Si en verdad deseamos contar con un portal de SharePoint diferente de los demás la mejor alternativa podría ser diseñarnos nuestro propio tema de Sitio, el cual puede incluso adaptarse a los requerimientos de imagen corporativa de nuestra compañía.

Aquí explico como poder hacerlo de una manera muy sencilla basándonos en un tema ya existente.

1.- En el servidor de SharePoint vamos a la carpeta de temas:

c:\Archivos de programa\Archivos comunes\Microsoft Shared\web server extensions\12\TEMPLATE\THEMES

Aquí existe una carpeta por cada tema disponible para nuestro portal.

2.- Hacemos la copia de un tema existente (carpeta) lo cual nos ahorra el comenzar desde cero, por ejemplo copiamos la carpeta de Classic, la pegamos en otra carpeta, la renombramos como MiTema y la regresamos a la carpeta de temas.

3.- Dentro de la nueva capeta renombramos el archivo .INF al mismo nombre de nuestra carpeta, en este caso deberíamos renombrar el archivo a MiTema.INF

4.- Editamos el archivo MiTema.INF:

  • en la sección de [info] cambiamos el valor de title por MiTema. Cambiamos el valor de codepage, por ejemplo 2007, esto es necesario para evitar errores de temas con el mismo código.

  • en la sección de [titles]  renombrar los valores para cada código. Esta sección se utiliza para presentar el nombre del tema en diferentes idiomas.

5.- Creamos una imagen para mostrar en la vista previa del tema. Esta imagen debe de ubicarse en:

 c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\IMAGES Por ejemplo: MiTemaPreview.gif 

6.- Editamos el archive SPTHEMES.xml ubicado en:

 c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\Layouts\1033\ 

le agregamos una entrada que haga referencia a nuestro tema recién creado de la siguiente manera:

<Templates>

<TemplateID>MiTema</TemplateID>

  <DisplayName> MiTema </DisplayName>

  <Description> Este tema contiene los colores corporativos.    </Description>

  <Thumbnail>images/ MiTemaPreview.gif</Thumbnail>

  <Preview>images/ MiTemaPreview.gif</Preview>

</Templates>

7.- Ahora modificamos el archivo CSS contenido en nuestra carpeta MiTema para personalizar el tema. Para esto debemos tener nociones de Hojas de Estilo y conocer de igual manera la estructura de las Hojas de Estilo que utiliza SharePoint (Gustavo page).

8.- Reiniciamos nuestro servidor IIS

9.- Para ver los resultados podemos aplicar el tema a un sitio de prueba.

Voila.

    

Jeraquía de objetos asegurables en SharePoint 06/09/2007

Posted by dquirozo in SharePoint.
add a comment

Jerarqua de Objetos asegurables en SharePoint

Migración del servidor completo de MOSS 2007 en solo 7 pasos. 05/25/2007

Posted by dquirozo in SharePoint.
12 comments

Migrar un servidor de Microsoft Office SharePoint Server 2007 (MOSS 2007) a otro y no morir en el intento puede ser una tarea un poco complicada de conseguir, principalmente por la falta de una procedimiento estándar y 100% fiable para realizarlo.

Es por eso que os expongo mi recomendación para efectuar dicho procedimiento.

Al final del post encontraréis las configuraciones pre y post migración que son requeridas al realizar este tipo de migración, os recomiendo que les echéis un ojo antes de iniciar.

Comenzamos:

PASO 1. Tenemos que identificar la, o las bases de datos de contenidos de las aplicaciones Web y respaldas (utilizando SQL Management Studio creamos una copia de seguridad de las base de datos por ejemplo), podemos ubicar a que base de datos corresponde cada aplicación Web yendo a: Administración Central – Administración de Aplicaciones – Administración de aplicaciones Web de SharePoint – Bases de Datos de Contenidos

PASO 2. En el servidor origen (W2K3) crearemos una nueva instalación de MOSS 2007 y realizamos su configuración básica (servidores del conjunto, Correo Saliente, etc.), pero por el momento no creamos ningún proveedor de Servicio Compartidos (SSP).

PASO 3. En la nueva instalación de MOSS 2007 creamos las aplicaciones Web necesarias (la misma cantidad de aplicaciones Web que las que deseamos restaurar)

Importante: Posterior a crear las aplicaciones Web no debemos crear ninguna colección de sitio pues utilizaremos las colecciones de sitio que se restauraran con las aplicaciones Web)

PASO 4. Utilizando nuestra herramienta manejadora de bases de datos preferida (en mi caso el SQL Server Management Studio) restauramos las bases de datos respaldadas en el paso 1 al servidor de SQL con el cual trabaja la nueva instalación de MOSS 2007.

PASO 5. Para adjuntar la, o las nuevas (recién restauradas) Bases de Datos es necesario eliminar las bases de datos de contenido de las aplicaciones Web creadas en el paso 3. Esto lo podemos hacer también yendo a Administración Central – Administración de Aplicaciones – Administración de aplicaciones Web de SharePoint – Bases de Datos de Contenidos y seleccionando cada una de las bases de datos para su posterior eliminación.

PASO 6. Y para finalizar y casi cerrar con broche de oro utilizaremos el comando addcontentdb de la herramienta stsadm de sharepoint de la siguiente manera:

stsadm –o addcontentdb –url http://NuevaAplicaciónWeb –databasename BD_Restaurada –databaseserver Servidor_BD

Por ejemplo:

stsadm –o addcontentdb –url http://sharepoint:8080 –databasename WS_Content_8080 –databaseserver SERVERBD

PASO 7. Creamos nuestro SSP el cual contendrá las aplicaciones Web, podemos decirle que utilice por ejemplo la aplicación Web que utiliza el puerto 80 para albergar el sitio de configuración del SSP.

Voilaaaa, un iisreset y pim, pom, papas, y lo sorprendente es que aunque nuestros servidores (el viejo y el nuevo) se llamen diferente todos los vínculos se actualizaran de manera automática,

Como había comentado al principio del post este procedimiento implicaría realizar una que otra configuración adicional, de igual manera este no se aplica a todas las necesidades pues implica algunos pros y contras:

Posterior a la migración será necesario realizar la configuración completa de nuestro SSP: Importación de perfiles, configuración de la búsqueda, rutas de confianza para los Servicios de Excel, Audiencias, etc.

El procedimiento es muy útil cuando necesitamos realizar un movimiento de todo el servidor de MOSS  2007, no así, si lo único que requerimos es mover un sitio de un servidor a otro para lo cual recomiendo utilizar el comando export e import de la herramienta stsadm

Este procedimiento no requiere más de 30 minutos (incluyendo la instalación de MOSS 2007) de teclazos y clics.

Espero vuestras sugerencias respecto al tema, tal vez así algún día logremos definir un procedimiento estándar para migrar sitios de SharePoint.

Conexiones a Servicios Web en formularios habilitados para el navegador Web (InfoPath) 05/23/2007

Posted by dquirozo in InfoPath, Servicios Web, SharePoint.
1 comment so far

Una de las nuevas característica de MOSS 2007 es la posibilidad de mostrar formularios diseñados en InfoPath directamente sobre el navegador Web a través de los servicios de formularios, ventaja que nos permite el evitar el tener instalado el cliente de InfoPath en cada equipo de los usuarios que necesitan rellenar o consultar información en algún formulario.

La primera vez que intente realizar una llamada a un Servicio Web con un Formulario Web diseñado en InfoPath basado en los servicios de formulario de MOSS 2007, obtenía un error de servidor que me indicaba que se había escrito una entrada en el Log del servidor con los detalles del error……. nunca encontré la dichosa entrada.

Recherchendo en la Web al fin encontré la solución que aquí os expongo de manera detallada:

En concreto solo son un par de pasos bastante sencillos.

1.- Primero hay que ir a nuestro sitio de Administración Centra, pestaña de Administración de Aplicaciones, sección de InfoPath Form Services y en la opción de Configurar InfoPath Form Services hay que marcar o habilitar la opción de “Acceso entre dominios para plantillas de formulario de usuario“ lo cual nos permitirá el tener acceso a datos entre dominios cruzados:

Acceso entre diferentes dominios

2.- Segundo, pero no menos importante, dentro de nuestro diseño del formulario, dentro de “Herramientas” – “Conexiones de Datos”, hay que convertir las conexiones a nuestros servicios Web y guardarlas dentro de nuestro sitio de sharepoint en una biblioteca de tipo “Biblioteca de conexiones de Datos” (Una biblioteca de conexión de datos es un nuevo tipo de biblioteca de documentos de SharePoint que provee un lugar para almacenar, administrar y compartir archivos de conexión), yo os recomiendo crear esta biblioteca en un sitio de nivel superior para poder tener acceso a las conexiones qua aquí se almacenen desde cualquier sitio dentro de la colección y fomentar la reusabilidad de estas:

Convertir Conexiones

OJO!! Yo he guardado las conexiones en formato tanto XML y UDCX, podéis intentarlo con la extensión que os vaya mejor. 

Es todo, el formulario de InfoPath que es renderizado en un navegador Web puede trabajar ahora con conexiones a servicios Web sin problema.

OJO!!! Las bibliotecas de conexiones de datos, por default, requieren aprobación de contenidos,, entonces no debemos olvidar aprobar cada archivo de conexión para hacerlos disponibles para todos los usuarios.

Según explica Nick Dallett [1], la necesidad de guardar nuestras conexiones a servicios Web dentro de una biblioteca de conexiones de datos ubicada en nuestro sitio de sharepoint es debido a que los servicios de formulario no pueden detener la ejecución de un proceso que corre del lado del servidor para cambiar de contexto y preguntarnos si deseamos conectarnos al origen de datos y posteriormente regresar a la ejecución del proceso del lado del servidor, entonces al tener almacenada la conexión dentro de esta biblioteca la ejecución continua sin interrupción.

[1] http://blogs.msdn.com/infopath/archive/2006/10/02/Data-Connections-in-Browser-Forms.aspx