Tags

Recent tweets

I'm sure we all agree that the single most exciting thing to happen in 2014 was the delivery of a 64-bit client for Rational DOORS.

Following on from this, in 9.6.1, we also deliver DOORS Web Access (DWA) in 64-bit.

However, do note that 32-bit builds are no longer built and delivered in parallel. So what? If you have 32-bit hardware, you cannot upgrade to DOORS 9.6.1 or DOORS Web Access 9.6.1. The last version to ship 32-bit builds of DWA and the DOORS client is 9.6.0.1.

The legendary DOORS client/server compatibility remains – so users with 32-bit hardware can be on the 9.6.0.1 32-bit client while those with 64-bit can move to 9.6.1.
The DOORS server is still 32-bit and there are no plans to move it to 64-bit.

The locking model of DOORS means that the creation of links from RQM (Rational Quality Manager) to DOORS will fail if the module or object is locked in DOORS with the following error:
If you "Cancel", nothing should happen. No link is created in either application. If it's you who has the module open in exclusive edit mode in DOORS (and I do this all the time, I guess I'm not alone...), it's an easy fix. Close it in DOORS and check "Try again".

But if you continue and "Save the partial changes", what have you done? You have created a link from RQM to DOORS but not from DOORS to RQM. This could impact reporting if the reports are only looking in DOORS as there is no link to the test case in DOORS. How do you fix that?

In DOORS, you could create the link to the RQM object. But also in RQM there is a little known but very nice feature that came in 4.0.1 for checking the state of these links. See:Ability to see back link status in traceability view. Here's a screenshot from RQM 5.0.2 RC1:

The missing links are identified and can be fixed by the broken link icon.

This has been implemented as a user setting. A customer recently asked why is this not the default? Well, consider the actual impact of this if you have thousands of test cases linked to requirements. It will send thousands of requests to DWA. With hundreds of users, DWA would need to be scaled to manage that increase in load. I would leave this feature for the users who need it. I would not activate it for every user as every user is not interested in the link status.

I most commonly see DOORS Web Access (DWA) installed on its own server and I prefer this for two reasons:

DWA is resource heavy. It wants RAM and CPU. The DOORS Database server is not resource hungry and can run on an old server with as little as 2GB of RAM. If you add DWA to such a server, the server will have to be upgraded.

Upgrading DWA impacts all DOORS users and the risk is greater than if DWA was on a dedicated server. Upgrading DWA is almost certainly going to require the database server to be restarted. There can also be the occasional DLL compatibility issues if DWA is upgraded but the server is not.

An important related note is that DWA should be close to the DOORS database server. A ping should be less than 50ms between where the database server is running and where DWA is running. I have twice seen DWA put in a remote location (a different city), with ping times significantly in excess of 50ms. The performance was unacceptable with operations such as login and opening modules timing out.

There was a time when either was fine. And it still is if you are only using DWA (DOORS Web Access). However, if DWA is used to integrate with other browser based applications, this becomes a critical point.

Modern browsers do not like mixed content. Which is to say, if an application configured on HTTPS wants to display content from one which delivers that content via HTTP, the browser will block the HTTP content. The user will see a blank dialog. It isn't always obvious to the user that anything has been blocked by the browser , and getting the browser to allow the mixed content can force page reloads.

All of the Jazz based applications are by default on HTTPS, including Rational Team Concert, Rational Quality Manager, DOORS Next Generation, Design Manager and Rational Engineering Lifecycle Manager. If you plan on an OSLC (Open Services for Lifecycle Collaboration) integration to any of these it is better to configure DWA on HTTPS. This is enabled by default from DWA 9.6 on-wards, though ideally in production you would replace the supplied self-signed certificate with a valid one, seeConfiguring Rational DOORS Web Access to use SSL or TLS

If you leave it with the self-signed certificates the browsers will ask users questions along the lines of "Are you really really sure you want to see this? It's not secure; The world might end and you'll be blamed if you proceed" etc.

The interop process (doors.exe) serves multiple users. However it is a single threaded process - it can only do one thing at a time for which it will attach
to one CPU core. So if it is busy with a large operation for one user (for example, a GET on 1000 requirements in IBM Rational DOORS), the other users are hung.
This 'large operation' is not typically seen if you are only using DWA. But it is when IBM Rational Quality Manager (RQM) is involved. The RQM Reconcile feature can be used to run very large GETs and PUTs from/to DWA.

Experience tells us that in RQM-DOORS setups, the number of interops are critical to having satisfactory end user performance. I always recommend at least 4 interops, ensuring there are also at least 4 CPU cores. In configuring this it is also good practice to limit the RAM usage of each interop. They will safely and silently restart if this limit is reached.