Hi DW,

Ultra short description of the request, because it's rather long… sorry for that.

The request is to add a "demo" categorization in the license for website, shop and products - which allows a "demo" site to exists on our customers solutions next to their own sites in our development/test environments. Without the site counts towards their license "max" amount of websites, etc.

In our scenario, we need to ensure we always have a website spot for the "Swift B2C demo shop" in development/test. To address that need, "Swift B2C demo shop" would be a perfect example to turned into that "demo" site.

Intro context

The request for this comes because we're looking into a way to easily work with, and upgrade to, newer swift versions - especially when it comes to new swift content. To give some context for my request for this kind of setup, I'll try to briefly explain our current process.

We already have procedures when working with swift Files. We have a setup where we work with custom file versions of the standard swift files, and one where we maintain our custom code directly in the standard files - which is our new approach.

The solution I've just upgraded is the custom files versions one, and was upgraded from swift version "1.15.0" to "1.26.3".

Upgrading to a newer swift version

To prevent the post being too long (or atleast try), I'll only dive into the process of upgrading swift content.

But to give some context, here's a short description of the whole process I used for this upgrade: I start of by upgrading DW version to the newest version. I go to https://github.com/dynamicweb/Swift and get the lastest Swift release Files folder, and the NoEcom database bacpac from https://doc.dynamicweb.com/downloads/swift and sets it up on my local sqlexpress db. I setup a local "upgrade" site in my IIS, which points to the same "Application/Admin" folder of the custom solution I'm upgrading, but it uses the new swift /Files folder and the new NoEcom database. I then basically just overwrite the custom /Files folder with the new swift release /Files.

Then I move onto upgrading of the swift content via the deployment tool, from the "upgrade" site to the custom solution.

Since I've already merged the newer /Files into the custom /Files of the solution I'm upgrading, I only need to deploy the "Ecommerce" part and then "Content".

Upgrading swift content

But upgrading "Content" can be a real headache for multiple reasons.

If the custom solution has changed the standard swift shop for testing/demoing.
If the custom solution has removed all the standard swift shop content, and populated it with their own content so it's their "main site" - the deployment tool compares the "upgrade" standard swift shop with their custom site, because its sees it as the same site.
It can be hard to identify if existing if an existing "feature" has been updated or if it's just minor content changes.
- A quick example of top of my head: when product search was expanded to product search and content in the same service.
The deployment tool is hard to navigate and use when it has hundreds of changes, since you need to click each box manually if you don't want all content.
- Example: I see "Email" and "System Email" only exists on the "upgrade" sites content, so it's a new feature - but I can't just select the the top "Email" parent page and say I want every child page checked aswell. I have to manunally select them all.
Sometimes the deployment tool fails, which means you have to go click all the boxes again.
With the deployment tool open, I usually also open both the "upgrade" site and the custom site. Then I compare the content in the administration since I feel it gives me a better overview of the content, and I can inspect the content directly and see the actual changes - instead of the "Details" text comparison the deployment tool gives. So I end up with 3 browser windows, one for each administration, and one with the deployment tool where I check off the boxes with the content I want.

Addition of "demo" categorization in licenses

The biggest "wish" in this post, is for the addition of "demo" content categorization in the licenses. With the demo content having their own "max" amount in the license information. My thought was it could consist of 1 demo website, 1 shop and 200 demo products - which the "Swift B2C demo shop" is a perfect fit and use case for.

The reason for swift standard shop to be marked as "demo", comes from a potentially issue one of my colleagues mentioned. What if our customers are already using the max amount of websites, shops, products, etc., allowed with their license. Then we have no room for making this clean upgraded swift standard swift shop, in their solution.

Some thoughts for the data itself in SQL and how to separate it could be

All the demo related content could have their own (new) dedicated SQL tables, so it's completely separate from touching any "real" content.
- This is probably overkill and too much effort to implement, since it requires a lot of underlying changes in how DW handles data
The existing tables which potentially could contain demo content, could get an extra "IsDemo" column which would be set to 1/true. Alternatively it could just be added to the Area and Shop table, and any data that has a relation to a shop or area with "IsDemo", is considered as demo content.
- Less overkill than option 1, but could potentially a big task aswell - since it kinda forces you have to check for area and shop relation any time you handle any kind of potential demo data.
Prepend all the necessary demo content's primary keys or ids with "DEMO", and add some sort of checks in the existing DW functionally so it can handle it as demo content if id contains "DEMO".
- Maybe a bit of hacky solution, but makes it an easier task to tackle - atleast as a version 1

Demo websites should probably also have its own demo checkout flow context, so it never interferes with LiveIntegration or other kind of ERP setup.

Reason for dedicated demo site

So my thought for simplifying the content deploy process, is where the dedicated demo site comes in. Instead of comparing content via the deployment tool, I want to deploy/overwrite the whole standard swift shop site every time - by deleting the existing standard swift shop first on the custom solution.

Then via the administration on the custom solution, in my opinion atleast, I have a simpler and cleaner way of comparing the content between the standard swift shop and the custom site, since it's on the same solution. But now I don't need 3 browsers and manually check every box of the content I want using the deployment tool. Now I can just copy the content down to the custom site.

If the custom solution is using the standard shop as a tester or populated it with their own content as mentioned above. We can make sure their custom site is recognized as a different site, than the old standard swift shop, by making a copy of their site on the custom solution to give it a new id - and then delete the old one we copied from. The deployment tool then sees the swift standard shop from the "upgrade" site as a new site on the custom solution - so we get a clean upgraded swift version of the standard shop into to our custom solution.

Pros and cons

Here's the biggest pros and cons I've thought about with this setup is:

Pros:

Makes it easier to deploy new swift content to our customers solutions (duh it's the reason for this post).
Makes it easier to add/remove unused swift features/content from their "real" solution.
- A random example: if our customer is not going to use the "Email" and "System Email" in their own custom swift shop. We don't have to copy it to their site, to prevent unused clutter. But if they at some later point for some reason want it anyways. We can just copy it from the demo site to their custom site in their test environment, without the need of setting up a new "upgrade" site, finding the correct Swift Files and database setup again. Or if someone accidentally breaks or removes a feature, we can easily restore it from the demo shop.
- With our old setup with the use of deployment tool, if enough time has passed so we've cleaned up after the original upgrade. We've removed the "upgrade" site setup with the new swift Files and clean NoEcom database - we'd have to setup the "upgrade" site locally again, find the correct swift Files versions and database version. So we usually just deploy it anyways, and move it to a "Unused features" folder. But it makes it hard to tell if the feature was a child page of Swift tools, Services or it was a root element.
Makes it easier to demo swift to our customers (and to demo the new features after upgrading) in a place where they also can access it. Since it gives us the opportunity to always have the upgraded standard swift shop directly in their solution in the test environment, because we know there's always room for 1 demo site with their license.

Cons:

Requires a bit of work from you to handle the separation of "demo" site and ecom setup, and "real" site and ecom setup. Both in the administration, in API calls and in the database tables.
Change of what licenses consists off with the addition of "Demo sites", "Demo shops" and "Demo products" - and other necessary stuff that needs to be separated.
Ensure it's not "abused" to use as an extra free website
- Maybe the demo site is only allowed on licenses where you've selected "Development", so it can't be used on live environments.

So the cons as I see it, is purely directed at you.

Alternative solutions

The most important thing for me in this request, is the need for an extra available spot in the license for the demo site.

The request for a demo shop and products, is to completely separate the demo ecom data from the customers own ecom data in their test setup - and we can delete all the "demo" content in one go, if we move the database to a live environment in case it's a new setup. It also gives us the opportunity of using the FullEcom shop out of the box, instead of using the NoEcom version and spending time setting the NoEcom shop up with their own products. So we have the full demo shop experience, with product sliders, product list, details page, cart and checkout in a default setup. Which can exists entirely on its own next to the customers own site and data.

I'm not too familiar with the current ecom and shop setup/functionality, and if it's already possible to easily separate the ecom data with the existing Shop functionality in DW. If so, it's just on us to make sure we create a shop for "real" ecom data, and keep the "Bikes" shop for demo ecom data. Maybe it could be renamed something with "Demo", like "Demo site - Bikes", so it clear what it's used for.

If it's not possible to easily have a complete separation of the ecom data, the demo shop and products. It's not a must have for now - so it could either be moved to "part two" of demo setup, or be scrapped and solved in an alternative way.

Hope you can see the need and benefits of this, and it's something that you want to move further with in the near future.

Best regards, Mikkel Hammer

dynamicweb / DynamicWeb

Dedicated demo website (and shop/products) amount in licenses, for swift developing/test environment purposes #82