James

I've done some playing about with XML validators like http://www.xmlvalidation.com/

The use of reserved characters (technet.microsoft.com/.../ms145315(v=sql.90).aspx) like the '&' or '<' symbol does not itself cause a problem. It can become a problem as the feed is consumed. Where are you consuming the payload?

I believe that characters that appear in URLs that form part of the payload are escaped as these are assumed to be available for immediate use.

Jeff, thanks for the reply.

It's not just '&' or '<' it's also quote marks (") too - which must be escaped when in an attribute value.

To answer - its all about the consumption of the feed - it's what we're trying to do.

Specifically we're loading the payload into an .net XmlDocument. This validates (rightly) the xml as it loads.

I think we'll need to remove the link nodes prior to loading them into the xml document.

---

Note: This behaviour seems to be new (perhaps in a later 7.3 service pack), as we had a number of unit tests that were working in previous versions, and with the original 7.3 release. You probably want to raise this as a bug and have it fixed.

James

You will need to be the one that raises the support request with your local Sage office. Cases are prioritised on whether they impact a named customer. If I raise an issue it would sit on the backlog.

Jeff, thanks.

With the greatest respect, nothing will occur!

When we developed our CRM connector (many years ago) we raised a whole bunch of issues with SData and SOAP with our local (UK) development team.

Most of these issues have still not been fixed!

Unfortunately, we don't have a specific customer (we're pre-empting these issues); this will affect all our customers using our CRM connector.

It does seem like a fairly fundamental issue.

Thanks

James

I have emailed my colleagues in L3 Support. SData is used by the integrations between Sage CRM and a variety of different Sage BMS products. This is something that Sage does take very seriously. There may be differences in the assumptions about the way in which the XML is to be consumed. As I noted earlier when I ran validation checks with third party tools they didn't object to the XML returned by the SData request. That doesn't mean that there isn't a problem or that it shouldn't be fixed but it does mean that we have to be clear as to the business case that requires the change. That business case does need to be backed up by the request coming from you as we want to make sure that we support you in your sales.

Jeff, thanks for getting back to me & pursuing this.

Further testing indicates we cannot get any query containing a double quote to return. For example the query (encoded...not the %22 for the quote):

crm73/.../opportunity

Simply returns a malformed URL exception.

Thanks