Per què CALL TRANSACTION falla en mode de procés automàtic per a certes transaccions

Aquest és dels que et fan dubtar del teu propi codi: l’automatització amb CALL TRANSACTION funciona perfecte quan la proves en diàleg, funciona perfecte per a la majoria de transaccions en background… i falla, silenciosa o sorollosament, per a una transacció concreta.

El símptoma

El job acaba “bé” (no hi ha dump), però el document no es crea, o es crea a mitges, o la BDCMSGCOLL retorna missatges que no tenen sentit amb el que veus si executes la transacció a mà. De vegades l’efecte és pitjor: el CALL TRANSACTION simplement penja el job fins a timeout.

La causa real

CALL TRANSACTION simula la interacció d’un usuari navegant per pantalles: omple camps de dynpro i “prem” el botó que li indiquis (ENTER, BACK, etc.), segons el mapping BDC que li passis. Això assumeix que la transacció es comporta igual davant d’un usuari que davant d’un batch input. No sempre és així.

Moltes transaccions —sobretot les que tenen lògica personalitzada en user-exits, BAdIs, o simplement codi antic— comproven explícitament el mode d’execució:

IF sy-batch = abap_true.
  " comportament diferent: es salta una validació,
  " no dispara un POPUP, canvia el flux de pantalles...
ENDIF.

IF sy-binpt = abap_true.
  " sy-binpt indica "estem en batch input",
  " i aquí és fàcil trobar codi que assumeix
  " que certs camps ja venen omplerts
  " d'una pantalla anterior que en el teu mapping no existeix
ENDIF.

Quan la transacció té un CALL SCREEN condicional (per exemple, un popup de confirmació que en mode diàleg es mostra però en batch input se salta o s’autoconfirma amb un valor per defecte que no és el que tu esperaves), el teu mapping de camps deixa d’encaixar amb la seqüència real de pantalles. El resultat és justament la mena de fallada silenciosa descrita més amunt.

Com confirmar-ho

Abans de perdre hores ajustant el mapping BDC a cegues:

1. Executa la transacció a mà en mode “Mostra totes les pantalles” des de SHDB gravant la mateixa seqüència que intentes automatitzar, i compara el nombre i ordre de pantalles amb el teu mapping.
2. Revisa si la transacció crida algun BAdI/user-exit conegut que consulti sy-batch o sy-binpt — un SE24/SE18 amb “on s’usa” sobre aquestes variables del sistema en els includes de la transacció sol delatar-ho ràpid.
3. Comprova el mode de CALL TRANSACTION que estàs usant: 'A' (totes les pantalles, per depurar), 'E' (només errors) o 'N' (sense pantalles, el que faries servir en background real). El comportament pot variar entre aquests tres.

La solució que funciona

Quan confirmes que la transacció té lògica depenent del mode d’execució, seguir insistint amb BDC és lluitar contra l’estàndard. Les alternatives que sí que funcionen, de millor a pitjor:

1. Usar la BAPI o funció estàndard equivalent, si existeix, en lloc de simular pantalles. La majoria de transaccions de creació de documents (comandes, factures, materials) tenen una BAPI al darrere que no depèn de dynpros ni de sy-batch.
2. Si no hi ha BAPI, aïllar el problema amb un mapping BDC específic per a mode batch (de vegades la solució és tan simple com afegir un valor de camp diferent només per a aquest escenari, no reescriure tota la lògica).
3. Com a últim recurs, i només si res del que precedeix és viable, CALL TRANSACTION en mode 'A' amb gestió d’excepció per al popup concret — més fràgil, però explícit sobre què estàs forçant.

La lliçó

CALL TRANSACTION no és “gravar i reproduir”: és simular una interacció amb una pantalla que pot comportar-se de manera diferent segons el context d’execució. Quan alguna cosa falla només en background, la primera sospita no hauria de ser el teu mapping — hauria de ser com la transacció tracta sy-batch i sy-binpt.