June 21, 2017 | Written by: Leho Nigul
Share this post:
IBM is in the process of rolling out an exciting transformation of our eCommerce portfolio. This is the second in a series of posts that will formally introduce these advancements and review the architecture of the services from a technical point of view. In this blog, the author outlines how IBM simplifies and manages our clients’ requirements for customization using xC (External Customization), an important component of our Digital Commerce strategy. Click here to review the previous blog posting, Monolith to pebbles: transformation of the IBM Commerce portfolio.
The Unwritten Agreement Around Innovation
The premise behind purchasing commercial software from a “vendor” revolves around the unwritten agreement that the vendor is effectively providing access to a pool of resources funded by many companies and as a result, the R&D innovation greatly exceeds that which any one company could do on their own for a given system (e.g., CRM, billing, e-commerce, ERP, etc.).
The challenge for web application architectures where this innovation was placed, whether they started on the J2EE paradigm or .NET, was how an individual company would customize the solution for their business. Depending on the customizations needed, companies often found themselves with a solution that couldn’t easily be upgraded to take advantage of the latest innovation provided by the vendor in each release. That would often be a result of direct class extensions and/or binary dependencies, which made the upgrade process significantly harder.
As IBM works to reimagine our commerce platform, one of the primary goals and success criteria for our SaaS offering is to meet the requirements of customers who now expect a solution with near infinite uptime, deliver innovations without any impact to a current implementation AND find a way to allow more flexibility and “customizations”.
Why are customizations critical?
There are certainly some eCommerce SaaS vendors out there who do not allow any significant customizations to their SaaS solutions. That, of course, has a direct negative impact on their clients’ ability to enable effective brand differentiation and alignment with client-specific business processes.
For example, some customers like to limit the number of certain items that buyers can add to a cart (if you are a parent of a young child, you are very likely to remember the Hatchimal craze last Christmas season). This simple example can be done through the customization of “add to cart” business logic in the checkout flow (check for the quantity of items added to the cart).
Even though we pride ourselves on having a very rich functional feature set, and we are continuously adding new functional features to our eCommerce platform, we realize that there will always be some scenarios that might not fit exactly with capabilities provided out-of-the-box, and we need to support them through enablement of well-defined customization flows.
How does the new IBM Commerce platform support programmatic customizations to business logic?
The traditional customization model implies the direct extension of java interfaces. While such a customization model is extremely powerful, and still relevant for customers who require very high levels of customizations, it also creates a significant “joined at the hip” effect between specific versions of the platform and the customization code. This approach makes it quite hard to adopt platform changes and improvements, per the Unwritten Agreement around Innovation mentioned previously.
The key objectives that we pursued in the area of platform customizability were to:
- Provide the ability to customize an eCommerce solution without creating binary dependencies between customizations and platform code
- Provide the ability to scale, run and operate customizations independently from out-of-the-box platform components. I will also include “neighbor” separation for customization implementations done for different customers.
- Prevent errors in the customization code from bringing down the platform services.
- Leverage the existing capabilities and knowledge that exists across the broader WebSphere Commerce ecosystem
- Provide enablement for end-to-end development and problem determination lifecycle of the xC customizations
To achieve #1 and #4 on the list, we chose to take advantage of the component model which already existed in the WebSphere Commerce solution, more specifically, the concept of task and controller commands. We decided to use that as the starting point for our new extension model, and to scope our external extensions at the level of granularity provided by existing command framework, but do it in such a manner that we could increase or decrease the granularity as we move forward.
Since a lot of business logic customizations actually involve pre/post business logic execution actions, where appropriate, we also modeled our extension points at pre/post/in-place execution scope. That means certain external customizations could be registered for execution before, after or instead of execution logic provided in the out-of-the-box (OOTB) implementation. We also extended the notion of xC extensions for other services, for example, Solr/query based execution logic. Below, you can see examples of these APIs for our order component.
Of course, to enable externalization of customizations, we needed to come up with a Java/Language independent mechanism to pass data between our out- of-the-box logic and the externalized extension. To do that, we developed a JSON-based data representation that encapsulates not only business-specific data relevant to each extension point, but also additional data associated with the execution context (similar to command/business context data in WebSphere Commerce).
If a corresponding business logic extension is registered, and relevant APIs are implemented within the customization package, the platform will send a JSON object containing business- specific and context-specific data to the external customization implementation. The implementation code can make relevant changes to the JSON object and send it back to the platform, where it will be properly parsed and changes will be persisted.
This process works well for relatively small JSON objects, but things can get tricky when the size of the object grows (for example, when you have business scenarios with large carts). To account for this use case, we also provided the capability to effectively filter in/out only specific data required for customization logic. In cases where obtaining the entire JSON object is potentially overkill for a given customization scenario (for example, creating a customization to check the quantity of certain product added to the cart), I would only send product quantity information to the extension logic instead of the entire JSON representation of the shopping cart. In our model, this is easily achieved by providing a filter configuration to the extension point. The filter provides a JSON template of the data that is shared to the external customization.
It is also important to note that we never assume common transaction boundaries between out-of-the-box platform code and xC customizations. In the case of transaction failure in OOTB business logic, the transaction failure compensation mechanism will be invoked within the xC implementation. More specifically, we provide out-of-the-box compensation APIs for the xC implementations where implementers can put their compensation logic. If the transaction fails on the platform side, this compensation API will be invoked. For example, if you implement integration with a loyalty points system, you can implement compensation logic for the scenario where the order submission transaction fails.
Is our approach any different from a “Web Hook” pattern?
Web Hook is a customization pattern where platform vendors define certain “punch out” points in the business logic execution flow (usually URL addressable) and assumes that implementers will develop, host and deploy implementation logic on the other side of the “hook” themselves.
The most significant aspect that differentiates xC model from the general “web hook” paradigm is support for the end-to-end development, deployment and problem determination lifecycle. In our view, it is very important to provide the APIs for creating external customizations, however, it is equally important to enable developers to efficiently deploy and debug their customizations as well. Let’s see how we do that.
In essence, xC development is largely about receiving the JSON data object from the Commerce platform, parsing it, implementing the customization logic on top of the provided data (as well as additional data from optional callouts) and providing a modified JSON object back to the platform. Much of this can be done in any development tool or IDE. However, we also provide implementers with an Eclipse-based SDK that enables them to not only create the customization logic, but also to unit test and build the deployment packages required using provided Gradle scripts.
Once a deployment package is created, it can be deployed to the appropriate environments using our web based self-service tool. The same tool can be used to seamlessly access the xC execution logs, using the web-based Graylog log browser to enable effective problem determination for the xC deployment packages.
As you can see in the diagram above, the self-service tool provides a single point of entry for various implementation activities – such as customization package deployment, problem determination enablement, user management (customer admin can add/remove other customers users who have access to the self-service tool), environment configuration and many others.
Finally, I want to add few words about the security and scalability of an xC-based solution.
All customer-specific xC logic is deployed into separate Docker containers (that are fenced off from both the platform logic as well as other customers xC Docker containers). Hence, we not only avoid the “noisy neighbor” effect across customers and between a customer and the platform, but also ensure that we can easily scale up customization implementations for a specific customer by starting up additional Docker containers dedicated to customization implementations.
All the invocations between platform and xC servers are done through SSL-enabled communications, which provide the highest level of protection for data transfer and service invocation between platform components and deployed customer customization.
Through this article, I have described how our new External Customization (xC) model:
- Enables programmatic modification of out-of-the-box business logic, while being able to take advantage of continuous innovation provided by the platform
- Delivers secure and scalable deployment of customization logic
- Provides self-service tools to perform environment configuration and support the end-to-end lifecycle of the customization logic that accelerates the implementation process
You’ll also want to read other posts in our Engineering series:
Monolith to pebbles: transformation of the IBM Commerce portfolio
How to build a cognitive system