Prefacio

RpgForWeb es un entorno para Facilitar las Aplicaciones Gráficas y Web dentro de la familia de Servidores IBM iSeries i5 (AS/400).

Desde el punto de vista de Desarrollo de Aplicaciones, RpgForWeb permite crear programas separados en dos capas: la lógica principal en RPG y la presentación en HTML.
Uno de los objetivos más obvios de ésta orientación es que los actuales profesionales RPG del entorno 400 puedan implantar soluciones Web sin tener que usar otros lenguajes o entornos que no conocen, así cómo utilizar partes de código existente.

El deseo principal de la comunidad de Usuarios es "que se puedan usar los programas actuales". Esto indica claramente que se consideran muy valiosas las aplicaciones existentes y no se quiere reprogramar, que és básicamente lo que hay que hacer si se quieren modernizar las Aplicaciones llevándolas a otros lenguajes y entornos cómo Java o .Net.

Desde luego puede usarse RpgForWeb para cambiar los programas con cierta cantidad de trabajo no muy grande, pero no pequeña, y el enfoque de persistencia (o de la falta de ella) en el modo de trabajo Web acompleja la comprensión de la solución.
Por tanto se percibe una resistencia a la migración de Aplicaciones, creándose la opinión de que RpgForWeb es mejor, o sólo, para nuevas aplicaciones.

qué estamos pensando

Estamos pensando, dentro de la tecnología RpgForWeb, simplificar, facilitar, los dos componentes que darían una mejora sustancial en la migración o conversión a modo Web de las Aplicaciones Tradicionales. Las dos maravillas resumidas serian:

• Separar la capa de presentación del programa.
   
• Soportar Persistencia real.

El objetivo es, por tanto, permitir que los actuales programas 400, mediante una conversión automatizada (aunque seguramente no del todo automática), corran en un entorno Web con pantallas HTML y lógica en RPG.

Objetivo de tanto párrafo:
Permitir que los actuales programas 400 corran en Gráfico y Web
con pantallas HTML y lógica RPG.

Veamos estas dos maravillas "explicadas".

Separar la capa de presentación

Los programas tienen ahora juntas, embebidas, las funciones de lógica y presentación: el mismo programa fuente contiene sentencias para todas las funciones, incluyendo el tratamiento de pantallas 5250.

Pretendemos separar la capa de presentación del programa (pantallas), dejándolo como un programa Batch y cambiando las funciones de Entrada/Salida de pantallas por funciones de conversación con la capa de presentacion Gráfica Web.

Para mayor facilidad, usaremos un convertidor mejorado de pantallas dds-dspf a html (Migration Wizard) para convertir la funcionalidad y apariencia, de forma que sólo requiera tiempo la mejora de la presentación o ciertas funciones complejas.

Soportar Persistencia real

Para que un programa tradicional tenga que sufrir menos cambios (en orden a incorporar en él funciones Web), queremos permitir un nuevo método de comunicación en RpgForWeb soportando persistencia real, de forma que el programa funcione igual que si tuviera pantallas, parándose en un EXFMT/READ y esperando que llege la entrada, etc.
Es decir, el programa de usuario no tiene que terminar para enviar html, sino que el programa permanece "activo" y en espera mientras que se presenta la pagina html y el usuario final teclea en el navegador, de forma que cuando el navegador envia datos el programa "resucita" en el punto adecuado, lee la entrada, etc.

Soportar la persistencia simplificaría enormemente la tarea de programar en Web, ya que ésta es la forma en la que trabajan ahora los programas tradicionales, y no se tienen que comprender los problemas (o forma de trabajar) derivados del método Web de trabajo sin persistencia.

En RpgToWeb, el soporte de la persistencia no se hará "atosigando" o "dejando parada" la instancia del servidor http, sino que la instancia http queda liberada mientras el usuario final ve la pagina presentada y teclea en ella.
El programa de usuario asociado con la instancia corre (parado, sin gastar recursos) en un trabajo batch separado, de forma que sólo cuando el usuario final teclea y envia los datos,  se vuelve a producir una entrada de trabajo en la instancia http, la cual se relaciona con el programa final del usuario que la estaba "esperando".

(si no lo entiendes vuelve a leerlo despacito)

RPG TO Web

Así que a toda ésta parafernalia vamos a llamarle RpgToWeb, contando con el dominio www.RpgToWeb.com en internet.

Ya que RpgForWeb (abreviado R4W o R4) significa "RPG para la Web", RpgToWeb (abreviado R2W o R2) significará "RPG hacia la Web", dando la idea de "convertidor". El caso es identificar con un nombre éste nuevo enfoque.

RpgToWeb sería, por tanto, un servicio añadido en RpgForWeb con el que se contaría en el caso de que nos enfrentemos a una migración de una aplicación existente.

el programa funciona igual ?

Qué queremos decir con "un programa convertido con RpgToWeb funcionaría igual"?

...pues eso... que la parte principal o total de cómo funciona el programa es RPG, compuesto por el tipo de instrucciones que ya conoces, y siendo capaz de crecer usando todo lo que te permita RPG IV.

Y CL? ...DB? ...LDA? ...Call ...?

Casi no hablamos de ésto, porque, en principio, lo soportaremos todo!

Toda la Base de Datos existente es compatible, ya que el objetivo es mantener los mismos programas sólo que "quitándoles las pantallas".

CL y por tanto DtaAra, Lda, etc no habrá que tocarlas a no ser que exista alguna cosa incompatible cómo presentación de mensajes, pantallas, cosas en general no compatibles con el entorno Web y que habría que retocar dependiendo del contexto.

Call entre programas está soportado, aunque si estos programas hacen algo incompatble con Web tendrían  que ser modificados adecuadamente. Si los programas llamados son de pantalla, "simplemente" se convierten como tales programas de pantalla.

La riqueza de funciones de programación en AS/400 es tan grande, y permite tal cantidad de combinaciones, que nunca será esperable que cualquier función se podrá convertir automáticamente o con muy poco trabajo. Algunas funcionalidades deberán ser retocadas, aunque dentro del marco RPG, otras funciones será mejor trasladarlas al Browser, etc.

Ejemplo de algunas funciones que tendrán que ser cambiadas (no están todas las que serán, es una lista ejemplo):

• Manejo de Entrada y Salida de Pantallas en CL. Deberá crearse un pequeño programa RPG para sustituirlo.
• Subficheros de mensajes quizá haya que retocarlos
• Programas que presenten pantalla que no puedan convertirse (p.e. por no tener los fuentes).
• ciertas funciones de pantalla demasiado particulares como algunos overlay, etc.
• en general, funciones demasiado rebuscadas necesitarán ser cambiadas, al igual que otras funciones que no tienen sentido en Web y que necesitarán pequeños retoques.

Subficheros?

Será parte fundamental de toda migración.

 RpgToWeb convertirá y soportará el modo de uso de Subficheros con sus elementos característicos como separación en dos registros de pantalla (control y líneas) e incluso en tres (pie), úniendolos en una sóla página html con tabla embebida -tal como permite RpgForWeb- y soportando las actividades de limpieza o inicialización, carga de detalles, lectura de registros cambiados, etc .

Sin embargo en subficheros y pantallas en general existen ciertas funciones o modos de uso, potenciados por la impresionante flexibilidad del 400, que no son habituales en los documentos con formularios en la Web.

Desde luego, las funcionalidades "normales o básicas" de subfichero las vamos a soportar, y para nosotros esto significa soportar mucho, pero seguramente todos los subficheros necesiten algun retoque, siempre tocando algo de html y algo de RPG.

Además creemos que los subficheros se podrán mejorar en ciertos aspectos, no sólo visiblemente, sino que podrá presentarse un mayor número de líneas, insertar líneas de totales, incluso añadir más campos a cada línea y alguna otra funcionalidad.

en qué entorno funciona el programa convertido?

En RpgForWeb. Por lo tanto:

• Servidor es un iSeries o AS/400, usando Apache HTTP Server, el estándar mundial. Los Ficheros de Base de Datos son los tuyos, Los ficheros Web html, js, csss... también en el IFS del iSeries.
   
• Cliente es cualquier pc o aparato (PDA, Movil...) que soporte un navegador de internet: sin instalar nada!
   
• Puede soportar PC Linux o Mac ya que RpgForWeb no anda en un PC sino en un navegador (browser)
   
• funciona en lo que ya conoces! nada que aprender!

Migramos automáticamente?
o trabajando duro?

Cada programa (y no digamos cada programador) es un mundo.

Una parte grande del análisis y una parte quizá menos grande de la conversión pensamos que puede llegar a hacerse automáticamente.
Esto permitiria actuar con rápidez y eficacia y con pocos errores, por ejemplo garantizando que la apariencia de las pantallas será equivalente, que los textos y longitudes de campos seran iguales etc, todo lo que supuestamente se quiere que exista en una conversión automatizada.

Cada aplicación requerirá una interpretación, comprensión, conocimiento del medio, capacidad de tomar decisiones, que será labor de profesionales que conozcan el lenguaje usado (RPG y RPG4 en éste caso), combinado con conocimiento de RpgForWeb + RpgToWeb y del necesario HTML, js, css, etc.

El manejo de las utilidades windows de RpgForWeb hará posible también mejorar las aplicaciones dándoles más calidad, profesionalidad, seguridad y rapidez.

• El convertidor de pantallas existentes dds-dspf a html (dspf Migration Wizard) con plantillas personalizables.
   
• El html Page Wizard para diseñar nuevos formularios html. Este wizard es también muy importante -en cualquier caso- para programas nuevos R4, ya que simplifica y potencia el diseño de formularios Web de forma parecida a cómo hace ADP400 con programas de pantalla.
   
• El  Translate Wizard para Soporte Multi Idioma. en caso de que la aplicación Web final necesite varios idiomas (español e ingles, etc).

Alguna clase de funcionalidades quizá sea necesario personalizarlas o adecuarlas al nuevo entorno Web, que pueden costar tiempo extra pero que también pueden mejorar en general la aplicacón. Piénsese que en una Aplicación Web es más fácil implantar funciones de Imágenes, E-Mail, etc (bueno, nosotros tambien lo hacemos en las aplicaciones verdes, pero ese es otro cantar).

Si un grupo de programas tradicionales ha costado cientos o miles de horas en desarrollo, qué porcentaje de tiempo y costo está el usuario dispuesto a poner para pasarlo a Web?
Cada uno va a contestar de forma diferente, pero otras alternativas no van a costar menos.

Incluso algunos maquilladores cuestan tiempo y dinero.

Algún otro "casi convertidor" que pueda existir, con una garantía de rapidez y eficacia muy lejana del 100% cuestan horrores de tiempo y dinero, con la desventaja de que luego ¿como mantienes esas aplicaciones?

Cualquier objetivo simple es convertir todo, y bien. Pero razonablemente debemos pensar que siempre existirá un porcentaje imposible y/o que necesita retoques, los cuales se irán viendo con el tiempo si pueden documentarse o incluso mejorar la conversion. Lo que sí es un objetivo es que en "poco tiempo" se pueda convertir una Aplicación o Grupo de Programas.

Esto será un maquillador?

NO.
Una vez que los programas fuente tengan separada la capa de presentación, cada una de las dos capas (html para presentacion, RPG para lógica de negocio) se puede modificar por las tecnicas normales, de forma que la apariencia y funcionalidad de la aplicación puede ir cambiando.

Esto es mucho mejor que un maquillador que no deja de ser la misma pantalla andando en un browser, y que puede requerir además el manejo de otras aplicaciones o entornos.

Cómo se convertirán las pantallas?

Se convertirán "bien".

La mayoría de las funciones, apariencia y exactitud de constantes etc se respetarán, aunque no pretendemos que la pantalla "parezca" una 5250 convertida, razón por la cual no vamos a respetar las posiciones exactas (para lo que habría que usar un font fijo y feo). Creemos que es mejor dedicar unos minutos tras la conversión a ubicar los campos más adecuadamente al entorno html usando tablas o css, ya que de ésta forma estamos realmente usando el estándar, y el mantenimiento futuro será más fácil y con más posibilidades.

Para mayor potencia, apariencia y capacidad de mantenimiento futuro, la conversión de la apariencia se hace a través de varias plantillas predefinidas (se podrán añadir más, incluso por el usuario), y que están basadas en css.

Existirán dos grupos básicos de plantilla, uno para que las teclas (convertidas a botones) aparezcan a la izquierda y otro para que aparezcan debajo.

Las plantillas tendrán básicamente cuatro cuerpos:

• cabecera para logo y nombre de Empresa o Aplicacion,
• parte izquierda para teclas, menu, etc,
• parte central con los datos de la pantalla en si
• y pie para poner zona legal, links etc.

Las plantillas, y las páginas web en general, soportan SSI (Server Side Includes), con lo que se pueden crear zonas repetibles en todas las pantallas, que se cambian simplemente cambiando en un solo sitio el contenido. Ideal para mensajes cambiantes según la temporada y otros mil usos.

Ejemplo de conversiones segun plantilla y colores personalizables

Después de Convertir?
¿Mantener? ¿Mejorar?

Un programa RPG al que se le haya quitado/separado la capa de presentación... que es?
Pues eso es: un Programa RPG Batch.
Así que se mantiene como cualquier otro programa batch, se puede editar con PDM/SEU o con CODE, se puede compilar, debugear, etc.

La parte de presentación es HTML con algunos añadidos de js y css, cosas que están a la orden del día y se pueden aprender en poco tiempo, además que són la substancia básica de la Web y es bueno conocerlos de cualquier forma.

Una vez que la Aplicación está "convertida" sería fácil o muy fácil implantarle cambios tal como:

• cambiar preguntas cortas (tipo Si/No) por option button.
• cambiar listas pequeñas (tipos de cliente, delegaciones...) por combo box.
• insertar fotos, imágenes relacionadas con campos variables
• hacer que los subficheros no tengan el tope de ancho y alto, hacer listas con 50, 100 o más filas y con más campos por cada línea, lineas de totales con otros colores...
• añadir más campos en una "pantalla" de los que físicamente caben en una pantalla de 400.
• toda clase de mejoras que soporta en entorno de navegador, tipos de letra, colores, imágenes fijas y variables, etc etc.

Qué es ésto de que corre en Batch?

Un programa RPG al que se le haya separado la capa de presentación y ésta se haga con RpgForWeb funciona en el entorno Batch del 400 en lugar del entorno Interactivo.

Esto significa que NO necesita la parte de Interactivo del iSeries 400, la cual cuesta dinero y a veces mucho dinero.

Debe tenerse en cuenta que si la misma máquina se usa para usos interactivos, cómo manejo de PDM y SEU por parte de los programadores, etc, será conveniente contar con un mínimo de interactivo o estudiar el uso de herramientas tipo Code400 que no hagan uso de la tarjeta interactiva.

Sólo anda en i5?

Anda en cualquier IBM iSeries i5 o AS/400 a partir de la version v4r5. Quizá ande en alguna versión anterior como v4r4, pero mejor cuanto más cerca se esté de la ultima version IBM (ahora v5r3).

El modelo de máquina puede ser "solo batch" o normal, y se soportan incluso máquinas anteriores como 270, 820, incluso 170 dependiendo de la versión del OS/400 instalada, etc.

Requiere Websphere o Java?

No.
Pero puede convivir con ellos si se desea.

Requiere algún servidor PC?

No.
los PC se pueden usar como cliente, para acceder a la aplicación usando un navegador.
También pueden usarse PC por parte de los programadores/diseñadores para las tareas de diseño de páginas Web, etc, pero no por necesidades de ejecución de Aplicaciones.

No hablamos de Cobol?

Ciertas tareas automatizadas, así como buena parte del "know-how" está basado en RPG.
Con trabajo y ayuda de expertos Coboleros podremos usar ciertas funciones para ayudar a convertir programas Cobol, pero nuestra intención primaria es RPG.

Esperemos que más adelante, o ante una propuesta más concreta, podamos abordar algo de Cobol.

un ejemplo?

Una pantalla tradicional cambiada un poco de aspecto es demasiado obvio para lo que se pretende obtener.

El convertidor de pantallas incluye diversas plantillas, que son además personalizables fácilmente, por lo que la apariencia dependerá de diversos factores.

Tú también puedes Ayudar!

Por una parte, conociendo el objetivo, estariamos encantados en recibir ideas, sugerencias, cuidados a tener con tal cosa, etc.

Y lo más importante puede ser enviarnos ejemplos de programas reales, mejor poco complejos, o varios indicando su nivel de complejidad aparente. sería ideal que los programas fueran pequeños en su extensión fuera de las funcionalidades de pantalla, nos va a dar igual si el programa tiene catorce rutinas para calcular no se que cosas sobre el ratio de probabilidad de concesión de creditos, ya suponemos que eso va a seguir andando.

Los ejemplos mejores serian con uno o pocos ficheros no muy grandes, y que todo (programas, fuentes, objetos, ficheros) estuviera en una sola biblioteca. Esa biblioteca salvada a un *SAVF y bajada al pc con FTP-Binary. Si es posible salvados en la mas antigua posible version del operativo. v4r5 estaría bien, aunque también tenemos máquinas con V5R3.
Fuentes pueden ser RPGIV o RPG. Si son RPG los convertiremos a RPG4 con el comando CvtRpgPgm de IBM.

Programas sencillos pero funcionales con solo pantallas, con uno o con varios subficheros y con la menor complejidad adicional posible serian los ideales, pero mas vale tener algunos complejos que no puedan desacomplejarse que no tener ninguna para probar.

Claro que nosotros tenemos programas para probar, pero todos estan hechos con ADP400 y queremos tambien probar programas que no se hayan hecho con un Generador sino "a mano".

Fin del Documento

RpgForWeb está orientado a CREAR programas en entorno gráfico y Web usando RPG en IBM iSeries 400. Se pueden reusar partes existentes.

RpgToWeb permitirá convertir más fácil, más rápido las Aplicaciones Tradicionales, separando la capa de presentación en los programas RPG y convirtiéndola en html.

RpgToWeb incluye algunas funciones automáticas, otras de ayuda al diseño y, en general, una metodología de migración de programas. Esto permitirá que las Aplicaciones Tradicionales sean llevadas al mundo Gráfico y Web por los mismos profesionales del 400.

Sólo con RpgToWeb se mantiene el know-how en RPG. No hay miedo a que los programas se reprogramen con errores de lógica.

Programar en varias capas es el futuro, y si además lo conseguimos en poco tiempo y con poco coste...

La migración la puede hacer la misma gente que conoce las Aplicaciones y el Servidor Empresarial. Damos valor a lo que sabemos que anda.

Toda la Base de Datos, los CL, LDA, dtaara, incluso la llamada con Call entre programas, todo compatible.

No gastes tiempo ni dinero con un simple GUI o pintador, a partir de la migración estás programando en "moderno", pero con lo que ya conoces!

BATCH = Menos Coste

Los programas convertidos funcionan en el entorno BATCH del 400, por lo que puede funcionar en máquinas más pequeñas o económicas, sin necesitar el entorno interactivo.

Y tus programas siguen siendo RPG, y los mantienes con SEU o Code400, etc.

Una vez migrado se pueden mejorar las pantallas, subficheros, etc con todas las funcionalidades que permite html, javascript, css, etc.

Tú mandas en la apariencia

Como Servidor Web http se usa el estándar mundial APACHE, integrado sin cargo en el iSeries 400.

Las Aplicaciones migradas se pueden acceder desde dispositivos de todo tipo que soporten un navegador Web, incluyendo PC's pero también PDA o Móviles. Y sin instalar nada!

No estamos haciendo nada raro,
Usando Apache, HTML y CSS, el verdadero estándar de la Web,
y RPG IV para iSeries 400, el verdadero estándar de las Aplicaciones Empresariales.

RPG no es lo que alguna gente cree o intenta hacer creer. RPG IV es un auténtico nuevo lenguaje con mejoras continuas desde hace años y con cantidad de nuevas y poderosas funciones.
No te dejes engañar: no hay nada que no puedas hacer con tu RPG.
Y ahora con RPG For Web: lo que faltaba!

Los Clientes pueden tener soporte y consultoría directa de CPI Software y de los Partners aprobados para asegurar la mejor calidad y eficiencia en la Migración y Desarrollo de Aplicaciones.