SAP Script Controls Complete Information for ABAPER


The functionality of the SAP script editor is made available through a set of commands which the user selects either from the menu or via the function (F-) keys. These commands give you full editing control over your text. They are executed immediately when called.There is, however, another kind of SAP script command, namely the control commands. The purpose of these is to allow control of the output formatting. These commands are not interpreted by the SAPscript editor, but are passed through to the SAPscript Composer for processing.

The Composer is the program that converts text from the form displayed in the editor to the form used for printing. This includes, for example, line and page formatting, the replacement of symbols with their current values and the formatting of text according to the paragraph and character formats specified.


The CASE command

Calling ABAP/4 Subroutines: PERFORM
Inserting Print Controls: PRINT-CONTROL
Boxes, Lines, Shading: BOX, POSITION, SIZE
Hexadecimal Data: HEX, ENDHEX
Summing a Program Symbol: SUMMING


The Syntax of Control Commands

SAPscript control commands are entered and edited in the text editor in the same way as a normal line of text. They do, however, differ from normal lines of text in respect to the following points:

  1. • The paragraph format /: must be entered in the format column to identify a control command.
  2. • You enter the command itself in the text line. You will notice that all key words and other parts of the specification not given as literal values enclosed in apostrophe characters are automatically converted to capital letters.
  3. • A control command, together with any parameters it requires, may not occupy more than a single line.
  4. • A maximum of one control command may appear in each line.
  5. • The editor formatting has no effect on lines containing control commands.


If a control command is unknown or it contains syntax errors, the line containing it will be treated as a comment line. It will be neither interpreted nor output.


Explicit Page Break: NEW-PAGE

SAPscript automatically inserts a page break when the main window of a page (MAIN) is full. You can use the NEW-PAGE command to force a page break in the text at any point you want one. The text following this command will appear on a new page. The page break will always be performed (it is an unconditional page break).


The NEW-PAGE command completes the current page. This means that all the windows that are still on the page will be output immediately. If you use the NEW-PAGE command without parameters then the page defined in the layout set for the current page as the next page will be taken next. If, however, your layout set contains a number of different pages then you can specify any one of these as the next page to be used.


Syntax:
/: NEW-PAGE [page_name]

/: NEW-PAGE
The current page will be completed and the text in the following lines will be written to the page specified in the layout set.
/: NEW-PAGE S1


As above, except that the page S1 will taken as the next page.

• If a page not contained in the layout set is specified in a NEW-PAGE command then this specification is ignored.
• You should take care that there is not an blank line immediately before a NEW-PAGE command. This would serve no useful purpose and may lead to an unexpected blank page being printed. This would happen if an implicit page break would normally occur within the blank line.



Preventing Page Breaks: PROTECT


You can specify either in the style or in the layout set that a particular paragraph should not be split in two by a page break. If the page protect attribute is set then the complete paragraph is always output on a single page. This property applies only to that particular paragraph.This attribute is not intended to be used to protect all paragraphs against a page break. The point is that a page break is by its very nature a dynamic event and the exact point at which it occurs depends on the current state (length and contents) of the preceding text. It is also possible that one may want to protect only certain parts of a paragraph against a page break.

In principle one could achieve this through the use of the NEW-PAGE command immediately before the text concerned. Explicitly beginning a new page at this point should ensure that a further page break does not occur within the text. However, this technique is not change-resistant.

Assume, for example, that you have formatted your text with the help of the NEW-PAGE command such that no page breaks occur where they should not, and that you now insert some new lines or delete some existing lines. These changes will cause all the subsequent text to be moved relative to the printed page, and you will therefore need to check each NEW-PAGE command you had previously inserted to see if it is still in the correct place.

SAPscript provides the PROTECT .. ENDPROTECT command pair to allow you to define the areas to be protected against a page break on an individual basis. If you enclose the text to be protected in these commands, then SAPscript will ensure that each line of this text is printed together on the same page.

If the complete text fits in the space remaining on the current page, then it is output on that page just as it would be if no PROTECT command had been used. If, however, the remaining space is not sufficient for the text, then the PROTECT command has the same effect as a NEW-PAGE command and text is printed on a new page.

Thus the PROTECT/ENDPROTECT commands may be regarded as a kind of conditional NEW-PAGE command, the condition being whether or not the lines enclosed between the two commands fit in the space remaining in the current main window.


Syntax:
/: PROTECT
:
:
/: ENDPROTECT

The text lines to be protected are enclosed between the two commands.

• An ENDPROTECT command without a preceding PROTECT command has no effect.
• If the terminating ENDPROTECT is missing, then it will be assumed at the end of the text.
• PROTECT .. ENDPROTECT command pairs cannot be nested. If a second PROTECT command occurs before the first one has been terminated by an ENDPROTECT, it will be ignored.


• If the text enclosed by a PROTECT .. ENDPROTECT pair is itself too long for a single page, then a page break is generated immediately before the text and the text is output in the normal way. It is then unavoidable that a page break will occur at some point within the text.


Next Main Window: NEW-WINDOW

Each page can consist of up to 99 main windows. Each main window is assigned a consecutive identifying number (0..98), and the windows are filled in this order. This feature enables SAPscript to print labels and to output multi-column text. When one main window fills up, the next main window on that page is taken, if there is a next one. A page break is inserted after the last main window.


You can use the NEW-WINDOW command to call the next main window explicitly, even if the current main window is not yet full. If you are in the last main window of the page, the command has the same effect as the NEW-PAGE command.


Syntax:
/: NEW-WINDOW



Assigning a Value to a Text Symbol: DEFINE

Text symbols acquire their values as a result of explicit assignment. This assignment can be performed interactively in the text editor via the menu option Include -> Symbols -> Text. This method is available for all text symbols belonging to a text module as well as those of the associated layout set.


Values defined in this way are lost when the transaction is left. If the text module is to be printed again then the symbol values must all be entered again. The purpose of the DEFINE command is to provide a means of making this value assignment a permanent part of the text, so that the values are available again when the text module is called again. This command can also be used to re-assign a new value to a text symbol part way through the text.


Syntax:
/: DEFINE &symbol_name& = 'value'

/: DEFINE &subject& = 'Your letter of 7/3/95'
The value assigned can have a maximal length of 60 characters. It may itself contain other symbols. A symbol contained within the value assigned to another symbol is not replaced with its own value at the point at which the DEFINE command is executed. Rather, this replacement is made when the symbol defined in the DEFINE command is called in the text.


/: DEFINE &symbol1& = 'mail'
/: DEFINE &symbol2& = 'SAP&symbol1&'
/: DEFINE &symbol1& = 'script'
&symbol2& -> SAPscript


If, however, the DEFINE command is written using the ':=' character rather than the '=' character, then any symbol contained within the value being assigned will be replaced immediately with its current value. The assignment to the target symbol will only be made after all symbols in the value string have been replaced with their values. The total length of the value string may not exceed 80 characters. The target symbol must be a text symbol, as before.



/: DEFINE &symbol1& = 'mail'
/: DEFINE &symbol2& := 'SAP&symbol1&'
/: DEFINE &symbol1& = 'script'
&symbol2& -> SAPmail

Formatting Date Fields: SET DATE MASK

The formatting for date fields can be defined with the SET DATE MASK control command. Executing this command causes all subsequent date fields to be output using the specified format.


Syntax:
/: SET DATE MASK = 'date_mask'
The following codes can be used in the date mask:


• DD: day (two digits)
• DDD: day name - abbreviated
• DDDD: day name - written out in full
• MM: month (two digits)
• MMM: month name - abbreviated
• MMMM: month name - written out in full
• YY: year (two digits)
• YYYY: year (four digits)
• LD: day (formatted as for the L option)
• LM: month (formatted as for the L option)
• LY: year (formatted as for the L option)


All other characters found in a date mask are interpreted as simple text and are copied straight into the output.

Assuming the current system date is March 1st, 1994.
/: SET DATE MASK = 'Foster City, MM/DD/YY'
&DATE& -> Foster City, 03/01/94
/: SET DATE MASK = 'MMMM DD, YYYY'
&DATE& -> March 01, 1994
The date mask may be reset to the default setting by using an empty string:
/: SET DATE MASK = ' '


The abbreviated and full forms of the names of the days and months are stored in the language dependent TTDTG table under the following keys:


• %%SAPSCRIPT_DDD_dd: abbreviated day name
• %%SAPSCRIPT_DDDD_dd: full form of day name
• %%SAPSCRIPT_MMM_mm: abbreviated month name
• %%SAPSCRIPT_MMMM_mm: full form of month name

dd: day number 01 = Monday, ..., 07 = Sunday
mm: month number 01 = January, ..., 12 = December

Formatting Time Fields: SET TIME MASK

You can use the SET TIME MASK control command to format time fields as you require. Executing this command causes all subsequent time fields to be output using the specified format.

Syntax:

/: SET TIME MASK = 'time_mask'
The following codes can be used in the time mask:

• HH hours (two digits)
• MM minutes (two digits)
• SS seconds (two digits)


All other characters found in a time mask are interpreted as simple text and are copied straight into the output.

Assuming the current time is 10:08:12,
/: SET TIME MASK = 'HH:MM'
&TIME& -> 10:08
/: SET TIME MASK = 'HH hours MM minutes'
&TIME& -> 10 hours 08 minutes
The time mask may be reset to the default setting by using an empty string:
/: SET TIME MASK = ' '


Country-Dependent Formatting: SET COUNTRY

The formatting for certain field types depends on the country settings. These field types include, for example, date fields and number fields that include either a decimal point or the 'thousands' separator character. The formatting options defined in the user master record are usually the ones used here. The SET COUNTRY control command can be used to select a formatting option other than that specified in the user master record. The country-dependent formatting options are stored in the T005X table.

Syntax:
/: SET COUNTRY country_key
The country key can be specified either as a literal value enclosed in quotes or as a symbol.

/: SET COUNTRY 'CAN'
/: SET COUNTRY &country_key&
A blank country name can be used to revert to the setting found in the user master record:
/: SET COUNTRY ' '
This SAPscript command actually calls the corresponding ABAP command internally. Therefore the effect of the SAPscript command is guaranteed to be identical with that of the ABAP command.

If the formatting turns out not to be as required, then you should check the settings in the T005X table.

Position of the Leading Sign: SET SIGN

The usual convention in business applications is to show the leading sign to the right of the figure to which it applies. However, it is sometimes necessary to show the leading sign to the left of the figure. The SET SIGN control command can be used to specify this globally. Executing this command affects the formatting of all subsequent program symbols that possess a leading sign.


Syntax:
/: SET SIGN LEFT
The leading sign is output to the left of the number.
/: SET SIGN RIGHT
The leading sign is output to the right of the number.

Initializing Numbered Paragraphs: RESET

The RESET control command is used to reset the numbering of an outline paragraph to its initial value. If the RESET command is not used, then the numbering of all outline paragraphs in a text will be continuous. If the name of an outline paragraph is specified in the RESET command, then its paragraph numbering and that of subordinate paragraphs will be reinitialized.


Syntax:
/: RESET paragraph_format
The paragraph format specifies the outline paragraph to be reset.


Assume that the paragraph N1 is defined in the style you are using. This kind of paragraph is intended for enumerated lists and causes a sequential number to be output.


* Proceed as follows if you want to work with the SAP R/3 system:
N1 Ensure that you have a PC
N1 Switch the PC on
N1 Click on the SAP icon using the mouse.
* You will then enter the SAP logon screen. In order to log
on here, you must carry out the following actions:
/: RESET N1
N1 Enter your user name
N1 Enter your password
N1 Select the application you want to use


Proceed as follows if you want to work with the SAP R/3
system:


1. Ensure that you have a PC
2. Switch the PC on
3. Click on the SAP icon using the mouse.
You will then enter the SAP logon screen. In order to log on here, you must carry out the following actions:
4. Enter your user name
5. Enter your password
6. Select the application you want to use


Initializing Numbered Paragraphs: RESET

The RESET control command is used to reset the numbering of an outline paragraph to its initial value. If the RESET command is not used, then the numbering of all outline paragraphs in a text will be continuous. If the name of an outline paragraph is specified in the RESET command, then its paragraph numbering and that of subordinate paragraphs will be reinitialized.

Syntax:
/: RESET paragraph_format
The paragraph format specifies the outline paragraph to be reset.

Assume that the paragraph N1 is defined in the style you are using. This kind of paragraph is intended for enumerated lists and causes a sequential number to be output.


* Proceed as follows if you want to work with the SAP R/3
system:
N1 Ensure that you have a PC
N1 Switch the PC on
N1 Click on the SAP icon using the mouse.


* You will then enter the SAP logon screen. In order to log
on here, you must carry out the following actions:
/: RESET N1
N1 Enter your user name
N1 Enter your password
N1 Select the application you want to use
This text specification would be output as follows:


Proceed as follows if you want to work with the SAP R/3
system:


1. Ensure that you have a PC
2. Switch the PC on
3. Click on the SAP icon using the mouse.
You will then enter the SAP logon screen. In order to log on here, you must carry out the following actions:
1. Enter your user name
2. Enter your password
3. Select the application you want to use


If there were no RESET command between the two sections, then the two lists would be numbered in a single sequence:

Proceed as follows if you want to work with the SAP R/3
system:


1. Ensure that you have a PC
2. Switch the PC on
3. Click on the SAP icon using the mouse.


You will then enter the SAP logon screen. In order to log on here, you must carry out the following actions:
4. Enter your user name
5. Enter your password
6. Select the application you want to use

Including Other Texts: INCLUDE


You can use the INCLUDE control command to include the contents of another text into the current text. The text to be included continues to be treated as a separate text and is copied over only at the print at which the output is formatted.


Thus the use of the INCLUDE command always ensures that the most current version of a text is included into the output, since the text is not read and inserted until the output is formatted.
Syntax:
/: INCLUDE name [OBJECT o] [ID i] [LANGUAGE l] [PARAGRAPH p]
[NEW-PARAGRAPH np]


The name of the text to be inserted must be specified and can be up to 70 characters long. If the name of the text contains spaces, then it must be enclosed in quotes as a literal value. The name may alternatively be specified via a symbol. All remaining parameters in the INCLUDE command are optional. If an optional parameter is not specified, then SAPscript uses default values as applicable for the calling environment.


/: INCLUDE MYTEXT
The text MYTEXT is included in the language of the calling text.
/: INCLUDE MYTEXT LANGUAGE 'E' PARAGRAPH 'A1'
The text with the name MYTEXT and the language E is included, regardless of the language of the calling text. The paragraph format A1 will be used as the standard paragraph type for this call.

Optional parameters:

• LANGUAGE

If this parameter is not specified, then the language of the calling text or the layout set language are used for the text to be included. If the language is specified, then the text will be fetched in this language, regardless of the language of the calling text.

• PARAGRAPH

The text to be included is formatted using the style allocated. The PARAGRAPH parameter can be used to redefine the standard paragraph for this style for the current call. All *-paragraphs in the included text will then be formatted using the paragraph specified here.

• NEW-PARAGRAPH

The first line of the text to be included will be given this format indicator, as long as it is not a comment or command line. If the optional PARAGRAPH parameter (see above) is not specified, then all *-paragraphs of the included text will also be formatted using the paragraph np specified in the NEW-PARAGRAPH command.

• OBJECT

In order to completely specify a text, information about the text object is also required. There are a number of restrictions and other rules that depend on the object type of the calling text:

- Any kind of text can be included in a layout set. If no object is specified, then TEXT will be used (standard texts).


- In the case of a document text (DOKU object), you can include only document texts. This object type will also be assumed if no object is specified in this environment.
- Only hypertexts and document texts can be included in a hypertext (DSYS object). If the OBJECT parameter is missing, then DSYS is used as the default value.


- In the other kinds of text you can include only standard texts (TEXT object), document texts or hypertexts. If there is no specification, then the default object is TEXT.

• ID

The text-ID is a part of the text key which permits further text objects within a given object. If no ID is specified, then the default include ID is used from the TTXID table for the calling text. If there is no entry in this table, then the text-ID of the calling text is used.

The following consistency check is applied both to the ID and the object:

• All text-IDs are allowed in a layout set.
• In document texts only document texts may be included which have text-IDs TX (general texts) or UO (authorization objects) and also other document texts which have the same text-ID as the calling document text.


• In DSYS texts all DSYS texts can be included, whatever ID they have. Document texts to be included must have one of the IDs TX and UO.
• Standard texts with any allowable text-ID, DSYS texts with all IDs and document texts with the IDs TX and UO can be included into the other texts.

The INCLUDE command returns a status code in the SAPSCRIPT-SUBRC symbol:

• 0: the text include was successful.
• 1: the command could not be executed because it contained syntax errors.
• 2: the rules governing the text to be included were not followed (see above).

This value cannot occur if the command is used in a SAPscript layout set.

• 4: the specified text could not be found.


Changing the Style: STYLE

The STYLE control command allows you to change the style within a text. The new style is in force until another STYLE command is issued. If * is specified as the name of style, then the system reverts to the original style.


Syntax:
/: STYLE style
/: STYLE *


The STYLE command is automatically set in the text editor if another text module is inserted and immediately expanded using the menu option Include ® Text. The same thing happens if the contents of texts that have been included using INCLUDE are copied into the text via Edit ® Selected area ® Expand INCLUDE.
 
Formatting Addresses: ADDRESS

The ADDRESS - ENDADDRESS control command formats an address according to the postal convention of the recipient country defined in the COUNTRY parameter. The reference fields are described in the structures ADRS1, ADRS2, or ADRS3, depending upon the type of address. Either direct values or symbols may be assigned to the parameters.


Syntax:
/: ADDRESS [DELIVERY] [TYPE t] [PARAGRAPH a] [PRIORITY p] [LINES l]
/: TITLE title
/: NAME name1[,name2[,name3[,name4]]]
/: PERSON name of natural person [TITLE form of address]
/: DEPARTMENT department
/: STREET street name
/: LOCATION additional location information
/: POBOX po box [CODE post code / zip code] [CITY city]
/: POSTCODE post code / zip_code
/: CITY city1[,city2]
/: REGION county / state
/: COUNTRY recipient country [LANGUAGE language code]
/: FROMCOUNTRY sender country
/: ADDRESSNUMBER address number
/: ENDADDRESS


The parameter values contain both formatting and address information. The address data are formatted for output according to the data in the following parameters:


• TYPE
• FROMCOUNTRY
• COUNTRY
• LANGUAGE
• PRIORITY
• DELIVERY; and
• LINES


Parameters

• DELIVERY

Means that the address should be formatted as a complete delivery address, i.e. using the street name and number rather than the P. O. Box.

• TYPE

Specifies the type of address. The following types are possible:

- 1 normal address (ADRS1). This is the address of a company or organization. It corresponds to the address structure that is expected in most SAP applications.
- 2 private or personal address (ADRS2). This is the address of a natural person, a private or home address.


- 3 company address (ADRS3) with contact person. This is the address of a colleague or contact within a company or organization. The company name should be specified in the TITLE and NAME fields; the ATTN: contact person should be named in PERSON and TITLE.

Should you enter another address type or leave the field blank, then type 1 is used for formatting.



• PARAGRAPH

Specifies the paragraph format to be used for outputting the address. If this parameter is not given, the address will be output using the default paragraph format.

• PRIORITY

Specifies which of the address lines may be omitted should this be necessary. Any combination of the following codes may be specified. The order in which you list the codes determines the order in which address lines are left out.
The codes are as follows:

- A title
- P mandatory empty line
- 4 name4
- 3 name3
- R region
- T neighborhood, administrative section of a city (CITY2)
- D department
- L country name
- C post code or zip code
- 2 name2
- B P.O. Box (Japan only)
- S street name and number or P.O. Box, depending upon DELIVERY parameter
- N name and form of address of natural person (PERSON and TITLE)
- I Location information in LOCATION
- O city

• LINES

This specifies how many lines may be used for formatting the address. If there are too few lines available to allow all the address data to be formatted, then the data specified in the PRIORITY parameter are omitted. If there is no LINES parameter and if this command is in a layout set window of a type other than MAIN, then the number of lines available for formatting the address are automatically calculated based on the current output position and the size of the window.

• TITLE

Title or form of address. Used only with addresses of types 1 and 3.

• NAME

Up to four names may be given, separated by commas. Used only with addresses of types 1 and 3.

• PERSON

Name of the addressee. Used only for addresses of type 2 (private or personal address) or type 3 (company contact address). In type 3 addresses, use PERSON for the name of your contact person: 'Attn: Mr. Jeffries'. The name fields should be used for the company address.


Language code of the language of the recipient country, if different than that of the recipient COUNTRY. Example: addresses in Switzerland. Standard SAP language codes are used; you can display these in the initial SAPscript text processing screen or in table T002.

• FROMCOUNTRY

Specifies the language to be used for formatting the name of the recipient country. For most European countries, the recipient country is specified by placing the international car registration letters in front of the post code and separating them from the post code with a hyphen.

SAPscript makes an internal call to the ADDRESS_INTO_PRINTFORM function module for formatting the address. If the result is not as expected, you should check the settings for this function module (see the function module documentation (transaction SE37)).

Setting a Header Text in the Main Window: TOP

You can use the TOP .. ENDTOP control command to specify lines of text which are always to be output at the top of the main window. These text lines are also known as header texts. An example of the use of header texts in the case of a very long table covering several pages of output would be to ensure that the table heading information were repeated at the start of each new page of output.


Syntax:
/: TOP
:
:
/: ENDTOP
The lines of text enclosed between the two control commands will be output from now on at the start of the main window.
An existing header text can be disabled by using the TOP .. ENDTOP command pair without enclosing any text lines between the two command lines:
/: TOP
/: ENDTOP
Subsequent pages will contain no header text.


• If the main window already contains some output then a newly specified header text takes effect on the next page only.
• The same applies to the deletion of a header text. If a header text has already been output on the current page then it cannot be retracted.

• Header texts should not be employed in texts that are printed from applications programs, e.g. reminder texts, order texts, etc. These applications programs can also work with header texts via the layout set interface, which may lead to unexpected results.

Setting a Footer Text in the Main Window: BOTTOM

Footer texts may also be specified for the main window in a similar way to header texts. Footer texts are always output at the bottom of the window.


Syntax:
/: BOTTOM
:
:
/: ENDBOTTOM
The lines of text enclosed between the two control commands will be output from now on at the bottom of the main window.
An existing footer text can be disabled by using the BOTTOM .. ENDBOTTOM command pair without enclosing any text lines between the two command lines:
/: BOTTOM
/: ENDBOTTOM


This and subsequent pages will contain no footer text.


• Assuming there is still sufficient space in the main window, a newly specified footer text will also be output on the current page.
• Footer texts should not be employed in texts that are printed from applications programs, e.g. reminder texts, order texts, etc. These applications programs can also work with footer texts via the layout set interface, which may lead to unexpected results.

Conditional Text: IF

You can use the IF control command to specify that text lines should be output only when certain conditions are met. If the logical expression contained within the IF command evaluates to be true, then the text lines enclosed by the IF ... ENDIF command pair will be output. Otherwise they are ignored.


Syntax:
/: IF condition
:
:
/: ENDIF
The logical expression can use the following the comparison operators:

• = EQ equal to
• <> GT greater than
• <= LE less than or equal to • >= GE greater than or equal to
• <> NE not equal to

The following logical connective operators can be used to combine conditions:

• NOT
• AND
• OR

Evaluation of both the individual logical expressions and of the combinations of expressions is performed strictly from left to right. There are no precedence rules. Bracketed expressions are not supported.


The comparison is always performed on literal values, i.e. the symbols are formatted as character strings before being compared rather than using the internal form. This is particularly significant in the case of program symbols, because the formatting of these may depend on various parameters. For example, the formatted form of a currency field employs a variable number of decimal places and a variable 'decimal point' symbol (e.g. a period or a comma) depending on the applicable currency key.


The IF command may be extended with the ELSE command to allow text lines to be specified which are to be output in the case that the condition evaluates to be false. The text lines enclosed by the IF and ELSE commands are formatted if the condition is true; otherwise the text lines enclosed by the ELSE and ENDIF commands are formatted.


Syntax:
/: IF condition
:
/: ELSE
:
/: ENDIF
The ELSEIF command allows multiple cases to be specified.
Syntax:
/: IF condition
:
/: ELSEIF condition
:
/: ELSE
:
/: ENDIF


You can use arbitrarily many ELSEIF commands within one compound IF .. ENDIF control command. The use of an ELSE command is then optional.


• A condition may not occupy several lines. Both the IF or ELSEIF command and the attached condition must be completely contained within a single line.
• IF commands may be nested.
• An IF command must be terminated with an ENDIF command. If this is forgotten, then there will be no more output following the IF command if the condition evaluates to be false.
• If a syntax error occurs in the interpretation of this command, then the command will not be executed. This may have an unexpected effect on the subsequent text output. For example if the IF statement is incorrect, then all following ELSEIF and ELSE commands will be ignored, since the opening IF command is 'missing'. This will cause all the text lines attached to the ELSEIF and ELSE commands to be output.


The CASE command

The CASE command covers a special case of the multiple case IF command. Rather than allowing an arbitrary condition to be tested in each of the individual cases (as in the general multiple case IF command), the CASE command allows a given symbol to be tested against specific values until a matching value is found.


Syntax:
/: CASE symbol
/: WHEN value1
:
/: WHEN value2
:
/: WHEN valuen
:
/: WHEN OTHERS.
:
/: ENDCASE


The symbol in the CASE line is formatted. If its value is to be found in one of the WHEN lines, then the text lines following this WHEN line are output. If no matching value is found then the text lines enclosed by the WHEN OTHERS line and the ENDCASE command are output. The WHEN OTHERS section is optional.


As in the case of the IF command, the comparison is always performed on literal values.

• A CASE command must be terminated by an ENDCASE command.
• The WHEN OTHERS section is optional.


Calling ABAP/4 Subroutines: PERFORM

You can use the PERFORM command to call an ABAP/4 subroutine (form) from any program, subject to the normal ABAP/4 runtime authorization checking. You can use such calls to subroutines for such purposes as carrying out calculations, obtaining data from the database that is needed at display or print time, format data, and so on.


PERFORM commands, like all control commands, are executed when a document is formatted for display or printing. Communication between a subroutine that you call and the document is by way of symbols whose values are set in the subroutine.


Syntax:
/: PERFORM
IN PROGRAM
/: USING &INVAR1&
/: USING &INVAR2&
......
/: CHANGING &OUTVAR1&
/: CHANGING &OUTVAR2&
......
/: ENDPERFORM


INVAR1 and INVAR2 are variable symbols and may be of any of the four SAPscript symbol types.

OUTVAR1 and OUTVAR2 are local text symbols and must therefore be character strings.

The form routine that you call with PERFORM may not contain any calls to the function modules of the SAPscript composer API (OPEN_FORM, WRITE_FORM, and so on).

Inserting Print Controls: PRINT-CONTROL

You can use this command to call certain printer functions from a SAPscript text. Although you cannot enter control characters for the printer directly in your text, you can define a print control via the spooler maintenance transaction SPAD that contains the printer commands you want. You can now call a print control using the PRINT-CONTROL SAPscript command.

Syntax:
/: PRINT-CONTROL name
Specify the name of the print control either with or without inverted commas.

• The contents of the print control called are transparent to SAPscript. SAPscript cannot check whether the printer commands contained in the control are correct. Therefore, if you experience problems when printing a text containing these commands, you should proceed by first trying to print the text without the print controls. Then, reintroduce the PRINT-CONTROL commands one by one until the command causing the problem is identified.

• You should ensure that the printer control sequences you define leave the printer afterwards in a well-defined state. SAPscript assumes that after completing each text output certain settings (e.g. font, current page) are still valid for subsequent printing. If your printer commands change these settings without resetting them again afterwards, the results may be unpredictable.

After executing a PRINT-CONTROL command SAPscript inserts a space character at the start of the next text line. If you do not want this, then you should give this text line the '=' paragraph format.

Boxes, Lines, Shading: BOX, POSITION, SIZE

The BOX, POSITION and SIZE commands for drawing boxes, lines and shadowing can be used for specifying that within a layout set particular windows or passages of text within a window are to be output in a frame or with shadowing.

The SAP printer drivers that are based on page-oriented printers (the HP LaserJet driver HPL2, the Postscript driver POST, the Kyocera Prescribe driver PRES) employ these commands when outputting. Line printers and page-oriented printers not supported in the standard ignore these commands. The resulting printer output may be viewed in the SAPscript print previewer.

Syntax:

1. /: BOX [XPOS] [YPOS] [WIDTH] [HEIGHT] [FRAME] [INTENSITY]
2. /: POSITION [XORIGIN] [YORIGIN] [WINDOW] [PAGE]
3. /: SIZE [WIDTH] [HEIGHT] [WINDOW] [PAGE]

BOX Command


Syntax


/: BOX [XPOS] [YPOS] [WIDTH] [HEIGHT] [FRAME] [INTENSITY]
Effect: draws a box of the specified size at the specified position.
Parameters: For each of XPOS, YPOS, WIDTH, HEIGHT and FRAME both a measurement and a unit of measurement must be specified. The INTENSITY parameter should be specified as a percentage between 0 and 100.

1. XPOS, YPOS: Upper left corner of the box, relative to the values of the POSITION command.

Default: Values specified in the POSITION command.
The following calculation is performed internally to determine the absolute output position of a box on the page:
X(abs) = XORIGIN + XPOS
Y(abs) = YORIGIN + YPOS

2. WIDTH: Width of the box. Default: WIDTH value of the SIZE command.
3. HEIGHT: Height of the box. Default: HEIGHT value of the SIZE command.
4. FRAME: Thickness of frame.

Default: 0 (no frame).

5. INTENSITY: Grayscale of box contents as % .

Default: 100 (full black)

Measurements: Decimal numbers must be specified as literal values (like ABAP numeric constants) by being enclosed in inverted commas. The period should be used as the decimal point character. See also the examples listed below.

POSITION Command

Syntax
/: POSITION [XORIGIN] [YORIGIN] [WINDOW] [PAGE]
Effect: Sets the origin for the coordinate system used by the XPOS and YPOS parameters of the BOX command. When a window is first started the POSITION value is set to refer to the upper left corner of the window (default setting).

Parameters: If a parameter value does not have a leading sign, then its value is interpreted as an absolute value, in other words as a value which specifies an offset from the upper left corner of the output page. If a parameter value is specified with a leading sign, then the new value of the parameter is calculated relative to the old value. If one of the parameter specifications is missing, then no change is made to this parameter.

1. XORIGIN, YORIGIN: Origin of the coordinate system.
2. WINDOW: Sets the values for the left and upper edges to be the same of those of the current window (default setting).
3. PAGE: Sets the values for the left and upper edges to be the same of those of the current output page (XORIGIN = 0 cm, YORIGIN = 0 cm).

/: POSITION WINDOW
Sets the origin for the coordinate system to the upper left corner of the window.
/: POSITION XORIGIN 2 CM YORIGIN '2.5 CM'
Sets the origin for the coordinate system to a point 2 cm from the left edge and 2.5 cm from the upper edge of the output page.
/: POSITION XORIGIN '-1.5' CM YORIGIN -1 CM
Shifts the origin for the coordinates 1.5 cm to the left and 1 cm up.

SIZE Command

Syntax
/: SIZE [WIDTH] [HEIGHT] [WINDOW] [PAGE]
Effect: Sets the values of the WIDTH and HEIGHT parameters used in the BOX command. When a window is first started the SIZE value is set to the same values as the window itself (default setting).


Parameters: If one of the parameter specifications is missing, then no change is made to the current value of this parameter. If a parameter value does not have a leading sign, then its value is interpreted as an absolute value. If a parameter value is specified with a leading sign, then the new value of the parameter is calculated relative to the old value.

1. WIDTH, HEIGHT: Dimensions of the rectangle or line.
2. WINDOW: Sets the values for the width and height to the values of the current window (default setting).
3. PAGE: Sets the values for the width and height to the values of the current output page.


/: SIZE WINDOW
Sets WIDTH and HEIGHT to the current window dimensions.
/: SIZE WIDTH '3.5' CM HEIGHT '7.6' CM
Sets WIDTH to 3.5 cm and HEIGHT to 7.6 cm.
/: POSITION WINDOW
/: POSITION XORIGIN -20 TW YORIGIN -20 TW
/: SIZE WIDTH +40 TW HEIGHT +40 TW
/: BOX FRAME 10 TW


A frame is added to the current window. The edges of the frame extend beyond the edges of the window itself, so as to avoid obscuring the leading and trailing text characters.

Hexadecimal Data: HEX, ENDHEX

This command can be used to send printer commands in a printer language directly to a printer that supports that language. SAPscript does not interpret the data enclosed by the HEX and ENDHEX command pair, but inserts it unchanged into the output stream.

This technique allows objects with a pixel-oriented format (e.g. graphics) to be printed as part of a SAPscript text. The HEX and ENDHEX command pair enclose the printer commands and data as hexadecimal text, so that the printer formatting routines interpret each successive pair of characters as a single hexadecimal value in the range 0..255.

The characters 0..9 and A..F for representing the values 10..15 are valid hexadecimal characters. The text may also include comment lines (these begin with /* in the format column), which will not be interpreted as hexadecimal data but are simply passed over by the formatting routines.

Syntax:
/: HEX [TYPE printer_language]

The HEX command denotes the start of the hexadecimal data. Subsequent text lines are interpreted as described above. If the TYPE parameter is present, the data will be sent to the printer only if the printer understands the specified printer language. The following printer languages are currently supported: POST (Postscript), PRES (Kyocera Prescribe) and PCL (HP Printer Control Language).

/: HEX [TYPE printer_language] [XPOS x_position] [YPOS y_position]
The output cursor is set to the absolute position indicated by the specified X and Y position parameters before the hexadecimal data is output. If either the X or the Y position is not specified, then 0 will be assumed for this parameter.

/: HEX [TYPE printer_language] [HEIGHT height] [LEFT left_indentation]
The HEIGHT parameter determines the amount of space to be reserved on the page for the output of the hexadecimal data.

Any text following the ENDHEX command will be output below this point. If the LEFT parameter is also specified, then the output of the hexadecimal data will be indented from the left margin by the specified amount.

/: HEX TYPE PCL HEIGHT '7.5' CM LEFT '2.25' CM
/* Creator: report ZQVNTE30 date 19940705 time 125129 user SAPSCRIPT

/= 1B2A7230461B2A743735521B2A7231411B2A62304D1B2A62343057FFFFFFFFFFFF
/= FF1B2A62343057FFFFFFFFFFFFC0007D00DFC0F7D0000000000000000000000017
/: ENDHEX

This data will be printed only by an HP PCL printer (e.g. HP LaserJet). 7.5 cm of space will allocated on the page for the output of the data and the output cursor will be indented 2.25 cm to the right of the layout set window edge.

The RSTXLDMC program may be used to upload correctly formatted pixel data to the R/3 system and to prepare it as a HEX-ENDHEX control command. This can then be saved as normal SAPscript text.

Summing a Program Symbol: SUMMING

The SUMMING command is used for accumulating a total value for a program symbol. The command should be specified just once. Then, each time that the specified program symbol is formatted, its current value is added into the total symbol. Several program symbols may all be added into a single total symbol.

Syntax:


/: SUMMING program_symbol INTO total_symbol
SAPscript cannot create the field for the total dynamically. The symbol used must be defined in a TABLES structure in the calling program.
RELATED POSTS

SAP NAVIGATIONS
SAP SCRIPT CONTROLS 1
SAP SCRIPTS PART 1
Organizational Challenges with crm and mysap crm solutions
My sap crm and marketing planning

Work Flow Scenarios in SAP ABAP


SAP Business Workflow is a solution which has been integrated fully in the R/3 System and which enables customer-specific business process flows to be coordinated and controlled on a cross-application and cross-workplace basis. SAP Business Workflow therefore enhances "ready-made" application software.

The SAP Business Workflow definition environment is available in order to represent business processes in a simple manner and to be able to respond to changing external conditions quickly during ongoing operation by flexibly adapting the business processes which have already been implemented.

A number of SAP applications support Workflow Management by SAP Business Workflow. In many situations you can therefore use workflow scenarios which have already been configured. These can either be implemented without any changes or they can be used for your business processes with minimal adjustments. These workflow scenarios reduce implementation time significantly and are optimally adjusted to the respective application functions.

The workflow scenarios are integrated in IDES (International Demonstration and Education System). It is possible to run the business processes of a model company in this fully configured system.

What is a workflow scenario?

The term "workflow scenario" describes the whole range of options which are available for supporting workflow functionality in an application. The workflow scenarios can be divided into three categories:

• Creation of events

Events are created to report status changes undergone by an application object and to allow a reaction to be made to these. You can respond to these events in a flexible and customer-specific way without the standard part of the application needing to be modified. You will generally use such events as triggering events for customer-specific customer tasks or workflow tasks.

The triggering of these events is often not activated in the standard version, but depends on the customizing settings.
You can find further information in the application scenario documentation.

• Provision of standard tasks

Standard tasks contain a task description and a connection to the application logic via business object methods. Before a standard task can be used productively, you must assign it to its possible agents.

The standard tasks provided by SAP are generally used as steps in a workflow template. They are available as "modules" which you can use for your own developments.

If a workflow scenario only involves one standard task, it can usually be regarded as a minimal solution for showing the connection between application functionality and SAP Business Workflow. For differentiated workflow management, this standard task should be replaced by a customer-specific workflow task.


• Preparation of workflow templates

Workflow templates contain complete process descriptions comprising several steps.In the cases where workflow templates describe business processes which occur in exactly the same way in your company, or in the cases where changes to the workflow template are not advisable for technical reasons, the workflow templates supplied by SAP can be used productively without any changes needing to be made. It may however be necessary to make some customizing settings.

In any other case, you can use the workflow templates as the basis for your own developments. The existing process structures of the business application components, which are often represented in a transaction, are generally not replaced. SAP Business Workflow is located as an integration level "above" the standard business functions and uses the existing transactions, function modules, and reports.


• In the business background you find out which business processes are supported by workflow scenarios, which employees are involved, and what advantages and benefits can be derived from using the workflow system.


• A more detailed presentation of the processes is provided in the description of the technical background of the respective scenarios. Here you learn in detail what steps were carried out by SAP in order to represent the business process in the system.

You are familiarized with the object types which form the basis of the scenario and you find out which standard tasks are defined to describe the activities which need to be performed, which roles are resolved, and which events are used.

This information is particularly useful if you are planning to enhance and modify the scenario.This section is not available or is very brief if no enhancements are planned or appropriate.

• To adapt the scenario to the specific features of your company, settings need to be made which are described in the section Preparation and Customizing.

The settings described need to be made specifically for the scenario and are generally additional to SAP Business Workflow customizing.

• The use of the scenario and the connection to application functionality are described in the last section of the respective chapter.

This documentation is not meant to replace the SAP Business Workflow manual.For information on using and calling the individual components of SAP Business Workflow and to take advantage of the full functionality in your enhancements and own developments, refer to the SAP Business Workflow manual

Basic Concepts

Area Menu SAP Business Workflow (Development)

All definition tools can be accessed from the area menu SAP Business Workflow (Development). You can reach this area menu from the R/3 initial screen via Tools ® Business Engineering ® Business Workflow ® Development.

Object Orientation in SAP Business Workflow

A workflow is generally used when business objects (business application objects), such as an invoice, material, or customer, are to be processed in the system over several steps and when this processing is to be followed actively until it has been completed. Options must therefore be available in the workflow system for

• naming objects,
• creating and processing objects (executing methods),
• evaluating attributes of objects (reading attributes) and
• responding to events (status changes of objects).


It is therefore appropriate that the interface between the workflow management system and the applications is based on object-oriented principles. Besides the business logic of the R/3 System, other applications on desktops or in other application systems (appropriately encapsulated) are therefore accessible to SAP Business Workflow.


Object Types and Objects

An object type refers to a generic object description which is created at definition time. This description includes the definition of the key fields required to uniquely identify an object of this type and the specification of the methods, attributes, and events of this object type..


An object is the specific instance of an object type which has been assigned values.

Modifying Object Types - Inheritance and Delegation

It is necessary to extend an object type rather than creating a new object type whenever you want to create additional components for an object type which are not provided in the standard version and at the same time need to ensure that productive scenarios with the original SAP object type remain operational.


Since you may not change the object types provided by SAP, create a new object type as the sub-type of the original object type which will then inherit its components and their implementation. Then modify this object type and make it the delegation type of the super type. All calls to the "old" delegating object type (super type) are redirected to the delegation type (sub-type) so that its definition is read and executed (delegation).


Business Object Repository

A directory of all object types defined in the SAP System is managed in the business object repository. These object types are each assigned to a business application component.In addition to the business object types, the business object repository also contains structural object types, such as company code, plant, or sales organization, and technical object types, such as text, note, work item, or archived document. Customers can define their own object types.

Object types and their elements can be found quickly by accessing this business object repository with the appropriate search functions (either via the component hierarchy or with a generic search using parts of a name).

Methods

A method refers to an operation which can be performed on an object.A method generally refers to ABAP/4 functionality which is already available (function module, transaction, dialog module, ...) and is called via an interface determined mainly by the method name and method parameters. The actual implementation of the method therefore remains abstract. It is not visible externally and does not need to be known to the calling program of the method.

Synchronous and Asynchronous Methods

Methods can be subdivided as follows depending on their response characteristics:

• synchronous methods

Synchronous object methods assume process control for the duration of their execution and report back to the calling program once they have been executed.

• asynchronous methods

Asynchronous methods do not report back to the calling program directly after their execution. The response is made via events which are used to report the processing results of the methods.

Synchronous and asynchronous methods can be distinguished according to the way in which they are used in single-step tasks: A single-step task which refers to an asynchronous method must be completed by an event.

Method Parameters

Parameters are used to exchange information between the calling program of a method and the method.Parameters of a method are values which are either passed to the method at runtime (import parameters) or are returned from the method (export parameters). When the parameters are defined, the interface of the method call is also defined. A method need not necessarily have parameters; many methods can be used without parameters.

Method Result

The result of a method is different to the export parameters. Possible values for the result can be fixed or contained in a check table. They are therefore known in a workflow definition and can be taken into account during process modeling.The various follow-up steps can be modeled in a workflow definition according to the results. A method can only ever have one result, although there is no limit to the number of export parameters.A method need not necessarily have a result.

Method Exceptions

In the same way, exceptions (cancellation by user, object to be processed does not exist, etc.) of a method can also be defined and taken into account in a workflow definition.

Attributes

An attribute describes a property or characteristic of an object.Attributes can be used to formulate conditions in the workflow definition. The object attributes are read or determined from the database at runtime and are used to control the workflow.

An object attribute can return

• the value of a field in the ABAP/4 Dictionary (database field attribute)
• an object reference to an object which is defined in the business object repository. Object attributes which return an object reference therefore allow the attributes of this referenced object to be accessed.
• a value which is not determined until database contents are calculated and/or evaluated at runtime (virtual attribute).

Events

An event publishes the occurrence of a status change of an object ("text deleted", "invoice posted", "material created", ...) system-wide.Events should always be seen in connection with the object they are "reporting" on. The events belonging to an object are therefore specified in the object type definition.


Events are published without the application, the event creator, knowing whether a receiver is interested in this event and whether it will respond. Potential receivers of an event are listed in the event receiver linkage table, where receivers can make and remove their entries as required. This allows the events created to be responded to flexibly.

Events and SAP Business Workflow

Events are used in the SAP Business Workflow environment,

• to start tasks (multistep tasks and single-step tasks). The events are therefore defined as the triggering events of the respective tasks.
• to complete single-step tasks which refer to an asynchronous object method. The events are therefore defined as the terminating events of the respective single-step tasks.

Event Parameters

Events are linked to runtime-dependent data (event parameters) which is available to the event receiver and can be used for event-driven control and communication mechanisms.

Event Generation

Event generation is not part of the object type definition in the narrow sense. However, for customer-specific event generation to occur, the relevant events must be added to the object type definition.If the events which are created in the standard version when particular conditions are met are not sufficient, you have the option of ensuring that additional events are generated without carrying out programming work. It is therefore possible to generate events where this is not supported by SAP in the standard version. There are basically four ways in which events can be generated:

• Generate events by calling a function module• Generate events for status changes
• Generate events when change documents are written
• Generate events via Message Control

While event generation as the result of calling the provided function module requires programming knowledge and experience, the last three options can be used without changing the program code of an application. These procedures take advantage of the fact that data consistency and security is ensured by the application when a change document is written, status management activated, or a message sent.The generation of events entered for the individual object types in the business object repository is ensured by SAP.

Integration of Organizational Management

The company-specific organizational plan describes the organizational assignment of an employee. This allows the responsibility of employees for performing individual business activities to be defined in the form of activity profiles.


The organizational plan is part of the PD component "Organization and Planning". It is client-dependent. An organizational plan which was created for personnel management purposes (or is still to be created) can be used in SAP Business Workflow without any changes provided the workflow functionality and the personnel management application use the same client.


In each client you will however generally (only) represent the sub-areas and organizational structures of your company in which you also coordinate business processes using SAP Business Workflow.This assignment is used to find the "correct" agents and allows tasks to be assigned actively by the workflow management system. Transparency of the business processes and responsibilities is achieved. Changes can be made to the organizational structure of the company without changes needing to be made directly to the SAP Business Workflow definitions or programming performed in an application.

To create an individual activity profile for a user in a modular way and without redundancy, it is necessary to describe the organizational assignment of this user in the company-specific organizational plan.


Organizational Structure and Organizational Units

An organizational plan is described by the organizational units available in the company. These organizational units are generally linked together in a hierarchical reporting structure, but can also be created in isolation.Organizational units are organizational sub-areas in a company (departments, project teams, groups) which have been created for business purposes.

Staff Assignments

Staff assignments are maintained for each organizational unit. The appropriate positions are assigned to the organizational unit. A position is derived from a describing job and is generally occupied by a user.

Jobs

Jobs are areas of activity within a company which are described by tasks or business application components and are often created across organizational units.

Positions

Positions can be regarded as the individual employee assignments within a company. A position is described by a job and always belongs to exactly one organizational unit.

Chief Position

One position can also be designated as the chief position of the organizational unit. This allows you to structure the positions within an organizational unit. This information is sufficient to address a work item to an employee's superior.

User/Person (Employee)

A position is held by an employee (person from HR master data management) or by a system user (user master), a position can also remain vacant.


For an agent to be determined by the workflow system, it must be possible to make an assignment between positions and system users. If a position is assigned to an employee, this employee must also be linked to his system user in the HR master data (infotype 105 Communication). Do not assign an employee and a person to a position.


RELATED POSTS

SAP SCRIPT CONTROLS
WORK FLOW PART 1
MySAP CRM and customer relationship management

Modifications of SAP StandardObjects

An object is original in only one system. In the case of objects delivered by SAP, the original system is at SAP itself. These objects are only copies in customer systems. This applies to your development system and all other systems that come after it.If you write your own applications, the objects that you create are original in your development system. You assign your developments to a change request, which has the type Development/Correction.This request ensures that the objects are transported from the development system into the subsequent systems.Changes to an original are called corrections. They are recorded in a change request whose tasks have the type "Development/correction".

If, on the other hand, you change a copy (an object outside its own original system), the change is recorded in a task with the type "Repair". Repairs to SAP objects are called modifications.When you repair your own objects (for example, if something goes wrong in your production system), you can correct the original in your development system straight away. When you change copies, you must correct the original immediately.However, you cannot do this with SAP objects, because they are not original in any of your systems.

You should only modify the SAP standard if the modifications you want to make are absolutely necessary for optimizing workflow in your company. Be aware that good background knowledge of application structure and flow are important prerequisites for deciding what kind of modifications to make and how these modifications should be designed.Whenever you upgrade your system, apply a support package, or import a transport request, conflicts can occur with modified objects.Conflicts occur when you have changed an SAP object and SAP has also delivered a new version of it. The new object delivered by SAP becomes an active object in the Repository of your system.

If you want to save your changes, you must perform a modification adjustment for the objects. If you have a lot of modified SAP objects, your upgrade can be slowed down considerably.To ensure consistency between your development system and subsequent systems, you should only perform modification adjustments in your development system. The objects from the adjustment can then be transported into other systems.A registered developer must register registers changes to SAP objects. Exceptions to this registration are match codes, database indexes, buffer settings, customer objects, patches, and objects whose changes are based on automatic generation (for example , in Customizing). If the object is changed again at a later time, no new query is made for the registration key. Once an object is registered, the related key is stored locally and automatically copied for later changes, regardless of which registered developer is making the change. For the time being, these keys remain valid even after a release upgrade.

How do you benefit from SSCR (SAP Software Change Registration)?

Quick error resolution and high availability of modified systems .All objects that have been changed are logged by SAP. Based on this information, SAP's First Level Customer Service can quickly locate and fix problems. This increases the availability of your R/3 system.Dependable operation Having to register your modifications helps prevent unintended modification. This in turn ensures that your R/3 software runs more reliably.

Simplification of upgrades Upgrades and release upgrades become considerably easier due to the smaller number of modifications.If you want to change an SAP Repository object, you must provide the Workbench Organizer with the following information:

SSCR key
Change Request
We saw above how you get an SSCR key. If you now continue to change the object, you must confirm the following warning dialogs: At this point, you can still cancel the action without repairing the object.

The Workbench Organizer asks you to enter a change request, as it would for your own objects. The object is automatically added to a repair task. The change request has the following functions:

Change lock After the task has been assigned, only its owner can change the object.

Import lock :The object cannot be overwritten by an import (upgrade or support package).

Versions :The system generates a new version of the object .

After development is finished, the programmer releases the task. At this point, the programmer must document the changes made. The objects and object locks valid in the task are transferred to the change request. If the developer confirms the repair, the import lock passes to the change request. If the developer does not confirm the repair when releasing the task, the import lock remains in place.Only the developer can release this lock.

Once the project is completed, you release the change request. This removes all of the change request's object locks. This applies both to the change locks and the import locks.When the change request is released, the objects are copied from the R/3 database and stored in a directory at operating system level. They can then be imported into subsequent systems by the system administrator.

After the modifications have been imported into the quality system, the developer must test them and check the import log of the request.When you release a change request, a complete version of all objects contained in the change request is written to the versions database.If you transport the Repository object again later, the current object becomes a complete copy and the differences between the old and the new object are stored in the versions database as a backwards delta.

Whenever you assign a Repository object to a task, the system checks whether the current version agrees with the complete copy in the versions database. If not, a complete copy is created. This process is also initiated the first time you change an object, since SAP does not deliver versions of Repository objects.

The versions of a Repository object provide the basis for modification adjustment. To support adjustment, information on whether the version was created by SAP or by the customer is also stored.Encapsulate customer source code in modularization units instead of inserting it directly into SAP source code (with, for example, customer function module calls in program source code, or customer sunscreen calls for additional screen fields).

When encapsulating the customer portions of a program, be sure to use narrow interfaces. You should define a standard for all of your company's modification documentation .You should also maintain a list of all modifications to your system .

All requests that contain repairs must be released before an upgrade so that all relevant customer versions can be written to the versions database (the system compares versions during adjustment).Repairs must also be confirmed prior to upgrade, otherwise the object being repaired is locked and cannot be imported.

Any modifications that you make to ABAP Dictionary objects that belong to Basis components are lost at upgrade--- these objects revert to their earlier form and no adjustment help is offered. This can lead to the contents of certain tables being lost.The aim of the Modification Assistant is to make modification adjustments easier. In the past, the granularity of modifications was only at including program level. Today, a finer granularity is available. Now, modifications can be recorded at subroutine or module level.This is because (among other reasons) the modifications are registered in a different layer. As well as providing finer granularity, this means that you can reset modifications, since the original version is not changed.

If, in the past, you modified an include for which SAP provided a new version in an upgrade, a modification adjustment was necessary. The modification adjustment had to be performed line by line. The system provided little support.The Modification Assistant has changed this situation considerably. Modifications are now recorded with finer granularity. For example, if you modify a subroutine, the rest of the include remains unchanged. If SAP delivers a new version of the include, the system looks to see if there is also a new version of that subroutine. If this is not the case, your changes can be incorporated into the new version automatically.

The original version of each software layer comprises the originals from the previous layer plus current modifications.In the ABAP Editor, you can use modification mode to change source code. Only a restricted range of functions is available in this mode. You can add, replace, or comment out source code, all under the control of the Modification Assistant.

Changes to layout and flow logic in the Screen Painter are also recorded.The Modification Assistant also records changes in the Menu Painter and to text elements, as well as the addition of new function modules to an existing function group.To avoid conflicts in the upgrade, table appends are also logged by the Modification Assistant.If you want to change an SAP object, you must provide the following information:

SSCR key
Change request

The system informs you that the object is under the control of the Modification Assistant. Only restricted functions are available in the editor.You can switch the Modification Assistant on or off for the entire system changing the R/3 profile parameter eu/controlled_modification. SAP recommends that you always work with the Modification Assistant.

You can switch off the Modification Assistant for single Repository Objects. Once you have done so, the system no longer uses the fine granularity of the Modification Assistant.In modification mode, you have access to a subset of the normal editor tools. You can access these using the appropriate pushbuttons. For example, in the ABAP Editor, you can:

Insert :The system generates a framework of comment lines between which you can enter your source code.

Replace:Position the cursor on a line and choose Replace. The corresponding line is commented out, and another line appears in which you can enter coding. If you want to replace several lines, mark them as a block first.

Delete:Select a line or a block and choose Delete . The lines are commented out.

Undo modifications:This undoes all of the modifications you have made to this object.

Display modification overview:Choose this function to display an overview of all modifications belonging to this object.

The Modification Assistant automatically generates a framework of comment lines describing the action. The comment also contains the number of the change request to which the change is assigned, and a number used for internal administration.The "modification overview" icon provides you with an overview of the modifications you have made in the current program.

The display is divided up according to the various modularization units. This corresponds to the structure used by the Modification Assistant to record the modifications.You can reset all of the modifications that you have made to the current object using the Modification Assistant by choosing this function. The record of the modifications is also deleted.

Remember that you cannot selectively undo modifications to an object. You can only undo modifications based on the "all or nothing" principle.The Modification Browser provides an overview of all of the modified objects in the system. The Modification Browser differentiates between modifications made with the Modification Browser and those made without.

On the initial screen of the Modification Browser, you can restrict the selection according to various criteria. This allows you to find modifications in a particular area.The Modification Assistant displays the hit list in tree form. Objects are arranged by:

Modification type (with/without the Assistant)
Object type (PROG, DOMA, DTEL, TABL,)

SAP recommends that you use Modification Assistant to make changes to R/3 objects. Changes without the use of the Modification Assistant should be avoided. However, should this be necessary, you should document your modifications in the source code as follows?

Preliminary corrections SAP note, repair number, changed by, changed on, valid until

Customer functions that have been inserted subject area, repair number, changed by, changed on, INSERTION

Customer functions that have replaced SAP functions subject area, repair number, changed by, changed on, REPLACEMENT The SAP functions that you do not need should not be deleted, but commented out instead

Subject areas are specified in the relevant process design blueprint (for example, subject area SD_001 = pricing).

SAP recommends that you keep a record of all modifications that have been made to your system (that is, of any changes you have made to Repository objects in the SAP namespace).

The following information should be logged for each modification:

  1. Object type (program, screen, GUI status,)
  2. Object name
  3. Routine (if applicable)
  4. Subject area (according to process design blueprint or technical design)
  5. Repair number
  6. Changed on
  7. Changed by
  8. Preliminary correction? (Yes/no)
  9. OSS note number, valid until Release x.y

Amount of time necessary to recreate modification during adjustment (measured in hours).A module pool is organized as a collection of include programs. This is particularly useful for making the program easier to understand. The organization is similar to that of function groups. In particular, the naming convention, by which the last three letters of the name of the include program identify its contents, is identical.

The main program, as a rule, contains the include statements for all of the include programs that belong to the module pool.The includes described as "special" includes in the program are themselves only include programs - technically, they are not different. These programs are only delivered once.User exits are a type of system enhancement that were originally developed for the R/3 Sales and Distribution Module (SD). The original purpose of user exits was to allow the user to avoid modification adjustment.

A user exit is considered a modification, since technically objects in the SAP namespace are being modified.The SAP developer creates a special include in a module pool. These includes contain one or more subroutines routines that satisfy the naming convention userexit_. The calls for these subroutines have already been implemented in the R/3 program. Usually global variables are used.

After delivering them, SAP never alters includes created in this manner; if new user exits must be delivered in a new release, they are placed in a new include program.User exits are actually empty subroutines that SAP developers provide for you. You can fill them with your own source code.

The purpose behind this type of system is to keep all changes well away from program source code and store them in include programs instead. To this end, SAP developers create various includes that fulfill the naming conventions for programs and function groups. The last two letters in the name of the include refer to the include that the customer should use: "Z" is usually found here.

This naming convention guarantees that SAP developers will not touch this include in the future. For this reason, includes of this nature are not adjusted during modification upgrade.The subroutine call is already implemented in the programt. The interface is already defined. Normally, subroutines of this type only work with global data.

If any new user exits are delivered by SAP with a new release, then they are bundled into new includes that adhere to the same naming convention.You can find a list of all user exits in the SAP Reference Implementation Guide.There, you will also find documentation explaining why SAP developers have created a particular user exit.

The set of objects for adjustment is derived from the set of new objects delivered by SAP in a new release. This is compared with the set of objects you have modified on your R/3 system.The intersection of these two sets is the set of objects that must be adjusted when you import an upgrade or support package.During modification adjustment, old and new versions of ABAP Repository objects are compared using transactions SPDD and SPAU.

You do not have to call transaction SPDD to adjust Dictionary objects if:No changes have been made to SAP standard objects in the Dictionary You have only added customer objects to your system. Only SAP objects that have been Changed must be adjusted using this transaction.

All other ABAP Repository objects are adjusted using transaction SPAU. Upgrade program R3up tells you to start the transaction after upgrade has finished. You have 30 days to use transaction SPAU after an upgrade. After 30 days, you must apply for a SSCR key for each object that you want to adjust.

Transaction SPAU first determines which objects have been modified. Then it determines which of these objects have a new version in the current upgrade. Modification adjustment allows you to transfer the modifications you have made in your system to your new R/3 Release.Use transaction SPDD to adjust the following ABAP Dictionary objects during the modification adjustment process:

Domains
Data elements
Tables (structures, transparent tables, pool, and cluster table, together with their technical settings)
These three object types are adjusted directly after the Dictionary object import (before the main import). At this point in time, no ABAP Dictionary objects have yet been generated. To ensure that no data is lost, it is important that any customer modifications to domains, data elements, or tables are undertaken prior their generation.

Changes to other ABAP Dictionary objects, such as lock objects, match codes, or views, cannot result in loss of data. Therefore, these ABAP Dictionary objects are adjusted using transaction SPAU after both main import and object generation have been completed. You can use transaction SPAU to adjust the following object types:

ABAP programs, interfaces (menus), screens, match code objects, views, and lock objects.During modification adjustment, you should use two different change requests to implement the changes you have made: one for SPDD adjustments and another for SPAU adjustments. These change requests are then transported into other R/3 systems you want to adjust. This guarantees that all actual adjustment work takes place solely in your development system.

When upgrading additional R/3 systems, all adjustments exported from the first system upgrade are displayed during the ADJUSTCHK phase. You decide which adjustments you want to accept into your additional systems and these are then integrated into the current upgrade. Afterwards, the system checks to see if all modifications in the current R/3 system are covered by the change requests created during the first system upgrade. If this is the case, no adjustments are made during the current upgrade.

For this process to be effective, it is important that all systems involved have identical system landscapes. This can be guaranteed by first making modifications in your development system and then transporting them to later systems before you upgrade the development system. You can also guarantee that all of your systems have an identical system landscape by creating your development system before upgrade as a copy of your production system and then refraining from modifying the production system again until after upgrade.

Version compare is also used during or after an upgrade for modification adjustment.During modification adjustment, version compare determines the number of SAP objects that you a) changed in the system and that b) were then overwritten by SAP at upgrade.Version compare allows you to find where changes were made and transfer them to your new SAP version if you want.

The icons in front of the individual objects that need adjustment show how they can be adjusted.
The possible methods are:

Automatically The system could not find any conflicts. The changes can be adopted automatically

Semi-automatically The individual tools support you in adjusting the objects.

Manually You must process your modifications with no special support from the system. In this case, the modification adjustment does allow you to jump directly into the relevant tool.

Adjusted objects are identified by a green tick.If you want to use the new SAP standard version, use Restore original. If you do this, you will have no further adjustment work in future.EPILOG:

Modifications can be categorized as 'critical' if:

They affect numerous other Repository objects (such as Dictionary objects or function modules) Modification adjustment is either difficult
Without the Modification Assistant (prior to Release 4.5A), both modifying GUI statuses and GUI titles, as well as assigning customer function modules to SAP function groups, should be considered 'critical' activities.

SAP only changes the following Repository objects in an upwardly compatible manner. They should therefore be considered 'uncritical' by customers who want to call them:

Function modules that have been released

BAPIs

Includes for user exits
Screen, program, menu, and field exits
After an upgrade, you must test customer reports that call SAP objects, as well as all objects displayed in the upgrade utility SPAU. This is also true for Repository objects that have been automatically adjusted using the Modifications Assistant (from Release 4.5A).

You must be familiar with the processing logic of your application in order to be able to adjust programs properly.Modification adjustment is not necessary if you avoid making changes to SAP objects.Use program enhancements and appends with SAP tables to enhance SAP objects in such a way that your changes cannot be overwritten by SAP at upgrade.

From Release 3.0, you can use Online Correction Services to import and cancel support packages and patches automatically (instead of having to insert preliminary corrections manually).Modification has the advantage that your live Repository objects do not lose their connection to the SAP standard. Copying, on the other hand, has the advantage that no modification adjustment will be necessary for your live Repository objects during subsequent upgrades.

Choose copying instead of modifying if:

You have to make numerous changes to an SAP program
Your requirements will not be met by the standard in future R/3 releases
During copying, pay attention to a Repository object's environment as well. You should only decide whether to modify or copy after having informed yourself of the consequences for the main program, as well as for all of the includes attached to the main program. The same holds true for function groups and function modules.

ABAP development projects can be evaluated according to the following criteria:

What will implementation cost, measured in manpower (creating the concept, implementation, testing)?

How will the ABAP development project influence:
Production operation performance?
The amount of adjustment at upgrade?

By calling SAP objects in your own Repository object, you can drastically reduce the amount of effort needed to implement your object. However, any changes that SAP makes to the Repository object you choose to call may make extra adjustment necessary after an upgrade. For example, SAP could conceivably change the user interface of a screen for which you have written a batch input program.

Naming conventions allow you to avoid naming conflicts and give your Repository objects meaningful names (that can be understood by others). The following naming conflicts can occur:

An SAP Repository object and a customer Repository object conflict SAP Repository objects and customer Repository objects should be separated from each other by strict adherence to SAP naming conventions. OSS note 16466 gives you an overview of the current naming conventions for customer Repository objects (usually names that begin with either Y or Z).

Two customer Repository objects conflict Naming conflicts can also occur between customers Repository objects in decentralized Development scenarios where more than one development system is being used. You can avoid naming conflicts in this area by reserving a special namespace for development areas within the customer namespace. The Workbench Organizer checks to make sure that you adhere to these conventions by making entries in view V_TRESN.

RELATED POSTS

SAP WORK FLOW SCENARIOS
CHANGING THE SAP STANDARD
CHANGES TO DATA BASE TABLES
SAP ENHANCEMENTS
What is SAP and Why do we are in need of It

Business Transaction Events in ABAP

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 run time. 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 run time 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.

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 enhancement 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 POSTS

MODIFICATIONS TO SAP STANDARD
sap internet transaction architecture
SAP internet transaction application components
SAP Authorization and ALE
Authorization and implementation of SAP
Mysap market place introduction