Configuring Workflows

The guidelines to configure a workflow for integration are as follows (see the Demand Management Configuration Guide for details as necessary):

  • Make sure the workflow includes execution steps and decision steps that enable the integration of OpenText PPM with QC/ALM. The workflows provided by ALM bundles include such steps.

    Note: A OpenText PPM decision step that depends on QC/ALM (that is, a OpenText PPM request that is supposed to be updated by a QC/ALM status change) can have its status changed in QC/ALM only by a user who has Administrator rights.

  • If you need to customize a workflow to create a defect or a requirement, we recommend using the execution steps that are included in the ALM - Defect Template with Quality Center Integration workflow, instead of building the steps yourself.

    To create defects or requirements in QC/ALM, your workflow must include one of the following execution steps that uses the stated special command:

    • To create defects, the ALM - Create QC Defect execution step with the ksc_create_defect_in_QC special command

    • To create requirements, the ALM - Create QC Requirement execution step with the ksc_create_requirement_in_QC special command

    In the Properties tab of the workflow execution step, specify a value in the Request Status field that is valid for QC/ALM, for example, 1-Requirements Setup Completed when creating a requirement.

    Once an execution step has created a requirement or defect in QC/ALM, then every time the OpenText PPM request status changes, the QC/ALM requirement or defect status also changes if the same OpenText PPM status exists for the QC/ALM requirement or defect. For example, if the OpenText PPM request status changes to Open, the QC/ALM requirement or defect status will also change to Open, as long as Open is one of the values allowed in the status field of the requirement or defect.

    For more information about configuring workflow steps, see the Demand Management Configuration Guide.

    Note: After QC/ALM sends an update to OpenText PPM, QC/ALM waits for a response, and the QC/ALM record remains locked until QC/ALM receives the response. Meanwhile, if OpenText PPM advances to the next workflow step and attempts, for example, to update (synchronize) QC/ALM with a new request status, QC/ALM rejects the update since the record is locked.

    Therefore, a OpenText PPM workflow should not contain successive steps such that the first causes a OpenText PPM request to advance based on a change in QC/ALM status, and the second causes OpenText PPM to attempt to update QC/ALM. Make sure there is an intervening step between two such steps.

  • When a OpenText PPM request is integrated with a QC/ALM project, you can use a change in the QC/ALM status to cause the OpenText PPM request to advance through an active decision step to the next step in the associated OpenText PPM workflow.

    For example, when the QA manager sets the status of a QC/ALM project to indicate that test planning is complete, the associated request in OpenText PPM can automatically advance from the step in the OpenText PPM workflow that is awaiting that notification.

    Conversely, whenever the status of a OpenText PPM request changes, OpenText PPM notifies QC/ALM, and (assuming the new status is valid in
    QC/ALM) QC/ALM users can take appropriate action such as starting tests.

    To enable this functionality, you must design the workflow decision steps such that the following three items have the same values:

    • QC/ALM status that will trigger the advancement in the OpenText PPM workflow.

    • Transition name (which is specified as the Meaning field of the validation value for the workflow step source) for the active decision step in the OpenText PPM workflow.

      We recommend that you give the Meaning field of the transition a value that is unique to this transition, that is, a value that does not exist anywhere else in the workflow. When this value becomes assigned to the ITG Status field in Quality Center version 10.00 or the PPM Status field in ALM version 11.00 or later, the OpenText PPM workflow advances if the value matches a valid transition in an active workflow step. If the workflow has more than one active step and the Meaning is not unique, the workflow could advance to an unintended step.

    • Request Status field in the destination step in the OpenText PPM workflow.

    If the QC/ALM status does not appear in the list of valid request status values in OpenText PPM, OpenText PPM sends an error message to QC/ALM, the QC/ALM status reverts to its previous value, and the OpenText PPM workflow does not advance.

    For example, in the following portion of the ALM - Plan Tests Sub WF subworkflow, the transition from step 7 to step 8 is called 1-Requirements Setup Completed.

    If you double-click step 8 (the destination step), the Properties tab of the Workflow Step window shows that the value in the Request Status field is also 1-Requirements Setup Completed.

    All three items—the QC/ALM status, the transition, and the Request Status field of the destination step—have the same value. Therefore, if the QA team changes the QC/ALM status to 1-Requirements Setup Completed when step 7 is active, the workflow will advance to step 8.

    If you need to change the value of the Request Status field of the destination step, in the Properties tab of the Workflow Step window for that step, specify the new value in the Request Status field and click OK.

    If you need to change the Meaning field that defines the transition name, right-click the preceding decision step and select Edit Source; in the Validation section of the Decision window, click Open; click the validation value (row) of interest and click Edit; specify the new value in the Meaning field; click OK to close all open windows. For more detailed information, see the Demand Management Configuration Guide.