AppD Monitoring UAT - ITPAM SC/PAM Requests
search cancel

AppD Monitoring UAT - ITPAM SC/PAM Requests

book

Article ID: 207790

calendar_today

Updated On:

Products

CA Process Automation Base

Issue/Introduction

We need to set up an AppD monitor to check how much time it takes for a Service Catalog request to reach PAM backend platform, and if a given threshold is exceeded generate an alert.

We would need to provide the request details such as a URL or the code executed when those calls are made. Do you know from where we can start with? (referring to the code and calls)

Is there any API we can use to accomplish this?

Environment

Release : 4.3

Component : Process Automation

Resolution

I found several areas of interest in the documentation for Service Catalog that might provide pieces to the puzzle:

Integrate CA Service Catalog with CA Process Automation Manually: https://techdocs.broadcom.com/us/en/ca-enterprise-software/business-management/ca-service-management/17-3/troubleshooting1/troubleshooting-ca-service-management/integrate-ca-service-catalog-with-common-components-manually/integrate-ca-service-catalog-with-ca-process-automation-manually.html

Troubleshooting CA Service Catalog: https://techdocs.broadcom.com/us/en/ca-enterprise-software/business-management/ca-service-management/17-3/troubleshooting1/troubleshooting-ca-service-catalog.html

Maintain Log Files: https://techdocs.broadcom.com/us/en/ca-enterprise-software/business-management/ca-service-management/17-3/troubleshooting1/troubleshooting-ca-service-catalog/maintain-log-files.html

Request Management Using CA Service Catalog: https://techdocs.broadcom.com/us/en/ca-enterprise-software/business-management/ca-service-management/17-3/using/request-management/request-management-using-ca-service-catalog.html

These are the timeout values between various components:

  1. Cluster membership is established using multicast heartbeats. All data communication happens over TCP. This membership timeout value is set to 3000ms
  2. Timeout between Catalog and EEM is 10 seconds (which is configured under Administration-Configuration)
  3. We use Apache DBCP as a connection pool to acquire DB connections and timeout is configured to 3 minutes (which is configured in applicationContext.xml) and other data sources have default DBCP timeout value. We should also make sure network latency between Catalog nodes and DB server should be minimum.
  4. Catalog communicates with PAM via SOAP calls and default Axis timeout is 60 seconds
  5. Default timeout of Catalog SOAP calls is 60 seconds.

Average network latency (ping time) between these components should be ranging from 0-5ms.

Q:

What we’re trying to figure out is related to SC and PAM requests timing.

We would need to monitor the requests submitted in SC going to PAM, the idea is to be warned when a request gets stuck or fails to reach PAM backend so we can check before the user engage us. For that we would need to compare the “Creation Time” in the front end against the “Start Time” in the back end, for example:

This is a common request in SC:

Same request in PAM:

I guess the 2 hours difference is due to time zone configurations. According to this the request took 7 secs to reach the backend, this is the information we would want to monitor, so in case a request takes more that “X“ secs threshold to reach PAM an alert is created.

The monitoring would be configured by our AppD specialist, but we would need to know what elements are involved in the creation/start times.

A:

In order to find the time difference between PAM process invocation and request submission, they can use the created date (for both request and PAM process). In general, PAM invocation will happen at various request status values. So if they want to find the time difference between two status values, they can use usm_request_status table (contains all status transition records of a request).

They can also configure Request SLA to schedule alerts when there is an SLA violation. Please refer to below documentation for more details:

https://techdocs.broadcom.com/us/en/ca-enterprise-software/business-management/ca-service-management/17-2/using/request-management/request-management-using-ca-service-catalog/request-management-from-an-administrator-perspective/manage-request-slas.html

Q:

-What’s the default status of a request when it reach the backend (PAM)?

-This SLA parameter “$elapsed_time$” checks the SC submission time and PAM process creation or it checks only when the request is completed in PAM?

-What would happen with scheduled start requests?

A:

-What’s the default status of a request when it reach the backend (PAM)?

   There is no default status for requests running the PAM process. PAM process can be triggered at any stage in request lifecycle through Event-Rule-Actions

-This SLA parameter “$elapsed_time$” checks the SC submission time and PAM process creation or it checks only when the request is completed in PAM?

    In SLA “$elapsed_time$” indicates the time taken for the request to reach from one status to another status for which that SLA is created.

-What would happen with scheduled start requests?

    Does it mean to initiate an SRF in PAM directly?

SLA will only give the time($elapsed_time$) it takes to move request from one status to another, but not the time it takes to reach PAM (or initiate an SRF)

In order to get this information, we should rely on usm_object_wf_instance_ref and usm_request table to get the exact time difference

Ex: To get the time difference between request submission and first SRF trigger time, this is the query to find it.

select ur.request_id,uowr.created_date as srf_time, ur.created_date as request_submitted_time from usm_object_wf_instance_ref uowr LEFT OUTER JOIN usm_request ur on ur.request_id=uowr.object_id1

 

Similarly we can find the time difference between a request status and its corresponding SRF triggered time using usm_request_status and usm_object_wf_instance_ref.