CoreSync - Sync Sitecore Content - Item Web API - Create Version - Part -3

This is third post in series of ‘CoreSync - Sync Sitecore Content’. Today we will walk through adding new processor 'Create Version', let's go and deep dive what we have done to have this feature.

Figure -1.1

As you can see we have introduced new config section entries which has three new processor.
To handle these new processor we need two important things first is ability to identify the version request then launch relevant pipeline. Second is right appropriate classes(Processors) which constitute that pipeline.

Figure -1.2

As you can see in Figure 1.2 Resolve action is the class which handles our create version requests and highlighted classes do the rest of work. The sequence is important in processor listing In Figure 1.1 which tells Sitecore to run those classes in same manner. In Post 2 Figure 1.5 we have shown that we have introduced a new verb 'ver' and handled the same by calling a new method 'ExecuteCreateVersionRequest(requestArgs)'.
In this method I need to identify first if the request is for Media Item, if it is then I need to handle it differently. So, I handled the create version request for Media Item in same 'CustomResolveAction' class. People may ask why you have not created a separate processor for it ? But I just followed the way it was handled for create media request by Sitecore itself, So I just followed the suit.
In 'CreateMediaVersionItems' function I just need to few formality first and then check if web request has the file, if it does then add the version to the media item and then upload the media file to new version of media item, it also update media item properties like height, width, alternate text if provided in the post back Form values.

While you go through my source code you will notice most of the time I have written re-usable functions in type 'Mindtree.ItemWebApi.Pipelines.Common.Functions'. Apart from that in order to improve performance of my code I have used .NET based Memory Cache, which have default hold up time of 30 minutes which can be configured using the config. I am sure The Caching and this Functions class you folks will like as it has day to day many usefull utility functions like resolving database, item, language, version etc., It also has the number of History engine functions which we have used in our CoreSync Interfaces. The common namespace also had other utility classes which may be useful to you folks also.

But what if the request if for non-media item, I mean general sitecore item. For that we need to call our new pipeline, but before doing that I need to make sure that 'CreateVersionArgs' is fully loaded with values like scope variable which actually hold the item which need to be versioned. Following is the magic line which call our new pipeline and initiate the processor :

CorePipeline.Run("itemWebApiCreateVersion", createVersionArgs);

Figure -1.3

To create appropriate processor as listed in the config I need to create two base classes which will be useful while create main processor class. First is 'CreateVersionArgs' class which has been inherited 'OperationArgs' class, this helps pass the arguments to the pipeline. I didn't need to add much to this class.

Figure -1.4

Second class is 'CreateVersionProcessor' which is inherited from 'OperationProcessor' taking parameter of type 'CreateVersionArgs' class.


The real job of creating version happened in newly created type 'Mindtree.ItemWebApi.Pipelines.Version.Create.Create' where is fetch the item from the scope and simply called an Sitecore API to add version and then pass it further to update values incase the request has updated fields.

Figure -1.5

To update values the next processor is TryUpdate which will try to update but in turn it just call the 'itemWebApiUpdate' using following code.
CorePipeline.Run("itemWebApiUpdate", updateArgs);

Figure -1.6

So now if you put all this in context then process of creating version is simple.
a. Filter version request uniquely by having a separate request verb.
b. Call your own method which can decide between media request and normal item request.
c. For media request expected behaviour should be same which is to create a numbered version and attach the new media file with its properties.
d. If not media request then pass to your new shiny pipeline which will create the numbered version.
e. Update the newly created version if it has new field values to update.
f. Set the result finally so that requester can be notified with result of the request.

No doubt that I am able to right all this classes by looking deep into Sitecore.ItemWebApi library.
In next post will be explaining another new Pipeline 'itemWebApiCreateAdvance' which has the capability to create Item while retaining GUID, this is most important addition to ItemWebApi, so stay tune for same.