Some Q&A to SSL certificates and the DirectSmile Shop

Do I need a certificate to secure the payment providers in the Shop?
Well, it depends on the payment provider you are using. Some of the payment providers initiate transactions in a separate window, like PayPal for instance. In this case the customer starts a new transaction in a PayPal session in an extra window and the DirectSmile Shop just redirects to the PayPal server.

There are other providers though, that do callbacks to the DirectSmile Shop using a secured channel. In those cases you must provide a certificate, because you don’t want to allow such communication in an unsecured way.

Are there other reasons to install a certificate?
Yes, the shop administration rely on a secured communication between the actual (Silverlight) application and the backend services the Shop is providing. Because the administration application runs actually on your client, you want this communication to be secured as well.
We also secured the communication to DSMI. Although this effects the shop indirectly it’s important to know, that if you intent to do changes to any account’s catalog the communication with those services must be secured as well.

What’s with sub shops? Do I need an extra certificate for each of them?

Well, first of all, there are two ways to create a sub shop.

A) The sub shop is just a sub domain of the main shop’s domain. For instance, your main shop domain name is, possible sub shops could be or In those cases you could use a wildcard certificate to secure just all subdomain of *

B) The sub shop could have a different domain then the main shop’s domain. For instance, your main shop domain is and your sub shop has the domain In this case you would really need two server certificates installed.

Gotcha, but what’s with the administration of sub shops?
Generally, you can configure any sub shop from inside the administration of your main shop. If you use the administration every sub shops is providing you will either need  the wildcard certificate or extra domain certificates for your sub shop.


Possible ways to upload items to DSMI

There are many different ways to upload items to DSMI, in fact there are four. Here’s a list of all possible ways and their pros and cons:

VDP Studio to DSMI
This is the oldest way to upload items. It’s using FTP to transfer item archives to DSMI. If the FTP server is set up correctly on the DSMI server this is quite an convenient way to transfer items. Because the VDP Studio synchronizes items against DSMI it automatically transfer only items that have been changed and are out-of-date on the server.


You might consider the FTP server as a disadvantage, because this needs an extra configuration of your firewall.

Uploading single items using the DSMI Itemsbrowser
An easy way to upload archives in Zip or dZip format, is to use the ItemsBrowser. This is an http based upload which does not need any further configuration.


This upload interface does not support single files, it accepts complete archives. If you want to update an item, you have to transmit the whole package, which can be quite big in case you are updating a document.

Uploading catalog archives
Another, quite new way is to import complete catalogs. This can make sense if you want to provide a whole catalog to a new created account in DSMI. From inside the Itemsbrowser you can import and also export a complete catalog or a branch of a catalog. The exported catalog is a zip archive that includes all items and resources and an xml file that contains the catalog structure information. Those archives can be uploaded and imported into another account or even into another DSMI. Redundant items, tags and custom values will be skipped and the imported catalog merged into the existing.


Upgrading items
From Inside DSMI you can also use the Upgrade function. This function can scan DSMI an account folder for items that are not known to DSMI so far.


This is a hierarchically flat import. The items are added to the root of the catalog. The items have to be copied into the users folder on the DSMI server up front before you can use this function.

New in DirectSmile Integration Server: Streaming Interface for Catalog XML

Besides the http GET based streaming interface for DirectSmile images and documents, we now have a new interface to stream an account’s catalog in XML format. You can profit from the same mechanism, like passing credentials, sealing support you already are familiar with from the other two http interfaces.

As we did for images and documents, we have a test page for the catalog streaming as well. You can find that in the Items menu inside DSMI.


Catalog xml
The catalog xml format is a tree structure that is fully representing the hierarchy of all items and groups of you catalog. It includes all variants, tags and custom values. Here’s an example:


Tags are stored in a normalized way to reduce data redundancy. Therefore all available tags are stored in an extra xml element at the bottom of the document and each item can contain a tags attribute that holds a collection of tag ids.


Custom values on the other hand are stored in a sub element of each item.

Streaming URL
The simplest URL you could build returns the full catalog and would look like this:

You can pass different filters in your catalog request to query for items only that have a specific list of tags for instance. In this you would get a catalog xml that contains just items having those tags assigned. The resulting catalog hierarchy would stay untouched.

Most of these filters default to meaningful values. Here’s a list of possible parameters:

name parameter description
Group alias g=alias returns one group and all it’s sub items
Tags tags=tag1,tag2,tag3 returns only groups and items that have these tags assigned
Include Empty groups e=1 returns empty groups. the default is false
Include invisible groups i=1 returns groups that do not have the Show In Catalog attribute
Include Masteritems m=1 returns the master items as well as virtual items

Is it possible to install a DSMX and a Shop on the same machine?

Yes. In the end it’s all about how you want to access the DSMX and the Shop. Although there is some configuration needed. Generally it depends on how your Shop and the DSMX should be accessed by the client.

Because the Shop and DSMX register http handler to analyze all incoming http requests you cannot install both application in the root of your IIS. What you would normally do if you had to install just one of both applications.

You have two options here:
First, install one application in a virtual subfolder of the other. Or second, install both applications in separate websites.

Here’s an example:
Imagine you have the following domain registered:

You could now install the DSMX in the root and the Shop in a subfolder. Therefore, you would access a purl campaign for instance by That looks like an easy URL to our campaign. To reach the shop on the other hand, you now have to add the subfolder, like

Another option would be, to install the shop in a second website and assign second domain name to it. This could be a sub domain or a complete different domain at all. For instance or


Use CTRL+F5 to debug console apps

If you debug console apps using CTRL+F5 VS automatically adds a console.readkey and “press a key to continue” question to the end of you app. I find this quite helpful, because you cannot forget any unwanted readkey in release 😉