ALE

[Former Member]

I need the detailed steps for succesfully transfering the IDoC's using ALE.Rewarded fully if its detailed & Sucessful.

[Former Member]

Hi,

IDoc Definition:An intermediate document (IDoc) is a container for exchanging data between R/3, R/2 and non-SAP systems.

Use:

ALE uses IDoc to exchange data between logical systems. Non SAP-systems can use IDoc as the standard interface for data transfer. IDoc are created by message types and (object) methods when data is to be distributed.

Structure:

An IDoc represents a configuration of an IDoc type that determines the IDoc structure. An IDoc consists of a header, several data segments and status records.The functions of the individual elements of an IDoc are as follows:

The contents, structure, sender, receiver and current status of the IDoc are defined in the IDoc header.

Each data segment contains a standard header consisting of a sequential segment number, a description of the segment type and a 1000 character long string field containing the actual data of the segment. The status records show the history of the processing steps applied to the IDoc so far. The structure of the IDoc is recorded in the SAP System. The structure definition covers the

following: The segment sequence. Hierarchical relationships between segments are possible. The number of times a segment can occur is specified for each segment, as is whether the segment is a mandatory segment or an optional segment. The fields cont ained in a segment. In the example shown above the IDoc contains a header segment that has to be the first segment of the message.

Thereafter there must be at least one additional item. The following conditions apply:

Each item must be followed by at least one sub-item and at most 99

Up to 9999 text segments can appear after an item's sub-items (optional)

The last segment in a message must be an accumulation segment (ACCUM)

An IDoc can only contain character fields.

Modeling Distribution:

Purpose:

To implement the distribution of business application processes and functions using ALE you need to construct a logical Distribution Model of the whole system. Within the framework of this configuration customers can specify what applications are to run on what systems and what messages are to be exchanged between the applications .

Distribution Model:

Definition: The distribution model describes the ALE message flows between logical systems.

Use:

You can specify the relationships between logical systems, message types, BAPIs and filters inthe distribution model. Applications and the ALE layer use the model to determine the receivers and to control data distribution.

Structure:

In the distribution model you can specify the messages to be sent to a logical system. You can also define requirements for message content and dispatch in the Filters. The distribution model consists of one or more views that you can define. With more complex distribution tasks you can assign business sub-areas or groups of logical systems to separate views. To ensure correct functioning the relevant views of the distribution model must be available in all the logical systems involved in ALE. You can find the functions for distributing views in Customizing for ALE.

Creation of Custom IDOc type and message Type

First Create Partner Profile(WE20 Tcode) and Port Definition in WE19 Tcodes.

take the Basis help to create them.

1.First create segments in WE31 Tcode with the required dataelements

2.Create the Basic Idoc Type in WE30

release the Segments and IDOC type.

3.Create Message type in We81

4.Assign the message type to IDOC type in WE82 T code

5.Create the process code in We41 (for Outbound) WE42 (for Inbound)

6.Create A fun module in SE37 starting with ZIDOC_OUTPUT_.. by copying some Inbound (for Inbound) Outbound Fun module

7.Create Workflow setting if needed ..

8. Assign the fun module to Idoc Type, Message Type and WF object (if it is there)

9.Define setting for fun module in BD51

10.In BD51 Define the settings for Fun module..

10.Assign the Processs Code to Fun mod`ule

Outbound:

Step 1. Application document is created when transaction is saved.

2. Message control is invoked.

3. Messages are processed by system.

4. Messages are Edited (if desired).

5. Output (ALE / EDI) is checked

6. Validate against Message control record from Partner Profile

7. Application Document is saved.

8. Entry NAST table is created for every selected output program

along with Medium & Timing.

9. Check for Process Immediately .

If (yes)

Determine Processing Program from TNAPR Table.

ELSE

Execute RSNASTED Program.

10. Read Partner Profile to determine Process Code.

11. Process Code points to the Function Module & Invoked.

12. IDoc is generated.

13. Check for ALE Request.

if (Yes)

Perform Filters, Conversions, Version Changes etc.

Else.

IDoc is stored in DATABASE.

INBOUND:

Step 1. EDI Subsystem creates an IDoc file from EDI Messages

2. Subsystem calls Functional Module EDI_DATA_INCOMING from startRFC program.

3. Data in Control Record is validate against the Partner Profile.

4. IDoc is generated in Database and syntax check is carried out.

5. IDoc file is deleted once file read.

6. Event PROCESSSTATE REACHED is triggered in Idoc Object Workflow.

7. Check for Process Immediately.

If NO

Execute RBDAPP01 Program

Else

Read Process Code from Partner Profile

Process Code Points to Function Module

Application Document Posted.

ALE/ IDOC Links

http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm

http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc

http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419

http://www.netweaverguru.com/EDI/HTML/IDocBook.htm

http://www.sapgenie.com/sapedi/index.htm

http://www.sappoint.com/abap/ale.pdf

http://www.sappoint.com/abap/ale2.pdf

http://www.sapgenie.com/sapedi/idoc_abap.htm

http://help.sap.com/saphelp_erp2005/helpdata/en/0b/2a60bb507d11d18ee90000e8366fc2/frameset.htm

http://help.sap.com/saphelp_erp2005/helpdata/en/78/217da751ce11d189570000e829fbbd/frameset.htm

http://www.allsaplinks.com/idoc_sample.html

http://www.sappoint.com/abap.html

http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm

http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc

http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419

http://www.netweaverguru.com/EDI/HTML/IDocBook.htm

http://www.sapgenie.com/sapedi/index.htm

http://www.allsaplinks.com/idoc_sample.html

http://www.allsaplinks.com/idoc_sample.html

http://www.allsaplinks.com/

http://www.sap-img.com/

http://www.sappoint.com/abap.html

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCMIDALEIO/BCMIDALEIO.pdf

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCMIDALEPRO/BCMIDALEPRO.pdf

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/CABFAALEQS/CABFAALEQS.pdf

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCSRVEDISC/CAEDISCAP_STC.pdf

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCSRVEDI/CAEDI.pdf

http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm

http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc

http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419

http://www.netweaverguru.com/EDI/HTML/IDocBook.htm

http://www.sapgenie.com/sapedi/index.htm

http://expertanswercenter.techtarget.com/eac/knowledgebaseCategory/0,295197,sid63_tax296858_idx0_off...

http://sap.ittoolbox.com/documents/popular-q-and-a/extending-a-basic-idoc-type-2358

http://help.sap.com/saphelp_47x200/helpdata/en/dc/6b7eee43d711d1893e0000e8323c4f/frameset.htm

ALE/ IDOC/ XML

http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc

http://www.thespot4sap.com/Articles/SAP_XML_Business_Integration.asp

http://help.sap.com/saphelp_srm30/helpdata/en/72/0fe1385bed2815e10000000a114084/content.htm

Reward Points if useful

Regards

Aditya.

[Former Member]

Hi Chidambar,

IDoc Outbound Triggers

Last edited: 2000-04-26 18:17 +0200

IDocs should be sent out at certain events. This may be the change of data, periodically or at manual request. Therefore you have to define a trigger.

NAST Messages Based Outbound IDocs

One of the key tables in R/3 is the table NAST. This tables records message reminders written by applications. Every time an applications sees the necessity to pass information to a third party, usually a printed document. a record is written to NAST, which schedules the send of the message. The very same table is consequently also used by EDI, as an IDoc is only the paperless form of a printed document.

NAST messages are created by application NAST type IDocs are designed to be triggered by an output message, which is generated by an application. This is a standard functionality in most of the SAP core applications. Those applications - e.g. VA01, ME21 - perform calls to the function group V61B. The actual message is created with the function module MESSAGING by use of the customized condition technique.

NAST contains object key, sender and receiver Such an output message is stored as a single record in the table NAST. That record stores all information that is necessary to create an IDoc. This includes mainly an object key to identify the processed object and application to the message handler and the sender and receiver information.

Messages are processed by FORM einzelnachricht IN PROGRAM RSNAST00 The message reminders which are stored in table NAST, are processed by a FORM which is included in the standard ABAP RSNAST00. This routine interpretes the NAST record and decides how the output is generated. RSNAST00 is also designed as a stand-alone ABAP, which looks for unprocessed NAST messages in table NAST and processes them appropriately.

NAST is shared by SapScript and EDI The entries in NAST are not purely reserved for IDoc generated. Rather, the record stores reminders for any type of output, especially the print or facsimile output distribution. RSNAST00 decides which media is used and then calls the appropriate processing routine.

Programs are customized in table TNAPR The processing routine for the respective media and message is customized in the table TNAPR. This table records the name of a FORM routine which processes the message for the chosen media and the name of an ABAP where this FORM is found.

Workflow Based Outbound IDocs

Not every application is creating messages. This is especially true for those master data applications. However, most applications fire a workflow event during update. This workflow event can easily be used to trigger the IDoc distribution.

Workflow is called to a function module Many SAP R/3 applications issue a call to the function SWE_EVENT_CREATE during update. This function module ignites a simple workflow event. technically a workflow event is a timed call to a function module, which takes the issuing event as the key to process a subsequent action. Because the wokflow is actually a call to a function module, the event handler is nothing else than a function module with a well defined interface structure.

Applications with cvhange documents always trigger workflow events If an application writes regular change documents (Änderungsbelege) to the database, then it issues automatically a workflow event. This event is triggered from within the function CHANGEDOCUMENT_CLOSE. The change document workflow event is always triggered, independent of the case whether a change document is actually written.

Workflow coupling can be done by utility functions In order to make use of the workflow for IDoc processing, you do not have to go through the cumbersome workflow design procedure as it is described in the workflow documentation. SAP provides a couple of utility functions, which register all entries that you need to chain your handler in a workflow.

Workflow cannot easily be restarted Triggering the IDoc from a workflow event has a disadvantage: if the send of the IDoc fails, the event cannot be repeated. Therefore you have find an own way how to make sure that the IDoc is actually generated, even in the case of an error. Practically this is not a very big problem. In most cases the creation of the IDoc will always take place. If there is a problem then the IDoc would be stored in the IDoc base with a respective status, so it will show in transaction WE05.

Outbound IDocs Based On Change Pointers

In order to have a protocolled way to send out IDocs via the ALE mechanism, SAP invented the concept of change pointers, which allow another jumping board to distribute IDocs.

Change pointers are records of modified fields ALE change pointers are entries in a change pointer table, which are written every time an application changes one or more fields out of a predefined list of relevant fields. So, change pointers are only created, if certain customizable fields of an application change. This change pointers are written from within the change document update, namely the function CHANGEDOCUMENT_CLOSE.

Cahnge pointers are processed by a collector ABAP The ALE processing reads all change pointers and calls the appropriate function module to generate the IDocs.

( FORM ale_processing IN PROGRAM rsnasted )

Check out the below links for FULL INFORMATION on IDOCS:

HI,

check url

http://www.sappoint.com/abap/ale.pdf

http://www.sappoint.com/abap/ale2.pdf

http://www.sapgenie.com/ale/configuration.htm

http://www.sappoint.com/abap/ale.pdf

http://www.sappoint.com/abap/ale2.pdf

http://www.sapdevelopment.co.uk/training

And also u can get lots of inof from the below link.

http://www.sapgenie.com/ale/why_ale.htm

Check the following links:

http://www.sapbrainsonline.com/TUTORIALS/TECHNICAL/ALE_tutorial.html

http://www.sapmaterial.com/alematerial.html

http://www.sapbrainsonline.com/TUTORIALS/TECHNICAL/IDOC_tutorial.html

http://www.sapbrainsonline.com/TUTORIALS/TECHNICAL/user_exits_tutorial.html

http://www.sapmaterial.com/idoc_sample.html

http://www.sapmaterial.com/user_exit.html

Please check this online document for ALE and IDoc.

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCMIDALEIO/BCMIDALEIO.pdf

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCMIDALEPRO/BCMIDALEPRO.pdf

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/CABFAALEQS/CABFAALEQS.pdf

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCSRVEDISC/CAEDISCAP_STC.pdf

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCSRVEDI/CAEDI.pdf

Also check this links for additional information.

http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm

http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc

http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419

http://www.netweaverguru.com/EDI/HTML/IDocBook.htm

http://www.sapgenie.com/sapedi/index.htm

IDOCS

http://idocs.de/www5/books/IDocBook/IDOCS_CHAP09-11.pdf

http://idocs.de/cookbooks/idoc/cb12_idoc_20_outbound/idoc_outbound_45_rsnast00/docu.htm

IDOC / ALE Blogs

/people/raja.thangamani/blog/2007/07/19/troubleshooting-of-ale-process

/people/kevin.wilson2/blog/2006/11/13/ale-scenario-development-guide

Kindly Reward points if you found this reply helpful

,

Cheers,

Chaitanya.

[Former Member]

ALE (Application Linking and Enabling)

Ale Technology is SAP’s technology to support distributed yet integrated processes across several SAP systems.

Distributed Process:

A distributed process is one in which part of a business process is carried out on one system and part on another. The two systems would exchange data with each other at appropriate points to stay synchronized.

Need for Distributed Process:

• Business in Different Geographical Locations.

• Non availability of dedicated network.

• Cultural and language differences in Geographical locations.

• Running of Mission-critical Applications (Like Maintenance downtime etc.).

• Separate up gradation of Modules.

Distributed SAP SYSTEM – CHALLENGES

• A system that understands the syntax and semantics of the data. It was important from the very beginning to base the distribution of data on business rules, not on database replication techniques.

• Distributed systems that can maintain their autonomy while being integrated as one logical SAP system. The systems should be able to operate independently and support logical processing of transactions and data.

• Distributed systems that can handle different data models. A local implementation should be able to customize the system to meet its local needs.

• Receiving systems that can handle their own problems and not tie up the sending system.

• Systems that maintain continued operation in spite of network failure. Changes made to either system should be synchronized after the network connection is restored.

• A sound technology and methodology that can be used in all distribution scenarios.

SAP Distributed environment:

ALE allows for efficient and reliable communication between distributed processes across physically separate SAP systems.

ALE is based on application to application integration using messaging architecture. A message defines data that is exchanged between two processes. IDocs are containers that hold data exchanged between the two systems.

Benefits of ALE:

• Integration with non-SAP systems: ALE architecture allows third party applications to integrate with SAP system.

• Reliable Distribution: Once message type created and the receiver of the message is determined, ALE delivers the message to the recipient. If there is any network problem it will buffer the message and delivers the message once the network is restored. It also ensures that the message is not delivered twice.

• Release Upgrade: Any of the distributed system can be upgraded to the new release of SAP without affecting the functionality. The ALE layer ensures backward compatibility of messages exchanged between systems.

ALE Architecture:

It consists of an Outbound process, an Inbound process, and an Exception – Handling process.

Outbound Process:

ALE Outbound Process in SAP sends data to one or more SAP Systems. It involves four steps.

1. Identify the need of IDoc: This step starts upon creating a application document, can relate to a change to a master data object.

2. Generate the Master IDoc: The document or master data to be sent is read from the database and formatted into an IDoc format. This IDoc is called as a Master IDoc.

3. Generate the Communication IDoc: The ALE Service layer generates a separate IDoc from the Master IDoc for each recipient who is interested in the data. Separate IDocs are generated because each recipient might demand a different version or a subset of the Master IDoc. These recipient-specific IDocs are called Communication IDocs and are stored in the database.

4. Deliver the Communication IDoc: The IDoc is delivered to the recipients using an asynchronous communication method. This allows the sending system to continue its processing without having to wait for the destination system to receiver or process the IDoc.

Inbound Process:

The inbound process receives an IDoc and creates a document in the system.

1. Store the IDoc in the database: The IDoc is received from the sending system and stored in the database. Then the IDoc goes through a basic integrity check and syntax check.

2. Invoke the Posting Module: The control information in the IDoc and configuration tables are read to determine the posting program. The IDoc is then transferred to its posting program.

3. Create the Document: The posting program reads the IDoc data and then creates a document in the system. The results are logged in the IDoc.

Over view of IDocs:

IDoc is a container that is used to exchange data between any two processes. The document represented in an IDoc is independent of the complex structure SAP uses to store application data. This type of flexibility enables SAP to rearrange its internal structure without affecting the existing interface.

IDoc interface represents an IDoc Type or IDoc data. IDoc Type represents IDoc’s definition and IDoc Data is an instance of the IDoc Type.

IDoc Types:

IDoc type structure can consist of several segments, and each segment can consist of several data fields. The IDoc structure defines the syntax of the data by specifying a list of permitted segments and arrangement of the segments. Segments define a set of fields and their format.

An IDoc is an instance of an IDoc Type and consists of three types of records.

i. One Control record: each IDoc has only one control record. The control record contains all the control information about an IDoc, including the IDoc number, the sender and recipient information, and information such as the message type it represents and IDoc type. The control record structure is same for all IDocs.

ii. One or Many Data records: An IDoc can have multiple data records, as defined by the IDoc structure. Segments translate into data records, which store application data, such as purchase order header information and purchase order detail lines.

iii. One or Many Status records: An IDoc can have multiple status records. Status record helps to determine whether an IDoc has any error.

Message in IDoc Type:

A Message represents a specific type of document transmitted between two partners.

Basic Type:

Basic IDoc type defines the structure and format of the business document that is to be exchanged between two systems.

Segments:

Segments form the basic building blocks of an IDoc type and are used to store the actual datta. A segment type is the name of a segment and is independent of the SAP elease. A segment definition is the release-specific name of a segment.

Steps in creating Segments:

T.Code WE31

Enter the name for your segment type and click on the create icon.

Type the Short text.

Enter the variable names and data elements.

Save and Go back.

Go to Edit -> Set Release.

Repeat the steps to create more segments.

IDOC TYPE:

Business data is exchanged with an external system using the IDoc Interface.

IDoc types (Special Structures) An IDoc type is defined through its permitted segments. Segments can be dependent on each other (parent and child segments). The IDoc interface can check for each IDoc whether thhe segments contained are compatible with thhe definitiion of its type. This systax check is activated or deactivated in the Partner Profiles.

Steps in creating IDoc Type:

T.Code WE30 to create IDoc Type.

Enter the Object Name, Select Basic Type and click Create Icon

Select the create new option and enter a description for your basic IDOC type and press enter

Select the IDoc name and click Create icon

The system prompts us to enter a segment type and its attributes

Choose the appropriate values and press enter

The system transfers the name of the segment type to the IDoc editor.

Follow these steps to add more number of segments to Parent or as Parent-child relation.

Save it and go back.

Go to Edit -> Set Release.

Message Type:

Steps in Creating Message Type:

T.Code WE81.

change the details from Display mode to Change mode

After selection, the system will give this message "The table is cross client (See help for further info)". Press enter.

Click New Entries to create new Message Type.

Fill details

Save it and go back.

Assign Message Type to IDoc Type:

T.Code WE82

Change the details from Display mode to change mode.

After selection, the system will give this message "The table is cross client (See help for further info)". Press enter.

Click New Entries to create new Message Type.

Fill details

Save it and go back.

Reward points if useful.