This content has been marked as final. Show 2 replies
Two things. :)
First, you can indeed send a response from the script back to the client. A simple case would be a string as the last statement in the script.jsx (If you have the server, then you got a set a sample scripts with it... try opening up 'HelloWorld.jsx' and adding a single line to the end:
You'll see it returned from the test client. Of course the return type doesn't have to be a string, it can be a number, or a collection, or any of the types called out in the WSDL file -- the string is just the easiest to try.
Second, providing your own SOAP server in the application seems like it would work, but I don't think Adobe has any samples around that, so you'd have to figure out how to build the SOAP server inside a plug-in yourself. Alternatively the SOAP server can sit outside the InDesign application. Then you'd have a couple of choices in communicating with InDesign Server... you could build WTManager still and it would talk to the external SOAP server through some other mechanism (shared memory, a socket, whatever) or, the SOAP server could then use OSA/COM to drive the server. The advantages there is that your SOAP server could provide a job queue and could drive multiple instances of InDesign.
I'm very grateful for your helpful reply. Particularly for putting to rest my worries about obtaining return values from scripts. I sort of assumed the "result" fields was just for the script interpreter to be able to report syntax and/or execution errors. Guess I need to learn to read code & docs more carefully :)
I'm sympathetic to the idea of an external SOAP server component, but am not sure how to set up my "WT manager" to be receptive to requests from the outside.
In any case, time is precious, so the scripting strategy seems much more appealing at this point. Thanks again!