FSM 6 - web client scripting - wait nicely for run to finish?

Hey @Brian Maus 

Have you found an answer to your question?

If not, can you elaborate what you are doing in point #2?

What functions are used? How? etc. If you can share your script it will be great.

Cheers!

Hi @Shneor Cheshin ,

I did not find a great method and got a feel from the baseline web client scripts that the use case exceeded the limitations of the web client scripting so I stuck with the hack in the original post.

While hacky this code has worked reliably in production and only offends the engineers, who have surely seen and written far worse. :)

(scripting is automation for flipping company-owned stock in-place into customer-owned via Requisition to PO to Receipt to Request to Part Usage to Invoice to RMA to Receipt triggered by button click on Requisition screen)

example web client script snippet:

//this is async so delay after calling to prevent underrunning invoice line generation
var theBillingResponse = executePerform('billing', thePerformBillingVars);
//call this which always runs for 5 seconds, giving perform time to complete
getDBValues('WAIT5SEC');
//get invoice information
var lineList = getDBValues('MACRO_INHOUSE_GET_INVOICE_LINES', [requsitionID]);
//use lineList to verify billing generation has expected output and then make Requisition Events, RMAs, and RMA Lines with lineList

example client script SQL function ‘WAIT5SEC’:

WAITFOR DELAY '00:00:05'

Hey @Brian Maus 

Thanks for the info.

I did not try this, but ‘executePerform’ returns a response. 

Can you check the response and decide if the execution is complete? It might be the response is returned at the begining of the ‘executePerform’ and then it is still an issue.

var theBillingResponse = executePerform('billing', thePerformBillingVars);
if(theBillingResponse .message!=null && theBillingResponse .message!='')
{
	Do something...
}

or check the size of the array returned?

if(size(theBillingResponse.MyBillingObject)> 0)
{
   Do Something...
}

Cheers!

The billing perform is asynchronous so the response is that the run started.

This would be a similar situation:

param ASYNC_THRESHOLD_SHIPMENT_POST = 100
 

call shipment post on a shipment with 200 items

var x = all lines posted?

x would false here as the scripting executes faster than the perform can update records- which why adding a delay somewhat helps. Other system activities may cause the perform to execute slower than the delay.

Rather - “complete execution past the delay”, so it’s a bit of a gamble about the delay length because it’s also interactive delay for the user.