BAPI_COMMIT not working in background

[Former Member]

Hi All,

I am using BAPI_SALESORDER_CHANGE in my program to update field VBKD-EMPST and additional custom status (VBKD-KDKG5) in Contracts and then calling BAPI_COMMIT. I have a job scheduled in the background for this Program.

After the program has finished running we found that some of the contracts are not updated. This occurs randomly. The same program works fine and all contracts are updated correctly if running in the fore ground. There's nothing peculiar about the contracts that are skipped. When we run the same program in the foreground for the skipped contracts, they are updated correctly. Please provide your valuable suggestions as this is an Urgent Issue and has been buggibg us for a very long time.

Thanks,

Raj.

[Former Member]

Have you confirmed that no users have the failed contracts opened in Change Mode - a record lock would cause this problem.

[Former Member]

Raj,

This BAPI also has a Return Table:

TABLES

*" RETURN STRUCTURE BAPIRET2

In your custom prog, add code to write out this int table if an error (type E) is encountered.

[Former Member]

Or even another background process that has some orders opened up.

[Former Member]

Hi,

Do one thing..

After the bapi call BAPI_SALESORDER_CHANGE.

Check the return internal table..And check for errors..And write it...So when run in background you will know what exactly is the error by checking the spool..

Ex..

CALL FUNCTION 'BAPI_SALESORDER_CHANGE'
    .......
    TABLES
        RETURN = T_RETURN.

LOOP AT T_RETURN WHERE TYPE = 'E' OR TYPE = 'A'.
  WRITE: / T_RETURN-MESSAGE.
ENDLOOP.

Thanks,

Naren

[Former Member]

HI Naren,

Thanks for the reply. I am checking for the errors in the Internal table after passing it to the BAPI, but the problem is the contracts that are getting skipped are not erroring out or listed in the spool. They do not even appear on the spool list of the succesfully updated Contracts. They are just getting skipped and when the same contracts are run through the program in foreground they get updated correctly.

Any suggestions??

[Former Member]

Hi,

Ok..You are displaying successfully updated contracts...

Also display the messages in the internal table T_RETURN if there are any messages of type error or abort..

That way you will get the exact description of why the contract didn't get updated..

Thanks,

Naren

[Former Member]

Naren,

I am checking in the Bapi return table for messages with type 'E'. I am not sure of abort. Anyways the contracts that are skipped do not appear in the bapi_ret table either successfully or with errors. They just dissappear of the spool. I am not sure why this is happening. I appreciate your prompt responses. Thanks again.

[Former Member]

"Anyways the contracts that are skipped do not appear in the bapi_ret table either successfully or with errors."

How do you KNOW that these contracts are being selected for processing? Are you assuming that they are OR do you create a processing log as you go along?

[Former Member]

Hi,

Yes..John is correct.Are you sure the contracts are getting selected??

Thanks,

Naren

[Former Member]

John

That is the issue here. I am not sure whether they are getting selected or not in the background. But when I run the program in the foreground with the same contracts they are selected and updated. I see no reason why these contracts would be selected in foreground and not in back ground if thats the issue.

One more thing - If I run the program in the background seperately for each contract then it does get updated. Its only when a range of Contracts are selected some random contracts out of them are skipped. Also before I pass the data from the internal table to the BAPI, I create a report with whatever data I have in the ITAB but the contract that are bskipped do not appear on this report also when running in the background. As far as my knowledge goes, if something is wrong with the selection criteria it should not work in the foreground and in the background. I am not sure why this is behaving differently.

Thanks,

Raj.

[Former Member]

Raj,

They would absolutely not be selected in b/g IF they had not been commited to the DB first.

If they were committed after the b/g job finished, and then the f/g activity was executed... this would scenario would occur.

Are you POSITIVE (without question) that the contracts have been fully saved/commited before executing the b/g task?

[Former Member]

Raj,

They would absolutely not be selected in b/g IF they had not been commited to the DB first.

If they were committed after the b/g job finished, and then the f/g activity was executed... this would scenario would occur.

Are you POSITIVE (without question) that the contracts have been fully saved/commited before executing the b/g task?

John,

I do appreciate your prompt reponses but I dont understand what you mean here.

'They would absolutely not be selected in b/g IF they had not been commited to the DB first.'

'Are you POSITIVE (without question) that the contracts have been fully saved/commited before executing the b/g task? '

The purpose of the program is to select contracts from database, perform some validations, see if they have status closed or open. If they are open, we need to update those contracts with the quantity and the custom status field and commit it to the DB. Why would they have to be committed to the DB first??

[Former Member]

If you are gathering these contracts using a SELECT statement, they MUST be saved fully first.

How are you gathering these Contracts?

[Former Member]

I am gathering the contracts from the db tables using Select statement into an ITAB . Hence this Select will return only those contracts that are in the DB tables, in other words committed Contracts. I loop at this ITAB, perform validations to ignore invalid and rejected contracts and pass the valid contracts record by record to the bapi and commit it to the db.

Now from these valid contracts in the ITAB that are passed to the BAPI some of them are getting skipped in b/g.

[Former Member]

Please provide the SQL and what you believe it's business intention to be.