This content has been marked as final. Show 11 replies
I'm assuming your talking in the context of workspace.
When you create a Task Manager endpoint to your process, it knows that in order to start this particular process, it needs to load the form that's define the xfaForm (or Document Form) input variable and present it to the end user.
Then when you submit the forms, it'll just submit it back that the process the end point was created for.
The form is totally independent.
You know, I was thinking that in workspace, the form is displayed and the process is not initiated until the form is submitted. I think that is not correct, rather, you are starting a process in the workspace and the form is a part of that process.
It's awesome when you have a big "aha" moment. Thanks Jasmin for clearing that up for me ;-)
Your process is not started until you submit. The form is rendered in preparation for that. It's an important difference to understand if you need to pre-populate the form. You would do that in a custom render, not your main process.
Mr. Bishop is correct.
The process is not started until the form is submitted. Workspace is just another way to invoke the process, just like if you were to use a web service call. When you hit the submit button, then it invokes the process.
The part that's confusing, is that there are settings you need to configure in the process, like an input variable with a render server), in order for that endpoint to work properly. So the forms seems to be part of the process, but really it isn't.
OK, I'm learning, ... so the form submittal invokes the process...
But if you have a custom render service, then that executes before the form is displayed, right? Then when the form is submitted, the main process is executed, correct?
Thanks for the answers ;-)
You got it!
Thanks Jasmin, now for one more question, back to my "draft" question. If you open a form in workspace, save it as draft (you will get the message that it is saved in your to-do folder), and never submit the form, what happens? Let's say the person that did this has left the company. Form is still a draft. From an administrator perspective, how can I clean these out?
I tested this with the mortgage application tutorial, saving the form three times as draft. I can not see the task for that user by using the admin ui.
The reason I ask is because I know that feature will be unintentionally abused.
Can you run a test on your end, doing the same thing, and let me know if you can see the task through the admin ui?
Here's the resolution I received from another adobe tech support contact: You would probably have to change the user's password so that the administrator can access his account through workspace and then delete all of his drafts. Since the form is not submitted, it has not entered the workflow process and will not show up as a task in the admin ui.
A request has been submitted to Adobe to add the ability for an administrator to remove drafts (in an upcoming release).
Not the answer I was hoping for, but that's ok...
Out of curiosity, does anyone know where/how Draft's are stored?
Cardinal Solutions Group
I'm glad I'm not the only one that asked that question! There was a good discussion on it at groups.google.com livecycle forum. Do a search for "workspace" and "draft" and you'll find it.
I know that the Draft function does not use the Submit on the form. Here is how I came about this conclusion:
The Save button does not appear if your process input variable is Document Form. I tricked Workspace into putting the Save button on when my submit format was PDF by making the variable xfaForm and using a submit service to convert the submitted PDF to an xfaForm variable. The Save button was there and would save the form, but apparently not as PDF because attachments were lost.