- 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.
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.
- "SuccessFactors-Partner connector" used in DELL Boomi client application.
- Standard "SuccessFactors ODATA V2" adapter in SAP CPI (Cloud Platform Integration)
- OData V2 Adapter in SAP CPI (Cloud Platform Integration)
- 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.
Example2: SPACE in $ORDERBY
Here, you would notice SPACE entered for $ORDERBY Parameter before "asc"
Example3: SPACE in $SELECT
Here, you would notice SPACE in the $SELECT parameter which needs to be encoded by the client application
https:// <API-Server>/odata/v2/User?$select=userId, username&$top=1
Example4: SPACE in $EXPAND
Here, you would notice SPACE in the $EXPAND parameter which needs to be encoded by the client application
Example5: SPACE in COMPLEX Query
Here, you would notice several SPACEs used in $FILTER parameter
https://<API-Server>/odata/v2/Position?paging=snapshot&$filter=parentPosition/lastModifiedDateTime le datetime'2001-07-01T17:19:28' or companyNav/lastModifiedDateTime ge datetime'2001-07-01T17:19:28'
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:
NOTE: %20 is encoded value for space
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 HXM Suite
- 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