Web Services for CA SDM - Best Practices and Recommendations

The usage of Web Service Calls in CA SDM is affected due to the following reasons: 
The usage of Web Service Calls in CA SDM is affected due to the following reasons: 
  • Performance Issues
  • CA SDM Not responding
  • CA SDM Process Memory Growth (domsrvr)
To avoid performance and other issues, ensure that you have taken into consideration the following: 
Add a Dedicated domsrvr to the Web Services Calls
If you are using CA Process Automation with CA SDM - or if any other application in your environment is integrated with CA SDM, consider installing a secondary CA SDM Server and point your Web Services Application or 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, you can make the changes in the CA SDM 
tab, under
Options Manager
Web Service
option. If the option is not installed, install it and set the new domsrvr process name to be used by web services. If you have already installed this option, edit it and adjust the domsrvr the process name. Restart CA SDM for changes to take effect. 
For Advanced Availability configuration, you can consider the following:
  • A dedicated domsrvr. Setting a dedicated domsrvr requires different configuration and planning in Advanced Availability. For more information, see Configure a Dedicated Domsrvr for SOAP Web Service - Advanced Availability
  • A dedicated Application server for Web Services calls.
  • If it is not possible to have a dedicated Application server, consider pointing the applications that are communicating with CA SDM via Web Services to the Background server, but preferentially to an Application server with less use/load.
Make use of logoff() when complete
After every set of Web Services calls, the Web Services client must perform a logoff() when complete. Web Services is intended to be an "on demand" resource, use what you need and 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. Evidences of these can be found in the
For example, we can see a login and a logout session done by the Web Services call in the following:
ada.cpp 2180 Web Services session ended 1814552582; user(ServiceDesk); IP Address; session count 0
ada.cpp 2180 web Services session created 779115035; user (serviceDesk); IP Address; session count 1
Search for
 in the 
and if it shows
Web Services session created,
it means a logoff is not used.
Each Web Services Client Must Use a Different CA SDM Web Services Policy
Ensure that the web services client is using a different CA SDM web services policy. 
Use a Different CA SDM Login for Web Services Client 
In the web services client that calls CA SDM Web Services, there is a location to enter the WSDL and username. It is not recommended that you use the CA SDM privileged user (
Service Desk
) for integrations. 
Do not allow Web Services Clients to Search with Wild Cards
In other words, if the Web Services Client does searches (that is a
), it must not allow a wild card search. In case of large MDB tables, CA SDM performance is negatively impacted as the Web Services query runs on top of the CA SDM object layer and all data retrieved by the query is loaded in the domsrv. This can cause performance issues or even make the domsrvr unresponsive and reach the max 2GB size limit on 32-bit applications. 
Avoid requesting large data sets with Web Service Method calls like "doSelect()"
For example, setting the
to return all rows has an adverse impact on the CA SDM performance. Using
 is a not recommended. Ensure that all Web Service calls are tested prior to being placed into production to see if there is any impact on the CA SDM performance. This is especially true for Web Services calls that utilize searches or requests for lists.
The maximum rows retrieved by a 
. This is by design and is non-configurable to prevent performance issues in CA SDM.
Fully Tested Web Services Client 
CA Support highly recommends that all Web Services clients must be tested fully by a user or implementer in a test environment before implementing it in the production environment. 
Distributing Web Services Requests for Multiple CA SDM Secondary Servers
It is very important to plan how the web services requests will be distributed across across multiple CA SDM Secondary Servers. You can address this by creating a routine which works as a pool of Web Services connections. The routine maintains permanent connections to CA SDM and distributes the calls among the available sessions that are recreated on a need basis.
Increase the Tomcat Memory (JVM) Size
Increase the Tomcat Memory (JVM) size to at least 1 GB. 
Increase the Tomcat 
Max Threads
By default, the max threads for Tomcat is set to
.  It is recommended that you set this value to 
when using web services. 
Cumulative Patch Implementation
If this is a new CA SDM implementation, ensure that you have installed the latest cumulative patch level. To verify the latest cumulative patch level, see CA Service Desk Manager Solutions and Patches.
The CMDB GRLoader utility uses Web Services. It is recommended to run the GRLoader utility against the CA SDM Web Services Interface on a dedicated CA SDM Secondary Server.