Hello! Hoping someone here might be able to push me in a direction to help resolve a long standing issue we’ve had (and by long standing, I mean about four or five years!).
I’ll start off by saying we are on an older version of PlanetPress - version 8.8 - and we do not have support which was why this issue has set around for ever (and yes - I’ve pushed for support to be renewed but since all we use PlanetPress for is to merge PDFs and print them out to a LPR printer destination, no one above me will approve the cost. I’ll also add that we did not write the Workflow and the company we worked with to design it we no longer have a relationship with so the whole situation is a mess.
So with that - I’m hoping this is a simple fix. We have been seeing for years when we run larger quantity print runs that it appears PlanetPress starts spooling files, then goes back to try to list the directory information but can’t find the files that it is already spooling. Normally wouldn’t be an issue, but what happens is after the spool is generated, PlanetPress prints out this XML-like debug information. Our Operations staff is mostly good at deleting this XML garbage printing out of the print queue, but occasionally they miss and then if no one in our mailroom catches it, it goes through our envelope stuffer, gets postage applied, and then gets caught which has a lot of downstream effects.
Here’s the message in the service console:
W3821: Error retrieving file attributes from INSERTPDFNAME.pdf: Invalid argument to date encode
The XML that prints out shows the files and their attributes like date and size, so the files mentioned in the log appear at the top of the XML garbage with no file size or anything. Again I’m removing the PDF name but I was able to re-create the problem with a virtual printer and was able to capture the XML garbage:
And then proceeds to list all of other filenames and information.
Now that I can re-create the problem without needing to burn through paper, does anyone have an idea? I know it is a long shot but we’re at the point of either we fix this or we totally rip PlanetPress out of the solution and find another product.
Yesterday I did some digging after I put up the post, and it looks like if I could just suppress the XML error messages printing out, I would be happy. I think I know what is causing it now - originally this was built with a web server component where one of our techs could open up a browser and release print jobs, but we abandoned it because the tech found it too difficult to use. However that web component constantly updates file counts which causes the error messages (PlanetPress is already spooling files that it thinks it needs to report the counts on).
What would be the easiest way to share the configuration?
I don’t recommend you share your actual configuration file out here, it is likely to contain sensitive information.
You could simply share a screenshot of the process that has the issue, that would already help in understanding what it does.
I think I narrowed it down to the web server component. It looks like the work flow loops through a few processes but what I believe is causing the XML garbage printing to pop up is every time it loops from ReleaseJob back to the subprocess BuildJobConsole, it’s already spooling files. So when the Folder Listing task on line 3 of the BuildJobConsole process runs, it’s trying to get information on files it thought existed but are already gone due to spooling.
Honestly - the error itself happening to me isn’t a big deal; It isn’t breaking anything with the spooling and printing workflow. However, the garbage XML output that prints is a problem as I mentioned above. If I could just suppress any error printing output I would be happy.
You could try adding a Text Condition task immediately before the Data Mapping task. That condition would check if the /files/@count value in the data file is equal to 0. If it is - or if there is just no files element in the file - the condition returns true and you can then end the subprocess.
Note how we’re setting the condition for a Numeric comparison which, if it errors out (presumably because there is no files element in the file) returns True, just like it would if the files/@count was set to 0 in the data file.
Good morning! Quick update - I added that extra line of logic in but it resulted in the same thing. I thought it might be helped to post the screenshots from the Debug Console as well as the XML junk output that PlanetPress creates (since I’m a new user I’ll have to make multiple posts). I already set our environment back - we only have one PlanetPress server so it’s always doing a snapshot, quick test, revert snapshot - but here are the screenshots if this helps. I left some non-identifying information in to follow the Console over to the XML junk that prints, but you’ll see that the first error line at 09:12:27.594 in orange is the line in the XML junk that says “error”.
Thanks again for all your help so far. This is an interesting issue and due to us having no support with OL (not my call), no relationship with the vendor that wrote the workflow with us (not my call), and honestly no expertise in-house on how the PlanetPress workflows actually run, with just been dealing with this for years.
OK, I understand a little better now. So the condition I provided earlier is of no help: the problem is not with the XML file itself, it is with the file locations that it contains.
It’s difficult to understand what exactly is going on without having the entire configuration at hand but from the little I can see here, the Process all jobs process is the one that triggers the Process Jobs process. That process runs a Folder Listing task for PDF files in a certain folder. And that’s where it becomes confusing: it runs another Folder listing input to check for the presence of a specific file, and then yet another Folder Listing task to capture the list of available PDF files…
That list is then split into individual files that are sent to the Release Job process.
But I can’t tell which process is sending the XML junk to your printer. Actually, it’s not junk, it’s just an XML listing of the PDF files that were found on the system by one of the Folder Listing tasks.
It would be easy for Support to help you out with that because they would have access to the entire config and they could explain how to implement a condition that prevents the process from sending the XML to the printer. But for a community forum such as this one, it might be a bit beyond what we can do unless you are willing to share the entire configuration (which I wouldn’t recommend anyway as it probably contains sensitive information).
Yeah I agree - it’s a foundational issue with the workflow. I was aware that the “XML junk” was the listing of PDFs but for what is happening with the output it is “junk” since it wastes paper and goes right into the shredder.
But yeah I’m in the same boat - I can’t tell what is sending the error messages to the printer. Like I mentioned in one of the earlier posts, I don’t care about the errors in the logs but I do care about the XML output.
We’re still deciding if we are staying with PlanetPress which will help lead the support conversation (It’s a spicy meatball in terms of cost to restart support for an application that we’re only using something that is just scratching the surface of what it can do).
Thanks for your help though! I did help confirm what I was thinking the issue is and we can determine next steps. Take care!
