In the documentation here, Bloomberg does not make a distinction in the request. The requests can only have 3 things:securities, fields and overrides.
So what are options? How do they get used? Is this a distinction imposed by Rblpapi? Can someone explain the distinction?
Please let me know if I am incorrectly understanding something.
Options are parameters that change how a Request or Subscription should behave. For example, a ref data request with returnEID=true will return the EID(s) of each security in response messages. A Subscription with interval=5.0 will make it an Intervalized Subscription.
Overrides, on the other hand, are field/value pairs that you specify in Requests to alter the form or content of the returned fields, for example, GICS_SECTOR_NAME will normally return sector name in English (or precisely the default terminal language), you can specify SECURITY_NAME_LANG=9 override to get the name in Korean. You can also "request" SECURITY_NAME_LANG field to know the language used in GICS_SECTOR_NAME field. Overrides can be used in Request/Response only (not subscriptions), and are applied to the entire request, on all fields that react to that override.
option.names = "optName", option.values = "optVal"
in R, maps to:
request.set("optName", optVal);
in Java. E.g:
option.names="periodicitySelection", option.values="MONTHLY")
request.set("periodicitySelection", "MONTHLY");
Related
Google deprecated the old GMB API v4.9 account.locations.get endpoint, and replaced it with Business Information API v1 locations.get.
Code change that affects me is:
Removal of LocationState object. The existing fields have been moved into Metadata.
The new Metadata object does not return the attributes LocationState object contained before. The ones I'm interested in are:
isVerified
isPublished
isSuspended
isDisabled
isDisconnected
etc...
My question is:
How could I get this data without using deprecated endpoints?
Try Verification API getVoiceOfMerchantState
isVerified (verify),
isPublished (hasVoiceOfMerchant=true AND hasBusinessAuthority=true),
isSuspended (complyWithGuidelines),
isDuplicate (resolveOwnershipConflict).
isDisabled & isDisconnected have no equivalent in new API
As far as I can see, based on the link you have sent it is written:
Endpoint URL:
Endpoints for all business information, attributes, categories, chains and locations search are accessible at https://mybusinessbusinessinformation.googleapis.com/v1/ instead of https://mybusiness.googleapis.com/v4/
The path name for locations endpoints has changed from
accounts/accountId/locations/locationId to locations/locationId
Maybe it was better if you could provide the request uri in the previous version so we could help you more precisely. Anyhow, what I tested in the google playground is as follows:
open [https://developers.google.com/oauthplayground]
after setting your clientId and Authorisation stuff, in the Request URI write
https://mybusinessbusinessinformation.googleapis.com/v1/locations/XXXXX?readMask=storeCode,metadata,profile,serviceArea,labels,adWordsLocationExtensions
instead of XXXXX, write your locationId
you can write different readMask fields, The possible fields for readMask are:
play with different fields to check if you have your desired one or not readMask="storeCode,regularHours,name,languageCode,title,phoneNumbers,categories,storefrontAddress,websiteUri,regularHours,specialHours,serviceArea,labels,adWordsLocationExtensions,latlng,openInfo,metadata,profile,relationshipData,moreHours";
If above does not help you, in the link below I see that all metadata attribute of a location might be:
Click [here] (https://developers.google.com/my-business/reference/businessinformation/rest/v1/accounts.locations#Location.Metadata)
I want to customize the standard drill-down functionality and add a text parameter to the drill-down URL. I will then parse and use the parameter in the SysStartUpCmdDrillDown or EventDrillDownPoller class like the solution provided by Jan B. Kjeldsen in this question.
The standard drill-down link is dynamics://Target/?DrillDown_RecID/ :
dynamics://0/?DrillDown_5637230378/
In previous versions of AX it was possible to modify the RecId to custom text and parse the text once the client is started:
dynamics://0/?DrillDown_0MenuItemName=PurchTable&FieldName=PurchId&FieldValue=P000044
Unfortunately, in AX 2012 the RecId is checked before the client is started and if it is not a valid int64, the drill-down event is not sent to the client. Since it is not possible to change the RecId to anything other than an integer, #Alex Kwitny suggested in the comments at that same question that you can add the custom text to the drill-down target like this:
dynamics://0MenuItemName=PurchTable/?DrillDown_5637230378/
The problem I experience with this is that the link now gets confused about which instance to start.
If the target is equal to the value in the System Admin -> system parameters -> Alerts ->Drill-down target, a client with the correct server instance is started. When I append the text with my custom text, it always starts the default instance(Which could be different from the instance I intended to start). While this is not ideal, I could work around this issue.
The bigger problem is that it now always starts a new session of the default instance, even if a client session is already started. As far as I can see I cannot write X++ code to solve this issue since the server instance is determined before any code in the client is executed.
My question is this - How can I add custom text to the drill-down link while preserving the way the client instance is started: If a client for the instance is already open, it should process the link in the open client, and not start up a new client of the default instance.
You should probably come up with another solution as mentioned in this post, but there could still be a way.
The URL has two objects that can be modified:
dynamics://[Drill-down target(str)]/?Drilldown_[Int64]
According to you, if you modify the [Drill-down target], then it launches AX using the default client config, and that is behavior that you don't want. If you have a matching [Drill-down target], it'll launch in the open client window, which is behavior I can't confirm, but I'll take it at face value and assume you're correct.
So that means the only thing you can modify in the URL is [int64]. This is actually a string that is converted to an int64 via str2int64(...), which in turn corresponds to a RecId. This is where it gets interesting.
This work all happens in \Classes\SysStartUpCmdDrillDown\infoRun.
Well, lucky for you the ranges for the objects are:
RecId - 0 to 9223372036854775807
Int64 - -9223372036854775808 to 9223372036854775807
You can call minRecId() and maxRecId() to confirm this.
So this means you have -9223372036854775808 to -1 numbers to work with by calling URLs in this range:
dynamics://0/?DrillDown_-1
to
dynamics://0/?DrillDown_-9223372036854775808
Then you would modify \Classes\SysStartUpCmdDrillDown\infoRun to look for negative numbers, and fork to your custom code.
HOW you decide to user these negative #'s is up to you. You can have the first n-digits be a table id or a look-up value for a custom table. You can't technically use a RecId as part of that negative number because in theory the RecId could get up that high (minus 1).
I have the following rest structure for 'keyboard' objects:
GET /keyboards/ -> Lists user keyboards
POST /keyboards/ -> Creates new keyboard
GET /keyboards/{id} -> Get specific keyboard by id
PUT /keyboards/{id} -> Update specific keyboard by id
DELETE /keyboards/{id} -> Delete specific keyboard by id
The front end uses whatever keyboard is set to the users default keyboard, or, if the user has no custom keyboard set, simply returns a generic default.
At present, that is done by requesting another URL:
GET /keyboards/default
However, this appears a little misleading to me, as the resource 'default' could change whenever the user changes their default, and actually is a pointer to a different specific resource.
I'm not sure of a more elegant solution to this, as the front-end would appear to need to make two requests otherwise:
GET /keyboards/ -> Revealing the default
GET /keyboards/{id} -> To get the mappings associated with the keyboard
Which seems a more laborious, two step process. Is the first option a reasonable one, or am I missing a more elegant implementation?
It's OK to have convenience identifiers like 'default', 'latest' etc...
GET /keyboards/default
-> {
id: 3,
Another option is to hang the default keyboard off of a containing/referencing resource if there is one. For example
GET /computer
-> {
name: foo,
defaultKeyboard: 3,
...
If you want to avoid two requests you could have isDefault on the keyboard object.
GET /keyboards
[
{ id: 1, isDefault: false, ... }
{ id: 3, isDefault: true, ... }
That allows you to filter via querystring params.
Finally, this doesn't have to be an OR - you can have all of these for a convenient API for different access patterns.
Having to do a higher number of requests than with other architecture styles is a well-known and assumed drawback of RESTful APIs.
It is counterbalanced by the fact responses may be cached more easily as each resource has a unique URL.
Does you keyboard resource expose an "IsDefault" property? It should. And so:
GET /keyboards/
Would return a list of keyboards. You could examine the keyboard resources in the list and choose the one that is the default.
And you could also solve this by making this a query parameter:
GET /keyboards?IsDefault=true
There's nothing wrong with having a convenience /keyboards/default identifier, as long as its cacheability is being defined correctly, which in this case would probably be to tell clients to not cache it at all.
How do you set the limit on the length of a POST request in twisted? I've looked around in the docs and can't find anything. It would even help if I knew the default limit.
I don't believe there is a default limit on the size of incoming POST data, but you could pretty easily impose one by overriding the Request.handleContentChunk() method, with something like:
from twisted.web import server
class SizeLimitingRequest(server.Request):
def handleContentChunk(self, data):
if self.content.tell() + len(data) > self.size_limit_on_post_data:
raise SomeKindOfError("too much data nooooooo")
return server.Request.handleContentChunk(self, data)
the actual method you'd be overriding is in twisted.web.http.Request, which is a superclass of server.Request. To make use of your shiny new class, just set your Site instance's requestFactory attribute:
mysite.requestFactory = SizeLimitingRequest
The situation
I'd like to use GA to track some serverside operations. That's why I cant make use of the GA JavaScript functions. But, as you might know, you can request the utm.gif right from your server. This already works fine.
The Problem
I'd like to trackt custom parameters. But I have no idea how to add them in the right format to the url-request
This one should do the custom parms. But I didn't get any results in GA.
utme=5(Init*load_success*http://www.mydomain.de)8(userstatus)9(fan)11(2)
Full list of params:
ref ts
utmac UA-XXXXXX-5
utmcc __utma=186215409.1789216404.1265552708.1280074861.1280493144.21;+__utmz=;
utmcs ISO-8859-1
utmdt Button
utme 5(Init*load_success*http://www.mydomain.de)8(mycustomvar)9(mycustomvalue)11(2)
utmfl -
utmhn mydomain.de
utmje -
utmn 1114675642
utmp button
utmr http://www.mydomain.de
utmsc -
utmsr -
utmul de-de
utmwv 4.5.7
not sure what's going wrong, given what you posted, but how about you write out what you want to send the traditional way (with javascript) and put it on a test page. Use firebug or whatever to grab the requested url that's built and compare it to what you have now.
The value of the utme gif Request parameter is encoded by ga.js--it's the only one that is, as far as i know.
Calling __trackEvent is the usual way to set the value of utme. These are client-side events though, which is no doubt why you are trying to set utme directly.
So if you just want to bind 5(Initload_successhttp://www.mydomain.de)8(userstatus)9(fan)11(2) to the variable utme, and you can't rely on user-behavior to trigger that binding, then here's what i suggest:
Pack your data into a 'custom variable' scoped to the page--this way, when the __trackPageview() is called, the value will be set.
Here's the analytics code required in your HTML to implement that:
The method signature for a custom variable:
pageTracker._setCustomVar(slot, // integer between 1 and 5, inclusive (just use '1')
name, // user-defined name for the custom variable
value, // string representing the value for the custom variable
scope, // you want '3' for page-level (an int, not a string though)
);
Within the HTML (order matter, of course):
pageTracker.__setCustomvar(1, "A Name", "A Value", 3);
pageTracker.__trackPageview();
A key point here is that the parameter 'value' can be set dynamically, so for the 'value' parameter, i guess you want to pass in 5(Initload_successhttp://www.mydomain.de)8(userstatus)9(fan)11(2)
Finally, here are the two key sources (Implementation Guide, Usage Guide) on Custom Variables from the GA Team