Opérations

Sauvegarde

Présentation

Les données et fichiers de base de données doivent être sauvegardés régulièrement pour préserver la fiabilité des processus et de leurs données associées.

• Il est fortement recommandé de faire la sauvegarde de la base de données et des fichiers en même temps. Pour assurer l'intégrité des données, il est également recommandé d'arrêter les services IIS et de base de données.

• Les procédures suivantes s’appliquent uniquement à MS SQL Server.

Complet (applications et données)

Application et fichiers de données

Sauvegardez le dossier DISQUE:\Inetpub\wwwroot\wfgen.

Si vous avez appliqué le stockage de fichiers, sauvegardez le dossier tel qu’indiqué dans le paramètre ApplicationDataPath dans le fichier web.config.

Base de données

Effectuez une sauvegarde de base de données SQL standard avec les outils fornis avec votre SGBD.

Données seulement

Base de données

Sauvegardez la base de données SQL avec les outils fournis avec votre SGBD.

Fichiers de données

Sauvegardez le dossier DISQUE:\Inetpub\wwwroot\wfgen\App_Data.

Déplacer la base de données WorkflowGen

Base de données du serveur SQL

Prenez les mesures suivantes pour déplacer la base de données du serveur SQL de WorkflowGen d'un serveur à un autre :

1. Arrêtez les services IIS sur le serveur de production.

2. Déconnectez la base de données WorkflowGen.

3. Copiez les fichiers .mdf et .ldf vers le nouvel emplacement.

4. Rattachez le fichier au nouveau serveur de base de données.

5. Mettez à jour la chaîne de caractères de connexion à partir du Panneau de configuration.

6. Redémarrez vos services IIS.

Déplacer l'application WorkflowGen

Prenez les mesures suivantes pour déplacer l'installation de WorkflowGen d'un serveur à un autre :

1. Arrêtez les services IIS sur le serveur de production.

2. Configurez la même version de WorkflowGen sur le nouveau serveur.

3. Copiez le contenu du répertoire DISQUE:\Inetpub\wwwroot\wfgen\App_Data de l'ancien serveur vers le nouveau serveur.

4. Si vous avez créé vos propres formulaires Web, applications SDK ou services Web :

   1. Copiez leurs dossiers dans l'arborescence correspondante du nouveau serveur. Par exemple, si vous avez créé un service Web nommé MonServiceWeb qui est situé dans \wfgen\wfapps\WebServices\MonServiceWeb, vous devrez copier le dossier entier vers le même emplacement sur le nouveau serveur.

   2. Créez l’application IIS avec les mêmes options de sécurité de répertoire sur le nouveau serveur pour les applications que vous avez copiées.

   3. Pour les services Web ou applications SDK, assurez-vous de mettre à jour l'URL de l'application dans le module d'administration.

   4. Pour les formulaires Web, assurez-vous de mettre à jour les données FORM_URL dans la définition des processus pour pointer vers le nouveau lien URL.

   5. Répétez cette démarche pour chaque application personnalisée que vous avez créée.

5. Mettez à jour l'URL de l'application à partir du module de configuration.

Surveillance

Espace de stockage

Données de fichiers

Le seul répertoire à surveiller pour l'espace de stockage est DISQUE:\Inetpub\wwwroot\wfgen\App_Data. Les autres répertoires devraient conserver toujours la même taille puisque tout ce qui est créé dans le temps est stocké dans ce répertoire.

Base de données

Vous pouvez surveiller la taille de la base de données à travers les fichiers .mdf et .ldf si vous utilisez le serveur SQL ou le faire au moyen des outils DBMS.

Les besoins d’espace mémoire peuvent varier dépendamment de l’option choisie pour le stockage de données de processus, notamment l’option de stocker le contenu des fichiers dans la base de données.

Synchronisation des répertoires

Les fichiers journaux de synchronisation des répertoires se trouvent dans le répertoire \wfgen\App_Data\LogFiles\Dir\Synchro. Vous pouvez consulter et gérer l'historique des journaux directement dans le module d’administration de WorkflowGen au lieu de parcourir les fichiers directement.

Services Windows

Les services Windows devraient toujours fonctionner automatiquement lorsque le serveur démarre. Périodiquement, les services Windows effectueront les tâches nécessaires :

• Signaler les exceptions en retard

• Envoyer les notifications d'actions en retard

• Supprimer les délégations inactives

• Supprimer les activités fantômes (des activités initiées mais jamais lancées)

Usage

Requêtes/actions par jour

Un module de statistiques est fourni dans le portail utilisateur pour voir des rapports détaillés sur les requêtes et actions. Il est possible d'appliquer plusieurs filtres aux différents rapports et un service d'organigrammes est aussi fourni.

Taille des fichiers joints

Les fichiers joints qui seront créés pour vos processus en utilisant des formulaires Web seront enregistrés dans le répertoire temporaire DISQUE:\Inetpub\wwwroot\wfgenApp_Data\Files\EFormASPX et seront automatiquement supprimés après 24 heures.

WorkflowGen copie ces fichiers vers une destination permanente. Si l’option de stockage de données des processus est sélectionnée, les fichiers joints seront stockés directement dans la base de données en temps réel. Sinon, ils sont stockés dans le système de fichiers tel que spécifié dans le paramètre ApplicationDataPath (p.ex. : \App_Data\Files\DataSet\runtime).

Si vous savez qu'un processus occupe trop d'espace disque ou trop d’espace dans la base de données dû aux données afférentes, vous pouvez désactiver l'option Archiver les résultats des actions dans la définition du processus. Ceci empêchera la conservation du fichier joint pour chaque action reliée à chaque requête. Seules les données présentes après la dernière action seront conservées sur le disque et dans la base de données.

Maintenance d’OAuth pour le serveur MCP

Lorsque le serveur MCP de WorkflowGen est activé, les inscriptions de clients OAuth, les transactions d’autorisation, les codes d’autorisation, les jetons d’actualisation et les clés de signature sont stockés dans les tables OAUTH_* de la base de données WorkflowGen.

Conservez une valeur stable pour OAuthServerKeyEncryptionKey après l’activation du serveur MCP. Si cette clé est modifiée alors qu’une clé de signature active existe déjà, le serveur MCP pourrait ne plus être en mesure de déchiffrer la clé de signature privée stockée, ce qui pourrait entraîner l’échec de l’émission des jetons.

Si une réinitialisation complète d’OAuth pour le serveur MCP est nécessaire, planifiez-la comme une opération de maintenance effectuée avec l’aide du service de soutien. La réinitialisation des inscriptions de clients OAuth, des jetons et des clés de signature peut forcer les clients MCP à se reconnecter.

Opérations relatives aux événements de modification

Conservation et sauvegarde de la clé

La clé d’intégrité est requise pour l’ajout d’événements, la vérification de l’intégrité et la rétention authentifiée. Stockez-la dans le gestionnaire de secrets approuvé du déploiement et conservez-en une copie protégée récupérable séparément des accès ordinaires à la base de données. Une sauvegarde de la base de données sans la clé d’origine ne permet pas de disposer d’une chaîne d’événements de modification vérifiable ni de poursuivre cette chaîne.

• Ne collez jamais la clé dans un ticket, un journal, une capture d’écran, un exemple de procédure opérationnelle ou un dépôt de documentation.

• Ne générez pas de clé de remplacement après le premier événement protégé.

• Il n’existe actuellement aucune procédure supportée de rotation ou de réinitialisation.

Vérification de l’activation des événements de modification

Après avoir configuré la clé et redémarré ou redéployé chaque instance Web et chaque instance du service du moteur concernée, procédez comme suit :

1. Confirmez que le mode activé prévu est actif : Standard pour une première activation, ou le mode Standard ou Complet conservé après une mise à jour.

2. Créez une catégorie de test temporaire et renommez-la.

3. Ouvrez les événements de modification dans le module d’administration et confirmez que les événements correspondants s’affichent avec l’utilisateur, l’élément et les valeurs précédentes/nouvelles attendus.

4. Supprimez la catégorie de test et confirmez que l’événement de suppression correspondant s’affiche.

5. Cliquez sur Intégrité, puis sur Vérifier l’intégrité dans le panneau État de l’intégrité, et confirmez que le résultat est Valide.

Si l’une de ces étapes échoue, rétablissez le mode sur Désactivé et suivez les instructions de la section Récupération ci-dessous avant de tenter une nouvelle activation. Ne réduisez pas la période de rétention en production pour tester la suppression.

Vérification de l’intégrité

Vous devez effectuer une vérification explicite après l’activation initiale, après la restauration d’une base de données ou d’une clé, après une mise à niveau de version, ainsi que chaque fois que l’état de préparation de l’intégrité ou l’état du rapport enregistré est dégradé ou obsolète. Un résultat Valide authentifie la chaîne protégée conservée jusqu’à l’instantané de vérification. Les nouveaux événements ajoutés après cet instantané rendent le rapport obsolète et nécessitent une nouvelle vérification lorsqu’une preuve à jour est requise.

Récupération

Situation	Réponse
L’activation du mode Standard ou Complet est refusée	Laissez le mode sur Désactivé. Vérifiez le format de la clé, la migration de la base de données, le fournisseur, les permissions d’exécution et l’état d’intégrité. Ne forcez pas l’activation en modifiant les lignes internes de la base de données.
Un nœud possède une clé incorrecte ou aucune clé	Restaurez exactement la clé d’origine sur chaque nœud concerné, recyclez ou redémarrez les instances, puis exécutez une vérification de l’intégrité. Ne créez pas de clé de remplacement.
L’accès normal au module d’administration est bloqué	Si nécessaire, définissez le mode sur Désactivé dans le panneau Configuration. Cela rétablit l’accès aux autres pages, mais masque les événements de modification et ne répare pas la chaîne.
La clé est perdue ou indisponible	Définissez le mode sur Désactivé, conservez la base de données et restaurez exactement la clé à partir de la sauvegarde protégée. Une fois tous les nœuds corrigés, suspendez le trafic, activez le mode prévu et vérifiez immédiatement l’intégrité. Si aucune sauvegarde fiable n’est disponible, communiquez avec le soutien technique.
La clé est soupçonnée d’avoir été compromise ou divulguée	Définissez le mode sur Désactivé, conservez la base de données et les éléments de preuve, limitez l’accès à la base de données et au secret, puis communiquez avec le soutien technique. La version actuelle ne dispose d’aucune procédure supportée de rotation ou de réinitialisation. Continuer à utiliser la clé divulguée ne corrige pas la compromission.
La vérification de l’intégrité échoue	Conservez d’abord une copie de la base de données. Utilisez l’historique de diagnostic disponible uniquement comme preuve non vérifiée. Ne modifiez pas manuellement les hachages des événements, les lignes d’en-tête, les points de contrôle ni les lignes d’événement.
La migration ou les permissions ont échoué	Arrêtez le trafic de l’application, corrigez les permissions normales ou réexécutez en toute sécurité le script fourni, puis réessayez pendant que le mode demeure défini sur Désactivé.
La rétention a déjà supprimé des enregistrements	Seule une sauvegarde externe de la base de données peut récupérer les charges utiles supprimées. Le point de contrôle ne peut pas les reconstruire.

📌 Exemple de récupération d’une clé

Si un nœud démarre avec une clé manquante ou différente, définissez le mode de capture sur Désactivé, restaurez exactement la clé d’origine sur ce nœud et sur toutes les autres instances concernées, recyclez ou redémarrez le déploiement, rétablissez le mode prévu pendant que le trafic est suspendu, puis exécutez une vérification de l’intégrité. La génération d’une clé de remplacement ne permet pas de récupérer la chaîne existante.