Unfortunately with the current version you can't really do that.
You could theoretically loop back to the gateway and go back into it n number of times, but you would need a second branch that goes straight to the end, and you would need to Gateway to be "No Wait".
There is going to be a new service in the next version of LiveCycle that will allow you to specify a list of users to send stuff in parallel.
I know it doesn't help you now, but it's coming.
Is it possible to explain a bit further, I still can't get it to work.
What are you trying to do? The looping back to the gateway.
That also might not work for you. For example, if you have three users, you'll loop back twice to assign a task to two more person.
The problem with that approach is that as soon as the first user completes the task, it'll come out of the gateway to continue in the main process (main branch).
When the other two users complete their task, it'll just get to the end of the gateway and finish. I'll never get back to the main branch since it was executed by the first person that completed the task.
I'm not sure if that makes sense but let me know.
Let me try and describe my situation, it's not too hard, I kind of got it working via events, but still need to do "something" to make it right.
Alright, I have a subprocess, which is just a no-wait single branch gateway with Assign Task in the branch, and the subprocess takes a string as input (username).
In the main process, first I a list of user names from making a webservice call in a pdf form, then I use a single branch gateway (no-wait), and inside this single branch, I use the sub process we created above inside a loop that loops thru the list of users, after that's done it exit the branch and waits at the "TaskCompleted Event" receive, when the total # of "taskcompleted" events were fired and received, equal to the number of users in the list, then it proceed to the next step.
This works, but I know it will catch "any" TaskComplete event, I need to filter out the ones I only really care about (which are the ones fired off in the sub processes), so I am not sure how I can catch just those tasks I care for this process instance.
You can use a filter based on information coming from the event.
You can use the /MapContent/StepName to get the name of the step where the task was completed from.
I tried to filter by the StepName, but I can't really find the right one to use as the filter.
But I just thought of something, what if there are multiple ppl using the same process (different instance), then this wouldn't work, because the TaskCompleted event will catch the event from other instance of the same process as well.
You could cross-reference it with the processInstanceId. It is unique for every invocation of the process.
But it get more and more complicated. Like I said in my original email, this is not easy to implement in the current release.
We've built a component for doing what you want.
Download from here:
Is this feature available now with ES2? I'm struggling with same issue now.
We still don't have a "dynamic" gateway in ES2.
However if your goal is to send it to a bunch of people in parallel, you can use the Assign Multiple Task. This allows you to send a task to multiple people and consolidate the result.
Would that work?
Hi Jasmin, thanks for your reply.
Actually I want to send pdf attached emails to people outside the organization. I can solved this part of the problem with a loop. But now, I need to know how can I handle responses. I want to get all responses and merge them into a form. But I dont know how to wait for each respond? For example I sent 3 email and to proceed process, I need to wait for each response. Do you have any suggestion?
That's not easy to do because the receiving process is really independent from the process that sends the three emails. At least, I think it should.
One way to approach it it to create a receiving process with an email endpoint. This process will be responsible to receive all emails that were sent for all requests. Maybe there was a request (A) that sent three emails out and another request (B) that sent 2 emails out.
Now when you receive the emails back, you would have to maintain the state of your requests in some ways. I suggest you create a database tables to keep track of the number of emails per request. The unique identifier for the request could be the process instance id from the main process since it'll be the same for every emails in a particular request.
When they come back, you can update the db and check if you have received all emails. If not, then you terminate and continue waiting for the next one. When you get them all, you call a process that generates the form.
Does that make sense?
I created what you are referring to as a dynamic Gateway. I have had it in production for years over multiple versions. I used a No-wait gateway in a loop and an event to capture when all the threads were completed. A problem I ran into was race conditions. If the Gateway had steps A, B, C and I had two thread 1 and 2. I did not always get A1, B1, C1, A2, B2, C2. If 2 users completed a task within a couple seconds of each other, I got A1, A2, B1, B2, C1, C2. This resulted in data corruption. One of the things I did was to get rid of the Gateway and replace it with no-wait sub process. I pass the process ID of the main process over and use it in the event throw/catch. To address the approval race condition, I put everything steps A, B and C did into an Execute Script step. At the start of the step, I did a JDBC/SQL select for update on the database row for the main process on a variable/column that is not used for anything else except for the lock. A secondary benefit is the processing is much faster. I don't know if this changed in ES2, but in ES1, you could not tell from an error which line of a set value was causing the issue. If you do the same thing in an Execute Script, you get the line number in the error message.
To do something similar with emails, I would make it so the returning emails kick off a process. Store the process ID of the original process in the data of the form. Use that to throw an event back to the originating process.
I have solved the problem as you suggested. When I find an
appropriate time I will post solution to my blog.
Also thanks to Steve for his