What's new for developers

This section describes the new additions and changes within only the initial WebSphere Commerce Version 9.0.0.0 release. For more information about new additions and changes for WebSphere Commerce Version 9 available through update packages, see:

For more information about update packages, including how WebSphere Commerce releases update packages, see Maintenance.

WebSphere Commerce Version 9 employs a modern technology stack for developers to make customization of the brand and business user experience more efficient and cost effective. The use of JQuery and JPA technologies helps development teams deliver custom code or implement integrations faster. Runtime RESTful APIs can wrap existing logic with customized logic so that developers can extend (or further enhance) the default capabilities without having to learn the implementation behind these features. These improvements decrease the time required to learn how to customize WebSphere Commerce .

Additionally, the externalized customizations (xC) programming model makes it possible to separate integration logic from business logic so it is easier to maintain customizations and use IBM provided enhancements.


WebSphere Commerce Developer

Get a quick start on developing the WebSphere Commerce storefronts with WebSphere Commerce Developer Enterprise or Professional.

Learn more...


Distributed servers

WebSphere Commerce is modularizing into loosely coupled components. In this release, the Store server and Search server are decoupled from the larger WebSphere Commerce server, now called the Transaction server. This separation is along well-defined service interfaces that allow for better horizontal scaling of your e-commerce system. WebSphere Commerce Version 9 evolves the traditional architecture into a microservices architecture with separate servers as Docker images. In this version, the Transaction Server is separated into five major functional servers:

The separation of servers allows developers to work in parallel with fewer dependencies.

Learn more...


Externalized Customization (xC)

Externalized customization is a new programming pattern that introduces a separation between the core application components and our customizations. By using this new pattern WebSphere Commerce can deliver innovation more quickly. More importantly, the new programming pattern allows us to deploy innovation more quickly. Developers create customization code external to WebSphere Commerce. When the business logic is called that you customized, there is a reference to fetch the customized instruction instead of running the IBM provided code. This isolation of customization also improves security, and the stability of your application, the e-commerce store.

Extending WebSphere Commerce with xC extension points


WebSphere Commerce Search

The architectural changes in WebSphere Commerce Version 9 mean that most Search services run in a dedicated Docker container, while a few functions are still done in the Transaction server. Because you have one development workspace for all containers, we can assemble and test all your code in one place. However it is important to know where the code will run once the Docker containers are assembled.
  • Inside the Search Docker container
    • Search service EAR

    • Configuration customizations

    • Managed Solr core configurations, including the solrconfig.xml, schema.xml, and wc-data-config.xml files

    • Runtime configuration, including the wc-component.xml and wc-search.xml files

    • The WebSphere Liberty profile

  • Outside the Search Docker container
    • Index data

    • Preprocess configurations, which reside inside the Transaction server

    • Utilities. Functions such as setting up the Search index were managed in previous releases by command-line utilities (for instance, SetupSearchIndex.sh). You now control these services using REST calls

This architecture is designed to make developing and managing Search much faster and easier. In terms of features, the most significant change in WebSphere Commerce Version 9 is that we can now add custom postprocessing commands to existing REST services. This ability replaces the BOD/data bean based approach of previous releases with a single, consistent control point for our custom code. We can add custom index fields, as described in Adding custom index fields in REST responses.

In addition, we can now add our own request handlers easily. With these changes, REST becomes the default interface for Search control, configuration, customization and extensions.

Search customization for server containers


Enterprise JavaBeans to the Java Persistence API

All WebSphere Commerce data beans now follow Java Persistence API. By moving from EJB to JPA, WebSphere Commerce can use a lighter web container. WebSphere Liberty replaces WebSphere Application Server for the Store, Search and Customization servers. The use of the Data Service Layer (DSL) is deprecated, use JPA entities instead.

If we created custom EJB beans, convert from EJB to JPA using the migration tool. See Migrating WebSphere Commerce Version 8 EJB entity beans to Java Persistence API.

In WebSphere Commerce Version 9, the EJB session bean is upgraded to 3.x. You do not need to migrate stateless session EJB beans to JPA.

Java Persistence API.


Db2 version 11

In previous versions, support was provided for the Derby database within the development environment. In WebSphere Commerce Version 9, both the development environment and the runtime environment support Db2 version 11.

Installing the IBM Db2 database.

(Oracle)

Oracle version 12c Release 2

In WebSphere Commerce Version 9, both the development environment and the runtime environment support Oracle 12c Release 2.

Install and configure Oracle 12c Release 2 database.


Aurora starter store

The Aurora starter store is rewritten to use JQuery. In addition to all the existing features that are supported in the Dojo version of the Aurora starter store, the jQuery version supports the following additional capabilities:

  • Store pages load a minimal number of JavaScript and CSS files, as a build script is provided that merges the code from all the files and then generates fewer files, with all its contents combined and minified. This performance strategy improves the web browser's page load time for store pages.

  • A store function is available to control whether dynamic E-Marketing Spots are loaded either server-side with the page, or loaded after the initial page load is complete, to better support Content Delivery Network (CDN) caching.

  • Interactions in the category page are implemented using full page loads, rather than using AJAX. This strategy simplifies page coding and removes the complexity of handling the web browser's back, forward, and bookmark features.

In WebSphere Commerce Version 9 the Store server uses the Rest tag to retrieve data. In previous versions, the getData tag was used.

The Store server uses Spring MVC, instead of Struts. See Spring MVC and store controller customization.

jQuery Aurora starter store.


Related concepts
What's new in WebSphere Commerce Version 9.0.1.x