Please note that the "PROCESS_TYPE" field Valerie references is actually named "AWS_PROCESSTYPE".
One additional note on top of Valerie's comments is that you want to make sure that your process definition does in fact have an init-form on it. The email reader will look for an init-form on the process type that you have provided in the "AWS_PROCESSTYPE" field, and will use that init-form to call createTask() (in the same way as Form Manager does). If you do not have an Init-Form specified on the workflow the workflow will actually not be started.
1.) Create form template (Designer) ensuring the AWS_MAILTO field contains the email address entered in the Workflow Email Settings page AND the AWS_PROCESSTYPE field contains the process type name where the process template exists. This is case sensitive.
2.) Save the form as XDP.
3.) Save the form as PDF. This will be used to initiate the process.
4.) Publish the XDP to Form Manager. If a subsequent step in the process is going to use the form via Form Manager you MUST associate the form with a category.
5.) Create your workflow.
6.) You must have an Init-Form that is referencing the XDP you published in step 4. **I did not include values in my dropdown so in my case the Choice-list option is blank. If you provide values for the choice-list parameter, you must ensure that the form template contains the exact same values or an error will be encountered when the user tries to submit the request.
7.) Create a new variable of type form and select the in parameter.
8.) Save and deploy your workflow.
9.) **Log into Form Manager as the user who will be initiating the process via email as you must be a known LiveCycle user. If accepting external requests, you could create a 'staging' account to facilitate this requirement.
You do not need to specify a schema to extract data from a Form Variable - it is only convenient to have a schema on your form so that the XPath browser helps you write XPath statements to the elements of the form data. You can however simply use the XPath browser to get to the default of "fields" and then append /FieldName and we will extract the correct value at runtime.
In the case of the XFO fields (AWS_*) you should not have to include these fields in the schema. In general if you wanted to add them to the schema they should be in the root of the schema and not be grouped.
Just a quick clarification. As Will mentioned, you do NOT need a schema to extract data. If you don't have one you can extract the data using the exact same XPath expressions as you would with one. The only difference is that without a schema Workflow can't build the tree in the graphical XPath expression builder so that you can simply scroll down the tree and click nodes to have it automatically build the expression.
However, if you do bind to a schema, you MUST include the AWS* fields in your schema. When you bind to a schema data that is exported conforms to the schema, so if those fields are not in the schema they will not be exported with the data.
You're right, if you don't add these fields to the schema, you won't be able to query those fields directly.
However, why would you need to query fields such as AWS_CHOICE? As far as I'm aware, they are populated automatically when the form is rendered by Form Manager, and any relevant data is extracted from these fields and used to govern the route that the workflow engine executes, the user who is logged as having completed the step, etc. I've always treated these as "internal implementation" fields that I should not/need not directly modify or read.
What are your use-cases for directly querying these fields?
Getting back to the original question, there is another way to start a process by emailing a form. Create a looping master-process that uses the EmailReceiver qpac to pull the form from a POP3 server, extract the attachment and other details, and then use the chain qpac to initiate the actual process. While this doesn't use the built-in capabilities of the workflow server to process incoming emails, in some respects, it is a simpler solution where you have more control over the operation. Just a thought...
After doing the steps from Valerie's post (#5), I still cannot initiate a workflow by e-mail.<br />Being in the prototyping phase, I am using the "administrator" account. The e-mail address is set (to "email@example.com"), and e-mails are sent and received correctly.<br /><br />But when LiveCycle processes the incoming e-mail, I have the following error message:<br />-------<br />10:19:22,640 INFO [STDOUT] 9 juil. 2007 10:19:22 com.adobe.workflow.email.Inbox<br />Reader logFailedToProcessMessage<br />GRAVE: can't process mailmessage from: Administrator <firstname.lastname@example.org>, subject: _bbo1370g1c842cri.xdp: no user found matching 'from' address<br />-------<br />I have tried to set it to 'Administrator <email@example.com>', to '<firstname.lastname@example.org>', to '"Administrator" email@example.com>', etc., and I always get the error...<br /><br />What is the expected format for the "From:" field? <br />What is the use of the "emailalias" field in the "edcprincipalemailaliasentity" table?<br /><br />Many thanks,
Only "registered" users can invoke a process. You must send the email from the email address of one of the registered users in LiveCycle. To find the address of a known user, login to http://localhost:8080/adminui and search for users, then click on each user to find out their email address.
The "administrator" user is a registered user. By default, he had not e-mail address. I added one in the "email" field of the "edcprincipalentity" table, but none in the "emailalias" field of the "edcprincipalemailaliasentity" table... and the field used by LiveCycle workflow to check e-mail addresses is the "emailalias" field !