Wednesday, March 09, 2016
In an Assembler based application, an overall flow for a standard page being rendered would be below:
1. A super-lightweight query is executed that only returns Supplemental objects representing rules, location, properties name and few other information from Experience Manager.
Query below from dgraph request log
/graph?node=0&profiles=site.<<site_name>>&offset=0&nbins=0&irversion=640
2. Depending on that meta-data, one or more subsequent queries is executed that will return:
o Dimensions
o Records
o Breadcrumbs
o NOT supplemental objects (this is true for patched ATG 10.2, 11.0 and 11.1)
As per above flow, a standard basic page would generate about 2 Endeca queries to be rendered.
There are some cartridges that generate more:
- featured records cartridges generate one query per cartridge as this cartridge can use different navigation state. So if you have multiple featured record cartridges, that would be multiple extra queries.
Note :- Navigation state can be change from cartridge handler and this may leads to fire another query to endeca.
A response from Endeca can consist of a number of different pieces of data:
- Records (like, products)
- Dimensions to navigate on
- Breadcrumbs (also sometimes called Descriptors), which return information on which things have been navigated on
- Supplemental objects: Used internally, these bring back meta-data about the rules being executed (such as landing pages, content slots, etc)
- Dimension search results: These are special queries that search only within dimensions, not products.
- Key properties: Almost never used. Returns meta-data about the properties and dimensions in the index.
- Other information about the index (such as the list of available sort keys, search fields, etc). You can't really turn any of that off.
No comments
Post a Comment
Note: Only a member of this blog may post a comment.