Aller au contenu

Maintenance planifiée

Mise à jour reportée

La mise à jour précédemment annoncée de l’API SIGN DE le dimanche 5 juin 2022 est reportée. La maintenance planifiée n’est donc plus nécessaire et est annulée. Vous trouverez plus d’informations dans notre article de blog associé Mise à jour reportée

Vous trouverez ici plus d’informations sur notre maintenance planifiée du 5 juin 2022. Nous mettrons à jour notre système pour le rendre encore meilleur.

Remarque : Maintenance planifiée le dimanche 5 juin 2022, de 08h00 à 16h00 CET L’API SIGN DE sera soumise à une maintenance planifiée le dimanche 5.6.2022, entre 08h00 et 16h00 (CET).

La maintenance impliquera une mise à jour progressive des instances TSS LIVE de la version 1.0.5-1.2.0 à la version 1.0.6-1.3.0 (où la première est la version SMAERS et la seconde est la version CSPL).

Durant la fenêtre de maintenance, les restrictions suivantes s’appliquent :

  • Les exportations de données sont désactivées.
  • Les transitions d’état TSS vers DISABLED ne sont pas possibles.
  • Les appels API peuvent prendre plus de temps que d’habitude ou expirer.
  • Des interruptions de service peuvent survenir.

Remarque : À la suite de la mise à jour du TSS, le 6 juin 2022 entre 05h00 et 08h00 (CET), la première requête adressée à un TSS peut prendre jusqu’à 15 secondes.

Vous trouverez ci-dessous les réponses à certaines questions que vous pourriez avoir concernant la mise à jour du TSS du 5 juin 2022.

La mise à jour concerne le déploiement des nouvelles versions certifiées pour le SMAERS (de la version 1.0.5 à la 1.0.6) et le CSPL (de la version 1.2.0 à la 1.3.0), représentant ensemble une mise à jour de l’ensemble du TSS vers la version 1.0.6-1.3.0.

La mise à jour du TSS représentera également le déploiement de la version 2.1.0 de l’API SIGN DE.

Vous pouvez trouver les documents de certification pour les nouvelles versions sur Certification | fiskaly.developer.

Les nouvelles versions de SMAERS et CSPL incluent des correctifs de bogues et des améliorations de stabilité. Les opérations des clients ne devraient pas être affectées, car il n’y a pas de modifications de l’API. Les seules différences visibles se trouvent dans les exportations déclenchées après la mise à jour : les exportations incluront les journaux de mise à jour, et la version TSS dans le fichier info.csv sera incrémentée à 1.0.6-1.3.0. Les anciennes exportations, c’est-à-dire celles déclenchées avant la mise à jour, ne seront pas affectées.

Seules les instances TSS dans les états UNINITIALIZED ou INITIALIZED seront mises à jour. Toutes les instances TSS existantes et nouvelles dans l’état CREATED seront dans la nouvelle version une fois qu’elles passeront à l’état UNINITIALIZED. La mise à jour des instances DEFECTIVE et DISABLED n’est pas possible pour des raisons techniques.

Les clients peuvent connaître une latence temporairement accrue dans le traitement de leurs premières requêtes après la mise à jour, en raison de la nécessité de rétablir la communication entre SMAERS et CSPL, et de synchroniser les journaux de mise à jour entre tous les composants.

Les clients n’ont rien à faire de leur côté. Comme mentionné ci-dessus, il n’y a pas d’effets sur les opérations des clients, hormis quelques restrictions et les inévitables interruptions pendant le processus de mise à jour.

Nous recommandons de suivre notre guide sur la gestion des interruptions de service et des expirations dans Gestion des erreurs et des expirations.

Une fois la mise à jour terminée, vous pouvez la vérifier en contrôlant vos fichiers info.csv dans les exportations de données des instances TSS INITIALIZED pour la version TSS correcte.

Puis-je continuer à utiliser l’API SIGN DE pendant la période de mise à jour ?

Section intitulée « Puis-je continuer à utiliser l’API SIGN DE pendant la période de mise à jour ? »

En principe, oui. Pendant la fenêtre de maintenance, des appels individuels peuvent échouer, expirer ou prendre plus de temps que d’habitude.

Les exportations de données et la transition d’état TSS vers l’état DISABLED seront également temporairement désactivées pendant la fenêtre de maintenance. Les endpoints HTTP concernant ces opérations répondront avec le code de statut HTTP 503.

Dans les autres cas, l’API SIGN DE restera disponible et fonctionnelle tout au long de la fenêtre de maintenance.

La mise à jour se déroulera comme une mise à jour progressive sur de plus longues périodes pendant la fenêtre de maintenance annoncée. Cela ne signifie pas qu’elle commencera exactement à 8h00 ou durera jusqu’à exactement 16h00, mais que pendant cette période, différentes parties de l’API SIGN DE seront mises à jour à différents moments.

Que signifie le fait que les exportations de données soient désactivées ?

Section intitulée « Que signifie le fait que les exportations de données soient désactivées ? »

Pendant la fenêtre de maintenance, les endpoints d’exportation renverront le statut HTTP 503.

Combien de temps les exportations de données seront-elles désactivées ?

Section intitulée « Combien de temps les exportations de données seront-elles désactivées ? »

Les exportations de données peuvent être désactivées et réactivées pendant de plus longues périodes à différents moments au cours de la fenêtre de maintenance annoncée. Nous recommandons d’éviter complètement les exportations de données pendant la fenêtre de maintenance.

Combien de temps la fonctionnalité de désactivation TSS sera-t-elle désactivée ?

Section intitulée « Combien de temps la fonctionnalité de désactivation TSS sera-t-elle désactivée ? »

La fonctionnalité de désactivation TSS peut être désactivée et réactivée pendant de plus longues périodes à différents moments au cours de la fenêtre de maintenance annoncée. Nous recommandons d’éviter complètement de définir des instances TSS à l’état DISABLED pendant la fenêtre de maintenance.

Que signifie le fait que des interruptions de service peuvent survenir ?

Section intitulée « Que signifie le fait que des interruptions de service peuvent survenir ? »

En plus de la fonctionnalité désactivée, pendant le processus de mise à jour progressive, des instances TSS individuelles peuvent être temporairement inaccessibles ou occupées pendant que leurs composants sont mis à jour.

Certaines instances TSS peuvent afficher temporairement une latence accrue dans le traitement de leurs premières requêtes après la mise à jour, en raison de la nécessité de rétablir la communication entre SMAERS et CSPL, et de synchroniser les journaux de mise à jour entre tous les composants.

Bonne mise à jour, l’équipe fiskaly SIGN DE

Was this page helpful?