.Net wrappers for XML functions

[ghost]

We use System.Xml.XmlNode, System.Xml.XmlNamespaceManager, System.Xml.XmlDocument and System.Xml.XmlNodeList.

Will it be posible to use corresponding functions in D365 for this or will we have to rely on XML-ports?

[StanislawStempin]

We are working on providing AL types and functions that you will be able to use instead of the .NET XML* types. It will be available within the next few updates.

[ghost]

That was very good news!

Thanks!

/Lars

Från: Stanislaw Stempin [mailto:notifications@github.com] Skickat: den 27 april 2017 10:06 Till: Microsoft/AL AL@noreply.github.com Kopia: Lars Westman lars@goprowe.se; Author author@noreply.github.com Ämne: Re: [Microsoft/AL] .Net wrappers for XML functions (#175)

We are working on providing AL types and functions that you will be able to use instead of the .NET XML* types. It will be available within the next few updates.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/AL/issues/175#issuecomment-297643033, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVx3y_760Q25fz6Gs1tS0Re5gZnpSoQ3ks5r0ExKgaJpZM4NI5Yw.

[rdebath]

I just though I'd add to this, the UK government gateway for submission of online VAT, tax and accounting returns makes heavy use of XML and XML namespaces.

For this communication we used XmlDocument, Xpath functions, XmlNamespaceManager, Attributes, XMLHTTP for the basic creation and sending of the gateway message. (Both Automation objects and later DotNET)

For authentication of the message an "IRMark" has to be generated, this uses XML c14n routines specifically XmlDsigC14NTransform to create a normalised stream which has to be converted back to a string so the newlines can be regularised to what their Java libraries expect after which it's converted to UTF-8 and a SHA1 sum generated on all the message except the location that the hash is to be stored (encoded in base 64).

Unfortunately I was unable to create the IRMark directly calling DotNET DLLs from Nav, mostly because of byte arrays if I remember correctly. So I ended up with two actual solutions; make a custom DLL in C# or embed the C# in Nav and use System.CodeDom.Compiler.* and System.Reflection.* to compile and execute it. Both methods work fine.

In addition for online submission of CT600 corporation tax and general accounts they currently use iXBRL documents for mixed data and visual representations which have to be constructed as valid xhtml with the iXBRL additions. In one option these are embedded inline in the c14n'd gateway message. This doesn't work very well so they included another variant where the included document is encoded to UTF-8 as a whole and encapsulated as a single base64 string. While the generation of the iXBRL is complex it doesn't generally need heavy usage of the XML library; it does, however, need full control over the representations of the prefixes used in the namespaces as these prefixes are required to be embedded in attributes for their processing.

The VAT submission routines do seem to be a nice candidate for an extension, but it cannot work without a working IRMark.

[RasmusTidselbak]

@StanislawStempin Do you have an expected release time for the XML component on the dev preview?

[StanislawStempin]

I have good news - it will be released in the July Update.