In our current environment, retry is handled at trigger properties instead at flow service level using throwExceptionForRetry service.

As per my understanding, trigger retry happens even when the transaction failed due to non-transient error and throw exception upon retry completion.
Later we can resubmit the failed transactions from MWS.

Due to lack of support team, now we got the requirement to provide a solution which removes the dependency of support team.

In other words, resubmit the request automatically when end system is up and running again.

Initially I thought of ‘suspend and retry later’ approach at trigger level, but in case the trigger will stuck in a loop if it is a non-transient error.

Other solution, I was thinking of writing a schedule service but did not find any build-in service which can be helpful in pick and push transactions.

Please advice another approach or pointer to implement the scheduled service approach.

Please note, we are using IS – 7.1.2 and Broker – 8

Thanks in advance.

A trigger service will be retried only if the service throws an ISRuntimeException. If failure still occurs after all retries are exhausted, and the trigger is configured with “Throw exception”, then it will throw a different type of exception.

The coder of the trigger service needs to catch all errors, determine if the error is considered transient and if so, call throwExceptionForRetry (this will throw an ISRuntimeException).

So your idea of using “Suspend and retry” will work and is predicated on the assumption that the service is able to reliably determine which errors are transient and which are not.

Thanks Reamon,

Currently in our environment, trigger is set ‘max retry attempt =5’, But trigger service is not using throwExceptionForRetry. Means retry will not at all happen and service will exit with failure.

Now I have the change, not to touch the existing code and resubmit the failed requests.
I think we can see these failed services in Monitor and resubmit these failed services.
We can use monitor in-build service pub.monitor.serviceControl:resubmit to resubmit the failed service. Could you please suggest any points to be considered while going ahead with this approach.

Thanks in advance.

• If the input to the service is a *node object, resubmission is not possible as the input to the service has not been saved (node is a unserializeable object)

• Be careful not to resubmit too many at a time. MWS does not “throttle” the resubmits in any way so if you kick off too many you can overrun IS, the end point or both.

So do you mean your service auditing/pipeline is ON/enabled in your flows and thus MWS Monitor shows all failures?

HTH,
RMG

Yes RMG, service auditing is enabled as below :
Enable Auditing - Always
Log on - Error and Success
Include Pipeline - On errors only.

Just want to reconfirm, Till we are not using throwExceptionForRetry service, service retry will not happen. Even though Retry property is set in service or trigger? Is this understanding correct.

Also, in which scenario we can documents in Monitor for resubmission. Like currently since service auditing is enabled and we are able to see services Monitor for resubmission.

Thanks in advance.

I have been given a new webMethods environment and told that the request is getting failed after 5 retries and support team has to manually submit the request from Monitor.

Since now I know that retry will not happen without throwExceptionForRetry service, I understand there should not be any retry happening in the environment when end system is down.

Or is there any other way to configure retry?

Please note, communication with end systems is via webservices.