Skip to main content
Cadet | Tier 2
August 25, 2026

SAP GUI Automatic Mode Connection Failure -- The Log Off problem and How to Fix It

  • August 25, 2026
  • 0 replies
  • 3 views

(NOTE: Scroll Down to find the fixes)

Problem: An AARI Process has multiple Bots that work with SAP. Connection with SAP is established in 1 Bot, and subsequent Bots use that connection using the Automatic Mode of the SAP Connect Action.

The Process runs as intended if you’re logged into the running device, but fails if you’re not logged in, even if no other parameters are changed. The error message is “SAP connection error. Log in using the SAP GUI and try again”. Crucially, this error only happens in the subsequent bots that Connect to SAP in Automatic mode, and not in any bot that Connects in SAP GUI mode.


Issue (diagnosed with help from Claude):
 SAP GUI's Automatic connect works by looking up a COM object (“SAPGUI”) in Windows' Running Object Table (ROT), which is scoped per Windows Terminal Services session — a process in one session can't see an object registered by a process in a different session. 
AARI’s Auto Login feature, used for unattended execution, logs the device in when a bot needs to run and then restores the device to its original state afterward. If that original state is "logged off," each separate bot deployment triggers its own fresh Auto Login cycle, which in turn means each deployment can end up running in a different Windows session. So, the bot that opened SAP GUI (session A) and the next bot trying to attach to it (session B) end up in two different sessions, with the SAPGUI entry in 1st Session’s ROT being invisible to the Bot in the 2nd Session. So, SAP Connection Error.


(NOTE: The 1st fix is quicker than the pinpointing imo, so its probably better to try and test that anyway. This part is only to be sure this is your issue.)
Issue Pinpointing (created with help from Claude): Add & Run the following Python Script at the start using Python Script → Execute function action, in both SAP GUI mode bot and subsequent Automatic mode bot that is meant to be using that Connection:

def get_true_session_id():
import ctypes
kernel32 = ctypes.windll.kernel32
pid = kernel32.GetCurrentProcessId()
session_id = ctypes.c_ulong()
kernel32.ProcessIdToSessionId(pid, ctypes.byref(session_id))
return f"SessionID={session_id.value}"

 Add an identifier in the return statement to correspond to which bot is running the script,
e.g. change the Return statement to

return f"CONNECTOR: SessionID={session_id.value}"

in the SAP GUI mode bot, and to

return f"USER: SessionID={session_id.value}"

in the subsequent Automatic mode bot.

Store the outputs in a variable, and log them to a common file using the Log to file action. Ensure that the log action happens before the actual connect action, so that errors don’t interrupt the logging.

Now run the process again, once when an user is logged in to the device, and once when they are not. If the SessionID is same for logged in case and different for not logged in case, then the issue is almost certainly the one mentioned above (according to Claude anyway).

 

Fixes: 
1) (this is what solved the issue in my case, was not suggested by Claude, hence the post): From the Control Room Admin, go to Manage → Devices → <running_device> → “…” → Edit Device → Auto Login tab. In the Settings below, change any that has the Log off setting selected to any of the other two (depending on your requirements).
If the options are not editable from Control Room Admin, go to Administration → Settings → Devices → Auto logon settings, and either change the options from there (would affect all devices), or set “Allow a user to change these settings individually for each device in Devices” to Allow changes, and then edit the device options as mentioned before.

2): If you’re not allowed to change the aforementioned settings, or that does not resolve the issue, the best fix that was also suggested by Claude is to have either all the SAP Actions in the same bot, or freshly Connect (and Disconnect) in every bot. Its not an elegant fix, but it should work in all cases since it bypasses the error source itself.

Please feel free to add any corrections or relevant additions/fixes in the comments.