2 Posts getaggt mit "maintenance"

TSS Update Postponed​

The reason is an bug discovered during testing that can cause updated TSS instances to transition to a permanent secure state. In consequence, the announced actions for 5.6.2022 and 6.6.2022 will not take place. We are analyzing the reason for the problem, and will proceed with fixing it. This will require a recertification of the SMAERS. A new update date will be announced in advance once the process is complete.

FAQ of Postponed Update​

Below you can find answers to some questions you may have on the postponed TSS update.

Does the postponed update affect my operation of SIGN DE?​

Customers will feel no impact from the postponement of the update. The presently running certified TSS version (1.0.5-1.2.0) is stable and works reliably.

The changes in the updated versions concern further improvements in stability, but are not critical for the normal operation of the SIGN DE API.

Why was the update postponed?​

During the extensive testing in our TEST environment, a bug was detected. Under certain circumstances, this bug results in some of the SMAERS instances that were updated from version 1.0.5 to version 1.0.6 entering an unrecoverable secure state.

‘New’ SMAERS instances, that were created in version 1.0.6, are not affected by this bug. No problems have been detected with the new CSPL version 1.3.0.

Fixing this problem is only possible by changing the implementation of our SMAERS, which means that it has to undergo a recertification process before it can be deployed to production. As a result, the planned update has to be postponed until that process is completed.

What is the impact of the postponed update?​

The postponement affects the update of the TSS in the LIVE environment. In TEST, which has already been updated, the TSS version 1.0.6-1.3.0 will continue to run for testing purposes. This means that:

• In LIVE environment, the TSS version will remain at 1.0.5-1.2.0 (the ‘old’ version). This means that for the customers, nothing will change compared to now.

• In TEST environment, the TSS version will remain at 1.0.6-1.3.0 (the ‘updated’ version). As the environment is set up to create new TSS instances only in this version, the bug will not affect customers' TSS instances in the TEST environment. The behaviour of this version from a customer perspective is indistinguishable from the previous version, meaning that the ‘updated’ TSS instances will behave the same as the ‘old’ ones. No tests or other customer-side integration will be affected, apart from the presence of the updated TSS version in the info.csv file of TSS exports.

Why was the problem not detected earlier?​

Despite extensive automated and manual testing, the bug was not detected during development or certification because the specific circumstances that triggered it were difficult to anticipate and test for in advance. The complexity of the TSS is such that some behaviors are rare and will only be detectable in large-scale and highly dynamic environments.

However, this was precisely why an extended period of testing in TEST environment, which more closely approximates the conditions and behavior of our LIVE environment, was planned for before the update in LIVE environment took place.

Will the update still take place in the future?​

The changes incorporated in TSS version 1.0.6-1.3.0 will be part of the next update, which will take place once the SMAERS recertification is complete, leading to a new SMAERS version (1.0.x). The update will then upgrade the TSS version in TEST environment and LIVE environment to version 1.0.x-1.3.0.

It is difficult to estimate how much time the development and recertification effort will require, but the anticipated delay is in the order of at least a few months. Should an update date be decided upon, we will notify customers in advance in the same manner as we did for this update.

Why not update the CSPL, if it has no problems?​

The TSS certification process requires the separate certification of both the individual component versions (SMAERS and CSPL) as well as their combination (i.e., the TSS as a whole). Hence we are not allowed to update only the CSPL, as this would lead to the TSS instances in LIVE environment being in an uncertified version (1.0.5-1.3.0).

Best, the fiskaly SIGN DE Team

TSS Update on June 5, 2022​

Here you find more information on our scheduled maintenance on June 5, 2022. We will update our system to make it even better.

SIGN DE - TSS Update Announcement​

The maintenance will involve a rolling update of LIVE TSS instances from version 1.0.5-1.2.0 to version 1.0.6-1.3.0 (where the former is the SMAERS version and the latter is the CSPL version).

During the maintenance window, the following restrictions apply:

• Data Exports are disabled.
• TSS state transitions to DISABLED are not possible.
• API calls may take longer than usual or run into timeouts.
• Service interruptions may occur.

Note for June 6, 2022​

FAQ of TSS Update​

Below you can find answers to some questions you may have on the TSS update on June 5, 2022.

What does the update entail?​

The update concerns the deployment of the new certified versions for the SMAERS (from version 1.0.5 to 1.0.6) and CSPL (from version 1.2.0 to 1.3.0), together representing an update of the entire TSS to version 1.0.6-1.3.0.

The TSS update will also represent the deployment of version 2.1.0 of SIGN DE API.

You can find the certification documents for the new versions at Certification | fiskaly.developer.

What are the effects of the update?​

The new versions of SMAERS and CSPL include bugfixes and stability improvements. Customers' operations should not be affected, as there are no changes to the API. The only visible differences are in the exports triggered after the update: the exports will include the update logs, and the TSS version in the info.csv will be incremented to 1.0.6-1.3.0. Old exports, i.e. exports triggered before the update, will not be affected by it.

Only TSS instances that are in the states UNINITIALIZED or INITIALIZED will be updated. All existing and new TSS instances in the state CREATED will be in the new version once they are transitioned into the UNINITIALIZED state. An update of DEFECTIVE and DISABLED instances is not possible due to technical reasons.

Customers may experience some temporarily increased latency in the handling of their first post-update requests due to the need to re-establish communication between SMAERS and CSPL, and synchronize the update logs across all components.

What do I need to do?​

Customers do not need to do anything on their side. As mentioned above, there are no effects on customer operations apart from some restrictions and the inevitable interruptions during the update process.

We recommend to follow our guide on how to deal with service interruptions and timeouts at Error and Timeout-Handling | fiskaly.developer.

After the update is completed, you can verify the update by checking your info.csv files in the data exports of INITIALIZED TSS instances for the correct TSS version.

Can I continue to use SIGN DE API during the update timeframe?​

In principle, yes. During the maintenance window, individual calls may fail, time out or take longer than usual.

Data Exports and the TSS state transition to state DISABLED will also be temporarily disabled during the maintenance window. HTTP endpoints regarding these operations will respond with HTTP status code 503.

Otherwise SIGN DE API will remain available and functional throughout the maintenance window.

When will the update take place?​

The update will take place as a rolling update over longer periods of time during the announced maintenance window. It does not mean that it will start at exactly 8:00 or last until exactly 16:00, but during that period different parts of SIGN DE API will be updated at various times.

What does it mean that the data exports are disabled?​

During the maintenance window the export endpoints will return HTTP status 503.

How long will the data exports be disabled?​

The data exports may be disabled and re-enabled for longer periods of time at various points during the announced maintenance window. We recommend avoiding data exports during the maintenance window entirely.

How long will the TSS disabling functionality be disabled?​

The TSS disabling functionality may be disabled and re-enabled for longer periods of time at various points during the announced maintenance window. We recommend avoiding setting TSS instances to state DISABLED during the maintenance window entirely.

What does it mean that service interruptions can occur?​

In addition to the disabled functionality, during the rolling update process, individual TSS instances may be temporarily unreachable or busy as their components are being updated.

Some TSS instances may temporarily display increased latency in the handling of their first post-update requests due to the need to re-establish communication between SMAERS and CSPL, and synchronize the update logs across all components.

Happy updating, the fiskaly SIGN DE Team