What's New in Server 2022.1
Release Date: May 4, 2022
Go to the complete Server 2022.1 Release Notes.
Removed Legacy OAuth1 Endpoints
In preparation for a future FIPS-140 offering, we removed our legacy public OAuth1 API endpoints (they required SHA1 hashing which is not FIPS-compliant). This removal includes the legacy WCF (Windows Communication Framework) endpoints, Swagger for these legacy endpoints, and OAuth1 middleware. To replace the OAuth1 endpoints, you can use the OAuth2 versions of the legacy APIs released in 21.4. You have the same functionality with the OAuth2 APIs as you did with the OAuth1 APIs. The only exception is that the GET/workflows/id/package call now returns a file instead of a binary object in the response.
We’ll continue to support subscription, V1, and V2 endpoints under OAuth2.
AMP Engine Enabled by Default
We've enabled the AMP engine by default on Server so that new worker nodes can run workflows for both the original and AMP engines concurrently. We will be providing guidelines on how to manage memory with multiple concurrent jobs, and in different combinations of the original and AMP engines.
What are the benefits of the AMP engine and why enable it?
- AMP provides significant performance and efficiency improvements over the original Engine.
- AMP is designed to work with larger volumes of data at a higher velocity and typically executes workflows faster, with efficient usage of machine resources.
- The original Engine architecture allows for mostly single-threaded processing, where your data are processed record-by-record sequentially. On the other hand, the new AMP concept allows for massively multi-threaded processing. Records process in 4 MB packets for a faster run time, and in parallel, which can affect the output record order.
- In the AMPlify Your Workflows article, some of the performance benefits that might be seen from using the AMP engine have been shown:
- The most commonly used tools will perform best on AMP.
- The benefit of AMP typically increases as data sizes become larger.
- Mileage will vary based on data sizes, underlying hardware, and workflow construction.
Required Password Reset for Built-In Authentication
If you use built-in authentication, you need to reset your password due to improvements in security. If you do not reset your password in version 22.1, then you must have SMTP enabled to reset it in version 22.2. For more information how to reset your Server password after upgrade to 22.1, visit the Reset a User's Server Password help page.
Along with the password reset, there is a Designer compatibility limitation for environments with built-in authentication. Older versions of Designer do not have the necessary password mechanism changes to authenticate with Server 22.1+. To ensure compatibility, you need to run Designer 22.1 or higher.
Server UI Localization (Beta)
We’ve localized the Server user pages in 8 languages (English, Japanese, Chinese, Spanish, French, Italian, German, and Portuguese) and 90+ locales. This is a beta version because some content is still in progress. To update your language and local preferences, go to My Profile > General.
Server UI Redesign
We’ve redesigned the Districts, Workflow Results, and Schedules user pages and the Collections, Credentials, Users, and Groups admin pages. The functionality of these pages remains the same.
New Welcome Email to Users Created via a POST /users API Call
We created a welcome email for new users created via a POST /users API call. The new welcome email includes a link for the user to set their password. This user experience is similar to what new users see when their account is manually created. Note that the welcome email will be sent only if SMTP is configured.
Built-In Authentication Configuration Options for Login Attempts and Account Lockout
To prevent brute force attacks, we added a configuration setting called Number of Login Attempts Allowed, where an admin can set the number of attempts allowed before a user is locked out. We also added a setting called Account Lock Timeout (Minutes), which sets the time in minutes that a user will be locked out after they have reached the maximum number of failed attempts. The default is set to 5 login attempts, after which we lock out for 5 minutes. We also added a setting option that allows curators to decide whether they want to enforce a login attempt timeout or not. The administrator can update these 3 security settings under Server Configuration > Security Settings. These settings are only available when you use Built-In Authentication.
Go to Alteryx Server Configuration for more information.
Upgrade jQuery Utilized by the New Swagger 2.0 Documentation
We upgraded jQuery to its latest version, 3.6.0, for Server's V3 Swagger documentation. This is part of a larger effort to remove old versions of jQuery. We expect to complete this later this year when we have redesigned the entire UI in the new React interface.
Migrated All Hashing Algorithms to SHA2 Using CryptoLib
In preparation for a future FIPS-compliant offering, we updated all non-Windows cryptographic calls in our codebase to rely upon a single Cryptographic Service Provider (CSP), the OpenSSL3-based module built and maintained by our DevSec team to FIPS-140 specification. This update should have no direct impact on user experience other than to make the solution more provably secure overall in its operation.
AES-256 Crypto Update
We migrated the cryptography we were using to secure legacy Data Connections (for example, DCM.E and API Secrets) to AES 256. This update has no direct impact on user experience, but it makes our solution more secure for our customers.
Internet Explorer Not Supported
Internet Explorer will no longer be supported as of 2022.1. The supported browsers are Chrome, Firefox, Edge, and Safari. Go to Version Support Policy for more information.