The Problem

A common theme with the deployments I have worked on have been performance issues:

• Backoffice Crashes
• Storefront Crashes
• Customer Transaction Timeouts

The Approach

A mixture of tools where used to diagnose the issues in production, replicate them in the lower systems and then design, implement and test improvements:

• New Relic, Dynatrace: Examine Infrastructure and JVM health (CPU, Memory, GC) to narrow down issues and trace transactions
• GNU Debugger, JStack, JMAP: Take core dumps of running processes to minimise impact to production and perform offline analysis of the Stack traces and Heap usage to find which objects (often xxxData or xxxModel) are persisting in survivor space.

The Outcome

Poor custom implementations found that were executing very Large SQL statements due to poor use of Flexible Search Restrictions, retrieving too many Models from the database and/or over-populating Data objects. Designed configurable populators to avoid these issues, optimised the Flexible Search restrictions and made better use of DAOs to only retrieve the necessary data. Overall transaction response times reduced, backoffice meeting close to 100% uptime rather than daily crashes and CPU alerts from the storefront nodes stopped.

The Problem

Another common theme is poor implementation of Search:

• Using a single template across site Search, Auto Suggestions, Menus etc.
• Poor tuning of Free Text Search

The Approach

Created search templates specific for use-case, e.g. a lightweight search template for auto suggestions

Work with business users to explain the impact of FTS settings and tune as approriate, e.g. in product codes with letters and numbers stored as text explain the impact of the SOLR filters combined with fuzzy matching to explain on the high level of irrelevant results. Explain the impact of the Stemming filters which may be counter-intuitive against business specific data.

The Outcome

Much faster auto suggestions, down from an unusable number of seconds to double digit milliseconds.

Tuning of the attributes used for Free Text Search

The Problem

A business requirement arose for the content pages to be indexed and searchable and presented within and separate to the product search results. This must work across all twelve languages.

The Approach

Discussions where setup with the CX team to explain the complexity of delivering this feature in SAP Commerce given it's not supported out of the box and the amount of customisation required. It was decided, however, to continue with a PoC and build this feature directly into Hybris.

A solution was designed and implemented as follows:

• Customisation of the Content Page model and Smart Edit editors to store and capture attributes relating to search: Indexable, Keywords, Description, Thumbnail etc.
• Creation of a new Index Type and the required Value Providers to index Content data
• Modification of the Search Facades and Services to perform the correct search and mix results as required
• Front end JSP modifications to show mixed, Product Only and Content Only results

The Outcome

Content Search was integrated into the main Product search with no performance overhead.

The Problem

Out of the Box SAP Commerce does not really implement SEO particularly when it comes to a multi-site/multi country architecture:

• Canonical URLs are not well implemented, if at all
• No hreflang implementation
• Sitemap and robots.txt implementations are poor

The Approach

Working alongside an SEO agency the problems with the OOTB were identified and solutions designed to fix these and close the gap.

Solutions:

• Ensure each page has a Canonical URL that is correct for that page.
• HREFLang implemented across all sixteen sites and twelve languages to ensure Google is indexing and serving the correct localised content and not penalising the implementation for a lot of duplicate content (e.g. English is available on all sixteen sites)
• Modified Content Page controllers/JSPS to obey the captured Robots tags
• Sitemap implementations updated to only output active pages, obeying country/language restrictions
• Robots.txt changed to a dynamic implementation that was meeting the expected syntax and included the language URL attributes

The Outcome

Improved SEO analysis

The Problem

Out of the Box the cookie banners are ineffective and no behaviour change is observed whether consent is given or rejected.

The Approach

Assisted the Product Owner in choosing an external cookie consent management platform that met both the technical requirements and business requirements.

It was important to ensure the business stakeholders understood that work was required both within the SAP Commerce platform but also inside any Tag Managers, Analytical platforms and content teams to ensure all tools and content was re-active to the cookie consents.

The following solution was designed, implemented and tested:

• JavaScript changes within Hybris to give content authors the ability to include iFrames/external scripts on condition of Cookie consent
• Google Tag Manager changes to make sure each tag reacted correctly to the given consent
• Activation of Google Consent Mode within Google Tag Manager for supported tags to pass correct handling of consent over to the specific tag implementations

The Outcome

Higher level of Cookie privacy compliance

The Problem

Out of the Box the integrations between SAP Commerce and other SAP products (SAP ERP, SAP C4C, SAP Marketing Cloud) are not always fit for purpose in the specific organisation, e.g.

• SAP Customer integration between SAP ERP and SAP Commerce Cloud (using both DataHub and Integration Suite/CPI) is at best a reference implementation with very poor (DataHub) and no (Integration Suite) delta support mechanism.
• OOTB defects in the integrations, e.g. expiring Price Rows at the beginning instead of end of day
• Low/No OOTB reference implementation for standard requirements such as Order History, Invoice PDFs etc.

The Approach

Extensive static and runtime gap analysis was performed between the business master and transactional data in SAP ERP, SAP Commerce Cloud, SAP Sales and Service Cloud and SAP Marketing Cloud against the SAP Integration Suite OOTB iFlows and as a result a number of problems were highlited with a risk/impact/effort scorecard:

• No delta support (e.g. only BD12 supported, not BD21)
• Datastore corruption due to IDOC timings
• Datastore expiration causing referential integrity issues
• Order information not updating after updates made in ERP (e.g. delivery schedules)

After logging, without result, the issues to SAP each iFlow was re-designed to incorporate custom logic or exists to address each of the problems. The implemention was given to a third party resource and was overseen, peer reviewed and tested internally.

The Outcome

From being contacted two or three times a week regarding customer data being out of sync we went to all data staying in sync. Price uplifts no longer required a manual IMPEX to correct the data before working hours. Order history was vastly improved, with placeholder skeleton products used to avoid integration failures, delivery schedules being updated to reflect ERP and generally improving the customer experience.

The Problem

As the business takes Payment Cards we were required to work towards PCI Compliance

The Approach

A PCI analysis was done and then a review of the options, which over time has involved:

• In the early PCI days, OOTB Payment Card encryption inside of SAP 4.6C was implemented which included finding and updating all custom transactions that used the Payment Card number
• As PCI progressed it was required to remove scope altogether and integrate a new Payment Service Provider that supported tokenisation as well as met all of our Level3/LID/VGIS requirements. I implemented this integration alongside the PSP in both SAP ECC6 as well as our BroadVision web platform.

The Outcome

Our web platforms were removed from the Cardholder Data Environment with respect to raw card numbers.

Our SAP system no longer stored raw card numbers

The Problem

Ongoing support of the payment card processing solution was being met internally but it was on a legacy PSP who did not support tokenisation and had falling levels of support available.

The Approach

An RFP process was setup to choose an alternative Payment Service Provider who had an accredited SAP implementation.

A gap analysis was performed between each of the solution options and the specific requirements; once a solution was chosen the solution was enhanced via a process of debugging and re-designing any solution gaps and passing these over to the PSP to be developed. The final solution was tested against some common gaps found between standard solutions and SAP OOTB:

• Retail vs non-Retail rounding issues with respect to tax (VAT)
• Split authorisations, orders and invoices with respect to backorders and complex supply chain
• Timing issues given the complex supply chain and backorder

The Outcome

A PSP was selected, and a sales office by sales office transition to minimise risk was successfully executed with all business being eventually transferred.

Activity

Support was required in choosing vendors / partners:

• Bridging gap between non-technical key business stakeholders and technical requirements from implementation teams
• Assessing suitability and fit of solutions and partner ways of working

The Approach

Worked alongside other business owners and senior magagement to define the tender questionnaires through to reviewing and scoring submissions. Throughout the process calling out any technical concerns and helping to support technical understanding.

Where necessary performed site visits, including to India, Bulgaria and Spain to talk to members of potential teams directly.

Staying close to the implementation partners and continously feeding back updates to the team through project meetings and steering meetings.

The Problem

Traditional waterfall development methodology had been applied to delivery usually resulting in a service take on towards the end. This had led to systems not being continually supported and improved to the required levels.

Ways of working in terms of Operations were not ideal:

• Deployments of Commerce platforms were very manual
• Deployments of Commerce platforms were followed with very little pro-active monitoring
• Little adherence to modern standards for development such as Peer Reviews, Unit Tests, Automated testing

The Approach

Supported senior management in adopting Agile ways of working across the Development and QA teams and helping to address and solve any new challenges that resulted from the tranisition such as balancing just in time Sprint planning vs the needs to understand dates years out.

Worked closely with senior management, junior Scrum Masters and Product Owners to explain the challenges of Technical Debt and ways of working challenges and put together the case to ensure time was being allocated to improve on both. This resulted in the team being given the time and empowered to:

• Create CI/CD pipelines with pro-active alerting to chat channels of results
• Create operational monitoring dashoards and alerting systems
• Replace manual work with automation, such as ansible playbooks