Ektron ESync Issues

Ektron E-Sync is a good product when it works but it can really make your users nuts!

E-Sync Logging: E-Sync logging is still very rudimentary and there are lot of chances to improve this. There are no simple configurations to change the logging locations and weird log names like “test.log”

E-Sync must tell clearly what content is published. Currently it is just copying the complete database from one machine to another machine where as a user I dont have any clue what is synced to next environment. It just states there are 150 changes to your database but this does not help when you try to debug some rogue content publishing.

Another annoying thing is, it sync your userids as well across environments. This means if you have AD integration in your production environment and you do not have AD integration in your dev/test environments then your system can break or if you added a user as CMS content author then he can not act as membership user.

Regular Full ESync: If you do not perform full ESync on regular basis then it can take hours next time. In my experience, as part of your publishing strategy you must think upon doing regular full ESyncs..to ensure it does not break the system

A granular control on what we are syncing to next stage is critical for an enterprise scale infrastructure…

Ektron E-Sync C:\Windows\Temp

When you run e-sync then it creates temporary copies of files in the windows temp directory before it actually commits them to actual location. If E-Sync fails then these files are not cleaned up and they stay in windows/temp directory itself. As ESync is using underlying windows sync service, this directory can not be re-configured to some other data drive. Sometime this can cause serious issues on production environment because it will keep on dumping files in C:\Windows\Temp directory and this can make your C:\ drive full silently.

To avoid any future production problems, I suggest to have a clean up program running on your source and target machines which cleans up these temp files on regular basis. It will be good to take a snapshot of the directory as well and move to your data back up drive and send out some emails to support team so that they can analyse the E-Sync failures.

This is a simple thing to perform before your application goes to production but debugging these issues when system is live can cause lots of pains!

Ektron CMS review

Recently I was working on a very large Ektron implementation. Our customer had old legacy bespoke CMS solution which was used by very few people in business. This was simply restricting business to increase their brand awareness.

A highly engaging, relevant, and interesting content driven website is a powerful tool for brand building. To achieve this, an effective content management system is needed and a Strategic approach is imperative for effective content management.

We selected Ektron as the CMS Tool after looking into various different options and last 7-8 months were very much getting Ektron platform deployed, site migration to Ektron from bespoke CMS and enable business users to start using the new toy. Overall a serious change for business and this exercise is lot more difficult because it was a public funded organization where reluctance to change was lot higher!

Why did we choose Ektron?

• Light weight CMS solution
• Quick to roll out
• Light infrastructure foot print
• Easy content authoring interface
• Ability to build good dynamic website OOTB
• Strong taxonomies, menus and collections to build personalized site

Few issues you need be aware of while doing Ektron implementation

• E-Sync : This can drive you nuts! I will write some specific issues I have experienced and respective solutions as well in the coming posts
• Release management : This needs more improvement how Ektron can support multiple complex releases in parallel. Ektron is a very DB centric application. Configuration changes like adding new templates, smartforms, taxonomies etc get added to DB. When you perform E-Sync then there is limited option to perform selective E-Sync. This means when you move your code from one environment to another then it can move everything from database to next environment and you can not control this.
• Integration with Third Party security tools: Example if you want to integrate with Third party external security tools like Microsoft ISA server, siteminder etc then it is not proven and tested integrations.
• Multiples sites using Ektron: You can do this but you need to be careful while designing it!
• Workflows: Workflows are very rudimentary still. Ektron is integrating with Windows Workflow engine in Ektron 9 and I believe this will bring Ektron workflows to right standards..

There are lot more pros and cons in my mind but I will leave them for the moment and will write my next post on specific issues we have faced in the project. Those can be helpful to developer community!

Interwoven TeamSite Usability with personalized content

As we know, content personalization is fairly common requirement in WCM world. Every customer wants to present the information which is relevent to their customers instead of content flood. Content personalization is being asked at user specific or user role specific.Content personalization is probably an old school requirement but still lots of companies talk about it where they have not reached to the extent of personalization, they would like to achieve and bring better conversion rate using their online channel.

When we need to provide personalized content using Interwoven TeamSite, it can go little tricky. Few people may not like this statement but this is the fact or I would say you pick any other content management tool as well and you will find similar problems. TeamSite provides great abilities to integrate it to any delivery platform if we define our content structures and meta model correctly but when we need to define user specific content it looses its charm because of content virtualization.

If you have loads of dynamic content on your site which is specific to a user or a role, then it will not be easy to virtualize this in the CMS and without a completely virtualized site in the CMS, CMS user experience can go really bad!! There are ways around this to define preview templates in the CMS and preview individual pages but it does not give you flexibility of virtualizing the complete site inside the CMS.

The key problem with Teamsite and personalized content is, user will find difficult to locate content inside TeamSite and he may end up browsing tons of folders!!

This scenario happens quite often and only solution I tend to suggest my customers to make extensive use of

Interwoven TeamSite bookmarks or

IDOL search platform

So just a word of caution, please consider CMS usability a lot when you are trying to present personalized content. This may sound simple as part of the implementation phase but it can make your business users absolutely mad when they need to mantain the content!!

Autonomy/Interwoven “Meaning based Marketing”

Couple of months back when Interwoven was acquired by Autonomy, I was fairly surprised about this acquisition. I was wondering Autonomy’s thought process for this move. I was not very clear

• How autonomy will use Interwoven’s flagship product TeamSite?
• How will they market it?
• Did they acquire Interwoven because of its customer based?
• or eDiscovery solution because Interwoven was fairly strong in this area.

But when Autonomy launched its campaign with buzz word “Meaning based marketing” I was able to visualize it clearly!

Autonomy is very good in knitting the new companies under its umbrella flawlessly and it has proven over the time like K2, Verity, Zantaz and Merdio etc which were acquired by Autonomy at one point of time and they were completely absorbed into Autonomy suite.

Autonomy seems to have similar plans for Interwoven as well with its new buzz word “Meaning based marketing”!!

Autonomy IDOL engine which can listen structured/unstructured content on multiple channels and test across all types of customer interactions and then deliver the content to targeted customers. You will find that TeamSite/Media Bin/Live Site all will become part of the bigger campaign from Autonomy now automatically..isnt this cool from Autonomy?

Read this paper from Autonomy and you will get the gist of it!

This concept looks pretty cool on paper but I am very keen to see some working demo or web cast of it which I am not able to get hold of…

Share your views on the success factors of this campaign from IWOV ..aha no Autonomy!

Fatwire/Portal Integration

Long time, didnt write much about my latest experiences of CMS world!

Okay recently I got a chance to explore Fatwire WCM and further to work on Fatwire/Portal integration problems. This was fairly interesting project where I found, a service company delivered a working solution without considering the operational mess of it!

Fatwire is fairly light weight product, you can get it up and running fairly quickly compared to Vignette where you need to consider multiple servers and couple of services and then integration between its services for its deployment architecture. Fatwire WCM is a again a simple war file cs.war which can be deployed to your loving application container like Tomcat, Sun portal, JBoss ..so personally I do not see much of compatibility issues.

Flex assets are great capability of Fatwire which enables developers to add new fields without much of problem. Flex assets means flexible assets which can be extended on need basis. Design of flex assets is key but lets not go into that detail for the moment. Fatwire works great when Fatwire is going to work in the delivery stage itself but this is not the real world scenario.

Large enterprises tend to use some robust and proven delivery application servers like Weblogic, Sun portal, JBoss etc …so challenge comes while integrating Fatwire with portals.

As always, while integrating CMS solutions with portal, we always ask a basic question before start thinking about detail design

• CMS centric design which means CMS will have more control on the implementation
• Portal centric design which means portal will drive the navigation structure and content

and as always, business wants to have more and more control on the site instead of IT to avoid raising change requests, waiting for release cycles so I tend to push for CMS centric design some time.

To achieve CMS centric design, Fatwire WCM has to expose content to delivery platform and to expose the content, Fatwire WCM provides web services like

• Asset.wsdl
• AssetSet.wsdl
• Miscellaneous.wsdl
• SitePlan.wsdl

Each web services exposes set of functions which can retreive the content from Fatwire WCM and display on delivery platform.

Although we can retreive content but I would like to make you aware that the complete integration framework can be fairly complex where you need to agree all the interface specs between CMS and the portal so that portal can understand the content and consume it. This can be a daunting task and over all delivery time can be couple of months itself depending upon your experience level itself.

A portal centric design using Fatwire can have very easy implementation but it has serious impact on the CMS usability and you may end up delivering a system which is managed by your support teams instead of  business users.

CMS and portal integrations are critical aspect of your web site delivery and while defining the integration framework, you should seriously consider about the operational use of the content management system. You may get a working system as part of your delivery but you will realize the actual solution when it is operational!

Interwoven TeamSite migration

I just completed a very interesting project where we upgraded legacy TeamSite 5.5 to latest TeamSite version 6.7.2 and another instance of Interwoven TeamSite 6.5 to TeamSite 6.7.2. This project was just not only upgrade but it was migration to new data centre as well which adds complexity to it and while moving to new data center, we need to bring all the best practices to ensure Interwoven platform is supported and mantained correctly in future.

In this blog, I have defined the high level steps for Interwoven TeamSite upgrade.

Further TeamSite upgrade has two parts

• Code uplift
• Content uplift

Lets talk about content uplift process itself. This is the scenario where you are moving your TeamSite instance from one machine to another machine

• Copy the content stores from production CMS 5.5 to target interwoven TeamSite 6.7.2 environment.
• The content store size can be quite large, so plan for couple of hours downtime on production machine to copy the content from existing TeamSite 5.5 to latest TeamSite 6.7.2.
• To copy the content, you can do it various ways like

1. Tar the content store and copy tar file
2. Use disc copy from one machine to another machine but this is generally quite difficult to copy the disc across data centers
3. If you are existing machine is correctly integrated with back up solutions then you can use netApp facility to clone the file system. This can be really handy and it can be done in the matter of minutes!!

• Extract content to the target backing store like /iw-store/archive. This step can take couple of hours and further it depends upon the size of content store, network speed, I/O speed.

Pre-requisites for Content Extraction

• Avoid extraction of content store on the same file system mount where your TAR file is located because it can cause high number of R/W operations on the disk and it can slow down the process.
• Before kick off content extraction, always ensure  that you have enough amount of disc space to extract the content
• Ensure you have enough number of indoes available for archive store and production store mount points. This can be extremely difficult to recover if your content extraction copy, extraction process breaks in between.
• Ensure, all the back ups etc are cleaned up and turned off before you kick off content extraction. You are going to extract large amount of content and your content snapshots can take up your complete space itself.
• Kick off content extraction and it will take couple of hours to complete
• On completion of content extraction, create new content EDITIONS to ensure the latest content in STAGING area of each branch is part of your EDITIONS as well. You need to perform this because IWMIGRATE only migrate EDITIONS and it does not migrate STAGING area and you will loose content history from STAGING
• Before we kick off iwmigrate, we need to run user migration on archive store and production store. There are set of steps we need to perform this and couple of Do’s and Dont’s which will be part of my next blog for Interwoven user migration.
• Please ensure it 100% that user permissions are correct on archive store and further, there are no existing tokens on your target production store.
• Follow the same set of checklist for production store as well like disk space, inodes, backups, snapshot clean up before you kick off iwmigrate

/iw-home/bin/iwmigrate -m /iwmnt/default -o /iw-store/<store name> -b /default/main -a 200000 -g

Cache size is fairly important and it can break your content migration if it is not set correctly.

Here we are migrating the content from default backing store to btcom backing store where -a option means cache size -a <cache_size > Number of objects kept in the cache

You can always redirect the log of iwmigrate to a log file for monitoring and further please ensure to run iwmigrate  in background so that it does not break because of connection timeout.

DB/FileSystem based content repository

This is a very interesting architecture question..While building a content management system this is the most important decision to determine about the content repository.

There are lots of pros and cons on this…

DB Based Content repository:

Key advantage for DB based content repository is

Dependency management: If content set is mapped inside the database then any change in one content item, will manage other content items quite effectively. This is one of the key pain point, I see with the file system based content management systems. Any organization would like to have content integrity on its website and to ensure that dependency management of the content is absolutely important.

For eg if we are updating a news article, then news item will be updated on your home page, news home page and actual article page itself..

If we need to perform this in FS based content repository and site is static then it is bit hard game to manage.

But still file system based content repositories has lots of advantages

1) Content versioning: You can manage content versions very easily like any other svn system..You have lot better auditing in place.

2) Point in time snapshots: You can manage point in time snapshots very easily. Using IWOV, you can take content editions and you can roll back to older edition to any point of time. You can keep site history 3,6,9,12…anything very easily. This is a great feature from content audit stand point

3) Release Management: You can manage multiple releases at the same time in very effective way using file based content repository. For example if you have a large website and you have multiple teams working at the same time on different releases. As part of release cycle, if you need to add some content to your production system then you can add delta content on development systems and you can move the content as delta content to your production system..Content merge across various application releases is fairly challenging for DB based systems.

4) Hardwired DB tables: Database tables are very hardwired and any change to those tables is not straight forward once the system is set up. Further if your system architecture is completely DB dependent then if later on you need to alter your content structures then it fairly complex operation in Vignette. So your content type definitions are one done are not very open for modifications

5) High DB Connections: To get simple information, you need to connect to the database and so many DB calls are always cost you in various ways. For example in Vignette, complete content is stored in database,

To fetch the content they have a huge SDK but so many DB calls were hitting performance massively and because of this they have released new API set which is getting the values from DPM cache.  This leads to DPM cache settings and again there are good number of performance glitches and now next solution is HPD…(High performance Delivery) I hope, I am clear where I am heading here!

Further if multiple people need to work on different areas of content and preview there own web sites then it is fairly easy using FS based CMS systems like IWOV/Alfresco where people have there own workareas or sandboxes but this is level of granularity is not easy to achieve in Vignette

So there are lots of areas where we can see challenges on this and will be great to know what do other developers think about it…

Alfresco Content deployment capabilities

Okay I have written about IWOV, Vignette and let me put more thoughts on Alfresco now

I am quite facinated with Alfresco, but at the same time I would like to say, still it has to go long way to server large organizations!

One of the key challenge we identified recently with Alfresco about its content deployment capabilities

As per my analysis, content deployment architecture is still in its very early stages and it needs to mature a lot for sure. Currently with Alfresco we can not do deployment to the database, if you need to write anything to the database then it can be written using custom java classes but it leads to the issue of transactional content deployment..basically if I want to deploy all the static files and need to publish all the articles to the portal side database as part of the same transaction then it is not possible. Your DB records has to go first and then you will invoke the file system deployment.

Further if I need to run the file system based deployment as an external service then it is not possible

Alfresco porvides transactional capability if I need to deploy static content to three servers but if we need to deploy mix and match of the static content then it is not possible..

Further, as part of the content deployment, if I want to index the content or clear the cache on the portal then there is no way to bind both the things together.

Content deployment service from Alfresco needs lots of further extensions…

Issue with VCM Versioning capabilities

I had a very interesting week…I was working on Vignette implementation from last couple of months and we are using VCM 7.5, VAP 7.4, VBIS for content migration, FURL etc..

Recently my client asked me about audit capabilities using VCM and I started exploring more on this area, I was amazed to find some facts..I was expecting Vignette to have very strong content audinting capabilities but to my surprise Vignette struggles with it ..

VCM just provides very rudimentry versioning capability and even to take automated versions, you need to write custom triggers. Truly I never expected from enterprise content management system to have such a basic scale of versioning capabilities.

Further you can not take point in time snapshots using VCM…which means if for any reasons, a site needs to be rolled back three months back, then you just can not do it. Only way to rollback is to rollback the database and you will loose all the information for the three months. This was surprising for me and I had long discussion on this on Vignette developer forum and Vignette Sr product manager Bertrand de Coatpont provided his views on this.

Bert explained this and reason for it was, VCM has its content repository in the database and you can not have check in check out, versioning capabilities if content repository is as file system..something similar to Seibel, SAP etc..You can read the complete discussion thread using the below link

http://success.vignette.com/gm/message-1.24.40524

VPS has developed an extension for it which provided the capability to know the content item state before or after modifying the content item but it needs to be integrated with product in the upcoming releases..Vignette has confirmed that this is part of their laundry list at the moment.

Now this particular point opens a very interesting architectural discussion which is while building the core foundation of CMS product then, file system is the right place to store the content or database..

I will write about this in my next post..