Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I suspect most developers who chose to write their own solution wrote their own classes for EDI to XML conversion because their end point integration supported XML (or they couldn't write to the db directly, or wanted to use XSLT to show the end user the data nicely). I've written parsers that "translated" into CSV and flat file formats, because that's what we needed to import. I've also written parsers to dump directly into a database. Parsing into XML usually represents a necessary step for some as a "middleware" kind of approach. If you don't need to do the intermediary step, then why should you? If you can write it out to the DB, by all means do so. You also didn't mention what documents you are doing, and I'm assuming you've built out the FA process in your application. RegEx should continue to work for you, and there's a lot of ways to skin the cat. </p> <p>With that said, my usual disclaimer applies. You are reinventing the wheel here. By miles. I understand your client's wishes, and glad you were able to meet the need. Frankly, I probably would have fired the client :) Since you only use Microsoft products, you've kind of hamstrung yourself. Looking around SO, BizTalk is more discussed than other packages. There's probably a reason for this, and as you found out, it's also very expensive. I'm a big fan of Liaison Delta - runs on Windows, uses Microsoft Foundation Classes at its core and allows you to translate any-to-any at a fraction of BizTalk's cost. Seems to me maintaining drag/drop "maps" is easier than maintaining thousands of lines of code, but hey, policy is policy :) Hope this helps.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload