BUSINESS TRANSACTION EVENTS
Compared with earlier releases, the software delivery process now looks quite different. Previously, only two parties were involved in the delivery: SAP produced the software, and delivered it to its end-customers. Customers could enhance this standard using customer exits.
However, now that the software is more component-oriented, more parties have become involved in the process: SAP provides the R/3 standard to each SAP Industry Solution, which uses it as a basis to add on its own encapsulated functions. The next link in the chain might be a partner firm, which builds its own Complementary Software Program (CSP) solution based on R/3. The last link in the chain is the customer, as before.
All of the parties involved in this process are potential users and providers of enhancements. This requirement cannot be satisfied by customer exits, which can only be used once. Consequently, SAP developed a new enhancement technique in Release 4.0, which allows enhancements to be reused.
Business Transaction Events (BTE) allow you to attach additional components, in the form of a function module, for example, to the R/3 system.
Business Transaction Events use one of the following types of interfaces:
Publish & Subscribe interfaces
These interfaces inform external software that certain events have taken place in an SAP standard application and provide them with the data produced. The external software cannot return any data to the R/3 System.
Process interfaces
These interfaces are used to control a business process differently than the way in which it is handled in the standard R/3 System. They intervene in the standard process, and return data to the SAP application.
You can attach various external developments to the R/3 System. You can create additional developments using the ABAP Workbench.
The example above pertains to Publish & Subscribe interfaces. In this case, data only flows in one direction - from the SAP application to the additional component.
SAP application developers make interfaces available to you at certain callup points in a transaction.
You can deposit additional logic at these points.
In a very basic scenario, SAP partners and customers can use the interfaces themselves. In this case business transaction events function in much the same manner as customer exits (see the unit on "Enhancements using Customer Exits").
The above scenario also pertains solely to Publish & Subscribe interfaces.
In contrast to customer exits, business transaction events allow you to use an interface for multiple types of additional logic.
If this is the case, you must decide which bit of logic you want to execute at what time.
Both of your enhancements exist side by side with out impeding each other; however, at runtime only one of the enhancements can be processed.
Publish & Subscribe interfaces:
Allow you to start one or more (multiple) additional operations when a particular event is triggered. They do not influence the standard R/3 program in any way.
Multiple operations do not interfere with each other.
Add-on components can only import data.
Possible uses: Additional checks (authorizations, existing duplicates, and so on)
Process interfaces:
In contrast to Publish & Subscribe interfaces, data exchange takes place in both directions with process interfaces. This influences the number of additions that can be attached to the interface.
When an event is triggered, a process in the standard program can only be replaced by a single external process using the process interface.
If you are using an add on from an SAP partner that uses a process interface, this enhancement is processed at runtime. If you choose to use this same process interface for one of your own developments, the partner enhancement is dismissed and your own enhancement is processed at runtime instead.
The graphic shows the flow of an SAP program. The program contains an enhancement in the form of a Business Transaction Event. The program calls a service function module, which determines and processes the active implementation of the enhancement. The naming convention for these function modules is OPEN_FI_PERFORM__E (or OPEN_FI_PERFORM__P).
This function module determines the active implementations for each enhancement and stores them in an internal table. The implementing function modules are processed in the sequence defined by the internal table. At this point the system also considers the conditions under which the function module will be processed in the customer namespace - for example, the country or application. These conditions are also shown as filter values.
This graphic shows the syntax used to call a program enhancement using a business transaction event.
In the SAP application program, a function module is called with the name
"OPEN_FI_PERFORM__E" (or, for process interfaces, "OPEN_FI_PERFORM__P").
The application program passes data to the service function module using the interface. SAP developers have already designed the interface.
The service function module searches for active implementations and places them in an internal table. They are then processed in a loop.
Business transaction events allow you to implement additional logic in a task function, similar to function module exits. SAP application programmers determine where to place business transaction events in a task function and what data should be transferred at each point. They also create sample function modules complete with short texts, an interface, and documentation, and describe the functions possible with the enhancement in the accompanying SAP documentation.
First, SAP application programmers assign a business transaction event an eight digit number by which it can be identified. These numbers should observe a particular convention. For example, the fifth and sixth digits should be identical with events in the same program.
The SAP developer registers the event and creates a template function module,
sample_interface_ , which establishes the interface for the user.
To find out directly whether an application transaction offers business transaction events, you can use the procedure described on the left-hand side of the graphic. In the program source text, search for the character string "OPEN_FI_PERFORM". The number that completes the name of the function module is also the name of the event.
In the SAP Customizing Implementation Guide (IMG), you will find the entry "Use business transaction events " under the "Financial Accounting Global Settings" node of the Financial Accounting area. Choosing this entry calls a transaction (FIBF) where you can execute all of the actions necessary for using Business Transaction Events.
Under Environment, you will find search functions that you can use to identify appropriate business transaction events. You can view the documentation for the event from the list.
The "Environment "menu of the service transaction FIBF contains two programs that you can use to search for BTEs. You can restrict the search by using various parameters.
The BTEs that the system finds are displayed in a list. You can then:
Display the model function module (start the Function Builder and copy it, for example)
Display the interface
Display the documentation
The documentation provides a clear explanation of how to use the enhancment and any restrictions that apply to it.
Use service transaction FIBF to create a product. A product groups together a collection of enhancements.
You can create products for various layers in the delivery chain. They define a sequence for processing the implementations of a business transaction event.
You can only switch each product on or off as a whole entity. This allows the user to control which enhancements should be processed and which should not. It also ensures the integrity of the whole enhancement.
You can use the transaction FIBF (called when you selected "Use business transaction events" from the financial accounting hierarchy) to carry out all necessary activities prior to using a business transaction event.
First, you must choose an interface to attach your function module to. The Interface button displays the parameter structure for the interface you have selected. You can also use the documentation to determine what functions each interface allows you to perform.
Use the ABAP Workbench to copy the sample function module sample_interface_ to the customer namespace (z_*) of a customer function group. You must not change the interface. You can fill the module with any source text except COMMIT WORK. Don't forget to activate the function module.
Create a product in transaction FIBF.
Assign a number to your function module and product.
In contrast to customer exits, business transaction events are client-specific. This means that the same event can be used in different clients for different purposes.
Business transaction events may also be used more than once.
With Publish & Subscribe interfaces, you can choose which enhancement you want to use.
With process interfaces, the system executes a single component in the hierarchical sequence SAP application, add on, customer.
RELATED POST
Subscribe to:
Post Comments (Atom)
Content
-
▼
2009
(120)
-
▼
March
(87)
- WORK FLOW SCENARIOS IN SD SAP II
- WORK FLOW SCENARIOS IN SD SAP I
- WORK FLOW SAP IV
- WORK FLOW SAP III
- WORK FLOW SAP II
- WORK FLOW SAP I
- BDC SAP X
- BDC SAP IX
- BDC SAP VIII
- BDC SAP VII
- BDC SAP VI
- BDC SAP V
- BDC SAP IV
- BDC SAP III
- BDC SAP II
- BDC SAP I
- BADI SAP III
- BADI SAP II
- BADI SAP I
- BAPI SAP IV
- BAPI SAP III
- BAPI SAP II
- BAPI SAP I
- TABLE CONTROL IN BDC
- USER EXITS IN DETAIL
- BDC AND LSMW COMPARISION
- MODIFICAITONS EXITEDED 57
- SAP MODIDICAITONS 56
- BUSINESS ADD INS 55
- BUSINESS TRANSACTION EVENTS 53
- ENHANCEMENTS USING COSTMER EXITS 54
- ENHANCEMENTS TO DICTIONERY ELEMENTS 52
- CHANGING THE SAP STANDARD 51
- AUTHORISATION CHECKS 50
- COMPLEX LUW PROCESSING 49
- ORGANIZING DATA BASE UPDATES 48
- SAP LOCK CONCEPT 47
- LUW’S AND CLIENT/SERVER ARCHITECHERE 46
- OVERVIEW OF DATABAE UPDATES XXXXV
- LISTS IN SCREEN PROGRAMMING XXXXIV
- CONTEXT MENUS ON SCREENS XXXXIII
- SCREEN ELEMENTS ANDTABLE CONTROLS XXXXII
- SUBSCREEN TABSTRIPS XXXXI
- SCREEN ELEMENTS FOR INPUT AND OUTPUT XXXX
- SCREEN ELEMENTS FOR OUTPUT XXXIX
- IDOC AND BAPI
- DIFFERENCE BETWEEN CONVERSION AND INTERFACE
- INTRODUCITON TO SCREEN PROGRAMMING XXXVIII
- INTERACTIVE LIST TECHNIQUES XXXVII
- SAP LANDSCAPE
- PROGRAM INTERFACE XXXVI
- BASICS OF INTERACTIVE REPORTS XXXV
- ALV GRID CONTROL XXXIV
- SAVING LISTS AND BACK GROUND PROCESSING XXXIII
- DATA FORMATTING AND CONTROL LEVEL PROCESSING XXXII
- SAP QUARY ADMINSTRATION XXXI
- PROGRAMMING DATA RETRIVAL XXX
- LOGICAL DATA BASES XXVIII
- SELECTION SCREENS ABAP REPORT XXIX
- ALV DOCUMENTATION COMPLETE
- FAQ'S ON ABAP CROSS APPLICATIONS
- TECHNIQUES FOR LIST CREATION AND SAP QUARY XXVI
- CALLING PROGRAM AND PASSING DATA XXV
- FUNCTION MODULES AND GROUPS OF ABAP XXIV
- SUB ROUTIENS IN ABAP XXIII
- INTERNAL TABLES IN ABAP XXII
- ABAP STATEMENTS XXI
- DATA TYPES AND DATA OBJECT XX
- ABAP RUN TIME ENVIRONMENT XIX
- SEARCH HELP XVIII
- VIEWS IN ABAP XVII
- CHANGES TO DATA BASE TABLES XVI
- DEPENDENCIES OF DICTIONARY OBJECTS XV
- CONSITENCEY THROUGH INPUT CHECKS XIV
- PERFORMANCE DURING TABLE ACCESS XIII
- ABAP DICTIONARY XII
- ABAP PROJECT OVERVIEW - XI
- REUSE COMPONENTS - X
- DIALOGS AND SCREENS - IX
- USER DIALOGS AND SELECTION SCREEN - VIII
- USER DIALOGS-LISTS - VII
- INTERNAL PROGRAM MODULARIZATION - VI
- DATA BASE DIALOG - V
- ABAP DATA OBJECTS AND STATEMENTS - IV
- ABAP WORK BENCH AND TOOLS - III
- SAP ARCHETECHERE AND DESIGN - II
- SAP NAVIGATION - I
-
▼
March
(87)
Privacy Policy
The articles are copyrighted to Technical Information and can only
be reproduced given the author's permission.Information furnished
in the blog is collected from various Resources.This blog does not
host any files on its server. Please report any broken links in
comment.
If u have any queries contact me at
technicalinformation.websites@gmail.com
0 comments:
Post a Comment