Skip to Content
I was working on some new development, but mistakenly created my objects in the wrong folder structure based on established standards at work. Unfortunately I’d already migrated this content (roles, worksets, pages and iViews, including portal content folders containing those objects) from our Development environment to our Test environment.

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:

image

2. Next, I right-clicked on the object and chose delete, as follows:

image

And, was presented with the following dialog:

image

3. Here I selected ‘Yes’, and then was presented with the next window (you’ve probably seen something similar to this before):

image

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:

image

5. So, I right-click on the object and choose Open, and then Delta Link Tracer, as follows:

image

And, see the following screen, where I then select the ‘Show Delta Link Dependents’:

image

Which gives me the following screen where I determine that there does infact exist a dependency on the object:

image

6. I then navigate to the System Administration -> Transport -> Export area, where I locate the transport package in question. Here I’ve two options:

a) Remove both the ‘Go Shopping’ workset object, and if you wish, the transport package object from the transport by selected the items and choosing the ‘Remove’ button (not visible here): image

b) Simply delete the transport package altogether from the PCD, since we would probably have a copy of it in our file systems: image

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:

image

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:

image

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.

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

    1. Former Member Post author
      Thanks, Prakash.

      This is very trivial stuff, but I’m sure many folks in the Portal realm have come across this, assuming they are using Ep6.  ‘Hope this was actually helpful to folks out there.

      (0) 
  1. Detlev Beutner
    … and helpful information. But – in the end, this strange behaviour should be considered as a bug (the different views on the PCD are different views, nothing else; if there are dependencies which can be killed, this should also reach transport packages, not only the PCD objects to be seen in one certain view). Did you think of opening an OSS message?!
    Best regards, Detlev
    (0) 
    1. Former Member Post author
      I’ve just requested an OSS account at work, and will likely consider submitting a bug report for this and see where it goes.  Thanks for the suggestion, Detlev.
      (0) 
  2. Former Member
    Hi Vishwa,

    since the normal transport procedure, import/export of portal will not keep track of the deletion of portal objects, we still delete them manually on each and every system.

    can we use this portal object to transport package dependency to delete the object in the target system PCD, without manually deleting them

    just trying out the options.

    (0) 

Leave a Reply