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.!!!!!
