Hello All,
Here in New York we had our first 3-day heat wave last week with 3 consecutive days over the 90 degree mark - Welcome to Summer! Things are heating up here at CA too with the many new features planned for the new versions of our products due out in the future - stay tuned and make sure you subscribe to the message boards so you can keep up-to-date on all the news and announcements, and of course for tips and tricks for those new features and versions right here on the Tuesday Tips message board!
This week, I want to share some information with you which can also be found in the CA Service Desk Manager 12.5 Green Book (in which nearly all of the content applies to later versions too), as well as in the implementation guide for all versions of the product. That is, the definition of the different components of the Service Desk product architecture.
We all know that there are many processes that all work together to make CA Service Desk Manager perform all of its functions and features, and sometimes we can all get confused as to what each of these does, where (on what server) it is, or can, be located, and which ones may be located on multiple servers in an environment.
So without further delay, lets jump right into it here...
First, lets look at, and describe all of the different CA Service Desk Manager components or processes:
Daemon Manager (pdm_d_mgr)
Starts process sets as defined in the startup file, pdm_startup.tpl. By default, the daemon manager tries to start a failed component up to 10 times. To check the status of all CA SDM components, use the pdm_status utility. The pdm_d_refresh utility instructs the daemon manager to start a new cycle of 10 attempts to start any process marked as previously failed.
Remote Daemon Proctor
When you install a secondary server, the pdm_proctor_nxd process is installed as the CA Service Desk Manager Remote Daemon Proctor service. When the primary server starts, the Daemon Manager instructs the Remote Daemon Proctor to connect to the Message Dispatcher. The Daemon Manager then instructs the Remote Daemon Proctor to start components on the secondary server as defined by Process Sets in the startup file pdm_startup.tpl. For this reason, the proctor service on the secondary server must be running before starting up the CA Service Desk Manager primary server.
Message Dispatcher (sslump_nxd)
Acts as a common bus or message passing system. Components that need to communicate with each other first register with the Message Dispatcher. When a component sends a message, the Message Dispatcher delivers it to those components that have registered to receive that type of message. If two components communicate so much that it would be inefficient to pass the messages through the Message Dispatcher, they create a fast channel between them. You can view a list of registered components using the slstat utility.
Database Agent (platform_agent)
Performs SQL queries on the database. Database agents adhere to the logical schema of CA SDM and translate the SQL at this level to the physical database platform SQL.
**Note: The database agent detects momentary disconnection and failed queries, and attempts to reconnect and communicate with the database. This is only meant for short outages, such as for a brief network outage and momentary disconnection. It is not meant for long outages such as shutting down a database service for maintenance, and so forth. The agent will only retry the connection for a defined number of times (the default is 3 times), and only for a short time period of a few minutes. If the outage is longer than a few minutes, the agent will stop trying to connect, and CA SDM must be recycled after the database has been made available again.
Agent Provider (platform_prov_nxd)
Starts or stops database agents. By default, a number of agents are running. If more are required to handle the number of database queries, the Agent Provider starts them. If the system no longer requires so many database agents, the Agent Provider terminates the unnecessary ones.
Virtual Database (bpvirtdb_srvr)
Enables the operation of multiple Object Managers. All Object Managers running on primary or secondary servers connect to the Virtual Database, which arbitrates their access to database agents. For example, when retrieving a new range of ticket reference numbers, the Virtual Database helps ensure that only one Object Manager at a time accesses the table containing the reference numbers. The Virtual Database also performs caching of database information for Object Managers.
Continuous Archive and Purge (arcpur_srvr)
Runs your archive and purge rules as configured by the CA SDM administrator.
Database Monitor (dbmonitor_nxd)
Monitors changes to common tables in the CA MDB, for example ca_contact.
KPI Daemon (kpi_daemon)
Manages the retrieval, organization, and storage of key performance indicator (KPI) metric data. It runs continuously. When the specified refresh time of a KPI query is reached, the KPI daemon interacts with other system components to collect data, and then stores the resulting metrics in the database.
License Manager (license_nxd)
Manages CA Technologies licensing for the product.
Mail Daemon (pdm_mail_nxd)
Sends outbound email notifications.
Mail Eater (pdm_maileater_nxd)
Accepts inbound email for ticket creation and updates.
Notification Manager (bpnotify_nxd)
Manages notifications in a Windows environment.
Spell Checker (lexagent_nxd)
Performs spell checking as requested by clients.
Text API Daemon (pdm_text_nxd)
Creates and updates tickets by external interfaces, such as command line and email.
Timed Event (animator_nxd)
Runs the delay times of events. In an implementation that has many service types or contracts, there may be many active events that the Timed Event engine needs to track. In this situation, you should dedicate the primary server Object Manager entirely to the Timed Event engine. You can configure other Object Managers on the primary or secondary servers for product access as appropriate.
Time-To-Violation (ttv_nxd)
Calculates projected violation times for service types.
Proctor Daemon (pdm_proctor_nxd)
Starts and restarts CA SDM components, as instructed by the Daemon Manager, on primary and secondary servers. When you install a secondary server, the pdm_proctor_nxd process is installed as the CA SDM Remote Daemon Proctor service. When the primary server starts, the Daemon Manager instructs the Remote Daemon Proctor to connect to the Message Dispatcher. The Daemon Manager then instructs the Remote Daemon Proctor to start components on the secondary server as defined by Process Sets in the startup file pdm_startup.tpl.
Object Manager (domsrvr)
Acts as the server process of CA SDM. When you install a primary server, by default, two Object Managers are installed: one for connections to the product, and one dedicated to the Web Screen Painter. This allows you to test your modifications without affecting the production environment. When you install a secondary server, you can configure additional Object Managers. There must always be a default Object Manager running on the primary server to which clients such as the Timed Event engine can connect. The Object Manager also caches various records and tables for clients. If you use pdm_userload to manipulate these records, you can also use the pdm_cache_refresh utility to make the Object Manager retrieve the new data.
Method Engine (spel_srvr)
Runs SPEL code, event, macros, and so forth for an Object Manager. We recommend that every Object Manager be run with its own method engine.
Login Server (boplogin)
Performs operating system user account validation and contact record lookups using the System Login field to match a user with an access type. If your business provides CA SDM to other client businesses, you can place the Login server on a secondary server at a single client location. External authentication can then be enabled in access types. This avoids creating user accounts for your clients on your business systems.
LDAP Virtual Database (ldap_virtdb)
Interfaces with an LDAP directory.
Knowledge Management Daemon (bpebr_nxd)
Performs knowledge base searches. Upon CA SDM startup, the bpebr_nxd daemon caches Knowledge Document data in its memory from the database.
Knowledge Management/Keyword Search Indexing Daemon (bdeid_nxd)
Indexes the knowledge base.
Knowledge Management FAQ Ratings Daemon (bu_daemon)
Calculates FAQ ratings for Knowledge Management.
Knowledge Report Card Daemon (krc_daemon)
Performs calculations for the Knowledge Management Knowledge Report Card (KRC) feature. This feature enables analysts and managers to display different matrix views of their knowledge contributions and provide feedback about which documents are most effective. The information provided can be used in a variety of ways to improve the processes of creating knowledge documents and providing the best support to customers.
Knowledge Management Daemon (kt_daemon)
Manages knowledge base administration and knowledge management logic. It also manages notifications and the document approval process.
Repository Daemon (rep_daemon)
Manages the attachment repositories for CA SDM and the Knowledge Management/Keyword Search Daemon.
Version Control Daemon (pdm_ver_nxd)
Synchronizes the schema files between a primary and secondary server to ensure that they are using the same schema.
Apache Tomcat Web Server (javaw)
Enables certain features to be implemented, regardless of whether Microsoft Internet Information Server (IIS) is used as the web server for access to CA SDM. These features include CA Workflow, Graph Items, Attachments, and Web Services. The Apache Tomcat web server can be administered with the apache Tomcat controller (pdm_tomcat_nxd).
Web Engine (webengine)
Connects to web browsers through a pdmweb cgi running on a Microsoft IIS or Apache Tomcat web server. There must be a web engine for WSP on the primary server so WSP Schema Designer can write schema files. Web engines are the true client of an Object Manager used by web browser to access the product. Web engines cache .htmpl web forms for connected users. You can manipulate the cache using the pdm_webcache utility and see connection statistics using the pdm_webstat utility.
Web Services
Lets applications communicate over HTTP to various servers regardless of operating environment. The web services are installed during the CA Service Desk Manager installation on the primary servers.
Web Directors
Used for load balancing within the software itself to distribute the user traffic among specified web engines. Web directors are optional and more than one can exist on the primary server, secondary servers, or all.
Support Automation
Support Automation is installed automatically on all operating environments for both primary and secondary servers. To expose and use Support Automation to implement automated support, configure the Support Automation components during the post-installation configuration step, pdm_configure, on your primary or secondary servers. One Support Automation main server must exist to run Support Automation, but you can configure optional Support Automation socket or proxy Support Automation servers to distribute process load.
CA CMDB Visualizer
CA Service Desk Manager installs CA CMDB Visualizer by default on all operating environments for both primary and secondary servers. To expose and use this component, configure it during the post-installation configuration step, pdm_configure, on your primary or secondary servers.
Now that we have described all of the different components and process within CA Service Desk Manager, lets take a look at where these processes are located by default (on which server), which ones can be moved to another server, and which ones can exist on multiple servers. This diagram will make it easy to see which processes are required on which servers, which processes can be moved, and which ones can have multiple instances on multiple servers:
**NOTE: Process with a "*" next to them must only have one instance of that process present in the environment, meaning that it can only exist on one server, NOT on multiple servers.
Additionally, CA Service Desk Manager may have the following additional add-on software components installed as well (and integrated with CA Service Desk Manager):
CA EEM (CA Embedded Entitlements Manager) — Provides an alternative to the default validation that the host operating system performs. CA EEM is only required for CA Workflow and CA IT PAM integration. The intention is for CA EEM to act as a single repository of the user and access policies for your organization. Therefore, we recommend that you install a single copy of CA EEM in your architecture. The Java Development Kit (JDK) is a required component for CA EEM 8.4 sr03; install it on every CA EEM server.
CA Workflow — Provides a high performance, scalable workflow management system to help automate your CA Service Desk Manager business processes. There can be only one CA Workflow instance in the CA Service Desk Manager architecture.
CA Business Intelligence (also called CABI or BOXI) — Enables the viewing and designing of CA Service Desk Manager reports.
CA MDB — Provides the central database for CA Service Desk Manager. This database is a required component and only one MDB can exist in the CA Service Desk Manager architecture, although other CA solutions can share it.
CA IT PAM — Provides a high performance, scalable workflow management system to help automate your CA Service Desk Manager business processes with sophisticated orchestration of resources and actors. CA Service Desk Manager can map to one CA IT PAM instance at a time to link categories to process definitions.
SO, in closing, I hope that this post will offer some clarification on all of the different CA Service Desk Manager processes, and how they fit into a CA Service Desk Manager architecture.
Thanks! Don't forget to check back again soon for more great tips and tricks!
Have a great week!
Jon Israel
Principal Support Engineer
Certified CA Service Desk Administrator
CA Technologies
Images used in this post: