I need to write some DataSnap “middleware” between Google Glass and a SwissLog ERP system, and I am trying to figure…

I need to write some DataSnap “middleware” between Google Glass and a SwissLog ERP system, and I am trying to figure out if there are significant differences between running the DataSnap as a standalone service (or app, for debugging) – and running as a CGI ISAPI plugin for IIS on a standard Windows Server.

Will the CGI be invoked per http session – or will there be a shared session running continously? I’ve never worked with CGI ISAPI before, so this is definitively a learning “opportunity”.

Pointers to relevant documentation would be appreciated.

11 thoughts on “I need to write some DataSnap “middleware” between Google Glass and a SwissLog ERP system, and I am trying to figure…

  1. Based on other CGI stuff I have seen, I would assume “one instance per http request”.

    According to the docwiki, DataSnap does not support CGI: docwiki.embarcadero.com – Types of Web Server Applications – RAD Studio though there seems a guy who has made it work with FastCGI: https://groups.google.com/forum/#!topic/extpascal/WnvAzDS2mks

    I’d go for ISAPI and IIS resource pools (as that way it is way easier to make it support HTTPS).

  2. May I ask why CGI? If I remember correctly, CGI are console applications, communicating with the web server via console input/output. If you’re integrating with IIS DataSnap already has the option to expose the appserver in an ISAPI extension.

  3. Marco Cantù Doh – I meant ISAPI, not CGI! Not sure why CGI was stuck in my brain, but it was prolly because it came up in a verbal discussion I had just before writing this post.

    Will an ISAPI DLL have a single “main thread” across multiple client sessions?

    Where would an ISAPI DLL typically store it’s configuration data?

  4. From your DLL’s perspective there’s nothing like the main thread. Your exported function will be called by the IIS host, passing you the information about the request so you can process it and generate a response. When your method gets called, it’s just running on the current thread (and possibly simultaneously on other threads, too). If you can, try to avoid creating or managing your own threads.

  5. Hmm. That may be a problem, since the ERP system has connection sessions, user lists, vehicle lists, etc – which could be rather costly to establish and retrieve per access. Perhaps a pure Delphi service / app is preferable after all.

  6. I should mention that I’m a bit rusty with Datasnap so before implementing anything I would first research if there’s something already available, either in Datasnap itself or by a third party. Datasnap has evolved since I’ve last used it…

  7. So far, I’ve implemented the JsonRPC interface in such a way that I can embed it in any of the variants that DataSnap offers. The next layers that I need to write, is the session manager and API communication interface, which is a TCP connection to the ERP server. The initial goal is to do it all without a local database, and isolate the APIs behind a layer that will allow a port to our other ERP/WMS variants as well, hopefully without changes to the Glass UI.

Leave a Reply