ALE IDOC - Part 1 - Definition | Why ALE IDOC | ALE IDOC Tutorial

Idoc - General Overall View

http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/5212%3Fpage%3Dlast%26x-showcontent%3Doff

A Single Mistake Can Cost You $$$$$

IDOC, Mike Salvo, RBDMIDOC, SAP

Posted by ccampbell on July 9, 2009 · Leave a Comment

While working with a client on developing EDI-856 transactions with one of their trading partners, an error occurred that cost my client thousands of dollars in charge back fines.

In their SAP environment they produce a single DESADV IDoc per order/purchase order.  This could amount to several hundred DESADV IDocs being generated.  The initial development was a 1 to 1 translation in that each DESADV IDoc that was produced would be translated into a single EDI-856 document.

Because of a single data error, due to department procedures not being followed in the warehouse in the closing of orders, the bad data element resulted and was repeated throughout all of the DESADV IDocs that were generated.  Translation of the IDocs was successful because this error was not conceived at the point of map development.  The hundreds of translated documents were sent to the trading partner and subsequently resulted in failed documents.

Because the trading partner generated a charge back for each document sent, my client was billed thousands of dollars in charge back fines.  This simple example shows how a single error repeated in each document can turn out to be a very costly problem.

I hope to show you in the next few postings how to bundle the IDocs together to:

• Bundle and reduce the number of IDocs being translated
• Reduce the number of EDI documents being sent to the trading partner
• Minimize the charge back cost, should and error occur

Changing SAP IDOCs Status In Mass / Mass Deletion Of IDOCs

Posted by Tim Yates on Wednesday, October 7, 2009 · Leave a Comment

Mass Change of SAP IDOC Status

From time to time it becomes necessary to change the status of SAP IDOCs in SAP. The most common scenario is the requirement to mark SAP IDOCs for deletion. There is no good way to mass mark IDOCs for deletion via the standard IDOC processing transaction BD87. However there is a program that will let you change status.

RC1_IDOC_SET_STATUS

CAUTION: This program should be used with great care and consideration. Improper use of this program can result in data consistency issues. Make sure you know what you are deleting, why you are deleting it, and what is required to correctly update you system after deleting.

Example: Marking IDOCs for Deletion In Mass

It is pretty typical for support users to set the deletion flag on IDOCs that have been incorrectly created and have errored. When there are a small number of IDOCs this is possible via transaction BD87.

An inbound IDOC in error will have the status 51, when it is marked for deletion it has a status of 68.

A view of the IDOCs to be deleted in WE05.

To mass delete IDOCs run the following program via SE38: RC1_IDOC_SET_STATUS via the SAP Transaction: SE38

There are only a few parameters on the selection screen for this program. It is most important that you correctly restrict the IDOCs you select with this program. The program automatically defaults to marking inbound IDOCs in error for deletion.

To mass select IDOCs to be marked for deletion select:

There are many options for selecting and restricting the IDOCs to Mass process. Select by single value or range. Restrict by single value or range.

The allows you to upload a list of IDOCs from a text file.

The allows you to apply a list from your clipboard.

Execute the program

Check the status of the 3 IDOCs in WE05

Example: Changing IDOCs Status To Repost

It is also possible to use this program to reset an IDOC so that it can be reprocessed.

With the following selection we are going to reset the IDOCs with status 68 marked for deletion back to status 64 to try and reprocess them.

Execute the program

As you can see, program RC1_IDOC_SET_STATUS is very helpful, but please be careful when you use it!

About Tim:

Tim has over 20 years industry experience, with 15 years concentrated on SAP and related technologies. He has broad industry exposure working with companies such as Siemens Automotive, Mercury Marine, SAP America, Eli Lilly & Company, and Verizon. Tim’s deep understanding of SAP and the industry comes from a very hands on approach. His concentration in SAP has been in systems architecture and integration, helping companies develop their infrastructure and controls to successfully integrate SAP into their existing IT landscape.

SAP Community Network Wiki - ABAP Development - Handling Idoc Acknowledgements

 My Home > ABAP Development > ...Data Transfers - BAPI, BDC, ALE, LSMW, DX-WB > ALE,IDOC > Handling Idoc Acknowledgements

Handling Idoc Acknowledgements 
Apr 13, 2009  (view change)

Labels:

idoc, ack, acknowledgement, status

Way of handling the acknowledgements forthe custom generated Idocs.

Note: I took an example custom Idoc which has already been developed to explain the concept of handling Acknowledgements. I am providing the necessary details here before proceeding to the actual concept

Sender System       : BANGSEND
Recieving System  : HYDRECIEVE
Message Type         : ZEMP84364_MNT_RPT
Basic Type                : ZEMP84364_MNT_RPT01
Functionality of the Idoc : Transfers the records created with the help of a report program and updates the database table of the target system.

For this scenaio, now we are going to see how we can handle the acknowledgement.

ALE Configuration for Idoc Acknowledgement:

Sender creates an Outbound Idoc and this particular Idoc is received by the receiver as an Inbound Idoc and receiver system processes the Idoc, it updates the database tables. Now, Sender system would never know what happened to the document that it has passed to the receiver. So, to make sure that the receiver had posted the application document in the necessary database tables, we would need an Acknowledgement.

ALEAUD is a standard message type through which we can achieve this functionality. Now, we need to update the settings for ALEAUD message type in both sender and receiver systems.

Add ALEAUD message type in the outbound parameters for the partner BANGSEND. Now, this particular Ack Idoc would behave as an outbound Idoc from the receiver system of the actual Idoc to the sender system of the actual Idoc.

The settings after adding the ALEAUD Idoc in the outbound parameters in the above screen is shown below.
This is the place where we are using the port that we have created in the receiver system.
Note: Select the Output mode as Transfer Idoc immediately (Though it is optional, you can collect all the Idocs and process them using a job). Save the screen.
Now, make similar settings in the sender system. As, HYDRECIEVE is the partner for the BANGSEND system, you would receive the Acknowledgement Idoc as inbound in the BANGSEND system. So, add the ALEAUD message type in the Inbound parameters of the partner HYDRECIEVE as shown below.
The actual process code settings that we need to do after adding the message type ALEAUD in the inbound parameters is shown below
Since you are using the standard message type, no need to write a function module to process these Ack Idocs. Even the process code that we are using is a standard one.
Now, you need to create Distribution model in the receiver system for these ALEAUD Idocs
Below screen shows that, HYDRECIEVE system is going send ALEAUD Idocs to the BANGSEND system with the distribution model name MODEL_ACKS which we have not yet created.

Save the screen now which is very important

To generate partner profiles, go to the menu Environment and click on Generate Partner Profiles and execute the below screen.

After executing the above screen you would see that the partner profiles created. Items marked in the green color are the ones which are created automatically.
A standard message type SYNCH always gets generated and you can check the same in the partner profiles.

Now, once you are done with the above you need to distribute the distribution model with the partner system by clicking on the menu Edit -> Model View -> Distribute
Click on Ok and the distribution model is shared with the partner system as shown in the next screen.

Click on OK.

Testing the Idoc by running the Application Program:

Go to the Sender system, execute the Application Program (ABAP Program) and enter the selection screen the details as shown below.

Now execute the above screen and you would see the output saying the Idoc number generated as shown below

Now, Go to WE05 transaction and see the above Idoc.
In the above screen the very last one is the Idoc that has been created now. Let us open the Idoc and verify the contents as shown below.

In the above screen, the final status of the Idoc is 03. It means that, the Idoc has gone to the destination system. But, we do not know whether the Idoc has been processed there or not. Now, let us go to the target system and check whether this particular Idoc has been converted in to an Inbound Idoc to get posted in the target database.
Execute WE05 transaction in the target system and see the Idoc. Based on the time, the last Idoc that has been processed should be the Idoc that has been created. The Idoc is selected for the reference.

Let us open the Idoc and see whether the contents of the Outbound Idoc of Sender are same as the contents of the Inbound Idoc in the target system.

You can see that content of the Idoc is same and as the status of the Idoc is in 53, we can confirm that the Idoc has been posted in the target database.
Let us verify that by opening the database table in the target system.

We can see that the record has been updated in the target database.

This ends the Idoc posting.

But, in the view of Sender as the Outbound Idoc is in 03 status, Sender would never know what happened to the Idoc in the target system.
So, in production environment generally a job is set to run periodically which has the program RBDSATATE with the variant SAP_AUDIT_SEND to send the audit data back to the Sender from the target system.

In our case, let us run the job manually to send the Audit data back to the sender system

The job has finished and the spool shows that there is an Idoc with the message type ALEAUD that has been generated as shown below.

Now, go to the Sender system and check the status of the Idoc it should have been changed to 41(Final Status of any Outbound Idoc) as the Idoc has been posted successfully here in the target system.Go to sender system and open WE05 transaction.

In the above screen, you can clearly see that all the Idocs have been changed to the status 41. You can see the same for our Idoc in the below screen.

This ends the way of handling Idoc Acknowledgements.

Contact Us Site Index Marketing Opportunities Legal Terms Privacy Impressum
Powered by SAP NetWeaver

SAP Community Network Wiki - ABAP Development - Handling Idoc Acknowledgements

SAP Community Network Wiki - ABAP Development - ALE,IDOC

 

ALE Technology : Application Link Enabling (ALE) is a technology to create and run distributed applications.  ALE Technology is proprietary of SAP.

ALE Objectives - ALE incorporates controlled exchange of data messages ensuring data consistency across loosely coupled applications. ALE comprises of three layers.  Application Services  Distribution Services  and Communication Services .Basic principle of ALE is to provide a distributed and fully integrated R/3 system. Each application is self-sufficient. The use of self-sufficient system implies a certain measure of data redundancy.Hence data has to be both distributed and synchronized.

Difference Between ALE and EDI :Normally we refer to EDI technology when a non SAP system is one of the communication channel. ALE communication occurs from the SAP side and EDI from the non-SAP side. IDOCs uses ALE and EDI to deliver the data to the receiving system. If the data needs to be exchanged between two SAP systems, then IDOC uses ALE technology . For the exchange of data between a SAP and Non SAP system, IDOC uses EDI subsystem to convert and deliver the data.

ALE Communication Diagram

1. What is the difference Between IDOC type and Message type? How to link the IDOC type with Message type?
Message type gives the meaning of the IDOC . IDOC type gives the structure of an IDOC.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 and  the IDOC type.The IDoc type indicates the SAP format that is to be used to interpret the data of a business transaction.
In the OO(Object Oriented) approach, Message Type can be refferred to a Class and IDOC Type as an instance of the class Message Type
The linkage will happen in transaction WE82.

2. Where the IDOC information gets stored?

Table
Description

EDIDC
Stores the Control Record information an IDOC

EDID4
Stores the Data Records (version 4.6)

EDIDD
Data Seg (EDI Intermediate doc)

EDIDS
Stores the Status of an IDOC

3. What is process code? What  are type of process codes

Process code refers to an workflow or a function module which helps in reading or writing data from/to Idoc. Process Codes are used in both ALE and EDI framework to identify the function module or API (Application Programming Interface) to be invoked for subsequent processing. Inbound as well as outbound interfaces use process code but for different purposes. Outbound process codes are stored in table TEDE1, while inbound process codes are stored in TEDE2.

Following are types of process code

Process Code
Description

Outbound Process Code
This will read application data and place data in Idoc 

Inbound Process Code
This will Idoc and create corresponding application data

System Process Code
This will create  work item in case some error occurs in idoc / application document processing

Status Proces Code
This will handle error that occurs when a idoc is sent to some other system

4. How to reprocess an IDOC?

You can use the below Programs for IDocs Reprocessing:

• RBDMANI2  : Reprocess Idocs manually
• RBDMANIN  : Posting of IDocs with Status 51
• RBDMOIND  : Outbound Idocs status 03->12
• RSEOUT00  : For Processing 30 Status IDocs
• RBDAPP01  : For Processing 64 Status IDocs
• RBDAGAIN : Reprocess Incorrect Outbound IDocs
• RBDAGAI2 : Reprocessing of IDocs after ALE Input Error

5. How to trace the IDocs of the Receiving system from the Sending system?

Steps:

• Execute the transaction BD87
• Give the Outbound IDocs in the IDoc Number field and execute or Just Note the Start time and End time when u execute the Master Data Transaction say for eg.BD10 and specify the same in the Time Created input field of BD87,also give the Message Type and the Receiving System Names and execute.
• Select the Repective Message Type and Press the Trace IDoc Button.

6. How to trace IDocs based on the data .

Steps:

•   Execute Transaction WE09
•   Put in the message type name in the field labeled 'Logical Message'   Ex -  DEBMAS
•   Now we will move to the section 'Criteria for Search in Data Records '
•   In this section we will put the Segment name in which we want to search the existance of data in the field labeled 'Search in Segment'  EX - E1KNA1M
•   In the field labeled 'Search in Field' we will put the field name of the segment in which we want to search the existance of data. Ex - KUNNR for searching IDOCs for certain customer number.
•   Now in the field labeled 'For Value' we will put the search value. Ex - Customer number as 100 .
•   We will now execute the transaction.
•   The result can be a single Idoc or a list of multiple IDOCS depending upon the Search Criteria entered.

7. How to Send and Receive an IDoc in the same system.

Steps :

• Create a Dummy Logical System.
  • Goto T-Code SALE-> sending and Receiving Systems -> Logical Systems -> New entries.Enter SYSID_CLNT, but this one is Dummy so use the first 2 characters of the SYSID and prefix 'D' then underscore and then the Client number.

• • E.g.: If ERP_100 is the logical system of the R/3 then create ERD_100 as the dummy system.
• Create Port for the Original System, (ERP_100)
  • Goto WE21 and select Transactional Port and press the Create button. Name the Port as "SAP" contatenated with the SYSID in our example it would be SAPERP Select the appropriate version and enter the RFC dest of the system that you are working on in this case it will be 'ERP'.
• Create Partner Profile in partner type LS:
  • Receiver Side ( Outbound to ) :  In Partner type LS name ERD_100create the Outbound Parameters, give the Message type, Receiver Port same as the port we created in step 2. Enter the Basic type.

• • Sender Side ( Inbound From ): In partner type LS name ERP_100 create the Inbound Parameters, give the appropriate message type and the process code.
• Now create the stand alone program to send the IDoc:
  • The program will at some point calls the MASTER_IDOC_DISTRIBUTE function module. When you pass the EDIDC structure it will be populated as follows:
    i_edidc-mestyp = message type.
    i_edidc-idoctp = basic type.
    i_edidc-rcvprt = 'LS'.
    Concatenate 'SAP' sy-sysid into l_port.  
    i_edidc-RCVPOR = l_port.
    i_edidc-rcvprn = 'ERD_000'.
    CONCATENATE sy-sysid '_' sy-mandt
    INTO l_sndprn.
    i_edidc-SNDPRN = l_sndprn.
    i_edidc-sndprt = 'LS'.
    i_edidc-sndpor = l_port.
• Observe that the Sender port and the receiver port is the same, this does the trick. The outbound Idoc is sent on the port SAPERP with the Sender as ERP_100 and receiver as ERD_100 and then the Inbound Idoc is also sent to the same port SAPERP with the Sender as ERP_100 and receiver as ERD_100.

8. What is message control and when do we use it?

Message control is a mechanism by which documents are output based on a selection criteria and requirements. This concept is applicable not only to EDI and ALE, but also to other output mediums (for example: print, fax). Message control determines the type of document, its timing, number, and the medium. NAST table stores output records. The conditions (selection criteria and requirements) for creating an output message are stored in condition tables. Search mechanisms are used through access sequences, output processes, and requirements to determine whether an application document qualifies for output.

Some of the tables for Message Control are :

Transaction Code
Description

NACE
Condition Record Maintenance

VOK2
SD Message Control Components

VOK3
Purchasing message Control Components

VOFM
View Message Requirements

V/86
Condition Table Field Catalog

WE15
IDOC test : outbound from Message Control

9. How do you reprocess the failed trfc entries?

  You can reprocess the failed trfc entries using the program RSARFCEX.

10. What is the transaction used to find the outbound and inbound process codes at one place?

WE64

Children Hide Children  |  View in Hierarchy

7 Steps For ALE Configuration
Administration of ALE Functions and Troubleshooting ALE
ALE- DDIC tables that are reflected with respect to Partner Profiles
Change Pointers
Creating an ABAP program from a BDC recording
Customer Master Record (Tax Groupings) in Customer ALE
EDI 997 - Functional acknowledgement
Handling Idoc Acknowledgements
IDOC Steps
Idocs
Interface Development using IDOC's
Managing Data in different Formats with IDOC
Message Control for ALE
Modify IDOC Status by Program
Outbound Idoc Through ALE
TO BE DELETED

SAP Community Network Wiki - ABAP Development - ALE,IDOC