Offline working in DOORS with Partitions

As our world becomes more connected, this topic comes up less often, but it is still an issue for many people. I am not talking about data sharing down the supply chain here, but about taking your work away with you on a laptop and returning it to the corporate database with updates some time later.

First the infrastructure. You have DOORS installed on a server somewhere, and you connect from a laptop with the standard thick client. You also have a DOORS server installed on the laptop, and a shortcut to use the client to connect to this local database. You have access to a license on the laptop, either by having a dedicated license, or by checking one out of the server pool of licenses in some way; this will depend on the type of licenses you are using.

Now the formal documentation. The published help on DOORS includes some good information on partitions here http://pic.dhe.ibm.com/infocenter/doorshlp/v9/index.jsp?topic=%2Fcom.ibm.doors.administering.doc%2Ftopics%2Fc_aboutpartitions.html

So what more is there to be said?

Well, DOORS partitions are often spoken about with that tone, the one that says “Don’t do it; here be monsters”. My experience of them, however, is that they work really well. For a while I was using them regularly in a DOORS v6 database and I never had a problem. I have used them occasionally since, and still never seen a problem.

Part of the issue is that when used to control data up and down a supply chain, the issue of ownership can be a problem. Some years ago we came up with a good working solution for that, but it still needed very careful management.

This article is about offline working, and for that, partitions work really nicely.

Terminology.

I will refer to the main database on the company server as the Home database, and the database on the laptop as the Away database. The formal terms for actions related to partitioning are in bold, and are Export, Import, Synchronize, Recover, Return and Rejoin.

 

So how does it work?

First sort out your partition definition. What do you want to have editable in your Away database, and what do you need to have read access to? When the partition is exported, there will be write access to everything in one or the other of the two databases, but not in both. You can take a read only copy of data that is needed for context without affecting the Home database.

Export the partition when you need to go offline, and Import it into your standalone database, the Away database.

You can now work on the standalone database. Anyone looking at the Home database will see the partitioned data as locked and will have read only access. For this reason you need to be careful about how much data you are taking out and how long you keep it out.

When you are ready to return to the connected world of your network, you need to put your changes back into the server database. There are a couple of things that can happen here:

1. You didn’t make any changes (the trip didn’t go to plan). In this case, you just need to Recover the partition in your Home database to release all the locks. It would also be sensible to delete the partition from your Away database.
2. You made changes, and are now back in the office for a few days. In this case you need to Return the partition from the Away database and Rejoin it to the Home database. Be sure to tidy up the Away database as this is now a dead-end.
3. You made changes, this is a fleeting visit to the office between trips and you want to deposit the changes made so far, but retain the offline capability. In this case you want to Synchronize (create a Sync file) from your Away database. You then need to Synchronize this with the Home database. Now you have updated the Home database with your changes, but you still retain the locks so you can keep editing on the Away database.

That is all fairly simple, but there are some complicating factors. All of the files (Export, Return and Sync) have the same extension, .par. This makes it easy to confuse a return and a sync file for instance. DOORS should recognize the internals of the files and not allow you to misuse one, but that doesn’t prevent you from becoming confused.

Any data left in the Away database will cause confusion when another partition of the same project is imported. It is always best to clean up and remove any traces of old partitions.

Any lost partitions can be Recovered, but any changes will be lost, the decision to Recover should be taken carefully, and preferably with input from the person who received the original Export.

This works well if used to work offline with relatively small teams. Large teams, where multiple people are editing the same modules, will not take well to this, as the data is locked for days at a time. Trying to share data longer term, as in a supply chain arrangement, is a more complex set up and, while it is possible, I really haven’t touched on the issues here.