Many organizations have complicated NetWeaver architectures that include multiple SAP Web Application Servers (WAS) - irregardless whether these are pure Java, pure ABAP or Java/ABAP-based; all these servers can host Web Dynpros. This distribution is important in high-performance environments or where the responsibility for individual WAS is given to different individuals / organizational units; the associated motivation may be based on different organizational, regional or technical reasons.
Based on the assumption that we would like to include Web Dynpro components in our Guided Procedure (GP) processes, what are options for such distributed architectures? In particular, what are the options for landscapes where the remote WAS are running under Java.
Existing options
First, let’s look at the initial options for the integration of Web Dynpro (local or remote) content in GP? (The ability to create Web Dynpro callable objects on the fly using the “Web Dynpro Application” will be ignored in this blog.) Currently, there are the following options present:
- Web Dynpro Component (GP Interface)
- Composite Application Web Dynpro Component
- ABAP Web Dynpro Application
The first two options are based on Web Dynpro applications that are deployed on the same portal where GP is running; thus, they are largely irrelevant in our scenario.
The third option is a step in the right direction. As the tutorial for the integration of these ABAP-based components demonstrates the first step is the selection of an endpoint for the Web Dynpro application which is perfect for a distributed architecture.
Unfortunately, there is no similar callable object type for Java-based Web Dynpro. Based on the absence of an out-of-the-box solution, what are our options?
Options for Java-based WASs
There are two options that are available as workarounds based on the absence of standard solutions.
- Use the Web Pages Callable Object. Since the access to the Java-based Web Dynpro is available via an URL, you can directly type in the address into the standard definition of the object.
- Use the Portal IView Callable Object to call the remote Dynpro via an IView based on the SAP Web Dynpro IView Template.
From the perspective of the end-user, the result of the two options is the same.
What are the advantages / disadvantages of these two solutions?
Use of “Web Pages” Callable Object
Advantages
- Easy configuration
- Ability to pass on GP “IN” parameters in the process context to the remote Web Dynpro via the URL. (Use WDWebContextAdapter.getWebContextAdapter().getRequestParameterMap() in WebDynpro to access the retrieved URL-parameters.)
Disadvantages
- The server names are hard-coded into the URL
- The BPX/GP designer must know the URL and its parameters
- Use of “OUT” parameters in the process context to return values from Web Dynpro is not possible using out-of-box functionality.
- SSO may be not supported (dependent on which user authorization in the system is used)
- Exceptions are not supported
Use of “Portal IView” Callable Object
Advantages
- More flexibility inasmuch as values are not hard-coded in the URL
- SSO supported based on definitions set in the used Portal System.
Disadvantages
- More difficult configuration inasmuch as a Portal System for the remote WAS and an IView must be created and configured. Inasmuch as these activities are usually performed by roles different from those individuals working with GP, more effort may be necessary to administer related activities.
- The BPX/GP designer must know about the assistance of the IView and the portal role in which it is available.
- Use of “OUT” parameters from the process context to return values from Web Dynpro is not possible using out-of-box functionality.
- Use of “IN” parameters from the process context to send values to Web Dynpro is not possible using out-of-box functionality.
- Exceptions are not supported
Workarounds
Parameters in the process context
The present options both have problems with parameters residing in the process context. There might be one work-around using a web-service callable object (or perhaps a background process element) that sends / receives parameters to and from the remote Web Dynpro elements and then includes the results in the process chain. This solution probably would have problems dealing with coordination issues inasmuch as the call to the web-service might occur after the callable object has already ended.
Summary
Based on these current options, existing integration scenarios for remote Java-based Web Dynpros are very rudimentary and not really satisfying. However, the current corporate environment is based on processes that include remote Web Dynpros; thus, the use of the described options are a first step to creating complete GP processes that reflect real-life processes.
This blog is based on 2004s SP8 environment. Hopefully, future developments include a callable-object that is similar to the ABAP Web Dynpro Application but available for Java-based WAS.
