SharePoint

Estandarice la administración de datos con tipos de contenido personalizados

Pav Cherny

Resumen:

• Administración del ciclo de vida del contenido con SharePoint
• Creación de paneles de información de documentos
• Edición de documentos de Office y SharePoint a través de InfoPath

Descargar el código de este artículo: ContentTypes2008_02.exe (779KB)

El elevado número de documentos y otros contenidos que se encuentran normalmente en un entorno empresarial plantean desafíos técnicos y empresariales para la administración de documentos, sus

metadatos y sus comportamientos de una manera centralizada y reutilizable. Microsoft® Office SharePoint® Server 2007 fomenta la colaboración en toda la empresa permitiendo que los distintos equipos de una organización compartan áreas de trabajo en sitios web, listas y bibliotecas de documentos.

SharePoint 2007 hace posible la estandarización de muchos aspectos de las características de contenido y ciclo de vida a través de los tipos de contenido. Los tipos de contenido de sitio son definiciones del metadatos que se pueden establecer independientemente de cualquier colección de sitios, sitio, lista o biblioteca de documentos específicos. Esto le permite establecer propiedades, flujos de trabajo, directivas de administración de la información y otros elementos en toda la empresa de manera coherente, al tiempo que posibilita que los propietarios individuales de departamentos o sitios personalicen tipos de contenido para propósitos específicos.

En este artículo, le mostraré cómo usar el nuevo modelo de contenido de SharePoint introducido con Windows® SharePoint Services (WSS) 3.0 y Microsoft Office SharePoint Server (MOSS) 2007 para construir jerarquías de contenido empresarial basadas en características generales. Estas jerarquías de contenido permiten la aplicación uniforme de metadatos, flujos de trabajo y directivas de administración de la información a nivel global, al tiempo que proporcionan la flexibilidad para acomodar las necesidades únicas de administración de contenido en el nivel de colecciones de sitios, sitios, listas y bibliotecas de documentos.

Para ilustrar algunos de los aspectos de bajo nivel de los tipos de contenido de SharePoint, he incluido varias herramientas personalizadas en el material del libro guía. He incluido igualmente el código fuente por si desea ampliar estas herramientas en función de sus necesidades específicas. Tenga presente que estas herramientas no se han probado exhaustivamente, por lo que no deben usarse en sistemas de producción. Puede descargar el código desde el sitio web de TechNet Magazine en technetmagazine.com/code08.aspx.

Ciclo de vida del contenido y definiciones de tipos de contenido

Recursos de SharePoint

• Blog del equipo de InfoPath
• Flujos de trabajo en Office SharePoint Server 2007
• Difusión por Web de TechNet: Instalación y configuración de la búsqueda en SharePoint Server 2007
• InfoPath Forms Services

Hay muchos detalles que se deben tener en cuenta para decidir cuándo administrar documentos y otros contenidos en una organización. Entre otras cosas, es necesario definir las personas o procesos que necesitan realizar acciones determinadas a medida que el contenido se crea, publica, archiva y desecha. Además, las organizaciones necesitan a menudo desarrollar plantillas específicas para la creación de contenidos, definir funciones a las que asignar responsabilidades y privilegios de acceso para usuarios, ofrecer control de versiones, supervisar el cumplimiento, el almacenamiento y el archivado, definir metadatos, etcétera.

Independientemente de lo complejo que pueda resultar el ciclo de vida de un contenido concreto, el modelo de contenido de SharePoint reconoce que existen algunas características generales y fases típicas que determinan el modo en que se deben tratar los elementos individuales. Por ejemplo, puede estructurar la creación de contenidos mediante plantillas y formularios de entrada, así como la visualización y la búsqueda de contenido a través de metadatos. También puede usar la edición, aprobación u otros requisitos de flujo de trabajo, los requisitos de archivado, los períodos de tiempo de expiración y las directivas aplicables de administración de la información para diferenciar fragmentos individuales de contenido. Puede que algunos contenidos no requieran plantillas especiales, o que nunca se archiven, pero incluso éstas son características del ciclo de vida que contribuyen a diferenciar éstos de otros elementos.

El modelo de contenido de SharePoint le permite definir tipos de contenido individuales y establecer relaciones jerárquicas. En una relación jerárquica, los elementos secundarios heredan características generales de tipos de contenido primarios, agregando características específicas según sea necesario.

La mejor manera de ilustrar esto es examinar los tipos de contenido integrados de SharePoint. WSS 3.0 y MOSS 2007 incluyen varios tipos de contenido predefinidos para los elementos típicos que se pueden almacenar en una lista o biblioteca de documentos, incluyendo documentos y tareas. Puede encontrar las definiciones de estos tipos de contenido estándar en un servidor de SharePoint en la carpeta %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Ctypes. Ahí encontrará un archivo de manifiesto llamado feature.xml. Mirando este archivo, puede ver que SharePoint implementa las definiciones de los tipos de contenido estándar como una característica oculta (Hidden="TRUE") con un ámbito de colección de sitios (Scope="Site") y que el archivo de manifiesto de elementos, que contiene los elementos de tipo de contenido, es ctypeswss.xml (<ElementManifest Location="ctypeswss.xml" />).

Si está interesado en obtener más información acerca de las características de SharePoint, le recomiendo que lea la columna Espacio de oficina de Ted Pattison en MSDN® Magazine titulada "Características de SharePoint," que está disponible en msdnmagazine.com/issues/07/05/OfficeSpace .

Abramos ahora el archivo ctypeswss.xml en el Bloc de notas para examinar los tipos de contenido estándar al margen de su visibilidad en la interfaz de usuario de SharePoint. No debe modificar el archivo ctypeswss.xml. Si piensa editar ctypeswss.xml para agregar campos nuevos a los tipos de contenido estándar o para hacer visibles los tipos de contenido ocultos de modo que los usuarios de SharePoint los puedan usar para derivar nuevos tipos de contenido, tenga en cuenta que generalmente esto no es necesario. Además, genera configuraciones no admitidas y las instalaciones posteriores de Service Packs pueden sobrescribir las personalizaciones e interrumpir sus soluciones de administración de contenido.

Un enfoque mucho mejor consiste en copiar lo que necesita en un archivo de manifiesto de elementos nuevo, agregar sus personalizaciones según sea necesario y, a continuación, implementar los tipos de contenido personalizados como una característica nueva con un ámbito de colección de sitios para ponerlos a disposición de todos los sitios incluidos en la colección de sitios.

Aquí se revela la definición basada en el Lenguaje de marcado de aplicaciones de colaboración (CAML, Collaborative Application Markup Language) del tipo de contenido System tal y como se especifica en el archivo ctypeswss.xml:

<ContentType ID="0x"
    Name=$Resources:System
    Group="Hidden"
    Sealed="True"
    Version="0">
   <FieldRefs>
      <FieldRef ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType"/>
   </FieldRefs>
</ContentType>

Los atributos Group y Sealed muestran que el tipo de contenido System está oculto y sellado para que no se pueda cambiar en la interfaz de usuario de SharePoint. El tipo de contenido System sólo tiene un elemento FieldRef que hace referencia a una columna de sitio integrada llamada ContentType. Éste es el nivel más alto de abstracción. Todos los demás tipos de contenido de SharePoint heredan esta propiedad del tipo de contenido System. De este modo, SharePoint se asegura de que todos los elementos de contenido almacenados en cualquier lista o biblioteca de documentos tienen esta propiedad en común.

La Figura 1 muestra un elemento web ContentTypeHierarchy, incluido en el material del libro guía para este artículo, que ilustra las jerarquías de manera más intuitiva. System se encuentra en la raíz de todos los demás tipos de contenido, seguido por Item, etcétera. El tipo de contenido Item, por ejemplo, establece el siguiente nivel de detalle. Si comprueba el archivo ctypeswss.xml, verá que Item define un solo campo de metadatos que hace referencia a una columna de sitio llamada Title. De este modo, todos los tipos de contenido integrados en niveles inferiores tienen una propiedad Title.

Figura 1** Jerarquía de tipo de contenido integrado WSS 3.0 **(Hacer clic en la imagen para ampliarla)

También es posible quitar un campo heredado, como demuestra la definición del tipo de contenido Document en el archivo ctypeswss.xml. El tipo de contenido Document incluye varios elementos RemoveFieldRef. Aún así, quizás desee mantener el campo Title en los tipos de contenido personalizados, ya que la columna Title da acceso al menú desplegable del cuadro de control de edición (ECB, Edit Control Box) en las vistas de lista y biblioteca de documentos de SharePoint.

Un buen ejemplo que ilustra cómo cambiar el nombre de los campos heredados es el tipo de contenido Far East Contact del archivo ctypeswss.xml. Busque 0x0116, que es el identificador de tipo de contenido correspondiente y, entonces, active el elemento FieldRef con el atributo Name="Title" para ver cómo puede usar el atributo DisplayName para cambiar el nombre de un campo de la interfaz de usuario. En este ejemplo particular, el atributo DisplayName cambia el nombre del campo Title en la interfaz de usuario a un valor de datos localizado al que "$Resources:core,Last_Name;" hace referencia.

Si presta atención a la Figura 1, podrá ver que el atributo ID del elemento ContentType identifica únicamente el tipo de contenido y establece la relación jerárquica. Todos los identificadores empiezan con el identificador del tipo de contenido primario con valores hexadecimales adicionales adjuntos. Los tipos de contenido estándar tienen normalmente dos valores hexadecimales adicionales adjuntos para crear un nuevo identificador único para el tipo de contenido secundario. Otra técnica consiste en anexar el valor "00" y un GUID hexadecimal. Así es como los tipos de contenido Office Data Connection File y Universal Data Connection File derivan a partir del tipo de contenido Document, por ejemplo.

Un punto importante que deben recordar los usuarios es que el atributo ID del elemento ContentType no puede exceder de 1.024 caracteres. Esto puede resultar un problema en una relación jerárquica grande si todos los tipos de contenido usan la técnica de direcciones de GUID hexadecimal. Sin embargo, no es buena idea comenzar con la técnica más corta porque puede que estos identificadores no sean únicos.

Para asegurar unicidad, use la técnica de GUID para establecer un espacio de nombres global para sus tipos de contenido empresariales y cambiar a la técnica más corta dentro de ese espacio de nombres. Para obtener información detallada acerca del atributo ID y otros elementos de definiciones de tipo de contenido, consulte el tema "Esquema de definición de tipo de contenido" en el SDK de WSS 3.0.

Dependencias de tipo de contenido

Centrémonos ahora en la cuestión de cómo usar tipos de contenido de SharePoint para estructurar la administración de elementos de contenido. Necesita considerar varias dependencias, tales como las interdependencias entre listas y bibliotecas de documentos, tipos de contenido, columnas de sitio y tipos de campo. Las bibliotecas y las listas hacen referencia a tipos de contenido, que a su vez hacen referencia a columnas de sitio, que hacen referencia a tipos de campo (como los tipos de campo estándar de WSS de texto, nota, elección, número, divisa, etcétera), que por su parte residen en los ensamblados de Microsoft .NET Framework, como el ensamblado principal de WSS Microsoft. SharePoint. dll.

Para encontrar un buen ejemplo podemos volver al tipo de contenido System tal y como lo ilustramos anteriormente en la definición CAML de la entrada de archivo de manifiesto de tipo de contenido System. Como vimos, este tipo de contenido incluye un elemento FieldRef que se refiere a una columna de sitio llamada ContentType. Tenga en cuenta que la definición del tipo de contenido no define la columna de sitio ContentType. ContentType es un campo de texto, definido en el archivo de manifiesto de elementos fieldswss.xml, que se encuentra en la carpeta %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields. El tipo de campo Text se define en el archivo fldtypes.xml, que puede encontrar en %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\XML. Un punto importante en referencia a este árbol de dependencias es que debe asegurarse de que todos los recursos están disponibles en sus servidores de SharePoint.

Los tipos de contenido que desea usar deben crearse en el nivel de sitio de sus listas y bibliotecas de documentos o en un nivel superior de la jerarquía de sitios. De igual modo, los campos de metadatos de sus tipos de contenido deben referirse a columnas de sitio existentes. Puede agregar columnas de sitio personalizadas o estándar basadas en los tipos de campo personalizados a los tipos de contenido, pero debe asegurarse de que las columnas de sitio existen en el sitio local. Además, si desea usar tipos de campo personalizados, deberá asegurarse de que los ensamblados .NET subyacentes están implementados en sus servidores de SharePoint.

Existen dependencias similares para los tipos de contenido que hacen referencia a plantillas de documento, receptores de evento personalizados, flujos de trabajo y otros componentes. Por ejemplo, la definición del tipo de contenido puede contener un elemento DocumentTemplate que señale a la plantilla de documento asociada con el tipo de contenido. La definición del tipo de contenido puede incluir también un elemento XmlDocuments con uno o varios elementos XmlDocument secundarios que definen características adicionales del tipo de contenido, tales como las definiciones de espacio de nombres, definiciones de paneles de información de documentos o cualquier información personalizada.

Establecimiento de tipos de contenido globales

Los usuarios con permisos de creación pueden crear nuevos tipos de contenido y columnas de sitio directamente en la interfaz de usuario de SharePoint, pero entonces los tipos de contenido sólo están disponibles en el sitio local o niveles inferiores de la jerarquía de sitios. Las columnas de sitio personalizadas sólo están disponibles en el sitio local. Esto no es suficiente si desea establecer tipos de contenido globales. Debe asegurarse de que los tipos de contenido globales están disponibles en todas las colecciones de sitios de su entorno. Aquí es donde las características de SharePoint demuestran su utilidad. Es sencillo instalar y activar las características de SharePoint a través de múltiples colecciones de sitios para aplicar las definiciones correspondientes de columna de sitio y tipo de contenido de manera coherente en todas las ubicaciones.

El material del libro guía correspondiente a este artículo incluye una característica de muestra llamada AdventureWorks que nos enseña cómo establecer un tipo de contenido global. La característica define un tipo de contenido general llamado Customer Documentation que puede usarse para crear cualquier tipo de material de cliente como cartas de ventas y propuestas. Es razonable asumir que todos estos tipos de documentos deben asociarse con información de cliente como el nombre de la compañía, los detalles de contacto y la dirección. Creé específicamente un campo personalizado llamado Customer Name para su tipo de contenido y agregué algunos campos integrados tales como Department y Primary Phone. Puede cambiar el tipo de contenido y los campos editando el archivo ContentTypes.xml y las referencias de campo mediante la edición del archivo SiteColumns.xml en la muestra del libro guía.

Si implementa la característica de la manera descrita en el archivo leame.htm, podrá activarla coherentemente en múltiples colecciones de sitios. El tipo de contenido Customer Documentation estará entonces disponible globalmente. De este modo, los departamentos individuales pueden crear documentación específica de cliente a través de tipos de contenido derivados asociados con plantillas de documento de destino. El material del libro guía incluye plantillas de documento de muestra que pueden usarse en ventas y consultoría. La Figura 2 muestra los tipos de contenido resultantes.

Figura 2** Tipos de contenido primario y secundario para la documentación de cliente **(Hacer clic en la imagen para ampliarla)

Puede elegir entre varias opciones para crear características para columnas de sitio y tipos de contenido personalizados en WSS 3.0 y MOSS 2007. Puede estudiar el SDK de WSS 3.0 y escribir archivos XML desde cero. También puede usar SharePoint Designer para exportar una lista a un paquete web personal, cambiar el nombre del archivo .fwp resultante a un archivo .cab, extraer el archivo manifest.xml del archivo .cab y, a continuación, buscar las definiciones de ContentType en el archivo manifest.xml. Desgraciadamente, ambos enfoques son farragosos y proclives al error.

Por el contrario, resulta bastante fácil crear columnas de sitio y tipos de contenido personalizados en la interfaz de usuario de SharePoint. Aún así, la interfaz no ofrece una opción para editar los archivos XML de las características. Las características son una manera eficiente de aprovisionar recursos de SharePoint, aunque una vez aprovisionados, los recursos sólo existen en la base de datos de contenidos. Quizás una versión futura de WSS incluya la capacidad de exportar columnas de sitio y tipos de contenido a archivos XML a través de la interfaz de usuario de SharePoint, de manera similar a la exportación de elementos web. Por ahora, tiene que apañarse con lo que hay.

El material del libro guía incluye un elemento web llamado ContentTypeSchema que puede servir como punto de partida. Usa el modelo de objetos de SharePoint para extraer la propiedad SchemaXML del tipo de contenido seleccionado. A través de las transformaciones basadas en el lenguaje de transformación basado en hojas de estilo (lenguaje XSLT), el elemento web deriva definiciones de campo o definiciones ContentType en función de la opción que seleccione en la interfaz de usuario antes de hacer clic en el botón Mostrar.

La Figura 3 muestra el elemento web en acción. Muestra el tipo de contenido Active Directory® Documentation, que he basado en el tipo de contenido Customer Documentation. El tipo de contenido Active Directory Documentation está asociado con una plantilla personalizada de Microsoft Word (Active Directory Template.dot). Tenga en cuenta que este tipo de contenido no tiene campos adicionales. Todos los campos se heredan del tipo de contenido primario.

Si planea usar el elemento web ContentTypeSchema en su propio entorno, tenga presente que este elemento web no se ha probado exhaustivamente. Mi elemento web usa transformaciones XSL relativamente complejas para construir una diferencia entre la propiedad SchemaXML del tipo de contenido seleccionado actualmente y su tipo de contenido primario. XSLT 1.0 no está realmente diseñado para conversiones avanzadas de documentos XML. No hay características integradas para comparar nodos XML. Además, los espacios de nombres XML, así como las secciones de CDATA, representan dificultades que XSLT 1.0 no puede tratar con eficacia.

SharePoint almacena la definición de las columnas de sitio y los tipos de contenido de sitio creados con la interfaz de usuario de SharePoint o el modelo de objetos de SharePoint en la tabla ContentTypes de la base de datos de contenidos. En la Figura 3, eche un vistazo al identificador de mi tipo de contenido personalizado. Por lo tanto, la siguiente instrucción T-SQL obtendría resultados exactos: SELECT Definition FROM ContentTypes WHERE ContentTypeId = <identificador del tipo de contenido>.

Figura 3** Definición de tipo de contenido personalizado en el elemento web ContentTypeSchema **(Hacer clic en la imagen para ampliarla)

Al margen del enfoque que decida usar, resulta muy sencillo crear características para tipos de contenido a nivel de empresa una vez obtenidas las definiciones de la columna de sitio y el tipo de contenido. Le recomiendo que use una sola característica para todos los tipos de contenido y columnas de sitio globales de su departamento o compañía. Así, parece claro dónde agregar nuevas definiciones de columna de sitio y de tipo de contenido.

Búsquedas a nivel de empresa en metadatos personalizados

Una ventaja inmediata que presentan las jerarquías de tipo de contenido es que todos los tipos de contenido secundarios heredan los campos de metadatos del tipo de contenido primario. Puesto que todos los tipos de contenido tienen campos de metadatos en común, es bastante fácil para los usuarios crear vistas y filtros personalizados en las bibliotecas de documentos.

La característica de ejemplo AdventureWorks demuestra esto de forma bastante intuitiva. Independientemente del contenido creado por un consultor o un vendedor, el guardado del documento de Word 2007 resultante requiere que se especifique un campo Customer Name, ya que el tipo de contenido primario Customer Documentation define este campo de metadatos como obligatorio. Agrupar o filtrar los elementos en una vista de biblioteca de documentos según el campo Customer Name permite a los miembros de los equipos de consultoría y ventas localizar toda la documentación existente de un cliente de manera rápida y oportuna, tal y como se muestra en la Figura 4.

Figura 4** Agrupación de varios documentos en una biblioteca en función de los metadatos en común **(Hacer clic en la imagen para ampliarla)

Los metadatos en común también facilitan la localización del contenido a través de múltiples sitios y bibliotecas de documentos usando las capacidades de búsqueda de WSS 3.0 y MOSS 2007. WSS permite la realización de búsquedas en bibliotecas, listas y sitios dentro de una sola colección de sitios. MOSS 2007 va más allá de estas capacidades básicas permitiéndole implementar un Centro de búsquedas a nivel de empresa y administrar los metadatos personalizados en la interfaz de usuario de Administración central de SharePoint 3.0. Por este motivo, las siguientes explicaciones se centran en MOSS 2007.

Al configurar un proveedor de servicios compartidos (SSP, Shared Service Provider) en MOSS 2007 y rastrear sus sitios de SharePoint, MOSS 2007 puede descubrir automáticamente los campos de metadatos personalizados usados en los orígenes de contenido. De este modo, puede encontrar los campos de metadatos personalizados en la lista de propiedades rastreadas.

Los campos de metadatos definidos en las características de SharePoint se encuadran generalmente en la categoría de SharePoint. Para encontrar su ubicación en Administración Central de SharePoint, en el menú Inicio rápido de Administración de servicios compartidos, haga clic, por este orden, en el vínculo a su SSP, en la configuración Búsqueda, en las asignaciones de propiedades de metadatos, en Propiedades rastreadas del menú Inicio rápido y, por último, abra la categoría SharePoint.

Le daré un ejemplo de esto en acción. El campo de metadatos denominado Customer Name acaba como una propiedad rastreada llamada ows_Customer_x0020_Name. Los prefijos de SharePoint rastrearon las propiedades con "ows_", y "_x0020_" es la versión codificada de un espacio único. Si muestra los detalles de esta propiedad rastreada, descubrirá que está incluida en el índice de búsqueda de manera predeterminada para que los usuarios puedan emplear los valores de esta propiedad rastreada para realizar búsquedas de contenidos. Sin embargo, para aumentar la precisión de la búsqueda, quizás sea mejor no asignar la propiedad rastreada a una propiedad administrada para que los usuarios puedan buscar explícitamente los contenidos por nombre de cliente.

Tiene dos opciones al asignar propiedades rastreadas a propiedades administradas. Puede generar automáticamente una nueva propiedad administrada para cada propiedad rastreada o puede asignar propiedades rastreadas a otras administradas de forma manual. La primera opción está disponible al mostrar la configuración de la categoría de propiedad rastreada deseada (al mostrar las propiedades rastreadas en una categoría como, por ejemplo, la categoría SharePoint, haga clic en la opción Editar categoría del vínculo de Inicio rápido). En Configuración de propiedades de rastreo masivo, tendría que seleccionar la casilla "Generar automáticamente una nueva propiedad administrada para cada propiedad rastreada descubierta en esta categoría". Sin embargo, los prefijos de SharePoint crearon automáticamente propiedades administradas con "ows" y espacios de escape con "x0020". La propiedad administrada correspondiente a la propiedad rastreada ows_Customer_x0020_Name sería owsCustomerx0020Name. Sin embargo, este nombre de propiedad no es muy fácil de usar.

Quizás una mejor estrategia consista en asignar manualmente propiedades rastreadas a propiedades administradas después de implementar los tipos de contenido a nivel de empresa. Puede asignar una propiedad rastreada a una o a múltiples propiedades administradas. Para crear nuevas propiedades administradas, en Administración Central de SharePoint, en el menú Inicio rápido de Administración de servicios compartidos, haga clic, por este orden, en el vínculo a su SSP, en la configuración Búsqueda, en las asignaciones de propiedades de metadatos y en Nueva propiedad administrada para especificar la información necesaria y asociar la nueva propiedad administrada con la propiedad rastreada deseada.

Así, los usuarios podrán localizar elementos de contenido relevantes usando las propiedades administradas en la sintaxis de propiedad o usando la búsqueda avanzada. Por ejemplo, si asigna la propiedad rastreada ows_Customer_x0020_Name a una propiedad administrada denominada Client, los usuarios podrán buscar todos los documentos de un cliente con sólo especificar Client: <nombre del cliente> en el cuadro de búsqueda estándar, como por ejemplo Client: Contoso.

También es una buena idea incluir las propiedades administradas correspondientes a los campos de metadatos más importantes de sus tipos de contenido en la lista de propiedades de la página Búsqueda avanzada. Para conseguir esto, muestre la página Búsqueda avanzada, haga clic en Acciones del sitio y seleccione el comando Editar página. Ahora puede hacer clic en Edición en el Cuadro de búsqueda avanzada para seleccionar la opción Modificar elemento web compartido. Al ampliar la categoría Propiedades y colocar el cursor en el campo de texto correspondiente, puede hacer clic en el botón para editar el documento XML de propiedades. Necesita agregar una definición de propiedad al elemento <PropertyDefs>, como <PropertyDef Name="Customer" DataType="text" DisplayName="Customer Name"/>, y necesita agregar igualmente una referencia a esta definición de propiedad en un elemento ResultType (por ejemplo, el elemento <ResultType DisplayName =" All Results" Name ="default">), como <PropertyRef Name="Customer" /.> La Figura 5a muestra la interfaz de usuario Búsqueda avanzada resultante. La Figura 5b muestra los resultados de la búsqueda.

Figura 5a** Búsqueda de documentación de la infraestructura de TI basada en el nombre de cliente **(Hacer clic en la imagen para ampliarla)

Figura 5b** Los resultados de la búsqueda de nombre de cliente **(Hacer clic en la imagen para ampliarla)

Garantía de la consistencia de la información

Llegados a este punto, he estandardizado correctamente los campos de metadatos y los tipos de contenido más importantes. También he ampliado las capacidades de búsqueda en todas las colecciones de sitios de mi empresa mediante MOSS 2007. Ahora es importante asegurar que los usuarios introduzcan información exacta en los campos de metadatos.

Hay dos maneras de hacer esto. En primer lugar, puede reemplazar el panel de información del documento estándar en sus plantillas de documento con un formulario InfoPath® personalizado que proporciona a los usuarios una selección predefinida de opciones de entrada, como las que aparecen en un cuadro de lista. En segundo lugar, puede enlazar un receptor de eventos al tipo de contenido y, a continuación, comprobar la precisión de los metadatos y otro tipo de información cuando los usuarios creen, modifiquen o eliminen los correspondientes elementos de contenido.

Ambas opciones son complementarias. Un formulario de InfoPath ofrece principalmente una manera oportuna de editar las propiedades de un tipo de contenido de SharePoint, mientras que un receptor de eventos puede asegurar la validez de los metadatos incluso si los usuarios editan las propiedades del tipo de contenido fuera del formulario de InfoPath. Puede enlazar controladores de eventos a un tipo de contenido específico. Esto le permite especificar eventos y sus respuestas para todos los documentos asociados con un tipo de contenido individual en todas las colecciones de sitios, independientemente de cuál sea la biblioteca de documentos. Puede obtener más información acerca de cómo desarrollar e implementar controladores de eventos en msdn2.microsoft.com/ms453149.

Quizás el método más fácil para asociar un tipo de contenido con un panel de información del documento personalizado consista en mostrar la configuración Panel de información del documento del tipo de contenido en la interfaz de usuario de SharePoint en un equipo con InfoPath 2007 instalado. Entonces puede hacer clic en el vínculo Crear una nueva plantilla personalizada en Plantilla del panel de información del documento para iniciar InfoPath 2007 en modo de diseño. Sin embargo, si el tipo de contenido del sitio incluye columnas de sitio sin un atributo SourceID explícito, podría encontrarse en una situación en la que InfoPath no puede crear un esquema XSD válido para el formulario Panel de información del documento. Por ejemplo, el tipo de contenido Customer Documentation presentado anteriormente incluye varias columnas específicas de contactos tales como Department, Office y E-mail que pueden causar este problema, tal y como se muestra en la Figura 6.

Figura 6** Incompatibilidades de esquema XSD en InfoPath 2007 **(Hacer clic en la imagen para ampliarla)

En este punto, tiene dos opciones si se le presenta este problema. Puede quitar las referencias a las columnas de sitio sin un atributo SourceID explícito de la definición de tipo de contenido. También puede sustituir las columnas de sitio integradas que causan el problema por columnas de sitio personalizadas que sean compatibles con InfoPath 2007. Tenga presente que no puede cambiar las referencias de campo de un tipo de contenido basado en CAML después de que se haya aprovisionado en la base de datos de contenidos, especialmente si ya ha creado tipos de contenido secundarios. Ya no puede simplemente actualizar el archivo de definición de tipos de contenido basados en CAML, ni desplazar hacia abajo los cambios hechos a tipos de contenido secundarios porque Windows SharePoint Services no hace un seguimiento de los cambios realizados a la definición del tipo de contenido primario.

Para desplazar hacia abajo los cambios, debe cambiar el tipo de contenido primario a través del modelo de objetos o la interfaz de usuario de SharePoint. También debe definir un nuevo tipo de contenido que se derive del tipo ya existente. La última técnica le permite quitar los campos críticos y agregar nuevas columnas. Sus usuarios pueden derivar tipos de contenido futuros a partir del nuevo tipo de contenido. Para evitar que los usuarios elijan el tipo de contenido equivocado, agregue el tipo de contenido anterior al grupo de tipo de contenido _Hidden.

Como dije antes, no puede actualizar los tipos de contenido basados en CAML después de implementarlos y activarlos. Por eso es muy importante probar los tipos de contenido globales antes de la implementación. Para obtener más información, consulte el artículo de MSDN "Actualización de los tipos de contenido" en msdn2.microsoft.com/aa543504.

Cuando haya creado un tipo de contenido con referencias de campo adecuadas, podrá crear un panel de información del documento personalizado en InfoPath 2007. La mejor estrategia consiste en permitir que los propietarios de sitios creen paneles de información de documento personalizados para sus tipos de contenido secundarios. InfoPath 2007 ofrece la opción de publicar el panel de información del documento personalizado directamente en el tipo de contenido seleccionado, lo cual facilita el escenario de implementación. También es posible publicar el formulario de InfoPath en una ubicación central, como una biblioteca de documentos, e incluir una referencia al panel de información del documento en el tipo de contenido. Esta es la mejor opción si planea proporcionar un panel de información del documento personalizado junto con sus tipos de contenido CAML. La Figura 7 ilustra la arquitectura de implementación.

Figura 7** Implementación de archivos XSN en una ubicación central en MOSS 2007 **(Hacer clic en la imagen para ampliarla)

La descarga del libro guía para este artículo incluye una característica llamada AdventureWorks_Update que amplía la característica AdventureWorks anterior agregando columnas de sitio adicionales que funcionan con InfoPath 2007. La característica AdventureWorks_Update marca el tipo de contenido Customer Documentation original como oculto y deriva un nuevo tipo de contenido denominado Customer Docs, que sustituye los campos integrados heredados por las nuevas columnas de sitio y asocia el nuevo tipo de contenido con un panel de información del documento personalizado.

La nueva definición del tipo de contenido Customer Docs incluye un elemento XmlDocument que proporciona información acerca del panel de información del documento. Específicamente, el elemento xsnLocation señala al formulario de InfoPath http://companyresources/DIPs/customerDIP.xsn, que implementa el panel de información del documento. Para obtener instrucciones detalladas acerca de cómo aplicar la característica AdventureWorks_Update, consulte el archivo leame.htm de la carpeta AdventureWorks_Update.

Conclusión

Puede usar tipos de contenido de SharePoint para crear directivas de metadatos y usarlas coherentemente en toda la empresa para la administración de contenido. La jerarquía de tipos de contenido le permite estandarizar características que son relevantes para todo el entorno empresarial y aplicarlas uniformemente en todos sitios mediante herencia.

Entre otras cosas, es posible ampliar las capacidades de búsqueda integradas de MOSS 2007 para que los usuarios puedan localizar contenidos específicos de manera más rápida y cómoda. También se puede aplicar la coherencia de la información relacionada con los metadatos y establecer directivas de administración de la información centralizada. La mejor estrategia consiste en estandarizar los tipos de contenido globales en las características de metadatos más abstractas para minimizar la necesidad de cambios posteriores. Basado en un modelo de contenido cuidadosamente diseñado, los tipos de contenido de SharePoint pueden proporcionar nuevas capacidades para estandarizar la administración del ciclo de vida del contenido en toda la empresa.

Pav Cherny es el presidente de Biblioso Corporation, autor y experto de TI especializado en tecnologías de Microsoft para la colaboración y las comunicaciones unificadas. Sus trabajo publicados se centran en las operaciones de TI y en la administración de sistemas.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.