Concept Synchronization

Problem Description

Public instance gets corrupted. Author is intact. Heavy usage of author instance, means there are many already modified and/or unpublished pieces of content.

Possible solutions

• Reactivate all content from existing public to new public
  • needs at least 1 public instance that is not corrupt
  • will increase load on surviving public instance while republishing.
• Reactivate all the content from author to new public.
  • The modification status is lost
  • All the content, including not yet approved gets published, creating potential leak of information for the client.
  • Change of configuration to subscribers is necessary forcing administrators to disconnect existing public even if it is only partially corrupted.
• Export/import all content
  • memory and CPU intensive operations
  • requires split and concatenation of big xml files
  • creates issues with reordering of content
  • in case of export from author, needs post processing to remove all modified and not yet activated content
  • not possible to republish previous versions of content, even if exists.
• Selectively reactivate content from author
  • needs special activation to traverse the content tree and
    • on not versioned author activate only previously activated and not modified content
    • on versioned author activate last version of content for previously activated content (can deal with modified content since published version exists)

Proof of Concept

Selective reactivation have been implemented and put in the enterprise incubator. Developed solution adds new menu entry under the Tools menu to schedule re-activation task. Task is performed asynchronously, to allow activation of big trees that will take considerable time and might be interrupted by session expiry if ran interactively. The task bypasses existing syndicator and subscriber configuration to allow reactivation to run with minimal disruption to normal business operations performed on the author instance. The solution is able to publish content to the public instance that is using either simple or transactional activation.

Future enhancement

• develop Journalling syndicator, to allow for replaying journalled ops and re-synchronizing public instance after it was out for certain amount of time.
• develop configuration in which all the content in it's current status will be published and keep log of such publishing to allow for periodic re-synchronization (special care would be needed to handle versions created on the author when performing such re-sync operation).

While public instance is protected by redundancy in standard EE setup (2public + 1author), there is no redundancy or any other kind of protection for the author instance. This feature would allow to keep hot backup of author instance for clients with high editorial workload and need for such in place replacement for the author. In this case client would have 2 public instances + 1 active author (AA) + 1 hot backup author (HBA). AA will have enabled subscribers and would publish all the content to public instances. On top of that AA will have scheduled task to use this silent activation for all content every hour or so, to resynchronize all content on HBA. HBA will have exactly same configuration as AA, but with subscribers switched off. In this case should something happen to the author instance, client would have immediate replacement for author instance and would loose at most 1 hour of work of editorial team since all even not published content will be synced on HBA.