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: 

Call transaction

Former Member
0 Kudos

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.

1 ACCEPTED SOLUTION

sergey_korolev
Active Contributor
0 Kudos

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.

11 REPLIES 11

sergey_korolev
Active Contributor
0 Kudos

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.

Former Member
0 Kudos

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

0 Kudos

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.

0 Kudos

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

0 Kudos

(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

0 Kudos

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.

0 Kudos

Also BAPI would not do what I want ie, make the user perform changes in the standard transaction, working in that screen.

0 Kudos

Don't know if you saw my previous post, but I wouldn't change what you are doing.

Brad

0 Kudos

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.

Former Member
0 Kudos

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

Former Member
0 Kudos

I guess it works. Lets see if we can get better alternatives.