# DDL1-5 CAS0 Etudes pour le préparation des quartiers de la feuille de route
{{INLINETOC}}
## CAS 1-3-2 Points d’accès sur le réseau longue distance
^ Chantier PCA | DDL1-5 Elaboration de la solution de secours |
^ Phase FdR | Phase B |
^ Quartier FdR | B1 Préparation plate-forme de secours |
^ Origine CAS | Atelier B1-BORDEAUX-SARI Mode opératoire reconfiguration des DAC |
### Objectifs du CAS
Deux points d'accès ont été identifiés:
- l'un pour la filière EDI via la plateforme d'échange POSEIDON
- l'autre pour la filière EFI via la PAS BIANCA et les DAC
En cas de sinistre les deux points d'accès doivent basculer vers les services ouverts sur le site de l'INTEX.
L'étude doit permettre le recensement des adresses qui portent ces points d'accès et des actions à conduire pour permettre leur basculement sur les adresses de l'INTEX.
### Méthodologie
Etude des documents fournis par SI2C:
- Les DEX techniques pour les adresses utilisées en production
- Les dictionnaires pour les adresses utilisées sur la plate forme d'INTEX en substitution de celles de production.
Il manque les DEX de Ref cb/Ref deleg et de GFE
Il manque les dictionnaires des traducteurs et du serveur de routage.
## CAS 7 Recensement des bases à restaurer
^ Chantier PCA | DDL1-5 Elaboration de la solution de secours |
^ Phase FdR | Phase B |
^ Quartier FdR | B6 Restauration composants de la zone agents |
^ Quartier FdR | B7 Restauration composants de la zone usagers |
^ Origine CAS | Atelier A3-SI2C Mode opératoire reconfiguration de la plate-forme d’INTEX |
### Objectifs du CAS
Pour permettre une reprise de l'activité au plus tôt, le principe d'un relance des modules de l'intex bases nues a été proposé.
Cependant cela ne concerne pas toutes les bases car les MA doivent pouvoir récupérer certaines informations (références bancaire, données de validité des habilitations, ...)
### Méthodologie
Etude des UC (UC=CU=Cas d'utilisations) et des activités primaires permettant de :
- recenser les UC les activités primaires qui correspondent aux actions définies dans le cpalier 1 (par exemple pour mire les UC Déclarer la TVA par EFI, Payer la TVA et Payer mes impôts correspondent à ce critère)
- déterminer le chemin critique (l'enchaînement des UC, par exemple pour payer la TVA il faut Accéder à mes services -> Choisir l'OCFI -> Choisir un dossier -> Appeler les services -> Payer la TVA )
- relever les liens entre le CU et les entités en relation (demandes de service [DS] vers une source externe par exemple les références de formulaire dans NREF et NDOC)
# Synthèse
## CAS1-3: Points d’accès sur le réseau longue distance
- Un atelier spécifique **B1-3-2 Mode opératoire modification routage aval POSEIDON** doit être programmé.
- Les ateliers **B1-SI1F Mode opératoire pour l’ouverture des flux** et **BORDEAUX-SARI Mode opératoire reconfiguration des DAC** sont regroupés au sein d'un atelier dont l'objectif est de choisir et de préparer la soltion technique de raccordement à une PAS BIANCA.
SI2C doit nous fournir le DEX technique des traducteurs qui n'était pas dans leur envoi.
## CAS7-1: Restauration composants de la zone agents
Un atelier **B6-1 dérouler les DEX C5\_ sauvegarde\_restauration** doit étudier:
- la récupération du MAS **Gestion Filière EDI** (et des référentiels NREF et NDOC) à jour, afin de restituer la validité des habilitations de ces partenaires EDI à la date du dépôt. |
- la récupération du fichier `connecteur.conf` à jour des partenaires PEDI
- la gestion du séquencement des envois EDI
- le récupération du fichier dictionnaire en adéquation avec la version NDOC/NREF utilisée.
- gestion de la volumétrie des données qui devront être stockées en l'absence d'OSATIS (question déjà arbitrée).
Bien que les référentiels sont écartés de l'étude, la restauration de **REF-CB** et **REF-DELEG** doit être traitée car ils appartiennent à **OPALE** qui n'est pas dans le périmètre du palier 1.
Cet atelier est fortement conditionné par la fourniture par SI2B MEMO d'une procédure permettant d'intégrer le catalogue des sauvegardes de production (atelier **B5-SI2B-MEMO Sauvegardes dans l’environnement d’INTEX**)
Les contributions de SI2C à cet atelier peuvent se faire uniquement sous forme d"écrits, puisqu'il s'agit essentiellement de connaître la fraîcheur des données hébergées.
## CAS7-2: Restauration composants de la zone usagers
Aucun atelier supplémentaire ne semble requis, seules les mentions suivantes doivent être intégrées dans la feuille de route:
- dans le contexte étudié (bases nues et absence d'Adélie) l'activité récupération des données pour affichage du formulaire pré rempli" ne peut aboutir.
- gestion de la volumétrie des données qui devront être stockées en l'absence d'OSATIS (question déjà arbitrée).
## Exemple de méthodologie de sauvegarde restauration
_*Source: [[http://venezia.appli.dgfip/share/page/site/ref-cb/document-details?nodeRef=workspace://SpacesStore/86bbda65-208a-4c2d-8248-b074cc413352|DAAD-ProjetREF_CB_v.04.doc]]*_
### Mécanisme de sauvegarde commun développé dans le cadre de COPERNIC.
```
On en distingue 3 qui ont tous lieu pendant que la base tourne (c’est-à-dire qu’il n’est pas nécessaire
d’arrêter la base):
- La sauvegarde complète (à effectuer automatiquement chaque dimanche): on sauvegarde tout le contenu
de la base.
- La sauvegarde incrémentale cumulative (à effectuer automatiquement chaque nuit): dans un fichier,
on sauvegarde les changements de la base depuis la dernière sauvegarde complète (du dimanche). Par
exemple, le lundi, on sauvegarde dans ce fichier les modifications depuis la sauvegarde hebdomadaire
de la veille; le mardi, on sauvegarde les modifications depuis 2 jours, etc...
- Le fichier RedoLog (géré par Oracle): en permanence, ce fichier mémorise les informations effectuées
dans la journée, c’est-à-dire depuis la sauvegarde quotidienne de la veille.
```
### Stratégie de restauration
```
Si le serveur tombe, il faut tout d’abord recharger la sauvegarde complète hebdomadaire, puis lancer
la dernière sauvegarde quotidienne (incrémentale cumulative) pour restaurer la base dans son état de
la veille au soir. Enfin le fichier RedoLog permet de retrouver la base telle qu’elle était juste
avant que le serveur tombe. Pendant ces opérations de maintenance, l'application est inaccessible
puisque le serveur Oracle ne tourne pas.
```