- 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. Refer to document TEC1364225 - How to configure a dedicated DOMSRVR for SOAP Web Service in Advanced Availability CA Service Desk Manager (CA SDM)configuration for instructions on how to do it.
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.
- 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.
Evidences of these can be found in the stdlog. 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.
- Each Web Services Client should use a different CA SDM Web Services Policy.
- 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.
- Support recommends to 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.
- 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 a 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 are 250. This is by design and non-configurable to prevent performance issues to SDM.
- It is fairly easy to negatively impact CA SDM performance using a Web Services client. CA Support highly recommends any and all Web Services clients should be tested fully by the customer or implementer in a QA environment.
- 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 which 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.
- Before implementation, the Tomcat Memory (JVM size) should be increased to as much as 1 GB.
Please refer to: TEC491277 - Steps to increase the JVM Heap Size for Tomcat in CA Service Desk Manager
- The Max Threads for Tomcat should be also be increased when using Web Services.
By default, it is set to 75. CA Support recommends to set this value to 300 - do not change it to a value higher than this.
Please refer to TEC598584 - How to increase Tomcat Max Threads on CA Service Desk Manager (SDM) 12.x and 14.1.
- Always ensure that you are on the latest CA SDM Cumulative Patch Level if this is a new implementation.
To verify the latest Cumulative Patch Level consult the CA Service Desk Manager Solutions & Patches page at Support.ca.com.
- If CMDB GRLOADER is used, please bare 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.
- 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.