Wiki

Vous affichez une ancienne révision du document ! Si vous l'enregistrez, vous créerez une nouvelle version avec ce contenu.

====== Relance calculs end ======

===== Objet =====
Cette page décrit comment relancer les calculs END dans les solutions Kerwin et Conext Control.
Il est utile de relancer les calculs lorsque nous constatons une absence de données dans des rapports mensuels.
\\
===== Kerwin =====
==== Principaux Lots ==== 
Ouvrir SQL Management Studio.\\
\\
Exécuter la requête suivante:\\
<WRAP round box 40%>
USE [CALCUL_END]\\
GO\\
DECLARE	@return_value int\\
DECLARE @date1 datetime\\
DECLARE @date2 datetime\\
/*Date de début*/\\
SET @date1 = '15/01/2018 00:00:00'\\

/*Date de fin*/\\
SET @date2 = '19/01/2018 00:00:00'\\

WHILE @date1 < @date2 BEGIN\\

EXEC	@return_value = [dbo].[End_DailyJob] @date1\\
SET @date1 = dateadd(day, 1, @date1)\\

END\\
GO\\

</WRAP>

Lorsque la requête a fini de s'exécuter vous pouvez retourner dans Kerwin, ouvrir le tableaux de bord correspondant et cliquer sur le bouton recalcul.

Pour les sites du Lot 1 et 2, il faut utiliser la base [Cal_END_MIN]
</WRAP>\\

<WRAP center round important 60%>
Pour le site de Caillan - Lot 4, il faut utiliser la base [End_DailyJobCaillian]
</WRAP>\\
\\

<WRAP center round important 60%>
La requête "End_UpdateSynthMonthMn" est utile pour "forcer" l'exécution des calculs dans le cas d'Hi non valide par exemple
</WRAP>

==== Solaire Direct ====
<WRAP center round alert >
Pour les sites de Solar Direct, la procédure est différente : voir ci après.\\
Bien pensez à modifier la date et à choisir les bons sites dans les requêtes.
</WRAP>

A chaque fois que l'on lance la procédure de calcul de l'END, une nouvelle ligne s'ajoute dans le rapport pour la date de calcul.\\
Il peut donc y avoir plusieurs lignes pour la même date dans les rapports.\\
\\ 
Il est donc nécessaire d'effacer dans un premier temps les données pour la date souhaitée avec la procédure suivante : (exemple pour la date du 07/03/2015 et pour le site Les Mees 2)\\

<WRAP round box>
DELETE\\
FROM [KERWIN_SQL].[dbo].[LM2_AlDebutFin] where [Date_debut] >='01/05/2018 00:00:00' and [Date_debut] <= '07/05/2018 23:59:59'\\

DELETE\\
FROM [KERWIN_SQL].[dbo].[LM2_DebFinToJour] where [Date] >='01/05/2018 00:00:00' and [Date] <= '07/05/2018 23:59:59'\\
</WRAP>

Vérifiez que la suppression à la date indiquée a bien été effectuée en remplaçant "DELETE" par "SELECT *" dans la requête précédente : aucune ligne ne doit être présente.\\
Ensuite, vous devez modifier les 2 procédures "**Daily job Run**" et "**Up Alarm**" pour chaque site dans:\\
\\
__Pour les sites de LM1 et LM2:__ **Kerwin_SQL -> Programmability -> Stored Procedures** pour les sites de LM1 et LM2 \\ 
 - LM1/2_DailyJobRun et LM1/2_UpAlarmes\\
\\
__Pour le site de Vinon:__ **Kerwin_SQL -> Programmability -> Stored Procedures** \\
 - AK_VinDallyJobRunTest1 et AK_VinupAlarmes pour Vinon\\
**Pour Vinon, seulement la date @d est nécessaire (pas besoin d'ajouter de Trigramme type 'SAR' en rejouant les calculs)**\\
**Pour Vinon, seule la requête "Up_Alarmes" est à modifier**\\
\\
__Pour les autres sites:__ **CALEND ->  Programmability -> Stored Procedures** pour les autres sites\\
Pour le site de Nohic, c'est les fichiers **NON**.

Sur ces procédures, il faut mettre à "1" (manuel) le paramètre **@DailyJobManualActive** en haut des deux procédures "**Daily job Run**" et "**Up Alarm**":
{{ :tma:pv:rex_ai:rapports:capture33.png?800 |}}
Exécuter ensuite la procédure pour enregistrer la modification.

Ensuite relancez la procédure de calcul de l'END :\\
<WRAP round box 40%>
declare @d datetime\\
set @d = '07/03/2015'\\

exec [KERWIN_SQL].[dbo].[LM2_DailyJobRun] 'LM2',@d\\
</WRAP>
\\
Vérifiez dans le rapport qu'une seule ligne pour chaque jour apparait.
\\

Pour finir, il faut repasser les fichiers précédemment décris en "0" (automatique), n'oubliez pas d’exécuter la procédure pour enregistrer la modification.
\\
<WRAP center round alert 60%>
Attention ,cette dernière étape est important, ça permet aux Jobs SQL journaliers de s’exécuter.
</WRAP>
\\
===== Conext Control ( lot 6 ) =====
Se connecter sur la machine Schneider18 (=ClearScada)\\
  - Le fichier C:\Program Files (x86)\Schneider Electric\Conext Control\PVDBEngine\PVdbConsole\Configurations\Nom_Site\Se.Pv.Controllers.cfg contient la date de la dernière journée valide (normalement la veille). En cas de bug il faut modifier manuellement la date pour passer au jour suivant sinon les données ne sont plus calculées. \\
  - Modifier aussi le fichier C:\Program Files (x86)\Schneider Electric\Conext Control\PVDBEngine\PVdbConsole\Configurations\Nom_Site\Se.Pv.Grafters.Counters.cfg et modifier la 1ère date de chaque ligne.
{{ :tma:rex_ai:rapports:ccv2_controllerscfg.png?600 |}}
\\
<WRAP center round info 60>
Si il manque des données dans une journée la consolidation ne s’effectue pas (la ligne est alors en rouge dans le rapport mensuel). \\
Il faut alors vérifier dans le dossier "Error Files" si il n'y a pas des fichiers à rejouer! (cf.procédure [[tma:pv:rex_ai:rejouer_fichier_cc|Rejouer fichiers sur Conext Control Lot 6]])
</WRAP>
Pour relancer les calculs, aller dans le PVDB engine, stopper tous les process pour éviter des conflits sur le sql (process, stop all). 
\\
\\
{{ :tma:rex_ai:rapports:ccv2_pvdb_process.png?800 |}}
\\
Puis aller dans Data Consolidation, start task et lancer les trois tâches dans l’ordre pour le site concerné, finir par daily job. \\
Vérifier ensuite la date dans le fichier Se.Pv.Controllers.cfg, **elle doit correspondre à la veille.**\\
On peut également valider le recalcul en regardant l'export de données site dans Clearscada ou en lançant la requête de rapport mensuel dans la base SQL.
\\
<WRAP center round important >
Bien penser à relancer les process du PVDB, via Process/Start all, une fois les calculs effectués
</WRAP>

\\
Cas de relance des calculs :\\
•	On était en perte de com au moment du daily job mais depuis les données sont revenues et ont été stockées dans la database.\\
•	Il existe des error file que l’on a intégré dans la base sql. (file, binary file, sélection  puis conversion)\\
•	Sans error file, cela veut dire que l’automate n’était pas alimenté et que l’on n’a aucunes données.\\

{{tag>calcul_END PVDB_engine rapports_mensuels requête_SQL recalcul_entre_2_dates}}

===== Conext Control CESTAS =====

<WRAP center round important 80%>
Il n'y a pas l'outil PVDbEngine sur cette version de Conext Control! L'outil de calcul PvdbConsole est intégré à la solution et fonctionne en tâche de fond
</WRAP>

\\
- sur le serveur ClusterX, ouvrir le fichier c:\Programmes\Schneider Electric\Conext Control\PVdbConsole\Configuration\SPVyyy\**Sc.Pv.GraftersCounters.Cfg.xml**\\
//X = numéro du cluster, yyy = numéro de la SPV//\\
- modifier le paramètre **LastExecutionDtoLocalApp** et mettre la date à partir de laquelle les calculs END devront être refaits\\
- enregistrer le fichier\\
\\
{{ :tma:pv:rex_ai:rapports:grafterscounterss_changeladateici.png?800 |}}\\
-> le calcul des END sera effectué automatiquement par le PvdbConsole en tâche de fond.\\
\\
- sur le serveur ClusterX, ouvrir le fichier c:\Programmes\Schneider Electric\Conext Control\PVdbConsole\Configuration\SPVyyy\**Sc.Pv.Controllers.Cfg.xml**\\
//X = numéro du cluster, yyy = numéro de la SPV//\\
- modifier le paramètre **LastExecutionDtoLocalApp** et mettre la date à partir de laquelle les calculs END devront être refaits\\
- enregistrer le fichier\\
\\
Le job se relancera automatiquement dans la nuit.
{{ :tma:pv:rex_ai:rapports:controllers_changeladateici.png?800 |}}\\
Il est possible de forcer le redémarrage de PVDbConsole en allant, via un clique droit sur la boule ClearScada de la barre de tâche, dans Server Status/General/Modules et relancer le service CCPVScheduler\\
Il est également possible de forcer un DailyJob en tapant les lignes de commande (cf. procédure pour Conext Control Solaire Direct ci-dessous)\\

Remarque : les opérations décrites ci-dessus devront être réalisées pour chaque SPV\\
\\

===== Conext Control Solaire Direct =====

Se connecter à la machine sdsv162 en accès RDP. Ce lot comprend bien un PvdbEngine, mais avec un comportement différent que sur le lot 6.\\

__**Etape 1:**__ Arrêter les process du PvdbEngine --> la solution la plus rapide est de "killer" l'applicatif via le gestionnaire des tâches, puis de relancer l'application **PvdbEngine.exe**\\

{{ :tma:pv:rex_ai:rapports:restart_pvdb.png?200 |}}\\

Vérifier que tous les processus sont bien en stop.\\

**__Etape 2:__** Modifier les fichiers de configuration correspond aux sites concernés, situés dans le dossier PvdbConsole, en modifiant les dates à partir desquelles on veut relancer les calculs:

{{ :tma:pv:rex_ai:rapports:dossier_pvdbconsole.png?700 |}}\\
Le fichier UpdateCounters:\\
{{ :tma:pv:rex_ai:rapports:update.png?700 |}}\\
Le fichier DailyJob:\\
{{ :tma:pv:rex_ai:rapports:dailyjob_file.png?700 |}}

**__Etape 3:__**Une fois que les modifications sont faites pour les dates souhaitées, il faut relancer les commandes de **__UpdateCounters__** (responsable des calculs fait dans la BDD) puis du __**DailyJob**__ (responsable de l'affichage des résultats dans les rapports)\\
Il faut taper dans l'invit de commande les lignes suivantes dans l'ordre:\\
{{ :tma:pv:rex_ai:rapports:updatec.png?600 |}}\\
{{ :tma:pv:rex_ai:rapports:dailyjob.png?600 |}}

<WRAP center round tip 60%>
Modifier le dernier numéro de la ligne de commande selon le site concerné!
</WRAP>

<WRAP center round tip 60%>
Vous pouvez rajouter l'option -f (avec DailyJobBatch uniquement) pour ne lancer le calcul que sur le premier jour.
</WRAP>

<WRAP center round alert 100%>
Ne pas oublier de relancer tous les processus du PvdbEngine une fois la manipulation effectuée!
</WRAP>

===== Exemple de tâches FS =====

Cette partie se propose de citer des tâches FS où l'on a résolu des problèmes d'incohérences dans les rapports après avoir rejoué les données:

SD_CC: FS#1852 (Brignoles)
CESTAS : FS#2250

Résumé

Wiki

Outils pour utilisateurs

Outils du site

Outils de la page