Utilisation de la passerelle d'application WebFacing pour l'interaction avec d'autres applications Web

La passerelle d'application WebFacing, introduite dans la version 7.1, permet de connecter de manière transparente de nouvelles applications Web (écrites avec EGL par exemple) à des applications WebFacing et/ou HATS existantes.

Par le biais de cette technologie, vos applications peuvent être modernisées de manière simple et rapide à l'aide de WebFacing et/ou HATS et de nouvelles applications Web peuvent être ajoutées de manière progressive pour bénéficier des dernières innovations Web.

A l'aide de la passerelle d'application, les applications WebFacing peuvent transférer le contrôle et les données vers et depuis d'autres applications Web, telles qu'EGL, ce qui permet de combiner les applications HATS, WebFacing et EGL en une seule application. Les avantages de cette technique ne se limitent pas à l'obtention des données IBM i dans une application Web via un accès direct à la base de données ou à l'appel d'un programme de traitement par lots via un service Web. Vous avez la possibilité de lier votre nouvelle application Web à une application IBM i interactive et de partager les données.

L'application WebFacing et l'application Web correspondante peuvent être intégrées sous la forme d'un fichier EAR à des fins de déploiement. Le fichier EAR peut être créé à l'aide de la perspective J2EE de l'environnement IDE. Les applications WebFacing et l'application Web peuvent cependant être déployées également en tant que fichiers EAR distincts au sein de la même instance de serveur d'applications.

Pour autoriser la prise en charge de l'interopérabilité entre une application WebFacing et une autre application Web, un enregistrement de lien DDS doit être créé et le paramètre Web Passerelle d'application doit être défini pour cet enregistrement. Un enregistrement de lien DDS est un enregistrement DDS standard contenant des zones définies comme étant masquées (usage H) qui permet de transférer les données. Ce n'est pas lui qui apparaît à l'écran. Il permet simplement de transférer des données et le contrôle à l'application Web indiquée dans l'URL de l'application cible du paramètre Web Passerelle d'application lorsque l'application IBM i exécute une opération de type WRITE sur l'enregistrement.

Pour plus d'informations sur la création d'un enregistrement de lien DDS, voir le paramètre Web Passerelle d'application dans Utilisation des paramètres Web avec le source DDS.

La passerelle d'application WebFacing prend en charge le transfert du contrôle et des données dans les scénarios ci-dessous.
  1. Une application WebFacing appelle une autre application Web comportant des données ; cette dernière renvoie le contrôle à WebFacing avec les mises à jour des données.
    • L'application IBM i exécute une opération WRITE sur l'enregistrement de lien WebFaced (transfert du contrôle et des données à une autre application Web) immédiatement suivie d'une opération READ et elle attend le renvoi des données.
  2. Une application Web appelle une application WebFacing. Cette dernière s'exécute et renvoie ensuite les données à l'autre application Web.
    • L'application IBM i exécute une opération WRITE sur un enregistrement de lien WebFaced avec le mot clé FRCDTA, puis elle s'arrête.

Le scénario 1 transmet les données de l'application WebFacing vers l'application Web indiquée dans l'URL de l'application cible du paramètre Web Passerelle d'application lorsque l'application IBM i exécute une opération WRITE et READ sur l'enregistrement de lien DDS. L'application WebFacing attend alors une réponse de l'application Web. Cette dernière lit ensuite les données via l'attribut de requête "LinkageData", effectue les mises à jour éventuelles, puis renvoie ces dernières à l'application WebFacing qui reprend alors le contrôle.

Le scénario 2 est pris en charge par l'appel par programmation WebFacing qui permet de spécifier n'importe quelle commande CL avec ou sans paramètre pour lancer une application WebFacing. L'application WebFacing s'exécute, puis retransmet les données à l'application Web indiquée dans la zone d'URL de l'application cible du paramètre Web Passerelle d'application lorsque l'application IBM i exécute une opération WRITE sur l'enregistrement de lien DDS. Dans ce scénario, le mot clé FRCDTA doit être spécifié dans l'enregistrement de lien DDS afin que l'application puisse s'arrêter avec succès. Pour plus d'informations sur l'appel par programmation, voir Appel par programmation d'applications WebFacing depuis d'autres applications Web.

La passerelle d'application WebFacing permet d'établir une interaction entre des applications WebFacing et/ou HATS et d'autres applications Web. HATS est configuré pour prendre en charge WebFacing lorsqu'un projet HATS et WebFacing sont liés par le biais de la fonction d'interopérabilité. Dans le cas des projets HATS/WebFacing liés, la passerelle d'application peut être utilisée dans les scénarios ci-dessous.
  1. HATS et Web/EGL : seul l'enregistrement de lien est converti/WebFaced dans le projet WebFacing ; permet aux projets HATS de transmettre le contrôle et les données à Web/EGL.
  2. WebFacing, HATS et Web/EGL : une partie de l'application est WebFaced et l'autre partie s'exécute en tant que projet HATS ; permet à WebFacing et/ou aux projets HATS de transmettre le contrôle et les données à Web/EGL.

Transmission du contrôle de WebFacing à une application Web

Dans les deux scénarios ci-dessus, une opération WRITE est exécutée sur un enregistrement de lien DDS dans le but de transmettre le contrôle de WebFacing à une autre application Web. Pour cela, la méthode de réacheminement J2EE est appliquée à l'adresse URL indiquée dans l'URL de l'application cible du paramètre Web Passerelle d'application. L'application WebFacing utilisera la première partie de l'adresse URL de l'application cible comme racine du contexte et acheminera l'application WebFacing vers l'autre partie de l'adresse URL. Si l'adresse URL de l'application cible est /appContextRoot/appEntryPoint, l'application WebFacing utilise appContextRoot comme racine du contexte et l'acheminement s'effectue vers appEntryPoint. L'application WebFacing ajoute alors l'attribut de requête "forwarded" à la valeur "WF" dans l'objet de requête avant de procéder à l'acheminement. Le module d'exécution de l'application de réception pourra ainsi exécuter toute action spéciale nécessaire lors de la réception du contrôle retransmis.

Transmission du contrôle d'une autre application Web vers WebFacing

Dans le cadre du scénario 1, lors du renvoi du contrôle vers l'application WebFacing et pour garantir la transmission des mises à jour des données, l'application Web doit ajouter l'attribut "forwarded" dans l'objet de requête avant de procéder au réacheminement. L'attribut de requête doit être "EGL" pour une requête acheminée depuis une application EGL et "CUSTOM" pour une requête acheminée depuis une autre application Web. L'application WebFacing de réception peut ainsi exécuter toute action spéciale nécessaire lors de la réception du contrôle retransmis. Le point d'entrée de l'application WebFacing est "/webfacing/WebFacing.do".

Echange de données entre WebFacing et une autre application Web

Les données de la passerelle d'application livrées par l'enregistrement de lien DDS à l'application WebFacing sont sauvegardées dans une Java, le nom de zone étant utilisé comme clé dans la HashMap et la valeur de zone comme valeur de la clé associée. Un attribut de requête "LinkageData" est utilisé pour fournir l'accès à la HashMap.

Les valeurs de zone contenues dans l'enregistrement de lien DDS sont stockées en tant que données de chaîne Unicode dans la HashMap. L'autre application Web met alors à jour comme il convient les zones de la HashMap et renvoie cette dernière à l'application WebFacing via l'attribut de requête "LinkageData". Une valeur de zone doit contenir les caractères admis par le type de données DDS correspondantes et avoir la longueur appropriée ; sinon, elle est rejetée par l'application WebFacing.

Prenez connaissance des informations suivantes :
  1. Zones de caractères et zones DBCS : aucun formatage n'est appliqué à ces types de données.
  2. Zones numériques : un séparateur décimal "." est inséré à l'emplacement approprié dans les données si la position décimale pour une zone est supérieure à 0 ; un signe négatif "-" est ajouté au début des données si la valeur est négative. Par exemple, -000123.45 est le format approprié pour une valeur numérique dont la longueur est de 8 chiffres et la position décimale de 2.
  3. Zones de données : le format ISO AAAA-MM-JJ est utilisé.
  4. Zones horaires : le format ISO hh:mm:ss est utilisé.
  5. Zones d'horodatage : le format ISO AAAA-MM-JJThh:mm:ss.uuuuuu est utilisé.
Remarque : Lorsqu'un enregistrement de lien DDS ne contient pas de zone, la valeur de l'attribut de requête "LinkageData" est nulle.