communication idco-masteridoc?

[Former Member]

communication idco-masteridoc whats d difference?

and in our lab we have single sapuser..

when one of my freind want run ale ..im unabel to run ale y this happening?

[Former Member]

Hi,

Communication idoc

An IDoc contains the business data in the format required for ALE to operate. It consists of segment types, where each segment type holds the required fields for that segment. There are 2 types of IDocs we deal with:

• Basic IDoc: This IDoc is used internally by the function modules creating the IDoc to establish the data that is required for distribution. A basic IDoc is created per business object. E.g. Per material master record.

• Communication IDoc: For each basic IDoc that is created on the sending system the relevant number of communication IDocs are created based on the customer model and how many systems are to receive this IDoc. This is then the IDoc that is sent to the receiving systems and can be viewed by transaction WE05.

Conversion rules

These are used to convert the field contents of a sender field for use in a receiver field. This allows conversions of organisational units, of units of measurement and customer-specific conversions from one system to another to be performed.

Customer distribution model (CDM)

The customer distribution model specifies which applications can communicate with each other in your distributed systems. The customer distribution model contains all the cross-system message flows in your company.

Filter object type

A filter object type is a selection criterion in the distribution reference model that specifies the criteria that determine whether a function type can be used several times in a distributed system. EG. Use it to specify the logical systems that are to receive a message (GLMAST) by stating the company code BUKRS as a filter object with 2000 as the value. This implies that only GL master records with 2000 as the company code will be distributed to the logical system with BUKRS = 2000 set as a filter object of GLMAST in the distribution model.

Function module

Function modules are external subroutines that are stored centrally in the Function Library and can be called from any ABAP/4 program.

In contrast to normal subroutines, function modules have a uniquely defined interface.

IDoc outbound processing

Usage of programs and subprograms which control the processing of application data up to the point of transferral as an IDoc to the ALE communication layer.

IDoc type

The IDoc type indicates the SAP format that is to be used to interpret the data of a business transaction.

An IDoc type consists of the following components:

• a control record

This is identical for each IDoc type.

• several data records

One data record consists of a fixed key part and a variable data part. The data part is interpreted using segments, which differ depending on the IDoc type selected.

• several status records

These are identical for each IDoc type and describe the statuses an IDoc has already passed through or the status an IDoc has attained.

Listings

Listings are used in master data management when distribution rules cannot be modelled using organisational units only. Listings exist for material, customer and vendor master data.

For each object type a (customer-defined) class type can be specified as ALE-relevant. All classes belonging to this class type can be used in the listings.

Since listings are used as classifications, they are maintained in the master data transactions. A master data object can be added to a list by classifying it.

The listing groups together all the objects belonging to a single class, and this class belongs to the ALE class type for the object.

Logical system

A system on which applications integrated on a common data basis run.

In SAP terms, this is a client in a database.

Messages are exchanged between the logical systems.

Message type

The messages exchanged between systems are of various message types. The message type depends on the data contained and the process involved. It determines the technical structure of the message, the IDoc type. For example, the FIDCMT message type is used for journal messages.

Partner profile

Definition of parameters for the message exchange of data with an ALE enabled partner via the ALE interface.

Port

Logical description of the system that communicates with the SAP System during ALE message interchange.

In the case of outbound processing, this system receives the Intermediate Documents, processes them, and sends status records. In the case of inbound processing, it sends the Intermediate Documents to the SAP System, which then forwards them to the respective application.

Reference Client

The reference client refers to the client that is used as the master data repository for that data that is to be distributed. I.E. If you are going to distribute the material master to 2 production systems then the reference client is that client which holds the material master data that was loaded directly by the user. The 2 production clients will receive the data via ALE and are referred to as destination clients. We suggest you separate the reference client from the production clients.

Remote function call (RFC)

RFCs allow you to call and process predefined procedures (functions) in a remote SAP System.

RFCs manage communication control, parameter transfer and error handling.

SerialiSation

If several IDocs are sent within a short period of time then "overtaking" can occur, so that later changes arrive sooner than changes that were actually made earlier. In order to avoid incorrect updates being made, a serialisation mechanism must be used that can spot "overtaking" and report it.

Master IDoc.

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:

Outbound processing

This area describes how ALE is used to process a transaction from the sending system to the communication layer. The inbound processing will show how ALE is used to take an IDoc from the communication layer to the receiving system and post it.

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:

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.

Data selection

Segment filtering

In ALE Customising, segments can be specified for each recipient that should not generally be sent to that recipient. This information is used at this point to filter out those segments. The appropriate setting depends on the sending and receiving logical R/3 System.

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).

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.

Dispatch control

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).

Controlling the time of dispatch:

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

• If the IDoc is to be dispatched in the background, a batch job has to be scheduled. The dispatch cycle may be chosen at will (daily, weekly, etc.)

Controlling the amount of data sent:

• The packet size can be defined. The packet size is the number of IDocs that are sent in a single operation.

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.

Regards

Sreeni

[Former Member]

Thank u srinivas gaaru!

Happy Holi! Enjoy...keep smiling and answering my queries toooo.

bye

Mr.Reddy.