Beruflich Dokumente
Kultur Dokumente
The actual program code is enhanced using ABAP Objects. In order to better
understand the programming techniques behind the Business Add-In
enhancement concept, SAP recommends reading the section on ABAP Objects.
What is difference between badi and user-exists?
What is difference between enhancements and user-exists? and what is the
full form of BADI?
I have another doubt in BDC IN BDC WE HAVE MSEGCALL (i did not
remember the > correct name) where the error logs are stored,
MSEGCALL is a table or structure.
What is the system landscape?
1) Difference between BADI and USER-EXIT.
i) BADI's can be used any number of times, where as USER-EXITS can be
used only one time.
Ex:- if your assigning a USER-EXIT to a project in (CMOD), then you can
not assign the same to other project.
ii) BADI's are oops based.
2) About 'BDCMSGCOLL' it is a structure. Used for finding error records.
3) Full form of BADI 'Business addins'.
3) System land scape will be depends on your project
Ex:- 'Development server'-->'Quality server'---> 'Production server'......
Note that an enhancement can only be used in 1 project. If the enhancement is already in
use, and error message will be displayed
Press Save
Press Components. You can now see that enhancement uses user exit
EXIT_SAPMV45A_002. Double click on the exit.
Now the function module is displayed. Double click on include ZXVVAU04 in the
function module
Insert the following code into the include: E_KUNNR = '2155'.
Activate the include program. Go back to CMOD and activate the project.
Goto transaction VA01 and craete a salesorder.
Note that Sold-to-party now automatically is "2155"
SAP creates user exits for specific programs, screens, and menus within standard R/3
applications. These exits do not contain any functionality. Instead, the customer exits act
as hooks. You can hang your own add-on functionality onto these hooks.
Types of Exits
There are several different types of user exits. Each of these exits acts as hooks where
you can attach or "hang" your own add-ons.
Menu Exits
Menu exits add items to the pulldown menus in standard SAP applications. You can use
these menu items to call up your own screens or to trigger entire add-on applications.
SAP creates menu exits by defining special menu items in the Menu Painter. These
special entries have function codes that begin with "+" (a plus sign). You specify the
menu items text when activating the item in an add-on project.
Screen Exits
Screen exits add fields to screens in R/3 applications. SAP creates screen exits by placing
special subscreen areas on a standard R/3 screen and calling a customer subscreen from
the standard screens flow logic.
Function Module Exits
Function module exits add functions to R/3 applications. Function module exits play a
role in both menu and screen exits.
When you add a new menu item to a standard pull down menu, you use a function
module exit to define the actions that should take place once your menu is activated.
Function module exits also control the data flow between standard programs and screen
exit fields. SAP application developers create function module exits by writing calls to
customer functions into the source code of standard R/3 programs.
These calls have the following syntax:
CALL CUSTOMER-FUNCTION 001.
Field Exits
Field exits allow you to create your own programming logic for any data element in the
Dictionary. You can use this logic to carry out checks, conversions, or business-related
processing for any screen field. Example: The data element BBBNR identifies a
companys international location number. You might want to set up your R/3 System so
that all international location numbers are larger than 100.
The field exit concept lets you create a special function module that contains this logic.
You assign the special function module to the data element BBBNR. You then assign the
module to any programs and screens in which users can add new international location
numbers. When you activate your field exit, the system automatically triggers your
special routine whenever a user enters a company location number.
In 4.6c, you can use "RSMODPRF" program to create field exits.
An example of a user exits :MODULE user_exit_0001 INPUT
CASE okcode.
WHEN 'BACK OR EXIT'.
CASE sy-dynnr.
WHEN '100'.
SET SCREEN 0.
LEAVE SCREEN.
WHEN '200'.
************************************************************************
******
**** Note that you can write any code that satisfy your
needs.
****
**** But in this case, this was wrote as a sample code for reference
sake.
****
**** And you can test
it.
****
************************************************************************
******
SET SCREEN 100.
LEAVE SCREEN.
ENDCASE.
ENDCASE.
USEREXIT
Userxits allow us to add our own functionality to SAP standard program
without modifying it . These are implemented in the form of subroutines and hence are also
known as FORM EXITs. The userexits are generally collected in includes and attached to the
standard program by the SAP.
All Userexits start with the word USEREXIT_...
FORM USEREXIT_..
z..
ENDFORM.
The problem lies in finding the correct userexit and how to find it if one exists for the purpose.
Once the correct userexit is found the necessary
customer code is inserted in the customer include starting with the z..
in the form routine.
e.g. USEREXIT_SAVE_DOCUMENT_PREPARE
Certain application like SD still provide this form of enhancement using userexit but this practice
is no longer being followed for newer extensions
instead they are using EXITs which come bundeled in enhancement packages . Neverthiless
existing USEREXITS will be supported by SAP an all the newer versions of SAP.
HOW TO FIND USEREXITS
Userexits can be found in number of ways:
1) To find userexits in SD module , goto object navigator(SE80) and select
development class from the list and enter VMOD in it. All of the userexits in SD are contained
in the development class VMOD. Press
enter and you will find all the includes which contain userexits in SD for
different functions like PRICING, ORDER PROCESSING etc. Select the userexit according to the
requirement and read the comment inserted in it
and start coding .
Some examples of userexits in SD(SALES & DISTRIBUTION ) are:
1)ADDING OF NEW FIELDS IN PRICING
In Pricing in SD the fields on the basis of which pricing is done are derived from the FIELD
CATALOG which is a structure KOMG .This structure is used to transfer transaction data to the
pricing procedure in SD and is also known as communication structure.This structure KOMG
consists of two tables KOMK for Header related fields and KOMP for item related fields.
The fields which are not in either of the two tables KOMK and KOMP
cannot be used in pricing .Sometimes a need arises when the pricing
is to be based on some other criteria which is not present in the form of fields in either of the two
tables.
This problem can be solved by using USEREXITS which are provided for pricing in SD.
Pricing takes place both when the SALES ORDER ( Transaction VA01) is created as well as
when INVOICING ( Transaction VF01) is done.Hence SAP provides 2 userexits ,one for sales
order processing which is
USEREXIT_PRICING_PREPARE_TKOMP or
USEREXIT_PRICING_PREPARE_TKOMK
Depending upon which table (KOMK or KOMP) the new fields were inserted we use either of the
above two userexits.These userexits are found in include MV45AFZZ of the standard SAP sales
order creation program SAPMV45A.
In the case of userexit which will be called when invoicing is done ,these
are provided in the include RY60AFZZ which is in the standard SAP
program SAPMV45A. The name of the userexits are same. i.e
USEREXIT_PRICING_PREPARE_TKOMP or
USEREXIT_PRICING_PREPARE_TKOMK
These userexits are used for passing the data from the communication structure to the pricing
procedure, for this we have to fill the newely
created field in the communication structure KOMG for this we fill the code in the above userexit
using the MOVE statement after the data that
has to be passed is taken from the database table by using the SELECT statement. The actual
structure which is visible in these userexits and which is to be filled for that particular field is
TKOMP or TKOMK.
Before the coding for these userexits is done ,it is necessary to create a new field in either of the
two tables KOMK or KOMP .For this purpose
includes are provided in each of them .
To create the field in header data(KOMK) the include provided is KOMKAZ
and to create the field in item data(KOMP) the include provided is KOMPAZ.
One possible example for the need of creating new fields can be e.g. Frieght to be based upon
transportation zone ,for this no field is available in field catalog and hence it can be created in
KOMK and then above userexits can be used to fill the transportation data to it.
2)The other method of finding userexit is to find the word USEREXIT in the
associated program of the transaction for which we want to determine userexit using SE38.
3)The other method of finding userexits is to find the include in case of SD/MM applications
where the userexits are located ,this can be found in the SAP reference IMG generally in the
subfolder under SYSTEM MODIFICATION.
Some other examples of userexits in SD are:
USEREXIT_NUMBER_RANGE
This userexit is used to assign a different internal document number to the
sales order(VA01) when it is created depending on some criteria like a different SALES
ORGANIZAION(VKORG) .
USEREXIT_SAVE_DOCUMENT_PREPARE
This userexit is used to insert the ABAP code which will be called when
the document (sales order VA01) is just about to be saved.This userexit is used generally for
custom checks on different fields , to display some information before the order will be saved or
for making changes to certain fields before the sales order will be saved.
Exits & Enhancements
There are mainly six types of EXITs in sap which have been collected in the form of
enhancement packages and attached to standard code in SAP.
These are different from USEREXIT in the way that they are implemented
in the form of FUNCTIONs while in USEREXITS we use form routines for their implementation.
These are also sometimes known as function exits .
These start from the word EXIT_ followed by the program name and then followed by a three
digit number.
e.g. EXIT_SAPMV45A_002
This exit is found in SD in enhancement V45A0002.
TYPES OF EXITS
1)MENU EXITS
2)FUNCTION EXITS
3)TABLE EXITS
4)SCREEN EXITS
5)KEYWORD EXITS
6)FIELD EXITS
We use SAP transactions CMOD and SMOD to manage exits. Before implementing an exit , it is
required to create the project by using CMOD
selecting the enhancement e.g. V45A0002 and selecting the component
(one which fulfills our need) i.e the exit which will be implemented in SMOD and after coding has
been done the project has to be activated.
An exit can be coded only once.
FUNCTION EXITS
These are used to add functionality through ABAP code . These start from the word
EXIT_programname_NNN ending in a 3 digit number. No access code is required to implement
any tupe of exit including function exits.
The function exits are called from the standard SAP program in the form
of ABAP statement
CALL CUSTOMER-FUNCTION 'NNN'
This is in contrast to USEREXITs where PERFORM statement is used to call
the required userexit.
To implement the FUNCTION EXITs first of all the project is created and a suitable enhancement
package is selected and from its compnents the function exit to be implemented is selected and
on double clicking it the exit code will appear in ABAP EDITOR(se38) where a Z include will be
found and the customer code should be entered in this include.
e.g.
ADDING A DEFAULT SOLD-TO-PARTY in Sales Order Creation
To show a default sold-to-party in this field when the user creates a sales order (VA01) we can
use a function exit .This function exit is located
in enhancement no V45A0002 . Before we can choose the exit we have to
create a project in CMOD after that enter V45A0002 in the enhancement field and click on the
components . In the components you will see the
exit EXIT_SAPMV45A_002 . This exit is used for our purpose.
Double clicking on this exit will takes us to function builder (SE37) . This
function exit has one exporting parameters and two importing parameters, we are interested in
exporting parameter which is E_KUNNR
of type KNA1-KUNNR i.e if we move the desired customer name to this
structure(E_KUNNR) it will be shown in the field as the default value when we create the sales
order.
This function also contains a customer include ZXVVA04 . This include
will be used to write our custom code .
Double clicking on this include and it will prompt us that this include does not exists do you want
to create this object ,select yes and the include will be created .In this include we can write our
own code that will fill the field E_KUNNR.
e.g. E_KUNNR = 301.
Activate the include and Activate the project. Now when ever the SALES ORDER will be created ,
sold-to-party field will come up with a predefined
customer .
FIELD EXITS
The field exits are managed,created,activated through program RSMODPRF. The field exit is
associated with a data element existing in ABAP dictionary and hence to the screen field using
that data element.
The format of field exit is :
FIELD_EXIT_dataelement_A-Z or 0-9
If a particular screen and program name is not specified than the field exit will effect all the
screens containing that data element.
The function module associated with field exit shows two parameters
INPUT and OUTPUT. Input parameter contains the data passed to the field exit when the field
exit was invoked by the R/3 , We can write our own code to change the output parameter
depending upon our requirements.
Before the field exit can have any effect the system profile parameter
ABAP/FIELDEXIT in all the application servers should be set to YES
ABAP/FIELDEXIT = YES.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CCUXOBTY |Object Types for the Object Search for Class Nodes
|
CCUXSETM |Saving of Manual Changes for SET Processing
|
CCUXSETQ |Component Quantities for Set Handling
|
CCUXSTAT |Define BOM Status for Instantiated Materials
|
CEI00000 |Availability of Customer Functions in Configuration Editor |
CEPEX001 |User Exit CEP: Authorization Check for Folder
|
CI200001 |Activate new component processing
|
CIFBTC01 |Enhancement for Transferring Customer-Specific Batch Fields |
CIFCID3 |User Exits for Deltareport3
|
CIFCNF01 |Customer Enhancements APO Integration Confirmation
|
CIFEVT01 |Core Interface with APO: Enhancements for Event Processing |
CIFIMO01 |Enhancement in Integration Model Creation
|
CIFIRQ01 |Enhancement for Requirement Reduction (Outbound)
|
CIFLOC01 |Enhancement for Transferring Customer-Specific Loc. Fields |
CIFLOC02 |Enhancement for Transferring Customer-Spec. Location Fields |
CIFMAT01 |Enhancement for Transferring Customer-Specific Matl Fields |
CIFMAT02 |Extension for Transferring Deactivated Materials
|
CIFORD01 |Enhancement for Incoming Orders Interface
|
CIFORD02 |Enhancement for Transferring Customer-Specific Order Fields |
CIFORD03 |Enhancement for In-House Prod. Order Inc.for Customer Fields|
CIFORD04 |Determine Rework Operations or Triggering Operation
|
CIFPCM01 |Enhancement for Recipient Processing in Production Campaign |
CIFPIR01 |Enhancement of Incomng Ind. Requirements for Customer Fields|
CIFPIR02 |Enhancement for Transfer of Planned Independent Reqs to APO |
CIFPPM01 |Core Interface for APO: Enhancements for PPM Model
|
CIFPPM02 |Enhancement for Transferring Customer-Specific PPM Fields |
CIFPUR01 |Enhancement for Transferring Customer-Specific PO Fields |
CIFPUR02 |Enhancement of Purchase Order Interface (Inbound)
|
CIFPUR41 |Suppression of Quota Arrangement Info. for APO Transfer |
CIFRES01 |Customer Exit for Resource Transfer
|
CIFRSV02 |Inbound Processing for Manual Reservations
|
CIFSHLF1 |Customer Exits for Shelf Life
|
CIFSLS02 |Enhancement for Sales Order Interface (Inbound)
|
CIFSLS03 |Influencing of Sales Order Data Prior to Dispatch
|
CIFSLS04 |Influencing of Reservation Data Prior to Dispatch
|
CIFSRC01 |Enhancement for Transferring Customer-Specific SS Fields |
CIFSTK01 |Enhancement for Transferring Customer-Specific Stock Fields |
CKML |User exits for actual cost accounting
|
CLCLRS01 |Additional Fields on the Result Screen
|
CLCLRS02 |Fill the Additional Fields on the Result Screen
|
CLCTMS01 |Default values for finding objects
|
CLCTMS02 |Check for Same Classification
|
CLCTMS03 |Dependencies for Finding Objects
|
CLFM0001 |Change or set default for classification of object
|
CLFM0002 |Call classification data before saving
|
CLFM0003 |Call Up After Check of Assigned Characteristic Values
|
CLIDL001 |Object Table Customizing for Initial Data Transfer
|
CLMMD001 |Selection of Objects for Mass Processing
|
CLSC0001 |Manipulation of search result
|
CMDI001 |Determine explosion control for BOM
|
CMFU0001 |Define customer-specific screen layout
|
CMFU0002 |Set parameters for time confirmation and goods movements |
CMW8DL01 |Enhancement CIF middleware user exit for delivery (inbound) |
CMW8SH01 |Enhancement CIF middleware user exit for shipments (inbound)|
CNEX0001 |PS: User fields
|
CNEX0002 |PS Authorization check
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3. Execute (F8).
You will find all the User Exit for the TCode.
This chapter focuses on writing user exits for your SQL*Forms and Oracle Forms
applications. First, you learn the EXEC IAF statements that allow a SQL*Forms
application to interface with user exits. Then, you learn how to write and link a
SQL*Forms user exit. You also learn how to use EXEC TOOLS statements with Oracle
Forms. (SQL*Forms does not support EXEC TOOLS.) That way, you can use EXEC IAF
statements to enhance your existing applications and EXEC TOOLS statements to build
new applications. The following topics are covered:
This chapter is supplemental. For more information about user exits, see the SQL*Forms
Designer's Reference, the Oracle Forms Reference Manual, Vol. 2, and your systemspecific Oracle manuals.
User exits are harder to write and implement than SQL, PL/SQL, or SQL*Forms
commands. So, you will probably use them only to do processing that is beyond the
scope of SQL, PL/SQL, and SQL*Forms. Some common uses follow:
host-language
EXEC SQL
EXEC ORACLE
EXEC IAF GET
EXEC IAF PUT
This section focuses on the EXEC IAF GET and PUT statements, which let you pass
values between SQL*Forms and a user exit.
field
block.field
system variable
global variable
host variable (prefixed with a colon) containing the value of a field, block.field,
system variable, or global variable
All field values are character strings. If it can, GET converts a field value to the datatype
of the corresponding host variable. If an illegal or unsupported datatype conversion is
attempted, an error is generated.
In the last example, a constant is used to specify block.field. You can also use a host
string to specify block and field names, as follows:
Unless the field is unique, the host string must contain the full block.field reference with
intervening period. For example, the following usage is invalid:
set blk = 'employee';
set fld = 'job';
EXEC IAF GET :blk.:fld INTO :new_job;
You can mix explicit and stored field names in a GET statement field list, but not in a
single field reference. For example, the following usage is invalid:
set fld = 'job';
EXEC IAF GET employee.:fld INTO :new_job;
field
block.field
system variable
global variable
host variable (prefixed with a colon) containing the value of a field, block.field,
system variable, or global variable
The following example shows how a user exit PUTs the values of a numeric constant,
string constant, and host variable into fields on a form:
EXEC IAF PUT employee.number, employee.name, employee.job
VALUES (7934, 'MILLER', :new_job);
Like GET, PUT lets you use a host string to specify block and field names, as follows:
set blkfld = 'employee.job';
EXEC IAF PUT :blkfld VALUES (:new_job);
On character-mode terminals, a value PUT into a field is displayed when the user exit
returns, rather than when the assignment is made, provided the field is on the current
display page. On block-mode terminals, the value is displayed the next time a field is
read from the device.
If a user exit changes the value of a field several times, only the last change takes effect.
where user_exit_string contains the name of the user exit plus optional parameters and
error_string contains an error message issued by SQL*Forms if the user exit fails. For
example, the following trigger command calls a user exit named LOOKUP:
USER_EXIT('LOOKUP');
Notice that the user exit string is enclosed by single (not double) quotes.
You can use this feature to pass field names to the user exit, as the following example
shows:
USER_EXIT('CONCAT firstname, lastname, address');
However, it is up to the user exit, not SQL*Forms, to parse the user exit string.
Using WHENEVER
You can use the WHENEVER statement in an exit to detect invalid datatype conversions
(SQLERROR), truncated values PUT into form fields (SQLWARNING), and queries that
return no rows (NOT FOUND).
An Example
The following example shows how a typical user exit is coded. Notice that, like a host
program, the user exit has a Declare Section and a SQLCA.
-- subroutine MYEXIT
EXEC SQL BEGIN DECLARE SECTION;
field1
CHARACTER(20);
field2
CHARACTER(20);
value1
CHARACTER(20);
value2
CHARACTER(20);
result_val CHARACTER(20);
EXEC SQL END DECLARE SECTION;
errmsg CHARACTER(80);
errlen INTEGER;
EXEC SQL INCLUDE SQLCA;
EXEC SQL WHENEVER SQLERROR GOTO sqlerror;
-- get field values from form
EXEC IAF GET :field1, :field2 INTO :value1, :value2;
-- manipulate values to obtain result_val
-- put result_val into form field
EXEC IAF PUT result VALUES (:result_val);
return(IAPSUCC);
-- trigger step succeeded
sqlerror:
set errmsg = CONCAT('MYEXIT: ', sqlca.sqlerrm.sqlerrmc);
set errlen = LENGTH(errmsg);
sqliem(errmsg, errlen); -- pass error message to SQL*Forms
return(IAPFAIL); -- trigger step failed
A form is displayed that allows you to enter the following information for each user exit
you define:
exit name
host-language code (COB, FOR, PAS, or PLI)
date created
date last modified
comments
After modifying the IAPXTB database table, use the GENXTB utility to read the table
and create an Assembler or C source program that defines the module IAPXIT and the
IAPXTB program table it contains. The source language used depends on your operating
system. The syntax you use to run the GENXTB utility is
GENXTB username/password outfile
where outfile is the name you give the Assembler or source program that GENXTB
creates.
Connecting to Oracle
User exits communicate with Oracle via the connection made by SQL*Forms. However,
a user exit can establish additional connections to any database via SQL*Net. For more
information, see "Concurrent Logons" .
Updating Tables
Generally, a user exit should not UPDATE database tables associated with a form. For
example, suppose an operator updates a record in the SQL*Forms work space, then a user
exit UPDATEs the corresponding row in the associated database table. When the
transaction is COMMITted, the record in the SQL*Forms work space is applied to the
table, overwriting the user exit UPDATE.
Issuing Commands
Avoid issuing a COMMIT or ROLLBACK command from your user exit because Oracle
will commit or roll back work begun by the SQL*Forms operator, not just work done by
the user exit. Instead, issue the COMMIT or ROLLBACK from the SQL*Forms trigger.
This also applies to data definition commands (such as ALTER andCREATE) because
they issue an implicit COMMIT before and after executing.
SET
GET
SET CONTEXT
GET CONTEXT
MESSAGE
The EXEC TOOLS GET and SET statements replace the EXEC IAF GET and PUT
statements used with SQL*Forms. Unlike IAF GET and PUT, TOOLS GET and SET
accept indicator variables. The EXEC TOOLS MESSAGE statement replaces the
message-handling function SQLIEM. The EXEC TOOLS SET CONTEXT and GET
CONTEXT statements are new and not available with SQL*Forms, Version 3.
Note: COBOL and FORTRAN do not have a pointer datatype, so you cannot use the SET
CONTEXT and GET CONTEXT statements in a Pro*COBOL or Pro*FORTRAN
program.
In the following Pro*C example, your user exit passes an employee name (with optional
indicator) to Oracle Forms:
EXEC SQL BEGIN DECLARE SECTION;
...
char ename[20];
short ename_ind;
EXEC SQL END DECLARE SECTION;
...
strcpy(ename, "MILLER");
ename_ind = 0;
EXEC TOOLS SET emp.ename VALUES (:ename:ename_ind);
where the optional keyword IDENTIFIED can be used to improve readability and
context_name is an undeclared identifier or a character host variable that names the
context area.
In the following example, your user exit saves context information for later use:
EXEC SQL BEGIN DECLARE SECTION;
...
char context1[30];
EXEC SQL END DECLARE SECTION;
...
strcpy(context1, "This is context1");
EXEC TOOLS SET CONTEXT :context1 BY my_app1;
In this example, the context name my_app1 is an undeclared identifier. Note that in C,
when a char array is used as an argument, the array name is synonymous with a pointer
to that array.
The EXEC TOOLS MESSAGE statement passes a message from your user exit to Oracle
Forms. The message is displayed on the Oracle Forms message line after the user exit
returns control to the form.
To code the EXEC TOOLS MESSAGE statement, you use the syntax
EXEC TOOLS MESSAGE message_text [severity_code];
where message_text is a quoted string or a character host variable, and the optional
severity_code is an integer constant or host variable. The MESSAGE statement does not
accept indicator variables.
In the following Pro*C example, your user exit passes an error message and severity code
to Oracle Forms:
EXEC TOOLS MESSAGE 'Bad field name! Please reenter.' 15;
New Features
This appendix looks at the improvements and new features offered by the Oracle
Precompilers Release 1.8. Designed to meet the practical needs of professional software
developers, these features will help you build effective, reliable applications.
Using DBMS=V6
Applications precompiled with DBMS=V6 maintain full compatibility with Oracle
Version 6. When upgrading to Oracle7, if you precompile with DBMS=V6 specified,
your applications will be unaffected by the ORA-01405 messages.
If you are upgrading to Oracle7 and use DBMS=V7 when precompiling, or if you intend
to use new Oracle7 features that are different from Oracle Version 6, in most instances,
the change requires minimal modification to your source files. However, if your
application may FETCH null values into host variables without associated indicator
variables, specify UNSAFE_NULL=YES to disable the ORA-01405 message and avoid
adding the relevant indicator variables to your source files. More on :
http://www.stanford.edu/dept/itss/docs/oracle/10g/appdev.101/a42525/apc.htm