Additional Blogs by SAP
cancel
Showing results for 
Search instead for 
Did you mean: 
stefan_schwing
Active Participant
0 Kudos

Introduction

    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.