Remedy Quality Management integration analysis

1. Introduction

This document analyzes Remedy Quality Management [RQM], owned by Peregrine Systems, and estimates the work required to integrate it with Perforce using the P4DTI Integration Kit.

The intended readership is development staff and management deciding whether to fund such an integration.

This document is not confidential.

2. Background

Remedy Quality Management [RQM] contains a defect tracking system. It is an application of the Remedy Action Request System (RARS) and I believe that it is a component of the Remedy Customer Relationship Management System (RCRM).

RQM uses a three-tier architecture consisting of a database server (Oracle, Sybase and Microsoft SQL Server are supported), a "workflow data server" which applies the business rules (runs on Microsoft Windows NT, Sun Solaris or Hewlett-Packard HP-UX), and a client.

3. Analysis

This analysis follows the steps in [GDR 2000-10-16].

3.1. Extending the Remedy schema

To create a relation (form or schema in Remedy) using the Remedy API, use ARCreateSchema and then make a sequence of calls to ARCreateField to add fields to the relation.

To create a record (entry in Remedy), use ARCreateEntry.

*** It looks as though you are supposed to create a schema first and then create fields. But indexes have to be specified when you create the schema. So how do you do that?

3.2. Extending the issue relation

RQM looks like it has three kinds of issue relation: qual_Defect, qual_ProductIssue and qual_RFE [Remedy 2000b] (presumably "RFE" stands for "Request for enhancement").

We need to adopt a design that doesn't preclude replicating all of these. I suggest extending the issue relation by creating a separate table (as in the Bugzilla integration) — this has the advantage that P4DTI data is localized. This table would have fields for the issue relation and the issue id within that relation: this pair would be the primary key for the table.

The three kinds of issue relation are mostly identical: the field IDs are consistent between the relations. So most or all of the code could be shared.

3.3. Discovering what's changed

All Remedy tables have a "Last Modified Date" field (field id 6) that we might use to implement the second solution in [GDR 2000-10-16, 4.6].

*** This method is subject to race conditions. Does the Remedy API have transaction processing facilities that we could use?

*** This method might be very inefficient.

3.4. Distinguishing replicated changes from other changes

We might be able to use the "Last Modified Date" field to implement the third solution in [GDR 2000-10-16, 4.7].

*** This method is subject to race conditions. Does the Remedy API have transaction processing facilities that we could use?

3.5. Making changes on behalf of defect tracker users

Most Remedy API functions have a control parameter as their first argument. This parameter contains login and session information. So the Remedy API can be used to perform operations on behalf of a Remedy user and permissions are checked accordingly.

*** However, in order to perform an operation on behalf of another user using this feature, the P4DTI will need their password. This is unlikely to be acceptable.

3.6. Perforce users who don't have licences in the defect tracker

*** Don't know.

3.7. Python interface to Remedy

Here are six ways of getting at Remedy from Python:

• Use the third-party COM interface to the Remedy 4.5 API [Benesch 2000-09] and the Python COM interface [ActiveState 2001], [Hammond 2000-01, page 193]. See [Widowfield] for some advice on how to use this.

  Advantages: Uses the Remedy API. Someone's already gone to the work of understanding the API.

  Disadvantages: No licence to use [Benesch 2000-09] — but we may be able to negotiate one; only runs on Windows.

• Use ODBC to connect directly to the database, using [eGenix 2001] as the ODBC driver on Unix.

  Advantage: runs on Unix as well as Windows.

  Disadvantages: cost of Python ODBC interface on Unix; bypassing the Remedy API means extra complexity in handling the schema and possible reliability problems.

• Make our own Python wrapper around the Remedy API [Remedy 2000-08-04], using the Python/C interface [van Rossum 1999-04-13].

  Advantages: runs anywhere we build it; uses API; no licensing issues.

  Disadvantages: need to decide which Python versions to support (or else P4DTI administrators may have to compile and build the interface themselves); significant cost.

• Use the Remedy Enterprise Integration Engine [Remedy 2001].

  Disadvantage: Looks complex, costly. Don't know if it's suitable or if it will work.

• Use JPython, JNI and Remedy's Java APIs [Widowfield 2002-02-20].

  Disadvantages: JNI may not be portable to some Unix platforms. P4DTI not supported or tested with JPython.

• Use Remedy's Perl interface, calling Perl from Python [Widowfield 2002-02-20].

Here are my best guesses as to how to perform necessary tasks using the Remedy API [Remedy 2000-08-04]:

• To query a relation and return a list of matching records, use ARGetListEntryWithFields, specifying the query as an ARQualifierStruct (it will probably be most convenient to build a little parser to make these qualifier structures).

3.8. Providing a Remedy interface to Perforce relations

*** Don't know. This might be possible through the Remedy API by modifying the defect schemas or creating appropriate join schemas.

A. References

B. Document History

Copyright © 2001 Ravenbrook Limited. This document is provided "as is", without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this document. You may make and distribute verbatim copies of this document provided that you do not charge a fee for this document or for its distribution.