Performing updates using alternate key in Dynamics 365 WebAPI - dynamics-crm

Can anyone help, as I believe someone has already faced the issue I'm having.
I have a custom entity (alssc_anglesector) with an alternate key (alssc_name)
“alssc_ANGLESector#odata.bind”: “/alssc_anglesectors(alssc_name=’Air’)”,
“alssc_ANGLESector#odata.bind”: “/alssc_anglesectors(alssc_name=’Water Auth/Company’)”,
when I create an account and use the first bind with “Air” it works fine, while when using the second “Auth/Company” I got the response
“message”: “Bad Request – Error in query syntax.”,
“type”: “Microsoft.OData.ODataException”,
“stacktrace”: ” at
Microsoft.OData.UriParser.ODataPathParser.ExtractSegmentIdentifierAndParenthesisExpression(String
segmentText, String& identifier, String& parenthesisExpression)
I have also tried to encode it
"alssc_ANGLESector#odata.bind": "/alssc_anglesectors(alssc_name=\u0027Water Auth\u002FCompany\u0027)",
but the end result was the same.
I’m not being able to overcome this, Any ideas / suggestions ?
could it be a Bug in D365 API WebApi ?

As per the answer in the comment thread: This request is unsupported because it contains Unicode characters
Unicode characters in key value
If the data within a field that is
used in an alternate key will contain one of the following characters
<,>,*,%,&,:,/,\ then update or upsert (PATCH) actions will not work.
The suggestion from the Microsoft Docs is to create another field (such as a code, or a simplified name) that does not contain these characters
https://learn.microsoft.com/en-us/powerapps/maker/common-data-service/define-alternate-keys-reference-records#unicode-characters-in-key-value

In this case you have to change ’Water Auth/Company’ with ’Water Auth%2FCompany’ because of '/' special character.
I hope it works.
Ugur

Related

How to use Power Automate "uriQuery()" function on an url that contains special characters

Due to some odd circumstances I have the necessity to use uriQuery() in a Power Automate flow in order to extract the query string from an url.
This works as expected in most circumstances, except when the url contains special characters like accented letters, for example
http://www.example.com/peppers/Jalapeño/recipe #1.docx
In such cases the call triggers an error and the exception message shows a (partially) encoded version of my url (why?).
The template language function 'uriQuery' expects its parameter to be a well-formed absolute URI. The provided value was '......'
Obviously the url was indeed a well-formed, absolute URI.
Since the error only triggers when the url contains special characters I assumed that I had to encode the value before calling uriQuery(), yet nothing I tried seems to work (for example encodeUriComponent() ). And as expected nothing I could find on the web mentioned a similar issue.
As a last attempt I am asking here - does uriQuery() support this use-case? And if it does... how?

LUIS issues with special characters

(TEXT) is converted to ( TEXT ) in LUIS when we identify an entity name.
Issues with special characters.
Refer the image in below:
Here monthly iq dashboard hospitalists is converted to reportname --> "monthly iq dashboard ( hospitalists )" in Entities. So when we use this entity in bot framework we are facing issues while comparing to actual report name stored in Metadata (database).
(TEXT) is converted to ( TEXT ) in LUIS when we identify an entity name. Issues with special characters.
The issue you reported seems be that whitespace is added when some special characters are using, I reproduced the issue on my side, and I find similar issues are reported by others:
LUIS inserts whitespace in utterances when punctuation present causing entity getting incorrectly parsed
LUIS cannot take care of special characters
when we use this entity in bot framework we are facing issues while comparing to actual report name stored in Metadata (database)
To solve it, as Nicolas R and NiteLordz mentioned in comments, you can try to handle that in your code. And to remove whitespace from ( hospitalists ), the following regex would be helpful.
Regex regex = new Regex(#"\(\s\w*\s\)");
input = Regex.Replace(input, regex.ToString(), c => c.Value.Replace(" ", ""));
Note: can reproduce the issue, and same issue will appear when we process something like URL that contains / and . etc

"=?utf-8?Q??=" in To: field with Outlook and MailChimp

I can't find much information on this problem aside from issues with Code Igniter and long subjects (my subject is < 20 chars). I sent a campaign with MailChimp, and found that when using Outlook (Gmail web is fine), the To: field says "=?utf-8?Q??=" instead of the recipient name.
What could cause this?
The To header below encodes an empty string (nothing between two ?'s in =?utf-8?Q??=:
To: =?utf-8?Q??= <MyName#MyCompanyName.com>
Either get rid of the utf-8 encoding or actually provide a display name
To: =?utf-8?Q?Some Name?= <MyName#MyCompanyName.com>

What constitutes a valid URI query parameter key?

I'm looking over Section 3.4 of RFC 3986 trying to understand what constitutes a valid URI query parameter key, but I'm not seeing a clear answer.
The reason I'm asking is because I'm writing a Ruby class that composes a URI with query parameters. When a new parameter is added I want to validate the key. Based on experience, it seems like the key will be invalid if it requires any escaping.
I should also say that I plan to validate the key. I'm not sure how to go about validating this data either, but I do know that in all cases I should escape this value.
Advice is appreciated. Advice in the context of how validation might already be possible through say a Ruby Gem would also be a plus.
I could well be wrong, but that spec seems to say that anything following '?' or '#' is valid as long. I wonder if you should be looking more at the spec for 'application/x-www-form-urlencoded' (ie. the key/value pairs we're all used to)?
http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1
This is the default content type. Forms submitted with this content
type must be encoded as follows:
Control names and values are escaped. Space characters are replaced by +', and then reserved characters are escaped as described in [RFC1738], section 2.2: Non-alphanumeric characters are replaced by %HH', a percent sign and two hexadecimal digits representing the ASCII code of the character. Line breaks are represented as "CR LF" pairs (i.e., `%0D%0A').
The control names/values are listed in the order they appear in the document. The name is separated from the value by =' and name/value pairs are separated from each other by &'.
I don't believe key=value is part of the RFC, it's a convention that has emerged. Wikipedia suggests this is an 'W3C recommendation'.
Seems like some good stuff to be found searching on the application/x-www-form-urlencoded content type.
http://www.w3.org/TR/REC-html40/interact/forms.html#form-data-set

Disabling visually ambiguous characters in Google URL-shortener output

Is there a way to say (programmatically, I mean their API) the Google URL shortener not to produce short URL with characters like:
0 O
1 l
Because people often make mistake when reading those characters from displays and typing them elsewhere.
You cannot request the API to use a custom charset, so no.
Not a proper solution, but you could check the url for unwanted characters and request another short URL for the same long URL until you get one you like. Google URL shortner issues a unique short URL for an already shortned URL if you provide an OAuth token with the request. However I am not sure if a user is limited to one unique short URL per a specific long URL in which case this won't work either.
Since you're doing it programmatically, you could swap out those chars for their ascii value, '%6F' for the letter o, for instance. In this case, just warn the users that in doubt, it's a numeral.
Alternatively, use a font that distinguishes ambiguous chars, or better yet, color-code them (or underline numerals, or whatever visual mark)

Resources