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
- 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
- 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.
- 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.