Invoke OpenRPA - Overload existing arguments with payload object

Hi all, this will be my first post, so please bear with me.
I want to know if it is possible to use the activity “Invoke OpenRPA” and give it a payload object as an argument that overloads the existing arguments of the invoked flow. I know this is possible using “Invoke Remote OpenRPA” but I am not able to use this approach, as this requires the robot to not be busy, and since I only want to invoke another flow from the same robot it will be busy running the flow that is essentially invoking the other flow in the first place.

output

Video (expires in 2 days)

When I invoke the workflow, I give it the payload from the Workitem as argument since I want these variables to overload the existing arguments in that specific workflow, but I am only able to do this with the remote invoke, but this will just deadlock as it is invoked from the same PC.

I’m so sorry, but I really don’t understand what the questions and/or issue is ?
What do you mean by overload variables ?

Thank you for the quick response.

To clarify, when I invoke a flow with the “Invoke OpenRPA” activity, I want to overwrite the values of the existing arguments of the invoked flow. In the activity, I provide the payload object with a new mapping of the arguments.

My goal is to overwrite the values of the existing arguments in the invoked flow using the payload with the mapping.

I can achieve this with the “Invoke Remote OpenRPA” activity, but not with the “Invoke OpenRPA”. It confuses me why the behavior differs between the two, as the only apparent difference is that the remote activity allows the flow to run on a different robot.

I have included a link to a video illustrating the different behaviors regarding the payload and arguments.

If directly using “Invoke OpenRPA” is not possible, I wonder if there is another way to assign all the arguments in a flow based on a mapping from a payload.

I hope this makes more sense now

I REALLY do not understand ?
what do you mean override ? you have UI where you can map all the arguments you want, and you set them to whatever you want ?

Maybe if i explain a bit more in details it would make sense

I am trying to invoke a flow containing these arguments:

I want to assign each values based on a payload (currentWI.payload):

The Flow:

I am aware that in the argument field of “invoke OpenRPA” i can just set the arguments for each the existing arguments in the flow, but i need them to be set dynamically using an object (currentWI.payload)

when i invoke the flow using “Invoke Remote OpenRPA” it works as expected and the flow has all the argument values based on currentWI.payload, but i cannot use this approach as this will just deadlock when i want to invoke a flow while the robot is already running.

The reason i want to do this is because. I want to add workitems to the “Dispatch_Master” from NodeRED, from which i manually configure what flow to run by adding an argument to the payload “argWorkflowPath” which is used to decide what flow to invoke from the Dispatch_Master flow.

This means that the arguments that will be provided in the “invoke openRPA” activity will be abitrary and to achieve this i give the whole payload object as argument.

In the video example i am trying to invoke this flow:

I hope this helped clarifying things a bit

Thank you for your patience

then send the payload and not each individual property on the payload.
then you can grab whatever you need of the payload inside the workflow’s.

I might be wrong, I’m simply “putting words in to your mouth” here, so please correct me if I’m wrong.
you want to have X amount of workflows, that all takes different amount of arguments.
you want ONE single workflow to call the “right” workflow depending on some logic, and then send the correct arguments. The values on there arguments exists as properties on a payload on a workitem, so you call the main workflow multiple times ( or it loops ) for each work item.

nothing wrong here, perfectly fine setup.
You must then update the main workflow to check what workflow is called and then call it with the correct arguments. ie, you must have multiple invoke openrpa inside an if/switch like statement corresponding to each workflow.
If you insist on using a single invoke openrpa using workflow as an variable, then you must also streamline the arguments. In most cases you would simply send the workitem to the workflow and it can then “take what it needs”.

I completely ignored the point you made about Invoke Remote OpenRPA. I did that deliberately, because it was leading you down a wrong path.

  • Invoke OpenRPA calls the workflow directly. ie. arguments are not serialized, and therefore also uses less memory ( and you can send any object, even non-serializable objects ).
  • Invoke Remote OpenRPA sends the request to openflow ( serializing the arguments ) and it then sends the request to the correct robot ( normally a remote one, but you can call yourself too, if you want )

So invoke remote OpenRPA will require more ram, it will send the data over the network, it will only work if you have a working connection to openflow ( ie, it can stall and never return if there is an network outage )

When you call Invoke OpenRPA or Invoke Remote OpenRPA it can work in one of two modes.

  • The “old” mode that is a bad practise, is to not define any arguments in the UI. This will make openrpa take all variables in your workflow and send them as arguments to the workflow you are calling ( and this will then reject anyone’s that does not match by name )
  • Or you can define a mapping between each argument to a variable or constant in the UI and then openrpa will only send that.

I suspect you had the arguments needed declared as variables in the main workflow, when testing Invoke Remote OpenRPA and had not mapped the arguments, and that is why you think it was overriding them ? ( or you found a bug … either way I don’t think using Invoke Remote OpenRPA is the right approach here )
If you still want to use Invoke Remote OpenRPA set the workflows you call as “background” workflows ( a checkmark when you select it under openflow tab ) or ( and i do not recommend this ) you can increase the number of allowed remote run workflows to more than 1, in settings.json

1 Like

Thank you for this amazing in depth feedback

You got it, this is exactly the behaviour i want to implement.

I was hoping it was possible to invoke a flow in the same way i do in NodeRED like this:

To avoid having to map all the arguments manually in each workflow.

But i now see that the activities differs a lot more than i initially thought

I just thought that since i am able to use the “Invoke Remote OpenRPA” and see the arguments be overridden in the invoked flow that i could achieve the same with “Invoke OpenRPA”

Is there a way that i can from within the invoked flow, map all its arguments to the payload (the one that is given in the “Invoke OpenRPA” <currentWI.payload>)

eg. using “invoke code” Is there a function in the openRPA library that lets me set the arguments for the “workflow_instance” based on a payload similar to how the msg.payload in NodeRED overrides the arguments?

Or is the only way, to map the variables used within the workflow based on the argument object “currentWI.payload”?

No, sorry. ( i do that internally, but it will take forever for me to rewrite and expose that argument’s array list ) so if this is something you really need, you need to do a round trip to a NodeRED or agent.
And I personally believe that is a wrong route to take, then just send the payload directly to each workflow and get the properties from that.

Alright, makes sense. Thank you for the quick responses and clarification

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.