Mejores prácticas al comunicarse con AS400 (IBM i) desde .NET

Question

Necesito ayuda sobre lo que es importante y las mejores prácticas al construir una solución de informes basada en .NET sobre un sistema existente basado en AS400.

• ¿Cuál es la más adecuada tecnología de integración (ODBC, OLE DB, ADO.NET) y hace que dependen de qué versión de AS400 que estamos hablando? ¿Es siempre bases de datos de DB2 o varía ? ¿Qué otro sistema de persistencia usualmente se usa?
• ¿Es posible llamar a programas en la computadora central que tiene lógica en ellos o es preferible a replicar que la lógica en la capa de .NET y luego llamar la unidad central DB directamente?
• Supongo que un sistema de informes debe estar en línea y llamar a la base de datos del sistema principal directamente o ¿hay otras formas (por ejemplo, exportación de archivos, etc.) que serían preferidas?
• ¿Qué detalles técnicos son importantes de averiguar antes de iniciar el proyecto (versión AS400, etc.) para eliminar los problemas.

Básicamente me interesa (y votaré) toda la información y experiencias de los proyectos .NET/AS400. Nunca lo he hecho antes y necesito saber las trampas antes del inicio del proyecto.

Answer 1

Si no está familiarizado con OS/400, prepárese para una curva de aprendizaje empinada. Pruebe y reduzca el dolor al contratar el asistente AS/400 local, será indispensable para escribir el programa CL extraño, obtener autorizaciones, etc.

Personalmente siempre me quedé con los controladores ODBC suministrados con Acceso de cliente, pero solo para leer -solamente. No puedo justificar esto, pero una década de programación AS/400 me enseñó que intentar actualizar una base de datos AS/400 desde fuera del AS/400 es una mala idea.

Es posible llamar a programas AS/400 CL desde su aplicación .NET y, si la lógica de negocio ya está programada allí, entonces usarlo tiene sentido; reinventarlo en .NET es costoso, propenso a errores y será mucho más lento.

Mismo mensaje para informar: utilice los existentes si es posible.

Cosas a tener en cuenta (algunos de ellos bien puede ser obsoleta):

DB2 SQL tiene muchas diferencias sutiles en otros dialectos SQL. Muchos DBMS aceptarán

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

como equivalente a

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

DB2 puede o no puede verlo, en función de las tablas. Cuando no lo hace, el primero puede ser muy lento. Dicho esto, si tienes un problema de rendimiento, hay algunas herramientas muy hábiles para analizar los planes de consulta DB/2; necesitará su asistente AS/400 para usarlos, ya que son un poco oscuros.

Si se encuentra en un entorno internacional, el manejo de las páginas de códigos necesita atención. Haga asegúrese de que todos sus AS/400s tengan la misma página de códigos del sistema.

Si está en una configuración multi-AS/400, tenga en cuenta que se puede acceder a las tablas locales y remotas de forma transparente (con paso a través).

OS/400 tiene una larga historia de amplia compatibilidad con versiones anteriores. Por lo general, no tendrá que preocuparse por las versiones, siempre y cuando todos los AS/400 con los que está hablando estén en la misma versión principal. También es una plataforma muy estable; los errores del sistema operativo son muy raros y se solucionan rápidamente.

Si puede administrarlo, obtenga acceso a un sistema de prueba con privilegio *ALLOBJ. Esto le permitirá enfocarse en el problema en cuestión y tratar los problemas de seguridad más adelante.

HTH

Answer 2

Ok, solía trabajar con AS/400 y sistemas de mainframe desde .NET hace varios años. Puede que no sea capaz de responder sus preguntas directamente, pero puedo informarle qué funcionó para mí y algunas de las cosas que hice en el pasado.

Un término común para este tipo de trabajo es Enterprise Application Integration (EAI) para que pueda comenzar leyendo sobre eso. Por lo que yo sé, es posible tener más que solo bases de datos DB2 en AS/400. Hubo 2 formas en las que trabajamos con pantalla verde (o herencia) aplicaciones:

1. un acceso a la fuente de datos/tiendas directamente
2. Crear una sesión, enviar pulsaciones de teclas, tales como F10, F4, etc., que la aplicación de legado utiliza para navegar a través de diferentes pantallas y tomar datos de puntos fijos en la pantalla heredada (esto a veces se llama raspado de pantalla).

Para responder parcialmente a la primera pregunta, para tener acceso a las fuentes de datos directamente creamos DSN (nombre de origen de datos) usando controladores ODBC que estaban disponibles a partir de 2 empresas en el momento, Rumba (hecha por Wall datos), y Attachmate (hecho por creo que IBM). Para crear un DSN de ODBC, normalmente ingresaba a Herramientas de administración/Fuentes de datos y agregaba un DSN del sistema. Necesitará el nombre de host (sistema heredado), el nombre de usuario para iniciar sesión y la contraseña. Luego usamos estos DSN dentro de las aplicaciones .NET para crear una conexión con las aplicaciones heredadas. Si tiene un DSN, puede usar algo como SQL Server DTS/SSIS para tomar datos del origen y guardarlos en alguna ubicación, ya sea la base de datos, los archivos CSV, los archivos de Excel, etc. También es muy posible que tenga una herramienta de informes (Crystal/SQL Server Reporting Services) accede a la fuente de datos directamente utilizando el DSN para que pueda informar directamente desde la fuente de datos. También probablemente podría crear conexiones DSN-less también, hace años necesitábamos DSN.

Para responder parcialmente a su segunda pregunta, es posible llamar y usar la lógica en las aplicaciones de pantalla verde si así lo desea. Una pantalla verde generalmente se divide en un número determinado de filas y columnas, y usamos un estándar llamado HLLAPI que envió las pulsaciones de teclas desde un sistema Windows a las posiciones en una pantalla heredada. Usamos Rumba para esto que estaba disponible como control OCX y estoy seguro de que Attachmate también lo está.Por ejemplo, podría crear un formulario de Winforms con cuadros de texto de ID de usuario y contraseña, luego crear una sesión para la aplicación heredada, y generalmente la primera pantalla sería una pantalla de inicio de sesión. Luego, usando las posiciones de los campos de nombre de usuario y contraseña en la pantalla verde, envíe la ID de usuario y la contraseña a esas posiciones, y luego envíe una tecla Enter o lo que sea necesario para iniciar sesión. Luego, puede navegar a otra pantalla, p. una pantalla de búsqueda, envíe los datos y las teclas para realizar una búsqueda, luego tome los datos resultantes de la pantalla verde. Otro enfoque es crear formularios Win/Web que repliquen la aplicación de pantalla verde y obtengan datos de los almacenes de datos directamente. La ventaja de esto es que no tiene que conocer las teclas/navegación de la aplicación heredada, que podría ser engorrosa para un sistema de pantalla verde grande. No está bien o mal, depende de las circunstancias. Nuestra compañía hizo una mezcla de ambos.

Para su tercera pregunta, depende del tipo de informes que desee. Si necesitan estar en tiempo real, entonces puede conectarse directamente al almacén de datos. Si no necesitan ser en tiempo real, podría hacer transferencias nocturnas de los datos del sistema heredado y almacenar los datos en SQL Server, por ejemplo, y luego ejecutar sus informes con los datos de SQL Server.

Una respuesta para su 4ta pregunta es que definitivamente necesitará poner sus manos en alguien que conozca la aplicación de pantalla verde. Pasará horas y horas revisando las pantallas de la aplicación heredada, por lo que acceder a los usuarios que conocen el sistema es crucial. También necesitará identificación de inicio de sesión y contraseñas, etc.

Finalmente, hay algunas empresas de terceros que se especializan en transferir datos de origen a destino, una de las que está por encima de mi cabeza es Data Mirror. Otro enfoque sería utilizar un producto de integración de nivel medio como BizTalk o Tibco, los cuales toman datos de una o más fuentes y los insertan en uno o más destinos, pero esto puede ser excesivo dependiendo de sus requisitos.

Espero que ayude y buena suerte :)

Answer 3

uso el acceso de cliente (de como se llame ahora) a los conductores a conectar con el servidor que creo que se basa en ADO.NET. A través de la versión del controlador que tengo (estamos en V5R4), no puede y tendría que crear procedimientos almacenados para llamar a los programas (lo que no es difícil). Creí haber escuchado sobre la última versión que puedes ejecutar programas, pero no estoy seguro.

La única otra cosa que consideraría es crear un usuario con solo las autoridades que necesita para hacer lo que debe hacer en caso de que alguien consiga ese nombre de usuario y contraseña, no pueden hacer demasiado. Hemos configurado un usuario de solo lectura (*USE) y un usuario de rwx (*CHANGE).

Answer 4

[lo siento no ver que esto es un antiguo puesto. Espero que todavía sea útil]

He escrito tanto la pantalla verde como las aplicaciones .Net. Desde mi experiencia ...

1. ODBC - funciona pero debe establecer la configuración ODBC en todas las PC del usuario. .NET Data Provider es mejor debido a más elementos .net específicos dentro y no es necesario establecer la configuración ODBC en todos los clientes. Antes del proveedor de .net disponible en as400, uso principalmente OLEDB. Consulte http://www-03.ibm.com/systems/i/software/access/windows/dotnet/ para obtener más información

2.Utilice los procedimientos almacenados. Procedimientos almacenados normalmente más rápido que poner todas las lógicas dentro de .net. Cree SQL o un procedimiento almacenado externo escrito en RPG, CL, COBOL, C++, etc ... No vuelvo a escribir toda la lógica anterior de RPG en .net, simplemente cambio poco el viejo programa RPG y lo hago en Externo almacenado procedimiento

3.Para los informes, use nuevamente los procedimientos almacenados que pasaron los conjuntos de resultados. Es rápido, más limpio y funciona bien con Crystal Report.

4.Detalles técnicos. Si tiene muchos clientes para instalar el programa, use los servicios web, no tiene que instalar el acceso de cliente con la versión correcta en todas las computadoras.

Mire su versión OS400. Si usa la versión V6R1 de OS400 y superior, asegúrese de que el acceso de cliente utilizado sea V5R4 o superior. Es posible que los procedimientos almacenados no funcionen bien en el Acceso de cliente anterior.

ODBC funciona en un acceso de cliente anterior, pero creo que .NET Data Provider solo funciona en V5R3.

Si compila el programa .NET utilizando .NET Data Provider V6R1, entonces el acceso de cliente del usuario también tiene que ser V6R1.

uso de procedimientos almacenados siempre que sea posible para la seguridad (no es necesario para exponer las tablas) y simplificar la lógica del programa (puede reutilizar programa RPG)

Por el lado OS400, asegúrese de que QCCSID valor del sistema se establece con CCSID adecuado p.ej 37 para inglés. El controlador ODBC, OLEDB, .net convertirá/traducirá automáticamente el carácter adecuado a su programa .Net. Nunca deje el valor como 65535.

Espero que esto ayude.