Running openedge application from the web

[Zadock]

Hi All,

We are on Openedge v11.1. We recently bought Appserver to enable our application run on the web.

I have gone through the documentations we have and I dont seem to understand how to post our application on the web. We have downloaded tomcat v8 and when we add the examples from java onto the webapps folder they are able to run fine.

Any help from someone who has done this before?

Thanks in advance.

 

[RealHeavyDude]

You should reveal more details about what you exactly mean by "post our application on the web".

Are you trying to access the AppServer via the AIA ( AppServer Internet Adapter ), WSA ( WebService Adapter ) or something else?

Heavy Regards, RealHeavyDude.

 

[tamhas]

Or WebClient, which is literally running your application on the web. The one qualification is that the code running in WebClient can do no data base accesses, so those have to be turned into AppServer calls.

 

[Zadock]

Hi All,

We are on Openedge v11.1. We recently bought Appserver to enable our application run on the web.

I have gone through the documentations we have and I dont seem to understand how to post our application on the web. We have downloaded tomcat v8 and when we add the examples from java onto the webapps folder they are able to run fine.

Any help from someone who has done this before?

Thanks in advance.

 

[Zadock]

I think since Im new on web technology, maybe we should go to the basics. How do we proceed to have our application sit on the web?

 

[tamhas]

There are many different ways as indicated above. You can run an existing client across the web with understandable performance issues and the need to install on the remote system. You can run WebClient with minimal installation on the remote system, but a need to convert database references to AppServer calls. You can create .NET, Java, Browser, or Mobile interfaces, but it means you need to rework your application to separate the UI into a separate layer, which has almost certainly not already been done if you are just getting AppServer. It all depends on what you want to accomplish and what work you are willing to do. There are people who consult in making these choices.

 

[TomBascom]

Does "sit on the web" mean:

1) Use a web browser for your UI?
2) Let users in remote locations access data at a central location using a protocol such as HTTP?
3) Deliver (download) an application to a local machine to be executed locally?
4) Something completely different?
5) Some combination of the above?

It sounds like someone wants to "be on the web" without any real understanding of what they are trying to accomplish and what any of that means. I'd start with the business goals of the application and then work out what that means in terms of possible technical approaches and whether or not "the web" has a role to play.

 

[Zadock]

Hi Tom,

Your 1st and 2nd point is what I would like to achieve. As Tamhas has advised, I probably need to go for webclient since I hope it wont involve alot of 'overhauling' on my existing application to suit the technology.

I dont seem to be able to get detailed documentations on where I should start. Any help?

Regards

 

[Stefan]

You may want to start here:

https://community.progress.com/comm...2352.openedge-11-5-product-documentation.aspx

Note that the WebClient has nothing to do with a web browser UI.

 

[jongpau]

Hi Tom,

Your 1st and 2nd point is what I would like to achieve. As Tamhas has advised, I probably need to go for webclient since I hope it wont involve alot of 'overhauling' on my existing application to suit the technology.

I dont seem to be able to get detailed documentations on where I should start. Any help?

Regards

Hi Zadock,

If your application currently is a "fat client" type application where the UI accesses the database then you will be in for a bit of work. Assuming you will want to keep your existing UI it is best (from a licensing/cost point of view) to look at using WebClient to run your UI (WebClient itself being a free download). WebClient is basically a normal OpenEdge GUI client except for the fact that it does not allow you to connect to databases and that it has some "smarts" in it that allow you to deliver your application to the client PCs. Because WebClient does not allow you to access a database you will need to use AppServers to run the Business Logic that accesses the DB. Whenever you need data on the client you will have run a program on the AppServer to get it for you. Equally saving and deleting data involves running programs on the AppServer as well. Usually data is passed between the client and server by means of Temp-Tables. Depending on how your application is architected all this can be relatively straight forward or quite a bit of work - how much is hard to say without knowing what your application and the code looks like. The best way to do this type of change depends on how much time and money you have available to get the job done.

Best to start reading the docos that Stefan posted a link to - scroll down to Application Server and you can always post here if you have any specific questions

Good luck!

Paul

 

[GregTomkins]

If you're going to go to all the work of converting an old-style direct-DB-access OE application to AppServer, I wouldn't use Progress for the front-end UI. That's one of the sweet things about AppServer - you can use it with a Java, C# etc. client more-or-less, or at least arguably, as easily as Progress. And Progress's strength is not, IMHO, in the Win32 GUI. Best tool for the job ... again, IMHO of course ... and assuming you don't care about the deployment ease of a browser-based application... Progress AppServer + C# Win32 client.

 

[TomBascom]

If "on the web" is anything more than clueless marketing blather you probably need to start with an understanding of browser based user interfaces. Then you can decide just how far down that road you want to go.

If you go even a little ways down that road you also need to start learning about javascript. On the one hand there are a lot of misguided slanderous screeds about JS. The truth is that it is a pretty neat language with a lot of really excellent features. Sadly it is extremely case sensitive. IMHO it would be almost perfect if it were not for that flaw. Although "===" is another one that hurts my head

Also take some time to learn about CSS & HTML.

Web development tip #1 -- DO NOT DEVELOP ON OR FOR INTERNET EXPLODER. Use any other browser for development. Test on IE because there are still a shocking number of people using it and many of them have no choice ("corporate policy"). But 99.99999% of the time stuff that works elsewhere will work just fine on IE. If it doesn't work right away on IE the fix is probably simple. 100% of the time stuff that is developed for IE first will break as soon as it runs on any other browser. You will save yourself endless agony by following this simple rule.

 

[GregTomkins]

... but in JS, you are syntactically prohibited from using upper-case keywords. That alone should put it on the top of your favorite languages list!

I always thought Progress was the weird one for not being consistently case sensitive and that practically every other language was. I could be wrong though, I'm no programming languages scientist.

 

[TomBascom]

Case insensitivity has always been a "Progress Difference" that IMHO should be much more widely adopted. The common case ought to be case-insensitive. Case sensitivity should be something that you have to work at to get.

Fixed length data is the same way. All data should be variable length. Fixed length data should be an exception that requires extra work to implement and enforce.

 

[GregTomkins]

Total agreement about fixed length data. That whole SQL obsession with declaring lengths and screwing around with them constantly ... I'll never understand it. Well, I don't understand anything, really, about the endless series of pointless frustrations that is SQL, and how 99.99% of the programming world is oblivious to there even being any other way.