Error: com.wm.app.b2b.server.ServiceException: [ISS.0086.9311] Could not save pipeline to file

Hi all,

When I receive files from customer, Transactions on My webMethods shows status success, but it gets Service invoke err:

An error occurred invoking the processing service * for this document. The original error was com.wm.app.b2b.server.ServiceException: [ISS.0086.9311] Could not save pipeline to file *.

at pub.flow.savePipelineToFile(flow.java:156)

I find the reason why the problem happened here, but it’s still not be solved.

Is there any solution about that now?

Thanks.

Hi @Jerry_Wang2 ,
In the attached topic, the problem seemed to be with having “:” colon in the filename, can you share what is the filename you are trying to save to? It is not clear from the error mentioned in your post. Or you could share the full stacktrace of the error.

-NP

Hi @Nagendra_Prasad,

The file name is Test.txt.

The IS version is 10.3.0.0 and core fix have:
IS_10.3_Core_Fix4
IS_10.3_SPM_Fix1
IS_10.3_SPM_Fix2
Trading Networks Server 10.3 Fix 1
Trading Networks Server 10.3 Fix 2
Trading Networks Server 10.3 Fix 6

And the full message is:

 An error occurred invoking the processing service *.processingRule:handleInboundMessage for this document. The original error was com.wm.app.b2b.server.ServiceException: [ISS.0086.9311] Could not save pipeline to file *.processingRule_handleInboundMessage.

 at pub.flow.savePipelineToFile(flow.java:156)

 at sun.reflect.GeneratedMethodAccessor162.invoke(Unknown Source)

 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

 at java.lang.reflect.Method.invoke(Method.java:498)

 at com.wm.app.b2b.server.JavaService.baseInvoke(JavaService.java:411)

 at com.wm.app.b2b.server.invoke.InvokeManager.process(InvokeManager.java:751)

 at com.wm.app.b2b.server.util.tspace.ReservationProcessor.process(ReservationProcessor.java:46)

 at com.wm.app.b2b.server.invoke.StatisticsProcessor.process(StatisticsProcessor.java:54)

 at com.wm.app.b2b.server.invoke.ServiceCompletionImpl.process(ServiceCompletionImpl.java:250)

 at com.wm.app.b2b.server.invoke.ValidateProce

When the customer sends the file, there will be an error, but if it is executed in the debug mode and I resubmit the file, there will be no error.

From the error text , it looks like the filename is passed as “*.processingRule…” which contains a *, that is not a valid filename. You can check by using a pub.flow:tracePipeline to check the exact filename the service savePipelineToFile is receiving as an input.

-NP

Is this service being used for debugging or is it in place for “real” processing? The general guidance for the savePipeline* services is to use them for debugging only. And as observed in the error message, seems like the filename is being dynamically created. Okay in some scenarios but be careful with that. In general, we use static filenames since debugging/troubleshooting activities are short-lived so the filename does not matter and does not need to “survive” for any length of time.

Hi @reamon,

Thanks for your reply.

I cannot really understand that. Do the filenames mean the service names which are saved by savePipeline?
(just like *.processingRule_handleInboundMessage → * is a fixed string too)
If yes, the filename is fixed, not dynamic.

In additional, our test environment is in Debug mode, and we use savePipeline when debug mode opens.
We mainly hope that the information which savePipeline has saved can help us debug.
Is there any other alternatives for me to be able to debug service errors?

Thank you very much!

If this means IS is started with the -debug Debug switch, that’s fine but has nothing to do with savePipelineToFile. That switch impacts what is logged to the server log (which we’ve found to log far too much as it basically logs everything about everything, which makes finding a problem almost impossible – we instead selectively turn on specific facility debug logging when needed, which is relatively rare).

If this means watt.server.pipeline.processor is set to true, that’s fine (and is the default) but also does not impact savePipelineToFile.

Just to be clear, pub.flow:savePipeline does not use a filename. This service accepts $name which is simply any identifier you want. This one can use * and: and other characters as desired. It is not a filename. In this case, the pipeline is kept in memory referenced by the $name specified. Keep in mind this consumes memory and there is no way (that I’ve seen) to remove these from memory other than an IS restart (or call savePipeline in Designer or IS Administrator to set it to an “empty” pipeline).

pub.flow.savePipelineToFile accepts one parameter, fileName. You specify it. It must be a valid filename for the underlying system. Your original post shows an error message complaining about filename of “*”. Your second shows a filename of “*.processingRule_handleInboundMessage”

The * character is not allowed in filenames in Windows, as @Nagendra_Prasad noted. On Unix, can be used but probably not a useful part of a name.

The filename can be anything you want. It can reflect the name of the service in which it is used – though be mindful of characters that are not allowed in filenames for your platform. E.g. * and : should be avoided.

We use savePipeline/savePipelineToFile only when actively debugging a specific issue in non-prod (we never do this in prod). We never just leave them enabled all the time. Not necessary. Indeed, we rarely use these for debugging and instead try whenever possible to use the debugger. Edit: And we remove save/restore steps after debugging is finished to avoid inadvertent behavior. But sometimes save/restore pipeline services are needed when chasing an issue with a specific call. Be careful with these as leaving a restore pipeline call in place errantly can be a big problem and can be hard to find sometimes.

2 Likes

Hi @reamon,

Ah, that makes sense.
Okay, I will use the debugger instead of save/restore pipeline.

Thank you for your time!

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.