Wait For Form and Resume Error in VM

[Kyleb91 (Kyle Brown)]

Hi All,

I’m aware of the issue in UiPath with Action center and having the Wait For Task and Resume Activity needing to be in the Main of a process file in order to work effectively, but running my process in a virtual machine I am getting one of two errors.

If I place it where I feel it should work, in Main, below Process I am getting a successful Create Form, but then fails as soon as it hits the Wait task with the following:

Type ‘System.__ComObject’ cannot be serialized. Consider marking it with the DataContractAttribute attribute, and marking all of its members you want serialized with the DataMemberAttribute attribute. If the type is a collection, consider marking it with the CollectionDataContractAttribute. See the Microsoft .NET Framework documentation for other supported types.

RemoteException wrapping System.Runtime.Serialization.InvalidDataContractException: Type ‘System.__ComObject’ cannot be serialized. Consider marking it with the DataContractAttribute attribute, and marking all of its members you want serialized with the DataMemberAttribute attribute. If the type is a collection, consider marking it with the CollectionDataContractAttribute. See the Microsoft .NET Framework documentation for other supported types.
at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result)
at System.Activities.WorkflowApplication.IdleEventHandler.OnStage2Complete(IAsyncResult lastResult, WorkflowApplication instance, Boolean isStillSync)
at System.Activities.WorkflowApplication.EventFrame(IAsyncResult result)

If I try Invoke it here, I get the following error:

An extension of type ‘UiPath.Activities.Contracts.Persistence.IPersistenceBookmarks’ must be configured in order to run this workflow.

I will mention I have ‘Supports Persistence’ Ticked in settings.

I have tried creating a new test workflow with the Wait for Form Task and Resume activity in the VM, and this works fine…

Any help please!!

[Jon_Smith]

Its not an issue that the action centre stuff must be on the entry point. That is the design and is required to make the serialization and deserialization work effectively.

To give further explanation on that, the point in the code is basically marked down, I believe the term is called a bookmark, and then all the variables currently in memory are serialized and all this data is passed to and stored in the orchestrator.

When the job resumes, the process is started from the bookmark and all the variables etc are deserialized again.

So, in order to work every variable currently in scope when you bookmark/suspend the job must be serializable. COM objects I dont think can be serializable because of their nature, so the message is logical. There are other objects that also cause problems, for example if you have a JObject you’ll get a slightly different error about recursive loops or something I think as JObjects cannot be serialized, cause they already are…

What variables do you have in memory when you suspend the job? Clean that up and you can fix it.

Forget trying to run it from an invoke, it is not supported and for good reason I think.

[Kyleb91 (Kyle Brown)]

Hey! Thanks!

Yes I think you’re right, I’m unsure about how you mean to clean up the VARs, how would I know which ones to do so, I have another workflow for reference, and doesn’t seem anything untoward, just strings, a couple Timespans, and the General Business process ones.

Interestingly when I run the analyze on file button, it gives me the following:

Error ST-DBP-025 Variables Serialization Prerequisite Non-serializable variable ‘TransactionItem’ in activity ‘General Business Process’ present in scope of persistence activity ‘Wait for Form Task and Resume’. Main.xaml
Recommendation
Consider using a serializable data type or move its usage to a different scope. Learn more.

Although, I have this in m,y Testing process and this is there also… but works…

[supermanPunch (Arpan)]

Hi @Kyleb91 ,

You could Check the below Documentation for types which are serializable and accepted by the Wait and Resume Activities :

Orchestration Process

[Jon_Smith]

Hey Kyle,

No worries. I hope its helped you gain some insight. I spoke to the devs involved in making this functionality as I have found some genuine bugs/issues and despite those things its genuinely very impressive functionality and gives you alot of options.
(The last thing I was discussing with them are retry scopes. You need to avoid retry scopes on your Main.xaml if you have it suspend.

Regarding ‘cleaning up your variables’. So variables have a scope right, at some point when your process suspends there are certain variables in scope. If you put a break point in your workflow and run it, when it breaks you can examine what values all the currently in scope variables have. Equally you can click on activity and see what variables are in scope in the variables pane.

What I am saying is, when you suspend your workflow, there are variables in scope that are not serializable. Can you start with perhaps clicking on your suspend activity and then giving us a screenshot of the variables in scope and the workflow arguments (as they are in scope on the entire workflow).

[Kyleb91 (Kyle Brown)]

Thanks man, there was a Browser type VAR causing issue! Thanks!

[Jon_Smith]

Spot on, that will make sense as an object that cannot be serialized and reserialized, especially since the job may resume on an entirely different machine so the browser cannot be ‘handed over’.