Configuration

[Former Member]

Hi all,

How to I Configure ALE for Performance.

[Former Member]

Hi,

this can help u.

1.2. Mass processing

The number of IDocs that are to be created influences the settings made in the partner profiles for the various message types. The users need to give a clear indication of the volumes, frequency and timings of these bulk creations.

Various jobs need to be scheduled to process IDocs collected on the outbound side as well as to process them in the background on the inbound side. These settings will be defined in a separate document detailing the ALE performance tuning options and settings.

1.3. ALE performance

IDocs are fundamental to Application Link Enabling; optimal performance in ALE processing is synonymous with optimal performance of IDocs.

In ALE processing IDocs are:

• created in the R/3 sender system

• transferred to the communication layer in the R/3 sender system

• used when R/3 sender and receiver systems communicate.

• updated in the receiver system

You can optimise IDoc handling in one or more of the following ways:

• Controlling IDoc Events

• Processing IDocs in Parallel

• Packet Processing

• Managing IDoc Communication

2. ALE TECHNICAL DESCRIPTION

Below is a pictorial representation of the flow of a complete ALE scenario from the sending system to the receiving system.

In the output processing one of the function modules of the application creates an IDoc, the so-called master IDoc. This IDoc is sent to the ALE layer where the following processing steps are applied:

2.1. Outbound processing

2.1.1. Receiver determination

An IDoc is similar to a normal letter in that it has a sender and a receiver. If the receiver has not been explicitly identified by the application, then the ALE layer uses the customer distribution model to help determine the receivers for the message.

The ALE layer can find out from the model whether any distributed systems should receive the message and, if so, then how many. The result may be that one, several or no receivers at all are found.

For each of the distributed systems that have been ascertained to be receiver systems, the data that is specified by the filter objects in the customer distribution model is selected from the master IDoc. This data is then used to fill an IDoc, and the appropriate system is entered as receiver.

2.1.2. Data selection

2.1.3. Segment filtering

Individual segments can be deleted from the IDoc before dispatch by selecting Functions for the IDoc processing -> Settings for filtering in ALE Customising. The appropriate setting depends on the sending and receiving logical R/3 System.

2.1.4. Field conversion

Receiver-specific field conversions are defined under Functions for the IDoc processing -> Conversions.

General rules can be specified for field conversions; 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 2 character field to a 4 character field.

The conversion is done using general EIS conversion tools (Executive Information System).

2.1.5. Version change

SAP ensures that ALE functions between different R/3 System releases. By changing the IDoc format you can convert message types of different R/3 releases. SAP Development use the following rules when converting existing message types:

• Fields may be appended to a segment type;

• Segments can be added;

ALE Customising keeps a record of which version of each message type is in use for each receiver. The correct version of the communication IDoc is created in the ALE output.

The resulting IDocs (it is possible that several IDocs could be created in the receiver determination) are referred to as communication IDocs and are stored in the database. The dispatch control then decides which of these IDocs should be sent immediately. These are passed to the communications layer and are sent either using the transactional Remote Function Call (RFC) or via file interfaces (e.g. for EDI).

If an error occurs in the ALE layer, the IDoc containing the error is stored and a workflow is created. The ALE administrator can use this workflow to process the error.

2.2. Inbound processing

After an IDoc has been successfully transmitted to another system, inbound processing is carried out in the receiver system, involving the following steps in the ALE layer:

2.2.1. Segment filtering

Segment filtering functions the same way in inbound processing as in outbound processing.

2.2.2. Field conversion

Specific field conversions are defined in ALE Customising.

The conversion itself is performed using general conversion tools from the EIS area (Executive Information System).

Generalised rules can be defined. The ALE implementation guide describes how the conversion rules can be specified.

One set of rules is created for each IDoc segment and rules are defined for each segment field.

The rules for converting data fields from an R/2-specific format to an R/3 format can be defined in this way. An example of this R/2 - R/3 conversion is the conversion of the plant field from a 2 character field to a 4 character field.

2.2.3. Data transfer to the application

2.2.4. Input control

When the IDocs have been written to the database, they can be imported by the receiver application.

IDocs can be passed to the application either immediately on arrival or can follow in batch.

You can post an inbound IDoc in three ways:

1. by calling a function module directly:

• A function is called that imports the IDoc directly. An error workflow will be started only if an error occurs.

2. by starting a SAP Business Workflow. A workflow is the sequence of steps to post an IDoc.

3. by starting a work item

• A single step performs the IDoc posting.

The standard inbound processing setting is that ALE calls a function module directly. For information about SAP Business Workflow alternatives refer to the online help for ALE programming.

You can specify the people to be notified for handling IDoc processing errors.

3. PROCEDURE TO CHANGE SETTINGS

3.1. Mass processing

• Mass processing refers to bundles of IDoc packets, which are dispatched and processed by the receiving R/3 System. Only one RFC call is needed to transfer several IDocs. Performance is considerably better when transferring optimal packet sizes.

To define a mass processing parameter, select Communication -> Manual maintenance of partner profile -> Maintain partner profile. For a message type the parameters packet size and output mode can be defined.

If the output mode is set to "Collect IDocs", outbound IDocs of the same message type and receiver are sent in a scheduled background job or in the BALE transaction in appropriately sized IDoc packets. The IDocs can be dispatched in batch or in the BALE transaction code.

Some distribution scenarios cannot support mass processing of inbound IDoc packets. This is especially true if the application sending the IDocs uses the ABAP/4 command CALL TRANSACTION USING. In this case the outbound parameter PACKETSIZE must be set to "1".

To get a list of function modules that can be mass processed, select Enhancements -> Inbound -> specify inbound module in ALE Customising. INPUTTYP is "0".

• The option of performing mass processing is provided for reasons of performance. This involves sending packets consisting of several IDocs to an application workflow.

The IDoc packets are put together using collective processing in the output processing before dispatch takes place. Each packet contains IDocs of a single message type intended for a single recipient.

These IDocs are then all communicated in a single step.

There are some scenarios that cannot deal with mass processing of incoming documents. This is always the case if the application that imports the data has to execute a batch input.

In such a case the packet size has to be set to 1 in the output processing.

3.2. Schedule IDoc dispatch

Some IDocs are not sent immediately, but are collected and then sent all together. The report RSEOUT00 must be scheduled in order that these IDocs can be sent.

The following steps are necessary for this:

• Define variants for the report.

• Schedule jobs, each with the report and a variant as the step.

Further notes

Numbers are assigned internally for IDocs which have been sent. Number ranges have to be maintained for this purpose. You do this under menu entry Basic settings -> Maintain number ranges for IDocs.

3.2.1. Define variant (SE38) Client Independent

In this section, variants are defined for the report RSEOUT00.

3.2.1.1. Procedure

1. You can maintain different values for sending:

• port,

• partner type, partner role

• partner number,

• message type.

2. SAP recommends variants with partner number and message type.

3. Create corresponding variants for the report RSEOUT00.

4. To do this, execute the transaction SE38 and enter "RSEOUT00", click on Variants and choose Change.

5. Enter a name for the variant and choose Create.

6. Enter the message type (for example, MATMAS).

7. Maintain the attributes for the variant.

8. Save the variant.

9. Repeat the process until variants have been created for all message types.

3.2.2. Schedule Job (SM36) Client Independent

The jobs for each message type are scheduled in this step.

Requirements

Variants for each message types must be maintained.

3.2.2.1. Procedure

1. Define a job with the step RSEOUT00 and a variant which you have maintained.

2. Schedule the job as a periodic job, where the period must be adapted to your requirements (for example, hourly, daily, and so on).

3. Save the job.

4. Create a job for every variant defined beforehand.

3.3. Schedule IDoc processing

Jobs for inbound processing are scheduled in this section. These jobs must be scheduled for the following situations:

• Processing the IDocs that are not imported immediately on arrival, but periodically in the background (settings in partner profile). Use Report RBDAPP01.

• Importing IDocs that are stored in the system, but which were not transferred to the application due to exceptional situations. (Report RBDMANIN). With selected parameters you can also schedule a job to collect IDocs that have not yet been processed, for instance, because of a locking problem.

To do this, the following settings are necessary:

• Define variants for a report.

• Schedule jobs, with the report and a variant as the step.

Further notes

The report RBDMANIN allows intermediate documents which have already been cancelled once with errors (e.g. Status: 51 error in transfer to application) to be read into the application again. It is also possible to schedule a job with selected parameters, in order to collect up intermediate documents which could not be processed, e.g. because of a locking problem.

Numbers are assigned internally for intermediate documents which have been sent. Number ranges have to be maintained for this purpose. You do this under menu entry Number ranges -> Maintain number ranges for intermediate documents.

3.3.1. Define variant (SE38) Client Independent

In this step you create variants for report RBDAPP01 or for report RBDMANIN.

3.3.1.1. Procedure

1. Define variants with the following values or a subset:

• logical message type

• message variant

• message function

• partner type of the sender

• partner number of the sender

• partner role of the sender

2. SAP recommends the definition of variants with the logical message type and the partner number. However, which IDocs are imported and how frequently depends on your requirements.

3. For all partner and message types for which no immediate processing is carried out you must create a variant of the report RBDAPP01.

4. SAP recommends that you define a variant without values in order to enter the remaining IDocs.

3.3.2. Schedule Job (SM36) Client Independent

Requirements

Variants must be maintained for each message type.

3.3.2.1. Procedure

1. Define a job with the step RBDAPP01 or RBDMANIN and a variant maintained by you.

2. Schedule the job as a periodic job where the period must be adapted to your requirements (for example, hourly, daily, and so on).

3. Save the job.

4. Create a job for every variant defined beforehand.

5. Create a job with the variant without values to import the IDocs that were not transferred to the application due to exceptional situations.

6. This job must have a period which is larger than the maximum period of the other jobs.