Ashwini Kalghatagi

DOORS-RDS Integration - All in One Configuration+Scenarios

Ashwini R Kalghatagi ‎ 1 Comment ‎ 4,698 Views

INTRODUCTION

DOORS – Dynamic Object Oriented Requirement System

It is a requirements management tool that is used for capturing, tracking, analyzing, and managing user requirements.

RDS – Rational Directory Server

It is designed to provide centralized common infrastructure services for User/Groups management for supported rational tools such as IBM Rational DOORS®, IBM Rational Focal Point™, IBM Rational System Architect.

LDAP – Lightweight Directory Access Protocol

It is an application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network

DOORS –RDS Integration Overview:

Provides following benefits by having DOORS User Management through RDS –
1. Provide Centralized User Management across Rational tools so maintenance of all user details is easy
2. Provides Security In terms of not having direct access to add/delete/edit users directly from DOORS, User should have access to LDAP to modify any user.

RDS can be configured in 2 Modes –

Standalone Mode – Here User/Group details resides within RDS machine
Corporate Mode – Here RDS fetches User/Group details from the LDAP

RDS supports following 4 LDAPs

Active Directory Server (ADS)
Tivoli Directory Server (TDS)
Oracle Directory Server (ODS)
Forest ADS

DOORS uses RDS with Tivoli variant (Other products like synergy uses Apache version of RDS)

STEP BY STEP CONFIGURATIONS & SCENARIOS (CORPORATE MODE):

After Installing RDS and RDA access RDA using following web URL :

http:// <IP Address of RDS machine>:8080/webrda/rda

Following screenshot shows RDA without configuring any LDAP partitions

Here there are no users listed as there is no LDAP partition is configured

Configure RDS with LDAP partition by following below steps :

Right click on Corporate Partition and create a new partition :

Fill In LDAP details in below displayed dialogue :

Partition Name – Can be anything

HostName – IP of the LDAP server

Port Number – Differs depending on which LDAP we are using and whethe rusing secured port or non secured port.

1389/389 is used for non secured port

1636/636 is used for secured port

Note – Enable SSL checkbox should be checked only when you configure for secured partition

From LDAP machine fetch the complete DN name of the user (This user can be either Administrator user or any other user on LDAP). In LDAP machine if you right click on any user and access its properties, it will have field with name Distinguish Name which provides DN value.

User Log On Attribute - This can be CN, UID or SAMAccount

Every User will have its full name and some common name and short name and that’s how the Log On attributes is configured for the partition and accordingly the User name is displayed in RDA and in DOORS.

Ex : Suppose IBM employee name is John Young, his blorepd name can be JohnY and his synergy user name can be YoungJ.

Configure Primary Search Base :

Here partition can be either configured as Primary Search Base or Multiple Search Base.

Multiple Search Base is basically used for Meta Group Scenarios; this will be covered in details later in this document.

Basically LDAP users are under hierarchy as per organization structure.

Ex : In IBM we have department for Software’s and under which we have many groups like Rational, Websphere, Tivoli etc..

So here IBM is the root and under that there is Organization Unit (OU) called Software’s under which we either have some more OU’s or directly groups for each department.

Primary search Base is fetched from complete DN name of any user on LDAP and we should remove CN=<name> part from the complete DN.

So here RDS gets configured to the particular OU provided in search base and RDS can see only users and groups under this OU.

Partition is configured successfully

Now check the Users and Group list in RDA.

This displays all Users and Groups under the OU from configured LDAP.

User Group Migration From DOORS to RDS :

XML Migration is supported from DOORS to RDS - Export users/groups from DOORS into XML format and then use RDS Migrate feature to migrate it to RDS
Migration is basically required to migrate the User Roles and Access Rights that are provided in DOORS for the particular user on LDAP.
Scenario – Example to migrate one user and group from DOORS to RDS –

Create a User and group in DOORS with the same name of User/Group present on LDAP. While creating users provide same name to User Name and System Username fields
Provide User Roles to Users Ex: Database Manager, Project Manager etc
Create project and module in DOORS and provide few access rights to the Users and groups created above

From DOORS export these users using DOORS Project->Properties->Export Users Groups with Corporate mode
From RDA access Console->Migrate option

Provide the details of file where DOORS users are migrated.

Upload the file and Finish

Migration Analysis windows shows the users listed in different category. Here in this case LDAP users already listed with this name, So DOORS users to be migrated are listed under Duplicate Users

Select all users and Merge and perform Migrate operation.

From third part software JExplorer check the User ID created for Users before and after migration :

Before Migration :

After Migration :

Note -

After Migration RDS creates one more ID for that user which will have information on User Role and set of 1 and 0 digits representing access rights which is tied to the Database ID in DOORS. For different DOORS DB different ID gets created, that means same user can get migrated for different DOORS DB. SO the ID generated helps to maintain the access rights and roles of the user with specific DOORS DBs.

Similarly perform Group Migration also
After Group Migration is done you can see specific Node is created under Database in RDA . This node is specific the particular DBID of DOORS.

Change DOORS to RDS Mode

From DOORS Project Properties ->Change

Select Rational Directory server

Provide server Host as IP of RDS server

Provide Server Port as 1389 for Non secured and 1636 for secured connection(Check the check box)

Perform Test Connection and relaunch the client

DOORS is launched in RDS Mode

DOORS User cannot create any more users from DOORS now
DOORS User and Group lists all users and groups present in the LDAP OU (Organization Unit)configured for RDS
Users/groups which are migrated retains its Role and access rights provided by DOORS
Login with one of the LDAP user to DOORS (this user should be migrated) – User logged in successfully and displays proper role and access rights affective on project

System User Capability in DOORS-RDS Integration –

System User Functionality in DOORS is used when user want DOORS to take the user details of NT /Windows machine user instead of user providing the user details.

When DOORS is configured with RDS we can still use this capability and you can enable system log in from RDS. User NT name provided on LDAP will be the Machine log on name while log in to DOORS.

From RDS enable System log in from following window:

Restart DOORS server and you can see 2 txt file are created under data folder of DOORS.

Now Log in to your windows machine using user name provided as system log in name and Launch DOORS

DOORS is launched and login dialogue displays prefilled Username and it’s greyed out.

RDS provides 2 types of names for system login, It can be either NT logon name or Windows logon name which can be checked from User properties in RDA.

Two Factor Authentication (TFA):

TFA feature of RDS provides extra security by having one more check of authentication where. This will be supported with the help of third party software “Radius”. TFA can be enabled/disabled for any user.

When TFA is enabled Administrator user of DOORS asks for one more authentication in which user need to provide the LDAP user details for which TFA is enabled in RDS, So Administrator should know the credentials of even this TFA user.

For the non admin DOORS user which is enabled for TFA, During DOORS login it asks user credentials and then goes through verification of Radius user credentials and then allows to launch DOORS.

TFA can be used along with System log in feature also enabled.

How to enable TFA? :

From RDS enable TFA from Database Node –

b. Provide Radius details from Security Configuration as in screenshot below :

Here Host IP is IP of Radius Machine

Port Numbe is 1812

Shared Key is : WinRadius

Launch Third party software “Radius” and create User “Test”
In RDS User properties -> Security tab provide the Radius User details :

e. From DOORS launch as Administrator User -

After providing Administrator credentials, It will prompt with one more authentication popup to enter RDS user details which is enabled for TFA, Followed by one more popup to provide details of Radius User.

This is how Two Factor Authentication takes place with multiple authorizations providing more security.

Meta Group Configurations :

RDS is configured for meta group when it is required to use small set of users from LDAP instead of fetching the whole set from the complete domain.

Ex : ibm.com domain which has all user details where as a group withing it that is in.ibm.com contains details about only Employees in India so It make sense to point to only in.ibm.com instead of fetching all the users.

How to Configure for Meta group?

From RDS Corporate Partition, Configure as below :

Only Search base will change here –

Here Users_India and Groups_India are the Groups created in LDAP under in.ibm.com domain which contains only the required set of Users/Groups.

Now RDS displays only Users that are under User_India Group and displays only groups that are under Groupd_India Group on LDAP
Now DOORS displays only Users that are under User_India Group and displays only groups that are under Groupd_India Group on LDAP
Any attempt to login to DOORS with user who is present in LDAP but not part of Users_India group will fail to login

Reference Links :

http://pic.dhe.ibm.com/infocenter/doorshlp/v9/index.jsp

http://www-01.ibm.com/support/docview.wss?uid=swg21509313

http://www-01.ibm.com/support/docview.wss?uid=swg21503110

Modified on by Ashwini R Kalghatagi

Migration of data from HP Quality Center to Rational Quality Management using RQM Migration Utility

Ashwini R Kalghatagi ‎ 7,804 Views

Introduction:

This article is a case study of a task whereby we have migrated around 3000 HP Quality Centre tests to Rational Quality Management (RQM) tool. The HPQC repository contained around 3000 tests going back 10 years. One of the major tasks was to maintain the structural hierarchy to ensure that the users would be able to find things as easily as they previously did in HPQC

The RQM Migration Utility was used to migrate the data. This article is not intended to be a replacement for the documentation that comes with the migration utility which can be found under links given in References section of this article.

Brief about the tools:

Quality Center (QC)

Quality Center is a HP product used for maintaining the test management data which contains test scripts, test executions, defects etc.

HP Quality Center has a well-defined hierarchy in which test scripts can be located. Tester creates the test script either with step by step explanation or as a whole scenario. There are user defined sets of attributes for each test scripts which may detail features, releases and so on.

Rational Quality Management (RQM)

Rational Quality management is IBM Rational tool used for Test Management; Along with test scripts it supports capability to maintain the test plans and its respective execution records.

There are set of categories tied to the test scripts explaining about the feature/release/automation etc the script belongs to. Provide easy search facility for test scripts. Each test script is having a test case which acts like a container for test script and test case provides the detailed explanation of Test Design, whereas test scripts provides the detailed steps of each step and its Pass/fail criteria. User can even track the actual Results while running test scripts.

Hierarchy levels can be achieved by creating sub categories at any number of levels and the values of parent category are tied to the list of sub categories values to display proper hierarchy of categories at left most portion of Test scripts window.

RQM Migration Utility

This is an ExcelExportImport utility, provides capability to import data from Excel file to RQM.

This utility can be installed by just running the .exe provided in Link under References section of this document. After the installation you can see a RQM menu option in your Excel file. Installation directory contains .cfg file where we provide the Excel file column names mapped to the respective fields(category) in Rational Quality Manager .

Following are few steps I performed before starting the actual migration of the data.

Preconditions:

Installed Microsoft Excel
RQM Migration Utility is installed and RQM option visible in excel file

Preparatory Work before migration:

Quality Centre can have any number of levels in hierarchy.

For our data it suited to have 3 Levels of hierarchy hence we decided to create maximum 3 levels of hierarchy.

Ex:

Level 1 -> Product Name

Level2 -> Feature Name

Level 3 -> Sub feature

Level4 -> Actual Test Scripts

Create 3 categories in RQM which will represent the 3 hierarchy levels in Quality Center

Create all the required categories in RQM which values will be mapped to fields values taken from Quality Center

Process:

Preparation:

Prepare the query to get list of absolute IDs :

As discussed before we have 3 levels of hierarchy in Quality Centre, when we perform migration of scripts we will be migrating whole set of test scripts that comes under targeted folder at Level2. In order to write a query to pull out list of scripts under specific folder we should know unique identity of that folder. Here in Quality Centre we have absolute IDs to identify folders uniquely.

I executed following query to get list of absolute ID’s on all folders existing in Quality Centre database.

Query is executed from Quality Centre->Dashboard section:

Below screenshot just show how to navigate in Quality Centre to get to the query editor.

Note: Do not use the query in given screen shot, Actual Queries are listed separately in below explanation.

Query to get absolute IDs is below :

SELECT ALL_LISTS.AL_ABSOLUTE_PATH /*Test Plan Folder.Absolute Path*/ ,

ALL_LISTS.AL_DESCRIPTION /*Test Plan Folder.Name*/

FROM ALL_LISTS

Note: Replace the Table and field names in above query with respective names used in your project

Prepare query to get all the test scripts under specific folder at Level2 in Quality Centre to Excel File.

All important required attributes are queried from Quality Centre along with its respective scripts. Following are the list of attributes considered and prepared query:

Note: In below query the value of ABSOLUTE_PATH variable changes depending on theLevel2 folder targeted for migration. Take the absolute path values from the result of query run in Step1.

QUERY:

Select

ALL_LISTS.AL_DESCRIPTION, /* Level3 Folder Name */

TEST.TS_CREATION_DATE, /*Test.Creation Date*/

TEST.TS_DESCRIPTION, /*Test.Description*/

TEST.TS_RESPONSIBLE, /*Test.Designer*/

TEST.TS_USER_04, /*Test.Exclusive*/

TEST.TS_USER_14, /*Test.Feature*/

TEST.TS_USER_03, /*Test.For Version*/

TEST.TS_USER_09, /*Test.Interfaces with O/S*/

TEST.TS_STATUS, /*Test.Status*/

TEST.TS_USER_02, /*Test.Suitable for Citrix*/

TEST.TS_USER_05, /*Test.Test Category*/

TEST.TS_TEST_ID, /*Test.Test ID*/

TEST.TS_NAME, /*Test.Test Name*/

TEST.TS_USER_08, /*Test.Test Rating*/

TEST.TS_TYPE, /*Test.Type*/

DESSTEPS.DS_STEP_NAME, /*Design Step.Step Name*/

DESSTEPS.DS_DESCRIPTION, /*Design Step.Description*/

DESSTEPS.DS_EXPECTED, /*Design Step.Expected Result*/

TEST.TS_SUBJECT /*Test.Subject*/

From Test,All_Lists,DESSTEPS

WHERE

TEST.TS_TEST_ID = DESSTEPS.DS_TEST_ID and

All_Lists.AL_ITEM_ID = Test.TS_SUBJECT and

All_Lists.AL_ABSOLUTE_PATH like 'AAAACPAADAAA%'

Order By

TEST.TS_TEST_ID, DESSTEPS.DS_STEP_ORDER

Note: Replace the Table and field names in above query with respective names used in your project

Above are the set of fields we finalized to be required fields for test script hence queried only those from Quality Centre.

Prepare a cfg file

This file is used by RQM Migration utility when we migrate scripts from Quality Center to RQM to map the Quality Center attributes to respective attributes

created in RQM

a. Every Test script in QC has its respective Test Script and Test Case in RQM.

All Test Script and Test Cases attributes are covered in this file

b. For every Test script associated Test Case is Created

c. Each Test Case Name is fetched from Excel File and then appended with “_TC”

Each Test Script Name is fetched from Excel File and then appended with “_TS”

e. Test Script ‘Summary Information’ in Quality Center is copied to Test Design section of a Test Case in RQM

f. In cfg file value of category Level 1 is always DOORS in our case as all scripts under DOORS project are migrated. [DOORS is our product name]

Level 2 value is hard coded as per which Level 2 folder from Quality Center is targeted from migration.

Level 3 value is dynamic which is directly picked from Excel file.

Cfg file Sample is as below:

testscript.XLSStartRow=2

testscript.dc:title=M & "_TS"

testscript.dc:description=M

testscript.XLSArtifactID=M

// the literal "execution" will be put into the step type tag, so all steps will be of type execution

testscript.steps.type="execution"

testscript.steps.description=Q

testscript.steps.title=P

testscript.steps.name=P

testscript.steps.expectedResult=R

testscript.category term="Owner".value=D

testscript.category term="Exclusive".value=E

testscript.category term="Feature".value=F

testscript.category term="For Version".value=G

testscript.category term="Interface with OS".value=H

testscript.category term="Citrix?".value=J

testscript.category term="Test_Category".value=K

testscript.category term="Test ID".value=L

testscript.category term="Test Rating".value=N

testscript.category term="Test Type".value=O

testscript.category term="Level1_Product".value=T

testscript.category term="Level2_Feature".value=U

testscript.category term="Level3_SubFeature".value=A

testscript.jzalm:state="Approved"

testscript.jzalm:Owner="Test"

// a new script starts when we encounter an empty row

testscript.XLSDelimeter=\n

testcase.ID=testscript.XLSArtifactID

testcase.dc:title=M & "_TC"

testcase.dc:description=M

testcase.Section("myns:com.ibm.rqm.planning.editor.section.testCaseDesign","RQM-KEY-TC-DESIGN-TITLE")=Pre(C)

testcase.category term="Owner".value=D

testcase.category term="Exclusive".value=E

testcase.category term="Feature".value=F

testcase.category term="For Version".value=G

testcase.category term="Interface with OS".value=H

testcase.category term="Citrix?".value=J

testcase.category term="Test_Category".value=K

testcase.category term="Test ID".value=L

testcase.category term="Test Rating".value=N

testcase.category term="Test Type".value=O

testcase.category term="Level1_Product".value=T

testcase.category term="Level2_Feature".value=U

testcase.category term="Level3_SubFeature".value=A

testcase.jzalm:state="Approved"

testcase.jzalm:Owner="Test"

testcase.XLSStartRow=2

testcase.XLSDelimeter=\n

Note: In this cfg file we are mapping the column names in Excel file to respective fields in RQM. Hence in above cfg content you need to replace the column names (Ex, B, C, N, T…) with respective columns in your excel file

Couple of Macro is run before sending an Excel for migration. These Macros will process data in Excel file and fine tune it to use for migration.

Following are the Macros used:

a. Macro to format Summary Information :

After the data is queried from Quality Center, Summary of Test case includes even the revision history, We wanted only the summary information because

that was the only useful information by ignoring the Revision History Information

Macro Sample:

Sub RemoveRevsionHistory()

RowCount = Application.WorksheetFunction.CountA(Range("L:L"))

For i = 2 To RowCount

s = Cells(i, 3)

Reply = InStr(1, s, "REVISION HISTORY", 0)

If (Reply <> 0) Then

s1 = Split(s, "REVISION HISTORY")

Else

s1 = Split(s, "Revision History")

End If

Cells(i, 3) = s1(0)

Next i

End Sub

Note: In above macro replace the column “L” with respective test ID column in excel,

Column 3 is used for revision history replace this column number with respective history

Column in your excel

b. Macro to separate the individual test scripts :

During migration the RQM migration utility will consider blank row as a separator between two scripts in excel.

Hence we add a blank line after all the steps of a test scripts are completed.

Macro sample:

Sub AddBlankLine()

RowCount = Application.WorksheetFunction.CountA(Range("L:L"))

RowCount = 3000

For i = 2 To RowCount

If (Cells(i, 12) <> Cells(i + 1, 12)) Then

RowCount = RowCount + 1

i = i + 1

Cells(i, 1).EntireRow.Insert

End If

Next i

End Sub

Note: In above macro replace the column “L” with respective test ID column in excel,

Column 12 is used for Test IDs replace this column number with respective Test ID

Column in your excel. Here the Rowcount variable value should be changed depending

on number of rows exists in your excel file

c. Macro to replace multi valued attributes values to a single value:

Few fields like “feature” containing multiple values which will make it difficult to search particular script with comma and semicolon in between, So to avoid

this problem, macro is run which will separate the values delimited by comma and considers only first value as the final one.

Macro sample:

Sub MultivaluedAttr()

RowCount = Application.WorksheetFunction.CountA(Range("L:L"))

For i = 2 To RowCount

s1 = Cells(i, 6)

Reply1 = InStr(1, s1, ";", 0)

If Reply1 <> 0 Then

r1 = Split(s1, ";")

Cells(i, 6) = r1(0)

End If

s2 = Cells(i, 11)

Reply2 = InStr(1, s2, ";", 0)

If Reply2 <> 0 Then

r2 = Split(s2, ";")

Cells(i, 11) = r2(0)

End If

Next i

End Sub

Note: In above macro replace the column “L” with respective test ID column in excel,

Column 6 and Column 11 is used for listing features and components replace this column

Number with respective columns in your excel

d. Macro to remove the appending numbers for feature values :

This step is to remove unwanted data which is not required. Following macro is used to remove appending numbers.

Macro Sample:

Sub RemoveAppendingNumber()

Dim RE As Object, REMatches As Object

Dim s As String

Set RE = CreateObject("vbscript.regexp")

With RE

.MultiLine = False

.Global = False

.IgnoreCase = True

.Pattern = ".*[a-z]"

End With

RowCount = Application.WorksheetFunction.CountA(Range("L:L"))

For i = 2 To RowCount

s = Cells(i, 6)

If (s <> "") Then

Set REMatches = RE.Execute(s)

Cells(i, 6) = REMatches(0)

End If

Next i

End Sub

Note: In above macro replace the column “L” with respective test ID column in excel,

Column 6 listing features replace this column number with respective columns in your

Excel

After completing above set of preparation activities we followed the below given sequence of Procedure steps to complete the migration task.

Procedure :

1. In Quality Center run query to get Absolute IDs and save the results in AbsoluteID.xls file.

2. Target for a Level 2 folder in Quality Center for migration and grab its Absolute ID from AbsoluteID.xls file.

3. In Quality Center modify the query with respective Absolute ID for Level 2 folder under migration.

4. Run the query to export test scripts to Excel file.

We have all test scripts and its attributes under the Level 2 folder and all exported to excel file, here each row indicates every step in a test script.

5. On the excel file run Macro 1 to fine tune the Summary information by removing Revision History.

6. Run Macro 2 to add blank line after every test script.

7. Run Macro 3 to fine tune value of multi valued attribute delimited by comma

8. Run Macro4 to fine tune value of Feature attribute by removing the appending numbers

9. Modify cfg file with the proper value for Level 2 folder

10. Import data in to RQM from Excel file using RQM plugin using the cfg file created for this task.

11. Repeat this whole [procedure for each Level2 folder in Quality Centre

Problems faced and could not resolve during our case study :

1. Unable to link the subcategory values with its parent category through migration utility. This was done manually after migration is performed.

2. Unable to migrate multivalued attributes values

3. Unable to migrate values to custom attributes in RQM

4. Unable to handle attachments during migration process. This was done manually after the migration completed

5. Call other script within a test script like Keywords are not handled during migration

6. Weight parameter Equivalent to Quality Centre is not found

References:

Link to Installation files for RQM Migration Utility

https://constellation.beaverton.ibm.com/RQM/TMMT/Mainline/N/TMMTMainline-N20111117_0606/cic-metadata/native/

Link to User Guild for RQM Migration Utility

https://jazz.net/wiki/bin/view/Main/RQMExcelWordImporter

Modified on by Ashwini R Kalghatagi

Feed for Blog Entries Feed for Blog Comments

Blogs