During your automation you may encounter a “server busy” popup that will interrupt it.

In this blog post we will find out how to handle this popup properly.

This blog post will be cut in different parts :

• Symptom
• Origin
• Solution & Workaround

Symptom

• Workflow freeze : the process hang and nothing is processed after that
• The popup often cannot be closed
• Most of the time, Agent systray is not reacting anymore
• To stop the Agent, it is necessary to kill it
• Sometime the popup may disappear after a while (and then process resume)

Origin

This popup is triggered when

• The target application is fully occupied and cannot answer to Agent requests.
  • A long JavaScript is running on a web page
  • The page is downloading/uploading big set of data (downloading a file / searching data in backend / etc..)
  • The application is slow or on an undersized environment
  • …

AND

• The Agent try to perform an action on this same application in the same time (click() / refresh() / …)

Solution depends on the technical connector but basically, we need to be sure that the application is available before doing anything else.

In some cases, it is fully originated from the target application. It means that this popup could be triggered by simple manual action without any running Agent.

In that case, it is up to you to determine when this may happen, and how you avoid it manually. You will then have to mimic that in your workflow.

However, by experience, most of the time the popup will be triggered by the Agent itself (ctxtrun.exe), even it is related to your application unavailability.

The server busy popup should disappear after stopping/killing the Agent.

If it comes from the Agent, then there are 2 possible technical origin that need to be identified.

• SDK
  • The SDK will ask the technical connector to perform actions and will request for a feedback.
    • Custom Polling and polling on item (item.wait())
    • Click on element
    • Execscript
    • …
  • Technical connector
    • The connector, beside executing requests from the SDK (see above), will mostly request the status of handled application
      • LOAD, wait of pages
      • Polling on pages
      • Start of application
      • …

Reminder

In any case, it is essential that you identify the actions that may led to this popup. Most of the time, this popup will be steadily appearing on the same workflow steps.

Even if you request for help, we will ask you to provide such information.

We strongly advise you to use project traces to do so (see this article).

How to check that it is Connector wise:

• Identify the event that leads to the popup in your workflow, and all the surrounding actions, eventually using project traces (see this article).
  • A click on a button
  • The LOAD of a specific page
  • Call of a script on a page
  • Download of a file
  • …
• Launch the debugger without launching any workflow
• Manually replicate the action that would have been done by the workflow right before this popup appearance
• If nothing appears then this issue is not triggered by the connector itself
  • It means that the wait or LOAD on pages activities are not the one that trigger this popup.
  • It is safe to wait for those pages, and the probable cause of the issue should be related with requested actions from the agent.
• If the popup appears :
  • If the application is captured with UIAutomation technology, then see below in Solution & Workaround, connector wise sub part.
  • Otherwise, open an incident on CA-ML-IPA component. It will be a possible blocker.

How to check that it is SDK wise:

• Identify the event that leads to the popup in your workflow, and all the surrounding actions, eventually using project traces (see this article)
  • A click on a button
  • The LOAD of a specific page
  • Call of a script on a page
  • Download of a file
  • …
• Launch the debugger without launching any workflow
• Copy paste actions (specific action and surrounding ones) from the workflow that seems to lead to this issue
  • Get rid of every scenario activity (endStep, endScenario, return, data management …)
  • It will often look like a click on an item that lead to a page wait or LOAD handler, that leads to a specific action as other click or item polling or custom script execution.

In case of server busy popup, we identified multiple possible activities that leads to this, but it is not exhaustive, those are SDK activities. The SDK will expect a feedback from the technical Connector that may be hanging waiting for a feedback from the unavailable application :

• Custom polling on a page (ctx.polling)
• Item polling (app.page.myElement.wait)
• UIAutomation refresh()
• Web execscript

There are activities that will not request for such feedback and that should help finding a solution/workaround :

• Use the wait on a page as much as possible
  • Along must exist on item to avoid item polling (item.wait)
• UIAutomation lockRefresh / unlockRefresh to prevent application flooding by the connector

Solution & Workaround

Having an optimized application is very important in this case. Optimizing an application will reduce the cost of requesting application, page and item state.

That will then limit the pressure on potential complex application.

Note : best practices on recognition with UIAutomation is to avoid must exist / must not exist when possible. In this case we may have to use them because of the necessity to avoid polling on items. (ctx.polling / app.page.element.wait)

SDK wise

UIAutomation / Web Technology

Your page took long time to LOAD / is downloading or uploading data and you experience this issue when sending action to the page. This page potentially being not yet fully available or not loaded with complete data.

• Search for any element that will surely indicate full LOAD of your page
  • Title update
  • Pagination update
  • Item fully loaded
  • Item not grayed out anymore
  • Loading icon disappearance
  • …
• Declare it as a must exist on this page, with proper criteria indicating expected element state (ungrayed out, display none …)
• Waiting for the related page will also wait for this element without SDK polling.
  • Doing an item.wait is SDK request
  • Having a must exist on the same item is only Connector duty (then no feedback will be requested by the SDK > no server busy popup)

GUI Technology

Subpages

Subpage may provoke this issue. You need then to avoid having GUI subpages. If a GUI subpage is not recognized, then SAPGUI will freeze which will then leads to a server busy popup.

Must/exist (passive optimization)

Having too much must exist/must not exist elements will raise the cost of page recognition. It will have a direct impact on application availability and on the popup appearance. It is then advised to limit their number as much as possible.

GUI Active optimization

Despite getting rid of sub pages and having limited number of must exist & must not exist, you may still face the issue, and in that case, you will have to apply active optimization. This is done by the usage of specific activity & method in the workflow : setBusyWaitTime / resetBusyWaitTime AND lockRefresh / unlockRefresh

• setBusyWaitTime / resetBusyWaitTime

SAPGUI transaction may be occupied when loading pages or doing specific tasks. It is important to avoid performing an action while having a busy transaction. The Agent will always attempt to perform an action when the transaction is not busy. If the session is busy even after a declared timer, then a message session busy will appear.

Those 2 methods are used to Extend the Wait Period When the SAP Session is Busy.

The setBusyWaitTime method should be called in the first step of a workflow. Usually we use it on the page when handling the Easy Access page.

SAPLOGON.pEasyAccess.setBusyWaitTime(//Time in milliseconds);

By default, the Busy Wait time is 1 second (1000ms) and can be modified. All the sessions opened during your process will use that time to handle every action made to the SAP GUI pages.

Each action done by the connector will check regularly up to the timer if SAP GUI is busy or not.

Always use resetBusyWaitTime when you finish your workflow as a best practice.

• lockRefresh / UnlockRefresh

UIAutomation and SAPGUI technical connector are working with polling mechanism. They will regularly refresh the state of handled application from the Agent point of view as well as for its content. The refresh is made by requesting those state directly to the application (and potentially stressing it).

Those refreshes may take time to be processed, and the polling mechanism may flood the application.

When performing an action during a poll, server busy popup may occur.

There is no way to slow down the polling mechanism with GUI technology (unlike UIAutomation).

These 2 functions are used to stop the connector from refreshing the content of the page from Agent point of view. It will allow to have time to perform action while avoiding flooding handled application.

Use it inside a wait listener when you know that the page is properly loaded

app.page.wait(function(ev) {

app.page.lockRefresh();

// >>> perform actions <<<

app.page.unlockRefresh();

});

Don’t forget the UnlockRefresh at the end of the step because the connector won’t see the next events as new page arrival.

Note : Automatic polling may slow down every action made on a page, especially when this page cannot be optimized, has a lot of item, deep deepness and a lot of must exist /must not exist …

Connector Wise

UIAutomation

• If the popup is not raised by the SDK :
  • Try enclosing the page with lock and unlock refresh functions. Check if server busy error is not coming. (see how to do it above lockRefresh / UnlockRefresh)
  • When the server busy popup comes up, wait for a few seconds to see if the pop up goes away automatically and bot execution proceeds. In that case, it may not be a blocker.
  • Deactivate automatic polling
    • In the studio, go to the page > parameters > set refreshmode= no.

• • • This mode will prevent automatic refresh of the page. Even if the page is modified (new content, new items), those updates will not be automatically be seen
    • Call mainpage.refresh or page.refresh in the code update state of the application from Agent point of view whenever you expect update from the page