The RFC server program (typically rfcexec) is unreachable; perhaps this program does not exist on the destination server, or the path is unreachable or inaccessible. Keep in mind that the path name and program name are case sensitive. The ID used to access the files is <SID>adm, where sid is the system ID. If you are using separate systems for SAP and the subsystem, refer to Chapter 6,
"Configuring Basic EDI Components."
•
Although the network is rarely at fault, check that the physical links and network links are working.
You can execute the ping command at the OS level to ensure that the link is up.
•
Testing the Port Definition
This test confirms access to the directory location where the IDoc files will be stored for the inbound and the outbound processes.
Execute transaction WE21. Select your port definition, and then click the Outbound File button to view the directory location where IDoc files will be stored. Click the Check button on this screen to test accessibility to the directory. If the check is successful, the port definition is correct. Perform a similar operation for the inbound process and the Command file.
If the test connection returns negative results, the message should indicate the problem.
The problem involves access to the directory location. Check that the path name is spelled correctly. It is case sensitive, and the directory name must end with a slash.
•
If access to the file system is via NFS (Network File System), the NFS mounts should be verified from the application server to which you are logged on.
•
Testing the Outbound Process Steps
The outbound process is essentially a sequence of subprocesses that link together to form the total process.
Five subprocesses are tested in the outbound process (see Figure 10.1).
Performing a Configuration Sanity Test
Figure 10.1: Testing outbound components
The successful creation of an application document
•
The proposal of output by Message control
•
The generation of IDocs
•
The connection between the SAP system and the subsystem
•
Status reporting by the subsystem
•
Verifying the Successful Creation of an Application Document
In this test, you want to ensure that your application document can be created successfully. Here are the steps to execute the test and verify the results.
Execute your application transaction (for example, VA01) to create a sales order or ME21 to create a purchase order. Check that the application document is created successfully. This step usually works without any problem. However, this step can fail completely (in which case, a document is not created) or fail partially (in which case, the document is marked incomplete).
Caution In certain situations, the system reports that the document was created successfully, but when you go into the display mode, you do not see a document. The problem lies in the IDoc selection program.
Check that the timing in the condition record is set to 1, as described in the prerequisites.
The system reports any problems to you immediately on the application status bar. You click the problem reported in the status bar to get additional details. You can also use extended help (if available) to view the online help in that context.
The application configuration can have a variety of problems. For example, pricing has not been maintained, a credit block is on the customer, or the vendor has not been maintained in the desired company code. You must work closely with the business team to resolve this type of problem.
If this step is successful, you should have an application document in the system. Verify it by going into the display transaction and making sure that you see the document and that it is complete.
Verifying the Proposal of Output by Message Control
If your output (EDI, ALE, or fax) will be proposed automatically via Message control, you must ensure that all the desired outputs are proposed with correct values.
You test this component by executing the application transaction. No tool is available to test the Message control component by itself. The only option is to create an application document and go to the output control screen. In some cases (for example, order change), you must go to the Change Document transaction instead of the Create Document transaction.
Verify the following on the output control screen.
Testing the Outbound Process Steps
The existence of an output record (if output is to be proposed automatically). If output is to be entered manually, display the list of output types and select your output.
•
The accuracy of the output medium, timing, and language.
•
If your desired outputs (such as EDI, ALE, fax, and print) are not proposed, go to the menu bar on the output control screen, and choose Goto, Determination Analysis to view the output log, which is shown in Figure 10.2.
Figure 10.2: The Analysis Output screen, showing the steps used in proposing an output type Tip Press Enter on the output control screen to validate the values.
The output log displays the reason for the problem. This log is cryptic, but it is the only alternative. If you understand the Message control concept, you should have no problem reading the log. For example, the next−to−last line in the Overview window (refer to Figure 10.2) indicates that the RD00 output has already been processed once and that a subsequent automatic proposal is not allowed.
The following list identifies common problems that can prevent the output record from being proposed. This list is not complete, but it will help you resolve some of the common problems.
The condition record is missing.
•
The Message control record of the partner profile is missing.
•
The output type is set to manual.
•
One of the prerequisites for the conditions was not satisfied in the requirement logic of the Message control.
•
If the output proposal is working correctly, you must make sure that a NAST entry is created for each of the outputs. To see the NAST entries, execute transaction SE16 or SE17, and enter NAST in the table name.
Enter your application document number in the Object Key field, click the Execute button, and verify that a record exists for each output proposed on the output control screen.
Tip If the application document number is fewer than 10 characters, you must prefix it with leading zeros;
otherwise, the record will not be located.
Verifying the Generation of IDocs
In this step, you verify the process of generating IDocs from the application document. If you have extended the IDoc selection program via user exits, modified it, or created a new one, this step allows you to debug
Testing the Outbound Process Steps
Transaction: WE15
Path: From the Area menu of EDI, choose Test, Outbound from MC.
You test this step by executing the RSNAST00 program via transaction SE38 or by directly executing transaction WE15. Figure 10.3 shows the selection screen for this program. This step processes the NAST entries you created in the preceding step and calls the selection program for that message. For example, IDOC_OUTPUT_ORDERS will be called for message type ORDERS.
Figure 10.3: The selection screen for the RSNAST00 program (© SAP AG)
Tip After a NAST record has been processed successfully, the record can be resent either by selecting the Send Again check box without creating a new document or by going into the application document again. You must make sure that the timing of the output is set to 1 or 2, as mentioned in the prerequisites.
If an error occurs during the execution of RSNAST00, it creates an output log that is displayed on the screen.
You can also find extended help on each record of the log by clicking the Documentation button.
Another possibility is that syntax errors have been found in the IDoc. The IDoc will be in status 26 (Error during Syntax Check of IDoc). You use transaction WE02 to display IDocs in the system. The status record in the IDoc tells you whether syntax errors were generated for the IDoc.
If you are testing a standard SAP−supplied program, errors at this stage are rarely due to program logic. The possible causes of the errors are
The partner profile has an incorrect process code. You can perform a syntax check on the partner profile.
•
The application document has been deleted. Display the application document to confirm that the document exists.
•
The application document contains an inconsistency. For example, partner functions might not have been defined.
•
The program logic has errors. If you have developed your own selection program or extended the standard program via user exits, check the program logic for errors.
•
If this step works correctly, a success message should appear in the output log window. You can then use transaction WE02 to display the IDoc. It must be in status 30 (IDoc Ready for Dispatch).
Tip If you cannot figure out the problem, try debugging the program. Set a breakpoint at the start of the function module. You can set additional breakpoints, depending on the problem. For example, if you are
Testing the Outbound Process Steps
getting an error message, set a breakpoint on the keyword message to navigate quickly to the code where the error is being generated.
Click the Documentation button in the output log window to view the IDoc number.
Verifying the Connection between the SAP System and the Subsystem
The connection between the SAP system and the subsystem is one of the major culprits in the process. This connection is responsible for the greatest number of problems because it crosses the boundary from SAP to the OS layer. If you successfully tested the components, you should not experience any problems here.
Transaction: WE14
Path: From the Area menu of EDI, choose Test, Outbound Processing from IDoc.
If the sanity tests were successful, there is very little chance of error in transferring IDocs from the SAP system to the operating system. The IDoc must be in status 30 (IDoc Ready for Dispatch) to be passed to the subsystem. Execute program RSEOUT00 via transaction SE38, or execute WE14 to transfer IDocs to the subsystem . The selection screen allows you to select an IDoc based on various criteria (see Figure 10.4). You can enter the IDoc number as generated in the preceding section, "Verifying the Generation of IDocs."
Figure 10.4: The selection screen for the RSEOUT00 program (© SAP AG)
If this step does not execute successfully, you have a problem, so check the last status record of the IDoc.
Refer to the list of errors explained in the sanity test in the "Testing the Port Definition" section. This step is verified by checking the status of the IDoc. If the RSEOUT00 program executes successfully, the status of the IDoc will change to 03 (Data Passed to Port OK). An IDoc file will also be created at the OS level with a name specified in the port definition.
Tip If you do not have an account at the OS layer, you can execute transaction AL11 to view the IDoc file.
Verifying Status Reporting by the Subsystem
In this step, you test the process of status reporting by the subsystem, but the subsystem is not required. SAP provides a utility to test this step.
Status codes can be of type success or failure. In either case, a status record is attached to the IDoc. If a status Testing the Outbound Process Steps
10.1).
Table 10.1: Status Codes Passed to SAP by the Subsystem
Status Code Workflow Description
04 Yes Error within control information of EDI subsystem
05 Yes Error during translation
06 No Translation OK
07 Yes Error during syntax check
08 No Syntax check OK
09 Yes Error during interchange handling
10 No Interchange handling OK
11 Yes Error during dispatch
12 No Dispatch OK
13 No Retransmission OK
10 No Interchange Acknowledgment positive
15 Yes Interchange Acknowledgment negative
16 No Functional Acknowledgment positive
17 Yes Functional Acknowledgment negative
22 No Dispatch OK, acknowledgment still due
23 Yes Error during retransmission
24 No Control information of EDI subsystem OK
36 No Electronic signature not performed (timeout)
Transaction: WE17
Path: From the Area menu of EDI, choose Test, Process Status File.
You can use a standard system tool to test the process without having a subsystem installed. First, you use this tool to import a status file with any success status code from Table 10.1. You do not have to test every success status code. Then, you can test each individual error status code from the subsystem by importing a separate file each time. Figure 10.5 shows the selection screen of this test tool, where you can specify the input file name. A sample file for testing inbound status processing appears in Listing 10.1. The second line gives you a reference for the position and is not part of the file. This file adds a status record with a status code 16 to an IDoc number 1184 with a date of December 16, 1998, and a time of 10:10:03. This record contains the minimum amount of information required to append a status record. You can certainly include additional information (for example, a message and message text).
Testing the Outbound Process Steps
Figure 10.5: Processing inbound status (© SAP AG) Listing 10.1: Sample Inbound Status File
EDI_DS40 00000000000011841998121610100316 12345678901234567890123456789012345678901234567890
In addition, if you are deleting a large number of work items it is a good idea to schedule the job to run when the system is less busy than normal.
The screen itself displays the results. This process does not experience many problems. The main reason for failure is that the format of the status file is imported into the system or that the IDoc number specified in the file is incorrect.
Note Because the file format has changed with every major release of SAP, the file should conform to the revision in use.
You verify the results by viewing the last status record in the IDoc. To view the IDoc, use transaction WE02 (Display IDocs). If the status code represents an error, the IDoc administrator will also be notified via workflow. The IDoc Administrator's Inbox should be checked for an error message.