Change HP Sprinter 11.52 Port for communication with HP ALM

If the port for HP Application Lifecycle Management (ALM) server is different from the default one 8080, this could bring some issues with HP Sprinter 11.52 because it is using that port.

In this situation this port could be changed with editing some configuration files in HP Sprinter 11.52.

Follow these steps in order to change the Sprinter port:

1. Navigate to program files of the client machine.

2. Open ~/HP/Sprinter/Bin

Find the following three configuration files:

– Sprinter.exe.config

– SprinterAgent.exe.config

– SprinterRTE.exe.config

In each file find <add key="InspectionPort" value="8080"/> and change the port to some other available port.

Save the changes and try to start Sprinter.

Fix the inconsistent permissions problem after an upgrade

In ALM 11.00 and above, you can experience the below issue in a project upgraded from QC 10.00, or a project newly created in ALM 11.00.

1.Manifestations of the problem:

a. In Customization->Groups and Permissions, group G is permitted to update field F in entity E but I cannot update this field.

b. In Customization->Groups and Permissions, group G is permitted to update entity E but I cannot update it.

c. In Customization->Groups and Permissions, group G is permitted to update entity E but I cannot copy-paste it.

d. Or any other similar manifestations saying Customization allows update but update is prevented in work in the modules themselves.

2. In ALM (11.00 and above) permission model, once a group G has at least the update permission of a field F of a entity E, ALM should regard the update permission of E is also granted to G .

However for some upgraded projects or new projects, by default we have the group G with the update permission of a field F but without the update permission of its parent entity E.

This is what we call “Inconsistent Permission”.

3. Look in the Customization->Groups and Permissions UI to make sure that it is actually permitted to update entity E. After that, the below SQL can help to identify any permission inconsistency on a specific table.

Replace ‘<E>’ with the entity table name, and run this SQL in site admin, then if there’s any inconsistency on the entity permission, the current permission (TB_GRANT_MODIFY) and the correct permission (CORRECT_PERMISSION) will be listed.


In this case, the solution below might be relevant.


The fix for this problem is contained in ALM 11 and ALM 11.5 patches.

The fix uses a verifier and repairer that find inconsistencies for the given tables and fix them by allowing entity update where it finds the update of at least one of their fields is permitted.

Note: the fix will always change the entity update permission from no to yes. So prior to use it, please make sure you really want to grant the entity update permission to this group.

In order to use this fix, we need to:

Upgrade patch level:

· In ALM 11, upgrade the patch level to at least patch 14.

· In ALM 11.5 and further, upgrade the version to at least ALM 11.52 patch 1.

Instructions for ALM 11 patch 14 or later and for ALM 11.52 patch 1 or later :

1. Backup your projects.

2. Add the required site parameter – Add a site parameter named “ENTITY_TABLE_NAMES_FOR_FIXING_UPDATE_PERMISSIONS_INCONSISTENCY”. The value of this parameter should be a comma separated list of the entity table names corresponding to the entities for which a problem was found in the TABLES table. For example: “BUG,REQ”.

3. Repair all relevant projects – This will update the TABLES table to fix the inconsistencies that were found.

Note: it’s possible to run “Repair” on a domain level – a one-click operation for all the projects in a domain.

4. Return server to original state – Delete the site parameter added in step 2.

Note: You MUST return server to original state prior to project upgrade, otherwise some side effect will take place during the project upgrade and will cause the upgraded project to be unstable.

5. Once done, the problem should be fixed – Run the SQL above to see that no consistency exists for those entities and check the functionality itself to see that the issue was fixed.

Known limitations of using BPTEE with ALM 11 and UFT 11.50

BPTEE in ALM 11 is partially supported with UFT 11.50.

Ø The execution of the tests from Test Plan module in ALM is supported.

Ø Execution of tests from Test Lab module will work only when "Detect changes" checkbox is turned off. Currently there are no plans to fix this limitation. In order to minimize customers’ impact, a code change is planned. During the execution of flows from Test Lab module, UFT should ignore the option "Detect Changes". This change is planned to be included in UFT 11.53.

Ø Recording of Flow with UFT and BPTEE is not supported. This is done from the button "Learn Flow" that appears in Test Script tab in Test Plan.

ALM 11: Configuration Wizard does not allow reinstallation

If Application Lifecycle Management (ALM) 11 needs to be reinstalled then the existing qcsiteadmin_db database which is already on the current version needs to be used for the reinstallation.

The Configuration Wizard cannot complete and results in error "Upgrade to 11.0 is not supported" .

In order to instruct the Configuration Wizard to bypass the check of the Site Admin database version, it is necessary to make the below steps. Then the ALM 11 Configuration Wizard runs without facing the mentioned limitation:

1.Navigate to the ALM Platform installation directory, open the run_after_finish.bat or file for editing.

2.Locate the rem set SKIP_VALIDATIONS line, and do the following:

a) Remove the rem command.

b) After the equal sign, add -wSaSchemaValidator :

set SKIP_VALIDATIONS=-wSaSchemaValidator

3.Save and close the file.

4.Run the file.

5.During the Re-configuration process choose “Upgrade existing schema” option.

NOTE: This limitation is fixed in ALM 11.5 Configuration Wizard which provides a new option "Connect to existing schema / second node". That allows to reconnect to the same qcsiteadmin_db and reinstall ALM 11.5.

ALM versioning during bulk operations

Creating many records in ALM (Application Lifecycle Management) by copying, importing, or enabling version control on project will result in the following behavior – the first version will be auto-generated when the entity version info is requested for the first time, e.g. one user attempts to view the versions, or check out the entity.

This behavior will be noticed only when performing bulky operations with entities. Here is a more detailed how flow of the process:

If Person A does the copy or import and Person B reviews the data (without checking out/in) then the record’s initial version contains the info of Person B as the actor.

This is true, for the “History/Versions and Baselines” part, because person B is the one who first requests the version info. However, the “History/Audit Log” (another mechanism not related to versioning) should contain the original information, i.e., the changes made by person A. It can provide another way for tracking changes, rather than versioning.