Working with Remedy

Caution

Test the script(s), processes and/or data file(s) thoroughly in a test environment, and customize them to meet the requirements of your organization before attempting to use it in a production capacity.  (See the legal notice here)

 

Note: The workflow sample mentioned in this article can be downloaded from the Opalis project on CodePlex:  https://opalis.codeplex.com

 

Overview

The Opalis Integration Pack for BMC Remedy contains a handful of activities that enable Opalis workflow authors to interact with Remedy in a very generic fashion. These activities require a very basic understanding of BMC Remedy in order to perform basic transactions with the system. These workflow examples are intended as starting-points for building workflows.

Please note that this Integration Pack requires a connection to BMC Remedy in order to author/edit activities. As such, the workflows are highly unlikely to be something an author could import and edit. Rather, one can import and view the samples, using them as a reference as new ones are created in a workflow.

Workflows

“1. Create Incident”

There are actually many different ways to create an Incident in BMC Remedy using the Opalis Integration Pack. Generally speaking, one would configure a “Create Request” activity against one of the HPD forms. This sample consists of a single workflow activity that will create an incident in Remedy.

The one typically used is the HPD:HelpDesk form which in most cases will mimic the form one actually sees on the screen when an incident is manually created in the BMC Remedy UI. That said, the HPD:HelpDesk form is optimized for a human interacting with the BMC Remedy UI and not for a source of automation. The form is subject to various rules internal to Remedy that can make it awkward (not impossible) to utilize using the Opalis “Create Request” activity.

Alternately, BMC provides the HPD:IncidentInterface_Create form, which is a somewhat simplified version of the HPD:HelpDesk form designed for a “programmatic” interface.

Notice how the form is filled in with the same sort of information as one would provide in the Remedy UI. With a few possible exceptions, this form should behave the same way as the HPD:HelpDesk form. However, workflow authors are generally presented with use-cases described in terms such as “this is how we do it in BMC Remedy…”

It is typical for users to describe their interaction with a system in terms of their primary interface with that system, in this case the BMC Remedy UI. In most situations one should be able to reproduce the desired behavior using the HPD:IncidentInterface_Create form, however if for some reason this can’t be done try using the HPD:HelpDesk form. Note that one might have to call the Remedy ticket number generator to create an Incident ID if one uses the HPD:HelpDesk form.

“2. Create Change from Template”

BMC Remedy has a concept of a “Template” which standardizes the creation of requests. As applied to Changes, a Template is a way to properly fill out a Change with appropriate information. Moreover, a template is typically used to assign sequences of Tasks to a workflow, which is key since the Tasks are the actual work being performed in the change (the Change record is little more than categorization data… it’s the Tasks where all the actual work is performed and tracked).

If one simple creates a Change (without using a Template) via the “Create Request” activity the workflow author assumes a tremendous amount of responsibility. To begin with, the correct Change type must be selected. Then the appropriate categorization data must be provided to the form. Finally, sequences of Tasks will generally have to be created and then associated to the Change record (this is non-trivial to do using the “Create Request” activity since it requires an understanding of the internal relationship forms in Remedy that generally aren’t manipulated by users of the application).

A much easier way is to just create a change from a Template. Templates will already have selected the correct form, pre-populated relevant field values for the change, and more importantly will provide and populate all relevant supporting records (such as Task sequences, CI dependencies, etc) and relate them to the created Change request.

The sample workflow illustrates a typical sequence for creating a Change from a Template via the Opalis Integration Pack for BMC Remedy:

Workflow Walk-Through

Get Template

First, you must get the unique entry ID for the Template. This can be tricky information to collect. You can create a “Get Request” activity to produce a test query of the “CHG:Template” form looking for the template by its name. Once you find the Template note its Change Template ID. This allows for a specific query for the Template in BMC Remedy. Note that the Change Template ID should be a very static value. In this sample the ID is just hard-coded into the workflow.

Create Infra Change ID

You will also need an Infrastructure Change ID created. This is done by calling the “CHG:CFG Ticket Num Generator” form. The result is a BMC Remedy Change ID. Once you have a Change ID and the Template information you can proceed to create the Change.

Get Blank RFC

Begin by getting the “blank” change request (“RFC”). This simply fetches the Change record that matches the Infrastructure Change ID that was just created.

Create RFC from Template

Now the actual Change is created. Populate any form values that you wish. The template will fill out the rest of the Change once the record is created.

Notice how at the end of the Create Record activity that the field “Template ID” is populated with the InstanceID of the Template you wish to use (this was identified when you did the query for the Template ID at the beginning of the workflow). When BMC Remedy sees this field has a value it will trigger internal logic that will apply the template to the newly created record. This logic will populate field values, create Tasks, etc.

Reread RFC

Since Remedy applied the template, the field values have no doubt been modified, so you want to re-read the Change to make sure all the Opalis Published Data values are up-to-date. This step is optional but highly recommended if you plan to make use of data from the change later in the workflow.

“3. Launch AIE Job”

BMC Atrium CMDB features a component called the Atrium Integration Engine (“AIE”). AIE is used to interface with external systems and broker data into the BMC Atrium CMDB. So, for example, if one had an external asset management system that produced an export of laptops deployed in the last several days, AIE could be used to query this export and manage adding/updating records in BMC Atrium appropriately.

It’s not uncommon for AIE to be called from Opalis since workflows could be built that interact with external systems that in turn interact with AIE. Referencing the prior example, Opalis could trigger the export of the inventory of laptops and then trigger the AIE job to import the data.

Triggering an AIE job is not difficult, but there are a few things one needs to be aware of. First, it certainly helps to know the correct form you should use to create a new job entry. Second, since the Create Request will return automatically, it helps to know how to check the AIE job log to determine if the AIE request has finished.

The sample workflow provided is designed to trigger an AIE job. The workflow doesn’t require any inputs as it is hard-coded to a specific job. You may wish to create a version of this workflow that is more generic. This sample has been made very specific so the details of the individual workflow components are easier to understand.

The “Format Current Time” activity is taking the time the workflow runs and reformatting the timestamp to be consistent with what AIE expects to see in its internal job table. The “Create AIE Job Entry” activity then creates an entry in the “Application Pending” form that will cause the selected AIE job (specified in the form) to be initiated. Note that there might be a delay from when the request is entered into the table and when the job begins.

Now all you have to do is check to see when the job has finished. This is accomplished by the “Check Job Status” activity with the looping property set. This query looks for a specific job that matches the known create date. The query will return a “0” if the job is not yet finished. It will return a non-zero value if the job is done.

The Looping properties are key since they define the exit criteria for the loop. You would generally not want to create a loop condition without some sort of effective exit term. In this case you limit the looping to either the job returning (a non-“0” record count) or 10 attempts. The loop is set for a 60-minute retry interval and hence this would be a 10 minute timeout. You would need to adjust these values accordingly to match the expected run-time for a given AIE job.

 

 

Share this post :