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.
|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 Dynatrace 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.|
Contains elements as defined in the following table.
|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.|
- Element MonitorOrderResponses
The following example shows the role that MonitorOrderResponse elements play in a ProvisionTests operation invocation:
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:
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.