[Openroad-users] App Server processing

[Bodo.Bergmann at t-online.de]

Martin,

if I understand your problem  correctly, then what you want to have is:
1. Trigger a client-popup from within the processing of the OR image
running on the server.
2. Return value(s) after user input from the client to the server and
synchronously continue processing on the server according to the values
returned.

I would have used the same approach Kim mentioned, but there is another
solution for your problem, but it's a little tricky and it depends on
what connections the client can have:
- DCOM
- Ingres/Net
As you are using the AppServer I assume all SQL has been moved to the
server, so Ingres/Net is probably not installed on the client, but DCOM
is
as you are using the ORServer. 

To accomplish your desired behaviour, you could install a DCOM server
application (could be written in VB, C++, etc.) on the client.
This application will provide the popup dialogs for the user.
The ORServer application has registered the DCOM executable as an
external class library. The OR server app creates an object of the
client DCOM application class - this will start the DCOM executable on
the client. Whenever the OR server app requires user interaction, it
invokes an according method of the client DCOM object, which will open
the dialog on the client, requesting information from the user and
returning it back as return value of the method to the OR server.
This should only be done with RP_PRIVATE servers - otherwise one user
could block lots of others.

If you have Ingres/Net available on the clients an easier solution is
possible by using the Ingres database. The server app could raise a
DBEvent. On the client an application has registered for the DBEvent,
triggers the popup and writes the result into a table. The  server app
polls the table for the result (server app can't process events) and
continues execution, when the result has been inserted.
The receiving application on the client could also be another OpenROAD
application (not the same one that triggered the AppServer as it is
waiting for the return of the Call4GL).

Hope this helps,
Bodo.


-----Original Message-----
Date: Thu, 23 Nov 2006 00:37:28 +0100
Subject: Re: [Openroad-users] App Server processing
From: "Martin Pomej" 
To: "'Kim Ginnerup'" , "OpenROAD Users" 

      Hi Kim,   Thanks  for your reply. I'm happy that what I thought
was correct, is correct, but I'm  unhappy that I am correct 8-)   Main
issue is that the popup's appear in a number of locations, so
breaking it down  to two or more calls is going to be painful.  
Regards, 
Martin.    PS  Does  anybody have access to bulk supplies of 
aspirin?

-------------------------
FROM: Kim Ginnerup [mailto:kgi at bording.dk]  
SENT: Thursday, 23 November 2006 02:43
TO:  martin.pomej at myworkplace.com.au; International OpenROAD Users
SUBJECT:  SV: [Openroad-users] App Server processing

Hi  Martin, 

 

There is only one way  you can accomplish that. 

Split the server call  into two calls. 

You are already using a  stateful server, so keeping the state
between the two calls shouldn’t that big a  deal. 

 

On thing you will need  to handle is the situation that the user
bails out between the first and the  second call. 

But that is something  you will need to handle anyway with a
stateful  server. 

Hopefully you popup is  not in the middle of a transaction.  ;-) 

  

Kim   
-------------------------

FRA:  openroad-users-bounces at peerlessit.com 
[mailto:openroad-users-bounces at peerlessit.com] På VEGNE AF Martin
Pomej
SENDT: 22. november 2006 16:22
TIL: OpenROAD Users
EMNE: [Openroad-users] App Server  processing 

  

Hello OpenROAD  legends,  

  

We have a tough situation involving  App Server and some heavy
processing and I wanted to ask if anyone had  encountered anything
similar and how they handled  it.  

  

Scenario  

- existing app converted to  eClient / App Server  

- heavy processing moved to App  Server due to the massive amount of
data  involved  

- depending on variables, certain  processing will occur and then
the user will be prompted for a response (this is  how the fat client
currently works)  

  

Problem  

- the prompting involves a frame  popping up and requesting
information  

- the information gathered in the  prompting cant be requested prior
to calling App  Server  

  

Ideal  Solution  

- make a call to App Server and when  a certain point in the App
Server processing is reached, halt what's happening  and return
control back to eClient  

- prompt the user for the  required information  

- pass information and control  back to App Server and continue on
with processing from the point where App  Server was halted  

  

My question is can App Server be  dealt with in this way? If so how?


(With my limited App Server  experience I cant see this working, but
I want to ask to be  100%)  

  

If anyone has dealt with a  similar scenario whereby processing on
App Server was halted, control  returned to eClient and then control
again returned to App Server,  would you mind sharing the way you
went about  it.  

I've almost lost the 2 strands of  hair I have left just thinking
about handling this, and surely my hair is worth  saving 8-P.  

  

Regards,  
_MARTIN  POMEJ_ 
MyWorkplace Solutions Pty  Ltd 
Ph:     1300 733  731 
Mob:    0414 230  845 
Em:      martin.pomej at myworkplace.com.au 
_Making Service  our Priority_ 
www.myworkplace.com.au [1]    



Links:
------
[1] http://www.myworkplace.com.au/