S
smat-consulting
Guest
Well, if the program you call on the server is accessing the DB you have a problem should the DB have gotten disconnected for whatever reason. If you call a wrapper procedure that does not have a DB reference, you can simply connect the DB and do your work. If the DB is connected already, it simply hands off the request to the actual program without any further action. I don't do app server from a guy client because OE doesn't support Apple - I use WebSpeed, as browser runs on anything: windoze, mac, tablets, mobile... However, WebSpeed is in essence using the stateless app server; the ultimate statelessness, if you will 
I have one program that includes the cgi-defs.i, reads the passed parameters into a temp-table, and outputs text-content to the web stream. Then it calls the actual procedure that is appropriate to fulfill the request. That procedure (and all it calls) creates a JSON response, which it stores as text-blocks in a temp-table - the same tt that the wrapper procedure outputs to the web stream - one text-block after the other. This system allows me to have only one single entry procedure. It also allows me to run the whole application form the editor for debugging and testing purposes (simply filling the parameter tt with values simulating the web-request, and outputting the text that usually would go to the web-stream into a file). When dealing with a GUI client/Appserver system you might not be able to have only one single wrapper program, as I do in WebSpeed. However, depending on your application, you might be able to write a handful of generic wrappers using dynamic temp-tables and datasets to pass through the request parameters and results. Or you might be able to do some fancy preprocessor magic to use the same physical program-file for both the wrapper (in which case the other logic is &IF-DEFed out) and the API (in which case the wrapper logic is &IF-DEFed out). Hard to provide ideas without knowing what kind of requests you are planning on sending back and forth...
Continue reading...
I have one program that includes the cgi-defs.i, reads the passed parameters into a temp-table, and outputs text-content to the web stream. Then it calls the actual procedure that is appropriate to fulfill the request. That procedure (and all it calls) creates a JSON response, which it stores as text-blocks in a temp-table - the same tt that the wrapper procedure outputs to the web stream - one text-block after the other. This system allows me to have only one single entry procedure. It also allows me to run the whole application form the editor for debugging and testing purposes (simply filling the parameter tt with values simulating the web-request, and outputting the text that usually would go to the web-stream into a file). When dealing with a GUI client/Appserver system you might not be able to have only one single wrapper program, as I do in WebSpeed. However, depending on your application, you might be able to write a handful of generic wrappers using dynamic temp-tables and datasets to pass through the request parameters and results. Or you might be able to do some fancy preprocessor magic to use the same physical program-file for both the wrapper (in which case the other logic is &IF-DEFed out) and the API (in which case the wrapper logic is &IF-DEFed out). Hard to provide ideas without knowing what kind of requests you are planning on sending back and forth...Continue reading...