# Microfocus HPSM Connector

The HPSM Connector activities uses the HPSM API to communicate with the HPSM Server. For status write-back, unload programs (.unl files) are deployed on the HPSM the server as needed to communicate updates to the PMG platform.

# Microfocus HPSM Connector Configuration

To define an HP instance for workflow, add the connector configuration for HPSM. To begin a new HPSM connector configuration, access the Connector Configuration from the Workflow Designer menu under "Manage", "Connector Configuration". If one is not yet defined, add a new HPSM connector configuration by specifying the name, "HSPM.Config.xml" and clicking "Create". Below is a template to use for HPSM.

<hpsmconfig>
    <!---
    Sample HPSM Web Service Endpoit
  -->
    <!--ws_url>http://hpserver.pmg.net/sc62server/ws</ws_url-->
    <!--ws_url>http://hpserver.pmg.net/sc62server/PWS</ws_url-->

    <ws_url>http://hpserver.pmg.net/SM/7/ws</ws_url>
    <username>falcon</username>
    <password>_encryptedPasswordHere_</password>

    <!-- Possible Values: 
    V602, 
    V701,
    V710, 
    V920
   -->
    <version>V920</version>
</hpsmconfig>

Each action accepts a scenario name which needs to match the given scenario name found in this XML blob. Multiple scenarios can be defined by adding additional scenario nodes to this XML structure. This allows the connector to access multiple environments and/or use different credentials.

# Configuring HP callbacks

To configure HP to call workflow when particular events have occurred within HPSM, use HPSM unload file import. To deploy the unload file:

From HPSM, type db in the command box in the client and hit enter
From the right-hand drop-down box, choose Import/Load

Find the .unl file you wish to load ("9.20 integration.unl" and "uslaunchNEW_SM7x.unl" files)
Click the 'load FG' button in the toolbar to load them. Repeat this for each import.

# Connector Actions

The Workflow Engine provides a powerful way to enter and track entries made into your HPSM system. Below are the main actions which are shipped by default.

# Create Incident

Action Function:

This action will create an incident within HPSM.

Action Outputs:

The action will follow out one of these paths

Success

The action ran successfully

Failure

There was an issue with the action execution

Action Properties:

Standard action properties:

By default, the action ships with the below fields to be set for the new incident.

Category
Status
Contact
Location
Affected Service
Affected CI
AssignmentGroup
Assignee
Area
Subarea
Impact
Urgency
Title
Description

Additional properties:

Output Key Value

This property specifies the variable which will contain the ID for newly created incident

# Retrieve Incident

Action Function:

This action will read an incident from HPSM.

Action Outputs:

The action will follow out one of these paths

Success

The action ran successfully

Failure

There was an issue with the action execution

Action Properties:

The action ships with the below fields.

Incident ID

The ID of the incident to read

XML Result

A target object variable to store the details of the incident

# Additional Actions

Similar to Incident, example actions ship for Change and Tasks

Create Change
Reopen Change
Retrieve Change
Update Change
Create Change Task
Retrieve Change Task
Update Change Task

# Define new HPSM triggers or Processes (Optional)

# Event driven support for receiving updates from HPSM to PMG

Purpose

Web Services Transaction Integration for HPSM System allows you to send updates for entities, such as incident and change management, or any other ticket data via a simple set of web services calls.

HPSM triggers and processes should be loaded in order to listen for status updates created from Workflow side. The corresponding Workflows should be configured with "Wait for Message" activities tied to the message key of the HPSM Ticket ID.

# Manually Defining HPSM triggers and processes to send events to the PMG Platform (Optional)

All triggers and processes should have been loaded so far by the .unl scripts, here is instruction for how to add new ones.

# Triggers

From HPSM client, type "db" in the command box located at the upper left corner of the client, and enter.
In the table field, type "triggers",
Click search.
Enter data to create a new trigger or search for examples (You'll see a bunch of existing triggers, loaded by the unl script mentioned in previous section).

HPSM Trigger 1

HPSM

# Processes

The steps are similar to adding triggers.

From HPSM client, type "db" in the command box located at the upper left corner of the client, and enter.
In the table field, type "Process",
Click search.
Enter data to create a new process or search for existing examples (You'll see a list of existing triggers, loaded by the unl script mentioned in previous section).

# Deploying waitformessage.exe on HPSM server

WaitForMessage.exe is a command line tool to be called by HPSM process discussed in previous sections to send status updates to workflow. If you are interested in getting status into the workflow, you need to deploy the following 3 files on the HPSM server, [HPSM Install Directory]\server\RUN:

WaitForMessage.exe

WaitForMessage.Config.xml

PMGSPEEncryption.dll

Here is an example of the WaitForMessage.Config.xml that need to be configured:

<WaitForMessager>
    <workingdir>Working</workingdir>
    <notreadyretrytime>0.00:05:00</notreadyretrytime>
    <processingdelay>0.00:00:02</processingdelay>
    <processingstartdelay>0.00:00:05</processingstartdelay>
    <spews>
        <url>http://scdemo.pmg.net/spe/spews.asmx</url>
        <user>spews@ebita.local</user>
        <password>password</password>
    </spews>
</WaitForMessager>

Make sure the workingdir points to a directory that already exists, manually create it if necessary. It can be an absolute path, or it can be relative to the "RUN" directory.

# Modifying Write-backs to workflow from Service Manager (Optional)

The Service Manager to workflow integration has the ability to write information from Service Manager modules directly back to awaiting workflows.

The modules this integration is activated for are:

Incident
Change
Problem
Request (Both Quotes and Orders)
Interaction
Quote Line items

The process of updating the workflow works as follows:

The Service Manager module record is updated via a 'save' in Service Manager
Custom "post update" Service Manager triggers check logic as to whether to fire. The logic is currently set to fire only on the change or status or phase, depending on the module.
The triggers call custom Process records in Service Manager.
The Process records call a windows executable or a UNIX script file, depending on the Service Manager implementation. The Process record controls which parameters to pass the waiting workflow.
The "WaitForMessager" integration app fires off the update to the workflow.

# Modifying the Integration Code to Control Write-backs (Optional)

There are two places to go to modify the code for the write-backs to PMG, depending on what you wish to change.

Changing when the write-backs to Workflow fire

You may wish to change when the write-backs to the workflow fire. For example, you may wish to update the workflow when an Incident's assignment group changes instead of when the status changes.

To make this change, you will be editing the custom Integration trigger. Here are the list of triggers and their associated modules:

Incident Management: after.probsummary.update
Change Management: cm3r.post.update
Problem Management: rootcause.after.update
Request Management (Quote-update): trigger.ocmq.post.update
Request Management (Order): trigger.ocmo.post.update
Request Management (Quote-add): afteradd.trigger.ocmq.post.update

Here is an example of how to change the Incident Management trigger to fire for Assignment changes instead of Status changes.

To edit the triggers, simply type db in the command line, then enter triggers in the Table name and click search. Enter the trigger name you wish to edit in the resulting search box and click search again. This will allow you to edit the trigger record.

The first couple lines are all we are concerned about. The rest of the code in the trigger is for setting up the call to the Process record.

if (record.opened_by=="PMG")
//Only run if the logged in user is PMG
{
if (record.problem_status!=oldrecord.problem_status)
//Run if status has been updated

The first line tells the code to only run if the user is the supplied "Integration" operator record. You only need to change this if you use a different operator than the supplied operator record.

The second line is checking the old value versus the new value. If they are different, the Process record that calls the workflow integration will fire. To change the logic to check the Assignment, simply change:

if (record.problem_status!=oldrecord.problem_status)

to:

if (record.assignment!=oldrecord.assignment)

Now the write-back will occur when the assignment group changes and not when the Incident's status changes.

# Modifying the Integration Code to Control What is Sent Back to workflow (Optional)

If you wish to modify the data that is sent back to workflow from the supplied integration, you will need to edit the Process record.

Here are the Process records along with their relevant Service Manager modules:

Change Management: Integration Change
Incident Management: Integration Incident
Request Management (Order): Integration Order
Request Management (Quote): Integration Request
Problem Management: Integration Problem

To edit the Process records, simply type db in the command window and hit enter. Enter Process (note the case) in the Table Name field and click Search. Enter the Process name in the "Process Name" field and click search. Now you can edit the Process code.

Following our example from above, if we wish to send back to workflow the assignment group information, we would need to edit the payload that is sent back.

To do this, we need to understand the integration code's parameters. We'll use the windows .exe for our example.

To edit the code, click on the RAD tab of the Process record. You will see that we are calling the RAD application us.launch.external.NEW. This is a custom RAD app developed by HP for the specific use of calling server-side executables. In this case, we will be calling the WaitForMessenger.exe that facilitates the communication between Service Manager and workflow.

WaitForMessenger.exe takes three parameters as follows.

/key:IM1000006

This is the Incident number that we are sending back to the workflow. This is the Service Manager key, not the workflow key. For our example, we are sending back the current ticket's number field.

/message:Status Updated

This is the message that we are sending back to workflow as the key telling the system what happened. For our example, we will leave it as "Status Updated"

/payload:Assignment Group

This is the actual data that we will be sending back to the workflow. In this case, it will be the new assignment group.

To change the code to send back the new assignment group, we must simply change the payload. Modify the first line of code in the Pre-RAD expression from:

$params=nullsub("/key:" + number in $L.file, "NONE");
$params=nullsub("/message:Status Updated");
$params=nullsub("/payload:" + problem.status in $L.file, "NONE")

To:

$params=nullsub("/key:" + number in $L.file, "NONE");
$params=nullsub("/message:Status Updated");
$params=nullsub("/payload:" + assignment in $L.file, "NONE")

You have now successfully changed the Incident Management to workflow integration to fire back updates to workflow when the assignment group has changed in the Incident ticket, rather than when the status has changed.

← Cherwell Connector IBM Tivoli Netcool Connector →