This page provides a general overview of all subsections of the output module and how they depend on each other. This helps to understand what the module is doing in which phase of the mapping process.
Basically, the module is going through four phases in order to map documents from synQup to Shopware:
- Sanity Checks to check if the module can be executed at all
- General preparations to speed up the actual mapping of data to shopware, e.g. by warming up caches
- Progress initialization
- Mapping documents to Shopware
The phases run strictly one after the other. Wherever possible, all subsections are initialized with a progress value before the module actually starts to transfer data.
You can find more details about each phase below.
Sanity Checks (Phase 1)
Sanity checks verify that the module can be executed successfully. This is done to prevent errors during the execution of the module, for example by ...
- ... checking the configured Shopware API integration
- ... validating if configured Shopware uuids are available in the target shop
- ... searching for configured languages and salutations in Shopware
If a sanity check fails you will be notified. In that case the module stops its current execution by not finishing the
General Preparations (Phase 2)
Extracting Embedded Documents
extract-embedded-document extracts certain
EmbeddedDocuments from their
BaseDocuments before processing them in
the mapping-subsections. This is done to increase the performance while mapping embedded documents and to be able to properly
initialize progresses before mapping embedded data.
Payments (to map payment methods) from
extract-embedded-product-info extracts properties (
PropertyValue), units and cross-sellings (
Build Category Trees
category-tree generates two category trees, one for synQup and one for Shopware. Those trees are used to derive
operations to synchronize the tree structures between synQup and Shopware. The operations are executed in the
category-tree-shopbuilds a tree from the Shopware categories
category-tree-transferbuilds a tree from the synQup categories
category-tree-comparecompares both category trees and generates operations to synchronize categories between your transfer data and Shopware
cache-warmup reads data from Shopware that is reused across several subsections, for example languages, locales
Progress Initialization and Inspection (Phase 3)
Before the module starts to map documents to Shopware, the progress for each individual subsection is calculated. This greatly increases the overview on the "Flow Executions" page of the synQup frontend since it is already visible how many entities of which type are going to be transferred.
Note that the calculated progress is not final for
If invalid documents (= documents that are
not mappable to Shopware) are detected before sending them to Shopware, the progress count is reduced. This means that the "upsert"
progresses are realistic representations of the actual count of documents sent to Shopware after the module is done.
Furthermore, this step is used to check the progress counts of subsections that delete entities from Shopware. If the progress is abnormally high, the anomaly detection process is initiated.
Document Mapping (Phase 4)
A subsection that transfers documents to Shopware basically consists of the following subtree of subsections:
output └───entity └───entity-build-cache └───[entity-delta-count] └───[entity-anomaly-check] └───entity-validate └───entity-upsert └───[entity-delete]
The sections shown in brackets are only executed in subsections that support the deletion of entities.
For each document, the module searches the corresponding Shopware entity and writes it into a cache. This is done in the
Delta Count & Anomaly Check
anomaly-check are part of
the anomaly detection. Please refer to the
documentation of the anomaly detection for details.
delta-count subsection basically checks how many of the documents marked with a deletion flag will actually be removed from
Shopware. The subsection
anomaly-check checks the previously calculated delete-count for anomalies.
validate subsection checks for each document if it can be transformed into a valid Shopware entity. If this is not the case the
upsert progress is reduced. Please refer to
the validation documentation for details.
Each document is transformed into a Shopware entity and then sent to the target shop via Sync API. You can find more information about this process in the documentation for upserts and the Sync API.
Each document, if the corresponding Shopware entity (still) exists, is transformed into a delete request and deleted via Sync API. You can find more information about this process on the delete-concepts page.
Mapping Subsection Dependencies
Open images in a new tab for a full screen version of the diagrams
The "mapping-subsections" (= subsections that are mapping documents from synQup to Shopware) are partially dependent on each other. This means that a subsection can only be completed successfully, if another subsection has been completed first. If the module detects that a required subsection is deactivated the execution will be stopped during the sanity checks.
The dependencies of the subsections are shown in the following figure:
Detailed Module Flow
The following diagram is a representation of the parent-subsections and their dependencies on each other:
The following diagram is a representation of all subsections (including child-subsections) and their dependencies on each other. For a better overview there are no lines between many child-subsections. In that case the subsections are executed from top to bottom.