Microsoft stopt met InfoPath-software voor invoerformulieren

Microsoft heeft de stekker uit InfoPath getrokken. InfoPath 2013 is daarmee de laatste versie van de software voor invoerformulieren op basis van xml. De softwarefabrikant streeft ernaar de invoerformulieren te integreren in andere applicaties, zoals Word.

Microsoft maakte het pensioen van InfoPath bekend op zijn Office-weblog. "We investeren in nieuwe formulierentechnologie voor SharePoint, Access en Word", schrijft Microsofts Office-team. De InfoPath 2013-client en de InfoPath Forms Services in SharePoint Server 2013 zijn de laatste versies die verschijnen.

Microsoft wijst erop dat InfoPath Forms Services in Office 365 blijft functioneren en dat er ondersteuning blijft voor de client en de Forms Services tot 2023. Daarnaast heeft de ontwikkelaar het over het bouwen van de 'nieuwe generatie van formulierentechnologie' waar bestaande gebruikers op termijn naar kunnen migreren. Meer details hierover komen later dit jaar. Microsoft introduceerde InfoPath bij de release van Office 2003.

Reacties (44)

En volgens mij heeft de concurrent, Nintex, een beter product in handen welke veel gebruiksvriendelijk is. Ik zie een potentiële overname kandidaat.. http://www.nintex.com/en-...iewForSharepoint2013.aspx

Bijna, een ander product van Nintex is bedoeld voor het maken van formulieren, Nintex Forms. Is niet 1-op-1 hetzelfde (zie vergelijk). Nintex Workflow is niet meer dan een (erg fraaie) grafische schil om de standaard SharePoint Workflow mogelijkheden. Gebruikers kunnen hiermee eenvoudig workflows ontwerpen en publiceren.

De het stopzetten van de doorontwikkeling van InfoPath is al een tijdje bekend. Het voldoet niet goed in een web based oplossing die cross browser en cross device moet werken. Nintex Forms is daar al een aardige vervanger voor. Daar zal echter nog wel wat aan geknutseld moeten worden om het geschikt te maken voor bedrijfsprocessen (denk aan het integreren met bestaande bedrijfssystemen). Maar Nintex zal niet stil zitten en hebben jaren lange ervaring met het bouwen van deze toevoegingen op SharePoint. Het kan dus best zijn dat Microsoft als het gaat om formulieren in SharePoint het overlaat aan partners als Nintex.

Ik heb geen inzicht in hoe de interface eruit ziet van SharePoint workflows maar dat van Nintex lijkt verdomd veel op de workflow functionaliteit die in Dynamics AX ( 2009, 2012, 2012R2 ) zit:" Link ".

Dat komt omdat zowel SharePoint als de Dynamics applicaties gewoon gebruik maken van de .Net Workflow libraries.

Ik heb als ontwikkelaar enkele keren gewerkt met zowel Infopath als SharePoint workflows...

Omtrent Infopath ben ik blij dat men er mee stopt, want het is een enorm brak pakket. Het is een ster als je een simpel formulier wilt bouwen, maar zodra het complexer wordt is de oplossing traag, buggy, en erg moeilijk te onderhouden.

Omtrent Workflow (of je nu Nintex, SharePoint workflows of Workflow Foundation gebruikt, allen komen op hetzelfde neer): Microsoft heeft enorme denkfouten gemaakt bij het ontwerp hiervan, zowel op het gebied van gebruiksvriendelijkheid en performance. Een voorbeeld is dat een workflow (bijvoorbeeld mensen die iets moeten approven) altijd op de achtergrond blijft zitten wachten op een aktie. Dit levert enorme schaalbaarheidsproblemen op. Verder is de UI om dingen te approven out of the box werkelijk dramatisch.

Het bovenstaande is eigenlijk waar voor alles wat met SharePoint te maken heeft: gebruik het zo simpel en standaard mogelijk en het kan iets voor je betekenen. Wil je echter stevig aanpassen, dan loop je tegen de ene na de andere WTF aan.

Ik zeg dit niet om Microsoft te bashen. Ze maken erg goede bedrijfssoftware, maar SharePoint en co is dat niet. Het is een enorme kostenpost voor bedrijven als je er meer mee doet dan de standaard features. Ik heb bedrijven in Nederland miljoenen aan kapitaal zien vernietigen door SharePoint te breed in te zetten. En als die miljoenen er eenmaal inzitten, komt de volgende versie, welke dus niet compatibel is.

Zelfs Microsoft raad inmiddels aan om SharePoint zo simpel mogelijk in te zetten, om je customizations buiten SharePoint te zetten.

Ik moet eerlijk bekennen dat ik nog nooit bij welk bedrijf dan ook een succesvolle en soepel lopende sharepoint omgeving heb gezien.
Houtje touwtje hobbypakket dat out of the box niks kan en enorme investeringen vereist.
Zijn tegenwoordig legio betere oplossingen voor.

Je moet dan ook SharePoint niet gebruiken waar het niet voor bedoeld is. SharePoint is van oudsher vooral bedoeld als document management systeem en daar is het ook erg sterk in. Wat je helaas maar al te vaak ziet is dat men zodanig SharePoint gaat zitten verbouwen dat je niet meer ziet dat het SharePoint is. Dan ben je per definitie verkeerd bezig en krijg je een enorm gedrocht wat niet meer goed onderhoudbaar is. Overigens zie je nu dat Microsoft inzet op meer het Cloud model voor customizations in SharePoint. Alleen is dat model wat mij betreft momenteel nog te onvolwassen om volwaardig ingezet te kunnen worden. Daarnaast is het de vraag in hoeverre alles wat je nu bouwt nog enigsinds backwards compatible is. Zo zette in SharePoint 2010 Microsoft vol in op sandboxed solutions en in SharePoint 2013 werd het alweer deprecated. In ieder geval is de weg waar SharePoint op gaat volledig afhankelijk van wat er met Office 365 gebeurd. Dat is waar Microsoft momenteel volledig de focus op heeft en de on-premise zaken lijken steeds minder belangrijk te worden.

Om nog even terug te komen op InfoPath. Dat was zoals al eerder hier gezegd een gedrocht van een product. In SharePoint heeft het ook nooit lekker gewerkt. Zodra je bijvoorbeeld iets met Managed Metadata wilde doen was je zwaar de klos, want standaard unsupported. Dan moest je weer allerlei zaken gaan coden, maar het is nooit enterprise ready geweest. Leuk voor proof of conceptjes en wat kleine projecten, maar niet voor grootschalig gebruik.

Wat betreft Infopath ben ik het 100% met je eens. Wat betreft SharePoint denk ik dat je niet het hele product moet afschrijven op individuele missers. Zowel kleine als grote bedrijven kunnen veel winnen door informatie te delen met SharePoint out of the box. Je moet eens kijken wat een tijd en geld verkwist wordt in bedrijven door geen producten zoals SharePoint te gebruiken.

Als je daarnaast als bedrijf nog wil investeren in functionaliteit out of box, moet je inderdaad goed nadenken over wat je doet. Maar er zijn genoeg mogelijkheden om zeer nuttige functionaliteit toe te voegen, denk maar aan Nintex. Hierboven ook al vaak genoemd.

Eerlijk gezegd vind ik ook het standaard delen van informatie slecht uitgewerkt in SharePoint. Allemaal losse vakjes en sitejes. Waar ik werk heeft men inmiddels meer dan 5,000 SharePoint sites om documenten te delen. Allemaal een eigen structuur, permissies zijn anders per site, documenten staan er dubbel in, enz.

We gaan off topic. SharePoint 2013 is gebouwd op Search. Out of the box kun je dan ook documenten via een zoekopdracht ordenen en op 'dashboards' tonen. Search houdt ook rekening met rechten. Door slim metadata in te zetten bewaar je de data dus binnen je afdeling in de wetenschap dat iedereen het binnen de organisatie zal kunnen vinden.

On topic: Infopath was een ster in het voorzien van documenten van metadata. Daar moet Microsoft iets voor gaan bedenken als InfoPath verdwijnt.

Dat was bij ons ook het idee. De realiteit is dat niet iedereen "slim metadata inzet" en dat al helemaal niemand nieuwe metadata aanvraagt wanneer een document het vereist. Het resultaat is een grote bak met erin een enorme stapel documenten.

Tja, technisch inrichten van SharePoint is deel 1. Iedereen er goed mee laten werken is deel 2. Minstens een iemand binnen de organisatie moet zich verantwoordelijk voelen voor de content van het Intranet. Als niemand zich daarvoor inzet moet je niet SharePoint de schuld geven.

InfoPath kan alleen technisch helpen met met het voorzien van Office documentent van metadata en het opbouwen van een formulierenstroom als steun bij bedrijfsprocessen. Je mag daarna als bedrijf lijnen uitzetten of er een potje van maken.

Ik ben in mijn werk (IT) of prive dit volgens mij ook nooit tegen gekomen. Werd Infopath in een bepaalde branche veel gebruikt?

Ik ben in mijn werk (IT) of prive dit volgens mij ook nooit tegen gekomen. Werd Infopath in een bepaalde branche veel gebruikt?

Ik zie het vooral terugkomen in workflows op Sharepoint. Infopath is daar de ideale companion voor.

Dat gezegd hebbende; Microsoft heeft ook met Sharepoint workflows en Infopath nogsteeds geen flauw benul van wat de gebruiker daar nou eigenlijk bij nodig heeft...... Net als met de workflows die ze ooit in Exchange in wilde bouwen slaat ook de implementatie in Sharepoint de plank aardig mis.

Ik heb SharePoint altijd meer gezien als een SDK, dan als een eind product. SharePoint is eigenlijk niet meer dan een toolbox om redelijk 'eenvoudig' een intranet neer te zetten. Die gedachte zie je ook terug bij de 'extenties' voor Office, Exchange, TFS en eigenlijk ook wel System Center.

Net als Microsoft hink ik bij Sharepoint ook op twee dachten: Als programmeur vind ik het SharePoint (WebParts) concept prettig, maar als eind gebruiker vermijd ik het als de pest.

Echter elk bedrijf heeft behoefte aan een ander soort intranet. Bij sommige bedrijven is het intranet meer een soort van blog terwijl weer andere bedrijven het gebruiken om de stroom van informatie in goede banen te leiden en dienen alle verzoeken via sharepoint gedaan te worden (nieuwe workstation, bepaalde software installatie, firewall exceptie, aanmaken nieuwe user, vrije dagen, declaraties, etc) waarbij op verschillende schrijven toestemming moet worden gegeven.

En zoals vaak met software welke 'alles' moet kunnen, werkt het in de praktijk vaak net niet lekker..

Kijk eens naar bonjour protocol van Apple
http://nl.wikipedia.org/wiki/Bonjour_(software)
Bestaat al heel lang en werkt altijd super.

Vandaar wellicht deze stap. Hopelijk is de nieuwe oplossing een stuk beter.
Over een paar maanden zullen we het weten.

Vandaar wellicht deze stap. Hopelijk is de nieuwe oplossing een stuk beter.
Over een paar maanden zullen we het weten.

Één van de belangrijkste eisen aan een goed workflow pakket is afstappen van relationele systemen. Ik kan me niet voorstellen dat Microsoft in staat is die stap te maken.

Maar ik wacht met spanning af.

Wat hebben relationele databases hier precies mee te maken?

Wat hebben relationele databases hier precies mee te maken?

Een workflow is per definitie een non-relationeel proces. Het toevoegen van relationaliteit in een workflow maakt de workflow tijd-sensitief en daarmee vernietigd het de mogelijkheid om terug te kijken.

Voorbeeld:
Een klant besteld een product bij een winkel. Deze bestelling wordt vastgelegd in een relatie tussen klant (met gegevens), producten (met gegevens) en order.
In een relationele database zal deze bestelling na een bepaalde tijd niet meer kloppen. Tenslotte zijn de klantgegvens en productgegevens wellicht verandert. Het bekijken van de order zal dus na verloop van tijd informatie opleveren die anders is dan de informatie van de originele order.

Nu nemen we dezelfde klant met dezelfde bestelling maar in een document-based database. De klantgegevens worden opgehaald en in het document gestopt. De productgegevens worden opgehaald en in het document gestopt. Daarna worden order gegevens toegevoegd.
Het maakt niet uit wanneer je naar deze order kijkt; hij zal hetzelfde blijven.

Nu weet ik dat dit ook mogelijk is met een goed opgezet relationeel systeem. Maar de bottom-line blijft dat document-based systemen hier oneindig veel beter in zijn; een concept wat Microsoft nooit begrepen heeft. En met Microsoft's sterke focus op MS-SQL verwacht ik niet dat ze dat in de volgende iteratie van hun forms-product wel zullen begrijpen.

het model dat je schetst voor de relatie tussen bestelling en de producten entiteit is een slecht relationeel model. je kan dit prima in een relationele database doen zonder de beperking die je hier aanhaalt.

het model dat je schetst voor de relatie tussen bestelling en de producten entiteit is een slecht relationeel model. je kan dit prima in een relationele database doen zonder de beperking die je hier aanhaalt.

Uit eigen werk:

Nu weet ik dat dit ook mogelijk is met een goed opgezet relationeel systeem. Maar de bottom-line blijft dat document-based systemen hier oneindig veel beter in zijn

Om even opnieuw Occams Razor aan te halen:
De beschrijving van de oplossing is in een document-based systeem veel eenvoudiger en zal dus de beste oplossing geven.

in je voorbeeld ga je er van uit dat er geen historiek wordt bijgehouden van de prijs in een aparte tabel, maar dat het een value is in de producttabel, waardoor de relatie fout loopt.

Dit is een schoolvoorbeeld van slecht programmeren, maar daarom moet je het kind niet met het badwater weggooien.

in je voorbeeld ga je er van uit dat er geen historiek wordt bijgehouden van de prijs in een aparte tabel, maar dat het een value is in de producttabel, waardoor de relatie fout loopt.

Dit is een schoolvoorbeeld van slecht programmeren, maar daarom moet je het kind niet met het badwater weggooien.

Zoals gezegd; je kunt truken uithalen in relationele systemen om hetzelfde te bereiken maar relationele systemen zijn in de basis niet geschikt voor document-gebaseerde functionaliteit.

In relationele systemen zul je óf de relatie tussen de order en de eigenschappen van de order los moeten laten (waardoor je dus geen relationeel systeem meer hebt), óf overal een uitgebreide historie bij moeten houden (wat funest is voor je opslag en performance). In een document-based systeem heb je zonder enige inspanning meteen alle functionaliteit die je nodig hebt.

Again; Ja, het kan in relationele systemen, maar in een document-based systeem is het oneindig veel eenvoudiger.

Ik heb veel document versus relationele discussies gehad/gezien de afgelopen jaren. Maar dat mensen voor deze non-argumenten een +1 geven geeft aan de misconcepties nog veel wijdverspreider zijn dan ik dacht.

Punt 1: workflow en relationele processen. Wat is het verband nu precies wat je probeert aan te geven?
Punt 2: Als je een orderhistorie bij wilt houden leg je altijd kopieeen van de dan geldende waarden aan. Of je nu relationeel of document oriented werkt
Punt 3: Wat je eigenlijk beschijft is een document archief en heeft niets te maken met relationeel versus document bases databases.
Punt 4: los van of ze oneindigveel beter zijn in iets, zijn er genoeg situaties te bedenken waarin relationeel minimaal net zo goed, zo niet beter is. Als de geschiedenis bekijkt zijn document databases al heel vaak geprobeerd (Lotus Notes anyone?) en keer op keer lukt het niet om het relationele model te verdringen. Ockhams razor toepassen: er zal wel iets zijn in relationele databases wat er voor zorgt dat het eenvoudiger/beter/breder te gebruiken is en daarom wint.

Als de geschiedenis bekijkt zijn document databases al heel vaak geprobeerd (Lotus Notes anyone?) en keer op keer lukt het niet om het relationele model te verdringen.

Mooi heh? Dat twee systemen die een ander doel hebben naast elkaar kunnen bestaan?
Dit is net zoiets als zeggen dat Facebook nog niet geslaagd is in het verdringen van EMail.

En het mooiste is nog dat je dat zelf al aantoont met je voorbeeld. Lotus Notes is nu, na 20 jaar, nog steeds een enorm succesvol platform. Dat IBM Nederland het hier verneukt heeft met hun implementatie bij Philips zegt helemaal niets. Wereldwijd gezien zijn er nogsteeds miljoenen gebruikers.
Occams razor toepassen is hier inderdaad de beste optie: Als beide systemen nogsteeds bestaan zullen ze allebei wel bestaansrecht hebben.

Lotus Notes is nu, na 20 jaar, nog steeds een enorm succesvol platform. Wereldwijd gezien zijn er nogsteeds miljoenen gebruikers.

ik denk dat er zelfs een veelvoud zimbra gebruikt, laat staan exchange

Waarom Lotus notes een succes is is mij wel een raadsel, zal wel met kosten te maken hebben want het gebruikersgemak is in ieder geval slechter dan bij de gemiddelde web based (gratis) email dienst.

hangt er van af wat je met je data wil doen, maar dat neemt niet weg dat je een slecht voorbeeld van relationele databases gebruikt om ze af te kraken. Document-based systemen vragen net meer opslag omdat je geen relaties legt en minder performance voor simpele queries, maar als je bvb de gemiddelde verkoopprijs voor producten met een zeer volatiele prijs wil gaan berekenen, zal het plots veel performance-intensiever zijn.

Soms is simpeler niet beter en moet je kijken naar wat het doel is. Moest je ze afkraken omdat de ontwikkeling langer en duurder is, zou ik je nog kunnen bijtreden, maar de quick way is vaak ook the dirty way, waarbij flexibiliteit vergeten wordt

hangt er van af wat je met je data wil doen

Exact wat ik al een paar keer zeg....

, maar dat neemt niet weg dat je een slecht voorbeeld van relationele databases gebruikt om ze af te kraken. Document-based systemen vragen net meer opslag omdat je geen relaties legt en minder performance voor simpele queries, maar als je bvb de gemiddelde verkoopprijs voor producten met een zeer volatiele prijs wil gaan berekenen, zal het plots veel performance-intensiever zijn.

Maar dan ben je helemaal niet meer met de workflow bezig en heb je dus zowieso je gegevens al niet meer in je document-based database staan.

"Oneindig veel eenvoudiger..." Als je toch aan het overdrijven bent kan ik ook beweren dat het oneindig veel complexer is om verbanden of management informatie te destilleren uit een docuementgebaseerde systemen.

"Oneindig veel eenvoudiger..." Als je toch aan het overdrijven bent kan ik ook beweren dat het oneindig veel complexer is om verbanden of management informatie te destilleren uit een docuementgebaseerde systemen.

Ik zeg ook niet dat Document based systemen de be-all en end-all zijn. Ik zeg wel dat als het over WORKFLOW gaat, ze over het algemeen superieur zijn.

Nog sterker: relationele systemen zijn net zo ongeschikt voor BI als dat documentbased systemen zijn. Je wilt daar graag dimensionele systemen hebben. Helaas zijn er nog helemaal geen zinvolle dimensionele database systemen dus zullen BI toepassingen het nog even met relationele systemen moeten doen.

Op het moment dat een klant een order plaatst, ga je al de-normaliseren: de naam, omschrijving, prijs van producten ga je los opslaan, juist om deze problemen te voorkomen.

Als je workflows maakt met Windows Workflow Foundation en bv InfoPath, dan kan dat prima 'non-relationeel'. Het InfoPath document (de XML met de data) wordt dan gewoon als "state" opgeslagen in de workflow State Machine. Dat die workflow state in een relationele database wordt opgeslagen heeft helemaal NIETS te maken met het wel of niet relationeel zijn van de door de gebruiker ingevoerde gegevens.

Als een orde geplaatst is en uitgevoerd dan zou die in eerste instantie al niet gewijzigd mogen worden in de database (lijkt me meer een manier van hoe je de database opstelt).

Ik ben in mijn werk (IT) of prive dit volgens mij ook nooit tegen gekomen. Werd Infopath in een bepaalde branche veel gebruikt?

Ik zie dat InfoPath veel in ziekenhuizen wordt toegepast. Veel formulieren moeten daar gedigitaliseerd worden en InfoPath is daar een uitstekende tool voor. Ik heb zelf ook nog genoeg formulieren ingericht in ziekenhuizen m.b.v. InfoPath.
Wat voor ons vooral goed werkte was het maken van een template en dan gewoon de inhoud inlezen vanuit een xml bestand. Hartstikke simpel om te bouwen en je hebt er enorm veel profijt van.

Hoe gaat dit nu eigenlijk voor Office 365 gebruikers? Blijft InfoPath 2013 staan als Office 16 erover heen wordt geïnstalleerd?

Anyway, zelf gebruikte ik deze applicatie nooit en wist eigenlijk niet eens waarvoor hij diende. Waarschijnlijk is dat ook de reden dat deze nu verdwijnt.

Je hebt nog nooit Office versies 'over' elkaar heen kunnen installeren. Wel naast elkaar. Infopath blijft dus behouden, net als Word 2013 bijvoorbeeld.

Waarschijnlijk op dezelfde manier als Office 2010 std installeren over Office 2007 Pro, de software die niet in de nieuwe versie zit blijft gewoon op de laatste versie staan . Dus alles zal naar Office 16 verhuizen en InfoPath 2013 blijft InfoPath 2013.

Ik heb dit afgelopen jaar voor het eerst gebruikt om een simpel formulier te bouwen en te integreren in onze afdelingssite binnen Sharepoint. Het werkt erg simpel en snel. Volgens mij worden de serieuzere workflows dan ook wel met Nintex gemaakt, vandaar dat Microsoft dit product laat vallen?

Ik vond t maar een log groot pakket voor iets wat gewoon web based moet kunnen... Of in een lichte portable app.

Jammer, maar het was al langer bekend. Gelukkig wordt het niet deprecated in een service pack van SharePoint. Daar was eerst ook nog sprake van.

Ik ben beniewd wat de vervanger zal zijn. Wellicht. NET forms? Voor functionele beheerders/consultants was het altijd makkelijk met InfoPath formulieren te maken. Nadeel bleef altijd wel voor SharePoint dat het alleen voor de enterprise versie beschikbaar was (icm rendering in de browser)

Binnen Google Apps heb je ook wel een app waarmee je formulieren kan maken.

Eindelijk! Wat een verschrikkelijk gedrocht is dat InfoPath, bij ons in het bedrijf gebruiken ze het voor de rapportages na major verstoringen. 9 van de 10 keer krijg ik errors bij het opslaan terwijl het een super simpel formulier is. Maja waarschijnlijk zullen ze het bij ons blijven gebruiken, wij gebruiken nu al veel uitgefaseerde software gaat waarschijnlijk alleen maar erger worden. Ik heb ook het idee dat je in word precies dezelfde formulieren kan maken als je beetje goed bent.