Introduction

With the workarounds introduced below you won't be able to navigate between objects but you can create,
change and display data. So this is not something you will be using in productive mode, rather it will help
you to understand some inner workings of SRM 7.0. I found it very helpful during a customer project where
the setup of portal infrastructure and business package installation were delayed. Also there were times
when the portal just wasn't available due to maintenance or other issues. In those cases the
developers were still able to run certain SRM scenarios and continue working, because they were able to
create the URLs for a particular object by themself and call that application.
For those of you who don't know yet, here is some technical background information regarding SRM 7.0:

SRM 7.0 requires Enhancement Package 1 of SAP

NetWeaver 7.0

SRM 7.0 applications are build completely on the Web

Dynpro ABAP user interface technology

SRM 7.0 applications are integrated through the Floorplan

Manager for Web Dynpro ABAP

another popular Web Dynpro ABAP component heavily

used in SRM 7.0 is the POWL (also known as POWER List)

Michael Judd from SAP has collected some nice videos guiding you through a couple of SRM scenarios on
SCN
(http://www.sdn.sap.com/irj/scn/weblogs;jsessionid=(J2EE3414700)ID0390806350DB01461547595717822
945End?blog=/pub/wlg/14843).
SRM 7.0 Application URLs
Let's first have a look at the Web Dynpro ABAP URLs used to access SRM applications. A typical URL for
accessing any Web Dynpro application, e.g. on your NSP installation, could look like this:
__http://nsp.mysystem.com:8000/sap/bc/webdynpro/sap/wdr_test_ui_elements?sap-language=de&sapclient=100
The different parts of the URL in this example are:
Protocol
Hostname
Domain
Extension
Port
ICF-Path
Application
Parameter 1
Value 1
Parameter 2
Value 2

http://
nsp
mysystem
com
8000
/sap/bc/webdynpro/sap
wdr_test_ui_elements
sap-language
de
sap-client
100

SRM applications are based on the SAP Floorplan Manager for Web Dynpro ABAP. They are using either the
Object Instance Floorplan component (FPM_OIF_COMPONENT) or the Guided Activity Floorplan component
(FPM_GAF_COMPONENT). The OIF is implemented e.g. for the professional shopping cart and the purchase
order, the GAF is implemented e.g. for the shopping cart wizard and the sourcing cockpit. The name of the
OIF application is /SAPSRM/WDA_L_FPM_OIF.
Now this application is used for all SRM applications that are based on a object instance floorplan, e.g. the
professional shopping cart, the purchase order, the bid invitation and so on. In order to differentiate the
layout, certain functions and the components which are used, there are different Web Dynpro configurations
defined. The parameter through which the configuration ID is passed is sap-wd-configId. In order to
differentiate the mode on which the application is started, i.e. whether an object will be created, displayed

or changed, a parameter with the name sapsrm_mode is used. Valid values for that parameter are CREATE,
DISPLAY and CHANGE. Furthermore the business object needs to be determined and its object ID passed to
the application. This can be achieved through parameter sapsrm_botype. The values passed through this
parameter are the business object IDs, e.g. BUS2121 for the shopping cart or BUS2201 for the purchase
order. There are a few more parameters available but with the information provided up to this point we can
already go ahead and create a first valid URL. An example URL for creating a shopping cart using the
professional shopping cart application looks like this:
__http://srm.company.com:8000/sap/bc/webdynpro/sapsrm/wda_l_fpm_oif?sap-language=de& sapclient=100&sap-wd-configId=%2fSAPSRM
%2fWDAC_I_FPM_OIF_SC_PROF&sapsrm_mode=CREATE&sapsrm_botype=BUS2121
The different parts of the URL in this example are:
Protocol
Hostname
Domain
Extension
Port
ICF-Path
Application
Parameter 1
Value 1
Parameter 2
Value 2
Paramter 3
Value 3
Paramter 4
Value 4
Parameter 5
Value 4

http://
srm
company
com
8000
/sap/bc/webdynpro/sapsrm
wda_l_fpm_oif
sap-language
de
sap-client
100
sap-wd-configId
/SAPSRM/WDAC_I_FPM_OIF_SC_PROF ("/" needs to be encoded)
sapsrm_mode
CREATE
sapsrm_botype
BUS2121

Providing the URL shown above just replace the parts hostname, domain, extension and port with the valid
values of your server environment. Now let's try to start the application. After doing so you should see a
screen as shown in figure 1. The application doesn't start up and tries to close the browser window. How
could that happen?

Figure 1: Initial start outside of the portal

Well, the SRM application always runs a check routine which asks for the portal instance. If this object is not
available, i.e. the application was started outside the portal, and certain other conditions are not met then
the application simply exits. In order to avoid this we need to do a little change in the coding provided in the
SRM standard. This can be done by utilizing the features of the enhancement framework.
Enhancing the SRM 7.0 Startup Scenario
Method CHECK_STANDALONE_ALLOWED of class /SAPSRM/CL_FPM_OVRIDE_HDLR is running a check
routine which determines whether certain starting conditions are met. In case the application was started
outside the portal then returning parameter RV_LEAVE_APPLICATION is set to abap_true (or 'X'). This will
cause the application to shut down and close the browser window (see figure 1). Inside of this method
another call is made to an instance of the assistance class. The method of the assistance class has the same
name, i.e. CHECK_STANDALONE_ALLOWED. This method now checks the availability of the portal manager
instance, which does only exist when the application is called from the portal.
Following the comments in the ABAP coding you can see, which further conditions are checked which
are important e.g. when the SAP support is running the application. It seems that a certain URL parameter
needs to be provided. However, we will not dig deeper into this, since the enhancement framework provides
sufficient functionality in order to achieve our goal, i.e. to invalidate the portal check result. If we'd be able
to achieve that the returning parameter RV_LEAVE_APPLICATION remains initial, then this would keep the
application from shutting down.
The following steps show how to solve this:
A. Create an enhancement
1. Use transaction SE80
2. Display class /SAPSRM/CL_FPM_OVRIDE_HDLR
3. From the main menu select Class -> Enhance
4. Enter name and description of the newly created enhancement (see figure 2)

Figure 2: Create an enhancement implementation

5. Save the new enhancement as Local Object'

6. Select the new enhancement from the list of available enhancements (see figure 3)

Figure 3: Select enhancement object

After you have created and selected the enhancement object of class /SAPSRM/CL_FPM_OVRIDE_HDLR you
are now able to implement certain pre-, post -and overwrite exits for methods of this class. In our case we
want method CHECK_STANDALONE_ALLOWED to always return an initial value in parameter
RV_LEAVE_APPLICATION.
The following steps must be implemented:
B. Implement enhancement method
1. Set the mouse cursor to method name CHECK_STANDALONE_ALLOWED and select from the main
menu Edit -> Enhancement Operation -> Insert Post-Method (see figure 4)

Figure 4: Select and implement post-method

2. An icon becomes visible in the column Post-Exit, by selecting the icon you will open the editor in order to
implement the post-method.
3. Add the ABAP statement as it is shown in line 34 of figure 5 to the post-method. Now, whatever value will
be assigned to RV_LEAVE_APPLICATION, the post-method will always set the returning value to initial.

Figure 5: Implementing the post-method

4. Save and activate the post-method.

Now we will call the shopping cart application again by using the URL as it was shown above. The result
should look like the screen shown in figure 6 below. You can see that the application is displayed in the
browser window without the portal frame.

Figure 6: Professional shopping cart application running outside the portal

The buttons Order, Save and Check will do their work. So you are at least able to do some basic testing of
the application. However, any navigation away or back to the object is not possible, since this is initiated and
controlled by the portal.
Discussion
In this how-to guide I've shown how you can run an SRM 7.0 application outside the NetWeaver Portal. By
applying this workaround you can only run a single instance of an object and it is not possible to navigate
from e.g. result lists (provided by the POWL) to other objects or between objects. Therefore, this
workaround can't be used in productive mode, but it might be an option during implementation phase when
the portal isn't always available. Any functionality regarding navigation is implemented and handled
through communication between the portal and the Web Dynpro ABAP runtime. In SRM 7.0 the navigation
type that is used is object based navigation (OBN) - other options are absolute or relative navigation.
In order to enable navigation features similar to the portal when running standalone, you would need to
implement this in a certain frame or container application which his handling the calls coming from the Web
Dynpro ABAP runtime. With the release of Enhancement Package 1 for SRM 7.0 such an application is
available providing role management based on transaction PFCG and navigation features executed through
the ABAP runtime.