Tokenization Service Release Notes

If Luhn and None were mixed for the Check Digit in custom tokenization formats, tokenization and detokenization requests failed.

Fix: A mix of Luhn and None for Check Digit is not allowed. If you try to add custom formats and mix Luhn and None for Check Digit, when you try to save the custom formats, the UI enforces proper configuration.

An error appears, which states that All entries for custom credit card formats should have the same value for luhnCheck and must also match the value of Luhn Digit Test field and you are not allowed to save the incorrectly configured custom formats.

Additionally, if all formats are set to None, you cannot select Generated token must pass Luhn test. The same error message as above appears, and you are not allowed to save the custom format.

(MSG-6616) The maximum value for the Response Msg Body Scanning is 1 MB, and messages exceeding that limit are no longer rejected—​they are simply not scanned.

Previously, the limit for the response body was 512 KB, and messages exceeding that limit were rejected. You no longer have to disable this option to ensure messages larger than the limit aren’t rejected.

(MSG-6733) In certain scenarios, the deployer is unable to move a deployment from the APPLYING state to the FAILED state for long periods of time, which causes the tokenization user interface to block all the action buttons. The user can’t change or delete the service.

Workaround: The user can call the API and set the deployment to STOPPED state using the following endpoint:

https://anypoint.mulesoft.com/tokenization/api/v1/organizations/{orgId}/environments/{envId}/service/{serviceId}?desiredStatus=STOPPED

After this call the deployment either sets the state to FAILED or STOPPED and all the action buttons are enabled in the tokenization UI.

(MSG 6587) The Tokenization API uses the user’s access token to perform CREATE, UPDATE and REKEY of the Tokenization service. These operations can sometimes take a very long time (especially when formats such as email and printableASCII are used). This may cause the user’s access token to expire before the operation completes, resulting in a state of FAILED, UPDATE_FAILED or REKEY_FAILED when using the API, or BUILD_FAILED when using the UI. If the user logs out, the token becomes invalid.

Workaround: Re-login to the user interface, or get a new access token on the API, and try the operation again.

(MSG 6496) When updating an existing Tokenization service, if there is no space left in the Kubernetes cluster, the Tokenization service enters the FAILED state.

If the Kubernetes cluster in Runtime Fabric is running low on memory or CPU, upgrading a Tokenization service (with no HA) fails. It also takes down the existing service and fails to bring it back to a running state.

Workaround:

(MSG-6319) There is an issue when more than one Tokenization service CREATE is initiated at the same time. A race condition can occur where the deployment request is lost and the Tokenization service CREATE fails.

Workaround: If the table fails to apply:

(MSG-6285) When deploying a Tokenization Service CREATE request, it is possible for the Tokenization service CREATE to get stuck in the applying state. If the service is stuck in the applying state for > 10 minutes, this problem occurs.

Workaround:

(MSG-6317) If the same user is editing the Secrets Group used for tokenization at the same time a Tokenization service CREATE is initiated, the editing session prematurely terminates. Edits in that session, as well as the VDP table key in the Secrets Group will be saved.

There are two different workarounds.

Workaround 1: Check all browser tabs before starting the Tokenization service CREATE to make sure a single user doesn’t edit the same Secrets Group that is also being used for tokenization.

Workaround 2: Use a dedicated Secrets Group for use only by the Tokenization service.

(MSG-6315) The Tokenization service CREATE does not navigate back to the Tokenization service list page after sending out a Successful Deploy Request message.

When the user clicks Deploy they see a green box in the lower right corner saying Request Successful for 10 seconds. The status on this page continues to display None. Depending on how many formats are included in the request, the Tokenization service can take from to 60 minutes to build and be applied. The status on this page doesn’t change during this time.

Workaround: Click the back link to go back to the Tokenization Service list page. The status of the current deployment is displayed in gray text following the Tokenization Service name in the list.