InfoPath umožňuje publikovat formuláře na SharePoint a rovněž umí odesílat vyplněná data do SharePointu. To se dobře hodí pro různé žádanky a podobné věci. Údaje z vyplněného InfoPath formuláře se totiž dají propagovat do vlastností typu obsahu, který se při publikaci na SharePoint vytvoří. Výsledkem pak je, že máte formulář, který si uživatel otevře a vyplní. Když dá Odeslat, data se uloží do určené knihovny, která má přiřazený odpovídající typ obsahu (vzniklý při publikaci). Díky propagaci vlastností může nad vyplněnými daty běžet workflow, které např. osobu uvedenou ve formuláři vyzve ke schválení a podobně.

Díky použití InfoPath formulářů máte k dispozici bohatší uživatelské rozhraní pro získávání dat od uživatelů. Musí ale mít nainstalovaný lokální InfoPath. Tato podmínka se dá obejít tím, že šablonu vytvoříte a publikujete jako webový formulář. To má ale na druhou stranu omezení ve funkčnosti formuláře a v tom, že to nepodporuje "bezplatné" WSS, dokonce ani MOSS, ale až MOSS Enterprise.

V průběhu používání InfoPath formulářů ve spojitosti s SharePointem jsem narazil na 4 momenty hodné zřetele:

Vícenásobná publikace

Pokud publikujete jeden formulář na 2 místa (např. na testovací server a ostrý) a potom v něm provedete změnu a opět ho publikujete na původní místo, máte problém. V typu obsahu, který InfoPath v průběhu opakované aktualizuje se vám "zdvojí" sloupce. Vypadá to tak, že v seznamu, kam se data ukládají, jsou např. 2 sloupce s názvem "Cena" (tzv. display name). Oba mají různý static name, typicky cena a cena1. Bohužel mnoho funkcí (včetně workflow) v SharePointu pracuje právě s Display name (tedy to, co vidí uživatel). Navíc se tento problém projevuje i tak, že stará data (ta, která byla uživateli vyplněna před aktualizací) jsou v původních sloupcích a nově vložená data se ukládají do nových sloupců. Do nových sloupců se ukládají i přeuložená data (taková, která sice vznikla před aktualizací, ale byla změněna pomocí šablony po aktualizaci). Zmatek v datech mají nejen uživatelé, kteří v seznamu vidí 2 stejně pojmenované sloupce, z nichž jeden obsahuje informace vyplněné do okamžiku aktualizace, a druhý, který obsahuje informace vložené nebo změněné po aktualizaci formuláře. Stejný problém mají i workflow. Problém je způsobený tím, že při publikaci se do formuláře (nejen do kopie, která se umístí na SharePoint, ale i do formuláře, který vás InfoPath donutí uložit během publikace) ukládají GUIDy jednotlivých polí. Děje se to při vytváření typu obsahu a tyto GUIDy se později používají při opakované publikaci šablony (aktualizaci). Během publikace totiž InfoPath kontroluje, jestli GUID prvku formuláře odpovídá GUIDu některého ze sloupců publikovaného typu obsahu. Jestliže ne, vytvoří v typu obsahu sloupec a vygeneruje mu GUID. Když existuje, aktualizuje jeho definici. Pokud ale publikujete formulář na server A, získáte 1. sadu GUIDů. Pak ho publikujete na server B a máte druhou sadu. Pak ho publikujete opět na server A máte za krkem "dvojitého Nelsona"! GUIDy ve formuláři totiž neodpovídají GUIDům v typu obsahu, a proto je do typu obsahu přidána ještě jedna sada úplně stejných sloupců. Potíže jsou navíc umocněny tím, že s typy obsahu, které vzniknou v průběhu publikace, nemůžete prakticky nic dělat (s vyjímkou jejich použití v knihovně dokumentů a jejich odstranění).

Workflow nad vyplněnými daty

Workflow pracující nad těmito položkami mají zvláštní chování. Projevuje se to tak, že workflow reagující na změnu je spuštěno tolikrát kolik je datových položek ve formuláři. Workflow napsané ve Visual Studiu, které je spouštěno vložením dat, musí nejprve počkat (pomocí delay aktivity), protože jinak jsou hodnoty vlastností prázdné. Z obou těchto projevů se dá usuzovat na to, že po uložení vyplněných dat na server se zřejmě spustí asynchronní proces, který postupně z XML dat zjišťuje hodnoty elementů mapovaných do typu obsahu. Tyto hodnoty pak ukládá do sloupců odpovídající položky. Díky tomu jsou hodnoty sloupců bezprostředně po vložení prázdné a dojde k několikanásobné aktualizaci položky.

Otevírání pomocí prohlížeče

Také jsem narazil na následující problém. Zapnul jsem na MOSSu Enterprise funkce a najednou se InfoPath data začala otevírat na webu. Samozřejmě to dopadlo špatně, protože šablona nebyla vyvíjena jako webová. Navíc ani v konfiguraci InfoPath services nebylo nastaveno, že by se ta šablona měla zpracovávat na webu. Zjišťoval jsem příčinu a zjistil jsem, že při HTTP žádosti je klient přesměrován na stránku MOSSu, která má na starosti zobrazení webových InfoPath šablon. Zatímco do té doby bylo klientovi vráceno XML vyplněných dat. Nicméně se stále dala požít volba "Zobrazit pomocí aplikace Microsoft Office InfoPath" z kontextového menu. Prozkoumal jsem tedy, jak to dělá a přišel jsem na to, že URL odkazu na vyplněná data je potřeba rozšířit o parametry "OpenIn=PreferClient" a "NoRedirect=true", které zajistí, že se data budou vždy otevírat pomocí klientského programu InfoPath. Takže výsledné URL, pokud chcete, aby se vyplněná data vždy otevírala pomocí klientského InfoPathu, musí vypadat nějak takto: http://server/web/vyplnenadata/zaznam.xml?OpenIn=PreferClient&NoRedirect=true.

Přidávání/mazání datových prvků z formuláře

Smažete-li při aktualizaci šablony nějaký datový prvek, máte problém. Data vyplněná v předchozí verzi šablony  nepůjdou s pomocí nové otevřít. Obráceně (přidávání polí) to funguje dobře. Takže pokud šablonu rozšíříte, nebo funkčně či vzhledově obohatíte, většinou vám pomocí nové verze půjdou otevřít i stará data. Na šablonu je potřeba se dívat jako na definici dat (ekvivalent XSD), funkční logiky a vzhledu. Pokud je šablona kompatibilní na úrovni definice dat, je to v pořádku. Musíte si ale dát pozor pokud nad vyplněnými daty máte workflow. To musí být připraveno na to, že v tom nově přidaném sloupci nic nebude. Workflow totiž bude zpracovávat i záznamy vyplněné před úpravou.