When using SOAP Web Services Policy limits in CA Service Desk Manager (CA SDM), how are the time frames determined?

Document ID : KB000019514
Last Modified Date : 14/02/2018
Show Technical Document Details

Question:

If you currently have various interfaces connecting to CA SDM via web services, and have created a separate web service policy for each interface and have them using the 'loginservice()' method to ensure the SOAP Web Services policy is enforced, a question may arise related to the values set in each policy file and how the transactions per hour is determined.

Is it on the round hours? For example, 1AM - 2 AM?
Perhaps it is determined by the initial transaction time. So if the first call was at 1:32am, it would be valid until 2:32am?
Maybe it is 1 hour from the login time?

This document helps to provide clarification on how the transaction counter is determined when using SOAP Web Services Policy.

Answer:

The counter starts for the individual policy at the moment it is first used to create a session id (SID).

Unfortunately, there is no tracking table for this information. If a request is declined because it was over the policy limit, the requester will get an exception.
There is no queuing that happens server side in this scenario.

Some integrations leverage login() to create the SID, which has no limits on what it can do.

Alternatively, integrations can leverage the duplication_id if they are calling createTicket, so it adds an entry to existing ticket vs. creating a new incident for what may be the same outage.

The CA Spectrum solution operates like this. Each time it creates a ticket for a device or alarm type, it will populate the duplication_id field so you can have it update the same ticket if the event is for the same device still being down.

There is a table (which may help) that stores the map between the duplication_id and the ticket # called "xent_map".
However, it does not store how many transactions were made in the past hours per policy etc...

One solution may be to use the name of the impacted service in the duplication_id attribute, in case it does not make sense to create multiple tickets for the same service being down.

The web services policy problem types (also called error types) could be configured to look for an existing ticket and what action you want it to take in that case (for example, adding an activity log).

Unfortunately, there is no way to determine how much time is left in the queue before it the Web Services Policy will allow creating new tickets.