Synthetic Classic has reached end of support and is no longer available. Existing Synthetic Classic customers have been upgraded to the all-in-one Dynatrace software intelligence platform.


MonitorOrderResponse elements appear in both ProvisionTestsResponse elements and in UpdateTestsResponse elements. In both contexts, the contain information about a monitor-level transaction that either completed successfully or failed to complete successfully.

Derived by

Restricting anyType


Name Type Required? Default Description
name string Yes The name of the browser test. This field maps to the description column of a monitor defined in the monitor table of the database.
folder string No The name of the folder to which the browser test belongs. This field maps to the description field of the monitor group.
monitorId string Yes The monitorId uniquely identifies the browser test in the Synthetic Classic Portal for the account. This information must be sent whenever the browser test is updated or deleted.
monitorStatus MonitorStatusType Yes The status of the test (Active, Inactive, or Deleted).
orderStatus ResponseStatusType Yes The status of the monitor order itself (SUCCESS if the test was successfully provisioned, FAILURE if the test could not be provisioned.
scriptId string No This field identifies the GSL script id used to create the test.

Content model

Contains elements as defined in the following table.

Component Type Occurs Nillable? Description
Message [element MonitorOrderResponse] string 0..1 No This is an error message at the level of a specific monitor order response. However, even if there is no error, message is populated with a description of the outcome of the monitor order. Use the orderStatus field to determine the outcome of the provisioning attempt and the message as a container of supporting data.

Referenced by


The following example shows the role that MonitorOrderResponse elements play in a ProvisionTests operation invocation:

      <MonitorOrderResponse name="Test 11-27-2012 EricS 004" monitorId="328581"
        monitorStatus="Active" orderStatus="SUCCESS">
         <Message>Successfully provisioned monitor: AccountName = DEV - Eric Smith,
            MonitorName = Test 11-27-2012 EricS 004, MonitorId =328581</Message>
      <MonitorOrderResponse name="Test 11-27-2012 EricS 005" monitorId="328582"
        monitorStatus="Active" orderStatus="FAILURE">
         <Message>The site product combination (Site = 777, Product=UTA-TRANSACTION)
            does not support IPv6.</Message>

In the previous example, the ProvisionTests request caused two transactions to be initiated. The first completed successfully, resulting in the creation of a test with monitorId 328581. The second transaction failed and had to be rolled back because of a violation of a business rule. The ResponseStat for the entire request is listed as a failure because of the failure encountered in the second transaction.

The next example shows the role that MonitorOrderResponse elements play in an UpdateTests operation invocation:

      <MonitorOrderResponse name="Updated Original Name" folder="TestFolder"
        monitorId="263717" monitorStatus="Inactive" orderStatus="SUCCESS">
         <Message>Successfully provisioned monitor: AccountName = DEV -
           Eric Smith, MonitorName = Updated Original Name,
           MonitorId =263717</Message>
      <MonitorOrderResponse name="MultiStepTest 7/19/2012 10:15:24 AM"
        folder="TestManagement, MultiStepTests" monitorId="263733"
        monitorStatus="Active" orderStatus="FAILURE">
         <Message>Failed attempting to map monitor named MultiStepTest
            7/19/2012 10:15:24 AM to a monitor object.
            Processing of this MonitorOrder aborted.  
            System.Exception: The site product combination
            (Site = 880, Product=UTA-TRANSACTION) does not support IPv6.

The use of the MonitorOrderResponse here is parallel to its use in the previous example. That examples shows how to update two monitors in two separate transactions. The first transaction completed successfully, while the second had to be rolled back to avoid the violation of a rule.