• You are here:  
  • Home
  • Q&A
  • Q&A
  • PowerBuilder
  • Appeon Web vs PB Client/Server with DB on a Web Server - Pros & Cons

Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (4)

Resolved Appeon Web vs PB Client/Server with DB on a Web Server - Pros & Cons

  1. Issue
0
Votes
Undo
  1. Daniel Vivier
    Daniel Vivier
  2. PowerBuilder
  3. Wednesday, 30 August 2017 00:55 AM UTC

Having encountered a significant amount of difficulty getting Appeon Web configured at all, and done the first deploy and analysis and seeing just how many parts of our existing PB code won't work - often with no suggestions for what to do about them in the Workarounds document - I'm starting to wonder whether another approach would be better.

The other approach would be to just put client DBs on a web server, and have a regular client/server version of our current apps access them directly, through SSL of course for security. (Our current apps are client/server with the DB on the user's PC, or on a computer on the user's LAN, and we will be continuing to offer that version whatever else we do.)

Here are some initial thoughts about pros and cons of each approach - I'd like others' feedback on their thoughts as well!

Pros of Appeon Web:

  • No installation (well, some!).
  • Probably faster data transfer.
  • Looks like it's a web app to the user (though I still think it's only a pseudo web app).

Cons of Appeon Web:

  • Huge effort to mod the app to get rid of all unsupported features, not clear how to do so for many of them (for instance, exception handling with Try/Catch/Finally).
  • Huge amount of documentation to read and understand (way over 1,000 pages).
  • Errors in the docs that lead to needing a lot of support. (For instance, the Appeon Web Server Configuration Guide suggested a bunch of steps for non-cluster setups that aren't necessary and killed everything - someone from Appeon just had me undo all of them to make things work!)
  • Unknown issues in features that are legal but behave differently in the Appeon Web version (like differences in handling of NULLs in arithmetic etc.), extremely hard to detect where that might be an issue, in a large code base.
  • Cost! Have to increase our prices to pay for the Appeon stuff.
  • Cost issues are risky because we don't know what the conversion rate would be from our current installed base (about 9,000 users) to the web version, and how many new users would purchase because of the new offering, won't know how many simultaneous users we will need until we have some experience with it, don't know for sure how soon we would need to move up to a cluster, and then the costs go up a lot. (Our programs are very inexpensive.)
  • Large amount of testing of all varieties of web browser, both 32 and 64 bit.
  • Have to have 64-bit versions of all of the current 32-bit DLLs and COM controls that our app uses, and do coding to abstract away whether we are using the 32-bit or 64-bit versions, depending on the bit-ness of the client browser.
  • Code bloat with all of the work-arounds to have some code run for Appeon Web and different code for our existing client-server version. (Would definitely be keeping only one code base for both!)
  • Not at all clear we can get our apps sufficiently modified and tested within the 30-day evaluation period to know whether it is a viable enough option that we want to purchase it, and the cost is significant for our small business.
  • Not too impressed with the support offering - bug submission, or Community forum that doesn't email you with answers. (I know that is scheduled to be fixed in Q4 sometime, but that will still be after our eval period ends.)

Pros of Client/Server with DB on our web Server:

  • Very little code modification needed. (Do need to migrate to a different DB server - we currently use Firebird and it doesn't even support SSL - but already did that conversion, to MySQL, in preparation for testing Appeon Web.)
  • App will run exactly like it now does, no worries about different functionality except perhaps disconnection issues over the Internet, and removal of features that don't make sense with that setup (like database backups).
  • Can get something working fast.
  • Current app features of converting data from the DBs of various competitors into our DB can be done with our existing code. (Appeon Web can't read client-side DBs natively, though I did come up with a solution using ADO.)

Cons of Client/Server with DB on our web Server:

  • Probably slower for data transfer than Appeon Web. (May not be a big deal, our users tend to have fairly small DBs.)
  • Still has to be installed just like our current apps.
  • Can't advertise it as a web app, maybe as a "Cloud Data" version or something.

Things that are about the same for either:

  • Only works on Windows (no Mac, which we get a fair amount of requests for). (Yes, Appeon can also work on mobile but that introduces even more limitations, and our apps are primarily data entry so not really appealing to use even on decent-sized tables with keyboards.)
  • Need more web server power than we have now (though probably more for Appeon Web than the client/server solution).
  • Need to handle backups ourselves (currently the users are responsible for their own backups).
  • Need to code for increased security, figure out some sort of licensing DB online etc.
  • Users would be able to use the app from anywhere (after some level of install), accessing the same data. (Currently we have several ways for users to access the same DBs from multiple PCs not on the same LAN, but all of those ways have their disadvantages!)

That's all I can think of on a first attempt, but I'm sure there are more issues too. I'd be particularly interested in hearing of major cons that we haven't thought of, for the client/server with DBs on a web server approach.  Thanks.

  1. Build
  2. PowerServer Web
WS issue
Already logged in
Responses (4)
Daniel Vivier
Daniel Vivier Accepted Answer Pending Moderation
  1. Wednesday, 30 August 2017 02:43 AM UTC
  2. PowerBuilder
  3. # 1

I should elaborate on saying "well, some" in reference to "no installation" with Appeon Web. We have a number of OLE controls and DLLs that the app uses, that would have to be downloaded regardless, plus a PDF printer (novaPDF) that the app needs for printing mail-merge documents from an embedded web-browser control (assuming we could get that working), plus I'd prefer to have it still download the real .CHM help file rather than always go off to a page in the webhelp, etc. So there would still be a lot, in addition to the plugin, that would have to be set to be downloaded for our app to fully work as an Appeon Web app.

Comment
There are no comments made yet.
Daniel Vivier
Daniel Vivier Accepted Answer Pending Moderation
  1. Wednesday, 30 August 2017 12:11 PM UTC
  2. PowerBuilder
  3. # 2

Another major Pro that I missed of Appeon Web is that we keep the app always up to date, so all users are on the "latest and greatest" version. With any installed solution like my client/server with web-based DB idea, the users have to choose to upgrade, and then you run into various installation problems you have to solve, plus users are using all different versions of the program, making support harder, etc.

Another con (which without a feature improvement in Appeon Web seems like a killer problem for us) is what Yakov just posted here at https://community.appeon.com/index.php/qna/q-a/64-bit-activex-control. Embedded ActiveX controls in windows will always be 32-bit, which means they won't work when the Appeon Web app is run through a 64-bit browser. Our main app uses an embedded WebBrowser control (a version of Roland Smith's free example) that at this point I'm assuming would not work in 64-bit because the app can't know to switch to a 64-bit version.

Comment
Mike S
  1. Mike S
  2. Wednesday, 30 August 2017 13:34 PM UTC
You should probably use the IWA option (installable web app) for appeon web, rather than directly using the browser(s).  That eliminates the 32/64 bit question - it will use your 32 bit dlls; it also ensures that google's frequent changes won't mess up your application.   the IWA option is stupid easy to setup.



I think your concern of web vs chm help may be overblown.   It works the same for us - context sensitive and everything.  You just need to generate web help out of your help system and point it a little differently when your user hits the help menu/F1.  The only difference that instead of opening the help application, it opens a web browser page.  the less stuff you have to download the better.



I agree getting it to work on mac would be ideal.  



code bloat  - no not really, just a relatively small amount of extra code.  we definitely have some appeon specific code, but it is mostly related to the login processing and is kept in its own library for appeon only deployment.  Also have some If appeon then X else Y code, but not very much of that either.   Some changes were made so that it works in appeon but also runs in client/server mode - for example we have 2 places in our system that uses a reselectrow and we had to write our own version of that since appeon doesn't support it.   The null differences in if/then statements were the worst to find.    We have very little usage of try/catch since we knew we were moving to appeon.  You want to test this yourself to see how it behaves, but it ignores the error processing part of it so if it is truely rare that an error occurs you may be ok as is.  If you are throwing your own errors for common occurring stuff , then it might be a bigger problem.  



buy the developer version first (you should have this anyway for your testing/development  even though it is no longer needed for deployment) and after you get it working then look to buy the production version.



web server power - pb web uses much less cpu/memory than you might think, much less than i thought anyway.



the one thing you may not have thought a lot about yet is your login processing.  when a user logs in you need to both validate that they are valid and what database they belong to or have access to (or schema if you go that way).   I use a directory database for this; the guys at sizes and colors use the URL to determine this.   You need a way to handle this even if you for some reason dont' go with pb web.



You need to match your licensing to your variable costs - which is concurrent users in pb web.  you *can* do named users instead, but then all your customers will use the same login to get around it.



 



what was your ADO solution for doing client side DB processing? 

  1. Helpful
Daniel Vivier
  1. Daniel Vivier
  2. Wednesday, 30 August 2017 14:01 PM UTC
Thanks, Mike. I sketched the ADO solution at https://community.appeon.com/groups/powerbuilder/accessing-local-files-odbc-appeon-web-apps. However, as you will see it has almost no error handling, and I'm coming to believe that there is no effective way to do OLEObject error handling in Appeon Web, because of the absence of try/catch, the ExternalException event, and the SystemError event. And you really do need to be able to catch such errors!

  1. Helpful
Gerry Whitmarsh
  1. Gerry Whitmarsh
  2. Wednesday, 30 August 2017 17:46 PM UTC
Sorry, placed my comment in the wrong place.

  1. Helpful
There are no comments made yet.
Gerry Whitmarsh
Gerry Whitmarsh Accepted Answer Pending Moderation
  1. Wednesday, 30 August 2017 13:20 PM UTC
  2. PowerBuilder
  3. # 3

Hi Dan,

Have you considered a Microsoft Terminal Server solution? 

Gerry.

Comment
Daniel Vivier
  1. Daniel Vivier
  2. Wednesday, 30 August 2017 13:56 PM UTC
Thanks, Gerry. Too expensive - as I understand it, client access licenses are at least $4/month, and that's the current price we charge our users for the main application (in the 2nd and following years). So that would double our price. Also, each user needs some files of their own (INI files etc.) and it's hard to see how that would be organized on a terminal services type solution.

  1. Helpful
Gerry Whitmarsh
  1. Gerry Whitmarsh
  2. Wednesday, 30 August 2017 17:45 PM UTC
Agreed, it is not the cheapest solution but personal ini files aren’t a problem. I place personal ini files in %appdata% and each user has their own personal drive mapping.

  1. Helpful
There are no comments made yet.
Appeon Support Team
Appeon Support Team Accepted Answer Pending Moderation
  1. Tuesday, 12 September 2017 09:03 AM UTC
  2. PowerBuilder
  3. # 4

Hi ,

PB apps are more stable; and Appeon web application client is quite easy for installation. You can try the new feature: Installable Web Apps in Appeon 2016.
https://support.appeon.com/index.php?/News/NewsItem/View/87

Data transfer is more secure with Appeon. You can refer to the article in the below link for details.
https://support.appeon.com/index.php?/Knowledgebase/Article/View/34/15/whats-the-appeon-encryption-mechanism


For the Try/Catch/Finally issue, generally no modification is needed is because the Try...catch statements can be automatically commented out during the deploy process. 
unlike the Client/Server architecture, Appeon web has its own way to trap the exception as stated below.

#1- Appeon offers built-in exception handling mechanism to avoid serious problems occurring on the end-user's side.

#2- Appeon Debug tool together with Appeon Server and Appeon Error log files are used to troubleshoot the application-problems, which are the substitutes of the debugging functions that offered by "Try..Catch".

And you can also refer to the article below to debug the application.
http://support.appeon.com/index.php?/Knowledgebase/Article/View/59/10/the-approaches-to-debug-the-appeon-application


For the document issue, Appeon provides a copy of detailed documentation (that may seem massive for users) and is always improving along with each release. You may search what you need by entering any keyword. If you find any error please feel free to let us know.


For the null value issue, please refer to the article below to work it around.
https://www.appeon.com/support/documents/appeon_online_help/2016/workarounds_and_api_guide/ch05s03s01.html#Null_values

For more unsupported features, please refer to 
https://www.appeon.com/support/documents/appeon_online_help/2016/workarounds_and_api_guide/ch05.html


For the 64-bit and 32-bit browser issue, please go to AEM > Application > Web Browser > [your application] page to set the compatibility mode.
https://www.appeon.com/support/documents/appeon_online_help/2016/workarounds_and_api_guide/ch05.html

And you can modify the registry on the client machine to run the application on a 32-bit IE. Here is the method:
Step1: In the registry , change the value of HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\TabProcGrowth to the value greater than 0.
Step 2: Restart the IE.
For more details please refer to:
http://support.microsoft.com/kb/2716529

Regards,
ZhaoKai

Comment
Daniel Vivier
  1. Daniel Vivier
  2. Wednesday, 13 September 2017 15:57 PM UTC
Thanks for this rather belated reply! I'm afraid we have still decided to go ahead with the other much simpler and certainly much cheaper option (not that it is trivial either!).

  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.