Web Services Best Practices for CA Service Desk Manager (CA SDM)
search cancel

Web Services Best Practices for CA Service Desk Manager (CA SDM)


Article ID: 9370


Updated On:


CA Service Management - Service Desk Manager CA Process Automation Base


This article describes Best Practices when using CA Service Desk Manager (SDM) Web Services.

It is very common to see SDM affected by the usage of Web Services calls.

The most common effects are:

  • Performance issues
  • SDM dying
  • SDM process memory growth (domsrvr)


CA Service Desk Manager 17.1 and higher.


(01) Add a dedicated domsrvr to Web Services Calls

If your site is using CA Workflow or CA Process Automation with CA SDM heavily - or any other application integrated with SDM, such as Spectrum, Nimsoft Monitor -, you should consider installing a secondary CA SDM Server and point your Web Services Application or Service Desk Integration that makes use of Web Services to the secondary CA SDM Server. Additionally, it is recommended to add a webengine/domsrvr pair for each secondary server used for this reason. 

For conventional installations, this setting is done in the SDM Administration tab, under Options Manager:

If the option is not installed, Install it and set the new domsrvr process name to be used by Web Services. If you already have this option installed, you should Edit it and adjust the domsrvr process name. Next, it is required that SDM be recycled so the change takes effect.

Related to this topic, it is important to mention some considerations when working with SDM in AA:

(a) Setting a dedicated domsrvr server in AA requires different steps.

(b) An alternative is to have a dedicated Application server for Web Services calls. 

(c) If it is not possible to have a dedicated Application server, you should consider pointing the applications communicating with SDM via Web Services to the Background server, but preferentially to an Application server with less use/load.

(02) Make use of logoff() when complete.

After every set of Web Services calls, the Web Services client should perform a logoff() when complete.  Web Services is intended to be an "on demand" resource - use what you need, then close the connection when possible, as opposed to re-using the same session id for hours at a time or leaving the session inactive.   The "Web Services Session Timeout" option is a configurable option in CA SDM Options Manager. 

Evidence of these can be found in the stdlog (14.1) or jsrvr (17.x). In the example below, we can see a login and a logout session done by a Web Services call:

If searching for “sda” in your stdlogs only shows “Web Services session created” it means a logoff is not being used.

(03) Each Web Services Client should use a different CA SDM Web Services Policy. 

(04) Each Web Services Client or CA solution using Web Services should use a different Service Desk login.

In each CA solution that calls CA SDM Web Services, there is a location to enter the WSDL and username. It is not recommended to use the CA SDM privileged user (i.e. Service Desk) for the integrations. 

(05) Support recommends not allow Web Services Clients to search with wildcards. 

In other words, if the Web Services Client does searches (i.e. doquery or getlist), it should not allow searches with a '*'.  If this is done against a large MDB table, CA SDM performance will be negatively affected. 

The reason for that is the Web Services query will run on top of the SDM object layer, and thus all data retrieved by the query will be loaded in the domsrvr in use. This can cause performance issues or even domsrvr to die due to reaching 2GB of size (which currently is its allocation limit, for being a 32 bit application) and dies trying to allocate more memory.

(06) Avoid requesting large data sets with Web Service Method calls like "doSelect()". 

For example, setting "maxRows" -1 to return all rows will impact CA SDM performance.  Using "-1" is not recommended.  Be aware that all Web Service calls should be tested prior to being placed into production to see if there is any impact on CA SDM performance.  This is especially true with Web Services calls that utilize searches or requests for lists. 

Note that the maximum number of rows retrieved by a doSelect is 250. This is by design and non-configurable to prevent performance issues to SDM.

(07) It is fairly easy to negatively impact CA SDM performance using a Web Services client. 

Broadcom Support highly recommends any and all Web Services clients should be tested fully by the customer or implementer in a QA environment. 

(08) The CA SDM Web Director does not work for Web Services. 

Planning how Web Services requests will be distributed across multiple CA SDM Secondary Servers is very important. One way to address this is by creating a routine that will work as a pool of Web Services connections. The routine will keep permanent connections to SDM and will distribute the calls among the available sessions, which will be recreated as needed.

(09) Before implementation, the Tomcat Memory (JVM size) should be increased to as much as 1 GB.

Please refer to:

Increase Java JVM Memory Heap Allocation

(10) The Max Threads for Tomcat should be also be increased when using Web Services. 

By default, it is set to 75.  CA Support recommends setting this value to 300 - do not change it to a value higher than this.

(11) Always ensure that you are on the latest CA SDM Cumulative Patch Level if this is a new implementation.

(12) If CMDB GRLOADER is used, please keep in mind that this utility uses Web Services. 

In a heavily used CA SDM environment, it is recommended to run GRLOADER against the CA SDM Web Services Interface on a dedicated CA SDM Secondary Server. 

(13) If using CA Workflow or CA Process Automation, consult the SOAP API Reference for instructions and best practices, as this uses the CA SDM Web Services API.