Exporting data for multi-PPD index

Just like 1PPD index, here users need to define configuration and data modules.

• In the configuration users would need to configure each entities and their fields. Under the array rootEntities, users just need to define all the entities. What is important here is that the relationship between entities should be defined using the field parentEntityIdentifier.

• Users would require data sources for all these entities and a module corresponding to each. Contents of these modules would be pretty much be similar to what was was already explained in Migration of Items of any Catalog index except that they would be entity specific.

What differentiates a 1PPD index from multi-PPD index is that, there are relations present between different entities. The way 1PPD template was defined, exported data would not have enough information to create a document with the parent and children information in every record. To fulfill such a requirement, primarily 2 things are required:

1. Some way to identify the parent or children record in the exported data.

2. Ensure that if any record from the hierarchy is getting exported then it's parent and all it's children and their children and so on are also exported. In short, full family gets exported each time a member gets exported.

Identifying the parent

For the purpose of identifying the parent, a new field is introduced for multi-PPD configuration. This field is called RecordJoin.

• RecordJoin would have a string value at the root of the hierarchy.

• RecordJoin would contain object as value otherwise, this object contains two fields:

  • name This field specifies the entity identifier for that record.

  • parent This field specifies the parent record's internal id along with it's container in the format of id@container

For example,

If there are 3 entities present in the system namely, Product2G, Variant, and Article. They are related as Product2G parent of Variant which is a parent of Article.

• RecordJoin for Product2G would look like this

  {?JSONStringElement "RecordJoin","Product2G"}

• RecordJoin for Article would look like this

Ensuring export of single record exports it's whole hierarchy

In order to achieve this goal, all we need is a few more data sources. The good thing is all that user needs to do is, create a module based off of these data sources and just copy paste contents from the data source which represents it's entity.

For 3PPD paradigm, modules are as mentioned below:

Migration of 3PPD template from v10.0.0.0

Templates are much simpler than they were in v10.0.0.0. Following steps would help a user in migration:

• Config stays the same.

• New language variable needs to be defined and logical keys based off of language need to be qualified using this one. (Optional)

• Users would need all the data sources that are defined above and a corresponding module for each.

• Deleted products and deleted variants stay the same.

• Copy the contents of New and changed products to all the above Product2G modules. (along with the sub module).

• From New and Changed Variants, remove the routing field. Remove the Higher-level Product sub module. Copy all it's contents to all the new Variant modules as mentioned above. (along with sub modules)

• Remove all the other modules.

• Define new modules for item. Copy the contents from an items-only template and paste it here on all the modules along with sub-modules. Add the RecordJoin field as mentioned above.