SharePoint

Enfoque inteligente para recopilar datos en la empresa

Keith Deshaies

Resumen:

• Recopilar y procesar datos
• Separar la lógica de presentación de la lógica de la administración de la información
• Usar las tecnologías de Microsoft Office 2007 para elaborar una solución de recopilación de datos

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

Las empresas recopilan inmensas cantidades de información mediante distintos métodos. Los datos llegan por correo electrónico, encuestas, formularios web y otros mecanismos de recopilación de datos. Por lo general, los datos

son positivos. Sin embargo, administrar la gran cantidad de herramientas de recopilación de datos y la diversa información resulta difícil. La integración confiable y el uso compartido seguro de los datos son desafíos constantes para las organizaciones de TI. Los estándares y las arquitecturas orientadas a servicios están evolucionando, lo que facilita a los profesionales de TI aumentar la accesibilidad a los datos de manera más segura. Pero aunque se dispone de las herramientas y de las tecnologías necesarias para crear una arquitectura empresarial eficaz, es muy habitual quedar atrapado en una red de interfaces patentadas, lo que desemboca en soluciones aisladas.

Tomemos como ejemplo las tecnologías disponibles en Microsoft® Office system. Puede crear rápidamente una encuesta departamental basada en Windows® SharePoint® Services 3.0, pero el que sea una solución estándar depende de su organización. Si su compañía usa ASP.NET y SharePoint como la plataforma para la colaboración y la integración de datos basadas en la Web, esta encuesta proporciona una solución estándar. Pero si su entorno es como en el que trabajo, SharePoint es sólo una de las muchas plataformas existentes.

Efectivamente, SharePoint ofrece muchas opciones para integrarse con sistemas de IBM, HP, Siebel, etc. Son buenas noticias para los usuarios avanzados que desean crear soluciones ad hoc y que los datos resultantes fluyan a distintos sistemas back-end. No obstante, si es arquitecto de soluciones, hay una solución incluso mejor: InfoPath® 2007.

Con InfoPath 2007, que forma parte de 2007 Office system, se puede separar la lógica de presentación de las soluciones de la lógica de la administración de la información hospedada en sus servidores. Con la tecnología de InfoPath basada en XML, puede crear soluciones de recopilación de datos preparadas para la empresa. Y en la mayoría de las ocasiones, los diseñadores de formularios InfoPath no necesitan un conocimiento detallado de XML, servicios web, arquitecturas de soluciones, ASP.NET o el modelo de objetos de SharePoint.

En este artículo, explicaré cómo se pueden crear soluciones flexibles para la recopilación de datos con InfoPath 2007, Office SharePoint Server 2007 y Forms Services. Y mostraré cómo XML permite separar la lógica de presentación de la lógica empresarial en una arquitectura empresarial de varios niveles.

Tenga en cuenta que cuando me refiero a "recopilación de datos", estoy denominando al proceso de recopilación de datos de procedencia humana. Evidentemente, existen otras formas de recopilar datos, como el rastreo de orígenes de datos, pero estos métodos automatizados están fuera del ámbito de este artículo.

Adquisición y tratamiento de datos

Los requisitos de adquisición de datos pueden ser complicados, pero estos procesos tienen algunos elementos en común. Si estas similitudes se tratan en módulos centralizados mientras los requisitos únicos se tratan en componentes descentralizados, se pueden limitar los esfuerzos redundantes, la sobrecarga de mantenimiento y el costo total de la propiedad.

Por ejemplo, las normativas de cumplimiento de las compañías públicas han derivado en requisitos de negocios que, a su vez, se traducen en directivas de administración de la información en toda la compañía. Estas directivas afectan a las soluciones de recopilación de datos que traspasan los límites departamentales y suelen duplicar los esfuerzos en cada departamento. Por ejemplo, las reglas acerca de la recopilación de información de identificación personal obtenida por un departamento de recursos humanos (tratamiento de la información de empleados) y un departamento de servicio al cliente (tratamiento de la información de clientes). Incluso los procesos de negocios entre departamentos individuales que son similares pero no están relacionados proporcionan oportunidades para unificar las soluciones de administración de la información.

En la Figura 1 se muestra un ejemplo de un proceso de negocios típico. Un empleado que desee intercambiar una asignación con un compañero, primero deberá obtener su conformidad, después la aprobación de un responsable o coordinador de la programación de asignaciones y, finalmente, del supervisor. Esto podría implicar a empleados que intercambian turnos de trabajo, por ejemplo. Aunque estos intercambios se producen en departamentos diferentes y pueden basarse en formularios distintos, los flujos de trabajo y la lógica de administración de la información se pueden compartir entre varias soluciones de departamento.

Figura 1** Ejemplo del proceso de recopilación de datos que puede compartirse entre los departamentos **(Hacer clic en la imagen para ampliarla)

Como es lógico, la consolidación de los componentes redundantes es una tarea enorme. Impulsar cambios organizativos en una compañía no es tarea sencilla, pero con las tecnologías de Office system puede crear una base sólida que facilite dichos cambios. InfoPath 2007 permite que los departamentos individuales creen aplicaciones de formularios que se integren con sistemas de administración de la información centralizados y estandarizados. Mientras tanto, SharePoint 2007 permite que los departamentos de TI deleguen el control administrativo sobre colecciones, sitios y bibliotecas de documentos a departamentos individuales y equipos. Como consecuencia, los equipos pueden crear e implementar soluciones propias con una mínima intervención del departamento de TI, mientras dicho departamento mantiene el control de todos los servicios y componentes compartidos, como flujos de trabajo, directivas de administración de la información y procedimientos de copia de seguridad.

Centralización de los esfuerzos de recopilación de datos

Las empresas suelen asignar servidores de aplicaciones departamentales a los equipos para adaptar las necesidades individuales de administración de la información. El departamento de TI tan sólo es el responsable de mantener el hardware y el sistema operativo en funcionamiento, mientras que cada departamento se ocupa de todos los aspectos de sus soluciones. Hay poca coordinación entre los departamentos y, además, el uso compartido de la información resulta difícil.

Los desafíos técnicos para centralizar los esfuerzos de recopilación de datos giran principalmente alrededor de la seguridad, el rendimiento, el mantenimiento y el soporte técnico de componentes personalizados hospedados en un entorno compartido. Por ejemplo, las consecuencias de un componente que no funcione correctamente son aisladas si las soluciones individuales se hospedan en servidores de aplicaciones departamentales. No obstante, en un entorno compartido, un componente con problemas de funcionamiento puede afectar a los procesos de negocios a mayor escala. En consecuencia, el departamento de TI debe establecer directivas estrictas en relación con la implementación y el mantenimiento de componentes personalizados en sistemas centralizados.

El hospedaje de las soluciones departamentales de SharePoint en una granja de servidores central requiere la implementación y el mantenimiento de todos los componentes individuales de dichas soluciones departamentales en los servidores de aplicaciones centrales. Una solución puede basarse en tipos de campo personalizados para ampliar la interfaz de usuario de la solución con listas desplegables rellenadas desde los servicios web back-end. Otra solución tal vez puede basarse en elementos web para la misma finalidad mientras otra usa flujos de trabajo personalizados. Todas ellas están escritas en código administrado y se implementan como ensamblados de Microsoft .NET Framework.

Incluso mover una cantidad relativamente pequeña de soluciones SharePoint a una granja de servidores de aplicaciones central puede derivar en problemas difíciles de configuración y de soporte técnico. Si los ensamblados se deben implementar en la caché de ensamblados global (GAC, Global Assembly Cache), la seguridad se convierte en un problema porque los ensamblados se deben ejecutar con confianza total. Los componentes con programación deficiente pueden abrir el sistema a los ataques de inyección de SQL, XSS o de denegación de servicio. Se debe garantizar que los componentes pueden resistir la carga de trabajo típica, así como los picos de demanda y las operaciones de larga duración. Debe asegurarse de que los componentes no bloquean otros procesos, tratar los eventos sincrónicamente y que los componentes efectúan una validación de entrada confiable, para que los usuarios no puedan insertar instrucciones SQL o scripts en las columnas usadas para actualizar una base de datos o un sistema web remoto.

En resumen, el objetivo es remarcar una configuración de servidor segura y confiable basada en características de producto estándar. Al basarse en soluciones reutilizables y probadas exhaustivamente, puede evitar la trampa de crear numerosos componentes personalizados. Tiene sentido mantener el front-end descentralizado y el back-end centralizado. La clave es integrar los componentes de una forma escasamente acoplada que promueva la reutilización de las soluciones existentes.

Dividir la lógica empresarial

¿Cómo se crean soluciones flexibles para la recopilación de datos que se puedan configurar en los servidores? La mejor estrategia consiste en dividir la arquitectura de soluciones en niveles individuales, como se muestra en la Figura 2: almacenamiento de datos, lógica empresarial y presentación o IU. En la actualidad, la IU normalmente se basa en explorador mientras que la lógica empresarial se encuentra en servidores de aplicaciones web. Éstos, a su vez, tienen acceso a bases de datos y repositorios de datos no relacionales.

Figura 2** Solución empresarial típica basada en una arquitectura de tres niveles **(Hacer clic en la imagen para ampliarla)

La lógica empresarial suele incluir la lógica de transacciones para garantizar que éstas se aplican de forma atomizada en los sistemas de administración de bases de datos. La lógica empresarial también puede integrar múltiples servicios de nivel intermedio mediante HTTP, colas de mensajes, RPC, etc. No obstante, la arquitectura de soluciones general permanece esencialmente como un modelo de tres niveles.

Lo que no se ilustra en la Figura 2 es la complejidad de la lógica empresarial en un entorno de negocios. Parece como si el servidor de aplicaciones de esta figura simplemente se centrara en representar un formulario basado en explorador y en el tratamiento de los datos enviados, pero dicha representación no tiene en cuenta los flujos de trabajo, el cumplimiento o los requisitos de administración de la información. Para atender estos requisitos, se debe dividir la lógica empresarial en dos: la lógica de presentación y la lógica de administración de la información. De este modo se pueden combinar los componentes de nivel intermedio según sea necesario sin volver a crear desde cero los componentes para cada solución.

En la Figura 3 se muestra esta arquitectura. En el centro están el contenido o los datos, rodeados por la lógica de administración de la información, que controla el contenido a lo largo de su ciclo de vida. La lógica de presentación interactúa con la lógica de administración de la información para proporcionar acceso a los datos mediante la interfaz de usuario.

Figura 3** Separar la lógica de presentación de la lógica de la administración de la información **

Recopilación y procesamiento de XML

En entornos de aplicaciones orientadas a servicios (SOA, Service Oriented Application), XML es el estándar dominante que se usa para definir y compartir estructuras de datos entre los componentes. Por lo tanto, XML constituye una buena elección para la interacción entre los componentes de presentación y de administración de la información.

La comunicación se debe establecer de dos formas: se tiene que traducir el código XML en un documento legible para el explorador, así como el documento XML generado por el formulario. Hasta hace poco, la creación de aplicaciones de formularios basados en XML requería amplios conocimientos de programación. En especial, cuando los datos XML resultantes se tenían que ajustar a un esquema sectorial para facilitar el intercambio de información entre las organizaciones.

InfoPath 2007 facilita mucho el desarrollo de formularios basados en XML. Sin duda alguna, un conocimiento sólido de los detalles de XML resulta útil, pero los diseñadores de informes y los usuarios avanzados no necesitan ser magos de XML para crear aplicaciones de formularios basados en XML. El diseñador de formularios importa simplemente un documento o esquema XML en InfoPath y asigna los nodos de atributo y elemento individuales de dicho origen de datos a los campos del formulario. Un diseñador de formularios también puede empezar por un servicio web, una base de datos de SQL Server® o una plantilla en blanco y crear un formulario desde cero mientras InfoPath crea automáticamente el esquema subyacente y los enlaces de datos en segundo plano.

La estandarización de formularios mediante InfoPath y esquemas XML tiene varias ventajas. Si ya dispone de un esquema XML bien definido, los diseñadores de formularios y los desarrolladores de flujos de trabajo y componentes de administración de la información pueden crear soluciones a partir de las mismas estructuras de datos. Si un diseñador de formularios comienza desde cero, los desarrolladores deben esperar a que esté finalizado el formulario para ver de qué modo afecta a las estructuras de datos subyacentes. Una vez que las estructuras de datos están definidas, las soluciones futuras, como nuevas plantillas de formularios, pueden reutilizar flujos de trabajo y componentes de administración de la información existentes si se basan en las mismas estructuras de datos. Los flujos de trabajo y los componentes de administración de la información futuros pueden trabajar conjuntamente con formularios y datos existentes. Si crea soluciones de recopilación de datos basadas en esquemas sectoriales establecidos, los resultados son incluso más flexibles. De hecho, estas soluciones serán compatibles con soluciones creadas por otras compañías que usan los mismos esquemas.

He creado un esquema DirectReports simple que asocia los empleados a responsables. Los responsables pueden usar el formulario resultante para evaluar sus informes directos. Puede encontrar el esquema, el formulario y un archivo leame.htm con instrucciones para volver a crear el formulario en la carpeta Direct Reports en la descarga que acompaña a este artículo, disponible en technetmagazine.com/code08.aspx. El formulario es básico, pero ilustra el concepto general.

Un punto muy importante: no creé ninguna lógica de validación en InfoPath, aunque InfoPath requiere que se especifiquen el identificador de usuario y las direcciones de correo electrónico en un formato específico (dominio\cuenta y destinatario@domino.tld). De lo contrario, el documento XML resultante no es válido. Esto se debe a que el esquema XML define estos formatos. Puede guardar el formulario con datos no válidos pero no puede enviarlo, como se muestra en la Figura 4. He agregado una regla de envío ficticia al formulario para que pueda probarlo sin enviar realmente los datos a ninguna ubicación. La validación de InfoPath 2007 garantiza automáticamente que el formulario está rellenado por completo y sin estos tipos de errores.

Figura 4a** Errores de validación que impiden que el usuario envíe un formulario **(Hacer clic en la imagen para ampliarla)

Figura 4b** Mensaje de error que se genera **(Hacer clic en la imagen para ampliarla)

El esquema XML actúa de contrato vinculante entre la lógica de presentación y la lógica de administración de la información. InfoPath bloquea el esquema para que el diseñador de formularios no pueda cambiar intencionadamente las estructuras de datos. Esto es importante porque al cambiar un esquema XML establecido se pueden ver afectadas las soluciones empresariales existentes, como los módulos de flujo de trabajo que se planean usar con la plantilla de formularios.

InfoPath proporciona una gran cantidad de características para crear una lógica de presentación avanzada en las aplicaciones de formularios. Puede consumir datos de archivos XML, servicios web, bibliotecas y listas de SharePoint, bases de datos, etc., para obtener valores predeterminados significativos. Puede cambiar los valores de campo según la selección del usuario mediante reglas, incluir lógica de validación, agregar código administrado para los requisitos de personalización más avanzados y usar Forms Service para que la plantilla de formulario sea accesible a través de la Web. En cualquier caso, los datos del formulario finalmente llegan a la lógica de administración de la información como un documento XML que cumple una definición de esquema.

Trabajar con XML o metadatos

Tal vez se pregunte si debe aplicar la lógica de administración de la información directamente al documento XML enviado o usar un analizador que extraiga la información requerida en metadatos. SharePoint es compatible con ambos enfoques. Los desarrolladores están acostumbrados a trabajar directamente con documentos XML, pero los metadatos ofrecen más flexibilidad.

Para demostrarlo, he creado un servicio web simple que analiza un documento XML pasado desde el formulario de informes directos que se muestra en la Figura 4a. En la carpeta XMLParsingWebService de la descarga adjunta se pueden encontrar el código fuente, los archivos de instalación y un archivo leame.htm con instrucciones paso a paso. El servicio web lee simplemente el identificador de usuario del responsable en el documento XML, divide el identificador de usuario en las partes de dominio y nombre de usuario, crea un mensaje basado en esas partes y, a continuación, produce una excepción genérica para devolver y mostrar la información procesada en forma de un mensaje de pseudoerror en el formulario de InfoPath. Se trata de una forma sencilla de mostrar un cuadro de diálogo en InfoPath después de haber enviado los datos. El servicio web funciona bien, pero si cambia el origen de datos subyacente (por ejemplo, si cambia el nombre del elemento OrgPerson por Manager en DirectReports.xsd y actualiza el formulario de InfoPath con el nuevo esquema tal como se indica en el archivo leame.htm), se produce un error en el servicio web. Pero no es de sorprender. Ahora el documento XML es distinto y la expresión XPath anterior para tener acceso al elemento user-id ya no es válida. Los esquemas OrgPerson y Manager son prácticamente idénticos, los formularios de InfoPath son idénticos y los resultados de procesamiento deseados son los mismos, pero aunque la diferencia es mínima, se deben implementar y mantener servicios web duplicados.

Éste no es un buen enfoque si se desean minimizar las repercusiones del código personalizado en los servidores de aplicaciones. Por el contrario, si se asignan los nodos XML a los campos de metadatos y se lleva a cabo el procesamiento en los metadatos, se pueden usar los mismos flujos de trabajo y lógica de administración de la información para estructuras de datos similares, aunque los esquemas XML sean distintos. Es necesario asegurarse de que el elemento secundario se asigna al campo de metadatos correcto y que el formato de datos cumple los requisitos de procesamiento. De este modo, se puede reutilizar el código existente.

La asignación de nodos XML a campos de metadatos es similar al enlace de nodos XML a controles de IU en un formulario de InfoPath, tal como se muestra en la Figura 5. En SharePoint, los campos de metadatos corresponden a las columnas definidas en el nivel de sitio o de lista, y se hace referencia a ellos en las definiciones de tipo de contenido. Los tipos de contenido definen las características de elementos de contenido, como campos de metadatos, flujos de trabajo y formularios. Para mantener los campos de metadatos de un tipo de contenido sincronizados con los nodos correspondientes del documento XML asociado, SharePoint se basa en un analizador XML integrado que realiza la promoción/degradación de propiedades. Durante la promoción de propiedades, el analizador XML extrae los valores de nodo de un documento XML en las columnas correspondientes de la biblioteca de documentos. La degradación de propiedades hace referencia al proceso inverso en el que los valores de columna se toman de la biblioteca de documentos y se escriben en el documento. La cuestión más importante es que el analizador XML mantiene sincronizados los campos de metadatos y los nodos XML asignados.

Figura 5** Asignaciones de esquema XML entre InfoPath y SharePoint **(Hacer clic en la imagen para ampliarla)

Cuando se usa el modelo de objetos de SharePoint, los elementos web, los flujos de trabajo y la lógica de administración de la información pueden trabajar con los campos de metadatos así como con los documentos XML subyacentes. Al cambiar el valor de un campo de metadatos asignado se cambia el valor de nodo en el documento XML y viceversa. Sin embargo, al trabajar directamente con el documento XML se acopla estrechamente la lógica empresarial con el esquema XML. Por otro lado, los campos de metadatos asignados aumentan la reusabilidad del código. Evidentemente, debe decidir el enfoque que resulta adecuado para su entorno, pero la mayor parte de las soluciones de SharePoint que se basan en campos de metadatos proporcionan más flexibilidad y más posibilidad de reutilizar el código.

Para ilustrar cómo SharePoint asocia nodos XML a campos de metadatos, incluí una característica de SharePoint en el material adjunto para el aprovisionamiento de una biblioteca de documentos personalizada (consulte el archivo OrgPersonContentType.xml que se encuentra en la carpeta OrgPersonLib de la descarga adjunta). El tipo de contenido OrgPerson hace referencia a cuatro campos: UserID, FullName, EMail y Direct_x0020_Reports. FullName y EMail son campos integrados. UserID y Direct_x0020_Reports son campos personalizados definidos en OrgPersonSiteColumns.xml.

Las definiciones de campo son bastante sencillas. Se pueden enlazar campos a nodos XML directamente en las definiciones de campo, aunque también se puede sobrescribir esta información en los tipos de contenido. Decidí usar esta última técnica porque me permitía usar los campos personalizados en tipos de contenido no relacionados con documentos XML así como en tipos de contenido basados en estructuras XML diferentes. El tipo de contenido OrgPerson enlaza los campos de metadatos a nodos XML que coinciden en su organización con el esquema OrgPerson que he explicado anteriormente. También hay un archivo llamado AdditionalContentTypes.xml que define más tipos de contenido que enlazan los mismos campos de metadatos a distintos nodos XML. Puede ver las diferencias si examina las expresiones XPath en los atributos Node.

Las bibliotecas de documentos del tipo OrgPersonLib pueden almacenar distintos tipos de documentos XML mientras que los valores de nodo se exponen a través de las mismas columnas de la biblioteca. Esta sencilla técnica de asignación también permite reutilizar flujos de trabajo y lógica de administración de la información, ya que los cuatro tipos de contenido (OrgPerson, Manager, Supervisor y User) hacen referencia a un conjunto común de campos de metadatos.

En la Figura 6 se muestra el elemento FieldRef del tipo de contenido OrgPerson para Direct_x0020_Reports, que asigna el campo a los nodos user-id de los informes directos según la expresión XPath, /OrgPerson/direct-report/user-id. Como el documento XML puede incluir varias entradas de informe directo, es importante especificar un atributo Aggregation. Esta acción define cómo el analizador XML tratará la colección de valores devuelta. Si omite este atributo, el analizador XML extrae sólo el primer valor de nodo. Los valores de agregación admitidos son sum, count, average, min, max, merge, plain text, first y last.

Figura 6** Campo de metadatos asignado a una expresión XPath **(Hacer clic en la imagen para ampliarla)

Todos los tipos de contenido de ejemplo usan la página upload.aspx estándar como el valor de DocumentTemplate, por lo que puede cargar los archivos XML en la biblioteca de documentos al hacer clic en el botón Nuevo en la IU de SharePoint. Tan pronto como cargue archivos con una extensión de nombre de archivo .xml, SharePoint invocará automáticamente el analizador XML integrado (una excepción son los archivos WordProcessingML, para los que SharePoint invoca un analizador WordProcessingML). El analizador XML examina el archivo .xml cargado para determinar el tipo de contenido asociado. De este modo, puede extraer los valores de nodo de las ubicaciones especificadas en las definiciones de campo y realizar la promoción de propiedades. Puede comprobar este proceso al cargar el archivo OrgPerson.xml incluido en la carpeta OrgPersonLib\XMLFiles. La estructura de este documento XML coincide con las expresiones XPath especificadas en la definición de tipo de contenido de OrgPerson. Por consiguiente, SharePoint extrae los datos del archivo .xml, escribe los datos en las columnas de biblioteca correspondientes y muestra los datos en la página EditForm.aspx para que pueda comprobar y actualizar las propiedades de documento que no están marcadas como de sólo lectura. En la Figura 7 se muestra el formulario EditForm.aspx con los datos extraídos de OrgPerson.xml.

Figura 7** Formulario EditForm.aspx con datos extraídos **(Hacer clic en la imagen para ampliarla)

Si cambia los valores de identificador de usuario, nombre completo o correo electrónico en EditForm.aspx, SharePoint realiza la degradación de propiedades para cambiar los valores de nodo en el documento XML subyacente. Sin embargo, tenga en cuenta que SharePoint no impone las restricciones de esquema XML a menos que implemente la lógica requerida en el formulario.

SharePoint tampoco ejecuta la lógica de presentación de una aplicación de formularios. Por ejemplo, al cambiar el identificador de usuario, SharePoint no valida que el nuevo valor cumpla las convenciones de NetBIOS y no actualiza automáticamente los campos de nombre de completo y de correo electrónico para que coincidan con la nueva selección. Por lo tanto, debe marcar la columna correspondiente en la definición de contenido como de sólo lectura si el cambio de un campo puede provocar incoherencias. Esto obliga al usuario a usar la aplicación de formularios, como InfoPath para actualizar los datos. El analizador XML promocionará los cambios del documento XML a los campos de metadatos correspondientes en SharePoint.

En el ejemplo de OrgPersonLib, puede cargar cualquiera de los archivos .xml de la carpeta OrgPersonLib\XMLFiles. Los archivos .xml usan estructuras de datos muy distintas, pero SharePoint reconoce los tipos de contenido y promociona los valores de nodo correctos en las columnas de sitio. Esto se debe a que usé una instrucción de procesamiento en los archivos XML para asociar los documentos XML con sus tipos de contenido correspondientes. No obstante, el archivo OrgPerson.xml, no incluye esta información, pero esto no constituye un problema. Si SharePoint no puede asociar un documento XML a un tipo de contenido mediante una instrucción de procesamiento o la plantilla de documento, SharePoint usa el tipo de contenido predeterminado. En el caso de OrgPersonLib, se trata del tipo de contenido OrgPerson y, por lo tanto, el documento XML se analiza correctamente.

En la Figura 8 se muestra cómo se puede asociar un documento XML explícitamente con un tipo de contenido. La instrucción de procesamiento MicrosoftWindowsSharePointServices define ContentTypeID como 0x010100668E393E4F0EFF4294DBD202D5D8321D. Es el identificador del tipo de contenido User, tal como se ha definido en AdditionalContentTypes.xml.

Figura 8** Instrucciones de procesamiento y datos XML del archivo de muestra User.xml **(Hacer clic en la imagen para ampliarla)

El analizador XML procesa la instrucción de procesamiento MicrosoftWindowsSharePointServices y escribe el valor ContentTypeID en el campo de metadatos ContentType. Todos los tipos de contenido de SharePoint comparten este campo de metadatos porque está definido en el nivel raíz del tipo de contenido System. Si abre el archivo fieldswss.xml en un servidor SharePoint (se encuentra en la carpeta %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields) y busca MicrosoftWindowsSharePointServices, podrá ver cómo SharePoint asocia la instrucción de procesamiento al campo ContentType. El atributo PITarget señala a MicrosoftWindowsSharePointServices (es la instrucción de procesamiento) y el atributo PIAttribute señala a ContentTypeID (que contiene el identificador del tipo de contenido User).

Asociaciones de tipo de contenido en InfoPath

Los aspectos técnicos del análisis de XML y las asociaciones de tipo de contenido intimidan a muchos diseñadores de formularios, pero InfoPath 2007 se ocupa de todos estos detalles fundamentales. El archivo leame.htm que acompaña a la muestra OrgPersonLib incluye instrucciones para publicar la plantilla de formulario de informes directos en SharePoint y crear un tipo de contenido que vuelva a enlazar con los mismos campos de metadatos (UserID, FullName, EMail y Direct_x0020_Reports). Puede agregar fácilmente el nuevo tipo de contenido a la biblioteca de documentos de OrgPersonLib en la IU de SharePoint. Pero el nuevo tipo de contenido señala la plantilla de formulario InfoPath como la plantilla de documento para invocar las aplicaciones de formularios al actualizar los documentos XML existentes. En la Figura 9 se ilustra cómo el asistente para la publicación en InfoPath simplifica la asignación de propiedades entre los valores de nodo XML y las columnas de sitio de SharePoint. Y, de nuevo, si asocia los valores de nodo a las columnas de sitio existentes, puede reutilizar los componentes de SharePoint existentes.

Figura 9** Asignación de propiedades en InfoPath 2007 **(Hacer clic en la imagen para ampliarla)

Conclusión

Recursos en línea adicionales

• Blog del equipo de InfoPath 2007
• Desarrollo y especificaciones de esquema de XML W3C
• Introducción a los esquemas XML
• Flujos de trabajo en Office SharePoint Server 2007
• InfoPath 2007 Forms Services

Con las tecnologías disponibles en Office, los arquitectos empresariales pueden crear soluciones de recopilación de datos que promuevan la reutilización de código y el intercambio de información. InfoPath 2007 permite que los departamentos creen soluciones que puedan obtener información de varios orígenes y que los datos se puedan enviar a varios sistemas, como SharePoint. SharePoint también proporciona a los desarrolladores un amplio conjunto de servicios e interfaces web para crear flujos de trabajo y componentes de administración de la información. Si estos componentes se hospedan en servidores de SharePoint centralizados, los departamentos dispondrán de la infraestructura necesaria para crear sus propias aplicaciones individuales.

Mientras tanto, los departamentos pueden crear sus soluciones de recopilación de datos más rápidamente. Las normativas de cumplimiento y otros requisitos de negocios globales se pueden tratar en el nivel interdepartamental. La facilidad de mantenimiento y la confiabilidad del entorno de TI aumentan a medida que se reduce el uso de componentes personalizados en los servidores de aplicaciones.

Keith Deshaies es un escritor técnico independiente y analista de TI para una gran compañía de telecomunicaciones. Está especializado en tecnologías de Microsoft Office y SharePoint, y es miembro de la Sociedad para la comunicación técnica.

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