Have you seen the data streams in Wireshark or some such packet sniffer?
Yes. I have used packet sniffers, but I much prefer a debugging tool named
Fiddler:
http://www.telerik.com/fiddler
I'd encourage developers to use a tool like that to review the data streams
of various types of browser applications to see what's going on under the
covers.
I'll provide a reference to one of our applications:
https://rd.radile.com/rdweb/apps/ovk/ofst101/begin.shtml
The following values may be used to test the interface:
Fueling Station ID: 123456
Employee Number: 123
Customer Account Number: 987654
Customer PIN: 9999
This application supports attendants at bulk fueling stations, which refill
tanks up to 15,000 liter capacities. It's a point of sale interface
designed for tablets - hence the built-in numeric keypad as opposed to the
tablet's keypad, which may exceed 50% of the screen size.
Fueling large tanks may take up to an hour. Tablets may be passed from
attendant to attendant in the meantime in order to start new transactions
at other pumps. Tapping on pumps in the list enables attendants to begin
new transactions or resume pending ones.
Inputs look something like:
GET
https://rd.radile.com/rdweb/apps/ovk/ofst101/substep.shtml?station=123456&pump=1&step=1&keyval=123
HTTP/1.1
Outputs from the server looks something like:
$("attendant").innerHTML = "Kendall Andelin";
dum("1","Enter Customer Account #");
$('curstep').value = 2;
select_step();
or
{
"employee":"123",
"name":"Kendall Andelin",
"acct":"987654",
"customer":"Relational Data Corporation",
"accttyp":"10",
"acctdesc":"Account 10",
"bal":"100000.00",
"amt":"",
"pin":"",
"step":4
}
The size and complexity of the data streams are smaller and simpler than
those of an application which is using a display file / screen-scraper
interface. The user experience and performance are much better. A single
IBM i JOB supports hundreds of concurrent pumps as opposed to hundreds of
JOBS serving hundreds of sessions. Vastly fewer server & network resources
are consumed.
midrange.com
