This service integrates in the feed import pipeline. The purpose is to transform customer supplied data into picalike supplied data. Currently we consider:

• categories (shop categories are turned into our internal category structure)
• gender
• brand
• attributes

git: https://git.picalike.corpex-kunden.de/v5/mapping-service

The service iterates over the meta_db_collection and performs the mapping for each product. The results will be stored in the document for the product under the key “mapping_service”.

• category: string [exactly one category per product]
• brand: string [exactly one brand per product]
• gender: list [multiple genders per product are possible]
• attributes: list [multiple attributes per product are possible]

• http://pci01.picalike.corpex-kunden.de:8053/ (backend)
• http://pci01.picalike.corpex-kunden.de:8052/ (frontend: mapping-tool)

bash ice_tea_build.sh && bash ice_tea_push.sh && bash ice_tea_deploy.sh

if shops are currently running, they will be restarted after deployment, so you should make sure, that no big shops are running, otherwise you are potentially completely mapping them twice

docker restart
/home/picalike/docker_bin/mapping-service/ice_tea_run.sh

Shops are usually triggered through the shop-conveyor-belt. You need to keep in mind that both the shop-conveyor-belt as well as the mapping-service keep track of an internal state. If the shop is busy in the mapping-service the start will fail silently.

The state for the mapping-service is kept in “osa-mongo.mapping_service.status” (search for busy true)… if the shop is not really running, you can just delete the entry from the status-collection or set busy: false

• the service writes some statistics in the mongo collection: mapping_service.status
• the service should at some point take over as the brand mapping service (currently in solr_updater), but the collections were never moved from osa_db.brand_* to mapping_service.brand_* . although the service is configured to use the currently correct collections in osa_db.brand_*, it is not recommended to switch to this service (not tested)

To rename a category, use the script one_time_mapping_changes.py from the git repository. It is not fully parametrized, so it needs some adaption before it can be used. But the rename is just a series of update_one in two(!) mongo collections.

A visual mapping service skeleton is implemented. Check the repository and the wiki page. For now, it only adds color information, but it's not deployed anywhere. It's a work in progress that has been put on hold together with OSA and it's referenced here for knowledge purposes only.

The category mapper relies on the Mongo Collection osa_db.category_relation

The Mongo Collections involved are:

• mapping_service.picalike_categories
• mapping_service.shop_categories
• mapping_service.category_mapping

The brand mapper depends on the following collections:

• osa_db.brands_picalike
• osa_db.brands_shop
• osa_db.brands_mapping

The gender mapping uses:

• osa_db.gender_relation
• osa_db.gender_category_text_relation