Jiwa

DannyC wrote:Because that's whats provided for us in the standard File Watcher plugin. I'm sure I'm not the only one who takes that as the "best practise" then just customizes around that ideal.

If there's a better way of importing XML documents, it might be an opportunity to tweak the standard File Watcher plugin to show us.

Like I said, we ship the File Watcher plugin with an example of using the XMLQueueImport to make migrations from the old version 6 easier.

I guess we're being punished for that.

In the same plugin, you'll see an example of importing XML files NOT using the XMLQueueImport - line 141 of our standard File Watcher plugin. I stand corrected! this actually still uses the JiwaImportQManager!

Your XML document is showing up in Mandarin in XML Pad - indicating a possible wayward byte mark somewhere, as Scott already suggested.

Here's a fragment of code for the Process() method of the XMLQueueImport.ImportQueueItem:

Code: Select all

Public Sub Process()
   If Status <> ImportQueueItemStatuses.Succeeded Then

      ImportQueueItems.RaiseProcessItemStartEvent(Me)

      Dim lJiwaDocumentNode As System.Xml.XmlNode
      Dim oSourceXMLDoc As New System.Xml.XmlDocument
      Dim XMLType As String = ""

      Try
         oSourceXMLDoc.LoadXml(m_TransformedXML)
         lJiwaDocumentNode = oSourceXMLDoc.SelectSingleNode("JiwaDocument")
      Catch ex As Exception
         ImportErrorMessage = ex.Message
         Status = ImportQueueItemStatuses.Failed
         My.Application.Log.WriteEntry("JiwaImportQManager.Process error : " & ImportErrorMessage)
         iSave()
         Exit Sub
      End Try

As you can see on exception we log and swallow the exception - hence why your file stays where it does - but it should have logged it to the Event log!

Check it with a hex editor and compare it to a working file. I bet there is a hidden character there.

Checked. Nope, no hidden char. I'm using HxD Hex Editor. I'll see if I can dig up XML Pad.

Also try reading it in in the order screen

It imports fine when doing it via the GUI

Also try reading it in in the order screen
It imports fine when doing it via the GUI

My suggestion would be use decompiler and see if there is anything the screen code is doing that you are not, unless Scott or Mike can suggest anything before doing that step.

I downloaded XML Pad.
Yep, it's coming up in chinese chars but in Notepad++ and HxD Hex editor and any other editor it's seems to be fine.
So I have no way of knowing where that wayward character is. Or how to fix it moving forward. Incidentally this XML import has been working fine for well over a year. It only just started behaving like this in January.

DannyC wrote:It only just started behaving like this in January.

Any number of things might have changed which triggered the problem - an update to the XML parser library or something perhaps.

Am I understanding right that it works fine when importing form the sales order form, but it gives an error "There is an error in XML document (1, 1)" when importing using our business logic Deserialise method?

That doesn't make sense, because the form just calls the business logic Deserialise. I'll try importing your XML file.

Ok, so I imported your file using our standard file watcher plugin with no issue.

I made sure I did not edit your file - so I created a debtor account, parts and a logical warehouse with all the matching values so I could import your file untouched and it worked for me.

I'm thinking this might be an environment thing - a different version of some .NET component or something.

What about if Danny tried using the sales order form inside the scheduler to do it as a test, not as a final solution?

Or the only other thing is what about the user the process is running under?

SBarnes wrote:What about if Danny tried using the sales order form inside the scheduler to do it as a test, not as a final solution?

I don't know how that would work out - I've never tried to load a form from within a windows service before.

SBarnes wrote:Or the only other thing is what about the user the process is running under?

Certainly could be a factor.

I changed the encoding in Danny's file to this:

Code: Select all

<?xml version="1.0" encoding="utf-8"?>

And now XML Pad opens it fine.

Danny - can you try changing the encoding as per the above - verify it works, and then change it back to utf-16 to verify it does not work? I want to eliminate editors changing byte order marks having an impact or anything like that.

In a hex editor, there is no byte order marker in the file, which means it's actually what's known as UTF-8 without BOM.

But the file has the xml attribute indicating it is encoding utf-16 .

I think that is the problem.

Either get whoever is producing the file to put the utf-16 BOM header in the file, or get them to change the attribute in the xml to be utf-8.

Mike.Sheen wrote:I don't know how that would work out - I've never tried to load a form from within a windows service before.

I have actually inside the scheduler, I don't know if you remember but there was a bug a while ago where loading the process object for sales order without the form produced a null reference exception, your suggested work around was create the form and it worked.