Answered Converting Application with Global Shared Variables to Classic AppServer REST Service

django

New Member
Hello,

I currently have an ABL UI application which was originally written with the business logic separate from the GUI. I am trying to convert the frontend to a website but keep the underlying Progress business logic so I am attempting to use a Classic AppServer REST broker to interact with the existing business logic via an API.

The issue I am having is that the existing code makes use of a lot of Global Shared Variables but on the RESTBroker these Global Shared Variables seem to be shared between all requests to the API rather than just to the connections themselves.

I have tried to set the AppServer's "Operating-Mode" to "State-Free" but it didn't fix my issue.

Is there a way to use these shared variables on the RESTBroker without sharing them between all connections?

Thanks.
 

Cringer

ProgressTalk.com Moderator
Staff member
"Shared" anything is a recipe for disaster. One option would be to convert them to serialisable objects encapsulated in classes. It's a bit of work, but you can then share the specific objects over the AppServer layer. It greatly depends what they are sharing though as to how useful that is. Whatever the case, the sooner you move away from the "Shared" structure, the easier it will be!
 

django

New Member
Thanks Cringer.

I agree with you on the "Shared" variables. I'd like to get rid of them but its tough to find the resources to do it because it would basically involve refactoring the majority of the code for no perceptible change from a non-developers view.

I'm also trying to keep the existing backend code the same so that I can move the GUI across in stages so there would be points where both the new and old frontend are interacting with the same code. So to remove the shared variables I would need to refactor my existing UI code and existing backend code before I can start on the new UI.

Is there no way to make my current plan work and leave the backend code as is with the Shared Variables?
 

django

New Member
I think I've managed to solve my issue. I just had to change the "GLOBAL SHARED" to "SHARED" when creating the shared variables.

I hadn't read the specification for the define variable statement and just assumed the "Global Shared" keywords meant the same as global variables in other programming languages that I have used before. From what I now understand, I only need the "Shared" keyword to share variables between procedures and the procedures/functions they call since the "Global" keyword is a booster for the "Shared" keyword which means it can be accessed session wide. So in the AppServer's case, since there is only one session, this means the variables are shared between all connections to it.

So it looks like the shared variables will be sticking around for a bit longer. They aren't actually that problematic right now - I can't think of a time where a bug has been caused by them. I think this is because they are used as constants so are only set in the one procedure and are never changed elsewhere.
 

Cringer

ProgressTalk.com Moderator
Staff member
Glad you found a working solution, but trust me, you really want to remove them as soon as possible.
 

TomBascom

Curmudgeon
Converting from GLOBAL SHARED to plain old SHARED might also result in unexpected side-effects. When a shared variable is GLOBAL additional NEW definitions have no impact. But if it is merely SHARED each NEW creates a new instance and values that might have previously been expected to pass "up" a layer will no longer do so.

For example:

Code:
/* p1.p
 */

define new shared variable c as character no-undo.

c = "fred".

message "p1.p, a: c =" c.
pause.

run p2.p.

message "p1.p, a: c =" c.
pause.
Code:
/* p2.p
 */

define new shared variable c as character no-undo.

c = "george".

message "p2.p, a: c =" c.
pause.
 
Top