Philo's WebLog : InfoPath

InfoPath & SharePoint screencast demo

philoj — Fri, 28 Sep 2007 08:01:00 GMT

As follow-up to the "hook InfoPath to a database" demo, here I'm taking a step back to a simpler form - building an InfoPath form to be used on its own in conjunction with SharePoint.

http://channel9.msdn.com/ShowPost.aspx?PostID=344635

In the next few videos I'm going to cover:

InfoPath, xml schemas, and xml
An advanced InfoPath form connected to a database
Connecting an InfoPath form to a .Net web service
Connecting an InfoPath form to a SQL Server web service
eForms & workflow in SharePoint

(Just a reminder - this and other fun InfoPath 2007 stuff all covered in my book...)

I'll also be covering more business intelligence content (SQL Server Analysis Services, ProClarity, PerformancePoint - stay tuned!)

Why InfoPath?

philoj — Thu, 20 Sep 2007 18:59:00 GMT

Okay, I'm going to try a different approach on the "why do I care about InfoPath?" issue.

I recorded a short screencast and posted it to Channel9: http://channel9.msdn.com/ShowPost.aspx?PostID=343092

In the screencast, I walk through setting up an InfoPath form to connect to a database, and show how the idea is to free up developers from having to write form after form after form...

I'd like feedback on if this approach helps, and if you'd like to see more screencasts.

For those who are wondering, the last year has been a bit, um, "interesting." I transferred out of my Office Developer role and over to the BI group, was in the BI group when we acquired ProClarity, lived through PerformancePoint's growing pains, and just three months ago transferred again to the Lockheed Martin account team. So - bumpy roads all around.

I'm going to broaden the focus of the blog here a bit (but Philo, how can it be any broader than "haven't posted anything"?) well... I'm going to start covering Business Intelligence as well, but keep a solution-oriented focus including SharePoint and InfoPath.

We'll see how it goes.

"InfoPath isn't part of Office"

philoj — Mon, 26 Feb 2007 16:04:00 GMT

Simon said:

"Then you find out its not part of the office suite."

To be fair, this is somewhat true. At best, it's confusing.

With Office 2003, InfoPath wasn't part of the suite you could buy retail or on open license. However, if you bought Office Pro on an enterprise agreement, you did have rights to InfoPath for every desktop.

Unfortunately, in the volume license media, there were two DVD's: one labeled "Office Professional" and another labeled "InfoPath." You had to understand the licensing to understand that you owned InfoPath.

This is much better in Office 2007, where InfoPath is in Office Professional Plus, Enterprise, and Ultimate.

Why hasn't anyone heard of InfoPath?

philoj — Mon, 26 Feb 2007 02:46:00 GMT

I recently wrote a book on InfoPath 2007. What I find most amazing about the book is that it's evangelizing InfoPath. I've shown a number of developers the book, and when they read the description, their reaction is "wow, InfoPath sounds cool - I should check it out."

How is it possible that a member of MS Office that's four years old has almost no mindshare?

I don't know the answer - I'd be interested to hear suggestions on how to get the word out to more users and developers.

Creating a web service for an InfoPath form in 25 easy steps

philoj — Tue, 08 Nov 2005 08:07:00 GMT

It took me a while to figure out how to do the InfoPath/webservice thing starting with an InfoPath form. Maybe this is blindingly obvious to everyone but me, but here it is anyway:

1) Create an InfoPath form from a new, blank form:

2) Lay out your form, using sections, grouping, and naming controls as appropriate:

3) Extract the form files (File | Extract Form Files) to a location you can find later.

4) Open Visual Studio .Net (I'm using 2003 in this example; this will work with 2005 as well. Remember - we're only building the web service in VS.Net; not InfoPath code)

5) Create a new ASP.Net web service project.

6) Switch to the code view of Service1.asmx and note the namespace. (Rename Service1 or add a new Web Service if you choose to)

7) Open the Visual Studio command prompt:

Start | All Programs | Microsoft Visual Studio .Net 2003 | Visual Studio .Net Tools | Visual Studio .Net 2003 Command Prompt

8) You'll have to either close InfoPath or copy the myschema.xsd to another location (the file will be locked by InfoPath in design mode)

9) Go to the location you specified in step 8. Run xsd against the myschema.xsd in that directory; specify the namespace to the namespace from step 6:

xsd.exe myschema.xsd /classes /l:cs /n:InfoPathFormService

10) You'll now have a myschema.cs file. Add that to the web service project (right-click on the project, Add -> Existing item)

11) Define a new webservice method:

[WebMethod]

public void SubmitForm(myFields newForm)

12) myFields is the root of the object model for your form:

13) Put any logic in the WebMethod you need to parse the values out of the form, perform business logic, update databases, etc.

14) Finally, let's hook the InfoPath form to the submit webservice. Publish the web service to a web server:

15) Copy the URL of the web service.

16) In the design mode of our InfoPath form, open Tools | Submitting forms:

17) Enable submit commands and buttons, select "Web Service" for "Submit to"

18) Add a data connection, paste the URL of your web service in the location box:

19) Next, then select the operation for your submit form action, then Next > again:

20) The next dialog will prompt to match the form's submission to the web method's parameter. Select "Field or group" then click the node button to the right of the text box:

21) Select the myFields node, then click "OK"

22) Select to Include the XML Subtree, including selected element

23) Next, Finish, then OK

24) Publish your form

25) Now, when users fill out the form, they can save it to their local drive as an XML file, or submit it to your web service.

Stupid SQL Tricks

philoj — Fri, 21 Oct 2005 01:59:00 GMT

Argh.

Classic Schroedinbug. I had an outer join between two tables to populate an InfoPath multi-select listbox. (So I needed a list of potential options with indications of which options had been selected). I created an outer join and put my parameter in the WHERE clause, like this:

SELECT dbo.NeedRequestType.NeedRequestID,

dbo.NeedType.NeedTypeID,

dbo.NeedType.NeedType,

dbo.NeedCategory.NeedCategory

FROM dbo.NeedCategory LEFT OUTER JOIN dbo.NeedType

ON dbo.NeedCategory.NeedCategoryID = dbo.NeedType.NeedCategoryID

LEFT OUTER JOIN dbo.NeedRequestType

ON dbo.NeedType.NeedTypeID = dbo.NeedRequestType.NeedTypeID

WHERE (dbo.NeedRequestType.NeedRequestID = 11)

OR (dbo.NeedRequestType.NeedRequestID IS NULL)

The interesting thing is that when you don't have much test data, this works. The WHERE clause combined with the outer join effectively selects "orphan" records out of the reference table. But as the number of "orphans" drops (by being selected), so do the number of records returned, until you only get the records that match your parameter ID (in this case, 11).

The proper syntax is:

SELECT  dbo.NeedRequestType.NeedRequestID
       ,dbo.NeedType.NeedTypeID
       ,dbo.NeedType.NeedType
       ,dbo.NeedCategory.NeedCategory

FROM    dbo.NeedType
JOIN    dbo.NeedCategory
   ON    dbo.NeedCategory.NeedCategoryID = dbo.NeedType.NeedCategoryID

LEFT OUTER JOIN
         dbo.NeedRequestType
   ON    dbo.NeedType.NeedTypeID = dbo.NeedRequestType.NeedTypeID
   AND   dbo.NeedRequestType.NeedRequestID = 11

Ah well, live and learn.

Philo

Emailing a different InfoPath form

philoj — Tue, 26 Apr 2005 01:33:00 GMT

I recently needed to create an InfoPath form that enabled the user to post the data to another user in a format they could open in *their* InfoPath form. After some thought, I went with the idea of running an XSL transform on the data and posting it via an email connector.

Of course, first I needed to create the XSLT. Obviously you can do this in notepad, but I prefer tools that are less likely to make my eyes bleed. I chose to go with Altova's MapForce - it's a great visual designer for mapping one schema to another:

I extracted the form files from each InfoPath form and loaded the myschema.xsd files as source and destination. MapForce handled most of the mapping, connecting similarly-named nodes. Then I generated the XSLT. I had to do a quick edit on the XSL to provide the processing instructions and pull out the schemaLocation attribute on the root. (You can probably do this in MapForce too, but I was in a rush...)

So, next thing - add the xslt to the form as a data connection. You want to create a data connection that will Receive Data from an XML file - then you can select your XSLT file and add it as a resource.

Now create a data connection to submit the form via email - set properties as needed.

Add a button and add form code - I'm working in jscript so that I didn't need a fully trusted form.

The final step, add the following code:

//Get the current form data
var CurrentForm=XDocument.DOM;

//Get the transform
var XSLTFileDOM=XDocument.GetDOM("MTCXSLT");

//Initialize the final xml DOM
var tmpDOM=new ActiveXObject("MSXML2.DomDocument.5.0");
tmpDOM.validateOnParse=true;
tmpDOM.async=false;

//Perform the transform; strDOM gets the XML String
var strDOM=CurrentForm.transformNode(XSLTFileDOM);

//Load the XML String from above into our DOM variable
tmpDOM.loadXML(strDOM);

//Post the DOM via email.
XDocument.DataAdapters("SubmitToMTC").SubmitData(tmpDOM);

Voila!

Philo

Creating a Structured Product Labeling Editor

philoj — Sun, 06 Jun 2004 08:16:00 GMT

The challenge: use InfoPath to create an editor for the Structured Product Labeling (SPL) subset of the HL7 Clinical Document Architecture (CDA) schema.

I've done quite a bit of document-centric work, and my philosophy has always been to design an XML schema first, because from an xsd, all other things can flow:

InfoPath can generate forms from schema
BizTalk can generate maps from schema
There are EDI tools to generate implementation guides from schema
XMLSpy can generate databases and code from schema

So when I was told there was an SPL schema to work from, I figured this was a one-day job, tops.

I was wrong.

Here's what a drug label usually looks like in the physical form. Now, one of the great features of InfoPath is that you can just point it at an xml schema and get a form out of it. However, doing this with the SPL Schema (this isn't complete - the included files aren't there; see the SPL schema link for the whole schema) yields a pretty unsatisfying result.

The problem is that the schema has a whole lot of metadata, and what is there for content is just markup, like HTML (imagine trying to autogenerate a form from the schema for xhtml - it doesn't reflect how people really use the schema).

This is, of course, in retrospect. Going in, I couldn't get the hang of why the form wasn't getting me where I needed to go. It wasn't until I looked at the sample SPL XML - that's when the markup concept clicked and I started looking at the SPL schema as a destination instead of a source.

Another consideration is that the SPL Schema serves the label, not the drug or the company. What this means is that the information in the schema is geared towards describing the medication, but there may be additional information regarding the drug, the label editing and approval process, or other considerations that the pharmaceutical company wants stored with the label.

These two considerations indicate that the label is best served by using an authoring schema to store the information and generating the SPL XML from that schema. Since InfoPath natively stores its data in XML, the InfoPath schema can serve as an authoring schema nicely. (Alternatively, if the pharma already has a business system in place to store SPL-type information, InfoPath can be designed to interact with that system)

So - next week we'll lay out an InfoPath form to serve the label, designed from a blank form to save directly to XML.

Philo

Healthcare / HL7 solution

philoj — Fri, 04 Jun 2004 17:51:00 GMT

Over the next few days I'll be posting a series of articles covering my trials and tribulations in creating an “HL7 Generator” - specifically using InfoPath to generate XML in the Structured Product Label format, which is a subset of the Clinical Document Architecture.

Here is an image of the (nearly) completed form.

As usual, it turns out the best approach was to look at it sideways...

Here's an (updated) approximate schedule of the articles:

6/7/2004: Analysis and SPL overview
7/12/2004: Form Design
7/19/2004: Code
7/26/2004: XSLT and views
8/2/2004: Task pane

Of course, this is subject to change as I write...

Philo

InfoPath Context Sensitive Help

philoj — Sun, 25 Apr 2004 23:10:00 GMT

InfoPath SP1 (public beta at the link; final due out this summer) includes a lot of cool changes, both in the UI and behind the scenes (most notably the ability to stuff managed code behind the form). First I'm going to cover the OnContextChange event and using it to create context-sensitive help.

To create a managed code InfoPath form, you need to download the InfoPath Toolkit for Visual Studio .Net - this provides the templates for InfoPath in VS. Once installed, open Visual Studio, create a new project, select Microsoft Office InfoPath Projects, then either “Visual Basic Projects” or “Visual C# Projects” (I'll be using C#), and “InfoPath Form Template” from the “Templates” pane.

Name your project, click “OK” and you've got an InfoPath project and form. (Also notice that under the “Project” menu in Visual Studio you've got some new InfoPath commands, most notably “Open InfoPath” for those times you close the form designer)

So, for our context-sensitive help we're going to need an HTML file containing the help. Create your file - all you really need to do is append all the help paragraphs/articles into a single file. The way I handled context sensitivity is to wrap each help segment into a DIV, then hide all the DIVs and show the appropriate DIV based on the control selected. Other possibilities include using HTML anchors and scrolling to the anchor for the article, or even creating a document with an empty DIV, then pulling the text from another location and dynamically inserting it into the document.

So, I have an HTML document with a series of DIVs. I used FrontPage 2003 because I found the layer handling helped out a lot. (View | Task Pane, then in the Task Pane menu at the top select “Layers”) You'll want each layer/DIV to use the following tag:

For [Name] use the control name for the control you want the DIV associated with.

[Thanks to Josh Bertsch for help with the following code, C# and jscript]

Now add the following jscript to the <HEAD> of the file:

This will, after a 1-second pause, zip through the DIV tags in the file, showing the one whose ID is the same as the control name, and hiding the rest.

Once you're happy with the file, in InfoPath go to Tools | Form Options, then the Advanced tab. In the “Custom Task Pane“ section check “Enable custom task pane”, then click the “Resource Files“ button and add your file. (NOTE: if you change your help file later, you'll have to go to this option, remove the file and add it again, otherwise you won't see your changes). Once you've added the file, then it should be available in the drop-down for “Task pane location“ - select it.

Now, in InfoPath go to the Tools Menu, Programming, and click “On Context Change Event“ - this will create and take you to the OnContextChange event handler in the VS.Net IDE.

Add a reference in the project to Microsoft.mshtml.

Use this code in your OnContextChange handler:

if (e.Type == "ContextNode")

{

string aLoc=e.Context.nodeName;

aLoc=aLoc.Replace("my:", "");

HTMLTaskPaneObject taskPane=(HTMLTaskPaneObject)thisXDocument.View.Window.TaskPanes[0];

mshtml.HTMLWindow2Class window=(mshtml.HTMLWindow2Class)taskPane.HTMLDocument.Script;

window.execScript("waitForContext('" + aLoc + "')", "JScript");

}

That should do it - now just remember that the DIV id has to be the same as the name of the control. Also watch out for width/height definitions on the DIVs - best to just let the task pane do the formatting.

Philo

Why Smart Clients?

philoj — Tue, 16 Mar 2004 22:23:00 GMT

... or “Why is my client so fat?”

InfoPath is really cool. To some degree, it actually delivers on the ancient promise of “productivity without programmers.” Fundamentally, it's a form design and publication tool - end users can design forms and publish them to a server where the people who need to fill out the form can access it, fill in the data, and submit the data to a predefined data store.

When combined with SharePoint, there is generally no reason a developer needs to be involved at all - users can lay out forms, create lookups, create *cascading* lookups, add validation, and so on. If the data is simply to be aggregated in a SharePoint forms library, the whole thing is automagical and can be queried directly at the end.

I think it's a wonderful thing for developers because personally I find building generic forms for standard business data collection somewhat, uh, tedious. I'd much rather be solving larger business problems and inventing the next bread slicer.

“But Philo,” you ask, “what does this have to do with fat, er, smart clients?”

Simple - the #1 question regarding InfoPath is “does everyone need InfoPath on the desktop to use an InfoPath form?”

The answer is “it depends.”

Since InfoPath is all XML based (the form definitions are saved in a cab file, but fundamentally they're an XML Schema; the form data is an XML document with a pointer to the XSD), then no - you could easily write an ASP.Net page or a Windows forms client that uses the form XSD to generate the form data in a properly-formatted XML document. But that's not really what the questioner is asking - they want to know “can people without InfoPath on their desktop use the InfoPath forms with no additional coding?”

Think about it - boil that question down and it's “can we get all the InfoPath functionality without InfoPath?” To which the polite answer is “no.”

Why not?

Anyone who's done web development has faced this question: “Can we have spell checking in this data entry form?” Often this happens on a contract where one delivery requirement is for complete client-side validation. Well, in essence this means that every time someone downloads the form, they need to download a dictionary as well. Rich text formatting, validation, spell-checking - these are all requirements we've faced, and we've either bought tools or coded them ourselves.

This means:

Additional development cost
Additional testing cost
For web-based clients, additional download sizes (often massive ones)

InfoPath offers a rich platform for end users to create forms on that provides the full power of the Word libraries (spell checking, grammar checking, rich formatting), a solid client-side validation model, .Net-based code behind (in SP1, download the preview), and offline capability. That's right - a web-aware solution that works in an offline mode, no additional code on your part necessary.

[One caveat in here is where the data goes. As I mentioned above, if the data is going into SharePoint, the end user can build the whole thing. If it needs to go into a business system, the IT Department may have to get involved to provide the data consumer. InfoPath consumes web services very nicely, in keeping with a service-oriented architecture.]

Web-based solutions definitely have a place, and the open architecture of InfoPath forms even allows web-enabling data entry and/or display of the form itself. But when you're talking about robust data entry requirements, web-based solutions generally run out of steam quickly. The client wants a form with spell-checking, client-side validation, offline capability, etc, etc, etc. You can build it, but it's going to be pricy, and it only solves one problem.

InfoPath gives developers the ability to let clients create their own forms with little or no developer intervention, and allows developers to move on to solving bigger and better problems. So you have to ask yourself how you'd rather spend your day: “Hey John, can you move these three fields five pixels to the right?” or “We need someone to build a proof of concept for the new smart phone client the Operations Department needs” ?

Learn more about how developers can add value to InfoPath solutions with the InfoPath Developer Resources Kit

Philo