IDoc Has Left The Building
SAP IDocs are a tried and true interface methodology. But as with any interfacing technology the most brittle component is the connection between the two systems (in the case, SAP and the subsystem). In scenarios where SAP is sending IDocs to a subsystem via the transactional RFC, one question is paramount:
How do you know when an Outbound IDoc has physically left SAP?
It’s a simple fact that if your subsystem never receives an IDoc from SAP, the subsystem will not be able to route or process the IDoc. I have always gone by the notion that once the subsystem has successfully received the IDoc, the subsystem now has all the responsibility to process and route the IDoc, but before that time, SAP has the responsibility to ensure that the IDoc is fully dispatched. The subsystem should have processes in place to determine if the IDoc has been received at the target system successfully or not. In this blog I will focus on the handshake between SAP and the subsystem. This will entail Outbound IDoc status and a couple of batch jobs that should be setup to ensure a better chance of a successful handoff between SAP and the subsystem.
SAP Event Driven Batch Job
When creating SAP batch jobs to run a program, most of the scheduling can be accomplished by setting a periodic time for when the job is executed. For example, execute the job every 10min, 30min, or 1 hour. But what if you needed more control of when a batch job was executed?
Turn any SAP remote-enabled function module into a Web Service – Part 2
In my previous blog I showed the steps into turning a simple function module into an Enterprise Service. Now that we have the service defined in ECC, our next step is to configure it so an external application can call our newly created service.
I will show how to configure and test the Web Service on ECC with Service pack 14 and higher. Before Service Pack 14, the configuration is completed in ECC, however after SP14 the configuration is completed on the Java Stack.
Turn any SAP remote-enabled function module into a Web Service – Part 1
It still amazes me that not a lot of developers know that you can turn any existing SAP remote enable function module into a Web Service. It may sound like a challenging task, but it is just one of those things that you either know how to do it or you don’t. And to know how to do it only takes 15min to understand.
I have broken this down into 2 blogs Part 1 will show how to create the simple structured web service Part 2 will show how to configure and test the web service using SOAMANAGER and WSNAV
Debugging Inbound Web Service calls in SAP
by Steve Park PI/ABAP consultant
Have you ever called a Web Service which is hosted by SAP just to get a generic return code that could mean anything? Do you wonder what was the exact data that was being passed in the parameter as it was executing the SAP web service? For example, when passing ‘00001’ is it really passing ‘00001’ or is it just passing ‘1’. This could be a difference between a successfully called web service or a web service call that brings back an exception.
I found an issue when testing an SAP web service when making a call from an external client. The SAP Web Service was sending back an exception to the external client that did not tell us much of anything.
This SAP web service was created from a function module so my first step was to go to the function module and input exactly what the external client tried to send and hoping to get the same exception. Surprisingly the function module came back successfully.
Since I could not figure out what was wrong when testing in SAP, my next step is to see what the external client is really passing real-time into the SAP Web Service by using the ABAP debugger. You are probably asking yourself, how in the world will SAP know when to initiate the ABAP debugger since SAP is being called from an external client?
The answer: You have to tell SAP that you are expecting a call
Here are the steps to activating the ABAP debugger for external calls. 1) In transaction SICF, find the service that you are having issues with and highlight your service then go to: Edit -> Debugging->Activate Debugging
2) Here you need to enter the user id that the external client is using when making the call. It is vitally important that it is the same user that you will be logged in SAP.
3) Make sure that you are currently logged into SAP with the same user. Now initiate the call from the external client and this time you will notice an ABAP debugger will be initiated as well. Now you can step through the code and see exactly where the problem is occurring.
4) Once you have found the problem, don’t forget to deactivate the debugger. If you forget, SAP will deactivate it automatically after a period of 2 hours.
