Desarrollo6 módulos15-18 días

Track Desarrollo

Plan de capacitación para desarrolladores: programar en IBM i, exponer servicios, integrar y automatizar el portafolio.

Progreso del track0 / 6 módulos

Objetivos y criterios

Track Desarrollo

Objetivo del rol

Programar sobre IBM i con tooling moderno, exponer servicios desde IBM i, integrar y extender los aplicativos del portafolio (Quick EDD, Connect CDC, Flash for i). Garantizar que las aplicaciones nuevas no rompan los pipelines de HA y CDC.

Audiencia y perfil

  • •Desarrolladores con experiencia (back-end, integración, DBA).
  • •Pueden venir de RPG/CL legacy o de stacks modernos (Node, Python, Java).
  • •Expectativa: trabajar tanto en código de aplicación como en automatización del operativo.

Prerequisitos

  • •Onboarding de empresa completo.
  • •Git y VS Code configurados.
  • •Cuenta de desarrollo en el laboratorio compartido (con permisos de cambio).
  • •Cuenta en portales Precisely Support y M81.

Día 0 común

2 horas. Base común de plataforma. Ver modulo-hardware.md y modulo-ibm-i.md.

Plan de capacitación

| Orden | Tema | Duración | Material principal | |---|---|---|---| | 1 | Hardware iSeries / Power | ½ día | Hardware — Para Desarrollo | | 2 | IBM i (sistema operativo) | 5 días | IBM i — Para Desarrollo | | 3 | AIX | 1 día | AIX — Para Desarrollo | | 4 | Assure Quick EDD | 2 días | Quick EDD — Para Desarrollo | | 5 | Connect CDC | 3 días | Connect CDC — Para Desarrollo | | 6 | Flash For i | 1 día | Flash For i — Para Desarrollo |

Total: 12½ días lectivos. Hasta 18 días con el proyecto integrador extendido.

Foco práctico del track

Capacidades que un desarrollador debe demostrar al final:

  1. •RPG IV / RPG free-form moderno — incluyendo opcodes nuevos de IBM i 7.5: SND-MSG, ON-EXCP, DATA-GEN (JSON/CSV desde RPG), FOR-EACH. Ver IBM i — Para Desarrollo.
  2. •CL para automatización y wrappers.
  3. •SQL embebido, stored procedures, IBM i Services.
  4. •APIs del sistema (QSY*, QC2*).
  5. •Servicios web — exponer programas RPG/CL como REST con Integrated Web Services.
  6. •Open source nativo en IBM i — Node.js, Python, PHP, Git vía RPM.
  7. •Code for IBM i en VS Code con Git.
  8. •Integraciones con Quick EDD (APIs, exits, automatización de role-swap), Connect CDC (configuración avanzada, mapping, transformaciones) y Flash for i (scripting alrededor del ciclo).

Laboratorio durante el track

  • •LPAR de desarrollo con Git, RPM-yum, IWS habilitado.
  • •Conector configurado a un destino Snowflake/Kafka de prueba.
  • •Quick EDD con un par source/target de práctica.
  • •Flash for i en modo de prueba.

Entregable de cierre

Proyecto integrador end-to-end. El desarrollador debe:

  1. •Crear un servicio en IBM i que exponga un dato del sistema vía REST/JSON, respetando journaling sobre los archivos involucrados.
  2. •Configurar un pipeline Connect CDC que replique cambios de ese dato a un destino externo (Snowflake o Kafka) en tiempo real.
  3. •Consumir el dato desde una app cliente (Node.js o Python) y verificar el flujo completo.
  4. •Automatizar monitoreo con scripts que envíen métricas/alertas de Quick EDD a la consola corporativa de monitoreo.

Documentación del proyecto:

  • •Diagrama de arquitectura.
  • •Código en repositorio Git.
  • •README con cómo desplegar y probar.
  • •Discusión de buenas prácticas aplicadas.

Criterios de aprobación

  • •Código RPG/CL legible en estilo moderno (free-form, modular, ILE).
  • •Journaling correcto sobre todos los objetos productivos creados; sin objetos huérfanos.
  • •REST funcional con manejo de errores.
  • •Pipeline CDC operando con cambios end-to-end visibles.
  • •Documentación completa.

Buenas prácticas que se enseñan explícitamente

  • •Toda biblioteca/objeto productivo creado en runtime nace journaled (caso contrario rompe Quick EDD y Connect CDC).
  • •Documentar contratos de datos hacia downstream (qué tablas/columnas son públicas).
  • •Cambios de schema con coexistencia — no borrar columnas usadas por CDC sin coordinar.
  • •Logs centralizados — mandar reportes a la consola corporativa.
  • •Versionado — código y configuración (Quick EDD scripts, Connect CDC pipelines) en Git.
  • •Test antes de prod — usar un clon Flash for i o el target de Quick EDD como ambiente de validación.

Mentoría y desarrollo continuo

  • •Code reviews con un desarrollador senior durante los primeros 60 días.
  • •Aporte continuo a librerías internas reusables.
  • •Renovación anual: nuevas TRs de IBM i (impactan opcodes RPG, IBM i Services), nuevas versiones de los aplicativos.
  • •Participación en COMMON, Common Europe, IBM Champions, blogs especializados (IT Jungle, etc.).

Recursos transversales

Módulos del track

Módulo 1

Módulo 1 — iSeries / IBM Power Systems (hardware)

½ día
Módulo 2

Módulo 2 — IBM i (sistema operativo)

5 días
Módulo 3

Módulo 3 — AIX (sistema operativo)

1 día
Módulo 4

Módulo 4 — Assure Quick EDD

2 días
Módulo 5

Módulo 5 — Connect CDC

3 días
Módulo 6

Módulo 6 — Flash For i

1 día

Agenda día por día

Agenda día por día — Track Desarrollo

Cronograma base de 12½ días lectivos (extensible a 18 con proyecto integrador prolongado). Bloques estándar: mañana 9:00–13:00, tarde 14:00–17:00.

Track completo: track-desarrollo.md.

Día 0 — Día común

14:00–16:00 (2 h). Historia, portafolio, vocabulario.

Día 1 (mañana) — Hardware (½ día)

  • •9:00–10:30 Contexto mínimo: dónde corre el código (LPAR, partition, IASP).
  • •11:00–13:00 Cuándo escalar al equipo de infra (saturación, IASP nuevo, cloud).

Material: Hardware — Para Desarrollo.

Días 1 (tarde) – 5 — IBM i (deep dev)

Día 1 (tarde)

  • •14:00–17:00 RPG IV / RPG free-form moderno. Procedimientos, service programs, activation groups.

Día 2

  • •9:00–13:00 Nuevos opcodes IBM i 7.5: SND-MSG, ON-EXCP, DATA-GEN, FOR-EACH. Práctica con ejercicios.
  • •14:00–17:00 IBM i 7.4 features para dev: ODBC nativo, idb-connector, paquetes Python ML, R, ActiveMQ. (Ver IBM i 7.4 features)

Día 3 — CL + SQL

  • •9:00–13:00 CL: wrappers, batch, automatización. Manejo de excepciones a nivel comando.
  • •14:00–17:00 SQL embebido en RPG/CL. Stored procedures.

Día 4 — DB2 for i + APIs

  • •9:00–13:00 DB2 for i avanzado, IBM i Services (OBJECT_STATISTICS, SYSTEM_VALUE_INFO, ACTIVE_JOB_INFO).
  • •14:00–17:00 APIs del sistema (QSY*, QC2*).

Día 5 — Servicios web + open source

  • •9:00–13:00 Integrated Web Services (IWS): exponer programas RPG/CL como REST. Observabilidad de IWS en 7.5.
  • •14:00–17:00 Open source nativo: Node.js, Python, PHP. Code for IBM i en VS Code con Git.

Material: IBM i — Para Desarrollo.

Día 6 — AIX

Mañana (4 h)

  • •9:00–10:30 POSIX + ksh / bash. cron. Compiladores xlC / GCC.
  • •11:00–13:00 PASE en IBM i — runtime AIX-compatible.

Tarde (3 h)

  • •14:00–17:00 Integración con el portafolio: Connect CDC con destino sobre AIX (Db2 LUW, Oracle), scripts de monitoreo en AIX, mksysb orquestado.

Material: AIX — Para Desarrollo.

Días 7–8 — Quick EDD (dev)

Día 7 — APIs y exits

  • •9:00–13:00 APIs y exits de Quick EDD (verificar versión exacta en docs Precisely).
  • •14:00–17:00 Lab: script de monitoreo que envía métricas a consola corporativa.

Día 8 — Automatización + buenas prácticas

  • •9:00–13:00 Lab: orquestación de role-swap automatizado para drills periódicos.
  • •14:00–17:00 Buenas prácticas en aplicación: STRJRNPF de objetos creados en runtime; documentar bibliotecas/objetos por release.

Material: Quick EDD — Para Desarrollo.

Días 9–11 — Connect CDC (dev)

Día 9 — Configuración como código

  • •9:00–13:00 Versionar configuraciones de pipeline en Git. Pipelines parametrizables (dev/QA/prod).
  • •14:00–17:00 Despliegue controlado.

Día 10 — Mapping y transformaciones

  • •9:00–13:00 Mapping declarativo, lookups, derivaciones. Cuándo transformar en CDC vs en destino (dbt/Snowflake/Spark).
  • •14:00–17:00 Lab: pipeline con transformaciones simples + tests.

Día 11 — Streaming + buenas prácticas IBM i

  • •9:00–13:00 Kafka (estrategia de tópicos, schemas Avro, particionado), Confluent Schema Registry.
  • •14:00–17:00 Buenas prácticas: tablas que nacen journaled AFTER/BOTH, contratos de datos, schema evolution con coexistencia.

Material: Connect CDC — Para Desarrollo.

Día 12 — Flash For i (dev) + arranque del proyecto integrador

Mañana (4 h)

  • •9:00–10:30 Wrappers en CL/Bash para encadenar Flash for i con otros pasos.
  • •11:00–13:00 Coordinación con scheduler corporativo. Integración con pipelines de datos.

Tarde (3 h)

  • •14:00–17:00 Kickoff del Proyecto integrador: definir alcance individual, repositorio Git, ambiente.

Material: Flash For i — Para Desarrollo.

Día 13 — Cierre del proyecto integrador

Día completo

  • •Implementar:
    1. •Servicio en IBM i que exponga un dato por REST/JSON, con journaling correcto.
    2. •Pipeline Connect CDC que replique cambios a destino externo.
    3. •App cliente (Node.js/Python) que consuma el dato.
    4. •Monitoreo automatizado de Quick EDD a consola corporativa.
  • •Entrega final con documentación, código en Git, README.

Material: Entregable — Track Desarrollo.

Días 14–18 (opcional)

  • •Proyecto integrador extendido con features extra (más transformaciones, más fuentes/destinos, schema evolution real).
  • •Code reviews con dev senior sobre el proyecto.
  • •Aporte a librerías internas reusables.

Recursos del track