Server modules

This Q&A forum allows users to post and respond to "How Do I Do ....." questions. Please do not use to report (suspected) errors - you must use your regional help desk for this. The information contained in this forum has not been validated by LANSA and, as such, LANSA cannot guarantee the accuracy of the information.
Post Reply
billcross
Posts: 30
Joined: Thu Apr 07, 2016 3:01 am

Server modules

Post by billcross » Tue Aug 09, 2016 10:18 pm

Are server modules that are defined in reusable parts loaded once or are they reloaded each time the specific module is executed ?

If they are reloaded is there a way to keep them resident while the reusable part is open ?

User avatar
Stewart Marshall
Posts: 417
Joined: Thu Nov 05, 2015 5:25 pm

Re: Server modules

Post by Stewart Marshall » Wed Aug 10, 2016 9:35 am

At runtime there are 2 distinct parts to a server module: the client side component instance and the server side executable processed by the Application Server.

The client side component instance is created by the Define_Com which is best placed within a Mthroutine as explained here (http://docs.lansa.com/14/en/lansa017/in ... 1_0415.htm)

This object is really little more than VL's equivalent of the underlying Ajax HTTPRequest. When the ExecuteAsync method is invoked, the HTTPRequest is sent to the WebServer, finding its way to the LANSA Application Server. It follows the rules of all components, so it will die when it is no longer being used.

On arrival, the request is processed. The Application Server has a pool of available jobs that can service the request. However, if they're all busy, a new job is created. Regardless of whether the job is new or not, the state of the job will be the same. i.e. It is a blank canvas and utterly stateless as far as the executing server module is concerned. Once all the processing is complete, the job will return to its default state ready for the next request.

This stateless model minimizes the impact of many users on the server, but means that each job ALWAYS starts from a default position.

However, there is clearly a requirement to manage application state to avoid repeatedly performing the same processing e.g. Lookups of table data. There are two features of VL that enable this this.

The first is that the client has a runtime. This means that whatever data you've downloaded is in memory and will be until you refresh the page. So, you might choose to download some commonly used static table data to the client when convenient. The app will then be able to use this memory resident data rather than reading server side tables, effectively sharing the processing between the server and the client.

The second is the use of persistent data within the bounds of a Session (http://docs.lansa.com/14/en/lansa017/index.htm). The PERSIST command (http://docs.lansa.com/14/en/lansa015/co ... ersist.htm) is used to store data on the server between requests. When a requests starts, the field values and lists are repopulated and are available for the server module to use.
Stewart Marshall

Independent IT Consultant
www.marshallfloyd.com.au

billcross
Posts: 30
Joined: Thu Apr 07, 2016 3:01 am

Re: Server modules

Post by billcross » Tue Aug 16, 2016 8:49 pm

Do persistent fields and lists stay available when you change from one window to another one ?

dannyoorburg
Posts: 148
Joined: Mon Jan 04, 2016 9:50 am
Location: Australia

Re: Server modules

Post by dannyoorburg » Wed Aug 17, 2016 9:37 am

Hi Bill,

A bit of experimenting with a simple Web Page and a simple Server Module will show you easily enough how persistence works. I would start there and try a couple of scenario's.

Feel free to post any questions that arise from that, with some sample RDMLX or a bit of a description of what you're trying to achieve.

Regards,
Danny

billcross
Posts: 30
Joined: Thu Apr 07, 2016 3:01 am

Re: Server modules

Post by billcross » Wed Aug 17, 2016 8:03 pm

Persistents works from reusable part to reusable part but does not appear to work from web page to web page which was what I meant to ask in my previous question instead of window.

Do persistent fields and lists stay available when you change from one web page to another one ?

dannyoorburg
Posts: 148
Joined: Mon Jan 04, 2016 9:50 am
Location: Australia

Re: Server modules

Post by dannyoorburg » Thu Aug 18, 2016 10:04 am

Hi Bill,

the server is (blissfully) unaware of what's going on in the client, it gets a request and that request either contains a session-id or it doesn't.

The default behavior in Visual LANSA is for that session-id to be passed in and out in the payload of each request.


Your Reusable Parts work because they are all running in the context of the same Web Page. The session-id coming back with the last request is maintained in memory and passed back to the server in the payload of the next request.

As soon as you navigate to another page, all state is blown away and the next request will go back to the server without a session-id.


In a classic web application the session-id usually travels in a cookie, and the browser will automatically send the cookie back with each request to the same domain. Therefor you can freely navigate between pages of the same domain.

That will work in Visual LANSA too, if you set the SessionKeyMethod in the Server Module to Cookie (or SecureCookie if you're using https), as in

Code: Select all

Begin_Com Role(*EXTENDS #PRIM_SRVM) SessionKeyMethod(Cookie)
your problem will go away.


If you don't want to use cookies, and you probably won't, you will have to change the way you navigate between pages (I'm guessing you're currently using #SYS_WEB.Navigate).

You can define a SrvRoutine to return a Web Page (instead of just data) using the following syntax:

Code: Select all

Srvroutine Name(ShowMyPage) Response(*WEBPAGE #MYPAGE) Session(*REQUIRED)
Field_Map For(*INPUT) Field(#STD_TEXT) Parameter_Name(Input)

Endroutine
and invoke it from the client using:

Code: Select all

Evtroutine Handling(#Button1.Click)
Define_Com Class(#MYSRVM.ShowMyPage) Name(#ShowMyPage)

#ShowMyPage.Execute Input("Hello World")

Endroutine
That way you will navigate to your page through the server module, and it will come alive in such a way that it knows the current session-id.

(Plus you've got the added bonus that you can pass fields and lists to it too :))

Hope that clears things up.

Regards,
Danny

billcross
Posts: 30
Joined: Thu Apr 07, 2016 3:01 am

Re: Server modules

Post by billcross » Sat Sep 17, 2016 12:28 am

How do you pass the URL of the new page into StartMyPage ?

dannyoorburg
Posts: 148
Joined: Mon Jan 04, 2016 9:50 am
Location: Australia

Re: Server modules

Post by dannyoorburg » Sat Sep 17, 2016 7:52 am

Hi Bill,

You don't pass in a URL. The Define_Com for the Server Routine (with Response(*WEBPAGE #NEXTPAGE) contains enough information for Lansa to construct the URL under the covers...

I can post a simple sample if it's still unclear...

Danny

billcross
Posts: 30
Joined: Thu Apr 07, 2016 3:01 am

Re: Server modules

Post by billcross » Mon Sep 19, 2016 7:52 pm

A simple sample would help a lot.

dannyoorburg
Posts: 148
Joined: Mon Jan 04, 2016 9:50 am
Location: Australia

Re: Server modules

Post by dannyoorburg » Tue Sep 20, 2016 1:41 pm

Hi Bill,

see the attached sample.

This is not necessarily the best way to do a login, ( you might want to check out the new Web Page templates for an alternative architecture as well ), but it shows the concept of transferring to another page and staying within the same session.

The package contains a Server Module (MPSSRVR) and 2 Web Pages (MPSLOGIN/MPSAPP)

Compile all and execute MPSLOGIN.

Cheers,
Danny
Attachments
QuickExport MultiPage App Sample.zip
(10.34 KiB) Downloaded 155 times

User avatar
MarcusLancaster
Posts: 22
Joined: Tue Nov 24, 2015 9:20 pm

Re: Server modules

Post by MarcusLancaster » Thu Oct 13, 2016 12:38 am

Hi all.

Continuing this thread... I've got a vaguely similar scenario, but the page I'm transferring to is not LANSA. I'm trying to work out the best / safest approach for implementing this...

Basically I've got a VL Web application, a customer logs on and I establish a server session. Once logged in, the customer can make a payment. This is done using a 3rd party web site which we transfer to. So the basic flow is; start a server session, click a button on my LANSA VL Web page to fire up the URL of the 3rd party (I'm using #sys_web.navigate to do this opening in the "current" window), customer does whatever they need to do in the 3rd party site, 3rd party site then fires up a "return" URL (a LANSA VL web page) that I provided to them. The problem is that firing up that return URL means I've lost the session and the user is thrown back to my login screen.

I tried setting SessionKeyMethod to cookie - and that worked (because the local cookie keeps hold of my session id while we're off at the 3rd party site) - but if possible I'd prefer not to rely on cookies. So I was looking at other alternatives... Just wondered if there's something "out of the box" that I'm missing which will allow me to hook up with the original session when I get back from the 3rd party. If not just wondered if anybody had done anything similar?

I've got a few ideas, but thought I'd float this here just in case there's something really obvious that's already baked into VL that I'm missing. Ultimately I don't want to leave the browser in a state where if the user killed the browser while away at the 3rd party site, and then subsequently restarted the VL app the login would be bypassed.

Cheers for now.

Marcus.

GregSippel
Posts: 25
Joined: Thu May 19, 2016 11:34 am

Re: Server modules

Post by GregSippel » Thu Oct 13, 2016 10:41 am

Marcus,

The way I would approach this is situation is to essentially to have your own session value to cover the scope of
the users 3rd party transaction.

I see these situations as having two issues,

1) The return to the site once the transaction is completed
2) The user clicking the browser back key once they get the 3rd party site

Both scenarios essentially add up to the same problem for a single page application which is, how do I get the application to pick
up from where they left.

The flow I would follow is this (without knowing the specifics of the 3rd party site)

1) As the user clicks the link to leave, you call a server module (SM).

2) The server module, saves any needed values and/or application state.

3) You generate a GUID in the SM as a link to the information above.

4) The SM returns the GUID and he completed event triggers a URL change that puts the GUID into the query string

5) You navigate the user to the 3rd party site, passing the return URL as the above URL with another parameter such as
"COMPLETED=Y".

6) If the user from the 3rd party site clicks the back key, your app will see the URL as having the GUID in the
query string but no the completed flag. So you app can the make a call to srvroutine to start a new session
and get the saved values. But since no completed flag exists you know they have returned.

7) If they return once completed, as above you can call a srvroutine to restore the saved values and the user can
continue on as the application can see the completed flag in the query string.

The variation to the above, could be that you use local storage to save teh application state and values.

Cheers
Greg

User avatar
MarcusLancaster
Posts: 22
Joined: Tue Nov 24, 2015 9:20 pm

Re: Server modules

Post by MarcusLancaster » Thu Oct 13, 2016 7:16 pm

Thanks for this Greg.

What you've suggested should fit in really nicely with the specific scenario I've got.

Thanks for the full and informative response. Much appreciated.

Cheers for now.

Marcus.

User avatar
Stewart Marshall
Posts: 417
Joined: Thu Nov 05, 2015 5:25 pm

Re: Server modules

Post by Stewart Marshall » Thu Oct 13, 2016 7:52 pm

Hi Marcus

Just in case you happen to be looking, there's a decent of example of URLParameter handling in the Samples

Have a look xDemoWebBackForward. This responds to an employee number, setting position in a list, but the concepts are much the same.

Regards
Stewart Marshall

Independent IT Consultant
www.marshallfloyd.com.au

John
Posts: 24
Joined: Thu Aug 10, 2017 3:21 pm

Re: Server modules

Post by John » Thu Jul 12, 2018 3:51 pm

Hi Stewart,

This URL no longer exists. IS there an updated one please as I'm interested in reading it'

http://docs.lansa.com/14/en/lansa017/in ... 1_0415.htm

Regards,
john.

User avatar
Stewart Marshall
Posts: 417
Joined: Thu Nov 05, 2015 5:25 pm

Re: Server modules

Post by Stewart Marshall » Mon Jul 16, 2018 8:15 am

Stewart Marshall

Independent IT Consultant
www.marshallfloyd.com.au

Post Reply