To render personalized or contextualized info in content areas it is important to have relevant shop context info available during CAE rendering. It will be most likely user session related info, that is available in the Commerce system only and must now be provided to the backend CAE. Examples are the user id of a logged in user, gender, the date the user was logged in the last time or the names of the customer segment groups the user belongs to, up to the info which campaign should be applied. Of course these are just examples and you can imagine much more. So it is important to have a framework in order to extend the transferred shop context information flexibly.

The relevant shop context will be transmitted to the CoreMedia CAE automatically as HTTP header parameters and can there be accessed for using it as "personalization filter". It is a big advantage of the dynamic rendering of a CoreMedia CAE that you can easily process this information at rendering time.

The transmission of the context will be done automatically. You do not have to take care of it. On the one end, at the commerce system, there is a context provider framework where the context info is gathered, packaged and then automatically transferred to the backend CAE. A default context provider is active and can be replaced or supplemented by your own ContextProvider implementation.

Implement a custom ContextProvider

To extend the shop context you have to supply implementations of the ContextProvider interface. The ContextProvider interface demands the implementation of a single method.

package com.coremedia.livecontext.connector.context;

import javax.servlet.http.HttpServletRequest;

public interface ContextProvider {

  /**
   * Add values to the given context.
   * @param contextBuilder the contextBuilder - the means to add entries to the entry
   * @param request - the current request, from which e.g. the session can be retrieved
   * @param environment - an environment, not further specified
   */
  void addToContext(ContextBuilder contextBuilder, HttpServletRequest request, Object environment);
}

      

Such implementations of the ContextProvider interface must be provided with the HCL Commerce workspace. This is typically done below the WebSphereCommerceServerExtensionsLogic directory of the your HCL Commerce project workspace. Such context provider implementations will use the HCL Commerce API to gather information from the current shop session. The current user id or all segment names the current user is member of are prominent examples of such context data.

There can be multiple ContextProvider instances chained. Each ContextProvider enriches the Context via the ContextBuilder. The resulting Context wraps a map of key value pairs. Both, keys and values have to be strings. That means if you have a more complex value, like a list, it is up to you to encode and decode it on the backend CAE side. Be aware that the parameter length can not be unlimited. Technically it is transferred via HTML headers and the size of HTML headers is limited by most HTTP servers.

Caution

As a rough upper limit you should not exceed 4k bytes for all parameters, as they will be transmitted via HTTP headers. You should also note that this data must be transmitted with each backend call.

All ContextProvider implementations are configured via the property com.coremedia.fragmentConnector.contextProvidersCSV in the file coremedia-connector.properties as a comma separated list. The configured ContextProvider instances are called each time a CMS fragment is requested from the CAE backend.

Read shop context values on the CAE side

On the backend CAE side the shop context values will be automatically provided via a Context API. You can access the context values during rendering via a Java API call.