Scénarios z/OS Connect
IBM® z/OS Connect propose un accès reposant sur REST aux applications et aux données dont le contenu est basé sur JSON. Ce modèle d'accès est très populaire dans l'industrie.
Les scénarios métier suivants décrivent les divers avantages de l'utilisation de z/OS Connect :
Consolidation ou regroupement de demandes distinctes (scénario d'une entreprise proposant des services financiers)
Une entreprise proposant des services financiers ayant récemment fusionné avec une autre entreprise recherche un moyen sécurisé et rapide d'ouvrir plusieurs applications métier essentielles et de les lier afin d'obtenir un résultat unique et de rendre ce résultat disponible depuis une application Web. Une application z/OS, appelée ACCTINFO, s'exécute dans l'environnement CICS® et fournit l'accès à des données de compte interne pour les clients. Une deuxième application, ACCTHSTY, s'exécute dans l'environnement IMS. Les données gérées par l'application CICS sont stockées dans des fichiers VSAM (Virtual Storage Access Method). Les données IMS se trouvent dans des tables DL/I.
L'entreprise souhaite unifier la sécurité de l'accès à ces applications et être en mesure d'identifier à quel moment et comment les nombreux appels de ces applications ont lieu, le nombre d'octets reçus et renvoyés, ainsi que le temps de réponse.
z/OS Connect propose une solution simple qui masque la complexité de ces environnements grâce à sa configuration. Cette solution permet de contacter un serveur unique qui s'exécute sur un système d'exploitation z/OS afin d'appeler les deux applications via des appels REST et JSON pour les contenus des messages. La prise en charge de la transformation des données qui est fournie dans z/OS Connect gère le mappage vers et depuis des tableaux d'octets et JSON pour chaque demande. De plus, z/OS Connect constitue le point unique de vérification de la sécurité afin de garantir que tout système d'ID demandant l'accès est autorisé à accéder à ces applications, et enregistre chaque appel REST dans la fonction SMF (System Management Facility) z/OS. Pour unifier ces demandes, les définitions de service z/OS Connect utilisent la chaîne serviceGroupingName lorsque chaque service est défini dans la configuration z/OS Connect. Vous pouvez configurer les données serviceGroupingName de sorte qu'elles soient communes à chaque service, par exemple 'ACCOUNT_INFO_HISTORY' ; le résultat apparaît dans les enregistrements SMF z/OS pour chaque demande, de sorte qu'ils puissent être corrélés en vue de leur analyse ou aux fins d'imputation des frais.
Scénario de séparation des demandes mobiles et Web (scénario de détaillant)
Un détaillant souhaite séparer les demandes Web envoyées à des applications sur des systèmes z/OS des demandes qui proviennent de ses nouvelles plateformes mobiles. Cette tâche est facilement réalisable en définissant et en configurant des définitions de service z/OS Connect distinctes de sorte qu'elles utilisent la même configuration de fournisseur de services, ce qui permet à plusieurs services REST d'appeler les mêmes actifs, alors que les appels sont enregistrés et sécurisés avec des critères différents. Les demandeurs provenant de plateformes mobiles peuvent utiliser un ensemble de services via REST, alors que les appels provenant de demandes Web non mobiles peuvent utiliser un ensemble distinct : ils accèdent tous aux mêmes actifs, mais ils sont suivis séparément. Toutes les données sont enregistrées dans des enregistrements z/OS Connect SMF 120 de sous-type 11 et sont accessibles via les mécanismes standard de suivi et d'audit z/OS.
Accès à des actifs de l'environnement z/OS Batch traditionnels via REST et JSON (scénario de compagnie d'assurance)
Une grande compagnie d'assurance souhaite accéder à un ensemble d'applications par lots Cobol qui contient une logique métier sophistiquée développée sur plusieurs années. La conversion de cette application dans un nouveau langage et un nouvel environnement d'exécution serait coûteuse et risquée. Une solution permettant l'accés à la logique métier de cette application par des demandeurs Web et mobiles est moins risquée et permet à d'autres systèmes métier de tirer profit des applications développées.
Si la prise en charge de WebSphere® Optimized Local Adapters dans Liberty et la fonction z/OS Connect WOLA sont activés, cette application est accessible très facilement via des appels REST et un contenu JSON. Le programme d'application Cobol cible requiert des mises à jour pour pouvoir utiliser les API WOLA afin de s'enregistrer auprès du serveur WOLA Liberty et de commencer à accepter des demandes. Une définition de service z/OS Connect est requise, ainsi que le fichier de liaison qui contient les informations sur les données devant être reçues. Vous devez copier les données de retour dans le chemin du fichier de liaison du serveur z/OS Connect. Une fois l'utilisation de z/OS Connect et des API WOLA activée, cet actif par lots est en ligne et disponible pour les clients REST z/OS Connect autorisés.
Reconnaissance des actifs z/OS et informations sur le contenu des demandes et des réponses
Vous souhaitez que votre outil de gestion des API ou de mise à disposition du cloud génère un catalogue des actifs qui sont publiés sur un système z/OS spécifique. Cet outil doit connaître ces actifs et les stocker, avec du contexte. Il doit également inclure des informations sur les éléments requis pour créer les données de demande qui sont transmises au service et des informations sur les éléments de réponse renvoyés par le service.
z/OS Connect propose un moyen de reconnaître tous les services de sa configuration avec un simple appel REST. Lorsqu'une demande HTTP GET arrive pour https://hôte:port/zosConnect/services, une liste au format JSON est renvoyée : elle répertorie tous les services que l'utilisateur authentifié peut voir. Depuis cette liste, vous pouvez extraire les adresses URL de chaque service et interroger chaque service à l'aide d'une demande HTTP GET afin de renvoyer des informations de schéma JSON pour les demandes et les réponses. Vous pouvez sauvegarder la référence de service (adresse URL du service), une description textuelle du service ainsi que les schémas de demande et de réponse JSON dans le catalogue de l'outil, en vue d'une extraction ultérieure. Le fait de pouvoir accéder au schéma JSON signifie que l'outil peut être configuré facilement pour générer un appel REST pour la transmission à z/OS Connect, avec une liste de paramètres JSON appropriée, pour le service z/OS Connect cible.