[sklett]

We have WorkFlow that manages notifications via a custom Workflow Action Script to an external system. The custom action utilizes calls to nlapiRequestURL() to make GET requests to the external system. As an order transitions through the pipeline (strategically modeled in the WF as various States) the custom action will be called, there are a total of 6 States in the WF that utilize the custom action.

When we were designing the WF we did not observe any network failures that would of caused us to design in a retry mechanism for the notifications. Now we’re experiencing regular timeout errors and the need to support retries is becoming more important.

I’ve been thinking of how to implement a retry mechanism and nothing is getting me too excited, here are some of the ideas I’ve had:

Pure workflow

Something like this:

(there WAS an image here, but apparently this forum removed it. Hmph!….)

Could be implemented like this:One custom action instance in the State will fire on Entry (status quo)
Store custom action result in WF field
Add condition to Transition checking action result
Use second instance of custom action with condition to only fire if result (step #1) was a fail, use delay and recurrence to retry
I don’t like this for a few reasons;It complicates each State that utilizes the custom action with a duplicate of the Action
Introduces minimum 60 minute delay to transition for what could be a general network fault that could be resolved with an immediate second attempt
Not reusable across State
Concern #2 can be addressed using yet another copy of the action that can fire right after the first with no delay – but… eww….

Concern #3 can be addressed (maybe) by using a separate Workflow for the notification. I could instantiate this workflow and the return back to the main one once it’s succeeded (or failed hard)

SuiteScript & WorkFlow HybridSomehow prevent the Transition to the next state
Add support to the Custom Action to call nlapiTriggerWorkFlow once it succeeds – basically changing the Custom Action result and transition to an asynchronous design
I don’t like this for the following reasons:Dragging WorkFlow responsibilities into script – breaking down my separation of concerns
Note sure if I can actually block the Transition in the WF and still satisfy it later when the nlapiTriggerWorkflow() call. I suppose I could set a field on the bound record that would be evaluated as a Transition condition. If we had a nlapiSetWorkflowFieldValue() I’d be set! This is a cached copy. Click here to see the original post.

[Author]

Posts