Différence entre versions

Version du 21 décembre 2020 à 10:05

Sommaire

1 Introduction
2 Problématique rencontré avec LPR
3 Solution
4 Problématique avec les paramètres &SPLUSRDTA et &FORMTYPE
5 Interprétation côté Onyx

Introduction

Le principe de cette fonctionnalité est d'utiliser la commande LPR native OS/400 pour l'envoi de fichier spool IBMI vers Onyx.

Problématique rencontré avec LPR

La plus grosse problématique avec l'utilisation d'une RMTOUTQ utilisant le protocole LPR pour l'envoi des spools AS/400 vers Onyx Linux/Windows est la perte des métadonnées car les attributs de spools ne sont pas transportés.

Solution

Avec la commande LPR, il est possible de faire transiter des métadatas grâce à l'utilisation du paramètre destopt de la commande LPR.

En l'utilisant comme dans l'exemple ci-dessous à partir du robot Mapping, il est possible de transporter les métadonnées que vous souhaitez :

LPR RMTSYS(xxxxx) (…) destopt('Z:map_userdata:KEY=VALUE')

Avec :

"Z:map_userdata:" : obligatoire pour indiquer à Onyx qu'il s'agit d'une métadonnée
"KEY" : le mot clé de votre choix
"VALUE" : la valeur de votre choix

Sous Onyx (Windows ou Linux), les informations se retrouvent alors dans le job sous forme de Mapping User Data :

USERDATAS_KEY=VALUE

Exemple d'utilisation :

LPR RMTSYS(xxxxx) (…) destopt('Z:map_userdata:FROMAS400=&USER;&OUTORI;&SPLFNAME;&STARTPAGE;&ENDPAGE;&USRDTA;&FORMTYPE')

Problématique avec les paramètres &SPLUSRDTA et &FORMTYPE

Le champs destopt a une longueur maximale de 128 caractères. Etant donné que tous les paramètres ne sont pas trimés (&FORMTYPE, &SPLUSRDTA), en cas d'utilisation de ces deux paramètres, le serveur ONYX ne recevra pas toute la valeur du FROMAS400. En effet celle-ci sera tronqué à cause des blancs après la valeur de &SPLUSRDTA ou &FORMTYPE. Pour pallier ce soucis, il convient donc de demander explicitement le trim de ces paramètres. Pour ce faire, un nouveau paramètre est apparu (Depuis la version 10.2.8 d'OPALE) : &TRIM. Celui-ci devra être positionner dans la commande LPR au niveau du destopt avant le ou les paramètres à trimer.

Exemple :

LPR RMTSYS('192.168.217.224') PRTQ(PRINTER1) FILE(&SPLF) JOB(&JOBNUM/&USER/&JOB) SPLNBR(&SPLNUM)DESTOPT('Z:map_userdata:FROMAS400=&SPLF;&OUTORI;&STARTPAGE;&ENDPAGE;&TRIM&SPLUSRDTA;&SPLF;&USRDFNDTA;&FORMTYPE')

En effet, tous les paramètres situés après le paramètre &TRIM se trouveront trimé.

Remarque 1 : Si vous souhaitez trimer tous les paramètres, vous pouvez mettre le paramètre &TRIM tout au début de la chaine devopt :

LPR RMTSYS('192.168.217.224') PRTQ(PRINTER1) FILE(&SPLF) JOB(&JOBNUM/&USER/&JOB) SPLNBR(&SPLNUM) DESTOPT('Z:map_userdata:FROMAS400=&TRIM&SPLF;&OUTORI;&STARTPAGE;&ENDPAGE;&SPLUSRDTA;&SPLF;&USRDFNDTA;&FORMTYPE')

En faisant cela, vous vous assurez du trim de tous les paramètres envoyés à Onyx.

Remarque 2 : Il est possible à tout moment de désactiver le trim en utilisant le paramètre &NOTRIM

LPR RMTSYS('192.168.217.224') PRTQ(PRINTER1) FILE(&SPLF) JOB(&JOBNUM/&USER/&JOB) SPLNBR(&SPLNUM) DESTOPT('Z:map_userdata:FROMAS400=&TRIM&SPLF;&OUTORI;&STARTPAGE;&ENDPAGE;&SPLUSRDTA;&SPLF)&NOTRIM&USRDFNDTA;&FORMTYPE')

Dans cet exemple, les paramètres (&SPLF;&OUTORI;&STARTPAGE;&ENDPAGE;&SPLUSRDTA;&SPLF seront bien trimés mais les deux derniers paramètres (&USRDFNDTA;&FORMTYPE) sont quant à eux non pris en compte par le &TRIM.

Interprétation côté Onyx

Avec cet exemple, il suffit ensuite de découper la chaine de caractères obtenue directement dans un workflow Mapping, à l'aide de la boite "String/Couper par champ", en précisant le délimiteur ainsi que le numéro de champ à extraire. Par contre, la position de l'élément est importante dans ce cas.

Une autre solution pourrait consister à passer également le nom des paramètres et utiliser la boite "String/Couper par séparateur".

Exemple d'utilisation :

LPR RMTSYS(xxxxx) (…) destopt('Z:map_userdata:FROMAS400=USER=&USER;OUTQ=&OUTORI;SPLFNAME=&SPLFNAME;STARTPAGE=&STARTPAGE;STOPPAGE=&ENDPAGE;USRDTA=&USRDTA;FORMTYPE=&FORMTYPE')

Ensuite, dans le workflow Onyx, pour récupérer la valeur "USER" par exemple, il faut mettre "USER=" dans le séparateur de début de sous chaine et ";" dans le séparateur de fin de sous chaine.

@@ Ligne 1 : / Ligne 1 : @@
-Le principe de cette fonctionnalité est d'utiliser la commande LPR native OS/400.
+==Introduction==
+Le principe de cette fonctionnalité est d'utiliser la commande LPR native OS/400 pour l'envoi de fichier spool IBMI vers Onyx.
+==Problématique rencontré avec LPR==
 La plus grosse problématique avec l'utilisation d'une RMTOUTQ utilisant le protocole LPR pour l'envoi des spools AS/400 vers Onyx Linux/Windows est la perte des métadonnées car les attributs de spools ne sont pas transportés.
-Or avec la commande LPR, il est possible de les faire transiter grâce à l'utilisation du paramètre '''destopt''' de la commande LPR.
+==Solution==
+Avec la commande LPR, il est possible de faire transiter des métadatas grâce à l'utilisation du paramètre '''destopt''' de la commande LPR.
 En l'utilisant comme dans l'exemple ci-dessous à partir du robot Mapping, il est possible de transporter les métadonnées que vous souhaitez :
@@ Ligne 24 : / Ligne 27 : @@
   LPR RMTSYS(xxxxx) (…) destopt('Z:map_userdata:FROMAS400=&USER;&OUTORI;&SPLFNAME;&STARTPAGE;&ENDPAGE;&USRDTA;&FORMTYPE')
-'''Remarque importante : Utilisation du paramètre &TRIM et &NOTRIM (A partir de la version IBMI-i 10.2.8'''
+==Problématique avec les paramètres &SPLUSRDTA et &FORMTYPE==
-Le champs destopt a une longueur maximale de 128 caractères. Etant donné que tous les paramètres ne sont pas trimés (&FORMTYPE, &SPLUSRDTA),en cas d'utilisation de ces deux paramètres, le serveur ONYX ne recevra pas toute la valeur du FROMAS400. En effet celle-ci sera tronqué à cause des blancs après la valeur de &SPLUSRDTA ou &FORMTYPE.
+Le champs destopt a une longueur maximale de 128 caractères. Etant donné que tous les paramètres ne sont pas trimés (&FORMTYPE, &SPLUSRDTA), en cas d'utilisation de ces deux paramètres, le serveur ONYX ne recevra pas toute la valeur du FROMAS400. En effet celle-ci sera tronqué à cause des blancs après la valeur de &SPLUSRDTA ou &FORMTYPE.
 Pour pallier ce soucis, il convient donc de demander explicitement le trim de ces paramètres. Pour ce faire, un nouveau paramètre est apparu (Depuis la version 10.2.8 d'OPALE) : &TRIM.
-Celui-ci devra être positionner dans la commande LPR au niveau du devopt juste vant le ou les paramètres à trimer.
+Celui-ci devra être positionner dans la commande LPR au niveau du destopt avant le ou les paramètres à trimer.
 Exemple :
@@ Ligne 36 : / Ligne 39 : @@
 En effet, tous les paramètres situés après le paramètre &TRIM se trouveront trimé.
-Remarque : Si  vous souhaitez trimer tous les paramètres, vous pouvez mettre le paramètre &TRIM tout au début de la chaine devopt :
+Remarque 1 : Si  vous souhaitez trimer tous les paramètres, vous pouvez mettre le paramètre &TRIM tout au début de la chaine devopt :
 LPR RMTSYS('192.168.217.224') PRTQ(PRINTER1) FILE(&SPLF) JOB(&JOBNUM/&USER/&JOB) SPLNBR(&SPLNUM) DESTOPT('Z:map_userdata:FROMAS400='''&TRIM'''&SPLF;&OUTORI;&STARTPAGE;&ENDPAGE;&SPLUSRDTA;&SPLF;&USRDFNDTA;&FORMTYPE')
@@ Ligne 42 : / Ligne 45 : @@
 En faisant cela, vous vous assurez du trim de tous les paramètres envoyés à Onyx.
+Remarque 2 : Il est possible à tout moment de désactiver le trim en utilisant le paramètre &NOTRIM
+LPR RMTSYS('192.168.217.224') PRTQ(PRINTER1) FILE(&SPLF) JOB(&JOBNUM/&USER/&JOB) SPLNBR(&SPLNUM) DESTOPT('Z:map_userdata:FROMAS400='''&TRIM'''&SPLF;&OUTORI;&STARTPAGE;&ENDPAGE;&SPLUSRDTA;&SPLF)'''&NOTRIM'''&USRDFNDTA;&FORMTYPE')
+Dans cet exemple, les paramètres (&SPLF;&OUTORI;&STARTPAGE;&ENDPAGE;&SPLUSRDTA;&SPLF seront bien trimés mais les deux derniers paramètres (&USRDFNDTA;&FORMTYPE) sont quant à eux non pris en compte par le &TRIM.
+==Interprétation côté Onyx==
 Avec cet exemple, il suffit ensuite de découper la chaine de caractères obtenue directement dans un workflow Mapping, à l'aide de la boite "String/Couper par champ", en précisant le délimiteur ainsi que le numéro de champ à extraire. Par contre, la position de l'élément est importante dans ce cas.