Denial of Service: activate MYSERVICE.DO_IT() ; No activation, but no $status

I decided to add this as an article because this is about the activate statement, even if someone does his best to push it into a discussion about newinstance; So I deleted my forum entry.

Return value

The values returned in $status following an activate statement are:

  • <0, if an error occurred. In this case, $procerror contains the exact error. Values of $procerror that are commonly returned by activate are shown in the following table.
    When a negative value is returned for $status, the values of parameters with direction OUT and INOUT must be considered to be undefined in the component that activated LitOperationName.

—————— above just for the eager chaps quoting the documentation ————————

LEARN: uniface DOES NOT tell you this denail of activation
but only 1st generation remote services are activated from the application, not 2nd generation ones.

Let’s assume:

operation GET_SESSIONINFO in SERVICE2 is implemented as

params
string p_sessioninfo : OUT
endparams
p_sessioninfo = “HARDCODED”

operation START_SERVICE2 in SERVICE1 is implemented identical to the one in our component:

v_myservice2 = “my_service2”
newinstance “SERVICE2”,v_myservice2
activate v_myservice2.GET_SESSIONINFO(v_sessioninfo)
if ($status < 0)
; do error handling
endif

From a form, we start SERVICE1 which in turn starts SERVICE2 ( U8.4.03, but it may happen to you as well).
Afterwards, we call an operation of SERVICE2 to get some information.

v_myservice1 = “my_service1”
newinstance “SERVICE1”,v_myservice1
activate v_myservice.START_SERVICE2()
if ($status < 0)
; do error handling
endif

v_myservice2 = “my_service2”
newinstance “SERVICE2”,v_myservice2
activate v_myservice2.GET_SESSIONINFO(v_sessioninfo)
if ($status < 0)
; do error handling
endif

the second newinstance returns -154; the service is already running (was started by SERVICE1)
and we have our v_sessioninfo (just assume it is a hardcoded reply).

Anything was fine and all worked quite happily and they lived in peace an harmony.
But one day, all the services have been assigned to run remote and the good times where over:

We run the same sequence, second newinstance still returns -154:
but v_sessioninfo was empty after the activate, even with a $status = 0 indicates no problems.

Debugger showed absolutely no processing (but no change in $status) for the line:
activate v_myservice2.GET_SESSIONINFO(v_sessioninfo)

Happy wintertime from Nuremberg/Germany (the on with the “Christkindlesmarkt”)

Success, Uli

P.S. Let me explain the issues in more detail (for those who need it):

1) The assignment where the services will be execute:

Scenario 1: ALL services run local; Scenario 2: ALL services run remote

– think we can agree that there is absolutely no justification to constuct existences of  local services under scenario 2

2) The implementation:
we have an operation in a service which returns a hardcoded value

– think we can agree that no matter which instance will be activated, we will get back a not-null value from this operation

3) The Observation:
Under Scenario 2, the v_sessioninfo is empty after the 2nd ACTIVATE (which returned $status = 0); this has not happened in Scenario 1.

The debugger showed that the activate line is ignored, but there is no $status indicating the denial of service (or in more detail)
– in the debugger, the cursor moves straight to the next line in “zero-time” (I do NOT pushed “step over”, to prevent further misunderstandings)
v_sessioninfo  is not filled at all
– $status is still 0 indicating nothing went wrong with the activate

0 thoughts on “Denial of Service: activate MYSERVICE.DO_IT() ; No activation, but no $status”

  1. Added a related content to Mikes excellent article about remote activation. Asked there what would be the difference when services are executed locally because the change from local to remote execution (just an ASN change which could be done even by an end-user) has made the difference here.

  2. Mike showed in his article that using handles avoid the problem. *** But managing handles via lists gives us a lot of problems (at least in 8.4). *** So I recommend the “1st generation” proxi as described above.

Leave a Reply