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
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'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
I have a domain in which exist team members that can assign tasks to each other. I have 2 bounded context:
TeamBC: Management of the team members and their info.
TaskBC: Management of tasks and their assignaments.
TeamBC is upstream and TaskBC is downstream. The concept "member" in the TeamBC is the concept "recipient" in the TaskBC. The recipient of a task is the team member who the task is assigned to.
I use sync integration, with rest api in TeamBC and ACL in TaskBC. Recipient is a VO in TaskBC.
My question:
When integrating with rest api (not using messaging between BCs), does the downstream context have to duplicate any data from the upstream? In my case... does the TaskBC have to store any data in its database from the member entity of the TeamBC ?
It doesn't have to duplicate anything but can.
With event-only integration via messaging, BC1 has no choice but store the interesting bits of information it got from BC2 upon message reception, because it cannot re-request them whenever it wants.
With REST API integration, there's no such restriction. However, forcing yourself to only store local copies and not reach out to the other BC at will still has the advantages of relative asynchrony and/or fewer direct calls.
Actually, you probably get one of the two : asynchrony if you choose polling and fewer direct calls if you choose BC1 => BC2 notification via API.
I hava a SAP HANA XS Server with some DB Tables and an OData service. I am able to connect to the OData service and to read data. As soon as I try to Create/Update/Delete data I get the 403 - Forbidden Error.
Actually my user has the required rights to execute all of the mentioned actions (I created data using the SQL command line in HANA Studio). When I try the same with the SYSTEM user I get the same result.
If your .xsaccess file looks like this:
{
"prevent_xsrf": true,
...
}
you have to fetch an XSRF-token before you modify your entity. Reading the entity works without.
Such a token can be obtained by executing a GET to the service endpoint with following header X-CSRF-Token=Fetch. The response contains a header like this X-CSRF-Token=13DC4988AEAA95.... If you execute your e.g. POST now with the just obtained token it will work.
I am guessing that your OData service is defined to not allow modifications of the data.
From the SAP HANA Developer Guide:
By default, all entity sets and associations in an OData service are writeable, that is they can be modified with a CREATE, UPDATE, or DELETE requests. However, you can prevent the execution of a modification request by setting the appropriate keyword (create, update, or delete) with the forbidden option in the OData service definition. The following example of an OData service definition for SAP HANA XS shows how to prevent any modification to the table myTable that is exposed by the OData service. Any attempt to make a modification to the indicated table using a CREATE, UPDATE, or DELETE request results in the HTTP response status 403 FORBIDDEN.
service {
“sap.test::myTable”
create forbidden
update forbidden
delete forbidden;
}
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.