Updated!: Calling a BSP application from a SAPGui Transaction
There has been some recent discussion on the ABAP forum about Calling a BSP application from a report. I thought I might share a solution we have used at our company. Please note that is weblog was updated on 9/14/2004 with a suggestion from Brian McKellar.
We developed a simple RFC that can be called locally on our WebAS or remotely from our R/3 or BW systems. This RFC will display a screen that has a HTML View control in it. You might be thinking – What’s so special about that. Well good question. There are two advantages to doing it this way.
Single Sign On
First you get Single Sign On with very little effort. This is new functionality that is available only with a combination of certain support packages, kernels, and SAPGui patches. The details and profile parameter changes necessary can all be found in OSS note 612670. However if you are already at the required patch levels, it should only take a few minutes to make the necessary configuration changes.
We accomplish this simple state management with a combination of two things. First we add a simple exit.htm page to any application that we want to load into this RFC. This exit page has no coding in its layout. All we want is to have the following code in the OnInitialization event.
This will close out our session and clean up after our stateful application. Updated!: Brian McKellar has suggested an even better approach. He suggests the following: For a more simplified approach, we do not create an extra dummy page inside the application. Instead we use two interesting features from ICM and BSP together. The ICM supports a sap-sessioncmd=CANCEL mode. With this, the session is killed by ICM, and then the incoming URL is still processed inside a new session. We just require an URL that looks exactly like the application URL in the part up to the name of the application, so that the session id cookie will be send with it. After ICM has cancelled the session, the URL will still be processed. So we require an URL that will be processed by the BSP runtime without any problems (and without opening a new session!). For this, we just use a special 1×1 URL. The BSP runtime has a performance improvement that will always reply with a 1×1.gif for an incoming URL of the format “…/1×1”. However, this 1×1 image is cached, and the trick will only work once. So we just add one timestamp to make the URL unique for the browser, and have it trigger the loading of the 1×1 image.
Now all we need is a trigger to call this page. That trigger comes from the fact that we are running in an ABAP screen. Just short of the user shutting down their SAPGui without exiting the program, we should get a PAI event for any request to close the screen that holds our BSP application. That way we can force the HTML control to navigate to the exit page before we release it. It all happens so fast that the end user never sees anything.
Let’s take a look at the code for this function module in detail. First we look at the function interface with the high level code. You can see that we accept the name of the BSP application and the start page. We also have the option to display fullscreen or in a modal dialog box.
The screen we have is really quite simple. Just define a screen as large as possible. Place a single custom container on this screen and set it to allow resizing vertically and horizontally. This will allow our HTML control to resize itself to fill the total screen area.
Next lets look at the code in the PBO (process before output). We will start off with same basic initialization.
The create_controls forms is where all the fun stuff is going on. In addition to creating our Custom Container and the HTML control, we will need to tell the HTML control that we want SSO. Then we will generate the URL to our BSP application and navigate to it.
Now we are ready to move on to the PAI (Process After Input) and respond to our only event – the request to exit. The PAI is really quite simple we take the only two OKCodes and funnel them both to an exit and free controls form.
Finally in our free_controls form we force the HTML control to log off the applicatin. The following is the original code from this weblog.
This is the new code following the suggestion from Brian McKellar: