Issue with BDC processing

[Former Member]

hi gurus ,

I have an issue with BDC

The BDC for MR21 works in A mode as well as in N mode but when we schedule a job for the same program conatining the same BDC : throws error in the spool output.

Saying that Material is not updated .

Can anyone guide me on this ?

there is no issue on executing that BDC in A mode neither N mode

But when i execute the program through a Job : then thejob executes bt in the spooli get same error.

Wat could be teh reason ?

Thanks

Kylie

[Former Member]

Hi kylietisha ,

Please make sure that there are no warning messages while you are doing it in A or N mode also

Warning messages can create problem while executing in background .

Thes warning messages can be supressed in backround also .

Hope it helps .

Regards

Swapnil

[former_member536879]

Hi,

if Mode = 'Background'

After the call Transcation use wait upto 5 sec.

endif.

Hope this might solve your Problem.

With Regards,

Sumodh.P

[Former Member]

hi ,

before checking your answer i Had incporated the same thingh inBckgrnd mode .

Could you advice me on the following tooo >>>>

Which is more beneficial : Commit Work /Wait upto xx seconds ?

One more guidance is required :-

According to the requirement there will be some product codes recieved from Business in a File data : DailyFile.txt

Now the file gets processed and updates a custom table with a flag and processing time. When this file data is checked across

Material Master data :MARA then the product codes from the file are checked with a pattern : _703124% so that we can check if

any materials are avilable at the data level.

If materials are not avilable then the previous code is throwing an Information Message and waiting for User input at Bckground processing too.

How can we handle this scenario so that the above Information Message is not shown up while processing in 'N' mode

Could anybody please help on this <removed by moderator>

Thanks

Kylietisha

Edited by: Thomas Zloch on Jul 13, 2010 4:06 PM

[former_member536879]

Hi,

When you are doing this in the Background each time each material gets locked for saving. For that we are giving the wait upto sec. If you use the commit work i think it will go for dump.

With Regards,

Sumodh.P

[Former Member]

ok , I got u.

Could you please helpin checking the other question also.

Thanks

Kylietisha

[former_member536879]

Hi,

You mean to say that you are updating a custom table while updating the mara?

Commit work : In a program executed using batch input, or if you have called the program using the USING

addition of the statement CALL TRANSACTION, COMMIT WORK terminates the batch input processing when

using the corresponding settings.

You cannot execute the COMMIT WORK statement during the updating procedure or during the execution

of subroutines registered using PERFORM ... ON {COMMIT|ROLLBACK}.

With Regards,

Sumodh.P

[Sandra_Rossi]

> swapnil kamble wrote:

>> Warning messages can create problem while executing in background

erm, messages sent using MESSAGE ... TYPE 'I' and 'W' are simply ignored, they do not cause any problem.

The only thing that can cause problems is that unexpected screens (not the I and W messages) are displayed. The only way to avoid this problem is to determine the conditions when these screens are displayed (ask functional people, debug code, etc.), and add them in the BDC data only when the conditions are true.

> Sumodh P wrote:

>> if Mode = 'Background'

>> After the call Transcation use wait upto 5 sec.

>> endif.

I don't really see why it would solve the issue, as the only thing we know is that an error "material not updated" occurs. That would work only if the same transaction is called several times, and the locks from the first CALL TRANSACTION USING (CTU) are still present when the second CTU runs. Note that it would be best to use synchronous or local update mode (parameter UPDMODE = 'S' or 'L' in OPTIONS FROM keyword of CTU)

> Sumodh P wrote:

>> When you are doing this in the Background each time each material gets locked for saving

No, there's no reason that dialog and background process locks differently.

>> For that we are giving the wait upto sec.

Prefer to use synchronous or local update mode as I said above.

>> If you use the commit work i think it will go for dump.

No, it's just useless if the program only executes CTU.

kylietisha,

be careful with terms, BDC mean the general technology, that is used by both CTU and Batch Input Sessions (SM35). Based on the answers, I understand that your question is about CTU.

If you see differences when you run in dialog and in background, I suggest that you execute it in dialog, screen-by-screen mode with the simulate background mode on (DISMODE = 'D'; it means that it's called like DISMODE = 'A' + sy-batch is set to X during the execution).

I suggest that you read the [SDN wiki about BDC|http://wiki.sdn.sap.com/wiki/display/ABAP/BatchInput-BDC], and especially the [FAQ|http://wiki.sdn.sap.com/wiki/display/ABAP/BatchInput+FAQ]

[former_member536879]

Hi Sandra,

Thanks for Updating.

With Regards,

Sumodh.P

[Former Member]

Well Sandra ,

thanksfor al your possible replies : lemeexplain the scene here .

The custom program being used to update these price changes for material : based upon CALL TRANSACTION mode.

CALL TRANSACTION MR21.

CALL TRANSACTION C_MR21

USING I_BDCDATA

MODE P_MODE : N mode (since there is a corresponding job which executes nightly)

UPDATE S

MESSAGES INTO I_MESSTAB.

the custom object reads an input file and based on that it updates the price changes (if any) for the material avilable in Master data

MARA table.

Now , the above process executes compfortably in Foreground Mode (A) : Works Fine in background Mode (N) but when a job is scheduled and executed : the spool shows "Error" for such materials which are updating in Foreground and N mode.

there are no errors (executed in E mode)that stops the execution of this process.

In the customcode there is a flag which gets updated after the CALTrans method .

If the caltrans :unsucesful : Flag Set : Errorprinted beside the material(coming from the file) otherwise appropriate mesg printed.

In the course of checking the executionof the above by scheduling a Job : after incorporating a Wait of 1 sec made difference

i din't find any such scenarios of (error) .

hence i thought of asking the question wether Wait can resolve such issues.

Since while executing that BDC i didnot find it to stop in any screen : in E mode that'swhy i dint change the BDC process.

Could you provide your advice on the way I m handling the above mentioned scenario?

Thanks

Kylitisha.

[Sandra_Rossi]

If you make 2 test runs with exactly the same context and data, except that one runs the WAIT UP TO SECONDS, and it succeeds, then it means undoubtedly that there is an asynchronous process which continues a few milliseconds after the CALL TRANSACTION USING and makes the next one fail for some reasons, usually it's caused by a SAP lock not removed (yet).

Possible causes:

1) Locks during update task of the CTU not removed:

2) asynchronous RFC calls with Wait mode

3) and of course any other processes in the system (users, batch jobs)

2 and 3 are unlikely, but well, you can check them (ST05 RFC trace, SM50, SM12, for example)

1: I thought it was impossible as you use S (synchronous) update mode, but after investigation, I'm not completely sure (it may depend on the system configuration maybe):

1-a) I saw that at the end of CTU, locks are removed, but it is an asynchronous process if the [enque/deque_wait_answer profile parameter is FALSE|http://help.sap.com/saphelp_nw2004s/helpdata/en/4c/1184365e3d4f4fb521a420bcad4e38/frameset.htm] (use RZ11 transaction to see this parameter). And FALSE is delivered by default.

1-b) Nevertheless, I saw in the corrective [Note 697989 - Objects locked despite synchronous update|http://service.sap.com/sap/support/notes/697989] (releases 4.6 to 6.40) that locks should be released synchronously if the update is synchronous...

I did tests on my system, I could see that the system remove locks synchronously if you run the updates of CTU synchronously (as said in 1-b)

Finally, I think that maybe the issues depend on your server configuration (do you use enqueue server or standalone enqueue server), and maybe come from network problems if you have application server and enqueue server not on the same system.

So I advise you to:

- talk to the admins

- apply note 697989 if applicable

- or change temporarily (if you can) the profile parameter so that to make sure whether it solves or not

- or analyze what happens: do a lock trace in SM12 (Note 125041 - Analysis of enqueue errors with enqueue logging) and check errors in SM21 (network problems).

Check also all SAP notes about locks... If finally that doesn't help, you may also ask SAP support.

And if you don't have the time to investigate, keep your current workaround

sandra

[Former Member]

kylietisha,

you need to print all your messages in i_messtab after the call transaction to understand this issue.

I am not sure if I have understood this correctly. But you cannot use "A" or "E" when the program in run as a job in the background. In that case you can only use N.

Are you using any table controls? When you did your recording, did you use the "default screen" option? Because when you perform a call transaction in online mode, it will use the resolution of the desktop. In background job, the default screen size is used. So, in that case, if you had recorded using the desktop screen size, your call transaction will be successful in foreground but will fail in background.

Salai

[Former Member]

solved by myself after checking thneccessary details and suggestions given by Sandra

Thank you

[Sandra_Rossi]

Hi Kylie,

could you tell us more? I'm really interested in what was the issue and how you solved it

Thx

sandra