Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
Customer has automated CDR on demand using the AXL/SOAP interface.   The automation stores the last successful CDR pull in a hash table, when the next request comes it looks at the last time of the last successful CDR on demand pull.    When the customer does CDR during the Daylight Savings time it returns invalid date range:
 
Version:1.0
StartHTML:0000000149
EndHTML:0000001769
StartFragment:0000000199
EndFragment:0000001735
StartSelection:0000000199
EndSelection:0000001735

<!--StartFragment-->The call managers are throwing an Invalid date range error as we are querying the following time range:

 

201203110257 (2012/03/11 02:57)

201203110356 (2012/03/11 03:56)

 

I am not very clear how cisco call managers handle the daylight saving time change. We may have to investigate or open a case with cisco or change our code. We are querying using GMT times.



Daylight saving March 2012
: set your clock(s) forward one hour at 2:00 AM on the second Sunday in March.

 

History of CDR reports:

 

No file found within the specified time range (2012/03/11 01:56 - 2012/03/11 02:11).

No file found within the specified time range (2012/03/11 02:12 - 2012/03/11 02:26).

No file found within the specified time range (2012/03/11 02:27 - 2012/03/11 02:41).

No file found within the specified time range (2012/03/11 02:42 - 2012/03/11 02:56).

Error retrieving NetIQ CDR files. java.rmi.RemoteException: Invalid date range

Error retrieving NetIQ CDR files. java.rmi.RemoteException: Invalid date range

Error retrieving NetIQ CDR files. java.rmi.RemoteException: Invalid date range

Error retrieving NetIQ CDR files. java.rmi.RemoteException: Invalid date range

[..]
 
The customers automation is not able to successfully pull CDRs when this happens since the hash table does not get updated.   I believe the response code of "invalid date range" is not correct since the format of the objects is an absolute time and formatted correctly.   Having CM respond with no files found is sufficient (and it is successful in the customers tool and the hash table gets updated).

 
Your Thoughts?
 
Dan 
<!--EndFragment-->

Possibly a defect, as you suggest - also agree that pursuing via a CDN Developer Support case is the best option.