ALE 6

Filtering BAPI Parameters

The BAPI parameter filtering can also take into account a hierarchical dependency between BAPI table parameters.You must specify any hierarchical dependencies before you generate the BAPI-ALE interface of the BAPI.The specified hierarchy is evaluated when the interface is generated and incorporated in the interface coding.The BAPI-ALE interface must be regenerated following all subsequent changes made to the hierarchy.Once the generated IDoc type has been released, the specified hierarchy of the asynchronous BAPI cannot subsequently be changed because of compatibility problems.

Defining Hierarchies Between BAPI Parameters

If you are developing your own ALE business processes, you may have to define dependencies between BAPI table parameters with regard to filtering parameters for data selection.These dependencies are defined by the field references between the table parameters of BAPIs.You can filter parameters to determine the dataset and to define dependencies only for the distribution of master data via BAPIs that are called synchronously.

A BAPI for material master data contains the tables for plant data and associated storage data.The table containing plant data has a reference to the table containing storage data via the key field PLANTS.There is a hierarchical dependency between the plant and storage data.If plant 001 of a material is not to be replicated due to parameter filtering, then none of the storage data for plant 001 will be replicated.

You use BAPI parameter filtering to manage the size of the dataset in the BAPI interface.

Procedure

You can define these hierarchical dependencies in ALE Development under BAPI → Maintain hierarchy of table parameters.Enter the object type and the method of the BAPI. You can display existing BOR object types and their associated methods using the input help (F4).The following processing options are available under the menu Hierarchy :

• Create

• Change

• Display

• Delete

Create Hierarchy

This checks whether a hierarchy for the BAPI already exists. Then it checks whether an ALE IDoc interface has already been generated and whether the associated IDoc has been released.If the IDoc has already been released, then the generated interface has already been delivered to customers and no hierarchy can be created or changed for an existing BAPI because of compatibility problems.In this case you have to create a new BAPI. A corresponding error message is displayed. If the ALE interface already exists, but the IDoc has not yet been released, then the system will inform you that it needs to be regenerated.A hierarchy tree is displayed on the next screen. For details see Editing the Hierarchy Display further below.

Change Hierarchy

The same checks are made as when you create a hierarchy. On the next screen the same processing options are provided as when you create a hierarchy.

Display Hierarchy

The same checks are made as when you create a hierarchy. On the next screen you cannot make any changes to the hierarchy.

To display the field references between the tables, double-click on the parent table. The parent table is automatically copied to the next dialog box.Select one of the child tables from the input help. Select Field references to display the field references.

Delete Hierarchy

The same checks are made as when you create a hierarchy. Once you have confirmed you want to delete the BAPI hierarchy, it is deleted.

Editing the Hierarchy Display

The root node in the hierarchy display corresponds to the function module of the BAPI. The root node is used only for display and is not saved. Also, it cannot be changed. You can edit the hierarchy display as follows:

• Insert table parameters

• Delete table parameters

• Define field references between parent and child tables

• Save hierarchy Parent tables inserted directly under the root node that do not have child tables are not saved.

If only this type of table is created, there is no hierarchy and therefore a hierarchy cannot be saved.

Insert table parameters

Place the cursor on a hierarchy node and choose Edit → Insert table parameters. If you place the cursor on a root node, you can select a parent table of the highest level via the input help. If a table exists above the marked node, this is copied to the next dialog box and you can add a child table to this table.In principle a table can only exist once in the hierarchy. You can display the available tables via the input help.In the dialog box you can display the common fields of the parent and child of the table in which the field references can be defined by selecting Field references. You can mark the fields for which a field reference is to be defined.

If no field references between the two tables exist, an error message is displayed. Delete table parameters To delete a table, place the cursor on the relevant node of the hierarchy with the table names of the child table.

Confirm the deletion. All other child tables of the deleted table will also be deleted.

Define field references between parent and child tables

Place the cursor on the node of a child table and choose Edit → Table parameters → Change field references or select the pushbutton Field reference with the change icon. The next dialog box contains the parent parameters and provided that a reference exists, the child parameters too.

When you create table parameter, you can select the associated child table via the input help. You can display common fields by selecting Field references.Only field references are displayed that have the same names in the parent and child tables. You can define the references between the fields by marking the appropriate references. Field references already defined are marked already.

Save hierarchy

To save a hierarchy, choose Hierarchy → Save.

A transport request is generated to send the associated Customizing table to the correction and transport system.

The hierarchy is not saved if an error occurs when accessing the database. A corresponding error message is displayed.

Maintaining BAPI-ALE Interfaces

The standard R/3 System contains a large quantity of business objects and BAPIs. These include BAPI-ALE interfaces that are generated from BAPIs and enable asynchronous BAPI calls in ALE business processes.

You can develop your own BAPIs in the customer namespace and generate the associated BAPI-ALE interface. The following objects are generated for a BAPI: • Message type • IDoc type including segments

• Function module called in the outbound processing side. (It creates and sends the IDoc from the BAPI data).

• Function module that calls the BAPI with the IDoc data on the inbound processing side The difference to manually maintained message types is that the function module that processes the change pointers does not create an IDoc.

Instead it fills the corresponding BAPI structures, determines the receivers and calls the generated ALE function module. The message types, IDoc types and function modules that have been generated can also be used to distribute master data using the SMD tool.

Prerequisites

The essential prerequisite is that a BAPI exists:

• You have developed your own BAPI in the customer namespace. • You have modified a BAPI from the standard system.The BAPI-ALE interface is then created in the customer namespace for the new sub-type and a method assigned to it.

Regardless of whether SAP delivers a BAPI-ALE interface for a BAPI with the new Release, any interface you have generated will continue to function in the same as in the earlier Release.You can regenerate the old interface to adapt newly added parameters, provided that SAP has not delivered a new interface in the new Release.

If SAP delivers a BAPI-ALE interface for a BAPI for which you have already generated an interface, you should use the new interface and delete the interface you generated. You can still use the old interface in the earlier Release.

If you regenerate the old interface, some generated objects, such as segments of SAP objects could be overwritten, if the interface in your BAPI function module references BAPI structures but belongs to SAP.If you want to take into account hierarchical dependencies between BAPI table parameters, then another prerequisite is that you define the hierarchy before generating the BAPI-ALE interface

The specified hierarchy is evaluated when the interface is generated and incorporated in the interface coding.The BAPI-ALE interface must be regenerated following all subsequent changes made to the hierarchy.Once the generated IDoc type has been released, the specified hierarchy of the asynchronous BAPI cannot subsequently be changed because of compatibility problems.

RELATED LINKS

ALE IN BRIEF

MySAP CRM System architecture and design

MySAP CRM architecture and E procurement introduction

ALE 5

Reducing Interfaces Use

The purpose of BAPI and ALE integration is to be able to use ALE business process BAPIs as interfaces.BAPI reductions are particularly necessary in ALE business processes in which master data is replicated asynchronously:

• Part of the BAPI parameter is not required for the receiving system, even though it is declared when the BAPI is called
• Monitor data transferred into non-SAP systems (non R/3 and/or between business partners) (for example, hide fields).

• Certain data cannot be overwritten in the receiving system. BAPI reductions can however be used everywhere where asynchronous BAPI calls can be used. For asynchronous BAPI calls via the BAPI-ALE interface, only the parameters of the BAPI interface relevant for the receiver should be transferred.You can set up BAPI reductions in receiver-dependent filtering in the ALE distribution model. You can create templates for making reductions. Material master data is replicated from a reference system to a sales and distribution system.


As only some of the data on the material is required in the sales and distribution system, a reduction of the BAPI interface, Material.SaveReplica, that contains parameters relevant only to sales and distribution, is specified. You can then specify in the distribution model that with Material.SaveReplica only data relevant to sales and distribution is transferred to the sales and distribution system.


You can filters BAPIs (parameter filtering and reduction), when you maintain the distribution model. Reduction and filter information are part of ALE Customizing data in the distribution model. BAPI filtering must be explicitly activated, when the BAPI-ALE interface is generated.

The reduction of the actual (asynchronous) BAPI call is carried out as a service in the ALE layer. The reduction service retrieves the details of the filter settings from the distribution model at runtime. For a receiver or a list of receivers the application development can query the list of parameters to be filled before the BAPI-ALE interface is called.

This keeps the read-access to the database as low as possible. (Alternatively the call can take place and it does not affect the result of the filtering.) You can only set up one BAPI reduction for each sender and receiver pair.

Prerequisites

The basic data of the BAPI reduction is maintained by the BAPI developer after the BAPI has been released and before the BAPI-ALE interface is generated.

If a parameter hierarchy is to be used, this has to be specified beforehand. The BAPI developer must create the BAPI as reducible using relevant parameter types. Mandatory parameters and fields must be specified.

The section Filtering Data has a table listing the prerequisites for using filter services.

Fully Reducible Parameters

Only table parameters of BAPIs can be fully reduced. A fully reduced table is an empty table in the receiving system.To fully reduce a table parameter T1 with a checkbox, the following prerequisites apply:
Table Parameter Structure
T1 Q1
T1X Q1X

T1X is a checkbox parameter.


Reducing Parameter Fields

Fields are reduced by converting the obligatory check fields of a BAPI and initializing the relevant fields in the data parameter. The checkboxes must be assigned to the data parameters following the naming and structure conventions.The following prerequisites apply for reducing fields of parameter P1:Table Parameter Structure
P1 S1
P1X S1X

Structures S1 and S1X must have the same number of fields, whereby the names of the fields in both parameters must be identical and in the same order.If P1 has a FUNCTION field or key fields, the FUNCTION field in S1 and S1X and each of the key fields have the same data element. All other fields of the checkbox use the data element BAPIUPDATE.

Procedure
To reduce BAPIs:
1. Create a reducible BAPI that satisfies the above prerequisites.
2. Before generating the BAPI-ALE interface, you have to activate data filtering (option Data filtering allowed).

You can set up the filtering in the distribution model in Customizing by choosing Distribution (ALE) → Modeling and Implementing Business Processes → Maintain Distribution Model.
Result
The generated BAPI-ALE interface enables BAPIs to be filtered as a service in outbound processing.

To avoid unncessary accesses to the database, the BAPI parameters required for the receivers can be determined before the BAPI-ALE interface is called. This is optional and will not affect the results of the filtering.


Defining and Assigning Filter Object Types

Filter object types

are already assigned to some BAPIs in your applications for the receiver and data filtering. You can also define your own filter object types and assign them to a BAPI or to a parameter of a BAPI.
Process Flow
To define filter object types for BAPIs, follow the steps below: • Define filter object types From the SAP menu choose Tools → ALE → ALE Development → BAPIs. You can create filter object types in Data filtering or Receiver Determination. Then choose Define filter object type (Transaction BD95, table TBD11).

Give the filter object type a name and specify a reference to a table field. The reference to a table field is needed to retrieve the documentation from the data element so that customers can get input help when maintaining the distribution model.


For this reason a foreign key must be maintained for the table field. Use the following conventions to name filter object types: - Release 3.0/3.1: Domain name (example: KOKRS for the controlling area) - Release 4.0: Default field name for the data element (example: COMP_CODE for the company code)


For the required data object check whether a name has already been entered in the domain and default field names of the data element. If the fields are empty, a new filter object must be created. Usually the filter object will also appear in the BAPI interface as a field in the transfer structure, for example, bapiachead-comp_code.


If this is the case create the filter object as follows: ALE object type: Field name in BAPI structure, for example, comp_code table name: Name of BAPI structure, for example, bapiachead field name: Field name in the BAPI structure, for example, comp_code

• Defining filter object types to a BAPI From the SAP menu choose Tools → ALE → ALE Development → BAPI Interface. You can assign filter object types to a BAPI in Data filtering or Receiver Determination.

The filter object types allowed for an object method are maintained in each view of Table TBD16. − Receiver Determination. Choose Assign filter object type to BAPI. You can maintain the entries: Object type (from table TOJTB), Method, Filter object type (from table TBD11) Keep in mind that for receiver determination you have to implement a business add-in f to determine values for the filter object type you have defined .

Defining and Assigning Filter Object Types

Choose Assign filter object type to parameter. You can maintain the entries:
Object type (from Table TOJTB), Method, Filter object type (from Table TBD11) Parameter Field name Enter the required data to assign a filter object to an object method for the receiver determination or parameter filtering.


Filtering BAPI Parameters Use

Parameter filtering enables you to manage the number of datasets to be replicated in the BAPI interface using filter objects in the ALE distribution model. The parameters filtered are BAPI table parameters. The lines in the BAPI parameter, that do not match the distribution specifications are filtered out. The filtered table lines are not replicated.

Example: The logical system Q4VCLNT800 is the BAPI server for the BAPI RetailMaterial.Clone. Through the parameter filtering only the plant data of the material plant 001 is to be replicated in this system.

Prerequisites

The prerequisite for this filtering is that a Filter Object Type is assigned to the relevant BAPI in your SAP applications. For some BAPIs SAP has already defined and assigned filter object types.You can also define your own filter object types and assign them to a BAPI (Defining Filter Object Types and Assigning Them to a BAPI .You have to define the valid filter object values in the distribution model. For more information see the R/3 Implementation Guide under Distribution (ALE) → Modelling and Implementing Business Processes → Maintain Distribution Model.

Presently, BAPI parameters can only be filtered for distributing master data via BAPIs called asynchronously. For this reason the required ALE Customizing for parameter filtering is only allowed for asynchronous BAPIs with an ALE IDoc interface.

Parameter filtering is allowed for distributing transaction data via asynchronous BAPIs but for the most cases, it has no purpose.BAPI parameter filtering for asynchronous parameters is always optional. To generate the BAPI-IDoc Interface you must select the Activate checkbox. Otherwise no coding can be generated in the BAPI-IDoc interface.

If a BAPI-IDoc interface has been generated without parameter filtering, you can specify no parameter filtering in ALE Customizing afterwards.

Features

Parameters are filtered dynamically at runtime using the current data in the BAPI table parameters and the distribution conditions specified in the ALE distribution model.

• Reads the specified parameter filter objects in the distribution model
• Reads the interface definition of the BAPI
• Reads the table field values of a table entry for the associated filter objects
• Compares the distribution conditions with the filter objects read out and determines the value of the logical expression
• Deletes table entry
• Examines hierarchy-dependent BAPI parameters and, if applicable, deletes dependent table entries
• For synchronous BAPIs: Calls associated function module and forwards the filtered parameters
• For asynchronous BAPIs: Calls the generated BAPI-ALE interface and forwards the filtered parameters.

RELATED LINKS

ALE PART SIX

MySAP CRM System architecture and design

ALE 4

Implementing Your Own BAPIs

SAP provides a large number of BAPIs. If you want to implement your own BAPIs, you have to use your own namespace.

You have the following options:

• You can develop your own BAPI in the customer namespace.

• You can modify a BAPI delivered in the standard system.

1. Copy and modify the function module belonging to the original BAPI.

2. In the Business Object Repository create a subobject type for your BAPI object type in the customer namespace (Tools → Business Framework → BAPI Development → Business Object Builder).When you create the subobject type the methods of the business object inherit the subtype.

3. Set the status of the object type to Implemented (Edit → Change release status → Object type).

4. You can change and delete the methods of the subtype or enhance them with your own methods.

Notes about Asynchronous BAPIs

If you want to implement an asynchronous ALE business process, you have to Define a BAPI-ALE Interface from the BAPI.If you implement a BAPI as an asynchronous interface, in addition to following the standard programming BAPI guidelines, keep in mind the following:

• The BAPI must not issue a COMMIT WORK command.

• The method's return parameter must use the reference structure BAPIRET2.

• All BAPI export parameters with the exception of the return parameter are ignored and are not included in the IDoc that is generated.

• Status records log the BAPI return parameter values.

After the function module which converts the IDoc into the corresponding BAPI in the receiving system has been called, status records are written for the IDoc in which messages sent in the return parameter are logged.If, in at least one of the entries of return parameter, the field Type in the return parameter is filled with A (abort) or E (error), this means:

• Type A:

Status 51 (error, application document not posted) is written for all status records, after a ROLLBACK WORK has been executed.

Type E:

Status 51 (error, application document not posted) is written for all status records and a ROLLBACK WORK is executed.Otherwise status 53 (application document posted) is written and a COMMIT WORK executed.

Filtering Data

There are two filtering services provided for asynchronous BAPI calls using the BAPI-ALE interface.

Interface Reduction: If you want to reduce the BAPI interface, you do not have to define any filter object types. The BAPI reduction does not have any conditions - it is a projection of the BAPI interface. The developer of the BAPI whose interface is to be reduced must create the BAPI as a reducible using appropriate parameter types. The optional BAPI parameters and/or BAPI fields are deactivated in the distribution model for the data transfer. You can reduce an interface in two ways,

• By fields (using checkbox lists)

• Fully • Parameter Filtering Filter Object Types [Extern] are assigned to the business object method. The valid filter object values must be defined in the distribution model. The BAPI parameter filtering is linked to conditions, it is therefore content-dependent: The lines in table parameters of asynchronous BAPIs are determined depending on the values in the lines (or dependent lines) for the receiver.

Filters are used to define conditions in the form of parameter values that must be satisfied by BAPIs before they can be distributed in ALE outbound processing. The table dataset of a BAPI is determined when the parameters are filtered. Hierarchy relationships between table parameters of the BAPI can also be defined. Distribution by Classes [Extern] is also supported.

For more information see Filtering BAPI Parameters BAPI filtering is the term used for the shared use of both the filter services of the BAPI interface. BAPI filtering is implemented as a service in ALE outbound processing.

Prerequisites for Using Filter Services

The table below lists the prerequisites that the BAPI interface must satisfy, so that ALE filter services can be used. The BAPI can have the following parameter types: Field Reduction Full Filtering Parameter Filtering

1. Unstructured without checkbox

2. Unstructured with checkbox X

3. Single-line structured without checkbox

4. Single-line structured with checkbox X .

5. Multiple-line structured without checkbox

X X

6. Multiple-line structured with checkbox

X X X

7. Multiple-line unstructured without checkbox

X

8. Multiple-line unstructured with checkbox

Note: The fields filled with X satisfy the prerequisites.

Explanation of above table:

1. An unstructured parameter without a checkbox is, for example, a BAPI key field (e.g. the parameter Material in methods of the business object Material). This parameter type cannot be reduced.

2. If there is an unstructured checkbox parameter with the name PX and the data element BAPIUPDATE for an unstructured parameter with the name P, the parameter P is reducible. The parameter is reduced by setting the value of P and of the checkbox parameter PX to EMPTY.

3. A single-line, structured parameter without a checkbox is not reducible.

4. A single-line, structured parameter P with structure S and associated checkbox PX with structure SX can be reduced by fields, provided that:

• S and SX have the same number of fields, which are identical in name and sequence.

• The FUNCTION field and the key fields in S and SX each have the same data element.

• All other fields in SX have the data element BAPIUPDATE.

The FUNCTION field in P and the key fields must be marked as mandatory fields. All the other fields you can chose whether to label them as mandatory. Mandatory fields cannot be reduced. Non-mandatory fields are reduced by setting the field values and the corresponding checkbox to EMPTY.

5. Multiple-line structured parameters (table parameters) without a checkbox cannot be reduced by fields. Parameter filtering and full filtering are possible.If the hierarchy is maintained and, if dependent tables exist in the hierarchy, records of the dependent tables will also be filtered.

6. A multiple-line structured parameter P with checkbox PX can be reduced by fields, fully filtered or filtered by parameters.

• For field reduction the prerequisites under 4 must be met.

• The checkbox PX must lie directly under P in the hierarchy, with identical key fields, so that the corresponding lines from P and PX are filled, when the parameters are filtered.

• If the hierarchy is maintained and, if dependent tables exist in the hierarchy, records of the dependent tables will also be filtered.

7. A multiple-line, unstructured parameter can only be fully filtered and cannot be used in a hierarchy. Parameter filtering is not allowed.

8. Multiple-line, unstructured parameters with a check box cannot be filtered.

RELATED LINKS

ALE PART 6

ALE PART 5

MySAP CRM business intelligence at work

CRM data administration in mysap and business intelligence

ALE 3

Distribution Using BAPIs

Controlling the amount of data sent:

• IDocs can be dispatched in packets. The packet size is assigned in ALE Customizing in accordance with the partner profile.Basis Application Link Enabling Modeling and Implementing Business Processes Partner Profiles and Time of Processing Maintain Partner Profile Manually or: Generate Partner Profiles This setting is only effective if you process the IDocs in the background.


Posting of application data and IDoc status If each IDoc or BAPI is processed individually, the data is written immediately to the database. If several IDocs are processed within one packet, the following may happen:

• The application data of the successfully completed BAPI together with all the IDoc status records is updated, provided that no BAPI call has been terminated within the packet.

• As soon as a BAPI call is terminated within the packet, the status of the associated IDoc will indicate an error. Application data will not be updated. Then inbound processing is run again for all the BAPI calls that had been completed successfully.

Provided that there is no termination during this run, the application data of BAPIs and all the IDoc status records are updated. This process is repeated if there are further terminations. Note: Packet processing is only carried out if there is no serialization.

Error handling You can use SAP Workflow for ALE error handling: • The processing of the IDoc or BAPI data causing the error is terminated. • An event is triggered. This event starts an error task (work item).

• Once the data of the BAPI or IDoc has been successfully updated, an event is triggered that terminates the error task. The work task then disappears from the inbound system.

RELATED LINKS

ALE PART FOUR

MySAP CRM System architecture and design
CRM data administration in mysap and business intelligence

ALE 2

The processes in the application layer and the ALE layer are completed on both the inbound and outbound processing sides. The communication layer transfers the data by transactional Remote Function Call (tRFC) or by EDI file interface.

The process can be divided into the following sub-processes:

1. Outbound Processing
• Receiver determination
• Calling the generated outbound function module
• Conversion of BAPI call into IDoc
• Segment filtering
• Field conversion
• IDoc version change
• Dispatch control

2. IDoc dispatch

IDocs are sent in the communication layer by transactional Remote Function Call (tRFC) or by other file interfaces (for example, EDI).
tRFC guarantees that the data is transferred once only.

3. Inbound Processing

• Segment filtering
• Field conversion
• Transfer control
• Conversion of IDoc into BAPI call
• BAPI function module call
• Determination of IDoc status
• Posting of application data and IDoc status
• Error handling

The sub-processes in inbound and outbound processing are described below:
Outbound Processing
On the outbound side first of all the receiver is determined from the distribution model.

Then the outbound function module that has been generated from a BAPI as part of the BAPI-ALE interface is called in the application layer (see also Example Programs with Asynchronous BAPI Calls [Seite 42]).

In the ALE layer the associated IDoc is filled with the filtered data from the BAPI call.The volume of data and time of the data transfer is controlled by the dispatch control.The outbound processing consists of the following steps:

Receiver determination
The receivers of a BAPI call are defined in the distribution model in same way as with synchronous BAPI calls.Before the BAPI or generated BAPI-ALE interface can be called, the receiver must be determined.

When the receiver is determined, the filter objects are checked against the specified conditions and the valid receivers are reported back.If the distribution of the data is also dependent on conditions, these dependencies between BAPIs or between BAPIs and message types are defined as receiver filters.For each of these receiver filters, before the distribution model is defined, a filter object is created whose value at runtimes determines whether the condition is satisfied or not.

For more information see Determining Receivers of BAPIs [Seite 35].Calling the generated outbound function module.If the receivers have been determined, you have to differentiate between local and remote receivers.

The BAPI can be called directly for local receivers. For remote calls the generated ALE outbound function module must be executed so that processing is passed to the ALE layer. The data for the BAPI call and the list of allowed logical receiver systems are passed to this function module.


Programming Notes:

After calling the generated function module the application program must contain the command COMMIT WORK.The standard database COMMIT at the end of the transaction is not sufficient. The COMMIT WORK must not be executed immediately after the call, it can be executed at higher call levels after the function module has been called several times.The IDocs created are locked until the transaction has been completed. To unlock them earlier, you can call the following function modules

:
DEQUEUE_ALL releases all locked objects
EDI_DOCUMENT_DEQUEUE_LATER releases individual IDocs whose numbers are transferred to the function module as parameter values.


Data Filtering

Two filtering services can be used - parameter filtering with conditions and unconditional interface reduction.

• Posting of application data and IDoc status
• Error handling
• f entire parameters have been deactivated for the interface reduction, they are not included in the IDoc. If, on the other hand, only individual fields are not to be included for structured parameters, the entire parameters are still included in the IDoc.

• With parameter filtering, table rows that have been filtered out are not included in the IDoc. For more information see Filtering Data [Extern]. Conversion of BAPI call into IDoc Once the data has been filtered, an IDoc containing the data to be transferred, is created from the BAPI call by the outbound function module Segment filtering Once the IDoc has been created, IDoc segments can be filtered again. This filtering is rarely used for BAPIs.

For example, the field plant can be converted from a two character field to a four character field.Standard Executive Information System (EIS) tools are used to convert fields. IDoc version change To guarantee that ALE works correctly between different releases of the R/3 System, IDoc formats can be converted to modify message types to suit different release statuses.

If version change has been completed, the IDocs are stored in the database and the dispatch control is started which decides which of these IDocs are sent immediately. SAP uses the following rules to convert existing message types:
• Fields can be appended to a segment type

• New segments can be added ALE Customizing records the version of each message type used in each receiver. The IDoc is created in the correct version in outbound processing. Dispatch control Scheduling the dispatch time: • IDocs can either be sent immediately or in the background.

This setting is made in the partner profile. • If the IDoc is sent in the background, a job has to be scheduled. You can choose how often background jobs are scheduled.

• f entire parameters have been deactivated for the interface reduction, they are not included in the IDoc. If, on the other hand, only individual fields are not to be included for structured parameters, the entire parameters are still included in the IDoc.

• With parameter filtering, table rows that have been filtered out are not included in the IDoc.

For more information see Filtering Data [Extern]. Conversion of BAPI call into IDoc Once the data has been filtered, an IDoc containing the data to be transferred, is created from the BAPI call by the outbound function module Segment filtering Once the IDoc has been created, IDoc segments can be filtered again. This filtering is rarely used for BAPIs.

These are important for converting data fields to exchange information between R/2 and R/3 Systems. For example, the field plant can be converted from a two character field to a four character field.

Standard Executive Information System (EIS) tools are used to convert fields. IDoc version change To guarantee that ALE works correctly between different releases of the R/3 System, IDoc formats can be converted to modify message types to suit different release statuses.

If version change has been completed, the IDocs are stored in the database and the dispatch control is started which decides which of these IDocs are sent immediately. SAP uses the following rules to convert existing message types: • Fields can be appended to a segment type

• New segments can be added ALE Customizing records the version of each message type used in each receiver. The IDoc is created in the correct version in outbound processing. Dispatch control Scheduling the dispatch time:

• IDocs can either be sent immediately or in the background. This setting is made in the partner profile.

• If the IDoc is sent in the background, a job has to be scheduled. You can choose how often background jobs are scheduled.

RELATED LINKS

ALE PART THREE

Customer Relationship Management and mysap an introduction
CRM Management and sales and service strategy of mysap crm

MySAP CRM and customer relationship management
My SAP CRM , Business Scenarios and SAP Solutions

ALE 1

ALE provides a complete programming model for implementing BAPIs. ALE supports these method calls:

• Synchronous method calls

Synchronous method calls can also be used in ALE distribution scenarios. These method calls are either BAPIs or Dialog Methods [Seite 191].In ALE Customizing you can assign the RFC destinations to be used for a synchronous method call.

• Asynchronous method calls

If BAPIs are called asynchronously, ALE error handling and ALE audit can be used.If an asynchronous BAPI call is to be used for the distribution, the BAPI-ALE interface required for inbound and outbound processing can be automatically generated. Developing an ALE business process in ABAP is restricted to the programming of the BAPI.

An object-oriented approach has the following advantages:
- The application only has to maintain one interface
- The automatic generation of the BAPI-ALE interface avoids programming errors.

Process Flow

If you are not enhancing an SAP BAPI and you are not creating your own BAPI when you are implementing an ALE business process, you can simply follow the steps below:
• Filtering Data
• Determining the BAPI Receivers

If, on the other hand, you want to enhance a BAPI or create your own, you have to follow these steps:

• Implementing Your Own BAPIs
• Maintaining the BAPI-ALE Interface
• Determining the BAPI Receivers Application programs must call a function module for the receiver determination and a generated application function module in the BAPI-ALE interface.You can verify the quality of the ALE layer and ALE business processes using Automatic Tests.

BAPIs can be called by applications synchronously or asynchronously. ALE functions such as BAPI maintenance in the distribution model and receiver determination can be used for both types of call.Note that synchronously-called BAPIs are only used for reading external data to avoid database inconsistencies arising from communication errors.

The application synchronously calls a BAPI in the external system to create an FI document. The document is correctly created but the network crashes whilst the BAPI is being executed. An error message is returned to the application and the FI document is created again.The document has been duplicated in the system called.An application program can implement a two-phase commit by thoroughly checking the data in the external system.An easier solution is to call the BAPI asynchronously, as Error Handling assures that the data remains consistent.
A BAPI should be implemented as an asynchronous interface, if one of the criteria below applies:

• Consistent database changes in both systems

Data must be updated in the local system as well as on a remote system
• Loose coupling

An asynchronous interface would represent too narrow a coupling between the client and the server systems. If the connection fails the client system can no longer function correctly.

• Performance load

The interface is used often or it handles large volumes of data. A synchronous interface cannot be used in this situation because performance would be too low.If you want to implement a BAPI as an asynchronous interface, you have to generate a BAPI-ALE interface for an existing BAPI.

RELATED LINKS

ALE PART TWO

Customer Relationship Management and mysap an introduction
CRM Management and sales and service strategy of mysap crm
MySAP CRM and customer as business partner
My SAP CRM , Business Scenarios and SAP Solutions

FAQ'S ON ENHANCEMENTS

What are user exits?

What is involved in writing them? What precautions are needed?
User defined functionality included to predefined SAP standards. Point in an SAP program where a customer's own program can be called. In contrast to customer exits, user exits allow developers to access and modify program components and data objects in the standard system.

On upgrade, each user exit must be checked to ensure that it conforms to the standard system.
There are two types of user exit:
User exits that use INCLUDEs.
These are customer enhancements that are called directly in the program.
User exits that use tables.
These are used and managed using Customizing.
Should find the customer enhancements belonging to particular development class.


What are the different ways in which you can make changes to SAP standard software ?

Customizing
Enhancements to the SAP Standard
Modifications to the SAP Standard
Customer Development

What is customizing ?

Customizing is the setting of system parameters via SAP's own interface.

Why do you need enhancements ?

The standard applications do not offer some of the functionality you need. The R/3 enchancement concept allows you to add your own functionality to SAP's standard business applications.

What are the different types of enhancements ?

Enhancements using customer exits
Customers' potential requirements which are not included in the standard software are incorporated in the standard as empty modification 'shells'. Customers can then fill these with their own coding. Enhancements can relate to programs, menus and screens. Upward compatibility is assured.

In other words, SAP guarantees that the jump from the standard software to the exit and the interface which call the exit will remain valid in future releases.

Enhancements to ABAP/4 Dictionary elements
These are ABAP/4 Dictionary enhancements (creation of table appends), text enhancements (customer-specific key words and documentation for data elements) and field exits (creation of additional coding for data elements).

What is customer development ?

Creating customer-specific objects within the customer name range.

What is SSCR ?

SSCR (SAP Software Change Registration) is a procedure, for registering all manual changes to SAP source coding and SAP Dictionary objects.

What is the difference between modifications and enhancements ?

Modifications mean making changes to the SAP standard functionality.
Enhancements mean adding some functionality to SAP standard functionality.

What are the disadvantages of modification ?

Modifying standard code can lead to errors
Modifications mean more work during software upgrades

What are the advantages of enhancements ?

Do not affect standard SAP source code
Do not affect software upgrades

when do you opt for modification ?

Customer exits are not available for all programs and screens within the R/3 standard applications. You can only use exits if they already exist within the SAP R/3 System . Otherwise you have to opt for modifications .

What are the various types of customer exits ?

Menu exits
Screen exits
Function module exits
Keyword exits

What is a menu exit ?

Adding items to the pull down menus in standard R/3 applications .

13.What is a screen exit ?

Adding fields to the screens within R/3 applications. SAP creates screen exits by placing special subscreen areas within a standard R/3 screen and calling a customer subscreen from within the standard dynpro's flow logic.

What is a function module exit ?

Adding functionality to R/3 applications. Function module exits play a role in both menu and screen exits.

What is a keyword exit ?

Add documentation to the data elements of key words defined in the ABAP/4 Dictionary. The system displays this documentation whenever a user presses F1 to get online help for a screen field.

How do SAP organizes its exits ?

SAP organizes its exits in packages that are called SAP enhancements. Each SAP enhancement can contain many individual exits.

What is an add-on project ?

To take advantage of the exits available within standard R/3 applications, you need to create an add-on project. This project lets you organize the enhancement packages and exits you want to use. The add-on project also allows you to hang add-on functionality onto the exit hooks contained with SAP enhancements.

RELATED POSTS

FAQ'S ON ABAP CROSS APPLICATIONS
ABAP ASSINGNMENT

MySAP CRM and customer relationship management
My SAP CRM , Business Scenarios and SAP Solutions

Marketing and erp mysap crm options
Organizational Challenges with crm and mysap crm solutions
My sap crm and marketing planning

FAQ'S ON MODULE POOL

Transactions:

A transaction is a program that conducts a dialog with the user. In a typical dialog, the system displays a screen on which the user can enter or request information.Based on the the user input or request, the program executes the appropriate actions like, it branches to the next screen, displays an output, or changes the database.Explain what is a transaction in SAP terminology.In SAP terminology, a transaction is series of logically connected dialog steps.

Explain how SAP GUI handles output screen for the user.

• User terminal input is accepted by SAP GUI and sent to the SAP dispatcher. The dispatcher co-ordinates the information exchange between the SAP GUIs and the work processes.The dispatcher first places the processing request in request queues, which it then processes. The dispatcher dispatches the requests to the available work process. The actual processing takes place in the work process.When processing is complete, the result of a work process is returned via the dispatcher to the SAP GUI. The SAP GUI interprets the received data and generates the output screen for the user.

What is LUW or Database LUW or Database Transaction ?

• A “LUW” ( logical unit of work ) is the span of time during which any database updates must be performed . Either they are all performed ( committed ) , or they are all thrown away ( rolled back ).

LUW ( or “database LUW” or “database transaction” )
This is the set of updates terminated by a database commit. A LUW lasts, at most, from one screen change to the next ( because the SAP system triggers database commits automatically at every screen change ).

LUWs help to guarantee database integrity. When an LUW has been successfully concluded, the database is once again in a correct state. If, however, an error occurs within an LUW, all database changes made since the beginning of the LUW are canceled and the database is then in the same state as before the LUW started.

An LUW begins

• Each time you start a transaction
• When the database changes of the previous LUW have been confirmed (database commit) or
• when the database changes of the previous LUW have been cancelled (database rollback)
An LUW ends

- When the database changes have been confirmed (database commit) or
- When the database changes have been canceled (database rollback)

What is SAP LUW or Update Transaction ?

- Update transaction ( or “SAP LUW”)
This is a set of updates terminated by an ABAP/4 commit. A SAP LUW may last much longer than a database LUW, since most update processing extends over multiple transaction screens.The programmer terminates an update transaction by issuing a COMMIT WORK statement.

Does the external program run in the same SAP LUW as the caller, or in a separate one?

- Transactions run with a separate SAP LUW
- Reports run with a separate SAP LUW
- Dialog modules run in the same SAP LUW as the caller

• Function modules run in the same SAP LUW as the caller
The only exceptions to the above rules are function modules called with IN UPDATE TASK (V2 function only) or IN BACKGROUND TASK (ALE applications). These always run in their own (separate) update transactions.

What are the requirements a dialog program must fulfill ?

• A dialog program must fulfill the following requirements
. a user friendly user interface
. format and consistency checks for the data entered by the user
. easy correction of input errors
. access to data by storing it in the database.
What are the basic components of dialog program ?

• Screens (Dynpros)
Each dialog in an SAP system is controlled by dynpros. A Dynpro consists of a screen and its flow logic and controls exactly one dialog step.
• ABAP/4 module pool
Each dynpro refers to exactly one ABAP/4 dialog program. Such a dialog program is also called a module pool, since it consists of interactive modules.
What is a dynpro ? What are its components ?

• A dynpro (DYnamic PROgram) consists of a screen and its flow logic and controls exactly one dialog step.The different components of the dynpro are:
Flow logic: Calls of the ABAP/4 modules for a screen
Screen layout: Positions of the texts, fields, pushbuttons, and so on for a screen
Screen attributes: Number of the screen, number of the subsequent screen, and others
Field attributes: Definition of the attributes of the individual fields on a screen
What is screen flow logic? What are the selections in it? Explain PAI and PBO?
Ans - Screen flow logic contains the procedural part of a screen. The screen flow logic is like an ABAP program in that it serves as a container for processing blocks. There are four event blocks, each of which is introduced with the screen keyword PROCESS:

PROCESS BEFORE OUTPUT.
...
PROCESS AFTER INPUT.
...
PROCESS ON HELP-REQUEST.
...
PROCESS ON VALUE-REQUEST.

Selections are performed in PAI.

PROCESS BEFORE OUTPUT (PBO) is automatically triggered after the PAI processing of the previous screen and before the current screen is displayed. You can program the PBO processing of the screen in this block. At the end of the PBO processing, the screen is displayed.

PROCESS AFTER INPUT (PAI) is triggered when the user chooses a function on the screen. You can program the PAI processing of the screen in this block. At the end of the PAI.

processing, the system either calls the next screen or carries on processing at the point from which the screen was called.

PROCESS ON HELP-REQUEST (POH) and PROCESS ON VALUE-REQUEST (POV) are triggered when the user requests field help (F1) or possible values help (F4) respectively. You can program the appropriate coding in the corresponding event blocks. At the end of processing, the system carries on processing the current screen.

Can we use WRITE statement in screen fields ? If not how is data transferred from field data to screen fields

• We cannot write field data to the screen using the WRITE statement. The system instead transfers data by comparing screen field names with ABAP/4 variable names. If both names are the same, it transfers screen field values to ABAP/4 program fields and vice-versa. This happens immediately before and immediately after displaying the screen.

How does the interaction between the Dynpro and the ABAP/4 modules takes place ?
• A transaction is a collection of screens and ABAP/4 routines, controlled and executed by a Dialog processor.

The Dialog processor processes screen after screen, thereby triggering the appropriate ABAP/4 processing for each screen. For each screen, the system executes the flow logic that contains the corresponding ABAP/4 processing. The control passes from screen flow logic to ABAP/4 code and back.


How does the Dialog handle user requests ?
- When an action is performed, the system triggers the PROCESS AFTER INPUT event. The data passed includes field screen data entered by the user and a function code. A function code is a technical name that has been allocated in the Screen Painter or Menu Painter to a menu entry, a pushbutton, the ENTER key or a function key of a screen. An internal work field (ok-code) in the PAI module evaluates the function code, and the appropriate
action is taken.


How are the function codes handled in flow logic ?
- When the user selects a function in a transaction, the system copies the function code into a specially designated work field called OK_CODE. This field is global in the ABAP/4 module pool. The OK_CODE can then be evaluated in the corresponding PAI module.


The function code is always passed in exactly the same way, regardless of whether it comes from a screen's pushbutton, a menu option, function key or other GUI element.
What controls the screen flow ?

• The SET SCREEN and LEAVE SCREEN statements control screen flow.

What are “field” and “chain” statements ?
• The FIELD and CHAIN flow logic statements let you program your own field checks. FIELD and CHAIN tell the system which fields you are checking,and whether the system should perform checks in the flow logic or call an ABAP/4 module.

What is an on “*-input field” statement ?
• ON *-INPUT
The ABAP/4 module is called if the user has entered a "*" in the first character of the field, and the field has the attribute *-entry in the Screen Painter. You can use this option in exceptional cases where you want to check only fields with certain kinds of input.

What are conditional chain statements ?
• ON CHAIN-INPUT similar to ON INPUT.
The ABAP/4 module is called if any one of the fields in the chain contains a value other than its initial value (blanks or nulls).
ON CHAIN-REQUEST
This condition functions just like ON REQUEST, but the ABAP/4 module is called if any one of the fields in the chain changes value.

What is “at exit-command” ?
• The flow logic keyword AT EXIT-COMMAND is a special addition to the MODULE statement in the flow logic. AT EXIT-COMMAND lets you call a module before the system executes the automatic field checks.

Which function type has to be used for using “at exit-command” ?
• To use AT EXIT-COMMAND, we must assign a function type ‘E’ to the relevant function in the Menu Painter or Screen Painter.

What is the difference between SET SCREEN and CALL SCREEN ?
With SET SCREEN, the current screen simply specifies the next screen in the chain. control branches to this next screen as soon as the current screen has been processed. Return from next screen to current screen is not automatic. It does not interrupt processing of the current screen. If we want to branch to the next screen without finishing the current one, use LEAVE SCREEN.

With CALL SCREEN, the current (calling) chain is suspended, and a next screen (or screen chain) is called in.

The called screen can then return to the suspended chain with the statement LEAVE SCREEN TO SCREEN 0. Sometimes we might want to let an user call a popup screen from the main application screen to let them enter secondary information. After they have completed their entries, the users should be able to close the popup and return directly to the place where they left off in the main screen. Here comes CALL SCREEN into picture.

This statement lets us insert such a sequence into the current one.
Can we specify the next-screen number with a variable. ( Yes / No ).
Yes.

The field SY-DYNNR refers to ________________.
Number of the current screen.

RELATED POSTS

FAQ'S ON ENHANCEMENTS
ABAP REAL TIME QUESTIONS PART 1
My sap crm and marketing planning

FAQ ON SCRIPTS 3

Styles

Styles are used to predefine paragraph and character formats for forms. SAP provides several standard styles e.g. for Address includes, on-line documentation and so on. You can define your own styles.

To find styles, create styles and maintaine styles, use transaction SE72.
You assign style to a text by using menu Format -> Style
You can make temporary style changes using the control command /: STYLE

Using graphics in SapScript
Use transaction SE78 to inmport graphics to SAP.
In the form painter, you can either include directly to the form using menu Edit->Graphic->Create or using the INCLUDE statement in a window.

To use an INCLUDE stanment, goto into the woindow script editor and use menu Include->Graphic. The include can look like this for a bitmap:
/: BITMAP MYLOGO OBJECT GRAPHICS ID BMAP TYPE BMON

Modifications


Considerations in connection with modifications

The standard SAP print program should only be changed when it is absolutely necessary. If additional data is needed, these can in many cases be retrieved using a a PERFORM statement in the form instead of changing the print program..

There can be the following reasons to change the print program:
Structureal changes
New text eloements are needed

Print program to be used to print additional forms
Determine/change which forms and printprograms that are used for printing
The forms and print programs for a given output type and application can be found in table TNAPR Processing programs for output

Use view V_TNAPR in (Transaction SE30) to change entries.
Import/Export SapScript form from PC file
Use ABAP program: RSTXSCRP
SD - Finding the name of the print program
For SD dopcuments you can use table TNAPR top find the name of the a
printprogram

RELATED POSTS

FAQ'S ON SAP SCRIPTS PART 1
CRM Uses and how to get best results with CRM
CRM software solutions and mysap advantage
My sap crm and marketing planning

FAQ ON SCRIPTS 2

Symbols and Control commands

Symbols are placeholders for values that are inserted during print formatting.
Symbols are indentified by name surrounded by "&" and are not case sensitive


Types of symbols
System symbols
DATE Date
DAY Day
NAME_OF_DAY Name of day
MONTH Month
YEAR Year
TIME Time
HOURS Hours
MINUTES Minutes
SECONDS Seconds
PAGE Page number
NEXTPAGE Number of next pagre
DEVICE Output device
SPACE Blank space
ULINE Underline
VLINE Vertical line
Standard symbols

Standard symbols are user defined and are maintained in table TTDG(table is not available???)

. You use transaction SM30 to change or display standard symbols.
An examples of standard symbols is &MFG& fot "Yours faithfully"
Standard text
standard texts is predifined texts that can be used in more than one form. Standard texts are can be created, changed and displayed using transaction SO10.
The text ID is used to classify texts.


To include a standard text in a form, use the INCLUDE command:
INCLUDE Z_BC460_EX4_HF OBJECT TEXT ID SDVD
When formatting the standard text the PARAGRAPH parameter is used. To center the text use:

Example:
INCLUDE Z_BC460_EX4_HF OBJECT TEXT ID SDVD LANGUAGE EN PARAGRAPH C.
Name: Z_BC460_EX4_HF
Object: Text
Text id: SDVD (Text id from SO10)
Language: EN
Paragraph: C (Centered)
Tip: You can use menu Insert->Text->Standard to make it easier to insert the text
Program symbols
Program symbols are for contents of database fields or global program symbols. When you print the form, data from the database tables are printed isntead of the symbols.
In the print program:


TABLES: kna1.
In the form:
&KNA1-NAME1&
Formatting
&SYMBOL& No formatting
&SYMBOL+4& Offset - Output begins here. Offset refers to formatted value
&SYMBOL(5)& Length - Output data in the specified length
&SYMBOL(I)& Suppress initial value - If the field has been initialized, nothing is output
&SYMBOL(Z)& Suppress leading zeros
&SYMBOL(C)& Compress blank spaces - Consecutice spaces are compressed into a single space. Leading spacesare suppressed.
&SYMBOL(R)& Right align output
&SYMBOL(S)& Operators are suppressed
&SYMBOL(*)& Dictionary length - The data length is defined by the ABAP dictionary
&SYMBOL(8.2)& Decimal format. Length 8 decimals 2
&'text1'SYMBOL'text2'& Text can be inserted before and after the symbol
Control commands
Control command are used to modify text output. Use format key /: in the format column.

The intensity is the grey scale of the box as %. The frame parameters is the thickness of the frame. Default is 0.


Each of the paramteters ypos, xpos, width, height and frame muts be followed of the measurement unit:


TW (twip)
PT (point)
IN (inch)
MM (millimeter)
CM (centimeter)
LN (line)
CH (character).
Examples:
BOX XPOS '11.21' MM YPOS '5.31' MM HEIGHT '10' MM WIDTH '20' MM INTENSITY 10 FRAME 0 TW

Draws two rectangles and two lines to construct a table of three columns with a highlighted heading section.

POSITION and SIZE

You can use the POSITION and SIZE commands to set default parmeters for a box. This can be usefull if you have several boxes that share the same parameters.

If you want to set the position realtively to the window use POSITION WINDOW to set the position to the top/left start of the window. Then use POSITION to set the current position relatively to the start of the Window. Note that you uses "+" or "-" in the ORIGIN position to the set the position relatively.the position is now 5 MM from the left and 10 MM from the top of the window.After using the position command you can move the current position realtively to the last used position

RELATED POSTS

FAQ'S ON SAP SCRIPTS PART 3
CRM software solutions and mysap advantage
MySAP CRM and customer relationship management
My SAP CRM , Business Scenarios and SAP Solutions

FAQ ON SCRIPTS 1

SAP Scripts

What is sap script and layout set?

Ans - SAP script is the integrated text management system of the SAP R/3 System. SAPscript is tightly integrated into the SAP System. It is used for many different word-processing tasks all over the SAP System.

What is layout set?

A layout set in SAPscript is used for page layout. The layout set contains various elements, which are used for layout control of the individual pages and also contain layout information for texts which are to be output on the individual pages.
The layot of a document is defined in a layot set.

A layout set specified the appearance and structure of a document.
Layout sets contain predefined text modules with space reserved for variable data. You can use these text modules for different application.

Every SAPscript document uses a layout set.
To make changes to your documents, such as moving a piece of text, or changing fonts, paragraph formats, and tabs, you only need to change the layout set.

There are two ways of formatting texts using layout sets:
The text is entered and output in standard text maintenance. You can assign any layout set.

Text can also be entered via the layout set a letter header, for example.

The text is formatted via an ABAP/4 program using a layout set. The program can either dynamically output individual predefined text modules, text elements or transfer entire texts, which are to be output in the layout set.

You can use Styles to define the formatting of the text in your documents. A style determines text formatting by setting the paragraph and character formats used in a document.

You can, for example, use a style to highlight character strings or whole paragraphs. You can assign a style to any text. Typically, however, you’ll use styles
primarily in the main windows of layout sets, where users type or enter text directly in documents.

Header data is found in both style and layout set maintenance.
In style maintenance, it is used primarily to present important information - designed to make it easier for the end user to select a style. The header data in layout set maintenance, on the other hand, is used for information and control purposes.


Windows are defined in layout set maintenance. They represent areas which are positioned on pages as page windows and in which text is later output. At least one window must be defined for each layout set. If not, a text cannot be formatted by SAP script.

The following window types can be used:
MAIN - Main window in which continuous text is output. This is the window used by dialog users of a print program and layout set. For example the body text of a letter would be entered in MAIN.


VAR - Window with variable contents. The text can vary on each page in which the window is positioned. Variable windows are formatted for each page.
CONST - Window with constant contents which is only formatted once.

A layout set has the following elements:

Header data - Data related to development (created by, development class, etc.) and layout set information (which elements are used) are both stored in the header data. A start page must be entered here.

Paragraph formats - Paragraph formats are required in layout sets - as in styles - in order to format texts. However, they are also used for word processing in layout sets, for example, to format text elements.

Character formats - You can also use character formats to format texts or paragraphs. Unlike paragraph formats, however, they are used to format text within a paragraph.
Windows - Windows are names and window types, which are not physically positioned until they are allocated to pages and units of measurement are specified.
Pages - Pages are defined to provide the system with a start and end point in text formatting.


Page windows - Page windows are the combination of windows and pages, where the dimensions of a window and its position on a page are specified.
The purpose of SAP script control commands 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.


What is SAPscript and explain its purpose?
SAP Script is the SAP system’s own text-proessing system. You’ll find that it looks and feels a lot like other leading text-processing system that you may use on your personal computer.


Every company needs to output documents with a uniformly defined layout (eg. Invoices, delivery notes, etc..) all the time.


The basic layout of the document is pre-defined , but in many cases, other data has to be merged with it, such as address data or purchase order items. This data might be entered manually by a employee, or retrieved from a database table.
Large quantities of these documents have to be produced.

From printing is usually a mattter of large print runs of documents such as payslips, checks, order confirmation, reminders etc.
SAPscript has been developed to meet the above requirements. IT is an integrated tool for text entry and form printing in R/3 applications.

These documents are normally provided by SAP but every organization have their unique waqys of these documents so to customize these and for creating newer ones if required; SAP script is used.


What are components of SAPscript?
Layout set, SAPscript Text, ABAP Print program , symbols, function modules like open_form, close_From, Read_text etc,.
What are the ABAP/4 Commands that link to a layout set?
Call function OPEN-form. Call function WRITE-from. Call function CLOSE-from
Importing Graphics (Logos) into SAPScript
The program RSTXLDMC can be used to upload graphics (file extension .tif on PC files) into individual standard text.
Other useful programs for SAPScript
RSTXFCON - Converts page format
RSTXSCRP - Upload/Download layout sets
RSTXDBUG - SAPScript debugger
Debug SAPScript


You can debug a SAPScript: Use Tools - Word Processing - Layout Set.
Enter name of layout set and then Utilities - Activate Debugger.
It is of no consequence which layout set you enter when selecting the SAPscript debugger. (Menu path: Tools-Word-processing - Forms, Utilities - Activate Debugger) The next layoutset called will invoke the debugger.

This is quite handy when verifying which layoutset is being called (Verifying customizing settings).
Another way to set the SAPScript debugger is to run program RSTXDBUG.
When a Form is copied from one client to another .And If U try to display or change the form in the copied client

.The possible error message cud be :
1.Form not found
Try coping again specifing the language .
2.IF IT dispalys an error message saying That the text file is inconsistent .
Then go to SE38 and Run “RSTXCHKO” .
It will ask for the form name ,then check all the checkboxes and then run the program.
Note : all Script related problems can be solved using Program ‘RSTX*’.
How to take a back up of script layout into U’r hard disk and load it later
Use Program RSTXSCRP.


Use EXPORT mode, when downloading and IMPORT when uploading a script. Don’t forget to give the form name in the object field. This will create a script with the same name as that of the original script .

If a script with the same name exists in the same client ,then it will give an error ‘Object cannot be overwritten ’ .
I want to copy table across clients
Use Program RSCLTCOP


To transfer script files across systems (Not Clients) - RSTXSCRP
To compare the contents of a table across clients: RSTBSERV
To change the development class of any object - RSWBO052
What type of variables normally used in sap script to output data?
&Tables name- fields&.
How do you number pages in sap script layout outputs?
& page &
&next Page &
What takes most time in SAP script programming?
Defining layout set up / sets.
How do you use tab sets in layout sets?
Define paragraph with defined tabs.
How do you backup sap script layout sets? Can you download and upload? How?
SAP script backup :- In transaction SE71 goto Utilities -> Copy from client -> Give source form name, source client (000 default), Target form name.
Download :- SE71, type form name -> Display -> Utilities -> form info -> List -> Save to PC file.
Upload :- Create form with page, window, pagewindow with the help of downloaded PC file. Text elements for Page windows to be copied from PC file.
What is Compare Tool in SAP Script ?
SAP Script offers tools for comparing objects across clients. We can compare or copy the following kinds of objects.
Styles
Layout sets
Documents
With the Compare tool we can do the following :
Check whether an object exists in both clients
Display the differences between the versions of an object
Layout Sets are used to control page layout and text formatting in documents .
SAP Standard styles and layout sets are always held in Client 000.



In what format does SAP Script store text ?
SAPscript texts are stored in Interchange Text Format (ITF). SAPscript offers conversion programs for the text file formats Rich Text Format (RTF) and ASCII as an interface to other word processors.
The various window types in SAP Script are
Main, Variable and Constant.


The New-Page command is used to force a Page break in the text at any point.
Protect ... Endprotect command pairs can be nested (True / False).
False.


Delimiter & must be used immediately before and after the symbol.
What does the composer do?
The final appearance of your documednt depends on interaction between the print program and the layout set.


The SAPscript print program initializes the printing process. Every command entered using the SAPscript programming interfaces is transferred to the composer.
The composer received layout information from the layout set specified by the print program. The documents are formatted according to this layout information.


If the documents contain variables, the compoer replaces these variables with data from the R/3 system, such as the current date, or with the userdata selected by the print program.
The print program controls the completion of thelayout set. Once this is done, the composer places the completed document in the spool.


Where do we define Tab space for data in SAPScript?
When defining the paragraph for the text element we can define the TABS then. There is parameter called TABS to be defined in paragraph definition.
what is difference between Window & a Page Window?

Window: An area that is predefined in the layout set. Windows are text modules, which are positioned on a document page.
We define the window type, Default Paragraph, specify the text elements or a SAPscript text to be included etc in the Windcow Component.
PageWindow: we define the parameters of the earlier defined Window, appearance on the document like left or right margins, Width & Height.
What are symboles & state their different types with E.g.

A Symbol is a constant, which can be inserted in a document. It saves the user unnecessary work when replacing sections of text, phrases, etc. Each symbol has a name which is encloses by &.
Eg. &variable name &
System symbols eg &Date&, &time& etc.
Standard symbols :Standard symbols are user-defined. They are maintained centrally in table TTDTG. Eg. &SGDH& for the opening salutation : “dear sir/madam”.
&MFG& for the closing salutation :”yours Faithfully”.


Program Symbols : Program symbols display data from the ABAP/4 program which has called the word processing function Eg. Itab-connid.


Text symbols: You can define a text symbol for any text module. This symbol is valid only in the text module for which you have defined it. Eg. Define &Symbol& = ‘value’.
How do we define Text symbols?
Using the control command DEFINE &x1& = ‘56’.
State few control commands?.
Protect .. endprotect, define, new-page, include.. if… endif.
what is the purpose of “Protect and EndProtect”?.


You can specify either in the style or in the layout set that a particular paragraph should not be slit in two by a page beak. If the page protect attribute is set then the complete paragraph is always output ona single page. This property applies only to that particular paragraph. SAPScript provides the PROTECT… ENDPROTECT command pair to allow you to define the areas to be protected against a page beak on an individual basis.

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.
How do we set the date, time format?
SET TIME MASK : CONROLS THE TIME FIELD FORMAT.
SET DATE MASK : CONTRLS THE DATE FIELD FORMAT.
EG. Set Time Mask = “ HH:MM:SS”.
what is the role of an ABAP progrm in SAPScript?
Retrieves R/3 application data from the database.


Defines the layout set processing logic ( The order and repetition of text elements).
Chooses a layout set for printing.
Selects the output device, such as printer,monitor, or fax.
Sets print attributes such as immediate output, number of copies ,and pages to beprinted.

How to reuse some components of the script layout to other program?
Is this script layout is standard for all the printer? If not then y we are going for script layout?

Give me couple of methods that I will take standard script layout printout for different printer.

How u will analysis script program? ( which goes to main and how many windows etc….)
Can V inserted logo on your program?. Give me the program name which uploads my logo and syntax for logo inserting in sap script.
Yes u can insert a logo on your script layout.
Use this Report “RSTXLDMC” which will uploads the logo.
Use the following statement which includes the logo on your script prog.
/: INCLUDE 'ZHEX-MACRO-XXX' OBJECT TEXT ID ST LANGUAGE 'E'.
XXX - object name, u will gives @ runtime in rstxldmc program.
Give me syntax for box command.
BOX XPOS 2 MM WIDTH 0 CM HEIGHT '9.5' CM FRAME 10 TW
Script Commands.
Defining a variable

DEFINE &CUST& = '00000021'.
Define and insert a standard text:
Standard texts is predifined textst that can be used in more than one form. Standard texts are can be created, changed and displayed using transaction SO10.
The text ID is used to callsify texts.
To include a stadard text in a form, use the INCLUDE command:
/: INCLUDE Z_BC460_EX4_HF OBJECT TEXT ID SDVD
When formatting the standard text the PARAGRAPH parameter is used. To center the text use:
/: INCLUDE Z_BC460_EX4_HF OBJECT TEXT ID SDVD LANGUAGE EN PARAGRAPH C.
Formatting addresses
The ADDRESS-ENDADDRESS command formats addresses according to the postal norms of the recipient's country, as defined in the
country parameter.
ADDRESS DELIVERY PARAGRAPH AD
NAME &KNA1-NAME&
STREET &KNA1-STRAS&
POSTCODE &KNA1-PSTLZ&
CITY &KNA1-ORT01&'
COUNTRY &KNA1-LAND1&
FROMCOUNTRY 'DE'
ENDADDRESS
Avoiding pagebreaks in a paragraph
/: PROTECT
:
:
/: ENDPROTECT

The text lines to be protected are enclosed between the two commands
Conditonal text ouput IF - ENDIF
You can use IF/ENDIF like in a normal ABAP program
/: IF condition
:
:
/: ENDIF
and
/: IF condition
:
/: ELSE
:
/: ENDIF
Example:
/: IF &SPFLI-CITYTO& = "BERLIN"
..... put some text here
/: ENDIF


RELATED POSTS

FAQ'S ON SAP SCRIPTS PART 2

Customer Relationship Management and mysap an introduction
Organizational Challenges with crm and mysap crm solutions
My sap crm and marketing planning

ABAP PERFORMENCE TIPS

ABAP/4 Optimization


Use the GET RUN TIME command to help evaluate performance. It's hard to know whether that optimization technique REALLY helps unless you test it out. Using this tool can help you know what is effective, under what kinds of conditions. The GET RUN TIME has problems under multiple CPUs, so you should use it to test small pieces of your program, rather than the whole program.

Avoid 'SELECT *', especially in tables that have a lot of fields. Use SELECT A B C INTO instead, so that fields are only read if they are used. This can make a very big difference.Field-groups can be useful for multi-level sorting and displaying. However, they write their data to the system's paging space, rather than to memory (internal tables use memory). For this reason, field-groups are only appropriate for processing large lists (e.g. over 50,000 records).

If you have large lists, you should work with the systems administrator to decide the maximum amount of RAM your program should use, and from that, calculate how much space your lists will use. Then you can decide whether to write the data to memory or swap space. See the Fieldgroups ABAP example.


Use as many table keys as possible in the WHERE part of your select statements.

Whenever possible, design the program to access a relatively constant number of records (for instance, if you only access the transactions for one month, then there probably will be a reasonable range, like 1200-1800, for the number of transactions inputted within that month). Then use a SELECT A B C INTO TABLE ITAB statement.

Get a good idea of how many records you will be accessing. Log into your productive system, and use SE80 -> Dictionary Objects (press Edit), enter the table name you want to see, and press Display. Go To Utilities -> Table Contents to query the table contents and see the number of records. This is extremely useful in optimizing a program's memory allocation.Try to make the user interface such that the program gradually unfolds more information to the user, rather than giving a huge list of information all at once to the user.

Declare your internal tables using OCCURS NUM_RECS, where NUM_RECS is the number of records you expect to be accessing. If the number of records exceeds NUM_RECS, the data will be kept in swap space (not memory).

Use SELECT A B C INTO TABLE ITAB whenever possible. This will read all of the records into the itab in one operation, rather than repeated operations that result from a SELECT A B C INTO ITAB... ENDSELECT statement. Make sure that ITAB is declared with OCCURS NUM_RECS, where NUM_RECS is the number of records you expect to access.

Many tables contain totals fields (such as monthly expense totals). Use these avoid wasting resources by calculating a total that has already been calculated and stored.

Program Analysis Utility


To determine the usage of variables and subroutines within a program, you can use the ABAP utility called ‘Program Analysis’ included in transaction SE38. To do so, execute transaction SE38, enter your program name, then use the path Utilities ->

Program Analysis

ABAP PERFORMANCE IMPROVEMENTS VIA DATA DICTIONARY

INDEX CREATION SUGGESTIONS RELATED TO DATABASE PERFORMANCE
The columns at the beginning of an index are the most “common”. The most “common” columns are those where reports are selecting columns with no ranges - the where clause for these columns is an “equal to” expression. Rearrange columns of an index to match the selection criteria. For example, if a select statement is written to include columns 1 and 2 with “equal to” expressions in the where clause and column 3 and 4 are selected with value ranges, then the index should be created with columns in the sequence of 1,2,3,4.Columns towards the end of the index are either infrequently used in selects or are part of reporting selects that involve ranges of values.

TABLE TYPE SUGGESTIONS RELATED TO DATABASE PERFORMANCE

Use VIEW tables to effectively join and “denormalize” related tables that are taking large amounts of time to select for reporting. For example, at times where highly accessed tables normalize description text into one table and the header data into another table, it may make sense to create a view table that joins the relevant fields of the two associated with a poor performing ABAP.


For POOL tables that contain large amounts of data and are highly accessed, convert the pooled table into a transparent table and add an index. POOLED tables are supposed to be collections of smaller tables that are quickly accessed from the database or are completely buffered in memory.

Pooled tables containing more than a few hundred rows and are accessed many times in a report or transaction are candidates for POOL to TRANSPARENT Conversion. For example, table A053 contains tax jurisdiction condition information and are accessed more than ten times in the sales order create transaction.

If the entire United States tax codes are loaded into these condition tables, the time to save a sales order increases to unacceptable levels. Converting the tax condition table to transparent and creating an index based upon the key fields, decreases processing time from minutes to seconds.

Do not allow the use of LIKE in an SAP SQL statement accessing a large table.
Use internal tables in ABAPs to preselect values once and store values in memory for sorting and searching purposes (this is an assumption stated at the beginning of this discussion).


Avoid logical databases when not processing all row s of a table. In fact, a logical database is merely a group of nested SAP SQL SELECT statements. In general, when processing a small number of rows in a larger table is required, the use of internal tables and NOT using a logical database or nested selects will be much better for performance.

RELATED POSTS

EFFECTIVE CODING IN ABAP PART 2
EFFECTIVE CODING IN ABAP PART 1
CRM software solutions and mysap advantage