Skip to main content

Posts

Showing posts with the label Event System

Yet Another Event System - Revisited

As a followup of my previous post Yet Another Event System? , it is time for a follow up on the code and examples. The code has been added to Google Code and it's available for free at  YAES source code . You can simply download the entire solution and start coding. If you're only interested in the main functionality class, go directly to ConfigurationManager.cs . Installation This is a normal Event System installation process: Copy the compiled Event System DLL to a location of your choosing Reference the DLL from file [Tridion_Home] \conf\Tridion.ContentManager.config , in section configuration / extensions / add , attribute assemblyFileName Copy a .config file to the same directory where your Event System DLL is located, and name it the same as your DLL, but with extension .config Restart Tridion processes. For knowing exactly which process to restart, have a look at my earlier post  Debugging a Tridion 2011 Event System Configuration The .config file al...

Yet Another Event System?

In my 9 years of consulting and implementing Tridion, I never wrote the same code twice... Kudos, Tridion -- you awesome beast! But every now and then I find myself needing the same low level handlers and I end up copy pasting them from somewhere. For example, with Event Systems I always prefer putting the configuration in a System Component in Tridion. I put it maybe in the current Publication metadata or current Folder/Structure Group meta. I always end up writing the same code to handle the reading of this Component, checking for modifications, caching it for a few minutes, then making the configuration values available inside some object model. Recently, this annoyed me enough to write an Event System base-project that takes care of this once and for all... Enter the Yet Another Event System framework. Functional requirements: Rapid development -- provide a base ready to be used in actual Event System development System Component is in free format -- provide a consistent A...

Event System to Create Mapped Structure Groups for Binary Publish

As a continuation of last week's Publish Binaries to Mapped Structure Group , this week's TBB is in fact the Event System part of that solution. Make sure you do check out the previous post first, which explains why and what this Event System does. To reiterate, the Event System intercepts a Multimedia Component save, take its Folder path and create a 1-to-1 mapping of Structure Groups. The original code was written, again, by my colleague Eric Huiza : [ TcmExtension ( "MyEvents" )] public class EventsManager  : TcmExtension {     private Configuration configuration;     private readonly Regex SAFE_DIRNAME_REGEX = new Regex ( @"[\W_]+" );     public EventsManager() {         ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap ();         fileMap.ExeConfigFilename = Path .GetDirectoryName( Assembly .GetExecutingAssembly().Loc...

Timeout Setting in Event System Threads

While debugging an Event System in SDL Tridion 2011 SP1, I noticed that every so often my debug session ends unexpectedly with an exception that thread was aborted. Obviously, the thread is taking too long so the event system engine is killing it in order to free up some resources. The problem for me was that it interrupted my debug session. The life span of the thread is quite low - 30 seconds by default. Thanks to Nuno  to point out where the configuration of this thread life span is: in the [Tridion_Home]\config\Tridion.ContentManager.config , in node eventSystem : <eventSystem maxThreadCount="5" threadTimeout ="30" threadNamePrefix="EventSystem" /> Change the threadTimeout to a bigger value (I set mine to 300 seconds). This will give you enough time to do sufficient debugging. Remember to shutdown the Tridion Content Manager COM+ application and restart SDL Tridion services that might be using the Event System. For for information abou...

Create Embedded Fields Programmatically

During on the my Event Systems, I came across the requirement of creating (and populating) new Embedded Schema fields. To do so, I still used the ItemFields collection, which has a constructor accepting a Schema parameter. This is the one to use, but the counter-intuitive part was to obtain the Embedded Schema. I ended up getting it from the field definition of the 'outer' Schema field. Finally notice that when the Component needs to be saved, the ItemFields collection needs first be saved into the Component's content. ItemFields fields = new ItemFields (component.Content, component.Schema); EmbeddedSchemaField linksField = fields[ "Links" ] as EmbeddedSchemaField ; EmbeddedSchemaFieldDefinition linksFieldDefinition = linksField.Definition as EmbeddedSchemaFieldDefinition ; ItemFields newItemField = new ItemFields (linksFieldDefinition.EmbeddedSchema); (( ComponentLinkField )newItemField[ "Component" ]).Value = anotherComponent; ...

Debugging a Tridion 2011 Event System

OK, so you wrote your Tridion Event System. Now it's time to debug it. I know this is a hypothetical situtation -- your code never needs any kind of debugging ;) but indulge me... Recently, Alvin Reyes ( @nivlong ) blogged about being difficult to know how exactly to debug a Tridion Event System. More exactly, the question was " What process do I attach to for debugging even system code? ". Unfortunately, there is no simple or generic answer for it. Different events are fired by different Tridion CM modules. These modules run as different programs (or services) or run inside other programs (e.g. IIS). This means that you will need to monitor (or debug) different processes, based on which events your code handles. So the usual suspects are: dllhost.exe (or dllhost3g.exe ) - running as the MTSUser is the SDL Tridion Content Manager COM+ application and it fires events on generic TOM objects (e.g. events based on Tridion.ContentManager.Extensibility.Events.CrudEven...

Capturing A User's Last Login Date Into The CME

Requirement: Indentify a user's last login date into the CME and store it for the purpose of later creating a report with different users and their last login date. This post only covers the storing of a last login and not the report itself. There are several ways of intercepting the when a user logs in: HTTP Module Global.asax Event System I tried the Global.asax and event system approaches with more or less success. I did not try the HTTP Module, which I believe would work the best. For storing the last login date, I used Application Data on the User object. 1. HTTP Module The idea is to write a HTTP Module that intercepts each request made to the CME. The module would check if the session has just been initiated, and if so, it would store the current DateTime in the current User object as AppData. One could get the User object by using the Core Service. 2. Global.asax First of all, this approach doesn't really work :-( The idea is to intercept the session...