Interaction Management Process
Process Design Questionnaire
- Who do your call center agents interact with?
- Customers only? Dealers? Partners?
- What types of interactions are received / sent out?
- What is the structure of the call center?
- What is the number of Agents?
- Will these users be divided into functional groups?
- Will users have access to some forms/commands/data and not others?
- Number of Call centers?
- Where are they located?
- How many agents are there at each location?
- What is the number of interactions handled per agent per day?
- How do you measure your call center agents?
Generic Interaction Management Process – part 1
Generic Interaction Management Process – part 2
Generic Interaction Management Process – part 3
Generic Interaction Management Process – part 4
Generic Interaction Management Process – part 5
Sample Implementation Decisions
Implementing Asynchronous UI
When designing an application front end UI, it is always highly desirable to provide friendly, intuitive and pleasant user experience while they are interacting with our application.
One of the most annoying phenomena happens when the UI seems to be freezed while waiting for a lengthy task to complete.
In order to enhance user experience and avoid possible frustration, it is recommended to provide an interactive visual feedback which continuously updates the human user about the current status of the task, while allowing them to continue free interaction their UI.
In the following example I shall demonstrate how to divert a task to a separate thread and allow the user to continue interacting with the UI for other tasks. I shall also show how two independent front end tasks can interact one with each other without interfering UI operations.
Read the full story on Implementing Asynchronous UI
Implement Context Menu in Data Grid
Amdocs Smart Client Framework (ASCF) provides a rich set of functionality to allow flexible and attractive UI.
It is often required to allow the user select an option from a context pop-up menu. The context pop-up menu should be displayed when the user right clicks the grid.
Unfortunately, as of Amdocs CRM release 7.5.2, this visual requirement is not directly supported.
Look at Implement Context Menu in Data Grid to learn how to add this functionality.
Migrating Amdocs CRM Classic to Smart Client (part 2)
When considering migration of legacy Amdocs Classic client implementation to Smart Client technology, it is important to understand several aspect which might impact such migration.
The first part of this discussion we discussed the business and technical drivers for migration from Amdocs Classic to Smart Client technology . We discussed the preliminary information needed for migration assessment, as well as the required resources for such assessment.
This part further describes the following migration assessment and implementation aspects:
- Migration Assessment Planning
- Migration Project Planning
- Phasing
- Migration Techniques
Read more at Migrating Amdocs CRM Classic to Smart Client (Part 2)
Migrating Amdocs CRM Classic to Smart Client (part 1)
Business justification for migration from classic to smart client technology is a difficult subject. In some respects migration can be seen as having purely IT benefits, such as reduced deployment costs, reduced maintenance costs etc.
The main business drivers for migration are often based on leveraging new functionality that is available in the smart client, not available the classic client. This means that a purely technical migration will likely result in limited or no identifiable business benefits, making the business case very difficult to prove.
In many cases both technical and business drivers arise during the migration assessment.
It is important to understand that although both technical and business drivers for migration are viewed separately, there is an overlap between the two areas, as improved functionality is enabled through the use of the new architecture.
Read the full story Migrating Amdocs CRM Classic to Smart Client (Part 1)
Implementing ‘Got_focus’ Event in Smart Client
Q: Clear Basic provide ‘got_focus’ event for controls but I can’t find the same event in smart client.
Is there any way to implement this feature in smart client?
A: You can add your native contol focus event listeners (lost/gained) as follows:
(assuming your control is a textBox named ‘txtCustomerName’)
// Add the following in the form_Load() event handler: // define focus event listeners (lost/gained) ( (javax.swing.JComponent)this.txtCustomerName.getNativeControl()) .addFocusListener(new FocusListener()
{
// this is the equivalent to Clear Basic Lost_Focus()
public void focusLost(FocusEvent focusEvent)
{
// your logic here...
System.out.println("focus lost");
}
// this is the equivalent to Clear Basic Got_Focus()
public void focusGained(FocusEvent focusEvent)
{
// your logic here...
System.out.println("got focus");
}
}
);
Using Contained Core Business Objects
Q. When working with establish relation, I had a problem with a Bo having many parent, like:
1. We have an exist CaseBo object: caseBo
2. By using XVO, we create 2 new row to insert: emailLogBo and actEntryBo
3. In which: actEntryBo is child of both caseBo and emailLogBo, emailLogBo also is child of caseBo.
=> how can I insert emailLogBo and actEntryBo to database ?
Note that: Both emailLogBo and caseBo are parent of actEntryBo, so we can’t use actEntryBo.setParentBo(..) to set up relation. So, please suggest how to solve this problem.
A. Note that CaseBo object contains all the logic to do it automatically for you.
All you need to do is to add your new emailLog record to the CONTAINED emailLogBo.
When doing so, an actEntry will automatically be added and related with all relevant BO parties (CaseBo, UserBo, EmailLogBo).
About Contained Business Objects
Many BOs Contain other Business Objects. These contained CBOs are exposed as properties of the containing BO. For example, when a Case BO is created, contained BOs are automatically created for the logs related to the cases, the site and contact that reported the cases, and the installed part identified in the case
These contained CBOs are automatically related to the Case BO, usually as child BOs of the parent BO. They are accessed through CaseBO properties.
Field values for contained CBOs are accessed through properties of the containing BO
The following code shows how to get the first name of the contact who logged a case: String firstName=boCase.getContact().toString(“first_name”);
Note:
- Most contained CBOs are Generic BOs.
- To reduce network traffic and improve response times, many contained BOs set bo.DataFields and bo.QueryMode to minimize the amount of data retrieved. Make sure to modify the DataFields property of the contained Bo to include necessary fields before performing the query.
Example:
String fields= boCase.getContact().getDataFields() + ",e_mail"; boCase.getContact().setDataFields( fields ); boCase.query();
Example of adding email log to a CaseBo:
// Add a new row to the contained EmailLog BO. boCase.getEmailLog().addNew(); // Set the note description for the new row. boCase.getEmailLog().setValue("description", "Customer mailed again to ask about the case status"); // Commit changes to the database. boCase.update();
Smart Client Messaging
About Smart Client Messaging
Smart Client messaging is far more flexible than its Classic predecessor. Smart Client forms can communicate with other forms by messaging.
See more about Smart Client Messaging…
Implementing Smart Client Tree Control
Smart Client Tree control displays hierarchical information in an outline structure.
It extends SWING’s JTree base functionality and provides visual presentation to hierarchical data.
Need to display logical model
In a dynamic tree control?
Learn how to implement Tree control in Smart Client Java Swing technology.
Read Implementing Smart Client Tree Control for full story and step by step examples.
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:
- Countinue using the WorkerBean and its related SaveBean / LoadBean
- Move the logic completely to a new XBean.
-
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.