Read the PDF details into an Excel file and store the information in the dtData DataTable variable, set up the necessary arguments, and invoke the Main workflow.
Use a For Each Row activity to iterate through each row in the dtData DataTable. * Within the loop, upload the corresponding PDF to the storage bucket.
Use the Create Form Task activity to create a task for each PDF and display it in the Orchestrator Action Center.
Configure the Form Task with the PDF details, including the approve and reject buttons.
Retrieve the output from the Create Form Task activity, which includes the Task ID, and store it in a variable (e.g., taskID).
Get Transaction Data:
In this phase, you don’t need to perform any specific actions, as you have already prepared the data in the initialization phase.
Use the Wait for Form Task activity and pass the taskID variable as the input.
This activity will pause the execution of the workflow until a decision is made in the Orchestrator Action Center for the corresponding PDF.
Once a decision is made, the workflow will resume automatically, and the output of the Wait for Form Task activity will be stored in a variable (e.g., formTaskOutput).
Based on the decision made in the Orchestrator Action Center, you can check the value of formTaskOutput and determine if the PDF was approved or rejected.
If the PDF was approved, you can proceed with moving or sending the approved PDF to the customer.
If the PDF was rejected, you can ignore it and move on to the next PDF.
Continue processing the remaining PDFs until all rows in the dtData DataTable have been processed
@Nitya1 Thanks for your reply. Here is a quick question.
If I use Create Form Task activity to create a task for each PDF within the foreach loop and display it in the Action Center then it will create taskID each time for the each pdf as output. Let say if we have 10 pdfs then loop will run 10 times and it will create 10 tasks in the action center and each time it will generate new taskID.
Later when we use the Wait for Form Task activity then are you saying to pass the taskID here which was generated last time?
then in this case it will take the reference of the last pdf. If user approves/rejects the rest of the previous pdf then how the Wait for Form Task activity will understand which job to resume?
To handle this situation, you need to ensure that you store and associate the task IDs of each PDF with their respective processing steps in your workflow. One way to achieve this is by using a dictionary or another suitable data structure to map the PDF file or some unique identifier to its corresponding task ID.
Then, when using the Wait for Form Task activity, you would need to pass the task ID associated with the PDF you are currently processing in the foreach loop. This ensures that the workflow waits for the specific task related to that PDF to be completed before moving on to the next iteration of the loop.
Let’s say if I’m processing 10 pdf at a time which will create 10 different task for user in orc Action Center.
10 different pdf will have 10 different task IDs so how to pass the 10 different task IDs to “Wait for Form Task and Resume” ?
I may have two options:
Pass the entire collection of task IDs but “Wait for Form Task and Resume” activity does not support passing an entire collection of task IDs as input.
One approach to handling multiple tasks would be to use a loop, such as a “For Each” loop, to iterate through the collection of task IDs. Inside the loop, you can use the “Wait for Form Task and Resume” activity and pass the current task ID as input. After each iteration, you can process the response and handle the approval or rejection accordingly.
But using a loop with the “Wait for Form Task and Resume” activity would cause the workflow to wait for each task individually, preventing further iterations.
And user may approve or reject one after another from orc Action Centre.
Edit: One other possibility is to use a Parallel For Each activity instead of a regular For Each. A Parallel For Each Activity with the Create From and Wait for Form Task and Resume activities inside would allow multiple tasks to be created from one job. As and when a task is completed, the same job will resume and be suspended again if there are other tasks still pending for that job. The job will only be completed once all tasks created from it have been completed.
Original post: What you actually need is one job to be triggered per PDF file, so that when a task is created in Action Center it can be traced back to one job only (as opposed to one job, multiple tasks).
Since you’re using REFramework, you can build a dispatcher bot and a performer bot plus an Orchestrator Queue. Build one robot to create a queue item for each PDF file that requires processing (e.g. a link or path to where the PDF file is located). Then have another robot that picks up one queue item, does the necessary processing, then creates the task and waits for it to complete. That way you can ensure that one PDF file = one job.
Else after create task a tivity get the task object and from that get the task id and add it to aseparate queue and create a separate process which uses get task data activity which will check for completion of tasks and if completed will process it
or I can keep simple for each loop for Create Form Task activity to create a task and collect the task id by doing add to collection and use a separate parallel for each activity where I can put “Wait for Form Task and Resume” activity to wait and resume the task by iterating the previously collected task id ?
This question is out of topic but it would be really great if you could answer it.
As I’m using RE framework so flow does not allow me to keep “Create Form Task activity” and "Wait for Form Task and Resume” in one single module which is other than Main.xml. So, do I need to keep “Create Form Task activity” in the process module and "Wait for Form Task and Resume” in the Main.xml module?
Hi the issue has been resolved. I have converted data table into the array . Now looping through array. Meanwhile i have downgraded my packages versions. It is working fine
Yes I am suggesting same…if you maintain different then parallely it would not wait anyways…so the same
Ideally re is not suited for it…but yes I believe it gives flexibility…that is the reason I proposed the aecond approach so it would fit ref as well. To answer your question…we have a long running workflow process template already…better use that…the approach for it shpuld be like this only…better have your ref process downlod keep and for long running processes alone you can have a process which can be triggered…little too much on design but would work flawlessly…else will be really problematicwitht he variables used
I have a process which I am planning to design the same way with two different processes.
Could you suggest based on my below scenario? Also, could you suggest how the long process fits for my scenario without waiting for the user approval in action center?
*My Scenario:
Processing input PDF files using DU. If all validations are good, Update in the application. For any validation failure, assign action item in Action center. Up on user validation and approval in Action center, I need to come back and update the application with corrected details.
*Solutions (Using REF):
Create 2 different processes as I don’t want the same process to create task in action center and wait for user approval and resume same process for next item as I am not sure how long it will take for the user approval, and I need my process to be executed for next interval of schedule (Scheduling an unattended BOT)
Validates and then created task in action center.
Up on user approval in action center, trigger another process to update the corrected details in the application.
Question:
How the second process will trigger once the task is approved in action center. Also, If there are multiple tasks approved simultaneously, how to handle trigger the process?
Anil_G
Quan.Mai
ashokkarale
sudster
Povilas_Jonikas
ijanszen1
Yoichi
dai_y
sven.wullum1
bhuvangates