Escaping } in REST API query

[dan.kelleher]

Hi All,

I'm having an issue with a query to get a user's default display alias:

} escaping to %7D

Code: Select all

api/v1/Dimensions('}Clients')/Hierarchies('}Clients')/Elements?$select=Attributes/%7DTM1_DefaultDisplayValue

Code: Select all

{
    "error": {
        "code": "278",
        "message": "Unsupported token at: }TM1_DefaultDisplayValue"
    }
}

I have a couple of workarounds - rule-derived alternative attribute not containing }, or

Code: Select all

api/v1/Dimensions('}Clients')/Hierarchies('}Clients')/Elements?$select=Attributes

and filter on the client side, but was wondering if anyone had a solution?

n.b.

Code: Select all

api/v1/Dimensions('}Clients')/Hierarchies('}Clients')/Elements?$select=Attributes/}TM1_DefaultDisplayValue

gives the same error.

[Mike Cowie]

Hi Dan,

You are not missing anything if you're talking about accessing element attribute values in general. However, if all you're hoping to do is to get the display name of the user there is a FriendlyName property of a User that takes care of retrieving this value for you.

As for why you can't address element attributes using the $select=Attributes/<AttributeName> option when there's a leading "}"...

OData entity identifier naming rules in urls are more restrictive than the allowable names you can give to TM1 objects. If you ever have trouble falling asleep have a look at the OData ABNF rules, where you'll find this definition:

Code: Select all

odataIdentifier             = identifierLeadingCharacter *127identifierCharacter
identifierLeadingCharacter  = ALPHA / "_"         ; plus Unicode characters from the categories L or Nl
identifierCharacter         = ALPHA / "_" / DIGIT ; plus Unicode characters from the categories L, Nl, Nd, Mn, Mc, Pc, or Cf

This is basically describing things in urls that are not in single quotes or part of certain components of query expressions: these identifiers must begin with an underscore or letters (incl. 2 Unicode categories) of some kind, and they can then have numbers, underscores, and letters (incl. more Unicode categories) thereafter. Identifiers are also supposed to be limited to 128 characters, but I haven't checked that TM1 enforces that.

Your workarounds are the ways to deal with this, which I agree can be frustrating especially if it's an attribute name you can't control. For the attribute names you *can* control, best to stick to the naming rules above if you hope to address them efficiently in the REST API.

Hope that helps!

[lotsaram]

There's also a gotya that the OData naming conventions also prohibit using spaces in attribute names! https://cubewise.com/blog/naming-conven ... attribute/

[dan.kelleher]

Hi Michael,

Thanks very much for the detailed explanation, and the FriendlyName suggestion which is a better solution that I had:

Code: Select all

/api/v1/Users('userid')?$select=FriendlyName

Thanks,

Dan