While we are working with SAP and its programming language ABAP, its advanced concepts like EDI will be very useful in communicating SAP with third party software suing EDI. It is widely used to simplify the process. Here we are going to discuss how do we SAP ABAP test the EDI interface.
Testing the Outbound Process
The outbound process is relatively simple to test, and requires the least simulation because the process originates in SAP and all the major components reside in SAP. The best approach for testing an outbound process is to first test each component, and then test the whole process.
Types of Test Utilities
Utilities for a sanity test performs a basic sanity test on the configuration of EDI objects such as the partner profile, port definition, and RFC destination parameters. A sanity test enables you to test a component without executing the actual process. For example, you do not have to execute the purchase order process to test the accuracy of settings in the partner profile. You can access these utilities from within the maintenance screens of the objects.
We can test the outbound process using the actual components involved in the process. The only piece that can be missing is the subsystem. A utility in the standard system simulates the functionality of the subsystem, which is to report the process status to the SAP system.
Prerequisites for Testing an Outbound Process
The outbound process is composed of programs that are linked to run one after another. To test each component separately, we have to make the following settings to ensure that the components are disconnected from each other and do not start the next process immediately.
If our application uses Message control, the timing of the output type should be set to 1 (Run with the Next Selection of RSNAST00) in the condition records. This setting causes the RSNAST00 program not to run immediately after creating an entry in the NAST table.
In the partner profile, set the Collect IDocs flag and the Do Not Start the Subsystem flag. These settings cause the RSEOUT00 program not to run immediately after an IDoc is created in the system.
Testing the Partner Profile
We can test partner profiles to make sure that the parameters specified are still correct. The checks are carried out are
The process code
The user to be notified
Message control consistency with outbound parameters
To check the consistency of partner profiles, we can execute the program RSECHK07. You can do this via transaction SE38 or from the menus of the initial partner profile screen. The output is a color coded report that shows the details of any problems that were found.
Testing the RFC Destination
This test confirms the connectivity between the computer system on which SAP is running and the system on which the subsystem is or will be installed.
We have to execute transaction SM59 and Click the RFC destination being used in the process. The destination is typically SERVER_EXEC, but confirm your RFC destination by viewing the details of the port definition that will be used for outbound processes. Click the Test button. If the results are positive, the connectivity is working correctly.
If the test connection returns negative results, the message should indicate the problem. If the message is not self−explanatory, you can turn on RFC trace to log every step of the RFC test.
The problem is basically the connectivity between the two systems. The possible causes of errors are
1.The RFC destination is using an explicit host name to reach the destination system, and this name is misspelled.
2.The RFC server program (typically rfcexec) is unreachable; may be this program does not exist on the destination server, or the path is unreachable or inaccessible. The path name and program name are case sensitive. The ID used to access the files isadm, where sid is the system ID.
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.
Here we have to execute transaction WE21 and 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.
1.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.
2.If access to the file system is via NFS (Network File System), the NFS mounts should be v verified from the application server to which you are logged on.
The previous post deals with SAP ABAP WORK FLOW setting using EDI
What is SAP Full form and its definition part one
SAP Full form and introduction part two
SAP architecture,its full form of working and enjoy sap products
SAP Full from and Drive from R/3 to MySAP.com
Testing the Outbound Process
The outbound process is relatively simple to test, and requires the least simulation because the process originates in SAP and all the major components reside in SAP. The best approach for testing an outbound process is to first test each component, and then test the whole process.
Types of Test Utilities
Utilities for a sanity test performs a basic sanity test on the configuration of EDI objects such as the partner profile, port definition, and RFC destination parameters. A sanity test enables you to test a component without executing the actual process. For example, you do not have to execute the purchase order process to test the accuracy of settings in the partner profile. You can access these utilities from within the maintenance screens of the objects.
We can test the outbound process using the actual components involved in the process. The only piece that can be missing is the subsystem. A utility in the standard system simulates the functionality of the subsystem, which is to report the process status to the SAP system.
Prerequisites for Testing an Outbound Process
The outbound process is composed of programs that are linked to run one after another. To test each component separately, we have to make the following settings to ensure that the components are disconnected from each other and do not start the next process immediately.
If our application uses Message control, the timing of the output type should be set to 1 (Run with the Next Selection of RSNAST00) in the condition records. This setting causes the RSNAST00 program not to run immediately after creating an entry in the NAST table.
In the partner profile, set the Collect IDocs flag and the Do Not Start the Subsystem flag. These settings cause the RSEOUT00 program not to run immediately after an IDoc is created in the system.
Testing the Partner Profile
We can test partner profiles to make sure that the parameters specified are still correct. The checks are carried out are
The process code
The user to be notified
Message control consistency with outbound parameters
To check the consistency of partner profiles, we can execute the program RSECHK07. You can do this via transaction SE38 or from the menus of the initial partner profile screen. The output is a color coded report that shows the details of any problems that were found.
Testing the RFC Destination
This test confirms the connectivity between the computer system on which SAP is running and the system on which the subsystem is or will be installed.
We have to execute transaction SM59 and Click the RFC destination being used in the process. The destination is typically SERVER_EXEC, but confirm your RFC destination by viewing the details of the port definition that will be used for outbound processes. Click the Test button. If the results are positive, the connectivity is working correctly.
If the test connection returns negative results, the message should indicate the problem. If the message is not self−explanatory, you can turn on RFC trace to log every step of the RFC test.
The problem is basically the connectivity between the two systems. The possible causes of errors are
1.The RFC destination is using an explicit host name to reach the destination system, and this name is misspelled.
2.The RFC server program (typically rfcexec) is unreachable; may be this program does not exist on the destination server, or the path is unreachable or inaccessible. The path name and program name are case sensitive. The ID used to access the files is
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.
Here we have to execute transaction WE21 and 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.
1.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.
2.If access to the file system is via NFS (Network File System), the NFS mounts should be v verified from the application server to which you are logged on.
The previous post deals with SAP ABAP WORK FLOW setting using EDI
What is SAP Full form and its definition part one
SAP Full form and introduction part two
SAP architecture,its full form of working and enjoy sap products
SAP Full from and Drive from R/3 to MySAP.com
No comments :
Post a Comment