You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The *Dynamic Multistore*feature lets you create and manage multiple stores within the same region in the Back Office. It streamlines the setup and maintenance of distinct stores tailored to various customer segments, regions, or product categories.
17
+
*Dynamic Multistore*(DMS) lets you create and manage multiple stores within the same region in the Back Office. It streamlines the setup and maintenance of distinct stores tailored to various customer segments, regions, or product categories.
18
18
19
19
In the Back Office, in the **Administration <spanaria-label="and then">></span> Stores**, you can view the list of stores in the current region. The **Stores** page shows all the stores within a specific region.
20
20
@@ -106,9 +106,58 @@ To avoid manually assigning entities in the Back Office, you can assign them usi
106
106
107
107
## Differences in modes
108
108
109
-
## Deployment file difference
109
+
This section describes the differences in different parts of application in DMS on and off modes.
110
110
111
-
### Environment variable section
111
+
112
+
113
+
## Differences between applications with and without Dynamic Multistore
114
+
115
+
In this example, EU region has DE and AT stores. US region has a US store. Dynamic Multistore introduces the following changes in this setup:
116
+
117
+
- URLs for Storefront, Back Office, Merchant Portal, and Glue API contain region instead of store name. For example–the URL of the Back Office is `https://backoffice.eu.mysprykershop.com` instead of `https://backoffice.de.mysprykershop.com`.
118
+
119
+
- RabbitMQ virtual hosts contain region instead of store. For example–`eu-docker` instead of `de-docker`.
- Redis keys contain store as a part of the key name for Dynamic Multistore enabled and disabled modes.
138
+
139
+
- When Dynamic Multistore is enabled, customers can switch between available stores for a region. When a customer changes a store, it's set to the `_store` query parameter. Using the query parameter, the store is added to session under the `current_store` key. It's used for fetching store-related data.
### Store context in different applications with Dynamic Multistore
146
+
147
+
All the applications work with the several stores within one region with the following differences:
148
+
* Back Office and Merchant Portal operate with data from all the stores within a region and don't require a store context.
149
+
* Storefront, GlueStorefront, and Glue require a store context and operate within only one provided store. If a store isn't provided, the default one is used.
150
+
151
+
### Cloud infrastructure differences
152
+
153
+
DMS doesn't affect cloud infrastructure. The only related changes are in the deployment files, which are described in the following sections.
154
+
155
+
156
+
### Deployment file differences
157
+
158
+
Applacation configurations are defined differently depending on whether DMS is on or off.
If a store isn't provided as a parameter, the command is executed for all stores within a current region.
238
287
239
-
### Rules for implementing custom console commands in environments with Dynamic Multistore
288
+
#### Rules for implementing custom console commands in environments with Dynamic Multistore
240
289
241
290
- `Store(Facade|Client)::getCurrentStore()`must not be used in the code the console command executes.
242
291
- All store-aware commands must implement `Spryker\Zed\Kernel\Communication\Console\StoreAwareConsole` and execute actions for a specific store if the store parameter is provided; if not provided, actions are executed for all the stores in the region.
243
292
- We recommend using the `--store` parameter instead of `APPLICATION_STORE` env variable; both methods are supported.
244
293
245
-
## How Dynamic Multistore affects a project
246
-
247
-
In this example, EU region has DE and AT stores. US region has a US store. Dynamic Multistore introduces the following changes in this setup:
248
-
249
-
- URLs for Storefront, Back Office, Merchant Portal, and Glue API contain region instead of store name. For example–the URL of the Back Office is `https://backoffice.eu.mysprykershop.com` instead of `https://backoffice.de.mysprykershop.com`.
250
-
251
-
- RabbitMQ virtual hosts contain region instead of store. For example–`eu-docker` instead of `de-docker`.
- Redis keys contain store as a part of the key name for Dynamic Multistore enabled and disabled modes.
297
+
There're no specific requirements, and the changes you need to make depend on the database structure. These entities should be handled in the same way as any other exposed through Data Exchange API database table.
270
298
271
-
- When Dynamic Multistore is enabled, customers can switch between available stores for a region. When a customer changes a store, it's set to the `_store` query parameter. Using the query parameter, the store is added to session under the `current_store` key. It's used for fetching store-related data.
The number of stores affects data import speed: the more stores you have, the slower the data import. Importing products for 40 stores takes approximately 5 times longer than for 8 stores.
278
304
279
305
## Limitations
280
306
281
-
With Dynamic Multistore, the separated setup is only possible with stores belonging to different regions. To learn about setups, see [Multi-store setups](/docs/ca/dev/multi-store-setups/multi-store-setups.html)
307
+
With Dynamic Multistore, the separated setup is only possible with stores belonging to different regions. To learn about setups, see [Multi-store setups](/docs/ca/dev/multi-store-setups/multi-store-setups.html).
0 commit comments