I had the privilege of taking part in putting together a leg of a POC that included the task of parsing a Json data set representing a group of users and doing two things with them. The first, adding them as Sitecore items in what could represent a profile page. The second, creating Sitecore user accounts based on that same json formatted data set.

Fellow Velirian, Nick Dorrough is presenting a series of posts on this POC. Be sure to check out his current post and the soon to be upcoming posts.

Along with the current DXF documentation being a resource, Nick's posts will dive into the details of the POC and working with DXF. So I certainly won’t repeat that information here. What I will focus on is the ability to add functionality of parsing Json and working with Sitecore not only in content creation, but to work in other Sitecore aspects, such as adding Sitecore User accounts.

In initial investigations, it was really evident that my work was not going to be done for me. No Json provider was noticed nor within the Sitecore provider a way of creating users. Curses!

Actually – I kind of thought that might be the case – so into the sandbox to play…..

First I looked into the File System Reader pipeline step provided in the documentation example (http://integrationsdn.sitecore.net/DataExchangeFramework/v1.1/implementing-a-provider/implement-pipeline-step/implement-pipeline-step-processor.html). The process works on the concept of file location and parsing by delimiter. I knew getting the json parser to work was likely more important, so opted to use a local json file. I could always change the way the json was delivered after the proof of concept and likely would need to, based on using the patterns for future solution implementations. I also needed to generate some data representing user accounts. I pulled user data from our GitHub company account and noticed the results needed a little data scrubbing, so at that point there was no turning back from using a local file.

So here is the result of the code for the new converter and pipeline step.

The converter I did was in fact no different than the one in the File System reader example. Except for the template Guid.

For the processor, I noticed the file system example loading “record” elements in a pipeline plugin that contained on object of IterableDataSettings. I knew that likely downstream I would create more work for myself if I changed this approach so, doings as the locals do, I deserialized the json into a List of POCO elements.

//
//read data from file
IEnumerable<GitMemberJsonModel> lines = LoadJson(settings);
//
//add the data that was read from the file to a plugin
var dataSettings = new IterableDataSettings(lines);

So as you can see it is similar to the example. The major difference between the two is obviously the Read Json User File pipeline step.

So when the pipeline batch is executed – the json file is read, json “parsed”, field values are mapped, and like magic we have our Sitecore items.

1st goal of POC completed. No sweat. Also no rest for the wicked, I have another goal to accomplish…

So now instead of writing to Sitecore items I need to create users through the membership provider. So simple…well it took a little bit to find the right fit. I had a few options, some kinda gross and one not gross.

I could have just extended the UpdateSitecoreItemStepProcessor to add Membership.CreateUser after the item update. This is gross because I’ve just couple item create and user creation, which goes against the pipeline concept. Not happening.

I could add a pipeline step within the User Info from File to User Item Pipeline, but then again my entire pipeline has both item creation and user account creation and when calling the pipeline I have to content with having both.

I honestly did do this for a bit for debugging purposes to make it easier to figure out where my data iteration lived and what it looked like for the plugin. But it wasn’t staying that way because sometimes I don’t want a Reeses Peanut Butter cup, sometime I just want the peanut butter.

The converter now stores the Sitecore pipeline step item’s field values as a plugin for retrieval in the processor. Knowing the json record were typical fields in the itemModel – I just grabbed them directly for storage.

Now the processor I based off of the decompilation of the UpdateSitecroeItemStepProcessor. I removed pieces around endpoint retrieval and modified the fixing of the Sitecore item to actually do this:

DISCLAIMER: I work at RBA. Everything here, however, is my personal opinion and is not read or approved before it is posted. Opinions, conclusions and other information expressed here do not necessarily reflect the views of RBA.