La version 1.1.8.3 d’Access Client Solutions apporte une fonctionnalité attendue : complétion SQL !
L’outil cherche pour vous les noms des tables et des colonnes :
Regardez notre courte vidéo pour vous faire une idée !
Vous êtes nombreux à nous solliciter sur une difficulté récurrente liée au débogage : comment déboguer un programme pour lequel le source n’est pas sur la machine, et qui n’a pas été compilé avec la vue *LISTING
Pour RPG : CRTBNDRPG/CRTRPGMOD … DBGVIEW(*ALL ou *LISTING)
Pour rappel :
Il est évidemment bien plus pratique d’indiquer DBGVIEW(*ALL ou *LISTING) pour permettre le débogage.
Vous distribuez vos objets programmes et ne souhaitez pas que vos clients puissent accéder au source ? Il est possible de crypter le source embarqué : lors du débogage, vous devez saisir la clé correspondante pour afficher le source !
Pour changer de vue source (équivalent F15 dans STRDBG), clique droit dans le source, changer la vue …
Revenons maintenant à notre cas : vous compilez avec DBGVIEW(*SOURCE) et vous envoyez vos programmes sur un autre système (production, recette/UAT …). Lorsque vous souhaitez déboguer vos programmes en production, impossible d’avoir le source, et donc de faire quoi que ce soit d’intelligent !
Vous pouvez bien sur envoyer le source ….
Mais RDi vous permet de déboguer un programme sur une machine de production, tout en accédant au source sur la machine de développement, voir sur votre machine Windows (Linux/Max pour ceux qui souhaitent) !
C’est assez simple :
– Dans RDi, assurez-vous de disposer d’une connexion RSE au système de production et d’une autre connexion au système de développement
– Evidemment, vous devez savoir où (bibliothèque, fichier …) se trouve le source
Lancez le débogage sur votre machine de production. L’écran suivant s’affiche, le membre source étant introuvable sur ce système :
Cliquez sur « Editer le chemin de recherche des fichiers source … », puis sur « Ajouter… » :
Puis « Fichier source IBM i » :
Sélectionner la connexion RSE correspondant à la machine de développement, puis dérouler les bibliothèques pour sélectionner la bibliothèque/fichier source correspondant, puis OK :
Le source s’affiche, vous pouvez déboguer normalement !
La technique peut s’appliquer également si lors de votre process de développement les membres source sont déplacés d’une bibliothèque (développement/version) à une autre (référentiel).
Vous avez le source sous forme de fichier texte sur votre machine ? Pas de soucis, vous pouvez également l’indiquer :
On peut alors déboguer :
Limitations :
– Impossible d’indiquer le nom du membre source : ne fonctionne pas avec les renommages
– les includes/copy, coloration, etc …
Isphere est un plugin eclipse que l’on peut installer sous RDi et qui apporte des fonctionnalités complémentaires
Il est gratuit, donc ça ne coûte rien de l’installer pour voir !
et c’est un produit open source vous pouvez même participer à son évolution
Vous avez un comparateur de sources un peu plus simple, qui permet par exemple de comparer 3 Sources …
Sur la gestion de vos spools le plugin permet d’avoir beaucoup plus d’options
C’est également vrai sur la gestion des messages …
Vous avez un outil qui permet de chercher des informations dans des sources avec une grande facilité d’utilisation
Editer simplement le contenu d’un fichier message .
Voici les principales options qu’on utilise chez GAIA
Il en existe d’autres, par exemple des options ILE sur les objets …
Plus toutes celles qu’on n’a pas trouvé encore !
Une des fonctionnalités attendues disponible avec la 7.4 / 7.3 TR6 (SF99722 niveau 19) est la possibilité de déployer des services web (REST uniquement) basés sur des instructions SQL au lieu de programmes ILE.
Voici nos premiers tests, effectués « à vue » la documentation IBM n’étant pas encore disponible …
En bref, vous avez désormais les possibilités suivantes :
De plus, IWS vous propose également un format de sortie HTML, en plus de JSON et XML déjà en place. De quoi faciliter l’intégration de vos données dans des pages web !
Comment fait-on ?
Déployer un nouveau service : vos avez maintenant la possibilité de choisir SQL
Comme d’habitude pour les services REST, vous indiquez nom de service et nom de ressource
Maintenant, vous avez des paramètres spécifiques à un service basé sur SQL vous permettant de régler les conventions de nommage et la résolution des objets non qualifiés dans vos requêtes. Le fonctionnement est habituel en SQL. Pour simplifier : basé sur la *LIBL en convention *SYS, sur un schéma par défaut en *SQL
Vous pouvez indiquer plusieurs « procédures » dans un service REST SQL, c’est à dire plusieurs opérations disponibles au travers de votre service, et identifiées (plus tard) par des URL et/ou des méthodes HTTP différentes
Pour commencer simplement :
Bien sûr, vous pouvez utiliser des paramètres dans vos requêtes SQL, identifiés par « ? » :
L’outil est plutôt bien fait de ce côté-là : il est capable de détecter le type des données correspondant à vos paramètres en analysant le fichier :
Vous devez ensuite régler le comportement attendu de votre traitement :
la suite des écrans est classique et ne présente pas de particularité dû au SQL, en dehors du type de sortie *HTML proposé.
Quelques exemples de résultats fournis par les appels de différents services (renvoyant une ligne ou plusieurs lignes, en JSON, en XML, en HTML …) :
L’outil vous permet également d’obtenir des informations sur l’exécution et les erreurs SQL :
Maintenant, passons à la possibilité qui ouvre d’autres perspectives !
Avec les services basés sur des programmes ILE RPG/COBOL, nous n’arrivons pas à retourner des images ou documents binaires : toutes les données sont converties en UTF-8 (par défaut) pour sortir sur le flux HTTP. Nos données binaires ne supportent pas bien … seule solution jusqu’ici : encoder en base64 (c’est à dire en caractères) ! Mais cela complexifie, nécessite du temps machine et augmente la taille de la sortie.
Lors du déploiement, sélectionner le type « Media resource »
Vous devez indiquer le type de ressource (seule la première valeur est prise en compte) :
Dès lors, vos services web peuvent retourner des documents (au sens large), par exemple un pdf accessible depuis un navigateur :
Ou une image (vous devriez reconnaître) :
Un nouveau script shell a fait son apparition dans /qibm/proddata/os/webservices/bin : getConfigurationFile.sh
Les informations disponibles actuellement : https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/dW%20IBM%20Integrated%20Web%20Services%20for%20i/page/Script%20to%20generate%20property%20file%20for%20a%20service
Ce dernier génère deux fichiers pour un service :
Le fichier properties contient les attributs du service, des procédures/méthodes, du connecteur jdbc.
Le fichier xml est en réalité un fichier pcml contenant des balises spécifiques utilisées pour le déploiement d’un service.
Ces formats de fichiers permettront également le déploiement par script shell (avec installWebService.sh) des services REST SQL.
L’outil poursuit sa belle évolution, avec toujours plus de fonctionnalités et de possibilités ! Nous compléterons prochainement avec des tests plus approfondis.
D’ici là, bonnes vacances à tous, et rendez-vous à la rentrée, reposé et bronzé !
En voici une qui va vous permettre de savoir si vous avez des données erronées dans vos fichiers PF.
Quand vous faites une requête avec un select sur un pf qui a des données en erreur, en fonction de votre interface vous obtenez des ++++ ou autres qui vous indique que vos données sont en erreur !
Mais surtout ça génère un message CPF5035 dans votre log qui vous indique la ligne et la zone en erreur
Exemple :
select substr(MESSA00007, 1, 10) as fichier ,
substr(MESSA00007, 21, 10) as biblio,
substr(MESSA00009, 55, 71) as texte
from table(qsys2.joblog_info(‘*’)) a
where MESSAGE_ID = ‘CPF5035’
Qui vous donnera
CLIENTS GAIA la zone CLIENTS_1.CAANC, numéro d’enreg 213, format *FIRST, membre
CLIENTS GAIA la zone CLIENTS_1.CAAN1, numéro d’enreg 213, format *FIRST, membre
CLIENTS GAIA la zone CLIENTS_1.CAAN2, numéro d’enreg 213, format *FIRST, membre
Ici on voit que sur l’enregistrement 213 (rang relatif) a des zones CAANC, CAAN1 et CAAN2 qui ont des données en erreur
Vous pouvez corriger facilement en faisant
update gaia.clients a set caanc = 0 where rrn(a) = 213
Voici un petit script CLLE qui vous permettra de savoir si un PF à des données en erreur
pgm parm(&table &lib)
dcl &table *char 10
dcl &lib *char 10
chkobj &lib/&table *file
RUNSQL SQL(‘drop table qtemp/wtest’) COMMIT(*NONE)
monmsg SQL9010
RUNSQL SQL(‘create table qtemp/wtest as (select * +
from’ *BCAT &LIB *TCAT ‘/’ *TCAT &TABLE +
*bcat ‘)with data’) COMMIT(*NONE)
monmsg SQL9010 exec(do)
/* ici votre traitement pour récupérer les erreurs CPF5035 */
/* select substr(MESSA00009, 55, 71) as texte */
/* from table(qsys2.joblog_info(‘*’)) a */
/* where MESSAGE_ID = ‘CPF5035’ */
/* vous devrez par exemple écrire ces données dans une table */
endpgm
Ce script est a améliorer en effet il ne donne que le premier enregistrement corrompu , sql interrompant le traitement à la première erreur.
{
« qteage »: [
{
« agence »: « LY »,
« qte »: 567
},
{
« agence »: « PA »,
« qte »: 879
}
],
« code »: « OK »,
« message »: « »
}
select u.* from json_table( ‘{
« qteage »: [
{
« agence »: « LY »,
« qte »: 567
},
{
« agence »: « PA »,
« qte »: 879
}
],
« code »: « OK »,
« message »: « »
}’, ‘strict $.qteage[*]’
COLUMNS( « CodAge » varchar(50) PATH ‘strict $.agence’ ,
« Quantite » decimal PATH ‘strict $.qte’
) ) AS U;
select u.* from json_table( ‘[
{
« agence »: « LY »,
« qte »: 567
},
{
« agence »: « PA »,
« qte »: 879
}
]’, ‘strict $.[*]’
COLUMNS( « CodAge » varchar(50) PATH ‘strict $.agence’ ,
« Quantite » decimal PATH ‘strict $.qte’
) ) AS U;
{ « data » :
[
{
« agence »: « LY »,
« qte »: 567
},
{
« agence »: « PA »,
« qte »: 879
}
] }
SET :donnees = ‘{« data » : ‘ || trim(:donnees) || ‘}’ ;
Vous êtes de plus en plus nombreux à utiliser IWS pour exposer des programmes (de service) ILE sous forme de service web ! Cette technique fonctionne bien : elle est simple, automatique, le code est écrit en RPG.
Mais utilisez vous toutes les possibilités fournies : XML ou JSON pour encapsuler les paramètres en sortie ?
De plus, nous sommes limités par le nombre de paramètres du code RPG :
Nous vous proposons aujourd’hui d’utiliser un type de media personnalisé en valeur de retour : vos services pourront retourner des documents de type XML, JSON, CSV, HTML, … en réalité tous les types usuels du web basés sur du texte.
Par exemple, la procédure suivante ramène les profils utilisateurs non système (la première lettre est différente de Q) et désactivés (une occasion de faire du ménage) :
Les paramètres :
Au déploiement du service vous devez indiquer certaines options :
On remarque :
Cette dernière option signifie que la valeur de retour sera toujours un document XML
Exemple lors de l’appel depuis un navigateur :
Ici le navigateur se base sur le type indiqué pour le retour (application/xml) pour mettre en forme le résultat.
Nous pouvons maintenant aller plus loin en rendant dynamique les types de données en sortie !
Par exemple, une procédure permettant de lire un fichier sur l’IFS dont le nom est transmis en paramètre, et de retourner son contenu :
Le nom du fichier à retourner est reçu dans le paramètre file.
Nous gérons dans le tableau httpHeaders() la valeur du type de contenu en retour via une entête HTTP Content-Type. Les valeurs usuelles sont listées ici : https://en.wikipedia.org/wiki/Media_type
Le type de contenu est défini en fonction de l’extension du fichier : application/xml pour tous les fichiers *.xml.
Si une extension n’est pas connu du programme, nous provoquons une erreur HTTP 406 NOT ACCEPTABLE.
De plus, si le fichier n’est pas trouvé, un code HTTP 404 NOT FOUND est généré.
Lors du déploiement, il est également nécessaire d’indiquer certaines options :
Principalement dans « Returned output media types » -> doit contenir la liste de tous les types de médias retournées par le programme. Une valeur qui ne serait pas présente ici sera interceptée par le serveur IWS et provoquera une erreur HTTP 500 (Internal Server Error) et aucune valeur ne sera retournée.
Les différentes valeurs sont séparées par des virgules : application/xml, text/csv, text/html, text/plain.
Le swagger généré tient compte de ces informations pour une meilleur documentation et interopérabilité de vos services.
Lors des différents appels (les fichiers indiqués sur l’URL existent dans le répertoire /home/NB/ressources) :
Pour la gestion des cas d’erreur (extension non gérée ou fichier inexistant) :
Grâce à IWS, vos programmes RPG peuvent désormais facilement renvoyer tous types de documents, que le contenu soit statique (comme un fichier dans l’IFS) ou dynamique (calculé en live par votre programme). Et n’oubliez pas, DB2 offre de nombreuses possibilités (XML, JSON, accès à l’IFS …) qui sont donc directement utilisables en SQLRPGLE.
Prochaine étape : des fichiers binaires (image, pdf) !