Orchestration service architecture overview

The Orchestration service bridges Ruby applications that can only recognize Elastic-based search formats and Solr-based search services. This introduction describes how the Orchestration service works and how Search-related messages flow between the two systems.

Background

The Orchestration service is a message-oriented middleware with a rule-based routing and mediation engine. It provides a Java-based implementation of the Enterprise Integration Patterns to mediate existing Solr-based search requests and responses into a format that can be consumed by a Ruby Storefront application. This Orchestration service can convert a JSON message from one format (Search v1 API) into another (Search v2 API).

The Orchestration application consists of a runtime containing routes representing the dataflow processing pipeline for each Search operation sent between Solr-based Search API and Ruby Storefront. A route can perform a series of related operations in one request. To access a predefined route, external systems and services, such as the Ruby Storefront, expose a corresponding endpoint through an HTTP component.

Using Solr-based Search customization with Orchestration service

Customers with existing Solr-based Search customization can continue since the programming model of Solr-based Search has not changed. When using these customization assets with Orchestration, additional custom data in the Search API response will be returned through the Orchestration service in the exact format provided through the Search API. The Orchestration service only performs transposition against those default elements inside the Search API response; custom data will not be modified.

Usage scenario 1 - search and browse operations

The Orchestration service bridges a Ruby Store and a Solr server, facilitating search requests and responses. It functions in the following way:

Receiving requests: The service starts by receiving requests from the Ruby Storefront in Elasticsearch-based Search (v2) API format.

Converting to Solr format: The service then converts these Elasticsearch-formatted requests into a format that the Solr-based Query server can understand.

Sending to Solr Query: The request is sent to the Solr Query server once the conversion is complete for processing.

Handling responses: After the Solr Query server processes the request, it sends back a response in the Solr-based Search (v1) API format.

Converting Back to Elasticsearch format: The Orchestration service converts this Solr-base Search (v1) API response into Elasticsearch-based Search (v2) API format.

Returning to Ruby Storefront: Finally, the converted response is sent back to the Ruby Storefront for use.

Usage scenario 2 - page layout lookup with SEO keyword

The Orchestration application also interacts with the Transaction server for Page Composer operations. It functions in the following way:

Receiving requests: The service starts by receiving a page layout lookup request from the Ruby Storefront in Elasticsearch-based Search (v2) API format.

Forwarding to Transaction server: The service then proxies the inbound request to the Transaction server to perform the actual page layout lookup operation since the Page Composer processing logic resides inside the Transaction server.

Handling responses: After the Transaction server processes the request, it sends back a response, which Orchestration will immediately route back to the Ruby Storefront for use.

Aurora uses /wcsstore (defined in wc-component.xml), while Ruby uses /hclstore (defined in STORECONF) to determine what to use for the image path prefix. When combining the use of both configurations, the query runtime uses the following logic flow sequence to determine the image path:

Each store can have its custom prefix, defined in STORECONF via hcl.imagePath with its own store.id as the owning store.
Next, if the above entry does not exist, it falls back to the asset store-level prefix, which is defined in STORECONF via hcl.imagePath, with the asset store as the owning store of this entry.
Finally, if none of the above applies (which is highly unlikely), the single site-level setting in the wc-component will be used as the current store's image path prefix.