Skip to main content

Note that with this release we have moved to a more traditional semver numbering scheme for release versions. The prior release was 2020.17.1.

Check out the enosix connect documentation portal

  • [Feature]: Lots of documentation updates
  • [Feature]: Changes to RIO bundles
  • [Feature]: SAP Cloud Platform credentials can now be renewed when they expire
  • [Feature]: SAP session functionality - you can now perform multiple API calls within a single session on the server; EXISTING TENANTS MUST BE REDEPLOYED TO TAKE ADVANTAGE
  • [Update]: Various console stability improvements
  • [Update]: Various improvements to the manual deployment process
  • [Bugfix]: You are no longer able to attempt to use an SAP Cloud Connector on apps not deployed in SAP Cloud Platform
  • [Bugfix]: Memory quota for apps in SAP Cloud Platform is no longer reset on redeployment
  • [Bugfix]: You can now create apps with the same name as apps that were previously deleted

The Salesforce Winter 21 release includes a breaking change

The Restrict Access to AuraEnabled Apex Methods for authenticated users was a critical update included in the Winter 21 release that essentially require that a user be explicitly granted access to the Apex code that a front-end lightning component calls. Without making a security change to Salesforce the lightning components in salesforce apps (including enosix apps) can behave in strange ways including not displaying or looking like they are frozen.

Does it impact my organization?

While this update affects all apps - not just enosix. But within your enosix apps, Surface v1.10 and later include the updated permission sets and are thus unaffected. All customers running an earlier version of Surface or any enosix product other than Surface are likely to see problems.

How do I fix it?

The easiest way to correct the issue is to create a Salesforce permission set per app and add all of the Apex classes for that app to the permission set. The permission set can then be granted to each affected user who needs access to that app.

Below is an example for our Surface app, and this same workaround will work for other enosix apps, as well as apps from other salesforce partners and any custom developed app you may have in your org.

1. Create a Permission set
  • Setup > Quick Find, Enter 'Permission Sets'
  • In the Permission Sets screen click on the New button it is in the list header.
  • In the Label field enter a descriptive name - something like 'enosix Surface Winter 21 Security Patch'. (The best practice is to create a permission set per app to reduce access to apex code but in a pinch one permission set can be used for all your apps.)
  • Click Save.
2. Add Apex Classes to the permission set
  • In the Permission Set screen click on the Apex Class Access Link. (Under Apps Section, fifth down from the top)
  • In the Apex Class Access Table click the Edit button in the table header.
  • There will be two list boxes, in the right one labeled Available Apex Classes, select the classes prefixed for the app your are correcting. For enosix Surface select all classes that start with ensxapp. (NOTE: for other enosix apps select ensxsdk, ensxafs, ensxb2b and any classes that start with the prefixes CTRL_, UTIL_, SBO_, or RFC_) . Other salesforce apps will have their own guidance on what prefixes or grouping to select.
  • With the list entries selected click on the Add Button with the Arrow pointing to the Right >, the selected entries will be moved to the Enabled Apex Classes list box. It may take a couple of scans of the list to find all of the apex classes, and the add button can be used multiple times.
  • Click on the Save Button.
3. Assign the permission set to users
  • Click on the Manage Assignment Button in the toolbar it is to the right of the Find Settings search box.
  • In the Assigned Users screen click add assignments and in the list of users select the users who need access to the app by checking the box in the Action column.
  • Click the Assign Button.
  • The user permissions for the app should now be corrected for Winter 21.

This patch release is to fix a single issue (see Bugfix below). Organizations not experiencing this issue do not need to upgrade.

Updated Install links are available here: Surface Salesforce Package Installation

  • [Bugfix]: Account number mapping (SAP Customer information Settings) using a field on custom SObjects (rather than the Account object) is now working. This fixes message: The "...__c" SObject is not currently mapped in the SAP Customer Information Setting Custom Metadata Type.
warning

When upgrading from versions <= 1.9.5 to v1.10.1 the page layouts become invalid because of an issue with the way field presets are stored on the record pages. To overcome this situation, you must click on the affected app pages that use custom field presets. You should record all existing values before you upgrade, since existing values in the app editor will be lost. After the upgrade, you can manually reconfigure your app pages with your recorded values.

warning

When upgrading from v1.7.x v1.8.x, you’ll need to modify any customized “SAP Sales Document Details” flows that use the Sales Doc Flow component by following the instructions located here: "Fixing “SAP Sales Document Details” flows cloned from v1.7.x or v1.8.x".

warning

When upgrading from v1.6 or below, please follow the instructions located here: Upgrading to Latest Version of Surface.

This release fixes the intermittent connection error that would happen every 30-40 min and then would resolve after about two minutes.

  • Fixed logic for authentication refresh token to SAP Cloud Connector proxy.

Ensure your manifest file is using the stable image, see below. Restart your link application instances in the Sap Cloud Platform Cockpit to perform the update.

docker:    
image: enosix/link:stable

enosix Link Docs

  • [Bugfix]: Fixed proxy authentication to SAP Cloud Connector. (Intermittent connection error every 30m)

  • [Feature]: New RIO bundles have been added
  • [Feature]: Lots of documentation improvements (notably RIOs related to sales document create and variant configuration)
  • [Update]: App deployments now use a background job so they can be restarted/recover on failure
  • [Update]: Some backend stability improvements
  • [Bugfix]: Now properly displays RIOs that are on the server but not in a bundle