Searching Multiple Forms

[mcp6453]

Today was my first day with InfoPath, and it seems that it is just the
ticket for a project I have. However, I don't understand how to search
across multiple forms.

Hypothetically, assume that each form includes a credit card number used
in connection with a retail sale. There were 100 sales in the previous
month. There is one completed form for each sale, so there are 100
forms. How would I search the 100 forms for the credit card number? What
would be a good way to organize the completed forms other than just
putting them all into the same folder?

It seems that there has to be some sort of database function to be able
to manage the plethora of forms. By the way, in this application, all
interactions with the forms are on the screen. There will be no need to
print any of the forms, except maybe on a rare occasion.

 

[Gavin McKay]

Hello,

If you are collecting any data via Infopath that you want to use to hook
into a back-end system I would suggest using Web Services to submit the data
to. While you can submit the form via email or to a physical location (like
a network drive), I think most of the people on this group would suggest you
store it in a database instead.

That way, searching for data would be a simple matter of a SQL statement in
a database.

However, if you are going to store it in a single location, you would need
to search across the information either via XPath using the Xml schema that
the form was saved, or use a free-text search engine to search over the
content.

You did give a credit card number in your example, so if that is the case I
would very strongly advise submitting the information directly to a web
service for storage using a secure (i.e. SSL encrypted) transport. Storing
credit card numbers anywhere must be secure, and there are plenty of articles
about how to securely transmit (generaly using SSL) and store (using one-way
encryption) private data.

HTH.

Gavin.

 

[mcp6453]

Gavin:

Thanks for the information. The credit card was just an example. The
real application does not contain confidential information.

The desired application would be a collection of completed identical
forms. While I was able to configure a form to perform exactly as I
would like, the idea of incorporating the forms into a database or to
use Web Services is foreign to me. I will have to do some more studying
to see if I can understand the technology better. If not, then at least
I can use InfoPath to better model the interface for the resulting
application.

Mike

 

[Gavin McKay]

Hi Mike,

No problem - there are tons of examples of hooking up data to web services
on MSDN. Search for "infopath" and "web services" should display plenty of
different options.

Ideally you would use Windows Communication Foundation (WCF) and .NET
3.0/3.5 as your web services base, but stock-standard .NET 2.0 *.asmx files
would also work just fine. I've implemented using WCF, but if you are new to
web services I wouldn't suggest this as a starting point - others may
disagree, but to me WCF is a very powerful, but also very advanced web
services solution. Configuration alone can take a while to get the hang of!

The end result is to get the information from Infopath into a database - how
you get there of course depends on you!

Gavin.

 

[Clay Fox]

Hi Mike.

I think Gavin's assessment is correct. InfoPath was designed to use web
services, since they provide the greatest flexibility, and provides the ideal
connectivity with SQL.

The challenge is creating these web services. You can however get a package
of installable webservices, which you can setup and use without code from
http://www.qdabra.com

This package was created so that people could leverage web services without
having to develop them from scratch and the package includes web services for
dynamically querying SQL tables as well as submitting back to multiple
tables. It also includes an Active Directory WS for identifying your form
user and leveraging Active Directory information.

If either of you would like a demonstration let me know.