DX Operational Intelligence

Expand all | Collapse all

CCR - StartTime and EndTime Oddities

  • 1.  CCR - StartTime and EndTime Oddities

    Posted 07-28-2017 04:28 PM

    I've been creating some new CCR reports and noticed a problem with the parameters passed to your SQL that specify the time range you selected for the report.

     

    Take a look at the screen shot below:

    • I specified a 12-hour time range for July 28 starting at midnight and ending at noon.
    • Two views are displayed; one is a tabular report and the second is a line graph.
    • The titles of the two views correctly display the values of {StartTime} and {EndTime} - GOOD.
    • The times displayed above the upper right corner of each view show GMT and are also correct - GOOD.
    • The x-axis shown in the line chart is using the correct times - GOOD.
    • The BAD news is that the times displayed in the single row of the upper tabular view do not match the selected time range.  In fact, both the {StartTime} and {EndTime} have been adjusted by -4 hours.  Since our CCR server is in Eastern Time, -4 sounds right.  But, GMT is the selected time zone.  I was not expecting the selected time range to be modified.

     

    QUESTION - Why are the values of {StartTime} and {EndTime} erroneously adjusted by time zone?

     

    This problem only seems to be in the SQL generating report content for a tabular view

     

     

     



  • 2.  Re: CCR - StartTime and EndTime Oddities

     
    Posted 07-28-2017 05:04 PM
      |   view attached

    It needs to be noted that this is NETQOS “NPC” version 6.x?  What is the current patch level?

     

    David

     

    David DuPre'

    Principal Services Consultant

    mobile: +1-404-617-3023

    David.Dupre@ca.com<mailto:David.Dupre@ca.com>

     

     



  • 3.  Re: CCR - StartTime and EndTime Oddities

    Posted 07-31-2017 06:19 AM

    If I infer correctly, your test SQL code is not actually pulling any ‘real' data, just returning the {StartTime} and {EndTime} values for testing purposes - correct?

     

    If so, the follow-on question becomes - what is different between the Properties of the Table and the Chart?

     

    The next thing to check is whether there is consistent use of the Integration.EnableUtcStartAndEndTimes property for both controls:

     

    , (@controlID, 'N',         'Integration.EnableUtcStartAndEndTimes',       'True')

     

    From the NPC Integration Guide:

     

    Integration.EnableUtcStartAndEndTimes

    This setting is optional. The default value for this setting is false for backwards compatibility. If set to true, then UTC start and end times will be passed to the data source web service. Otherwise, the NPC server start and end times will be passed.

     

    If this parameter is not explicitly set, ‘false' will be used and the ‘NPC server start and end times will be passed' - it appears that this might be the case for the tabular data in your example…?

     

    Please verify these settings in the MySQL file and let us know.

     

    Regards,

                  Adrian



  • 4.  Re: CCR - StartTime and EndTime Oddities

    Posted 07-31-2017 10:57 AM

    This problem has been resolved - thank you Mr. Johnson.

     

    Now for a few answers:

    • CCR patch level?  Unknown.  Where would I look to determine the patch level?
    • The SQL backing the two test CCR views (table & line chart) are not pulling any data from the database.  In both cases they are something like  "SELECT {StartTime},{EndTime} FROM DUAL".
    • Correctly using the CCR parameter Integration.EnableUtcStartAndEndTimes in the dot-SQL file solves the problem:
      • The line graph had this parameter set to TRUE - this is explains why the line chart was working as expected.
      • The tabular view did not use this parameter (which explains its unexpected behavior).  After adding this parameter to the tabular view, results are exactly as expected.

     

    The moral of this story:  You should always set Integration.EnableUtcStartAndEndTimes to TRUE in your dot-SQL file to generate consistent =results.