Skip to Content

Clear the fog – understand windowID parameter in Portal URLs…

   If you are running automated tests for the portal you may have noticed the parameters we pass inside the URLs. It is good to know that we don’t add them just to make the URLs as cryptic as possible (we reserve the right to do so in future versions :)) but we have a good use for it. One such case is the windowID parameter.  This is how the parameter looks like in its natural habitat – the inner page URL:  …/*windowId=WID1209300705273*…   windowID parameter in portal innerPage URL
You must be Logged on to comment or reply to a post.
  • Hey Yoni,

    Thanks for the blog.  I have a situation where I have recorded a script that accesses a WDA application from the Portal.  The ESID is being set and when I replay for a number of users the same ESID is being used.

    The consequence of course is that whilst each user is authenticating to the ERP 6.0 backend only the first user to authenticate is generating HTTP traffic as the same ESID is used by all users.  That is the same session in the ERP 6.0 system is always being used.

    When you say that the windowsID is used to calculate the ESID, can use your windowID substitution approach to ensure that an new ESID is generated for each logon?

    Do I need to remove the sap-ext-sid from the URLs or is there a similar substition process required?


    • Hi John,
      First thing first – thanks, it’s nice to hear the blog helps!

      The correct way to handle the sap-ext-sid post parameter is to build a LoadRunner correlation rule for it. I will just say that working with WD apps involves with many parameters that requires correlations, I hope in your case this would be enough but take into account that this may only one parameter in a long list. Also, it is not easy to define and work with correlations. I’m not sure what is your expertise with LR, I will try to describe the general process and if you need specifics just let me know.
      After you recorded/played your script, go to the “Generation Log” tab (usually below the main script view). Find there the first occurrence of your parameter (sap-ext-sid). You should see some html code there…
      Now click on the menu “Tools” -> “recording options” and choose “Correlation” from the tree on the left. Create a “New Application” which is like a package that will hold your correlation rules and then “New Rule” within it. Now you need to define your rule – in “Action” choose “search… all of the body text”, Left and Right boundaries are the full text before and after the value you want to replace (not the key, the sid value himself), and parameter prefix is usually the parameter key itself.
      Now make sure the “application” you created is marked as selected and regenerate the script, or record it again.
      If everything went ok you will see in the script that the value was changed with a parameter. From now on, each time you play the script, even with multiple users, the LR will be able to simulate the browser behavior for this parameter (each user will get a new sid for each application).
      One last thing, sometimes the LR doesn’t manage to identify the correlation and it requires additional “tweaking”.

      Hope I didn’t make it too complicated.


      • Hi Yoni,

        Your explaination is great and I hope to get a look at LR one day.  I am not using LR so I have had to settle for second best, well maybe tenth best.

        I have already used the information in your blog to generate an appropriate timestamp for the windowID.

        As you say, clearly a correlation rule in LR is the correct way to handle the ESID but I was wondering if you could provide more details on its actual generation.

        You have indicated a dependence on the widnowID in your blog, is the ESID post parameter also set by java script?

        Many Thanks

        • Hi John,

          Yeh, SAP spoiled me with resources so I sometimes forget the cost issue of LR. Luckily, it is the skills of the operator that counts more than the quality of the tool he uses :))

          There are two problems with the ESID parameter:
          1. It is generated differently for each application – WD, BSP, ITS etc have their own algorithm each for generating the ESID. The WID is one of the values used to generate it.
          2. The ESID value is generated on the server side and sent back to the client, in opposed to WID which is generated by JavaScript on the client side. This means you cannot create it with a script in your client and force the server to use the value you give it. I also don’t think it will be possible to predict the value and calculate it in parallel on the client side.

          At least, this is what I know of it – but I will be happy if someone could prove me wrong.

          I don’t know which tool you are using, but most tools have basic scripting options that you can use. It may require some expertise but it should be possible to capture the returned value and replace it on the fly for all user actions in your scenario, kind of the correlations LR provides.
          I remember that in Startup Company some time ago we used OpenSTA, it wasn’t easy at the beginning but later it proved to be very helpfull.


  • Hello Yoni,
    Your article is really informative. I was facing exactly the same issue and have followed the same steps. The windowid is getting captured. But when I am running say 10 iterations, my script is still failing some of the times. At tomes it is passing. Could u plesae elaborate more on getUniqueWindowId function. I could trace this function in the generation log of the script. Is the window Id always created using timestamp. This function implements some logic which I am not able to understand.Looking forward to ur inputs on this.
    • As far as I know, the WID is calculated as mentioned  – using a timestamp. The getUniqueWindowId() function is responsible for calculating this value but you override it in your script and supply your own WID value, because the URLs you use in the LR script are not dynamically created by the JS script.
      If during your scenario the same user opens more than one window things can get rather complicated and cause failures. You can check your scenario and look into the traces for the windowId values that were generated.

      Hope this helps, for more than that you may need WD expert.
      Thanks, Yoni