Introduction

cXML Order Injection is a B2B feature that describes the receiving and processing of a cXML order request, generally sent from a procurement system. After receiving a cXML file, it is parsed, a basket is created with certain values from the cXML file, and an order is created.

References

• Concept - Order Creation | Basic Handler Chain Framework
• Cookbook - cXML Order Injection
• Cookbook - cXML Punchout
• Concept - UserPreference Table
• Concept - Dependency Injection and ObjectGraphs

Glossary

cXML is a standard for Punchout similar to OCI. Besides the Punchout to an external B2B store, it also supports order injection with basket data.

General Concept

This feature is very flexible and will most likely be implemented differently in every project. Therefore, one of the main goals for this implementation was the exchangeability and extensibility of the provided functionality. To achieve this, the handler chain framework has been chosen. This allows projects to easily extend, replace, or remove standard functionality.

Before the handler chain is being executed, ICM receives the cXML content via a pipeline call and tries to determine the version of the cXML file evaluating the cXML DOCTYPE tag. If the version cannot be determined, the registered default handler chain will be used, in standard case the CXMLOrderInjectionChainV2. The handler chain manages everything else, like unmarshalling the provided cXML, checking user credentials, creating a basket, mapping different values to the basket, and finally creating the order. In any case, a response will be sent, either including a success message or some information about any problems that occurred, based on the cXML Standard.

Handler Chain

There are two main chains implemented in the standard implementation and several handlers. Some of the handlers are version-independent, and some work with version-specific classes. This can be differentiated by the package name. Version-independent handlers can easily be reused in a different chain for a new version.

The first is PreCXMLOrderInjectionChainV2. It handles all kinds of preparation to place the order later. Currently (7.10.31) implemented handlers are:

The second chain CreateOrderCXMLOrderInjectionChainV2 creates the actual order and has only one handler:

Versioning

The cXML order injection feature released with 7.10.31 is based and tested on cXML Version 1.2.049. In ICM, the implemented cXML feature is referred to as V2.

Other minor cXML versions will most likely work with V2 as well but that has not been tested.

If another feature version is needed, this can be done by implementing a new handler chain for the according version and registering it via Guice. Please refer to Cookbook - cXML Order Injection | Recipe: How To Support Another Version of cXML.

Testing

https://punchoutcommerce.com/tools/cxml-order-tester offers a testing tool for your environment.

If your environment is only available internally, you can follow Cookbook - cXML Order Injection | Recipe: How To Test My System.

Configurable Unit Mapping

This section describes how certain values can be configured. Since order injection does not handle localized text, this description relates only to the unit mapping configuration.

A new database table "UserPreference" was introduced to store user-specific cXML configuration data such as the unit mapping (UOM code mapping) and the export locale.

The unit mapping converts procurement system units (usually UOM codes) like BX (box) or PC (piece) to units that are maintained as product packing unit in the ICM and vice versa. This is necessary because procurement systems usually only support UOM codes and the product unit in the ICM does not have to follow any standard. It could also be that different procurement systems support a different set of UOM codes. Since the settings are user-specific, multiple cXML users with individual mappings can support multiple procurement systems.

It is also possible to store a global configuration for unit mapping and the export locale in properties which will be overruled by user-specific settings, if they exist.

The CXMLPunchoutConfigurationProvider

This provider is used to supply the configurations for the global or user-specific locale and the unit mapping. It is used for both, the cXML Punchout basket and the cXML order injection.

The provider currently has two methods:

Map<String, String> getUnitMappings(UserBO userBO); 
LocaleInformation getPunchoutLocale(UserBO userBO);

Both retrieve the configuration from a hierarchy. The details are described in the next chapters for locale and unit mapping.

In case the hierarchy logic or the source of the configuration must be different in a customized project, it can be replaced.

This can be done by implementing your own customCXMLPunchoutConfigurationProviderImpl and using Concept - Dependency Injection and ObjectGraphs to wire it to the interface.

Locale for Product Texts

The locale configuration is used for localized product texts when transferring the Punchout basket.

A "global" configuration can be defined by creating a property with the key intershop.cxml.punchout.locale. It is also possible to create a preference in table UserPreferences with name punchout.locale and group cxml to define a user-specific configuration.

Hierarchy

The hierarchy or priority for the locale is as follows:

1. The user-specific preference stored with the given user.

2. The 'global' configuration stored in a property, read via ConfigurationMgr.

3. The locale stored for the current application.

4. The system-wide lead locale.

Unit Mapping

The unit mapping is used for both, Punchout and order injection.

Global Mapping Configurations

It is possible to create a property with key prefix intershop.cxml.unitmapping to define "global" mapping configurations.

Example: intershop.cxml.unitmapping.EA=pcs or intershop.cxml.unitmapping.BX=Box etc.

User-Specific Mapping Configurations

It is also possible to create a preference in table UserPreferences with name unitmapping and group cxml to define a user-specific mapping configuration.
Here the configuration data is expected to be stored in one line. 

The key and values are separated by a ';', the different groups(key-value-pairs) are separated by a '\t' tabulator character.

Example stringValue: EACH;pcs   BOX;box   DOZ;DOZEN

Key and Value - Unit Explained

The left-hand side of the configuration aka 'key' are the units in the procurement system.

The right part aka 'value' is the unit available in the ICM.

Example mapping:

• For the cXML Punchout process the mapping happens from value to key configuration (ICM to calling procurement system).
• For the Order Injection process the mapping happens from key to value configuration (order injecting procurement system to ICM).

Default Key or Value

If the value for the unit is not available, default values for the key and the value can be defined, see Cookbook - cXML | Recipe: Add Default Custom Unit Mappings. 

This means, for example, that if no unit is defined for a product, the default configuration is used instead, if available.

Hierarchy

The final unit mapping used in the REST calls can come from user-specific preference configurations, from a global property configuration and/or a combination of both.

The hierarchy or priority for the unit-mapping is as follows:

1. The user-specific preference stored with the given user.
   It overwrites/replaces any already existing global values and adds non-existing user configurations.

2. The 'global' configuration stored in properties, read via ConfigurationMgr.

Examples:

There are basically three different possibilities for configuration:

• A global configuration where some user-specific configurations are replaced
• Exclusive use of user-specific configuration
• Exclusive use of global configuration