Tuesday, July 8, 2014

Omniture tagging with Oracle WebCenter / ADF pages


In this post we will see how to do omniture tagging with Oracle WebCenter  portal pages. Omniture is an industry leading reporting service which is primarily used by enterprises to track user behavior across custom portals. 

Adobe Omniture Analytics tagging is done can be done on various client actions such a loading a page, clicking on a button or even hovering on a text. The tagging is done through a standard omniture javascript library called s_code.js

We need to include the s_code js file as a resource in our pagetemplate and subsequently use the s variable exposed in the file in utility tagging methods. s_code.js file looks something like this and you can get the actual version from Adobe product team once you get access to setup account.















Omniture global configuration properties

We should have these properties configured from database and depending on environment variables.
  1. s_account
  2. s.visitorNamespace
  3. s.trackingServer
  4. s.trackingServerSecure

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
/* SiteCatalyst code version: H.25.3.
Copyright 1996-2012 Adobe, Inc. All Rights Reserved
More info available at http://www.omniture.com */
/************************ ADDITIONAL FEATURES ************************
     Plugins
*/

var s_account="xyz-dev"
var s=s_gi(s_account);

/* WARNING: Changing any of the below variables will cause drastic
changes to how your visitor data is collected.  Changes should only be
made when instructed to do so by your account manager.*/

s.visitorNamespace="xyz"
s.trackingServer="track.xyz.com"
s.trackingServerSecure="strack.xyz.com"


Apart from the global variables - omniture requires the pages to define the type of event ( or event name), custom properties and variables. Defining these variables help reporting and segregating the event types and values.

We create a JavaScript method to push event to omniture .


1
2
3
4
5
6
7
8
9
10
11
function tagLinkClick(event) {
    var eventSource = event.getSource();
    var linkName = eventSource.getText();
    var eventName = eventSource.getProperty("eventName");
 s.eVar1 = linkName;
 s.prop1 = linkName;
 s.linkTrackVars = 'eVar1,prop1,events';
 s.linkTrackEvents = eventName;
 s.events = eventName;
 s.tl(this, 'o', 'Click Me');
}



Capturing client events

Last and the easiest step is to call the tagLinkClick javascript method on link click.

1
2
3
4
5
 <af:commandLink text="#{bundle.CLICK_ME}"
  id="cl1" >
 <af:clientAttribute name="eventName" value="eventX"/>
 <af:clientListener method="tagLinkClick" type="action"/>                  
</af:commandLink>


You can then login to omniture account and see the real time reports. Please let me know what you think about the approach. Any comments welcomed.


Monday, June 30, 2014

ADF: jQuery Auto Suggest Implementation


Oracle 11gIn this post we will see how to integrate the one of the jquery's famous plugins, the ui autosuggest component with an Oracle Webcenter application using ADF faces. This implementation assumes that the requirements around the autosuggest doesn't meet the requirements of the af:autoSuggestBehavior. So lets first discuss why is the out of box auto suggest behaviour in behavior in adf not that desirable.



Cases where af:autoSuggestBehavior is useful

  1. If you have a large complex dataset ( in tunes of +5000 objects)
  2. If the performance / experience of the autosuggest is not a concern

Cases where custom implementation is useful

  1. The autoSuggestBehavior is not a "client only" side implementation so every change in the value triggers an expensive backend call even if there is a static list of values.
  2. Not every time we require to fetch data from backing bean, there are times and I believe for most of the cases we already know the data for which we are applying autoSuggest.
  3. The lack of flexibility to add custom behavior to suggested output is difficult.


So lets build our awesome autosuggest. Assume we have a requirement of auto-suggesting the user from a list of countries. Here's the steps

Step 1 : Add required libraries to our template


Libraries required:
  1. Add jquery core library, if not present already
  2. Add jquery ui custom library ( including the autosuggest plugin )
  3. Also we need GSON jar in classpath ( optional ). Its useful to flush out JSON in proper format

1
2
<af:resource type="javascript" source="/js/jquery-1.11.0.min.js"/>
<af:resource type="javascript" source="/js/jquery-ui-1.10.1.custom.min.js"/>

Step 2: Add a clientListener

The clientListener will fire a client event on focus to a javascript method suggestContries

1
2
3
4
5
6
<af:inputText label="#{bundle.COUNTRIES}" id="it1"
  clientComponent="true" styleClass="countriesBox"
  value="#{myBean.country}"
  immediate="false">
 <af:clientListener method="suggestCountries" type="focus"/>
</af:inputText>


Step 3: Add a method in backing bean


Lets create a method in our backing bean to initialize the data for autosuggest. The method flushes out javascript variable data to the client.The flushed out data contains the list of countries in JSON format. On executing the method we get the JSON string in a JS variable called countriesJS


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
public void getCountriesJSON() {
 
 StringBuilder sb1 = new StringBuilder();
 try {
  /*
  * Get all countries:
  */
  //TODO: replace retrieveCountries method to get the set of CountryData objects
  Set<CountryData> countries = retrieveCountries();
  // create an instance of JsonArray
  JsonArray countriesJsonArray = new JsonArray();           
  sb1.append(" countriesJS=");
  Iterator<CountryData> iter = countries.iterator();

  while (iter.hasNext()) {
   CountryData countryData = iter.next();
   JsonObject countryDataObjJson = new JsonObject();

   countryDataObjJson.addProperty("label", countryData.getCountryName());
   countryDataObjJson.addProperty("value", countryData.getCountryCode().trim());

   countriesJsonArray.add(countryDataObjJson);
   }


  sb1.append(countriesJsonArray.toString());

 } catch (Exception e) {
  e.printStackTrace();
 }
 /*
  * Utility method to add the product json object to client page
  */
 addScriptOnRequest(sb1.toString());
}


Utlity method to add script on request:


1
2
3
4
5
6
public static void addScriptOnRequest(String script) {
 FacesContext context = FacesContext.getCurrentInstance();
 ExtendedRenderKitService erks = 
 Service.getRenderKitService(context, ExtendedRenderKitService.class);
 erks.addScript(context, script);
}

Step 4: Get the data on page load


Now lets add the following code to the page where you have the autosuggest input box. This piece of code will call getCountriesJSON method in your backing bean and load the JSON data on the client.


1
2
3
4
<af:document id="d1" title="#{bundle.MY_COUNTRIES}">
 <af:clientListener type="load" method="loadCountriesOnLoad"/>
 <af:serverListener type="loadCountriesEvt" method="#{myBean.getCountriesJSON}"/>
</af:document>


Add loadCountriesOnLoad Javascript method


1
2
3
4
5
6
 function loadCountriesOnLoad(evt)
{
 var customEvent = new AdfCustomEvent(evt.getSource(),"loadCountriesEvt",{}, true); 
 customEvent.preventUserInput();
 customEvent.queue(true);
}


So when page loads we will have the countriesJS is assigned to the following JSON


1
2
3
4
[
    {"label":"Afghanistan", "value":"AFG"}, 
    {"label":"Albania", "value":"ALB"}
]


Step 5: Wiring everything up


We will write the final JavaScript method mentioned on the onFocus event mentioned in Step 1
 - suggestCountries


1
2
3
4
5
6
7
8
9
10
11
12
13
14
function suggestCountries(evt) {
    var src = document.getElementById(evt.getSource().getClientId() + '::content');
    countriesComp = $(src).autocomplete( {
        "source" : countriesJS, "minLength" : 2,autoFocus: false,
        select : function (event, ui) {
           
        }
    }).autocomplete( "instance" )._renderItem = function( ul, item ) {
      return $( "<li>" )
        .append( "<a>" + item.label + "<br>" + item.value + "</a>" )
        .appendTo( ul );
    };
    
}


so here you go, we have the all client side auto suggest implemented !!! Please let me know what you think about the approach.


Friday, June 27, 2014

ADF Code Examples: af:selectOneChoice


Oracle 11gThis component generates a menu link with a single menu selection model. The value that goes to backing bean by default is an index (0,1,2) unless the valuePassThru is true. If valuePassThru is false then the selection value is based on indices. I am trying to use as much properties in the examples but please free to use them selectively.



Populating af:selectOneChoice  using af:forEach

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<af:selectOneChoice id="sc1" clientComponent="true"
  required="false" immediate="true" 
  shortDesc="#{bundle.TYPES}"
  showRequired="true" mode="default" 
  contentStyle="width:30px" 
  binding="#{pageFlowScope.myBean.types}"
  value="#{pageFlowScope.myBean.type}"
  unselectedLabel="#{bundle.SELECT_ONE}"
  label="#{sprportalBundle.TYPES}:"
  autoSubmit="false">
 <af:forEach items="#{bindings.typeLOV.iteratorBinding.allRowsInRange}"
   var="item">
  <f:selectItem id="sit1" itemLabel="#{item.type}"
    itemValue="#{item.type}"/>
 </af:forEach>
</af:selectOneChoice>


Populating af:selectOneChoice  using individual af:selectItem tags

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<af:selectOneChoice label="#{bundle.MYLABEL}"
  id="xs1" required="false"
  immediate="true"
  valueChangeListener="#{pageFlowScope.myBean.typesVCL}"
  showRequired="true"
  value="#{pageFlowScope.myBean.type}"
  binding="#{pageFlowScope.myBean.typeBinding}"
  styleClass="classname">
 <af:selectItem label="#{bundle.CHOICE_TYPE1}"
   value="#{pageFlowScope.myBean.typeValue1}"
   id="xs2"/>
 <af:selectItem label="#{bundle.CHOICE_TYPE1}"
   value="#{pageFlowScope.myBean.typeValue2}"
   id="xs3"
   rendered="#{pageFlowScope.myBean.typeValueShown}"/>
</af:selectOneChoice>

Populating af:selectOneChoice  using af:selectItems tag


1
2
3
4
5
6
7
8
 <af:selectOneChoice value="#{bindings.Team.inputValue}"  label="#{bundle.MYLABEL}"                      
  shortDesc="#{bindings.type.hints.tooltip}" id="xc2"
  binding="#{pageFlowScope.myBean.team}" autoSubmit="true"
  unselectedLabel="#{bundle.MYLABEL}"
  rendered="#{not pageFlowScope.myBean.noTeams}"
  simple="true">
 <f:selectItems value="#{bindings.Team.items}" id="xc3"/>
</af:selectOneChoice>


ADF Code Examples: af:commandButton [deprecated]


Oracle 11gThis post provides different flavors of af:commandButton usage however the component itself has been deprecated in favor of af:button (super button) in 12c. A command button generates an action event  on the server following a button press which largely differs from the behavior of a goButton.



Using af:commandButton to call an action method with params in your bean


1
2
3
4
5
6
7
8
9
<af:commandButton text="#{bundle.MY_BUTTON}"
  id="cl1"
  actionListener="#{myBean.actionMe}"
  partialSubmit="true"
  partialTriggers="cl2"
  rendered="#{myBean.showLink}">
 <af:setActionListener from="#{myBean.oneVariable}"
   to="#{myBean.otherVariable}"/>
</af:commandButton>


Using af:commandButton to open a popup


1
2
3
4
5
<af:commandButton text="#{bundle.MY_BUTTON}" id="cl1"
  partialSubmit="true"
  clientComponent="true">
 <af:showPopupBehavior triggerType="click" popupId="p1"/>
</af:commandButton>

Calling a JavaScript function with af:commandButton


1
2
3
4
5
6
7
8
9
 <af:commandButton text="#{bundle.MY_BUTTON}"
  id="cl1" 
  clientComponent="true"
  partialSubmit="true">
 <af:clientAttribute name="name"
   value="#{myBean.name}"/>
 <af:clientListener method="showAlert"
   type="click"/>
</af:commandButton>


Thursday, June 26, 2014

JDeveloper and its confusing Extension versions

Extensions for JDeveloper are synonymous with plugins for Eclipse only that the former is tied to Oracle Fusion Middleware Products. There are number of fusion middleware products and these products have there own versions, needless to say not all product versions get served with only a single JDeveloper version.

We take an example of Oracle WebCenter Extensions - recently WebCenter Portal PS7 got released, hurray ! excited ! anyways coming back to point - PS7 was released with extension version of 11.1.1.8 and logically ( as well as historically ) you would have a JDeveloper 11.1.1.8 but No ! - you only see a 11.1.1.7 version ??

Now if you are like me then you go to Google and check if  JDeveloper 11.1.1.7 supports WebCenter Extensions 11.1.1.8 and you would be lucky enough to find this great table from JDeveloper' Extensions and a comment from andrejus. Else just follow my que and download JDeveloper from here

VersionRequirementsLinks



11.1.1.8.0.130707.1955oracle.studio (min=11.1.1.7.40.64.93, max=11.1.1.7.999)
oracle.j2ee (min=11.1.1.7.40.64.93, max=11.1.1.7.999)
Download
11.1.1.8.0.130926.1405oracle.studio (min=11.1.1.7.40.64.93, max=11.1.1.7.999)
oracle.j2ee (min=11.1.1.7.40.64.93, max=11.1.1.7.999)
Download
11.1.1.8.0.131217.0204oracle.studio (min=11.1.1.7.40.64.93, max=11.1.1.7.999)
oracle.j2ee (min=11.1.1.7.40.64.93, max=11.1.1.7.999)
Download
11.1.1.8.0.140404.0207oracle.studio (min=11.1.1.7.40.64.93, max=11.1.1.7.999)
oracle.j2ee (min=11.1.1.7.40.64.93, max=11.1.1.7.999)
Download

Now thats a find don't you think :)

Abhinandan Panda
Happy Me ! BTW, I am the one at back

Wednesday, June 25, 2014

ADF Code Examples: af:commandLink [Deprecated]


Oracle 11gThis post provides different flavors of af:commandLink usage however the component itself has been deprecated in favor of af:link in 12c. A command link generates an action event  on the server following a link click which largely differs from the behavior of a goLink.

Using af:commandLink to call an action method with params in your bean


1
2
3
4
5
6
7
8
9
<af:commandLink text="#{bundle.MY_LINK}"
  id="cl1"
  actionListener="#{myBean.actionMe}"
  partialSubmit="true"
  partialTriggers="cl2"
  rendered="#{myBean.showLink}">
 <af:setActionListener from="#{myBean.oneVariable}"
   to="#{myBean.otherVariable}"/>
</af:commandLink>


Using af:commandLink to open a popup


1
2
3
4
5
<af:commandLink text="#{bundle.SUI_RECENT_SEARCHES}" id="cl1"
  partialSubmit="true"
  clientComponent="true">
 <af:showPopupBehavior triggerType="click" popupId="p1"/>
</af:commandLink>

Calling a JavaScript function with af:commandLink


1
2
3
4
5
6
7
8
9
 <af:commandLink text="#{row.header}"
  id="cl1" 
  clientComponent="true"
  partialSubmit="true">
 <af:clientAttribute name="name"
   value="#{myBean.name}"/>
 <af:clientListener method="showAlert"
   type="click"/>
</af:commandLink>



Blogger: "don't track your own pageviews" issue


Why am I getting this freaking error? Surely, Google can do better than this.



Here is some trace to help solve the issue

Network Trace:


  1. Request URL:
    https://www.abhinandanpanda.com/b/statsBlockingCookie?action=TEST&callback=__gwt_jsonp__.P1.onSuccess
  2. Request Headers CAUTION: Provisional headers are shown.
    1. Accept:
      */*
    2. Cache-Control:
      no-cache
    3. Pragma:
      no-cache
    4. Referer:
      https://www.blogger.com/blogger.g?blogID=7960247454552015802
    5. User-Agent:
      Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
  3. Query String Parametersview sourceview URL encoded
    1. action:
      TEST
    2. callback:
      __gwt_jsonp__.P1.onSuccess

Top adf code snippets for common tasks

Hello there!  Today let’s see the top commonly used ADF snippets (at least that’s what I thought while starting to share itso here you go with the entries.


1.      Getting the page bindings


This is commonly used to get the page bindings in the managed bean to get either specific binding values or get a hold on the action for the binding.

1:    public static BindingContainer getBindingContainer() {  
2:      FacesContext facesContext = FacesContext.getCurrentInstance();  
3:      Application app = facesContext.getApplication();  
4:      ExpressionFactory elFactory = app.getExpressionFactory();  
5:      ELContext elContext = facesContext.getELContext();  
6:      ValueExpression valueExp = elFactory.createValueExpression(elContext, "#{bindings}", Object.class);  
7:      return (BindingContainer)valueExp.getValue(elContext);  
8:    }  

2.     Getting hold off the Application Module


Application modules are required to do any sort of tasks binding the view object and the view links and all wrapped around by services. So needless to say that whenever there is a need to call your service getting to your AM is your first step.


1:    public static ApplicationModule getApplicationModuleForDataControl(String name) {  
2:      BindingContext bindingContext = BindingContext.getCurrent();  
3:      ApplicationModule appModule = null;  
4:      if (null != bindingContext) {  
5:        DCDataControl dc = bindingContext.findDataControl(name);  
6:        if (dc != null) {  
7:          appModule = (ApplicationModule)dc.getDataProvider();  
8:        }  
9:      }  
10:      return appModule;  
11:    }  


3.     Resource Bundle Properties


     There are scenarios where we want to get the property values from the resource bundle in our beans and this happens more often than you think!

1:    public static String getResourceProperty(String label, Locale userLocale) {  
2:      String bundle_name = "com.example.mybundle";  
3:      String txt = null;  
4:      try {  
5:        ResourceBundle bundle = BundleFactory.getBundle(bundle_name, userLocale);  
6:        if (bundle != null) {  
7:          txt = bundle.getString(label);  
8:        }  
9:      } catch (Exception e) {  
10:        logger.severe("Problem in loading resource bundle: " + bundle_name, e.getMessage());  
11:      }  
12:      return txt;  
13:    }  

4.     Is the request a PPR?


     Ever wondered if a request is a normal full request or a partial page request, well the following snippet gives you that information. This is a very useful thing to know when you try to filter out requests in your listeners.

1:    public static boolean isPprRequest() {  
2:      FacesContext facesContext = FacesContext.getCurrentInstance();  
3:      return AdfFacesContext.getCurrentInstance().isPartialRequest(facesContext);  
4:    }  

5.     Retrieving the request headers from within managed bean


     We can get the request headers from the bean using the following snippet


1:  FacesContext facesContext = FacesContext.getCurrentInstance();  
2:  ExternalContext externalContext = facesContext.getExternalContext();  
3:  Map requestHeaderMap = externalContext.getRequestHeaderMap();  


6.     Accessing request and response objects from a bean




1:  FacesContext facesContext = FacesContext.getCurrentInstance();  
2:  ExternalContext externalContext = facesContext.getExternalContext();  
3:  HttpServletResponse response = (HttpServletResponse)externalContext.getResponse();  
4:  HttpServletRequest request = (HttpServletRequest)facesContext.getExternalContext().getRequest(); 


7.     Putting and retrieving from session scope


     Quick ways to manage objects in session scope.


1:  ADFContext.getCurrent().getSessionScope().put("abc", abcValue);  
2:  ADFContext.getCurrent().getSessionScope().remove("abc");  
3:  ADFContext.getCurrent().getSessionScope().get("abc");  

8.     Adding partial targets at runtime



     We could add partial targets to components at runtime so that the property changes made in a bean method to a previously non target component reflects in UI.

1:  AdfFacesContext.getCurrentInstance().addPartialTarget(myComponent); 


9.     Adding JavaScript to response



     More often than not we might be required to trigger some external Javascript on click of a button. To achieve it we use the following code.

1:    public static void addScriptOnPartialRequest(String script) {  
2:      logger.fine("Adding Java Script " + script);  
3:      FacesContext context = FacesContext.getCurrentInstance();  
4:      if (AdfFacesContext.getCurrentInstance().isPartialRequest(context)) {  
5:        ExtendedRenderKitService erks = Service.getRenderKitService(context, ExtendedRenderKitService.class);  
6:        erks.addScript(context, script);  
7:      }  
8:    }  


10. Get the current Locale


     Snippet to get the current locale


1:  public static Locale getLocale() {  
2:  ADFContext adfctx = ADFContext.getCurrent();  
3:  return adfctx.getLocale();  
4:  }  



Tuesday, June 24, 2014

ADF : Handling browser back button

One of the most annoying side effects of doing a PPR request or matter of fact an AJAX request is the inability of the user to go back to previous transaction using browser back button. This is a common pitfall and there are number of ways to deal with it.


Case Study:
Lets assume we have 3 page fragments (jsff) in a bounded task flow and "main.jspx" where task flow is imported and a "launch.jspx" from which we trigger the new page with TF. When the user goes from step 1 to step 3 through step 2 and does a back button, the user is redirected to "launch.jspx" instead of "main.jspx" ( step 2)


Ways to handle browser back button

  1. Simplest - Avoid using bounded task flow ( Not recommended ) -  Now ! this may sound as a non - solution and to most part of it is correct ! but for specific user stories it could make sense. For example, in the above scenario we could use 3 different task flows for each of the fragments and use af:goLinks to navigate from one page to the other by keeping the data in session. This could be a solution when reusing task flow is not really a concern.
  2. Using session variable and servlet filter - We create a bounded task flow with session variable (currentStep = 0) as the input to each step, this is to track the user's current step. 
    • If the user is in step 3 then we set currentStep = 3 and set the value in session. 
    • When the user clicks on back button we check if the request is coming from "launch.jspx" and the currentStep != 0 then go to "main.jspx" with currentStep = currentStep  - 1
    • Once we have the Task Flow triggered through "main.jspx" - we check the value of currentStep  and show the user the requested fragment
  3. Using session variable and PagePhaseListener  ( Recommended )- We follow the same steps as above but instead of a filter we use a PagePhaseListener  to capture the back button request to "launch.jspx".
  4. There is an excellent article on "How To Handle Web Browser Buttons in ADF/WebCenter Applications" by Andrejus who provides an additional approach.

Preventing request caching on browser back button

One more catch with the above implementation logic is to get the request to come to server when user clicks on back button as browser tend to cache the resources.

To prevent it browser caching:


package com.example;  
 import javax.faces.context.FacesContext;  
 import javax.faces.event.PhaseEvent;  
 import javax.faces.event.PhaseId;  
 import javax.faces.event.PhaseListener;  
 import javax.servlet.http.HttpServletResponse;  
 public class PagePhasehaseListener implements PhaseListener  
 {  
   public PhaseId getPhaseId()  
   {  
     return PhaseId.RENDER_RESPONSE;  
   }  
   public void afterPhase(PhaseEvent event)  
   {  
   }  
   public void beforePhase(PhaseEvent event)  
   {  
     FacesContext facesContext = event.getFacesContext();  
     HttpServletResponse response = (HttpServletResponse) facesContext  
         .getExternalContext().getResponse();  
     response.addHeader("Pragma", "no-cache");  
     response.addHeader("Expires", "Wed, 1 Dec 2012 01:00:00 GMT");  
     response.addHeader("Cache-Control", "no-cache");  
     response.addHeader("Cache-Control", "no-store");  
     response.addHeader("Cache-Control", "must-revalidate");  
   }  
 }  

ADF: Optimize Read-Only Queries (for caching)

Consider you have a list of items which you show to the user regularly, be it in a table or a listOfValues or even for processing. With default setting of the view object you would have to fire as many queries as you have in database ( Duh ! )

So the default settings look like this:




With the above settings it will fetch "All the rows" in batches of 1 ( "As Needed" ). This largely affects the table scrolling as queries gets fired "As Needed" in batches of 1.

For caching purposes we should have "All Rows" queried "All at Once" - this will ensure we get all results into our view with just one query. Be careful though with the number of records you have in table - you might land up in "OutOfMemory" exception :)





Note: You might also want to play around with "in batches of" parameter to regulate the number of queries fired.