Transactional behaviors in Sharepoint

I know some sharepoint developers would say “Are you kidding me ?” when read the title of the post, yes I know sharepoint is not recommended to implement transactional behaviors, this is for particular situations for example Imagine an situation where an action in your form implies to execute three operation at business level, for example image that with a click in a submit button you should to insert a item in a list, update an existing item in another list and finally load a document to document library. Now imagine that you develop this functionality and everything is nice until your QA team makes some nice tests and discover that some times that code is breaking in the last operation, I mean loading the document in the document library, so you notice that the transaction is incomplete and this makes your software unstable. If we were working with a Database get a solution for this issue would be very easy using transactions, rollbacks and commit, but Sharepoint does not support the use of transactions natively.

So Im going to describe the way that our develop team is avoiding this kind of issues. Basically we are emulating transactions using the most simple design pattern we know, the  command pattern. Steps below show how we implement transactions in Sharepoint

Creating a base command clase

The command pattern is one of the most simplest patterns and its based in an interface and our approach with this pattern is to separate all the operations of a transaction in classes that should implement the base interface, using this approach we will have command classes  that are responsible for execute a command and also undo the command if some exception is thrown. Figure 1 show the implementation of the base command class.

Fig. 1

As you can see this interface only has two methods you can add more if you need, for example some times is necessary a validation after execute the command so you can add a method called Validate() to validate something before execute your command, next step is create all the commands, for this example Im going to base my code in the description of the problem at the begin of the post, so Im going to implement the two first commands creation of an item in a list and update an existing list, figure 1 and 2 show how this classes would look.

Commands Implementation

Fig. 2

Fig. 3

Transaction Implementation

The last class is the transaction, this class basically is a command too, the difference with the others is that this command will be responsible for the execution and undo of the commands if is necessary of the other two commands.

Fig. 4

Fig 5.

Fig 4 and 5 is the implementation of the transaction. As you can see the execute method is responsible for the execution of the other commands and after the execution of each command the executed command is stored in an stack this is because if something is wrong and an exception is thrown the undo method of the transaction needs to know what commands have been executed. I really like this approach because is simple and in addition of the undo possibility for a transaction, this approach help to organize the code and makes the code legible and more maintainable, I hope this would help in your SharePoint projects, I will be appreciate any feedback about this approach or another approaches to make SharePoint work with transactions in SharePoint.

Advertisements

3 thoughts on “Transactional behaviors in Sharepoint

  1. Hi Diego,

    This approach very interesting. I have two questions:
    + I wonder how to achieve Undo part of delete command. Sometime you need to delete list item that cascade delete many other items. And ID will be changed.
    + Do you have any ideal to generalize this approach?

    • Hi sorry for the delay for the undo you only need to add a undo method about the id issue I did not find any way in order to avoid this issue maybe if you store a backup of the deleted item in your action class could be possible to avoid the lossing id, this approach should be use very carefully catching the possible exceptions in the appropiate way in the undo methods ir not you could have a half o your transaction rollbacked and the other commited.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s