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 PPM with QC/ALM. The workflows provided by ALM bundles include such steps.
Note: A PPM decision step that depends on QC/ALM (that is, a 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 PPM request status changes, the QC/ALM requirement or defect status also changes if the same PPM status exists for the QC/ALM requirement or defect. For example, if the 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 PPM, QC/ALM waits for a response, and the QC/ALM record remains locked until QC/ALM receives the response. Meanwhile, if 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 PPM workflow should not contain successive steps such that the first causes a PPM request to advance based on a change in QC/ALM status, and the second causes PPM to attempt to update QC/ALM. Make sure there is an intervening step between two such steps.
When a PPM request is integrated with a QC/ALM project, you can use a change in the QC/ALM status to cause the PPM request to advance through an active decision step to the next step in the associated 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 PPM can automatically advance from the step in the PPM workflow that is awaiting that notification.
Conversely, whenever the status of a PPM request changes, 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 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 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 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 PPM workflow.
If the QC/ALM status does not appear in the list of valid request status values in PPM, PPM sends an error message to QC/ALM, the QC/ALM status reverts to its previous value, and the 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.