Documentation Content

#Introduction

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:

1. Sanity Checks to check if the module can be executed at all
2. General preparations to speed up the actual mapping of data to shopware, e.g. by warming up caches
3. Progress initialization
4. 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 subsection sanity-checks.

#General Preparations (Phase 2)

#Extracting Embedded Documents

The subsection 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.

The subsection extract-embedded-customer-info extracts CustomerGroups and Payments (to map payment methods) from Customers. extract-embedded-product-info extracts properties (PropertyOption and PropertyValue), units and cross-sellings (Relations) from the document Product.

#Build Category Trees

The subsection 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-mapping-subsection.

Summary:

• category-tree-shop builds a tree from the Shopware categories
• category-tree-transfer builds a tree from the synQup categories
• category-tree-compare compares both category trees and generates operations to synchronize categories between your transfer data and Shopware

#Cache Warmup

The subsection cache-warmup reads data from Shopware that is reused across several subsections, for example languages, locales and salutations.

#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 -upsert subsections. 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.

#Build Cache

For each document, the module searches the corresponding Shopware entity and writes it into a cache. This is done in the -build-cache subsection.

#Delta Count & Anomaly Check

delta-count and anomaly-check are part of the anomaly detection. Please refer to the documentation of the anomaly detection for details.

The 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

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

#Upsert

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.

#Delete

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.