I’m unable to use an XML file in Workflow’s Data Selector dialog. When I try I get the following error:
“The file is not an XML file or is corrupt (Reason: Tag expected)”
When I copy the text from the file in VS Code, open up a new window, paste the text in and save it, I can open the new XML file just fine in Workflow’s Data Selector dialog.
The file in question is from our production system and even produces the error after removing text from the file and saving it, and after running it through a Powershell script. Here’s a link to the file in question:
does-not-work.xml:
Here’s a link to the file that I can load without errors:
The file that does not work contains a binary BOM header. You can’t see it in a text editor because most text editors strip that header away (which explains that when you save it, the resulting file then works in Workflow). To see the binary header, open a Command prompt, type type does-not-work.xml and notice how the first few characters are unreadable.
EDIT: you can also view that binary header if you open the sample file as an ASCII file in Workflow. If you then remove the first 3 characters and save the file again, it will become usable as an XML file in Workflow.
For the next person that needs this, in the Emulation section in the Data Selector in the screenshot below, make sure to change it from XML to ASCII (this wasn’t clear to me initially):
Can you tell what the issue is based upon the ‘Open XSLT: W1603’ code? Or do you need to see the OL-workflow and the XML file in question? (The actual XML file is more complex than the example one I posted previously and I’d prefer not to post it on the forum.)
I assume you are referring to the XSLT I provided in this other post.
In any event, the issue doesn’t appear to be in the XSLT itself but rather in the task’s inability to load the sample data file, which suggests this problem is caused by one of two things:
This new file contains a few more or a few less invalid characters than other files. You will therefore have to adjust the number of characters being removed by the Add/Remove text task.
More likely, the file contains NO invalid character, in which case the Add/Remove text task renders the XML file invalid because it removes 3 characters that should stay in there!
Since your files are inconsistent, you may want to sanitize them more thoroughly before passing them on to the XSLT task. The following script could be used instead of the Add/Remove text task:
var fso = new ActiveXObject("Scripting.FileSystemObject");
var inputFile = fso.OpenTextFile(Watch.GetJobFileName());
var outputFile = fso.CreateTextFile(Watch.GetJobFileName()+".tmp",true);
// Clean up first line
var oneLine = inputFile.ReadLine();
oneLine = oneLine.slice(oneLine.indexOf("<"));
outputFile.WriteLine(oneLine);
// Write all other lines
while(!inputFile.AtEndOfStream){
outputFile.WriteLine(inputFile.ReadLine());
}
inputFile.Close();
outputFile.Close();
//Delete original file and replace with new one
fso.DeleteFile(Watch.GetJobFileName());
fso.MoveFile(Watch.GetJobFileName()+".tmp",Watch.GetJobFileName());
The script looks at the first line of the file and removes anything before the first < character. If there aren’t any extra characters before that, the script just copies the line over to a new file. It then proceeds to write the rest of the file as is, and when done, it makes the new file your current job file in the process.
Should I move my last question to the other thread, or I suppose it’s too late now?
Just a shout-out for PlanetPress in case any potential customers are reading this: PlanetPress has great customer support, better than any IT company I’ve ever worked with and I’m old, too old.
Thanks for your kind words, I will shamelessly quote you on this!
Your post does highlight an interesting point, though: no matter how hard we try, we all know that no software application is perfect. Those of us in charge of these forums have always made a point of openly discussing those shortcomings with our users, even if it means admitting to a bug, which I think sets us apart from other tech companies.
And you make a great point: the largest, most expensive project failures/over-runs I’ve ever experienced have been because IT companies have not been straightforward about the current status of their product or their support abilities (ahem, Amazon, Microsoft, Paypal, Google…). “Trust me, I’m smarter than you” is a risky business proposition. If I can see the risks I can weigh them and make a good decision. If all I can see is a black box with a billion dollar logo on it, then I have no idea what the risks are.
