The K2 Salesforce broker fails to create an instance and SmartObjects when TLS 1.0 is disabled in Salesforce.
You may receive an error similar to the following:
UNSUPPORTED_CLIENT: TLS 1.0 has been disabled in this organization. Please use TLS 1.1 or higher when connecting to Salesforce using https.
Salesforce is in the process of disabling TLS 1.0 encryption protocol in a phased approach, finalizing the transition in July 2017. After this date, the TLS 1.1 encryption protocol will be required to connect to Salesforce. This change affects all inbound and outbound connections. (For more details, please refer to the Salesforce article ‘Salesforce disabling TLS 1.0.) As a result of this change, if your K2 environment currently integrates with Salesforce or you are configuring the Salesforce broker, you might experience issues when connecting to Salesforce from K2.
There are a couple of options when dealing with this TLS issue based upon what version of K2 you are on and when you are viewing this document. The below options should not require you to rebuild any forms, workflow or SmartObjects.
Option 1 - Prior to July 2017
The original K2 Salesforce broker requires that TLS 1.0 is enabled to make the connection to Salesforce. Salesforce will permit its customers to request that TLS 1.0 be re-enabled until early July, 2017 when TLS 1.0 is deprecated completely. To resolve issues with the broker that are related to the protocol change, you will need to contact Salesforce.com and request that TLS 1.0 is re-enabled for your organization, to allow your K2 Salesforce integration to continue to function as expected. Once done this should require no additional effort on the K2 configuration. However, this will stop working in July, 2017.
Alternatively, if you are on K2 version 4.6.10, 4.6.11 or 4.7 (or are willing to upgrade) you can consider moving to TLS 1.1 or 1.2 now. For more details see option 2 below.
Option 2 -During or after July 2017
If you are reading this during or after July 2017, you must move to TLS 1.1 or 1.2. This requires you to be on K2 4.6.11 or greater. If you are on K2 4.6.10 or 4.6.11 you can request a code fix from K2 Support that provides the updated Salesforce broker. If you are on K2 4.7, the fix is included with the platform so you do not need to make a support request. If you are on a version earlier than 4.6.10, you must upgrade to either K2 4.6.10 or 4.6.11 (and request the code fix) or upgrade to K2 4.7. Once upgraded to K2 4.7, you need to rerun the broker management tool using the .NET 4 option to regenerate the DLLs.
Once the DLLs have been regenerated, there is no need to re-register the SalesForce service instance when you follow the steps below.
With the updated Salesforce component, it is possible to replace the service instance DLLs without re-registering the service instance. Use the Broker Manager tool as described in the Configure Salesforce Integration topic of the K2 Installation and Configuration Guide.
- Generate a new instance using the same WSDL file and the same service instance name (in the This instance name box) as you used for your existing service instance. However, choose a different instance destination path and use the .NET 4 option. This creates new DLLs in the folder.
- Then, when the DLLs are generated and you are prompted to register them, choose No.
- Close the Broker Manager tool, backup the old service instance DLLs, and then replace them with the newly generated ones. This should not result in any changes to the SmartObjects, meaning that all forms and workflows using Salesforce SmartObjects should continue to function without issue.
K2 is developing a new Salesforce service broker that will not only work with the TLS 1.1/1.2 encryption protocol but also leverage a different Salesforce API. The original Salesforce service broker uses the legacy SOAP API, while the new K2 Salesforce service broker will use the Salesforce REST API. Apart from supporting TLS 1.1, the new REST API also allows for improved integration between K2 and Salesforce. The behavior of the REST API is, however, different from the older SOAP API which means that the objects, properties, and methods are not backwards-compatible between the old and new service brokers. When the new service broker is available, you will have to rebuild your existing Salesforce-integrated SmartObjects and dependent items (such as forms, workflows and other integration that uses or relies on those Salesforce-integrated SmartObjects).