Userdata handling on the server side

Sales Center provides the capability of sending and retrieving custom data back and forth to WebSphere Commerce Server without extending the BOD request. This can be done by adding the Userdata and filling it with a set of name-value pairs. At the receiver side the Userdata element will be unmarshalled and will populate its values to the Java objects. By default, the Sales Center client application creates and unmarshalls the Userdata up to the level of each model object in request handler classes. This means that wherever a model object exists in its own method, the framework creates as well as unmarshalls the Userdata automatically.

However, Sales Center server application (extension logic at WebSphere Commerce Server) has only one level of Userdata support by default. Each response builder class has one SearchResultBean object which is populated based on the request parameters and it contains the data beans at various levels. Here the problem is that only SearchResultBean supports the Userdata property and not the data beans. While creating the response BOD, only the top level of Userdata gets added automatically; you have to add Userdata programmatically in all lower level as required.

There is one more difference between client and server side creation of Userdata. There are several places on the client side for customization to add Userdata, such as extending the request handler and adding name-value pairs in the data model, or extending the editor and populating the name-value pairs in the data model. But on the server side, you have to extend the response builder class to manipulate the Userdata because there is only one place for customization. So in all cases you have to extend the default response builder classes. Currently, server code creates Userdata for each response BOD, and when it finds the Userdata property in SearchResultBean, it populates in the BOD. This can be easily done as follows:

Extend ConfirmSalesOrder response builder class and add custom information in Userdata map as a name-value pair:

public class ExtConfirmSalesOrder extends ConfirmSalesOrder {
     protected Element
createSalesOrderElement(OrderBaseSearchResultBean
abnOrderBaseSearchResult, Element aParent) throws ECException {
     if (null == abnOrderBaseSearchResult){
         
abnOrderBaseSearchResult.addUserDataField("firstEelement", "First
Eelement");
           abnOrderBaseSearchResult. addUserDataField
("secondEelement", "Second Eelement");
           abnOrderBaseSearchResult. addUserDataField
("thirdEelement", "Third Eelement");
}
           return
super.createSalesOrderElement(abnOrderBaseSearchResult,aParent);
     }
}

The resulting BOD will look like this:

<wc:SalesOrder>
     <wc:UserData>
           <wc:UserDataField name=" firstEelement"> First
Eelement </wc:UserDataField>
           <wc:UserDataField name=" secondEelement "> Second
Eelement </wc:UserDataField>
           <wc:UserDataField name=" thirdEelement "> Third
Eelement </wc:UserDataField>
     </wc:UserData>
</wc:SalesOrder>

Now the client side unmarshall method will take these values and repopulate the SalesContainer data model.

public class ExtdShowSalesOrder extends ShowSalesOrder {
      protected Element createLineElement(OrderBaseSearchResultBean
abnOrderBaseSearchResult, Element aParentElement) throws
ECException {
            Element lineElement =
super.createLineElement(abnOrderBaseSearchResult, aParentElement);
            if(null != lineElement){
                  Element userDataElement =
createWCDocumentElement(lineElement,
BodConstants.TAG_WC_USER_DATA);
                  createUserDataFieldElement(userDataElement,
ECMemberConstants.EC_ADDR_FIELD1, "some value1");
                  createUserDataFieldElement(userDataElement,
ECMemberConstants.EC_ADDR_FIELD2, "some value2");
                  createUserDataFieldElement(userDataElement,
ECMemberConstants.EC_ADDR_FIELD3, "some value3");
            }
            return lineElement;
      }
}