Un expresso sans sucre

La plupart des SI ont un passé et disposent de systèmes anciens dits « legacy », ces systèmes hébergent encore de nombreuses applications et leur remplacement ne peut pas se faire du jour au lendemain.

Il est donc important de pouvoir valoriser ces systèmes et de les intégrer dans des architectures à base de service dites SOA.

Pour les systèmes AS/400, OS/400, i5/OS, iseries ou System i (rayez les mentions inutiles), voici les mécanismes que j’ai mis en oeuvre:

• Exposition de services de l’AS/400

IBM publie en OpenSource une librairie nommée JT400 qui permet de se connecter à l’AS400 et entre autre de faire du RPC en lançant les programmes à distance. La connexion se fait en TCP/IP et cela fonctionne avec des programmes écrits en COBOL, RPG et RPG ILE, avec des scripts CL et probablement dans d’autres langages.

La javadoc de la classe ProgramCall contient un bon exemple d’utilisation.

Une fois le service interfacé en Java, il est exposé vers le monde « ouvert » et peux donc être ré exposé sous toutes les formes possibles : WebService SOAP, Resource REST, EJB, …..

• Consommer un service depuis l’AS/400

IBM met à disposition une boite à outil qui permet de consommer des WebServices SOAP depuis des programmes C, RPG ou COBOL qui tournent sur l’AS/400.Cette boite à outil est en fait un portage de la librairie Axis C vers l’AS/400 ce qui est à mon avis un bon signe de maturité.

Cet article explique la méthode à utiliser. Voici quelques remarques suite à l’utilisation que j’en ai faite.

• Les chaines de caractères sont de type « xsd_string », ils faut les passer au stub SOAP par adresse (%addr) et non par valeur.
• Ne pas oublier de tronquer les chaînes de caractères à la bonne longueur et d’y ajouter un zéro binaire (X’00’) que ce soit pour l’URL du WebService ou pour ses paramètres

Le RedBook nommé « Building SOA-based Solutions for IBM System i Platform » documente les différentes manières d’intégrer un AS/400 dans une architecture orientée service.