Automation/Integration: Posting to existing UniGUI session to execute action

[wprins]

For automation and integration it would be useful to be able to be able to post directly to a running session to affect it's state.  How might one accomplish this?

 

That is to say, if one considers the UniGUI server as a web service, how might one post to it to affect it in some way?  Suppose a user has a browser page already open, viewing an existing UniGUI session.   It should be possible to (somehow) identify the session and do a direct POST (from another browser page) or a third party system to for example open a new page or open a new customer (say).  For a conventional Windows application similar could be achieved on one machine via posting Windows message, or across a network by having the application listen on a port for messages etc.   

 

Additionally (though this is perhaps worth a separate question), what if a new session is to be created?  I can imagine perhaps examining some params passed on URL in LoginForm FormShow() and then directing the automatic logon and interpreting of commands from there.  Though it seems a bit smelly that this logic/responsibility must be handled in the login form(?)   

 

 

[Ron]

You don't need to handle anything in the loginform, as the mainmodule beforelogin event

is called first, so you handle it there, and set "handled" as you please.

 

You can pick up the url params in mainmodule, and handle it all in the beforelogin event.

That is the logic.

 

As for posting to a session to affect its state, there is obviously a security question

if you are going to let outside processes affect a running session. The session is

and must be tightly linked to the client all the way, and I would assume you could

get concurrency issues too if you start opening up the session for outsiders

without some extra stuff handling that. Data is all about consistency, and thus security.

[wprins]

You don't need to handle anything in the loginform, as the mainmodule beforelogin event

is called first, so you handle it there, and set "handled" as you please.

 

You can pick up the url params in mainmodule, and handle it all in the beforelogin event.

That is the logic.

 

As for posting to a session to affect its state, there is obviously a security question

if you are going to let outside processes affect a running session. The session is

and must be tightly linked to the client all the way, and I would assume you could

get concurrency issues too if you start opening up the session for outsiders

without some extra stuff handling that. Data is all about consistency, and thus security.

 

Thanks, I had missed the MainModule.BeforeLogin event, I'll use that.

 

Agree about the security considerations and other points you make, though if one explicitly accepts that responsibility then it ought still be possible to do this I'd argue.  There would need to be some sort of authentication & authorization check for such requests, no different to what one might demand in a normal stateless web based system faced with a request which obviously faces the same concerns w.r.t data and concurrency that you raise, where every request in principle need to be authenticated as allowable or not.  

 

Concretely, UniGUI is stateful (for obvious reasons) and uses sessionid's of some sort to associate requests with the state on the server, I don't know the details (nor have I looked), and I don't know what else it may or may not be doing to reauthenticate/validate incoming requests as valid for a specified/requested sessionid.  I assume it is (unfortunately) a "black box detail" at the moment, and that implementation constraints may make making submissions against an existing session outside of the UniGUI browser JS problematic, though I'd argue in principle it need not necessarily be this way. 

 

That is to say I was hoping there would be a simple way to directly push a notification into an existing UniGUI server/session (somehow) to basically affect/update/change an existing (already open) page for a specific user (ergo, integration, notification generated from another system.)  

 

But lacking this I'll consider other options and see if rolling my own in some way is feasible.  Offhand (thinking out loud) I though of adding a DS client in the UniGUI server [ugh] to use its callback functionality perhaps, or perhaps look into WAMP/Autobahn/Websockets (which I've been wanting to do for some time), via perhaps the esegece Delphi websockets components (which implement WAMP compliant client and server components), though I'd rather not introduce more third party components...  but I digress.  Thanks again for your response!

[wprins]

You can pick up the url params in mainmodule, and handle it all in the beforelogin event.

That is the logic.

 

Could you clarify what you ought to do in BeforeLogin() to effectively customize/tailor the display (main form) successfully from within BeforeLogin() as it is not working as I anticipated.  

 

Currently I do simply this:

// Pseudocode of what I do
procedure TMainModule.UniGUIMainModuleHandleRequest(ASession: TObject;
var
  LUniGUIApplication : TUniGUIApplication;
begin
  LUniGUIApplication := TUniGUIApplication(UniApplication);
  if LUniGUIApplication.Parameters.GetText <> '' then
  begin
    // Check params on URL etc. Authentication/authorization etc...
    if valid then
    begin
      MainForm.Setup(......)
      MainForm.Show;
      Handled := True;
    end;
  end;
  ///...
end;

 

The expectation is that instead of opening the login form as normal, the system would show the main form directly after setting up accordingly as per the parameters etc.

 

However what I'm seeing is that the main form is displayed in its initialized state.  It's as though after calling my setup routines above, the main form is recreated or reinitialized.  

 

I've looked at moving the logic to "OnHandleRequest()" but that is evidently wrong as it breaks it more fundamentally.

 

What am I missing/doing wrong?

[maher]

try this

 if TUniGUISession(ASession).UniApplication.Parameters.Values['OP'] = 'xxx' then
 begin
 ...... 
   Handled := true;
 end 
 else
 begin
 ...... 
   Handled := false;
 end 

[Hayri ASLAN]

Hi

 

Please look to HTTP Post Callback demos.

 

The key point is UniSession.CallbackUrl

[Farshad Mohajeri]

Please check 4 examples provided for "Post Callback".

[erich.wanker]

i use a AndroidApp to search in my UniApp via Voice Recognition ...

 

The AndroidApp records the voice .. the GoogleApi (SpeechToText) gives me the Text .. and the AndroidApp send the text with parameters to my UniGui-Server-URL .. the AndroidAp has Settings for ServerName and UserID (to find the Session of loggedIn User) 

 

P.s.: I Use a Timer .. there are better ways to do it without timer ;-)

 

 

 

The AndroidApp sends something like: http:// www. yourdomain .com/unigui.dll ?user_id=123&search=showme contract 1000&function=speechsearch

procedure TMainForm.UniFormCreate(Sender: TObject);
...

handy_user_id:=UniApplication.Parameters.Values['user_id'];
handy_user_search:=UniApplication.Parameters.Values['search'];
handy_function:=UniApplication.Parameters.Values['function'];


...
 begin
    // Suche Session und starte Suche
        ASessionList := UniServerModule.SessionManager.Sessions.SessionList; //  .SessionList.  ist;//  .LockList;
          try
            for I := 0 to ASessionList.Count -1 do
            begin
              USession := TUniGUISession(ASessionList[i]);
              M := USession.UniMainModule as TUniMainModule;
                 if UniApplication.UniSession.SessionID <> USession.SessionId  then   // Do not close my OWN Session
                 begin
                    if M.benutzernummer = handy_user_id then
                    begin
                      M.sprachsteuerung :=handy_user_search;
                    end;
                 end;
             end;
          finally
             uniapplication.terminate;   // UniServerModule.SessionManager.Sessions.SessionList.UnlockList;
          end;
    end;

 

 

 

unit MainModule;
....
  public
    benutzernummer:String;  // Wird für Handy sprachsteuerung verwendet
    sprachsteuerung:String; // Wird für Handy sprachsteuerung verwendet
    username:String;        // Wird für "die Session nur einmal starten" benötigt
    LMessageStr:String;     // Wird für "die Session nur einmal starten" benötigt

 

 

 

 

procedure TMainForm.UniTimer2Timer(Sender: TObject);
begin
 if UniMainModule.sprachsteuerung <> '' then
 begin
  sende_close;
  s_Agent.starte_suche(UniMainModule.sprachsteuerung);
  UniMainModule.sprachsteuerung := '';
 end;
...