Question LAN to WAN options

[Paul123]

Hi,
I wonder if anyone has any insights into moving a SmartObject application currently running in client/server mode on a LAN to serving a more dispersed group across an intranet. This involves a small group of users with a low volume of transactions. All locations have 100 baseT connections. Users currently use net setup for their Progress installation. The small amount of testing I have been able to do suggests this setup will not provide satisfactory results though having a local installation of Progress, and the application code, present on the client would be acceptable but more problematic for management. I think there will be a period where the application will need to go through a number of changes.

The WebClient and Citrix have both been put forward as possible options but I am not clear on the requirements for either of these scenarios or how much work would be needed, or what the cost might be if it were to be done outside. I have been under the impression that moving a SmartObject application to a WebClient would be quite simple if the interface and business logic are properly separated. This migration is also something that should have happened much earlier so there is also some pressure to move quickly.

Any comments or suggestions on these or other options will be greatly appreciated.

thanks,
Paul

 

[GregTomkins]

I don't know about SO's but we went through the whole process of porting from client-server to WebClient, with Citrix as an interim measure. My $.02;

1. Citrix is amazing and awesome, but for us was not a good long-term solution due to customer resistance and cost. It was great to carry us over a couple of humps, though.

2. Having said that, we have customers running WebClient *on* Citrix and quite happily. The reason is: our app might be 'WAN friendly' but it is one of many apps, some of which are not. Don't forget that you are sharing a PC with a bunch of other stuff.

3. We had a few relatively small but nonetheless "development required" issues to get our app to work on Citrix. Things like shared drives and registry keys. Not a show-stopper by any means, but, neither is it true that you can assume a "dedicated PC" app will run on Citrix without any changes.

4. 'would be quite simple if the interface and business logic are properly separated' is probably true but my experience is, 'business logic' is never separated quite as nicely as you think. There is often all sorts of 'business logic' implicit in things like FORMAT clauses and enabling and disabling of fields that may be trickier to 'separate' than meets the eye.

5. If you do end up doing a major rewrite, I'd seriously question investing a lot of $$ in a WebClient UI. I'd do it in C# or JavaScript, depending on the situation, and leave Progress for the back end stuff. That's just me though. I know there are lot of opposite opinions out there.

Good Luck!

 

[TomBascom]

And if you're looking at #5 spend a few minutes checking out Progress Rollbase.

 

[Paul123]

Thanks for your responses. I am really hoping to avoid having to a lot of code rewrite initially in order to move things along but will need to keep in mind the best direction for the application so thanks for the suggestions.

Some of the functional challenges I think we may encounter with Citrix (or WebClient?) might be the ability to launch and load data into applications like Excel, and drag and drop files to our application window and then storing the processed files on a server. If these are issues I imagine there is some work around that could be possible.

Having used both the WebClient and Citrix I am wondering how you think they compare in terms of the user experience and from a development/administration point of view.

 

[RealHeavyDude]

Running an ABL application as Web Client means that there is no database access on the client. It all has to go through the AppServer. You mention SmartObject but not whether it is ADM1 or ADM2. Only the latter, ADM2, out-of-the-box has the capability to run as an n-tier application having the business logic ( encapsuled in the SmartDataOjbect ) on the AppServer. Although the ADM2 ( the SDO in particular ) promotes to having the UI and business logic separated, it does not enforce it in any way. I've seen so many "bad" designed and programed ADM2 applications over the year that I doubt , when such an appliation is run client-server it will run seamlessly with AppServer. There is this ever populat CAN-FIND on a database table in an SmartDataBrowser or SmartDataViewer and and there might be all other sorts of procedures that have DB references which are designed to run on the client.

Heavy Regards, RealHeavyDude.

 

[GregTomkins]

I would say from a User Experience point of view, Citrix and WebClient are more-or-less equivalent, depending how you set it up (Citrix can be made to look like a whole separate PC running inside another PC, or, almost like any other application on a single PC. If you do the latter then normal users would not really notice much difference in most cases).

In terms of development of course it depends where you are coming from. If you have a legacy code base that has non-isolated DB/UI logic, then your only real option is Citrix. If you are starting from scratch I think most developers would firmly isolate this logic and that would lead them to WebClient to save the cost of Citrix.

In terms of admin/deployment, that's a massively complicated issue but bottom line I think that's always going to be a major challenge proportional to how many desktops you have to reach and how much control you have over them. 100 years from now, assuming there is still energy to power our servers, companies will STILL be coming up with new ways to deploy stuff and spending billions of dollars trying to figure out better ways.

When WC first same out we had high hopes that it would save us a lot of this hassle, but it really didn't; we invested a ton of time figuring out how to overcome limitations of the WC deployment utilities and we still have a whole department full of people whose sole job is to handle this. Now we are going down the browser road and once again it's massive hassle, in that case you replace the hassle of CAB files and so forth with the hassle of dealing with browser inconsistencies. The only truly solid smooth path to deployment is a CUI/Telnet based app, which is obviously the crappiest user experience and not all that sellable in 2013.

 

[Paul123]

It is ADM2 and yes there were some CAN-FIND functions in there. I have been getting more conscientious about the coding as time goes on but there is likely still more clean up required. Any ideas on how to efficiently find any stray database references? I have looked at the xref file output by the compiler. It lists database references but I seem to get, what I assume to be, false positives as browsers and viewers reference the .i associated with the SDO (which defines the temp-table fields LIKE the associated database fields).

 

[GregTomkins]

Good question for which I do not have a good answer!

Are you sure a LIKE reference doesn't require a run-time DB connection? I don't see why it would, but you might want to check that out. I'm sure another PT'er will clarify this shortly.

 

[RealHeavyDude]

There is the RCODE-INFO system handle. You can assign the FILE-NAME attribute to any r file you have and then check the DB-REFERENCES attribute. It will give you a comma-separated list of logical database names referenced which need to be connected when you run it.

That way, if you know whether it is supposed to be a client- or server-side procedure, you can easily determine whether it has gone "rogue" - or have made to be rogue by the responsible developer ...

Heavy Regards, RealHeavyDude.

 

[Cringer]

Good question for which I do not have a good answer!

Are you sure a LIKE reference doesn't require a run-time DB connection? I don't see why it would, but you might want to check that out. I'm sure another PT'er will clarify this shortly.

A LIKE definition only needs the db connected at compile time.

 

[Cringer]

There is the RCODE-INFO system handle. You can assign the FILE-NAME attribute to any r file you have and then check the DB-REFERENCES attribute. It will give you a comma-separated list of logical database names referenced which need to be connected when you run it.

That way, if you know whether it is supposed to be a client- or server-side procedure, you can easily determine whether it has gone "rogue" - or have made to be rogue by the responsible developer ...

Heavy Regards, RealHeavyDude.

The alternative is to compile with XREF and search for database references. In our system you search for "db.". I'm not sure if that's universal though.

 

[Paul123]

Thanks for the clarification on the LIKE reference. So I don't need to be concerned about those SDO include file references that show up in the xref file as database REFERENCEs. I have also noticed that certain database references are not identified with the REFERENCE reference type. I suppose I should look at all database references, as you suggest, using the database name instead of the particular reference type.