Communicating with InDesign Server

Overview

This post assumes you have InDesign Server running as described here perhaps.

A lot of useful information is in a PDF document called "Intro to InDesign Server 2020.pdf" which is in the InDesign Server installation folder (for me C:/Program Files/Adobe/Adobe InDesign Server 2020/Documentation/English).

WSDL and SOAP

I didn't open up our Azure VM to the internet so interacted with it using localhost. The WSDL is here (substitute 18383 for the port number you configured to run InDesign Server on).

1http://localhost:18383/service?wsdl

You'll notice there is just one method called RunScript() which does exactly that - runs a script you ask it to. I'm guessing they are automating the same run script functionality of the desktop version of InDesign. There is a brief history of InDesign Server here that makes it sound like that's what is happening.

It would be simple enough to reference that WSDL in code and start calling into the InDesign Server API. But the SDK comes with a bunch of samples and sample code...

InDesign Server SDK

The SDK is here https://developer.adobe.com/console/servicesandapis/id

I downloaded the same version as the InDesign Server I have running. v15 of InDesign Server maps to App Version 2020, Download Version v1 - Nov 2019 of the SDK:

InDesign Server SDK download

Sample Code and Applications

The SDK comes with a bunch of sample code and a "SampleClient" application that you can run from the command line.

The documentation is at server_sdk_15.0.0.155/server/docs/html/index.html

I gravitated towards the ASP.NET sample at server_sdk_15.0.0.155/server/samples/sample-client/aspnet/sampleclient-aspnet-cs-soap. It's a Web Forms app and needed a bit of fiddling to get working - I wouldn't run it on a production server.

  • It required IIS with .NET 3.5 and 4.7 (ASP.NET) installed
  • Create a website using the code provided (server_sdk_15.0.0.155/server/samples/sample-client/aspnet/sampleclient-aspnet-cs-soap)
  • Assign it to port 81 (or whatever port you prefer)
  • Change the App Pool to use ASP.NET v2 (not 4)
  • Allow the App Pool identity "Full Control" on the directory where the scripts will be running (IDS_Scripts)
  • Copy the IDS_Scripts directory that up one directory into the sampleclient-aspnet-cs-soap directory. I couldn't get the sample to work without doing this. But it meant I had to change the path to the directory on line 29 of Default.aspx.cs from
1String kScriptsFolder = "../IDS_Scripts/";

to

1String kScriptsFolder = "IDS_Scripts/";
  • And then you should be able to run the site (https://localhost:81) and it should do valid stuff (on a VM with no GPU this timed out)

InDesign Server also comes with a command line tool called sampleclient.exe. For me this is in C:/Program Files/Adobe/Adobe InDesign Server 2020.

And using the scripts mentioned above from server_sdk_15.0.0.155/server/samples/sample-client/IDS_Scripts you can do something like:

1sampleclient -host localhost:18383 <path to SDK>/server/samples/sample-client/IDS_Scripts/MakeDocument.jsx 

InDesign Server Scripting

The scripts you can run against InDesign Server are exactly the same as the ones you can run using the Desktop version. As we have a Windows VM in Azure we can write these scripts in VBScript or JSX (if you run InDesign Server on a Mac you can use AppleScript instead of VBScript). We decided it would be sensible (?) to use JSX.

The scripting environment is geared, understandably, towards doing InDesign-y desktop-y things. I was able to manipulate files and folders but not download files from the internet or shell out to run wget for example. But this is likely my failing so I'll revisit this if I get something like that to work.

Plugin, COM or .NET

The documentation also mentions the possibility of writing a plugin in C++ or a COM component in VB6 to call directly into InDesign Server "Your best bet for creating an InDesign Server COM component is to use Visual Basic 6". I haven't done one of them in 20 years! So .NET is out, or at least triky to get to work. I think with the limitations of the scripting environment we'll end up writing some .NET code to live on the server alongside InDesgin Server to do the logistics around picking tasks up off a queue, downloading file packages, unzipping them and reporting back to an API.