ALE audit in IDOC

In respect of ALE Audit in IDOC
1. All IDOC receivers send Acknowledgement.
2. All IDOC senders expect an Acknowledgement
3. Receiver communication channel is required for ALE Audit
4. Sender communication channel is required for ALE Audit
I believe 1 and 3 correct. Please confirm me.
thanks
kumar

Kumar,
I think 3 is correct , 1 & 2 also correct but based on condition, please see below.
 3 -sure
2 - Please refer the below doc ,Page 1
fyr :In general, acknowledgments have to be requested explicitly by the sender. However, this does not apply to IDocs. The following acknowledgments are sent back by default, unless the corresponding message type is maintained in an exception table.
1 - Please refer the below doc Page 1
fyr :IDocs only return acknowledgments if the receiver is configured for using ALE audit.
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/f6d2d790-0201-0010-9382-b50b499b3fbe
Please correct me if i 'm wrong!!!
Best regards,
raj.

Similar Messages

Problem while sending back ALE audit Idoc

Hi,
I have a scenario in which an idoc is send from R/3 system to file service using XI. Here we have used BPM, in which Integraion process is the receiver of the idoc and then it is send to file system using file adapter. All the business services and Integration processess are created under Party. We expect XI would send implicit ALE audit Idocs to sender R/3 system.
I have created a communication channel pointing to sender R/3 system. After maintaining everything also it is throwing an error saying that unable to convert sender service to an idoc partner or ALE logical system.
Please help me in resolving this issue.
Thanks,
Vijay Kumar T.

Hi,
I have maintained adapter specific parameters for my integration process and those parameters are corresponding to sender business system parameters. As i told, i am using party and corresponding identifiers. My idoc is coming and successfully transmitted to file system but only problem is with acknowledgement that need to reach sender R/3 system.
Thanks,
Vijay Kumar T.

Setup of ALE Audit in SAP Receiver System

Hello,
for a scenario JDBC -> XI -> IDoc, I have to setup ALE Audit in the receiver SAP sytem.
I have followed the steps in the How-To-Guide (Handle acknowledgements for IDocs):
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/f6d2d790-0201-0010-9382-b50b499b3fbe
However I just want to have acknowledgements sent back to SAP XI for a specific type of IDoc (source coming from the database) and not all received IDocs as there are different sender systems sending IDocs (some of them via XI some of them directly).
Is there a way to configure ALE Audit in a way ALEAUDITs are sent just for specific sender systems / IDoc types. I want to avoid that the SAP XI system receives ALEAUDIT for all inbound IDocs.

Hey,
This document describe how the handle audit the the sender and the receiver systems are SAP system, when one of the sides (sender/receiver) is not SAP system,
than the configuration become much more complex.
As of XI SP18, there are ways to control ALEAUD,
for more information, read:
http://help.sap.com/saphelp_nw04/helpdata/en/42/c8f66bc7a56bb0e10000000a1553f6/frameset.htm
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/oss_notes/sdn_oss_bc_xi/~form/handler%7b5f4150503d3030323030363832353030303030303031393732265f4556454e543d444953504c4159265f4e4e554d3d393634373435%7d
/people/saravanakumar.kuppusamy2/blog/2005/01/20/configuration-tips-for-a-business-serviceintegration-process-to-send-back-ale-audit-idoc

ALE Audit

Hi All,
Please give me ur inputs on this scenario:
Scenario: FileXI- ECC - Data from File is converted to various IDocs and posted in SAP. (No BPM used)
Problem: Exception Handling > > We want a message back from SAP system telling us that out of 100 IDocs that were sent, n were posted successfully and rest failed along with the error description. How can this be achieved?
Possible Solution 1: Along with the IDocs a proxy is also sent to the SAP from XI. Proxy has a wait time and collects following information:
No: of IDocs posted successfully,
No of IDocs Failed and there reason.
And then an email has to be sent using Alert Message to the process head with the above information.
Possible Solution 2: ALE AUDIT is used on the receiver SAP system and the error messages are sent to XI and the messages are collected in another interface in XI and subsequent Alert Management is used to shoot email.
Which solution is better and why?
Regards,
XIer

Hey
>>Problem: Exception Handling > > We want a message back from SAP system telling us that out of 100 IDocs that were sent, n were posted successfully and rest failed along with the error description. How can this be achieved?
For this you need to use BPM coz File can't handle sync calls.
As far as i know,in both the cases you need to use BPM.
Note:ALEAUDIT is mainly used in a IDOC to IDOC scenario or IDOC to File scenario
Thanx
Ahmad

ALE Audit - ALE logical system

Dear all,
we encounter an issue with an integration workflow that sends an ALE audit back to the R/3 system (Scenario:
R/3 -IDOC-> |XI-BPE| -HTTP->Partner)
Everything works fine except the ALE audit from the process to the R/3 System.
In the receiver agreement we use a header mapping to map the Sender.
Is there any difference between usual IDOC posting (for which our config works of course) and ALE Audit IDOCs?
Thanks in advance,
Helge

Hi Helge,
if you're using BPM in the XI
this is what you could to:
create a new processing code for inbound aleaudits
and change a little the standard function module
for inbound ale audits (the only change
would be a table in which you'd map
BPM names to just on partner profile)
this way if you'd be using a new BPM
you will only have to add one record to the table
and the processing will always be done correctly
with just one partner profile
Regards,
michal
<a href="/people/michal.krawczyk2/blog/2005/06/28/xipi-faq-frequently-asked-questions">XI FAQ - Frequently Asked Questions</a>

Maintaining distribution model for ALE audit.

hi,
I have to create a bcakground job in the receiver system to periodically send back the audit data to the sender system. To do the same i need to maintain a distribution model for ALe audit. For doing so i don't have the modal view XIDEMO in BD64. How to implement. Also in SM59 while maintaing RFC destination it says U6D_700 no longer exists. Please suggest how to get it resolved.
Regards
Akash SInha
Edited by: Akash Sinha on Dec 16, 2009 9:59 AM

Hello,
You can create your own model view in BD64. In the model view add message type ALEAUD with sender as your system name and logical system of your reciever.
Also configure the Partner profile in WE20, with outbound parameter ALEAUD and IDoc Type ALEAUD01.
Schedule the program RBDSTATE with the required parameters.
BR/Yogesh

Ale audit steps

Hi,
Can anybody please explain ale audit steps.
1. i am sending idocs from send1 rece1. how i can i know the status of outbound idocs using ale audit
i want to know the process behinds this.

Hi Sudhakar..
ALE Audit Steps:
In the Sender system:
1. In the Model view (BD64) : Add the Message type ALEAUD
Note: Sender and Receiver has to be reverse..
Distribute the Model view to the Receiver system.
2. Audit data can be confirmed periodically back to the sending system, you have to use the program RBDSTATE to specify a variant and schedule a background job in the receiving system
Reward if Helpful

Setting up ALE AUDIT between XI and R#.

Hi Experts ,
I have a scenerio here. I know most of you will be asking me to google and search SDN blogs for the same , but let me tell you , I have already gone through most of them , specially the HOW TO manuals.
Mine is a R3 to XI to Web scenerio.
Initial rquirement is, R3 will trigger a delivery Idoc, and, if it reaches XI and failes in mapping do to any reason , it will trigger back to R3 the ALE AUDIT idoc. I have gone through the documents, but I cant make out how to I connect the failure of mapping of the specific idoc information , and tigger the ALE AUDIT idoc back to R3.
Can any one help me out with the scenerio, I just am unable to visualise the scenerio.
I have medium level experience in ALE idoc settings .
Regards,
Arnab.

There is no standard way to send ALE IDOC back to SAP R3 if mapping fails in middleware.
But this can be handled through BPM.I am not sure if you are from XI background or R3 background
The BPM design looks like this,
Receive( IDOCs from R3 ) -
> Block step ( Inside block Mapping-> If mapping success>.Send to Target application
If mapping Fails(System Error)>Mapping (MAP ALE IDOC with respective details)->Send IDOC to R3 system.
Hope thsi helps

Executing RBDSTATE for ALE-Audit Processing

Hi Experts,
when I execute RBDSTATE into my Z_Function for BOMMAT Inbound Processing, it doesn't find any IDoc for the ALE-Audit Processing :
"No data relevant to audit were selected."
Any idea ?
Regards,
David

Hi Gordon,
I've decided to create another Distribution Model, only for ALEAUD (why ? I don't know...).
Now the IDoc ALEAUD is created into the Target System, but with Status is 02 "Could not find code page for receiving system".
Regards,
David

Doubt regarding ALE SETTINGS in IDOC scenario.

Hi Friends,
        I have some doubts regarding ALE settings for IDOC scenarios, can anyone please clarify my doubts.
For exmaple take IDOC to FILE scenario
The knowledge i got from SDN is --
One need to do at the R3 side is --- RFC DESTINATION (SM59) for the XI system.
                                                   --- TRFC PORT for sending IDOC to the XI system
                                                   --- CREATING LOGICAL SYSTEM
                                                   --- CREATING PARTNER PROFILE
               at the XI side is --- RFC Destination ( For SAP sender system)
                                       --- CREATING PORT for receiving IDOC from the SAP sending system(IDX1).
1. Do we create two logical systems for both Sender ( R3 system ) and Receiver( XI system ) in R3 system itself or in XI system or in both systems we create these logical systems? Is this a mandatory step in doing ALE configurations?
In IDOC to IDOC scenario-------
2. Do we craete two RFC destinations in XI system? One RFC DESTINATION for the Sender R3 system and another RFC DESTINATION for the Receiver R3 System? and do we create RFC DESTINATION for the XI system in receiver R3 system? If not.....y we don't create like this........Please give me some clarity on this.............
3. If we use IDOC adapter ,since IDOC adapter resides on the ABAP STACK ,we don't need sender communication channel ,for the similar reason----
y we r creating receiver communication channel in the case of FILE to IDOC scenario?
4. Can any one please provide me the ALE settings for IDOC to FILE scenario,
                                                                                FILE to IDOC scenario,
IDOC to IDOC scenario individually.
Thanks in advance.
Regards,
Ramana.

hi,
1. Yes, we create two logical systems for both Sender ( R3 system ) and Receiver( XI system ) in R3 system itself and
it is a mandatory step in doing ALE configurations
2. We create 1 RFC destination each in R3 and XI.
    R3 RFC destination points to Xi and
    XI RFC destination points to R3
3 We need to create Communication Channel for Idoc receiver as the receiver channel is always required but sender may not be necessary
4. ALE settings for all IDOC scenarios are same as follows....
Steps for ALE settings:-
Steps for XI
Step 1)
     Goto SM59.
     Create new RFC destination of type 3(Abap connection).
     Give a suitable name and description.
     Give the Ip address of the R3 system.
     Give the system number.
     Give the gateway host name and gateway service (3300 + system number).
     Go to the logon security tab.
     Give the lang, client, username and password.
     Test connection and remote logon.
Step 2)
     Goto IDX1.
     Create a new port.
     Give the port name.
     Give the client number for the R3 system.
     Select the created Rfc Destination.
Step 3)
     Goto IDX2
     Create a new Meta data.
     Give the Idoc type.
     Select the created port.
Steps for R3.
Step 1)
     Goto SM59.
     Create new RFC destination of type 3(Abap connection).
     Give a suitable name and description.
     Give the Ip address of the XI system.
     Give the system number.
     Give the gateway host name and gateway service (3300 + system number).
     Go to the logon security tab.
     Give the lang, client, username and password.
     Test connection and remote logon.
Step 2)
     Goto WE21.
     Create a port under transactional RFC.(R3->XI)
     Designate the RFC destination created in prev step.
Step 3)
     Goto SALE.
     Basic settings->Logical Systems->Define logical system.
     Create two logical systems(one for XI and the other for R3)
     Basic settings->Logical Systems->Assign logical system.
     Assign the R3 logical system to respective client.
Step 4)
     Goto WE20.
     Partner type LS.
     Create two partner profile(one for XI the other for R3).
     Give the outbound or inbound message type based on the direction.
Step 5)
     Goto WE19
     Give the basic type and execute.
     fill in the required fields.
     Goto IDOC->edit control records.
     Give the following values.(Receiver port,partner no.,part type and sender Partner no. and type)
     Click outbound processing.
Step 6)
     Go to SM58
     if there are any messages then there is some error in execution.
     Goto WE02.
     Check the status of the IDOC.
     Goto WE47.
     TO decode the status code.
Step 7)
     Not mandatory.
     Goto BD64.
     Click on Create model view.
     Add message type.
BD87 to check the status of IDOC.
In case if not authorized then go to the target system and check in SU53, see for the missing object
and assign it to the user.
SAP r3
sm59(status check)(no message)
WE02(status check)
WE05(status check)
BD87(status check)
Xi
IDx5(Idoc check)
SU53(authorization check)
Reward points if helpful
Prashant

ALE Audit System

Does ALE audit system work between a non-sap sending system and SAP as receiving system. If yes, then how is the "audit table" and "audit analysis program" step taken care of?

Hi Helge,
if you're using BPM in the XI
this is what you could to:
create a new processing code for inbound aleaudits
and change a little the standard function module
for inbound ale audits (the only change
would be a table in which you'd map
BPM names to just on partner profile)
this way if you'd be using a new BPM
you will only have to add one record to the table
and the processing will always be done correctly
with just one partner profile
Regards,
michal
<a href="/people/michal.krawczyk2/blog/2005/06/28/xipi-faq-frequently-asked-questions">XI FAQ - Frequently Asked Questions</a>

ALE, EDI and IDOCS

Hi
I am learning some stuff on ALE,EDI and IDOCS... are there any good sites which gives clear step by step procedure for the above.
Thanks in Advance.
Sudhi

Hi Sudhi
You can find details on SAP courses from your country's sap.com site. You can find links from http://www.sap.com/contactsap/countries/index.aspx .
Also some Education Partners of SAP give courses. Some info about these will also be there...
Regards...
*--Serdar

ALE , EDI and IDOC with MM??

hii
What is ALE, EDI and IDOC in SAP??
How its linked with MM??
Explain the above things with example
Thanks

Hi!
IDOC = Intermediate Document
IDoc or Intermediate Document is a standard SAP document format. IDoc's allow different application systems to be linked via a message-based interface.
For more detailled information look in SAPNET under
http://service.sap.com/EDI
For exapmle in purchasing:
The IDoc message type ORDERS is used to send a purchase order to a vendor.
EDI = Electronic Data Interchange
EDI stands for Electronic Data Interchange, which means that data is electronically transmitted from one system to another. The main requirement of EDI is that the systems of the communicating partners understand each other. Usually, the data from one partner gets mapped into the format of the other partner and vice versa.
Supporting this there exist EDI standards (named EDIFACT, ANSIX12, ODETTE, VDA, TRADACOMS, SPEC2000, ...), where the data formatting for exchanging documents are specified. Normally the partners agree using a special standard message (for example EDIFACT message ORDERS for a purchase order).
In the SAP system the outgoing data are stored in IDoc format. When processing a receiving document, the Inbound SAP system receives the data in IDoc format too.
Further processing (converting/mapping from IDoc in another format and vice versa) depends on the partner agreement:
If the partners have agreed using a special EDI standard, mapping between IDoc and the EDI standard is necessary. This mapping is not supported by SAP, external converters or EDI subsystems must be installed by the customers for this purpose.
If both systems use SAP software, there is usually no need for mapping (which can save users a lot of money). The two systems are often connected via ALE (Application Link Enabling).
If partners are using XML, the SAP Business Connector can be used. The business connector is a tool used to help customers connect via EDI. It includes routing and mapping and is XML compatible. To read more about XML at SAP go to SAPNet Alias 'XML' (http://intranet.sap.com/XML).
For example:
Vendor can send the invoice by EDI creating an IDoc with message type INVOIC using IDoc Type INVOICxx. He can determine (depending on the partner agreement) how to create an IDoc for Inbound processing with FI or MM-IV.
ALE = Application Link Enabling
ALE is short for Application Link Enabling. Special Basic programs support this functionaliity (see documentation of BC_MID_ALE).
To link applications you have to configure an ALE model. It contains all relevant data about how a system's configuration (normally a central system and assigned local systems) exchange data.
With help of the ALE technology, the distribution of contracts is possible in MM via the following business process:
Contracts that a central purchasing organization distributes to local purchasing organizations to allow the latter to utilize the more favorable conditions they contain for the procurement of materials or external services.Each local purchasing organization sends information on its own release orders back to the central purchasing organization.
For this purpose the contract in the central system can be copied to the local systems (with message BLAORD and COND_A). When a release order to a distributed contract is created in a local system, the release docu is automatically sent to the central system (with message BLAREL) updating the release docu of the contract in the central system.
Precondition for this scenario is, that in all systems the used master data (material, vendor, sources of supply, ...) are the same. This master data can be distributed by ALE, which should be done before sending the contract from the central system. Available message types for distribution of master data are:
MATMAS (ARTMAS in retail system) for material master
CREMAS for Vendor master
INFREC for info record
SRCLST for source list
COND_A for conditions of info record
SRVMAS for service master data
Technical documentation to ALE can be found by path:
Basis Components / Middleware (BC-MID) / Application Link Enabling (BC-MID-ALE)
The most important Transactions for testing Idoc:
WE02 Display IDOC
WE05 IDOC list
WE19 Testing IDOCs
BD87 Status Monitor for ALE Messages (reprocess)
Notes:
456127 FAQ: Electronic Data Interchange (EDI) in Purchasing
536411 Sample scenario for ALE contract distribution (only internally released)
I hope I could help you fruther
Best regards
Erika

Relation of ALE , EDI and idoc

HI
     what is relation of these ALE, EDI, IDOC , i know the definition of these , i want know ( while the transfer of sap to sap ALE tool is used ,) where this idoc is used ,
regards
shivaji

Hi Shivaji,
What is EDI?
Electronic Data Interchange
     The computer-to-computer electronic exchange of machine processable business documents in a standard format
     An electronic alternative to paper, fax, and phone-based transactions used by companies to communicate with one another
Purpose:
     Allows for better time management and relieves the entering of duplicate information while cutting down on discrepancies and human intervention.
     The Electronic Data Interchange component in Sales and Distribution consists of an Intermediate Document (IDoc) [Ext.] interface. You can use this interface to
     send messages (outbound processing) such as an order confirmation through Electronic Data Interchange (EDI)
     receive messages (inbound processing) such as a sales order through EDI
EDI:
     What?
     The technology of transmitting documents electronically
     Why?
     For Electronic Data Interchange between a company and trading partners
     How?
     By means of an electronic document - the IDoc
From the SAP side, the EDI interface is based on IDoc technology, which is independent of
EDI standards. All data is transferred in files between the R/3 System and the EDI subsystem.
Synchronous Remote Function Call (RFC) is implemented to define the time of transfer for a
file between the two systems. The following data can be transferred using the EDI interface:
Outbound Idocs: IDocs are transferred from the R/3 System to the EDI subsystem.
Inbound Idocs: IDocs are transferred from the EDI subsystem to the R/3 System.
Status report: The EDI subsystem sends a status report to the R/3 System on the progress of
the processing of the outbound Idoc.
Contents of IDOC
The data in every IDoc is exchanged between the SAP system and a subsystem in the following three record types, irrespective of the IDoc type:
     Control record (Table: EDIDC): Contains information about Sender and Receiver. There is only one control record per IDoc. It consists of
IDoc Number
Sender and Receiver information
IDoc Message Type* / Port.
IDoc Type / Direction / Current status / Partner No / Partner Type (Vendor/customer)
     Data record (Table: EDIDD): Contains the message to be exchanged between Sender and Receiver. An IDoc can contain multiple data records, as defined by the IDoc structure. Data records store application data such as purchase order / sales order header information, sales order details like sales doc #, Material / Qty and other relevant information.
     Status record (Table: EDIDS): Contains Status of IDoc at various stages, during the transmission of IDoc between Sender and Receiver. Multiple status records are usually attached to an IDoc. Status records are attached to an IDoc throughout the process like status code, date and time at every stage
Know Me
Basic Type: The form of IDOC type that is originally created in the system. Like ORDERS01 is a basic type IDOC for order messages. It is using the basic types only you would be able to enhance them to suit new requirements within the same IDOC structure. Any enhancement to the basic type IDOC will produce an Extension IDOC that would be more or less similar to the basic type with some new additions (of segments or fields). Here, I would go on to say that IDOC type and Basic type is the same thing that would be referred to interchangeably.
Message type: Again, obvious from the name, its the message that is being conveyed. A message type is assigned to the Basic type. Here, logical messages are assigned to the basic type to reflect a business message being transacted. For example, ORDERS is the message type for a purchase order sent by buyer to vendor. The use of which Basic type in this message will differ from buyer to vendor. Basic types used for ORDERS are ORDERS01/02/ etc...Also, one may come up with a custom built IDOC type (or basic type as you can say)...But it is essential to associate a message type with a basic type IDOC. This feature will enable the same IDOC type to be used for a related message. For example : ORDERS01 can be used for message ORDERS for posting a order, the same IDOC can be associated with message ORDCHG to indicate that the message is an order change and so the processing of this IDOC will change accordingly.
IDoc Type:
     Defines the structure of data records
      IDoc Type is used to understand the message in string form available in the data records.
      IDoc type is version dependent i.e an Idoc type can be used only in versions in and above the version in which IDoc is released.
      Transaction WE30 is used to define and release IDoc Types
      Newly created Idoc is a BASIC IDoc and modifications
             (Additions of segments) to IDoc after it has been released can be done by creation of extension      of IDoc.
      IDoc type can be defined by structuring Segments
Function Module: The most important player in the IDOC processing. This is nothing but an ABAP program to process the IDOC. SAP has supplied function modules to process all standard basic IDOCs and messages. A function module is determined based on the Basic IDOC type and the message type (also message code). So from the above descriptions about basic and message type, the combination of two would primarily determine which IDOC will process this idoc. As an instance, ORDERS01 with message ORDERS is configured to be processed by FM IDOC_INPUT_ORDERS. Similarly, ORDERS01 + ORDCHG will be processed by IDOC_INPUT_ORDCHG. Likewise, you can see all associations in WE57 for inbound. For out bounds, you would refer to process codes (WE41).
Segments: The idenfiers in the IDOC structure which indicates the data, their level, state of occurrence....You can take them as records in the IDOC. Each individual segment will come to you as a record in the IDOC. (Go to EDID4, provide an IDOC # and it will list all included segments as records.) Segments are logically nested to indicate various levels of data (header, item etc).
Qualifiers: Inside the segments, there are fields that can carry actual data often signified by use of qualifiers. A qualifier for a segment field would provide the exact meaning of the data. For example, E1EDK03 segment is configured for dates related data. Segment field IDDAT qualifies the date type and the DATUM field gives out the actual date. So you may see a date qualified as 002, which can be interpreted as requested delivery date. Likewise you can see all qualifiers and their meanings in the associated segment fields in SE12. Give the segment name and go to the domain the ranges for the ID fields.
How EDI Works
Sending Data
     Computer system serves as a data repository.
     EDI extracts information from existing computer applications.
     Transmits paperless, computer-readable documents via telephone lines.
Receiving Data
     Fed directly into a computer system.
     Automatically processed and interfaced with internal applications.
Processing Time
     Accomplished in minutes.
     No re-keying.
     No paper shuffling.
     No attendant costs of manual document processing and delivery.
What is the difference between ALE, EDI, IDocs and BAPI?
The interface concept of the classic R/3 is based on two different strategies: Remote Function Calls (RFC) and data exchange through IDoc message documents. RFC makes direct and synchronous calls of a program in the remote system. If the caller is an external program it will call an RFC-enabled function in R/3 and if the calling program is the R/3 system it will call an RFC-function in another R/3-system or it will call a non-R/3 program through a gateway-proxy (usually rfcexec.exe). BAPIs are a subset of the RFC-enabled function modules, especially designed as Application Programming Interface (API) to the SAP business object, or in other words: are function modules officially released by SAP to be called from external programs.
IDocs are text encoded documents with a rigid structure that are used to exchange data between R/3 and a foreign system. Instead of calling a program in the destination system directly, the data is first packed into an IDoc and then sent to the receiving system, where it is analyzed and properly processed. Therefore an IDoc data exchange is always an asynchronous process. The significant difference between simple RFC-calls and IDoc data exchange is the fact, that every action performed on IDocs are protocolled by R/3 and IDocs can be reprocessed if an error occurred in one of the message steps.
While IDocs have to be understood as a data exchange protocol, EDI and ALE are typical use cases for IDocs. R/3 uses IDocs for both EDI and ALE to deliver data to the receiving system. ALE is basically the scheduling mechanism that defines when and between which partners and what kind of data will be exchanged on a regular or event triggered basis. Such a set-up is called an ALE-scenario.
The philosophical difference between EDI and ALE can be pinned as follows: If we send data to an external partner, we generally speak of EDI, while ALE is a mechanism to reliable replicate data between trusting systems to store a redundant copy of the IDoc data. The difference is made clear, when we think of a purchase order that is sent as an IDoc. If we send the purchase order to a supplier then the supplier will store the purchase order as a sales order. However, if we send the purchase order via ALE to another R/3 system, then the receiving system will store the purchase order also as a purchase order.
ALE/EDI - Purpose
Electronic Data Interchange (EDI) and Application Link Enabling (ALE) are used for exchanging business data between different systems.
For both these forms of communication, you require the IDoc Interface. The IDoc interface is made up of the definition of a data structure and the processing logic of this data structure. The data structure is the IDoc. The IDoc is the general exchange format of the communicating systems. IDocs can be sent using different methods (for example, RFC or as a file).
Application Link Enabling (ALE)
You distribute data using ALE if you want to communicate from one system to one or more other (mostly internal) systems. ALE transfers data in IDoc format and uses the methods of tRFC for data transfer.
1.     ALE enables the integration of business processes across several SAP or non-SAP systems.
Electronic Data Interchange (EDI)
You use EDI if you want to exchange business application documents with an (external) partner system (for example, a customer or vendor). The SAP system sends EDI messages in IDoc format to an EDI subsystem, where they are converted to a universal EDI standard (UN/EDIFACT or ANSI/X12). This enables communication with non-SAP systems.
1.     By definition, two partners are involved in the process in an EDI application scenario: The sender and the recipient of an EDI message.
IDoc Interface/ALE
Purpose
The IDoc interface exchanges business data with an external system.
The IDoc interface consists of the definition of a data structure, along with processing logic for this data structure.
The data structure is the IDoc. The IDoc is the exchange format common to all the communicating systems. You can specify exception handling in the SAP Business Workflow, with IDocs, without the data already having to exist as SAP application documents.
You need the IDoc interface in the following scenarios:
Electronic data exchange (EDI)
Connect other business application systems (e.g. PC applications, external Workflow tools) by IDoc
Application Link Enabling (ALE).
Application Link Enabling (ALE) is a technology to create and run distributed applications
Hope this would help you.
Reward points if helpful.
Vamsi.

Step-by-step procedure of ALE. EDI & IDOC'S

Guys,
Does any one has step-by-step procedure of ALE. EDI & IDOC'S. Or if any one knows, from the scratch Please post in E-learning or Articles.
Advance Thanx,
Madhu.....

Welcome to SCN.
Considering probably you were not Aware of rules of Posting.
Please Search(Atleast twise) before posting.I just Copy-paste your Subject line into
[Google|http://www.google.ca/search?hl=en&q=step-by-stepprocedureofALE.EDI%26IDOC%27S++&btnG=GoogleSearch&meta=] .

ALE audit in IDOC

Similar Messages

Maybe you are looking for