2010 Jul 12 10:26 PM
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
2010 Jul 13 7:13 AM
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
2010 Jul 13 8:11 AM
Hi,
if Mode = 'Background'
After the call Transcation use wait upto 5 sec.
endif.
Hope this might solve your Problem.
With Regards,
Sumodh.P
2010 Jul 13 1:34 PM
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
2010 Jul 13 1:48 PM
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
2010 Jul 13 2:41 PM
ok , I got u.
Could you please helpin checking the other question also.
Thanks
Kylietisha
2010 Jul 13 2:54 PM
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
2010 Jul 13 3:44 PM
> 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]
2010 Jul 13 3:52 PM
2010 Jul 13 7:02 PM
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.
2010 Jul 13 10:40 PM
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
2010 Jul 14 5:48 AM
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
2010 Jul 22 4:57 PM
solved by myself after checking thneccessary details and suggestions given by Sandra
Thank you
2010 Jul 22 5:11 PM
Hi Kylie,
could you tell us more? I'm really interested in what was the issue and how you solved it
Thx
sandra