Skip to Content
avatar image
Former Member

Call function in update task

Hi experts,

I have a requirement to build a program where lot of objects will be created/updated.

For instance : Materials will be created/extended, classifications will be updated ..etc.

I know i have to build my solution using using the LUW technique ( everything or nothing principe).

But : some operations will depend on another . for example : i have to create change master ( transaction cc01 ) , the second operation have to change the classifications of that change master.

I get logic like :

- create change master.

- Use the id of change master , and assign classification to it .

call function xxx in update task : does not support exporting/returning parameters.

Could you please help me with some tips/sample codes


Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Nov 26, 2017 at 08:20 PM

    Unfortunately, SAP is limited. I assume BAPIs exist. Usually, you must commit the data between each called BAPI. In rare cases, there are BAPIs which use a buffer to inform other BAPIs about the updates being submitted to the update task, and you can commit only once after all BAPI calls (for instance, first BAPI "says" document number "$1" is created, where "$1" is not known before the update task is started, and you transmit "$1" to the second BAPI, and during the update task, "$1" will be replaced with the actual number).

    So, usually, you have to commit after each BAPI whose updated table data is needed by the next BAPI, and define a recovery program/procedure if one of the BAPIs fails.

    Add comment
    10|10000 characters needed characters exceeded

    • Hmm I never thought to call BAPIs from inside an update task. That's not the concept of update tasks (only updates, not the checks). I don't know what could be the conséquences (possible slowing of overall updates in the system as your code will take more time).

      Some BAPIs call function modules in an update task. In the ABAP documentation, I read that, during an update task, a function module called in update task is called immediately (as without IN UPDATE TASK).

      Be careful, there are old non standard BAPIs which are still doing a COMMIT WORK (would short dump within an update task).

      But I guess that technically it could work: call Z in update task + commit work, and the Z function module will call the BAPIs sequentially. Note that the update task can't return parameters, so you should store messages in a database table for instance. You should do a proof of concept.

      I hope other people will give their opinion.

      EDIT 1 hour later: in the update task, the rollback is possible only by triggering an error message (a direct rollback will trigger a short dump) + consequently there could be possibly many false update errors (because of errors during BAPI checks) in transaction SM13 so detect the possible errors before starting the update task + it's not possible to store messages in case of error because there's a rollback (or possible only via an extra database connection).

  • Nov 27, 2017 at 08:42 AM

    Maybe IN UPDATE TASK is not really what you're looking for. As Sandra Rossi pointed out, that is not really the concept for them. Also if used like this it might take up valuable system resources if plenty and long running.

    How important is the "everything or nothing principle" here? Are partial rollbacks ok if one steps fails?

    I think you are going to have to commit data between the steps, especially if you are creating/updating standard SAP-objects. And then you need to implement the logic for your steps forward and your rollback steps yourself (In the cases where rollbacks are actually neccesary). And of course, the solution will be depending on your requirements...

    This could of course easily be serialized in an online scenario (i.e. input data, loop over data, for each item, run the different steps in order, rollback if neccesary, loop finished, present result to user.)

    If you want to parallelize or not do this "online", you could also go for a Workflow-approach, where the different steps are called in turn and can pass data to each other. And also rollback steps when required.

    Or a simpler parallelization/offline approach that might work is to create the steps in a background job and execute immediately (i.e. FM BP_JOB_CREATE). This I think might use the least critical resources of the system.

    Add comment
    10|10000 characters needed characters exceeded