Jag skrev en artikel för SharePointBriefing.com och sätter man upp live idag.
Här är en teaser:
</slutet>
Följ mig på Twitter vid http://www.twitter.com/pagalvin
Jag är varit arbetar med ett projekt där jag ska packa bilagor från ett InfoPath-formulär. Det finns några bra resurser för parsning av InfoPath-formulär (som är bara XML-filer, så det är faktiskt ganska lätt).
Medan jag höll på att bygga upp projektet, Jag började genom att hämta ett InfoPath-formulär och spara den till min lokala hårddisk. Min c# kod läste direkt från den instansen. Men, InfoPath-formulär verkligen lever inuti ett SharePoint-formulärbibliotek. Jag gjorde en liten halv hjärtan sökning om du vill veta hur till läsa den direkt från biblioteket och gav nästan upp, i vilket fall jag skulle ha sparat formuläret till en lokal temp katalog och läsa den därifrån. Men, Det finns ingen anledning att gå igenom de fälgar som du kan läsa den direkt från biblioteket. Detta lilla utdrag visar hur:
/// Klass definitionen grejer här, inklusive:
privat SPFile mySharePointFile; /* Del av en SPList */ // Mer kod går här och inne en metod i klassen har vi: textReader = nya XmlTextReader(mySharePointFile.OpenBinaryStream()); textReader.WhitespaceHandling = WhitespaceHandling.Ingen; textReader.Read(); // Om noden har värde medan (textReader.Read()) { |
De viktiga bit ovan är att vi kan läsa InfoPath direkt via OpenBinaryStream() metoden kallar på SPFile som en parameter till konstruktören på XmlTextReader. Det fungerar bra.
</slutet>
Följ mig på Twitter vid http://www.twitter.com/pagalvin
Jag har en bekostnad post lösning för en klient som utnyttjar InfoPath och arbetsflöde. Vid ett tillfälle under godkännandeprocessen, Jag behöver för att generera ett e-postmeddelande som har alla dessa bra InfoPath-data samt bilagor sig så att (suck) någon kan ta dessa data och manuellt igen nyckel den in i en Oracle-databas ansökan.
Det är inte mycket svårt att få på eller tolka InfoPath-formuläret. Jag visste inte hur man ska hantera bilagor, men. Efter en timme eller två peta runt Internets (en evighet!) Jag hittade denna artikel: http://support.microsoft.com/kb/892730
Det ger lite händig kod till extraktet den bifogade filen från en nod i form. (Du behöver fortfarande hitta noden och alla som, men det är bara XML parsing).
Jag vet att bilagan är base64-kodat och jag gick ursprungligen i riktning mot bara extrahera den base64 data, avkodning det och spara det. Men, Jag insåg snabbt att jag inte vet hur man får namnet själv tills jag hittade den ovannämnda artikeln.
Jag hade faktiskt tyckte att ganska tidigt, men jag var avskräckas av dess personlighetsklyvning. Å ena sidan, artikeln * säger * det är bra för InfoPath 2007. Ännu, koden och instruktioner handlar om Visual Studio 2003 och referenser till InfoPath 2003.
Nedersta raden, den kod som artikel förutsatt fungerar bra för mig (så långt). Jag kan få min InfoPath-formulär, Jag kan tolka det, Jag kan hitta och avkoda den bifogade filen och jag vet dess namn. Vad mer kan man begära av livet?
</slutet>
Följ mig på Twitter vid http://www.twitter.com/pagalvin
Om du är orolig att din SharePoint-miljö kan vara en smula ohälsosamma, Låt mig hjälpa dig fixa det med en hälsokontroll.
Jag har en kostnad godkännandeprocess som jag måste genomföra med hjälp av InfoPath i ett formulär baserade autentisering (FBA) miljön med hjälp av forms services (webbaserad InfoPath).
Det finns två godkännandegrupper och processen fungerar så här:
På InfoPath sida av saker, Jag har olika sektioner som Dölj/visas baserat på om användaren är medlem i en av dessa godkännandegrupper.
I FBA miljö användarnamn() funktionen returnerar alltid tomt, Tyvärr. Vad jag har gjort har ställts in en en anpassad lista som kallas "Godkännandegrupper".
Jag lägger inte några ytterligare kolumner i listan.
När formuläret öppnas, den har en regel som denna:
"Set ett fälts värde" är här:
Detta i grunden säger: Fråga listan anpassade godkännande och filter som fråga genom att söka efter någon rad där titeln värde = "NORDIC".
Om som returnerar något värde, då är den aktuella användaren medlem i gruppen. Jag vet att det innehåller detta värde eftersom strängen är större än noll.
Stänga slingan genom att säkra de enskilda artiklarna i listan godkännandegrupp. Vid körning, om den aktuella användaren inte har kommer inte att rätt säkerhetsåtkomst till artikeln sedan frågan returnera den, sträng-längd blir noll och nu vet du den aktuella användaren är inte en del av gruppen. Du kan använda detta faktum som behövs i form.
Detta är en super kort skriva upp. Jag är ont om tid eller jag skulle ge mer i detalj.
Jag vet inte hur relevant det är att jag i FBA miljö. Detta skulle nog fungera bra i en icke-FBA miljö men jag kan tänka mig fall där detta skulle vara användbart.
</slutet>
Följ mig på Twitter vid http://www.twitter.com/pagalvin
Jag arbetade i en InfPath idag och sprang mot en gammal vän, "Undantag när rendering formulär System.Xml.XmlException: Oväntat filslut vid parsning namn har uppstått."
Detta hände mig för länge sedan och jag vet inte vad exakt jag gjorde för att lösa det. Ärligt talat, Jag tror att jag hade varit övergår till ett nytt projekt och aldrig såg här en löst (min ersättare hade att ta itu med denna huvudvärk). Jag minns det var en djävul av ett problem. Jag tillbringade flera misslyckade dagar handlar det. Sedan dess, Jag har sett detta komma upp på MSDN: S Forum minst en gång under det senaste året och aldrig riktigt såg ett svar för det.
Jag slog det idag och lyckligtvis denna gång , Jag hade just gjort en förändring till formuläret. Jag backas ut ändringen och problemet gick bort. Det visar sig att det är möjligt att skapa en mall med hjälp av InfoPath Designer på ett sådant sätt att det genererar ett parse error på serversidan former av staketet.
I mitt fall, Problemet orsakades av stegen:
Jag vet inte om dessa steg orsaka problem eller kanske, på något sätt är data i själva listan ett problem. Jag ska experimentera lite och se om jag kan spika downt han parametrar av detta med någon mer i detalj.
</slutet>
Följ mig på Twitter vid http://www.twitter.com/pagalvin
Jag fortfarande lever i InfoPath-formulär världen och jag behövde göra en av dessa "små" ändringar i en form som, Tyvärr, bryter en namngivningskonvention som jag antog med det två veckor sedan. Jag tänkte för mig själv, "någon ska titta på denna sak ett år från nu och säga, "Vad tänkte Paul? Av Jove, hans namnkonventionen är meningslöst!”
Jag insåg att jag kunde skapa en vy i formuläret för detta och sedan, En gång till, insåg att jag kunde ha gjort något sånt här hela tiden. Jag la "Developer anteckningar" utsikt till InfoPath-formuläret som sådan:
Jag har konfigurerat formuläret så att användare inte kan komma till denna uppfattning och därför, Det är bara synlig med InfoPath-klienten i designvyn. Nu känner jag mig lite inokulerade mot vissa framtida okända utvecklare titta på min form och tänkande dåliga tankar om mig. Puh!
</slutet>
Följ mig på Twitter vid http://www.twitter.com/pagalvin
Jag verkar gå via InfoPath faser där, Out of the blue, Jag crafting en massa former. Mina fingrar lära sig använda verktyget väl och sedan jag gå igenom nio månaders torka och måste lära sig det över igen.
Jag är mitt i en InfoPath-fas och jag skapar InfoPath-formulär med en massa visningar. En sak du förmodligen märka är att InfoPath 2007 klienten visar vyer i alfabetisk ordning. Detta är ett elände några gånger. Min bästa teknik är dessa dagar att prepend ett tal till vynamnet så att de visar alltid i den ordning jag vill, som illustreras här:
Jag önskar jag hade gjort det hela tiden.
</slutet>
Följ mig på Twitter vid http://www.twitter.com/pagalvin
Jag har varit arbetande på vissa InfoPath-formulär i veckan i MOSS i FBA miljö och lärde, När jag gick för att distribuera formulären till en produktionsmiljö med en FBA zon som användarnamn() funktionen funktion fungerar inte. Jag använde det för att generera unika filnamn.
Brunn, denna funktion fungerar inte i ett FBA-miljö (minst, inte ur lådan). Och, vid närmare eftertanke, med användarnamn på det sätt som jag hade planerat skulle inte har garanterat ett unikt filnamn som helst.
Min lösning var att använda nu() funktion och en regel som bränder på lastning av form. Jag tilldela sedan filnamnet till dataelement när den är tom:
Fördelen med denna metod är att filnamnet anges endast en gång. (Jag Visa inte det i skärmbilden, men sätta ett villkor på regeln att endast eld när "myFilename" är tom). Jag används för att ange namnet på data source nivå. Normalt, Jag skulle göra något (Dålig) Gillar det här:
Problemet med det är att om användare A öppnar formuläret på måndag och användaren B ändrar det på tisdag, du ska sluta med två olika former eftersom två olika användare sparas det med olika användarnamn.
Så, som irriterande som FBA kan i allmänhet och med InfoPath i synnerhet, Det fick mig att tänka en liten men mycket viktig teknisk detalj och strategi som jag inte skulle ha gjort annars!
</slutet>
Följ mig på Twitter vid http://www.twitter.com/pagalvin
Det finns en gemensam affärsscenario såhär:
Exemplet office.microsoft.com Beskriver hur du skapar en separat "vy" och markera hela vyn som skrivskyddad. Detta är en fungerande metod men har den nackdelen att du effektivt har skapat två hela versioner av samma form och måste nu hålla dem synkade manuellt. Om du lägger till ett fält i vyn redigerbara, Du måste sedan lägga till vyn inte redigeras också. Över tid, med olika utvecklare, Det kan finnas vissa skillnader.
Detta alternativ kan fungera bättre i vissa fall:
Nackdelen med detta tillvägagångssätt är att alla fält fortfarande kommer att redigeras på skärmen. Användaren kan få ett falskt intryck att de faktiskt kan ändra innehåll. Du kan komma runt det genom att lägga in lite text att formuläret är inaktiverad, möjligen i stora röda bokstäver överst på sidan.
I ett projekt, Jag skapade en "arbetsflödesstatus" Visa. Som arbetsflödet fortskred, Det skulle uppdatera specifika status-fält som hade blivit befordrad från formuläret. När användaren öppnar formuläret, den "öppna formen" regeln bytte automatiskt till att visa och användaren hade en trevlig liten sammanfattande status.
</slutet>
Vi hade ett utvecklat ett InfoPath-formulär med flera vyer att stödja en ny hyra / på ombordstigning process. När företaget anställer en ny person, IT-avdelningen och andra grupper måste vidta åtgärder (Ställ in löne, Aktivera åtkomst till lämpliga program, Leta upp ett skrivbord, m.m.). Vi använder på form men en annan vy av formuläret för var och en av dessa funktioner.
På detta företag, de flesta av inblandade i affärsprocessen är IT-kunniga, så när de öppnar formuläret, deras standardvyn är en "meny" Visa med knappar som hänvisa dem till sin specifika funktion. Men, Vi behövde för att förenkla saker och ting för den nya hyra direkt manager. Denna person bör inte se någon av IT relaterade saker. I själva verket, hon bör se en vy av formuläret och inte ens har en möjlighet att se andra vyer.
I vårt fall, som rikta chefens konto är direkt kopplad till formuläret artighet av en Kontakta selector (som jag alltid vill kalla en "människor picker" av någon anledning).
Stegen är följande:
1. I designläge, gå till verktyg-> Formuläralternativ-> Öppna och spara.
2. Välj "regler".
3. Skapa en ny regel vars verkan är "växla för att Visa" och vars villkor utnyttjar användarnamn() funktionen.
Användarnamn() Returnerar det "enkelt" Användarnamnet utan domän. Om jag loggar in på SharePoint med autentiseringsuppgifter "domainpagalvin", Användarnamn() Returnerar "pagalvin".
Kontakt väljaren ger tre bitar av information för en kontakt. "AccountID" del är mest användbar för detta scenario. Det enda som gör detta ännu lite utmaning är att kontakta väljaren (i min omgivning ändå) Returnerar domän och användar-ID, som i "domainpagalvin". Det hindrar oss från att göra en enkel jämlikhet förutsättning sedan AccountID ("domainpagalvin") kommer aldrig vara lika användarnamn() ("pagalvin").
Vi kan komma runt detta med den "innehåller" operatör: AccountID innehåller användarnamn().
Vi kan ta det vidare och pre-pend en hårdkodad domän framför användarnamnet() funktion för att få vår jämställdhet check och eliminera risken för ett falskt positivt på den innehåller.
Skulle vi verkligen gillar att automatiskt växla vy för andra användare baserat på deras annons säkerhetsgrupptillhörighet. Till exempel, När en medlem av "det Analytics" gruppen har åtkomst till formuläret, automatiskt växla till vyn IT Analytics. Vi hade inte tid att genomföra det., men min första tanke är att skapa en webbtjänst som skulle ha en metod som "IsMemberOfActiveDirectorySecurityGroup", passera det användarnamn() och återvända tillbaka sant eller falskt. Har någon någon annan, mer smart idé? Finns det någon SharePoint-funktion som vi kan utnyttja från InfoPath att göra detta konstaterande?
</slutet>
