InfoPath strategy/Problem

[Tom Curtin]

I'm an enterprise architect at a large healthcare company and I'm tasked with
this great project using tablet PC's and potentially infopath to collect
survey info in the field. We're basing these forms on an existing Access
application that they had used on laptops. At this point I'm beginning to
question if InfoPath can be used for this since it seems like its data
abilities a bit limited as compared with the demo's and labs I saw at
Tech-Ed.

For example the first task is pretty simple, populate a drop down list from
a list of providers in access, and then use that list to filter a table of
patients, and then from that table select a patient and fire off the infopath
questionnaire, populating a few fields in the new form on the way.

In Access, I'd have this done in a morning, in .Net about the same, but
Infopath seems dense on this sort of thing. The business user would like to
use InfoPath, My Microsoft folks want it, and I want it.. and lord knows my
Hardware rep wants it to go, but I'm wondering if we know what Infopath is
really appropriate to the requirements.

 

[Badajoz95]

Should be really easy if you know InfoPath at all... Use Data Connection \
Add. You could use Access as a data source but in a truely distributed
environment, I would highly suggest using a .NET to wizard the Access data
into a web services and then getting Infopath to consume the web service.

Basically, if you knew InfoPath like you probably know Access then I am sure
you would say it was terribly easy in InfoPath

There as so many advantages to InfoPath over .NET or Access in terms of
development time savings for simple tasks.... but I don't have time to go
into them now... or would you rather know that as a totally independant
technical enterprise architect consultant, I am very keen about this
technology. I can certainly say that its data abilities are anything but
limited.

 

[Tom Curtin]

The actual connection and filtering isn't hard, its coming up with a way for
an end user to easily launch another form and pass the parameters, preferably
without a lot of script. I think I can use the DOM though to accomplish the
sharing of data. A little more reading and I'll probably have it.

I also agree with you about the web services approach, but I'm working under
some constraints. If I were free I'd probably ditch the access db and start
with a fresh data structure/model since its a pretty involved app that a
business user put together a long time ago.

I still don't think though that InfoPath is a full replacement YET for
Access or .Net Studio for building front-end data entry applications for end
users.

 

[Badajoz95]

Passing Parameters into InfoPath... hmmmm... little look around shows this
as a little feature oversight perhaps... but you could do a few ways I
reckon:
1. Pass parameters as suggested here
http://geekswithblogs.net/bpaddock/archive/2004/05/14/4907.aspx
2. Use 1 form with many different views. As the user clicks what form they
want to fill in then it changes view to the desired form. This depends on
the volume of the number of forms... and I have heard that InfoPath gets bad
when its big.
3. Form A saves an XML chunk of data (the parameters) that the called Form
B/C/etc know about (give full trust to forms and certificate them to enable
disk access)

Btw, agreed -> There is definately times when Access \ .NET \ InfoPath are
going to be better fits to problems and that each one now has its role. I am
currently architecting a large enterprise government application using
Office / InfoPath / SharePoint as the front end and what ever I can't do in
SharePoint \ InfoPath, has to be built using .NET web parts \ traditional
ASP.NET forms.... but as a cost effective development platform that the
users can themselves help prototype / actually build (they know office - but
don't know VS.NET - we set the XML schemas of the data - they design
against) ... I think it has its place.