This sample contains multiple pre-built Linx functions which allow you to quickly connect and make HTTP requests the Salesforce REST API. These 'connector' functions have been built and tested to handle to the specifics of interacting with the various Salesforce API methods and objects. You can copy and use these functions in your own Linx Solution to accelerate development.
The goal of this Linx Solution is to ultimately include custom built connector functions for all the methods of the Salesforce REST API.
Requests made to the Salesforce API must use a unique URL which is based on their instance name. This name needs to be retrieved using the Identity Url from Salesforce. This identity url can be retrieved by querying for user info with the access token string.
-
Install the Linx Designer. Download it here.
-
Open the sample Solution '.lsoz' in your Linx Designer.
-
Open the Solution's settings and add your Salesforce instance name. For example, if my Salesforce instance URL is
https:/linx-dev-ed.salesforce.com/then my instance name is "linx-dev-ed".A function GetIdentity has been included in the sample to retrieve this information if you already posses your access token, see below for info on access generation..
Authentication of requests is achieved via access tokens, the functions take in the "access token" used in the request as an input parameter at runtime, which is then added to the header of the request.
This "access token" needs to be passed in to each function by you, this could be retrieved from a database, file or external service.
You're able to generate and retrieve your token from an external authentication service or, alternatively, you're able to host your own Linx authentication service with the linx-oauth-token-service project on GitHub.
This sample contains generic "connector" functions which can be imported and used in your own Linx Solution.
Each connector function in the Solution follows the below structure:
- Takes in an "access token" value as an input parameter.
- Takes in any data used for the request parameters such as query, path or requestBody values.
- Makes a HTTP request to the API and returns a string response.
- The response string is then de-serialized into the function result object type.
These functions do not persist any data and only return or send data that is received at runtime, therefore you must add your own data persistence layer if required.
An automated testing function has been included in each sub-sections of the Solution Explorer within the sample Solution to test the relevant functionality. For example the 'Accounts' section contains all the neccessary methods for interacting with the 'Account' object on the Salesforce API.
To test out an area's functionality:
- Located the Test folder of the sub-sections of in the Solution (i.e. Accounts > Tests).
- Initalize the debugger on the TestAllXXXRequests functions (i.e. TestAllAccountRequests).
- Add your access token as an input parameter.
- Start the debugger.
- The function executes the following requests with test data (i.e TestAllAccountRequests):
- Creates a new account
- Retrieves the details of the new account
- Retrieves a list of all of the accounts
- Loops through the account list
- Updates the relevant account
- When the function completes, a test object will have been created and updated on the Salesforce API.
- Right-click on the SalesforceAPI folder in the Solution Explorer.
- Select Copy.
- Open your own Solution.
- Right-click on your Solution Explorer and click Paste.
- A validation error will occur referencing the missing setting values.
- Copy and paste the setting names and values from the Sample solution into your own Solution.
- The validation messages will dissapear and you can now drag the required connector functions into your own custom functions.
For questions and issues please ask the Linx community or use the Slack channel.
If you have any specific requests for sObjects that have not yet been implemented, get in touch with [email protected].