About Extending Infosys Equinox

This article discusses extensions in Infosys Equinox.

Overview

This document provides an introduction to customizing and extending Infosys Equinox’s platform release 8.0 (“Infosys Equinox” or “platform”). It includes details how the platform is organized and key extension and customization features. We describe:
  • The major building blocks of the platform from front-end to backend
  • They key places where customization and extension are designed into the platform
  • Compile, Deployment, and Runtime customization options
  • Authorization and authentication patterns
  • How to call the platform
  • How the platform is deploying using Docker and Kubernetes
  • How the admin components of the platform are built and extended
  • How the UI/UX elements of the platform are build and extended

Expectations

The reader of this document is expected to have a basic understanding of:
  1. Java Spring Boot architecture (https://spring.io/projects/spring-boot)
  2. Building and deploying Java artifacts using Kubernetes (https://kubernetes.io/) and Docker (https://docs.docker.com/)
  3. JavaScript (https://www.javascript.com/) and React (https://reactjs.org/) front-ends
  4. Modern SQL (https://modern-sql.com/) and NoSQL (https://nosql-database.org/) databases
This document is not intended to be a comprehensive guide for updating specific microservices or components in Infosys Equinox, rather it is intended to give the reader a high-level understanding of how they may be modified and to direct the reader to the specific components they may wish to modify.

Platform Components and Concepts

Infosys Equinox Commerce consists of five (5) primary blocks:
  1. The underlying distributed computing components used to deliver the platform
  2. The backend microservices which hold persistent state
  3. The orchestrations which link microservices together and support operational and admin functions
  4. The frontend presentation services which support consumers (buyers)
  5. The admin presentation services which support administrative and business users

Users and Roles

Infosys Equinox includes three (3) types of users: end-users, business users, and site administrators.
  1. Site or End-Users (Consumers)
    • These users are the customers of our clients who actually use the site to engage in commerce. They search for products, place them in carts, make payments, and receive the items being purchased — either electronically or via physical shipment.
  2. Business Users
    • Business users manipulate the content of the site. They manage the products for sale, place them in categories, and manage promotions and merchandise. Business users are managed via roles.
  3. Site Administrators (Business Admins)
    • Site Administrators manage the platform itself. They manage the roles that control what Business Users are authorized to do, control access to security keys, and can update key configuration information that controls the platform.
Note: Each action performed by a user role can be performed through the platform’s application programming interfaces (APIs).

Basic Structure

Infosys Equinox can be thought of as having three (3) broad capabilities, delivered by a collection of coordinated microservices.
  • An e-commerce website
  • Business User and Admin control of the website
  • Backend that supports the other two (2) capabilities

Figure 1: Platform Capabilities

The Platform delivers these functions through a collection of microservices which manage low-level data, orchestration which stitches these low-level functions into useful capabilities, and then a set of presentation services which present the data to both end-users and administrative users. Consumer sites are presented via React, GraphQL, and orchestration specific to supporting end-user capabilities. Business user and platform administrative capabilities are provided through templated ThymeLeaf pages, and all of the low-level functions are provided by a set of microservices. (See Figure 2: Major Platform Components)

Figure 2: Major Platform Components

Points of Customization

The following points in the platform can be customized or used to modify the behavior of the platform.
  1. Camel Orchestration Layer
    • For individual microservices
    • For composite REST microservices
  2. Microservices
    • Each has validation extension points that allow custom code (currently Java) to be invoked to validate inputs
    • Each has processor extension points that allow custom code to be invoked, which performs specific well understood operations, including:
      • Sending emails, texts (SMS) and other forms of notifications
      • Processing payments
        • Each has a pre-process extension point that may be used prior to routine processing
        • Each has a post-process extension point that may be called after routine processing
  3. Order Management
    1. Microservice has Camunda BPM workflows that can be modified to handle custom behaviors
    2. Has the ability to install Work Items to process nodes in the BPM workflows
  4. Notification Events
    • Each microservice creates notifications events on major activities. These events, delivered via RabbitMQ topics, allow customizations and extensions to asynchronously respond to these activities.
  5. React
    • Specific React components can be created that call the out-of-the-box services or any extensions in the solution.
  6. ThymeLeaf
    • ThymeLeaf admin screens can call additional plug-ins that invoke each of the extension / customization points has different properties and capabilities.

Camel Orchestration

Camel Orchestration acts as the primary way of coordinating the behavior of the microservices. There are several forms of orchestration, each of which can be modified.

Microservice Routes

Each microservice has a Camel route. These routes permit both simple tweaks to the behavior of the existing microservice, and wholesale substitution via wrapping external services.

Composite Routes

A number of core services are implemented through the action of multiple microservices. These form composite services, built as Camel orchestrations. The behavior of the high-level composite services can be modified by changing the composite orchestrations, adding or removing steps, or invoking additional internal or external services.

Wrapped Services

As every low-level microservice is exposed via a Camel route, we can replace a low-level service with a wrapped external service by creating a new Camel route. The Camel route needs to externalize the same interface as the microservice. The Camel route can modify inputs and outputs to/from the external service, and can call Java utility functions to augment inputs and outputs. As an example, an external enterprise resource planning (ERP) system could be wrapped to provide the inventory status for some or all product in a solution. All of the existing functions of Infosys Equinox would invoke the new route, which would direct queries and post changes to the ERP system. Thus, existing product detail pages (PDPs) could check for inventory, and the cart management and checkout service would reserve and expend the items without change.

Microservice Code Extension Points

The microservices define a series of extension points where a plug-in jar can extend or override the behavior of the microservice. These extension points are designed as Java interfaces which can be extended. This permits the core service to invoke the interface and call to either the default or the extension behavior. Which class is invoked is determined at runtime via the extension classes having hooked the factory used to instantiation actual runtime objects. Specific extension points for each microservice are described in the detailed documents for the microservices. See the Microservices section of the portal.

Order BPM and Work Items

The Order microservice, unlike the other services, is built around the Camunda BPM engine. The structure of the microservice consists of a spring-boot controller which processes requests and then calls the associated Camunda BPM to handle the workflow. The workflows consist of XML encoded BPM which invokes low level work Items to perform the work. The service may be customized by:
  1. Modifying or extending the BPM
  2. Modifying work items
  3. Providing both new BPM and new or extended work items
  4. Adding new endpoints which invoke new BPM which may invoke new or extended work items.
For additional details about Camunda in general, see https://camunda.com/products/bpmn-engine/.

Event-Driven Extension

Each Microservice can be configured to deliver RabbitMQ Advanced Message Queuing Protocol (AMQP) events when major operations occur. These events are published to service-specific topics. By receiving the events and responding to the events, the platform can be extended and modified. These events are purely asynchronous and non-blocking; accordingly, it is not possible to alter the primary flow of a microservice. When, for example, an order is created, the order will exist before the event is created. Thus, we can only modify the order after its creation. We cannot block its creation or change its properties prior to its creation. The normal flow of an event-driven extension is that the event is received and the extension calls the REST APIs to perform processing. The event does not contain the full details of the system, but rather is used to trigger additional processing, as any state included in the event is ephemeral, and may be superseded by processing which occurs after the event was generated.

React Frontend Component Extensions

The React frontend in the out-of-the-box platform is built to provide an easily themed frontend experience that follows a white-label approach. The frontend is also built to permit both detailed creation of new components, and the use of the existing components to build a specialized frontend experience. These components may also include calling extended function from the base platform. Added function to be used by the frontend should ideally be exposed through GraphQL, in the same fashion as base function is exposed, but it is also possible to call directly to the orchestration layers or the underlying microservices.

Admin Extensions

All of the Infosys Equinox 8.0 Admin interfaces are built on top of the ThymeLeaf templating framework. We can add admin functionality at multiple levels in the system.

Adding Microservice Functionality

Admin functions can be added directly to the microservices. Strictly speaking, these features are added to the microservice, and can be used for any purpose, including administration. In practice, administrative features will require administrative rights in their JWTS token and, thus, be limited to use by administrative functions.

Adding / Changing Admin Orchestration

Parallel to the storefront orchestration, there are Camel orchestration services which support admin features. These orchestration can be extended and modified in a parallel fashion to the store front orchestration, allowing additional or changed functionality for administrative features.  


Revision History
2022-04-10 | JP – Fixed link and http issues.
2020-03-27 | JP – Minor edits.
2019-07-03 | PLK – Minor formatting edits.
2019-06-16 | PLK – Page added and content uploaded.