'Remote Delta Link' Mode

Use

With the remote delta link (RDL) usage mode, a content administrator on a consumer portal can create delta links to content objects (iViews, pages, worksets, and roles) that reside on a remote producer portal. The content administrator on the consumer portal can then reuse, configure, and customize the delta link content as local content. At runtime, the execution of iView applications is performed on the producer portal.

Standard delta link behavior also applies to remote delta links:

Remote delta link objects on the consumer portal can be customized without affecting their source objects on the producer portal.
Changes to source objects on the producer portal are automatically updated in their corresponding target objects on the consumer portal, except for properties that a content administrator has modified directly in target objects on the consumer portal.

Remote delta link mode is available only to SAP NetWeaver portals.

Advantages and Disadvantages

Advantages	Disadvantages
Supports various object types: iViews, pages, worksets, and roles. ⁽¹⁾ The standard behavior of delta links improves flexibility for content administrators-it allows them to modify remote content on the consumer, but at the same time keep unmodified content synchronized with its source content on the producer. ⁽¹⁾ Local content can be customized according to local requirements. These changes do not affect the source content on the producer. ⁽¹⁾ Runtime execution of iView applications (source code) remains on the producer portal. Supports mixed scenarios of local and remote content running together on the consumer. ⁽¹⁾ Allows full customization of remote roles on the consumer. ⁽¹⁾ Supports end user personalization of remote delta link content on the consumer. Allows flexible transport of portal content between portals; the consumer can clone a complete Portal Catalog structure (roles, worksets, pages, and iViews). ⁽¹⁾	Once remote delta links are created on the consumer, the source content on the producer portal must not be deleted or moved; otherwise the remote delta link objects on the consumer will not function. Remote delta link objects created on the consumer portal need to be maintained and monitored by a local content administrator.

Advantages

Disadvantages

Supports various object types: iViews, pages, worksets, and roles. ⁽¹⁾
The standard behavior of delta links improves flexibility for content administrators-it allows them to modify remote content on the consumer, but at the same time keep unmodified content synchronized with its source content on the producer. ⁽¹⁾
Local content can be customized according to local requirements. These changes do not affect the source content on the producer. ⁽¹⁾
Runtime execution of iView applications (source code) remains on the producer portal.
Supports mixed scenarios of local and remote content running together on the consumer. ⁽¹⁾
Allows full customization of remote roles on the consumer. ⁽¹⁾
Supports end user personalization of remote delta link content on the consumer.
Allows flexible transport of portal content between portals; the consumer can clone a complete Portal Catalog structure (roles, worksets, pages, and iViews). ⁽¹⁾

Once remote delta links are created on the consumer, the source content on the producer portal must not be deleted or moved; otherwise the remote delta link objects on the consumer will not function.
Remote delta link objects created on the consumer portal need to be maintained and monitored by a local content administrator.

⁽¹⁾ These capabilities are not available to roles consumed through remote role assignment . For more information, see 'Remote Role Assignment' Mode .

Basic Administration Workflow on the Consumer Portal

After the producer and consumer portals have been paired and registered, trust has been established, and the portal administrator of the producer has performed the necessary steps to expose its portal content to the remote consumer portal, the content administrator of the consumer portal can copy remote content as remote delta links to the consumer portal.

The content administrator of the consumer portal performs the following steps:

Browses the Portal Catalog of the remote producer portal.
Selects relevant folders, roles, worksets, pages, and iViews that reside on the producer portal.
Copies the selected content as remote delta link objects to the local Portal Catalog of the consumer portal.
Incorporates the remote delta link content with other local content and assigns it to local users, groups, or roles.

More information: Consuming Content as Remote Delta Links

Technical Aspects

Pay attention to the following requirements and issues when working with the remote delta link mode:

After a content administrator on the consumer portal creates remote delta link content, the source objects and its entire delta link chain on the producer are always required. They cannot be deleted.
If the source objects are deleted or moved to a different folder on the producer portal, the remote delta link objects on the consumer become unresolved delta links and cannot be run.
If any producer portal pages or layouts are based on non-standard portal components (for example, pages not based on the standard portal component: com.sap.portal.pagebuilder.pageBuilder ), then their respective portal components do not need to be deployed on the consumer portal.
If a content administrator copies a folder from a producer portal, and any pair of objects in the folder has a delta link dependency between them, a matching delta link between the two corresponding target objects on the consumer is not generated. Instead, the remote delta link objects created on the consumer reference the source objects on the producer (see following figure). The reason for this is that a delta link object can only have one source object.

In the figure above, iView A is a unit iView. It is embedded as a delta link (delta link 1 to iView B) in Page 1. Both iView A and Page 1 are located in the same Portal Catalog folder on the producer. The folder is copied to the consumer. As a result of the copy, matching delta link objects are created on the consumer: iView C, iView D, and Page 2. Note that a delta link between iView C and iView D on the consumer does not exist (as do the corresponding source objects on the producer). Instead, remote delta links (2, 3, and 4) between objects on the producer and objects on the consumer are generated. As a result of the delta link relationships described in this example, you can expect the following behavior:
- If a content administrator on the producer modifies iView A, then iView B and C are automatically updated as a direct result. iView D is also updated as a result of iView B being updated.
- If a content administrator on the producer modifies iView B, then only iView D on the consumer is updated. iView C on the consumer does not receive this update.
- If a content administrator on the consumer modifies iView C, then none of the remaining iViews are updated.
- If a content administrator on the consumer modifies iView D, then none of the remaining iViews are updated.
- If a content administrator on the producer adds or removes an iView in Page 1, the changes are updated in Page 2 on the consumer.
Creating a remote delta link to a role does not include the user assignments of the source role on the producer. A user administrator on the consumer needs to assign new users and groups to the remote delta link role.
Using the Role and Workset editors in the portal, a content administrator can add local and remote content from any producer to a remote delta link role or workset .
Since remote delta link pages are executed at runtime on the producer portal, there are some limitations when a content administrator modifies a remote delta link page in the Page editor on a consumer portal:
- The following actions are permitted: Hiding existing content in the page, editing object properties, and switching layouts already assigned to the page.
- The following actions are not permitted: Adding or deleting content and layouts from the page.
A content administrator can mix remote-based content from different producers in a local page or role on a consumer.
End users on the consumer portal can personalize remote delta link iViews and pages. Examples of personalization include removing iViews from a pages, changing the page layout, and configuring properties in iViews.

When end users personalize remote delta link pages, note the following:
- End users cannot add local or remote iViews to the page.
- End users must use the Restore Defaults option in the page personalization screen to restore iViews they have removed from the page.
Personalization data as a result of changes to remote-based iViews and pages, made by end users on the consumer, is stored on the producer portal. Storing consumer-based personalization data on the producer, rather than on the consumer, improves runtime performance.
To optimize runtime performance of remote-based content on the consumer, consider the following:
- For all iView types, except for AppIntegrator iViews, such as Web Dynpro ABAP iViews and SAP application iViews (SAP transactions, Business Server Page (BSP) applications, BW reports, Crystal Enterprise reports, and Internet Application Components (IACs), we recommend that you copy the remote delta page that contains the iViews to the consumer, rather than to copy the iViews as individual unit objects and then embed them in a local page on the consumer.
  
  The reason for this is that a separate round-trip to the producer is made for every remote-based unit object (such as an iView) embedded in a local page on the consumer, even if all the remote-based objects originate from the same producer. For example, if a local page contains five remote delta link iViews, the consumer makes five trips to the producer to render the entire page. If the same five iViews were copied within remote delta link page and run on the consumer, the consumer would make a single round-trip to the producer to render the entire page.
- For AppIntegrator iViews, we recommend you copy the producer-based iViews individually as delta link iViews to the consumer, and to then embed them in a local page on the consumer. Therefore, you should avoid copying pages that contain AppIntegrator iViews.
To ensure a seamless flow of data through the federated portal network, you need to configure certain single sign-on authentication settings. For more information, see Single Sign-On .
The remote delta link usage mode supports the SSL protocol. For more information, see Setting Up SSL for Remote Delta Link Usage .
The portal does not permit a content administrator to reuse remote-based content on another consumer portal.
To support object-based navigation (OBN) with remote delta links, local copies of used business objects must exist on the consumer. The remote delta link creation mechanism searches for targets implementing business objects and copies them as well, but not as remote delta links. For more information, see Using Object-Based Navigation in a Federated Portal Network .
Note the following with regard to synchronization updates in the source objects on the producer portal to their corresponding delta link target objects on the consumer portal:
- The producer portal automatically sends content modifications made in the source objects to their corresponding target delta link objects on the consumer portal once every hour. This interval can be modified on the consumer portal. For more information, see Working with Remote Delta Link Content ).
- An administrator on the producer portal cannot enforce a content update (synchronization) to its registered consumer portals. Content updates can only be initiated from the consumer portal itself. For more information, see Working with Remote Delta Link Content .
When remote delta link iViews and pages are added to a local page on the consumer, the value of any property categorized as an integration property (see list below) is retrieved from the consumer at runtime. The values for all other properties (non-integration properties) are retrieved from the producer at runtime. Both cases refer to properties that have not been modified by the content administrator on the consumer. Therefore, if a content administrator on the producer modifies the value of any integration property, the content on the consumer is rendered at runtime using the old value stored on the consumer until the new value from the producer is synchronized to the consumer.

Any remote-based object running inside a remote delta link page uses the integration properties on the producer at runtime, regardless of what is stored on the consumer.

In order for consumer-side remote delta link objects to render at runtime with the new values of the modified integration properties from the producer, the content on the consumer must be synchronized with the content on the producer. Content updates on the consumer can be done either manually by the system administrator or automatically at intervals defined by the system administrator.

The following table lists the known integration properties:

General Properties	Navigation Properties	Tray Properties
`Description` `Name` `Object is a Template`	`Can be Merged` `Default Entry for Folder` `Entry Point` `Initial State of Navigation Panel` `Invisible in Navigation Areas` `Launch in New Window` `Merge ID` `Merge Priority` `Sort Priority` `Width of External Window (Pixels)` `Height of External Window (Pixels)` `Window features` `Workset Map Pictogram`	`Height Type` `Initial State - Open or Closed` `Maximum Automatic Height (Pixels)` `Minimum Automatic Height (Pixels)` `Show 'Add to Favorites' Option` `Show 'Details' Option` `Show 'Help' Option` `Show 'Open in New Window' Option` `Show 'Personalize' Option` `Show 'Refresh' Option` `Show 'Remove' Option` `Show Object Name in Tray` `Show Tray`

The standard transport mechanism of the portal for exporting and importing content automatically makes an attempt to reconnect remote delta links when moving content from one consumer portal to another. For more information, see Transporting Content within a Federated Portal Network .
When creating a remote delta link to an iView or page that has related items, such as dynamic navigation or related links iViews, the isolation method of the related item is automatically set to URL to ensure that the isolation mode is enforced. This is done regardless of the isolation method set for the corresponding object on the producer portal. For more information, see Isolation Method of iViews .
In use cases where the Application Integration service retrieves properties from objects located in the Portal Content Directory (PCD) of the producer portal, such as SAP transaction iViews embedded in remote delta link pages, you may need to manually clear the cached consumed content on the consumer before its cache lifetime expires. For example, if a content administrator on the consumer portal changes an application property in a remote delta link iView that has already been rendered, then the old property value is taken from the cache at runtime. The new value is rendered in the iView at runtime only when the cache has been cleared manually or automatically on schedule. For more information, see Configuring the Federated Portal Cache on the Consumer Portal .

The following figure provides a more detailed view of the runtime flow of content retrieval and rendering starting at the client for remote delta link mode (in this example, a remote delta link iView running in a local page):

The following figures show the design time and runtime relationships between objects on the producer and the consumer:

Figure: Remote delta link of a single iView. On the producer portal, iView 1 exists as a local entity and executes an application residing on the same portal. At design time, the content administrator on the consumer creates the remote delta link View (iView A) based on iView 1. The content administrator on the consumer then assigns iView A as a delta link to a local role (Role A). At runtime, when users assigned to Role A log on to the consumer portal, the execution of iView A' in Role A passes through iView A, which executes iView 1 on the producer portal.

Figure: Remote delta link of a single page. On the producer portal, iView 1 exists as a local entity and executes an application residing on the same portal. Page 1 contains iView 1', which is a delta link of iView 1. At design time, the content administrator on the consumer creates a remote delta link page (Page A) based on Page 1. The content administrator on the consumer assigns Page A to a local role (Role A). When users assigned to Role A log on to the consumer portal at runtime, the execution of iView A' in Role A passes through Page A (and iView A), which in turn executes Page 1, iView 1', and iView 1 on the producer portal. The execution of portal components for Page A and its layouts take place on the producer.

Figure: Remote delta link of a single role. On the producer portal, iView 1 exists as a local entity and executes an application residing on the same portal. Page 1 contains iView 1', which is a delta link of iView 1. Page 1 is assigned as a delta link to Role 1. At design time, the content administrator on the consumer creates a remote delta link (Role A) based on Role 1. The content administrator on the consumer then assigns users to Role A. When the assigned users log on to the consumer portal, the execution of the role and its content takes place on the producer portal at runtime.