Implementing Partial Indexing in Endeca

Hi all,

    After Spending more time with the Partial Indexing, I am Writing this posts, so it could be useful for the other people trying to implement the Partial Indexing for their Projects.

Usually all the Projects, would have Configured the Baseline Indexing in the Scheduled Manner, If We have got the Requirement of Indexing the Inventory From Endeca , Will think of Having the Partial Indexing Configured for the Scheduled Manner, the Constraint is that it cannot pick up the Changes, Since the Inventory Comes or updates as part of the Feed Process.

Before pitching in to the Discussion of that, let’s see what are all can be achieved with the Partial Indexing.

When the Deployment is made from BCC by Creating a new Proj will update/add the Properties , if the Properties Belong to the Same Repository.ie Adding the Promotion will not reflect after the Deployment and the  Partial Indexing , the Reason is that the Promotion belongs to the Different Repository not the Product Catalog.

So , How Does the Flow Goes or what is Behind the Scenes of the Partial Indexing ? .

Before Knowing the Flow, we all should aware of the Basics of Partial Indexing.

Basics of Partial Indexing

There is a Repository called the Incremental Item Queue that is Responsible for Triggering the Partial Indexing. We have a Property called the Monitored OutputConfigs that should have our Config paths eg: ProductCatalogOutputConfig , Article OutputConfig.

There Will be Generation Id Associated With the Each OutputConfig Paths. So During Deployment the Sku or the Product, or Article Will be Added to this Incremental Item Queue Repository along with the Generation Id and the Item Descriptor . During the Partial Indexing this table will be Flushed out by submitting those to the Indexing . If the Products are not loading as part of the Partial Indexing after knowing that Items are avalaible in Incremental Item Queue Repository, then the Problem with miss match of the GenerationId.

You are also should be aware if the Tables from the DB Where these Operations take place.

srch_update_queue: this Table Where will be having the

config_repo_id will be the Config id of the output config path .

item_desc_name will be the Item Descriptor name .

repository_id is the Id of the updated product / Sku .

generation is the value of the Current id .

change_type is the value of the Change Type .

please find the Below Example .

values ('14500010','product','product101','2279','0');

srch_config this table is the Place where will be getting the Config Repoid and Generation for the Particular Config Path.

So now you are aware of the Flow of Partial Indexing Flow. If your Requirement to Indexing comes as part of the Feed then you have to identify the Changed Items and Write explicitly in to the Incremental Item Queue and Scheduled the Indexing of the Partial then it will take.

If your Property Belongs to the Different ItemDescriptior or Repository , make sure that you are making the Linking to any of the property in the Product Catalog  after linking only it will be taken as part of the Indexing otherwise will not be taken.

Only those Properties that will not be added as part of the BCC Deployment , We have to Write Explicitly in to the Incremental Item Queue. Others not Required .

So Keep this Information or the Constraint in mind Before Start Implementing to your Application .

Happy Learning.!!!!!