Anatomy of a DX Engine Component
A Component performs one of the following:
- Reads from a data source
- Writes to a data target (which may or may not act as a data source for other Components)
- Modify data that was read from a data source
- Modify data that was from the result of another Component
All Components have some sort of configuration that controls the Component's behaviour. For example, a Component may have configuration that will, for example:
- select the content type in which to fetch specific content records
- determine the search index to query
- choose a promotion to offer
- specify a value to transform
- select a collection to write to
- provide a list of products to remove from inventory
- determine whether the component should do anything at all
Many configurations can use values that are determined by it query-time via Expressions.
There are three different methods of specifying configuration values:
|Specific value||A hardcoded configuration value is specified within the Component at setup-time.|
|Context Field||The configuration value is determined at query-time by using the value from the specified Context Field.|
|Expression||The configuration value is determined at query-time by evaluating an expression (which has access to all Context Fields and Component results)|
There are a common set of configurations that all DX Engine Components have. Depending on the type of Component, there are configurations that are specific to a Component.
|Context Field Enrichments||contextFieldEnrichment||Yes||Uses the Component's response to calculate values to be put into the Context for other Components to reference. See details here.|
|Sub Components||subComponents||Yes||Provides a way to enrich each record in a Component's response with the results of other Component executions using custom Contexts. See details here.|
|Cached||cached||No||If set to |
|Cache Time-to-live||cacheTtl||No||The number of seconds that cached responses will be cached.|
|Trigger Expression||trigger||Yes||The default value is |
|Validity Expression||validity||Yes||The default value is |
|Skip on Failed Dependency||skipOnFailedDependency||No||The component's execution is skipped if any of the components on which it depends, is in a |
|Skip on Skipped Dependency||skipOnSkippedDependency||No||The component's execution is skipped if any of the components on which it depends, is in a |
|Skip on Invalid Dependency||skipOnInvalidDependency||No||The component's execution is skipped if any of the components on which it depends, is in an |
The Property column list the compondng property to update via the Management API.
Component-specific configurations are dependent up on the specified Component Type of a Component. The available configurations for each Component are documented on that Component's documentation page. Note that some Component-specific configurations allow for the entry of an expression.
Depending on where and expression is used, it has access to different set of variables/functions.
The following sections list what variables/functions are available to expressions
Expression used for Component-specific configurations
Expression used for Triggers
Expression used for Validity
Expression used for Context Field Enrichments
Expression used for Sub Component
Component X becomes dependent upon Component Y when Component X uses any expression (anywhere within Component X's configurations) that contains:
someContextFieldis enriched by Component Y's Component Field Enrichments
When a query is made to the DX Engine, all of the requested components are processed. The following flowchart describes the various states that a Component goes through.
|PROCESSING||A request to the DX Engine has occurred and this Component is part of fulfilling the reponse. Uses the |
|WAITING_FOR_COMPONENT_DEPENDENCIES||Waits for any Components on which it depends to be complete (either of the following states: |
|EXECUTING||The Component logic is run. If any failure occurs during the execution, it enters |
|SKIPPED||The Component was not executed.|
|VALID||The Component's response is valid.|
|INVALID||The Component's response is not valid.|
With Expressions and Component Statuses, the DX Engine allows for many complex real-time orchestration scenarios.
Context Field Enrichment
After a Component is executed and it is valid, it will process its Content Enrichments (if any). Take the following Content Field Enrichment configuration.
After this Component is run and get a response from whatever data source it is querying, it will evaluate each of the three expressions and puts the value into the request's context so that other Components can use it. If a Context Field already exists, it will be overwritten.
If Component A references a Context Field that is enriched (via Context Field Enrichment) by Component B, then the DX Engine is aware that Component A dependent on Component B and will ensure that:
- Component B is executed, even if it was not explicitly requested by the DX Engine Query.
- Component B is executed BEFORE Component A is executed.
After a Component is executed and it is valid, it will process its Sub Components (if any). Take the following Sub Component configuration.
After this Component is run, it will:
- Create a new Context that is a copy of the context available to the current Component with the addition of a new Context Field,
actorIds. Note: This newly-created Context is only available to the specified Components in the Sub Components configuration (
- Execute the the
- Add the response of the
actorsComponent into the parent Component's response under the property,
The Components specified within another Component's Sub Component configuration may, themselves, have more Sub Components. There is no limit to this nesting. This "nested orchestration" is much like the possible nesting seen with GraphQL (but without the need to write resolver code!).