I have a short-term process that grabs a file via a Watched Folder and passes that file to an InvokeOneDocument (Assembler) service. Using the specified DDX, the PDF comes out with watermarking. That's what happens if there is no process failure.
The user asked me to drop a log file in the result directory in the event of a processing failure. The name of the log file should be based on the name of the input file. No problem. I used getDocAttribute to get the filename and routed the exception handler of the Assembler service to a Variable Logger. The logger is supposed to use the input filename as the prefix to the log filename.
I have a few badly formed PDFs that I am using for testing purposes to deliberately trigger a process failure.
Using the process recorder in Workbench, I have run the process with my bad PDFs repeatedly, and always with the same result...
everything is fine until the process gets to the Assembler (InvokeOneDocument) service and then all the variables get changed to "empty".
The process then routes to the Variable Logger, which no longer has the input filename to use as the prefix for the log file.
What is happening to my process variables that the string holding the input filename is getting cleared before it gets to the Variable Logger and how can I prevent this from happening?
Thanks in advance.
I have a work-around for the loss of the process variable values, but it's not as elegant as I would like.
I am writing a value to the filesystem and then retreiving it in the event of a process failure.
It works, but I would like a more... contained solution.
I pose the question, is writing variables to the filesystem and retreiving them as part of the exception
routing the best available solution (short of writing my own exception handler) or is there a better way
to preserve process variables in the event of a process failure?
Any insights would be appreciated.
I would try to fix the problem with the variable being cleared in the first place.
Can you post the xml of you process?