Donner des paramètres souples aux utilisateurs

La plupart des applications tournant sur System i exécutent des jobs demandant des paramètres dont les valeurs changent entre deux exécutions. Ces paramètres peuvent être très simples : une date entrée par l’utilisateur, ou très complexes : une série complète avec numéros de clients, paramètres de sélection, et ainsi de suite.

De nombreux artifices permettent de personnaliser cette entrée de paramètres : d’une invite simple non formatée à des écrans ad hoc chargés de contrôler les paramètres saisis. Dans le premier cas, cette approche rudimentaire peut faire l’affaire si le format du paramètre est lui aussi très simple et donc si l’utilisateur a peu de risque de se tromper. Dans le second cas, il est probable qu’on surveillera strictement le contenu du paramètre, parce que les utilisateurs pourraient provoquer des dégâts en choisissant des valeurs erronées. Le plus souvent, les exigences des systèmes se situent au milieu.

Souvent, les administrateurs système doivent contrôler quelque peu le format des données des paramètres mais répugnent à proposer aux utilisateurs une multitude d’écrans de saisie spécialisés. Voyons un exemple concret de cela. Une application pourrait avoir à exécuter un certain nombre de jobs batch moyennant des paramètres fournis par l’utilisateur. Au lieu de développer des fichiers d’affichage personnalisés (en même temps que le programme de traitement de fichiers d’affichage requis) pour capturer les paramètres saisis par l’utilisateur, pour la soumission du job batch, un site System i pourrait définir les paramètres dans l’utilitaire que j’offre ici et appeler le programme de saisie de paramètres en utilisant soit une zone tampon de longueur fixe, soit une structure de données qui correspondrait à la structure du tampon de paramètres renvoyé. Le tampon de paramètres serait ensuite utilisé dans une soumission de jobs batch. La figure 1 montre un exemple de ce processus.

L’utilitaire de paramètres que je présente ici s’adresse au gros de la troupe, en excluant les cas très simples et très compliqués. Il est extrêmement souple, avec chaque chaîne de paramètres comportant jusqu’à 20 sous-champs, et il offre une édition de type de données basique de l’entrée utilisateur : par exemple, s’il faut une date au format JJMMAA, il n’accepte qu’une valeur correcte. L’utilitaire ne prétend pas valider les données par rapport à une base de données d’application, mais il s’assure que la chaîne de paramètres construite est plausible et raisonnable.

Les écrans System i standard sont utilisés pour maintenir la base de données des paramètres et des sous-champs. L’écran qui sert à accepter la saisie utilisateur est construit en utilisant des API Dynamic Screen Management. Ces API permettent à l’utilitaire de construire le panneau de saisie de chaque paramètre en fonction des spécifications propres au dit paramètre.