Hi Experts,

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

Max Retry Attempts = 0
Retry Interval = 0

What am I doing wrong here?

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/037a1c8a8de3ba6ed614ed2a3576a8d078562a8f.jpeg 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/037a1c8a8de3ba6ed614ed2a3576a8d078562a8f.jpeg 2x" data-dominant-color="F7F8F8">

SAG970×378 54.5 KB

Hi Kailash,

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.

Regards,
Dinesh

Thanks Dinesh

Will try your suggestion of utilising debugLog

Hi Kailash,

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.

Regards,
Holger

Thanks for the response Holger.

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.

Perhaps I can verify this with the debugLog step

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.

Thanks for the inputs Raemon.

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.

@DINESH_J

Hi

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

@Holger_von_Thomsen

HI
the debugLog logging indicates that the error variable which I populated in CATCH sequence is available in the FINALLY sequence

@reamon,

Hi

Currently The SEQUENCE Exit On property is as

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

What about the SEQUENCE inside the BRANCH?

You want Exit on Failure. Not on Done nor on Success.

And as noted above, you really don’t need the “finally” steps in a SEQUENCE. They can be at the “top” level.

This indicates at the time of the logging, either those vars were not present or the var substitution checkbox as not checked.

Not sure if that is signalling current status or the config. If the latter, then that would explain why no retries.

Can you share service via attachment? And the properties of the trigger. Someone should be able to see what is amiss.

Hi Kailash,

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.

Two issues:

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.

@reamon

Sorry for not clearing stating earlier.

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.

@DINESH_J

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

Oh, okay. Thanks for the clarification. What is recorded in the log? You should also log maxRetryCount for this debugging activity.

@reamon

Only the below was recorded in Log :

*[2701]Max Retry is : 3 *
[2700]2021-03-15 05:02:36 EDT [ISP.0090.0003C] Retry Count is : 0

Also, PFA the IS Pkg for the same.

TestRetry.zip (10.6 KB)

@reamon

Thanks for you valuable inputs !

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 ?

Thanks,
Kailash

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.

Thanks @reamon it is crystal clear now !