Avoiding pitfalls when using MDM Data Objects in BPM

Body

Occasionally when creating Business Process with the MDM Application Toolkit you may be returned errors from the server which at first glance seem a bit cryptic. When running against Virtual MDM you may sometimes come across errors which look like the following: IxnMemPut did not succeed. Reason: member XXX, unable to insert/update/delete member data.

In some cases this can be caused by the way BPM initialises variables as it serialises between Java objects and Javascript objects, for use on Coaches. So for example if I have an un-initialised, or null object before I display this object on a coach (i.e. have it bound to a CoachView) then when I check it after the coach, it will have been initialised. The problem is in fact a bit more convoluted than this, with nested complex objects, as the level they are initialised to is increased with every coach the object is used in. So for example, if I have a heavily nested data type, and an instance of this is used in 3 coaches, after the first coach the top level is initialised, after the second coach the top level, and the children of the top level are initialised, and after the third coach the top level, it's children and their children will be initialised. In Json this would look like:

Person : { Name : { First : String, Last : String}, Address : {Line1 : String}}
If we perform a search and get back person = {Name : {John, Rogers}}. We select this entry and move to the next coach.
In the next coach we will have person = {Name : {John, Rogers}, Address : {}}. If leave this coach and send data up to the server
we will in fact be sending person = {Name  : {John, Rogers}, Address : {Line1 : "" }} with this, we may get an error (if field is mandatory), or we may overwrite data in the server with blank fields.
 

This can be a problem in the Application Toolkit, for example when creating a simple search and update process. If I retrieve a sparsely populated object from the server, and pass it into a coach, any unused or empty fields will now be inititalised, if I pass this object to several more coaches before sending it back to the server as an update, then several levels of initialisation may have occured in any nested complex objects. In Virtual MDM this may give you an error if one of those initialised fields is required, as the engine will check to make sure you are not trying to set it to as blank, or an empty value. If you don't get an error that does not mean everything is okay, it could be that data on the server that was not originally retrieved has now been overwritten by empty values.

To make sure this doesn't happen it is important to follow BPM Coach design best practice and make sure you always use a display object when displaying an object in a coach. What this means is creating a data type (the display object) that contains only the fields you wish to display on screen, and copying the values into an instance of this new data type from the object retrieved from the server. This will also offer a performance enhancement as the whole object from the server is not passed back and forth from BPM to the web browser.