Posts in "Serializer" category

sobject-serialization project update

The arrival of Winter ’12 brings with it the long awaited feature, by me at least, native JSON support.  This is a massive plus for the platform and it’s ability to support further integration with external systems – something which is key to the survival of any cloud based platform in this day and age.

Whilst being fantastic news for the platform, it does sound the death knell for my sobject-serialization project over on GitHub.  The project started out life as a way to pass sobjects to @future methods by serializing them into a string and then rehydrating them within the @future method.  I started by using solely the string.valueOf method to serialize the sobject then added primitive JSON like capabilities.  Most recently I was expanding it to also allow you to pass primitive types and lists using the same methods.  However, the in built JSON support will allow you to do this without having to make use of my classes and hence your script statements and associated governor limits!

The best thing is it’s all really easy to do, just look at this overly simple self contained example:

public class PassToFuture{
    public void PassAnAccount(){
        Account a = new Account(name = 'Simon');
        String s = JSON.serialize(a);
        MyFutureMethod(s);
    }
    @future(callout=false)
    public static void MyFutureMethod(string accountString){
        Account a = (Account)JSON.deserialize(accountString, Account.class);
    }
}

Given that this is so easy, I really can’t see the point in continuing to develop my project. It will reamin on GitHub for anyone to do with as they please; I however will probably not be putting too much effort into pushing it forward.

And that is that – I have some more Winter ’12 thoughts to come especially around public test classes but I’ll save those for another day.

Project updates

The past few weeks have been quiet for me in terms of any kind of technology driven activity, outside of work. Mainly due to the massive reorganisation of the house that we’ve been undertaking: creating an office, remodelling the living room, creating a nursery and contemplating the merging of the kitchen and dinning room – no room has been left unturned! All very DIY and I have to say; these hands were made for typing.

All of this has meant that I’ve not had much chance to contribute to the world in any particular way. However, over the past week I have managed to find some time and energy to get back into the swing of things and I have made some contributions to two of my open source projects.

  • FluentHTML – I have started working my way through the list of tags that exist in HTML5 and adding them into the project.  It’s ongoing but I have a couple of commits in there now which I think brings the list up to the end of the b’s!  I am just pushing through the list initially to try and get all of the tags in there.  After that I will look at any refactoring that might be possible and also at providing useful overrides on the methods.  I am also toying with the idea of validating the attributes that you can add to each tag but as I stand am unsure as to whether this is a good idea.
  • sObject Serialization – I have decided to make some fairly big changes to this.  Whilst the original idea was driven by the need to pass sobjects to @future methods I have decided that I will branch the project out and make it able to also (de)serialize lists and primitive types too.  This means a change to the interface so for the meantime I have created a Lists and Primitives branch in GitHub and am committing these changes to it.  Once they’re ready I’ll merge it back into master.  Currently I have updated the string serializer to fulfil the new requirements.  The JSON version will be updated but I need to update the JSON parser in there first, so it won’t happen straight away.

So that’s where I currently stand on these two projects and should hopefully give you a view of where I’m going in the short term with them.  Obviously progress is, as ever, subject to free time – an concept that currently seems to ebb and flow without much control.

JSON serialization for sObjects

I have just pushed an update to the sObject serialization project up to GitHub.  This update is a class to serialize/deserialize sObjects into JSON.  This removes the dependance on the native string.valueOf() method that the earlier serializer was dependent on and also means that the objects are converted to a standard format rather than a proprietary one.

I followed the specification for the JSON format as specified on the JSON.org website.  The biggest issue I had was around accessing fields from the object that hadn’t been selected in the SOQL.  I couldn’t find a way to test to see if the field was available which has unfortunately led me to have to use exception handling to control the situation.  I’m not keen on using the try/catch construct to control program flow but I can’t see another way around this it at the moment so have reluctantly left the swallowing catch in the code.

The serializer implements the same serializer interface as the StringSerializer does which means if you want to change serialization methods you can simply swap the StringSerializer out for the JSONSerializer and everything should continue to work as before.

With the introduction of the REST API from Salesforce this class is fairly redundant from an integration stand point.  However for passing sObjects to @future methods this still has legs; hence the update.

As ever this is up on GutHub as Open Source and as such is there for everyone to use, steal or enhance so feel free to dig into it and make use of it.

sObject serialization project update

A quick update on the sObject serialization code.  I have added the project to GitHub as promised and I have also submitted it to the Force.com Code Share site too.  Although if/when it will appear on there I have no idea.

Other than that I haven’t, as of yet, managed to actually update the code base in any fashion, so that’s pretty much all I’ve got to say about this today!

Passing sObjects to @future methods in SalesForce

I discovered something this week: you can’t pass sObjects as parameters to methods that are decorated with the @future annotation in SalesForce. It is documented, I’d just missed it previously – it is there just read carefully. Oh, bummer, I like passing sObjects around.

I decided to solve the issue by serializing the sObject to a string, passing the string to the @future method and then deserializing it back into the sObject.

The serialization part of the problem is already solved for us by the string.valueOf() method. I say solved; it doesn’t provide a complete solution, for example it won’t traverse relationships, but it’s complete enough for my current needs.

The deserialization is, unfortunately, not such a simple solution. SalesForce don’t provide us with a method such as Schema.sObjectFrom( string input ). This means that we need to parse the string back into an object ourselves.

The output from the string.valueOf() method can be generalised like this:

<sobjecttype>:{<field1>=<value1>, <field2>=<value2>, …, <fieldn>=<valuen>}

At first glance this string looks fairly easy to parse we have the sObject type listed so we can easily instantiate one of those and then for the fields we have commas and equal signs that we can use as delimiters. However after two more seconds of thought you soon come to realise that it is, indeed, too good to be true. The problem lies in the fact that the values of the fields can potentially be any string of characters; this includes commas and equal signs. Suddenly the parsing of the string isn’t such a simple prospect.

In fact to find any delimiters that are 100% reliable is an impossible task. So what can we do instead? The approach I decided to opt consists of a two pronged attack. The first part of the solution prepends the string “, ” that’s &lt;comma><space> to the string between the curly braces. Then applying the following regular expression to the result: Pattern.compile( ‘, ([^ ]*?)=’ )

This returns a series of matches and in each match two groups of characters. The second prong is to look at the second grouping in each match and see if it is a valid field name for that object. Whilst not fool proof this provides a fairly high level of certainty that we’re breaking the data up correctly.

After we’ve broken the string down correctly it’s simply a case of checking the types and adding the data to the right field in our new sObject.

There is one slight oddity; if we have an Id then we have to instantiate the sObject with the Id, which means looping through the fields and if there is an Id there then recreating the result sObject.

The resulting code can be install from this unmanaged package.

An obvious limitation to this, and any kind of non-SalesForce deserialization, is that we cannot update certain fields such as LastModifiedDate. This will always be the case and as such something that we have to live with, if you need this information from the original sObject then you’ll have to pas it to the method separately. But at least you don’t have to pass every field this way.

Overall I’m happy with this as a solution to the problem but it is clearly very brittle; if SalesForce change the way in which string.valueOf() works we’re doomed. The solution to this is to control both sides of the equation and that’s what I plan to do next. Customising both sides of the process should allow for the creation of a much more robust solution.

You may have noticed that the class above implements an interface called Serializer.  I have done this to allow me to write more implementations of the serialization code and to be able to swap it in and out with ease.  Over the next few days I will get this code up onto Google Code and try and make a start on the better serializer implementation.  Updates to hopefully follow soon.