Please ensure you have a valid reason for applying any of the changes below. These notes are posted as a result of very specific customer virtualization use cases.
If ever you have a question about these techniques, please add a question in Communities or open a ticket with CA Support to receive proper configuration guidance.
As with any modification implemented in DevTest, it is important that the developer understand the impact changes can have on the system. We recommended that backups exist prior to making any changes.
I was asked by a customer about how to configure DevTest to not apply Magic Date processing to certain date ranges in a response payload. After some probing, I found out that some mainframe-based applications use the concept of 'high-date' to represent an open-ended date. One might see something like this when looking at a response payload that contains a From and To date. To express a valid looking, open-ended 'To Date' an application might insert a date value such as 9999-12-31, 12/31/9999, 12/31/5000, etc. This technique ensures that business logic will never evaluate the current date (i.e., today's date) as exceeding the date coded in the response payload.
DevTest's magic date analyzer doesn't really care about the business reason dates might be set to represent some fictitious value. The processor simply sees data in the response that matches a valid date format or pattern, and creates a doDateDeltaFromCurrent calculation based on the date and today's date. The idea is to provide future responses with dates adjusted based on the date the transaction enters the service. The resulting calculation can create some extreme values such as: =doDateDeltaFromCurrent("yyyy-MM-dd","2915447D");/9999-12-31/
But, what happens when tomorrow's date plus 2915447 causes the year 9999 to overflow? Or, what happens when the application has a hard-coded reference to the year 9999 and your magic string processing just changed it?
Tightening Magic Date Ranges to Specific Years
The rules used by DevTest to control magic date processing are implemented in the lisa.properties file.
The following approach can be used to cause the magic date processor to ONLY process dates having centuries starting with "1" or "2" thus, ignoring dates having centuries "3-9". It should be noted that this change could introduce a Y3K issue...
Before Version of the Long Year Rule
Search on lisa.vse.datechecker.yearlongregex in lisa.properties, and you will find the default date rules applied by the Magic String processor. There are quite a few of them. You will also notice a long year regex pattern that looks like this:
After Version of the Long Year Rule - Including only first and second century dates
A slight adjustment can be made to the Regex pattern to include only centuries beginning with 1 and 2. The subtle change looks like this:
Stop Magic Date Processing
Under very specific conditions, it may be necessary to disable Magic Date processing. For example, suppose that a given recording has an extremely high number of requests and responses AND dates in the responses are either non-existent or unimportant to the System-Under-Test. In this case, you might speed the construction of the service by turning off magic date processing. The following provides a set of instructions for disabling magic date processing.
NOTE: Please exercise appropriate caution before turning off Magic Date processing - make sure you know why you are doing this and for how long the logic will be disabled so as not to impact others that may require Magic Date processing.
Locate and comment out the following lines in the lisa.properties file:
After commenting the above, add the following lines to the file: