Posts tagged Personalization

ADF 11g – persisted run time user UI personalization or: Impatient man’s MDS

 

One of the rather cool pieces of functionality that did not make it into the JDeveloper 11g Boxer release of early October 2008 is the Meta Data Service or MDS and especially its capability to store and reapply user created personalizations of the User Interface across sessions. Some simple examples of what this means: ADF 11g Rich Client Components allow users to manipulate the state of components – such as the position of the separator in the PanelSplitter, the ordering and width of Table Columns, the initially visible tab or accordion child etc.. Through MDS, these changes are captured and stored for th duration of the session (if so desired), which means that when the user returns to a page thus ‘personalized’,  the component will not assume their default state as specified in the JSF page at design time by the developer, but rather the state that user specified. Eventually MDS will persist these component personalizations across sessions – but not right now. That means that at the present when a user starts a new session, all components are presented in their default state.

In this article I will describe two things: Change Persistency for all attributes – not just the built-in settings that can be manipulated through the components and Persisting the changes across sessions, even with the current release of JDeveloper, ADF and MDS.

Read the rest of this entry »

Personalizations in CRM foundation

The Case
At the customer we use Oracle Incentive Compensation (OIC). OIC is used to compensate external partners. These partners are maintained in CRM foundation. The partners are set up as salesperson. Salespersons can be used inside OIC.

The customer has two operating units. In CRM for each operating unit, the salesperson must be set up. So if you had setup the salesperson in operating unit A, then there’s not yet a salesperson in operating unit B.

The problem in CRM foundation is that it is possible to change information of operating unit B, while you’re using a responsibility that is assigned to operating unit A. If you change information of operating unit B, using the responsibility for operating unit A, the relation in the database will be made with operating unit A. So for example you changed a role that is used in operating unit B this will be related to the salesperson of operating unit A. This causes inexplicable errors. On screen everything seems ok, but somewhere hidden in the database there is a wrong relation.

Read the rest of this entry »