Re: RE: [LoadRunner] Problems correlating LoadRunner scripts with PeopleSoft 7 - 3tier
- Sorry about the delay, things have been busy.
For info, we're running PeopleSoft on Oracle 7.3.3 on a Digital UNIX box. The clients are configured to run off a Tuxedo application server co-hosted on the database server (logical 3-tier).
I do use the lrt_save_searched_string function, but in some of our scripts (different business processes) it's very tough to find out what to correlate. I know how it's supposed to be done (recording twice with different data, etc) but when it comes time to do a compare (eg. via WDiff) there is enormous amounts of differences.
I'll try to explain an example... We've simplified a script to do nothing other than bring up an employee's leave history, insert a new record, save, and exit. The script will play back fine against the original user (provided the database is set to original state beforehand). However, if the original user's leave history is different (ie. one more/less/different record exists) the script will no longer run. When looking at the tux buffers, it appears that the employee's history is retrieved early on in the script. Fine. Later, however, it appears to be sent back to the appserver (in a sbuf) at the end of the script (on the SAVE I presume). This leads me to believe that there is some verification happening with the leave history even though I'm just inserting one new record. If so, that's fine. But how do I correlate the leave history data that will be retrieved during the script when the amount of historical data will differ from user to user - that this script is int!
ended to run against?
Am I way off on this? Merc Int tech support are sure, as am I, that some correlation needs to be done, but so far have been little help in this regard. If you're familiar with what I just finished ranting about, and might have some suggestions I'm all ears!
Thanks for your time,
Department of National Defence
On Sat, 26 Feb 2000 23:02:28 -0500, "Tim Nichols" <tnichols2@...> wrote:
> From: "Tim Nichols" <tnichols2@...>
> You are working with PeopleSoft via Tuxedo, yes?
> As you have no doubt seen, this is not a simple case of pointing, clicking
> and correlating!
> You are using the lrt_save_searched_string function, correct?
> Let us know your environment before I go off down a long and winding
> soliloquy about Tuxedo/PeopleSoft...
> Tim Nichols
> CorTechs, Inc
> One email address - many people!
> Start a free email group on eGroups!
- Just a general thing that I do when the correlations are difficult to
Create a WinRunner script to exercise the front end. Let WinRunner drive
the front end while WinRunner records the database calls. Then, change
something, such as the login name, in your WinRunner script, then re-run the
WinRunner script while recording the database calls again. Use the wdiff
tool to examine the differences between the two virtual user scripts. This
will help you with figuring out what to correlate.
Just as an aside, I asked tech support to consider integrating WinRunner and
LoadRunner more tightly such that one could have the WinRunner TSL code that
corresponds to a control activation (i.e. button_press, edit_set,
menu_select_item ) be placed as a comment into the DB vuser code so that you
could see which GUI action produced which database call. They thought that
this was an *interesting* idea, which I take to mean that they don't get
enough requests for this and they probably won't do it.
Welkin Consulting, Inc.
Get Your Private, Free Email at http://www.hotmail.com
- Hi Mark,
> early on in the script. Fine. Later, however, it appears to beThis is exactly correct. Tuxedo is verifying the updater of the row is the
> sent back to the appserver (in a sbuf) at the end of the script
> (on the SAVE I presume). This leads me to believe that there is
> some verification happening with the leave history even though
> I'm just inserting one new record.
holder of the updated row. Thanks for saving me from having to explain it!
In your case where you are working with historical data you would have a
large amount of fields to correlate. I've had good experiences in other
Tuxedo environments where I get the developers involved to the extent that
they provide me with the row layout information so that I know or better
understand the data with which I'm dealing.
> Am I way off on this? Merc Int tech support are sure, as am I,FYI...PeopleSoft use Mercury products to test their own products. I've
> that some correlation needs to be done, but so far have been
> little help in this regard. If you're familiar with what I just
> finished ranting about, and might have some suggestions I'm all ears!
noticed in the past they have include some sample scripts in their
production distribution. I might suggest calling your PS support rep and
asking them if they have any shortcuts they've gleaned from their experience
with testing their own product.
Unless they have alternatives that we don't know about, you might consider
creating a modified version of your database that has the same historical
data for all the employee data so that you only have to deal with the
columns that you want to change.
Good luck, sir!