Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi There,
I'm running Qliksense 3.02. When I execute the below code in the engine explorer, I'm expecting to see a new "measure" master item created on the frontend of the application, however, on the frontend a blank measure is created as shown in the attached screenshot (above the "GetMeasure" measure).
Am I misunderstanding how the CreateMeasure method works? Looking at the documentation, it seems as though it's just a matter of entering the parameters and executing? Any help would be greatly appreciated.
{
"handle": 1,
"method": "CreateMeasure",
"params": {
"qProp": {
"qInfo": {
"qId": "Measure01",
"qType": "measure"
},
"qMeasure": {
"qLabel": "Label",
"qDef": "Whatever",
"qGrouping": 0,
"qExpressions": [
""
],
"qActiveExpression": 0
},
"qMetaDef": {}
}
}
}
Ah, set a tags property on the qMetaDef such as
qMetaDef: {
tags: []
}
It's important to understand that the Engine API is not coupled to the self-service client, the Engine is designed to be client agnostic so the self-service client has some properties that are specific to the client hence you won't find them in the Engine API documentation.
That is correct, however the Client also sets some client-specific properties that aren't part of the Engine API.
You can see a working example here, different library but you can take the definition out of this example and use it in engine explorer qsocks/measure.js at master · mindspank/qsocks · GitHub
Hi Alex,
I now have a measure with a description created using the below request. Something I've noticed though is that the created measure doesn't have the context menu that measures created in the app have. Do you perhaps know if this is a limitation of the API, or if there is some other config option for the request that needs to be added? I've attached images of what I'm referring to.
{
"handle": 1,
"method": "CreateMeasure",
"params": {
"qProp": {
"qInfo": {
"qId": "",
"qType": "measure"
},
"qMeasure": {
"qLabel": "This is a measure created with the Engine API",
"qDef": "Sum(Expression)"
},
"qMetaDef": {
"title": "This is a measure created with the Engine API",
"description": "A Description"
}
}
}
}
Ah, set a tags property on the qMetaDef such as
qMetaDef: {
tags: []
}
It's important to understand that the Engine API is not coupled to the self-service client, the Engine is designed to be client agnostic so the self-service client has some properties that are specific to the client hence you won't find them in the Engine API documentation.
It works! Hooray! Thanks so much. This is gonna save me a ton of time
Awesome! Since we don't document (yet) client properties a good way is to inspect the traffic to see exactly what kinda of messages we send from the client. If you run the self-service client in Chrome you can pop open the developer tools, go to network and find the websocket connection. From there you can access what they call Frames which is the clear text traffic of what is sent over the socket between client and server, then you can easily create a measure in the client and see exactly what is sent to the server to replicate it.
If you want to move stuff over to code eventually Qlik ships a SDK for .NET but there are also Engine API implementations for Go (https://github.com/mattbaird/glik), JavaScript (https://github.com/mindspank/qsocks) and soon also a Observable implementation in JS once skokenes gets his act together and open sources it
Thanks a lot for the extra info. I've managed to figure out now how to add the measure using the .NET SDK, which is working really well.
My original plan was to use the SenseMeasuresImporter in Qlik Branch, but the source code doesn't compile on the latest versions of the SDK. It will be really great once the documentation can catch up to the pace of the development happening right now in Sense, and there's still quite a bit of guess-work in terms of what the engine actually wants.
It's actually what the Client wants, the Engine don't really understand what "tags" are but persists them anyway.
Yeah, right now we have good documentation around the Engine itself but what we are hoping for is to be able to gather up how the Client is implemented and be able to document that sometime in the future.
The .NET SDK is trying to keep up in general but since we currently do not have a centralized entity schema for the Client sometimes a property is missed there also.