Impact du processus de RDB Refresh sur les données de Capacité des Ressources

Bonjour,

Comme vous le savez, pour forcer la synchronisation des données la base Reporting avec la base Published, nous recommandons souvent de faire une simple manipulation de sauvegarde/restauration de champs personnalisés. Cela produit ce que l’on appelle communément un processus de “RDB Refresh” qui permet la resynchronisation des données projet (tâches, affectations, ressources) mais pas celle des feuille de temps.

Récemment, un utilisateur nous a contacté pour nous faire part d’un problème de perte de données de la capacité des ressources dans son cube OLAP, après avoir eu recours à ce procédé de synchronisation. Dans son cas, il manquait de nombreuses données de capacité dans le passé.

Alors pourquoi cela est arrivé ? A travers cet article, je vais tenter de vous expliquer comment cela fonctionne.

Par défaut, la période définie dans la Capacité des Ressources est de –1/+12 mois :

clip_image001

Cela signifie que dès lors que vous créez un processus planifié (scheduled job)  pour calculer cette capacité, c’est une plage commençant 1 mois avant et se terminant 12 mois après la date de création du processus qui est définie.

MAIS, et c’est là le plus important, cette plage n’est pas effacée et recrée à chaque fois que le processus planifié s’exécute (tous les jours à la même heure). Elle est calculée de –1/+12 mois chaque jour, mais les données passées ne sont pas supprimées.

Prenons un exemple:
Si le processus est créé le 1er janvier 2011, lors de l’exécution de ce processus, les données de capacités visibles s’étendront du 1er décembre 2010 au 1er janvier 2012.
Lorsque le processus va s’exécuter le 2 janvier 2011, les données de capacité s’étendront du 1er décembre 2010 au 2 janvier 2012.

Lorsque le processus va s’exécuter le 1er février 2011, les données de capacité s’étendront du 1er décembre 2010 au 1er février 2012.
et ainsi de suite…

Dans la base Reporting, les données de capacité s’étendent donc régulièrement et on obtient donc les plages suivantes :

clip_image002

Il est donc très important de comprendre que la date la plus ancienne de la plage de capacité est celle qui a été calculée la première fois que le processus planifié s’est exécuté. Il est donc tout à fait normal, après plusieurs mois ou plusieurs années, d’avoir une plage de capacité très importante dans la base de Reporting, et donc, dans le cube OLAP.

Pour connaitre la vraie plage de capacité que contient la base de Reporting, il suffit d’exécuter ce script :

select min(timebyday), max(timebyday) from msp_epmresourcebyday

 

Alors pourquoi le fait de forcer une resynchronisation de la base Reporting fait perdre des données ?

 

La réponse est simple : Le processus de resynchronisation efface toutes les données de la base Reporting. Toutes les données de capacité des ressources sont donc effacées et elles ne seront réapprovisionnées que lorsque le processus planifié sera exécuté de nouveau.

On se retrouve alors dans la même situation que lorsque l’on a défini ce processus la première fois : la plage est calculée à –1/+12 mois par rapport à la date en cours. On perd donc tout l”historique :

clip_image003

 

Que faut-il faire pour retrouver les données perdues ?

 

Il n’est pas possible de retrouver les données qui ont été supprimées.

Par contre, on peut les recalculer à nouveau. Si vous avez perdu un an de données passées, il suffit pour cela d’étendre la plage dans le passé à –12/+12 et d’attendre que le processus planifié effectue son calcul.

Une fois que c’est fait, je vous conseille de revenir aux paramètres par défaut (-1/+12) afin de ne pas surcharger le calcul de la capacité.

 

Voilà, j’espère avoir été assez clair pour vous expliquer ce fonctionnement de Project Server. Si vous avez des questions, n’hésitez pas à les poser via les commentaires.

 

Bonne journée

 

Marc Biarnès