5.5 Specifying Scenario-Specific Attributes

5.5.1 FTP Scenario Attributes

Table 5-2 describes the FTP scenario attributes.

Table 5-2 FTP Scenario Attributes

Attribute

Specify

Host

Name of the FTP server to test.

File Name

File to upload or download from the FTP server. Precede the file name with the “/” (forward slash) character. Date macros can define File Name values. See Section 5.5.13, Using Date Macros within Scenarios for more information.

Method

Method used to interact with the FTP server.

GET (uploads the selected file from the FTP server).

PUT (downloads the selected file to the FTP server).

Type

Type of transmission that occurs: BINARY or ASCII.

Socks Host

SOCKS proxy hostname.

Socks Port

Port number on which SOCKS proxy host listens.

5.5.2 DHCP Scenario Attributes

Table 5-3 describes the DHCP scenario attributes.

Table 5-3 DHCP Scenario Attributes

Attribute

Specify

MAC Address

Address that network adapters use to uniquely identify themselves on a LAN. MAC addresses are 12‑digit hexadecimal numbers.

Server IP

IP address of the server. If the field is left blank, 255.255.255.255 is used as the default broadcast address.

Port

Port used by the server for DHCP broadcasts. If the field is left blank, port 67 is used.

5.5.3 HTTP(S) Scenario Attributes

The Hrefs attribute (Web pages that are linked from the host Web page and show statistics) are no longer supported in Experience Manager. Table 5-4 describes HTTP and HTTPS scenario attributes.

Table 5-4 HTTP and HTTPS Scenario Attributes

Attribute

Specify

Host

Web address to test.

Port

Port used by the Web server for HTTP requests. Defaults to 80 for HTTP tests. Defaults to 443 for HTTPS tests.

File Name

File to access on the Web site (that is, the specific Web page). Precede the file name with the “/” (forward slash) character. Date macros can define File Name values. See Section 5.5.13, Using Date Macros within Scenarios for more information.

Method

Method used to interact with the Web page:

GET: A request for a file

POST: Send text to the Web page

User Agent

User-defined string that is inserted into the browser “user agent” informational text area. Defaults to Experience Manager Monitor. Often used to identify the source of a transaction as a synthetic test rather than a real user.

Parameters

Parameter definitions that do the following:

  • Add customized header information into the HTTP request

  • Define a unique piece of HTML response data to capture and use in forms for subsequent test scenarios

  • Specify form values

  • Post raw data. See Section 5.5.4, HTTP(S) Parameters.

Steps

Instructions that allow a scenario to crawl through a set of Web pages by extracting the URL link for a specific HREF, REFRESH, FRAME, and/or FORM. See Section 5.5.5, Handling Dynamic Web Pages.

Ignore Hosts

Enter one or more hostnames, separated by commas, to ignore during test execution. Partial hostnames are acceptable. For example, double-click matches doubleclick.net and ads.doubleclick.com.

This field applies only to HTTP assets referenced by the page (that is, images included on the page) that are not explicitly named in the scenario or its steps.

Use this feature to exclude double-click ads that appear in Web pages. Excluding hosts that the Web engine might execute against avoids making calls that impact response time measurements for the double-click ads. However, it does include all other assets to which a Web page refers.

Follow refreshes

Select the check box to have the test follow any page containing a REFRESH HTTP-EQUIV <meta> tag to redirect the Web browser to a different URL.

Include frames

Select the check box to include all frame pages that are part of the Web page and display statistics for these in the Assets tab of the test record (alarm).

Include images

Select the check box to include all images that are a part of the Web page and display statistics for these in the Assets tab of the test record (alarm).

5.5.4 HTTP(S) Parameters

Adding parameters to HTTP(S) scenarios enables the following customizations:

Adding Header Information

An HTTP transaction consists of headers that specify information such as the action required of the server, the type of data being returned, or a status code.

Use the Add Header parameter to add customized header information in the HTTP request or manipulate existing HTTP headers by overriding values. For example, setting name to Accept-Transfer-Encoding and value to None informs the Web server that no transfer encoding is necessary.

Another use for the header information is to arbitrarily add cookies to a synthetic session by adding cookies explicitly via the Add Header option.

Data Capture

Data capture defines a unique piece of HTML response data or header date that a user might want to capture and use dynamically for form field data in subsequent scenarios for an HTTP test. If the name of the data capture is in variable format (surrounded by curly braces {}), then the captured data is stored in a variable and is available for the remainder of the test.

Form Fields

Specify form fields for an HTTP test scenario to add form data for a URL request. Web site forms receive the information required to properly access the page and run the test.

For example, to search for content on a specific page, first log in to access the page. Use form fields to have the test log in before performing other tests on the site.

Post Raw Data

When specifying an HTTP POST, you can post form field data to the server or post it as raw data. Normally, XML data is URL-encoded, which a server can not process. The Post Raw Data feature enables the Experience Manager Monitor to send XML data to servers that require an XML string as the post data.

Defining a Parameter for the HTTP(S) Test Scenario

To define a parameter for the HTTP(S) test scenario:

  1. In the Create Scenario dialog box, in the HTTP(S) tab, click the New Parameter icon to open the Create Parameter dialog box:

  2. Select the Type drop-down list and select the type of action to be performed.

    The following table provides explanations of each parameter type:

    Parameter Type

    Function

    Next Steps

    Add Header

    Adds customized header information, manipulates existing HTTP headers by overriding values or adds cookies.

    • Type a name for the header in the Name text box.

    • Type the value for the header in the Value text box.

    • Add cookies explicitly by typing Set-Cookie: (ending colon is required) in the Name text box and setting the value pair in the Value text box (for example, myname=David).

    Capture Data

    Captures data.

    • Type the name for the data capture in the Name text box.

    • To define how the test searches for data to capture, specify the left_boundary and right_boundary.

      For example, if left_boundary="SWERowId=\" and the right_boundary="\" and if any of the HTML response data from within all scenarios of a test contains [SWERowId=\"1-999\"], the data captured is [1-999].

    • When a marked form_field or cookie with use_capture_data contains this value, a dynamic substitution occurs when running the scenarios.

    Post Raw Data

    Posts raw data.

    Submit Form Field

    Submits a form field.

    • Specify the Name and Value that the Web page form field expects.

    • Date macros can define values for form fields. See Section 5.5.13, Using Date Macros within Scenarios for more information.

    • Select the URL encoded check box if the value is already URL-encoded.

    • Select the Use data capture check box to replace the value with the captured data. If this option is selected, the Value specified above must be the name of the captured data.

    • Select the Use cookie data check box to have the form field value contain the value for the cookie. If selected, the Value specified above must be the name of the cookie.

    • If both Use data capture and Use cookie data are selected, the test engine attempts to fill the dynamic value from the cookie and then from the captured data store.

    • Select the Value is Password check box to encrypt the form field because it is a user password field.

  3. Click the Create button.

    The Create Parameter dialog box closes and the new parameter displays in the Parameter list.

Adding Header Information

To add header information:

  1. In the Create Parameter dialog box, select the Type drop-down list, then click Add Header:

  2. Type the header name in the Name text box.

  3. Type the header value in the Value text box:

    • Add cookies explicitly by typing Set-Cookie: (ending colon is required) in the Name text box and setting the value pair in the Value text box (for example, myname=David).

    • Use date macros to define values for the header. See Section 5.5.13, Using Date Macros within Scenarios for more information.

  4. Click the Create button.

    The Create Parameter dialog box closes and the new parameter displays in the Parameters list in the Create Scenario dialog box:

5.5.5 Handling Dynamic Web Pages

To perform multiple HTTP tests under one scenario, use step tags. The steps instruct a scenario to crawl through a set of Web pages by extracting the URL link for a specific HREF, REFRESH, FRAME, FORM-GET, or FORM-POST.

Steps define a series of sequential actions where each relies on the previous. When a step fails, then all remaining steps are not executed. Step tags apply to the current scenario only, as they are performed separate from and without impact to the next scenario.

For example, assume an HTTP scenario performs a search for “NetIQ” on Google. The engine parses the HTML response and searches for the HREF link of “NetIQ” and then proceeds to www.netiq.com.

Additionally, it is possible to validate the following aspects of a Web page:

  • The title of the Web page

  • The length of the Web page’s contents

  • The Web page’s return code

  • Specific content within the Web page

To set up dynamic Web pages:

Setting Step Tags for the HTTP(S) Test Scenario

To set step tags for the HTTP(S) test scenario:

  1. In the Create Scenario dialog box, in the HTTP(S) tab, click the New Step icon. The Create Step dialog box opens.

  2. Type a step name in the Name text box.

  3. Select the Type drop-down list and select a step type:

    Href: Finds its URL from <a href="url">. In the Reference text box, specify the name of the link on the Web page. For example, the reference is <b>NetIQ</b> and the URL is http://www.netiq.com if the HTML code is:

    <a href="http://www.netiq.com"><b>NetIQ</b></a>
    

    The reference must include all syntax between the <a> and </a> tags.

    Frame: Finds its URL from <frame src="url">. In the Reference text box, specify the src value of the frame tag. For example, the reference and URL are overview-frame.html if the HTML code is:

    <FRAME src="overview-frame.html" name="packageListFrame">
    

    Refresh: Finds its URL from <meta http-equiv="refresh" content="X;URL=url …>. In the Reference text box, specify the URL portion of the content value of the <meta> tag. For example, the reference and URL are mlb_scoreboard.jsp?ymd=20030812 if the HTML code is:

    <meta http-equiv="refresh" content="180;URL=mlb_scoreboard.jsp?ymd=20030812">
    

    form-get: Finds its URL from <form action="url">.

    form-post: Posts its URL to <form action="url">. Specify a value in the Reference text box.

    For form-get and form-post, specify the reference as the name of the Submit button of the corresponding input type=submit tag. For example, the reference is Google Search and the URL is the search from the form action, if the HTML code is:

    <form action="/search" name=f>
    <input type=submit value="Google Search" name=btnG>
    </form>
    

    Define the form_field values in the parameter definitions. See Section 5.5.4, HTTP(S) Parameters.

  4. Create parameters by clicking the New Parameter icon to open the Create Parameter dialog box.

  5. Select the Type drop-down list and select a parameter type:

    Capture Data: Specify the name for the data capture in the Name text box, and the left and right boundaries in the Left Boundary and Right Boundary text boxes.

    Submit Form Field: Specify the form name in the Name text box and an optional value in the Value text box. Select the check boxes for URL encoded, Use data capture, Use cookie data, and/or Value is password.

    Post Raw Data: Specify the data in the Data text box. Select the Data is XML check box if the data is XML code.

  6. To save the parameter, click the Create button.

    The Create Parameter dialog box closes and the new parameter displays in the Parameter list.

Specifying Response Time Validation for the Step

To specify response time validation for the step:

  1. In the Create Step dialog box, click the Validation tab to display the Validation tab:

  2. Click the New Rule icon to open the Create Rule dialog box.

  3. Select the Rule Type drop-down list, then click Response Time.

    Response time is the default for all scenarios except HTTP and HTTPS.

  4. Select the Response Type drop-down list and select one of the following:

    Range: Generates an alarm when the response time is within the specified time range. Specify the time range using the Minimum Time and Maximum Time (in milliseconds) text boxes. Select the Alarm Severity drop-down list and select a severity to set for the alarm issued when the response time is within the specified time range.

    Upper Threshold: Generates an alarm when the response time exceeds the specified maximum time interval.

    Lower Threshold: Generates an alarm when the response time is less than the specified minimum time interval.

  5. If the Response Type is Lower or Upper Threshold, select the Alarm Severity drop-down list and select a severity to set for the alarm issued when a response time rule violation occurs.

  6. In the Alarm Description text box, specify a description for the issued alarm:

  7. Click the Create button to create the rule.

    The rule displays in the Validation Rules list in the Validation tab.

  8. In the Validation tab, provide information for the following HTTP content that returns from Web server and can be validated:

    Content Length: An element that defines the HTML document’s content length. Select the Include frames check box to calculate the content length for all frames including main HTML document. The content length does not include images or other types of application/binary data.

    Page Title: An element that defines the HTML document’s title. Select the Case Sensitive check box if the match must be case sensitive. The test fails if the value does not match.

    Select the Regular Expression check box if case does not matter. The regular expression entered is used to validate the syntax.

    Status Code: An element that defines the HTML document’s return status code. Type the valid HTTP response code. The test fails if the codes do not match.

    Select the Allow redirects check box to allow page redirects without failing the test. For example, assume the HTTP code is set to 200 and this check box is selected. The test does not fail if, through the gathering of URL assets, there are one or more redirects that have a code of 302.

  9. Click the Create button to create the step.

    The Create Step dialog box closes and the step definition displays in the Steps list in the Create Scenario dialog box.

  10. Because steps occur in the order in which they display, you can click the Move Up and Move Down icons to reorder selected steps:

  11. Click the Create button to create the scenario.

    The new scenario displays under the Shared Scenarios element in the Explorer pane.

Specifying Rules for Cookie or Content Match Validations

When defining HTTP and HTTPS test scenarios, it is possible to define rules for performing specific actions based on cookie or content matches.

To specify rules for cookie or content match validations:

  1. In the Create Scenario dialog box, click the Validation tab to display the Validation tab.

  2. Click the New Rule icon to open the Create Rule dialog box:

  3. Select the Rule Type drop-down list and select one of the following:

    • To validate cookies received from Web pages, select Match Cookie.

    • To validate page content, select Match Content.

  4. In the Name text box, type the page field name or cookie field name.

  5. In the Value text box, type the cookie or content value.

  6. Select the following check boxes as needed:

    Fail on match: Causes the scenario to fail if the rule content is matched.

    Case Sensitive: Specifies that matching is case sensitive. Clear the check box if the value specified is a regular expression.

    Regular Expression: Identifies the value specified as a regular expression.

  7. Click the Create button to create the rule.

    The rule displays in the Validation tab:

  8. In the Validation tab, type information for the following HTTP content that returns from Web server and can be validated:

    Content Length: An element that defines the HTML document’s content length. Select the Include frames check box to calculate the content length for all frames including main HTML document. The content length does not include images or other types of application/binary data.

    Page Title: An element that defines the HTML document’s title. Select the Case Sensitive check box if the match must be case sensitive. The test fails if the value does not match.

    Select the Regular Expression check box if case does not matter. The regular expression entered validates the syntax.

    Status Code: An element that defines the HTML document’s return status code. Type the valid HTTP response code.  The test fails if the codes do not match.

    Select the Allow redirects check box to allow page redirects without failing the test. For example, assume the HTTP code is set to 200 and this check box is selected. The test does not fail if, through the gathering of URL assets, there are one or more redirects that have a code of 302.

  9. Click the Create button to create the scenario.

    The new scenario displays under the Shared Scenarios element in the Explorer pane.

5.5.6 ICMP Scenario Attributes

Table 5-5 describes the ICMP scenario attributes.

Table 5-5 ICMP Scenario Attributes

Attribute

Specify

Host

Machine to echo/ping.

Count

Number of echo requests to send.

5.5.7 LDAP Scenario Attributes

Table 5-6 describes the LDAP scenario attributes.

Table 5-6 LDAP Scenario Attributes

Attribute

Specify

URL

Location and port of the LDAP server to which the Operations Center server connects.

Base DN

Distinguished name for the root naming context. For example, if the server has the root naming context dc=example, dc=com, then set the basedn property to this value.

Initial Context

Starting context for performing LDAP extended operations and controls. If it is left blank, the default is com.sun.jndi.Ldap.LdapCtxFactory.

Authentication

Security level as follows:

  • None: No user authentication is performed.

  • Simple: Simple credentials are required.

  • Strong: Strong credentials are required.

If it is left blank, the default is Simple.

Principal

Identity of the principal for authenticating the caller to the service. The format of this property depends on the authentication scheme. The user name and password in an associated authentication identity overwrite any value entered for this property.

Credentials

Credentials of the principal for authenticating the initial context of the service. The value of this property depends on the authentication scheme. For example, the value of the authentication scheme might be a hashed password, cleartext password, key, or certificate.

The user name and password in an associated authentication identity overwrite any value entered for this property.

Security Protocol

Security protocol to use.

Organizational Unit

Organizational unit under the base DN where the user entries reside.

5.5.8 E‑Mail Scenario Attributes

Table 5-7 describes the e-mail scenario attributes.

Table 5-7 E‑Mail Scenario Attributes

Attribute

Specify

SMTP Server

Address of the mail server used to send mail.

Inbox Server Type

Type of e‑mail server. Select POP3 or IMAP.

Inbox Server

Address of the mail server used to receive mail.

Mail Address

Actual e‑mail user destination address.

Message Body Size

The size in KB of the e‑mail message. Defaults to 20.

Require SMTP Authentication

Select the check box if SMTP authentication is required when running the e‑mail test.

An e‑mail test scenario attempts to send an e‑mail to a specified mail address. If it is successful reading the e‑mail from the recipient’s in box, Experience Manager deletes the e‑mail.

If the test fails to read and delete the e‑mail, there are two probable causes:

  • Authentication problem: Invalid credentials always prevent the reading and deletion of an e‑mail. Verify that the scenario uses a valid set of user credentials associated with the destination mailbox.

  • Client conflict: A thick e‑mail client accesses the same user account specified in the e‑mail test scenario and removes the e‑mail from the server before it is read and deleted by Experience Manager. Verify that another client does not use the same e‑mail address.

5.5.9 DNS Lookup Scenario Attributes

Table 5-8 describes the DNS lookup attributes.

Table 5-8 DNS Lookup Scenario Attributes

Attribute

Specify

Query

Hostname or IP address to resolve.

Name Server

Name (or IP address) of the DNS server.

DNS port

DNS lookup port. Defaults to 53.

Transport

Transports the specified protocol. The default is UDP. You can set it to TCP.

Enable reverse lookup

Select the reverselookup check box to invert the address, append in-addr.arpa, and look up the PTR (pointer) data instead.

Enable recursion

Select the recursion check box to ask for a recursive answer to the query. Defaults to a selected check box.

5.5.10 SQL Scenario Attributes

Table 5-9 describes the SQL scenario attributes.

Table 5-9 SQL Scenario Attributes

Attribute

Specify

Host

Name of the host server.

Query

Actual query statement to execute. Use date macros to define values for the query. See Section 5.5.13, Using Date Macros within Scenarios for more information.

DB Type

Type of database. Specify oracle, sybase, db2, or mssql7.

DB Name

Name of the database.

DB Port

Port number used by the database.

To define a result set to match the SQL test:

  1. In the Explorer pane, expand the Elements root element > Experience Manager Adapter > Administration > Test Administration > Tests.

  2. Right-click an SQL test, then click Properties to open the Status property page.

  3. In the left pane, click Test to open the Test property page:

  4. Select a scenario, then click the Edit Scenario icon to open the Edit Scenario dialog box. The Edit Shared Scenario dialog box displays:

  5. Do one of the following:

    • Select the Edit the scenario shared by all tests radio button to edit the shared scenario definition.

    • Select the Create and edit a private copy radio button to modify the scenario without affecting all tests that use it.

  6. Click the Edit Result Set Item icon to open the Edit Result Set Item dialog box:

  7. In the Column text box, type the name of the database column.

    Column is the name of the database column name.

  8. In the Value text box, type one of the following:

    • Type value for a result set that matches this value.

    • Type null for a result set that returns a null value.

  9. Click the Create button.

    The new result set displays in the Edit Scenario dialog box:

  10. Click the Apply button to update the scenario and close the Edit Scenario dialog box.

5.5.11 Trace Route Scenario Attributes

Table 5-10 describes the trace route scenario attributes.

Table 5-10 Trace Route Scenario Attributes

Attribute

Specify

Host

Target host machine name.

Maximum Hops

Maximum number of hops allowed. If the test cannot reach the host in the number of hops specified, the test fails. A suggested value is 30.

In a packet-switching network, a data packet hops from one router to another.

5.5.12 Third-Party Scenario Attributes

Developers can write tests that the Experience Manager Monitor’s test engine executes, leveraging all the normal consistency of the other test protocols.

A sample third-party test is located in the tests/thirdpartyexamples file in the Experience Manager Monitor installation directory.

Creating a Class File

To create a class file:

  1. Create a class file that extends the Experience Manager Monitor’s methods.

  2. Continue with Creating a Java File to Implement the Test.

Creating a Java File to Implement the Test

To create a Java file to implement the test:

  1. Create a Java file with a class that imports:

    com.mcode.agent.test.thirdparty.*;
    
  2. Verify that the class extends:

    com.mcode.agent.test.thirdparty.ThirdPartyTest
    
  3. Verify that the following abstract protected method is included:

    protected void runTest() throws java.lang.Exception
    {
      //perform your test
    }
    

    The parent class gathers the response time.

  4. To access the parameter data, add one of the following methods:

    •      /**
            * This method returns the name portion of the parameters
            * 
            * @return the names
            */
           public String[] getParameterNames()
      
    •      /**
            * This method returns the value portion of the parameters
            * 
            * @return the values
            */
           public String[] getParameterValues()
           {
             return values;
           }
      
    •      /**
            * This method returns a specific value of the parameter based on name
            * 
            * @return the value based on a name or NULL if not found
            */
           public String getSpecificParameterValue(String name)
      
  5. To include additional data in the alarm properties, call the following method:

    public void addDetail(Detail detail);
    //To create a new Detail object
    public class Detail
    {
     private String name;
     private String value;
     public Detail(String name, String value)
     {
      this.name=name;
      this.value=java.net.URLEncoder.encode(value);
     }
    }
    

    In the alarm properties, each value pair is represented as a name value pair.

    To access the log object, add one of these methods:

    •   /**
            * This method logs a warning
            */
           public void logWarning(String msg)
      
    •   /**
            * This method logs a debug
            */
           public void logDebug(String msg)
      
    •   /**
            * This method logs a Info
            */
           public void logInfo(String msg)
      
    •   /**
            * This method logs a error
            */
           public void logError(String msg)
      
  6. Compile the code using the thirdpartytest.jar located in the /OperationsCenter_ExperienceManager_install_path/tests/thirdpartyexamples directory.

    A .class file is created for the Java file.

  7. Create a .jar file.

  8. Add this new .jar file to the /OperationsCenter_ExperienceManager_install_path/html/bem/monitor directory.

    This alerts the Experience Manager Monitor to add the file into its classpath.

    It is not necessary to add the thirdpartytest.jar because it is already included in the manager.jar file.

  9. Add this new .jar file as an application resource to /OperationsCenter_ExperienceManager_install_path/html/bem/monitor.jnlp.

  10. Restart the Experience Manager Monitor to download the new binary file.

Creating a Third-Party Test Scenario

To create a third-party test scenario:

  1. In the Create Scenario dialog box, select the Type drop-down list, then click Third Party.

  2. On the Third Party page, type the Class Name.

    Provide a fully qualified class in order to call the test. It is not necessary to add the .class extension to the class name.

  3. Click the New Parameter icon to add name/value pairs as required for the third-party test scenario.

  4. Click the Create button to create the scenario. The new scenario displays under the Shared Scenarios element in the Explorer pane.

5.5.13 Using Date Macros within Scenarios

Define date macros within scenarios to calculate dates based on the current date:

  • The CURRENT_ DATE macro defines values in text fields for all scenario types

  • The DAY_OF_WEEK function can calculate a static date, such as the first day of the week

Table 5-11 illustrates the various CURRENT_ DATE macro syntax patterns and resulting output.

Table 5-11 CURRENT_ DATE Macro Syntax Patterns

Date/Time Pattern

Result

{CURRENT_DATE}

20120629 (default yyyyMMdd)

{CURRENT_DATE(1)[yyyy.MM.dd]}

2012.06.30

{CURRENT_DATE(‑1)[EEE, MMM d, yy]}

Tues, Jun 28, 12

{CURRENT_DATE[MM/dd/yy]}

06/28/12

The following syntax is valid for defining a date macro within the field values. skew represents the number of days plus or minus the current date:

{CURRENT_DATE}
{CURRENT_DATE(skew)}
{CURRENT_DATE(skew)[format]}
{CURRENT_DATE[format]}

Integrate date macros with other data to define the value. For example, the file location of an HTTP test might vary every day with locations based on dates:

<http file="/articles/{CURRENT_DATE(-1)[MMddyyyy]}/article1.htm">   

This translates to file="/articles/06282004/article1.htm" when the test is executed on June 28, 2004 and to file="/articles/06292004/article1.htm" on the following day.

The DAY_OF_WEEK function can calculate a date based on the first day of the current week, which is assumed to be Sunday. The following syntax is valid for defining a date macro within the field values. Skew represents the number of days plus the first day of the week:

{DAY_OF_WEEK}
{ DAY_OF_WEEK(skew)}
{ DAY_OF_WEEK(skew)[format]}
{ DAY_OF_WEEK[format]}

Table 5-12 shows examples of the DAY_OF_WEEK macro syntax patterns and resulting output.

Table 5-12 {DAY_OF_WEEK} Macro Syntax Patterns

Date/Time Pattern

Result

{ DAY_OF_WEEK}

20121127 (yyyyMMdd — first Sunday of current week)

{ DAY_OF_WEEK(1)[yyyy.MM.dd]}

2012.11.28 (Monday)

{ DAY_OF_WEEK[MM/dd/yy]}

11/27/12

It is also possible use a date macro to set the current date. Table 5-13 shows some examples.

Table 5-13 Date/Time Syntax Patterns

Date/Time

Pattern Result

yyyy.MM.dd G 'at' HH:mm:ss z

2012.07.04 AD at 12:08:56 PDT

EEE, MMM d, “yy

Mon, Jul 4, '12

h:mm a

12:08 PM

hh 'o''clock' a, zzzz

12 o'clock PM, Pacific Daylight Time

K:mm a, z"

0:08 PM, PDT

yyyyy.MMMMM.dd GGG hh:mm aaa

02005.July.04 AD 12:08 PM

EEE, d MMM yyyy HH:mm:ss Z

Mon, 4 Jul 2012 12:08:56 ‑0700

yyMMddHHmmssZ

120704120856‑0700

Another option is to create variables and use the date macro as the value. See the Section 6.11, Creating Test Variables section for details.