NetworkedPlanet Blog Insights into developing with NetworkedPlanet products

TMCore EPiServer Module Update

Thanks to excellent feedback from our partners and our continued QA processes we are pleased to announce the update of the TMCore EPiServer Module to version 2.0.1.0

The following bugs have been fixed

1. Publishing a page caused all associations to be published, even if the page at the other end of the association was unpublished. Behaviour is changed to only publish associations where both ends of the association are published pages (or a topic without a page).
2. Javascript error reported if calling up topic details for a topic which did not represent an EPiServer page in the EPiServer Edit mode. This has been fixed.
3. Copying a page in EPiServer did not cause a new GUID to be assigned or a new topic to be created. This has been fixed.

Please contact Networked Planet to obtain an updated version of the module.

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:

1. Manually set the GUID subject identifier on the topic to match the changed page GUID; or
2. 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.