SOAP and ASYNC-Triggers

Author: (istiller)

Hi Simple question: Does SOAP and ASYNC-Trigger work together? :-) Background: We do have a SOAP-service-component defined. As a SOAP instance is stateless, this instance will be destroyed just after the call from outside. To hold some information (e.g. settings,l ogon information,...) I do create another, distacched instance of a second component. The second instance will "survive" after the SOAP call and could be fetch (as the next SOAP call) from instancepool by componentname. This will works perfect by now. But then I run into a little bit of a challange. If the USERVER.EXE is killed by taskmanger or crash [okay, UnifAce will never crash :-) ], I could not issue a proper shutdown sequence. To check, if a "logon" is still alive I have to implement some "heartbeat" functionality. $TIMEOUT=1 and a little bit of programming in ASYNC-trigger and voila ... Shit, nothing will happen, the ASYNC ist not fired. So the question is, how to implement a heartbeat functionality? Or which trigger catch the ASNYC if there is no application shell and no instance do have the focus?   Any hint is apprecite :-) Ingo


  1. Hi Ingo, The ASN setting $TIMEOUT will only work with an interactive client application (and not on a server). You could use the UTIMER component instead for your heartbeat functionality. This will work with a UServer. I'm, however, not sure how this would help when the UServer process is forcefully killed or aborts. Hope this helps. Daniel

    Author: diseli (
  2. Hi Daniel I just tried UTIMER: Nope, doesn't work either :-( If there are more then one USERVER started (same UST), only one got the messages. Ingo

    Author: istiller (
  3. Hi Ingo, Sorry, my bad.Confused I should have remembered this (documented) limitation. Embarassed When using the UTIMER in a Uniface Server then it runs in a separate thread from the main userver process and the communication is done via the Uniface Router. And at the moment it's unfortunately not possible to address a specific shared UServer (or all of them) with UTIMER (or postmessage). So my suggestion would only work if you would limit the number for the specific UST to 1 (which would probably create an undesired bottleneck for the SOAP clients). So instead of storing the mentioned info in a instance you probably have to look for alternative ways (e.g. storing the info in a db table and add an expiration date to the data). But maybe someone else has a better idea how to tackle this. Daniel

    Author: diseli (
  4. Also, due to the stateless nature of the connection and multiple uservers per UST, you might not get back the same userver process you had on the first call, meaning that storing the persistent data in memory on the server is not likely to work in a multi user environment.  Better is probably a 'session id' with the data stored in a database, with a standard proc updating the 'last accessed' time of the stored data, and a timeout feature removing all data not accessed in an hour, or two.  You could have a process fired on the server which 'pinged' the client application using a web-service the other way, and preserved the session info if it got a response.  Iain

    Author: Iain Sharp (
  5. Hi Iain We use SOAP to communicate between two applications with allways the same session-information. Only reason for having multiple USERVER running is load balancing. So there is no need for switching between different "environments" on every call. Problem we do have, if (for what ever reason)  USERVER crash, there is still a session record in our database. This records have enough timestamp (logon, logoff, last activity,...) so it is possible to set such a session to "gone" But after wich time I should do so? At day there a calls to the SOAP-interface every few seconds, at night there will be no one for hours. So my idea was to implement a heartbeat which set the "last activity" timestamp every minute And there it is, the problem with SOAP and ASYNC :-) A second idea was to have a monitor programm and send USERVER a message. If there is no answer, then kill the record. But same problem as I could not send a distinct USERVER. a "vicious circle" :-) Ingo

    Author: istiller (