Skip to main content

ATG Search architectural flow : Search and Index



I would like to explain the high level ATG Search implementation architecture ( for an online store) through the above diagram. In this diagram 1.x denotes the search functionality and 2.x denotes the indexing functionality. I have given JBoss as the application server.

Physical Boxes and Application Servers in the diagram ( as recommended by ATG )  :
  1. Estore ( Commerce ) Box --> The box with the estore/site ear (with the site JSPs and Java codes).
  2. Search Engine Box --> The box with the search engine application running.
  3. Indexing Engine Box --> The box with the indexing engine application running.
  4. CA (Content Administration) Box --> The box with the ATG CA ear ( where we could take CA -BCC - Search Administration and configure the search projects) .
  5. Search Indexer Box --> The box with the ATG Search Index ear ( to fetch the index data from repository). Note that the engine performing indexing will need access to the data it is indexing, which for production is the production repository. It will typically access the data via a commerce instance.  For best performance, and for large repositories, that commerce instance should be dedicated for search indexing, and should be a fast machine.
1. Search functionality flow details :

     1.1   Estore server will find the search engine box's host and search engine application running port details from the Search repository
     1.2   Estore server will call the Search engine application as a SOAP request using this host an port
     1.3   Search engine will find the search results using the index file
     1.4   Search engine will send the search results back to the Estore server

2. Index functionality flow details :

     2.1   CA server will start the indexing and will call the Search Index server to fetch the data to be indexed from the repository
     2.2   Search Index server will fetch the data from the catalog repository
     2.3   CA server will call the Index engine application to create the index files
     2.4   Index engine application will create the index files and keep it in a shared folder so that all the search engine applications can read it
     2.5   During the index deploy phase, all search engines will copy the index files to a local folder for fast access

If you need more details, please comment so that I can answer your specific questions  :-)


Labels:

Comments

  1. Anonymous18 January 2012 at 15:55

    nice article

    ReplyDelete
  2. Anonymous15 February 2012 at 06:14

    it is great and simple. Incase both Ca, index and search engine are on same host even then will it communicate via RMI?

    ReplyDelete
  3. Sony Thomas15 February 2012 at 12:26

    First of all, it is not recommended to have these 2 servers and search engine in the same host due to performance reasons. If we have them on the same box, communication with the search engine will always be through SOAP http request and from CA to search index will be via the remote port defined in search indexer.

    ReplyDelete
  4. Anonymous9 March 2012 at 01:49

    Does the engine query the latest deployed index for the results or does it query the index file that is mentioned as part of the search request?

    If it does the latter, how does the index information get updated on the client?

    ReplyDelete
  5. Sony Thomas9 March 2012 at 10:12

    The engine will look into the current deployed index. The current deployed index can be the latest index or can be an old one deployed through historical index deploy.

    Why the client need the index information ?

    ReplyDelete
  6. Anonymous26 July 2012 at 16:46

    All articles related to ATG are really interesting and easy to understand Thomas! Great work.

    ReplyDelete
  7. Anonymous29 May 2014 at 12:10

    Ur are really amazing SONY.... Iam New to ATG.. I want to know more concepts of ATG will u help me plzzz.....

    ReplyDelete

Post a Comment

Popular posts from this blog

ATG CA - BCC home screen : how to add a new link

          Activity source is the property which controls the links on the left nav on the BCC home screen. All activity sources are registered with the ActivityManager component at /atg/bizui/activity/ActivityManager . When rendering the BCC home page, the ActivityManager cycles through all the registered ActivitySource components and displays left navigation links for each of them on the BCC home page. For example if I want to add a new link "My New Link" , below screen shots exaplins how this can be done 1. Add  activityManager.properties to specify the activityresources. In this  activityManager, I specified one MyActivitySource. 2. Add  MyActivitySource.properties  to specify the name of the link and the other details . Here it refers to a bundle properties file.  3. Add  the bundle properties file  to specify the name of the link.  4. Now you could see the new link...
6 comments
Read more

How the ATG Order flow manages a transaction

See more about ATG  Tx management @ http://tips4ufromsony.blogspot.com/2012/05/atg-how-to-use-transaction-manager.html Most of the ATG Commerce form handlers extend atg.commerce.order.purchase.PurchaseProcessFormHandler. The transaction management pattern in order flow is implemented through this form handler’s beforeSet, afterSet, and handler methods. The transaction will be started @ beforeSet method and is ended @ afterSet method. In general, the design pattern for updating an order is as follows: Acquire lock-manager write lock on profile id from the /atg/commerce/order/LocalLockManager Begin Transaction Synchronize on the Order object. Modify Order Call ((OrderImpl) pOrder).updateVersion(); --> atg.commerce.order.InvalidVersionException is thrown based on this Call OrderManager.updateOrder() Release Order synchronization End Transaction Release lock-manager write lock on profile id from the /atg/commerce/order/LocalLockManager     ...
Post a Comment
Read more

ATG - how to prevent Cross-Site attacks using _dynSessConf parameter

Cross-site scripting attacks take advantage of a vulnerability that enables a malicious site to use your browser to submit form requests to another site. In order to protect forms from cross-site attacks in ATG, you can enable form submissions to automatically supply the request parameter _dynSessConf , which identifies the current session through a randomly generated long number. On submission of a form (using dsp:form tag) or activation of a property setting (using dsp:a tag), the request-handling pipeline ( DAFDropletEventServlet ) validates _dynSessConf  against its session confirmation identifier. If it detects a mismatch or missing number, it can block form processing and return an error. To disable this functionality, we could give the following properties (@ /atg/dynamo/Configuration to disable it globally) enforceSessionConfirmation  = false -->  specifies whether the request-handling pipeline requires session confirmation in order to proc...
1 comment
Read more

ATG Search Indexing - overview of different steps in search indexing

Read more about the search indexing behind the scene steps @  http://tips4ufromsony.blogspot.in/2011/12/atg-search-indexing-behind-scene-steps.html ATG Search prepares searchable content by indexing the products specified in the XML definition file (/atg/commerce/search/ProductCatalogOutputConfig). Generally there are two types of indexing 1.  Full Indexing  --> all data taken for indexing 2.  Incremental Indexing --> only changed data will be taken for indexing When full indexing is triggered, following happens:    1. The out of box component BulkLoader will call IndexedItemsGroup.getGroupMembers() to load the products to the XHTL document. It prevents uncategorized products from getting indexed. The definition file format begins with a top-level item as a product and includes the properties of parent category and childskus. For each product, the set of Variant Producers configured in ProductCatalogOutputConfig is execute...
2 comments
Read more

ATG - quick reference to commonly used DSP Tags

In this blog, I would like to give a quick reference to the most commonly used DSP Tags.Note that in this DSP tag details : bean refers to a Nucleus path, component name, and property name param refers to a Page parameter value refers to a Static-value var refers to a EL variable id refers to a scripting variable ============================================================== 1.dsp:importbean     example: <dsp:importbean bean="/atg/dynamo/droplet/Switch"/> ============================================================== 2.dsp:page     usage: It encloses a JSP. The dsp:page invokes the JSP handler, which calls the servlet pipeline and generates HTTPServletRequest.    example:    <dsp:page> ..... </dsp:page> ============================================================== 3.dsp:include     usage: Embeds a page fragment in a JSP.     example:   <dsp:include src="/myPage/Result...
9 comments
Read more