Hands-On – Testing Integration with SuccessFactors SFAPI

SFAPI is SuccessFactors web-service to import or export data to or from SuccessFactors. As this is a web-service, an obvious choice for testing is SOAPUI. This document will walk you through the simple steps to test connection with SuccessFactors and extract some data using SOAPUI. You may replace SOAPUI with any of your middleware/ ETL tool/ HTTP Client application capable of handling HTTP cookies for real world scenario.

Note: The authorization available to SFAPI user is pretty extensive and therefore this demo can help the tester to extract a lot of critical employee data. Please restrict the SFAPI access and use it wisely.

Prerequisites

1. Enable SFAPI in Provisioning.
2. Create SFAPI user in Provisioning.
3. Provide Role Based Permission (RBP) authorization to the SFAPI user. If you are not using RBP, you may use User based permission.
4. SOAPUI installation and a very basic understanding.

SuccessFactors URL

SuccessFactors URLs or endpoints are specific to data centers. You should always use the URL specific to your data center.

https://<hostname>.successfactors.com/sfapi/v1/soap

The WSDL as usual can be retried by adding “?wsdl” to the link

https:// <hostname>.successfactors.com/sfapi/v1/soap?wsdl

You may find an actual WSDL structure here:

https://salesdemo4.successfactors.com/sfapi/v1/soap?wsdl

SuccessFactors User Credential

In order to access the data, you will need username, password and Company ID. The Company ID is your unique Company ID which you use to log into your SuccessFactors instance.

SOAPUI Configuration

1. Create a new SOAPUI Project and use the SuccessFactors URL as the ‘Initial URL’. ‘salesdemo4’ is used as a hostname only for reference to upload the WSDL. For actual data extraction, you should either have access to salesdemo4 with all the prerequisites met or use your client specific data center.

  2. Once you click OK, you will find the entire definition loaded into SOAPUI.

  3. Right click SFAPISoapBinding and click on Generate TestSuite.

  4. When it prompts, there is no need to change any parameter and you may directly click Ok. Change the TestSuite name if needed, else press OK. You will find a TestSuite generated.

  5. First one you want to try is the login TestCase. Double click the ‘login’ tab and enter your username, password and CompanyID. Verify the URL and execute.

  6. Hurray! The session ID is retrieved which shows that the connection successfully worked.

But that is not all. The main criterion to test SFAPI is the session handling. The session ID retrieved in step 5 is the HTTP Cookie that must be passed to all subsequent HTTP requests for authentication purposes. Unless you execute a logout step, the session stays open until 10 minutes. So let’s have a look how a session can be maintained using SOAPUI.

   7. Open one of the ‘Test Step’ in the Test suite you created. For testing I am using ‘list’ option. Add login and logout step before and after the list step respectively.

  8. To do that, click on SOAP request, name it ‘login’ and select the login operation.

  9. Repeat the step to create a logout step after the list step. Your test case should have 3 steps as shown:

  10. To maintain HTTP session, use ‘Sets options for this TestCase’ option and select ‘Maintain HTTP Session’.

  11. Add login details to login step as done in Step 5 and check again the URLs used in each test step. Once done, execute the test case.

  12. Output of each test step can be seen by double-clicking the steps. A sample of list output is below:

13. To monitor this call in SFAPI, Login to instance -> Admin Tools -> SFAPI Audit Logs

Note: You may freely use Session management (login, logout) and Metadata (list, describe) operations. However, while using Data Manipulation operations (insert, update, upsert, delete), take extra care as you are directly manipulating the database.

Also see: Hands-On – Testing Integration with SuccessFactors Odata API