3080793 - SuccessFactors ODATA API call connectivity verification to validate compatibility with SAP network changes to be security compliant

• To be compliant with latest security standards, SAP SuccessFactors will roll out network changes across DC2, DC10 and DC12 Datacenters.
• One impact which we have evaluated is Interpretation of non-encoded spaces in HTTP URIs. 
• This would affect ODATA API request and validate if client Application from where ODATA API call is being triggered is encoding the special character "  Space" or not.
• The test steps described in this KBA are to verify if there is any SPACE special character being sent by client application to SuccessFactors. 

NOTE: "Client Application" refers to any application from where ODATA API GET request (query Operation) is being triggered.

Change Date

DC12(Production): 13th November, 2021

DC10(Production): 10th July, 2022

Note: As changes are being done at network layer, change will be impacting preview and production environment together. It is not possible to roll out the changes in Preview environment explicitly.

Would this be impacting all customers?

No. Customers need to validate their GET request for ODATA API call and check if any SPACE is used in the ODATA API GET request URI (QUERY Operation). If yes then validate the client log to check if Client is doing the space encoding. Validation steps are shared below under resolution section.

SAP provided standard connector/Adapter would be impacted too?

Below standard adapters/Connector provided by SAP in respective client applications by default supports URL encoding for SPACES and no action is required for these adapters and connectors.

1. "SuccessFactors-Partner connector" used in DELL Boomi client application.
2. Standard "SuccessFactors ODATA V2" adapter in SAP CPI (Cloud Platform Integration)
3. OData V2 Adapter in SAP CPI (Cloud Platform Integration)
4. SuccessFactors ODATA Adapter in SAP PI/PO

Few Examples of impacted ODATA API URI?

Below are few examples:

Example1: SPACE in $FILTER

Here, you notice the SPACE before and after operator "eq". If this space is not being encoded by the client then this needs to be manually replaced with %20 which is the encoded value for SPACE Character.

https://<API-ENDPOINT>/odata/v2/User?$filter=userId eq 'xxxx'

Example2: SPACE in $ORDERBY

Here, you would notice SPACE entered for $ORDERBY Parameter before "asc"

https://<API-Server>/odata/v2/User?$orderby=username asc

Example3: SPACE in $SELECT

Here, you would notice SPACE in the $SELECT parameter which needs to be encoded by the client application

NOTE: Above are few examples based on observation of usage. Make sure you validate your API Request URI carefully for any SPACE to avoid any failure.

Can you validate the GET request under Admin center-> ODATA API Audit log?

No. This validation method is wrong and you cannot confirm looking at the Audit log request. You need to validate the client application log. Check the example in resolution section.

If you are going to be impacted, what would be the next step?

Make sure ODATA API Request URI generated by client application has encoded space. If client application does not support SPACE Encoding then replace the SPACE with %20 manually.

For one of the examples above,ODATA API Request URI would look like below:

https://<API-ENDPOINT>/odata/v2/User?$filter=userId%20eq%20'xxx'

NOTE: %20 is encoded value for space

https://www.w3schools.com/tags/ref_urlencode.asp

NOTE: Do validate if you are using other adapters or any other 3rd party client application to trigger the ODATA API call.

Disclaimer: Image/data in this KBA is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental. 

• SAP SuccessFactors HCM Suite
  
  • Integrations
    
    • ODATA API

Steps to validate:

1. Reach out to your Integration consultant and share this KBA to evaluate the impact.

2. Use this GET Request after replacing the "API ENDPOINT" with endpoints based on Data Center and provide a valid userId value in filter parameter: https://<API-ENDPOINT>/odata/v2/User?$filter=userId eq 'XXX'

Example: If SF Company ID in DC2 then API endpoint URL would be api2.successfactors.eu and get request would become https://api2.successfactors.eu/odata/v2/User?$filter=userId eq 'XXX'

3. Trigger this query from all the clients you are currently using for ODATA API query operation using filter parameter.

Example of HTTP URI generated in one of the client and corresponding log shows query formed by the client which would be sent to SAP SuccessFactors:

If client generates query like above where you can see that WHITE SPACE is not encoded by the client application then your query will be impacted once SAP implements network related changes as above request URI is not secured.

4. Make sure you replace the WHITE SPACE with "%20" and test again. Your application log would look like  below:

If your application client is generating encoded filter as above or "+" instead of WHITE SPACE then your API call would not get impacted post SAP implements the security changes.

ODATA API GET request, Query Operation $FILTER, security changes, spaces, space, URL, encoding, space encoding,  , KBA , LOD-SF-INT-ODATA , OData API Framework , Problem