Also, if we add Fetch XML in Web API rest call<\/strong>, then at times we do not get result due to few special characters added in fetch XML.<\/p>\n So, in this blog, we are mainly looking at how fetch behaves differently when adding some special symbols. We will also look at how we can handle special characters of fetch XML while adding in Web API rest call.<\/p>\n Now, first let\u2019s look into how the fetch behaves differently when adding some special symbols:<\/p>\n As we all know fetch XML is in XML format which follows below sample structure.<\/p>\n <fetch version=”1.0″ output-format=”xml-platform” mapping=”logical” distinct=”false”><\/p>\n <entity name=”account”><\/p>\n <attribute name=”name” \/><\/p>\n <attribute name=”accountid” \/><\/p>\n <order attribute=”name” descending=”false” \/><\/p>\n <filter type=”and”><\/p>\n <condition attribute=”name” operator=”eq” value=”test”<\/strong> \/><\/p>\n <\/filter><\/p>\n <\/entity><\/p>\n <\/fetch><\/p>\n This fetch works both times, whether we execute fetch XML programmatically or in Web API rest call.<\/p>\n Here, many times we get requirements where we need to add value in the condition tag programmatically, for example instead of value=\u201dtest\u201d we add value=\u201dTest Company A & B\u201d in condition tag programmatically for our test account record.<\/p>\n Now, the above fetch is changed to –<\/p>\n <fetch version=”1.0″ output-format=”xml-platform” mapping=”logical” distinct=”false”><\/p>\n <entity name=”account”><\/p>\n <attribute name=”name” \/><\/p>\n <attribute name=”accountid” \/><\/p>\n <order attribute=”name” descending=”false” \/><\/p>\n <filter type=”and”><\/p>\n <condition attribute=”name” operator=”eq” value=”Test Company A & B”<\/strong> \/><\/p>\n <\/filter><\/p>\n <\/entity><\/p>\n <\/fetch><\/p>\n But if we execute this fetch XML programmatically, it doesn\u2019t give us any result but if the same fetch is executed manually then it gives us result.<\/p>\n The reason behind this is the special character \u201c&.\u201d As the fetch converts &<\/strong>, \u201d<\/strong>, ><\/strong> and <<\/strong> characters to &<\/strong> , "<\/strong> , ><\/strong> and <<\/strong>.<\/p>\n So instead of \u201cTest Company A & B\u201d, the value should be converted and used as to \u201cTest Company A & B\u201d.<\/p>\n The final working Fetch XML becomes as below:<\/p>\n <fetch version=”1.0″ output-format=”xml-platform” mapping=”logical” distinct=”false”><\/p>\n <entity name=”account”><\/p>\n <attribute name=”name” \/><\/p>\n <attribute name=”accountid” \/><\/p>\n <order attribute=”name” descending=”false” \/><\/p>\n <filter type=”and”><\/p>\n <condition attribute=”name” operator=”eq” value=”Test Company A & B”<\/strong> \/><\/p>\n <\/filter><\/p>\n <\/entity><\/p>\n <\/fetch><\/p>\n Now, let\u2019s look at how we can handle special characters of fetch XML while adding in Web API rest call:<\/p>\n While running Fetch XML through Web API rest call, if we use fetch XML without any special symbol in value as shown below, then we get correct result without any error.<\/p>\n https:\/\/yourcrmname.api.crm.dynamics.com\/api\/data\/v9.1\/accounts?fetchXml=<fetch version=”1.0″ output-format=”xml-platform” mapping=”logical” distinct=”false”><entity name=”account”><attribute name=”name” \/><attribute name=”accountid” \/><order attribute=”name” descending=”false” \/><filter type=”and”><condition attribute=”name” operator=”eq” value=”Test Company A “<\/strong> \/><\/filter><\/entity><\/fetch><\/p>\n But if we have special symbol in value as in above fetch XML (for example, value=”Test Company A & B”) without converting special characters in values, then it gives error. This is since \u2018&\u2019 character in rest call is considers as start of next URL parameter.<\/p>\n So first we need to convert fetch XML to convert special characters in values as mentioned above. This will add &<\/strong> , "<\/strong> , ><\/strong> or < <\/strong>if there are &<\/strong>, \u201d<\/strong>, ><\/strong> or < <\/strong>characters in fetch XML. If we still execute below xml we will get error<\/p>\n https:\/\/yourcrmname.api.crm.dynamics.com\/api\/data\/v9.1\/accounts?fetchXml=<fetch version=”1.0″ output-format=”xml-platform” mapping=”logical” distinct=”false”><entity name=”account”><attribute name=”name” \/><attribute name=”accountid” \/><order attribute=”name” descending=”false” \/><filter type=”and”><condition attribute=”name” operator=”eq” value=”Test Company A & B”<\/strong> \/><\/filter><\/entity><\/fetch><\/p>\n Now, in script we need to use encodeURIComponent<\/strong> to convert the above created Fetch XML, so that \u2018&\u2019 character will be converted in its representative characters. The resulting working rest call will be as shown below:<\/p>\n https:\/\/yourcrmname.api.crm.dynamics.com\/api\/data\/v9.1\/accounts?fetchXml=%3Cfetch%20version%3D%221.0%22%20output-format%3D%22xml-platform%22%20mapping%3D%22logical%22%20distinct%3D%22false%22%3E%3Centity%20name%3D%22account%22%3E%3Cattribute%20name%3D%22name%22%20%2F%3E%3Cattribute%20name%3D%22accountid%22%20%2F%3E%3Corder%20attribute%3D%22name%22%20descending%3D%22false%22%20%2F%3E%3Cfilter%20type%3D%22and%22%3E%3Ccondition%20attribute%3D%22name%22%20operator%3D%22eq%22%20value%3D%22Test%20Company%20A%20%26amp%3B%20B<\/strong>%22%20%2F%3E%3C%2Ffilter%3E%3C%2Fentity%3E%3C%2Ffetch%3E<\/p>\n While modifying and executing fetch XML programmatically, we should always handle special characters as mentioned above. We should also handle special characters and then encode fetch XML while using it in Web API rest call.<\/p>\n Introduction We frequently use Fetch to search records in CRM and few times use the Fetch XML in code for ease of changing fetch query, if needed. Fetch XML also supports adding most of the special symbols. Due to this, most of the times we do not go in depth to check how fetch behaves\u2026 Read More »<\/a><\/span><\/p>\n","protected":false},"author":13,"featured_media":18201,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[65],"tags":[],"class_list":["post-15464","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-webapi"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/posts\/15464","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/comments?post=15464"}],"version-history":[{"count":0,"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/posts\/15464\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/media\/18201"}],"wp:attachment":[{"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/media?parent=15464"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/categories?post=15464"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/tags?post=15464"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Conclusion<\/h2>\n
![\"\"](\"https:\/\/www.inogic.com\/blog\/wp-content\/uploads\/2019\/04\/Get-started-with-QuickBooks-and-Dynamics-365-Integration.png\")
<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"