I.2. Définition des Tâches - ERP Silog

Owned by Hugues Dubuisson
Last updated: Oct 31, 2024
24 min read

Sommaire :

1. Introduction

C’est cette application qui est chargée d’exécuter l’intégration des données en utilisant les macro commandes. 

Lorsqu’elle est utilisée hors du contexte EDI :

Cette application peut fonctionner de façon autonome. Elle peut prendre en charge l’intégration de données dans l’ERP à partir de données sources alimentées dans des tables si ces sources ont une structure compatible avec les tables destinations. Elle peut aussi être utilisée comme automate de traitement pour lancer des traitements de l’ERP. Elle est pilotable en ligne de commandes, il est possible de piloter l’exécution des tâches dans un planificateur de traitement.

Lorsqu’elle est utilisée en EDI :

Chaque message EDI doit être associé à une tâche (job) pour être exécuté.  

 La tâche permet :

 En Emission :

  • Gérer des traitements SQL avant et après la tâche d’exécution du message.

  • Exécuter des fichiers d‘extension « CMD » avant et après la tâche d’exécution.

  • Générer le fichier.

  • Imprimer les rapports d’exécution.

  • Envoyer les notifications des rapports d’exécution par mail en pièce jointe.

 En Intégration :

  • Gérer la séquence d’intégration des données dans les applications (Corps de l’application).

  • Gérer des traitement SQL avant et après intégration pour chaque application concernée.

  • Gérer des traitements SQL avant et après toute la tâche d’exécution.

  • Exécuter des fichiers d‘extension « CMD » avant et après la tâche d’exécution.

  • Exécuter la tâche d’intégration.

  • Imprimer les rapports d’exécution.

  • Envoyer les notifications des rapports d’exécution par mail en pièce jointe.

2. L’entête de l’application « Définition des tâches »

L’entête de l’application « Définition des tâches » en mode Liste
L’entête de l’application « Définition des tâches » en mode Page

2.1. Le masque des clés

Code tâche : Une tâche est définie par un code tâche à saisir dans le masque des clés.

Tache standard : Tâche livrées et maintenue par Silog. Ces tâches ne sont pas modifiables.

 Ci-dessous, un extrait de la liste des tâches livrées en standard.

2.2. L’onglet « Général » 

  • Code message : Saisir ou Importer le code du message EDI concerné si la tache concerne un message EDI.

  • Actif : Pour activer ou désactiver la tâche.

  • Description : Saisir une description pour la tâche.

  • Cmd avant/après : Ces zones permettent de saisir le chemin et le nom de fichiers d’extension « cmd » (équivalent des fichiers « bat ») pour qu’ils s’exécutent avant et/ou après l’éxécution de la tâche. C’est facultatif, cela peut servir pour renommer, déplacer des fichiers ou des répertoires avant et/ou après l’éxécution de la tâche.

  • Requête présélection (Emission uniquement) : Saisir la requête de présélection des données si nécessaire, elle annule et remplace la requête de présélection du message EDI si elle existe.

  • SQL avant/SQL après : Même principe que pour le message EDI, ces blocs sont prioritaires sur les blocs du message EDI s’ils sont renseignés. Par exemple, le bloc « SQL Avant » des messages de type intégration peut servir à mettre à jour le champ « DesactiverAction » des tables temporaires.

Dans le cas d’un fonctionnement autonome sans message EDI :

Le SQL avant peut être utilisé pour alimenter les tables sources des données. Par défaut les tables sources sont les tables «  #NOMTableDestination ». Si vous souhaitez alimenter COME, la source est « #COME » puis « COMC », la source est #COMC.

Exemple : La tâche « CDE_RETOUR ».

Dans cet exemple, suite à la création d’un retour client avec échange, le système peut générer une commande client d’échange après validation du retour. Cette création est gérée par une tâche.

Les tables #COME et #COMC sont alimentées avec les données de l’échange , il s’agit des tables temporaires de sources de données.

declare @NoCommande VARCHAR(30),@CodeClient VARCHAR(30),@ModeGestion VARCHAR(30)='',@BonRetour VARCHAR(30) ,@Option_ch VARCHAR(MAX) declare @GestionDevise int=0 select @ModeGestion=GrilleOuTarif , @GestionDevise=GestionDevises from paramg where NumeroFiche=1 set @Option_ch=@Option$ while @Option_ch<>'' begin select @BonRetour=dbo.GetColValue(@Option_ch,';',1) select @CodeClient=dbo.GetColValue(@BonRetour,'|',1) ,@NoCommande =dbo.GetColValue(@BonRetour,'|',2) insert into #COME(CodeClient,NoCommande,EcoParticipation,Confirmee) select @CodeClient, @NoCommande ,'N','O' insert into #COMC(CodeClient,NoCommande,NoLigneCommande , CodeArticleprestto,QuantiteCommandee,PrixUnitEnFrancs,PrixUnitEnDevise,PrixNetON,PrixSaisiCalc,CodeCentrePayeur) select CodeClient,NoBonRetour,1,CodeArticle,QteRetournee ,case when @GestionDevise<>3 THEN 0 ELSE NULL END ,case when @GestionDevise= 3 THEN 0 ELSE NULL END ,case when @ModeGestion='T' THEN 'O' ELSE NULL END ,case when @ModeGestion='T' THEN 'S' ELSE NULL END ,BDEC.CodeCentrePayeur from RETOURCLIE LEFT JOIN BDEC on BDEC.NoBonExpedito=RETOURCLIE.NoBonExpedito AND BDEC.NoLigne=RETOURCLIE.NoLigne AND BDEC.NoAccuseRecepto=RETOURCLIE.NoAccuseRecepto AND BDEC.CodeArticleprestto=RETOURCLIE.CodeArticle AND case when BDEC.CodeLot = '*' then '' else BDEC.CodeLot end= case when RETOURCLIE.CodeLot='*' then '' else RETOURCLIE.CodeLot END where NoBonRetour=@NoCommande select @Option_ch=SUBSTRING(@Option_ch,len(@BonRetour)+2,len(@Option$)) END

Les structures des données à intégrer des tables sources sont compatibles avec les tables destinations (inutile d’alimenter tous les champs de la table cible), les noms des colonnes matchent. L’intégration des données effectue le mappage automatique, et alimente les données dans la destination.

Remarque :

Sans utiliser les tables « # », en standard Silog livre également des tables permanentes dédiées à l’intégration des tâches. Ces tables portent le même nom que les tables standards de Silog précédées du suffixe « SIL_JOB_ », la structure est compatible avec la structure des tables de destination. Ces tables sont utilisées pour intégrer les données de la nouvelle mobilité Silog.

Ces tables peuvent être utilisées comme source de données. Dans ce cas il faut déclarer dans le corps de la tâche les tables sources utilisées pour l’entête et le corps des applications concernées.

Ces tables contiennent des champs supplémentaires qui peuvent être gérés dans les groupes SQL avant et après.

Par exemple pour l’intégration des Articles depuis la table SIL_JOB_ARTICLE : il est possible, entre autres, de gérer le flag d’intégration des données et l’idEvent de la tâche d’intégration, pour assurer une traçabilité.

Exemple pour Articles :

SQL avant

UPDATE SIL_JOB_ARTICLE SET IdEvent=@EDI_EVENTE.IdEvent WHERE Flag=0 AND IdEvent IS NULL 

Pour bien comprendre, il est possible de consulter des exemples de tâches qui utilisent ces tables dans votre base de données..

  • Répertoire, fichier et extension (Intégration uniquement de messages EDI) : Saisir le chemin complet des fichiers à intégrer avec l’extension si la tâche intègre les données avec des fichiers comme sources de données.

Par exemple :

  • Pour intégrer tous les fichiers csv commençant par « cde » d’un répertoire :

  • Pour intégrer tous les fichiers « txt » d’un répertoire quel que soit le nom.

  • Nombre de fichiers (Intégration uniquement de messages EDI) : Pour ne traiter qu’un certain nombre de fichiers par tâche d’intégration.

  • Taille des fichiers Ko (Intégration uniquement de messages EDI) : Pour ne traiter que les fichiers qui ne dépassent pas la taille saisie en Ko.

  • Option feuille excel (Intégration uniquement de messages EDI) : Lorsque la tâche d’intégration concerne un fichier xls, saisir les noms des feuilles à intégrer séparés par des virgules, par défaut toutes les feuilles sont traitées.

  • Répertoire d’export (Emission uniquement de messages EDI) : Saisir le chemin complet des fichiers à émettre.

Exemple :

  • Répertoire (Emission uniquement de messages EDI),

  • Exemple  ftp: Il s’agit d’un répertoire présent sur un site ftp. Si cette zone est alimentée, alors les fichiers émis ou intégrés sont déplacés dans ce répertoire.

Pour le sftp remplacer ftp par sftp.

La syntaxe doit être la suivante :

Dans l’exemple suivant :

ftp : A saisir au début de la chaine de caractères.

hugd01 => Code utilisateur, saisir le code utilisateur qui a les droits en lecture/écriture dans le répertoire ftp.

/tmp/In => /dossier[/sousdossier], c’est le chemin complet du dossier de destination.

@  => Pour indiquer le début du nom du serveur ftp.

ftp.silog.net => C’est le nom du serveur ftp, dans l’exemple ftp.silog.net.

[ => Pour indiquer que la chaine de caractères suivante correspond au mot de passe utilisateur.

sfsfsfsfvvvrr# => Saisir le mot de passe de connexion au site ftp de l’utilisateur (ce mot de passe ne doit pas contenir le caractère suivant « ] »)

] => Pour indiquer la fin de la chaine de caractères correspondant au mot de passe.

Remarque : Il est possible de saisir une adresse URL d’un fichier à télécharger. Ce fichier sera téléchargé dans le répertoire renseigné dans la tâche.

Dans cette version seuls les fichiers au format XML sont pris en charge lorsqu’ils proviennent d’une adresse de type URL.

 Voir l’exemple de la tâche EDI standard dans votre ERP qui permet de mettre à jour les cours des devises nommé : SIL_IMPORT_TAUX_BCE.

  •  Répertoire d’archives : Saisir le chemin du répertoire d’archives.

Exemple :

  • Dans le cas des messages de type intégration, le listage du bas permet de visualiser le corps de la tâche avec l’ordre dans lequel les applications seront traitées par macro-commande dans la tâche. Cet ordre est modifiable.

Les boutons Magnétoscope “haut” et “bas”  permettent de modifier l’ordre de traitement de l’application sélectionnée dans le listage en faisant monter ou descendre la ligne concernée.

Dans l’exemple ci-dessus, il faut d’abord traiter l’intégration des familles avant d’intégrer les articles.

L’ordre doit donc être le suivant :

Ordre 1 => Application « Famille ».

Ordre 2 => Application « Article ».

  • Le menu contextuel de ce listage

    • Il est possible d’ouvrir le corps pour modifier/Créer une enregistrement dans le corps.

    • Depuis la version 2024.Q4, il est possible d’exécuter la tâche de la ligne sélectionnée ou d’exécuter toutes les tâches jusque la ligne sélectionnée en mode trace ou non.

2.3. L’onglet « Editions »

Cet onglet permet d’associer les éditions à la tâches en cours. il s’agit d’une application en mode container.

Pour créer/modifier ou supprimer une association, il faut utiliser la barre d’outils suivante comme toutes les applications placées en mode container. 

Code tâche : Code tâche en cours, zone alimentée automatiquement.

Code état : Importer l’édition concernée : 

Quatre éditions sont proposées en standard :

 1 : EDI_EVENT-D.rpt : Compte-rendu détaillé. Ce rapport présente le contenu détaillé du rapport d’émission ou d’intégration du message.

2 : EDI_EVENT-E.rpt : Compte-rendu Erreur. Ce rapport présente les erreurs rencontrées lors de l’exécution du message d’intégration ou d’émission.

3 : EDI_EVENT-M.rpt : Compte-rendu macro. Ce rapport présente le détail de la réalisation des macros commandes en intégration.

4 : EDI_EVENT-S.rpt : Compte-rendu de création, modification ou suppression en intégration.

Nom de l’état : Par défaut, c’est le nom de l’état déclaré dans le paramétrage des états. Le nom est modifiable.

Actif : Pour rendre actif ou non l’édition concernée dans la tâche en cours.

Description : Non utilisé dans cette version..

Automatique : Pour lancer l’impression automatique de l’état à l’issu du traitement de la tâche.

La liste des éditions associées à la tâche en cours est visible en selectionnant le bouton .

2.4. L’onglet « Notification » 

Cet onglet permet de définir si nécessaire la liste des éditions à notifier par mail (envoyées en pièces jointes). Il s’agit d’une application en mode container.

Le principe de saisie est donc similaire à celui de l’onglet précédent. Seuls les états associés à la tâche dans l’onglet « Editions » sont disponibles pour les notifications.

Les notifications utilisent les serveurs et les modèles d’envoi de mails du module optionnel « C9_Envoyer des courriels », il faut donc disposer de ce module pour disposer des notifications.

Dans l’entête, sont définis les zones suivantes :

  • Un « Code notification » à saisir.

  • Une « Description ».

  • Un « Modèle de mail » enregistré dans l’application « Modèles de mail ».

 

  • « Actif » pour activer ou désactiver la notification.

  • « Fichiers traités en pièce jointe » : Pour envoyer en piece jointe le fichier traité avec les rapports.

  • « Envoyé si echec » : Pour ne traiter la notification que dans la mesure où la tâche a retourner une erreur.

  • « Envoyé les enregistrements en erreur en PJ » : Pour envoyer les enregistrements en erreur dans une pièce jointe.

 Il est donc possible de définir des notifications différentes suivant les destinataires concernés.

 Dans le corps, sont définis ( le corps est accessible via le bouton  ) :

La liste et le format des éditions à mettre en pièces jointes de chaque notification.

Mode Liste :

Mode Page :

  • Code état : Sélectionner l’état associé à la tâche comme édition de la tâche.

  • Format de l’état : Sélectionner le format du rapport désiré dans la notification.

  • Options : Non utilisé dans cette version.

 Dans le bas de l’onglet l’application « Modeles de mail » permet de créer ou modifier un modèle de mail si vous disposez du module optionnel « C9_Envoyer des courriels »,

2.5. L’onglet «Journal des évènements » 

Voir Journal des évènements

2.6. L’onglet « Paramétrage de la tâche »

Cet onglet est basé sur le même principe que l’onglet  « Paramétrage du traitement » du corps de l’application.

Y sont visualisés les fichiers évènements traités avant et après le traitement.

 Dans l’éxemple ci-dessus avant de lancer le traitement :

« DébutJob.evt » et après le traitement  « FinJob.evt ».            

 

Pour les traitements déclarés dans le corps de l’application, il est possible de saisir :

  • Des conditions pour les éditions dans un fichier « ConditionEdition.evt ».

  • Des conditions pour les notifications dans un fichier « FinJob.evt ».

3. Le corps de l’application « Définition des tâches »

Le corps de l’application permet de déclarer dans chaque enregistrement, les applications qui doivent être traitées en macro-commande et leurs priorités dans la tâche (numéro d’ordre dans le traitement).

Chaque application déclarée dans le corps de la tâche sera ouverte et fermée en macro-commande en exécutant au minimum les actions suivantes :

Par exemple, pour l’application « Article »

Si un message EDI est associé ou s’il existe des données dans les tables sources ou les tables associées aux segments concernés du message, alors les données seront traitées et intégrées en macro commandes en passant par les points d’entrées SQL, les contrôles personnalisés et les fichiers évènements.

3.1. L’onglet « Général »

L’enregistrement du corps de l’application contient les zones suivantes :

  • Un code traitement à saisir,

  • Un numéro d’ordre pour définir l’ordre de passage de l’application dans la tâche.

  • Actif : Pour activer ou désactiver le traitement de l’application concerné par la macro-commande.

  • Description :  Pour saisir une description.

  • SQL avant/après :

 

Dans le cas de l’EDI :

Pour saisir un traitement SQL qui doit s’exécuter avant et/ou après de traiter l’application concernée en macro-commande.

  • Suppression des enregistrements de la table source après traitement : Pour supprimer les enregistrements traités de la table source. Les enregistrements qui ont comme valeur du Flag -1 restent dans la table source.

  • Insérer une ligne dans le log si l’enregistrement est validé : Pour ajouter une ligne dans le rapport du traitement pour chaque enregistrement validé.

  • Table entête/Table corps (intégration uniquement) : Si les tables sources ne doivent pas être celles que le traitement gère en standard (tables temporaires créées automatiquement « # ») dans les messages EDI, par exemple, saisir le nom des tables ou des vues d’entête et de corps sources de données concernées par l’application en cours. Pour une intégration, le nom des champs sources et destinations doivent être les mêmes, et la structure des données doit être compatible.

  

 

  • Lien table entête et corps (C.NomChamp=E.NomChamp) en intégration uniquement : Si les deux champs précédents sont renseignés, saisir en langage SQL le lien entre les deux tables d’entête et de corps.

 

  • Les actions (uniquement pour les intégrations).

Elles permettent de définir pour l’application traitée ce que la tâche doit faire pour l’en-tête et le corps de l’application :

Création : Si le traitement doit procéder aux créations.

Suppression et création : Si le traitement doit procéder aux suppressions des enregistrements existants avant de les recréer.

Modification : Si le traitement doit effectuer des modifications sur les enregistrements qui existent. Cette action ne peut être sélectionnée si l’action précédente est aussi sélectionnée.

Suppression :  Pour supprimer les données présentes dans la table source.

Affectation auto clés : Pour que le système génère automatiquement le script macro d’écriture des clés.

Affectation auto data : Pour que le système génère automatiquement le script macro d’écriture des données non clés.

  •  Répertoire config.

Il s’agit du répertoire où se trouvent les fichiers événements de l’application en cours pour la tâche en cours. Par défaut ces fichiers se trouvent dans le répertoire « \PARAMETRAGES\EDI » de Silog.

Si cette zone est alimentée, le traitement travaillera dans ce répertoire en priorité.

Si la zone « Utiliser exclusivement ce répertoire » est cochée, la priorité devient une exclusivité, aucun autre répertoire ne sera consulté. Si une tâche standard est dupliquée ce répertoire est vide, il faut définir le chemin de la configuration pour la tâche dupliquée.

  •  Table complémentaire

 Ce listage permet d’associer à l’application sélectionnée des tables supplémentaires qui ne sont pas les tables d’entête et de corps de l’application.

Les tables déclarées dans ce listage sont adressables dans les fichiers événements via la syntaxe suivante :

#NomTable ou #NomTable_NomApplication

Dans notre exemple :

#PARACALC ou #PARACALC_FAMILLE

3.2. L’onglet « Paramétrage du traitement »

Dans cet onglet, sont visualisés les fichiers évènements traités par la tâche. La colonne « Fichier » permet de visualiser la localisation des fichiers utilisés.

Dans l’exemple ci-dessus, un fichier est utilisé :

AppresMOApp.evt : Il correspond au script traité par la macrocommande après ouverture de l’application.

 Le menu contextuel permet d’ouvrir le fichier evt, avec l’application de Windows associée par défaut  à l’extension « .evt » de ces fichiers.

Par exemple : via le bloc note, ouverture du fichier « ParamApp.evt »

Voir le paragraphe « Les fichiers évènement » pour bien comprendre la notion de fichiers évènements.

Le menu contextuel permet de mettre à jour le listage des fichiers évènement via la fonction « Charger ».

A utiliser après avoir déposé un fichier, pour réactualiser les données. 

3.3. L’onglet « Paramètres d’exécution des tâches »

Cet onglet permet la saisie des noms de paramètres ainsi que des valeurs associées pour l’exécution du traitement lorsque celui-ci a besoin de données en paramètres. Il s’agit d’une application en mode conteneur avec toutes les fonctionnalités habituelles d’une application standard.

 En entête, une gestion d’indice, il s’agit d’un numéro de cycle de traitement qui porte dans son corps les paramètres du traitement ainsi que les valeurs associées au cycle et à la tâche.

Dans l’entête :

Un indice numérique permet d’identifier un ensemble de paramètres (un cycle de traitement) avec ses valeurs associées pour le traitement en cours. Il est possible de définir, une période de validité. 

Cela permet de définir une saisonnalité dans les traitements.

Si la tâche est gérée dans un planificateur de tâches, cet indice ne sera pas traité s’il est lancé à une date n’appartenant pas cette plage de validité.

 La description permet de saisir précisément ce que fait le traitement. 

Lorsque la période de validité n’est pas saisie, le traitement est effectué à chaque exécution, il est considéré comme valide.

S’il s’agit d’une tâche livrée en standard, les indices sont gérés par le système, il n’est donc pas possible de créer un nouvel indice manuellement et définir de nouveaux paramètres.

Dans le cas où vous souhaiteriez modifier le standard, nous vous invitons à dupliquer la tâche.

Seule la duplication d’un indice est permise lorsqu’il s’agit d’une tâche standard pour définir un ou plusieurs cycles de traitement avec des valeurs différentes de paramèttres et potentielement une période de validité différente.

La duplication d’un indice est gérée par un traitement nommé «  Dupliquer les paramètres »

Dans ce cas l’indice sélectionné et son corps sont dupliqués. Un nouvel indice « 2 » est généré. Il permet de définir un deuxième cycle de traitement avec des valeurs de paramètres différentes. 

Dans le corps :

La liste des paramètres et des valeurs de paramètres associés à l’indice et à la tâche en cours.

Le listage « Liste des paramètres » permet d’accéder directement aux données du corps.

Cas d’une tâche non standard Silog :

Le menu contextuel permet de modifier, créer ou supprimer des paramètres.

 Cas d’une tâche standard Silog :

Le menu contextuel permet de modifier la valeur des paramètres. Il ne permet pas la suppression où la création.

Masque de modification de la valeur des paramètres (accessible via un double-clic).

La suppression d’un paramètre livré en standard est interdite.

De même, la création d’un nouveau paramètre est interdite dans une tâche Silog standard.

Détaillons un exemple de traitement qui necessiterait deux cycles de traitement (2 indices).

Cas concret : Exécuter, le traitement de mise à jour du coût standard une fois pour valoriser les produits fini au PMP et une autre fois pour valoriser les Matières Premières au DPA.

Le traitement de mise à jour du coût standard livré dans une tâche standard à partir de la version 10.10 attend 7 paramètres :

 Ci-dessous, on peut voir que tous les paramètres du traitement sont pris en charge par la tâche .

Dans l’exemple ci-dessous : Le traitement d’indice 1 (Cycle 1) valorise les produits fabriqués au PMP (O), il ne valorise ni les Matières Premières ni la Sous-traitance (N).

La duplication des paramètres permet d’ajouter un deuxième cycle (indice 2) de traitement pour permettre de gérer aussi la mise à jour des matières premières au DPA :

Il suffit de définir les valeurs des paramètres pour la valorisation des matières premières au DPA dans le cycle 2 (indice 2).

La désignation des différents paramètres contient de façon explicite les valeurs possibles pour les paramètres dans les tâches standards. 

Exemple :

Valorisation des Matières première => O = OUI  ou N =NON

PMP ou DPA => DPA pour valoriser au DPA, PMP pour valoriser au PMP

Un double clic sur un paramètre permet de modifier la valeur du paramètre. 

Après modification des différentes valeurs : Le cycle 2 permet d’éxécuter le traitement de mises à jour des matières premières pour la période saisie.

 L’exécution de la tâche exécute le traitement deux fois, un traitement par cycle si les périodes de validités le permettent. 

 La suppression d’un indice est possible via le traitement « Supprimer les paramètres ».

La liste des indices supprimables est affichée. Lorsqu’il s’agit d’une tâche standard Silog, le cycle d’indice 1 ne peut pas être supprimé, car il s’agit du standard livré

4. Les traitements

L’entête :

Le corps :

4.1. Exécuter la tâche (ou le traitement) \ Exécuter la tâche (ou le traitement) en mode trace

Ces traitements permettent d’exécuter manuellement la tâche d’intégration ou d’émission en cours.

Le premier exécute la tâche sans alimenter le journal, le deuxième alimente le journal.

En intégration : Un listage de présélection permet de sélectionner le ou les fichiers à traiter si un code message est associé à la tâche.

Le listage présente tous les fichiers présents dans le répertoire source renseigné dans la tâche.

A l’issue du traitement, le journal d’intégration ou d’émission est présenté, les éditions activées sont imprimées, les notifications sont envoyées et les messages sans erreur sont archivés dans le répertoire « EDI_CONFIG\ARCHIVES ».

Les messages qui présentent des erreurs sont archivés dans un sous répertoire « Erreur » du répertoire « EDI_CONFIG\ARCHIVES ».

Pour les messages en erreur, si vous souhaitez les retraiter, il faudra les déplacer  manuellemnet dans le répertoire suivant : « EDI_CONFIG\TMP\INBOX\CodeDuMessage » du répertoire d’installation de Silog ou dans le répertoire source associée à la tâche.

Des filtres sont saisissables sur les colonnes suivantes :

  • Niveau : Saisir -1 pour tout afficher.

  • TypeInfo : Laisser le champ vide pour tout afficher.

  •  Si le journal est alimenté, il apparaît en fin de traitement :

  • L’onglet « Fichiers » permet de visualiser la liste des fichiers traités.

  • En émission : Si une requête de sélection est renseignée dans le message. Le listage de sélection des données à filtrer apparaît. Il faut sélectionner les données à traiter et valider.

  • L’onglet « Fichiers » permet de visualiser la liste des fichiers émis.

Voir l’application « Journal des évènements ».

4.2. Publier une tâche

Ce traitement permet de générer un fichier XML contenant la tâche en cours. Le but de cette action est de permettre d’installer la tâche sur une autre base de données Silog.

Le fichier généré se trouve dans le répertoire « EDI_CONFIG\SetUp\TACHE » de l’ERP Silog. Il porte le nom de la tâche.

Exemple :

4.3. Publier toutes les tâches

Ce traitement permet de générer un fichier XML par tâche. Le but de cette action est de permettre d’installer toutes les tâches sur une autre base de données Silog.

Les fichiers générés se trouvent dans le répertoire « EDI_CONFIG\SetUp\TACHE » de l’ERP Silog.

Exemple :

4.4. Publication directe sur une base (à partir de la version 2024.Q4)

Ce traitement permet de publier la tâche en cours ou toutes les tâches directement sur une base de données.

 

Pour publier une ou toutes les tâches sur une base de données présentes sur le même serveur SQL.

  • Toutes les tâches/Tâche en cours : Pour publier la tâche en cours ou toutes les tâches directement sur une autre base de données.

  • Serveur : Nom et instance du serveur SQL cible.

  • Base : Nom de la base de données Cible.

 

Pour restaurer un backup avant d’y publier une ou toutes les tâches sur une base de données présentes sur le même serveur SQL.

  • Toutes les tâches/Tâche en cours : Pour publier la tâche en cours ou toutes les tâches directement sur une autre base de données.

  • Cocher “Restaurer un .bak avant publication” : Pour restaurer une base de données sur laquelle les tâches seront créées.

  • Cocher “Mise à jour des bases après restauration” : Pour mettre à jour la base de données restaurée dans la même version que la source (fortement conseillé en cas de restauration).

  • Serveur : Nom et instance du serveur SQL cible.

  • Base : Nom de la base de données cible.

  • Backup à restaurer : Chemin et nom du backup à restaurer si la restauration est demandée. Par défaut, c’est le chemin enregistré dans le Traitement “Paramètre” et le nom du backup de la tâche en cours. La valeur est modifiable.

4.5. Installer une tâche

Ce traitement permet d’installer une tâche qui a été publiée dans un fichier XML par un des traitements précédent.

La fenêtre suivante permet de sélectionner le fichier à importer.

Valider. Si une tâche de même code existe, le message suivant apparaît, l’intégration n’est pas possible.

4.6. Epurer le journal des évènements

Sélectionner la tâche concernée et jusqu’à quelle date épurer le journal des évènements puis valider.

 Une confirmation est demandée avant traitement. 

 

 

 

 

 

 

4.7. Paramétrages (à partir de la version 2024.Q4)

Ce traitement permet de renseigner le chemin par défaut pour sauvegarder les bases de données. Ce chemin sera utiliser par défaut dans le traitement de sauvegarde et le traitement de restauration.

4.8. Sauvegarder la base dans le répertoire de test (à partir de la version 2024.Q4)

Ce traitement permet de lancer la sauvegarde le la base de données en cours dans le répertoire paramétré dans le traitement précédent.

Par défaut le backup porte le nom de la tâche en cours. la valeur est modifiable.

4.9. Activer/Désactiver la tâche

Ce traitement permet de désactiver l’exécution d’un traitement d’une tâche du corps de l’application, il met à jour la zone « Actif » d’un traitement.

Il peut être utilisé pour les tâches standards livrées par Silog.

Lorsque la tâche contient plusieurs enregistrements dans son corps, ce traitement permet de désactiver un ou plusieurs traitements. Ces traitements ne seront pas exécutés lors de l’exécution de la tâche.

Donnez votre avis sur la Base de connaissance Silog ici ou contactez-nous directement par mail sur confluence@silog.fr