Automatic Approval vs Multi-Destination Publishing

After the introduction of WebCenter Sites 11g8 version, Sites provides various improvements from creation of vanity url to proxy-assets to various customization hooks. One of the new customization hook introduced was - RealTime Publishing Customization Hooks which describes on how one can develop a custom solution for multi-destination/multi-target destination publishing. Although official guide provides full detail, I recommend to read this article once.

Thus, there is already an custom solution to:
1. Publish assets simultaneously to multiple destination. Furthermore, publishing to disaster recovery server can also be included.
2. Publish audit trails: Who published what and when
3. Minimize the effort of Contributors and Publishers

In one of my previous blog post - Automatic Approval of assets, I provided a glimpse on how to create a simple custom solution to automatically approve assets wherein administrators have control over setting up time when approval of content should occur which is similar as configuring scheduling publishing. With this approach:
1. Content is approved automatically to targeted destination
2. Admin has choice of selecting which content type (asset type) should be approved
3. Scheduling configuration just like scheduled publishing
4. If proper solution is developed, wherein administrators can easily disable/enable System Events, update asset types required for approval, destinations, scheduling, etc; automatic approval of assets can be helpful in various scenarios.

So, now which one to choose? Automatic approval or Multi-Target Publishing?
I have listed down few points which can help in deciding which mechanism will meet your requirements.

Features	Multi-Target Publishing	Automatic Approval
SCHEDULING	Although multi-publishing mechanism provides scheduling; it fails to configure different time settings for different destinations. This may be required sometimes when a piece of content is required to be shown at different times according to timezone and place; given that delivery servers are located at different geographical locations.	As automatic approval event itself is separate event, administrators can set automatic approval event for different target destination to different time as needed, furthermore, they can also set scheduling publishing as required.
EFFORT	This tasks will take only one step i.e. to build the solution and deploy it, that's it. Although it is one step process, if any regular changes required, it may require many changes within the solution; including restart of delivery servers which may not be desirable at all to customers.	Once the automatic approval element is ready which can intake assettypes and target destination as parameter, it is just matter of adding row in SystemEvents table. But if there is no way to update SystemEvents table via SiteExplorer (blocked due to security reasons), developers may need to build few more custom elements to add/update/delete approval events within SystemEvents table.
AUDITING	As already mentioned in developer's guide and the Oracle PDIT blog, one can also add methods within same implementation to include audit trails as required.	This mechanism can be very helpful in maintaining separate approval logs and publishing logs can be maintained.
NOTIFICATIONS	Publishing logs will contain full verbose output. But only those users with access to Admin UI can check the status and output. To access publish console from Contributor UI, will require another customization which is aptly described here - https://blogs.oracle.com/pdit-cas/entry/exposing_the_publish_console_in	Same customization of exposing publishing console can be helpful to know which assets were published. For approval messages, user can select the asset and check the status of each assets individually.
CONFIGURATION	After custom solution is ready, configuring multi-target publishing is very easy. It is the same process as one would configure publishing destination but with few more arguments.	Configuring automatic approval can be tedious task as admin has to manually add/update row within SystemEvents table. But if custom solution is developed for adding/updating rows, then it can become quite easy for administrators to maintain different approval events.
CAVEATS	One of the major problem with this functionality  is that it is required to restart all target servers as there would be changes made within AdvPub.xml file, but it is one time process. But there are other alternatives one can take like routing the traffic to other delivery server until other is restarted or content can be served from CDNS until all delivery server(s) is/are up and running. Another issue is even if any one of the target server is down, although assets were published to other running target server(s), assets are marked as NOT published for all the servers; whether they were running or not. Thus, assets will get published again next time  to all servers which may degrade performance depending on cache configurations.	One major problem is configuration i.e. adding or updating or deleting entry in SystemEvents table. But if custom solution is build for configuring automatic approval, then it is very easy for administrators. Another issue can be as it is more of custom solution built around WCS elements and not a separate customization hook, one has to make sure that during upgrade, custom elements are to be taken care of. Developers need to re-test the functionality again if OOTB approval element was changed.

So there you have it, all pros and cons of both mechanisms. There is no preferred or superior option to other. One has to weigh both the options according to cache configurations, architecture and of course, customer requirements. Furthermore, both mechanisms can be mixed and used as needed. For e.g. Multi Realtime publishing can be configured for delivery servers whereas test servers can be setup for automatic approval of content + scheduled publishing during no/less editorial activities.

Disclaimer: The code and/or the configurations posted are not official recommendations and should be used at sole's discretion with proper testing before deploying on live WebCenter Sites systems. Cheers!!

Showing alert message to users

WebCenter Sites provides various customization hooks for customizing Contributor UI as mentioned in Developer's guide. But there is no illustration provided on showing custom message(s) to Contributor UI users either via simple alert or floating modal window.

When can custom messages be helpful? 
Few use cases of showing custom message(s) which can be:
1. Showing welcome message
2. Showing message for changing password every 3 months
3. Showing message for upcoming event or scheduled maintenance period

As WebCenter Sites provides customizing Contributor UI via SiteConfigHtml element, it is very easy to create alert messages.

Simple welcome message can developed by creating CustomElements/UI/Config/SiteConfigHtml element using either Admin UI or Sites Explorer. Add the following code within SiteConfingHtml.jsp as shown below:

Now whenever any user logins to WebCenter Sites Contribution UI, welcome message is visible as shown below for fwadmin.

Welcome message!!

Above example is very simple one. In order to show message like scheduled maintenance, password change alert, deadline of a task to particular user or other important messages; one can simply make Ajax call to certain WebCenter Sites element and show corresponding results from the element in the alert message.

For e.g. Consider showing same welcome message via an element rather than defining within SiteConfigHtml.jsp.

1. Create a CSElement and add the code: Welcome <ics:getssvar name="username"/>! between opening and closing tag of <cs:ftcs>
2. Create a SiteEntry and associate the above CSElement (Wrapper=NO; pagelet=NO; uncached)
3. Make Ajax call from SiteConfigHtml.jsp to call the above SiteEntry and show the message only after Contributor UI is loaded. Add the following code within SiteConfigHtml.jsp:

Output should be same. Thus, it is very easy to create alert messages within Contributor UI which can be very useful sometimes when combined with other functionalities like system events, publishing, asset operations, etc.

Disclaimer: The code and/or the configurations posted are not official recommendations and should be used at sole's discretion with proper testing before deploying on live WebCenter Sites systems. Cheers!!