14 Jun 2020

The PDF problem

In one of our recent implementations that required us to integrate a marketplace platform with a commerce platform, we faced an interesting operational problem that is often overlooked during design: The PDF problem.

Background: This was a new marketplace for overstock items that aimed at attracting sellers that wanted to liquidate their old stock.

While sellers were happy to sign-up and make some money on old stock, they weren’t particularly enthusiastic in spending work hours to enrich product content on some items destined to the yard for recycling. They wanted an easy way to associate product specifications that were in pdf format to their products on the website, else they would have to manually key them through the marketplace seller portal.
Client as the operator of the marketplace was principally inclined to provide product specification information on the PDP pages and hence obliged to seller’s request to upload the pdfs during product creation and not needing to key-in the information.

But alas, the marketplace platform did not support pdf upload at the time of our implementation. Hence came into being “The PDF problem.”

The PDF problem

The ask was to be able to associate a product specification pdf to a product during its creation in the seller portal within the marketplace platform.
The data along with the other product data (images, offer, product basic data etc.,) would then be transferred to the eCommerce platform and be displayed on the website. The issue arouses due to the fact the seller portal did not support upload of pdfs.

How did we solve

Pragiti’s analysis resulted in knowing that this is a business operations problem that required a technical solution. Our analysis resulted in the following findings

  1. The client as the operator mandated attaching a pdf spec sheet for all items on the website
  2. Not all sellers had a pdf spec sheet for the items they sell
  3. Few sellers had pdfs stored in their file systems
  4. Some sellers were able to only provide public URL references for the pdf spec sheet of individual product than to download and manually send them, simply due to the sheer volume of items

Based on the analysis, we came up with a solution that was cost effective, easy to use and was accepted by all parties involved.

Our approach was to ensure that irrespective of the seller’s approach to share the pdf spec sheet, we would create a consistent experience in product & offer creation, thereby keeping the impact on business operations minimal.

To address the challenge, we simply leveraged the existing IT infrastructure of the client and created a technical solution that adapted to the variations in sellers’ approach to pdf spec sheet and one that did not adversely disrupt existing operations.

  • Per the client’s need, we mandated the need for a pdf spec sheet for every product.
  • We defaulted to a standard ‘Spec sheet not available’ template for those items the seller did not have a pdf spec sheet.
  • We repurposed client’s unused server as a file server and made it available to sellers to securely access and upload the pdf spec sheet.
  • We created code to extract the pdf file from an URL and loaded it into a local file server that was not attached to the marketplace platform. We then simply referenced the file directly within the website.

It was a solution that we turned around in quick time and one that was effective in addressing all the variations. It was a gratifying experience to have used an IT solution to solve a business problem.

Up next is the ‘FTL Dilemma’ – stay tuned to know what was it and how we approached to solve the problem.


14 Nov 2017

Hybris : How to replace base_{locale}.properties approach to fetch localized content for website


In Hybris e-commerce platform, localization of certain content on the web pages is addressed by spring framework class “ReloadableResourceBundleMessageSource” which takes care of fetching the messages from base_{locale}.properties

base_{locale}.properties :

The keys and it’s values are referred in the jsp/tag files using spring framework tag library

Problem Statement or current limitations

The approach of fetching localized content from base_{locale}.properties has certain limitations that can be explained with the below mentioned scenario:

  • A website has launched and a long-awaited campaign is finally live. The site is experiencing heavy traffic with many customers accessing the site across the globe. The content manager suddenly realizes that some content on the site is incorrect and need to be corrected immediately.
    • What are the steps to correct the content on the site?
      • Inform the IT team that manages the site and explain the issue with the content.
      • IT team analyzes the issue and finds the root cause.
      • IT team informs the content manager that the content value in base_{locale}.properties needs to be corrected. It would take a few minutes to make this minor change and servers would need to be restarted to reflect the updated content.
      • Servers restarted after the changes are made in base_{locale}.properties and the updated content shows up on the site.

Instead of every such minor content change going through the above cycle:

  • What if such a change could be made without any server restart?
  • What if a content manager is given the ability to update content without relying on the IT team and have it reflect on the site immediately?

How amazing it would be if a content manager has the power to make changes to content just as he/she manages content in WCMS (Web Content Management System)!


Here’s an approach that will empower a content manager to make changes to content that is a part of base_{locale}.properties without having to chase an IT team to get a fix in place, without having to restart servers and still have the change reflect immediately on the site

  1. Create an item type which stores all the key=value that is defined in base_{locale}.properties.
    • The item type can be made catalog aware to ensure that the content value that is changed can be previewed before allowing the change to reflect on the site.
    • The value qualifier in the item type can be localized to ensure that this approach takes care of storing the values of locales that the website supports.
  2. Override the ReloadableResourceBundleMessageSource class of Spring framework which fetches the values from base_{locale}.properties with the new class  CustomBundleMessageSource. This takes care of fetching the value from the database.
  3. Make the newly created item type, that stores the key and values that are usually created in base_{locale}.properties, available in Back Office such that content managers can login to Back Office and make the necessary changes without relying on an IT team to make content corrections.

Performance considerations

As the proposed solution indicates that an item type is created to replace base_{locale}.properties for fetching the localized content. This implies that every request to fetch content will result in a call to the database, giving rise to performance concerns. To avoid making a database hit for every request, load the data from every query to the item type in the cache thereby any request for the same message content will be fetched from the cache and not from the database. This will prevent any subsequent database calls being made to fetch the content that’s already in cache.

To achieve this, introduce a class, say “BaseMessagesCacheRegion“, which extends “EHCacheRegion“. This will hold all the values that are returned by the queries to fetch the content messages from the database.

This leads to another point of consideration – when a content manager updates the content from Back Office, the changes will not reflect on the website immediately. The reason being that that particular value is already in the cache. When the system identifies the content’s key and its value in the cache, it will not query the database to fetch the value that has been updated by the content manager. To display the updated content on the website, one must login to HAC and clear the entire cache.

This implies that the cached data for the entire content is cleared and not just the one for which the content manager has made an update via Back Office. To address this, introduce an interceptor which will take care of updating the cache with recently updated content in Back Office. This will eliminate the need of clearing the entire cache from HAC.

Note: There are many ways to address updating of cached content; what has been used here is the approach of an interceptor to address the update of cached content.

References of a working example:

  • Snapshot of Back Office displaying “BaseMessages” item type created to load the base_{locale}.properties data.

  • “contentBaseMessageCacheRegion” that’s introduced to store the cached content of BaseMessages.

06 Feb 2017

SOAP/REST message monitoring in Eclipse and IntelliJ

Webservice applications ,either SOAP or REST send a lot of information in the headers along with the actual message.Most of the information is not captured in the application logs.

For debugging web service client/server applications , it is necessary to see the exact message that is sent on the wire i.e HTTP message along with the HTTP headers. Application logs usually print only the webservice request and printing the HTTP headers needs additional configuration based on the specific library being used.

SOAP UI- sample Raw HTTP message

Eclipse and IntelliJ provide plugins which help to intercept the HTTP messages sent between the client and server by acting as Man in the Middle.This is a very useful feature to debug the HTTP requests generated by application code and is very easy to setup.

Client/Server — Normal Communication

Client/Server — Communication with TCP Monitor

Eclipse Plugin — TCP/IP Monitor

TCP/IP Monitor -Eclipse

IntelliJ Plugin — TunneliJ

TunnelliJ HTTP Monitor

For advanced debugging and monitoring of TCP traffic, Wireshark can be used. I will try to cover this in a separate post.

23 Jan 2017

Using Stagemonitor with hybris

Stagemonitor is an opensource solution for performance monitoring of Java applications.It provides insights about the call stack ,Method execution time, page load time,JVM,JDBC, Request metrics and helps to better understand and improve the performance of applications.

Stagemonitor can be used for both development and production environments.It imposes a very low overhead on the application.

Stagemonitor for Development

hybris storefront with Stagemonitor widget

For development environments, Stagemonitor provides a widget which is injected into the webpage which is being monitored.This widget gives the details about the Call stack, time spent in each method,Web Requests and JVM metrics.

Stagemonitor widget-Call Tree tab

Call Tree tab provides the call stack and the time spent in each method.

Stagemonitor widget-Request tab

Request tab shows the total Page load time and also shows time taken for network,Server processing and DOM Processing.

Stagemonitor widget-Metrics tab

Metrics tab provides the details about the JDBC, JVM and Web Requests.


Stagemonitor can be configured to send the performance metrics to time series databases like ElasticSearch, Grafana.This allows the flexibility to monitor requests/metrics over a period of time and helps in understanding the application performance issues.

Multiple application instances running on different hosts can be monitored at a time using Stagemonitor.

Elasticsearch — JVM Metrics

Integrating with hybris

1. Download and install the below extension and add entry in the localextensions.xml . This extension contains all the dependencies and properties for running stagemonitor.

Stagemonitor hybris extension

2. The file at the below path is where the configuration can be controlled.

${HYBRIS_BIN_DIR}/bin/custom/stagemonitor/resources/, de.hybris = true

stagemonitor.applicationName=Electronics storefront
stagemonitor.instanceName=Electronics storefront


stagemonitor.instrument.jdbc.dataSource.implementations=com.mysql.jdbc.jdbc2.optional.MysqlDataSource, org.apache.tomcat.jdbc.pool.DataSource, org.apache.tomcat.dbcp.dbcp.PoolingDataSource, org.apache.tomcat.jdbc.pool.DataSourceProxy, org.apache.commons.dbcp2.PoolingDataSource, org.apache.commons.dbcp.PoolingDataSource, org.springframework.jdbc.datasource.AbstractDriverBasedDataSource, org.hsqldb.jdbc.jdbcDataSource, org.apache.commons.dbcp.BasicDataSource, de.hybris.platform.jdbcwrapper.HybrisDataSource

#stagemonitor.elasticsearch.url= http://localhost:9200

3. The tomcat general options property needs to be modified to include the below java agent.


4. Once hybris is restarted after the above changes, stagemonitor starts collecting the metrics and depending on the configuration, either the widget can be used from the browser or the the metrics can be sent to the Elasticsearch server for further analysis.