Project and Portfolio Management Practitioners Forum
cancel

SYNCH_EXEC_INIT_WAIT_TIME

Highlighted
dirkf
Acclaimed Contributor.

SYNCH_EXEC_INIT_WAIT_TIME

The Admin Guide discusses some parameters for the wait-page of requests on execution steps.

 

These are the following:

SYNCH_EXEC_INIT_WAIT_TIME (default: 4 secs)

SYNC_EXEC_POLL_INTERVAL  (default: 4 secs)

SYNC_EXEC_MAX_POLL_TRIES  (default: 15 secs)

 

There have been some misunderstandings on how this is supposed to work.

 

The general understanding seems to be that when set, the *INIT_WAIT_TIME-parameter will kick in after a certain wait time if the request workflow step execution has then not finished and will then wait for the given value amount of time to check by the poll interval if the execution has finished.

For example:

The execution step is triggered and finishes after two seconds – no wait page is shown

The execution step is triggered and would potentially finish after six seconds – the wait page kicks in after four seconds and after an interval of another four seconds, the *POLL_INTERVAL checks for completion.

 

This is wrong!

 

The design is as follows:

 

With the *INIT_WAIT_TIME-parameter set to four seconds, when you click the workflow button on the request detail page, the page will wait for 4 seconds; during these 4 seconds nothing is done, it will not execute the execution step. What happens is that the execution step (including ksc_store command) will start execution after four seconds if SYNCH_EXEC_INIT_WAIT_TIME=4, thus after this time the page will go to the wait page (intermediate Request Working page), and the execution step is active and starts executing.

 

Once this has happened and with the *POLL_INTERVAL on default value of four seconds, the wait page will check if the execution step has completed after four seconds. If yes, it will return to the request details page in the next status (if the step completed successfully); if not, if will again poll for four seconds for completion. With the default settings, it will continue to poll for a total of 15 times before timing out.

 

Hope this helps to clarify for the future.

 

KM00615420 has been written with this information.

4 REPLIES
Erik Cole
Acclaimed Contributor.

Re: SYNCH_EXEC_INIT_WAIT_TIME

With the *INIT_WAIT_TIME-parameter set to four seconds, when you click the workflow button on the request detail page, the page will wait for 4 seconds; during these 4 seconds nothing is done

 

What's the point of this?

MikeCF
Respected Contributor.

Re: SYNCH_EXEC_INIT_WAIT_TIME

Neither before nor after changing the default values of the parameters SYNC_EXEC_INIT_WAIT_TIME and SYNC_EXEC_POLL_INTERVAL they are listed in the administration console.Why?

Are these parameters really considered because we don't really notice any changes in the behavior (faster display of the intermediate request page).

 

Thx

Michael

dirkf
Acclaimed Contributor.

Re: SYNCH_EXEC_INIT_WAIT_TIME

Hi Mike,

 

not quite sure about your question. The parameters that you list are spellt wrong, since the SYNCH is missing an H, something that was documented and fixed earlier. they don't appear as values in the admin console? they should show if added via the server.conf and kUpdateHtml was run.

The should also then take effect.

Make sure that true / false are listed in small letters which I believe is correct

 

Best regards,

Dirk 

dirkf
Acclaimed Contributor.

Re: SYNCH_EXEC_INIT_WAIT_TIME

Hi Eric,

 

I went back to RnD to get further explanations on your questions and received the following reply - hope this helps.

 

"I have discussed it internally and we also think this is meaningless to let the page wait for 4 seconds with nothing to do. So we earlier made the wrong conclusion that “PPM  is waiting for the results of an execution step which runs a special command”. Actually it will not run a special command and just wait.

 

And then I did further investigation and set a break point just at the wait function, and I found the request fields have been saved to DB this time, so there’s some idea come up to my mind, I think there may exist blow scenario:

1)      The RT has many rules which may 300+ so it will take 2 seconds to finish all UI rule and SQL rule, and the execution step may run a special command depends on the rule result.

2)      The request is saving to DB and the execution step need a value which input in previous step, but it haven’t saved to DB so you may get the old value if not wait some seconds.

 

Best regards,

Dirk