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
Related
I have a task toget some data from an external supplier.
They have a Rest OData API. I have to connect using a subscription-key(APIKey).
When creating the OData LService, I add an Auth Header: "subscription-key" and in the Value field, I enter my key. After saving, I create a new dataset, and the OData LinkedService, provides me with the remote tables. I can choose the table I want and after that I create a pipeline to copy data from that table to my Azure SQL server.
This works fantastic :-)
However, after closing my browser and re-open it, the subscription key that I have entered earlier on the linked service, is now replaced with stars as it is a securestring. When I now run my pipeline, it will think that my key is the ten stars that have replaced my real key.
What am I doing wrong here ?
Also I would prefer to get my value from the KeyVault, but it seems that this is not possible on ODat connections....
Hope someone is able to provide some insight here :-)
BR Tom
From my testing I did not get any error on re-running. However coming to dynamic keys - I was not able to achieve it using the ODATA linked service.
Alternatively, if you can hit the ODATA endpoint with REST / HTTP Connector
You could - have a Web Activity to get the keys from the Key Vault and Set in the Variable.
WEB Activity URL : https://<your-keyvalut-name>.vault.azure.net/secrets/<your-secret-name>;
You could access the output of the web Activity using : #activity('Web1').output.value & Store in a variable.
You can reference this variable as the SUBSCRIPTION KEY for the subsequent steps in the REST/HTTP dataset.
You could pass it along the additional headers
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
My calls to the API to get users work just fine, but the default URL does not return the home phone number, or the ip phone number.
/Users/jo.bloggs#example.com
adding parameters works for other things
/Users/jo.bloggs#example.com/?$select=id,displayName,mail,postalCode,businessPhones
works too, I have tried homephone, homephones, homePhone, homePhones and ipphone, ipphones, ipPhone, ipPhones but do not get those properties returned. We can see the properties filled in on our local Active Directory, so they are in there.
Looking at the docs I don't see mention of home or ip phones https://learn.microsoft.com/en-us/graph/api/resources/user?view=graph-rest-1.0 but I am hoping I am missing something.
To extend on my comment
For some reason the fieldname ipPhone does not work, only a prefixed
version with a 33 character hash in it extension_<33chars>_ipPhone. I
don't have direct access to the system, but have been told its been
done correctly, so it works enough for us
The URL path we have is now:
/Users/user.name#example.com/?$select=id,displayName,mail,homePhone,mobilePhone,businessPhones,ipPhone,profile,streetAddress,postalCode,extension_e48de7ec5b11c947e3006271ff83029_ipPhone,extension_e48de7ec5b11c947e3006271ff83029_homePhone
The codes for both of our fields fields are the same.
I presume the codes for other orgs will be different, but just in case I have not used our actual ones here.
Some attributes (such as ipPhone) that are synchronized by default might not be exposed using the Microsoft Graph API. In these cases, you can use the Azure AD Connect directory extension feature to synchronize the attribute to Azure AD.
I am currently working on a solution that is accessing OneDrive in Office 365 using Microsoft Graph. I am using the adal4j library to handle authentication and have configured the app in portal.azure.com.
My question relates the call to get the children for a specified drive. I am using a query similar to the one shown below, as I want to get folders and files at the root level of a specified users drive:
https://graph.microsoft.com/v1.0/users/*user id*/drives/*drive id*/root/children
When I login to the Graph Explorer and execute the query, I get a json result showing the root folder contents for the drive and user specified. All works as expected.
When I call it from my java application, the JSON node value is empty ([]).
Initially my thought was, because the Graph Explorer uses a different app id in the portal it was possibly something to do with access rights. However, I successfully read user profiles in our O365 tenant, the drive id's for each user, and if I execute the following:
https://graph.microsoft.com/v1.0/users/*user id*/drives/*drive id*/root/search(q='')
It provides me a complete list of all of the folders, sub folders etc within the appropriate user's drive.
Therefore, making me think this is a bug with the Graph query I am attempting to use rather than an authorization issue, but, that wouldn't explain why it works in the Graph Explorer.
The same java method is used for all calls, and the url is passed in as a parameter.
Just to follow up, the azure portal app permissions has the capability of adding permissions for the graph api. This was, indeed the problem. It would appear that the search was ignoring the permission and successfully reading the data whereas the /children call was honouring the security model. This caused a lot of confusion, but is now resolved.
Thanks Marc for your help.
I am planning to make a browser extension which uses Youtube data API v3. Since the code is public to the user, I am unable to use my API-key in the code. What is the correct way to use API in such a scenario? Also, since the API call will be made from user's browser, is there any other way to fetch data without using API-key at all?
TL;DR
On the API screen of Google Cloud Console, create a new key or edit an existing one to have no restriction. This will enable anyone to use this key to make requests the moment you publish it. There is no way to use the YouTube API without a key (or token respectively, when using OAuth). Your clients are allowed to consume up to 50.000.000 quota units per day, after which your app will essentially break for the rest of the day unless you buy more quota.
However, I have to disagree with the statement that you cannot (or "shouldn't") publish your API key; in certain scenarios, this may very well be desired.
Detailed Explanation
Web application keys used to be organized in two groups: Server keys and browser keys, the former of which where to be kept secret on the server of the web application, while the latter was sent to the client for use in JavaScript. Server keys could be configured to only be accepted from certain IP addresses. That way, even if someone got hold of your key, they wouldn't be able to use it. Browser keys could be restricted to a specified referrer, i.e. the domain (as in DNS) of your web application, so it wouldn't work on other sites beside your own either.
Nowadays, there is no distinction between server and browser keys anymore, they are simply called "API keys". This union makes perfect sense to me, since the only difference between the two types was how they were restricted. With the new API keys, one can still choose how to restrict its usage - or choose to not restrict the key at all.
This is where we get back to your case: It is, of course, possible to publish a key and at the same time not restrict it. Depending on how many users are using your app (and will be using it in the future) and how many are using your key for their own app (which you have no control over), the 50 million quota limit will work out for you or it will not.
An then there's responsibility as well. You are responsible for the queries that are made with your API key. This is probably one of the reasons why YouTube doesn't allow for requests without a valid key: They need to stay in control of their service and, naturally, want to protect it from DOS attacks. If someone does mischief with your key, you are the one who gets punished for it, usually by deactivation of the key.