publish with delayUntilServiceSuccess

We’re having some problems with the publish built-in service on IS. When we specify delayUntilServiceSuccess = true, the service will still run and publish despite the flow throwing a ServiceException. For example, the flow looks like:

throw new ServiceException

From the description of the service option, the publish should not happen. I’ve also tried to use the EXIT construct (with failure), but that doesn’t prevent the publish either. The environment is IS 6.5 SP2. Has anyone else seen this issue?

Can you provide additional detail about the service? Is the publish within a child service? If so, the top-level service must fail for the publish to be stopped. How is the SEQUENCE step you show in the list configured?

Hi Rob-- there is a parent and child flow.



publish (delayUntilServiceSuccess = true)
EXIT ($flow and signal FAILURE)

For the child sequence, I tried changing the SEQUENCE to exit on FAILURE. I also tried to throw a ServiceException (using a java service), but that did not work either.

The problem is that the parent must exit with a failure, not just the child. The docs state that the top-level service must exit with a failure.

The best bet is probably to remove the try/catch structure in the parent.

Yes, that works; however, what I’m seeing is that you must use the EXIT construct. Throwing a ServiceException does not prevent a publish. This is a bit problematic for us, since we invoke a utilty service to throw an exception everywhere. I don’t suppose there’s a way to invoke an EXIT construct in java?

Why is a utility service being used everywhere to throw an exception?

Find out what an EXIT and signal FAILURE really does in terms of an exception or other state. Then you should be able to replicate that in Java.

EXIT with failure throws a FlowException. However, java services throw ServiceException’s by default, and FlowException does not derive from the ServiceException hierarchy. So I think we’re stuck rewriting some of our services, rather than fixing the one utility service. I’m also going to see if wM has any recommendations.

castropb: What would be the alternative? The only exception that is provided out of box is pub.flow:throwExceptionForRetry

The alternative is using the out-of-the-box option: EXIT and signal FAILURE. In the vast majority of the flow services I’ve written, using the EXIT step to signal a failure was more than sufficient. The only time I use something different is when I need to cause the trigger to “retry a document,” and in that case, I use pub.flow:throwExceptionForRetry.

I guess I was just curious to know why a utility service is being used everywhere to throw an exception.

  • Percio

I often use a Java service to throw a service exception instead of using an EXIT step. The reason is that using EXIT doesn’t always populate the lastError structure and therefore calls to getLastError didn’t return anything. This behavior may have changed of late but I’m not sure.