RTC and XMLPorts behaviour

jpjesusjpjesus Member Posts: 45
edited 2010-04-26 in NAV Three Tier
Message: Invalid name character in 'soap:Envelope'. The ':' character, hexadecimal value 0x3A, cannot be included in a name.

See link for the original post details:
http://www.mymibuso.org/forum/viewtopic.php?f=32&t=39968&start=0&sid=6db8bf86c0c1bc5bd4e828924dc9be16



Maybe I am the only NAV developer that didn't know this....

The XMLPort behaviour while called from the Classic Client 2009 is different from the behaviour when called from the RTC.

Example:
The properties "UseDefaultNamespace" and "DefaultNamespace" have no influence whatsoever when the Classic Client is making the call. If the call is made from the RTC, the UseDefaultNamespace should be YES and DefaultNamespace = whatever NS you are using.
Specially if you are using nNS and SOAP.
When using this I no longer get an error and the XMLPort is executed. here is an example of the output (from RTC):

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"&gt;
<soapenv:Header />
<soapenv:Body>
<soapenv:SetItems xmlns="http://tempuri.org/"&gt;
<tem:Items xmlns:tem="http://schemas.xmlsoap.org/soap/envelope/"&gt;
<x:Header xmlns:x="http://schemas.xmlsoap.org/soap/envelope/"&gt;
<x:From>NAV</x:From>


For the exact same XMLPort when called from the Classic Client the output is:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<soapenv:Envelope>
<soapenv:Header/>
<soapenv:Body>
<SetItems xmlns="http://tempuri.org/"&gt;
<x:Items>
<x:Header>
<x:From>NAV</x:From>


As you can see, the behaviour is quite different as well the output.

One other thing I noticed. While using the Classic Client you can use the Attributes to add Namespaces. And it works just fine.
However, you cannot use Attributes in the XMLport in below the soap:Envelope. Here you need to use the properties "UseDefaultNamespace" and "DefaultNamespace".
But in the tag "SetItems" I am using an Attribute and the XMLPort works fine in Classic or RTC.

Another behaviour that I am still trying to figure out...
When using the Classic Client, I can use the XMLDom.Load (Automation: 'Microsoft XML, v3.0'.DOMDocument) and it works.
With RTC I don't get any errors, but it won't load anything....

Hope this helps other developers out there, as the information available on these issues is slim to none.

Comments

  • jlandeenjlandeen Member Posts: 524
    I have recently encountered a number of "differences" between XML Port behaviour when running under Webservices than through the Native NAV Client (i.e. non RTC Client).

    1) I continue to work under the assumption that NAV handles namespaces poorly and I always run any XML document submitted to NAV (via client, or other wise) through a function with runs an XSLT to remove namespaces from the document.
    2) Permissions - found that XML Ports ran fine in Classic client (i.e. without raising any error) even for XML Port Object ID's that were not licensed but when run via web service on the service tier they would raise a SOAP exception to the calling web services siting a permission problem (this was resolved with a license change - but still odd that same license is treated differently when running via NAV Classic or service tier)
    3) COMMITS DO NOT WORK - we tried to use proper error handling via the If codeunit.run(<variable>) Then...syntax and have a codeunit that handled calling the XML Port and scrubbing namespaces. The idea being that we could trap the error, fail gracefully and return some sort of controlled failure status to the calling application. However during testing we found that it worked properly when using NAV classic client to submit XML Ports but it did not commit any data if it was run through the Web Service (i.e. service tier). There is a hot fix available for this (see partnersource site).
    4) XML Port variables do not initialize properly - again different behaviour when processing XML file via classic client and via web service/service tier. In this case string variables were not being reset to '' after each element was processed. E.g. A Sales Header with lines is being processed, 1 header element and multiple child line elements, if line 1 had a LineDesc element with some string say "first line description here" and then line 2 had a blank LineDesc element, the XML Port would NOT reset the variable in the XML port and this would incorrectly write line 1 and 2 with a description of "first line description here"

    It is clear there are differences in how NAV Classic and the 3 tier architecture are handling XML Ports and some of them can be really annoying.
    Jeff Landeen - Sr. Consultant
    Epimatic Corp.

    http://www.epimatic.com
Sign In or Register to comment.