SAP Transaction Concept and Security
You must also keep in mind the SAP transaction concept when designing any type of outside interface into the SAP system. Even if the interface is a simple Java screen or an ITS transaction, you must ensure that you do not compromise the integrity of the data within SAP.
A transaction is a sequence of actions that logically belong together, for example, a finance transaction in which a value is subtracted from one account and added to another. The LUW (Logical Unit of Work) here is the posting of both rows in the database. If one row is posted and the other row is not, a data inconsistency will occur. An SAP transaction comprises at least one LUW, but might comprise many. For instance, month-end jobs often process many two-sided financial transactions. Each transaction has its own LUW.
If you are updating any data in the SAP system, your external interface must call only properly constructed BAPIs. By definition, BAPIs must perform a complete LUW and cannot create data inconsistencies (if a problem occurs with any SQL statement, the entire transaction is rolled back at the database level and a return code is generated).
Another thing to consider with regard to SAP transaction data is that multiple users are on the system at one time. For example, suppose that your Java application needs to update a specific field in the customer master for a given set of selection criteria. Even if you call a BAPI to perform this function, you might still cause a data integrity issue if you are not careful, as the following scenario points out.
Suppose you are running a Java application, which reads in a customer master record, allows you to change some values, and then writes the entire record back to SAP via a BAPI call. In principle, this process sounds OK, but what if another user in SAP wants to edit the same record? In this case, your Java program could read in the customer master record; at the same time, the other user could go into the SAP transaction to modify the customer data and quickly save the changes. You then make your changes and write the changes via the BAPI call, but if you write all the fields of the customer master, you will unknowingly overwrite the other person's changes.
If everyone is using standard SAP transactions, this problem won't develop because SAP locks an object if a person is currently editing it. When the first person is finished, another person can go into the transaction, read all of the previous changes, and then make any desired modifications. However, when external interfaces are employed, such as Java through BAPI calls or even things like ALE (Application Link Enabling), it is important that you modify only the fields that you intend to, and not write back fields that you have not changed.
Team-Fly |
