Accept Header Enricher

Overview

The Accept Header enricher persists the value of the accept parameter that is sent in the HTTP header of events during the consumer's browser session.

At the beginning of each new browser session, this enricher associates an accept node with the new session node in the graph. If the accept node previously existed in association with another session node, then this commonly-shared accept node implicitly associates the old and new session nodes with a single browser. Thus, this enricher enables multiple sessions to be identified as originating from the same browser.


Events

The front-end entered event, stored in the Context service, triggers the Accept Header Enricher. The enricher extracts the value of the accept attribute in the payload's http_headers element.

Triggered by SchemaPayload schemaPayload example
context/commerce/FrontendEnteredSchema{'eventType': 'AcceptHeaderMessage','payload': {'sessionId': 'someSessionId','user': 'someUser','action': 'someAction','tenant':'someTenant','source': [{'http_headers': [{'accept':'application/json'}]}]} }

The Accept Header Enricher draws an edge between the session node and the HTTPHeadersAccept node in the graph database, as shown. The value of the acceptHeader property is the value of the accept attribute extracted from the payload. For more information, see the Secure Graph service documentation.

Node or Relationproperties
nodes/commerce/HTTPHeadersAcceptacceptHeader
relations/commerce/Session/commerce/HTTPHeadersAccept/commerce/HAS


Metamodel

Enrichers react to one or more schema events. A schema event references a context, a node, an edge, or a property; for example, a keyword search context, the creation of a new product node, the update of an edge between product and cart nodes, or the update of an edge property. In response to a triggering schema, the enricher retrieves the complete event data from the context service, enriches this data, and updates the graph accordingly. Enrichers can only affect their declared schemas in the graph.

The following interactive graphic displays the schemas that invoke this enricher and the schemas the enricher can affect in the graph.

Hint: Use the scroll wheel to zoom. Click on the background and drag the image to pan.


Scopes

Scopes are strings that represent permission to access specific resources and/or operations. For example, a scope string may represent permission to write data to a data repository.

You must provide a scope that enables users to perform certain operations. The scopes should be granted in an access token from the OAuth 2.0 service. For more information about the authorization and authentication used in SAP Hybris services, and also about the scopes in general, see: Authorization Scopes

Scopes

hybris.profile_graph_view: Use this scope to view data in the graph.

hybris.profile_graph_manage: Use this scope to update data in the graph.


Glossary

TermDescription
authorizationThe process of determining whether a given microservice has permission to gain consent.
consentPermission to access (read, write) specific profile data, for example, permission to read/write age estimation or physical address. A consumer and a tenant can grant and revoke consent for subsets of their respective data.
consent classA string alias, defined by developers, that references a set of profile data (also called "schemas") for which consent can be granted and revoked. This string is exposed to users (consumers and tenants) as a reference through which they control consent. For example, the consent class "Purchases" might reference a set of data that includes items purchased, purchase dates, and purchase prices. Toggling consent for "Purchase" enables and disables consent for that entire set of data.
consent referenceA unique, randomized string that serves as a passcode to decrypt data associated with one or more schemas. Various service calls require a consent reference.
consumerThe end user whose actions yield profile data in the graph. A profile describes a single consumer.
contextData that affects the state of the graph. This data can be collected from consumer-triggered events or from third-party sources such as weather stations.
Context AdapterA microservice that receives data and, optionally, adapts it for entry into the graph. For example, a Context Adapter can adapt address data by adding a ZIP code and normalizing the street labels (for example, changing "St" to "Street"). The Context Adapter then passes the data through the Context service, which caches it so that enrichers can subsequently persist the data in the graph.
context repositoryA temporary cache for adapted context data, before it is further processed by enrichers and persisted in the graph.
context serviceAn internal microservice that manages the insertion of, and the retrieval of, context data in the Context Repository.
encryption keyA unique, randomized string used to encrypt and decrypt specific data in the graph. Each data element is encrypted with a different encryption key. Decryption, using this key, is required to access, view, and alter the data.
enricherA microservice that retrieves data from the Context Repository and/or Graph, possibly alters or extends it, and then persists data in the graph. An enricher can interpret data points, or sets of data points, to yield new data to persist. For example, an enricher can interpret purchasing data and contemporaneous weather station data to yield new data indicating that the consumer is a rainy-day shopper.
graphThe database that stores profile data as nodes, edges, and properties, and allows semantic queries.
identityOne of many independent units of data used to identify a unique profile, such as an email address, browser type, or version.
profileData about a single consumer, collected and derived from events that are triggered by, or are logically associated, with that consumer.
schemaA string representation of a path in the graph that represents an abstraction, rather than a concrete instance, of a particular data structure.
tenantA registered entity with a shared commercial goal that subscribes to SAP Hybris Profile services and packages to reach that goal. A tenant can also develop and contribute enrichers and context adapters to the SAP Hybris Profile suite. Within YaaS, a tenant is a project.


  • Send feedback

    If you find any information that is unclear or incorrect, please let us know so that we can improve the Dev Portal content.

  • Get Help

    Use our private help channel. Receive updates over email and contact our specialists directly.

  • hybris Experts

    If you need more information about this topic, visit hybris Experts to post your own question and interact with our community and experts.