BDC updates several screens but commit to database not done until the end

[former_member80953]

We have a very large ABAP program which was written quite a few years ago using BDC technology. The program is used to manage employee changes via PA30 with BDC's. It has been working well but we have come across one problem and when I trace it, it is because the BDC does not update the database tables until the end. If I do all of the steps below manually everything works just fine because with each step it saves the data to the PA table I mentioned. However when you do these same steps via BDC, data is not saved to the PA tables until the end. The problem is that SAP Code behind these screens expects the correct data to be in the actual database. We are changing some data in the Actions/Orgs, but it is not being saved for when it gets to the Basic Pay. Therefore, the problem is really not with our ABAP itself, but how the BDC is not saving out to the tables. We know that all of this was o.k. at least previous to mid 2016. Has anyone else experience this or have any thoughts?

tx: PA30

EE#:89184

Select Actions (pa0000) and click on Create

Change Start Date to 2017.06.09

Reason: 71

EE Subgroup:50

Save – get record delimtted msg

Save

On Org Screen (pa0001)

Subarea: 0001

Save - get record delimtted msg

Save

On Planned Working Time Screen (pa0007)

Save

On Basic Pay Screen (pa0008)

PS Type: E

PS Area: US

PS Group: JB06

Save

All is Good! This was done manually

[Sandra_Rossi · Accepted solution]

Maybe your issue is because of a COMMIT WORK added by a developer, which would occur during the save. The BDC stops by default at the first COMMIT WORK. Cf component RACOMMIT of ABAP word OPTIONS of CALL TRANSACTION parameter in ABAP documentation of CALL TRANSACTION - USING.

[Former Member · Accepted solution]

Thx for your answer Sandra. The BDC keeps running, it does not stop. The problem is that the BDC involves the update of several screens and it does not save to the database at each screen (only at the very end).

Therefore when it gets to the Basic Pay screen and needs to have accurate info in the database from the previous screens and it does not so it fails.This happens manually outside of my program as well - i.e. it happens if I manually do a BDC recording via SHDB).

I did add in the RACOMMIT option in the code just to see what would happen and nothing changed - I didn't think it would have any impact only because the issue is not a premature end of the transaction.

If I have mis-understood your answer please let me know. I have run out of options except running it as 2 BDC's and lots of reasons why I would prefer not to do this.

[Sandra_Rossi · Accepted solution]

Did you get any message from the BDC message table? (even S messages can be errors, especially the messages 344 to 349 from the message class 00)

Does the BDC work with display mode = E (display screen when error) or does it stop at the Pay screen?

If you run the BDC with display mode = A (display all screens), do you notice an additional screen or error message?

Did you run the BDC with RACOMMIT-NOBINPT = 'X'? (it will make the SY-BINPT=' ' during the run, as if you were running PA30 without BDC)

Did you compare automatically the SAT traces (in "no aggregation" mode) between dialog run and BDC run, to see from which statement it goes differently?

I'm afraid that the last solution is to rewrite the BDC program with BAPI_BASICPAY_CHANGE.

[Former Member · Accepted solution]

Thx very much Sandra. I did take a little time to try a few more things once I saw your answer and no luck. I think your Bapi suggestion is the probably the right direction. BDC's are really not the best to use these days anyways so it is time to update this old program.

[Former Member · Accepted solution]

Me again Sandra, I am a little new to this new SCN ... other than doing a "like" I cannot seem to find a way to say correct answer or anything on your response. If you know how I can do this please let me know.

[Sandra_Rossi · Accepted solution]

Do you see an "accept" link below the answer at the first level?

[matt · Accepted solution]

You could also perhaps split the BDC into two, doing a save, then processing the Basic Pay screen. But BAPI is definitely the way to go. BDCs just aren't reliable enough. I've not written one for over 15 years...!

[chaouki_akir]

Also you can put a break-point at instruction COMMIT and COMMIT WORK to check for example if a developer has newly added a COMMIT instruction in a user-exit.