Ég skrifaði grein fyrir SharePointBriefing.com and they put it up live today.
Hér er beitu:
</enda>
Gerast áskrifandi að bloggið mitt.
Fylgdu mér á 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 (sem eru bara XML skrár, svo það er í raun alveg auðvelt).
Á meðan ég var að byggja upp verkefni, I started by downloading an InfoPath form and saving it to my local hard drive. My c# code was reading directly from that instance. Hins, 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. Hins, there’s no need to go through those hoops as you can read it directly from the library. This little snippet shows how:
/// Class definition stuff here, þ.mt:
einkaaðila SPFile mySharePointFile; /* Part of an SPList */ // More code goes here and inside a method of the class we have: textReader = ný XmlTextReader(mySharePointFile.OpenBinaryStream()); textReader.WhitespaceHandling = WhitespaceHandling.Ekkert; textReader.Read(); // If the node has value while (textReader.Read()) { |
They key bit above is that we can read the InfoPath directly via the OpenBinaryStream() method call on the SPFile as a parameter to the constructor on XmlTextReader. It works great.
</enda>
Gerast áskrifandi að bloggið mitt.
Fylgdu mér á 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, Ég þarf að búa til tölvupóst sem hefur öll þessi góðu gögn InfoPath og viðhengi sig svo að (andvarp) someone can take that data and manually re-key it into an Oracle database application.
It’s not very difficult to get at or parse the InfoPath form. I didn’t know how to handle the attachments, þó. After an hour or two of poking around the Internets (an eternity!) I found this article: http://support.microsoft.com/kb/892730
It provide some handy code to extract the attachment from a node in the form. (You still need to find the node and all that, but that’s just XML parsing).
I know that the attachment is base64-encoded and I originally went down the path of just extracting the the base64 data, decoding it and saving it. Hins, I quickly realized I didn’t know how to get the file name itself until I found the aforementioned article.
I had actually found that quite early, but I was put off by its split personality. On the one hand, the article *says* it’s good for InfoPath 2007. En, the code and instructions are all about Visual Studio 2003 and references to InfoPath 2003.
Neðsta lína, the code that article provided is working well for me (svo langt). I can get my InfoPath form, I can parse it, I can find and decode the attachment and I know its name. What more can one ask of one’s life?
</enda>
Gerast áskrifandi að bloggið mitt.
Fylgdu mér á Twitter á http://www.twitter.com/pagalvin
If you’re worried that your SharePoint environment may be a tad unhealthy, let me help you fix that with a health check.
Ég er með samþykki kostnað ferli sem ég þarf að innleiða með InfoPath í a form byggja staðfesting (FBA) umhverfi með því að nota eyðublöð þjónustu (vefur byggir InfoPath).
Það eru tvær samþykki hópa og ferlið virkar eins og þetta:
Á InfoPath megin hluti, Ég mismunandi kafla sem fela / virðist byggjast á því hvort notandi er meðlimur í einn af þeim samþykki hópa.
Í FBA umhverfi notandanafn() skilar alltaf autt, því miður. What I’ve done is set up a a custom list called “Approval Groups”.
Ég bæti ekki frekari dálka á listann.
Þegar mynd opnast, það er regla eins og þetta:
The "setja gildi reit til" er hér:
Þetta er í grundvallaratriðum að segja: Fyrirspurn hópsins samþykki sérsniðnum lista og sía þessi fyrirspurn með því að leita að einhverju röð þar sem verðmæti Titill s = "NORRÆNA".
Ef það skilar hvaða gildi, 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, Ef núverandi notandi hefur ekki viðeigandi öryggi aðgang að þeim lið þá fyrirspurn mun ekki skila, 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.
</enda>
Gerast áskrifandi að bloggið mitt.
Fylgdu mér á Twitter á http://www.twitter.com/pagalvin
Ég var að vinna á InfPath formi í dag og hljóp upp á móti gömlum vini, "Óvænt undantekning þegar flutningur formi System.Xml.XmlException: Óvæntur endir á skrá meðan þáttun Name hefur átt sér stað. "
This happened to me a long time ago and I don’t know what exactly I did to resolve it. Honestly, I think that I had been transitioning to a new project and never saw this one resolved (my replacements had to deal with that headache). I do remember it was a devil of a problem. I spent several unsuccessful days dealing with it. Since then, I’ve seen this come up on MSDN forums at least once over the last year and never really saw an answer for it.
I hit it today and fortunately this time , 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.
Í mínu tilfelli, the problem was caused by these steps:
I don’t know if those steps cause a problem or maybe, somehow the data in the list itself is a problem. I’m going to experiment a bit and see if I can nail downt he parameters of this with any more detail.
</enda>
Gerast áskrifandi að bloggið mitt.
Fylgdu mér á Twitter á http://www.twitter.com/pagalvin
Ég er enn á lífi í Infopath Eyðublöð heiminum og ég þurfti að gera eitt af þessum "litlu" breytingar á formi sem, því miður, breaks a naming convention I adopted with it two weeks ago. I thought to myself, "Einhver er að fara að líta á þetta hlutur á ári héðan í frá og segja, "Hvað var Páll hugsa? By Jove, Nafngiftir venju hans gerir ekkert vit!"
Ég áttaði að ég gæti búið til sýn á formi fyrir þetta og þá, aftur, realized that I could have been doing something like this all along. I added a “Developer Notes” view to the InfoPath form as such:
Ég hef stillt að mynd svo notendur geta ekki fengið það sem skoða og því, 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!
</enda>
Gerast áskrifandi að bloggið mitt.
Fylgdu mér á Twitter á http://www.twitter.com/pagalvin
Ég virðist fara í gegnum stig Infopath þar, út af the blár, 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.
I’m in the middle of an InfoPath phase and I’m creating InfoPath forms with a lot of views. One thing you probably notice is that the 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, as illustrated here:
I wish I had been doing this all along.
</enda>
Gerast áskrifandi að bloggið mitt.
Fylgdu mér á Twitter á http://www.twitter.com/pagalvin
Ég hef verið að vinna á sumum InfoPath eyðublöð þessari viku í mosa í FBA umhverfi og lærði, þegar ég fór að senda eyðublöðin til framleiðslu umhverfi með FBA svæði sem notandanafn() function function does not work. I was using it to generate unique file names.
Jæja, that function doesn’t work in an FBA environment (að minnsta kosti, not out of the box). Og, upon reflection, using username in the way I had planned wouldn’t have guaranteed a unique file name in any event.
My solution was to use the now() 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. (I don’t show it in the screen shot, but put a condition on the rule to only fire when “myFilename” is blank). I used to set the file name at the data source level. Typically, I would do something (slæmt) like this:
The problem with that is that if user A opens the form on Monday and the user B changes it on Tuesday, you’ll end up with two different forms since two different users saved it with different user names.
Svo, as annoying as FBA can be in general and with InfoPath in particular, it made me re-think a small but really important technical detail and approach that I wouldn’t have done otherwise!
</enda>
Gerast áskrifandi að bloggið mitt.
Fylgdu mér á Twitter á http://www.twitter.com/pagalvin
Það er sameiginlegt fyrirtæki atburðarás eins og þetta:
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. Með tímanum, with different developers, there can be some divergence.
This alternative might work better in some cases:
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" skoða. 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.
</enda>
Við höfðum þróað með InfoPath form með mörgum útsýni til að styðja nýja ráða / on-boarding process. When the company hires a new person, The IT deild og aðrir hópar þurfa að grípa til aðgerða (setja upp launaskrá, virkja aðgang að viðeigandi forritum, finna skrifborð, o.fl.). We use on form but a different view of the form for each of those functions.
Á þetta fyrirtæki, flestir sem taka þátt í viðskiptum ferli eru IT-kunnátta, svo þegar þeir opna mynd, their default view is a "menu" view with buttons that direct them to their specific function. Hins, we needed to simplify things for the new hire’s direct manager. This person should not see any of the IT related stuff. Í raun, hún ætti að sjá bara einn mynd af formi og ekki einu sinni kost að sjá aðra skoðanir.
Í okkar tilviki, að reikningur beinni stjórnanda er beint tied til mynd kurteisi af a samband val (which I am always wanting to call a "people picker" fyrir sumir ástæða).
Skrefin eru eftirfarandi:
1. Í ham hönnun, fara í Tools -> Form Valkostir -> Opinn og Vista.
2. Select "rules".
3. Create a new rule whose action is "switch to view" og þar sem ástand notar Notendanafnið() virka.
username() returns the "simple" user name without the domain. If I log into SharePoint with credentials "domain\pagalvin", username() 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 (í umhverfi mínu samt) skilar ríki og Aðgangsorð notanda, as in "domain\pagalvin". This prevents us from doing a straight-forward equality condition since AccountID ("domain\pagalvin") mun aldrei jafna notandanafn() ("pagalvin").
We can get around this using the "contains" rekstraraðila: AccountID inniheldur notandanafn().
Við getum tekið það frekar og pre-pend a harður-dulmáli ríki framan notandanafn() virka til að fá jafnrétti athuga okkar og koma í veg fyrir hættu á falskur jákvæður á inniheldur rekstraraðila.
We would have REALLY like to automatically switch view for other users based on their AD security group membership. Til dæmis, when a member of the "IT Analytics" Hópurinn notar mynd, 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", standast það username() and return back true or false. Does anyone have any other, meira snjall hugmynd? Is there any SharePoint function we can leverage from InfoPath to make that determination?
</enda>