CoreMedia Digital Experience Platform 8 Developer Manual, Version 7.5.45-10
5.1. Commerce-led Integration Scenario | 5.1.3. Extending the Shop Context in Commerce-led Integration Scenario

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 IBM WCS shop only and must now be provided to the back-end CAE. Examples are the user id of a logged in user, gender, the date he was logged in the last time or the names of target groups he 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 IBM WebSphere Commerce System, there is a context provider framework where the context info is gathered, packaged and then automatically transferred to the back-end CAE. A default context provider is active and can be replaced or supplemented by our own ContextProvider implementation.

Implement a custom ContextProvider

Let's imagine you have to implement a new ContextProvider that will extend the shop context. It should be possible to apply it for all available content slots or only for a certain one because of its supposed exceptional specialty.

First, you write a class that implements 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);
}

      

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 back-end 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. As a rough upper limit you should not exceed 4k bytes for all parameters. You should also note that this data must be transmitted with each back-end call.

	Caution
	As a rough upper limit you should not exceed 4k bytes for all parameters, as they will be transmitted via HTTP headers.

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 back-end.

Read shop context values

On the back-end 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.

import com.coremedia.livecontext.fragment.links.context.Context;
import com.coremedia.livecontext.fragment.links.context.LiveContextContextHelper;

import javax.servlet.http.HttpServletRequest;

public class FragmentAccessExample {
...
  private LiveContextContextAccessor fragmentContextAccessor;

  public void buildContextHttpServletRequest request(){
    fragmentContextAccessor.openAccessToContext(request);
  }

  public String getUserIdFromRequest(HttpServletRequest request){
    Context context = LiveContextContextHelper.fetchContext(request);
    return (String) context.get("wc.user.id");
  }
...
}