Friday, February 29, 2008

CURAM UIM problem

I had this funny problem..in CURAM...

we had a requirement , where we had to develop a screen based on a particular type..

For example :- for type 1 we needed the screen to show 3 fields
for type 2 we needed the screen to show 4 different fields and so on .. and we had around 40 types... so it was a question how do we resolve this issue with Curam UIM limitations...


The Approach:--
Solution 1 :- Have a table that would map each type to a UIM and the metadata for that type(like fields to display and so on).and write code to generate the UIM screens and the facade methods and the structs for the facade mthods

The appoach.. was interesting as it involved some code generations.. but some how with the time constarint and not a scalable solution , we did not go by this approach.


Solution 2:- We decided to show all fields of all the type in a single UIM and then have a display indicator for each field..based on the type would display it.
And a single facade method that would have 3 attributes , that is the field type, new value and old value...as every filed is modified .. using AJAX call the facade method and then store each field in a cache and once all of them is done .. do the required server processing...

The approach was complex and was getting away from the UIM architecture.. had to use a lot of custom JSP to get it solved.. and there would be a lot of calls from the client to the server, which would cause a lot of network traffic.

Solution 3:- Have a single UIM with all fields and a display indicator for each field.Have a facade method with all the field value , field type .i.e we had around 40 fields of all types.. so he had this huge struct of 80 attrubtes used in the facade method to do the server side processing.

The approach is not the best solution to the design problem. as it is not scalable..but it was a simple one...and when u want to implement this on the client side.. we may have to forget the best way ..most times... and go for a simple approach as it involves cost and time :-).. time cannot be spent on identifying the best and the right approach.. so we decided to go with this approach...

No comments: