Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

SM35 Re-processing of Incorrect/Error session in Background Mode

antony_paul2
Active Participant
0 Kudos

Hi all,

I am trying to reprocess a session in SM35 which is in Error status. Here I am a facing an issue, if I reprocess this session in background mode then it says that Batch input data is not available for a screen which is already processed. Ideally it should start from the screen where it threw error in the first run. If I select mode as Foreground or Display error then session is getting processed correctly.

Note:

If the session is in Ready to Process state then processing in background works perfectly fine. Has anyone came across this problem ?

Has anyone tried reprocessing Incorrect Session in background mode ??????

Regrads,

Antony

1 ACCEPTED SOLUTION

Sandra_Rossi
Active Contributor
0 Kudos

Hi Antony,

This issue is quite frequent (among the known issues). See consulting note 33319 - Batch input: Backgr. runs diff. than in the dialog.

As you say that modes A (display all screens) and E (display screen if error) work but not N (background), there are the following possibilities :

1) the program tests SY-BATCH system field somewhere (it's blank for A and E, and 'X' for N). Unfortunately, it means that the batch input was incorrectly recorded (we must record in "background" mode), so the program must be corrected, and a new session generated.

2) the user in the batch input session is different from yours, there's probably a failed authorization check somewhere (use authorization trace), or a different date format or number format. Run the BDC with the same user.

3) there may be an issue with SET-GET parameters: they are cleared in background mode, but yours are kept in A and E modes. Run the BDC with the same user so that to use the same initial values of the SET-GET parameters

4) In background mode, the standard screen size is used. So remember to tick that checkbox in A and E modes.

5) maybe you should fill BDC_CURSOR if it's not defined for some screens

there's at least one other possibility...

By the way, what was the original batch input error?

See also the SDN wiki about batch input troubleshooting.

Best regards,

Sandra

9 REPLIES 9

Sandra_Rossi
Active Contributor
0 Kudos

Hi Antony,

This issue is quite frequent (among the known issues). See consulting note 33319 - Batch input: Backgr. runs diff. than in the dialog.

As you say that modes A (display all screens) and E (display screen if error) work but not N (background), there are the following possibilities :

1) the program tests SY-BATCH system field somewhere (it's blank for A and E, and 'X' for N). Unfortunately, it means that the batch input was incorrectly recorded (we must record in "background" mode), so the program must be corrected, and a new session generated.

2) the user in the batch input session is different from yours, there's probably a failed authorization check somewhere (use authorization trace), or a different date format or number format. Run the BDC with the same user.

3) there may be an issue with SET-GET parameters: they are cleared in background mode, but yours are kept in A and E modes. Run the BDC with the same user so that to use the same initial values of the SET-GET parameters

4) In background mode, the standard screen size is used. So remember to tick that checkbox in A and E modes.

5) maybe you should fill BDC_CURSOR if it's not defined for some screens

there's at least one other possibility...

By the way, what was the original batch input error?

See also the SDN wiki about batch input troubleshooting.

Best regards,

Sandra

0 Kudos

Hi Sandra,

My problem is a bit different, If I execute the session in background mode for the first time it works perfectly fine. Let say after executing it for the first time if the session is in error due to some other issues, then I can only reprocess the session in foreground/display Error mode. This really baffles me.

Regards,

Antony

0 Kudos

Antony,

Was your problem solved? Which transaction you are processing? There are transactions in SAP that has different screen sequence based on document types or already existing data in system.

Refer to your transaction for these to conditions.

0 Kudos

Batch Session I am creating contains 2 transactions, 1st KEBC & then KEU2. As a normal scenario while processing transaction KEU2 of the session it can go in error due to issue with data/locks. If the session went to error mode while processing transaction KEU2, then if i try to reprocess the same session in background mode, I guess it processing starts again with transaction KBEC ( Ideally it should start with screen which threw error in the inital processing i.e screen realted to transaction KEU2) & system says no data for Batch Input Screen linked to transaction KEBC.

But in Foreground & Display error mode it starts with transaction KEU2 (Correct screen where it threw error in the initial processing).

0 Kudos

Hi Antony,

My problem is a bit different

Apparently, it's not so different from a part of what I answered. So you have checked everything I said? The session user is yours, and so on.

Batch Session I am creating contains 2 transactions, 1st KEBC & then KEU2. If the session went to error mode while processing transaction KEU2, then if i reprocess the same session in background mode, I guess it starts again with transaction KBEC & say the no data for Batch Input Screen linked to transaction KEBC, but in Foreground & Display error mode it starts with transaction KEU2, where the previous processing ended.

But don't you look at the session log? If the first transaction is successful, it is removed from the session! So it can't be restarted. I think there's something unclear in what you told us...

One possibility is that KEU2 has been incorrectly recorded : it was recorded with SY-BATCH = space, while this one is 'X' in background mode, and KEU2 probably displays a different screen in that case.

Could you restart the session in A or E mode, with Simulate background mode activated (it sets sy-batch = X), I think it fails, isn't it?

Take time to read the wiki, it gives very interesting information for troubleshooting (though it may be not obvious to understand how to use it).

BR

Sandra

0 Kudos

Thanks Sandra,

Indeed I understood the problem. And the problem is that transaction KEBC is always executed correctly & since its processed correctly its removed from the BDC Queue

Here transaction KEBC, sets a Memory Parameter, and transaction KEU2, first checks whether the memory parameter is initial, if found intial it pops-up a screen and makes the user enter it. In my case KEBC always run successfully

As you rightly suggested when session is in error, transaction KEBC is not getting called again to set the memory parameter & its throwing the pop-up from the transaction KEU2 to be entered by the user. ( BDCDATA currently dosent handle this Pop-up).

I could have omitted the KEBC transaction, but handling this pop-up from transaction KEU2 becomes tricky since it will only pop-up if the memory parameter is initial. And unfortunately Pop-up is the first screen in the sequence for transaction for KEU2 & nothing can be done in coding level to call KEU2 with the pop-up in all scenarios(Even when Memmory varaible is set) !

So I am kind of in a dilema, how to handle this? What I am suggesting to the Functional consultant is that let the session be only run in background mode (as it will be always in a new internal session memory variable will always be inital ) & I will record this pop-up in my BDC omitting transaction KEBC.

Do you have anyother solution for this?

Or is there any option to re process even the successfull transacations ?

0 Kudos

Hi Antony,

Thanks, very nice explanation, I feel I understood everything

You can use this kind of trick : create a new generic transaction which sets SAP memory and calls your transaction:


PARAMETERS p_tcode TYPE tcode OBLIGATORY.
TYPES spa_value TYPE c LENGTH 255.
PARAMETERS p_spa01 TYPE tpara-paramid.
PARAMETERS p_val01 TYPE spa_value.
PARAMETERS p_spa02 TYPE tpara-paramid.
PARAMETERS p_val02 TYPE spa_value.
PARAMETERS p_spa03 TYPE tpara-paramid.
PARAMETERS p_val03 TYPE spa_value.
START-OF-SELECTION.
IF p_spa01 IS NOT INITIAL.
  SET PARAMETER ID p_spa01 FIELD p_val01.
ENDIF.
IF p_spa02 IS NOT INITIAL.
  SET PARAMETER ID p_spa02 FIELD p_val02.
ENDIF.
IF p_spa03 IS NOT INITIAL.
  SET PARAMETER ID p_spa03 FIELD p_val03.
ENDIF.
LEAVE TO TRANSACTION p_tcode.

You may reuse it for any other batch input where you need to set parameters.

BR

Sandra

0 Kudos

Thank you Sandra .....Its solved ... What I did is I created a program with two statements


CALL TRANSACTION 'KEBC'.

CALL TRANSACTION 'KEU2'.

and linked this to a transaction. Then while building my BDCDATA table I am only inserting one transaction code instead of 2. This will help me reprocess KEBC while processing Error sessions.

Once more thank you for all the help, I was breaking my head all day and finally I did find some light at the end of the tunnel

0 Kudos

Hi Antony,

you're welcome

By the way, calling an additional dialog step (KEBC) which does the same thing as entering a SET-GET parameter, is counter-performant, especially in case you use it during a "big mass upload".

BR

Sandra