Today I’d just like to write a few lines about the changes regarding the RQL programming in version 11 of the Management Server (scheduled for the end of the year.) The change I’ll describe might sound like a totally different approach (and that is possible when looking behind the scenes) but the impact for you as someone who creates RQL based plugins is very small.
Ok, the change: In the Managment Server Version 11 (Swan version) Microsofts COM components for the RQL communication are not longer available/supported. Instead of the COM communication the Management Server will use the Windows Communication Foundation that is part of the .Net framework.
- COM components were introduced by Microsoft in the year 1993 (18! years ago) and worked well for the Management Server. But nowadays it seemed to be much better to rely on a state-of-the-art technology.
- Microsofts support for COM components ended years ago and we would like to use a fully supported technology.
What does that mean for your RQL based plugins?
- If you use the RQL webservices for the communication within your plugins, then the change does not have any impact.
- If you use the COM objects, then you’ll have to implement small changes.
In order to provide a good overview I’ll provide a function that is probably used by many developers and in a second step I’ll provide a sample RQL plugin that is intended to run on a Management Server version 11.
What we see here is a function that…
- receives a string (RQL command)
- creates an object (RQL object)
- executes the RQL command
- and returns an XML structure (server response)
Version 10 and earlier: <% function sendXML (XMLString) set objData = server.CreateObject("RDCMSASP.RdPageData") objData.XMLServerClassname="RDCMSServer.XmlServer" sendXML = objData.ServerExecuteXML(XMLString, sErrors) end function %> Version 11: <% function sendXML (XMLString) set objData = Server.CreateObject("OTWSMS.AspLayer.PageData") sendXML = objData.ServerExecuteXml(XMLString, sErrors) end function %>
The changes to this function are obviously very small:
- Instead of RDCMSASP.RdPageData we now use OTWSMS.AspLayer.PageData to create the RQL object.
- the line objData.XMLServerClassname=”RDCMSServer.XmlServer” is not longer used in this function.
What do I have to do with a plugin that has been developed before version 11 that shall run on a version 11 Management Server?
- Use the Search&Replace function of your development environment: Search for “RDCMSASP.RdPageData” and replace it with “OTWSMS.AspLayer.PageData“
- Use the Search&Replace function of your development environment: Search for “objData.XMLServerClassname=”RDCMSServer.XmlServer” and replace it with “”.
Hint: If your obejcts do have other names….then of course you have to use different search strings 😉
As most people (including me) like to have a runing script instead of just a code snippet, this sample plugin might be helpful:
<% ' Create RQL Server Object And XML Document Object set XMLDom = Server.CreateObject("OTWSMS.Core.RdObject") set RQLObject = Server.CreateObject("OTWSMS.AspLayer.PageData") ' Define Variables Dim RQLStatement ' Contains the RQL command Dim RQLRequest ' Contains the result of the RQL Server Dim ServerError ' Contains an error message of the RQL Server Dim Projects ' Contains the number of the projects LoginGUID = session("LoginGUID") SessionKey = session("SessionKey") ' Create RQL Statement (Load All Projects) RQLStatement= "<IODATA loginguid=""" + LoginGUID + """>" + _ "<ADMINISTRATION>" + _ "<PROJECTS action=""list"" />" + _ "</ADMINISTRATION>" + _ "</IODATA>" ' Transfer RQL Statement To RQL Server Object RQLRequest = RQLObject.ServerExecuteXml(RQLStatement, ServerError) ' Show Appearing Errors if ServerError > "" then Response.write "An error has occured:</BR></BR>"+ServerError ' Load Result Into XML DOM Call XMLDom.LoadXML (CStr(RQLRequest)) ' Execute XML Query For Projects In XML DOM Set XMLDom = XMLDom.ObjectByQuery ("//PROJECTS") ' List Every Project By Name for Projects=1 to XMLDom.objects.count Response.write XMLDom.objects(Projects)("name")+"</BR>" next ' Kill RQL Server Object Set RQLObject=Nothing %>
Hint: If you have a closer look at the script, you’ll notice that there is another change that I forgot to mention. If you don’t use the Microsoft XML-DOM object but the one that is provided by the Management Server you’ll also have to change this line: set XMLDom = Server.CreateObject(“OTWSMS.Core.RdObject”). The same line in version looks like this: set XmlDom = Server.CreateObject(“RDCMSAspObj.RdObject”).
So another search & replace task would look like this: Search for “RDCMSAspObj.RdObject” and replace it with “OTWSMS.Core.RdObject”
Ok, so these were the changes regarding RQL communication. A description of the changes as well as the sample RQL plugin (above) are planned to be part of an updated RQL documentation.
To answer a question that might possibly occour: No, I’m not aware of any other changes regarding RQL. 😉
Have fun with RQL!
12 thoughts on “RQL development with Open Text Management Server 11”
Nice post. I wish I could have a secret peak at it too before it is released!
Sounds like the eDocs DM Integration will be dropped? otherwise would have to be rewritten to use WCF?
Sounds like 😉 but in fact we provide the eDcos integration in version 11 and version 12 and do not have any plans so far to stop providing this integration.
so will this incur a drop in performance using WCF rather than COM?
WCF is not the same as the normal RQL webservices, so I think WCF communication will not have any impact on webservice communication. But the question is good and I’ve exactly asked this to our R&D department!
Manual, thanks for the great info.
Kim, out of curiosity myself also as, I used ILSpy and found:
RQL Communication order
User -> RQL Web Service (Remoting) -> RQL Windows Service -> COM .NET Interop -> COM (VB unmanaged code).
WCF will replace the COM (VB unmanaged code).
So the new code Manual provided will still be the most performant of the entire RQL communication stack.
nice one.. looking forward to seeing this getting released!
A point of clarity… in your example you use:
Is this not COM? If I’m reading that right it looks like your WCF libraries have COM wrappers – which means now you pay the performance hit of all of COM, WCF and .NET jitting. I can’t imagine how this can be faster than straight COM compiled to machine code.
Let’s hope the installer runs ngen on all your assemblies!
the main focus of my blog post was to make sure, what people have to do in order to get their plugins run in version 11 of the Management Server. Within this blog article, Dennis describes the technical background much better than I could do this. Maybe this helps you more from a developers point of view.