Ideas for Apica Synthetic Monitoring

Got an idea? Share it here and we'll have a look at it.

Check Results for Scenario Steps via API

Currently there is no way to capture check results for each step within a scenario, except by scraping the timings off the screen in the UI.  It would be very helpful to be able to capture check results for each scenario step via an API or be able to parse check results by step for a scenario check via API.

  • Gravatar Jeff Mills
  • Jan 13 2016
  • Shipped
  • Jun 7, 2016

    Admin Response

    This is currently planned for release in Q3/Q4.

  • Attach files
  • Admin
    Lars Malm commented
    January 29, 2016 08:26

    You get the result for a check run with these two API routes:

    https://api-wpm.apicasystem.com/v3/Help/Route/GET-checks-browser-checkId-results-resultId-urldata_format

    https://api-wpm.apicasystem.com/v3/Help/Route/POST-checks-browser-checkId-results-urldata

    And please refer to this document with further information:

    http://kb.apicasystem.com/display/WPM/Browser+Data+Mapping


    Please let me know if this does not suit your needs.

  • Jeff Mills commented
    April 22, 2016 17:41

    While the ability to get URL level data is important and is probably what you use to build your waterfalls, that was not my request.  I requested check results at the "step" level, not at the "url_number" level.  

    The API's you've shown below provide results for each and every "url_number" or HTTP request.  I'm needing the aggregate metrics of all the "url_numbers" for each "step".  Let me know if this is unclear.

  • Admin
    Lars Malm commented
    May 3, 2016 14:03

    Hi Jeff! Sorry for the missunderstanding. Let me check in with our developers and then get back to you.

  • Admin
    Erik Torlen commented
    May 27, 2016 18:59

    Hi Jeff - sorry for the delay on this one.

    We are planning to execute on this in an upcoming version.

    To clarify the requirements - what data besides Response Time would be interesting for you to have on a Step level through the API?

  • Jeff Mills commented
    May 27, 2016 19:24

    Pagesize by page and number of times the check was run during the date range that we run the API for (e.g. # of runs for the week or month).

  • Admin
    Lars Malm commented
    November 29, 2016 09:54

    The following API route: http://api-wpm.apicasystem.com/v3/Help/Route/POST-checks-browser-checkId-results-stepdata has been updated. Hopefully this fits your needs at the moment. If not, please let me know.


    Please see this response example:

    "check_results": [
       {
         "check_id": 801xxx,
         "result_id": "8cb41374-1f4a-427d-95bb-590ed3bfxxxx",
         "time_stamp_utc": "2016-11-27T19:10:36.137",
         "step_results": [
           {
             "step": 1,
             "url_count": 1,
             "started_utc": "2016-11-27T19:10:36.137",
             "elapsed_ms": 0,
             "received_bytes": 0,
             "sent_bytes": 0,
             "started_utc_iso_8601": "2016-11-27T19:10:36.1370000"
           }
         ]
       }
     ]
    }

  • Jeff Mills commented
    November 29, 2016 14:25

    The API result example below does align with our request for aggregated metrics by step. However, the original request asked for the capability to provide a date range (from-UTC and to-UTC) and have the API deliver aggregated metrics by step for the entire date range (e.g. multiple check executions). I don’t see that in your API result example below. So we’ll need some clarification and proof as to whether the entire request was satisfied.

    Thanks,
    Jeff

  • Jeff Mills commented
    November 29, 2016 14:27

    The API result example below does align with our request for aggregated metrics by step.  However, the original request asked for the capability to provide a date range (from-UTC and to-UTC) and have the API deliver aggregated metrics by step for the entire date range (e.g. multiple check executions).  I don’t see that in your API result example below.  So we’ll need some clarification and proof as to whether the entire request was satisfied.

     

    Thanks,

    Jeff

  • Admin
    Lars Malm commented
    December 7, 2016 12:24

    In order to get the result from multiple check executions I would recommend that you use this API route http://api-wpm.apicasystem.com/v3/Help/Route/GET-checks-checkId-results_fromUtc_toUtc_detail_level using the detail_level=1.

    Let me know if I can help in any other way.

    Regards,

    /Lars

  • Jeff Mills commented
    December 7, 2016 14:38

    Lars,

    The API you suggested still does not provide the information we need.

    See example here:
    https://api-wpm.apicasystem.com/v3/checks/65861/results?fromUtc=2016-12-01T12:00:00&toUtc=2016-12-06T12:00:00&detail_level=1

    API Results:
    [
    {
    "message": "3 steps, 3 pages, 159 urls, 303630/7011901 sent/received bytes",
    "identifier": "6f8bcd83-f703-4d0f-afdf-9cc6787277dd",
    "attempts": 2,
    "result_code": 0,
    "check_id": 65861,
    "timestamp_utc": "2016-12-01T12:03:28",
    "severity": "I",
    "value": 21153,
    "unit": "ms"
    },
    {
    "message": "3 steps, 3 pages, 161 urls, 302055/7028910 sent/received bytes",
    "identifier": "95042086-61c6-444c-b644-f31bb0ac3e73",
    "attempts": 1,
    "result_code": 0,
    "check_id": 65861,
    "timestamp_utc": "2016-12-01T12:12:19",
    "severity": "I",
    "value": 20872,
    "unit": "ms"
    },
    {
    "message": "3 steps, 3 pages, 177 urls, 214590/7479001 sent/received bytes",
    "identifier": "d85dd1bf-d706-4b21-9871-5c7211aabee5",
    "attempts": 1,
    "result_code": 0,
    "check_id": 65861,
    "timestamp_utc": "2016-12-01T12:22:58",
    "severity": "I",
    "value": 25489,
    "unit": "ms"
    }, . . . . .

    While this API works for a date range, it DOES NOT provide “value”s for each of the 3 individual steps in the browser scenario with checkID of 65681.

    Jeff

  • Admin
    Lars Malm commented
    December 7, 2016 15:36

    Sorry, I should have made it clear that you need to first extract the result IDs (i.e "identifier": "6f8bcd83-f703-4d0f-afdf-9cc6787277dd") with this route: http://api-wpm.apicasystem.com/v3/Help/Route/GET-checks-checkId-results_fromUtc_toUtc_detail_level and then use the updated route: http://api-wpm.apicasystem.com/v3/Help/Route/POST-checks-browser-checkId-results-stepdata to get the Step Data for those result IDs.


    Please let me know if I can be of more assistance.


    Regards,

    /Lars

  • Jeff Mills commented
    December 7, 2016 16:15

    So, in other words, the API’s do not provide the aggregated response times BY STEP for a DURATION (fromUtc – toUTC). Please confirm whether my understanding of this is correct, so we know what’s actually involved.

    We will have to build a script and process to get all the individual data points for each check execution within the date range, capture and determine the mean or median response time by step for each result ID and then aggregate “like” step metrics to determine average response time by step for a week or month.

  • Admin
    Erik Torlen commented
    December 8, 2016 01:47

    Hi Jeff,

    This endpoint is not exposing *aggregated* data over a longer period per Step. This endpoint provides detailed data for each step inside of a individual result. You can continuously poll out the response time for each step in a result and store it on your side. In that case the flow would be to:

    1. Poll result-ids for a time period

    2. Poll step response times for each result-id

    If you are continuously polling the API this would work.

    If you want to get aggregated Step metrics over a longer period in one call - we are releasing aggregated Step metrics in Feb 2017.

    Erik Torlén

    CTO

  • Jeff Mills commented
    December 8, 2016 13:50

    Erik,

    Thanks for the explanation and proposed timeline for the new API. I knew our request was in the works, so when I got an email from Lars Malm with an API to address it, I thought he was referring to the same request.

    Thanks,
    Jeff

  • Gravatar
  • Gravatar
  • Gravatar