Going through the documentation for the Sharepoint API (located here: http://msdn.microsoft.com/en-us/library/office/dn605900(v=office.15).aspx) I am trying to figure out how to select chunks of documents. I was expecting $skip to work, as it is implied that most OData functionality should be present, but this doesn't work. I also can't figure out whether or not $skiptoken is a valid query param. It's listed in the documentation near the bottom (without further explanation), but I can't coax the proper result out of it so far.
If somebody knows about $skip or $skiptoken or another method available for getting chunked responses back, help with this problem would be great!
EDIT: to clarify, things like API_URL/files?$orderby=url&$top=5 work, but things like API_URL/files?$orderby=url&$skip=50 do not. However, I have just found a 'next' URL in the response which appears to provide server-side paging support. I'll try to figure out the use of $skiptoken from here.
The OData V4 protocol has specified (referencing 11.2.5.7 Server-Driven Paging) that:
OData services may use the reserved system query option $skiptoken when building next links. Its content is opaque, service-specific, and must only follow the rules for URL query parts.
OData clients MUST NOT use the system query option $skiptoken when constructing requests.
Thus, the implementation of the O365 SharePoint API that it publishes $skiptoken as a query option that the client should use for excluding first few items in the queried collection is a violation of the protocol. The client should use $skip for such scenario. But it seems from the O365 spec you attached that $skip is not implemented.
If you query a entity set of the O365 service and the response payload contains a next link (a #odata.nextLink annotation in the response JSON object), then it indicates that the service has server-side paging for the entity set. Typically the next link would be a URL containing the $skiptoken query option such as http://host/service/entityset?$skiptoken=n that the client can use for getting the next page.
Related
I have Elevated access to the Twitter API V2, and I am working with the API in Postman to search for recent Tweets containing a keyword. Iād like to be able to add a further query parameter to only return Tweets that have a geolocation associated with them. To do this, I am adding the has:geo parameter, as shown in the below URL call:
https://api.twitter.com/2/tweets/search/recent?query=dogs lang:en -is:retweet has:geo
However, this is returning with the following error:
There were errors processing your request: Reference to invalid operator 'has:geo'. Operator is not available in current product or product packaging. Please refer to complete available operator list at https://developer.twitter.com/en/docs/twitter-api/enterprise/rules-and-filtering/operators-by-product.
From my understanding, of this page in the documentation, the has:geo search operator is only available to accounts with Elevated Access to the V2 API (which I have).
If anyone has any suggestions of how I can get around this issue, that would be much appreciated please.
If you check the detail on that page, it further explains:
Twitter API v2
- **Essential**: Available when using any Project
- **Elevated**: Available when using a Project with *Academic Research access*
I agree that it is not sufficiently clear on that page, unless you re-read it (because "Elevated" and "Academic Research" are technically different access levels for your account).
The answer is that in order to use that search operator, you would need to have Academic Research access, not just Elevated access.
In the release notes of OpenUI5 it says that since 1.72 server side pagination is supported.
https://openui5.hana.ondemand.com/1.72.1/#/topic/25e532617b7f4b9bad842757324151ed.html
But I can't see any reference to it, how it is used, how it is activated.
My questions are in particular:
Must the $metadata contain anything special to enable that?
How to force UI5 to send a $skiptoken URL parameter
Thanks in advance
I am replicating the Successfactors Employee Central Data (including FO, MDF, BG elements and etc.) via OData API to local database for third party integration.
It is able to trace changed records by filtering last modify date. However, the deleted record is not able to capture from OData API. Hence I cannot delete the record in my local database when corresponding EC record is deleted.
Is there any way I can get the deleted records from the API or other sources? Thanks.
OData API is not able to handle this task.
Extract from SF OData API doc:
Don't use our OData APIs when:
ā Your system cannot consume either OData APIs or SOAP for an initial data load. In this case, you would go
for Import/Export with a CSV. Automation via FTP would also be a possibility.
ā You need employee replication field level delta, snapshot, or read modified employees only, then SOAP Compound Employee API is your tool of choice. You can find more information in the guide Implementing the Employee Central Compound Employee API.
ā You only need to read data, then the SOAP Compound Employee API would also be your tool of choice.
However with SFAPI (SuccessFactors CompoundEmployee API) it's easy. SFAPI has a special parameter changedSegmentsOnly that does exactly just what you want, the API returns only changed segments with an action code not equal to NO_CHANGE in delta transmission.
You make a query, for example, for changed employee data:
<urn:query>
<urn:queryString>select person,
personal_information,
address_information,
email_information,
phone_information,
employment_information,
job_information,
compensation_information,
paycompensation_recurring,
paycompensation_non_recurring,
direct_deposit,
national_id_card,
payment_information
from CompoundEmployee
where person_id_external = 'cgrant'
</urn:queryString>
<urn:param>
<urn:name>resultOptions</urn:name>
<urn:value>changedSegmentsOnly</urn:value>
</urn:param>
<urn:param>
<urn:name>maxRows</urn:name>
<urn:value>50</urn:value>
</urn:param>
</urn:query>
This API query will return you all the employees that were changed or deleted.
After that you can filter your response by that field.
ADDENDUM: any change to MDF entity, both standard and custom, can be tracked via OData Audit logs. How to enable them:
Go to this setting in API center
Enable this switch. It can be enabled for SFAPI as well
This way all API calls payloads will be saved and you will be able to see what entity was changed with each call
Prerequisite: the object must be visible by API and MDF version history must be enabled
More about API types for SuccessFactors:
SAP Note 2613670
OData API reference Guide
SFAPI reference Guide
I am trying to use filter and orderby query parameters to sort or filter the results. But the API is ignoring the query parameters and returning entire results.
https://graph.microsoft.com/v1.0/sites/{site_id}/drives?orderBy=name%20desc
I'm not sure why this isn't documented in the Microsoft Graph documentation (it should be), but from the OneDrive API documentation itself:
Note that in OneDrive for Business and SharePoint Server 2016, the orderby query string only works with name and url.
I've added an issue to the documentation's repository so this issue can hopefully get resolved in the future.
Although the original OneDrive API docs/Graph Drive API docs state they support orderby, but the actual OneDrive Graph API should be have not support filtering or ordering results. So although we pass the orderby parameter, when Microsoft Graph sees a query parameter it doesn't expect, it simply ignoring the unknown filter/orderby parameter and returning us an unfiltered/default-sorted result.
My test string:
https://graph.microsoft.com/v1.0/sites/my-site-id/drives?$select=id, name,webUrl&$orderby=name%20desc
So the only suggestion for you is to vote up the existing feature request in User Voice or submit a new one.
I've been trying to return the employeeId of a user through the Microsoft Graph API but so far haven't had much luck.
I'm assuming this is probably because it doesn't exist in the metadata for the user in the Graph API so makes sense.
However, the property is populated in Azure AD. If I use the AZ command prompt to query the user I can see the property. Likewise, if I query the old Active Directory Graph API endpoint I can even see it there.
For example, querying
https://graph.windows.net/{tennant}/users/{upn}?api-version=1.6 directly I receive the employeeId as part of the response (using the ActiveDirectoryClient however seems to ignore this property and doesn't store it anywhere).
Is there any reason for this? Wouldn't it make sense to have it returned as an additional property? I've also looked into extensions, but as it's not an extension isn't returned there.
Any help would be appreciated. I can get the information I need by querying the old endpoint directly, but this seems like a complete backwards step and involves multiple queries to get the information I need - including having to use multiple end points (one of which I assume will be deprecated and removed soon).
EmployeeId is currently a beta feature and is only available in the beta endpoint of the Graph API.
So if you want to access the beta endpoint you just have to change the version to beta in your url. For example:
https://graph.microsoft.com/beta/me/
https://graph.microsoft.com/beta/users/{id|upn}/
https://graph.windows.net/{tennant}/users/{id|upn}?api-version=beta
For more information about the user-object in the beta endpoint see: https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/resources/user