As part of our change management process we specify instructions to our BASIS team of the steps that are required to backout a change if it is either cancelled or transported in error. My simple instructions were to just delete those objects manually and transport a new package with the objects placed in the proper locations of the PCD.
Unfortunately it’s not that straightforward, especially if you have object dependencies that go beyond just the actual roles, workset, pages and iViews themselves. That is, you likely have a transport package dependency. Here’s how I found out it was this very case when I was trying to get rid of a workset called Go Shopping (part of our SRM/SCM implementation at Suncor):
1. I navigated to the location of the workset object I needed to delete called Go Shopping through the Content Administration -> Portal Content tool, as follows:
2. Next, I right-clicked on the object and chose delete, as follows:
And, was presented with the following dialog:
3. Here I selected ‘Yes’, and then was presented with the next window (you’ve probably seen something similar to this before):
4. Here, again, I chose ‘Yes’, as I wanted to delete this object, convinced that I’ve already gotten rid of any dependencies it has or other objects have of it (specifically other roles, worksets and so forth). Yet, when the Portal content catalog is refresh, low and behold, it’s still there:
5. So, I right-click on the object and choose Open, and then Delta Link Tracer, as follows:
And, see the following screen, where I then select the ‘Show Delta Link Dependents’:
Which gives me the following screen where I determine that there does infact exist a dependency on the object:
6. I then navigate to the System Administration -> Transport -> Export area, where I locate the transport package in question. Here I’ve two options:
7. I opted for the second option, since I’ve destructive tendencies (just joking). Here, I’d get the following dialog from which I’d select ‘Yes’ to confirm deletion of the transport package:
8. Finally, I navigate back to where the original workset, I wanted to delete, was located, and am now able to delete the object from the PCD. And, with a refresh of the screen:
Voila! It’s no longer there. I can now proceed to delete any other objects that are referenced by the deleted transport package.
I’ve often chosen to remove the transport package object from the transport package itself whenever I create a new transport, as my first step. Later, once I’ve completed my transport, I usually delete the transport object altogether from the PCD, as I’d maintain a copy on some file system.
Our BASIS teams maintains the packages in both the PCD as well as file shares. It’s probably a ‘just-in-case’ approach. But, if we need to clean up objects, it can be a real pain when it comes to backing out transports. As such, it’s probably better to not keep your transports in the PCD, so you avoid problems like this – but this is my own opinion. I’m sure there are compelling arguments to the contrary.