FYI that is not XML on the laptop screen. It’s hard to find an aesthetic XML picture. Cheers.
XML Documents in SAP are usually involved during integration or interfacing functionalities. One good example is when a third-party software is involved and sends data (in the form of .xml file) to SAP for processing. You can refer to the diagram below for more information.
We can associate the black arrows as inbound communication while the blue arrows will be associated with outbound communication.
There will be times wherein an issue is encountered, and you would need the erroneous XML file to simulate (maybe even debug) the error. There could also be instances wherein you will need to test XML files before moving certain changes to production. Either way, the steps we will discuss will cover those scenarios.
Overview
- Retrieve or Monitor the XML File – SXMB_MONI
- Testing Proper – SPROXY
- Validation
- Summary
- Additional Info
1. Retrieve or Monitor the XML File – SXMB_MONI
You will need 3 things before doing the actual testing:
- Understand The Flow in Concern – Inbound or Outbound?
- Know The Concerned Namespace
- Get Your Test Data Ready (XML File) or Monitor the XML Processing
Let’s get started!
[Understand The Flow in Concern – Inbound or Outbound?]
First, you need to understand the flow in concern. You need to understand the direction of the data if you want to simulate or perform testing. Is the XML data going to SAP? Or is the XML data going to the third-party application?
This is important because this will help you isolate the scenario and in turn populate the parameters correctly. You may refer to the table below for guidance.
| Is the XML data going to SAP? | Inbound / Receiver |
| Is the XML data going to the third-party application? | Outbound / Sender |
We say Inbound as Receiver because we understand that SAP is the one receiving the data. On the other hand, saying Outbound as Sender is understood that SAP is the one sending the data to another application.
For this example, we will cover the Inbound / Receiver scenario – A third-party application sends data to SAP for posting.
[Know The Concerned Namespace]
The second thing you will need is to know the concerned namespace and namespace interface. If this is an issue encountered in production (or in any SAP environment), you will need to retrieve and check on the XML file. This will be your first line of checking.
1. Go to TCode SXMB_MONI to monitor and retrieve the concerned XML File.
The transaction code can be used as high level monitoring and it can be utilized to save XML files for testing. To save or locate the XML Files, you need to know the namespace and namespace interface.
2. Click on Monitor for Processed XML Messages as highlighted below.
3. You will be presented with the screen below. The important parameters to fill out would be the:
- From Date/Time
- To Date/Time
- Interface Name + Interface Namespace (SENDER or RECEIVER).
4. This is the part where you need to determine or isolate the scenario to sender (outbound) or receiver (inbound).
In most cases, there are a lot of XML messages that have been processed in the system so it is best to narrow down the parameters to locate the concerned XML. The same goes if you are just looking for a reference XML.
In this example, we focus on the Receiver results of the XML Messages. If a third-party application sends data to SAP for posting, it should pass through SAP PI and eventually passed to SAP.
SXMB_MONI in this case will be used to monitor and check on the inbound / received messages.
Tip: If you are unsure of the Interface Name and Interface Namespace, you can always click on the selection icon and do a wildcard search (*) of the name.
[Get Your Test Data Ready (XML File) or Monitor the XML Processing]
This brings us to the third need or requirement: monitoring and / or getting the XML file. After executing SXMB_MONI with the necessary parameters, we will see the screen below.
If you are aware of the timing on XML sending to SAP, you can sort and select according to the closest time frame.
1. If you are dealing with a narrow set of test data, select on one row and double click on the receiver namespace (highlighted in red) to see more details.
I do this so I prevent clicking on the flag or accidentally do unintended processing.
By default, I have 2 windows open. If you want to see the actual XML file in concern, expand the Inbound Message flag and look for the Payloads Folder.
2. Expand the contents of the payloads folder (highlighted in red) and double click on the xml (highlighted in orange). After double clicking, you should see the xml contents on both windows.
You can do some further analysis in this view.
3. If you need to download the XML file as reference test data (or as data for replication), click on XML Message > Download Window 2.
In this example, the content I need is in Window 2 but if you are unsure, you can freely download both or save the entire message version.
2. Testing Proper – SPROXY
Now that you have your reference XML or test XML file downloaded, we can proceed to TCode SPROXY to do actual testing. In this Transaction Code, we will be able to simulate the inbound / outbound scenario for XML.
Again, our example focuses on the inbound. We can clearly restrict it to that behavior because we know the dedicated namespace and namespace interface for our inbound scenario.
1. Once you are in TCode SPROXY, Select Enterprise Services Browser. You will see the screen below.
2. You will now expand the namespace selection (highlighted in orange) below.
After which, you can traverse the list and look for the namespace you are concerned with. In our example, it is http:// random.com/test/module.
3. Expand that namespace selection and look for Object (highlighted in Red).
After expanding the Objects, locate for the namespace interface in concern (highlighted in red) below. Notice how the icon differs to the rest. The circle icon with red color corresponds to “Service Provider” while the plain circle icon corresponds to “Service Consumer”. To more about the difference, check out the Additional Information portion at the end of this post.
4. Double click on the namespace interface.
After double clicking on the namespace interface (our example being SI_DataArray_In_Async), you will see several details on the right-hand side of the screen. We can clearly see that it is an INTF Interface ABAP Object etc.
5. To proceed with the actual testing, click on the Test button (highlighted in red with arrow).
Your screen should now pattern the screenshot below. Since we have our XML file downloaded, it would be easier to just load a skeletal or general request template (highlighted in red) below.
If you plan on doing some debugging (optional), SPROXY allows you to do so using the options (highlighted in purple) below.
6. Select those that best fits your need (or just the Debug Method) and click on the Execute Button (see arrow) below.
After executing, you will see a general xml request template below. Notice that there is existing dummy information provided such as “String 1”, “String 2”, String 3” etc. This serves as general data where you can edit and replace the dummy information with realistic values.
Again, we don’t need to manually update this template. Why?
7. We can simply load our downloaded XML to this tool by clicking on the Load File Button (highlighted in red) below.
Note: You need to be wary of the existing test data in your test environment. It is possible that the XML data you pulled, may not necessarily have the exact same data in the test environment. If that is the case, you can create a copy of that XML and slightly manipulate the values according to your test need.
For example: if Vendor 12345 is blocked in the Test Environment and it has been unblocked in the Production Environment, you may want to pattern the master data or slightly modify the XML file to have a valid vendor. At the end of the day, it helps to setup your test data accurately and know the overall process / behavior, so the scenario is well replicated.
8. After clicking on the Load File Button, select your XML file and click open.
9. After loading the XML file, click on the Execute Button (highlighted in red) to start testing.
If testing goes well, you should receive a notification like this: “Successful with empty result – commit may be required”.
10. Go to Extras > Trigger COMMIT WORK to complete the testing.
If there are formatting issues, SAP will inform you that there is an error during testing.
In most cases, the formatting can be right but there are issues with the related program. This is where the debugging serves useful. SPROXY will not explicitly tell you there is an error. Rather, you will have to check on it through debugging to see where the issue lies.
3. Validation
It helps to know the behavior and process flow of your testing. If the expected end result is that data is being posted to SAP Tables, then you can check on the corresponding tables. If the expected end result is to post an accounting document, you can check on the recently posted accounting documents.
In most cases, it is easier to check on the corresponding SE16 or SE16N tables to see if the expected entries are visible. After which, you can proceed to check on other SAP related validations.
4. Summary
- RETRIEVE OR MONITOR THE XML File – SXMB_MONI
- [Understand The Flow in Concern – Inbound or Outbound?]
- [Know The Concerned Namespace]
- Go to TCode SXMB_MONI to monitor and retrieve the concerned XML File.
- Click on Monitor for Processed XML Messages.
- You will be presented with the next screen. The important parameters to fill out would be the: From Date/Time, To Date/Time, Interface Name + Interface Namespace (SENDER or RECEIVER).
- This is the part where you need to determine or isolate the scenario to sender (outbound) or receiver (inbound).
- [Get Your Test Data Ready (XML File) or Monitor the XML Processing]
- Select on one row and double click on the receiver namespace to see more details.
- Expand the contents of the payloads folder and double click on the xml . After double clicking, you should see the xml contents on both windows.
- If you need to download the XML file as reference test data (or as data for replication), click on XML Message > Download Window 2.
- TESTING PROPER – SPROXY
- Once you are in TCode SPROXY, Select Enterprise Services Browser.
- Expand the namespace selection.
- After expanding the namespace selection, look for Object.
- Double click on the namespace interface.
- To proceed with the actual testing, click on the Test button.
- Select those that best fits your need (or just the Debug Method) and click on the Execute Button.
- Load your downloaded XML to this tool by clicking on the Load File Button.
- After clicking on the Load File Button, select your XML file and click open.
- After loading the XML file, click on the Execute Button to start testing.
- Go to Extras > Trigger COMMIT WORK to complete the testing.
- VALIDATION
- SE16 or SE16 Table Checks
- Other SAP Checks
5. Additional Information
SAP Integration and Interfaces
XML files through SFTP is not the only integration or interface method. There are other existing options. If you want to know more about SAP integration / interfaces, feel free to check out this post: SAP Interfaces In A Nutshell | RFC, BAPI, IDOC, EDI, ALE, UDDI, SOAP, WSDL, REST, API, FTP, SFTP . In the Service Provider vs Service Consumer portion, I briefly mentioned SOAP, WSDL, and UDDI. These are also explained in the linked interface nutshell article.
Third-Party Applications and XML Files
As mentioned in the overview of this post, the need for XML files arise when interfaces or integrations need to be tested. This scenario is highly applicable for those companies with system architectures that involve third-party applications.
The concerned third-party application can send or receive data from SAP by XML form. This is not necessarily a direct interface as SAP PI would most likely be involved.
Pay Attention To The Acknowledgements
There are instances wherein it is not a one-way street. I mean to say that if a third-party application sends data (in the form of XML) to SAP, the third-party application can in turn expect another XML from SAP. This can act as as “acknowledgement” or “confirmation” on the processing of data in SAP.
Given this scenario, you will need to test on both sides (sender and receiver).
Understand the Process Flow and Behavior
One key tip for issues that arise, is to really understand the flow and behavior of the concerned system. For example, if the third-party application sends data to SAP and expects an acknowledgement, this is a good indicator to pinpoint where the issue lies.
If the third-party was able to send the data but there is no trace on SAP, then the flow of the data must have been cut off at one point. Most likely it would be before reaching SAP. This in turn gives you a clue as to where the checking should be done – maybe SAP PI or even the third-party application.
Analysis – Are There Recent Changes?
It also helps to know if there are recent changes that happened. You can in turn use the information to focus your check on those functionalities / behaviors that were recently changed.
Overall, this type of testing requires a certain level of process and functionality understanding because it involves 2 or more systems.
Be Careful When Testing SPROXY
Caution and careful execution should be practiced especially when dealing with SPROXY in the production environment. As much as possible, you need to ensure that data isn’t being accidentally processed.
It is possible that you did not execute the COMMIT but the data would still be processed in SAP. It would depend on the behavior of the program or how SAP is tasked to handle the XML. Overall, it is best to double check and be aware of any unintentional changes.
Service Provider vs Service Consumer
Earlier we mentioned: The circle icon with red color corresponds to “Service Provider” while the plain circle icon corresponds to “Service Consumer”. The simplest explanation would be the following:
| Web Service Consumer | Consumes external Web services |
| Web Service Provider | Exposes business processes, services, or both as Web Service |
In our example, we used the “Service Provider”. Let us ask the question: What instance is providing the service? SAP in this context is providing the service because it treats it as an Inbound Web Service. It is is receiving the data from another source and doing the necessary processes. As additional info, this setup also sends an acknowledgement back to the third-party system to give it an update. This means this Web Service Provider is exposed through proxy technologies for external clients / systems to use.
“Service Consumer” on the other hand considers the Web Service of another / external source. In our example, SAP is sending data to another source – this outbound scenario needs the Web Service of the external source. SAP can be dependent on the Web Service of the external source.
On a high level note we can say Inbound = Provider while Outbound = Consumer. SAP is now both the Provider and Consumer (using different service instances) given the scenario. Note that it would depend on the context. This is not a always a simple heads or tails scenario as it involves a deeper kind of understanding.
There is of course a more technical explanation and background to this. if you’re interested, you can refer to this SAP Help Document on Creating and Configuring Service Provides and Service Consumers or research more about Web Services. The document also talks about Web Service Standards such as SOAP, WSDL, and UDDI.
Another way of looking at the difference can depend on the requirements. If you need to create a new Function Module and Web Service, it would most likely be a Service Provider. If you are given a WSDL or API, then it would most likely be a Service Consumer. Again, it would depend on the overall functionality and requirements. The same explanation applies as above.
I hope this helps. Good luck! 😊
Techlorean. 
One thought on “How To Fully Test XML Docs in SAP – SPROXY SXMB_MONI”