Cortex Call Stack

This section describes how a single authorized request drills down through the Cortex’s architectural layers and then percolates up back through the layers and returns to the client application that made the request.

Version 7.1 of the Cortex API introduces the Helix programming model for designing resources. Helix resources interact with the different layers of the call stack in a less complex manner than legacy resources do. This document is divided into two sections: one for Helix resources, and one for legacy resources.

Helix Resource Call Stack

Overview of Helix Resource Call Stack:

1. The client application sends a HTTP request (GET, PUT, POST, or DELETE) to Cortex.

   Cortex authenticates the request using the authentication token found in the request header. Once the request is authenticated, the request is passed to the HTTP bridge.

2. The HTTP Bridge converts the HTTP request into a ResourceOperation, which contains the resource being referenced, the HTTP request’s method, and the request’s Subject.

   The ResourceOperation is then passed to the Kernel. The resource being referenced could be carts, items, lineitems, etc. Supported HTTP request methods are GET, POST, PUT, DELETE.

3. The ResourceKernelImpl receives the ResourceOperation and runs the submitOperation (ResourceOperation) method to verify that the request’s Subject is authorized to access the resource.

   If the subject is verified, ResourceKernelImpl loads the resource referenced in the ResourceOperation through the ResourceServer.

4. The ResourceServer reads the ResourceOperation's resource and the operation type (GET, PUT, POST, DELETE) to determine the correct Prototype to run and then executes the prototype.

5. The prototype gets injected with the appropriate repository, the RequestIdentifier, and if necessary the ResourceEntity which have been injected as fields into the prototype.

6. The prototype then calls the appropriate method on the repository, based on the type of operation being performed.

7. The repository performs the necessary requests against the Self-Managed Commerce Engine, and returns the response in an rxJava stream, either as a Single, Observable, Maybe or Completable rxJava stream type.

8. The resource receives the rxJava stream result from the repository, and returns it to the kernel.

9. The kernel converts the data from the rxJava stream into a JSON object, and sets the Status Code to 200, 401, etc., depending on the success or failure of the operation.

10. A JSON object is returned back the client with the HTTP status.

Legacy Resource Call Stack

The main difference between Helix programming model resources and legacy resources is in the resource and integration layers.

1. The client application sends a HTTP request (GET, PUT, POST, or DELETE) to Cortex.

   Cortex authenticates the request using the authentication token found in the request header. Once the request is authenticated, the request is passed to the HTTP bridge.

2. The HTTP Bridge converts the HTTP request into a ResourceOperation, which contains the resource being referenced, the HTTP request’s method, and the request’s Subject.

   The ResourceOperation is then passed to the Kernel. The resource being referenced could be carts, items, lineitems, etc. Supported HTTP request methods are GET, POST, PUT, DELETE.

3. The ResourceKernelImpl receives the ResourceOperation and runs the submitOperation (ResourceOperation) method to verify that the request’s Subject is authorized to access the resource.

   If the subject is verified, ResourceKernelImpl loads the resource referenced in the ResourceOperation through the ResourceServer.

4. The ResourceServer reads the ResourceOperation's resource and the operation type (GET, PUT, POST, DELETE) to ResourceOperation to run and then executes the ResourceOperation.

5. The ResourceOperation, which encapsulates the Resource URI, the resource, and the operation being applied to the resource, delegates the operation to the resource’s lookup or writer depending on the operation type.

   If the operation is a GET, the resource’s lookup is used. If the operation is a DELETE or a POST, the resource’s writer is used.

6. The resource’s writer or lookup calls a strategy class in the integration layer. The strategy performs a CRUD operation that calls into the Elastic Path Core services. (More on this is step 7 below)

7. For a READ operation, the strategy returns a Java object and then calls a transformer to convert the Self-Managed Commerce object into a DTO (Data Transfer Object).

   The DTO is wrapped in an ExecutionResult, a flag is set on the ExecutionResult to indicate the call’s success or failure, and then the ExecutionResult is passed to the resource.

   For a CREATE or UPDATE operation, the GUID of the newly created object or the updated object is put into an ExecutionResult and then passed to the resource.

8. The resource receives the ExecutionResult from the Integration layer, takes ExecutionResult's DTO, and uses the resource’s transformer to create a representation of the DTO.

   The resource then sends the ExecutionResult with the representation to the Resource server layer.

9. The Resource server layer wraps the ExecutionResult in an OperationResult and passes the OperationResult to the kernel.

10. The kernel converts the Representation nested in the OperationResult into a JSON object and sets the OperationResult's ResourceStatus to 200, 401, etc, depending on the success or failure of the operation.

Process Request by API Platform

The following diagram shows the workflow of the process request by API Platform: