Storefront advanced search now includes an attribute keyword filter and extended functionality:

• The filtered navigation configuration xml parser can parse keyword filters
• The FilterFactory can create AttributeKeywordFilter objects.
• The Solr Facet Adapter can generate query on AttributeKeywordFilters
• The Advanced Search controller handles keyword searching

Customer Segments are the functionality which enables customer to be grouped together. Once available, customer segments can then be used to outline conditions for delivering price lists, dynamic content and cart promotions. In Elastic Path Commerce, Customer Segment tags are used to determine whether or not a customer belongs to a segment and resulting in content, prices, or promotions to be delivered to the current customer in the storefront.

More information about this feature can be found in the 6.10.0 Documentation.

This adds the ability for a CSR to initiate a return of digital goods via the CM Client. The refactoring also adds server-side validation of returns to support future development of API-based CSR initiated returns and/or customer self-service returns.

Note that returns of subscription products are not included. Typically these would be done via the downstream subscription/billing system.

In order to support caches for both storefront and Cortex, a new pluggable Caching API was created in the ep-cache bundle. It supports the following capabilities:

1. Pluggable implementations, including JSR-107 caches and Ehcache with future support for distributed caches (e.g. memcached) envisioned.
2. Threadsafe operation with OpenJPA entities.
3. Pub/Sub cache invalidation (Future)

In an additional note, ep-cache is now the first module in Commerce Engine which uses mockito for unit tests instead of JMock.

The Payment Gateway API was enhanced to support ExternalAuth capabilities for payment-gateways.

The method getImportConfiguration() has been added to Import/Export's ImportController, allowing programatic access to the Import/Export configuration.

When using the Import/Export tool, the operator is now able to supply an external importexporttool.config file, so he does not have to invade the deployment to configure database and search server configuration. For example,

importexport.bat -e searchconfiguration.xml -p [filepath]\importexporttool.config

If the argument is not specified, then the default config file is used so it is backwards compatible.

The storefront Order History page, Order Confirmation (Receipt), and the Order Confirmation Email now display all tax details instead of a summary.

Previously, when an order was created, the new order is filled with details right away before it is saved to the context. So if anything goes wrong while filling in the order details, the created order can't be rolled back. The CreateNewOrderCheckoutAction was changed to split this into 2 steps, saving the order in the context for rollback action after the order is created but before details are filled.

This included adding capabilities to trigger event to the CM Client

For developers running tomcat from the command line via maven: where before you would have used mvn tomcat:run or mvn tomcat:run-war, you should now do mvn tomcat7:run or mvn tomcat7:run-war. The plugin configuration was also set to disable http-only cookies due to compatibility issues with DWR.

Automated end-to-end testing has been added to Import/Export. In particular, a Java process builder is used to run the Import/Export CLI and ensure it can be used successfully.

The EP Core Tool has had a new command added to update the Store URL:

set-store-url <storecode>=<url> 

ProductSku now has its own optional tax code field. If not set, the tax code is obtained from the parent product. The tax code inheritance now lives in a new TaxCodeRetriever service. The old get/setTaxCode methods on Product have been renamed to get/setTaxCodeOverride to more clearly convey the field's intended use and have also been added to ProductSku.

Additional fields have been added to ProductAssociationSearchCriteria to allow inclusion of Start Date and End Date in the query. The query building logic in ProductAssocationServiceImpl was extracted out into a separate class, ProductAssociationQueryBuilder.

When you view a product bundle with a multi-sku product constituent and the multi-sku constituents' default sku is not available for purchase, the entire bundle becomes unavailable for purchase even when the multi-sku constituent has other skus still available for purchase.

This premature marking of bundles as out of stock in this scenario was addressed by adding a step to the process of wrapping a product into a storeProduct. This extra step traverses a bundle's constituents and checks whether a product constituent's default sku is available. If it is not, then the product constituent's default sku is set to an available sku if one can be found.

Previously when a shipment is processed and has a zero-amount shipping cost, no tax journal entries are recorded for the shipping cost. These tax journal entries will now be craeted. Note that this applies to physical shipments but not electronic shipments, because electronic shipments are always free. This means there is different treatment for "zero-cost" shipping and an absence of shipping.

Previously, discounts applied to the shopping cart were stored in a private Map field in the cart. Applications such as Cortex may want to use this information, so the private Map of Maps was changed to be a new DiscountRecordContainer class, and this is exposed on the shopping cart via getDiscountRecordContainer().

Methods which read Product and ProductSku entities by immutable unique keys were moved from the ProductService and ProductSkuService to the new ProductLookup and ProductSkuLookup interfaces. These new lookups have the following characteristics:

1. To reduce confusion, both the ProductService and ProductLookup interfaces and ProductSkuService and ProductSkuLookup interfaces are completely disjoint. The services do not share any methods with the lookups.
2. Lookup interfaces do not support any FetchGroup or LoadTuner arguments. The expected contract is that an entity returned from a lookup will always be "fully loaded"

The following methods were moved from ProductService to ProductLookup:

The following methods were moved from ProductSkuService to ProductSkuLookup:

shoppingItem.getProductSku()
orderSku.getProductSku()

productSkuLookup.findByGuid(shoppingItem.getSkuGuid())
productSkuLookup.findByGuid(orderSku.getSkuGuid())

New Event Messages are published by Commerce Engine that will trigger email delivery:

• Commerce Manager User Events
  • CM User created
  • CM User password changed
  • CM User password reset
• Customer Events
  • Anonymous Customer registered
  • Customer registered
  • Customer password changed
  • Customer password forgotten
  • Wish List shared
• Data Import Events
  • Import job completed
• Gift Certificate Events
  • Gift Certificate purchased
• Order Events
  • Order exchanged
  • Order shipment created
  • Order shipment release failure
  • Order shipment shipped
  • Order returned

Solr was upgraded from version 1.4.1 to 4.5.1. This resolves problems that some customer have encountered with replication of large indexes, fuzzy matching, as well as various other Solr bugs, including:

• SOLR-309: A solr.StrField that has analyzers configured should emit warning to log
• SOLR-1846: Remove support for (broken) abortOnConfigurationError
• SOLR-2591: Remove commitLockTimeout option from solrconfig.xml
• SOLR-5227: attempting to configured a dynamicField as required, or using a default value, should fail.
• SOLR-2015: add a config hook for autoGeneratePhraseQueries\
• SOLR-1261: Lucene trunk renamed RangeQuery & Co to TermRangeQuery
• LUCENE-995: Add open ended range query syntax to QueryParser
• LUCENE-4024: FuzzyQuery should never do edit distance > 2
• LUCENE-2458: queryparser makes all CJK queries phrase queries regardless of analyzer

If you have made customizations to any of the index schema files, solr indexing code or querying code you should review the out-of-the-box changes made in these areas to see if similar changes will be required for your customizations.

OpenJPA was upgraded from version 1.2.1 to 2.3.0. This means we now support the JPA 2.0 standard for persistence. Some changes made to support this:

• No private setters
• • A handful of classes had property setter methods marked as private. JPA 2.0 doesn't support this for persistent fields so the setters were changed to protected
• Non-standard Join syntax
• • We previously used a non-standard join syntax for joins to TLOCALIZEDPROPERTIES. This is no-longer supported, and has been replaced by use of the @ElementClassCriteria annotation
• Persistence Entity Listeners
  • The old PersistenceEngineEntityListener which was attached to the PersistenceEngine has been replaced by two separate listener interfaces. OpenJPA LifecycleListeners can now be added to the EntityManagerFactory via the spring context. The EntityManagerFactory takes responsibility for attaching these listeners to each EntityManager created by the factory at creation time. This means that OpenJPA Lifecycle listeners now receive all lifecycle events exposed by OpenJPA.
  • The PersistenceEngine specific events in PersistenceEngineEntityListener have been moved to PersistenceEngineOperationListener. These events were only used by the AuditEntityListener. PersistenceEngineOperationListeners are attached directly to the PersistenceEngine singleton. Of course, individual listeners like AuditEntityListener are free to listen to both sets of events, but are not required to do so.
• ORM file changes
• • The *-orm.xml files have been changed to update the persistence schema version as well as removing the <package> and <entity> elements - basically they now only hold the named queries. Customers no longer need to duplicate the file and suppress the OOTB version in order to override entity persistence annotations - they can just introduce a new file with their entity definitions. The OOTB orm files only need to be duplicated and changed if OOTB named queries are being replaced.
• jpa-persistence.xml changes
• • Customers overriding the jpa-persistence.xml need to ensure that the following properties are present:
  • <property name="openjpa.jdbc.FinderCache" value="false”/>
  • <property name="openjpa.Compatibility" value="convertPositionalParametersToNamed=true,ignoreDetachedStateFieldForProxySerialization=true"/commerce-legacy/> <property name="openjpa.MetaDataRepository" value="Preload=true”/>
  • The schema version has been updated to 2.0
  • In a new or overriding jpa-persistence.xml file you may also need to include the following element to ensure JSR-303 validation is not performed during persistence: <validation-mode>NONE</validation-mode>

Previously, multi-valued attribute data became corrupted if the values contained a comma because delimitting of these attributes were handled by manually calling StringUtils.split() or split() on a comma..

There are now 2 formats of encoding and decoding of multi-value attribute:

1) RFC-4180 compliant encoding using SuperCSV 2.1 library (link).

Note: SuperCSV is our candidate encoder because it is licensed under Apache v2 and it has a release. We did not use Opencsv because it is not fully RFC compliant and it returns the entire row as the first element when parsing.

2) Legacy encoding (delimit on commas) for existing multi-valued attribute data

The reason for having legacy encoding is that the legacy data are not properly formatted and may result in data corruption.

For example, consider the encoded string,

3" DVD-R, 3" DVD-L

RFC-complaint encoding will treat the double-quotes as escape characters. The result after decoding is,

{ "3 DVD-R, 3 DVD-L" } a list of 1 element

Thus, the "multi-valueness" of an attribute is no longer a boolean state, but of three modes: 1) a single-value; 2) legacy encoded; 3) rfc-4180 encoded.

All existing data is kept in legacy encoding. All newly created attributes will be in RFC 4180 encoding.

The method changeFromAnonymousToRegisteredCustomer(CustomerSession customerSession, Customer customer, String storeCode) has been added to CustomerSessionService. This will change the Customer associated with the session to a new registered Customer, create a new Shopper and handle updates (such as merging ShoppingCarts and WishLists and updating the CustomerSession. This functionality was previously spread across private methods.

Two new methods have been added to ProductAssociationService:

• findByCriteria(ProductAssociationSearchCriteria criteria, int startIndex, int maxResults) - Searches the product associations by given search criteria, at the starting index with a result limit
• findCountForCriteria(ProductAssociationSearchCriteria criteria) - Finds the count of product associations by the given search criteria.

Validation logic that was previously within private methods in the shopping cart has been moved to new methods on the appropriate services:

• RuleService. isRuleValid(Rule rule, String storeCode) will check if the given rule is valid in the given store
• CouponUsageService. isValidCouponUsage(String customerEmailAddress, String couponCode) will check that the coupon usage is valid for the given coupon code and email address

A new method reApplyCatalogPromotions has been added to CartDirectorService that re-applies the catalog promotions to the ShoppingCart so that the applied rules are tracked on the cart.

The Money interface and MoneyFactory class have been replaced with a single Money implementation. This implementation is final, and contains factory methods that can be used to create new Monies, making it analogous to core JRE datatypes such as BigDecimal or Long. As with the core JRE datatypes, a correct Money implementation is critical to the correct functioning of Commerce Engine and therefore it should not be possible nor necessary to replace this object with a different implementation.

As a result of this change it is no longer possible to create or encounter Monies in invalid states (ie. missing a currency or amount), and therefore it should be more difficult to introduce bugs. Any defects or shortcomings with the Money implementation should be reported and remedied in the platform.

A CustomerRegistrationService was added which houses customer registration related logic. This currently has two methods:

• registerAnonymousCustomer(Customer) - Performs field validation on the customer, and updates it to registered status and sends a confirmation email. Systems using Commerce Engine will no longer have to do these operations separately by calling into different services, making integration less brittle. Returns a CustomerRegistrationResult object which holds any field constraint violations that were found during validation, as well as the updated Customer object.
• registerCustomerAndSendPassword(Customer) - was moved from CustomerService to this new service. This method is currently used by Commerce Manager Client only.

The domain class CustomerImpl was invoking service methods on AttributeService and CustomerService to load metadata and settings values respectively. These values were lazy loaded at run-time when setters were invoked.

This has several problems:

• It makes CustomerImpl make unexpected calls to the service/persistence layer at run time. This is made worse by the fact that CustomerImpl can be serialized to the Commerce Manager Client.
• Invoking reads in the middle of a transaction can cause unexpected flushes of partially changed objects
• CustomerImpl requires static access to the ElasticPath singleton and the bean factory.
• Calling services from domain objects is not best practice.

This change does three main things:

• It adds a generic OpenJPA post-load listener to the EntityManagerFactory. This post-load listener handles distribution of PostLoad events to PostLoadStrategies, configured with spring. The new listener provides a place to hang spring-configured post load handlers.
• It removes the calls in CustomerImpl which lazy-loaded data from the AttributeService and CustomerService. Instead, CustomerImpl objects are eagerly loaded with all the configuration they require to execute properly. Existing CustomerImpl instances retrieved from the database have their metadata populated with a PostLoadStrategy. New CustomerImpl instances created by the spring bean factory have their metadata populated from spring.
• It removes CustomerProfileImpl and CustomerProfileValueImpl from the bean factory. Extension projects can still override these classes if they need to by overriding protected factory methods in CustomerImpl and CustomerProfileImpl respectively.

Logging of applied rule codes & checksums during order creation has been changed from being at level INFO to level TRACE.

A transient field has been added to ShippingServiceLevel to record any applied promotion Rule ids. The ShoppingCart.fireRules() lifecycle governs the lifecycle of the applied promotions on a ShippingServiceLevel. The following two methods were added to ShippingServiceLevel:

• void recordAppliedRule(long ruleId, long actionId, Money discountAmount);
• Set<Long> getAppliedRules();

In order to be able display promotion information that was captured at the time of purchase (e.g. for Cortex) we need to save the display name (in the shopper's locale at the time of purchase), and the description into TAPPLIEDRULE. In addition, to retrieve a promotion applied to a purchase an Applied Rule must be distinguishable from other Applied Rules so a Guid has been added to AppliedRule (and consequently to the TAPPLIEDRULE table).h3.

• New table TTAXJOURNAL was added.
• TAX_DOCUMENT_ID column was added to TORDERSHIPMENT and TORDERRETURN
• SHIPPING_TAX column was added to TORDERRETURN
• New table TCARTORDERCOUPON was added
• TCUSTOMERGROUP table had the columns DESCRIPTION and ENABLED added
• New Customer Segment tags were added: new data in TTAGVALUETYPE, TTAGVALUETYPEOPERATOR, TTAGDEFINITION, TLOCALIZEDPROPERTIES, TTAGDICTIONARYTAGDEFINITION tables
• TCARTITEM and TORDERSKU tables both had the column SKU_GUID added as a non-nullable foreign key to TPRODUCTSKU. The value is automatically computed in the Liquibase script.
• TCARTITEM and TORDERSKU tables both had the SKU_UID column removed
• A GUID column was added to TCATEGORY. For upgrades, liquibase will automatically populate this with "master category code|catalog code" which was previously the "effective" guid.
• A PARENT_CATEGORY_GUID column was added to TCATEGORY. For upgrades, Liquibase finds the category linked to by the PARENT_CATEGORY_UID and puts its GUID in the new field
• After the above change, the PARENT_CATEGORY_UID column was dropped from TCATEGORY
• A TAX_CODE_UID column was added to TPRODUCTSKU
• Columns RULE_DESCRIPTION, RULE_DISPLAY_NAME and GUID were added to TAPPLIEDRULE.

The following Setting definitions were added to the database via Liquibase:

Setting Definitions and Values with a path starting with "COMMERCE/SYSTEM/ASYNC" were removed as they are not used.

• ImageService was moved from ep-core to ep-common-web
• Shopping Cart Refresh functionality was moved from storefront to core.
• getWebInfPath() was removed from ElasticPath/ElasticPathImpl. You should now use getConfigurationRootPath() on EnvironmentInfoService.
• All *-cucumber-tests modules have been renamed *-acceptance-tests to better reflect what they are

• Refactored Customer Tagging logic into reusable modules
• Extracted PriceListStack setup logic from WebCustomerSessionService
• The Product Association type constants on ProductAssociation have been removed, and a ProductAssociationType extensible enum is now used instead.
• Payment Handlers now throw a consistent error message if an authorization is attempted for a zero amount
• Coupon validation logic has been moved into a ValidCouponUseSpecification class.
• Coupon auto-apply logic has been moved into a CouponAutoApplierService class.
• PaymentType was changed to be an extensible enum.
• Incorrectly spelled method setResour eDirectory in EsapiSecurityConfig was renamed to setResourceDirectory
• Previously in checkout.xml , abstractCheckoutServiceDelegate had three properties for defining the checkout actions to run. Only the reversibleActionList property was a reference value. The other two checkout actions list are now also reference values. This enables extension projects to override the list beans to define their own checkout actions for setupCheckoutActions and finalizeCheckoutActions.

• Removed fncLoader from ElasticPathImpl
• Removed ctxEp from velocity
• Removed unused getAllRegions method from ShippingRegionService
• Removed DST dependency on ElasticPathImpl
• AsyncService was unused and has been removed.
• MessageSource was removed from ElasticPath & ElasticPathImpl. Classes requiring this can just have coreMessageSource injected or get it from the bean factory.
• The EpService interface and AbstractEpServiceImpl class were removed. Classes that used this to get access to ElasticPath for bean creation now use an injected BeanFactory instead.
• Removed unused methods getCountry() and setCountry() from ShoppingCartDto
• Removed unused methods getElasticPath() and setElasticPath() from EventOriginatorHelper.