SARA vs TJC ASC : pourquoi la transaction SAP SARA ne peut pas offrir une automatisation complète de l’archivage

Auteur : Thierry Julien, PDG, TJC Group

Vous devez archiver FI_DOCUMNT. Vous ouvrez la transaction SARA, saisissez le nom de l’objet et appuyez sur Entrée. L’écran se charge. Et maintenant ? Vous voyez une série de boutons : Write, Delete, Store, Read, ainsi qu’un lien vers Customising. À partir de là, tout repose sur vous : quels codes société, quels exercices fiscaux, quelle variante, quand planifier, quoi faire lorsque quelque chose se casse. SARA vous a donné les outils. Il ne vous a pas donné de plan. Cet article explique pourquoi cette distinction est importante et à quoi ressemble réellement une automatisation complète de l’archivage.

Le scénario : vous devez archiver des documents financiers

Commençons là où tout effort d’archivage commence : par un problème réel.

Votre système SAP fonctionne depuis quelques années. Les tables ACDOCA ont atteint des centaines de millions d’enregistrements. Les performances du système se dégradent au point que vous n’êtes pas certain de pouvoir clôturer l’exercice l’année prochaine, et vous ne pensez pas qu’il y ait un budget pour ajouter de la mémoire ou passer à une taille de T-shirt supérieure. Votre équipe Basis vous indique que la base de données a besoin d’être soulagée.

La réponse, sur laquelle tout le monde s’accorde une fois que l’aging et le tiering ont été identifiés comme des solutions trompeuses, est l’archivage des données. Vous allez archiver FI_DOCUMNT, l’objet d’archivage des documents de comptabilité financière. Il couvre des tables comme BKPF, BSEG, BSAD, BSAK, BSAS et (dans S/4HANA) ACDOCA. C’est l’un des objets d’archivage les plus volumineux de tout système SAP, et il figure généralement parmi les premiers candidats de tout programme d’archivage.

Vous vous connectez donc à SAP, saisissez SARA dans le champ de commande, entrez FI_DOCUMNT comme objet d’archivage et appuyez sur Entrée. L’écran Archive Administration apparaît. Vous êtes prêt à commencer. Mais commencer quoi, exactement ?

Ce que SARA vous affiche réellement

SARA, SAP Archive Administration, est un écran bien structuré. Pour FI_DOCUMNT, il vous présente les éléments suivants :

Les boutons d’action

Write : c’est ici que vous créez et planifiez le job d’écriture. Le programme d’écriture (FI_DOCUMNT_WRI) lit les documents financiers depuis la base de données et les écrit dans des fichiers d’archive. Avant de pouvoir l’exécuter, vous avez besoin d’une variante d’écriture, c’est-à-dire d’un ensemble de critères de sélection indiquant au programme quels documents sélectionner. Pour FI_DOCUMNT, les principaux champs de sélection de clé sont le code société et l’exercice/période fiscale. Vous pouvez également filtrer par type de document, date de comptabilisation et d’autres critères.

Delete : une fois que le job d’écriture a commencé à s’exécuter et a créé le premier fichier d’archive, le programme de suppression (FI_DOCUMNT_DEL) retire de la base de données les enregistrements correspondants. C’est l’étape qui libère réellement de l’espace. Le job de suppression n’accepte pas ses propres critères de sélection. Il opère sur le numéro de session d’archive créé pendant la phase d’écriture.

Store : le job de stockage transfère, de manière optionnelle, les fichiers d’archive vers un référentiel de contenu ou un stockage externe. Selon votre Customising, il peut s’exécuter automatiquement après la phase d’écriture ou être déclenché manuellement.

Post-processing : le programme de post-traitement (FI_DOCUMNT_PST) nettoie les tables d’index secondaire (BSAK, BSAS, BSIS) en supprimant les enregistrements qui ont été marqués pendant la phase de suppression. Il doit s’exécuter directement après la suppression.

Le lien Customising

Via Customising, vous configurez les paramètres spécifiques à l’objet : le nom de fichier logique pour les fichiers d’archive, la taille maximale des fichiers, si les jobs de suppression et de stockage s’exécutent automatiquement ou manuellement, ainsi que le scénario d’archive (supprimer avant stocker, ou stocker avant supprimer). Vous maintenez également une durée minimale de résidence afin de protéger les données qui ne doivent pas être archivées.

Ce que SARA fait bien

Rendons à César ce qui lui appartient : SARA vous offre une vue complète et transparente de l’infrastructure d’archivage pour n’importe quel objet. Vous pouvez voir les programmes, le Customising, les journaux des sessions précédentes et l’état des exécutions en cours. Pour une session d’archivage unique sur un seul objet, il fournit tout ce dont vous avez besoin pour exécuter le processus correctement.

C’est réellement utile. SARA est une interface fiable et bien documentée qui sert les clients SAP depuis des décennies. Le problème n’est pas ce que SARA vous montre. Le problème, c’est tout ce qu’il attend que vous fassiez ensuite, seul, à la main, à chaque fois.

L’écart : SARA est une rampe de lancement, pas un moteur

SARA vous montre les programmes. Il vous donne accès aux boutons. Mais il ne fournit aucune logique pour les exécuter en toute sécurité, dans le bon ordre, à grande échelle et de manière récurrente. C’est là que les lacunes apparaissent, et elles s’amplifient rapidement lorsque vous passez de l’archivage d’un seul objet à l’exécution d’un programme d’archivage à l’échelle de l’entreprise.

Vous devez créer et maintenir chaque variante à la main

Pour archiver FI_DOCUMNT pour le code société 1000, exercices fiscaux 2015–2018, vous créez une variante d’écriture avec ces critères de sélection. Pour le code société 2000, vous en créez une autre. Pour le code société 3000, encore une autre. Si vous avez 40 codes société et souhaitez archiver six exercices fiscaux pour chacun, vous vous retrouvez avec des dizaines de variantes, chacune créée, nommée et maintenue manuellement. Cela ressemble à seulement quelques dizaines de jobs, mais un programme d’archivage complet finit par représenter des dizaines de milliers de jobs. Il s’agit d’un processus d’archivage de données non réversible ; une exécution manuelle n’est donc pas exactement ce que la direction attend, une fois qu’elle a connaissance du processus.

SAP propose bien des variables de variante capables de calculer des dates de manière dynamique, mais cette fonctionnalité atteint rapidement ses limites. L’archivage des documents financiers est généralement piloté par la période fiscale et la durée de résidence, et non par la date du calendrier. Les variables de variante utilisent la date système actuelle comme point de référence, ce qui signifie qu’elles ne peuvent pas générer correctement les critères de sélection pour une exécution d’archivage retardée qui aurait dû avoir lieu il y a des années. La variante doit alors être adaptée manuellement avant de pouvoir être utilisée, une étape fastidieuse et sujette aux erreurs qui annule l’objectif de toute planification mise en place.

Vous n’avez aucun contrôle sur ce qui se passe après le job d’écriture

Une session d’archivage se compose de plusieurs jobs, et certains d’entre eux (le job de stockage et le job de suppression) ne sont pas connus au démarrage de la session. Vous ne savez même pas combien de jobs de suppression doivent s’exécuter. Leur exécution dépend du résultat du job d’écriture. Dans SARA, vous avez deux choix : configurer ces jobs pour qu’ils se lancent automatiquement via l’ADK, ou les planifier manuellement une fois le job d’écriture terminé.

Si vous choisissez le lancement automatique, vous perdez le contrôle du nombre de jobs exécutés simultanément. Ces jobs de suppression, exécutés en parallèle, peuvent surcharger la base de données et provoquer des problèmes de performance pendant les heures de pointe. Si vous choisissez le lancement manuel, vous revenez à l’attente et à la surveillance : vérifier si le job d’écriture est terminé, puis déclencher manuellement la phase suivante. Aucune des deux options n’est satisfaisante. Ce dont vous avez réellement besoin, c’est d’une exécution gouvernée : des jobs lancés selon des règles définies, dans des créneaux définis, avec des limites de traitement concurrent. SARA ne propose pas cela.

L’enchaînement entre objets relève entièrement de votre responsabilité

FI_DOCUMNT est rarement archivé isolément. Un programme d’archivage typique inclut MM_MATBEL (documents de matériel), SD_VBAK (commandes client), IDOC (documents intermédiaires) et potentiellement des dizaines d’autres objets. Certains de ces objets, y compris désormais FI_DOCUMNT, ont des dépendances. Certains objets ILM doivent être traités dans une séquence définie, où la session de l’objet A ne doit démarrer qu’après la fin réussie de la session de l’objet B.

SARA ne dispose d’aucun mécanisme pour gérer ces dépendances. Chaque objet est administré indépendamment. Si l’objet B échoue et que vous ne le remarquez pas, l’objet A s’exécutera soit sur des données obsolètes, soit échouera à son tour lorsqu’il sera planifié. Coordonner la séquence sur 20 ou 30 objets, sur plusieurs codes société, est un exercice d’orchestration manuel qui exige une attention constante. Lorsque le consultant archivage/ILM part ou prend des vacances, tout s’arrête, et le plus souvent ne redémarre jamais.

La reprise après erreur est manuelle

Les sessions d’archivage échouent. Un document est verrouillé par un autre processus. Un job batch expire. Le système redémarre pendant une fenêtre de maintenance. Lorsque cela se produit dans SARA, la session se bloque. L’administrateur doit constater l’échec (en vérifiant les journaux ou l’état des jobs), diagnostiquer la cause, la résoudre et relancer manuellement la phase interrompue.

SAP a publié au fil des ans des notes OSS pour améliorer cela (la note 2520094 fournit des recommandations pour poursuivre des sessions interrompues, la note 2586921 avertit des exécutions précédentes non terminées), mais il s’agit d’aides informatives, pas de mécanismes de reprise automatisés. L’humain reste le gestionnaire d’erreurs. Ces écueils manuels figurent parmi les principales raisons pour lesquelles les projets d’archivage de données SAP peuvent échouer.

Il n’y a aucune prise en compte du moment où l’archivage doit ou ne doit pas s’exécuter

Les jobs d’archivage consomment des ressources système. Exécuter un gros job d’écriture FI_DOCUMNT pendant les heures de pointe dégradera les temps de réponse pour les utilisateurs en ligne. L’exécuter pendant la clôture de fin de mois est pire. La planification des jobs dans SARA est basique : vous choisissez une date et une heure de démarrage. Il n’a aucune notion de calendriers métiers, de fenêtres de maintenance ou de périodes d’interdiction. Aligner les exécutions d’archivage sur ces contraintes est un exercice de coordination manuel entre l’équipe d’archivage, l’équipe Basis et les métiers.

Les gains s’évaporent sans récurrence

C’est la lacune la plus déterminante. Un projet d’archivage initial pour FI_DOCUMNT peut supprimer six années de documents historiques et la compression d’ACDOCA qui suit peut réduire les tables concernées de 30 % ou plus. Des résultats impressionnants. Mais les bases de données SAP augmentent généralement de 15 à 20 % par an. Sans sessions d’archivage régulières et récurrentes, ces gains s’éroderont en 18 mois.

SARA ne fournit aucun mécanisme pour garantir que l’archivage se poursuive une fois l’équipe projet passée à autre chose. Il n’y a ni moteur de récurrence, ni programme planifié de sessions, ni alerte si l’archivage n’a pas été exécuté pendant une période définie. C’est pourquoi tant d’organisations se retrouvent à relancer des projets d’archivage depuis zéro tous les deux ans environ, un cycle coûteux et frustrant que TJC Group a observé à maintes reprises au cours de plus de 25 ans de missions de gestion des volumes de données SAP. Adopter dès le départ les bonnes stratégies d’archivage, notamment en planifiant l’automatisation et la récurrence, est essentiel pour rompre ce cycle.

Principaux points à retenir

SARA est une rampe de lancement, pas un moteur. Il vous montre les programmes d’archivage, le Customising et les journaux. Il ne planifie pas vos sessions, ne génère pas vos variantes, n’enchaîne pas vos objets, ne se remet pas des erreurs et ne garantit pas que l’archivage s’exécutera le mois prochain. Tout ce qui dépasse le fait d’appuyer sur les boutons relève de votre responsabilité.

Le véritable défi n’est pas d’exécuter une session. C’est de maintenir un programme d’archivage. Une exécution unique de FI_DOCUMNT dans SARA est simple. Exécuter 30 objets sur 40 codes société, chaque mois, pendant des années, sans lacunes ni erreurs, est un problème fondamentalement différent. Ce problème exige de l’automatisation.

Les gains d’archivage sont temporaires sans récurrence automatisée. Les bases de données augmentent de 15 à 20 % par an. Un projet d’archivage initial fait gagner du temps ; la récurrence automatisée via ASC rend la réduction permanente.

Si vous gérez l’archivage des données SAP uniquement via SARA, en créant manuellement des variantes, en planifiant manuellement des jobs et en vérifiant manuellement les journaux, vous mobilisez des ressources qualifiées sur un travail qui devrait être automatisé. TJC Group, fort de plus de 25 ans d’expertise en gestion des volumes de données SAP, a conçu l’Archiving Sessions Cockpit pour résoudre précisément ce problème. Contactez-nous pour découvrir à quoi peut ressembler une automatisation complète de l’archivage dans votre environnement.