Program Stack
- Thread starter Kalan
- Start date
RealHeavyDude
Well-Known Member
That is because the AppServer is a seperate ABL session and the call stack that does not expand outside the session boundary.
Is there any particular reason as to why you want/need to know the name of the client-side procedure that invoked the AppServer? I am asking because usually something like this smells like attemting to make AppServer code "client-aware". If you really, really need such information on the AppServer you must make it part of your own context management.
Heavy Regards, RealHeavyDude.
Is there any particular reason as to why you want/need to know the name of the client-side procedure that invoked the AppServer? I am asking because usually something like this smells like attemting to make AppServer code "client-aware". If you really, really need such information on the AppServer you must make it part of your own context management.
Heavy Regards, RealHeavyDude.
mollyfud
Member
Would be good to understand your reason for asking. I am fairly sure, especially after just testing with 4GLTracing, that the AppServer can't tell the procedure name of the client that calls it. In later versions, there is a lot more information about the clients but not that information. For debugging, and I haven't done it for a while, you can step into the AppServer code from using the debugger from the client side but not the other way around.
If you have a real reason you think the ability to determine the calling procedure on the AppServer is needed, you may want to document the idea in the Progress Community Idea section (Enhancement request). Details on doing that are available in this article: http://ow.ly/Cjtay
TIA
Molly
If you have a real reason you think the ability to determine the calling procedure on the AppServer is needed, you may want to document the idea in the Progress Community Idea section (Enhancement request). Details on doing that are available in this article: http://ow.ly/Cjtay
TIA
Molly
GregTomkins
Active Member
Somewhat related question: from inside ActivateProcedure, does anybody know of a way to find the name of the procedure that is about to be executed, eg. the one that the AppServer client did a RUN ON SERVER of in order to trigger ActivateProcedure?
I know there is CURRENT-REQUEST-INFO in v11, and I assume that's what this does, but I don't have access to v11, so I'm hoping there is some other way.
I know there is CURRENT-REQUEST-INFO in v11, and I assume that's what this does, but I don't have access to v11, so I'm hoping there is some other way.
Kalan
Member
Purpose of identifying the calling procedure, there are 2 different UI interfaces calls my server side internal procedure. Business logic dont want to do specific alert raising process if its called from particular UI otherwise it becomes redundant. I've managed to achieve this by setting Control Flag variable in server side logic. However, if source-procedure/program-name(2) works like client-server mode then my work would be more easier 
Thanks for all your clarifications.
Thanks for all your clarifications.GregTomkins
Active Member
IMO, you shouldn't control that sort of thing based on program names. Instead you should use some kind of 'client_type' or 'alerts_required' flag (passed from the client to the AppServer) to indicate the behaviour that each client expects.
In the end, it amounts to pretty much the same thing ... but as a general rule of thumb ... program names should never appear in code (outside of a RUN statement) ... anytime I have done that I ended up regretting it ... it's just one of those things that ain't right, like hard-coding user ID's.
In the end, it amounts to pretty much the same thing ... but as a general rule of thumb ... program names should never appear in code (outside of a RUN statement) ... anytime I have done that I ended up regretting it ... it's just one of those things that ain't right, like hard-coding user ID's.
RealHeavyDude
Well-Known Member
+1.
Any logic that runs on the AppServer should be completely client-agnostic. Anything the logic needs to know must be part of the API or context management ( like security - authentication ). I would strongly advice anybody not to compromise this rule because it could come in handy in one specific use case.
Heavy Regards, RealHeavyDude.
Any logic that runs on the AppServer should be completely client-agnostic. Anything the logic needs to know must be part of the API or context management ( like security - authentication ). I would strongly advice anybody not to compromise this rule because it could come in handy in one specific use case.
Heavy Regards, RealHeavyDude.