can we submit 3 programs at a time in a bapi?

[Former Member]

Hi All,

Can we submit the 3 programs at a time in a BAPI?

for example:

In BAPI 'ZYYYY'-> submit test1 with selection-screen '100' using selection table rsparam.

submit test2 with selection-screen '100' using selection table rsparam.

submit test3 with selection-screen '100' using selection table rsparam.

Regards,

Devi.

[Former Member]

True BAPIs should not have screens.

Rob

[Former Member]

Rob is correct.. ture purpose of BAPI are to simulate how transaction works and do the task without any screen processing.

and Yes.. you can SUBMIT...though the true meaning of BAPI wont have the justice..

[Former Member]

Can we submit the 3 programs at a time in a BAPI?

Sure, but the question might be should we submit......

submit test1 with selection-screen '100' using selection table rsparam.

I'm not familiar with syntax with selection-screen .. using..., though I could see [submit using selection-screen .. with selection-table|http://help.sap.com/abapdocu_70/en/ABAPSUBMIT_INTERFACE.htm]. Also, you'd have to use the [and return|http://help.sap.com/abapdocu_70/en/ABAPSUBMIT.htm#!ABAP_ONE_ADD@1@] addition (will be obvious once you read the documentation).

Now the more interesting part, is this in compliance with the BAPI interface contract? In the [Introduction to BAPI's|http://help.sap.com/saphelp_nw70ehp2/helpdata/en/e3/cfa21850a711d395f900a0c94260a5/frameset.htm] SAP defines:

Business Application Programming Interfaces (BAPIs) enable access to SAP functions across formal, stable and dialog-free interfaces.

As your idea seems to be to submit the program without showing a screen we should still be ok. So let's read on and check the [BAPI Transaction Model Requirements|http://help.sap.com/saphelp_nw70ehp2/helpdata/en/43/b46c4253c111d395fa00a0c94260a5/frameset.htm]:

As of Release 4.0 BAPIs must not execute 'COMMIT WORK' commands. \[..\] Several BAPIs should be able to be combined within one LUW. \[..\] The following commands must not be used:
- CALL TRANSACTION
- SUBMIT REPORT
- SUBMIT REPORT AND RETURN
\[..\]
Database changes can only be made through updates. 
Reason: The RFC executes an implicit database commit.

Fair enough. We should avoid commits so that users can bundle BAPI's into one LUW. However, the requirement to use updates (which I read as update function modules) implies that any [implicit commits|http://help.sap.com/abapdocu_70/en/ABENDB_COMMIT.htm] shouldn't have any impact as long as the submitted program doesn't change any data. Thus assuming that all BAPI's comply with SAP's requirements (which we know they don't, but that's another story), I don't see a reason why we shouldn't for example submit some legacy program to retrieve for example some data (I know poor design, but most of us deal with lots of existing code).

So please correct me if I'm missing something substantial here, but I think for sake of clarity the BAPI implementation requirements are overly restrictive and SAP simply tries to avoid explaining odd corner cases...

[Sandra_Rossi]

> So let's read on and check the [BAPI Transaction Model Requirements|http://help.sap.com/saphelp_nw70ehp2/helpdata/en/43/b46c4253c111d395fa00a0c94260a5/frameset.htm]:

>

> As of Release 4.0 BAPIs must not execute 'COMMIT WORK' commands. \[..\] Several BAPIs should be able to be combined within one LUW. \[..\] The following commands must not be used:
> - CALL TRANSACTION
> - SUBMIT REPORT
> - SUBMIT REPORT AND RETURN

Here, I don't understand the documentation. I mean: SUBMIT REPORT AND RETURN, alone, does not trigger an implicit database commit (or does it depend on something? I made tests in 7.0, there is no implicit DB commit). It occurs only if a screen is displayed, or RFC is called, ...

> However, the requirement to use updates (which I read as update function modules) implies that any [implicit commits|http://help.sap.com/abapdocu_70/en/ABENDB_COMMIT.htm] shouldn't have any impact as long as the submitted program doesn't change any data.

Your statement applies only if you call a BAPI once in the LUW. However, BAPIs may be called several times in the LUW by standard programs (IDocs especially, those which allows processing by packets).

> but I think for sake of clarity the BAPI implementation requirements are overly restrictive and SAP simply tries to avoid explaining odd corner cases...

I agree on that, but only about the SUBMIT REPORT AND RETURN, not the implicit DB commit

[Former Member]

SUBMIT REPORT AND RETURN, alone, does not trigger an implicit database commit (or does it depend on something? I made tests in 7.0, there is no implicit DB commit).

You are absolutely right. I must admit that I'm a bit surprised, but when I tested it I also didn't get any implicit commit. I think the help is a bit misleading, because even though the submit statement is not mentioned for [implicit commits|http://help.sap.com/abapdocu_70/en/ABENDB_COMMIT.htm], the help on [commit work|http://help.sap.com/abapdocu_70/en/ABAPCOMMIT.htm] states:

Within an update function module started using COMMIT WORK, the execution of statements that lead to a database commit is not permitted. In particular, the following are forbidden:
\[..\]
SUBMIT

Even though it doesn't explicitly state that the commands are forbidden, because of an implicit commit, I was always assuming that this is what it's trying to tell me...

>> However, the requirement to use updates (which I read as update function modules) implies that any implicit commit shouldn't have any impact as long as the submitted program doesn't change any data.

> Your statement applies only if you call a BAPI once in the LUW. However, BAPIs may be called several times in the LUW by standard programs (IDocs especially, those which allows processing by packets).

Sorry, I don't understand what you mean. I was trying to say that as long as all BAPI's do any persistent changes via update function modules any implicit commit would not trigger those updates and thus the transactional model would still work. I.e. you could call the BAPI several times and despite implicit commits triggered in the BAPI you could still either commit or rollback everything once your transaction is done. I would appreciate if you could elaborate where my thinking is wrong.

Thanks a lot for the corrections, it's always good to learn/understand the inner workings of ABAP better...

[Sandra_Rossi]

> Sorry, I don't understand what you mean. I was trying to say that as long as all BAPI's do any persistent changes via update function modules any implicit commit would not trigger those updates and thus the transactional model would still work. I.e. you could call the BAPI several times and despite implicit commits triggered in the BAPI you could still either commit or rollback everything once your transaction is done. I would appreciate if you could elaborate where my thinking is wrong.

My bad. I was still thinking that previously called BAPIs could do direct updates, this is a too much recent concept for me (I discovered it yesterday, owing to you, so my ideas are not clear about it yet)

I found another reason to say that BAPIs must not do database commits, that seems rather obvious when said like that: SAP doesn't say how we must call BAPIs, so I assume it's free: if your program executes direct updates and calls a BAPI, you should have the guarantee that you can rollback the whole updates (here, yours especially, plus update function modules) if you want/need to.

> it's always good to learn/understand the inner workings of ABAP better...

I like that too, what I do is I watch people who post interesting remarks

-

---

I found something interesting too: according to [sap library - Transaction Model for Developing BAPIs|http://help.sap.com/saphelp_nw2004s/helpdata/en/a5/3ec8654ac011d1894e0000e829fbbd/frameset.htm], and BC417 (training for BAPI development, 2008, page 17), BAPIs are allowed to trigger COMMIT WORK, but it must be indicated in their documentation, so always read it!

So, I deduce that BAPIs could do the following, if this is documented:

- do a simple database commit*

- do direct updates : if there can be a commit work in a BAPI, why couldn't there be a direct update!

Note about the importance of BAPI documentation about the presence of a commit:

> Abstract of [SAP Library - Designing the BAPI|http://help.sap.com/saphelp_nw70/helpdata/EN/43/b46c1e53c111d395fa00a0c94260a5/frameset.htm]:

>> Since BAPIs represent business interfaces and not technical ones, the following central requirement for developing BAPIs arises:

>> In an external application, users must be able to correctly implement a BAPI call using their knowledge of the application and the BAPI documentation alone. Users are not expected to have any knowledge of SAP, so that they can view the SAP System as a "black box".

[Sandra_Rossi]

PS:

1) as the SAP library is unclear, I looked at the BC417 (2008, page 204), one of the first lines of the Update chapter: "Database updates are always done via update processes" (now that's clear!)

2) Note that we still find in BC417: "A BAPI must not trigger further LUWs. Therefore don't use \[...\] SUBMIT <report> \[AND RETURN\]. I wonder if it has changed with recent kernel, can someone test with a 4.6C or 6.20 release? Or is it a profile parameter?

3) Example of a "bad" BAPI: BAPI_CASE_CREATE uses direct update (ECC 6). If it is called via RFC, the updates will be committed even if you later use BAPI_TRANSACTION_ROLLBACK! The BAPI documentation does not contain this important information (though it should!)

4) Standard BAPIs which use COMMIT WORK are indicated in Note 131838 - Collective note for BAPIs w/ 'Commit Work' command (as I know SAP, maybe this note is not up to date, there are probably other ones, or these ones are corrected)

5) I wonder if we are allowed to call a BAPI from the update task (though I think there is no interest to do so)

[Former Member]

Sandra, very nice write-up - I think we're making good use of this thread...

On the commit work I prefer usage of the programming principle of least surprise and thus the strict recommendation given in the [BAPI Transaction Model Requirements|http://help.sap.com/saphelp_nw70ehp2/helpdata/en/43/b46c4253c111d395fa00a0c94260a5/frameset.htm] I quoted earlier:

As of Release 4.0 BAPIs must not execute 'COMMIT WORK' commands.

Part 2 of your comments is also still a mystery to me:

2) Note that we still find in BC417: "A BAPI must not trigger further LUWs. Therefore don't use \[...\] SUBMIT <report> \[AND RETURN\]. I wonder if it has changed with recent kernel, can someone test with a 4.6C or 6.20 release? Or is it a profile parameter?

I fail to see why it's bad to start a new LUW as long as no explicit commit is triggered. Obviously whatever code is executed in the new LUW cannot do any updates (well, even more strict, it should not have any functionality that requires implicit or explicit commits) to comply with the (stricter) transaction requirements I quoted. I'm not aware of any [profile parameters|http://help.sap.com/saphelp_nw70ehp2/Helpdata/EN/c2/b1bf3dce8f4895a8bd7379506ed932/frameset.htm] influencing LUW behavior or implicit commits related to SUBMIT.

5) I wonder if we are allowed to call a BAPI from the update task (though I think there is no interest to do so)

In theory I'd say it should be ok, though I think it would be a stretch to call anything that does updates. However, in practice I'm with you as I don't see use cases for this: Within an update module I'd say one focuses on performing database updates, so data should be checked already. Probably there are some BAPI's out there that still might be useful, but in general I doubt that one would call a BAPI in an update module.

[Former Member]

Hi All,

How to find a table that is being accessed in all the tcodes?

for example: we have MARA table, how to find that this table is accessed in different transactions like

MM0,CV0,CA0* etc. Help would be appreciated.

Regards,

Devi.

Moderator message - This is an entirely different question - one question per thread please IF the original question is solved, please assign po1nts to helpful answers and mark it as solved and start a new thread with the new question

Edited by: Rob Burbank on Jun 8, 2010 9:15 AM