The DynamicWeb Provider is the fastest provider to use when adding data to the DynamicWeb database.
However, the price is a higher level of complexity when setting up the activity, compared to the more specialized providers – e.g. the Ecom Provider, the User Provider, or the Order Provider.
With the Dynamicweb Provider, data is continually added to the database, so the size of the data input is effectively only limited by your database or disk size.
When using the Dynamicweb Provider, relations between tables must be handled manually (as the table structure you access is the underlying DynamicWeb database). For instance, if you want to add products and product groups to the database you cannot limit the import to EcomGroups and EcomProducts, you also need to add the relevant rows to the EcomGroupProductRelation table and the EcomShopGroupRelations table - and define the relevant keys.
Used as a source provider
When used as a source, the DynamicWeb provider exposes all database records of the DynamicWeb solution for export — no additional configuration is required.
Used as a destination provider
Important
Please ensure that all IDs you set explicitly during an import - e.g. ProductID - contain the characters Aa-Zz and/or 0-9 ONLY. Using any other characters may cause the application to fail or behave in unexpected ways.
When used as a destination provider (i.e. to import data into DynamicWeb) you have access to more extensive settings and options.
Since the DynamicWeb Provider can be used to access the entire DynamicWeb database, you can use it to import all kinds of data into your solution.
Most of the time, however, you will be importing products, product groups and related Ecommerce data, so there are extra options available for that:
| Option | Description | Interacts with |
|---|---|---|
| Insert only new records | Inserts new records present in the source, but does not update existing records | |
| Update only existing records | When this option is ON the imported rows are updated but not inserted. When OFF rows are updated and inserted | Delete incoming rows – if this option is ON, Update only existing records is skipped |
| Deactivate missing products | When ON missing products are deactivated. When OFF no action is taken | Hide deactivated products – this option is used only when Deactivate missing products is ON |
| Remove missing rows after import in the destination tables only | Deletes rows not present in the import source - excluding related tables | When Delete incoming rows is ON, this option is ignored |
| Remove missing rows after import | Deletes rows not present in the import source - including related tables | When Delete incoming rows is ON, this option is ignored |
| Remove missing rows across all tables after import | Deletes rows from all destination tables and relation tables by considering the entire dataset in the import source | When this option is ON, it takes over the removal step entirely — Remove missing rows after import, Remove missing rows after import in the destination tables only, Delete products/groups for languages included in input, and Deactivate missing products are not applied for row removal |
| Delete incoming rows | Deletes existing rows present in the import source | When Delete incoming rows is ON, the following options are skipped: Insert only new records, Update only existing records, Deactivate missing products, Remove missing rows after import, Remove missing rows after import in the destination tables only, Delete products/groups for languages included in input, Hide deactivated products |
| Delete products/groups for languages included in input | Deletes products and groups only from the languages included in the import | If Delete incoming rows is ON, Delete products/groups for languages included in input is skipped |
| Discard duplicates | When ON, duplicate rows are skipped | |
| Hide deactivated products | When Deactivate missing products is ON, this option hides the deactivated products | If Delete incoming rows is ON, Hide deactivated products is skipped. If Deactivate missing products is OFF, Hide deactivated products is skipped |
| Persist successful rows and skip failing rows | Allows the activity to do partial imports by skipping problematic records and keeping the successful ones | |
| Shop | Restrict the import to a specific shop. Only shown in the UI when a shop has been selected — leave unset to import across all shops | |
| Default Language | Override the language used for imported data. Only shown in the UI when set to a language other than the system default — leave unset unless you need to target a specific non-default language |
Three of the settings – Delete products/groups for languages included in input, Deactivate missing products & Remove missing rows after import – are resolved in a clear hierarchy, depending on which tables are being imported to:
When both Remove missing rows across all tables after import and Delete incoming rows are OFF, the hierarchy is the following:
- IF the current importing table is EcomProducts or EcomGroups and Delete products/groups for languages included in input is ON the products and/or groups are deleted in the languages included in input
- ELSE IF the table is EcomProducts and Deactivate missing products is ON, the products are deactivated (and also hidden if Hide deactivated products is ON)
- ELSE IF Remove missing rows after import is ON, the missing rows are deleted.
Finally, the DynamicWeb Provider supports updating your repository indexes every time an activity has been run - this may have a temporary impact on performance every time an import is run.
Automatic table sorting
When a job using the DynamicWeb provider as destination is run, the table imports are automatically executed in accordance with the underlying database schema. This means that the DynamicWeb provider checks the foreign keys of the established table mappings to determine if one table should be executed after another to maintain proper data relations.