Timeouts when rendering large Sets in DirectSmile Integration Server

Sometimes you may receive a time out if you render as large Set. The DSMI Backend service considers a time out as hit, when a Production Server that is assigned to a specific render job does not transmit its current status in a configured period of time. The default time span is 20 seconds. Just to be a bit more certain here, we talk about the time it takes the Production Server to render one specific action (i.e. a heavy graphical effect).

If you are experiencing such time outs you have two options:

Turn Auto Scaling on
DSMI comes with a new feature called auto scaling for DirectSmile Sets. This feature is turned off by default, but it’s worth to be turned on, at least for some of the Sets that take longer than others.

If turned on you can choose if you like to create a specific scale while you maintain the catalog and upfront before you actually request specific size.

Or you can activate general auto scaling that scales a Set on demand when a specific size is requested. If the requested scaling is not available DSMI starts internally a second thread that provides the scaling for future calls and renders the request image in parallel. The next request uses then the scaled version.

Increase the short time out in the DSMI Backend config
If you optimized the performance of your Set using the auto scale option and you are still experiencing time outs when the Set is rendered you may hit a time out thrown by the DSMI Backend. This leads into a restart of the Production Server originially assigned to the job. Such a restart of a Production Server is mentioned in the Backend Monitor and log file by the way.

The default is 20 seconds, but you can increase it in the DSMOnlineBackend.exe.config file. The file is located here (assuming you have installed DirectSmile applications on the C: drive):

C:\Program files (x86)\DirectSmile\Directsmile Online Backend\DSMOnlineBackend.exe.config

You want to increase the following value in the config file:


Again, this time out is only hit, when a specific render calculation takes more than 20 seconds. But some of the Sets make it necessary to increase this value, especially if you are printing in A3.

What to do if the DirectSmile Integration Server services are inaccessible

Today I would like to list some of the typical reasons why DSMI services fail to initialize or why you can’t access those services. Below you will find a short to-do or what-to-check list, that I’m going through when ever I have problem. Those are all things that you can easily do.

Multiple SSL Certificates

DirectSmile relevant certificates are stored in the localmachine/my certificate store. Please check if you have just one certificate with the common name that is addressed in the web.config file of DSMI. If you have multiple certificates, then it’s impossible for the web server to distinguish between the certificates and the initialization of the WCF services will fail. This error is often the case if you requested a new certificate from your CA, because the old expired and you forgot to remove the old one from the store.

Compilation error

Open the workflow URL in the browser to check if the typical WCF generated info screen appears. The URL would look like: http://SERVER/dsmo/workflow.svc

If successful you should see something like:


If not, you receive a HTTP 500 (Internal Server Error) Status Code.

Fiddler Test

Run Fiddler on your client and browse to the workflow or repository manager. Check if fiddler reports any errors. If you don’t have Fiddler installed go check: http://www.fiddler2.com/fiddler2/

Server Event log

If you have access to the server, a check in the event log is always worthwhile. Typically you will find errors indicating why a service could not be started.

Server Time vs Client Time

The time difference between the client and server is immanent to establish an SSL Connection. The difference must be less than 5 minutes between the server and the client. This is independent from time zones, because the server and client local time is always mapped to GMT.

Crosssite Scripting

To allow the Silverlight Clients like the Workflow and the Repository Manager to connect to the DSMI server the server must provide a so called ClientAccessPolicy.xml file in the web servers root folder. This file contains a straight forward set of rules, that tells the webs server to allow access to http/https applications or not.

Important in our case is, that it explicitly allows https access, like this file:


WCF Tracing

If all those checks from above were fruitless, you could activate WCF event tracing in the web.config file of DSMI. But maybe this is something you want to do together with the DirectSmile Support Zwinkerndes Smiley

New font installation feature in DirectSmile Integration Server

Exporting and installing fonts is not an easy approach. There are actually many hurdles to overcome, while finding a font on the source machine and finally installing it on the destination machine. Applications running in a remote desktop initiated user session behave tricky from an installation point of view. And while the User Access Control is a blessing on modern Windows based PCs it’s a burden if you try to deploy fonts automatically. Another important factor is the font header information stored in the font itself. The information provided in the header is unfortunately not always enough to distinguish a specific font.

Having those issues in mind we rewrote our font installation from scratch and we now come up with a complete approach. Especially the export includes some straight forward conventions, we think are necessary to make.

Export a Set including system fonts

Let’s say we have a Set that uses two  fonts. Like this one here:


Usually if you export a Set that includes system fonts, the font will be found and automatically added to the export archive. Sometimes though, the font could not be found the VDP Studio designer. Unfortunately this did not produce any error message.

Exporting the Set above would cause trouble, because only one font would be exported. The second (a font called Rosewood Std Regular) would be silently removed and not installed. Even worse, it would not be part of the archive. And if you would place the font in the destination folder by hand, it would be removed automatically from this folder, because for the same reason, that it’s just not part of the archive.

We changed this behavior. Now we will show a message box, showing a list of all fonts that could not be found while the export. Then you have the option to copy the font manually to the source Set directory. Following the convention that all fonts located in the Sets folder are automatically part of the export archive, those fonts are definitely included even the VDP Studio designer struggles to find the font itself. We also included a logic that tries to map the font family name to the file names of fonts located in the Set directory to avoid unnecessary listing of  already added by hand. (Although, we cannot promise that this will work for all fonts)

Installation on DSMI

If the font is included in the archive, DSMI adds a record in the dsmodb database telling the DSMI system to install the font. This information is read by the DirectSmile Watch Dog and installed in the system.

We added all this functionality to Watch Dog, because we found a reliable application that runs in the user context and is available all the time.

To avoid patching the configuration file of the Watch Dog by hand, we added the new Watch Dog to the DirectSmile Online Backend installation directory. The necessary configuration is now automatically done by the DSMI installation.

The result of the font installation is persisted in the database and shown in a balloon info in the Windows sys-tray.


After that the font will be immediately available for any application in the system.

DSMI Replication

We use the dsmo database to ensure that the installed fonts are replicated over different DSMIs. If you are using a replicated DSMI we recommend to update you DSMI to this version.

Possible ways to upload items to DirectSmile Integration Server Part 2

As I showed in this article Possible ways to upload items to DSMI, we provide many different ways to upload items to DSMI. There was one piece missing though. That is http based upload from inside the VDP studio.

We now added http upload functionality to the VDP Studio and DSMI.

It works in the same way as uploading items using ftp before. The VDP Studio now checks if the DSMI is supporting http upload. If the DSMI supports http it initiates an http transfer to upload the item. If the DSMI is not supporting http upload the VDP Studio falls back to ftp again.

On the other hand, the latest DSMI still supports ftp, if the VDP Studio is older and does not support http.

Although the VDP Studio and the DSMI is downward compatible we recommend to use http instead of ftp. If both application do support http, the VDP Studio will always use http.