First OpenText Web Site Management Server 11 Technology Preview Feedback

Today, I got the first performance feedback from our technology preview partners. Some partners who tested with big projects that had caused some headaches in the past, where quite excited about the performance. While doing a publication, the cpu usage climbed up to 90 %, memory was filled and working in SmartEdit was possible with a very good performance.

Maybe some of the partners who tested this could step up the plate and give more insights on their performance measures.

Some insides about the technology preview VMware:
We delivered a VM based on Windows Server 2008 x64 with 4 GB of ram, using 2 CPUs. For sure, it is possible that partners with adequate hardware could change the settings and test with even better hardware.

Using PDF 1.6 With OpenText Web Site Management Asset Manager

Reading metadata from PDF 1.6 documents in the released OpenText Web Site Management Server
versions is not working at the moment, as a quite old 3rd party component (pdfinfo.exe) used by the
AssetManager is not supporting newer PDF versions.
There is a pretty easy way to come around this limitation. All you need is the freely available
iTextSharp library and this small piece of code to create a console application called PDFInfo.exe
that behaves like the old version, but can handle the newest PDF versions:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using iTextSharp.text.pdf;
namespace PDFInfo
{
    class PDFInfo
    {
        static void Main(string[] args)
        {
            PdfReader reader = new PdfReader(args[0]);           
            Dictionary<string,string> infos = reader.Info;
            foreach (string key in infos.Keys)
            {
                string value = infos[key];
                switch (key) {
                    // check if the date has to be transformed otherwise
                    case "CreationDate":
                    case "ModDate":
                        value = value.Replace("D:","");
                        value = value.Trim();
                        break;
                }
                Console.WriteLine("{0}: {1}",key.ToLower(),value);
            }
            Console.WriteLine("Pages: {0}",reader.NumberOfPages);           
            Console.WriteLine("Encrypted: {0}",reader.IsEncrypted() ? "yes" : "no");           
        }
    }
}

A full featured sample can be downloaded here. Please be aware that this
sample is using iTextsharp that is licensed under the Affero General Public License.

To actually use this small console program in your Web Site Management Server, build the console
app and copy the .exe file into your %RDCMS%\MediaCatalog folder. Please make a backup copy of
the old before.

Please also note that WSM is only executing the process for 5 seconds. If the process needs more
time, e.g. with large documents, the process will be killed and no metadata is read. There is no
configuration possibility to change this threshold value.

The sample is provided without any warranty. Please try it on your own risk.

Using WCF to create an RQL client for Web Site Management

A few days ago, I posted about executing RQLs in version 11. I clarified that the currently shown
way of using some .NET objects instead of the old COM+ components, is just a temporary way till
the RDCMSCMSXmlServer Web Service has been implemented with the means of WCF.
I'll now show you in detail how to create a WCF based RQL client that can already be used from
CMS version 7.5 on, I guess. At least WSM 10.1 will work fine with this implementation.



All the steps can be done in around 15 minutes.
As a short outline, the steps are:
1. Create a new console application project in Visual Studio
2. Add a service reference to http://localhost/cms/webservice/RDCMSXMLServer.wsdl
3. A new XMLServerSoapPortClient is generated
4. Use the generated client to connect to WSM
5. That's it
Easy? Yepp, there's not much code you'll have to write manually for this example. As always, in
a real project, you'll have to do some additional work, e.g. creating a separate assembly containing
the client and additional convenience methods for sending certain actions. Probably making the
assembly COMVisible if it has to be called from your old legacy ASP code.