Question

Touchapps in IFS 8

  • 2 February 2022
  • 3 replies
  • 87 views

Userlevel 2
Badge +6

Hi All,

We are testing the touchapps scanit application for IFS  8. Is there a way to limit the number of calls in between the touchapp server to the application server? if anyone has worked on it, please provide some inputs on it.

 

Regards,Sri


This topic has been closed for comments

3 replies

Userlevel 6
Badge +16

There is no way to prevent/block the number of calls between Touch Apps Server and the MWS.

Can I ask why you want to limit the number of calls?

Userlevel 2
Badge +6

We have a wadaco process to scan multiple barcodes, when we start scan it inserts the data and return the scanned data. During this process if the previous scan was delayed and we scanned a new one. Then suddenly we get an error “The object has been modified by another user”

Userlevel 6
Badge +16

Wadaco/scanit is a total online client, trying to limit the number of calls from client to server would be very contra productive. Is the process your testing a IFS Core process or is it something you have built?

If its your own process maybe you have done some strange things like trying to set values before they are entered in the session or trying to save values directly in the session without letting FW handle that, that could cause modified by another user.

I’m not sure if understand your problem with previous scan delayed, is it that the barcode is not sent entirely in one go to the field and comes in subsections/parts sometimes maybe? Or are you talking about performance issues?

I have heard/seen issues like that happening sometimes with the new Aurena framework, but never for the old Apps8 Android app, like the barcode string was buffered and didn’t came directly in one go or that the carriage return in the end of the barcode came before the entire barcode had been sent to the scanning field. Not sure if it could be fixed by making sure Carriage return is not send in the barcode string and let the system send the entire barcode until the user press Save manually instead.

If the process have performance issues so the server handling takes too long time, this could cause the client to timeout after a certain time, and in worse case maybe the buttons are activated again so user continues before the old server job is finished, that could also cause modified by another user in some case maybe. But in that case the investigation should be on the performance issue and maybe try to change configuration  a bit.

There was also bug fix 133597 made in 2017 that fixed one kind of issue that could give this error when network connection issues happened, it was made for App9 and Apps8. You could double check if you have that fix. But it might have been mostly for Windows Mobile issues and not the Android app from what I could read in its description.