2005 May 27 12:34 PM
Hi All,
In a dialog program when we need to include some standard functionality we would use CALL TRANSACTION <tcode>. But because this spans a new SAP LUW, when we return to the initial program it becomes difficult to make decisions regarding the data base changes made by the user in the called transaction. Using a BDC just to call the transaction seemed easy (as this is in the same SAP LUW) but this is relatively inefficient I suppose( am I right ?).
It will be helpful if someone can let me know the best possible approach to this kind of situations.
2005 May 27 2:05 PM
Instead of CALL TRANSACTION you also might call some appropriate BAPI. E.g. for purchase order you can use BAPI_PO_CREATE1 instead of calling transaction ME21. In ideal case you can place more than one BAPI into one LUW in a "all-or-nothing" manner. Why ideal?
The problem is that not for all SAP transactions BAPI exist. Also there are some BAPIs which you cannot call more than once in one LUW (e.g. BAPI_GOODSMVT_CREATE).
So, the bottom line - use BAPI's wherever possible, use CALL TRANSACTION when there is no other way out.
2005 May 27 2:05 PM
Instead of CALL TRANSACTION you also might call some appropriate BAPI. E.g. for purchase order you can use BAPI_PO_CREATE1 instead of calling transaction ME21. In ideal case you can place more than one BAPI into one LUW in a "all-or-nothing" manner. Why ideal?
The problem is that not for all SAP transactions BAPI exist. Also there are some BAPIs which you cannot call more than once in one LUW (e.g. BAPI_GOODSMVT_CREATE).
So, the bottom line - use BAPI's wherever possible, use CALL TRANSACTION when there is no other way out.
2005 May 27 2:48 PM
Dear Pavan:
It is not that CALL TRANSACTION is inefficient, but yes, it has its own LUW.
I think you should not focus on if a CALL TRANSACTION is available or not BUT concentrate more on what is the process that you are trying to automate. The changes/data in the process should be saved only after a decision is reached that the data is final. Saving changes to database at intermediate stage (via INSERT or Call Transaction or BAPI etc) is not a good option at all; because it would become hard to revert the changes if a subsequent step in the whole process fails.
Revisiting the process in entirety, analysing when to get acceptance from user/process to save changes, and how to save changes in one-shot is something that you should do. And then, when changes are saved in one shot, whether you do it as call transaction, BAPI, RFC, via custom tables, etc or a grouping of some or all of these things - is just a matter of implementation.
Hope it helps. Else, briefly explain what you are trying to achive and I can suggest some alternatives.
Regards,
Chetan
2005 May 27 3:12 PM
Chetan, Sergei & Sanjeev
I did never say that CALL TRANSACTION is not efficient. I just expressed my doubt if the batch input approach is any overhead.
May be my earlier message was not in the required detail.
Here you go,
In the GUI, I provide the user with a push button to carry out some action. When it is clicked I navigate to a standard transaction and let the user make any changes( or no changes). When that transaction is done, I try to find if he is done with the activity completely and set a flag so that in the PBO, I can use it to enable/ disable the push button. That is to say, the user doesn't need this functionality once it is completed.
But the problem is in finding out whether or not he is completely done with the std transaction when he returns from it to my screen. I attempted querying DB tables, status info etc but of little use as it is different LUW and there is some out of sync with the commit happening there. So, I resorted to use 'CALL TRANSACTION .. USING..' ie, the batch input way so that LUW is the same & there is no out of sync commit. I am not convinced that this is the best way to go about.
Hope you have more clarity now. Meanwhile I will try n see if any BAPI are available, as suggested. Thanks for all your help. I will wait to hear from you.
regards,
Pavan.
2005 May 27 3:24 PM
Hi Pavan,
Add the following to your CALL TRANSACTION <b>UPDATE S</b> or <b>UPDATE L</b>.
This will mean that the updates are performed before control is returned from the CALL TRANSACTION.
Then when you check the database, you will definitely see whether or not the user has performed the action.
Cheers,
Brad
2005 May 27 3:31 PM
(maybe you are already doing my first suggestion, if not then you are not guaranteed that the update will have finished before you do your select statement).
And to address your concern, I don't think this is an inefficient or BAD way to solve your problem.
It works, and it doesn't consume any more processing power. The only downside is a slightly increased wait time for the user, but no big deal. With BAPIs, however, you have the same problem. When you do the COMMIT WORK, the update is still potentially asynchronous to your task, so you could still have synchronisation problems (plus there are no user screens, how will the user fill in the data).
The BAPI synchronisation issue could be overcome with SET UPDATE TASK LOCAL, or COMMIT WORK AND WAIT, but I think your CALL TRANSACTION approach is fine.
Brad
2005 May 27 3:32 PM
Hi Brad,
This is what I am doing right now. 'UPDATE' is available only in conjunction with 'USING' (ie, the batch input approach). I wish it were available without USING too.
Thanks,
Pavan.
2005 May 27 3:37 PM
Also BAPI would not do what I want ie, make the user perform changes in the standard transaction, working in that screen.
2005 May 27 3:39 PM
Don't know if you saw my previous post, but I wouldn't change what you are doing.
Brad
2005 May 27 3:46 PM
Hi Brad,
I guess we had some sync problem with the messages.. ha ha ha. I just saw your replies. Thanks for your help.
Cheers,
Pavan.
2005 May 27 2:56 PM
I generally decide in following order -
1. BAPI - No problems with upgrades. Consistent interface across all releases. Only downside is that you do not have BAPI for things you want to do. If available use it. In case of error difficult to figure out where it is happening as opposed to BDC where you can process in foreground mode to see what is happening.
2. ALE - Very good for interfacing, even better than BAPI if used for interfaces, have the same advantages as BAPI only difference is that it is asynchronous. Advantage is that you get good error handling, error tracking and re-posting mechnism to support a robust interface. Tools available to display, re-process and test IDOC's.
3. BDC - We all know the downside but for some situations, this is the only option. Advantage is that troubleshooting is very easy.
I hope this answers your query.
Regards,
Sanjeev
2005 May 27 3:48 PM
I guess it works. Lets see if we can get better alternatives.