cross applications

[Former Member]

higurus

Can anyone tellme detail anout ALE,iDocs and workflow?

thanks advance

[Former Member]

Hi

Refer below Url

<a href="http://www.insightcp.com/res_23.htm">SAP WORK FLOW</a>

<a href="http://www.thespot4sap.com/Articles/SAP_ALE_Introduction.asp">SAP Application Linking and Enabling</a>

IDoc (for intermediate document) is a standard data structure for electronic data interchange (EDI) between application programs written for the popular SAP business system or between an SAP application and an external program. IDocs serve as the vehicle for data transfer in SAP's Application Link Enabling (ALE) system. IDocs are used for asynchronous transactions: each IDoc generated exists as a self-contained text file that can then be transmitted to the requesting workstation without connecting to the central database. Another SAP mechanism, the Business Application Programming Interface (BAPI) is used for synchronous transactions.

A large enterprise's networked computing environment is likely to connect many geographically distributed computers to the main database. These computers are likely to use different hardware and/or operating system platforms. An IDoc encapsulates data so that it can be exchanged between different systems without conversion from one format to another.

IDoc types define different categories of data, such as purchase orders or invoices, which may then be broken down into more specific categories called message types. Greater specificity means that an IDoc type is capable of storing only the data required for a particular transaction, which increases efficiency and decreases resource demands.

An IDoc can be generated at any point in a transaction process. For example, during a shipping transaction process, an IDoc may be generated that includes the data fields required to print a shipping manifest. After a user performs an SAP transaction, one or more IDocs are generated in the sending database and passed to the ALE communication layer. The communication layer performs a Remote Function Call (RFC), using the port definition and RFC destination specified by the customer model. The IDoc is transmitted to the receiver, which may be an R/3, R/2, or some external system. [url=http://www.thespot4sap.com/Articles/SAP_ALE_IDOCS.asp]SAP IDOC[/url]

[Former Member]

ALE:--

The following steps need to be noted when configuring your ALE solution:

Confirm business requirements - Before commencing configuration ensure that you have the detail of the business requirements for the whole scope of the implementation.

Configure the ALE basis portion to enable ALE in the development environment. This involves the following steps:

Create Logical System (LS) for each applicable ALE-enabled client;

Link client to Logical System on the respective servers;

Create background user, to be used by ALE, on each client;

Create RFC destination for each destination client; and

Generate partner profiles for sending system. (Can only do this if at least 1 message type exists against the sending system's LS). This automatically generates the port if the LS and RFC name are the same.

Following the basis configuration is the functional configuration:

Create a Customer Distribution Model (CDM);

Add appropriate message types and filters to the CDM;

Generate outbound partner profiles;

Distribute the CDM to the receiving systems; and

Generate inbound partner profiles on each of the clients.

Keep your ALE configuration diagram up to date and follow change management procedures rigorously, as you begin to configure. Areas you need to document well include the finer details involved with an ALE implementation:

Listings / classes;

Object types \ Workflow tasks;

Conversion rules;

Filters & Segment filters;

Change pointers \ Fields activating change pointers;

Serialization;

Partner profiles: Immediate Vs Background;

Background job definition and scheduling;

Control data required to be in synch; and

...

Functional specifications need to be drawn up, by the business, describing exactly what is required by them, that is not available in the standard ALE scenarios.

A technical specification can then be drawn up by the ALE team. In this technical specifications the following needs to be addressed:

New IDocs required;

New fields added to existing IDocs;

Program \ user exits \ message control for populating the fields;

Inbound functional module details;

ALE configuration set up requirements; and

Error handling.

Once the specification is completed and confirmed by the business, programming can begin.

Developing an ALE scenario will include the following steps:

OUTBOUND:

Create Segments and IDoc type;

Create Message Type and link to IDoc type;

Populate IDoc using message control \ user exit or program (ABAP);

Distribute IDoc using MASTER_IDOC_DISTRIBUTE;

Create object type if required;

Define CDM with message type and filter object. Distribute model. Generate outbound partner profiles;

INBOUND:

Write inbound function module (FM) to process inbound IDoc (ABAP);

Create process code and link to FM;

Generate inbound partner profiles; and

Link object type to FM for error handling.

IDOC:-

An IDoc is made up of the following parts:

Control Record: This section contains control information regarding the Idoc. Its constituents are Sender’s name, Receiver name, Message type and Idoc type (illustrated in figure 3). The format of the control record is similar for all IDoc types.

Data Segment: It consists of a header that contains the identity of the Idoc. Its constituents include, a sequential segment number, a segment type description and field containing the actual data of the segment.

Status records: The status record shows the information regarding the already processed stages and remaining processing stages of the Idoc. It has an identical format for each IDoc type.

T code for Idoc

WE30 -- develope Idoc types

WE02 -- Idoc list

WE09 -- Idoc testing tool

Reward points if u helpful