just starting a little discussion regarding XML ports…
Whenever i try to use an XML port to import data i nearly always run into some issue that means i can’t use an XML port and end up reverting to a codeunit (luckily with XML buffer this is now fairly simple) XML ports are generally find for quick internal transfers but if you want to integrate with another system then i’m starting to think why even bother with an XML Port?
The issues include :-
anything other than very basic namespace declarations
Variation in which fields will appear (i.e. some fields will be in the file but not in XML port and vice versa) UseLax should be the solution but I’m yet to find a situation where it’s of benefit
Order of fields varying in the file
Slightly clumsy to work with if there’s a mix of direct field mapping and variables
I’m currently working on a pretty complex implementation and every time i’ve needed to import some XML data one of these issues has become a deal breaker and i’ve fallen back to using a codeunit. Looking on the forums there are few if any decent solutions to any of these problems.
It seems like yet another case of so close yet so far from Microsoft, something that should be a really simple and powerful solution is rendered almost useless by a few simple shortcomings and oversights. Does anyone else have any of these issues? or disagree with me completely?
I’m mostly using XMLports for simpler exports. When it comes to imports, then they are often not flexible enough.
I am mostly using the dotnet XML controls for importing, which gives me all the flexibility I need. With NAV 2018/Extensions/VSCode, most of these functions have even become “native” to AL.
In the way of design/mapping, then the XMLport object is really just a “modernization” of the old DataPort object, which died with the RoleTailored client. It’s “clumsy”-ness is just a sign of that I think.
Personally I have never really missed any additional functionality, when we have both options. Don’t think that it is a fallback to use a codeunit.
But going forward then I’m sure that the Data Exchange Framework will replace both a lot of code and XMLports, when it comes to handling XML files. The DEF may take a bit of time getting familiar with, but once you are, then it’s a great tool for handling all kinds of XML (or text) file imports and exports. Have you looked at this?
that’s all i really use them for now, which is a shame… I never really found dataports overly useful either.
I did look at the Data Exchange Framework a while ago, i found it a little over complex for most requirements. I’ll give it another look though, thanks for the tip!
Hi Garry,
Dataports had the same issue, best for “simple” challenges.
Yes what talks against the Data Exchange Framework is that it does take a bit of “extra work”, but in return then error handling etc. becomes much easier. Once you have done it a few times, then you can copy paste most of it.
On of my favorite “features” is that it allows you to import into an intermediary file. Useful when working with orders etc. I mostly learned it by study the many ways it’s used in standard NAV.
I am definitely not an expert like many of you here, but I do have the yay as supposed to nay answers here so far.
We used XMLports extensively at our company. We are in the retail business and we use XMLports for processing inbound orders from various different sources, we use it to communicate inventory data to 3PL warehouses as well as sending orders to them to pack and ship, we use it for service orders, the list goes on… AND we hardly ever run into any issue that can be attributed to the use of XMLports alone.
That said, I am definitely In the opinion of Dataports. They are so inconsistent, buggy, and quite frankly down right dangerous to use in Production.
Navision was designed as a robust and very simple to use system. In fact the original Navision slogan was
The Beauty Of Simplicity.
But we seem to have forgotten that. Navision was designed as a business tool, not as a geeky development language. Your average business person with some basic programming skill can make an XML port work and work reliably if done so within the constraints of what it was designed for, which was basically a replacement for dataports.
If you need to transfer data from one system to another, XML ports are a fast solid and reliable way to do so.
keeping things simple means that they will cost less, implement faster, be easier to test and will be more reliable.
That’s part of my problem with them, Microsoft have imposed limitations that don’t exist in XML that make them significantly more difficult to work with than they should be, for example I’m doing a Shipping Agent integration, it’s an XML file transfer basically output an XML file, wait for the response then import 2 fields from the response… sounds very simple.
the Export works perfectly as I’d expect, exports are generally pretty good with XML ports. the import however, there are thousands of potential fields in the schema so it is not realistic to replicate the entire schema (especially when I’d do all that work then hit a deal breaker that stops me being able to use it) If there’s an error then The Error node is included otherwise you get a Shipment details node, there is no combination of MinOccur, MaxOccur and UseLax that allows this schema to be processed, whatever options are chosen it’ll fail on either an error or a successfully processed document. these aren’t restrictions in XML it’s just some self imposed limitations in XML Ports.
another example, we receive XML order files from customers, some customers send through the elements in a slightly different order, which again is perfectly reasonable with XML, but there’s no way to handle this in an XML port, in NAV 09 there was a messy work around where you could add an element in every position it might appear with minoccur set to 0 and it’d handle it, that seems to have disappeared with later versions.
XML Ports just seem to strip away a lot of the flexibility that makes XML so useful and only allows for importing of very strict/static XML files… i.e. it’s not extensible anymore.
