Answered Transition from CUI to ASP/AppServer

[jim_shepherd]

I’ve been developing and supporting char-based Progress apps on Unix/Linux since the mid 1980’s. Occasionally, the customers will ask about giving the apps a “fresh look” (aka a GUI interface). We all get excited for a while but the conversation usually ends with the customer sentiment “I don’t want to pay 6-figures for a re-write just so I can click the mouse instead of pressing F1.” (I guess it’s a hidden compliment that they are still satisfied with the “meat and potatoes” of the apps.)

I recently encountered a firm with an in-house Progress character-based app that supposedly addressed this by re-writing important parts of the “front-end” in C# asp.net and keeping the back-end in Unix Progress. My understanding is that the “business logic” moved to AppServer, which somehow sits between the two.

My (long-winded) question set is: Has anyone successfully integrated asp and Progress like this? Is this a reasonable approach? Are there “best practices”? Can anyone show me a “Hello World” level tutorial or feasibility study based on this technology? Would the fact that the back-end is in Progress instead of SQL be a huge shock to a seasoned C# programmer? What do AppServer and/or WebSpeed bring to the game?

Thanks in advance for any advice --

 

[RealHeavyDude]

Come OpenEdge 10 ( some 10 years ago ) Progress introduced the open clients for the AppServer along with the ProDataSet. The OpenClient technology ( for .NET, Java and web services ) supports accessing business logic from other technologies as a service ( or in case of Java or .NET just like invoking the next method in the other library ). The ProDataSet even maps perfectly to data structures used in .NET ( ADO .NET ) and Java ( Java SDO ) which respective developers should find easy and seamlessly to work with. Come OpenEdge 11.2 ( some months ago ) they even support mobile application development that supports REST - though I did not have a look at that yet.

I am not familiar with .NET but I did a lot of Java application development using the Java Open Client to access Progress business logic running on the Progress AppServer and I can tell that the combination of these two - for Web based applications - really rocks. Furthermore I did not see many Java business logic developers really code hardcore SQL - most of them were using frameworks like Spring MVC, Hibernate or combinations of them. Can't speak for the .NET world though.

To answer some of your questions:

• Yes, many people have successfully integrated .NET and/or Java based UIs ( or even different ones using web services ) with the Progress AppServer.
• If you have a look here http://communities.progress.com/pcom/docs/DOC-16074 you will find a dedicated Open Client section that should contain everything you need ( it did what I needed ) to get you or a .NET or Java developer going.
• No, your seasoned C# programmer ( or Java crack if you want to ) won't be shocked.

Of course, as always, your milage will vary. I am saying that because experience showed me that it might be a steep learning curve for a seasoned procedural client/server developer to move on to different application architectures and object oriented programming.


Heavy Regards, RealHeavyDude.

 

[tamhas]

You have many, many options, but unfortunately all of them are going to require an architectural shift except one. That one is that there used to be telnet clients which would provide a sort of pseudo-GUI appearance without actually changing any code, but it is a sort of pre Win97 look at best, so hardly fresh. If, however, you bite the bullet and move your code to AppServer to separate the logic and data access from the UI, then many options are open to you. You can write the UI in ABL and use the ABL GUI for .NET tools to make an extremely up to date appearance. You can move to 11.2 and use OE Mobile to create browser and/or mobile device interfaces. You can use WebClient to deploy ABL clients across the internet. You can use OpenClient to deplay Java, .NET, or browser clients. 11.2 has REST support for that as well. The potential here is for a bigger change than just a fresh look, but the move from ChUI with all the UI, logic, and data access mushed together to AppServer layer separation is also a lot more than a weekend project. I just gave a talk to the Russian PUG on Practical Transformation which might give you some ideas. I should have it posted on my website later today. There are tools which could significantly reduce the cost of the project, but no magic machine, so you will need a serious business commitment to justify the work.

 

[tamhas]

Here's the presentation http://www.cintegrity.com/content/Practical-Transformation

 

[GregTomkins]

We have a fairly big (5,000 programs, 20,000 users) application that started off as Telnet; we ported it to Progress Client-Server; then to Progress WebClient (Win32 client), and for the last year or so I have been working on porting it to JavaScript. I don't have any real experience with porting to a non-Progress Win32 client, but it sounds as if you are not interested in that anyway. I also don't know too much about ASP.Net or the Java equivalents and I generally view those sorts of products with disdain.

In all cases, we have never really considered moving away from Progress for the back end, and, while I like to b**ch about various things, for the most part, I think Progress AppServers are a gift from God compared to writing the same sorts of code in Java/C# etc.

Anyway, here are a few thoughts:

1. My overwhelming daily thought is: I wish (in our older code base) things were better segmented and specifically, that business logic and UI were uniformly and cleanly separated. Your task will be an order of magnitude greater or less depending on how often you see things like 'FIND order, DISPLAY order' in the same .p file.

2. Making things overly dynamic (for example, generating UI's from server-provided widget definitions) sounds really cool and DOES have its place, but it can also be a path to madness.

3. The web world of JavaScript/CSS is really neat and interesting and I am really grateful for the chance to learn about it. But it is also a path to madness. You will find yourself spending hours and hours dealing with things that in Progress took you 5 seconds, and vice-versa. One little example: masking (eg. the ability to define an input field in such a way that it only accepts numbers) is easy in Progress, in web-land, not so much.

4. jQuery is one of the most awesome pieces of software ever written, but, in the same way that outhouses must seem awesome if you have only ever known ditches. I mean, I can't live without jQuery, but it's kind of crazy (IMHO) that web-land doesn't just work that way to begin with.

5. For web development, Stack Overflow is possibly the greatest thing to ever grace the Internet. Post a few web-land questions on there and you will realize what a tiny and insular world Progress is (no offense, Progress Talkers).

6. Be prepared for the fact that when you change things, for example the font in some part of your application or other because your new platform doesn't support the old one, a significant chunk of your users will hate you, even if to everyone else the change is completely innocent or obviously for the better. Think long and hard before making significant changes.

7. You will never completely or even mostly retire the old code. Ever. No matter how hard you try. You might retire some parts of it at great effort and expense. But eventually you will try to retire something that you are certain nobody uses but someone will come out of the woodwork, a crisis will ensue, and after that, you'll be a lot less keen on doing that anymore.

That's all I can think of for now! Good Luck!

 

[tamhas]

Wonderful summary Greg!

It is very likely that the project will seem overwhelming, but ask yourself if there is some piece of it that could be done separately and still be meaningful. E.g., if the only thing you have is a zillion people pounding away at terminals or terminal emulators, then it seems like an all or nothing proposition. But, if, for example, the ordinary order takers and the like are actually happy enough with ChUI ... I've had some threaten me if I made them use a mouse ... but there is another class of user like managers or salesreps or something that use a limited number of screens, then consider focusing on that as a first project. Once in house and some expertise built up, you can expand from there.

 

[GregTomkins]

I guess this thread is over but I wanted to add 4 more things:

1. It's super important to decide up front how much functionality you are adding or changing - eg. is your project "convert from CUI to GUI", or is it "convert from CUI to GUI, deal with every complaint and request in our backlog, restructure a bunch of schema, etc?". Obviously, the former is much more manageable and likely to succeed, but if you do that, you may open yourself up to "I can't believe you guys just spent $1,000,000 and 2 years without fixing problems X, Y and Z!!!".

2. It is helpful to have some reference to look at to resolve the inevitable GUI bike shed arguments. When we did our CUI-to-GUI project (one of my favorite and I daresay most successful projects ever), we used Outlook; whenever someone said "how should we do X?", we tried to resolve it by saying "what does Outlook do?". I'm not saying Outlook is the gold standard, just that it's useful to have SOME standard.

3. The single smartest thing I did on that project was to have a solid framework for handling report requests. There's a huge amount of things to think about there. Our solution is quite complex but it handles PDF and ASCII, allows for offline reports to be run, launches Acrobat, etc., and the code in each individual report (of which there are hundreds) is tight and minimally repetitive.

4. The single dumbest thing I did was to not have a solid framework for handling browses (aka grids, tables etc.), we have dozens and dozens of browses, they do complicated things like allowing users to make and save column preferences, and the code to do that is largely repeated in each program with lots of minor inconsistencies.

OK that's it now

 

[tamhas]

More good tips from the trenches, Greg. If I may glibly generalize:

1. Be aware of all of the things you might like to do, but don't seem to get to right now. If you get a commitment for one type of larger change, it is possible that there is a synergy in making other changes at the same time or at least in doing things in a way that will make it easier to make those changes in the future.

I will note that there are those who argue in favor of replicating the prior system exactly first and then making other changes. They have a point because that is an easily testable goal which is less likely to get out of hand. But, I think it ignores the fact that one rarely has the system one wants and that one should move toward the wanted system as efficiently as possible since one never has unlimited budget, resources, and time.

2. Establishing standards should clearly precede any work. Start now. Apply these standards to routine maintenance work; you will be incrementing the quality of the application, even if by small degrees.

3. Do as little work as possible, i.e., by creating frameworks, using program generation for predictable elements, or even going as far as model-to-code. The goal is the best application for the work exerted, not to write the most lines of code by hand.