Checkpoint del Módulo 4

Con los Módulos 3 y 4 tienes las dos mitades de casi cualquier automatización: leer y escribir. A partir del Módulo 6 las meterás dentro de triggers, donde el volumen no lo eliges tú. Este checkpoint es el ensayo general.

Lo que has aprendido, sub-lección a sub-lección

1 · DML. insert, update, delete, undelete y upsert son las operaciones de Data Loader. insert rellena el Id; update necesita el Id; upsert decide por un Id externo. Todo DML pasa por validaciones, flows y triggers.

2 · Resultados parciales. La instrucción es todo o nada; Database.insert(lista, false) guarda lo que puede y devuelve un SaveResult por registro, en el mismo orden: tu success.csv y error.csv. Parcial nunca significa ignorar los errores.

3 · Bulkificación. Los registros llegan de 200 en 200. Ninguna consulta ni DML dentro de un bucle: juntar en un Set, consultar una vez con IN, trabajar en memoria, guardar una vez. Map para no duplicar Ids.

4 · Governor limits. 100 consultas, 150 DML, 50.000 filas leídas, 10.000 filas escritas, 10 s de CPU, 6 MB de heap, por transacción y compartidos con los flows. LimitException no se captura. La clase Limits mide.

5 · Savepoints. Database.setSavepoint() marca y Database.rollback() vuelve: deshacer una parte y seguir. Cuestan DML, no devuelven límites y no borran los Ids de tus variables.

La nutria: La lista de revisión que ya usas con Flow

Antes de activar un Flow desencadenado por registro, yo siempre me hacía tres preguntas: ¿hay Get Records o Update Records dentro de un Loop? ¿Qué pasa si Data Loader carga 200 registros? ¿Qué pasa si falla un Create Records? Son exactamente las tres preguntas de este módulo: bulkificación, límites y manejo de fallos. Háztelas con cada bloque de Apex.

La nutria: ¿Y por qué no un Flow? El escalado sí; el resumen, no

Un flow programado sobre los casos de ayer podría escalar los de cuentas Hot (mirando $Record.Account.Rating) y crear las tareas. Pero Soporte quería cada mañana un resumen: cuántos se escalaron y cuántos fallaron. En un flow programado cada caso es una interview independiente, con sus propias variables, así que no hay un contador común para los 200. En Apex el proceso ve los 200 a la vez y los SaveResult te dan el recuento.

Ahora en tu Developer Org

1. En Developer Console → Debug → Open Execute Anonymous Window, ejecuta tu solución del ejercicio de la lección 1. Busca Nimbus Logistics en la interfaz: ahí están la cuenta y sus dos contactos.
2. Ejecuta delete [SELECT Id FROM Account WHERE Name = 'Nimbus Logistics']; y abre la Papelera: la cuenta está allí. Recupérala con undelete, usando ALL ROWS en la consulta.
3. Provoca el límite a propósito: for (Integer i = 0; i < 151; i++) { insert new Task(Subject = 'Prueba ' + i); }. Lee el error: «System.LimitException: Too many DML statements: 151». Luego busca las tareas «Prueba»: no hay ninguna. La transacción se deshizo entera.
4. Ahora la versión bulkificada: añade las 151 tareas a una lista dentro del bucle y haz un solo insert fuera. Funciona. En el log, con Debug Only desmarcado, busca LIMIT_USAGE_FOR_NS: «Number of DML statements: 1 out of 150». Borra después esas tareas.
5. Guarda la clase LimitsReport de la lección 4 en Setup → Apex Classes → New, y llama a LimitsReport.log('fin') al final del ejercicio de este checkpoint.

El diccionario completo: de Data Loader y Flow a Apex

La nutria: Lo que no se traduce: tú eres el responsable

Te lo digo por experiencia: Data Loader te enseña el error.csv aunque no lo pidas, y Flow Builder te advierte de algunas malas prácticas. En Apex nadie te avisa: si no guardas los SaveResult, los errores desaparecen; si pones una consulta en un bucle, compila igual. Por eso la receta de esta lección no es un truco de estilo, es la lista de comprobación que un revisor aplicará a tu código antes de dejarlo pasar a producción.