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.

CoreSync - Sync Sitecore Content - Item Web API - Part -2

This is second post in series of ‘CoreSync - Sync Sitecore Content’. Today we will walk through the ‘Item Web API’ and figure out what we need to customize and what to introduce new in order to extend this web service.
Let’s state the clear objectives what we do extend in Sitecore Item Web API service, answers are as follows:

• Add a processor which should allow to create the Item numbered or language versions.
• Add a processor which should allow to create the new item while specifying the GUID for the new item.

Few Clarification, Here creation should work for any item means even Media items. Another important clarification about second point is it should not replicate the existing default Create processor but introduce new one so that item can be created still in old way wherever required.

Now as my objectives are clear, I need to first understand the existing code culture, details and flow. So that I can introduce the new processor on similar lines. To start doing it, service config file and tool ‘IL Spy’ come very handy. ‘Item Web API’ introduce couple of processor in ‘httpRequestBegin’ pipelines which make sure that how the upcoming request will be routed to further appropriate pipeline processors. So as shown in Figure 1.1, it is my first clue. I need to introduce new processor and need to evolve the way context properties resolves.

Figure -1.1

As you can see in Figure 1.1 highlighted in red rectangle, I commented out ‘Sitecore.ItemWebApi.Pipelines.HttpRequest.LaunchRequest, Sitecore.ItemWebApi’ and replaced it with my own processor ‘Custom.ItemWebAPI.Pipelines.HttpRequest.LaunchRequest, Custom.ItemWebAPI’. Figure 1.2 which tells what I replaced in new class.

Figure -1.2

During the course of writing this customization I realize I need a way where I can have better way to resolve the routine context properties so for that I have created a public static class named ‘Functions’ in namespace ‘Custom.ItemWebAPI.Pipelines.Common’ which provide me the functions like GetItem(), GetLanguage() etc., These same functions I have used in the above class.

What is in this class?

• You can find the code shared in GitHub. But for overview I write couple of overrides to GetItem() functions where I can get the item based on various parameters and you can call those as per your convenience.

But yet I didn’t find the way to resolve my new processor, so as stated in ‘LaunchRequest’ class I need to look into ‘itemWebApiRequest’ pipeline. Where I find my next clue, as you can see in below snap there are three processor which I replaced with my custom processor, the most important processor(highlighted in yellow rectangle in Figure 1.3) is ‘Custom.ItemWebAPI.Pipelines.Request.CustomResolveAction’ because here is the magic where I can introduce new processor (here it is called action like create, update etc.,).

Figure - 1.3

Rest of the processor I need to replace as I need to find the custom way to resolve items and pass necessary parameters to new processors. In ‘CustomResolveAction’ class I introduced couple of new functions which will suit my needs and also introduced new request verb for version processor (action). Also I need to have full media capabilities and enhanced the existing media update capability. Figure 1.4 which reflects the changes in comparison with old class structure.

Figure 1.4

Figure 1.5 shows how we had introduced new verb. We also need to distinguish new type of create facility where GUID can be retained and still need to persist existing create facility.

Figure - 1.5

Will explain in detail what I have written in above two new processor in detail and there concepts. Till then Happy New year & Happy Coding to all of my friends.