How web part replication works (Webpart) (4277208)

This Knowledge Base article provides assistance with the following:

• How web part replication works
• Things to keep in mind when building custom web parts.
• Location of the assemblies for custom web parts.

Resolution

Once Replicator receives a queued item notification, either captured or queued, that the web parts on a SharePoint web part page have changed on the source web application (WAP), the following steps are performed in order to replicate these changes to all of the Replicator enabled target web applications:

1. Determine the URL for the page containing the web parts. This could be a web part page (e.g. Default.aspx), a publishing page in a pages document library or a list view web part of a public view page for a list.
2. Review each web part on the page on the source web application and determine if the web part is a Replicator supported web part. If the web part is supported, then package the web part with all its properties that are marked as serializable, and then place them into a Replicator custom property bag.
3. Once all of the supported web parts on outbound page have been processed, Replicator will serialize the package and notify the target server that a new package is ready to be downloaded.

Inbound Steps

1. Replicator, running on the target server, then accepts, downloads, and deserializes the replication package.
2. Replicator applies all of the events in the package to the target web application. First, we locate the appropriate SharePoint web site and target web application's page where the web parts are to be added.
3. Replicator now examines all of the existing web parts on the target web application's page and removes any of the web parts that are supported web parts. This step is necessary to ensure all the web parts are added to the proper zones and in the correct order on the page. This also ensures that the same

Once Replicator receives a queued item notification, either captured or queued, that the web parts on a SharePoint web part page have changed on the source web application (WAP), the following steps are performed in order to replicate these changes to all of the Replicator enabled target web applications:

1. Determine the URL for the page containing the web parts. This could be a web part page (e.g. Default.aspx), a publishing page in a pages document library or a list view web part of a public view page for a list.
2. Review each web part on the page on the source web application and determine if the web part is a Replicator supported web part. If the web part is supported, then package the web part with all its properties that are marked as serializable, and then place them into a Replicator custom property bag.
3. Once all of the supported web parts on outbound page have been processed, Replicator will serialize the package and notify the target server that a new package is ready to be downloaded.

Inbound Steps

1. Replicator, running on the target server, then accepts, downloads, and deserializes the replication package.
2. Replicator applies all of the events in the package to the target web application. First, we locate the appropriate SharePoint web site and target web application's page where the web parts are to be added.
3. Replicator now examines all of the existing web parts on the target web application's page and removes any of the web parts that are supported web parts. This step is necessary to ensure all the web parts are added to the proper zones and in the correct order on the page. This also ensures that the same web parts exist on both the source and target web applications, and that there are no orphaned web parts on the target web application’s page that did not exist on the source web application’s page (unless they were marked as unsupported). If you wish to have an unsupported web part removed from the target web application’s page, then you must do that manually.
4. Replicator examines the web part property bag and adds each of the web parts and their properties to the target web application’s web part page. If any warnings or errors are detected as we process each of the web parts, then they will be recorded and subsequent web parts will be processed, until all of the web parts have been processed on the inbound page.

Notes:

If you have the ProcessUnSupportedWebParts configuration flag set to true, then Replicator will process all web parts as being supported. That is, web parts will be packaged on the source web application and cleared from the page on the target web application before re-adding all of them to the page on the target web application.

You should always ensure that you have properly tested the replication of any custom web parts in a non-production environment before installing them into the production environment and enabling the ProcessUnSupportedWebParts configuration setting.

Best Practices for Building Custom Web Parts

Make sure the custom web part does not use any properties containing GUIDs that cannot be resolved on all the target servers. GUID values are not the same on all servers. For example, do not use List IDs, User IDs, Site IDs, Web IDs, List Item IDs, and so on, as web part property values. It is best to use a descriptive name to represent the list, such as the title of the list, since this value can be serialized and does not have to be changed or resolved, as long as the list has the same title on all servers.