SAP Successfactors Odata and SFAPI API-How to work with them

The foremost question that comes to the mind is what endpoint should we make connection to , in order to execute the APIs for the Successfactors Instance URL that we are having access to / or the one that needs to be integrated.

And this has been a mystery for almost everybody who wants to enable integration with Successfactors application.

Here, in this lecture and a couple of lectures accompanying henceforth , the attempt has been laid to demystify the endpoint URL to connect to , when only the Successfactors Application URL is known to us.

Wishing you Happy Learning!

Here , we will see in order to execute the SFAPI calls ,the call can be made to a derivative URL of the Successfactors Application URL ; we will see here why that it is not a recommended way; and the calls need to be made to the DC (Data Center) URL.

Here, we are continuing on our journey to gather the Data Center URL for the Successfactors Application URL; the end goal being the SFAPI/OData URL.

In this lecture , we are covering the step of identifying the Data Center identifier that corresponds to the Successfactors Application URL that needs to be integrated via the APIs.

This lecture covers 2 steps out of 4 , to identify the DC URL.

In this step we will work on the Step 3 out of 4 to identify the Data Center URL for the APIs to connect to.

Once this step is performed , we will be able to get the Data Center URL to which the API calls need to be submitted.

Please also follow the recently added extension to this lecture in order to gather the Data center url.

This is an extension to the previous lecture in order to get the Data center URL , this is with updated information with some of the recent application urls those have been circulating in.

Here, we will see the additional steps we need to carry out in order to reach the goal of being able to confirm the end point Data Center URL and eventually the target end point URL i.e the SFAPI URL.

We will embark on the journey on how to form the SFAPI URL , which is the end point to which the calls are made by the SFAPIs.

Here, we will gather the information on how to form the SFAPI endpoint URL towards which the various methods and functions from SFAPI are exposed.

Here in we will have a look at the wsdl and more primarily we will seek out what all operations can be made via the SFAPI wsdl.

There is also an alternate to check over the available operations from the SFAPI , which we will be looking at in the subsequent discussions.

Herein , we will discuss over what is OData URI; we will also understand what is the difference between application url (aka company url), Data Center url and OData URI.

We will also see as to how just knowing the application url, the Data Center and OData URI information could be gathered.

This is an extension to the previous lecture in order to get the Data center URL , this is with updated information with some of the recent application urls those have been circulating in.

Here, we will understand how to download and install the SOAP UI tool, which will be used to execute various web service calls to SAP Successfactors.

Here in we will see how to enable the calling from SOAP UI to Successfactors in view of the disablement of the TLS (Transport Layer Security) v1.0; else you might experience SSL handshake exception when communicating with Successfactors from SOAP UI.

Also please note if the link as provided as resource to this lecture is not getting open by clicking here; please search for note 2461964 over the net , it would be available there as it is a public SAP note so is available free to be accessed.

This is the most prominent tool to make the REST calls and that includes OData calls. We will see as to how to set up the tool in order to execute the OData calls been discussed in the upcoming sections.

Herein , we have already installed and discussed at length as to how to set up the SOAP UI for the SFAPI calls in the earlier sessions , in this session we will see as to how we can make the OData calls from the SOAP UI.

Herein, we will see as to how the OData call can be made from the Advanced Rest Client (ARC) which is available as Chrome App.

Herein , we will see as to how the OData calls can be made from the Chrome/Firefox browser. And how we can gather the response both in JSON and Atom format when the call is executed from these browsers.

Here we will have an introduction of OData and understand the various components ,their significance in making up an Odata service.

Here, we will understand what a Service Document and Service MetaData Document is, and not only that we will also see what differences exist between the information conveyed by these documents.

We will also execute different possible OData URIs to gather these documents and also the finer points in the information displayed via these different URIs.

Here, we will discuss over the Entity Metadata document and the information it contains , also we will have a comparison study between the 3 documents (Service Document , Service Metadata Document, Entity Metadata Document) over the information these docs hold.

Here, we will discuss various ways in which following documents can be gathered:

1. Service Document

2. Service Metadata Document

3. Entity Metadata Document

Different variants of the OData URIs those can be used to gather the various documents and different options available.

We will also see some nitty gritty details over the impact of gathering the Service Metadata document for the specific entities - eg impact on the Navigation properties been outputted.

Having now understood, how the different docs can be gathered , the comparative study of information stored in those; let's now have a closer look onto the Service Metadata Document. Here we will start by understanding what are EntitySets and EntityType in the document.

Here we will be looking into what are AssociationSets and Association in the Service Metadata Document.

Here we will be looking into what are the Navigation Properties in the Service Metadata Document and here we will bring up the binding factor between Association and Navigation Property; we will demystify the logic to know what object is shown up when the navigation property is expanded.

Here we will be looking into what are the Function Import in the Service Metadata Document and here we will work out with some Function Imports and also understand various nitty-gritties related to the Function imports - http method, parameters, payload, return type and how information over these function imports can be gathered.

Here, we will have a closer look at the Entity Metadata Document and will understand what all information can be inferred from the Entity Metadata document and some tips to traverse this document that would add up to the productivity.We will also see as an use case here how can we gather all the sensitive fields of an object from the Entity Metadata document with minimal efforts.

Herein, we will understand what all constitute the OData URI; this is the starting of understanding the way different uri calls are structured:

Service Root

Resource Path

Query Options

Herein, we will try to understand the most complex component of the OData URI , Resource Path; in this and couple of upcoming sessions we will try to demystify the resource path.

Also we will see the different representations of the resource path and will associate them to the odata queries , in order to understand the practical manifestation of the logic.

Herein , we will be looking into some more interesting resource path representations and one of the constraints of the Resource Path representation (where in query options could have been more friendly).

Herein, we will be looking into the third OData URI component, that is , query options.We will understand basics about the various query options that we have  in the OData; this is the beginning session for the detailed sessions to be taken up in the upcoming section over the various query options to be dealt with individually.

1. System Query options

   $orderby

   $top and $skip

   $filter

   $expand

   $format

   $select

   $inlinecount

2. Custom Query options

3. Function Import parameters

Herein , we will discuss over the various nitty gritty details of having an orderby system query parameter; which is used in Odata query operations.

Herein , we will discuss over the top and skip system query parameter; which is used in Odata query operations. We will also how combination of top,skip and orderby can help us paginate the output results from the OData queries.

Herein, we are looking at one of the special case that highlights the importance of why we should not solely rely on the page count (established via top and skip) to ensure whether those number of records have been returned.

Here, we are looking into one of the most prominent system query option $filter.

We will consider the basics about the $filter criteria and also seek out the odata query which lists all Successfactors users including the ones those are inactive and be them internal or external.

Herein, we will see the logical and comparison operators those are supported by the $filter query option:

1. Equals

2. Not Equals To

3. Greater Than

4. Greater Than or Equal To

5. Less Than or Equal To

6. And

7. Or

8. Not

Herein , we will be looking at the arithmetic operators supported by the $filter:

1. addition

2. subtraction

3. division

4. multiplication

Herein , we will be looking at the arithmetic operators supported by the $filter:

1. () Precedence grouping

2. in

3. like

4. startswith

5. endswith

6. tolower

7. toupper

8. trim

9. length

We will also look at some special considerations using like operator.

Herein, we will look at the DateTime and DateTimeOffset data typed fields and understanding the format in which the DateTime(Offset) fields anticipate data and what timezone do they represent the datetime in.

Herein, we look at the various OData queries involving the DateTime , DateTimeOffset data types fields; also we go through some nitty gritty nuances.

Herein, we will look at the Time data typed fields and understanding the format in which the Time fields anticipate data.

Herein, we will look into some additional examples of the OData queries involving the Datetime fields - Time , DateTime, DateTimeOffset and also seek out resolution to a particular issue we get while executing the query on one of the datatimeoffset datatyped field.

Herein, we will look at various numerical datatypes and will also figure out some finer nuances needed to operate with these datatypes :

1. decimal

2. long

3. float

Herein, we will see the specifics around using the boolean datatyped fields in the filter applied over Odata entities.

Herein , we will look at one of the very important query options provided by OData i.e. $expand and we will see how the expand functions and helps in getting the navigation properties' objects deflated as represented as flat objects inline; we will also understand various nitty gritties around using the $expand.

Herein, we will have a look at one of the system query options $format, which drives the way the results are outputted - either in xml or in the JSON format. We will look at those options to alter the output in the needed format.

Herein, we will be looking extensively into $select system query option and what all capabilities it provides considering the simple , navigation , nested-navigation properties.

Herein, we will be looking into $inlinecount system query option and what all capabilities it provides. Also we will have a look over how to change the record size of the response been returned from OData.

Herein , addition to the ways being discussed in earlier sections as to how to create the API user;couple of additional mechanisms are discussed as to create API user via OData call and to provide the authorization to make the Odata calls and perform certain operations on the Successfactors application.