SAP GUI Load Generators issue

458 views
Skip to first unread message

Ltester

unread,
Dec 13, 2009, 8:23:02 PM12/13/09
to LoadRunner
I created scripts using SAP GUI protocol and i have been doing this
for years now so no problems with the scripting part.
the issue i am facing is when i run the scripts from the controller. i
have 20v
Load Generators that i can access remotely. sometimes it works and
the scripts run just fine and many many times, it gives me the below
errors

vuser_init.c(21): Error: Failed to find SapGui component by ID
"sbar"15
vuser_init.c(21): Error: Failed to open new connection to server "SCE
- X02 - ECC"
2-79952 vuser_init.c(21): Error: Failed to get active window
2-79946 vuser_init.c(21): Error: Failed to get the status bar text

any idea?

Thanks

James Pulley

unread,
Dec 14, 2009, 1:33:02 PM12/14/09
to lr-loa...@googlegroups.com
You cannot connect from this user, 'Failed to open new connection to server
"SCE
- X02 - ECC"'. Examine your SAP application server logs
--
You received this message because you are subscribed to the Google
"LoadRunner" group.
To post to this group, send email to LR-Loa...@googlegroups.com To
unsubscribe from this group, send email to
LR-LoadRunne...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/LR-LoadRunner?hl=en

Rams

unread,
Dec 17, 2009, 6:16:46 AM12/17/09
to LoadRunner
Hi,

vuser_init.c(21): Error: Failed to find SapGui component by ID

"sbar"15 --

The above error you will get if the SAPGUI logon pad does not contain
the required connection portal (Update your SAPLOGON.ini file),
Add or modify required connection details and try.

Regards,
Rams


On Dec 14, 11:33 pm, "James Pulley" <jpul...@itestsolutions.com>
wrote:

> For more options, visit this group athttp://groups.google.com/group/LR-LoadRunner?hl=en- Hide quoted text -
>
> - Show quoted text -

Ltester

unread,
Dec 18, 2009, 12:04:23 AM12/18/09
to LoadRunner
I found the solution, we previously have standardized all of the .ini
files and the SAPMSG.ini as well and we added the proper entries into
the services file too.

the solution was to disable "Extended logging" in the run time
settings; although it is not my best solution as i would like to track
and include checkpoints in the scripts, but thats the only solution
that we tried and worked. not sure why?!

Thanks

> > For more options, visit this group athttp://groups.google.com/group/LR-LoadRunner?hl=en-Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -

Floris Kraak

unread,
Dec 18, 2009, 2:48:35 AM12/18/09
to lr-loa...@googlegroups.com
On Fri, Dec 18, 2009 at 6:04 AM, Ltester <azar...@gmail.com> wrote:
>
> the solution was to disable "Extended logging" in the run time
> settings; although it is not my best solution as i would like to track
> and include checkpoints in the scripts, but thats the only solution
> that we tried and worked. not sure why?!
>

Adding checkpoints for each step to see if the step actually was
successful and responded with something that you expect to see is very
important if you want to have a script that reports errors properly,
as I'm sure you are aware.

You could just use code to selectively re-enable extended logging for
the step you wish to examine only.

As an example, here's a bit of code from my
hopefully-soon-to-be-announced (yay!) open source loadrunner
libraries:

---
int _logLevel = LR_MSG_CLASS_DISABLE_LOG; // previous loglevel for use
with log toggle functions.

// .. more code

void y_log_set_extended()
{
lr_log_message("Log level set to EXTENDED.\n");

// Save the previous loglevel.
_logLevel = lr_get_debug_message();

lr_set_debug_message(LR_MSG_CLASS_DISABLE_LOG, LR_SWITCH_OFF);
lr_set_debug_message(
LR_MSG_CLASS_EXTENDED_LOG | LR_MSG_CLASS_RESULT_DATA |
LR_MSG_CLASS_PARAMETERS | LR_MSG_CLASS_FULL_TRACE,
LR_SWITCH_ON);
}

// Restore the log level to the old state.
y_log_restore()
{
/*
if(_logLevel == LR_MSG_CLASS_DISABLE_LOG)
{
lr_log_message("Warning: Restoring the previous loglevel will
turn logging OFF.\n");
// If the current loglevel is off as well nobody can hear this scream ..
}
*/
lr_set_debug_message(_logLevel, LR_SWITCH_ON);
lr_log_message("Log level restored to the previous state.\n");
// Of course if the previous state was "OFF" the user will never
see this either ;-)

}
---


Or alternatively, do things the hard way and look at the HTML using
the View Source option in your browser.


Regards,
Floris
---
'What does it mean to say that one is 48% slower? That's like saying
that a squirrel is 48% juicier than an orange - maybe it's true, but
anybody who puts the two in a blender to compare them is kind of
sick.'
--- Linus Torvalds

Floris Kraak

unread,
Dec 18, 2009, 2:55:25 AM12/18/09
to lr-loa...@googlegroups.com
On Fri, Dec 18, 2009 at 8:48 AM, Floris Kraak <rand...@gmail.com> wrote:
> On Fri, Dec 18, 2009 at 6:04 AM, Ltester <azar...@gmail.com> wrote:
>
> As an example, here's a bit of code from my
> hopefully-soon-to-be-announced (yay!) open source loadrunner
> libraries:

Oh, and btw: That bit of code is licensed under the GPL v2. So behave :P

James Pulley

unread,
Dec 18, 2009, 6:35:45 AM12/18/09
to lr-loa...@googlegroups.com
Because your logging became as a drag anchor and slowed your users so much that they timed out... Which is why such log levels are not recommended during the execution of a performance test

Floris Kraak

unread,
Dec 18, 2009, 7:23:24 AM12/18/09
to lr-loa...@googlegroups.com
On Fri, Dec 18, 2009 at 12:35 PM, James Pulley
<jpu...@itestsolutions.com> wrote:
> Because your logging became as a drag anchor and slowed your users so much that they timed out...
> Which is why such log levels are not recommended during the execution of a performance test

Hmn, how did I miss that little detail?
Ah right, because it's such a basic thing for me that I don't expect
others to do that either ;-)

Reply all
Reply to author
Forward
0 new messages