Meilleures pratiques lors de la communication avec AS400 (IBM i) à partir de .NET

Question

J'ai besoin d'aide sur les éléments importants et les meilleures pratiques lors de la création d'une solution de génération de rapports basée sur .NET sur un système AS400 existant.

• Quel est le plus adapté intégration technologie (ODBC, OLE DB, ADO.NET) et fait qui dépendent de la version de AS400 dont nous parlons? S'agit-il toujours de bases de données DB2 ou est-ce que peut varier? Quel autre système de persistance est habituellement utilisé?
• Est-il possible d'appeler programmes dans le mainframe qui a logique dans eux ou est préférable de répliquer cette logique dans la couche .NET et ensuite appeler la base de données centrale directement?
• Je suppose qu'un système de reporting doit être en ligne et appeler la base de données centrale directement ou existe-t-il d'autres moyens (par exemple l'exportation de fichiers, etc.) qui seraient préférables?
• Quels sont les détails techniques importants à connaître avant de démarrer le projet (version AS400, etc.) pour éliminer les problèmes.

Fondamentalement, je suis intéressé (et je voterai) dans toutes les informations et expériences des projets .NET/AS400. Je ne l'ai jamais fait auparavant et j'ai besoin de connaître les pièges avant le début du projet.

Answer 1

Si vous n'êtes pas familier avec l'OS/400, préparez-vous à une courbe d'apprentissage raide. Essayez de réduire la douleur en enrôlant l'assistant local AS/400, il sera indispensable pour écrire le programme CL impair, obtenir des autorisations, etc.

Personnellement, je suis toujours resté avec les pilotes ODBC fournis avec Client Access, mais seulement pour lire -seulement. Je ne peux pas le justifier, mais une décennie de programmation AS/400 m'a appris qu'essayer de mettre à jour une base de données AS/400 depuis l'extérieur de l'AS/400 est une mauvaise idée.

Il est en effet possible d'appeler des programmes AS/400 CL à partir de votre application .NET et, si la logique métier y est déjà programmée, son utilisation est logique; Le réinventer dans .NET est cher, sujet aux erreurs et sera beaucoup plus lent.

Mêmes messages pour le signalement: utilisez ceux existants si possible.

choses à regarder dehors pour (certains d'entre eux pourrait bien être dépassée):

SQL DB2 a de nombreuses différences subtiles à d'autres dialectes SQL. De nombreux DBMSs accepteront

SELECT X, Y FROM A, B WHERE A.T=B.T 

comme équivalent à

SELECT X,Y FROM A INNER JOIN B ON A.T=B.T 

DB2 ou non voir, selon les tables. Quand ce n'est pas le cas, le premier peut être très lent. Cela dit, si vous avez un problème de performance, il existe des outils très efficaces pour analyser les plans de requête DB/2; Vous aurez besoin de votre assistant AS/400 pour les utiliser, car ils sont un peu obscurs.

Si vous travaillez dans un environnement international, la gestion des pages de codes nécessite des soins. Assurez-que tous les vos AS/400 ont la même page de codes système.

Si vous êtes dans une configuration multi-AS/400, sachez que les tables locales et distantes peuvent être accédées de manière transparente (avec passthrough).

OS/400 a une longue histoire de support arrière étendu. Vous n'aurez généralement pas à vous inquiéter des versions, tant que tous les AS/400 auxquels vous parlez sont sur la même version majeure. C'est aussi une plateforme très stable. Les bogues du système d'exploitation sont très rares et rapidement corrigés. Si vous pouvez le gérer, accédez à un système de test doté du privilège *ALLOBJ. Cela vous permettra de vous concentrer sur le problème et de traiter les problèmes de sécurité plus tard.

HTH

Answer 2

Ok J'avais l'habitude de travailler avec et de me connecter aux systèmes AS/400 et mainframe de .NET il y a plusieurs années. Je ne pourrais peut-être pas répondre directement à vos questions, mais je peux vous faire savoir ce qui a fonctionné pour moi et ce que j'ai fait dans le passé.

Un terme commun pour ce type de travail est Enterprise Application Integration (EAI), donc vous pouvez commencer par lire à ce sujet. Autant que je sache, il est possible d'avoir plus que des bases de données DB2 sur AS/400. Il y avait 2 façons dont nous avons travaillé avec écran vert (ou héritage) applications:

1. Accéder à la source de données/magasins directement
2. Créer une session, envoyer des séquences de touches telles que F10, F4, etc. que l'application héritée utilise pour naviguer à travers différents écrans, et saisir des données à partir de points fixes sur l'écran hérité (ceci est parfois appelé le grattage d'écran).

Pour répondre en partie à votre première question, pour accéder aux sources de données directement nous avons créé DSNs (nom de la source de données) en utilisant les pilotes ODBC qui étaient disponibles à partir de 2 sociétés à l'époque, Rumba (faite par Wall Data), et Attachmate (fait par je pense IBM). Pour créer un DSN ODBC, vous avez généralement accédé à Admin Tools/Data Sources et ajouté un DSN système. Vous auriez besoin du nom d'hôte (ancien système), du nom d'utilisateur avec lequel vous vous connectez et du mot de passe. Nous avons ensuite utilisé ces DSN dans des applications .NET pour créer une connexion aux applications existantes. Si vous avez un DSN, vous pouvez ensuite utiliser quelque chose comme SQL Server DTS/SSIS pour récupérer des données de la source et les enregistrer dans un emplacement donné, qu'il s'agisse de la base de données, des fichiers CSV, des fichiers Excel, etc. un outil de création de rapports (Crystal/SQL Server Reporting Services) accède directement à la source de données à l'aide du DSN afin que vous puissiez générer des rapports directement à partir de la source de données. En outre, vous pourriez probablement créer des connexions sans DSN, il y a des années, nous avions besoin de DSN.

Pour répondre partiellement à votre 2ème question, il est possible d'appeler et d'utiliser la logique sur les applications à écran vert si vous le souhaitez. Un écran vert est généralement divisé en un nombre défini de lignes et de colonnes, et nous avons utilisé un standard appelé HLLAPI qui envoyait les frappes d'un système Windows à des positions sur un écran hérité. Nous avons utilisé Rumba pour ce qui était disponible en tant que contrôle OCX et je suis sûr que Attachmate est aussi.Par exemple, vous pouvez créer un formulaire Winforms avec des zones de texte ID utilisateur et mot de passe, puis créer une session dans l'application héritée, et le premier écran sera généralement un écran d'ouverture de session. Puis, en utilisant les positions des champs de nom d'utilisateur et de mot de passe sur l'écran vert, envoyez l'ID utilisateur et le mot de passe à ces positions, puis envoyez une frappe de touche Enter ou tout ce qui était nécessaire pour se connecter. Vous pouvez ensuite naviguer vers un autre écran, par exemple. un écran de recherche, envoyer les données et les touches pour effectuer une recherche, puis saisir les données résultantes à partir de l'écran vert. Une autre approche consiste à créer des formulaires Win/Web qui répliquent l'application à écran vert et récupèrent directement les données des magasins de données. L'avantage de ceci est que vous n'avez pas besoin de connaître les frappes/navigation de l'application héritée qui pourrait devenir lourde pour un grand système d'écran vert. Il n'y a pas de bien ou de mal cela dépend des circonstances. Notre société a fait un mélange des deux. Pour votre troisième question, cela dépend du type de rapports que vous voulez. Si elles doivent être en temps réel, vous pouvez vous connecter directement au magasin de données. Si elles n'ont pas besoin d'être en temps réel, vous pouvez effectuer des transferts nocturnes des données à partir du système hérité et stocker les données dans SQL Server par exemple, puis exécuter vos rapports sur les données SQL Server.

Une réponse à votre 4ème question est que vous aurez certainement besoin de mettre la main sur quelqu'un qui connaît l'application de l'écran vert. Vous passerez des heures et des heures à parcourir les écrans de l'application existante, de sorte que l'accès aux utilisateurs qui connaissent le système est crucial. Vous aurez également besoin d'identifiant et de mots de passe, etc.

Enfin, il existe des sociétés tierces spécialisées dans le transfert de données de la source à la destination, l'une de mes têtes étant Data Mirror. Une autre approche consisterait à utiliser un produit d'intégration de niveau intermédiaire tel que BizTalk ou Tibco, qui prennent des données provenant d'une ou de plusieurs sources et les collent dans une ou plusieurs destinations, mais cela peut être excessif selon vos besoins.

espoir qui aide et bonne chance :)

Answer 3

J'utilise l'accès client (de ce qu'il appelle maintenant) les pilotes de se connecter au serveur que je crois sont basés sur ADO.NET. Grâce à la version du pilote que j'ai (nous sommes sur V5R4), vous ne pouvez pas et devez créer des procédures stockées pour appeler les programmes (ce qui n'est pas difficile). Je pensais avoir entendu sur la dernière version, vous pouvez exécuter des programmes, mais je ne suis pas certain. La seule autre chose que je voudrais regarder est de créer un utilisateur avec seulement les autorisations dont vous avez besoin de faire ce que vous devez faire au cas où quelqu'un obtient un nom d'utilisateur et un mot de passe, ils ne peuvent pas en faire trop. Nous avions installé un utilisateur en lecture seule (*USE) et un utilisateur rwx (*CHANGE).

Answer 4

[Nous n'avons pas vu que c'est un ancien article. J'espère que c'est encore utile]

J'ai écrit à la fois des applications vertes et .Net. De mon expérience ..

1. ODBC - fonctionne, mais vous devez définir les paramètres ODBC à tous les PC de l'utilisateur. Le fournisseur de données .NET est meilleur en raison de plus de contenu .net spécifique à l'intérieur et n'a pas besoin de définir les paramètres ODBC à tous les clients. Avant que le fournisseur .net disponible en as400, j'utilise principalement OLEDB. Voir http://www-03.ibm.com/systems/i/software/access/windows/dotnet/ pour les détails

2.Utiliser les procédures stockées. Procédures stockées normalement plus rapide que de mettre toutes les logiques à l'intérieur. Net. Créer une procédure stockée SQL ou externe écrite en RPG, CL, COBOL, C++, etc ... Je ne réécris pas toute l'ancienne logique RPG en .net, je change juste un peu de vieux programme RPG et le transforme en External stocké procédure

3.Pour les rapports, utilisez à nouveau des procédures stockées qui ont renvoyé des jeux de résultats. C'est rapide, propre et fonctionne bien avec Crystal Report.

4.Détails techniques. Si vous avez de nombreux clients pour installer le programme - utilisez les services Web - vous n'avez pas besoin d'installer Client Access avec la version correcte sur tous les PC.

Regardez votre version OS400. Si vous utilisez OS400 version V6R1 et supérieure, assurez-vous que l'accès client utilisé est V5R4 ou supérieur - Les procédures stockées peuvent ne pas fonctionner correctement avec l'ancien accès au client.

ODBC fonctionne dans un accès client plus ancien mais je pense que .NET Data Provider ne fonctionne que dans V5R3.

Si vous compilez un programme .net à l'aide de .NET Data Provider V6R1, l'accès du client utilisateur doit également être défini sur V6R1.

Utilisez la procédure stockée chaque fois que possible pour la sécurité (ne pas besoin d'exposer les tables) et de simplifier la logique du programme (peut réutiliser programme RPG)

Sur le côté OS400, assurez-vous la valeur du système que QCCSID est réglé avec CCSID appropriée par exemple 37 pour l'anglais. Le pilote ODBC, OLEDB, .net convertira/traduira automatiquement le caractère approprié à votre programme .Net. Ne jamais laisser la valeur comme 65535.

Espérons que cela aide.