Thursday, January 27, 2011

Separating your code from Ektrons’

Similar to my last post, this post is about creating a DLL which will access the Ektron repository. However, this time the DLL will be included as a reference in the website. This allows you to separate out your logic code from the presentation layer.

(Initially, I thought I would be restricted to using the Webservice API. However, as the DLL will be run within the context of the Ektron site, you are able to use the framework and controls).

 

  1. Add a new code project project to your Ektron site solution
  2. Add the following references to the code, by browsing to /Path/To/Site/bin-
    1. Ektron.Cms.Common
    2. Ektron.Cms.Framework
    3. Ektron.Cms.ObjectFactory
  3. Add your new project as a reference to the Ektron website.

 

The advantages of this are-

  • Re-usability – you can create a helper function DLL of common actions, which can be dropped into new projects
  • Testability – You can write and run tests directly against your DLL using nUnit Test Runner or similar. Ektron objects won’t be available, but can be mocked.
  • Reduces JIT-compilation load, though this can be mitigated by pre-compilation. However, this in turn is trumped by the fact that the Ektron workarea does not currently compile (high hopes are held for version 8.5)

 

In the end, I returned to putting all my logic code back in App_Code. The main reason was the tight deadline which was not allowing me the time to get past a couple of problems, namely-

  • Permissions issue on Logic.DLL. Visual Studio was unable to automatically update the DLL in the website, and i was forced to manually delete it from the bin folder.
  • Dev process is slower as Logic.DLL needs to be recompiled with every change.
  • Our standard helper functions have not yet been moved to a DLL, but have been used and tested in App_Code.

Monday, January 24, 2011

Accessing Ektron from a DLL or console app

As part of trying to use Webforms.MVP with Ektron, I have created a DLL that contains my business logic, which is referenced by the Ektron site. However, this DLL needs to access the Ektron webservice, in order to get/update content and members.

Note: wsdl and csc are part of the .Net SDK. You will need to have this installed. Once installed, you can access them via the SDK Cmd Shell, or, if your path is correctly configured, via cmd.exe.

 

  1. Create a proxy object for the web service
    1. Run .Net tool wsdl.exe against your webservice address, e.g. http://localhost:/Workarea/webservices/ContentWS.asmx
    2. Compile into DLL by running “csc /t:library ContentWS.cs”
  2. Add the DLL as a reference to your DLL or console app
    1. Copy the DLL to a Lib folder in your project
    2. Right click “Add reference” and browse to your created proxy DLL.
  3. Add System.Web.Services as a reference to your DLL or console app
  4. Call the proxy DLL from the code

      ContentWS cApi = new ContentWS();
      ShowContentResult response = cApi.GetContentBlock(contentId);
       

 

That’s enough if your DLL or console app needs access. However, if, like me, you wish to have your Ektron site reference your DLL (in my case, for testability via Webforms.MVP) then you get a DLL conflict. The next post will be on how to overcome this.

 

References-

Great little tutorial on access web services from a console

MSDN article on Wsdl.exe

Sunday, January 16, 2011

Improving Ektron eSync

For a feature with so much upside as eSync, why do I always dread having to use it?

 

I mean, who wouldn’t want an easy way to push your development changes seamlessly into production? Or easily recreate the client’s bug report by pulling down all the production content?

In order of priority, I think the following would make eSync better-

  • Better error messages – The errors messages are arcane. There seem to be a couple of common causes of problems - license, certificates, web service path - yet there are not standard errors for these causes.
  • Better tooling/support – The current tooling is sufficient, but could be much, much better. The tools should automate as much of setup process as possible, and do some simple checks of common problems.
  • Support for or integration with source control systemsI’ve learnt the hard way that eSync and Subversion don’t play nicely together. My current method is to keep the two apart as much as possible. There is a lack of documentation on best practises with eSync and source control.
  • More fine-grained control – The main problem we get is with the users being synchronised. It would be able to bring across the content but keep the users. Or just eSync certain folders (there are filters, which, as mentioned above, I’ve never had much luck with).
  • More than just master/slave – eSync relationships are limited to two parties, and anything complicated must be modelled as a series of two party relationships. Support for many slaves to one master would be nice for a multi-developer, single UAT server environment.
  • Support for continuous integration – This is partly mitigated by the ability to set a schedule. It would still be nice to be able to kick off an eSync from the command line.
  • Ability to change port used – I’m a little concerned about this, if a vulnerability is found, then attackers know exactly which port to knock on.

Lastly, no eSync blog post is complete without a link to Martin’s eSync Trouble Shooting Guide. Whenever I have to set up eSync, this page gets opened up before I even start, and takes away just a little of that aforementioned dread.

 

(the eSync that prompted this post went rather painlessly, with only 1 (firewall-related) error)