CoreMedia Digital Experience Platform 8 Developer Manual, Version 7.5.45-10
Chapter 5. IBM WebSphere Commerce Integration | 5.4. Connecting with an IBM WCS Shop

To connect your Blueprint web applications with an IBM Commerce Store, you configure a connection on the CMS side. The connection to the IBM WebSphere Commerce system contains two parts:

	Note
	Prerequisite Before you can connect the CoreMedia system with the WCS you need to deploy the CoreMedia extensions into your WCS system as described in Section 3.4, “Customizing IBM WebSphere Commerce”.

Spring Configuration

The information on how to connect to the IBM WCS system is configured in the filesystem of the web applications that use the e-Commerce API. These web applications are at least the Studio web application (workspace module studio-webapp) and the CAE applications for delivery (workspace modules cae-preview-webapp and cae-live-webapp).

The application.properties file below the WEB-INF directory of your web application contains the IBM WCS related configuration properties. Example 5.4, “IBM WCS configuration in application.properties” shows the relevant parts of the file. The meaning of the values ​will be explained in the table below.

###############################################################################
# CoreMedia LiveContext Configuration
###############################################################################

livecontext.ibm.wcs.url= http://wcs-server.yourdomain.com
livecontext.ibm.wcs.secureUrl= https://wcs-server.yourdomain.com
livecontext.ibm.wcs.rest.url= ${livecontext.ibm.wcs.url}/wcs/resources/store
livecontext.ibm.wcs.rest.secureUrl= ${livecontext.ibm.wcs.secureUrl}/wcs/resources/store
livecontext.ibm.wcs.store.url= ${livecontext.ibm.wcs.url}/wcsstore/Aurora
livecontext.service.credentials.username= <wcs_username>
livecontext.service.credentials.password= <wcs_password>
livecontext.managementtool.web.url= ${livecontext.ibm.wcs.secureUrl}/lobtools/cmc/ManagementCenterMain

The exact store configuration depends on your store configuration in your IBM WCS environment. The store specific properties that logically define a shop instance can also be part of the Spring configuration. The following listing gives an example.

<util:map id="myStoreConfig">
  <entry key="store.id" value="${my.wcs.store.id}"/>
  <entry key="store.name" value="${my.wcs.store.name}"/>
  <entry key="catalog.id" value="${my.wcs.catalog.id}"/>
  <entry key="currency" value="${my.wcs.store.currency}"/>
  <entry key="dynamicPricing.enabled" value="${my.wcs.store.dynamicPricing.enabled}"/>
</util:map>

<customize:append id="ibmStoreConfigurationsCustomizer" bean="ibmStoreConfigurations">
  <map>
    <entry key="myStore" value-ref="myStoreConfig"/>
  </map>
</customize:append>

The example makes use of Spring placeholder tokens that are mapped in the properties file mentioned above. It also shows how to add the custom store configuration to the existing ibmStoreConfigurations map. Later this store configuration (myStore) can be referenced from the site configuration settings within the content. Individual values can be overwritten in the content again.

Alternatively to a catalog.id it is also possible to use the catalog name within a catalog.name property instead. It will be mapped to the current catalog.id at runtime. When the catalog id is not given in configuration the id from the default catalog will be automatically used.

The same function is also available for the store ID. In case a store ID is not given it can also be retrieved from the IBM WCS but a given config value for store.id takes precedence.

Content Settings

Each site can have one single shop configuration (see the Blueprint site concept). That means only shop items from exactly that shop instance (with a particular view to the product catalog) can be interwoven to the content elements of that site.

At least the config.id must be configured for the site root page (see the Local Settings tab) within a struct property named livecontext.store.config. This config.id maps to a named store configuration mentioned above (configured via Spring). The Spring configuration itself provides all other connection relevant values.

All other store configuration settings, like the store.id will be taken from the Spring configuration. But it is also supported to overwrite such settings within the content settings.

	Note
	The concrete store related IDs (store.id and catalog.id) can also be dynamically retrieved from the IBM WCS. As long as a store.name and catalog.name value is available in the configuration (Spring or content settings) the corresponding IDs will be retrieved dynamically.

Redefine the Currency

A popular example would be the usage of a base configuration in Spring referenced by the config.id but with the variation of the locale and currency for each site (default currency of myStore is USD).

	Note
	Be aware, that the locale is also part of each shop context. It is defined by the locale of the site. That means all localized product texts and descriptions have the same language as the site in which they are included and one specific currency.

Enabling Dynamic Pricing

Dynamic price rendering is disabled by default. If this feature is not used on IBM WCS side then it is not necessary to turn it on on CMS side. It avoids an additional call to IBM WCS that is not needed in such a scenario.

But if you use personalized price rules in IBM WCS then it is necessary to switch this feature on. For price rules on contract bases (where the prices are the same for all members of the group) you do not necessarily need to enable this feature.

Please see Section 5.4, “Connecting with an IBM WCS Shop” to get the information how the dynamic prices can be switched on on IBM WCS side.

Tenant specific Configuration

Per default only one IBM WebSphere Commerce Server Management Center system can be configured per Content Application Engine. If you want to connect to different IBM WebSphere Commerce Server Management Center hosts per site for example (dev, staging), you need to duplicate all URL configuration properties the hostname is part of via Spring. Since this would multiply the amount of your configuration properties, LiveContext 2 provides a mechanism to replace placeholder tokens within your configured URLs etc. with values defined in the current StoreContext at runtime.

For example within the component-lc-ecommerce-ibm.properties the following is defined:

livecontext.ibm.wcs.url=http://${livecontext.ibm.wcs.host}
livecontext.ibm.wcs.rest.path=/wcs/resources
livecontext.ibm.wcs.rest.url=${livecontext.ibm.wcs.url}${livecontext.ibm.wcs.rest.path}

Instead of the global host configuration you want to connect different IBM WebSphere Commerce Server Management Center environments per site:

livecontext.ibm.wcs.url=http://{livecontext.ibm.wcs.host}
livecontext.ibm.wcs.rest.path=/wcs/resources
livecontext.ibm.wcs.rest.url=${livecontext.ibm.wcs.url}${livecontext.ibm.wcs.rest.path}

You need to add the following to your site specific store configuration:

 <util:map id="auroraStoreConfigDev">
  ...
  <entry key="livecontext.ibm.wcs.host" value="myhost"/>
</util:map>

After doing that the URL token will be replaced with the values of you current store configuration at runtime: livecontext.ibm.wcs.rest.url >> http://myhost/wcs/resources

The configuration keys must exactly match with the token defined in your URL configuration. If you add custom properties make sure to use the replacement mechanism CommercePropertyHelper:

public String getCustomWcsUrl() {
  return CommercePropertyHelper.replaceTokens(customWcsUrl, StoreContextHelper.getCurrentContext());
}