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.