The title of this tip is a bit overly restrictive. Using the procedure described in this tip, you can actually...
perform a user switch within any ABAP program. But it will work for Web applications as well.
Enabling a user switch within your application means that you have programmatically converted from one user to another during the course of application execution. Because SAP tracks all user interaction within the system, a user switch allows one user to masquerade as another, including changes recorded within a transaction's change history. From a Java/JCo perspective, enabling a user switch has several important functions.
As seen in my previous Java tips, JCo relies on a connection object that is created with a specific userid and password. This means that if your Web/Java application requires a named user ID in SAP, you must instantiate a unique instance of the JCo connection class for every user. Although this may not seem like a problem, such a deployment can kill performance once a high volume of traffic is coming through the application.
JCo does offer connection pooling to reduce some of this additional overhead. A connection pool maintains a set of connections that can be checked out and in as your application's usage varies. The major limitation with JCo's pooling mechanism is that each connection uses the same user ID and password. This is fine for a browsing or catalog style application, where you do not need to track the users in SAP. However, if your application needs to create or update data in SAP, you would likely want to track this by a named user ID in SAP. See my previous tip on connection pooling with JCo for more information.
So, the challenge is to utilize JCo's connection pooling mechanism for high performance and still support unique user IDs in the SAP system. Fortunately, there is a relatively simple solution - implement a user switch in each RFC that will update SAP. The major caveat here is that you will need to build a custom RFC wrapper around each standard SAP RFC or BAPI that requires a user switch. This custom RFC development is straightforward ABAP, so I will not get into it here.
Your custom RFC wrapper must first call the function module 'SUSR_INTERNET_USERWITCH'. This function takes a user ID and password and converts the original, connecting user to the named user specified to this function. Imagine that you have created a JCo connection pool and populated in with ten connection objects all using the SAP system user 'DUMMY'. Without the user switch, any RFC or BAPI you execute with JCo will be attributed to the user 'DUMMY' in SAP. By calling the user switch before executing the actual RFC or BAPI, the user 'DUMMY' becomes whatever unique user ID that has been passed in by the Web/Java application. Of course, this user must still be a valid SAP user so that SAP can record changes in the appropriate logs.
The following demonstrates the user switch function:*
data: username type usalias, password type bapipwd, password_state type xupwdstate, new_username type ususername, error_table type table of bapiret2. call function 'SUSR_INTERNET_USERSWITCH' exporting * This example assumes an alias has been created for the SAP user ID * If not, you need to export the field username: * username = username alias = username password = password importing bname_after_switch = new_username password_state = password_state tables return = error_table exceptions current_user_not_servicetyp = 1 more_than_one_mode = 2 internal_error = 3 others =4.
You will need to build a quick RFC application to test this function, rather than using the Function Builder. The reason is that this function needs to switch from a 'Service' user type and will not work from a 'Dialog'-based user type.
User switching is a powerful way to optimize a Web application without sacrificing SAP's built-in change history and logging. However, you should excercise caution when building and deploying your application. Make sure that the user switch cannot be compromised and allow an unauthorized user to switch to an authorized user. Mainly, this is done by passing the unique SAP user's password to your custom RFC wrapper, thereby insuring the only the authorized user can perform a user switch.
How can SAP custom development be limited?