Since the release of the Role Tailored Client, it is well known that dataports will no longer be supported in NAV. My first reaction to this was: "Oh no, how will we import bulk data into NAV then, if we don't have an XML file?"
And there was another problem; you weren't able to run an XML port directly.
As some of you know I'm speaking past tense here. Somewhere in the release process of NAV 2009, Microsoft listened to the community or had a brain wave and fitted in some new features for XMLports.
For those of you, who aren't familiar with the new features, just read along!
First of all, Microsoft added a number of properties to the XMLport that make this object type a lot more useful than it already was.
On the left side, the XMLport properties in NAV 4.0, on the right side the properties in NAV 2009 R2. Note that some of the new properties look a lot like properties that we all know so well from dataports!
Does this mean you can use an XMLport as a RTC supported dataport? Yes you can!
Now just look at some of those new properties :
Xml, Variable Text, Fixed Text
Tells the xmlport which type of formatting to handle. When setting this to variable or fixed text, you do not longer have an xmlport but a dataport in disguise.
The filename to use for the xmlport.
This property replaces the "FieldStartDelimiter" and "FieldEndDelimiter" properties of the dataport. In here you can set the characters that specify the beginning and end of a field.
This is the replacement for the old FieldSeparator property, for CSV files you can use ';' here.
This is the character that separates records when using a non-XML format. By default, this is "<NewLine>".
This is the character that separates tables when using a non-XML format. By default, this is a double "<NewLine>".
This property sets if you use a requestformpage when running the XMLport (!)
Is this starting to look like a dataport or not?
Another little known feature of the XMLport is the RequestOptionsPage. In here you can customize the equivalent of the old RequestOptionsForm that we know so well from the old Dataport.
Note that the caption of this page is used when running the XML Port, so keep this in mind.
To make all if this a little more clear, I've created a small example XML port that can export/import customer information in a CSV format.
First we create a new XMLPort with the following layout.
Keep in mind that the first element in a text-XMLport has to be a "Text" source type; I called this one 'Root'. The second element is a 'Table' element called Customer, with the Customer table as the data source.
Next I added the different fields I want to export/import. In this case the fields "No." and "Name".
So far we still got a normal XMLport that would produce the data in XML as a result. To get a CSV file format, I changed the following properties.
Finally, I filled the caption at the RequestOptionsPage and saved and compiled the XMLport.
In the old days, you had to run an XMLport from code. So next to the XMLport object you had to use a codeunit, report or function to get it to do its magic.
In the RTC this is not an issue anymore. Just add the XMLport to the RTC Menu suite and you are good to go!
When running the RTC, you'll find the XMLport in the menu suite. Just click it and you'll get our new XMLports RequestOptionsPage!
Just set the filters and click 'OK'. Next you'll get the following dialog.
If you choose to open the file, you'll see the result of our work.
The conclusion: We no longer even need the dataport! Because now, all Dataport functionality is merged in the XMLport.
"Does this mean you can use an XMLport as a RTC supported dataport? Yes you can!"
One HUGE problem with the new functionality in XMLport is, that it doesn't work from the classic client! That means you either have to move ALL users from Classic to RTC in one step without fall-back ability, or have duplicate code by having Dataport for classic clients and XMLports for RTC.
We usually end up rewriting existing dataports into reports with file.read or file.write statements. This is the only way to have the same codebase running in both Classic and RTC. Long live the amazing file handling of the RTC... NOT!
Time to move to RTC!
@Peter, considering the fact that you get the possibility to save or open the exported file. I don't see any problems in the file handling of the RTC in this case.
I didn't mean to say that the XMLPorts were bad. I'm just very frustrated about the lack of support in the Classic client. We normally go live with the RTC as primary client, but we still insist on having the Classic client as a fall-back client if when the RTC or NAV server causes problems. This is not possible without having either duplicate code or "code" our own import and export routines in i.e. reports.
My frustration about the file handling in the RTC has nothing to do with XMLports. It is the problem with the File system tabel and UNC paths, and the hassle with transfering files back and forth between the server and the client...
nice one...very useful..thanks
Is there any conversion tool available that would help me bring over all 20 or more dataports as it is and convert those to XML?
I am thinking I would still need to write a new XML port for all the dataports that I had developed in previous versions, correct?
Here's a little "universal" XMLport that lets you import data from any text file (regardless of field order) into any table: mibuso.com/dlinfo.asp
For people with multiple existing dataports, this could likely replace all of them, or at least make it easier to migrate them. If you want an XMLport for a specific table (for example if end users need to run it), you can create a copy of the XMLport and hard-code the table ID, then add any of your custom logic into the "doInternalPreProcessing" function.
There's also a dataport version at: mibuso.com/dlinfo.asp
Thank you. This has helped me a great deal the "data at the root level is invalid" that was eating me up error is gone