Robot setting the Queue item status as Success,As soon as killing the process from orchestrator

Learning Hub Academy Feedback
,
1

Hi All,

@Palaniyappan @Lahiru.Fernando @loginerror
As soon as killing the process in middle of the transaction/on going transaction item, Robot was setting the Queue item status as Success.

Any one know why the robot was setting the status as success? robot should not set the status as success?

Queue / Transaction items status should be keept it as - In-Progress right?

Best regards,
Naveen Chaganti

1 Like
2

Right. Can you double check?

3

Could you tell us more how exactly do you kill the process? Also, how the process looks like?

4

Hi @loginerror @badita

Thank you for the response.

Please find below are the steps for one of the process…but we are facing many of process same issue.

1.Login to Orchestrator
2.Trigger the process
3.As soon as login to the sap
4.Process will pick the new item from queue and it will change the status as In-progress
5…then Kill the process from orchestrator.
6.check the status of specific queue item

Note- If it is required i can show the demo also how it is happening via web-ex

Best Regards,
Naveen Chaganti

5

@ovi @Pablito

Could you please provide your thoughts on this issue.

6

Could you maybe post a screenshot of the process where it would normally change the Transaction Status to Success?

Could you then put a long Delay before this activity, then run the process from Orchestrator and kill it again?

1 Like
7

Hi @loginerror

Thank you for your response.

Do you mean in set transaction status under success case I have to add long delay?

There is no certain stage in process to share the screen shot, as soon as pickup new item from queue, we are trying to kill the process from orchestrator.

As soon as killing the process from orchestrator robot was setting the status as successful for specific queue item.

Best Regards,
Naveen Chaganti

8

I have to assume that you are using ReFramework? :slight_smile:

It would be nice to see the place in your workflow where the transaction would be set as Successful on a standard run.

1 Like
9

HI @loginerror

Yes, i am using RE framework.
in my case it will set the status as success under set transaction status state.

here my question is, we are killing the process while executing the process.xaml under process state from orchestrator,but we are not sure why the robot was going to set transaction status, it should stop in process state only as soon as killing the process.

Best Regards,
Naveen

10

This sounds like the exact behaviour of the Stop option instead of the Kill option:
image

The stop button on the left results in the behaviour where it finishes the transaction and stops.
The kill button on the right should indeed result in the transaction being left as In-Progress.

This is why I wanted you to debug it a bit and place a Delay activity with a long delay (>5min) just before the Set Transaction Status workflow and then kill it with the button on the right.

11

Hi @loginerror ,

We are having the same issue as @Naveen.ch describes:

Whenever REF goes into Process.xaml and the job is killed in Orchestrator, the Executor immediately exits Process.xaml, but continues to the Finally clause of the outer Try-Catch in Process Transaction in Main.

I’ve made a simple Worker that have a 5 minute delay in Process.
Whenever it is “working” and I kill it from Orchestrator, it triggers the outer Finally clause in Main. However, as neither SystemError nor BusinessRuleErorr are set, SetTransactionStatus.xaml marks the QueueItem as Successful.

However, if I ad a 5 minute delay in the Finally clause, the robot doesn’t make it to the invocation of SetTransactionStatus - it simply dies during the second delay (as it was supposed to do in Process.xaml).

We are on version 2018.4.1 both Studio, Orchestrator, and Robot.

Process.xaml:

process
process856×740 15.7 KB

Main.xaml:

main
main487×704 19.2 KB

Execution logs:
TestKillProcess with delay in main.txt (50.4 KB)
TestKillProcess without delay in main.txt (58.1 KB)

1 Like
13

Hi @MadsT

Thank you for your response.

As I am already aware about work around.

It should supposed to complete the transaction with in 5 minutes beacuse of workaround it will take 10 minutes.

I hope there is no sense using of delay to work the functionality as expected.

Uipath need to add the condition as ‘check signal’ in finally block before setting the status wheather process was killed or stopped.like get transaction before getting new item

Best Regards,
Naveen

14

I agree.
I guess another work around could be to have Process.xaml have a boolean out variable stating completion or not, which is then passed to SetTransactionStatus.xaml. SetTransactionStatus should determine if

  1. SystemError is thrown
  2. BusinessRuleException has occured
  3. The process completed successfully

and handle accordingly.

15

Hi everyone,

I dug a bit deeper and found the underlying cause. It has to do with how a running process handles the Kill command.

How it works:
• Whenever a process is sent the Kill command from Orchestrator, it first tries to Cancel the execution and if the execution is not finished in 3 seconds, the execution is killed.
• Whenever a process receives the Cancel command, it cancels the execution of the current activity and starts executing the Finally block for clean-up reasons .

This is what happens:

  • you click Kill process in Orchestrator
  • your process receives the command from Orchestrator
  • your process immediately cancels the current activity and goes to the Finally block to clean-up
  • the REFramework is currently programmed to set the transaction status within the Finally block → it sets it as Successful if neither BREception or Exception flags are true, which will always be the case when you kill the process
    As such, your transaction item is now marked as False

Ways to avoid it:

  • reprogram the ReFramework to set BREception and Exception transaction status from the Catch rather than Finally
  • (less ideal, but simple to implement) Add a 4 second delay at the beginning of the Finally → Note! This is not advised because it results in every transaction being delayed by 4 seconds.
3 Likes
17

Thank you so much for all this information!

I need more information about that point:

  • reprogram the ReFramework to set BREception and Exception transaction status from the Catch rather than Finally

What do you want to say with BREception?

Thanks!

18

BRE would be Business Rule Exception. These are treated a bit differently in the ReFramework than general Exceptions.