Escribí un artículo para SharePointBriefing.com y lo pusieron vivir hoy.
Aquí es un reclamo:
</final>
Sígueme en Twitter en http://www.twitter.com/pagalvin
Yo soy estado trabajando en un proyecto donde necesito extraer los archivos adjuntos de un formulario de InfoPath. Hay algunos buenos recursos para el análisis de formularios de InfoPath (que son sólo archivos XML, por lo que es realmente muy fácil).
Mientras estaba construyendo el proyecto, Comencé a descargar un formulario de InfoPath y guardando en mi disco duro local. Estaba leyendo mi código c# directamente en esa instancia. Sin embargo, las formas de InfoPath están realmente viviendo dentro de una biblioteca de formularios de SharePoint. Hice un poco medio corazón buscando saber como leer directamente desde la biblioteca y dio casi para arriba, en cuyo caso habría guardado el formulario a un directorio temporal local y leer desde allí. Sin embargo, no hay que pasar por los aros como se puede leer directamente de la biblioteca. Este pequeño fragmento de código muestra cómo:
/// Cosas de la definición de clase aquí, incluyendo:
privada SPFile mySharePointFile; /* Parte de un SPList */ // Aquí va el código más y dentro de un método de la clase tenemos: textReader = Nuevo XmlTextReader(mySharePointFile.OpenBinaryStream()); textReader.WhitespaceHandling = WhitespaceHandling.Ninguno; textReader.Read(); // Si el nodo tiene valor mientras (textReader.Read()) { |
Clave de bits arriba es que podemos leer el InfoPath directamente a través de la OpenBinaryStream() método de llamada en el SPFile como parámetro al constructor de XmlTextReader. Funciona muy bien.
</final>
Sígueme en Twitter en http://www.twitter.com/pagalvin
Tengo una solución de entrada de gastos para un cliente que aprovecha el InfoPath y workflow. En algún momento durante el proceso de aprobación, Es necesario generar un correo electrónico que tiene todos los buenos datos de InfoPath, así como los anexos propios para que (suspiro) alguien puede tomar esos datos y manualmente lo explicativo en una aplicación de base de datos de Oracle.
No es muy difícil de conseguir en o analizar el formulario de InfoPath. No sabía cómo manejar los archivos adjuntos, Sin embargo. Después de una hora o dos de hurgando los Internets (una eternidad!) Encontré este artículo: http://support.microsoft.com/kb/892730
Proporcionan algún código útil para extraer el accesorio de un nodo en forma. (Todavía necesita encontrar el nodo y todo eso, pero eso sólo XML parsing).
Sé que el archivo adjunto está codificado en base64 y fui originalmente por el camino de sólo extraer el los datos base64, descifrarlo y guardarlo. Sin embargo, Rápidamente me di cuenta que no sabía cómo obtener el nombre del archivo hasta que encontré el artículo citado.
Realmente había encontrado muy temprano, pero fui aplazar por su doble personalidad. Por un lado, el artículo * dice * es bueno para InfoPath 2007. Todavía, el código y las instrucciones son todos acerca de Visual Studio 2003 y las referencias a InfoPath 2003.
Línea inferior, el código de artículo siempre está trabajando bien para mí (hasta la fecha). Puedo obtener mi formulario de InfoPath, Yo puedo analizar, Puedo encontrar y descifrar el archivo adjunto y sé su nombre. Qué más puede pedir de la vida?
</final>
Sígueme en Twitter en http://www.twitter.com/pagalvin
Si estás preocupado de que su entorno de SharePoint puede ser un pelín insalubre, Permítanme ayuda arreglar eso con un chequeo.
Tengo un proceso de aprobación de gastos que deba implementar utilizando InfoPath en una autenticación de formularios basados (FBA) medio ambiente utilizando forms services (basada en la Web de InfoPath).
Hay dos grupos de aprobación y el proceso funciona así:
En el lado de InfoPath de cosas, Tengo diferentes secciones que ocultar/aparecen basadas en si el usuario es un miembro de uno de esos grupos de aprobación.
En un entorno de FBA el nombre de usuario() función siempre devuelve en blanco, Lamentablemente. Lo que he hecho es configurar una una lista personalizada denominada "Grupos de aprobación".
No añadir ningún columnas adicionales a la lista.
Cuando se abre el formulario, tiene una regla como esta:
El "valor de un campo de juego" es aquí:
Esto es básicamente diciendo: Consulta la lista personalizada de grupo de aprobación y filtro que consultan buscando cualquier fila donde valor de Title = "Nórdico".
Si eso devuelve ningún valor, entonces el usuario actual es un miembro de ese grupo. Sé que contiene ese valor porque la longitud de la cadena es mayor que cero.
Cerrar el ciclo por asegurar los elementos individuales en la lista de aprobación de grupo. En tiempo de ejecución, Si el usuario actual no tiene acceso de seguridad apropiados para ese elemento entonces la consulta no devuelve lo, longitud de la cuerda será de cero y ya sabes el usuario actual no es parte de ese grupo. Puede usar este hecho en la forma.
Esta es una super breve reseña. Siento presionado por el tiempo o me gustaría aportar más detalle.
No sé cómo de relevante es que estoy en un entorno de FBA. Esto probablemente funcionaría bien en un ambiente no-FBA pero puedo imaginar casos donde sería útil.
</final>
Sígueme en Twitter en http://www.twitter.com/pagalvin
Yo estaba trabajando en un formulario de ésta hoy y corrió contra un viejo amigo, "Excepción no controlada al procesar el formulario System.Xml.XmlException: Final de archivo inesperado al analizar el nombre se ha producido".
Esto me pasó hace mucho tiempo y no sé qué exactamente que hice para resolverlo. Honestamente, Creo que había sido la transición a un nuevo proyecto y que nunca había visto este uno resuelto (mi reemplazo tuvo que lidiar con ese dolor de cabeza). Recuerdo que era un demonio de un problema. Pasé varios días sin éxito, tratando con él. Desde entonces, He visto esto sube en los foros MSDN al menos una vez durante el último año y por ello en realidad nunca vi una respuesta.
Le di hoy y por suerte esta vez , Yo sólo había hecho un cambio a la forma. Respaldé eso cambio y el problema desapareció. Resulta que es posible crear a partir de plantilla utilizando el diseñador de InfoPath de tal manera que genera un error de análisis por parte del servidor de formularios de la guía.
En mi caso, el problema fue causado por estos pasos:
No sé si esos pasos causan un problema o tal vez, de alguna manera los datos en la lista de sí mismo están un problema. Voy a experimentar un poco y ver si puedo de uñas downt parámetros de esto con más detalle.
</final>
Sígueme en Twitter en http://www.twitter.com/pagalvin
Todavía estoy viviendo en el mundo de formularios de InfoPath y necesitaba hacer uno de esos "pequeños" cambios a la forma que, Lamentablemente, rompe una Convención de denominación que adoptó con él hace dos semanas. Pensé para mis adentros, "alguien va a mirar esto al año desde ahora y decir, ' Lo que estaba pensando Pablo? Por Zeus, la Convención de denominación no tiene sentido!”
Me di cuenta de que esto podría crear una vista sobre la forma y luego, Otra vez, se dio cuenta de que podría han estado haciendo algo como esto a lo largo. He añadido una vista "Developer Notes" en el formulario de InfoPath como tal:
He configurado el formulario para que los usuarios no puedan llegar a ese punto de vista y por lo tanto, sólo es visible con el cliente de InfoPath en la vista Diseño. Ahora me siento un poco inoculado contra algún desarrollador desconocido futuro mirando mi forma y malos pensamientos pensar acerca de mí. Ufff!
</final>
Sígueme en Twitter en http://www.twitter.com/pagalvin
Me parece que pasan por fases de InfoPath donde, Out of the blue, Estoy bordando un montón de formas. Mis dedos aprenden a usar bien la herramienta y luego ir a través de la sequía de nueve meses y tiene que aprenderlo todo otra vez.
Estoy en medio de una fase de InfoPath y estoy creando formularios de InfoPath con un montón de puntos de vista. Una cosa que probablemente se cuenta es el InfoPath 2007 cliente muestra vistas en orden alfabético. Esto es una verdadera molestia algunas veces. Mi mejor técnica es anteponer un número para el nombre de la vista por lo que siempre muestran en el orden que desee, como se ilustra aquí:
Deseo que había estado haciendo esto todo el tiempo.
</final>
Sígueme en Twitter en http://www.twitter.com/pagalvin
He estado trabajando en algunos formularios de InfoPath esta semana en MOSS en un entorno de FBA y aprendido, Cuando fui a implementar los formularios a un entorno de producción con un FBA zona que el nombre de usuario() función no funciona. Lo estaba usando para generar nombres de archivo único.
Bien, esa función no funciona en un entorno de FBA (por lo menos, no fuera de la caja). Y, sobre la reflexión, usando nombre de usuario en la forma que había planeado no habría garantizado un nombre de archivo único en cualquier caso.
Mi solución fue usar el ahora() función y un estado que se activa en la carga de la forma. Asignar el nombre del archivo al elemento de datos cuando está en blanco:
La ventaja de este enfoque es que el nombre del archivo es solamente una vez. (No me presento en la captura de pantalla, pero puso una condición sobre la regla para disparar sólo cuando "myFilename" está en blanco). Permite configurar el nombre del archivo en el nivel de la fuente de datos. Por lo general, Yo haría algo (mal) Así:
El problema es que si el usuario A abre el formulario el lunes y el usuario B cambia el martes, Terminarás con dos formas diferentes puesto que dos usuarios distintos guardan con nombres de usuario diferente.
Por lo tanto, tan molesto como FBA puede ser en general y con InfoPath en particular, me hizo volver a pensar en un pequeño pero muy importante detalle técnico y enfoque que no hubiera hecho lo contrario!
</final>
Sígueme en Twitter en http://www.twitter.com/pagalvin
Hay un escenario de negocios comunes como este:
Este ejemplo office.microsoft.com describe cómo crear una vista"independiente" y marque la vista entera como de sólo lectura. Este es un enfoque viable pero tiene el inconveniente de que efectivamente ha creado dos versiones enteras de la misma forma y debe ahora mantenerlos sincronizados manualmente. Si agrega un campo a la vista editable, entonces usted debe agregar a la vista no editable, así. Con el tiempo, con desarrolladores de diferentes, puede haber algunas divergencias.
Esta alternativa podría funcionar mejor en algunos casos:
El inconveniente de este enfoque es que todos los campos seguirán siendo editables en la pantalla. El usuario puede obtener una falsa impresión de que realmente pueden cambiar contenido. Usted puede mitigar poniendo en algún texto que el formulario está deshabilitado, posiblemente en grandes letras rojas en la parte superior de la página.
En un proyecto, He creado un "Estado de flujo de trabajo" vista. Mientras que progresó el flujo de trabajo, ¿actualización de campos específicos del estado que habían sido promovidos de forma. Cuando el usuario abre el formulario, el formulario abierto"" regla cambió automáticamente para que la vista y el usuario tenían un Estado resumen poco agradable.
</final>
Tuvimos un desarrollado un formulario de InfoPath con varias vistas para apoyar un nuevo empleado / proceso de incorporación. Cuando la empresa contrata a una nueva persona, el Departamento de TI y otros grupos deben tomar acción (Configurar nóminas, permitir el acceso a las aplicaciones apropiadas, Localice un escritorio, etc.). Utilizamos en forma sino una visión diferente de la forma de cada una de las funciones.
En esta empresa, la mayoría de las personas involucradas en los procesos de negocios es expertos en IT, Así que cuando acceden a la forma, su vista predeterminada es un "menú" Ve con los botones que se dirigen a su función específica. Sin embargo, Necesitamos simplificar las cosas para el gestor directo de la contratación. Esta persona no debería ver cualquiera de la TI relacionadas con cosas. En realidad, debería ver una vista de la forma y ni siquiera tiene una opción para ver las otras vistas.
En nuestro caso, que dirigir la cuenta de administrador está ligada directamente a la forma de cortesía de un selector de contacto (que yo siempre estoy queriendo llamar un selector de personas"" por alguna razón).
Los pasos son los siguientes:
1. En modo de diseño, Vaya a herramientas-> Opciones de forma-> Abrir y guardar.
2. Seleccione "reglas".
3. Crear una nueva regla cuya acción es "cambiar para ver" y cuya condición aprovecha el nombre de usuario() función.
nombre de usuario() Devuelve la "simple" nombre de usuario sin el dominio. Si registro en SharePoint con credenciales "domainpagalvin", nombre de usuario() Devuelve "pagalvin".
El selector de contacto proporciona tres pedacitos de la información para un contacto. El "ID de cuenta" porción es más útil para este escenario. Lo único que lo hace incluso un poco de reto es que el selector de contacto (en mi entorno de todos modos) Devuelve el identificador de usuario y dominio, como en "domainpagalvin". Esto nos impide hacer una condición de igualdad directa desde el ID de cuenta ("domainpagalvin") Nunca será igual a userName() ("pagalvin").
Podemos conseguir todo esto usando el "contiene" operador: AccountID contiene userName().
Podemos tomar más lejos y pre-pend un dominio codificadas delante el nombre de usuario() función para obtener el cheque de la igualdad y eliminar el riesgo de un falso positivo en el operador contiene.
¿Tenemos realmente como para automáticamente cambiar vista por otros usuarios basados en su pertenencia de grupo de seguridad de AD. Por ejemplo, Cuando un miembro de la "que Analytics" Grupo accede a la forma, cambia automáticamente a la vista de análisis IT. No tenemos tiempo para implementarlo, Pero mi primer pensamiento es para crear un servicio web que tendría un método como "IsMemberOfActiveDirectorySecurityGroup", pasar el nombre de usuario() y devolver true o false. Alguien tiene alguna otra, idea más inteligente? ¿Hay alguna función de SharePoint que podemos aprovechar de InfoPath para realizar esa determinación?
</final>
