I am trying to use the in-built service pub.flow:throwExceptionForRetry as a flow step in the FINALLY sequence of a flow service which is invoked by a
webMethods Messaging Trigger for which the Transient Error Handling Properties are set as :
Retry until = Max Attempts Reached Max Retry Attempts = 3 Retry Interval = 10 seconds On Retry Failure = Throw Exception
I have disabled the Adapter Connection which is utilized by the JDBC Adapter invoked in the Flow service to simulate the below Error :
[ART.117.4002] Adapter Runtime (Adapter Service): Unable to invoke adapter service TestPOC.adapter:selectperson with connection Test.connections.jdbc:Test.
which I extract in the CATCH sequence from lastError/error and map to string variable “error” which is subsequently mapped to wrappedException input of pub.flow:throwExceptionForRetry service
But when I publish the document then the mail is getting generated only once signifying the trigger service is invoked only a single time and no subsequent automatic retry happens.
Note : For the Trigger service Transient Error Handling Properties are default values as
Does your service goes into the branch step < throwExceptionForRetry> of the final block ? Can you add the debug log and verify it ? I suspect branch on expression is not working.
Your setup looks good. It should retries 0 , 1 , 2 on last attempt your service consider retry on failure to throw exception.
I agree with Dinesh that adding some dbug logging for verification will be helpful.
Additionally you should note that any variables, that are created in the Main-Sequence are not visible to any step in the Finally-Sequence or later even when they appear visually in the pipeline in Designer.
Depending on wM version you might want to check for the new TRY-CATCH-FINALLY template introduced with wM 10.5.
This avoids to create the Try-Catch construct manually.
The trigger is not configured to retry, so it isn’t retrying. Set the max retry attempts to non-zero. You will want a retry interval too – no sense in failing X times in a few milliseconds.
There is no need for the “finally” block from a functional perspective. In the current structure, it will be executed even when there is no error. You’ll want to use a BRANCH instead to check if “error” is not empty (you can use a regex: /\S/ as the label) then execute the block. You may also want logic of some sort to determine if the error is really transient. Blind retries regardless of the error will almost always bite you at some point.
So you suggest that error variable which I am populating in the CATCH sequence of the MAIN Block would not be available in the FINALLY sequence at runtime.
For the webMethods Messaging Trigger in theis case trigger:subscribeError I had configured the below Transient Error Handling properties.
Retry until = Max Attempts Reached Max Retry Attempts = 3 Retry Interval = 10 seconds On Retry Failure = Throw Exception
For the flow service i.e, lastErrorSubscribe which is invoked by the Messaging Trigger trigger:subscribeError the Transient Error Handling Property for the flow service is
Max Retry Attempts = Retry Interval = 0
I was under the impression that the if we specify the Transient Error Handling property in the messaging trigger then we do not need to specify the same Transient Error Handling property in the invoked Trigger Service as it will be overridden by the Messaging Trigger Transient Error Handling properties. Is this assumption flawed?
You’re right – as long as you have the trigger configured for retry it should do what is needed. As you state, the config on the service will be ignored. From the help docs:
Configuring Transient Error Handling for a webMethods Messaging Trigger
webMethods messaging triggers and services can both be configured to retry. When a webMethods messaging trigger invokes a service (that is, the service functions as a trigger service), the Integration Server uses the webMethods messaging trigger retry properties instead of the service retry properties.
I also misread your post and thought the config you shared was for the trigger settings, not the service. Sorry for that misunderstanding.
For the structure you shared above, what are “Exit on” settings for each SEQUENCE? I’m wondering if it is set to DONE, that the throwExceptionForRetry is being ignored.
I have added the debugLog as depicted in the below diagram and after I publish the document only the below entry is logged in Server Log
debugLog : Message input =
Retry Count is : %retryCount% Error is "%error%
*[9716]Error is "[ART.117.4002] Adapter Runtime (Adapter Service): Unable to invoke adapter service TestPOC.adapter:selectperson with connection Tes.connections.jdbc:EDP. * [9715]2021-03-11 06:18:30 EST [ISP.0090.0003C] Retry Count is : 0
MAIN ( Exit on Success )
TRY ( Exit on Failure )
TRY ( Exit on Done )
FINALLY ( Exit on Done )
For the FINALLY Sequence I tried changing the EXIT ON property and retested by Publishing the Document but still only no Retry happened
FINALLY ( Exit on Done ) : only 1 email generated signifying no Retry
FINALLY ( Exit on Failure ) : only 1 email generated signifying no Retry
FINALLY ( Exit on Success ) : No Email generated signifying the flow exited from FINALLY after successfully executing the first flow step getRetryCount
Can your share your package or let us know what you configured for branch step label in finial block. Because I could see error log with retry count 0.
At Design Time for the flow step pub.flow:debugLog I have set the input parameter message as below with the Perform Pipeline Variable Substitution Checkbox checked and it is working fine and logging the information in serverLog
Retry Count is : %retryCount% Error is "%error%
What I meant was that it is Logging the information in SeverLog as expected but it is logging for the first/initial publish executed from my end but not for the suppose to happen Subsequent Retries indicating that No Auto Retry is happening
[9716]Error is "[ART.117.4002] Adapter Runtime (Adapter Service): Unable to invoke adapter service TestPOC.adapter:selectperson with connection Tes.connections.jdbc:EDP. * [9715]2021-03-11 06:18:30 EST [ISP.0090.0003C] Retry Count is : 0
For the SEQUENCE under BRANCH the Exit On property was already FAILURE
And yes as you mentioned the FINALLY Block is not required and I concur on that. Will remove it as retry.
For the BRANCH step the Evaluate Label property is set to True and for the SEQUENCE under it the Label is set as %retryCount%<%maxRetryCount% with Exit On as FAILURE
For sending the flow via attachment let me see on that too
The Exit on DONE is the first culprit. Change it to Exit on Failure or remove it.
The other culprit is mapping the error string to the wrappedException which needs to a Throwable object. This causes a java.lang.ClassCastException: java.lang.String incompatible with java.lang.Throwable exception. Which clobbers your retry attempt. Don’t pass anything to throwExceptionForRetry. Not really needed.
I removed the error mapping as suggested and tried with the FINALLY sequence with Exit On as Failure and and also without the FINALLY sequence and in both the cases now the Retries are happening as configured.
Can you please elaborate on how the Exit on DONE for the FINALLY sequence was playing spoilsport ?
Exit on Done basically ignores errors. If a step throws an exception, the SEQUENCE ignores it and continues on to the next step. For the retry to work, the exception must be allowed to exit the service.
