The PagerDuty Remedy integration is a binary that provides various helper functions to the BMC Remedy tool. The behavior and requirements of this tool are dictated solely by BMC Remedy behavior, so use of it as a general tool is discouraged.
Currently, there are four main functions required to make the Remedy integration go. They are documented below.
The trigger
subcommand is used to trigger a new PagerDuty Incident. Example:
./pd-remedy trigger --api-key KEY --incident-key REMEDY_INCIDENT_NUMBER --description "This is a new incident" --details "This is the incident details" --service-id PAGER_DUTY_SERVICE_ID --assignee ASSIGNEE_USER_ID --requester USER_EMAIL --client REMEDY_CLIENT_VALUE --client-url REMEDY_INCIDENT_URL
It requires api-key
, incident-key
, description
, service-id
and requester
. assignee
, details
, client
, and client-url
are optional. If not specified, client
will default to "BMC Remedy" and client-url
will default to https://www.bmc.com.
The acknowledge
subcommand is used to acknowledge open PagerDuty Incidents. Example:
./pd-remedy acknowledge --api-key KEY --incident-id PAGER_DUTY_INCIDENT_ID --requester USER_EMAIL --client REMEDY_CLIENT_VALUE --client-url REMEDY_INCIDENT_URL --retry NUMBER_OF_TIMES_TO_RETRY --delay-time NUMBER_OF_SECONDS
It requires api-key
, incident-id
and requester
. If the incident-id
is not known incident-key
can be used. client-url
, retry
and delay-time
are optional.
If not specified, client
will default to "BMC Remedy" and client-url
will default to https://www.bmc.com.
retry
and delay-time
allow user to specify the number of times to try to find the existing PagerDuty incident and the number of seconds to delay before the next retry attempt. retry
requires incident-key
.
The resolve
subcommand is used to resolve open PagerDuty Incidents. Example:
./pd-remedy resolve --api-key KEY --incident-id PAGER_DUTY_INCIDENT_ID --requester USER_EMAIL --client REMEDY_CLIENT_VALUE --client-url REMEDY_INCIDENT_URL --retry NUMBER_OF_TIMES_TO_RETRY --delay-time NUMBER_OF_SECONDS
It requires api-key
, incident-id
and requester
. If the incident-id
is not known incident-key
can be used. client
, client-url
, retry
and delay-time
are optional.
If not specified, client
will default to "BMC Remedy" and client-url
will default to https://www.bmc.com.
retry
and delay-time
allow user to specify the number of times to try to find the existing PagerDuty incident and the number of seconds to delay before the next retry attempt. retry
requires incident-key
.
The get-iles
subcommand is used to retrieve the history and status of a particular PagerDuty incident using Incident ID (based on PagerDuty Incident ID) or Incident Key (based on Remedy Incident Number). If both Incident ID and Incident Key are provided, it will use Incident ID. An error is thrown if the Incident ID or Incident Key is invalid. delay-time
is optional. It allows user to specify the number of seconds to delay before performing the subcommand.
./pd-remedy get-iles --api-key KEY --incident-id PAGER_DUTY_INCIDENT_ID --incident-key REMEDY_INCIDENT_NUMBER --delay-time NUMBER_OF_SECONDS
These are functions to retrieve or validate id's.
The get-id
subcommand is used to translate a PagerDuty Incident Key into a PagerDuty Incident ID. The Incident ID is required during incident-specific API actions (such as retrieving incident updates), and is useful for generating links to the PagerDuty Incident after it has been submitted. delay-time
is optional. It allows user to specify the number of seconds to delay before performing the subcommand. PLEASE NOTE: This subcommand will return an empty string and exit with code 0 if no incidents match the given key. This is a Remedy-ism.
./pd-remedy get-id --api-key KEY --incident-key REMEDY_INCIDENT_NUMBER --delay-time NUMBER_OF_SECONDS
The get-validate-id
subcommand is used to verify a PagerDuty Incident ID. The Incident ID is required during incident-specific API actions (such as retrieving incident updates), and is useful for generating links to the PagerDuty Incident after it has been submitted. PLEASE NOTE: This subcommand will return an empty string and exit with code 0 if no incidents match the given key. If a match is found, it will return the validated PagerDuty Incident ID. This is a Remedy-ism.
./pd-remedy get-validate-id --api-key KEY --incident-id PAGER_DUTY_INCIDENT_ID
The get-ill-created-at
subcommand is used to retrieve the created date for the latest log entry of the PagerDuty incident. This subcommand will return a numeric Unix time if successful. Otherwise, it will return -1. delay-time
is optional. It allows user to specify the number of seconds to delay before performing the subcommand.
./pd-remedy get-ill-created-at --api-key KEY --incident-id PAGER_DUTY_INCIDENT_ID --delay-time NUMBER_OF_SECONDS
The get-service-id
subcommand is used to translate a PagerDuty Service Name into a PagerDuty Service ID. The Service ID is required during incident-specific API actions such as creating incident. PLEASE NOTE: This subcommand will return an empty string and exit with code 0 if no services match the given key. This is a Remedy-ism.
./pd-remedy get-service-id --api-key KEY --service-name PAGER_DUTY_SERVICE_NAME
The get-service-escalation-id
subcommand is used to retrieve the PagerDuty Escalation Policy ID corresponding to a PagerDuty Service ID. The Escalation Policy ID is required during incident-specific API actions such as reassigning incident. PLEASE NOTE: This subcommand will return an empty string and exit with code 0 if no services match the given key. This is a Remedy-ism.
./pd-remedy get-service-escalation-id --api-key KEY --service-id PAGER_DUTY_SERVICE_ID
The validate-escalation-policy-id
subcommand is used to validate a PagerDuty Escalation Policy ID. If a match is found, it will return the validated Escalation Policy ID. PLEASE NOTE: This subcommand will return an empty string and exit with code 0 if no escalation policy match the given ID. This is a Remedy-ism.
./pd-remedy validate-escalation-policy-id --api-key KEY --escalation-policy-id PAGER_DUTY_ESCALATION_POLICY_ID
The get-user-id
subcommand is used to translate a PagerDuty User Email Address into a PagerDuty User ID. The User ID is required during incident-specific API actions such as setting value for assignee during incident updates. PLEASE NOTE: This subcommand will return an empty string and exit with code 0 if no users match the given key. This is a Remedy-ism.
./pd-remedy get-user-id --api-key KEY --user-email USER_EMAIL
The test-connection
subcommand is used to test the connection to the PagerDuty instance. Returns "ok" if connection is working or "failed" otherwise.
./pd-remedy test-connection --api-key KEY
Incidents can be updated due to reassignment. Reassignment can mean a change of escalation policy or reassignment to a different assignee. NOTE: Cannot perform reassignment using both assignee and escalation policy at the same time.
For the examples below, incident-key
can be used if incident-id
is not available. The mode trigger
can be set to acknowledge
if needed.
This will set the PagerDuty incident status to triggered
and PagerDuty will reassign the incident based on the escalation policy. The examples use acknowledge
but trigger
can also be used.
pd-remedy.exe acknowledge --api-key KEY --incident-id PAGER_DUTY_INCIDENT_ID --escalation-policy-id PAGER_DUTY_ESCALATION_POLICY_ID --requester USER_EMAIL --client REMEDY_CLIENT_VALUE --client-url REMEDY_INCIDENT_URL
The status of the PagerDuty incident remains as acknowledged
when assignee is provided.
pd-remedy.exe acknowledge --api-key KEY --incident-id PAGER_DUTY_INCIDENT_ID --assignee ASSIGNEE_USER_ID --requester USER_EMAIL --client REMEDY_CLIENT_VALUE --client-url REMEDY_INCIDENT_URL
- Fork this repo and clone it to your workstation.
- Create a feature branch for your change.
- Write code and tests.
- Update the docs.
- Push your feature branch to github and open a pull request against master.