Monitoring SOAP and XML Transactions

A SOAP/XML transaction policy can monitor any server-to-server transaction that uses HTTP and can post files or forms (most commonly SOAP or XML but also Email or RSS feeds). SL1 sends a request and some data and then examines the result of the transaction and compares it to a specified expression match.

For each SOAP/XML policy, SL1 will collect data and create trend reports about availability, page size, download speed, lookup time, connection time, and transaction time.

Use the following menu options to navigate the SL1 user interface:

To view a pop-out list of menu options, click the menu icon ().
To view a page containing all of the menu options, click the Advanced menu icon ().

Viewing the SOAP/XML Transaction Monitoring Policies

You can view a list of SOAP/XML transaction monitoring policies from the SOAP/XML Transaction Monitoring page. The SOAP/XML Transaction Monitoring page displays the following information on each policy:

SOAP/XML Policy Name. Name of the policy.
Policy URL. URL to which the policy sends test transactions.
Policy ID. Unique, numeric ID, assigned to the policy automatically by SL1.
Device Name. Name of the device associated with the policy.
IP Address. IP address of the device associated with the policy. This is the IP address SL1 uses to communicate with the device.
Device Category. Device category of the device associated with the policy.
Organization. Organization for the device associated with the policy.

From the list of policies, you can select the checkbox for one or more policies and choose one of the following bulk actions from the Select Action drop-down at the bottom right of the page:

Delete Monitors. Deletes the selected policies from SL1. The associated reports (from the Device Reports > Performance tab) are also deleted.
Enable Monitors. Enables the selected policies so that SL1 can collect the data for these policies.
Disable Monitors. Disables the selected policies. SL1 will not collect the data specified in these policies.

Filtering the List of SOAP/XSL Transaction Policies

You can filter the list of policies on the SOAP/XML Transaction Monitoring page by one or more parameters. Only policies that meet all the filter criteria will be displayed in the SOAP/XML Transaction Monitoring page.

To filter by parameter, enter text into the desired filter-while-you-type field. The SOAP/XML Transaction Monitoring page searches for policies that match the text, including partial matches. By default, the cursor is placed in the left-most filter-while-you-type field. You can use the <Tab> key or your mouse to move your cursor through the fields. The list is dynamically updated as you type.Text matches are not case-sensitive.

You can also use special characters to filter each parameter.

Filter by one or more of the following parameters:

Policy Name. You can enter text to match, including special characters, and the SOAP/XML Transaction Monitoring page will display only policies that have a matching name.
Policy URL. You can enter text to match, including special characters, and the SOAP/XML Transaction Monitoring page will display only policies that act on a matching URL.
Policy ID. You can enter text to match, including special characters, and the SOAP/XML Transaction Monitoring page will display only policies that have a matching policy ID.
Device Name. You can enter text to match, including special characters, and the SOAP/XML Transaction Monitoring page will display only policies aligned with a device with a matching device name.
IP Address. You can enter text to match, including special characters, and the SOAP/XML Transaction Monitoring page will display only policies aligned with a device with a matching IP address.
Device Category. You can enter text to match, including special characters, and the SOAP/XML Transaction Monitoring page will display only policies aligned with a device with a matching device category.
Organization. You can enter text to match, including special characters, and the SOAP/XML Transaction Monitoring page will display only policies that have a matching organization.

Defining a SOAP/XML Transaction Monitoring Policy

You can define a SOAP/XML transaction monitoring policy for a device on the Monitors tab of the Device Investigator.

To define a SOAP/XML transaction monitoring policy:

Go to the Devices page and click the Device Name of the device for which you want to define a SOAP/XML transaction monitoring policy. The Device Investigator displays.

Click the Monitors tab.

Click Create, and then select Create System Process Policy. The SOAP/XML Transaction Policy modal appears:

In the SOAP/XML Transaction Policy modal, supply a value in each of the following fields:

Select Device. Select a device from this drop-down list to align with this policy. By default, the current device is selected in this field.

NOTE: Before you can define a SOAP/XML policy, you must decide which managed device you want to associate with the policy. You might want to associate the policy with the device where the SOAP server or XML datastore resides, but you aren't required to do so. Alternately, you might want to create a virtual device to associate with a SOAP/XML transaction policy. Although SL1 will not use the device name to determine where to send the policy data, the reports that result from the policy will be aligned with the device you specify in the Select Device field.

Policy Name. Name of the new policy. This can be any combination of letters and numbers.

State. Specifies whether SL1 should start collecting data specified in this policy from the device. Choices are:

Enabled. SL1 will collect the data specified in this policy, from the device, at the frequency specified in the Process Manager page (System > Settings > Processes) for the Data Collection: Web Transaction Verifier process.
Disabled. SL1 will not collect the data specified in this policy, from the device, until the State field is set to Enabled.

Port. Port on web-server to which SL1 will send queries. This is usually port 80 (the HTTP port), or port 443 (the HTTPS port).
Timeout. After the specified number of seconds, SL1 should stop trying to connect to the server. If the timeout period elapses before SL1 can connect to the server, an event is generated.

Proxy Server:Port. For companies or organizations that use proxy servers, enter the URL and port for the proxy server in this field. Use the format:

URL:port_number

Proxy Account:Password. For companies or organizations that use proxy servers, enter the username and password for the proxy server in this field. Use the format:

username:password

Proxy Auth Method. For companies or organizations that use proxy servers, specify the type of authentication:

Default. By default, no authentication parameters are sent. Use this option for proxy servers that do not require authentication. However, if you supply a value in another field that requires authentication, such as Proxy Username:Password, the Any authentication parameter will be used.

Basic. Most widely compatible authentication across platforms. Sends a Base64-encoded string that contains a user name and password for the client. Base64 is not a form of encryption and should be considered the same as sending the username and password in clear text.
Digest. Password is transmitted as encrypted text, but the username and content of the message are not encrypted. Digest authentication is a challenge-response scheme that is intended to replace Basic authentication. The server sends a string of random data called a nonce to the client as a challenge. The client responds with a hash that includes the username, password, and nonce, among additional information.
GSS-Negotiate. Authenticates using Kerberos and the GSS-API. Kerberos authentication is faster than NTLM and allows the use of mutual authentication and delegation of credentials to remote machines.
NTLM. NT LAN Manager (NTLM) authentication is a challenge-response scheme that is a more secure variation of Digest authentication. NTLM uses Windows credentials to transform the challenge data instead of the unencoded username and password. NTLM authentication requires multiple exchanges between the client and server. The server and any intervening proxies must support persistent connections to successfully complete the authentication
Any. Accept any type of authentication.
Any except Basic (Any Safe). Accept any type of authentication except Basic.

Post File Name. Some server-to-server transactions require data to be uploaded or sent as a Post File. For example, such a file may contain an XML or RSS feed. To send a Post File, specify a name, such as "myrss.xml" in this field. Supply the deliverable data in the Post Data Content field.
Uniform Resource Locator (URL). URL or URI of the server to send the transaction to.

Post String. If the URL is very long or requires data that cannot be transferred with a standard "GET" request (that is, data that cannot be included in the URL), you can enter a POST string in this field. The format is:

var1=val1&var2=val2&var3=val3

If you are going to include more than one variable/value pair, separate each pair with an ampersand (&). For example, suppose you want to send values for the fields "Birthyear" and "Value". You could enter the following in the Post String field:

Birthyear=1980&Value=OK

NOTE: If you want to include non-alphanumeric characters in the Post String field, make sure you encode the characters using appropriate URL encoding.

Content Encoding. Specifies the encoding method used for the request. Choices are:

text/xml
application/x-www-form-urlencoded
multipart/form-data
application/soap+xml
text/xml;charset=utf-8

Request Method. Specifies whether the request will be sent as an HTTP POST or an HTTP GET request.
Post Data / Content. Data to send to the remote server, such as the body of a SOAP request. If you entered a value in the Post File Name field, enter the deliverable data in this field.
Auth Account:Password. For websites that pop-up a dialog box asking for user name and password, use this field. Enter the username and password in this field. Use the format username:password.

HTTP Auth Method. For websites that require authentication, use one of the selected methods:

Default. By default, no authentication parameters are sent. Use this option for websites that do not require authentication. However, if you supply a value in another field that requires authentication, such as HTTP Auth Username:Password, the Any authentication parameter will be used.

Basic. Most widely compatible authentication across platforms. Sends a Base64-encoded string that contains a username and password for the client. Base64 is not a form of encryption and should be considered the same as sending the username and password in clear text.
Digest. Password is transmitted as encrypted text, but the username and content of the message are not encrypted. Digest authentication is a challenge-response scheme that is intended to replace Basic authentication. The server sends a string of random data called a nonce to the client as a challenge. The client responds with a hash that includes the username, password, and nonce, among additional information.
GSS-Negotiate. Authenticates using Kerberos and the GSS-API. Kerberos authentication is faster than NTLM and allows the use of mutual authentication and delegation of credentials to remote machines.
NTLM. NT LAN Manager (NTLM) authentication is a challenge-response scheme that is a more secure variation of Digest authentication. NTLM uses Windows credentials to transform the challenge data instead of the unencoded username and password. NTLM authentication requires multiple exchanges between the client and server. The server and any intervening proxies must support persistent connections to successfully complete the authentication
Any. Accept any type of authentication.
Any except Basic (Any Safe). Accept any type of authentication except Basic.

SSL Mode. Specifies whether SL1 should use SSL when communicating with the httpd service.
Expression Check #1. Regular expression to search for. This can be any alphanumeric value, up to 128 characters in length.
Expression Check #2. Another regular expression to search for. Can be any alphanumeric value, up to 128 characters in length.
Custom Header Elements. Allows you to include a custom header with your transaction. Enter the header in this field.

Compatibility. Specifies the type of application SL1 will be communicating with on the server. Choices are:

Default. Standard HTTP/HTTPS.
SOAP. SOAP-based requests.
Cisco AXL. Cisco AXL interface.

Click Save.

Example SOAP/XML Transaction Monitoring Policy

In this example, the policy monitors SOAP transactions to a VMware ESX server at "https://%D/sdk/vimService.wsdl". VMWare ESX servers accept SOAP requests.
The policy uses cURL to send a SOAP request to the ESX server.
The SOAP request includes a SOAP API "RetrieveServiceContent". This API ensures that SL1 can communicate with the VMware server and returns information about the services available on the VMware server.

Defining a SOAP/XML Transaction Monitoring Policy in the Classic SL1 User Interface

There are two places in SL1 from which you can define a monitoring policy for SOAP/XML transactions:

From the Device Manager page (Devices > Device Manager):

In the Device Manager page, find the device that you want to associate with the monitoring policy. Click the wrench icon () for the device.
In the Device Administration panel, click the Monitors tab.
From the Create menu in the upper right, clickCreate SOAP/XML Transaction Policy.

Or:

From the SOAP/XML Transaction Monitoring page (Registry > Monitors > SOAP-XML Transactions):

In the SOAP/XML Transaction Monitoring page, click the Create button.

The SOAP/XML Transaction Policy modal appears.

For information about completing the fields in the SOAP/XML Transaction Policy modal, see the section on Defining a SOAP/XML Transaction Policy.

Editing a SOAP/XML Transaction Monitoring Policy

To edit a SOAP/XML transaction monitoring policy:

Go to the Devices page and click the name of the device for which you want to edit a monitoring policy. The Device Investigator displays.
Click the Monitors tab.
Find the policy you want to edit and click its wrench icon (). The SOAP/XML Transaction Policy modal appears.
In the SOAP/XML Transaction Policy modal, you can change the values in one or more of the fields described in the section on Defining a SOAP/XML Transaction Policy.
Click Save.

Editing a SOAP/XML Transaction Monitoring Policy in the Classic SL1 User Interface

There are two places in SL1 from which you can edit a monitoring policy for SOAP/XML transactions:

From the Device Manager page (Devices > Device Manager):

In the Device Manager page, find the device that you want to associate with the monitoring policy. Click the wrench icon () for the device.
In the Device Administration panel, click the Monitors tab.
In the Monitoring Policies page, find the policy you want to edit and click its wrench icon ().

Or:

From the SOAP/XML Transaction Monitoring page (Registry > Monitors > SOAP-XML Transactions):

In the SOAP/XML Transaction Monitoring page, find the policy you want to edit and click its wrench icon ().

The SOAP/XML Transaction Policy modal appears.
In the SOAP/XML Transaction Policy modal, you can change the values in one or more of the fields described in the section on Defining a SOAP/XML Transaction Monitoring Policy.
Click Save.

Executing a SOAP/XML Transaction Monitoring Policy

After creating or editing a SOAP/XML transaction policy, you can manually execute the policy and view detailed logs of each step during the execution.

NOTE: After you define a SOAP/XML transaction monitoring policy and enable the policy, SL1 will automatically execute the policy every five minutes. However, you can use the steps in this section to execute the policy immediately and see debug information about the execution of the policy.

To execute a system process monitoring policy:

Go to the Devices page and click the name of the device for which you want to execute the monitoring policy. The Device Investigator displays.
Click the Monitors tab.
Find the policy you want to run manually and click its lightning bolt icon ().
The Session Logs modal opens while the policy is executing. The Session Logs page provides detailed descriptions of each step during the execution. This is very helpful for diagnosing possible problems with a policy.

Executing a SOAP/XML Transaction Monitoring Policy in the Classic SL1 User Interface

To execute a SOAP/XML transaction monitoring policy in the classic SL1 user interface:

In the SOAP/XML Transaction Monitoring page, find the policy you want to run manually.
Click the lightning bolt icon () to manually execute the policy.
While the policy is executing, SL1 spawns a modal called Session Logs. The Session Logs page provides detailed descriptions of each step during the execution. This is very helpful for diagnosing possible problems with a policy.

Deleting a SOAP/XML Transaction Monitoring Policy

You can delete a SOAP/XML policy from the Monitors tab of the Device Investigator. When you delete a monitoring policy, SL1 no longer uses the policy to collect data from the aligned device. Deleting a monitoring policy will also remove all data that was previously collected by the policy.

To delete a SOAP/XML transaction monitoring policy:

Go to the Devices page and click the name of the device for which you want to delete the monitoring policy. The Device Investigator displays.
Click the Monitors tab.
Find the policy you want to delete and click its bomb icon (). A confirmation prompt appears.
Click OK.

Deleting a SOAP/XML Transaction Monitoring Policy in the Classic SL1 User Interface

You can delete one or more SOAP/XML transaction monitoring policies from the SOAP/XML Transaction Monitoring page. When you delete a monitoring policy, SL1 no longer uses the policy to collect data from the aligned device. Deleting a monitoring policy will also remove all data that was previously collected by the policy.

To delete a SOAP/XML transaction monitoring policy in the classic SL1 user interface:

Go to the SOAP/XML Transaction Monitoring page (Registry > Monitors > SOAP-XML Transactions).
In the SOAP/XML Transaction Monitoring page, select the checkbox(es) for each SOAP/XML policy you want to delete. Click the checkmark icon () to select all of the SOAP/XML policies.
In the Select Action menu in the bottom right of the page, select Delete Monitors.

Click the Go button to delete the selected SOAP/XML monitoring policies.
The policy is deleted from SL1. The associated reports (from the Device Reports > Performance tab) are also deleted.

Viewing Reports on a SOAP/XML Transaction Policy

See the section on Viewing Performance Graphs for information and examples of reports for monitoring SOAP/XML transactions.

Viewing Raw Data from a SOAP/XML Policy

You can view the raw data sent from SL1 to the external URL and the raw data returned to SL1. This feature can be helpful when troubleshooting a policy.

To view raw data from a SOAP/XML policy:

In the SOAP/XML Transaction Monitoring page, find the policy you want to view raw data for.

Click the page icon () to the far left in the table.
The Results Page Dump modal appears. This page displays the raw data sent to the external URL and the raw data returned to SL1.