Skip to main content
Kinetic Community

Kinetic Task ARS Shim

The Kinetic Task ARS Shim application allows Remedy ARS to initiate communication to the Kinetic Task engine.

Kinetic Task / ARS Shim Application

Since no current version of Remedy (up through 9.x) can consume a RESTful web service, BMC Remedy cannot natively communicate with Kinetic Task.  If you have a Kinetic Request Remedy Edition implementation, you most likely do not need the shim application.  Otherwise, this Shim application is required to allow Remedy-to-Kinetic Task communication.

Components

The Shim includes two components

  • The Remedy portion which includes a limited number of forms (5) and related workflow (30, including one menu). This creates a single repository in Remedy where any/all Remedy forms (i.e., HPD:Help Desk, CHG:Infrastructure Change) can push data for processing
  • The Web Application which polls one of the new Remedy forms to retrieve pending activities and pass it on to the Kinetic Task application

Implementation Instructions

Follow these instructions for each environment (Development, QA/Test, Production, etc.)

  1. Download the kinetic-task-ars-shim.war file.
  2. Put the .war file into the deployment directory of an existing servlet container (i.e., "webapps" directory in a Tomcat installation).  A good place to put this is the same location where Kinetic Task web application is running.
  3. Download the Kinetic Task ARS Shim Workflow.def  
  4. Using Remedy Developer Studio, import the .def file into your Remedy environment. Your system may require a mid-tier recache after this def has been successfully imported.
    There are 5 forms, 1 menu, and 29 pieces of workflow in the Def file.  These should import as all new workflow.

Web Configuration Instructions

  1. Once the web application has been deployed, go to <web server name>:<port>/kinetic-task-ars-shim to access the configuration screen (the default username/password is admin/admin)

Remedy Properties

The Remedy properties tell the Task Shim how to connect to the Remedy server.

  1. Although the first entry says Remedy Server URL, it is just the Remedy Server name that should be listed (e.g., remedy.clientname.com).
  2. Add port number if appropriate.  Leave '0' if you use port mapper.
  3. Add program number if appropriate.  Leave '0' if you do not use one.
  4. For the Remedy user name, a Remedy user account with Admin rights is necessary. (The Remedy forms imported earlier have no permissions. Customizing the Remedy forms would allow a user with lesser permissions to be used)

Task Properties

The Task properties section tells the shim what Remedy forms contain the data.  To support complex configurations, these are configurable.  For a normal implementation using the forms that were imported earlier, use these values:

  • Task Server Remedy Table: KS_TSK_TaskServer
  • Task Remedy Join Table: KS_TSK_TaskApiCall_TaskApiCallLock_join
  • Task Remedy Lock Table: KS_TSK_TaskApiCallLock
  • Task Remedy Table:  KS_TSK_TaskApiCall

Server Properties

Contains configuration options for log level, log file size, administration user name and password.  Change these values as appropriate for your installation or keep the default values.

Remedy Configuration Instructions

  1. Using Mid-Tier, access the KS_TSK_TaskServer form
  2. For each Kinetic Task system that this environment (i.e., prod, dev, qa) will be interacting with you need to create an entry on this form.  Normally, there is just a single system for each environment, but there are situations where multiple task systems may be used.  If there is a single task system, but multiple task servers, the base URL should point to the load balancer that has been configured.
    Only two fields are required to be completed for each entry:

Remedy Form Integration

The final step to complete the installation is to implement appropriate workflow to get data into the KS_TSK_TaskSeed form.  (Note: The KS_TSK_TaskSeed form will properly encode the data it receives and automatically push it to the KS_TSK_TaskAPICall form. The KS_TSK_TaskAPICall form is polled by the web application.)

In the SAMPLE_KS_TSK_TaskSeed_Filters.def file are three sample filters. One is for triggering new task processes, one is for updating deferred task nodes, and one for sending a complete trigger:

  • +KS_HPD_Create_Trigger-KS_TSK_TaskSeed
  • +KS_HPD_Update_Trigger-KS_TSK_TaskSeed
  • +KS_HPD_Complete_Trigger-KS_TSK_TaskSeed

These samples are written against the HPD:Help Desk form. They are active filters but should be disabled immediately.  They are NOT suitable for use as is; they must be modified or used as templates.

Items to review include:

1. Source Name field.  For the Update and Complete triggers, the source name needs to match the Kinetic Task source name that initiated the Remedy ticket.  This field should match the source name from your Kinetic Task implementation.  NOTE:  The source name is "-" (a dash) when initiated from a Routine.  For ease of use, it is recommended that Remedy tickets always be created from routines instead of main task trees.

2. Task Server field.  The Task Server field needs to match what you entered in the Remedy form KS_TSK_TaskServer.  The sample forms use 'Kinetic Task', but if you used a different option, update the handlers appropriately.

3. SRID qualification.  The SRID field is also used by the SRM application.  If you are also using that application, there could be situations where you want to use a special qualification using the SRID field.  Such as: NOT 'SRID' LIKE "RQT%" so no actions happen when the SRID field includes data populated from the SRM application.

 

Sample Work Order filters are also located in the attached SAMPLE_KS_TSK_TaskSeed_Filter_WorkOrder.def. They also need to reviewed before use, paying attention to the items listed above.  Included filters are:

  • +KS_WOI_Create_Trigger-KS_TSK_TaskSeed
  • +KS_WOI_Update_Trigger-KS_TSK_TaskSeed
  • +KS_WOI_Complete_Trigger-KS_TSK_TaskSeed