Firstly, let’s look at the official SAP definition of Delta Links:
“A delta link is a relationship between two objects of the Portal Content Directory (source and target objects) that are linked with a delta link. The source object is the object that passes its property values to the target object that is derived from the source object. Changes made to the source object are copied to the target object and are visible there. Changes made to the target object have no effect on the source object.”
Now, if I understand correctly, this means that if I should make a change directly to an iView that is a delta link on a page, that change should also be applied to the delta link version on that page (if we can separate the delta link with the original object, from an entity perspective). Well, unless I’ve misunderstood, I’ve found that this isn’t exactly accurate. Or, Ep6 (Sp9) doesn’t quite behave according to the definition stated above. I’ll elaborate with a few scenarios that lead me to this conclusion.
Scenario 1: Changing page names in the navigation of a workset within a role
The recommended approach here would be to go directly to the workset, and determine whether the page has been added as a delta link or copy. If it is a delta link, you should see an icon as follows next to the item:
If it is a copy, or it was formerly a delta link, but has changed within the workset, you would see the following icon next to the item:
This is a nice visual distinction, that can help you more quickly locate problematic objects.
Next, you can select the item and choose the ‘Properties’ button in the object editor window. In the right frame, you’ll see an abbreviated list of properties you can change, including the name. Now, in theory, you should just be able to change the name here and click the ‘Save’ button and that modification should occur immediately to the page in the workset. Does this also mean that you’ve modified the master object? Not necessarily. And, does the modification actually occur? Not always.
I found that although the object now appears as a changed object, any changes to this object may or may not actually apply to the master object. Anyone at SAP out there? Please explain! And, whether the modification actually occurs or not, seems almost random. Although, the change may appear visually within the object editor, it may not appear in the navigation when actually navigating to that location in the portal. So, I’m left with the last resort of taking the objects apart, including the role and workset that contain the delta link or copy of the page.
First, I go directly to the role, and remove any and all worksets containing either other worksets, and/or folders containing the pages to be renamed. Then, I go to each individual workset and remove the pages that need to be renamed. I then rename the pages individually, then re-add them to the associated worksets as copies, not delta links. Then re-add those worksets to the worksets or roles they were originally associated to as delta links. And, voila – this works! SAP, what am I not understanding here? Or, was my approach correct, and SAP is working on fixing this bug / enhancing this feature in EP6?
Scenario 2: Modifying a folder name within a workset or role
We need to ask the following questions before we begin: What physically is a folder within a workset or role? Is it a master object hidden from us within the PCD that appears as a delta link or copy within the role or workset? Or, is it now a property of the workset or role object that only exists within that role or workset? Either way, if you want to make a change to the name of the folder, prepare to recreate the folder from scratch. I’ve now done this several times to the point that I’m convinced that you have to delete the folder, then recreate the folder from scratch using the same ID, but different name. Then, re-add any pages, or worksets that were originally contained within that folder.
Based on these common scenarios, I would say that delta links are not exactly what they are supposed to be in Ep6. Ofcourse, another factor in my work, was the number of pages that did not get migrated properly into a useable format in Ep6. These were originally in Ep5 and the Ep5 to Ep6 migration tool, did not do a 100% job of converting those objects into proper Ep6 equivalents. So, I found myself even having to recreate the pages from scratch in some instances, because applying the name change directly to the page, would still not affect the master object, and as a result its delta link.
So, my recommendation is use the most guaranteed approach, however exhaustive, to ensure that these types of changes are applied to the objects in the PCD. Our senior analyst in the team, recently called a meeting to deal with the issue of Delta Links. In that conversation, it was understood that we should proceed with caution when using delta links. Another issue, is how now do we transport these changes from one environment to another (going from Development, to Test/QA, right through to Production)? My preference is to include every object that I modified, even if it is a delta link within another object. And, this has worked for me consistently with every such transport I’ve requested. From that conversation, and my own experience thus far, here’s my strategy when dealing with delta links:
1. If the object is being added to the most granular object within the navigation hierarchy you wish to build, such as a workset or folder, add the object (usually a page) as a copy. Then, add its parent objects as delta links to their parent objects, following the hierarchy right up to the role object.
2. If you are making changes to object names such as folders and pages, follow the most exhaustive approach. Take the role, the workset, the folder apart. Rename the objects accordingly, then re-add them making sure the changes are reflected visually in the object editor, right up to the highest object in that hierarchy.
3. When transporting such changes across environments, include every object that was either modified or referenced as a delta link/copy.