When using the SAP.ReadStatusbar activity, if your SAP session is disconnected, hangs or has a execution timeout (anything that keeps the gui scripting busy), the timeout will never be triggered so no system exception is triggered.
Whilst a rare combination of events, we have experienced this issue a few times in production. Our current workaround is to have a parallel process with a stopwatch running to kill the sap session after our maximum wait time has been reached. Once the SAP process has been killed, the selector will fail and trigger a system exception.
Would be great if this activity behaved as others do and stick to the timeouts.
Activity pack(s) used;
I too would like to know the answer to this! Causing huge headaches.
i also use a parallel process (with isolated property) to have a stopwatch on a separate thread handle this for now.
But i found an alternative which is directly use SAP GUI scripting (using vbscript) for some of the actions such as download that sometimes causes SAP to hang. Then i use uipath’s invoke vbscript activity that comes with a timeout property to call this script. Using this method, the timeout does trigger even if SAP is disconnected/hangs
Let me check what is going on here…
Stay tuned. I will be back
Best regards, Lev
Thanks for your feedback!
Can you please tell me which statement better describes your situation?
The activity (
SAP.ReadStatusBar or other, like a
Click which triggers a time-consuming operation in SAP) would succeed if you gave it enough time. But you still want it to fail, if it takes longer than a precise amount of time. Eg: the activity succeeds in 31 seconds, but you want it to fail if timeout is set to 30 seconds.
The activity has no chance to succeed, no matter how big the timeout is, due to some serious internal error in SAP, for instance. So, the SAP application hangs, this causes the UiPath Robot to also hang and you don’t like this. You would like the UiPath Robot to detect that the target application is unresponsive and throw an exception, instead of it staying also hanged.
Thanks for reaching out.
Generally scenario 2 best fits our scenario, however both scenarios can be true for us at different times.
For instance, scenario 1 would be the scenario if we had a 10 minute timeout specified for a vendor line search after which we would want this to fail. To succeed this search might take 1 hour or more, depending on the search required for the process and the size of the vendor account. (we have experienced a scenario where a search was active for 12+hours and still going)
Whereas scenario 2 would be more suitable for scenarios where SAP might disconnect unexpectedly or otherwise hang.
In both cases we would like the timeout property to be our control to specify how long an activity should wait. We can then simply specify how long to wait for a result, after which the exception trigger can be caught and handled as required for the specific process. However if it were possible to detect a fully unresponsive SAP session it would be ideal to have this throw an exception when it occurs rather than wait for the timeout.
Chris, the use cases that you described make perfect sense.
However, many other users don’t expect the timeout to be enforced at the expense of failing a workflow that could succeed, given a little more time. They see the timeout as a guard to prevent the robot from retrying to perform an activity indefinitely.
That’s why our current convention is to do one complete attempt to perform the activity, before checking the timeout. Then, if the attempt fails, the robot will keep retrying until the timeout expires.
For advanced RPA devs who want to enforce a hard timeout limit on activities, there are options like the one you use, or the one mentioned by Jack Chan, or others. So far, I did not encounter a use case related to timeouts that could not be addressed with the current set of activities. If you happen to run into such an use case, please let us know.
Also, for most scenarios, in order to properly handle an error condition signaled by an expired timeout, a custom sequence of activities is needed anyway (Eg. killing the
saplogon process), so having a hard limit enforced on the timeout is not a solution alone. Usually a complete solution is composed of a hard timeout limit, combined with other error handling logic.
This discussion is not very technical, it’s more about user experience and product design . I hope I gave you some background about why the timeout is not enforced precisely when it expires and why situations like the ones described by you should be addressed like you did, with custom handling.
We are continuing to encounter similar scenarios where any activity interacting with SAP does not obey the timeout.
As an example, we have a OnUiElementAppear activity with a 5 minute timeout (300000 ms), which left the job running for 8 days. On investigation we found that SAP had lost network connectivity in between executing the transaction and the result appearing on screen (around 20 seconds).
Without adding many hundreds of parallel steps to my process to loop checking for the disconnection error popup, how can this be handled?
May 14… Come on mate where you hiding?
The whole explanation was provided on 18th May by Iulian. Read it carefully.
Please use this solution, which should solve the “SAP Freezing/SAP Hanging” troubles:
Use Invoke Workflow with a timeout while executing it Isolated (it will run in a separate windows process). This timeout value would be the expected maximum workflow execution duration + extra time as buffer.
If sap freezes and the workflow invocation reaches the timeout you would have the exception thrown and you can handle it in your workflow as you desire.
So summary of solution:
Invoke Workflow File" with the “Isolated” property checked + Timeout property set
Best regards, Lev
Just so i understand clearly. This effectively means i need to redesign existing solutions that have this scenario since updating our product version? If so thats a major concern with the stability of your product and i’ll need to discuss with our account manager.
I am hearing a frustration in your message. Your statement is not fully right.
“SAP is hanging”, “SAP is having a network issues”, “SAP is freezing” and you are blaming “stability of UiPath Product” for it
Lets connect to discuss this further and let me see your case.
Best regards, Lev
I would have to agree with @cconnors here. I did not have an issue with “SAP hanging” until I updated UIPath to use the newest activities. All of my SAP bots that have not updated do not have the hanging issue…and if SAP does hang UIPath doesn’t hang and is able to kill the process and restart. I’m not sure what changed with the newest activities, but I feel like there may be a bug somewhere in them.
Please describe the issue as precise as possible. “Updated to the newest activity…”
From what to what? and what has happened?
It can be a bug! We are not perfect, but we are open and hearing to customer and community.
We just need to find the exact place and also in the best case to be able to reproduce the stuff.
Help me to find the root cause and I will make UiPath even better.
Thanks for your support @cconnors and @s3vn
Best regards, Lev
To clarify, I updated the packages to the newest versions. The issue started occurring after that change. Unfortunately I don’t think it is linked to a specific Activity because the bot/SAP was always hanging in the same area so I changed the Type Into activity to an SAP Call Transaction activity and the bot/SAP continued to hang in the same area. The workaround you suggested me (of invoking a workflow with Isolated checked) is working, but SAP/UIPath continues to hang.
Previous Package Versions:
Current Package Versions:
I tried rolling back a test project to your old package versions, but continued to see the same issue.
So far i’ve been able to determine that this issue is specific to the type of activity being attempted at the time of SAP being unavailable (due to either being busy executing or being disconnected). Click and Read Status Bar are the two common offenders.
I am having the issue with Type Into and Call Transaction activities. Mine was always occurring at the same spot in the process and changing the activity did not resolve the issue.
Hello @LevKushnir ,
Even I had faced a similar issue. I had not specified any timeout for the SAP “Read status bar” activity. So the default had to be 30 sec but I have seen instances where the activity was waiting for more than 30 minutes and still fetched the right results. This works well for a happy path scenario.
But when I have large data to process , SAP gives a memory or a restarted popup and goes into a hang state. In this scenario uipath doesn’t recognize the same and is still executing the “Read status bar” activity
Could you help me understand the below scenario:
- What is the maximum default timeout for the SAP “Read status bar” activity to eventually fail
- In case I am using a parallel activity as the solution , with Invoke workflow that has isolated property and timeout set as 30 min for the workflow that checks the memory popup. What would happen if the Read status bar gets a success status in like 2 minutes. Would the parallel block wait for 2 minutes or 30 min(timeout of the Invoke workflow that checks the SAP hang popups)
When you performing some activities in SAP, we (UiPath) are speaking to SAP API scripting interface and “asking” in which state it is. It can be Click, it can be Read Statusbar - does not matter.
In your happy path scenario above. SAP was busy and active, this is the reason, why we were waiting for 30 minutes to proceed. It can be 2 seconds or 60 minutes. The key point is: SAP is working / the session is busy / the element Statusbar is available on the screen.
Now to your questions
There is no timeout to fail for a good execution.
The question is too unclear and too much theoretical (would, would, would).
You are mixing and bringing too much different topics together: SAP Timeout, SAP Hanging, Parallel Execution, Invoke Workflows.
If you want to discuss in detail, please create a new thread and lets starts with proper definition of what’s expected from the robot.
Then we can have a clear discussion and clear answers
Best regards, Lev