Microsoft Office 2007 Groove can produce events that represent changes to the data within tools in Groove workspaces (or for a number of other reasons). This blog explores putting Groove events, of any kind, into a database table. This is of interest because from there, you can process the events "at leisure", and you can have a full history of event data to reference. Putting event data into a database table separates a solution into two more easily solved pieces – the piece that handles processing events from Groove, and the piece that processes data from a database, transforms it, and puts it somewhere else.

A typical use of such a capability is shown in Figure 1. This shows a Groove Data Bridge (GDB) server participating in a Groove workspace that contains a Discussion Tool. The GDB passes events representing CRUD operations on Discussion entries to a "Groove Event Service" to put into an Events Database Table. A "SharePoint Publisher" piece then removes event data from the Events Table and using a Discussion Entries Table, publishes the data to a SharePoint server where it becomes accessible to SharePoint clients.

Figure 1 - Groove to SharePoint Discussion List Publisher

The key thought in this blog is that a single table can contain event data from any class and type of Groove event, for any and all sources of events in Groove. A suitable table format is shown in Figure 2. What I want to discuss is how to transform events received from Groove to insert them into this table format, and how to transform data from this table back into a format that can be easily processed.

Figure 2 - Groove Events Table

The Groove Events table has the following fields (with reference to Figure 2):

• SequenceNumber (primary key) – an auto-incrementing 64 bit number
• EventTime – the time that the event was recorded in the database
• EventSequence – the sequence number for events from this source
• SubscriptionName – the invariant name given the subscription that produced the event
• SubscriptionID – the Groove subscription ID, which can change over time
• EventClass – defines the generic kind of event generator – Calendar, Contact, ContactDirectory, Files, Forms, Members, Messages, Space, and Tool.
• EventType – Defines the specific event – e.g., Add, Delete, Update, …
• EventSource – Defines the specific event source – a tool or a space or an account
• EventDataType – unused, remnant from an earlier version of the code.
• EventData – The actual event data for the event

Using the Groove Web Services Helpers (http://www.codeplex.com/GWSV12Helpers), events are delivered to IGrooveWebServicesEventCallback member ProcessEvent, with the method signature:

public void ProcessEvent(GrooveWebServicesV12Helpers.GrooveEventsWebService.Event i_Event)

The Event class is declared in the helpers as:

Clearly, all of the members of this class easily go into the Events table, with the exception of EventData. Here is the serialization of EventData to make it available to insert in the table:

Given the information above, it is easy enough to insert an event into the table shown. Now, how do you get the data, specifically the EventData, out of the table? Here's the code that it takes to "reconstitute" EventData:

Calling Deserialize<t>(Stream i_Stream) with the appropriate type for t returns the original event data. The EventType field indicates the type of the EventData – so you'll have to switch on EventType to process the event, in code like this:

This technique is particularly valuable if you're working through some issues with processing events – since you've got a record of events at hand that you can peruse.

Now, just to mention the downside of processing events – Groove events are asynchronous, "after" events. Given the nature of Groove, you could be processing an event a long time after the data change that the event represents actually occurred. Furthermore, events do not convey "bulk" data – Forms tool events don't carry any attachments for the record; Files too events don't carry the file data. These two considerations (the possibly long delay and the "remoteness" of the bulk data) mean that you must be careful to recognize that the underlying data may no longer exist. Given an event sequence like Add, Delete, by the time you process the Add event, the action that caused the Delete event has likely already deleted what the Add added. So you can't rely on data existing. Again, though, having the event data persisted in a database can make it easier to figure out what's going on.