Category Archives: Vignette

Vignette Migration – Launched!

Well the launch went off rather well… The website publisher and his staff have a lot of issues, some of which we cannot resolve because we had to make decisions based on the entire corporate data, not just theirs. Luckily, we’ve been able to resolve most of their issues…

Most importantly, the CDA code is handling the traffic extremely well and is performing very well. We had to add some caching on the java server so it wasn’t querying the database for every user request. The Vignette piece is doing ok, although it seems rather slow if we have any type of migration script going at the same time as we’re trying to use it. We only have about 10 users on that part of the system, but the migration scripts are fairly intense with their calls to the Vignette API to insert our data from v6 (we try to run them at night most of the time).

We’ve also had some issues with our Google box crawling the new site properly. We tracked it down to an issue where our CDA was giving a response code other than what it expects for a redirect. If your page gives a 302, then Google indexes the redirect page but stores it at the original location. If you give a 301 instead, Google will follow the redirect and store the information at the new location. Normally this wouldn’t really matter for search results, but we have a contextual ad system which relies on the locations being in the proper place for ads to show up correctly.

Now we get to focus on the really difficult part… launching the rest of the sites, one per day, by a January 31st, 2006 deadline. Wish us luck!

Technorati tags: , , ,

Vignette Migration – T-1 Day to Launch

The site is really coming together now. We have all the XSLTs in place and are in final review stage – what we’re calling NitPick. We’re tracking all the issues in a bug/issue tracker and then going back through the XSLTs to fix issues that surface. We still have a few systems that we won’t really be able to test until the website is launched – namely the Google crawl and our contextual ad system. But those are both based on the Google crawl which should work correctly.

Of possibly more concern, the VCM is taking up to 5 mins to publish items. We have several more publications worth of data migrated over, so hopefully it isn’t a function of how large the database is. We asked VPS point blank if this was a problem, and they said no, the only issue would be without how many concurrent users on the VCM itself (we’re under 10).

This past week we worked heavily on improving the performance of the CDA. We reindexed and analyzed the Oracle tables, which reduced the response time by half on the home page. We also implemented jboss caching on the Production stage, with a time to live of 5 minutes. We’re going to do a last round of load testing today to see how well the caching is doing. There are more places the code can be tightened up in the next few weeks and we also have some options for clustering and server enhancements.

Launch is looking like a go, so keep your fingers crossed for us….

Technorati tags: , ,

Vignette Migration – T-One Week to Launch

We’re hoping to launch our first website in the new hybrid Vignette v7 system at the end of next week. Our custom CDA (Content Display Application) seems to be running well, and we’re just coasting on bug fixes as we find them. The team is focused on finishing the XSLTs so that we can display the different content items properly and we actually have what looks like a proper website coming together. We should have all of next week to hammer on the system and work out any bugs, plus have layout review to make sure all the content is displayed properly. We also have to integrate and test some of current systems with the new website, including our Google crawl and our new NetTracker software.

Our SysAdmin is going to be running some bandwidth/traffic testing to see how the system holds up. We had done intial testing awhile ago, but we want to make sure it still looks steady before launch. We have setup the system to allow for clustering of the various systems for scalability.

Currently I am also working on the list of features we will be putting into version 1.1 of the system, as we are implementing a much tighter versioning/daily build type of mentality to protect the asset we have coded.

Technorati tags: , ,

Vignette Migration – Current Thoughts on v7

Anyway, my opinion about v7… I’m not really very happy with it right now, but let me address why we chose it. I looked at completely replacing Vignette as our CMS solution instead of going to v7 or renewing our v6 support. However, all the solutions that were out there just were incredibly expensive for the number of sites we have (they had a per site licensing usually) or for the initial investment we would have to make. So we decided to go with v7 because it was a “free” upgrade.

Initially I was fairly impressed with the VCM and their Portal. However, as we dug deeper into the design and our own requirements for the redesign, we decided to design our own CDA on top of their VCM (it saves licensing costs as well). Now we’re in a situation where our own CDA is working fairly well, but we’re having a lot of problems with serious limitations of the VCM. Some of the major problems include having to use widgets to extend the functionality that should be there our of the box – you either have to pay VPS for these widgets (which are expensive and they only support for one upgrade) or you have code them yourself (or have someone else code them). The VCM API is very hard to use and there are a lot of hidden functions and functionality that VPS does not release out to the world (we happened to get them from former VPS employees).

We just rolled out the VCM to some of our employees to train them on content entry. They almost rebelled! The system was so much more difficult for them to use than v6 that they didn’t want to even try to learn it – and these were some of our more technically savvy users. So, we’ve come up with some compromises to make their lives easier, but we are considering the possibility that we may write a layer above the VCM for content entry work. This will probably lead to us completely removing Vignette from our systems when we write our own CMS as well.

Technorati tags: , ,

Vignette Migration – Special Characters – Argh!

Argh! Special characters in our v6 content has caused major headaches for our v7 migration scripts.  Our v6 content entry system has no checking of the content entered into the database (other than perhaps a successful insert).  Content Entry people have entered all sorts of strange characters into the system.  Our migration scripts often are able to successfully enter the content into the v7 system, but the v7 system can’t handle the publishing of those fields into XML.  The Vignette XML parser throws errors when it goes to publish the content into XML.  We have had to make our migration scripts much more robust at error checking the content fields before the data is entered into the v7 system.

Another problem we’ve run across is all sorts of different data entered into fields it should not have been.  Plus data being entered in multiple types of ways.  For instance, we have a company profile content type, which has address fields, including city and state.  There is no standardization of how users have entered the state… sometimes you get the full name: North Carolina, sometimes the postal appreviation: NC, sometimes a partial abbreviation: N. Carolina, and sometimes whatever they felt like typing: N. Carol.  Granted that a lot of the problem is that these freelancers are copying what is in a print magazine issue, and there is no quality control process (or quality checking in the v6 content entry system).

The migration scripts have had to handle a lot more data cleansing than we had hoped to have to do.  In our original migration project planning, we were going to clean the v6 data fields of any html or strange characters and do data cleanup of the states, etc.  However, we didn’t really have time for the extra step due to the schedule that has been given to us.  So… we’ll do the best we can, and spend a little extra time watching over the migration of each publication.

Technorati tags: , ,

Vignette v6 Down!

This week was more exciting than I ever want to have for awhile.  The v6 servers started acting extremely slow on Monday around noon – they were maxing out the Oracle server at 100% cpu.  We tried restarting them several times and finally we just had to take them down.  One of the webservers had a corrupt hard drive, so we took the downtime to run chkdisk on it.  Meanwhile, we put in a support ticket with Vignette to figure out what was causing the Oracle database to max out at 100% cpu.

We tracked the issue down to the cstld process from the CDS in the Oracle logs.  The CDS was spawning multiples of them at startup, many of which were inactive, and they were spiking the CPU.  Vignette’s first step was to increase the logging on the CDS and all the webservers configured on it.  Their initial reaction to the Oracle cstld process was to increase the timeout for the cstld so that the CDS wouldn’t leave the inactive processes hanging.  We restarted the CDS, but it didn’t help any.

In the log files, Vignette noticed 2 strange occurences: 1) a web server that wasn’t responding and 2) an IP address it was trying to connect to that was timing out.  The first one turned out to be a phantom web server – one that had been improperly removed from IIS but not Vignette.  At startup, the CDS was trying to connect to it and configure it with information from the CMS.  This ended up being the cause of the 100% CPU usage on the Oracle box.  The second one was an IP that used to be used by a vignette web site, but now was in use on a non-vignette website on another server – which didn’t speak vignette.  I removed both from the system using their knowledge base article about phantom websites.  After a restart, the websites all came back up on that CDS and Oracle was happy.

Now to repeat the process on the other CDS…

The second CDS had 4 phantom websites, so I removed them following the same process.  After rebooting the server, the websites came back up and Oracle was still happy.  Now the question is why this happened on Monday at noon.  We had restarted the entire complex on the Thursday before with no ill affects.  What had caused the system to suddenly have issues with Oracle?

After letting the websites purr for half a day, I gave my team permission to start using the development environment again to fulfil website changes.  I told them they could save changes but not to launch until I gave the go ahead.  Meanwhile, I was testing launching on my own and there seemed to be no ill effects on Oracle.  I gave the go ahead and everything seemed fine for a few hours.  I had a 2 pm meeting which I went to, but an emergency ticket came in during the meeting about all the news items on a particular site not working.

I went to investigate and suddenly two other website were completely down… giving 404 errors.  We were seeing this earlier in the week but couldn’t track it down.  Well, it turns out people on the web team were making changes and not previewing the templates before launch.  There would be an error on the template that they made live and they also didn’t check the site to make sure it launched correctly.  Further laziness abounded in that no versions were saved so there was nothing to fall back on.  I ended up having to extract missing templates from the database and painstakingly debugging the sites to get them back up.  As it stands now, all the websites are working, except one site’s archive, which I need to do further debugging on.

After running through many of the sites trying to get them back up, I noticed that no one has been saving versions.  This prompted me to remove everyone’s access to development so we can go over proper procedures on Monday morning.  If versions had been saved, I could have done a quick restore of the faulty templates and brought the sites back up within a few minutes.  Instead, two sites were down for over a day, with lost revenue from their advertising, plus my lost personal time on nights and evenings.  This is a professional publishing company, we need the web designers to act professionally.  Quality over quantity.

I do want to give proper credit to the Vignette tech, who helped me through the Oracle issues, Sunny was a pleasure to work with and took steps to escalate the problem when I needed to.  She walked me through commands and made sure I knew what I had to do.  I’m not a Vignette expert and don’t want to be, but she treated me with respect and understanding.  Thanks Sunny.

Vignette Migration – Preparations to Launch

We have what is hopefully the full checklist needed to launch our first website in the new system.  We’ll be going over it tomorrow (Tuesday) with the group to make sure everyone knows what they are doing and who is responsible with what.  We’ve been using BaseCamp to keep track of everything for each of the websites and we’re going to make sure everyone is using that so we know at a glance where each website is.

Our checklist includes:

  • Training the publication’s content entry staff on the new systems so they have time to get used to it before they are forced to use it.
  • Finish preparing the static HTML pages, including applying the CSS and entering them into the Vignette v7 CMS.
  • Create the XSLTs and the Preview app for the content types.
  • Finish setting up the Production Environment for the CMS/CDAs.
  • Setup the Layouts for the publication website.
  • Run the migration scripts to move the content from Vignette v6 to v7.  Then we have to go through and check the content for any v6 URLs are remove them.
  • Code a custom 404 script to try to direct users to the proper content if they come into the site using a Vignette v6 URL.
  • Rewrite the static content URLs so that we can use some type of token for them in content entry.

It’s not a final list, but includes the big stuff.  Lots of detail to bring together and we’d like to get at least a beta site finished in September so that the publisher can run through it and make sure everything was moved over properly.  It’ll also give us time to work out any bugs we may find in the code/process.

Technorati tags: , ,

Vignette Migration – Static Pages Headache

One of the biggest problems we are facing in the migration is all the static HTML pages we have on the sites.  If we weren’t changing the look & feel of the websites at the same time, it wouldn’t be such a headache, as we could import them directly as static pages in v7.  However, since we are changing the look of the websites, we have to go through every static page and remove any references to the header, sidebar and footer.

The other issue is the static image and pdf files.  They’re not too difficult to move over, but both the URLs and the Vignette IDs used to reference them will change in v7.  So we have to go through the system and look for any hardcoded urls in the content.

On top of these issues, our publishers need to continue to update some of the static pages, so we have to keep track of when updates occur and try to make sure we have the current copy of the pages when they go live in v7.

Technorati tags: , ,

Vignette – You have to buy the Support we want to sell you…

Our support contract with Vignette is up.  So they sent me a new one – which has several problems with it.  First off, they’ve been overcharging us by 2 CPUs for supporting a development box (you only pay for production CPUs) and they’ve been doing this for years.  Secondly, we’re in the midst of the migration to v7 and that environment only has 1 production CPU (yep, we learned something from the v6 environment).  So when I asked them to just charge us for the v7 support since we were going to migrate to it this year, they came back telling me what support we could have (as opposed to what I wanted).

I was told that the support for the v6 environment would cover the v7 environment during our transition, which is nice but very expensive.  As long as we require support for the v6 CPUs, we have to pay for it, which is true, but I think we can be the judge of what we need support for.  If that system was to crash in the next year, we only get phone support anyway and that’s not going to be much help.  More importantly, I was told that they would have to get their legal department involved to change the support to remove the 2 CPUs they’ve been overcharging us for, and certainly if we just want to pay for the 1 v7 CPU.  They also questioned why we only had 1 CPU in v7 – maybe because all of the issues we’ve had with your product add up to us trying to minimize the risks and committment we have to it?

And since I’ve given them low marks on their Customer Satisfaction Survey, now all of sudden all the divisions want to know why.  Why should I spend the time now to educate them when they make my job so much harder than it has to be?  Why do I have to figure out how to minimize our use of their product because of all the problems with it?

Technorati tags: , ,

Vignette Migration Update

We are currently in the midst of coding the Content Display Application (CDA) as a Java application.  We have the framework done as well as the page generator.  Later this week we hope to have a proof of concept to make sure that our design will work the way we intend.

Next up is the form generator, which will allow forms to be created in the VCM, and then displayed through the CDA.  Automatic validation of form elements, and then execution of the form action is included in this code.  This should simplify the work required by web designers to setup various forms but still allow us the flexibility to support all the various forms that are currently out there and that will be out there in the future.

We are still trying to work out issues with the migration scripts using Vignette’s VBIS application.  If we cannot resolve them in the next week, we will have to code our own scripts to move the data from one database to the other.  This may actually allow us more flexibility to move the data properly, but it will require additional work to create code that is supposed to be supported with the VBIS application.

On the publication side, we are about halfway through redesigning the look & feel of the websites based upon the redesign template.  We have started to create site maps which will help us understand what content on each site is in content entry (in the database) and what is static HTML files which we will have to cleanup and manually enter into the database for migration.

Once a site map is created, we are walking through each site with each publisher to help them understand the process and what content is what.  Any content that should be in content entry which is not we are having the publication enter, and once we reach this phase, we are putting a freeze on all static html pages on the website so that we may prepare them for migration.

Ordinarily, if we were keeping the same look & feel on v6 and v7 we could very easily use the VBIS tool to move the content as static files.  However, with the new look & feel, we have to strip out most of the html from the files, apply the new style sheet styles, make sure the opening and closing tags match, and then enter the html into the database through the v7 VCM.

Technorati tags: , ,