Question Openedge Oo Classes On Appserver Called From (windows) Client Application

Rutger Olthuis

New Member
I just started to dive into the world of OOP with OpenEdge and bumped into something.
How do I instantiate objects of classes that reside on the AppServer from my window client application?
Is this even possible or do I have to use some kind of procedural proxies to handle this?


Active Member
I'm curious to see what the crowd says - we don't use OOABL, but based on my good knowledge of AppServer and vague knowledge of OOABL Progress ... I doubt you can have an object on an AppServer that was instantiated directly by a Windows client. Or if you can, you'd need to be STATE-AWARE or something similarly prohibitive. The doc specifically says that you can't pass objects across the AppServer boundary. (I'm sure it's no problem to instantiate objects in Windows or on the AppServer, but that's not the same thing).

Rutger Olthuis

New Member
Thank you for your answer. I feared as much ;) To be honest, I think the restrictions around passing objects across the AppServer boundry pretty uhm.. well bugger.
Setting my workdir in the dir where my .r code is placed? Work dir must be ready-write and my .r code is in a read-only dir.
I want my objects to be in separate directories... modules divided, factory classes, DTO classes, repository classes and BL classes divided etc. Perhaps I could have all DTO's in the same dir and use that as a working dir. Might be worth a test. And of course I have to convince my organisation to move to OE114...

tamhas Sponsor
Personally, I am not in favor of sending objects across the AppServer boundary. If nothing else that locks you in to ABL at both ends. If it is a property object, why not convert it to JSON or some such that is architecture neutral. If it is an error object, why not handle the error and send an appropriate message to the client which can handle the message regardless of the technology of the client?

Yes, I agree that I am unhappy about needing to front an object on the AppServer with a .p, but I recognize that it may require adding something like a Main method to the object, or modifying the AppServer call to have object, method, *and* parameters, potentially for both the constructor and the method.

I have no idea what your issues are about directories. I certainly have never had everything lumped together and many people have r-code and source separate. Have you looked into PLs?

Rutger Olthuis

New Member
I was thinking along the same line with passing json or xml in a longchar and the same goes for messages. In my opinion the extended part of an error message should be put into a logfile and not be reported back to the client.

About the directory structure.. I refered to the documentation and video's I read/watched about passing objects across the AppServer boundary and those said that to be able to do this, the working dir of the AppServer broker should be set to the directory that holds the code (and I assume r-code in this case for all the obvious reasons). So I wonder (and I can test and will test that myself without any doubt) what code should be in that working directory. The just the .p procedures that are used as entry point? Or the class files of the objects that are communicated as well?

Sidetracking, I guess to start an application from windows shortcut you need a .p as an entry point as well since ABL classes indeed lack the "Main" method feature.

btw my money for Progress to call classes from the Client to the AppServer would be to extend the DO phrase with the option to add a Server handle. Something like:

   --all run statements and object initalizations/method calls are executed on the AppServer--

tamhas Sponsor
What to do with an error message depends on the error message. Certainly, I would generally be in favor of server side logging of server side errors where appropriate, but the client needs to know what happened.

I will let you pursue the directory structure issue. It sounds foreign to anything I know about.

Yes, one needs a .p for a shortcut or any other initial invocation. E.g., my ABL2DB utility, which is all OO at core, still has .ps to invoke the various services. They don't do anything except start the logging and provide parameters to the initial object.

That DO structure looks like it would require a persistent connection and multiple calls ... which, of course, one can do now. Their goal would be to have something that could be done in a single call.