Eu escribín un artigo para SharePointBriefing.com and they put it up live today.

Aquí está o teaser:

Consulte.

</final>

Rexístrate para o meu blog.

Siga-me no Twitter http://www.twitter.com/pagalvin

I’m been working on a project where I need to extract attachments from an InfoPath form. There are some good resources for parsing InfoPath forms (que son só os ficheiros XML, polo que é realmente moi fácil).

Mentres eu estaba construíndo o proxecto, I started by downloading an InfoPath form and saving it to my local hard drive. My c# code was reading directly from that instance. Con todo, the InfoPath forms are really living inside a SharePoint forms library. I did a little half hearted searching to find out how to read it directly from the library and almost gave up, in which case I would have saved the form to a local temp directory and read it from there. Con todo, there’s no need to go through those hoops as you can read it directly from the library. This little snippet shows how:

/// Material de definición de clase aquí, incluíndo:

privado SPFile mySharePointFile; /* Parte dun SPList */

// Máis código vai aquí e dentro dun método da clase temos:
XmlTextReader TextReader;

TextReader = novo XmlTextReader(mySharePointFile.OpenBinaryStream());

textReader.WhitespaceHandling = WhitespaceHandling.Ningún;

textReader.Read();

// Se o nó non ten valor

mentres (textReader.Read())
{

Eles bit clave anterior é que podemos ler o InfoPath directamente a través do OpenBinaryStream() method call on the SPFile as a parameter to the constructor on XmlTextReader. It works great.

</final>

Rexístrate para o meu blog.

Siga-me no Twitter http://www.twitter.com/pagalvin

I have an expense entry solution for a client that leverages InfoPath and workflow. At one point during the approval process, Eu teño xerar un correo-e que ten todos os datos do InfoPath boas, así como os anexos propios para que (suspiro) alguén pode asumir que os datos a man e re-key-lo nun programa de base de datos Oracle.

It’s not very difficult to get at or parse the InfoPath form. I didn’t know how to handle the attachments, con todo. After an hour or two of poking around the Internets (unha eternidade!) Eu atopei este artigo: http://support.microsoft.com/kb/892730

It provide some handy code to extract the attachment from a node in the form. (Aínda que atopar o no e todo o que, pero iso é só analizar XML).

Sei que é o anexo codificado en base64 e eu orixinalmente descendeu o camiño de só extraer os datos dos base64, decoding it and saving it. Con todo, Eu rapidamente entender que non sabía como O nome do ficheiro en si ata que encontrei o citado artigo.

Realmente penso que ben cedo, pero foi adiada pola súa dobre personalidade. Por unha banda, the article *says* it’s good for InfoPath 2007. Aínda, o código e as instruccións son todas sobre o Visual Studio 2003 e referencias a InfoPath 2003.

Bottom line, o código que desde artigo é traballar ben para min (ata agora). I can get my InfoPath form, Podo analiza-lo, I can find and decode the attachment and I know its name. What more can one ask of one’s life?

</final>

Rexístrate para o meu blog.

Siga-me no Twitter http://www.twitter.com/pagalvin

Se está a preocupar que o seu ambiente SharePoint pode ser un pouco insalubre, deixe-me axudar a solucionar isto cun recoñecemento médico.

Eu teño un proceso de aprobación de gastos que eu teño para implantar o uso do InfoPath nunha autenticación baseada en formularios (FBA) ambiente, utilizando servizos de formas (InfoPath baseado na web).

Existen dous grupos de aprobación eo proceso funciona así:

• Usuario encher un informe de gastos e enviá-lo para aprobación.
• That triggers an email to first level approver group.
• First level approver reviews and approves or denies the report.
• If first level person approves it, system notifies second level approver.

On the InfoPath side of things, I have different sections that hide/appear based on whether the user is a member of one of those approval groups.

In an FBA environment the username() function always returns blank, tristemente. What I’ve done is set up a a custom list called “Approval Groups”.

I don’t add any additional columns to the list.

When the form opens up, it has a rule like this:

The “set a field’s value” is here:

This is basically saying: Query the approval group custom list and filter that query by looking for any row where Title’s value = “NORDIC”.

If that returns any value, then the current user is a member of that group. I know it contains that value because the string length is greater than zero.

Close the loop by securing the individual items in the Approval Group list. At run-time, O usuario actual non ten acceso de seguranza adecuado para este elemento, a continuación, a consulta non pode devolve-lo, string-length will be zero and now you know the current user is not part of that group. You can use that fact as needed in the form.

This is a super brief write-up. I’m pressed for time or I’d provide more detail.

I don’t know how relevant it is that I’m in an FBA environment. This would probably work well in a non-FBA environment but I can imagine cases where this would be useful.

</final>

Rexístrate para o meu blog.

Siga-me no Twitter http://www.twitter.com/pagalvin

Estaba a traballar nunha forma InfPath hoxe e deparou-se cun vello amigo, "Excepción non tratada durante a renderización System.Xml.XmlException forma: Fin de ficheiro inesperada en tanto que o nome de análise ocorreu. "

This happened to me a long time ago and I don’t know what exactly I did to resolve it. Honestly, Eu creo que eu fora a transición cara a un novo proxecto e nunca vin esta resolto (miñas substitucións tivo que lidar con esta dor de cabeza). I do remember it was a devil of a problem. I spent several unsuccessful days dealing with it. Since then, Vin isto xurdiu en foros MSDN polo menos unha vez no último ano e nunca vin unha resposta para iso.

Eu bati-o hoxe e por sorte esta vez , I had just made a change to the form. I backed out that change and the problem went away. It turns out that it’s possible to create a from template using InfoPath Designer in such a way that it generates a parse error on the forms server side of the fence.

No meu caso, o problema foi causado por estes pasos:

1. Engadir un novo elemento a unha fonte de datos como un campo de texto.
2. Solte o na forma.
3. Cambia o de exhibición nunha lista de correo.
4. Diga a lista drop down para tirar os seus valores a partir dunha lista personalizada de SharePoint.

Eu non sei se eses pasos causar un problema ou que, dalgún xeito os datos da lista en si é un problema. I’m going to experiment a bit and see if I can nail downt he parameters of this with any more detail.

</final>

Rexístrate para o meu blog.

Siga-me no Twitter http://www.twitter.com/pagalvin

Eu aínda estou vivindo no mundo de formularios InfoPath e eu precisaba facer unha desas "pequenas" cambio de forma que, por desgraza, breaks a naming convention I adopted with it two weeks ago. Eu penso para min mesmo, "Alguén vai mirar para esa cousa de aquí a un ano e dicir, "O que estaba a pensar Paul? By Jove, súa convención de nomenclatura non ten sentido!"

Entender que eu podería crear un punto de vista sobre a forma para iso e, a continuación,, unha vez, realized that I could have been doing something like this all along. I added a “Developer Notes” view to the InfoPath form as such:

Eu configurei o formulario para que os usuarios non poden chegar a ese punto de vista e, polo tanto,, it’s only visible with the InfoPath client in design view. Now I feel a little inoculated against some future unknown developer looking at my form and thinking bad thoughts about me. Phew!

</final>

Rexístrate para o meu blog.

Siga-me no Twitter http://www.twitter.com/pagalvin

Paréceme pasar por fases onde InfoPath, fóra do azul, I’m crafting a bunch of forms. My fingers learn how to use the tool well and then I go through nine month drought and have to learn it all over again.

Eu estou no medio dunha fase InfoPath e estou creando formas do InfoPath con unha morea de puntos de vista. Unha cousa que probablemente vai notar que o InfoPath 2007 client shows views in alphabetical order. This is a real nuisance some times. My best technique these days is to prepend a number to the view name so that they always show in the order I want, como ilustrado aquí:

I wish I had been doing this all along.

</final>

Rexístrate para o meu blog.

Siga-me no Twitter http://www.twitter.com/pagalvin

Eu estou traballando nalgúns InfoPath forma esta semana en Moss nun ambiente FBA e aprendeu, cando fun implantar os formularios a un ambiente de produción cunha zona FBA que o nome de usuario() function function does not work. I was using it to generate unique file names.

Ben, que a función non funciona nun ambiente FBA (polo menos, non fóra da caixa). E, despois reflexión, usar nome de usuario na forma na que eu tiña planeado non tería garantido un nome de arquivo único, en calquera caso.

A miña solución foi usar agora() function and a rule that fires on loading of the form. I assign the file name to data element when it’s blank:

The advantage of this approach is that the file name is set only once. (Eu non mostra-lo na captura de pantalla, pero puxo unha condición na que a regra só dispara cando "myFilename" está en branco). I used to set the file name at the data source level. Typically, Quere facer algo (malo) así:

O problema con isto é que se o usuario A abre o formulario o luns eo usuario B cambia o martes, vai acabar con dúas formas distintas, xa que dous usuarios diferentes salvou con diferentes nomes de usuario.

Así, como irritante como FBA pode ser, en xeral, e co InfoPath en particular, iso me fixo repensar un detalle pequeno, pero moi importante técnica e visión que eu non faría doutra forma!

</final>

Rexístrate para o meu blog.

Siga-me no Twitter http://www.twitter.com/pagalvin

Hai un escenario de negocios común como esta:

• Usuario encher un formulario do InfoPath.
• Somete forma.
• Longo proceso de execución de fluxo de traballo comeza.
• Mentres que o fluxo de traballo está en execución, Non queremos que ninguén para cambiar o contido da forma.

This office.microsoft.com example describes how to create a separate "view" and mark the whole view as read-only. This is a workable approach but has the drawback that you’ve effectively created two entire versions of the same form and must now keep them in sync manually. If you add a field to the editable view, you must then add it to the non-editable view as well. Ao longo do tempo, with different developers, there can be some divergence.

This alternative might work better in some cases:

• Add a new field to the form called "IsEditable".
• Set its default value to true.
• Promote it when publishing to MOSS.
• No fluxo de traballo, set the value of IsEditble to false.
• Go back to the form.
• Add a rule that "upon open of the form", disable your save button when IsEditable is false.

The drawback to this approach is that all the fields will still be editable on the screen. The user can get a false impression that they can actually change content. You can mitigate that by putting in some text that the form is disabled, possibly in big red letters across the top of the page.

In one project, I created a "workflow status" ver. As the workflow progressed, it would update specific status fields that had been promoted from the form. When the user opened the form, the "open form" rule automatically switched to that view and the user had a nice little summary status.

</final>

Rexístrate para o meu blog.

Nós tiñamos un país desenvolvido unha forma de InfoPath con varias exhibicións para apoiar unha nova contratación / on-boarding process. When the company hires a new person, o departamento de TI e outros grupos teñen que tomar medidas (configurar folla de pagamento, permitir o acceso a aplicacións axeitados, atopar un balcón, etc). We use on form but a different view of the form for each of those functions.

Nesta empresa, a maioría das persoas implicadas no proceso de negocio son IT-savvy, así cando acceder ao formulario, their default view is a "menu" view with buttons that direct them to their specific function. Con todo, we needed to simplify things for the new hire’s direct manager. This person should not see any of the IT related stuff. En realidade, debe ver só unha vista da forma e nin sequera ten a posibilidade de ver os outros puntos de vista.

No noso caso, que o relato de director directo está directamente ligada á forma como cortesía dun contacto co selector (which I am always wanting to call a "people picker" por algunha razón).

Os pasos son os seguintes:

1. No modo de deseño, vaia a Ferramentas -> Opcións de Formulario -> Abrir e Gardar.

2. Select "rules".

3. Create a new rule whose action is "switch to view" e cuxa condición aproveita o nome de usuario() función.

Nome de usuario() returns the "simple" user name without the domain. If I log into SharePoint with credentials "domain\pagalvin", Nome de usuario() returns "pagalvin".

The contact selector provides three bits of information for a contact. The "AccountID" portion is most useful for this scenario. The only thing that makes this even a little bit of challenge is that the contact selector (no meu ambiente de calquera maneira) devolve o dominio e ID de usuario, as in "domain\pagalvin". This prevents us from doing a straight-forward equality condition since AccountID ("domain\pagalvin") nunca será igual usuario() ("pagalvin").

We can get around this using the "contains" operador: AccountID contén usuario().

Podemos ir máis aló e pre-pende dun dominio hard-Coded diante do nome do usuario() función para comprobar a nosa igualdade e eliminar o risco dun falso positivo do operador contén.

We would have REALLY like to automatically switch view for other users based on their AD security group membership. Por exemplo, when a member of the "IT Analytics" grupo accede ao formulario, automatically switch to the IT Analytics view. We didn’t have time to implement it, but my first thought is to create a web service that would have a method like "IsMemberOfActiveDirectorySecurityGroup", pasalo a usuario() and return back true or false. Does anyone have any other, idea máis intelixente? Is there any SharePoint function we can leverage from InfoPath to make that determination?

</final>