14 Replies Latest reply on Apr 8, 2014 9:59 AM by Andrew MacIntosh

    TM ART URL Checker for login prompts

    Andrew MacIntosh


      Is there a recommended approach to using the TMART URL Checker to monitor URL's which have a login prompt popup? I am seeing a lot of errors when using the URL Checker to monitor these URL's.

       

      Thanks,

        • 1. Re: TM ART URL Checker for login prompts
          Hal DeVore

          Unless you're doing a Browser-Driven monitor (the URL checker is not), then there is no popup when TM ART runs the script.

           

          What there is, however, is some form of authentication request.  This is easily handled in a Workbench script but the URL checker is not built to handle pages that require authentication.

           

          Record accessing your page with the Workbench, then examine the code.  What should happen is detection of the authentication will cause the Workbench to insert some commented-out code for setting authentication.  Workbench cannot capture your credentials so you must manually un-comment the code and insert credentials.

           

          --Hal

          • 2. Re: TM ART URL Checker for login prompts
            Hal DeVore

            Moved to TM ART discussion space

            • 3. Re: TM ART URL Checker for login prompts
              Liz Wiklund-Papadopulos

              Hi Andrew,

              I wanted to add something to Hal's comments.

              The URL checker is designed for ease of use and to quickly enable a user to measure the response time for a specified URL only; to verify that the page is available. However, the URL Checker provides only very limited functionality, it is not designed to support all the features of a Monitor Script recorded in the BMC TMART Workbench.

              A Monitor Script captures multiple measurements from the beginning to the end of the defined transaction (including page times, throughput, Overall Response Time etc), providing a much more detailed report on the performance of the application.
              With regards to adding the user/password in your script in Monitor Workbench, there are a few ways to do that:
              1) Open your project, do Settings -> Active Profile, Replay -> Web (Protocol Level) -> open the Authentication-tab.
              Enter the username/Password under the User authentication.

              You can look in the Help-section for information on this.

               

              2) The second is by using the Project Attributes, ie from Monitor Workbench, do Project -> last option "Monitor Workbench".
              Here you can create the user that is required for accessing the application as well as its password.

              You will find more information about this if you click on the "Learn more about project attributes" link.

               

              Hope this helps.

              Liz

               

               

               

               

              • 4. Re: TM ART URL Checker for login prompts
                Andrew MacIntosh

                Thanks for the replies. I have a requirement to monitor the response time of over 400 URL's (which have a login prompt) without logging in. I just need to verify that the login prompt appears and measure the response time. The 400 URL's are comprised of 4 or 5 different applications. Any thoughts on how to best achieve this? I would like to avoid recording these transactions as it takes a lot more time and effort Also, some applications require web browser driven project type recordings which need Execution Servers running as a process instead of service if I'm correct.

                • 5. Re: TM ART URL Checker for login prompts
                  Andrew MacIntosh

                  Thanks Hal. I don't need to authenticate to the URL's however I just need to verify that the login prompt appears or that authentication is attempted and I can assume the URL is available. Can I achieve this via the URL checker?

                  • 6. Re: TM ART URL Checker for login prompts
                    Dan Egner

                    Here is a sample I found:

                     

                    // Benchmark Description:
                    //
                    // Example script to read in a comma delimted file that has URLS in
                    // it to do a simple URL check on. the input file has 3 URLs per line and
                    // and therefore will check 3 URLs per run.
                    //
                    /* Here is a 2 line example of that the input file c:\\urls.txt may look like:
                    http://www.yahoo.com,http://www.bing.com,http://www.microsoft.com
                    http://www.google.com,http://www.bmc.com,http://www.ibm.com

                    */
                    //-------------------------------------------------------------------

                    benchmark BenchmarkName

                    use "WebAPI.bdh"

                    const
                    MAX_LEN := 254;

                    dcluser
                      user
                        VirtUser
                      transactions
                        TINIT                : begin;
                        TMain                : 2; //This 2 is just for testing in the Workbench.
                                                  //This 2 is ignored when run from an Execution Server.
                      var
                        hFile     : number;

                    dcltrans
                      transaction TINIT
                      var

                        sFileName : string;
                        
                      begin

                       sFileName := "c:\\urls.txt";    //See above for the format of this file.
                       FileCSVLoad (hFile, sFileName); //We open the file once each time the monitor is initialized
                                                       // That is why we open the file in TInit
                      end TINIT;

                    dcltrans
                      transaction TMain

                      var
                        nRead : number;
                        sData : string;
                        sURL1, sURL2, sURL3 : string;

                      begin

                        // See online help for FileGetNextRow
                        // If the current row is the last row in a file, then
                        //   the current row is set to the first row of the file.
                        FileGetNextRow(hFile);    // Read a new record in each time the script is run.     

                        //The record read in has 3 URLs separated by commas.
                        sURL1 := FileGetCol(hFile, 1, MAX_LEN);
                        sURL2 := FileGetCol(hFile, 2, MAX_LEN);
                        sURL3 := FileGetCol(hFile, 3, MAX_LEN);

                        WebPageUrl(sURL1, sURL1);
                        WebPageUrl(sURL2, sURL2);
                        WebPageUrl(sURL3, sURL3);

                        WebThreadWait();

                      end TMain;

                    • 7. Re: TM ART URL Checker for login prompts
                      Andrew MacIntosh

                      Dan,

                       

                      Will this method work for URL’s which prompt for login? I do not need to login but rather just verify that the prompt appears.

                       

                       

                      Andrew A MacIntosh | Senior Principal Consultant, Cloud Infrastructure Services | NTT DATA, Inc. | w. +1.902.422.6036 x 2357 | m. +1.902.401.2392 | e. andrew.macintosh@nttdata.com<mailto:andrew.macintosh@nttdata.com> | Learn more at nttdata.com/americas<http://www.nttdata.com/americas>

                      • 8. Re: TM ART URL Checker for login prompts
                        Dan Egner

                        I tried it on this URL and it seemed to work fine:

                         

                        https://retirementplans.vanguard.com/VGApp/pe/PublicHome

                         

                        But I am not sure that URL acts that way that your URLs do.

                         

                        Regards,

                        Dan Egner

                        • 9. Re: TM ART URL Checker for login prompts
                          Andrew MacIntosh

                          URL’s like this with embedded authentication don’t seem to cause any issues however it is the URL’s that have an actual pop-up prompt for authentication that cause issues.

                           

                           

                          Andrew A MacIntosh | Senior Principal Consultant, Cloud Infrastructure Services | NTT DATA, Inc. | w. +1.902.422.6036 x 2357 | m. +1.902.401.2392 | e. andrew.macintosh@nttdata.com<mailto:andrew.macintosh@nttdata.com> | Learn more at nttdata.com/americas<http://www.nttdata.com/americas>

                          • 10. Re: TM ART URL Checker for login prompts
                            Hal DeVore

                            Andrew,

                             

                            There's not going to be a one-size-fits-all for your situation if I understand it correctly.

                             

                            For your applications that need BDM: if they really need that for their login page to be presented, then you'll have to record them using the BDM project type.  I'd suggest deferring that  until other options have been tried.

                             

                            For the applications that require login: Well, these can be complicated. Here's the process at a protocol level for simple web authentication:

                            1. Browser sends GET request for a page that requires authentication
                            2. Web server replies with an HTTP 401 error (see: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_Error).  The error includes a header giving the allowable authentication method(s)
                            3. Browser pops up its standard username/password dialog.
                            4. User enters credentials
                            5. Browser constructs authentication header
                            6. Browser resends original GET request with added authentication header
                            7. Webserver validates authentication, if failed, sends error (can be another 401 or can be 403 Forbidden), if passed, sends the page content.
                            8. On all following exchanges, the authentication header will be sent.  Remember that browser/server exchanges are stateless.

                             

                            If you record this sequence with the Workbench you'll be able to examine the exchange in the TrueLog.

                             

                            For non-BDM scripts, the process above is usually short circuited in the code.  Since TM ART doesn't run the browser but works at the protocol level, the authentication credentials are set (via a call or Profile options) and the authentication header is sent along on all requests.  That effectively skips steps 1 to 5 above.

                             

                            Now that is the simple case for "built in" authentication methods.  It works for large numbers of web applications.  But the real world isn't simple so it is possible that your application is doing almost anything imaginable for authentication.

                             

                            Where to you go from here: I'm not sure I know but I can give you some thoughts.

                            • If you really don't want to log in to the applications then you will want to do something that looks for the 401 error.  At the protocol level, that is the indication that the webserver required authentication. The standard URLchecker isn't going to work because you'll want to treat a 401 or 403 error status as good and a 200 OK status as bad.
                            • You are going to have to try recording one or two sample URLs from each of your applications and carefully examine the Recording TrueLogs to see it they are doing anything custom for authentication.  With some luck all the apps will be using the same authentication mechanism so you just have to puzzle out what that is.
                            • You might have to switch to a Web Low-Level recording type to handle this situation, I'm really not sure.
                            • Once you've figured out the authentication "pattern" for the apps, you should be able to record a single script for each "pattern" and then convert the URL into a parameter.

                             

                            --Hal

                            • 11. Re: TM ART URL Checker for login prompts
                              Hal DeVore

                              I'm guess that "actual pop-up" means something beyond the W3C-defined authentication mechanisms.  Possibly a dialog from server or client-side code.  That's a case where things get tricky and might be one where you need to use a browser-driven monitor so that the application is run via a headless browser.

                               

                              TM ART makes the standard cases very, very simple to deal with and gives you a toolkit to handle the rest.

                               

                              Sounds like your situation is going to require you to get out the hammer and saw and use the tools to build something specific to your application(s).

                               

                              Keep in mind that TM ART Workbench is a slightly modified version of Borland Silk Performer.  Our version removes the load testing capabilities but other than that is identical.  You can often find useful examples and idea via google for Silk Performer.

                               

                              --Hal

                              • 12. Re: TM ART URL Checker for login prompts
                                Andrew MacIntosh

                                These are all great comments. I think in my situation I hope to steer away from using the BDM and stick with Web Transaction and configure the projects to treat HTTP 401 errors as successes. One additional question I have is that with these types of monitors, is it still good practice to limit each project to 10 Monitors? The only reason I ask is because I have so many URL’s and I would prefer to group them by Application.

                                 

                                 

                                Andrew A MacIntosh | Senior Principal Consultant, Cloud Infrastructure Services | NTT DATA, Inc. | w. +1.902.422.6036 x 2357 | m. +1.902.401.2392 | e. andrew.macintosh@nttdata.com<mailto:andrew.macintosh@nttdata.com> | Learn more at nttdata.com/americas<http://www.nttdata.com/americas>

                                • 13. Re: TM ART URL Checker for login prompts
                                  Dan Egner

                                  It is a best practice to put no more than 20 (some say 10) monitors in a project. Some screens calculate and display things at a project level and adding up all that monitor data can make some of the screens display slowly.

                                   

                                  Dan Egner