Additional information about upgrading to the TMCore EPiServer 2.0 Module
A number of projects are using a Release Candidate or Beta release of the EPiServer Module 2.0. With the final release now public here are a few additional pieces of information:
Which files are added/deleted?
There have been additions to the documentation and the AJAX topic editing client. However, deploying over the top of an existing installation will work correctly; the obsolete files will simply not be used.
Is it necessary to run the EpiServerModule.sql when I am updating?
Yes, we've updated the SQL Stored Procedures. However, this does not change any of the data in the database.
Which web.config settings should be added/removed?
No settings must be removed or changed, however you should review your existing web.config configuration with the installation guide to ensure correct operation.
Adding a new Dynamic Property 'topicidentity' to the EPiServer Project. Should there be a default value?
No value is required as default. It will get filled in automatically on each page by the EPiServer Module, either during the page create post-processing, or by the consistency checker.
The first time I run the Consistency Checker I get a lot problems reported
page name has no GUID. Will create one: urn:guid:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx page name has unwanted subject identifier http://www.networkedplanet.com/2005/01/episerver/np-gen-psi/pageid page name requires new subject identifier: urn:guid:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
In TEM 2.0 we require the definition a new dynamic property to EPiServer which is a GUID, or Globally Unique IDentifier. The GUID is then used, in combination with a prefix urn:guid:, to construct the subject identifier of the topic representing the page.
The result of this is that the GUID property of the page is unchanged throughout the life of the page, and is preserved through export operations. This therefore allows EPiServer administrators to export page data, export the XTM from TMCore and then import in to new systems and the system will work as expected.
The EPiServer page ID can still be derived from the a topic via an occurrence value on the topic, typed by the Page ID occurrence type topic, by default this a topic with the subject identifier http://www.networkedplanet.com/2005/01/episerver/pageid.
The old subject identifier is no longer required and will be removed by the consistency checker.
EPiServerModule 2.0 Changes – GUID vs. Page ID
In the latest version of the Networked Planet TMCore EPiServer Module (henceforth TEM); we moved away from the model of using EPiServer page IDs to instead use a dynamically generated GUID.
EPiServer Module 1.x
In TEM 1.x each topic that represented in a page in EPiServer would have a subject identifier which was composed of a prefix (typically http://www.networkedplanet.com/2005/01/episerver/np-gen-psi/ followed by the integer ID of the page that this topic represented. The advantages of this system were:
- The ID was persistent in EPiServer, so there were no concerns with the ID changing within an EPiServer installation.
- The subject identifier of the topic could be easily derived from the page (just add the prefix), and vice versa.
Unfortunately this system also carried a penalty. If page data was exported from EPiServer and then migrated to a new EPiServer installation, a new ID would be assigned, usually different from the old id. This means that the link between the page and the topic was broken. In short, moving page data around between servers was very difficult and we felt we had to address this in the 2.0 release of the TEM.
EPiServer Module 2.0
In TEM 2.0 we require the definition a new dynamic property to EPiServer which is a GUID, or Globally Unique IDentifier. The GUID is then used, in combination with a prefix urn:guid:, to construct the subject identifier of the topic representing the page.
The result of this is that the GUID property of the page is unchanged throughout the life of the page, and is preserved through export operations. This therefore allows EPiServer administrators to export page data, export the XTM from TMCore and then import in to new systems and the system will work as expected.
The EPiServer page ID can still be derived from the a topic via an occurrence value on the topic, typed by the Page ID occurrence type topic, by default this a topic with the subject identifier http://www.networkedplanet.com/2005/01/episerver/pageid.
Pitfalls
Of course, nothing ever comes for free, there are few ill-considered things you can do to EPiServer which will cause problems with this new system.
The most serious of these is to delete the dynamic property from EPiServer. This causes all GUID values of pages to be destroyed. These values are unfortunately unrecoverable.
Manually setting the GUID is also unwise, not only do you risk setting the GUID to a value which will potentially clash with another page ID, but also you will put the page GUID out of sync with the topic GUID. This means that you must either:
- Manually set the GUID subject identifier on the topic to match the changed page GUID; or
- Run the TEM consistency checker which will create a new topic for the page, based on the new GUID. However, this will leave the old topic hanging around in the system, along with all its associations which may cause confusion.
TMCore Configuration and Deployment on Windows 2003 Server for EPiServer Projects
Many projects are developing solutions on XP and then deploying them onto Windows 2003 Server. To minimise the configuration issues here are a few suggestions:
On Windows 2003:
Install the TMCore Services (TMEditor, TMService and NPCLService) into their own website (perhaps called TMCore) with its own AppPool. Just copying the DefaultAppPool works fine. This has the benefit of keeping TMCore out of the EPiServer project space (i.e. no fiddling with httpmodule exclusions etc, issues with different .NET versions).
Install the EPiServer Project into its own website and configure as normal. The only property in the EPiServerModule that needs to be changed is the one referencing the TMWS endpoint. Obviously the TMCore website will be running on a different port to the EPiServer site.
On Windows XP:
The real pain here is that IIS can only host one website! And even worse is that while Microsoft have achieved binary compatibility between .NET 1.1 and .NET 2.0 they have failed to ensure XML compatibility in the web.config files! Thus if you are using the ASP.NET 1.1 TMCore services it is not possible to deploy them under an EPiServer install using ASP.NET 2.0.
Some options:
1. Use the TMCore ASP.NET 2.0 Web Services for TMEditor, TMWS and NPCL, and install them under the EPiServer virtual website.
2. Install a virtual machine (either MS or VMWare) and on this install TMCore. The benefit of this is that this machine can then run happily and support multiple projects.
3. Not sure EPiServer recommend this any more, but install EPiServer in a virtual directory and TMCore services in virtual directories all in the same website. The advantage of this is that it removes the need for fiddling with the httpmodule exclusions AND means that TMCore can support multiple projects more cleanly.
Hope this helps.
