WorkflowServer + DataSnap + IPC - EOSError

Dear TMS team,
I'm trying to setup a Workflow server with Restful API exposure.
I first added a Datasnap component directly into the project, and 1 method was created that is starting a WorflowInstance by Name.  When the process get executed, I've got the following

ERROR:
Project WorkflowServer.exe raised exception class EOSError with message 'System Error.  Code: 1400.
Invalid window handle'.


The Debugger stops at LiveDiagram.pas line 1888 - the end of TLiveDiagram.DoOnTerminate procedure.
I can confirm that all other blocks where executed from the flow chart, it hangs on the END block.
First I thought this is because Datasnap is running new thread for every request, which results in synchronization between the Workflow component and the thread resulting the exception, so I  decided to change my approach.
I have how implemented IPC (http://www.cromis.net/blog/downloads/cromis-ipc/).

Inside the workflow server I have a IPC with a named Pipe, and on the Datasnap server (another application) I have implemented the client.

Both Workflow & Datasnap are running in 1 PC, so far so good, all works well, but unfortunately I run in the same problem but with a different exception:
Project WorkflowServer.exe raised exception class EOSError with message 'System Error.  Code: 5.

Any idea or guidance on how I can run Workflows calling them remotely will be gratefully appreciated.
Thanks,
Kamen
Access is denied'.


sorry, the second message error message is as follows:
Project WorkflowServer.exe raised exception class EOSError with message 'System Error.  Code: 5. Access is denied.

I don't know how my text got in between.

Workflow Studio is not very suited to run in server applications. It's based on diagram which in turn is based on graphic lib (gdi/gdi plus) and also uses the application main thread which can cause problems in server applications.

Hi Wagner,
thanks for getting back to me.
Yes I've realised that, so I can use it without a problem as a single thread application.
What I've done (again not the most elegant solution) was to implement a Queue using database...
So if a client want to start a new WfInstance, he will send a command via Datasnap, which will be queued (inserted in a database) where the WfServer will pick up on it's next iteration for RunPendingWorkflowInstances.

I was just wondering if you have any other thoughts on how this can be improved?
Cheers,
Kamen

Hi Kamen, improved in which sense, you mean? If you have it running in such a "hostile" setup, it's already a win :-)

I must admit, this reply just made my day! lol!
Cheers :)
K.