Escaping text

[mikeread2018]

Hello,
We are currently using the FetchXML Builder to extract settings from CRM into json. Under the options we are using Serialized = JSON.
Some of the data we are exporting contains "fetch xml" queries. The Serialized Result doesnt escape the embeded values - therefore the json parser (just viewing in VS shows the errors) fails.

Is there anyway to escape the embedded values? Or can you point to code routine so we could attempt it?

Thanks inadvance - Mike

[rappen]

Hi Mike,
Would gladly have a look at this.
Do you have any example query and/or JSON?
There are a bunch of sites offering escaping of strings, if that should do it.
Example: https://www.freeformatter.com/json-escape.html

Jonas

[mikeread2018]

Hi @rappen

Here is a sample
test1.txt

The mr_content is typical of the type of output. I'll find a fetch example too

A simple code test:
var settings = JsonConvert.DeserializeObject(File.ReadAllText($"{path}test1.json"));

[mikeread2018]

A similar issue with the embedded fetch..snippet:

            {
                "name": "mr_content",
                "type": "String",
                "value": "<entities xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
						  <entity name="site" displayname="Site">
							<records>
							  <record id="dafbd21d-6666-66-66-6666">
								<field name="siteid" value="dafbd21d-6666-66-66-6666" />
								<field name="name" value="TrackTrans" />
								<field name="timezonecode" value="85" type="Number"/>
							  </record>
							</records>
							<m2mrelationships />
						  </entity>
						"
            },

[MarkMpn]

I’m looking at this now and I’ve got a prototype fix.

I’ve noticed while doing this that there are some places where this format could be made closer to the format returned by Web API - would that be a useful change to make at the same time? @rappen - I think you put the JSON serialiser into the xrmtb.XrmToolBox.Controls project originally, is the current format like it is for a reason?

[rappen]

The current format is basically what needed to be done to have anything...
So there are no "constraints" from my side on that point.
However if people (like Mike) are using it today to export using this format, they might expect to have no breaking changes to that format...

[MarkMpn]

@mikeread2018 and anyone else using this format: what impact would any of the following changes have on you:

1. Changing the format of the value to the native JSON type, e.g numeric or optionset attributes could change from:

{
  "name": "new_optionsetattribute",
  "value": "1"
},
{
  "name": "new_multiselectoptionsetattribute",
  "value": "[1,2]"
}

to

{
  "name": "new_optionsetattribute",
  "value": 1
},
{
  "name": "new_multiselectoptionsetattribute",
  "value": [1, 2]
}

2. Changing the attributes to be a dictionary rather than a list, e.g. changing from:

{
  "entity": "contact",
  "id": "<guid>",
  "attributes": [
    {
      "name": "firstname",
      "type": "String",
      "value": "Mark"
    },
    {
      "name": "lastname",
      "type": "String",
      "value": "Carrington"
    },
    {
      "name": "parentcustomerid",
      "type": "EntityReference",
      "entity": "account",
      "value": "<guid>"
    }
  ]
}

to

{
  "entity": "contact",
  "id": "<guid>",
  "attributes": {
    "firstname": "Mark",
    "lastname": "Carrington",
    "parentcustomerid": {
      "entity": "account",
      "id": "<guid>"
    }
  }
}

[mikeread2018]

Morning Both,
@rappen Let me find and obfuscate with some data.

@MarkMpn - That would be good. However, to maintain backwards compatibility I would propose adding a "format" option under options + serialise + JSON (Maintains as is now) and JSON Ext (the new format you are proposing.