Commit de varias bapis

[jtristan]

Hola,

estoy utilizando las bapis:
-BAPI_GOODSMVT_CREATE
-L_TO_CREATE_MULTIPLE

Quiero, que en el caso de que algo fallase en la segunda, la primera no tuviese efecto.
He probado ha hacerlo con un IN UPDATE TASK pero creo que ninguna de las dos funciones tienen esta opción.
He probado con un BAPI_TRANSACTION_COMMIT al final de las bapis, pero tampoco he conseguido que no se grabase en la base de datos la primera.

¿Cómo podría hacerlo?

Muchas gracias.
Un saludo.

[Neo_25]

Rollback

Si la segunda falla, no podrías hacer: ROLLBACK WORK ?
Y si la segunda va bien COMMIT WORK

[jtristan]

Hola, si, he intentado cancelar las dos con un rollback. Al ser bapis he leido que tenía que usar el BAPI_TRANSACTION_ROLLBACK en vez del ROLLBACK WORK a secas. Pero a pesar de pasar por el rollback, los movimientos figuraban en la base de datos.

Muchas gracias.

[Neo_25]

Te digo de memoria,
algunas BAPIS tienen un indicador a 'X' para que la haga pero que no lo ejecute, q no se grabe. Es como si no se hubiera hecho.
Podrías hacer las dos de esta manera y si la segunda va bien las haces con la condición en blanco.

Harías dos veces las bapis, pero así realizas esa comprobación.

[jtristan]

voy a mirar si en estas dos bapis encuentro ese indicador. No me importa tener que hacerlo así, no me va a incrementar el código y al menos se quedará seguro.
Lo miro y os digo.

Muchas gracias.

[jtristan]

Los tiros iban por ahí. En la segunda bapi, la L_TO_CREATE_MULTIPLE, he dejado el i_update_task = 'X' y el i_commit =' '.
En la primera bapi, la BAPI_GOODSMVT_CREATE, que no tiene estas opciones, he utilizado el SET UPDATE TASK LOCAL.
Como he utilizado el update task en la primera, imagino que en la segunda no haría falta. Voy a probarlo.
Después con un commit work o un rollback work, en caso de fallo, funciona correctamente.

Muchas gracias.
Un saludo.

[Neo_25]

Ya lo encontré,
yo llamé a la BAPI: BAPI_SALESORDER_CHANGE

1 con el flag --> simulation = pi_simulacion "X

2 recogí la tabla return --> return = po_return

3 si en la tabla había algún error -->
CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.

4 si no había error --> vuelvo a llamar a la BAPI con
simulation = pi_simulacion "blanco ' '

5 finalizo --> CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'

Yo hice esto, intenta adaptarlo y prueba

Saludos

[jtristan]

Hola,

ninguna de estas dos bapis tiene el parámetro simulación, aunque me parece muy útil sabe que si que existe para algunas.
Por el momento, pudiendo trabajar con LUW me funcinona.

Muchas gracias.
Un saludo.

[ballan]

Para poder dar una respuesta correcta se necesitarian mas datos

Si cuando llamas a la L_TO_CREATE_MULTIPLE NO necesitas que se haya creado previamente el movimiento podrias hacer lo siguiente

CALL FUNCTION 'BAPI_GOODSMVT_CREATE'
...
TESTMODE = 'X'.

CALL FUNCTION L_TO_CREATE_MULTIPLE
COMMIT WORK = space


IF SY-SUBRC IS INITIAL.

CALL FUNCTION 'BAPI_GOODSMVT_CREATE'
...
TESTMODE = SPACE.

COMMIT WORK AND WAIT.

ELSE.

ROLLBACK WORK.

ENDIF.

Si cuando llamas a la L_TO_CREATE_MULTIPLE SI necesitas que el movimiento se haya creado previamente entonces forzosamente tendras que crear el movimiento, despues llamar a la L_TO_CREATE_MULTIPLE y si esta falla tendras que CANCELAR el movimiento o bien con la BAPI_GOODSMVT_CANCEL o bien haciendo un batch input contra la MBST

[jtristan]

El problema sobre todo lo tengo para casos en que la bapi, no me devuelve un error capturable, o al menos yo no sé capturarle. Es decir, cuando se produce un error, que directamente te saca del proceso a la dynpro en la que estabas y te muestra el texto del error.
Si pasa esto al crear una ot, no tendría forma de anular el documento material (al menos desde el propio programa).
Por ello, las opciones de empezar un SAP LUW y que no grabe nada hasta hacer el commit es lo más seguro que se me ocurre.

Muchas gracias.
UN saludo.

[ballan]

Creo que ya entiendo lo que dices

Cuando la L_TO_CREATE_MULTIPLE da un error creo que te aparecia como una dynpro en blanco donde te sale el error y te saca de la ejecucion del programa

Para evitar esto puedes utilizar un truquillo, llama a la funcion de esta manera

CALL FUNCTION 'L_TO_CREATE_MULTIPLE' DESTINATION 'NONE'.
...

Al añadirle el destination la llama por RFC y asi no te saca de la ejecucion si da un error

No recuerdo bien si habia que poner destination 'NONE' o 'BACK' asi que prueba con los dos