Process flow: In RE framework iterating through email attached pdfs > Extraction using DU > Creating action center task for all pdfs using ‘Create Document Validation Action’ > At the end wait for all task to approve using ‘Wait For Document Validation Action and Resume’ > Update latest data into excel.
Here, I am using ‘Create Document Validation Action’ in invoked workflow inside process state. After collecting all Action Objects in End state using ‘Wait For Document Validation Action and Resume’ waiting and fetching latest data.
You are using non serializable datatype variable which is resulting in this error.
All variables used in the scope of a long-running activity must be serializable. Types of variables listed in this page are serializable: Text, True or False, Number, Array, Date and Time. Data Table and GenericValue variables.
Refer these best practices to avoid these kind of errors:
Transactional processes are not fit for human in the loop as it suspends the process and blocks the next transaction from starting. You should look into Orchestration Process as linked above.
As mentioned above, a Transactional process is not fit for a human in the loop and persistence. You should have a linear process instead and run multiple of those, the REFramework doesn’t support this.
The serialization error is because of the data type specified however, you must have a variable or something in scope using that class, which cannot be serialized it looks like you have a very large number of variables so you’ll need to go through yourself abit.
Please listen to @Jon_Smith, REFramework is not suitable for use with Persistence (ie wait for action and resume).
You should have something like this architecture:
Dispatcher: looping (could be REFramework) automation that picks up the items to be processed, puts them somewhere, and then creates a queue item
Performer: top down automation that picks up the queue item, creates the Action and then waits
This performer would be on a queue trigger that allows for creation of multiple jobs, and the result is you have multiple jobs - one job for each queue item - suspended while waiting for the Actions to be completed
Once the Action is completed this performer should do the rest of your process, including marking the queue item success/fail etc.
Again, the performer needs to be top down and just process ONE item, not a looping automation that processes multiple items.
@Jon_Smith, @postwick our solution is build in RE framework. Due to architecture of solution planning, we haven’t used Orchestrator features in our logic other than scheduling the BOT. As @Anil_G & @ashokkarale mentioned the core concept of long-running activities, I tried with different approach to develop the solution without much changes in already developed code.
I customized the RE framework logic. Everything I shifted from End state ( where we had covered waiting and fetching updated data from AC ) to newly added parent scope in sequential order after RE Framework. All unnecessary variables scope set till RE Framework only. In following sequence we covered the logic to wait for all Action Center task & updated excel output. All variables scope limited to child sequence to void any issue for long-running activity.
I urge you to reconsider.
Mixing long running workflows in a transactional process is just a bad idea and leaves alot of risk for things going badly wrong.
I will give you some examples based on hypotheticals.
Lets say you process all the items in the queue, and then separately you wait for all of these items on the main.
You either do this in a sequential loop or a parallel one.
If sequential then you are bottlenecked by the first task you are waiting for. If that takes say 3 days to complete then another 50 tasks behind it are stuck as the loop is sequential.
If your loop is parallel then you risk getting bad responses from the Orchestrator that will crash your process. If you are waiting for say 50 tasks in parallel then any time a single task is completed the job will wake up, but all 50 threads will be resumed and check the status of the task they wait for, when the robot makes 50 api calls at once to the Orch you reject them being rejected as a DDOS style attack. When this happens your performer will crash and you’ll lose the tracking of all 50 tasks causing huge cleanup efforts.
Another hypothetical is also based on an item crashing the entire code, a simple logic error can do this, if you make a mistake and the performer crashes due to one bad task then you’ll again lose everything else the job was tracking.
Its a terrible idea to package human in the loop within a transaction process, making the performer track multiple queue items is a nightmare. Don’t do it. There are much better ways of dealing with this. The REFramework shouldnt be twisted and mutated to try to fit every type of business process, its already an outdated template and is good at one thing, transactional processing. It does not support human in the loop, use a different process type.
Totally agree with you, @Jon_Smith. What I did was a trial to identify the root cause of the error. It was found, as @Anil_G and @ashokkarale mentioned, to be the usage of a non-serializable datatype variable.
The best solution is to create an orchestration process with two dispatchers and a queue-triggered performer:
D1: Extract and create Action Center task
D2: Wait for and get the approved Action Center data
P: Use the latest data and perform further steps.
Feel free to suggest if any additional improvements can be made to the model above.
@Yoichi, @kishan.savaliya, @Jayesh_678.
