To check weather the electronic data interface of SAP is working properly or not we do have different test to do.
We do test various components of SAP ABAP EDI Inbound process and they are
We do test various components of SAP ABAP EDI Inbound process and they are
- The inbound triggering process ·
- The successful creation of IDocs in the database ·
- The posting of the application document.
A multitude of errors can be related to data errors. Detailed information about a specific error is also logged in the status record, and an error workflow is started to notify the person responsible for handling the error. If your posting program uses the Call transaction to post the document, you can step through every screen to determine the exact location of the error.
This can be shown diagrammatically as shown below.
How do we Verify the Inbound Triggering Process ?
This step tests the connectivity between the subsystem and the SAP system.This test requires the process to begin at the OS layer using an IDoc file.
The results of executing the startrfc command are displayed at the command line where you started the program. The errors are usually from message class E0. If you see a message with E0, you can use transaction SE91 to look up the details of the message. If the error message is unclear, you can turn on the trace when executing startrfc to view detailed information.
The problems in this test could be
1.Permission problems in executing the startrfc command. You must have proper authorization to execute operating system commands.
2· Problems with input parameters. The parameters must be specified according to the syntax. It may be the user ID and passwords have problems. You can use your logon ID to test the process.
3·Problems with the gateway services. You can use transaction SMGW to check the status of your gateway services. Gateway services are used for every CPI−C communication, and RFC is implemented using CPI−C protocols. Check with your Basis staff for appropriate gateway service
values.
4·Problems accessing the inbound file. The file system, if NFS mounted, might not be available, or SAP does not have authorization to read the file.
5· If this step is successful, an IDoc should be created in the SAP database .and don't bother errors in the IDoc at this stage. The scope of this test is limited to ensuring that the triggering process works.
How to Verify the Creation of Successful IDocs ?
In this step, we use the information in the IDoc's control record to verify that a partner profile is found and that the IDoc is created without any structural errors. This step is useful for custom IDocs when you want to make sure that the incoming IDocs are structurally correct.
Here we have to start the inbound process with one of the utilities and shall not start from a file.
The results are logged in the IDoc's status records. You can display the status records by using the IDoc display utilities. If an error occurs, the IDoc gets a status code of 56 (IDoc with Errors Added), and an error workflow is started.
The person notified in this case depends on whether a partner profile could be read. If a partner profile was found, workflow is sent to the person specified in the partner profile. If a partner profile entry could not be read, the message is sent to the IDoc administrator.
Common problems in this step are related to data in the control record and to syntax errors in the IDoc. The parameters in the control record must match the key of the partner profile record for that inbound message.
The status records should give you the specific details. If this step is successful, you will see an IDoc that has a status code of 64 (IDoc Ready to Be Passed to Application).
How to Verify the Posting of Application Documents?
The transaction code is BD87.
The logic for posting an application document is coded in inbound function modules. Verifying the logic of the inbound function module is the most important step for custom function modules. You verify not only that the posting function module is working correctly, but also that the logic and interface of the function module are correct. If problems exist, you might also want to debug the process one step at a time.
The IDoc created in the "Verifying the Creation of Successful IDocs" section is used to test this process. To start, execute program RBDAPP01 via SE38, or execute BD87. Then, enter your IDoc number and start the process. The selection screen for the RBDAPP01 program appears in Figure below.
Errors in this step are mainly related to data errors and are logged in the status records of the IDoc. You can display the status records by using the IDoc display utilities. The IDoc gets a status code of 51 (IDoc with Errors Added).
The common problems in this step are either data related or in the application configuration, so you must make sure that the data values are correct in the data record fields. Check your program logic for any errors.
If this step is successful, an application document is created, and the IDoc gets a status code of 53 (Application Document Posted). The document number is logged in the status record. For example, if an incoming IDoc creates a sales order number 10000, this number appears in the last status record.
The previous post deals with SAP ABAP EDI Inbound process utilities.
The previous post of the blog deals with EDI Testing outbound process.
How do we Verify the Inbound Triggering Process ?This step tests the connectivity between the subsystem and the SAP system.This test requires the process to begin at the OS layer using an IDoc file.
The results of executing the startrfc command are displayed at the command line where you started the program. The errors are usually from message class E0. If you see a message with E0, you can use transaction SE91 to look up the details of the message. If the error message is unclear, you can turn on the trace when executing startrfc to view detailed information.
The problems in this test could be
1.Permission problems in executing the startrfc command. You must have proper authorization to execute operating system commands.
2· Problems with input parameters. The parameters must be specified according to the syntax. It may be the user ID and passwords have problems. You can use your logon ID to test the process.
3·Problems with the gateway services. You can use transaction SMGW to check the status of your gateway services. Gateway services are used for every CPI−C communication, and RFC is implemented using CPI−C protocols. Check with your Basis staff for appropriate gateway service
values.
4·Problems accessing the inbound file. The file system, if NFS mounted, might not be available, or SAP does not have authorization to read the file.
5· If this step is successful, an IDoc should be created in the SAP database .and don't bother errors in the IDoc at this stage. The scope of this test is limited to ensuring that the triggering process works.
How to Verify the Creation of Successful IDocs ?
In this step, we use the information in the IDoc's control record to verify that a partner profile is found and that the IDoc is created without any structural errors. This step is useful for custom IDocs when you want to make sure that the incoming IDocs are structurally correct.
Here we have to start the inbound process with one of the utilities and shall not start from a file.
The results are logged in the IDoc's status records. You can display the status records by using the IDoc display utilities. If an error occurs, the IDoc gets a status code of 56 (IDoc with Errors Added), and an error workflow is started.
The person notified in this case depends on whether a partner profile could be read. If a partner profile was found, workflow is sent to the person specified in the partner profile. If a partner profile entry could not be read, the message is sent to the IDoc administrator.
Common problems in this step are related to data in the control record and to syntax errors in the IDoc. The parameters in the control record must match the key of the partner profile record for that inbound message.
The status records should give you the specific details. If this step is successful, you will see an IDoc that has a status code of 64 (IDoc Ready to Be Passed to Application).
How to Verify the Posting of Application Documents?
The transaction code is BD87.
The logic for posting an application document is coded in inbound function modules. Verifying the logic of the inbound function module is the most important step for custom function modules. You verify not only that the posting function module is working correctly, but also that the logic and interface of the function module are correct. If problems exist, you might also want to debug the process one step at a time.
The IDoc created in the "Verifying the Creation of Successful IDocs" section is used to test this process. To start, execute program RBDAPP01 via SE38, or execute BD87. Then, enter your IDoc number and start the process. The selection screen for the RBDAPP01 program appears in Figure below.
Errors in this step are mainly related to data errors and are logged in the status records of the IDoc. You can display the status records by using the IDoc display utilities. The IDoc gets a status code of 51 (IDoc with Errors Added).The common problems in this step are either data related or in the application configuration, so you must make sure that the data values are correct in the data record fields. Check your program logic for any errors.
If this step is successful, an application document is created, and the IDoc gets a status code of 53 (Application Document Posted). The document number is logged in the status record. For example, if an incoming IDoc creates a sales order number 10000, this number appears in the last status record.
The previous post deals with SAP ABAP EDI Inbound process utilities.
The previous post of the blog deals with EDI Testing outbound process.
No comments :
Post a Comment