SharePoint 2010: Error al utilizar InfoPath

Al utilizar un formulario InfoPath con la RTM de SharePoint 2010 aparece un error del tipo “No se puede representar el formulario. Esto puede deberse a un problema en la configuración del Servicio de estado de Microsoft SharePoint Server”. Al analizar el log de SharePoint encontramos una traza del tipo “The FormServer is not configured properly: The StateService cannot issue a new session, either because no StateServiceApplicationProxy is bound to the current webapp, or because no online and unpaused databases could be found”.

El problema es que por defecto vienen la mayoría de los servicios de aplicación sin activar, incluido el “Servicio de estado” o “StateService”. En SharePoint 2010 el servicio de estado se provee como una aplicación de servicio, para activarlo no podremos crearlo desde la opción de “Nueva aplicación de servicio” en la Administración Central, por lo que tendremos que hacerlo desde el asistente de de configuración que encontraremos en la Administración Central, seleccionaremos la opción “Servicio de estado” y “Siguiente”.

 

Novedades InfoPath 2010

InfoPath 2010 también incorpora mejoras, sobre todo en cuanto a diseño de formularios y su publicación. Entre las principales novedades podemos destacar:

 

• El cliente InfoPath se separa en dos: InfoPath  Filler y InfoPath Designer.
• Se incorpora el Ribbon en los clientes InfoPath y en la interfaz web.
• Más fácil a la hora de publicar: Existe la publicación rápida y la avanzada.
• El WebPart de formulario admite conexiones.
• Reglas: Permiten realizar validaciones y acciones de forma fácil.
• Formularios de listas: permite personalizar los formularios de creación, edición y visualización de elementos de lista.
• Plantillas de formularios: Crea una plantilla a partir de la estructura de un origen de datos: bbdd, lista, servicio.
• Diseño de formularios: Aplica un diseño sobre el formulario ahorrando tiempo en cuanto a distribución de controles.
• Nuevos controles: Forms Services soporta nuevos controles de base, entre ellos el user picker (ya no hay que agregarlo a mano).
• Configuración desde PowerShell: Mediante PowerShell podremos configurar el servicio y desplegar las plantillas de formulario.
• La parte de administración no sufre cambios.
• Programación VSTO: Se mejora algo el MO para InfoPath, aunque de momento no hay gran cosa. El cambio se produce en la forma de desplegar el assembly generado por el código personalizado, en lugar de copiarse físicamente en los frontales, se ejecuta en modo sandbox.
• Nuevo formato de ficheros de conexiones.
• Formularios con formato XHTML.

 

Juan Carlos González ya nos dejó un recopilatorio de vídeos acerca de las novedades de InfoPath 2010.

[Infopath 2010] Requested registry access is not allowed

Al intentar entrar en la configuración de forms services de SharePoint 2010 me encontraba con que me devolvía el error “Requested registry access is not allowed’”.

El problema fue que el usuario configurado para el pool de aplicaciones de la administración central de SharePoint 2010 era “Networservices” por lo que no disponía de suficientes privilegios al impersonar determinadas acciones de administración.

La solución ya la comentó Joel Oleson’s para MOSS 2007, había que cambiar la identidad del pool de aplicaciones de la administración central por un usuario que fuera miembro del grupo de usuarios del dominio WSS_ADMIN_WPG y reiniciar el pool de aplicaciones.

Material WebCast Infopath

Que mejor forma de agradecer a todos los que estuvieron conectados la semana pasada al WebCast de infopath que colgaros el material con el que trabajamos. Aunque no nos dio tiempo a verlo todo, pudimos darle un repaso desde el principio, consejos y como conectar contra una bbdd y un servicio wcf. Igual dentro de poco hacemos una segunda parte de Infopath gracias a nuestros amigos de SUGES.

Para ver la grabación podéis entrar en http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032416012&EventCategory=4&culture=es-ES&CountryCode=ES , al registraros podréis descargarla o verla online.

 

• Presentacion WebCast Infopath NUGES.zip: Presentación para ver las versiones
• ASMXWebService.zip: Servicio web asmx para probar la lectura del usuario que realiza la solicitud.
• WcfTiposDeAusencias.zip: Servicio wcf como origen de datos lectura/escritura
• Formularios.zip: formularios de ejemplo
• SolicituDeMateriales.zip: Fuente para construir un drilldown en un formulario infopath

 

Si queréis estar informados de nuevos eventos y noticias relacionadas con Sharepoint en España, registraros en http://suges.es/

 

Nos veMOSS.

Hoy WebCast Infopath con SUGES

Hoy a las 19:30 Madrid, París de la mano de SUGES haremos un Webcast sobre Infopath. Haremos una introducción rápida para ver después que cosas podemos hacer con Infopath para aplicarlas en nuestros proyectos.

Si aún no estáis apuntados podéis entrar en http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032416012&Culture=es-ES

 

Si no tenéis el cliente Live meeting podéis descargarlo desde http://www.microsoft.com/Downloads/details.aspx?familyid=3539CB05-12FD-425B-9317-CE6AB0A2E3CF&displaylang=en

 

Nos veMOSS!!

WebCast Infopath con SUGES

El próximo 20 de Mayo a las 19:30 desde SUGES haremos el WebCast Infopath orientado a aplicaciones empresariales.

Infopath es una herramienta que suele estar desaprovechada, conocerlo mejor y saber explotarlo nos permitirá crear y proponer nuevas soluciones y servicios.

La idea es dar una introducción muy rápida para los que no lo conozcan y una visión un poco más a fondo para que los que lo hayan visto sepan que cosas se pueden hacer.

 

Podéis registraros al evento online desde http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032416012&Culture=es-ES

 

También os animo a que forméis parte de SUGES (Grupo de Usuarios de SharePoint de España) para manteneros informados de noticias y eventos acerca de sharepoint en España.

Este año que entra vienen muchas novedades y seguro que SUGES nos mantendrá bien informados.

[Infopath] Resumen

Cierro con este post la temática de este último mes acerca de Infopath orientado al desarrollo como ya hice con [Sharepoint] Introducción al desarrollo.

 

Empezando con Infopath

Introducción al concepto de Infopath

Infopath Form Services y Office Forms Server

Explicación de las distintas versiones y licenciamiento.

Formularios con Infopath

Cómo diseñar formularios y manejar los controles.

[Infopath] Orígenes de datos

Cómo manejar los distintos orígenes de datos.

[Infopath] Mostrar un formulario desde un WebPart

Como configurar el XmlFormView para visualizar un formulario infopath desde un webpart.

[Infopath] Control de selección de usuario

Cómo agregar un control para seleccionar un usuario del dominio.

Programando en Infopath

Cómo empezar a programar con Infopath

Cómo hacer un DrillDown

Post de Álvaro Arias acerca de cómo encadenar combos de selección con Infopath.

[Infopath] Promoción de propiedades

Concepto y ejemplos.

Internacionalización con Infopath

Ejemplos con distintos formatos de fecha y decimales.

 

Recursos

Microsoft Office Forms Server 2007 SDK

TechCenter de Microsoft Office Forms Server

InfoPath Team Blog

InfoPath Forms for Workflows

 

Libros

Designing Forms for Microsoft Office InfoPath and Forms Services 2007

Internacionalización con Infopath

La internacionalización en Infopath nos permite diseñar formularios para distintos idiomas y formatos. El problema lo tenemos cuando trabajamos con campos de fecha, decimales o campos moneda. Infopath nos permite definir como se visualizarán estos campos en tiempo de diseño y en ejecución. No es lo mismo “100.2” que “100,2”, tampoco es lo mismo “30/03/2009” que “03/30"/2009”.

Cuando diseñamos nuestra plantilla podemos definir el idioma para todos los controles, esto hará que aquellos controles que hereden de las propiedades definidas en la plantilla se comportarán en función del idioma indicado.

El idioma de la plantilla lo establecemos desde Opciones del formulario > Examinar > Idioma del formulario. Si no especificamos ninguno, por defecto aplicará el definido regionalmente en el equipo sobre el que se ejecute.

Sobre cada control además podemos definir en que formato queremos que se visualice.

Para los campos del tipo fecha podemos mostrar directamente el valor almacenado en xml, indicar un formato específico o que el formato sea el indicado por la cultura regional.

Para los campos de tipo decimal o doble, podemos definir el número de dígitos decimales y el separador de millares.

Para verlo con más claridad he diseñado una plantilla que muestra un campo de tipo fecha y numérico en distintos formatos:

• El 1º muestra el valor xml
• El 2º muestra la fecha en función de la zona definida
• La 3º muestra la fecha en formato DD/MM/YYYY
• El 4º y 5º muestran un control fecha asociado a un campo del tipo texto.
• El 6º muestra el valor decimal almacenado en el xml.
• El 7º muestra con separadores
• El último muestra sin separadores de millares

En Español:

En Inglés:

Y cómo afecta la internacionalización al xml generado?, si abrimos el xml generado en los dos casos veremos que tenemos un xml similar:

Español:

<?xml version="1.0" encoding="UTF-8"?><?mso-infoPathSolution solutionVersion="1.0.0.5" productVersion="12.0.0" PIVersion="1.0.0.0" href="file:///C:\Users\Administrador\AppData\Local\Microsoft\InfoPath\Designer2\e706af73eab64283\manifest.xsf" ?><?mso-application progid="InfoPath.Document" versionProgid="InfoPath.Document.2"?><my:misCampos my:Fecha2="2009-04-24" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:my="http://schemas.microsoft.com/office/infopath/2003/myXSD/2009-04-20T21:11:49" xmlns:xd="http://schemas.microsoft.com/office/infopath/2003" xml:lang="">
<my:Fecha1>2009-04-11</my:Fecha1>
<my:Decimal1>1234567.89</my:Decimal1>
</my:misCampos>

Inglés:

<?xml version="1.0" encoding="UTF-8"?><?mso-infoPathSolution solutionVersion="1.0.0.5" productVersion="12.0.0" PIVersion="1.0.0.0" href="file:///C:\Users\Administrador\AppData\Local\Microsoft\InfoPath\Designer2\e706af73eab64283\manifest.xsf" ?><?mso-application progid="InfoPath.Document" versionProgid="InfoPath.Document.2"?><my:misCampos my:Fecha2="2009-04-09" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:my="http://schemas.microsoft.com/office/infopath/2003/myXSD/2009-04-20T21:11:49" xmlns:xd="http://schemas.microsoft.com/office/infopath/2003" xml:lang="">
<my:Fecha1>2009-04-15</my:Fecha1>
<my:Decimal1>12345678.67</my:Decimal1>
</my:misCampos>

De modo que si queremos manejar estos valores en los tipos nativos de .NET podemos hacer lo siguiente:

Para las fechas podemos utilizar directamente “DateTime.parse”.

Para los decimales o dobles tendremos que utilizar “double.parse” pero especificando el idioma ingles. Si quisiéramos realizar una validación desde infopath podríamos hacer algo como esto:

public void Decimal1_Validating(object sender, XmlValidatingEventArgs e)
{
if (!string.IsNullOrEmpty(e.NewValue))
{
System.Globalization.CultureInfo en = new System.Globalization.CultureInfo(1033);
double valor = double.Parse(e.NewValue, en);
}
}

Y qué pasa si abrimos un fichero xml generado con una plantilla en un idioma y lo abrimos en otro idioma?, pues que infopath convertirá automáticamente los valores sin lanzar ninguna excepción.

[Infopath] Promoción de propiedades

Nos queda por ver como relacionar los formularios infopath con Sharepoint más allá de la visualización. Para ello vamos a ver la promoción de propiedades y como manejar el elemento generado mediante un EventHandler desde Sharepoint.

La promoción de propiedades consiste en extraer los valores de ciertos campos del formulario para utilizarlos en otro entorno como por ejemplo sharepoint, pudiendo manejarlos en vistas, búsquedas, workflows, etc.

Si continuamos con nuestro ejemplo de notas de gasto de los anteriores post, promocionarnos la propiedad del campo “estado” para controlarlo desde un EventReceiver y así controlar que no se pueda editar el documento una vez entregado.

Al guardar los datos de un formulario infopath podremos indicarle que lo haga sobre una biblioteca de documentos de Sharepoint, que llame a un servicio web, que lo envíe por correo o que lo envíe en modo post a a una páginas web. En sharepoint lo guardaremos en una biblioteca de formularios. Al guardar el formulario, infopath creará sobre la biblioteca indicada un fichero xml con los datos introducidos. Podemos entonces asociar a la biblioteca un EvenReceiver, un Workflow o promocionar propiedades.

Asociaremos entonces un EvenReceiver sobre la biblioteca que tenía asociada la plantilla xsn con nuestro formulario. Este EvenReceiver controlará el estado de la nota de gasto de forma que una vez la hayamos entregado no podamos volver a editarla. Hasta ahora no habíamos definido ningún campo “estado” en nuestra plantilla, por lo que ¿cómo lo agregamos para que podamos leer desde el formulario infopath y el EvenReceiver de sharepoint?, pues con la promoción de propiedades. Básicamente consiste en indicar tanto a sharepoint como a infopath que camos del origen de datos principal se va a compartir. Para infopath la propiedad promocionada será como un campo más del origen de datos principal, y para sharepoint corresponderá con una nueva columna en la biblioteca donde se aloje la plantilla xsn.

Abrimos entonces nuestro fichero EjemploNotasDeGasto.xsn en modo edición. Agregamos un campo al origen de datos principal un nuevo campo con el nombre “Estado” del tipo texto, además marcaremos que se pueda editar el campo desde una venta de propiedades.

A continuación publicamos nuestra plantilla sobre una biblioteca de documentos, en esta ocasión lo he publicado como plantilla de una biblioteca de formularios con compatibilidad de explorador. Es importante que antes de publicar indiquéis en las propiedades de la plantilla que determine el nivel de seguridad automáticamente.

Una vez indicada la biblioteca os aparecerá una pantalla con el siguiente aspecto, sobre la que agregaremos una nueva columna sobre la que indicaremos la relación entre la columna de la biblioteca con el campo del origen de datos del formulario infopath.

Una vez publicado nuestra plantilla xsn veremos en las propiedades de nuestra biblioteca una nueva columna:

Con VisualStudio creamos un EvenReceiver y lo asociaremos a la biblioteca de forma que cuando el usuario rellene el campo “Responsable” cambiemos el valor del campo “Estado”.

Pero fijaros que el responsable no es una propiedad promocionada, entonces ¿cómo leemos los datos xml generados por infopath para conocer los valores del Responsable?:

• Promocionando la propiedad
• Leyendo los datos guardados por infopath en modo xml

Si abrimos el fichero xml generados por la plantilla encontraremos algo como esto
<?xml version="1.0" encoding="utf-8"?>
<?mso-infoPathSolution name="urn:schemas-microsoft-com:office:infopath:Plantilla1-2:-myXSD-2009-03-20T16-27-26" solutionVersion="1.0.0.29" productVersion="12.0.0.0" PIVersion="1.0.0.0" href="http://w2k3r2:17092/FormServerTemplates/Plantilla1_2.xsn"?>
<?mso-application progid="InfoPath.Document" versionProgid="InfoPath.Document.2"?>
<my:misCampos xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:my="http://schemas.microsoft.com/office/infopath/2003/myXSD/2009-03-20T16:27:26" xmlns:xd="http://schemas.microsoft.com/office/infopath/2003" xml:lang="es-ES">
<my:txtNombre>Mario</my:txtNombre>
<my:txtEmail>mcortes@renacimiento.com</my:txtEmail>
<my:txtApellidos>Cortés flores</my:txtApellidos>
<my:txtNumeroEmpleado>338877</my:txtNumeroEmpleado>
<my:grupo1>
<my:grupo2>
<my:txtFecha>2009-04-02</my:txtFecha>
<my:txtImporte>11</my:txtImporte>
<my:tipoDeGasto>Taxi</my:tipoDeGasto>
</my:grupo2>
</my:grupo1>
<my:txtObservaciones></my:txtObservaciones>
<my:gpResponsable>
<my:Responsable>
<my:DisplayName></my:DisplayName>
<my:AccountId></my:AccountId>
<my:AccountType></my:AccountType>
</my:Responsable>
</my:gpResponsable>
</my:misCampos>

Si accedemos por código al objeto SPListItem que representa el elemento almacenado dispondremos de la propiedad “File” que podremos leer abriendo un stream de la siguiente forma:

XmlDocument xmlNotaDeGasto = new XmlDocument();
XmlTextReader
xmlTextReader = new XmlTextReader(properties.ListItem.File.OpenBinaryStream());
xmlNotaDeGasto .Load(xmlTextReader );

Una vez cargado los datos como un XmlDocument accederemos al campo "my:AccountId” para leer el valor. El problema vendrá cuando intentemos acceder por ejemplo con el método “SelectSingleNode”, obtendremos una excepción pidiéndonos un “XmlNamespaceManager”, si lo creamos y lo pasamos a SelectSingleNode obtendremos otra excepción del tipo “unrecognized ‘my’ prefix”. Para solucionarlo crearemos el XmlNamespaceManager de la siguiente forma:

public XmlNamespaceManager InitNamespaceManager(XmlDocument xmlDOMDoc)
{
XmlNamespaceManager xnmMan;

xnmMan = new XmlNamespaceManager(xmlDOMDoc.NameTable);

foreach (XmlAttribute nsAttr in
xmlDOMDoc.DocumentElement.Attributes)

{

if (nsAttr.Prefix=="xmlns")

xnmMan.AddNamespace(nsAttr.LocalName,nsAttr.Value);

}

return xnmMan;

}

Para crear el EvenReceiver he utilizado las extensiones VseWSS 1.3 y el código quedaría una cosa así:

public class NotasDeGastoItemEventReceiver : SPItemEventReceiver
{
public NotasDeGastoItemEventReceiver()
{
}

public override void ItemAdding(SPItemEventProperties properties)
{
ItemUpdating(properties);
}

public override void ItemUpdating(SPItemEventProperties properties)
{
try
{
if
(string.IsNullOrEmpty((string)properties.ListItem["Estado"]))
{
XmlDocument xmlNotaDeGasto = new XmlDocument();
XmlTextReader
xmlTextReader = new XmlTextReader(properties.ListItem.File.OpenBinaryStream());
xmlNotaDeGasto.Load(xmlTextReader);
XmlNode nodoAccountResponsable =
xmlNotaDeGasto.SelectSingleNode("//my:AccountId",
InitNamespaceManager(xmlNotaDeGasto));
string nuevoEstado;
if
(!string.IsNullOrEmpty(nodoAccountResponsable.InnerText))
nuevoEstado =
"Publicado";
else
nuevoEstado = "Borrador";

DisableEventFiring();
try
{
properties.ListItem["Estado"] = nuevoEstado;
}
finally
{
EnableEventFiring();
}
}
}
catch
{
properties.ErrorMessage = "Se ha producido un error que impide la
modificación";
properties.Status = SPEventReceiverStatus.CancelWithError;
}
}

public override void ItemDeleting(SPItemEventProperties properties)
{
if (!string.IsNullOrEmpty((string)properties.ListItem["Estado"])&&
(string)properties.ListItem["Estado"] != "No iniciado" &&
(string)properties.ListItem["Estado"] != "Borrador")
{
properties.ErrorMessage = "La nota de gasto no puede borrarse";
properties.Status = SPEventReceiverStatus.CancelWithError;
}
}

#region "Helper"
public XmlNamespaceManager
InitNamespaceManager(XmlDocument xmlDOMDoc)
{
XmlNamespaceManager
xnmMan;
xnmMan = new XmlNamespaceManager(xmlDOMDoc.NameTable);
foreach
(XmlAttribute nsAttr in xmlDOMDoc.DocumentElement.Attributes)
{
if
(nsAttr.Prefix == "xmlns")
xnmMan.AddNamespace(nsAttr.LocalName,
nsAttr.Value);
}
return xnmMan;
}
#endregion "Helper"

}

Por último nos queda controlar desde el formulario que solo se pueda abrir en modo edición cuando el valor del campo estado no sea “No entregado” o “Borrador, (en este caso no lo vamos a hacer por programación sobre Infopath), bloquearemos los controles usando los “formatos condicionales”. Desde las propiedades de cada uno de los controles desde la pestaña “Presentación” > formato condicional > agregar.

Programando en Infopath

Hasta ahora solo hemos visto de Infopath ha sido desde el diseñador, toca mojarse un poquito con el código. ¿Podemos escribir código en un formulario Infopath para que actúe de acuerdo a una lógica de negocio?, pues sí, para éllo Infopath utiliza las VSTA (Microsoft Visual Studio Tools for Applications). Con VSTA podremos programar en Visual Basic .NET o c# de forma integrada con el formulario que estemos diseñando. Todo lo que desarrollemos generará una dll que irá incrustada en nuestra plantilla xsn. Si utilizamos Infopath Forms Services al subir nuestra plantilla a Sharepoint se desplegará automáticamente una solución wsp de sharepoint con todos los elementos de nuestro formulario y lo mejor de todo es que además deplegará la dll necesaria para ejecutar nuestro código.

Empezando con las VSTA

Lo primero que necesitamos son las VSTA, aunque tengamos instalado Visual Studio las vamos a tener que instalar, si no lo hacemos nos encontraremos un mensaje de error del tipo: “Infopath no puede iniciar Microsoft Visual Studio Tools para aplicaciones”

Para instalarlo necesitaremos tener el Framework 2.0 y habilitar el paquete desde el setup de nuestro infopath u office seleccionando el elemento “Infopath > Compatibilidad con programación .net > Compatibilidad con programación .net para .net framework versión 2.0 > Visual Studio Tools para aplicaciones.

Una vez instalado antes de empezar a tirar líneas debemos pensar donde vamos a alojar el código generado. Desde herramientas > opciones del formulario > programación encontraremos una ventana con las opciones disponibles, en nuestro caso elegiremos el lenguaje .net en el que generaremos el proyecto y el path físico donde se alojará el proyecto de las VSTA.

Este paso es importante ya que por defecto viene en visual basic y en la carpeta “Mis documentos”. Además cuando publiquemos la plantilla se incrustará la dll ya compilada pero no el código del proyecto, por lo que si copiamos a otro equipo solo el xsn no estaremos copiando los fuentes pudiendo llegar a perderlos.

Manejar eventos en infopath

Aunque podemos definir reglas y condiciones desde el diseñador (“no se por qué”) siempre hay alguna condición que debemos escribir mediante código. Usaremos el manejo de eventos de infopath para validar las entradas del formulario.

Continuando con el anterior ejemplo [Infopath] Control de selección de usuario, incluiremos por ejemplo una validación en la caja de importes para controlar que no se introduzcan importes superiores a 1000€. Seleccionando con el botón derecho la caja Programación > Evento Validating.

Al seleccionarlo se abrirá una ventana de visual studio con el siguiente aspecto:

Lo primero que debemos saber es que no un Visual Studio normal, si vamos a la ayuda y vemos la versión veremos que es un Visual studio 2005 especial.

Otra cosa a destacar es que en la ventana de exploración no disponemos de un elemento solución solo disponemos del proyecto dll con las referencias a las VSTA y a infopath. Si luego buscamos en el path indicado para los fuentes veremos que realmente hay un fichero .sln que nos será muy útil.

También destacamos el fichero .snk necesario para que la dll tenga un strongname y pueda registrarse con un publickey.

Vemos también que no disponemos de un evento “Onload” sino que disponemos del método “InternalStartup” desde el que registraremos todos los eventos que desearemos capturar en el formulario en tiempo de ejecución. Esto se debe a que nuestra clase hereda de Microsoft.Office.InfoPath.XmlFormHostItem.

Siguiendo con el ejemplo, vemos que el evento de validación generado recibe un parámetro XmlValidatingEventArgs con la referencia al elemento de nuestro origen de datos principal el cual a generado el evento. En mi caso el ejemplo quedaría:

public void txtImporte_Validating(object sender, XmlValidatingEventArgs e)
{
if(!string.IsNullOrEmpty(e.NewValue))
if (double.Parse(e.NewValue) > 1000)
{
e.ReportError(e.Site, false, "El importe debe ser inferior a 1000€");
}
}

Para probarlo podremos hacerlo desde la opción de ejecución de Visual Studio o desde la vista previa del diseñador del cliente Infopath.

Otro de los eventos que podemos controlar es el del envío de los datos al servidor al hacer Submit. Desde el evento InternalStartup agregaremos una línea del tipo:

EventManager.FormEvents.Submit += new SubmitEventHandler(Form_Submit);

donde “Form_Submit” es el nombre de mi método para capturar el evento. En mi ejemplo voy validar que la suma de todos los importes no supere los 3000€ quedando un código similar al siguiente:

public void Form_Submit(object sender, SubmitEventArgs e)

{

XPathNavigator navigator = MainDataSource.CreateNavigator();

XPathNodeIterator importesSolicitados = navigator.Select("/my:misCampos/my:grupo1/my:grupo2", this.NamespaceManager);

double importeTotal = 0.0;

foreach (XPathNavigator importeSolicitado in importesSolicitados)

{

string stImporte = importeSolicitado.GetAttribute("txtImporte", "");

importeTotal += double.Parse(stImporte);

}

if (importeTotal > 3000.0)

{

e.CancelableArgs.Cancel = true;

e.CancelableArgs.Message = "El importe total de los gastos no debe superar los 3000€";

}

}

Si quisiéramos manejar el evento de carga del formulario utilizaríamos en el InternalStartup algo similar a lo siguiente:

EventManager.FormEvents.Loading += new LoadingEventHandler(FormEvents_Loading);

Manejar los orígenes de datos

Como vimos en el post [Infopath] Orígenes de datos disponemos de varios tipos de orígenes de datos en Infopath.

Para acceder al origen de datos principal utilizaremos la propiedad “MainDataSource”.

Para acceder a los orígenes externos utilizaremos la propiedad DataSources y accederemos a los orígenes mediante el nombre indicado en el diseñador, por ejemplo:

DataSources[“TiposDeGastos”]

Alvaro Arias nos muestra un ejemplo de como hacer un DrillDown de combos con infopath.

Depurar una plantilla infopath compleja

Cuando trabajemos con plantillas con orígenes externos nos será muy difícil depurar directamente desde el cliente infopath. Una alternativa consiste en abrir la solución generada por VSTA directamente desde Visual Studio en lugar desde Infopath, generar la dll en debug y sustituir el assembly, y depurarlo atacando al proceso w3wp.

El fichero sln de la solución lo encontraremos en la carpeta física establecida en la configuración de programación de la plantilla.

Para sustutir el assembly que depliega Infopath Form Services tenemos que buscar la feature instalada físicamente ya que no lo registra en el GAC. Un truco es buscar la característica de colección instalada, darle a desactivar y en la pantalla de confirmación en la url tendremos un parámetro FeatureId con el nombre de la carpeta que contiene nuestra dll a sustituir.

[Infopath] Control de selección de usuario

Cuando diseñamos un formulario para ser utilizado en Infopath Forms Services debemos tener en cuenta que no todos los controles son compatibles con el explorador. Esto se debe a que el cliente de Infopath es mucho más rico que el motor de Infopath Form Service, debemos verificar en el diseño si nuestro control es compatible en modo explorador.

Nos puede surgir el caso en el que el cliente nos solicite que el formulario pueda seleccionar un usuario del dominio, ¿Es este control compatible?, pues sí (a medias), pero debemos agregarlo a los controles personalizados ya que no aparece en la lista de controles estándar.

Desde la ventana de “Tareas de diseño” > seleccionamos agregar u ocultar controles personalizados > agregar… > control activex > contact selector

Para poder utilizarlo tendremos que tenerlo registrado, aunque también podemos hacer que el propio fichero xsn incluya el fichero .cab con la instalación del Activex.

Para que sea compatible con Infopath Forms Service debemos marcar “No incluir un fichero cab”.

En la pantalla siguiente de enlace de propiedades seleccionamos “value”. A continuación indicamos a Infopath como se guardarán los datos, seleccionamos “Campo o grupo (cualquier tipo de datos)”.

Al finalizar dispondremos del control para ser arrastrado al formulario. Solo quedaría asociarlo a un grupo de datos, pero este debe tener una estructura determinada.

En la sección de orígenes de datos “agregamos un campo o grupo” > seleccionamos > grupo > indicamos un nombre de grupo. Repetimos el mismo proceso e indicamos el nombre que representa el registro que se repetirá por cada uno de los controles, no os olbideis de marcar “repetir”. Por último agregamos al anterior grupo los campos de tipo texto: DisplayName, AccountId y AccountType.

Solo quedaría enlazar el control al grupo extensible seleccionando el control y con el botón derecho "cambiar enlace".

Al probar nuestro formulario sobre Sharepoint veremos algo similar a la siguiente imagen:

La entrada original la podéis encontrar en: Using the Contact Selector Control

[Infopath] Mostrar un formulario desde un WebPart

Siguiendo con el post anterior “[Infopath] Orígenes de datos”, veremos como visualizar un formulario de Infopath desde un WebPart. Recordar que para poder renderizar un formulario necesitaremos de Infopath Services, además tendremos que haber habilitado la compatibilidad del formulario para que se pueda abrir en el explorador, desde la opciones del formulario > Compatibilidad > compatibilidad de explorador > marcaremos “Diseñe una plantilla de formulario que se pueda abrir en un explorador o infopath”.

Utilizaremos el WebPart “XmlFormView” que está alojado en la librería Microsoft.Office.InfoPath.Server.dll. Antes de poder agregarlo debemos asegurarnos que lo tenemos registrado correctamente como safecontrol, agregaremos en el fichero web.config la entrada:

<SafeControl Assembly="Microsoft.Office.InfoPath.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.Office.InfoPath.Server.Controls" TypeName="*" Safe="True" />

A continuación iremos a la galería de elementos web en la configuración de nuestro sitio > seleccionaremos la opción “Nuevo” > marcaremos el webpart “Microsoft.Office.InfoPath.Server.Controls.XmlFormView” > Llenar galería. Esto hará que el webpart esté disponible para ser agregado desde cualquiera de las páginas de nuestra colección.

En la página que deseemos agregar el WP la editaremos y agregaremos el WP con título “XmlFormView”. La primera vez puede que nos muestre un error de infopath diciendo que no tenemos la plantilla adecuada, esto se debe a que todavía no lo hemos configurado y está intentando renderizar el formulario.

Editaremos entonces las propiedades del webpart añadido y en la sección “Enlace de datos” indicaremos el fichero xsn y la librería donde se guardarán los datos xml generados por el formulario.

En la propiedad XsnLocation indicaremos la ruta del fichero xsn, en mi caso he publicado desde Infopath el formulario de notas de gasto en una biblioteca de documentos de forma que la ruta queda: http://w2k3r2:17092/FormServerTemplates/EjemploNotasDeGastos.xsn

Si os aparece siempre el mensaje “Formulario cerrado” verificar el fichero de log de Sharepoint, que tenéis la url correctamente, que habéis indicado una ruta para SaveLocation y la propiedad “EditingStatus”. Aseguraros además que habéis publicado correctamente el formulario desde la administración central y lo habéis activado para la colección actual.

[Infopath] Orígenes de datos

Con infopath podremos manejar datos procedentes de distintos orígenes: Xml, Una base de datos, un servicio web y una lista de sharepoint.

Para manejar los orígenes de datos iremos al menú Tareas de diseño > Orígenes de datos, siempre tendremos al menos el origen de datos Principal como comentábamos en el anterior post “Formularios con Infopath”. Recordar que el origen de datos principal contiene la estructura del xml que generará Infopath al guardar el formulario.

Para agregar una nueva conexión seleccionaremos “Agregar conexiones de datos…”. Al seleccionar esta opción se abrirá una ventana con las conexiones de los distintos orígenes configuradas. Para agregar un origen de datoa tendremos que configurar primero la conexión y el tipo de acción lectura/escritura.

Los datos sensibles de las conexiones como pueda ser el usuario y contraseña se pueden guardar o bien incrustados en el infopath o en una librería de conexiones. Si incrustamos los datos de conexiones se guardarán dentro del fichero y solo podremos modificarlos editando el fichero xsn dede Infopath. Lo recomendable es que usemos fichero de conexiones, que consisten en ficheros con los datos de conexión y se alojan en sahrepoint, en caso de cambiar algún dato de conexión (por ejemplo al cambiar de entorno), solo tenemos que tocar el fichero de conexión y subirlo de nuevo. 

Leer datos

Agregaremos entonces una nueva conexión e indicaremos que deseamos “recibir datos”, a continuación indicamos desde donde queremos leerlos.

Leer de una base de datos

Mediante esta opción podremos ejecutar una consulta SQL contra una base de datos. Indicamos entonces que queremos leer de una base de datos y agregamos una nueva conexión. En mi ejemplo he creado una tabla con los tipos de gastos en mi SqlServer. La primer vez tendremos que crear un fichero de conexión de datos que se almacenará en nuestro pc, seleccionando la opción “Nuevo origen de datos” indicamos el tipo de conexión, en mi caso “Microsoft Sql Server“ y a continuación los datos de conexión (servidor, usuario, contraseña, etc). En caso de disponer del fichero solo tendremos que seleccionarlo.

Una vez hemos conectado con nuestra bbdd, elegiremos las tablas y campos a consultar o bien editamos nuestra consulta sql.

Por último, podremos indicar si queremos que almacene los datos en el propio fichero xsn y si queremos que ejecute la consulta al abrirse el formulario.

 

Ahora que tenemos configurado nuestro origen de datos, haremos que el control de tipo de gastos muestre los datos de este origen. En las propiedades del control seleccionamos “Buscar valores desde un origen de datos externo” > indicamos el origen previamente configurado. En el campo Entradas seleccionamos la tabla o la entrada de registro que queremos mostrar, en “valor” el campo que contiene valor del elemento seleccionado  y en “nombre para mostrar” el campo con la descripción que visualizará el usuario.

Para verificar que hemos configurado correctamente todo podemos realizar una vista preliminar y comprobar que se cargan todos los datos.

 

Leer datos de un servicio web

Seleccionamos como antes “agregar conexión de datos” > recibir > servicio web, indicamos la url de nuestro servicio web, para el ejemplo voy utilizar los servicios de Sharepoint para leer el contenido de una lista con los tipos de gastos, de manera que la url sería “http://w2k3r2:17092/_vti_bin/lists.asmx?WSDL”. Al darle a “Siguiente” el asistente de conexión mostrará todos los métodos disponibles, para el ejemplo he seleccionado “GetListItems” que corresponde con el método que devuelve todos los elementos de una lista de Sharepoint. Como existe un problema de interpretación de tipos entre Infopath y los servicios de Sharepoint, he necesitado de un servicio web intermedio que tenga una definición de tipos de parámetros que entienda Sharepoint (ver ejemplo : http://wssdev.blogspot.com/2007/06/infopath-use-sharepoint-web-services.html).

Al aplicar el servicio de proxy los tipos los he convertido a “string”, con lo que puedo establecer los parámetros obligatorios desde Infopath con la opción “establecer valor”. Una vez agregado el origen de datos volveremos a configurar nuestro control para que lo utilice. Fijaros que en este caso la estructura XML del origen de datos generada por el servicio es más compleja que la anterior.

Podéis descargaros el código del servicio web intermedio en http://blogs.renacimiento.com/mcortes/Documentos/WebService1.zip

 

 

Insertar Datos

Solo nos queda ver como guardar los datos introducido en el formulario. A este proceso Infopath lo llama “Envío de datos” y disponemos de los siguientes tipos de orígenes de datos: a un servicio web, a una biblioteca de sharepoint, por correo electrónico y a una página ASP.NET. En este caso no disponemos de la opción de una bbdd por lo que si queremos guardarlos en una tabla tendremos que utilizar un servicio web o una página ASP.Net. El problema que podemos encontrarnos si lo hacemos de este modo es que el envío puede que sea de un nuevo elemento o de una actualización, por lo que tendremos que ser nosotros los que detectemos esto.

Si lo queremos guardar en una biblioteca de sharepoint tenemos dos opciones, o bien definimos nuestro formulario como plantilla de una biblioteca o hacemos que el envío se haga hacia una biblioteca independientemente de donde se aloje nuestro formulario.

Para hacer que nuestro formulario aparezca al darle a´l menú “Nuevo elemento” de una biblioteca seleccionaremos la opción de archivo > publicar > en un servidor de sharepoint > indicamos la url.

Para enviar los datos a una biblioteca de documentos, seleccionamos Administrar conexiones de datos > agregar > enviar > a una biblioteca de documentos. Una vez creado el origen de envío indicaremos al formulario que debe usarlo para enviar los datos desde la opción Herramientas > opciones de envío > permitir a los usuarios enviar este formulario > biblioteca de documentos de sharepoint > Seleccionamos nuestra conexión de envío. Esto hará que al visualizar nuestro formulario aparezca una opción con el título “Enviar” y al seleccionarlo enviará el xml generado por infopath a la biblioteca indicada.

 

Ficheros de conexiones de datos

Hasta ahora las configuraciones de las conexiones a nuestros orígenes de datos se han guardado de forma embebida en el fichero xsn. Si ahora tuviéramos que utilizar nuestro formulario en otro entorno tendríamos que volver a editarlo y modificar los datos de conexión. Una forma de evitar esto es mediante el uso de ficheros de conexión, básicamente son ficheros xml con los datos de conexión que tendremos que subir a Sharepoint.

Podemos alojar los ficheros en dos sitios en una biblioteca de conexiones de una colección de sitios específica o en una biblioteca de conexiones de la administración central. Os recomiendo guardarlos en la administración central, aunque dependiendo del tamaño de vuestra granja puede ser recomendable la otra opción.

Para crear un fichero de conexión abriremos la lista de conexiones en “Administrar conexiones de datos” > Convertir > indicamos la url de la biblioteca de conexiones > seleccionamos el tipo de biblioteca de conexión.

Una vez guardado el fichero podéis descargarlo de la biblioteca y editarlo como un fichero xml.

Mi fichero de conexión a la bbdd es el siguiente:

<?xml version="1.0" encoding="UTF-8"?>
<?MicrosoftWindowsSharePointServices ContentTypeID="0x010100B4CBD48E029A4ad8B62CB0E41868F2B0"?>
<udc:DataSource MajorVersion="2" MinorVersion="0" xmlns:udc="http://schemas.microsoft.com/office/infopath/2006/udc">
    <udc:Name>TiposDeGastos</udc:Name>
    <udc:Description>Format: UDC V2; Connection Type: Database; Purpose: ReadOnly; Generated by Microsoft Office InfoPath 2007 on 2009-03-30 at 01:29:53 by PIGNOISE\Administrador.</udc:Description>
    <udc:Type MajorVersion="2" MinorVersion="0" Type="Database">
        <udc:SubType MajorVersion="0" MinorVersion="0" Type=""/>
    </udc:Type>
    <udc:ConnectionInfo Purpose="ReadOnly" AltDataSource="">
        <udc:WsdlUrl/>
        <udc:SelectCommand>
            <udc:ListId/>
            <udc:WebUrl/>
            <udc:ConnectionString>Provider=SQLOLEDB.1;Password=misgastos;Persist Security Info=True;User ID=misgastos;Initial Catalog=Pruebas;Data Source=w2k3r2;Use Procedure for Prepare=1;Auto Translate=True;Packet Size=4096;Workstation ID=PIGNOISE;Use Encryption for Data=False;Tag with column collation when possible=False</udc:ConnectionString>
            <udc:ServiceUrl UseFormsServiceProxy="false"/>
            <udc:SoapAction/>
            <udc:Query>select "IdTipo","Descripcion","Activo" from "dbo"."TiposDeGastos" as "TiposDeGastos"</udc:Query>
        </udc:SelectCommand>
        <udc:UpdateCommand>
            <udc:ServiceUrl UseFormsServiceProxy="false"/>
            <udc:SoapAction/>
            <udc:Submit/>
            <udc:FileName>Specify a filename or formula</udc:FileName>
            <udc:FolderName AllowOverwrite=""/>
        </udc:UpdateCommand>
        <!--udc:Authentication><udc:SSO AppId='' CredentialType='' /></udc:Authentication-->
    </udc:ConnectionInfo>
</udc:DataSource>

 

La forma de subir los ficheros está muy bien explicada en el post de Juan Carlos González enMOSS: Publicación de formularios Infopath…el otro camino!.

 

Podéis descargaros la nueva plantilla en http://blogs.renacimiento.com/mcortes/Documentos/EjemploNotasDeGasto2.xsn

Podéis descargaros el código del servicio web intermedio en http://blogs.renacimiento.com/mcortes/Documentos/WebService1.zip

 

Hasta aquí los orígenes de datos, hay muchas más opciones pero lo que no hay es tiempo, así que os dejo trastear.

Formularios con Infopath

Después de unos días preparando una serie de materiales por fin he sacado un hueco para continuar con la temática de infopath. En el post anterior hablábamos acerca de la diferencia entre “Infopath Form Services y Office Forms Server” y “Empezando con Infopath”. En este post veremos cómo definir un formulario en Infopath y las opciones de publicación.

Para crear un formulario Infopath tendremos que diseñar una “plantilla de formulario”, que consiste en un fichero con extensión “.xsn” que contendrá la definición del formulario, los recurso adjuntos, consultas sql o servicios web, código .net (dll).

Empezaremos abriendo el cliente Microsoft Office Infopath y seleccionaremos la opción “Diseñar una plantilla de formulario”, a continuación seleccionamos una plantilla en blanco. Se abrirá entonces una ventana en blanco sobre la que diseñaremos nuestro formulario. entre los elementos disponibles distinguimos los siguientes:

• El menú superior con todas las opciones disponibles.
• El menú lateral de tareas de diseño, básicamente un acceso directo a las opciones de diseño del formulario. La zona de diseño, corresponde con la zona central sobre la que desplazaremos los controles para diseñar nuestro formulario.

Para el ejemplo vamos a diseñar un formulario con el que podamos insertar las notas de gasto (podéis descargaros la plantilla de ejemplo), para ello tendremos que solicitar al usuario los datos personales para saber de quien son los gastos, la fecha de los gastos, el concepto, el importe y un campo de observaciones.

Lo primero que vamos a hacer es insertar una tabla para distribuir el contenido de forma uniforme. Seleccionamos en el menú de tareas de diseño > diseño >Tabla personalizada ... Nos aparecerá un cuadro de diálogo preguntando por la distribución de columnas y filas de la tabla, en nuestro ejemplo insertamos 1 columna y el menos 3-5 filas. La primera fila la utilizaré para insertar una imagen con el logo de la empresa y un texto con el título del formulario. Si queremos alinearlo un poco más podemos insertar otra tabla dentro de la primera fila.

Para insertar la imagen tendemos dos opciones: agregarla como recurso incrustado en la plantilla o como vínculo a un campo del formulario. En nuestro caso la agregaremos como recurso del formulario, es decir, la imagen se almacenará dentro del fichero xsn. Podremos hacerlo desde el menú de tareas de diseño > controles > imagen o bien arrastrando el fichero de la imagen sobre la superficie de diseño.

Para disponer de una vista preliminar del formulario podemos seleccionar la opción Archivo > Vista previa > formulario. Esto nos abrirá otra instancia de Infopath con el formulario actual.

Ahora insertaremos una sección con los datos personales, en nuestro caso he agregado una tabla en la 2º fila para añadir los distintos campos. Solicitaremos el nombre, apellidos, email, nº empleado, departamento etc.

Para agregar un texto podemos poner el foco directamente sobre la zona de diseño y escribiremos el texto. A continuación añadimos un control del tipo textbox desde tareas de diseño > controles > Cuadro de texto. Al añadirlo veremos que nos añade una caja intentando ocupar el 100% del ancho de la casilla de la tabla. Para establecer el tamaño podemos establecerlo desde el panel de propiedades del textbox pinchando dos veces > tamaño ,o con botón derecho > propiedades > tamaño. También podemos establecerlo encogiéndolo con el ratón, pero ojo hacerlo desde el lado izquierdo de la caja ya que si lo hacemos desde la derecha nos encogerá además el ancho de la columna.

Otra de las cosas que podemos ver al añadir el textbox es que en las propiedades nos aparece un campo con el texto “Nombre del campo”. Este campo no es en realidad el nombre del control, sino el nombre del campo donde se almacenará el dato insertado.

Orígenes de datos

Ya hemos comentado que Infopath genera un xml a partir de los datos introducidos en el formulario.

Este xml se maneja desde el origen de datos principal. Para visualizar su estructura podemos entrar en tareas de diseño > orígenes de datos y seleccionaremos en el combo “Orígenes de datos” el valor “Principal”. Según vaya creciendo nuestro formulario el origen de datos irá creciendo.

Desde esta ventana podemos editar además el tipo de campo del origen de datos, podemos establecerlo como cadena, numérico, fecha, hora, etc..

Desde las propiedades del control podemos especificar como se realizará la entrada de datos. En caso que queramos cambiar el campo en el que se guardarán los datos del control podremos hacerlos in tener que escribir el nombre, seleccionando con el botón derecho el control > cambiar enlace.

Podemos tener más orígenes de datos, estos orígenes de datos los utilizaremos para leer datos de una bbdd, un servicio web, un fichero xml o una lista de sharepoint.

En el siguiente post veremos cómo manejar los orígenes de datos.

Tablas extensibles

Las tablas extensibles serán la forma que tengamos de definir un conjunto de datos de forma conjunta, podremos definir tablas de controles de manera que en tiempo diseño especifiquemos que controles aparecerán por cada una de las líneas de la tabla y a que nodo del Xml del origen de datos primario se asociará. Las tablas extensibles permiten al usuario agregar o quitar líneas en tiempo de ejecución. Cada una de estas filas corresponde con un nodo xml que agrupa a otra seeríe de nodos hijos.

Añadiremos la tabla extensible desde tareas de diseño > controles > Tabla extensible, a continuación indicaremos el número de columnas de nuestra tabla. En la siguiente imagen vemos como los nodos del xml para almacenar la fecha el tipo de gasto y el importe se agrupan de un nodo con el título “grupo1” y “grupo2”. Esto hará que al generarse el xml con los datos del usuario se creará un nodo “grupo2” por cada una de las líneas que se inserten en la tabla extensible. Si hacemos una vista previa de nuestro formulario dispondremos de una opción “Insertar elemento” para agregar una línea en la tabla. Para eliminarla podremos posivionarnos sobre la fila y nos aparecerá un botón a la izquierda con la opción de “Quitar”.

Al guardar el formulario tendremos un xml con el siguiente formato:

<?xml version="1.0" encoding="UTF-8"?>
<?mso-infoPathSolution solutionVersion="1.0.0.4" productVersion="12.0.0" PIVersion="1.0.0.0" href="file:///C:\Users\Administrador\AppData\Local\Microsoft\InfoPath\Designer2\7d8c9a95df2b42bc\manifest.xsf" ?><?mso-application progid="InfoPath.Document" versionProgid="InfoPath.Document.2"?><my:misCampos xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance%22 xmlns:my="http://schemas.microsoft.com/office/infopath/2003/myXSD/2009-03-20T16:27:26%22 xmlns:xd="http://schemas.microsoft.com/office/infopath/2003%22 xml:lang="es-ES">
<my:txtNombre>Mario</my:txtNombre>
<my:txtEmail>mariocortesflores@hotmail.com</my:txtEmail>
<my:txtApellidos>Cortés</my:txtApellidos>
<my:txtNumeroEmpleado>22334</my:txtNumeroEmpleado>
<my:grupo1>
<my:grupo2>
<my:txtFecha>2009-03-10</my:txtFecha>
<my:campo3></my:campo3>
<my:txtImporte>10.5</my:txtImporte>
<my:tipoDeGasto>Taxi</my:tipoDeGasto>
</my:grupo2>
<my:grupo2>
<my:txtFecha>2009-03-12</my:txtFecha>
<my:txtImporte>5.4</my:txtImporte>
<my:tipoDeGasto>Parking</my:tipoDeGasto>
</my:grupo2>
<my:grupo2>
<my:txtFecha>2009-03-12</my:txtFecha>
<my:txtImporte>36.5</my:txtImporte>
<my:tipoDeGasto>Comida</my:tipoDeGasto>
</my:grupo2>
</my:grupo1>
<my:txtObservaciones></my:txtObservaciones>
</my:misCampos>

Publicación

Una vez finalizado nuestro formulario publicaremos la plantilla en Sharepoint. Para hacerlo disponemos de dos mecanismos: Desde el asistente de Infopath o desde la administración central de Sahrepoint.

Cómo esto ya está explicado muy bien Juan Carlos González en su post MOSS: Publicación de formularios Infopath…el otro camino! echarle un vistazo.

Infopath Form Services y Office Forms Server

Continuando con el anterior post “Empezando con Infopath”, vamos a subir un poco más de nivel para ver en que versiones de sharepoint podremos utilizar Infopath Form services. En la siguiente imagen podemos ver las funcionalidades por versión de sharepoint:

Fijaros que Infopath Form services solo está disponible para la versión Enterprise de MOSS, con lo que si tenemos la versión Standard o wss3, ¿no podemos utilizar Infopath Form Services?. La respuesta, es que “sí podemos”, pero en función de que versión tengas de sharepoint habrá una solución distinta.

¿Cómo uso Infopath Form Services si tengo WSS3?

Lo que ha hecho Microsoft para este caso es sacar el componente de Infoptah Form services en un paquete que lo ha denominado “Microsoft Office Forms Server”. Form Server está basado en WSS3 por lo que no tendremos ningún problema a la hora de montarlo en nuestra granja de Wss3.

El instalador de Form server instala todos los binarios de Wss3 + los necesarios para infopath forms services.

Office Form server

Office Form server es el nombre que se ha dado a sacar Infopath Form services de MOSS y meterlo en un paquete aparte junto con Wss3.

Algo parecido se ha hecho por ejemplo con Search Server o Project Server.

La forma de licenciar Office Form server es la siguiente:

Office Forms Server

- Se licencia por servidor.

- Se necesita una CAL por cada cliente que que accede a Office Forms Server 2007

Office Forms Server for Internet Sites

- Se licencia por servidor.

- Únicamente para extranet e internet sites

- Incluye toda la funcionalidad de Microsoft Office Forms Server 2007.

De manera que tendremos que adquirir una licencia por servidor de la granja que tenga habilitadas las funcionalidades de Infopath. Si nuestra ganja wss3 está formada por dos frontales deberíamos adquirir dos licencias de servidor de Form server. Si solo tubiéramos una licencia de Form server también podríamos hacer que funcionara en uno de los nodos pero de forma muy limitada y perdiendo la alta disponibilidad.

¿Cómo uso Infopath Form Services si tengo MOSS 2007 Standard?

Este caso es distinto al de wss3 ya que la instalación de MOSS 2007 lleva todos los binarios y ficheros de la Enterprise y es a la hora de introducir la licencia cuando se habilitan o deshabilitan las funcionalidades, además que siempre podemos pasar a la Enterprise.

Para este caso Microsoft recomienda que habilites las características Enterprise y adquieras una licencia CAL de Enterprise para aquellos usuarios que usen solo las funcionalidades Enterprise.

Por lo que tendremos que ser nosotros los que limitemos los usuarios para no tener que adquirir demasiadas CAL de Enterprise.

Server and client access licensing. For each server, or each server in a farm, a valid server license must be purchased. For each client accessing Office SharePoint Server 2007, a Standard CAL must be purchased. To enable the enterprise features of Office SharePoint Server 2007, an Enterprise CAL, in addition to the Standard CAL, must be purchased. Once the enterprise features are enabled on a server, clients accessing that server, or farm of servers, should have a valid Enterprise CAL in addition to their Standard CAL when accessing the enterprise functionality.

De modo que para que los usuarios puedan utilizar Infopath Form Services en MOSS tendremos que adquirir una CAL Standard + CAL de Enterprise por cada usuario que lo utilice.

Podéis encontrar más información de licenciamiento en:

Microsoft Office SharePoint Server 2007 and Related Technologies pricing

Microsoft Office SharePoint Server 2007 frequently asked questions

o consultando con vuestro soporte preventa o comercial de Microsoft.

¿Puedo montar Office Form Server sobre una granja MOSS Standard?

Técnicamente se puede, aunque no es la mejor solución técnica y económica, ya que el coste de licencias es muy similar y casi no sale rentable.

En caso que ya tengas adquirida las licencias de Form Server puedes agregar un nuevo nodo con Form Server a la granja pero con muchas limitaciones:

• No pueden coexistir en un mismo equipo Office Form Server y MOSS 2007, por lo que tendremos que montarlo en nuevo nodo.
  
• Como las licencias de Form Server van por servidor (y CAL de usuario) deberíamos limitar los accesos a la funcionalidad de Infopath services solo a aquellos nodos que tengan adquirida la licencia.
  
• No podremos utilizar las funcionalidades de MOSS (publicación, colaboración etc.) en el nodo que tenga instalado Form Server, ya que éste solo tendrá los binarios de Wss3 y puede que no sea capaz de procesar las peticiones a determinados sitios con estas características. Tendremos que limitar los accesos a este servidor solo para los nuevos sitios que utilicen Infopath Forms Services y los usuarios que tengamos CAL de Form server adquirida.

Como resumen, si tenemos MOSS 2007 Standard es mejor pasar a la versión Enterprise de MOSS en lugar de adquirir Office Form Server.

Podéis encontrar más información técnica en:

Microsoft Office Forms Server TechNet TechCenter

Planning and architecture for Office Forms Server 2007

Empezando con Infopath

Infopath es la solución que nos proporciona Microsoft para crear formularios de una forma rápida y ‘sencilla’. Tenemos dos formas de trabajar en modo cliente con los formularios: desde el cliente office de Infopath y desde un entorno web.

La idea de infopath es proporcionar una herramiena para diseñar formularios sin necesidad de realizar un desarrollo a medida o desplegar una gran cantidad de componentes. Infopath además permite manejar datos de entrada procedentes de varios orígenes de datos distintos: de una bbdd, un servicio web, un xml y una lista de sharepoint. Los datos que introducimos en el formulario de infopath se guardan en formato xml o son enviados a un destino configurado en tiempo de diseño.

Sharepoint tiene la capacidad de integrar los formularios infopath de forma ‘nativa’ de dos formas: mediante librerías de formularios y mediante Infopath Form services.

Las librerías de formularios consisten en librerías de documentos con una plantilla de infopath asociada, de forma que la edición de los elementos se maneja mediante el formulario Infopath y los datos manejados se almacenan en formato xml en la librería.

Infopath Form services consiste en un componente instalado en el servidor encargado de renderizar en Html los formularios diseñados en Infopath. Esto evita la necesidad de tener instalado el cliente Infopath para trabajar con los formularios. Para manejar los formularios con Infopath Form services tendremos que subirlos a Sharepoint desde la administración central e indicar en que sitios podremos manejarlos. En el post “MOSS: Publicación de formularios Infopath…el otro camino!” podéis encontrar como publicar un formulario.

Una vez configurados podremos visualizarlos en nuestros sitios con el webpart XmlFormView, si no lo tenéis habilitado podéis consultarlo en “Embedding InfoPath Form in SharePoint Page”.