NextGen Consulting

How to Upgrade Backend

Q. There is a form, the back end for that form was implemented by Worker Bean.
I’m upgrading that form to a new version by creating derived form and add on some needed features.
What about the backend, Is there any way to upgrade the old Woker Bean?
Note that the new backend should be implemented by XBean.

 

 

A. Using derived form does not require any change in the backend if you do not need any changes or additions to the backend logic.

If you do need to modify the backend code, you can use either of the following options:

1. Countinue using the WorkerBean and its related SaveBean / LoadBean
2. Move the logic completely to a new XBean.

 

1. Countinue using the WorkerBean and its related SaveBean / LoadBean
   

In this case you need to:

• Override the original Workerbean.
  Create your own version to the WorkerBean only if your new logic require passing new parameters.
  If there is no change is the parameters, do not override the workerbean, leave the original one.
• Override the related Savebean (or Loadbean) with a new Save/Load bean.

  

Remember that overriding a backend Bean (WorkerBean, SaveBean or LoadBean) equires:

• Providing a new name to the new Bean (i,e X1<original_bean_name>)
• Mapping the original bean name with the new bean name.

 

Mapping

The mapping should be in a backend class called Config.java  located in the package com.<your Organization>.crm

For example: com.nextgen.crm.Config.java

 

 The mapping format for each entry should be as follows:

String <original class full qualified name> + ";" + String <new class full qualified name>

If you have several new entries, seperate them by a coma (,).

 

Example for Config.java which contains two entries:

 

package com.nextgen.crm;

/**

  *

  * @Description Replace OOB Beans with Custom Beans

  * @version NextGen

  * @author 

 **/

public class Config {

  // Default constructor

  public Config() {}

  //String array mapping baseline classes with custom subclasses

   public static String[] m_MapTable = {

  com.clarify.isupport.contact.savebean.ContactOverviewCIHSB.class.getName() + ";" +
  com.nextgen.isupport.contact.savebean.X1ContactOverviewCIHSB.class.getName()

 ,com.clarify.isales.account.workerbean.CustomerProfileTabCreateSaveWB.class.getName() + ";" +
  com.nextgen.crm.isales.account.workerbean.X1CustomerProfileTabCreateSaveWB.class.getName()

   };

  /**

    * @Description Retrieve the mapping of custom subclasses when Weblogic starts

    */

  public String[] getClassMapTable()

  {

     System.out.println("*** New Class Map *** [" + this.getClass().getName() + "]");

     return m_MapTable;

  }

} /// Config

 

Updating ASC

Remember that you need to make sure class path of Config.java is configured in your ASC (Amdocs System Configuration) as follows:

Node Path:             /crm/baseConfig/clarifyEnv/user_package

Entry:                 com.<your organization>.crm

Entry example:     com.nextgen.crm

 

 

2.  Move the logic completely to a new XBean

Moving the logic to a new XBean first requires copying the old logic from the Workerbean and its related SaveBean (or LoadBean) to a new XBean.

 

Note the following:

 

• The Workerbean is used only for passing the data from your front end client to your SaveBean. This data is passed via CDOs, where the XBean gets its data directly using XDOs (practically XVos).
  You shall need to convert your passed data fron CDO to XVo.
    
• You shall need to copy the SaveBean (or loadBean) logic to the new XBean.  
  This should be fairly easy if you managed to properly convert your data as mentioned in (1).
    
• You might consider *not* to map the original OOB WorkerBean to your new XBean,  but call it explicitely from your front-end.
  This is to maintain backward compatibility with other front-end code that might use it from other forms.

 

 

Which Option to Use?

Obviously, moving logic to a new XBean is more complex, and needs to be updated with every upgrade to a future release. However, it provides much more efficient code which is easier to maintain.

On the other hand, merely creaying your new versions for the OOB WorkerBean and SaveBean (or LoadBean) is much easier task and backward compatible.

15/09/2010 Posted by Yuval R. | Amdocs, CRM, CRM, Development, Smart Client, Technology | Leave a comment