InfoPath Dev

Hi
Just started investigating infopath, you guys have lots of great stuff here.

I've got an "Approach" question.

Basically, I've got a health services company, lots of paper forms they're looking to automate. IP Seems like a great way to go except for the handling of offline stuff.

Essentially, lets say I have 20 forms and users will create 10 "entries" per form, per day (Yeah, this is likely a little overblown, but I just want to work through the handling).

So, If I'm understanding it, that user will end up with 200 seperate XML files at the end of the day, and they'll have to +individually+ reopen and "submit" each one once they're connected back to the network.

Doesn't sound so hot.

Is there some built in functionallity for managing forms offline that I'm missing or is that really a "roll it yourself" issue.

I've found ways to SAVE off the xml on submit and essentially "queue" it up (very good examples on the IP Team blog site), but that approach requires a fully trusted form, which I'd rather not have to do, because it means that more more work getting it installed on each machine.

My Current thinking goes like this.
1. Create a "Master" IP form, that contains one big dataset in a "master child" configuration for all the various forms I want to collect.
2. Put each form in a seperate view (there's about 120 of em though)
3. Only allow those forms that are appropriate for a user based on the users login credentials (so they can't see all 120)
4. During the day, all input is stored in a single XML file, queued up. When they reconnect to the network, I light the SUBMIT button, give em a list of those forms that can be submitted (maybe even with a checkbox to only submit certain forms) and then handle the submit with some custom scripting code back into the database


The benefits as I see it is
1) All the forms are in one place, makes it easy for users to download and manage things
2) gives easy access to all created forms for users to perform an "overall submit" at the end of the day.
3) maintenence is simplified because everythings in one file, no copying tons of script code and keeping a bunch of seperate forms up to date as scripting changes.
4) I Won't have to "trust" the master form, because the user can simply save that single form to the same filename over and over. Requires not Save or saveas access and won't require that I get to the filesystem through script.


Anyone else try to handle a situation like this. Am I off my rocker? Is there a better way, maybe even a better solution than IP?

Thanks
Darin

Hi Darin,

Welcome to our forum! Let me see if I can respond to your post...

If users have 20 forms with 10 fields they should only have 20 xml forms to submit at the end of the day. E-mail integration is built in, so they could conceivably send to an automated mailbox that opened the forms and submitted them to a database or website. Assuming they have an e-mail outbox, this should be pretty seamless. When they go back online the machine would automatically send them in so they wouldn't have to remember to do this.

E-mail submit should be doable with domain level trust.

The big challenge is the performance with the huge dataset. You'll want to make sure that the dataset used to prepopulate the form is set into the secondary data source. Otherwise, if the dataset is large, it could significantly impact view performance.

I wouldn't put separate forms in separate views. That won't scale well. You could put all of the forms in a master-detail within the same view. That would be better. It should be easy to limit which forms they can see, but it isn't a truly secure solution since they could just open the XML in notepad. You'll want to do something else.

You could enable submit when they go back online, but that might require full trust (to query online status). I don't remember.

In general, the problem with all of the forms in one place is that they have to then be shredded during the submit process. I.e. more coding required at submit time. But, you're right about it being a more accessible interface to see and edit multiple forms. Benefit #3 doesn't really make sense since the script isn't copied anyway. The solution template defines the code. The code does not exist in the form. Benefit #4 also looks like a non-issue if you submit through e-mail.

Patrick Halstead [InfoPath MVP]
InfoPathDev

Hi Patrick

Thanks for the response.

Maybe I should clarify things a bit.

First, Although I may only define 20 forms, each "save" of a form results in a seperate XML file. So if the user filled out the same form 10 times, that'd be 10 XML files for that one form that would have to be submitted at the end of the day, right? Or are you thinking to create a "master detail" arrangement for each form, and store all the copies of that one form within one XML file, (so you would only have a single submit at the end of the day for ALL instances of that form that had been filled out.)

About Issue3 (copying code). If I create 20 "seperate" forms for users to fill, won't any common script code need to be copied between them all? Is there some cross template sharing facility I'm not aware of yet? By seperate I mean distinct forms (ie, Order form vs HR hire form). Maybe I'm using the wrong terminology.

About Issue 4. Email would be great, but I've been given a strict "no email" policy (HIPPA requirements and all that), So I can't truck anything through email.

My plan was to encrypt the XML using the OnSaveRequest functionallity and a little VB.NET (I've seen examples on how to do that) when storing the data locally.

Just FYI, querying online status doesn't +APPEAR+ to require full trust. At least not so far in my tests.


Two other questions.
1) How is putting all the forms (in reality there may be as many as 100 distict forms when I'm done) into a single view more scalable than using seperate views? I'm just curious. It would seem to be the same, but I haven't gotten into it too far yet.

2) It appears that I can't have the same field name in a single data source, even if they're in seperate groups, unless I create a seperate XSD file and use namespaces.
for instance
my:fields/my:Group1/my:ClientID
my:fields/my:Group2/my:ClientID

won't work, even though the client ID elements are at different levels. It's probably just an XML thing, but it sure makes things difficult if I fold all the forms into one template, because each one has a clientid field.


Thanks again for all your input and responses

Darin

Sure 10 saves = 10 forms, or you could do M-D on a Database full of forms. We have done both models. I think the latter is good for a "dashboard" or "console" that administrators use to manage the forms. Whereas, the former is good for users filling out forms, but we use both patterns frequently.

Issue 3: You don't have to copy code between forms that have the same parent template. The code lives in the template, not the form. But, if you have different templates (Order form and HR Hire form) then you're right. There is no way to share code between forms, but you can certainly create a common static library that both forms access.

Issue 4: We have a web service that encrypts data and you could use that. Let me know if you'd like to evaluate it. We will have it for sale as an InfoPath tool in a few weeks.

New Question #1) I was confused about your forms. I didn't realize you have separate schemas. Obviously, for good design, you shouldn't put all of the forms in the same view if they have different schemas.

New Question #2) Correct. This is a nuisance.



Patrick Halstead [InfoPath MVP]
InfoPathDev