Visual LANSA Forum

Hi

I have an VL-WEB application. In my main web page I have this: Evtroutine Handling(#SYS_WEB.RequestFailed) Handled(#Handled) Request(#Request) Reason(#Reason)
and if there is an error i goto signon again.

Now at the customersite they have poor wifi so we get alot of errors where we do not have the connection to the server. A few mili seconds later we have connection again, but we have already gone to signon becaus of the error.
We use ExecuteAsync when we call the server modul routine.

How do other handle the issue with bad connection?
I would like to retry the executeAsync X number of times before it fails and returs to signon.

Any suggestions?

regards Klaus

Hi Klaus

Interesting question....

While the .requestfailed can capture all the falls, I doubt there is a way to retry or to come back to the program to an specific point

What I will probably will try - besides adding repeaters or starlink-, is in the more critical programs to have the .failed event in which I could start a timer, and by the tick of the timer, call again the routine (let's say refresh routine) that performs the executeasync. The refresh routine will start with the stop timer.

Now if you tell me that you have hundreds of executeasyncs you want to cover, probably I would think in some kind of program that will be in charge of the calls to execute asyncs , timer and failed event, so my views and other web things will just talk with that handler. But probably that will be too much.... I may just put the logic in a template and used every time I want this.

Hi Klaus

In traditional client/server the connection is a what I would call a hard connection, where if there is an internet drop-out the connection is lost and must be re-established. The paradigm here is to first check that the connection is up. If it is then proceed with your processing, if not the establish a new connection, then do the processing.

In the web world the connection is a soft connection. If it is lost then re-established then the connection is not lost. The only issue is when you are trying to interact with the server when the connection is down.

One way would be to to poke the server first before trying to process. this is called a noop or no operation. You could try it synchronously (or asynchronously), because it goes to the server then back without any processing, and when the connection is up the speed will be fast, while if the connection is down you can manage retrying for n tries or until you get a successful return.

You could code your noop lookup in a client side reusable and server side server module, then before every one of your processing calls to server modules, first run the noop check connection and don't do the processing server module call until the check connection returns ok.

You would need to add the check connection method call before every server module call.

Tim

Hi.

Thans for your response.

Tim: I can not use the noop lookup because next time I try to call the server routine it might be the time where I have a bad connection.

I have made this for test:

Mthroutine Name(GetReklinier_com)
Define_Map For(*INPUT) Class(#rmhnum) Name(#Modtnum)
Define_Map For(*BOTH) Class(#LISTCOUNT) Name(#Err_count)

Define_Com Class(#Test_serverModule.GetRekLineList) Name(#GetRekLineList)
#GetRekLineList.ExecuteAsync modtlin(#modtlin) RMHNUM(#Modtnum)
Evtroutine Handling(#GetRekLineList.Completed)
#Err_count := 0
Endselect
Endroutine
Evtroutine Handling(#GetRekLineList.Failed) Handled(#Handled)
#Handled := True
#Err_count += 1
If Cond(#Err_count *LE 10)
Begin_Loop To(1000000000)
End_Loop
#com_owner.GetReklinier_com Modtnum(#Modtnum) Err_count(#Err_count)
Else
#SYS_WEB.Alert Caption('Now we stop!!!!: ' + #Modtnum.AsString + ' / ' + #Err_count.AsString)
Endif
Endroutine
Endroutine

first time I call the routine I set the err_count to 1. the begin_loop is only because i need to wait some time ( it could have been made witht timer).

But this works okay for a test. I will make small changes so the user get a pop-up if the connection is bad and I have tried 10 times. The they can try 10 times more or close the application.

Is there any problem when the routine call itself x number of times?
/klaus

Use the timer instead the loop, probably less cpu intensive, just have a timer.start instead the loop, and by the evtroutine timer.tick event have your executeasync

I think the call should be fine as it is

We had the same issues using a handheld device. We upgraded the firmware on the WIFI access point device and also set a fixed IP address on the handheld device. This solved the issue for us with regards to the performance (dropping out) of the PWA on the handheld device.