Extend WebSphere Commerce with xC extension points

For some parts of WebSphere Commerce, we can write extension code to extend WebSphere Commerce controller or task commands. You create extension code in the development environment.

Overview

The term xC stands for externalized customization; customizations that are external to the default WebSphere Commerce platform logic. The default WebSphere Commerce code runs on the Transaction server, whereas our custom xC code runs on the Customization server. By isolating our custom code, we can easily and frequently upgrade without worrying about IBM overwriting your code.

IBM provides xC extension points in some WebSphere Commerce controller commands or task commands in the WebSphere Commerce Transaction server. We can configure these extension points to run your extension code. Extension code is the custom business logic created. Extension points are an optional approach for customizing WebSphere Commerce. IBM recommends that you leverage the xC model to implement simple customizations using the provided extension points. In some cases, using extension points can be easier to implement than directly customizing a framework or subsystem. For example, IBM provides extension points that make it easy to integrate WebSphere Commerce with an external tax system or external payment system.

To implement extension code, you need to implement a REST API in the Customization server, which follows the input/output specifications of the xC extension point. After you implement extension code, you need to register the code in the WebSphere Commerce database so that the WebSphere Commerce command framework is aware of existing extension code. When a command is called, WebSphere Commerce checks whether any extension code is assigned to the extension point. If yes, the Transaction server calls out to the Customization server to execute our custom logic. We can configure your extension code to run before (preUE), as a replacement for (replaceUE), or after an existing command (postUE). We can browse the following section to see if any extension points suit our customization requirements, xC extension points.

Note: WebSphere Commerce Version 9 supports both the traditional customization model and xC customization model at the same time, but it is not recommended using the two customization models in a single WebSphere Commerce customization. Trying to use both models increases the complexity in architecture and programming and defeats the purpose of xC separation. For example, the extension point order_item_add_pre supports customizing the order flow to complete an action before an item is added to the cart. But since the extension point cannot access the database, it is not recommended that you customize the OrderItemAdd command to query an external database table and pass to the User Exit (UE) for processing. For more information about developing using the traditional customization model (local model), see Customizing WebSphere Commerce.

• Assigning extension code to extension points
  After you develop xC extension code, we must register your extension code within the WebSphere Commerce database and assign extension code to extension points.

• Adding access control to extensions
  We can associate an extension point with an access control action. We can configure WebSphere Commerce to check whether the current user can perform the action before the extension code is invoked, and pass the result to the extension code through the access control context.

• xC extension points
  To develop logic for integrations with WebSphere Commerce, we can use xC extension points. The extension points enable you to extend the classes for some commands.