Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Sommaire :

...

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

...

2.2. L’onglet « Général » « 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.

Code Block
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 :

...

  • 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.

...

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.

...

  • 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).

...

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 :

...

Remarque

Dans la structure des tables « SIL_JOB_ » , il existe un champ nommé « Lien » pour identifier les données liées entre l’entête et le corps.

Dans ce cas la syntaxe est la suivante pour l’application Bon d’expédition :

Par exemple :

  • image-20240201-085315.png

    Bien respecter l’ordre C.Lien=E.Lien et non E.Lien=C.Lien.

 

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

...

#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.

...

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.

...

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 :

...

4 . Les traitements

L’entête :

...

 Le Le corps :

...

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

...

Des filtres sont saisissables sur les colonnes suivantes :

  • Niveau Niveau : Saisir -1 pour tout afficher.

  • TypeInfo 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 ».

...

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

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.5. 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. 

...

 

...

de publier la tâche en cours ou toutes les tâches directement sur une base de données avec possibilité de sauvegarder et restaurer une base de données.

Note

La base de données cible doit être sur le même serveur SQL que la source de données.

...

  • 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.

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

  • Mise à jour des bases après restauration Pour mettre à jour la base de données restaurée dans la version, en cours.

  • Serveur : Nom et instance du serveur SQL Cible

  • Base : Nom de la base de données Cible. Si la restauration est cochée, la base de données cible est écrasée.

  • 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

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

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

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.

...

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.