Running .cls files over appServer

Posted by Lauri Greenbaum on 31-Jan-2017 02:03

Hi everyone,

I am in a situation where I am adding new appServer procedures and thought of making them classes. The background it that APP1 is calling procedures over appServer from APP2. Is it even possible to replace procedure in APP2 to be a class and use it in APP1. APP1 and APP2 have different GIT repos so the codebase is not the same.

Procedures are run in following way, is there any way to have the other end as class with methods.

run xx/xxxxxxxx.p persistent on server hAppServer set hAsProjectProductLink.
run updateProjectProductLink in hAsProjectProductLink
             ( table ttUpdateProjectProductLink ).

the first problem I see, is that how to use USING phrase in APP1 if .cls is in APP2.

OpenEdge Development - Forum

All Replies

Posted by Mike Fechner on 31-Jan-2017 02:22

The ABL does still have no concept of calling into classes on a remote AppServer.
 
Such a concept exists only for http callers (in 11.2 the session singleton classes were introduced for Mobile/REST clients and in 11.6 Web handlers for the new WebSpeed).
 
IMHO such a feature is way overdue in the ABL!
 
ABL clients should also be able to call into Session Singletons on a remote appserver.
 
For the time being, you will need to work with Proxy procedures on the remote appserver. You can implement the functionality in classes on the remote appserver – but need those .p’s to pass the call through.
 
11.4 added the ability to pass (parameter) objects to remote AppServers and receive them as well as error objects. That may be helpful with simplifying signatures of the procedures as a single object may replay 100’s (joking) of primitive parameters.
 
Von: Lauri Greenbaum [mailto:bounce-Metsakohin@community.progress.com]
Gesendet: Dienstag, 31. Januar 2017 09:07
An: TU.OE.Development@community.progress.com
Betreff: [Technical Users - OE Development] Running .cls files over appServer
 
Update from Progress Community
 

Hi everyone,

I am in a situation where I am adding new appServer procedures and thought of making them classes. The background it that APP1 is calling procedures over appServer from APP2. Is it even possible to replace procedure in APP2 to be a class and use it in APP1. APP1 and APP2 have different GIT repos so the codebase is not the same.

Procedures are run in following way, is there any way to have the other end as class with methods.

run xx/xxxxxxxx.p persistent on server hAppServer set hAsProjectProductLink.
run updateProjectProductLink in hAsProjectProductLink
             ( table ttUpdateProjectProductLink ).

the first problem I see, is that how to use USING phrase in APP1 if .cls is in APP2.

View online
 

You received this notification because you subscribed to the forum.  To stop receiving updates from only this thread, go here.

Flag this post as spam/abuse.
 

Posted by Lauri Greenbaum on 31-Jan-2017 02:25

TY for the answer, I agree, this should be supported by Progress

Posted by dbeavon on 31-Jan-2017 07:23

Maybe now that reflection is being added to ooabl, you will be able to reflect on your class and auto-generate the .p code that serves as a proxy to your class.   Then you could add a huge warning at the top of them /* AUTO-GENERATED. DO NOT EDIT !!! */

I agree that the proxy.p files are not ideal.  They aren't really a massive problem in and of themselves, but they lead to problems because their presence encourages the less informed ABL programmers to jam in their business logic instead of leaving them alone (to serve as simple "pass-through" programs.)

Posted by gus bjorklund on 31-Jan-2017 11:00

> On Jan 31, 2017, at 3:24 AM, Mike Fechner wrote:

>

> IMHO such a feature is way overdue in the ABL!

>

Appealing as this may seem at first, I think this is a very very bad idea. It will enable tight coupling of code across the network with no effort required. That will allow you to create stuff with no thought at all as to what should be sent and received over the network. This in turn will result in horrendously bad performance.

It will also make updating the code harder due to the tight coupling across machines.=

Posted by Mike Fechner on 31-Jan-2017 11:10

If this would be remote instantiation, I would agree. The singleton run model is far from that and nothing else that running a .P file.

Sent from Nine
Von: gus bjorklund <bounce-wizard@community.progress.com>
Gesendet: 31.01.2017 6:02 nachm.
An: TU.OE.Development@community.progress.com
Betreff: RE: [Technical Users - OE Development] Running .cls files over appServer

Update from Progress Community
gus bjorklund

> On Jan 31, 2017, at 3:24 AM, Mike Fechner wrote:

>

> IMHO such a feature is way overdue in the ABL!

>

Appealing as this may seem at first, I think this is a very very bad idea. It will enable tight coupling of code across the network with no effort required. That will allow you to create stuff with no thought at all as to what should be sent and received over the network. This in turn will result in horrendously bad performance.

It will also make updating the code harder due to the tight coupling across machines.=

View online
 

You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

Flag this post as spam/abuse.

Posted by Thomas Mercer-Hursh on 31-Jan-2017 11:22

How does introducing a stub .p create decoupling?

Seems to me that this is an issue of subsystem design and one is either going to design decoupled subsystems or not and the exact mechanism used for the link is irrelevant as long as the link is one of "running" something rather than simply sending a message.

This thread is closed