This blog will show you how you can track your ERP report through the Duet landscape from the Duet client via the Add-On server to the backend system and back to the Duet client. The flow of data is similar in case you are running a BW query; this blog shows the flow by running an ALV report in an SAP ERP system.
Running the Report
In the first step, you will need to run your report from the Duet client using the report template. In this example I picked an ALV report BALVEX02 which displays a list of flights from the good old flight model. When you hit the "Run" button, the Duet client will call the Web Service "ReportingFacadeWS" on the Duet Add-On server in order to schedule this report in the backend. While the client is performing the HTTP call, you should see a spinning icon at the bottom of the Duet action pane:
Take a look at the Web Service call
By using one of the many network sniffers out there like YATT, you can see the actual SOAP request and response of the Web Service call for the scheduling:
Check if the report was scheduled
In order to check if your report was scheduled for processing in the backend, you can first go to the Add-On Server and have a look at the default trace file of your J2EE engine (Make sure that you set the severity of the locations "com.sap.xapps.osp" and "com.sap.mw.jco" to ALL by using the Log Configurator of the Add-On J2EE). From there, the Duet Web Service for Reporting will call the backend via JCO in order to schedule the report execution as a job in sm37. In case of ERP reports, this is done by calling the funciton module /OSP/REPORT_SCHEDULE: If the scheduling worked out, you should see an entry like this in your trace file: For the scheduling to work, the Assertion Ticket logon needs to work between your Add-On server and the respective backend system. In your backend system, you should now be able to find a new entry in transaction sm37 for your user. In this example it is the job with id 7AC89925BC25C44F9F34517616FC96BF:
How the report is executed and sent
The programm that is scheduled in the backend system for ERP reports is /OSP/REPORT_INTERCEPTOR. So /OSP/REPORT_INTERCEPTOR actually executes our example report BALVEX02, and /OSP/REPORT_INTERCEPTOR is also responsible for sending the result of BALVEX02 back to the Add-On Server. This is done by using the logical port /OSP/CO_REP_ADAPTER_WSVI_DOCUM, which itself uses an HTTP Connection to the Add-On's Web Service "RepAdapterWS". For the report sending to work, the Assertion Ticket logon needs to work between your backend and your Add-On server. Additionally, make sure your logical port is the default port and active. Now that the report output has made its way to the Add-On server, an email with the report data will be generated and sent to you. In the Add-On's default trace file you should see entries like these: The Add-On uses the "sap.com/xapps~osp~formatter~wsproxy/com.sap.osp.formatter.wsproxy.formatter/FacadeSoap" Web Service destination of the J2EE engine to trigger the Microsoft Request Handler to send this email to your user. So you have to make sure that this destination is configured for BASIC Authentication and that the Request Handler Web Site on the IIS of your Duet Server is also configured for BASIC authentication.
See the control messages on the client
Now you should be able to see the delivered report data on your Duet client. By using the "Web" Toolbar, enter the following folder name "outlook:obacontrolmessages": This hidden folder is the one in which all so called control messages, like the CREATE message for a newly delivered report, are delivered to. From there, they are picked up by a clientside component called Control Message Processor (CMP) and moved to the corresponding location; in this case the "Reports" folder. This is the last queue in which the report data ends up. As the interval in which the CMP runs is determined by the group policy setting "Synchronization frequency", all messages can be technically delivered to your Mailbox, but as long as the CMP has not processed them, you will not be able to see them in your Inbox or as a new entry in your "Reports" folder. Remember that when we ran the report from the template, we marked the checkbox "E-mail me a notification when this report is delivered" ? This results in the fact that you receive not only the report data as a new email in your reports folder, but also a plain email which tells you that the report you requested has been delivered to your "Reports" folder.
In contrast to the email which contains the report data, this notification email does not go to the "outlook:obacontrolmessages" folder; it goes directly to your Inbox. So you will always see this notification email first before you see the actual report output in your "Reports" folder. This is because one of those messages goes via the "outlook:obacontrolmessages", and one doesn't. One last word regarding the hidden folder OBAControlMessages: under no circumstance should you delete any messages from this folder, you could mess things up big time. Just don't do it.