Troubleshooting the ALE process

Introduction:
This tip will focus on troubleshooting ALE processes. It covers the following matrixes:

 

1. How to determine what code the IDoc is executing
   1. Outbound
   2. Inbound
2. High level error resolution for outbound/inbound IDocs
   1. Not sure if IDoc was created or received
   2. IDoc not created/received, which should have been.
   3. IDoc created, but not received by receiving application
   4. How to resend an IDoc.
   5. IDoc received, but not posted (inbound side).
   6. IDoc Batch Job:

Let's look at each in detail.

1. How to determine what code the IDoc is executing:
   In some cases, you may need to debug through the IDoc code to see where data is being pulled from and/or where the IDoc is failing. The following will provide this information for Outbound and Inbound ALE IDocs.
   1. Outbound – IDoc can be created in 3 ways.
      1. Message Control
      2. Direct Path
      3. Change Pointers

Message Control:

1. Execute Transaction Code - WE20
2. 
   
    
3. Select the logical system and double-click the message type under Outbound Parameter.
4. 
   
    
5. Select the Message Control Tab
6. 
   
    
   
   Note: This tab will be displayed if "Message Control" is used. In this case, message control is being used and Idocs will get created for every New and/or Change of delivery notes. If you don't see message control set up, go to Direct Path and changes pointers.
   
   
7. Double-click on process code to see what code it is triggering.
8. 
    
   
   
9. You can double-click on the inbound function module name to view code and set breakpoints.
10. 
    
     
    
11. DO NOT DO IN PRODUCTION: Process an IDoc via BD87. And you should stop at the breakpoint.

Direct Path:

1. DO NOT DO IN PRODUCTION: Debug program RSEOUT00 for direct path
   1. You can also look at transactions WE64, but not all process codes will be listed there.

Change Pointers:

1. DO NOT DO IN PRODUCTION: Debug program RBDMIDOC for direct path
   1. You can also look at transactions WE64, but not all process codes will be listed in there.

So far we covered the Outbound process. Let's look at the Inbound Processes.

 

b. Inbound:

1. Execute Transaction Code - WE20
2. 
   
   
   
   
3. Select the logical system and double-click the message type you are looking for on the right hand side under "Inbound Parameter".
4. 
   
   
   
   
5. Double-click on the process Code
6. 
   
   
   Note: The function module name is in the "Identification" Field. This is what gets executed when the IDocs is inbound. The processing does many data validation checks and then updates the database tables.
7. You can double-click on the inbound function module name to view code and set breakpoints.
8. 
   
   
   
   
9. DO NOT DO IN PRODUCTION: Process IDoc via BD87 and you should stop at the breakpoint.

So far we've seen what code an IDoc is triggering. Now lets see how to troubleshoot the problems.

1. High level error resolution for outbound/inbound IDocs
   1. Not sure if IDoc was created or received
   2. IDoc not created/received, which should have been.
   3. IDoc created, but not received by receiving application
   4. How to resend an IDoc.
   5. IDoc received, but not posted (inbound side).

Case 1: Not sure if IDoc was created or received.

1. Execute Transaction WE05; enter correct date/time frame and logical message type. (You can also search by a specific IDoc, see section Searching for a specific IDoc)
2. Double-click on your valid Message type line to get a list of IDocs.
3. 
   
   
   
   
4. See IDoc Statuses section to determine if IDoc(s) was successful or not. Note: there maybe several different statuses for a Message type so you may need to repeat steps 1-2 for the different status until you find your IDoc(s). If IDoc not found, go to IDoc batch job section and case 2 section.
5. 
   
6. If IDoc is found in a successful status, go to case 3. If IDoc found in failed status, open status records folder and double-click on the failed status records to get error message as why IDoc failed.

Case 2: IDoc not created/received, which should have been.

1. Use steps in case 1 to verify if the IDoc was created or not and successful or not.
2. If IDoc is not found, validate job is running. See section IDoc Batch Job.

Case 3: IDoc created, but not received by receiving application.

1. Use steps in Case 1 and 2 to verify if the IDoc was created or not and if IDoc is in a successful status or not.
2. If the IDoc is in Yellow status (Status-30), you can push through Transaction code - BD87.
3. If the IDoc is located and status is successful but receiver has not received the IDoc, execute transaction SM58 to determine if IDoc is stuck in the ALE/RFC layer. Enter a ‘*’ in all fields except leave Display period field with default values.
4. 
   
   
   
   
5. Hit execute.
6. 
   
   
   
   
7. If entries exist in SM58, look for Message Type. If message type exist and Run the Program "RSARFCEX"
8. If after the RSARFCEX program has ran and IDocs are not in SM58, issue should be solved. Validate in receiving system via WE05 that the IDoc was received. If IDoc is still stuck in SM58, check RFC connection. Go to SE37, enter function module RFC_PING.
   Note: In most of the case we'll not have access to SM59 to test the RFC Connection.
9. Hit test button, Enter RFC destination (the interface system of the IDoc). NOTE: when entering RFC destination, keep in mind the field is case sensitive.
10. Hit execute button
11. If function module fails, there is an RFC issue. Contact team, which creates the RFC Destination.

Case 4: How to resend the IDocs. We can segregate into 2 parts here:

1. How to resend Master IDocs
2. How to resend an Existing Idoc

Lets see the option 4a: How to resend Master Idoc Here i gave couple of Transaction to push the Master data.

1. To push Material Master - use Tcode BD10
2. To push Customer Master - use Tcode BD12
3. To push Vendor Master - use Tcode BD14
4. .....

Lets look at the option 4b: How to resend an Existing Idoc

1. Execute transaction WE19.
2. Enter the Idoc # you would like to resend in the Existing Idoc field.
3. Select Execute
4. Click on "Standard Outprocessing". Be very careful not to change the Idoc information. This gets save to the Database if changed
5. 
   
   
   
6. Select Continue.
7. Idoc has been resent. Notice the message IDoc no. ### saved in database. A new IDoc number has been resent but sent with same information.

Case 5: How to process an IDoc.

1. After an issue has been resolved and/or you need to process an IDoc, besides processing IDocs via programs, you can also process IDocs via Transaction BD87
2. Execute transaction BD87
3. 
   
   
   
4. If you know the Idoc number, enter the Idoc number in the Idoc number field. If you need to process many Idoc numbers, you can also just hit execute.
5. Hit execute
6. 
   
   
   
7. Expand the Idoc(s) you would like to process.
8. Select the Message Type you would like to process. Note: If you did not enter a specific Idoc number, when you select the Message Type, ALL of those Idocs for that message type will be processed.
9. 
   
10. Click "Process" button.
11. You results will be displayed (if Idoc processed successfully)
12. 
    
     

IDoc Batch Job. If IDocs are processed in SAP batch, validate the job is running via SM37.

1. Typical Inbound jobs run programs:
   1. RBDAPP01 (posts IDocs)
   2. RBDMANIN (posts status 51 IDocs)
   3. RBDMIDOC (Change Pointers, can check via BD50)
2. Typical Outbound jobs run programs
   1. RSNAST00 – WE15 (if using message control, can check via partner profile WE20). Also validate message control is set up properly via NACE. (Creates IDocs)
   2. RSEOUT00 (sends IDocs – we14)
   3. RSARFCEX (clears IDocs out of ALE/RFC layer)
   4. RBDMOIND (changes IDoc from status 03 to 12)