Loading ...
Sorry, an error occurred while loading the content.

Re: RE: [LoadRunner] Problems correlating LoadRunner scripts with PeopleSoft 7 - 3tier

Expand Messages
  • Capt.M.Togher
    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
    Message 1 of 3 , Mar 1 9:51 PM
    • 0 Attachment
      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,
      Mark Togher
      Department of National Defence
      613-995-0679

      On Sat, 26 Feb 2000 23:02:28 -0500, "Tim Nichols" <tnichols2@...> wrote:
      > From: "Tim Nichols" <tnichols2@...>
      >
      > Hi...
      >
      > 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
      > 904-234-8917
      >
      >
      > ------------------------------------------------------------------------
      > One email address - many people!
      > Start a free email group on eGroups!
      > http://click.egroups.com/1/1887/5/_/459799/_/951624184/
      > ------------------------------------------------------------------------
      >
      >
      >
    • Andrew McFarlane
      Just a general thing that I do when the correlations are difficult to find... Create a WinRunner script to exercise the front end. Let WinRunner drive the
      Message 2 of 3 , Mar 2 4:00 AM
      • 0 Attachment
        Just a general thing that I do when the correlations are difficult to
        find...

        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.

        Andrew McFarlane
        Welkin Consulting, Inc.
        welkin_inc@...
        ______________________________________________________
        Get Your Private, Free Email at http://www.hotmail.com
      • Tim Nichols
        Hi Mark, ... This is exactly correct. Tuxedo is verifying the updater of the row is the holder of the updated row. Thanks for saving me from having to
        Message 3 of 3 , Mar 2 6:42 AM
        • 0 Attachment
          Hi Mark,



          > 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.

          This is exactly correct. Tuxedo is verifying the updater of the row is the
          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,
          > 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!
          >

          FYI...PeopleSoft use Mercury products to test their own products. I've
          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!

          Tim Nichols
          CorTechs, Inc.
          904-234-8917
        Your message has been successfully submitted and would be delivered to recipients shortly.