This content has been marked as final. Show 7 replies
The Complete Task process is a process that already exists that LiveCycle uses to complete tasks in processes.
If you create an email endpoint to that process, then you can send an email to that process and it'll take care of completing the task for your.You don't need to add that step in your process.
For example if you have a 2-user step process called "MyProcess" and that process has two steps called "stepA" and "stepB". When a new form is initiated, the first user gets the form and the form has a task id associated with it (let's say 111). When they send the email back to the Complete Task process, it'll be smart enough to know that task id 111 refers to the process "MyProcess" and will complete that task, which will then create a new task for the second user in the process.
Yes it makes perfect sense now, with the advice you dished out on https://forum.adobe.com/webx/.3c05c334 it appears my email task submission is working!
Like Jasmine mentioned, I have
Start -> User A -(approve)-> User B -(approve)-> End
the task is created, and USER A gets the email with the PDF attached.
They open the email, approve and submit.
The email gets sent.
We receive the email in the LC mailbox.
But it never continues, and the logs see no activity.
No chron job, no listening.
We set up the pop3 and all for 30 second intervals, but it doesnt seem to work.
Does this mean that for every process I must put an email end point in it for LC to listen to its inbox, and for the process to continue?
I have added an Email endpoint to the process.<br />The mail gets removed from the inbox as i would expect but i get an error email.<br /><br />LiveCycle ES has tried to process your request and encountered the following error:<br />Cannot coerce object: <document state="active" senderVersion="3" persistent="false" senderPersistent="true" passivated="false" senderPassivated="true" deserialized="true" senderHostId="127.0.0.1//10.64.128.161" callbackId="0" senderCallbackId="27" callbackRef="null" isLocalizable="true" isTransactionBound="false" defaultDisposalTimeout="600" disposalTimeout="600" maxInlineSize="65536" defaultMaxInlineSize="65536" inlineSize="2326" contentType="application/xdp" length="-1"><cacheId/><localBackendId/><globalBackendId/><senderLocalBackendId/><senderGl obalBackendId/><inline><?xml version="1.0" encoding="UTF-8"?> <?xfa generator="XFA2_4" APIVersion="2.6.7120.0"?> <xdp:xdp x...</inline><senderPullServantJndiName>adobe/idp/DocumentPullServant/adobejb_server1</se nderPullServantJndiName><attributes file="form_data.xdp"/></document> of type: com.adobe.idp.Document to type: class com.adobe.idp.taskmanager.form.impl.xfa.XFARepositoryFormInstance<br /><br />I had to set the mapping to *.xfa otherwise the email would just be ignored.<br />It seems to me that livecycle is not clever enough to pick up an email that its own form sent to the server.<br />Furthermore it would seem that an inbox must be unique for livecycle to pick up any submitted forms. That makes the whole send form to user thing worthless, since the form send to the user ALWAYS has the standard livecycle submit email address. That means per livecycle server you can have exactly one process that has an email endpoint for in process form submissions/reminders.<br />An email inbox should work exactly like watched folders, i.e. email patterns per workflow.
After digging some more i found a "Complete Task" service, and after looking at the process and further digging:<br />ADD AN EMAIL ENDPOINT TO "Complete Task" ONLY<br /><br />This will give you exactly what should work out of the box when you select "enable incoming emails" in the server configuration about email notifications.<br /><br />(i am sure this has been mentioned a number of times, but since there is no sticky, no moderation and no useful search ...)<br /><br />Although this got me to the point of actually being able to complete forms offline i cannot actually start new processes with this.<br />A quick look at the result and it would seem that a newly submitted form produces a different xfa/xdp than a continued form. (the root node is replaced by <FSFIELDS_>)<br /><br />If anyone has any info on how to properly start processes with "Complete Task" ...
"Furthermore it would seem that an inbox must be unique for livecycle to pick up any submitted forms. That makes the whole send form to user thing worthless, since the form send to the user ALWAYS has the standard livecycle submit email address."
That's not true. The inbox and email settings are configured on the Email endpoint. You can have as many email endpoints as you want, all using their own email inbox.
I think you're getting confused with the email endpoint and the email notification that can be generated by LiveCycle.
The email endpoint will just take care of initiating a process, just like a watch folder. Once the process is initiated its job is done. If your process uses a User service, and you use Reminder and Deadlines notification, then those notification are coming from LiveCycle and not the email endpoint.
I hope this clears things up a bit.
I wont start a discussion of the usefulness of out-of-the-box functionality.
I think these forums are proof enough.
Email notification with attached form does not work "out-of-the-box". Period.
"Enable incoming email" does nothing. Reminders with form attachment does nothing.
Notifications with email attachment does nothing if the user has not logged into workspace at least once and selected "include pdf in email".
Selecting "include pdf email" does nothing if not enabled in the backend. (known issue i believe, supposedly "fixed" in SP2, however SP2 broke notifications)
Creating a different mail account for each process IS useless. That may have nothing to do with notifications HOWEVER forms that need to work for offline initiation AND offline continuation either
* need to have two different email addresses coded into the form
* only one process on the entire server can have both at the same time
Configuring pdf notifications also means that offline continuation (and in turn initiation) is enabled by default for all processes, rendering the email endpoint for individual processes useless. (as already "enabled" through complete task)
My comment was related to the email endpoint option, and that it is not only misleading but all in all useless. (for regular business processes such as purchase orders, holiday requests, etc)
I was also referring to the impracticality of adding an active directory account (+mail) for every single process.