1
Masterarbeit
Generic Web-Service Adaptation for SAP’s Business
Suite UI Framework
Kai Hu
Technische University Dresden
Fakultät Informatik
Institut für Systemarchitektur
Lehrstuhl Rechnernetze
Betreuender Hochschullehrer: Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill
Betreuer: Dipl.-Ing., Dipl.-Inf. Thomas Frambacher (SAP AG)
Dr.-Ing. Gerald Hübsch
Dr.-Ing. Thomas Springer
Bearbeitungszeitraum: 01.04.2010 bis 30.09.201
II
Selbständigkeitserklärung
Hiermit erkläre ich, dass die vorliegende Arbeit selbstständig, ohne fremde Hilfe
angefertigt wurde. Alle aus fremden Quellen direkt oder indirekt übernommenen
Gedanken sind als solche gekennzeichnet und im Literaturverzeichnis
aufgeführt.
Dresden, 28.09.2010
1
Contents
Chapter 1 Introduction .......................................................................................... 1
1.1 Motivation ................................................................................................ 2
1.2 Structure of Thesis ................................................................................... 4
Chapter 2 Background & Related Work ............................................................... 5
2.1 Background .............................................................................................. 5
2.1.1 Introduction of SAP Business Suite & Web Dynpro technology ... 6
2.1.2 Introduction of Enterprise Service Oriented Architecture ............ 12
2.1.3 Introduction of Enterprise Services Repository ............................ 15
2.1.4 Introduction of SAP NetWeaver Process Integration (PI) ............ 17
2.1.5 Introduction of Floor Plan Manager Framework .......................... 21
2.2 Related Works ........................................................................................ 29
2.2.1 Consuming Web Services with Web Dynpro ABAP ................... 30
2.2.2 Consumption via SAP NetWeaver Composition Environment .... 32
2.2.3 Consuming Web Service via JDE EnterpriseOne Tools .............. 37
2.2.4 Dynvoker Approach ..................................................................... 40
2.3 Summary ................................................................................................ 43
Chapter 3 Design ................................................................................................. 45
3.1 Generic Adaptation Overview ................................................................ 46
3.2 Role Model ............................................................................................. 49
3.3 Main Concept of Generic Adaptation .................................................... 51
3.3.1 Acquisition of attributes ............................................................... 52
3.3.2 Field catalog creation .................................................................... 56
3.3.3 Consumption via Generic Adaptation .......................................... 59
3.3.4 Message-handling Class ............................................................... 66
3.4 Generic Adaptation for Synchronous Web Services .............................. 67
3.5 Generic Adaptation for Asynchronous Web Services ............................ 70
3.6 Analysis of automation for the three processes ...................................... 73
3.7 Summary ................................................................................................ 74
Chapter 4 Implementation ................................................................................... 75
4.1 Development environment ..................................................................... 76
4.2 Important field catalog types .................................................................. 77
4.3 Important methods within Generic Adaptation Interface ....................... 78
4.4 Implementation of Generic Adaptation Class ........................................ 80
4.4.1 Implementation of processes Acquisition of attributes & Field
catalog creation ...................................................................................... 81
4.4.2 Implementation of process Consumption via Generic
Adaptation section one .......................................................................... 84
4.4.3 Implementation of process Consumption via Generic
Adaptation section two .......................................................................... 86
4.5 Summary ................................................................................................ 88
Chapter 5 Evaluation ........................................................................................... 89
5.1 Synchronous Web Service via Generic Adaptation ............................... 90
5.1.1 Synchronous Web Service for List Generic UIBB ....................... 90
5.1.2 Synchronous Web Service for Search Generic UIBB .................. 93
5.1.3 Two synchronous Web Services for two Generic UIBBs ............ 96
2
5.2 Asynchronous Web Service via Generic Adaptation ............................. 99
Chapter 6 Summary and Outlook ..................................................................... 102
6.1 Summary of the thesis .......................................................................... 103
6.2 Outlook ................................................................................................. 105
Bibliography ..................................................................................................... 107
1
Chapter 1 Introduction
SAP solutions as the most popular software are affecting the business software
world. One of the SAP solutions, SAP Business Suite, is a bundle of business
applications that provides the integration of business information and processes,
collaboration, industry-specific functionality, and scalability. SAP UI framework
on the top of SAP Business Suite provides the user interfaces for the SAP
products belonging to SAP Business Suite, such as Human Capital Management,
Materials Management and Financial Services, etc. Floor Plan Manager
Framework as the standard UI framework for new SAP Business Suite
applications was introduced in 2006, and it has been widely used along with the
SAP Business Suite applications since.
Due to the benefit of Web Services compatibility for different platforms and
heterogeneous systems, the demand to adapt SAP Business Suite applications by
consuming Web Services is increasing. However the way to consume Web
Services within SAP UI framework needs lots of manually work. Therefore it
would be much better to enhance the consumption of Web Services by bridging
the gap between SAP standard UI framework and Web Services with a new
solution.
2
1.1 Motivation
Floor Plan Manager Framework, based on Web Dynpro ABAP, is the standard
Business Suite UI framework for easy, efficient and highly-configurable
application development and adaptation. With the advantages below:
1. Easy configuration;
2. Dynamic behavior with coding possible;
3. Compliance with all UI guidelines guaranteed;
4. Modification free customers changes.
Floor Plan Manager Framework can achieve that customers are able to easily
adapt delivered UIs to their specific needs modification-free by simple UI
guidelines configuration, and also consistency across Business Suite applications
as well as 100% UI compliance can be guaranteed by means of predefined
components, which are all provided within Floor Plan Manager Framework.
On the other side, more than 5000 Web Services are published within SAP to
achieve the demand of compatibility. However, as the standard UI framework of
SAP Business Suite, Floor Plan Manager Framework consumes Web Services
needs lots of manually work, not only the coding work but also the configuration
work. Thus, the ability of Floor Plan Manager Framework to the consumption of
Web Services requires improvement. It means that it is better to introduce a new
solution based on the Floor Plan Manager Framework, which reuses the
advantages of Floor Plan Manager Framework and also provides a better
approach to consume Web Services within Floor Plan Manager Framework for
Business Suite applications.
In order to achieve the functionality with consumption of Web Services within
Floor Plan Manager Framework and bridge the gap between Floor Plan Manager
Framework and Web Services, there are two main problems to solve:
1. How to make the solution generic. Generic solution would be more
meaningful for users to consume Web Services within Floor Plan Manager
Framework. The users can consume any Web Services in the same way.
2. Secondly, how to integrate the consumption of Web Services into Floor Plan
Manager Framework. The idea is to provide a mechanism to map the attributes
of input and output parameters in the Web Services to Floor Plan Manager
Framework and easily for users to achieve their Business Suite applications.
This Thesis describes the solution with solving both of these problems and
introduces a solution, so called Generic Adaptation for Floor Plan Manager
3
Framework to enhance the way of consuming Web Services for the Business
Suite applications. This Generic Adaptation also allows the enhancement of the
field for the usage of Floor Plan Manager Framework widely and the
enlargement of the potential users. Figure 1.1 shows the diagram of Generic
Adaptation with other entities. The Generic Adaptation is used as a bridge
between Web Services and Floor Plan Manager Framework. Generic Adaptation
handles the communication between both. Therefore, by enhancing the Floor
Plan Manager Framework with Generic Adaptation, users can achieve the
Business Suite (Web Dynpro) applications by consuming business models via
Web Services.
Web Services
Enabling
Web Services
Generic
Adaptation
Floor Plan
Manager
Framework
Web Dynpro
applications
Templates for Web
Dynpro applications
Business
Models
Figure 1.1: Diagram of Generic Adaptation
4
1.2 Structure of Thesis
Chapter 2 describes the necessary background information. They are:
introduction of SAP Business Suite, introduction of Enterprise SOA,
introduction of Enterprise Service Repository, introduction of SAP NetWeaver
Process Integration and introduction of Floor Plan Manager Framework. The
second part of Chapter 2 introduces the related works, which already exist as
either products or scientific solutions.
Chapter 3 depicts the concept of the design of Generic Adaptation. It is mainly
comprised with role model, three processes of Generic Adaptation and two sub-
chapters with analysis of Generic Adaptation for synchronous and asynchronous
Web Services.
Chapter 4 gives the implementations based on the concepts and analysis from
chapter 3. And some important codes and defined types are presented here. The
chapter is focusing on the implementation of consumption of synchronous Web
Services via Generic Adaptation within Floor Plan Manager Framework.
Chapter 5 evaluates the implemented solution with different Floor Plan Manager
Framework components and with both synchronous and asynchronous Web
Services. And it also describes the drawbacks.
Chapter 6 concludes the Generic Adaptation. Based on the evaluations from
Chapter 5, the future work to enhance the solution is described also in this
chapter.
5
Chapter 2 Background & Related Work
2.1 Background
This chapter provides a brief introduction to the important architectures and
technologies, which are provided by SAP and also the related products and
scientific solution, are described in this chapter.
First of all, the relationship between the technologies, architectures and the
Generic Adaptation is described here. The Generic Adaptation enhances the
functionality of consuming Web Services within Floor Plan Manager
Framework by providing a generic solution to achieve Business Suite
applications with Web Services. To achieve this goal, the important architecture
pattern is Enterprise Service Oriented Architecture (Enterprise SOA). And in
practical world, SAP NetWeaver Process Integration (PI) is implemented as
Enterprise SOA middleware, which is responsible for the transmission and
mapping of messaging within the Enterprise SOA.
6
2.1.1 Introduction of SAP Business Suite & Web Dynpro
technology
This subchapter describes the concept of SAP Business Suite and Business Suite
applications in the first part. The second part depicts the basic UI technology,
which is Web Dynpro technology. Especially, the Web Dynpro ABAP is used as
basic UI technology for Floor Plan Manager Framework.
As one of the most important SAP solutions, SAP Business Suite is based on
SAP technology platform called SAP NetWeaver, which is the basis in all SAP
solutions. SAP Business Suite offers users an opportunity to improve business
processes efficiently and integrate business processes that enable them to
compete more effectively in their industry. [1] Integrated enterprise applications
delivered with SAP Business Suite enable enterprises to execute and optimize
business and IT strategies. Also SAP Business Suite enables the users to perform
essential, industry-specific, and business-support processes with modular
solutions that are designed to work with other SAP and non-SAP software. [1]
Figure 2.1 shows the technology stack of the SAP Business Suite and the SAP
Business Suite products.
SAP NetWeaver
SAP Business Suite
SAP
ERP
SAP
CRM
SAP
PLM
SAP
SCM
SAP
SRM
Figure 2.1: SAP Business Suite
7
In the Figure 2.1, SAP Business Suite is a summarization of five SAP Business
Suite products, including:
Enterprise Resource Planning (SAP ERP);
Customer Relationship Management (SAP CRM);
Supply Chain Management (SAP SCM);
Supplier Relationship Management (SAP SRM);
Product Lifecycle Management (SAP PLM);
Web Dynpro is the UI technology for SAP Business Suite. Besides classic UI
technologies such as SAP Graphical User Interface (GUI) [5] or Business Server
Pages, [6] Web Dynpro ABAP as basic UI technology to represent the
NetWeaver application is mainly used for the Floor Plan Manager Framework. It
consists of a runtime environment and a graphical development environment
with special Web Dynpro tools that are integrated in the ABAP Workbench.
ABAP Workbench integrates graphical development environment in the SAP
systems. [7]
With it, the ABAP Workbench enables to develop, modify, test, and manage
client/server applications written in ABAP language, which is the programming
language special used within SAP. SAP Web Dynpro ABAP, which is Web
Dynpro technology special for ABAP language, is an important technical tool in
the development environment of web-based user interfaces. [4] Web Dynpro
ABAP offers the following advantages for application developers:
● The use of declarative and graphical tools significantly reduces the
implementation effort;
● Web Dynpro supports a structured design process;
● Strict separation between layout and business data;
● Reuse and better maintainability by using components;
● The layout and navigation is easily changed using the Web Dynpro tools;
● Automatic data transport using data binding;
● Automatic input check;
● User interface accessibility is supported;
● Full integration in the reliable ABAP development environment. [4]
Moreover Web Dynpro applications, or Business Suite applications based on
Web Dynpro ABAP, are built using declarative programming techniques. It
means that the users can specify which user interface elements they wish to have
8
on the client and where those elements will get their data from. They also can
define the possible navigation paths declaratively in their Business Suite
applications. All the code to create the user interface is then generated
automatically within a standard runtime framework.[2].
Web Dynpro is also designed to support structured development. The software
modularization units are Web Dynpro components, which can be combined to
build complex applications. This helps Floor Plan Manager Framework to
reduce the redundant programming work for the users. All Web Dynpro
applications are constructed from the same basic units. [2]
Based on all these advantages provided from Web Dynpro, the Business Suite
applications are easily adjusted by configuring the underlying Web Dynpro
components and not by additional programming. Floor Plan Manager
Framework also gets benefits from the Web Dynpro adjustments. More details
are mentioned in the chapter 2.1.5 introduction of Floor Plan Manager
Framework.
Web Dynpro is also a client-independent programming model of the SAP
NetWeaver technology platform for developing user interfaces for professional
business applications. It is based on the Model View Controller (MVC) paradim
which ensures that the business logic is separated from the presentation logic. [8]
Model forms the interface to the back end system and thus enables the
Web Dynpro application access to data;
View is responsible for the representation of the data in the browser;
Controller lies between the view and the model. The controller formats
the model data to be displayed in the view, processes the user entries
made by the user, and returns them to the model. [8]
Figure 2.2 describes the Web Dynpro application MVC programming model.
9
Figure 2.2: Web Dynpro application MVC programming model [2]
Web Dynpro component is the most important part for Web Dynpro MVC
model. It allows structuring complex Web Dynpro applications and developing
reusable entities. Web Dynpro components are containers for other entities
related to the user interface and Web Dynpro program. [2] Figure 2.3 shows the
structure of Web Dynpro component.
10
Figure 2.3: Web Dynpro component [2]
Figure 2.3 describes that the entities related to the user interface of Web Dynpro
application are windows and views. The layout of a view is the rectangular part
of a page displayed by the client. The view contains user interface elements such
as input fields and buttons. The complete page sent to the client can be set up by
only one view, and can also be a combination of multiple views. The possibility
of combinations of views and the flow between the views is defined in a
window. [2]
A window can contain any number of views. A view can be embedded in any
number of windows. Both views and windows are integrated into Floor Plan
Manager Framework.
Inside Web Dynpro, programming part is located in Web Dynpro controllers.
Global variables of controllers are defined as controller attributes. Global data
related to the user interface, which is displayed by elements on the user interface
or used to manipulate user interface element properties, has to be stored in a
hierarchical storage called Web Dynpro context. The context is structured for
hierarchical data storage, stores data related to the user interface and also stores
the data transporting between the controller. The values of user interface
elements that allow user input have to be connected to the context attributes of
the corresponding Web Dynpro Component controller. This is called data
binding. Through data binding, an automatic data transport between the user
interface elements and the context attributes is established. [9]
11
The variables defined in a Web Dynpro controller context can be referenced
from other Web Dynpro controllers. This is called context mapping. Context
mapping allows to share common attributes between different controllers, so
copying these attributes between the controller contexts is not necessary. So with
these two concepts, data transport between user interface elements located in
different views can be defined in a purely declarative way. [9] Web Dynpro
MVC model is the basis for Floor Plan Manager Framework. The Floor Plan
Manager Framework is implemented as Web Dynpro ABAP component and
integrated into the Web Dynpro ABAP development environment.
12
2.1.2 Introduction of Enterprise Service Oriented Architecture
Enterprise Service Oriented Architecture (Enterprise SOA) is an important
architecture pattern, which is Service Oriented Architecture (SOA) merged with
SAP NetWeaver platform. Enterprise SOA describes the information about how
to publish and consume the thousands of Enterprise Web Services (Web
Services in short) within SAP.
SOA is also an architectural pattern, which requires all exposed functionality to
be published as services in a platform-independent manner. In any SOA-based
environment, it is possible to delivery loosely coupled and interoperable
application services based on Web Services standards that operate independently
of the underlying platform and programming language. [13] The individual
software components may be implemented in different programming languages.
For example, one software component might provide a service that is
implemented in Java and is accessed by another software component or service
that is implemented in ABAP or C#. Industry standards, for example WSDL for
Web Services, define the way in which the service is accessed. In this manner,
each software component or service encapsulates and therefore hides the vendor-
specific, language-specific implementation from the calling software component
or service. [13]
Besides the descriptions above, SOA has also another two advantages. One is the
strict separation of the service implementation with its publicly available
interface. SOA defines a communication endpoint, where the service provider is
published as a service description in a service registry. And the other one is that
SOA also represents a contract between the service provider and service
consumer. [13] For each service consumer, it can have several logical ports, and
each logical port is used to connect with an endpoint with a service provider.
Figure 2.4 shows the difference between SOA and Enterprise SOA.
13
Figure 2.4: SOA & Enterprise SOA [3]
Compared with SOA, Obviously, Enterprise SOA has well organized repository,
which is called Enterprise Services Repository (ESR). And Enterprise SOA is
not only inherits the mechanism of providing the pair of communication
endpoint and logical port at both service provider part and service consumer
part, also Enterprise SOA is based on SAP NetWeaver platform and includes
business semantics. The design of Generic Adaptation is based on the Enterprise
SOA.
Figure 2.5 is the SAP Enterprise SOA Infrastructure. With Enterprise SOA, Web
Services are loosely coupled, so that they can communicate and interoperate to
each other. Enterprise SOA allows integrating the functionalities of both non-
SAP and SAP systems into service-based solutions. These systems can be
running on the SAP NetWeaver platform, as represented by the Partner and SAP
application boxes. They can also be running on other platforms, as represented
by the Legacy Third Party and SAP R/3 system boxes. [13]
14
Figure 2.5: SAP Enterprise SOA Infrastructure [13]
15
2.1.3 Introduction of Enterprise Services Repository
The most important part of Enterprise SOA is Enterprise Service Repository
(ESR). Enterprise SOA builds new or extends existing business applications in
SAP using independent building blocks. These building blocks, including
business objects, enterprise services, and process components, both SAP
supplied and custom-built, are stored in a central shared repository that is ESR.
ESR is a design-time tool that is the central place where the Enterprise SOA
element definitions are stored and maintained. [13] Each Web Service is defined
within ESR, and the ESR provides a pair of service interfaces for each Web
Service. The service interfaces are outbound service interface and inbound
service interface. All the Web Services can be extracted by connecting the
service interfaces, as showed in the Figure 2.7.
Enterprise SOA elements described below are defined in the ESR. For each Web
Service, there are four important elements at least are needed to be defined in the
ESR. They are Data types, Message Types, Operations and Service interfaces.
All these Data types, Message types and Operations’ metadata are encapsulated
with the Service Interfaces. Operations are the functions, which can be carried
out by the Web Services. The Operations can be synchronous or asynchronous
communications. Message Types are special within SAP Enterprise SOA. The
Message Types are used to identify what kind of Operations within the same
Service Interface. However inside SAP, all the Web Services can be connected
via Service Interfaces from the ESR, and the conversation can be done
automatically via Enterprise SOA.
Data types: Basic elements that are used to construct Web Services,
business objects, and interfaces. For example, to define data types such
as city, ZIP code, street, and house number that are used to construct a
customer or supplier address.
Message types: XML entities that are the design-time representation of
messages that describe the communication messages that are sent by
Web Services.
Operations: Synchronous or asynchronous actions that Web Services can
perform at runtime. For example, to define a material available check
operation, is a synchronous action that is performed by the purchase
order completion step in a process.
Service interfaces: Metadata descriptions of messages and operations that
are used at runtime. One example is the service interface that is used to
generate a WSDL document.
Business objects: Identifiable business entities such as a material or a
sales order that can have a logical relationship with other business
objects. Business objects are used to ensure orderly development and
generate Web Services. [13]
16
The ESR holds all Enterprise SOA artifacts and also allows the users to
understand the dependencies between those elements in the ESR. [3] The ESR is
complemented by the Services Registry (SR) [10], which is the directory for all
service definitions and callable service endpoints available in the SAP systems.
Service providers publish their ready-to-use Web Services to the SR, consumer
applications retrieve the definitions from there. Thus the SR allows to categorize
and organize Web Services based on naming standards and classifications, to
browse and search for Web Services, access control of assets in the registry so
that only authorized users are able to publish, search, and view Web Services,
and labeling of Web Services and classification of providers and consumers, thus
providing a different view of the Web Services to the different classes of service
consumers.
Within SAP, ESR and SR are both supported in two different infrastructures.
They are SAP NetWeaver Process Integration and SAP NetWeaver Composition
Environment:
SAP NetWeaver Process Integration: With ESR to model the business
processes and design the service interfaces, data types and the message
exchanging.
SAP NetWeaver Composition Environment: Not focus on process
integration, the ESR and SR provide the capabilities for the service
providing and consumption.
17
2.1.4 Introduction of SAP NetWeaver Process Integration (PI)
SAP NetWeaver PI is SAP’s implementation of Enterprise SOA middleware and
facilitates the integration of business processes that span different departments,
organizations, or companies. [11] SAP NetWeaver PI is not focusing on the
inner life of the individual process components or how the business logic is
implemented within a process component but rather on how the process
components exchange data with each other. Process integration is all about the
choreography of data exchange between process components. [11]
Within SAP NetWeaver PI, the most important part is the way to communicate
with each other between different systems and exchange the data. There are two
main approaches. If one system calls another using a remote function call, then it
is named Point-to-Point or Direct communication. If there is a central instance
interconnecting the systems, then it is called Mediated communication.
Compared to the Point-to-Point communication, the number and arrangement of
connections remains manageable within Mediated communication. However the
mechanism of providing a pair of communication endpoint and logical point for
both sides is also remaining within SAP NetWeaver PI. Below Figure 2.6 show
the differences of both communications.
Integration
Server
Figure 2.6: P2P on the left & Mediated communication on the right
Both Point-to-Point communication and Mediated communication are widely
used. For example, for synchronous Web Services, they are mostly using Point-
to-Point communications; for asynchronous Web Services, they can use both of
them.
There is a protocol, called eXchange Infrastructure (XI) protocol, is responsible
for the exchanging XML messages between different systems or environments.
18
SAP XI protocol is based on general standards so as to enable external systems
to be integrated by providing a pair of proxy classes at both sides. The proxy
classes called Proxy Provider Class are used to communicate with the provider
via the endpoint and guarantee the mapping and exchanging of data with
provider. The proxy classes called Proxy Consumer Class are responsible to
communicate with the consumer via logical port and guarantee the mapping and
exchanging of data with consumer.
Within SAP NetWeaver PI, both of the proxy classes require to be generated
together with the creation of endpoint and logical port. The Proxy Provider Class
is generated at the service interface when the Web Service is published into
ESR. Also the endpoint of this Proxy Provider Class is created together. Then,
the Proxy Consumer Class is generated based on the WSDL, which is provided
by the Proxy Provider Class, and then the consumer creates the logical point
based on the created Proxy Consumer Class. Finally, both of the proxy classes
are connected via the endpoint and logical port with the Web Service.
At the center of the Mediated communication is an XML-based communication
that uses Hyper Text Transfer Protocol (HTTP). The application-specific
contents are transferred in messages in user-defined XML schema from the
sender to the receiver using the Integration Server. Senders and receivers that
exchange messages using the Integration Server are separated from one another.
This separation makes it easier to connect systems that are technologically
different. Every system that can exchange messages with the Integration Server,
which is showed in the Figure 2.8, can also exchange messages with all other
systems that are connected to the Integration Server. [12]
Figure 2.7 shows the way to consume Web Service under the help of SAP
NetWeaver PI in SAP Web Application Server in ABAP. As mentioned from
Chapter 2.1.3, the consumption is done bypassing service interfaces of ESR and
the use of proxy classes at both sides. A XI format message created by outbound
service interface will be sent to the Integration Server via the logical point of
Proxy Consumer Class. On the other hand, there is a Proxy Provider Class,
which will be generated at the inbound service interface. It receives and
exchanges the messages in XI format from the Integration Server and converts
the data into the required format in the Web Application Server. Then the
communication is established.
19
Outbound
Service Interface
Inbound
Service Interface
Consumer
Proxy
Provider
Proxy
SAP NetWeaver
Application Server - ABAP
SAP NetWeaver
Application Server - ABAP
ABAP
Application
ABAP
Application
Enterprise Services Repository
ABAP Proxy Generation
Web Service Runtime
Figure 2.7: Enterprise Services Repository & Proxies
Figure 2.8 shows the way to use XI protocol to communicate with two SAP Web
Application Servers via Integration Server, which is included within SAP
NetWeaver PI. The Integration Server exchanges messages based on the help of
proxy classes, sending messages to the Integration Server, using the Proxy
Consumer Class and providing a Web Service on the SAP Web Application
Server which can be addressed by messages from the Integration Server, using
the Proxy Provider Class.
20
Integration Server
Proxy
Consumer
Class
Web Service
Framework
SAP Web AS SAP Web AS
Proxy
Provider
Class
Web Service
Framework
XI
prototol
SOAP
Figure 2.8: Communication using Web Services
For consuming asynchronous Web Services with Point-to-Point communication,
the WS-RM protocol [13] is needed. It is very important to guarantee that the
request of message is sent and only once, when consuming the asynchronous
Web Services. The WS-RM protocol, so called Web Service-Reliable Messaging
protocol, is introduced to guarantee the reliable sending and only once.
Within SAP NetWeaver PI, SOA manager is the tool, which is used to configure
the proxy classes by creating the endpoint for the Proxy Provider Class and also
the logical ports for the Proxy Consumer Class. When the logical port is set to
the relative endpoint, the trace between both proxy classes is established.
Therefore, with SAP NetWeaver PI, the communication of the providers and
consumers of Web Services is successfully guaranteed across the entire IT
landscape, including providing access to legacy systems and Business-to-
Business protocols more quickly and easily. [15]
21
2.1.5 Introduction of Floor Plan Manager Framework
Floor Plan Manager Framework, based on Web Dynpro ABAP technology, is
the standard UI Framework for SAP Business Suite applications. Floor Plan
Manager Framework, which provides the components, such as floorplans, UI
Building Blocks as templates and also the Configuration Editor as configuration
tool, is used to create Web Dynpro applications within SAP Business Suite. [14]
Figure 2.9 shows the Floor Plan Manager Framework within Business Suite.
End User
Administrator
Developer
Web Dynpro ABAP Application
Floor Plan Manager Framework
Business Logic
Business Data
Business Suite
Floorplans Configuration Editor
GUIBBs
Figure 2.9: Floor Plan Manager in the SAP Business Suite
Floor Plan Manager Framework is based on Web Dynpro ABAP that provides a
framework for developing new Web Dynpro ABAP application floorplans
22
consistent with SAP UI guidelines. Floor Plan Manager Framework currently
supports the users in creating and configuring user interfaces with the following
floorplans, which can be configured using the Floor Plan Manager Configuration
Editor [14]:
Object Instance floorplan (OIF)
Guided Activity floorplan (GAF)
Overview Page floorplan (OVP)
And Floor Plan Manager Framework supports also the following floorplan areas:
Identification Region (IDR)
Message Region (MR)
Context Navigation Region (CNR)
Roadmap Element
Floorplans are design templates for applications. Thus, using floorplans can
improve the uniformity and the usability of applications. In the Web Dynpro
ABAP, floorplans are implemented as separate, highly configurable Web
Dynpro components that serve as main components in the Web Dynpro
applications. The Floor Plan Manager Framework for Web Dynpro ABAP is a
framework consisting of these highly configurable Web Dynpro components.
This allows combining multiple views of one or more Web Dynpro components
to a new Floor Plan Manager Framework application. [4]
Object Instance floorplan (OIF): The OIF usually describes several view
tabs, and a defined business object type determines those contents and
the distinctive tasks based on the users’ needs. Figure 2.10 shows the
example of Object Instance floorplan, named Flight Overview:
Figure 2.10: Example of OIF
Guided Activity floorplan (GAF): The GAF is a floorplan for an activity
that can be divided in a logical sequence of steps. It consists of a series of
23
screens that guide the user through an activity to achieve a specific goal.
A roadmap provides a visual representation of the whole activity to the
user. [4]
Overview Page floorplan (OVP): The OVP is quite similar to OIF but
comprised with Assignment Blocks. But the main difference is that OVP
is focusing on Objects only and it doesn’t have any view tabs like OIF.
Figure 2.11 shows an example of OVP, named Business Partner Query
with two Assignment Blocks.
Figure 2.11: Example of OVP
Besides these floorplans above, Floor Plan Manager Framework also provides
UI-Building-Blocks (UIBBs) as design templates. UIBBs are contents to
comprise floorplans. UIBBs include Freestyle UIBBs and Generic UIBBs.
Freestyle UIBBs are normal UIBBs, in which the users can create the layout in
freestyles. Generic UIBBs are UIBBs with standard predefined layouts. And
Generic UIBBs support the users in creating and configuring application-specific
views. In the Figure 2.11, there are two Generic UIBBs in the OVP floorplan,
which are Generic UIBB for Search on the top and Generic UIBB for List on the
bottom.
The Freestyle UIBBs and also Generic UIBBs within Web Dynpro applications
are realized as Web Dynpro components. Generic UIBBs are centrally provided
UIBBs, where the Web Dynpro applications only need to define the business
logic as field catalog and input parameter in flat structure for Generic UIBBs.
And Generic UIBBs works with only flat structures. Therefore, all the field
24
catalogs and input parameters require to be defined in flat structures within
Generic UIBBs. For example, Figure 2.11 includes two Generic UIBBs, and one
is a Generic UIBB for List on the bottom. Inside this Generic UIBB, there is a
field catalog, which comprises with five fields. Figure 2.12 shows the flat
structure for this field catalog in the Generic UIBB for List.
Structure of Field
Catalog
Company Name
First Name
Last Name
Legal Form
Partner ID
Figure 2.12: Example of flat structure for field catalog
A field catalog is a list of fields with certain types to define a certain type and
provides a certain interface for Generic UIBBs. Then Generic UIBBs can
communicate with these fields via the certain interface. Input parameters are
special field catalogs only for the input attributes. Both of field catalog and input
parameters are defined and configured at design time. For example, in the Figure
2.11, the Generic UIBB in the bottom comprised one field catalog, which is
showed as a table. This field catalog contains five different fields. All the fields
are defined from the business logic at design time.
Floor Plan Manager Framework and the Web Dynpro application components,
which include the Generic UIBBs, communicate via Floor Plan Manager
Interfaces during the floorplan event loop. The floorplan event loop comprises
with a sequence of predefined methods belonged to a class, so called feeder
class, that starts when the instance of floorplan is instantiated at runtime.
The predefined methods are defined in the Floor Plan Manager Interface, which
are triggered during the floorplan event loop. Feeder classes supply the specific
information for the UIBBs within the Web Dynpro applications by implementing
the Floor Plan Manager Interface together with the predefined methods at
runtime. For example, the definition of field catalog within the UIBBs is defined
with the GET_DEFINITION method in the feeder classes. And the method
GET_DATA determines the concrete values for the fields in the field catalogs
within the UIBBs. Table 2.1 and table 2.2 depict the examples above based on
the Generic UIBB in the Figure 2.11 on the bottom.
25
Method of Feeder
Class
List Generic UIBB
GET_DEFINITION
Table 2.1: Example of GET_DEFINITION method within feeder class
Within Table 2.1, the diagram depicts the defined field catalog in the Generic
UIBB for List by implementing the predefined method GET_DEFINITION in
the feeder class. The definition for the field catalog is defined within feeder class
at design time.
Method of Feeder
Class
List Generic UIBB
GET_DATA
Table 2.2: Example of GET_DATA method within feeder class
The diagram in the Table 2.2 depicts the field catalog with the concrete values
by implementing the predefined method GET_DATA in the feeder class at
runtime.
Therefore, feeder classes provide all the necessary application-specific
information to the Generic UIBBs by implementing the Floor Plan Manager
Interfaces for the Generic UIBBs. All the necessary methods, such as
GET_DEFINITION and GET_DATA, and corresponding signatures are used to
achieve the standard communication between the Web Dynpro applications and
the Generic UIBBs within feeder classes. The communication embraces:
Web Dynpro application definition: for example, data definition,
structure or table definitions and the technical aspects;
Possible default layout information and the corresponding field
dependencies;
The action definition based on metadata from Business logic;
The action or event handling and data is forwarding to the underlying
application model. [17]
26
The most common predefined methods within feeder classes are described below
for UIBBs.
AFTER_FAILD_EVENT
FLUSH
NEEDS_CONFIRMATION
PROCESS_BEFORE_OUTPUT
PROCESS_EVENT:
It is the main method within feeder classes. For example, in Search
Generic UIBBs, the method of PROCESS_EVENT checks the input
value for the search criteria from the end user and stores them inside
its parameter for further functions.
Right now, Floor Plan Manager Framework supports three kinds of Generic
UIBBs to cover the most important use cases. They are:
Form Generic UIBB:
Input parameter;
Result field catalog;
Search field catalog (optional);
List Generic UIBB, as showed in the Figure 2.11 on the bottom:
Input parameter;
Result field catalog;
Search Generic UIBB, as showed in the Figure 2.11 on the top:
Search field catalog;
Result field catalog;
Input parameter (optional).
Except the predefined methods above for UIBBs, there are several other methods
defined for different feeder classes by different Generic UIBB interfaces. They
are:
GET_DEFINITION:
Defines the field catalogs;
GET_DATA:
Get output values and display the output values in the result field catalog
for the Generic UIBBs;
GET_PARAMETER_LIST (option):
Defines the input parameters;
INITIALIZE (option):
Checks the changes of input values of input parameters and stores the
input values in the parameter IT_PARAMETER for the Generic UIBB.
27
Floor Plan Manager Framework includes a role model with three different roles,
which are described in the Figure 2.9, Developer, Administrator and End User.
Different role has different responsibilities.
Developer: Design time: Defines field catalog and input parameter based on the
business logic for Generic UIBBs. And he implements the feeder classes to
determine the concrete value for the Generic UIBBs. For example, in the Figure
2.11, developer defines the field catalog with five fields for the List Generic
UIBB on the bottom, and the search field catalog with three fields as search
criteria for the Search Generic UIBB on the top.
Administrator: Design time: configure the Generic UIBBs based on the defined
field catalog and input parameter for floorplans. For example in the Figure 2.11,
the administrator can choose which field of search criteria is displayed in the
Search Generic UIBB on the top and also which field of field catalog is display
in the List Generic UIBB on the bottom.
End user: Runtime: trigger the Web Dynpro applications and choose the
preferred value for the search criteria in the Search Generic UIBBs. For
example, when the Web Dynpro application is started with the Search Generic
UIBB in the Figure 2.11 on the top, the end user can insert the values for the
search criteria of field catalog.
Figure 2.13 shows the Floor Plan Manager Framework Phase Model, which
describes that Floor Plan Manager Framework based on Web Dynpro ABAP, is
mainly comprised with the floorplan event loop. At runtime, the feeder class
implements the UIBBs interface with the predefined methods to provide
concrete value for defined field catalogs and input parameters for further
consumption of business logic. When the end user in the left triggers a Web
Dynpro application, then the WD runtime starts and checks whether there are
floorplan components. If yes, then go into the floorplans with the UIBBs or
Generic UIBBs. All the predefined methods are triggered during the sequence of
floorplan event loop. After the floorplan event loop, the phase turns back to the
Web Dynpro application.
28
Figure 2.13: Floor Plan Manager Phase Model [16]
In the Figure 2.13, all the blue texts are the methods belonged to the Floor Plan
Manager Framework. Within Floor Plan Manager Framework, there is a
mechanism to receive the messages during the runtime and display them into the
Message Region in the floorplans by providing a parameter named
ET_Messages within four predefined methods of feeder classes. All the
parameters named ET_Messages are transmitting during the runtime with the
messages and providing the information to the Message Region to inform the
end user about the results of the actions. Four predefined methods include the
ET_Messages parameters. They are GET_DEFINITION, GET_DATA,
CHECK_CONFIG and PROCESS_EVENT. All of these methods can return a
message during the floorplan event loop, and store the messages within
ET_Messages displayed in the Message Region of the floorplans.
29
2.2 Related Works
However there are also several existing solutions inside and outside SAP, which
can also deal with the consumption of Web Services. This chapter describes the
concepts of these solutions and analyzes the advantages and disadvantages of
these solutions.
30
2.2.1 Consuming Web Services with Web Dynpro ABAP
Within Web Dynpro ABAP technology, there is one existing way to deal with
Web Services by creating a service call as Web Dynpro component for the Web
Dynpro ABAP application.
During the creation of service call, the user can choose the attributes of input and
output parameter of Web Service for further configuration. All the chosen
attributes are mapped to the Web Dynpro application context. Based on the
advantages of MVC model of Web Dynpro ABAP, Web Dynpro application
maps the attributes of Web Services to the fields in the layout via the Web
Dynpro application context, and triggers the Web Services as service call within
the Web Dynpro components.
The most important part of this solution is the wizard to create the service call,
called Web Dynpro Service Wizard. Web Dynpro Service Wizard actually is a
process for specific Web Service consumption manually. It integrates the
function of Web Service inside Web Dynpro component as a service calls:
1. Create Web Dynpro application and also the Web Dynpro component;
2. Start the process to create Service Call within Web Dynpro component,
and the process for the configurations;
Specify the controller;
Specify the Service type, for example: Web Service proxy:
The Web Service proxy means the pair of proxy classes
provided to deal with the mapping between XML-based
and ABAP-based for the Web Service.
Specify proxy class, method name and logical port name;
Choose input / output Parameters and map to the context of Web
Dynpro component;
Finally the Service Call is created for the specific Web Service
based on the configurations.
3. Draw the Layout in the view of Web Dynpro component and map the
layout elements with context of Web Dynpro component.
Figure 2.14 shows diagram of Web Dynpro Service Call Wizard. The two green
boxes in the middle are two different ways to go through the Web Dynpro
Service Call Flow. Function Module and Web Service proxy class are two ways
to choose the Services types to be created as Service Calls.
31
Creation of Web Dynpro Component
A
Function
Module
Web Service
Proxy class
1. Function Module’s name, Logical Port
name;
2. Proxy Class, Method name, Logical
Port name.
Choose Input/Output
Parameters
Context of
WDCMapping Input/
Output
Parameters to
Context
Draw Layout of Web Dynpro
Component A
Connect the elements of Layout
to Context elements
Figure 2.14: Diagram of Web Dynpro Service Call Wizard
The Advantages of the solution within Web Dynpro ABAP, based on the Web
Dynpro Service Wizard, is that the process is easy to follow. But it also has
some lacking points:
1. The Wizard is not independent. For each specific Web Service, the whole
process is almost the same. However, the configuration for the service
call is dependent on the different kind of Web Services. Therefore a lot
of manually configurations is necessary for each consumption of Web
Service;
2. The consumer has the global view of Web Services. During the
configuration, the consumer needs to specify the input and output
parameter of Web Service, and map them to the context of Web Dynpro
component. It is not convenient for the user to consume any Web Service
without global view.
3. The layout of views needs to be drawn all by the users.
32
2.2.2 Consumption via SAP NetWeaver Composition
Environment
The second solution which deals with the consumption of Web Services is based
on Web Dynpro Java in SAP NetWeaver Composition Environment 7.1. Web
Dynpro Java is represented inside SAP NetWeaver Composition Environment
7.1.
Except SAP NetWeaver PI, SAP NetWeaver Composition Environment (CE)
7.1 is also another platform that provides the Service Oriented Architecture to
walk through the process of consuming Web Services.
The reason to provide SAP NetWeaver PI and SAP NetWeaver CE is because
that each focuses different environments. SAP NetWeaver PI is ideal for
situations where human integration is not required. [18] SAP NetWeaver
Composition Environment is an ideal environment for developing complete
composite applications, where have collaborative processes and want to
aggregate data from different back-end systems into one or more UIs. [18]
Before, SAP always uses SAP NetWeaver PI to provide Enterprise Services in
ABAP, and use SAP NetWeaver CE to consume Enterprise Services. Below
Figure 2.15 depicts the basic components of SAP NetWeaver Composition
Environment. Symbol 1, a Java EE 5 application server, represents the basic
foundation of SAP NetWeaver Composition Environment. Symbol 2, also part
of SAP NetWeaver Composition Environment, is the development and modeling
environment SAP NetWeaver Development Studio. SAP NetWeaver
Composition Environment consists of different architectural layers – an
underlying service and business objects layer, a UI layer, and a process layer,
where glue together the UIs and service calls. The addition of the services layer
is very important, and it can decouple all service consumers, like the UIs, from
back-end systems, and then replace those back-end systems as needed without
any impact on the consumer side. [18] As showed in the Figure 2.15, SAP
NetWeaver Composition Environment can also consume Web Services from
ESR. At UI layer, SAP NetWeaver Composition Environment comprises
dedicated tools, like SAP NetWeaver Visual Composer, for model-driven UI
development for lightweight UIs with almost no complicated UI logical. [19]
33
Figure 2.15: Basic Components of SAP NW CE [18]
SAP NW Visual Composer: is used to model lightweight UI logical. It can
create new models or reuse the existing models, such as Web Services, Remote
Function Calls (RFCs), Portlet Applications, SAP NW Visual Composer models
and also Web Dynpro application. SAP NW Visual Composer can search or
restrict the Enterprise Services Classifications by using UDDI – standard
identification criteria. For example, from the SR, it can choose Customer or
Employee as Business Object Search Criteria to find out all the relative Services
to Customer or Employee. It is much easy for users to choose and connect with
Enterprise Logic. After the Service is chosen, SAP NW Visual Composer drags
and drops the Service inside as model. Figure 2.16 shows an example that
modeling a Web Service’s user interface within SAP NetWeaver Visual
Composer. SAP NetWeaver Visual Composer retrieves the WSDL information
for that chosen Service, which the systems can then use to automatically derive
input and output forms or tables from the respective parameters of this Service.
SAP NetWeaver Visual Composer allows users to model these parameters
without any additional coding. [18]
34
Figure 2.16: Modeling a Web Service’s user interface within SAP NetWeaver
Visual Composer [18]
Adaptive Web Service Model: For complicated UI logical, or more complex
input verifications, it is better to use Web Dynpro Java to consume Web Services
by creating a model, which is similar to the solution above, to support the
connectivity to Web Services. The Adaptive Web Service Model is the interface
that the user would use to support the connectivity to Web Services for the Web
Dynpro Java applications. The Adaptive Web Service Model provides the
functions:
Calling Web Services from Web Dynpro Java applications;
Create Web Services Logical destinations with Configuration of connection,
authentication and encryption settings;
Tracing of model content, such as model metadata, for problem analysis;
Access Web Service runtime Service Extension Interface to modify HTTP,
SOAP, and Security settings via API.
The Web Service destinations provide the benefits for changing of settings
without modifying the code or configuration files of the Web Dynpro Java
applications. The Adaptive Web Service Model needs to create two kinds of
Web Services destinations. They are:
Metadata destination: is used to find the WSDL at runtime from which the
Adaptive Web Service Model reads its metadata;
Execution destination: is used to execute the Web Services. [19]
Figure 2.17 shows the architecture of the use case of Adaptive Web Service
Model. For this Adaptive Web Service Model, dynamic proxies enhance the
Web Service runtime. The Dynamic Invocation interface is used to retrieve the
Web Service destinations for the logical ports. The Web Dynpro runtime, which
35
is part of the J2EE Engine of the SAP Web Application Server, comes with a
Common Model Interface-based metadata generation. [20]
.
Figure 2.17: Use Case for Adaptive WS Model for Web Dynpro Java [20]
The Adaptive Web Service Model object creation always requires a model
instance, which is used to bind the context-to-model for an Adaptive Web
Service Model object. This model instance is not created or maintained by the
Adaptive Web Service Model itself, below Listing 2.1 is the code sample to
achieve this model instance. [21]
//create model instance
Model model = new Model ();
//create model objects + relations
Request_NumberToWords requestMO = new Request_NumberToWords
(model);
NumberToWords words = new NumberToWords (model);
Words.setUbiNum (123);
RequestMO.setNumberToWords (words);
//bind model object to WD context
WdContext.nodeRequest_NumberToWords ().bind (requestMO);
Listing 2.1: Sample of model instance creation
After the Adaptive Web Service Model object is creation, then the user can trace
the request / response of a Web Service call by switching on logging for the
Model object. All the complete http-request / -response are contained within the
logs.
The solution for consumption of Web Service via SAP NetWeaver Composition
Environment makes so many benefits for the users with the details process and
36
architectures. Especially the users are in the J2EE local Application Server. The
main part of this solution is Adaptive Web Service Model (AWS) and it provides
many advantages in different areas:
1. Adaptability: In AWS, the metadata of Web Service is re-loaded at runtime
from the WSDL. With this, the runtime is capable of adapting to the
compatible changes of the WSDL thus avoiding the need for re-import of the
model and re-deployment of application;
2. Configuration: HTTP Proxy settings, like host and port, in AWS Model are
configurable and are not tightly coupled with the imported model. This
eliminates the need of additional entities such as logical port in AWS Model.
Additionally, AWS allows maintaining configurable destinations for
different Web Service providers;
3. Authentication: Accessing authenticated WSDL in AWS is possible by
providing the required user credentials during import process;
4. Structure Complexity: AWS Model supports for nested complex types;
5. Security: AWS Model also supports advanced security features like non-SAP
SSO authentication tickets, WS SOAP header etc. [21]
Conclusion, the solution for consumption of Web Service in SAP NetWeaver
Composition Environment has many advantages and provides also benefits for
many users. However, the solution can be limited only to SAP NetWeaver
Composition Environment, because The Floor Plan Manager Framework is
based on Web Dynpro ABAP. It is better to find the solution based on the SAP
NetWeaver Process Integration
37
2.2.3 Consuming Web Service via JDE EnterpriseOne Tools
JDE EnterpriseOne stands for the product of Oracle. Oracle’s JD Edwards
EnterpriseOne is an integrated application suite of comprehensive enterprise
resource planning (ERP) software that combines business value, standards-based
technology, and deep industry experience into a business solution with a low
total cost of ownership. [22] Oracle's JD Edwards EnterpriseOne Tools, which is
Business Services Development based on Service-Oriented-Architecture,
includes support for the development, deployment, and management of Web
Services, providing the ability to aggregate JD Edwards EnterpriseOne business
functions and database operations into a “business service” that can then be
exposed as a Web Service and also can be consumed. JD Edwards
EnterpriseOne can be a Web Service Provider and also a Web Service
Consumer. JD Edwards EnterpriseOne Web Services are called published
business services. A published business service consists one or more classes, one
of which publishes methods. Each method performs a business process. The user
creates a Web Service by creating a published business service and identifying
the published class. [24]
As a Web Service Provider, JD Edwards EnterpriseOne exposes Web
Services for consumption by external systems. Each operation of the Web
Service performs a business process. Multiple Java classes are used to
perform the requested business process. The JD Edwards EnterpriseOne
Web Service is generated from a Java class called a published business
service class. The methods of the published business service class receive
and return data through payload classes called value objects. Within each
method, internal business service and value object classes are used to access
existing logic and data in the JD Edwards EnterpriseOne system. The
business processes exposed through the published business service class can
be accessed from an external system using a Web Service call or from other
published business service classes. [24]
As a Web Service Consumer, JD Edwards EnterpriseOne calls an external
Web Service from within the JD Edwards EnterpriseOne business logic
layer. An action that uses a business function occurs in JD Edwards
EnterpriseOne. The business function calls a business service. The business
service calls an external Web Service. A Web Service proxy is provided end
point and security information for the external Web Service. The external
Web Service returns the results of the call to the business service. The
business service passes the results to the business function. [24]
The business services server enables JD Edwards EnterpriseOne to natively
produce and consume Web Services. The business services server production
environment is used by the administrators to create Web Services. An
38
administrator generates Web Service interfaces that expose the business service
logic. During the Web Service generation, WSDL files are produced. WSDL
files are used by external systems during orchestration development. After Web
Services are generated from the Java classes, they can be consumed by external
systems. [24]
JD Edwards EnterpriseOne can call Web Services. To enable JD Edwards
EnterpriseOne as Web Service consumer, the user needs to create a business
service that uses a Web Service proxy to call an external Web Service. A method
in that business service can be called by a JD Edwards EnterpriseOne business
function. The business function, which resides in the user enterprise server, uses
an API to call the business service method, which resides on the business
services server. JDENet is the communication mechanism between the servers.
An Object Configuration Manager (OCM) mapping tells the enterprise server the
business services server name and port for sending the JDENet messages. After
the OCM is configured with the business services server information, user can
ping the business services server from OCM to ensure that the business services
server is running and listening for messages. [24]
It is also possible to create a business service to consume an external Web
Service in the same way. But instead of using a published business service as the
Web Service, the business service is used to consume the Web Service by using
the Web Service proxy. A Web Service proxy is a collection of classes generated
with the target WSDL of external Web Services. Within JD Edwards
EnterpriseOne, a business function can directly call a business service that can
then call out to the external Web Service. The process is fully Synchronous,
allowing the response to be sent directly back to the business function. [23]
Figure 2.18 shows the way JD Edwards EnterpriseOne consumes External Web
Services. The target Web Service information will be retrieved from JDE
Enterprise Server to JDE Web Server via JDENet. Then Business Service calls
the External Web Service via Web Service proxy client, which is generated
based on the target WSDL of the external Web Service.
39
Figure 2.18: Structure of consumption of External Web Services by JDE
EnterpriseOne [23]
40
2.2.4 Dynvoker Approach
Except the solutions or products are already on the market, there are lot of Web
Service research projects which provide tools to improve the usage of Web
Services. Web Services are also targeted directly in the interaction between
humans and machines. A generic human-driven ad-hoc usage is introduced with
benefits in many scenarios, including rapid service testing and dynamic
inclusion of services as plug-ins into applications. Dynvoker, based on the
interaction model for ad-hoc service usage, is a generic Web Service client. [25]
When the message syntax, operational semantics and non-functional properties
of services are described by the file format specifications, it is possible to call
the services with the generic clients, such as Dynvoker, by introspecting the
descriptions and deducing behavioral information. [25]
Ad-hoc usage of simple services requires:
Navigation: to find the desired service. Navigation guides the user from
the expression of a goal to generate the input form automatically;
Form Generation: to form an interaction pattern. Including creation of
form elements, layout and embedding the form into an application
context and augmentation of existing services with local hints for the
graphical representation;
Submission: is done in the background and involves the interaction with
a service. After the submission of the form, the service is invoked and the
output form is rendered based on the results. [25]
Figure 2.19 describes the basic interaction model for ad-hoc service usage. For
more complex use cases, the forms can either be pure input and output forms
using previous input or output information.
Figure 2.19: Basic interaction model for ad-hoc service usage [25]
41
Dynvoker consists of a relatively small application core which can be run as a
servlet, a web service or a command-line application. The generic handling of
input, i.e. web service descriptions, and output, i.e. user interfaces, is reflected in
the modular architecture, showed as Figure 2.20. It contains several adapters to
generate forms, and inference modules for various service description formats.
[25]
Figure 2.20: Dynvoker Architecture [25]
GUIDD stands for the GUI Development Descriptor [26]. WSGUI, or Web
Services Graphical User Interface, has been introduced to derive user interfaces
from service definitions. When internal variable names are used, along with
complex type definitions, value restrictions and unclear services and operations,
it is very hard for user to navigate a Web Service. [26] The WSGUI concepts
allow the GUIDD side by side with a WSDL file to make the internal operations
visually accessible to the user, independent of the environment like desktop
toolkit or web browser. A GUIDD file is an XML-formatted file and consists of
a header and 4 sections. The section Operations describes the general page
creation and another section named Source is coupled to the existence of a Web
Service file. Another two are responsible for the display of input and output
forms. [25]
However, right now a large number of services with WSDL descriptions can
already be used with Dynvoker. Dynvoker is a viable generic client, which can
dynamically explore method-centric and resource-centric services alike, output
forms in various formats or integrate GUI services to provide a richer user
experience. [26]
This solution introduces an ad-hoc usage of Web Service, which is special for
humans-to-machines model. And it also depicts a generic client, called
Dynvoker, which includes an interaction model. With the generic client been
developed, it allows the access to all the existing services without the need for
the cooperation from the service authors [25].
Both of these two aspects can help the design of the Generic Adaptation. The
goal of Generic Adaptation is to provide a bridge to gap the Web Services and
the Floor Plan Manager Framework, which is the standard UI framework within
42
SAP. Therefore the ad-hoc usage for the humans-to-machines model is quite fit
for the design of Generic Adaptation. In the Figure 2.19, the interaction model
for ad-hoc service usage guides the processes or interactions for the human-to-
machine model to deal with the information from the Web Services by
contacting with the service interfaces. However, within the ESR, there is also a
pair of service interfaces is provided for each published Web Service within SAP.
Therefore, all the service interfaces from the ESR can be reused for the Generic
Adaptation.
On the other hand, the idea for the generic client is also useful for the design of
Generic Adaptation. The goal for the Generic Adaptation is also generic for any
kind of Web Services, and also can work for multiple Web Services. Within
Floor Plan Manager Framework, the feature, field catalogs and input parameters
are created to contain the fields and worked as interfaces for the Generic UIBBs.
Therefore, it is possible to create the field catalogs and input parameters for the
information from the Web Services. Then the Floor Plan Manager Framework is
allowed to access all the existing Web Services without the need for the
cooperation from the Web Service authors.
43
2.3 Summary
In this chapter, the basic architecture and technologies are introduced, and they
are the partners to be connected by the help of the Generic Adaptation.
Enterprise SOA and SAP NetWever PI as SAP’s implementation of SOA
middleware are all existed within SAP. Enterprise SOA is the architecture to
deal with Web Services within SAP. SAP NetWeaver PI deals with the mapping
between xml-based data type and ABAP-based data type by providing the pair of
proxy classes at both provider and consumer sides, and also handles the
communication for messaging.
Floor Plan Manager Framework, as the standard UI framework, extracts
information from business logic, defines field catalogs and input parameters for
Generic UIBBs. Floor Plan Manager Framework Configuration Editor is
responsible for configuration and provides the Generic UIBBs as application-
specific views. Feeder classes are implemented at runtime to exactly determine
the concrete value of field catalogs.
However Floor Plan Manager Framework does not include the function of
consumption of Web Services as the way same way for the consumption of
business logic.
Also the related works are described here. Below Table 2.3 depicts the
comparisons between all the related works and requirements of Generic
Adaptation.
Human-to-
Machine
Web
Services
Environment Generic
Solution
Automation
Requirements
for Generic
Adaptation
Yes All Web Dynpro
ABAP
Yes No need
SAP WD
ABAP
No need Easy
structured
Web Dynpro
ABAP
No No need
SAP NW CE No need All Web Dynpro
Java
No No need
JDE
EnterpriseOne
No need All Java No No need
Dynvoker Yes All Not specified Yes Required
Table 2.3: Table of the comparisons with Generic Adaptation
44
The next chapter shows the concepts of design for the Generic Adaptation,
which works as a bridge between Web Services and Floor Plan Manager
Framework based on the existing architectures and related works described
within this chapter.
45
Chapter 3 Design
This chapter describes the concept of design of the Generic Adaptation for Web
Services consumption within Floor Plan Manager Framework for Web Dynpro
applications. First, an overview of the Generic Adaptation is given. Second, the
subchapter describes the role model, which improves the role model of Floor
Plan Manager Framework. Third, the subchapter shows the main concept of
Generic Adaptation with three processes, which is based on the requirements of
existing architectures and technologies. Fourth, the subchapter describes how
Generic Adaptation works for synchronous Web Services. And fifth,
demonstrates the way that Generic Adaptation works for asynchronous Web
Services. And then the sixth, describes the analysis of the automation for the
three processes. The last section in this chapter gives a conclusion of design for
the Generic Adaptation.
The design is guided by the motivations and research questions that motivate this
thesis. Generic Adaptation is based on the architectures and techniques that have
been described in chapter 2 Background and it is introduced as a gap to bridge
between Web Services and Floor Plan Manager Framework. The main goal is to
provide a generic solution for the consumption of Web Services for Web Dynpro
applications and also enhance the functionality of Floor Plan Manager
Framework.
Existing techniques embedded in this design chapter were described in the
Chapter 2 Background. The main contributions of the Generic Adaptation
however, are pointed out in the particular subchapters and an evaluation is
shown in the chapter 5.
46
3.1 Generic Adaptation Overview
Generic Adaptation provides a generic solution to consume Web Services in
Web Dynpro applications within Floor Plan Manager Framework. The design of
Generic Adaptation is based on the requirements of the existing architectures,
technologies and analysis of existing solution in the chapter 2.
From chapter 2, the consumer part is Floor Plan Manager Framework, and more
specifically, the feeder classes of Generic UIBBs in floorplans of Floor Plan
Manager Framework. On the other hand, SAP has integrated SOA into the main
infrastructure called Enterprise SOA. Enterprise SOA provides the way to
extract the Web Services by communicating with the service interfaces within
ESR. SAP NetWeaver PI as the middleware of Enterprise SOA, which handles
the transmission of messaging, the mapping of data-format and exchanging of
messages, provides one pair of proxy classes for each Web Service. From which
the Proxy Consumer Class is used to communicate with the consumer part via
outbound service interface, and the Proxy Provider Class is used to communicate
with the provider part via inbound service interface, and the communication
between two proxy classes is guaranteed by the endpoint at Proxy Provider Class
and logical port at Proxy Consumer Class. Therefore the design of Generic
Adaptation is based on the feeder classes of Generic UIBBs and the Proxy
Consumer Classes of the service interfaces within ESR.
The design of Generic Adaptation should include three parts below:
.
1. Contact with the service interfaces within ESR, and create a channel to
retrieve the information from Web Services;
2. Create field catalogs and input parameters as interfaces for
communication between Generic UIBBs and the information retrieved
from Web Services;
3. Trigger the consumption of Web Services and handle all the interactions
during the consumption.
Generic Adaptation includes Generic Adaptation Interface, which will be
implemented by Generic Adaptation Class at runtime for specific Web Service,
and a message-handling class providing the messages during the consumption.
Regarding to the three aspects above, the Generic Adaptation Interface should
provide the methods, which can achieve all the three aspects to fit all kinds of
Web Services and Generic UIBBs. Therefore, Generic Adaptation Interface
includes four methods. They are:
CREATE_FIELD_CATALOG: the method of GET_DEFINITION in the
feeder class defines the field catalogs under the help of the method of
CREATE_FIELD_CATALOG in the Generic Adaptation Interface;
47
CREATE_INPUT_PARAMETER: the method of
GET_PARAMETER_LIST in the feeder class defines the input parameters
under the help of the method of CREATE_INPUT_PARAMETER in the
Generic Adaptation Interface;
GET_INPUT_VALUE: get input values for input parameters for List or
Form Generic UIBBs by communicating with the parameter
IT_PARAMETER within the method INITIALIZE in the feeder class, and
get input values for search criteria of search field catalog for Search Generic
UIBBs by communicating with the method of PROCESS_EVENT in the
feeder class at runtime;
GET_OUTPUT_VALUE: get the output value after the consumption of
Web Services, and fill the concrete values into the result field catalog for
Generic UIBBs by communicating with the method of GET_DATA in the
feeder class at runtime.
Figure 3.1 shows an overview of Generic Adaptation. On the left in Figure 3.1
depict the relationship between Proxy Consumer Class, Proxy Provider Class
and Web Services. On the right in Figure 3.1 depicts the relationship between
feeder classes, Generic UIBBs and Floor Plan Manager Framework. All of them
interact with Generic Adaptation Class. The Generic Adaptation Class
implements the Generic Adaptation Interface at runtime. All the implemented
four methods, showed in the Figure 3.1, are taking care of the interactions
between the Proxy Consumer Classes and feeder classes as the main concept of
Generic Adaptation.
48
+CREATE_FIELD_CATALOG()
+CREATE_INPUT_PARAMETER()
+GET_INPUT_VALUE()
+GET_OUTPUT_VALUE()
«interface»Generic Adaptation Interface
Generic Adaptation ClassProxy Consumer Class Feeder Class
1 1 1 1..*
Proxy Provider Class
11
Web Service
1
1
+AFTER_FAILD_EVENT()
+FLUSH()
+NEEDS_CONFIRMATION()
+PROCESS_BEFORE_OUTPUT()
+PROCESS_EVENT()
+GET_DEFINITION()
+GET_DATA()
+GET_PARAMETER_LIST()
+INITIALIZE()
«interface»
IF_FPM_GUIBB
GUIBB
1
1
Floor Plan Manager Framework
0..*1
Figure 3.1: Overview of Generic Adaptation
49
3.2 Role Model
This subchapter describes the role model, which improves the role model of
Floor Plan Manager Framework under the help of Generic Adaptation. As
described in the chapter 2 Background, there are three roles within the role
model of Floor Plan Manager Framework. They are Developer, Administrator
and End user showed in the Figure 2.9.
Generic Adaptation also introduces a new role, called Controller role. Figure 3.2
describes the enhanced Floor Plan Manager Framework role model. Compared
with Figure 2.9, the consumption of Web Services via Generic Adaptation can
enhance the Floor Plan Manager Framework with the consumption of Web
Services within business logic.
The role Controller takes care of the implementation of Generic Adaptation
Class to achieve the interactions with Proxy Consume Classes and feeder
classes. As showed in the Figure 3.2, the Controller encapsulates all the Web
Services within the Generic Adaptation by implementing the Generic Adaptation
Class, so that the developer of Floor Plan Manager Framework can consume
different Web Services in the same way. This improvement makes more
convenient for the developer to consume any Web Services.
The developer role can directly communicate with Generic Adaptation Class and
implement the feeder classes for the Generic UIBBs. But the developer has no
direct communication with the Web Services. The Generic Adaptation
encapsulates all the details of Web Services, such as the structure of input and
output parameters of methods within Web Services. The developer defines the
field catalogs and input parameters at design time via the communication with
Generic Adaptation Class. And developer implements the feeder classes to
determine the concrete values for the field catalogs at design time.
The administrator role is focusing on the configuration of floorplans with
Generic UIBBs via Configuration Editor. The administrator can choose the
values for the input parameters and decide which fields can be displayed in the
field catalogs in the Generic UIBBs at design time.
The End User can trigger the Web Dynpro applications and especially insert the
value for the search criteria of search field catalogs for Search Generic UIBBs at
runtime.
50
End User
Administrator
Developer
Web Dynpro ABAP Application
Floor Plan Manager Framework
Business LogicWeb Service
(Proxy Consumer
Class)
Business DataBusiness Suite
Floorplans Configuration Editor
GUIBBs
ControllerGeneric
Adaptation
Figure 3.2: Enhanced Floor Plan Manager Framework
From the Figure 3.2, by implementing the Generic Adaptation Class, the role
Controller enhances the functionality of directly consumption of Web Services
for Floor Plan Manager Framework.
51
3.3 Main Concept of Generic Adaptation
This section enhances the overview of Generic Adaptation of the chapter 3.1 in
more details. Generic Adaptation provides a generic solution with three
processes to consume Web Services within Floor Plan Manager Framework and
also provides a message-handling class to handle all the messages showed in the
Message Region of floorplans within Floor Plan Manager Framework.
This generic solution includes Generic Adaptation Interface and Generic
Adaptation Class. The Generic Adaptation Interface provides four methods, and
they handle all the three requirements discussed in the chapter 3.1. Therefore,
Generic Adaptation Interface is generic for all kinds of Web Services and
Generic UIBBs by providing these basic four methods. All the three processes
are implemented by the four methods within Generic Adaptation Interface.
However, Generic Adaptation Class is also generic for all kind of Generic
UIBBs, but specific for the different Web Services. For each Web Service, there
is one instance of Generic Adaptation Class is instantiated. Therefore, Generic
Adaptation can not only work for one Web Service and also multiple Web
Services with different instances at the same time within one floorplan of Floor
Plan Manager Framework.
The main concept of Generic Adaptation can be separated into three processes.
First, process of Acquisition of attributes depicts the interactions between
Generic Adaptation and SAP Enterprise SOA. Second, the process of Field
catalog creation defines the field catalogs and input parameters based on the
different Generic UIBBs by communicating with the methods of
GET_DEFINITION and GET_PARAMETER_LIST in the feeder classes. After
these two processes, all the attributes of Web Services are mapped into the field
catalogs and input parameters, then the Generic UIBBs of Floor Plan Manager
Framework can communicate with the attributes via the field catalogs and input
parameters as interface. The last process, Consumption via Generic Adaptation
is responsible for the interactions after the consumption in the backend. At the
end, the subchapter gives a concept about the message-handling class.
52
3.3.1 Acquisition of attributes
For the first process, Acquisition of attributes is also introduced based on the
requirement of Generic UIBBs within Floor Plan Manager Framework. All the
Generic UIBBs within Floor Plan Manager Framework can only works with the
flat structures. For example, all the types of field catalogs and input parameters
should be flat structures.
The structure of Proxy Consumer Class is displayed in the Figure 3.3, which
shows the structure of one Proxy Consumer Class with three methods. However,
one Proxy Consumer Class includes at least one method. One method includes at
least one output parameter, and the input parameter is optional.
Proxy Consumer
Class
Method 1
Method 2(Optional)
Method 3(Optional)
Input
Parameter
(Optional)
Output
Parameter
Input
Parameter
(Optional)
Output
Parameter
Input
Parameter
(Optional)
Output
Parameter
Figure 3.3: Structure of a Proxy Consumer Class
Each input and output parameter has a parameter type, which stores the structure
of the attributes of the parameter. All the attributes of input and output
parameters can be found within these structures. The process of Acquisition of
attributes is focusing on extracting the attributes from the structures of the input
and output parameter of Proxy Consumer Class.
However, the types of input and output parameters of Proxy Consumer Class
within Enterprise SOA are not only flat structure, and they can be very deep
structure with many levels. Therefore, the structures are quite different from
each other. Figure 3.4 depicts both flat and deep structures of parameter types.
53
Flat Parameter
Type
Deep Parameter
Type
Attribute A
Attribute B
Attribute N
First Level
First Level
Second Level
Second Level
Second Level
Attribute A
Attribute B
Attribute C
Attribute D
Attribute E
Figure 3.4: Left: Flat Parameter Type; Right: Deep Parameter Type
Demonstrated in Figure 3.4, on the left is the example of Flat Parameter Type,
and the type has one level with three Attributes, which is fit for the requirement
of the Generic UIBBs within Floor Plan Manager Framework. On the right is an
example of Deep Parameter Type, and it includes several levels with attributes at
leaves. Obviously, this deep parameter type is not fit for the flatten requirement
of Generic UIBBs. However, the process Acquisition of attributes needs to
extract all the attributes from the deep parameter type.
Another problem is the name conflict during the Acquisition of attributes.
During the acquisition, there might same Web Services are consumed or same
names of attributes of parameters. For instance, there is a Web Service named
Delivery Check. There is an attribute named Address in the input parameter, and
another attribute also named Address in the output parameter. However,
Acquisition of attributes extracts attributes from input and output parameters
separately, and stores them in separate field catalogs. The details of field
catalogs are described in the chapter 3.3.2 Field catalog creation.
For the name conflict of names for Web Services, each Proxy Consumer Class
maps to one Web Service, and is generated based on the WSDL of the Proxy
Provider Class. After the generation, the name of the Proxy Consumer Class is
comprised with 2 parts, one part is directly made of the name of Web Service,
and another part is random during the generation of the Proxy Consumer Class.
That means even for the same WSDL, the name of the generated Proxy
Consumer Class is different. And the same, the names of the parameter types of
input and output parameter of methods are also different based for each
generation.
The methods of Generic Adaptation Interface, CREATE_FIELD_CATALOG
and CREATE_INPUT_PARAMETER are responsible to extract the attributes,
and create field catalogs and input parameters based on the requirements of
Generic UIBBs. As mentioned in Chapter 3.2, the Controller role has the global
view of Web Service about the structures of input and output parameters. When
54
the Controller implements the Generic Adaptation Class to consume the Web
Service with these two methods, the Generic Adaptation Class extracts the
attributes. Figure 3.5 depicts an example of process Acquisition of attributes for
the Generic Adaptation. One Web Service includes four attributes.
In more details, the Controller predefines the flatten parameter types with the
attributes based on the structures of input and output parameters of the Web
Services. And then at runtime, the Controller searches the input and output
parameter types by identifying the names of Web Services and method of the
Web Services. And then Controller compares the attributes of defined parameter
types with the extracted attributes. If the defined types are matched with the
input and output parameter types, then the defined types are sent to the second
process of Field catalog creation.
+CREATE_FIELD_CATALOG()
+CREATE_INPUT_PARAMETER()
+GET_INPUT_VALUE()
+GET_OUTPUT_VALUE()
«interface»Generic Adaptation Interface
+CREATE_FIELD_CATALOG()
+CREATE_INPUT_PARAMETER()
Generic Adaptation Class-Attribute A
-Attribute B
-Attribute C
-Attribute N
Proxy Consumer Class
Feeder Class
1 1 1 1..*
Figure 3.5: An example of process of Acquisition of attributes
Figure 3.5 shows the diagram of process of Acquisition of attributes by
implementing the methods of Get field catalog and Get input parameter. For
example, at the Proxy Consumer Class side, there are four attributes come from
input and output parameters. Controller within Generic Adaptation Class
predefines the input parameter type and output parameter type. At runtime, the
process of Acquisition of attributes extracts all the four attributes and compares
with the attributes within the defined parameter types. If all the attributes are
matched, then the defined parameter types are sent to the feeder classes for the
next process of Field catalog creation.
Therefore, after the process of Acquisition of attributes, the attributes to create
field catalogs and input parameters of Generic UIBBs within Floor Plan
Manager Framework are ready for the second process of Field catalog creation.
55
Compared with the solution of consuming Web Services with Web Dynpro
ABAP in the chapter 2.2.1, process of Acquisition of attributes can deal with all
kinds of structures for input and out parameters. However, the solution of
consuming Web Services with Web Dynpro ABAP can only work for deep
structure for input and output parameters of Web Services by manually mapping
all the attributes including the sub-level attributes of the input and output
parameters to the Web Dynpro context.
56
3.3.2 Field catalog creation
The process of Field catalog creation is also based on the requirement of Floor
Plan Manager Framework and mainly handled by the feeder classes. The main
Generic UIBBs provided within Floor Plan Manager Framework are Form
Generic UIBB, List Generic UIBB and Search Generic UIBB. Different Generic
UIBB requires different kinds of field catalogs and input parameters at design
time. All the concrete values are filled in at runtime during the process of
Consumption via Generic Adaptation. The field catalog stands for the different
field catalogs and input parameters, which are used to contain the attributes from
Web Services as fields.
Search Generic UIBB: Input parameter (optional);
Search field catalog;
Result field catalog.
Form Generic UIBB: Input parameter;
Search field catalog (optional);
Result field catalog.
List Generic UIBB: Input parameter;
Result field catalog.
From the list above, there are totally 3 different kinds of field catalog. All these
three kinds of field catalogs are defined based on the attributes extracted from
the process of Acquisition of attributes by implementing the methods of
CREATE_FIELD_CATALOG and CREATE_INPUT_PARAMETER, as
showed in the Figure 3.5. CREATE_FIELD_CATALOG communicates with the
method of GET_DEFITITION in the feeder class to define all the field catalogs.
And CREATE_INPUT_PARAMETER defines all the input parameters by
communicating with the method of GET_PARAMETER_LIST in the feeder
class.
Under the mechanism of Floor Plan Manager Framework for Generic UIBBs,
those attributes of input parameter of Web Services are used to define the input
parameters for List or Form Generic UIBBs and search field catalogs for Search
Generic UIBBs, and those attributes of output parameter of Web Services are
used to define the result field catalogs for all kinds of Generic UIBBs. Figure 3.6
demonstrates an example of the process of Field catalog creation for these three
different field catalogs.
57
Search field catalog
(Search Generic
UIBBs)
Input parameter
(Form & List
Generic UIBBs)
Result field catalog
(Search, Form &
List Generic
UIBBs)
Input-Attribute1
(Web Service)
Input-Attribute2
(Web Service)
Input-Attribute3
(Web Service)
Input-Attribute1
(Web Service)
Input-Attribute2
(Web Service)
Input-Attribute3
(Web Service)
Output-
Attribute1 (Web
Service)
Output-
Attribute2 (Web
Service)
Output-
Attribute3 (Web
Service)
Figure 3.6: Example of created field catalogs
In the Figure 3.6, all the created field catalogs are flattening, with the relative
attributes based on the requirements of different Generic UIBBs within Floor
Plan Manager Framework.
After the process of Field catalog creation, the extracted attributes of Web
Services are used to define the field catalogs for the Generic UIBBs. Figure 3.7
displays an example of the processes Acquisition of attributes and Field catalog
creation with multiple Web Services and Generic UIBBs by implementing the
methods CREATE_FIELD_CATALOG and CREATE_INPUT_PARAMETER
with two Proxy Consumer Classes. It defines the field catalogs for one feeder
class of Search Generic UIBB and one feeder class of List Generic UIBB.
58
+CREATE_FIELD_CATALOG()
+CREATE_INPUT_PARAMETER()
+GET_INPUT_VALUE()
+GET_OUTPUT_VALUE()
«interface»Generic Adaptation Interface
+CREATE_FIELD_CATALOG()
+CREATE_INPUT_PARAMETER()
Generic Adaptation Class
-Input Attribute A
-Output Attribute D
Proxy Consumer Class-A
-Search field catalog : <unspecified> = Attribute A
-Result field catalog : <unspecified> = Attribute D
Feeder Class-Search Generic UIBB
1
1 1
1
-Input parameter : <unspecified> = Attribute B
-Input paramter : <unspecified> = Attribute C
-Result field catalog : <unspecified> = Attribute E
Feeder Class-List Generic UIBB
1
1
-Input Attribute B
-Input attribute C
-Output Attribute E
Proxy Consumer Class-B
1
1
Figure 3.7: Example of processes Acquisition of attributes and Field catalog
creation with multiple Web Services and Generic UIBBs
In the Figure 3.7, two Proxy Consumer Classes are showed on the left. Proxy
Consumer Class A includes attribute A for input parameter, and attribute D for
its output parameter. Proxy Consumer Class B has attributes B and C within the
input parameter, and attribute E for its output parameter.
Two feeder classes, displayed on the right side, one implements the Search
Generic UIBB on the top, and another implements the List Generic UIBB on the
bottom.
After the process of Field catalog creation, all the extracted attributes are
mapped into different field catalogs by communicating with the
GET_DEFITITION and GET_PARAMETER_LIST methods in the feeder
classes at runtime. All of the field catalogs are flattening, and fit the
requirements of Generic UIBBs.
Compared with the solution of consuming Web Services with Web Dynpro
ABAP in the chapter 2.2.1, the process of Field catalog creation integrates all the
attributes into the Floor Plan Manager Framework very well by filling the field
catalogs and input parameters with the attributes. However the solution of
consuming Web Services with Web Dynpro ABAP needs to manually map all
the attributes to the Web Dynpro application context.
59
3.3.3 Consumption via Generic Adaptation
The process of Consumption via Generic Adaptation is the most important
process of the concept of Generic Adaptation. The Consumption via Generic
Adaptation is responsible mainly to deal with the interactions via Configuration
Editor at design time and interactions via the consumption of Web Services at
runtimes.
All the interactions above can affect the output values of the consumption of
Web Services. Therefore, there should be a process to handle all these
interactions, and trigger the necessary methods when these interactions
happened. Process of Consumption via Generic Adaptation is responsible for
this issue.
The methods of GET_INPUT_VALUE and GET_OUTPUT_VALUE from the
Generic Adaptation Interface are implemented during the process of
Consumption of Generic Adaptation and handle the interactions. Both of
GET_INPUT_VALUE and GET_OUTPUT_VALUE use the results from the
previous processes at runtime and evaluate the results from the previous
processes at design time.
First of all, the method of GET_INPUT_VALUE is responsible to get the input
values of search criteria for Search Generic UIBBs from the end user at runtime
by communicating with the method of PROCESS_EVENT of feeder class. And
it is also responsible to get the values for input parameter by checking the
changes of the input parameters at runtime under the help of the method of
INITIALIZE of feeder class.
In additional, the method of GET_OUTPUT_VALUE firstly evaluates the
changes for the field catalogs within Configuration Editor at design time, and
then it uses the input values from the method of GET_INPUT_VALUE to
trigger the consumption of Web Services. Moreover, this method automatically
returns the output values to fill the result field catalogs for the Generic UIBBs at
runtime.
Figure 3.8 displays sequences of Consumption via Generic Adaptation for List
Generic UIBB. This example is special for the method GET_INPUT_VALUE
getting input values for the List Generic UIBB. In the Figure 3.8, there are five
objects, and they are the end user, Web Dynpro runtime, FPM (Floor Plan
Manager Framework) – List Generic UIBB, feeder class – List and Generic
Adaptation Class. Each of them performs its activities after the end user triggers
the action within Web Dynpro applications. The red annotations stand for the
actions or processes happened during the action blocks, which is described as
dark blue block in the Figure 3.8. All the black contexts, showed as the
messages, depict the items sent to the next object.
60
1. There are totally three action blocks within Generic Adaptation Class
object. They are presenting the three processes of the Generic
Adaptation. The four methods defined within Generic Adaptation
Interface achieve these three processes when the feeder class triggers the
instance of Generic Adaptation Class.
2. First, the feeder class for List Generic UIBB instantiates the instance of
Generic Adaptation Class. Then, based on the attributes extracted within
the process of Acquisition of attributes, the methods of
GET_DEFINITION and GET_PARAMETER_LIST define the result
field catalog and input parameters at design time. After the third process
of Consumption via Generic Adaptation, feeder class fills the output
values with method of GET_DATA from the Generic Adaptation Class
into the result field catalog and deliveries the result field catalog with
concrete values to List Generic UIBB.
3. FPM-List Generic UIBB instantiates the feeder class first of all. Then,
after the administrator inserts the values for the input parameters at
design time. The parameter of IT_PARAMETER within the method of
INITIALIZE stores the input values. Then at runtime, FPM-List Generic
UIBB directly deliveries the input values and together with the
configurations on the field catalogs within Configuration Editor to the
instance of Generic Adaptation Class. At last, with the returned concrete
values from output, the FPM-List Generic UIBB includes the result field
catalog is returned back to the WD (Web Dynpro) runtime.
4. WD runtime is triggered with the action from end user, and finishes the
action after the consumption of Web Services is done.
61
End user
Web Dynpro Runtime FPM-List Generic UIBB Feeder Class-List Generic Adaptation Class
Web Dynpro AfterAction
Web Dynpro Onaction
Modify Generic UIBBs
List Generic UIBB with Result field catalog
Action
Instantiate Feeder Class
Instantiate Generic Adaptation Class
Result field catalog with output value
Attributes
Input parameter & Result field catalog
Input parameter with values
Action of result field catalog
FPM start
Create List
Generic UIBB
Feeder Class start Process of
Acquisition
of Attributes
Field
catalog
creationGet_parameter_list
defines input parameter;
Get_definition defines
Define result field catalogInsert value for Input
parameter and stored by
Initialize
Get input value in the
Consumption via
Generic Adaptation
Check the actions for
result field catalogs
Get output value via
Get_data in the
Consumption via
Generic Adaptation
Figure 3.8: Sequences of Consumption via Generic Adaptation for List Generic
UIBB
Figure 3.9 shows the sequences of Consumption via Generic Adaptation for
Search Generic UIBB. This example is special for the method
GET_INPUT_VALUE getting input values from the search criteria of Search
62
Generic UIBB. In the Figure 3.9, there are five objects, and they are the end
user, Web Dynpro runtime, FPM (Floor Plan Manager Framework) – Search
Generic UIBB, feeder class – Search and Generic Adaptation Class. Each of
them performs its activities after the end user triggers the action within Web
Dynpro applications. The red annotations stand for the actions or processes
happened during the action blocks, which is described as dark blue block in the
Figure 3.9. All the black contexts, showed as messages, depict the items sent to
the next object.
1. There are totally three action blocks within Generic Adaptation Class
object. They are presenting the four methods of the Generic Adaptation
Interface. The four methods defined within Generic Adaptation Interface
achieve the three processes when the feeder class triggers the instance of
Generic Adaptation Class.
2. First, the feeder class for Search Generic UIBB instantiates Generic
Adaptation Class. Then, based on the attributes extracted within the
process of Acquisition of attributes, the method of GET_DEFINITION in
the feeder class defines the search field catalog and result field catalog at
design time. After the process of Consumption via Generic Adaptation,
the method of GET_DATA in the feeder class fills the output values
from the Generic Adaptation Class into the result field catalog and
deliveries the result field catalog with concrete values to Search Generic
UIBB.
3. FPM-Search Generic UIBB instantiates the feeder class first of all. Then,
FPM-Search Generic UIBB checks the actions on the search and result
field catalogs within Configuration Editor, and deliveries to the instance
of Generic Adaptation Class. At last, with the concrete values of result
field catalog, FPM-Search Generic UIBB turns back to the WD (Web
Dynpro) runtime.
4. WD runtime is triggered with the action from end user, and finishes the
action after the consumption of Web Services is done. But there is one
special action compared with the example for the FPM-List Generic
UIBB. At WD runtime, the end user inserts the values for the search
criteria of the search field catalog. Then, all the values are received by
the method of PROCESS_EVENT in the feeder class at runtime and sent
to the Generic Adaptation Class to trigger the third process of
Consumption via Generic Adaptation.
63
End user
Web Dynpro Runtime FPM-Search Generic UIBB Feeder Class-Search Generic Adaptation Class
Web Dynpro AfterAction
Web Dynpro Onaction
Modify Generic UIBBs
Search Generic UIBB with Result field catalog
Action
Instantiate Feeder Class
Instantiate Generic Adaptation Class
Result field catalog with output value
Attributes
Search field catalog & Result field catalog
Search field catalog with input values
Action of both field catalogs
FPM start
Create Search
Generic UIBB
Feeder Class startProcess of
Acquisition of
Attributes
Field catalog
creation
Get_definition: defines
search field catalog
and result field catalog
Process_event: gets
values for Search
criteria for search
field catalog within
Web Dynpro runtime
Get input value in
the Consumption
via Generic
Adaptation
Check the actions for
result field catalogs
Get output value via
Get_data in the
Consumption via
Generic Adaptation
Figure 3.9: Sequences of Consumption via Generic Adaptation for Search
Generic UIBB
64
Based on both of the examples above, GET_INPUT_VALUE method of
Consumption via Generic Adaptation can get input values in two different ways.
Figure 3.8 shows the way to get input values special for List or Form Generic
UIBBs, and Figure 3.9 displays the way to get input values special for Search
Generic UIBBs.
The process of Consumption of Generic Adaptation takes care of the interactions
after the consumption of Web Services within Web Dynpro application with
GET_OUTPUT_VALUE method. Figure 3.10 demonstrates the diagram of
result with process of Consumption of Generic Adaptation by implementing the
method of GET_OUTPUT_VALUE for two Web Services. And this example
also depicts the way that Generic Adaptation can work for multiple Web
Services at same time.
In the Figure 3.10, the Generic Adaptation works for two Generic UIBBs to
consume two different Proxy Consumer Classes by separating both of the Proxy
Consumer Classes with names, and for each Proxy Consumer Class, there is one
instance of Generic Adaptation Class is instantiated. After the function calls for
both Proxy Consumer Classes, Proxy Consumer Class A returns output values A
and B, and Proxy Consumer Class B returns output values C, D and E. The
GET_OUTPUT_VALUE method receives the output values and fills them into
different result field catalogs of feeder class-Search and feeder class-List. After
all, Floor Plan Manager Framework displays the Generic UIBBs with concrete
result field catalogs in the Web Dynpro applications.
+CREATE_FIELD_CATALOG()
+CREATE_INPUT_PARAMETER()
+GET_INPUT_VALUE()
+GET_OUTPUT_VALUE()
«interface»Generic Adaptation Interface
+GET_OUTPUT_VALUE()
Generic Adaptation Class
Actions from the Configuration Editor
+Function call A()
-Output value A
-Output value B
Proxy Consumer Class-A
-Result field catalog : <unspecified> = Output value A
-Result field catalog : <unspecified> = Output value B
Feeder Class-Search Generic UIBB
1
1 1
1
-Result field catalog : <unspecified> = Output value C
-Result field catalog : <unspecified> = Output value D
-Result field catalog : <unspecified> = Output value E
Feeder Class-List Generic UIBB
1
1+Function call B()
-Output value C
-Output value D
-Output value E
Proxy Consumer Class-B
1
1
Figure 3.10: Example of GET_OUTPUT_VALUE method
65
These three processes are the basic concept of the concept of Generic
Adaptation. All of them are necessary for all kinds of consumption of Web
Services with Generic Adaptation for Floor Plan Manager Framework. However
all Web Services can be divided into two parties based on different
communications. One is synchronous Web Services and another is asynchronous
Web Services. Below, the two sub chapters describe the Generic Adaptation for
both synchronous and asynchronous communications.
Compared with the solution of consuming Web Services with Web Dynpro
ABAP in the chapter 2.2.1, the Generic Adaptation provides a generic solution
for consuming Web Services by encapsulating all the Web Services within
Generic Adaptation. The Floor Plan Manager framework consumes any Web
Services in the same way by implementing the Generic Adaptation Interface. In
addition, there is no need to draw any layout manually within Floor Plan
Manager Framework.
66
3.3.4 Message-handling Class
This subchapter gives an analysis about the message-handling class for Generic
Adaptation and describes how Generic Adaptation provide the message-handling
class to display message during the consumption of Web Services.
The error-handling is one of the important cases for the consumption of Web
Services. Users require the function to deal with the different kinds of errors
during the consumption of Web Services. Therefore, the message-handling class
is important for the users of Generic Adaptation within Floor Plan Manager
Framework. The message-handling class defines several messages with contexts
and can be displayed when the errors are appeared. Then the users can be alerted
with the messages and trigger the actions in time.
In the chapter 2.1.5 Introduction of Floor Plan Manager Framework, Message
Region of floorplans is the area to display all the messages with the help of
parameter ET_Messages within three methods in the feeder classes.
Generic Adaptation designs one message-handling class, which is separately
with Generic Adaptation Class, and directly, communicates with the parameter
ET_Messages during the actions of feeder classes. There are three methods,
which includes the parameter, need communications with Generic Adaptation.
1. GET_DEFINITION: feeder class defines all the field catalogs within this
method. Generic Adaptation checks whether the action of definition is
successful or not. If the action gets an error, then one error defined
message within message-handling class is stored in the ET_Messages
parameter and displayed in the Message Region.
2. GET_DATA: feeder class gets the output values from the Generic
Adaptation. If the action is successful, then a defined successful message
from message-handling class is transformed into the ET_Messages, and
showed in the Message Region. If the action if not successful, then a
defined error message will be displayed in the Message Region.
3. PROCESS_EVENT: especially, feeder class for Search Generic UIBB
gets the input values for search criteria of search field catalog by
implementing this method. If the action if successful, then a defined
successful message from message-handling class is transformed into the
ET_Messages, and showed in the Message Region. And in the opposite,
an error message will be displayed in the Message Region.
67
3.4 Generic Adaptation for Synchronous Web Services
Synchronous Web Services stand for the Web Services with synchronous
communications, which require all the parties involved during the
communications. Usually, synchronous Web Services perform business checks
such as tickets availability, where the calling software component waits for a
response before continuing.
Within Enterprise SOA, all the synchronous Web Services are published with
both input and output parameters for each synchronous communication in the
ESR. Figure 3.11 depicts the diagram of Synchronous communication for Web
Services. In the Figure 3.11, synchronous communication includes only two
steps. First, the sender sends the request for the consumption of Web Service.
Then the receiver replies the message with result of consumption to the sender
immediately. Both of the partners of synchronous communications need to be
alive during the synchronous communication, it is meaningful for the use cases
as Web Dynpro applications as UI consume the Web Services. Because the end
user of Web Dynpro applications always want to see the result as soon as he
triggered the consumption of Web Services.
Sender Receiver
Step 1: Sender send message to Receiver with
request to consume the Web Service.
Step 2: Receiver immediately reply message to
Sender with the result of consumption of Web
Service.
Figure 3.11: Diagram of synchronous communication
The sequences for the consumption of synchronous Web Services via Generic
Adaptation within Floor Plan Manager Framework is described below. The Web
Dynpro application based on the Floor Plan Manager Framework stands for the
sender, and the Web Services, which can provide this synchronous
communication, stands for the receiver. Firstly, the process Acquisition of
attributes extracts all the attributes from the input and output parameters. Then
the field catalogs are defined in the methods of GET_DEFINITION and
GET_PARAMETER_LIST in the feeder class under the help of process Field
catalog creation. After that, the process Consumption via Generic Adaptation
updates the configurations within Configuration Editor and triggers the
consumption of synchronous Web Service. Finally, the output values from the
68
Web Service will be filled into the result field catalog in the Generic UIBB and
displayed via the Web Dynpro application.
Based on the analysis above, Generic Adaptation can fit very well for
synchronous Web Services. Figure 3.12 demonstrates an example of
consumption of the synchronous Web Service with Generic Adaptation. The
example includes two senders and two receivers.
Sender 1
(Feeder
Class 1)
Sender 2
(Feeder
Class 2)
Receiver 1
(Proxy
Consumer
Class 1)
Receiver 2
(Proxy
Consumer
Class 2)
Search field catalog 1
Input parameters 1
Result field catalog 1
Search field catalog 2
Input parameters 2
Result field catalog 2
Generic Adaptation
1.Request for
Receiver 1
6.Return concrete
Result catalog 1
1.Request for
Receiver 2
6.Return concrete
Result catalog 2
Processes of Acquisition
of Attributes &
Field catalog creation
Process of Consumption
via Generic Adaptation
Instance 1 of
Generic Adaptation
Class
Instance 2 of
Generic Adaptation
Class
2.Request for
Attributes
3.All Attributes
2.Request for
Attributes
3.All Attributes
4.Input values
4.Input values
5.Trigger the
Consumptions with
concrete Field
catalogs
Figure 3.12: Diagram of consuming synchronous Web Service
In the Figure 3.12, it shows that for each sender the Generic Adaptation
instantiates an instance of Generic Adaptation Class. Then, first, senders send
requests to Generic Adaptation. Second, after Generic Adaptation receives the
requests from senders, it sends requests for the attributes to the receivers. Third,
all the attributes are acquired from the receiver side as Proxy Consumer Class.
Fourth, senders as Generic UIBBs insert the input values, and the Generic
Adaptation checks and receives. Fifth, Generic Adaptation triggers the
consumption of receivers. Finally, the concrete result values are filled in the
result field catalogs and sent to the senders.
However, in the Figure 3.12, the senders are the Generic UIBBs within Floor
Plan Manager Framework, and the Proxy Consumer Classes stand for the
receivers. Generic Adaptation provides one Generic Adaptation Class for one
69
Proxy Consumer Class, as described as Instance of Receiver in the Figure 3.12.
Firstly, Generic Adaptation receives the requests for the consumption of
receivers, it instantiates the instances of Proxy Consumer Classes within Generic
Adaptation Classes. After the feeder classes fill the input values for the created
field catalogs and input parameters. The consumption of Web Services starts by
calling both instances within Generic Adaptation Classes. Finally, the concrete
result field catalogs are returned to the Generic UIBBs to display.
In conclusion, the mechanism of Generic Adaptation is not only working for the
synchronous Web Services, also provides a generic solution for the consumers to
consume more than one Web Service by implementing the Generic Adaptation
Interface with the same four methods and the same processes.
70
3.5 Generic Adaptation for Asynchronous Web Services
Asynchronous Web Services stand for the Web Services with asynchronous
communications, which do not require all the parties alive involved during the
communications. Asynchronous Web Services are usually used in processes that
are separate business process steps, where the calling software component or
service continues to operate without waiting for a response.
Figure 3.13 displays the diagram of asynchronous communication. The first part
of the diagram is quite similar to the diagram of synchronous communication.
But there is no direct response immediately sent from receiver to sender. There
are more steps processed in the backend from both sides. On the receiver side,
the process of request is happened in the backend after the receiver is alive. On
the sender side, there is a container in the backend, which is used to periodically
check the return messages from receiver. If the message arrives, the container
stores the value and then informs the sender with a warning message. Finally,
the result message can be showed or received in an application at sender side.
Sender Receiver
Step 1: When Sender is on-line, Sender sends
message to Receiver with request to consume the
Web Service.
.
.
.
Step 2: When Receiver is on-
line, it processes the request for
a period time.
Receiver
(Backend)
Container
(Backend)
Step 3: After the process during some period time, the
result of consumption is sent back to the sender side.
Step 4: When the reply is
notified, the container stores
the result, and create a
warning to Sender with the
receipt of the result
consumption.
Figure 3.13: Diagram of asynchronous communication
From Chapter Background, ESR is the repository to store all the Web Services
for Enterprise SOA. ESR provides one pair of service interfaces to encapsulate
the Web Service, and provides a communication channel for the consumption
via ESR in Enterprise SOA.
71
For synchronous Web Service, the inbound service interface provides the Proxy
Provider Class at the provider part, and the consumer requires to generate a
Proxy Consumer Class at the outbound service interface based on the WSDL
provided by the Proxy Provider Class, in the meantime, endpoint and logical port
are created to guarantee the communication between both proxy classes through
the service interfaces.
However, it is different for asynchronous Web Service in ESR. The process of
asynchronous communication is supported with two steps and two pair of
inbound and outbound service interfaces. The first pair of service interfaces
provides a Proxy Provider Class at the inbound service interface in the same way
like the synchronous Web Service as showed in the Figure 2.7, but the method of
this Proxy Provider Class includes only input parameter. Therefore the first pair
of service interfaces is only responsible for the message of requesting. Then the
second pair of service interfaces provides a Proxy Consumer Class at the
outbound service interface. And this proxy class includes a method with only
output parameter, which is only responsible for the message of responding.
Consequently, the consumer for the asynchronous Web Service requires to
generate a Proxy Consumer Class based on the first pair of service interfaces to
achieve only responsible for the requesting, which is the same way as for the
synchronous Web Service. In additional, the consumer has to generate a Proxy
Provider Class based on the second pair of service interfaces to be responsible
for the responding. The ESR, when publishing the asynchronous Web Service
into ESR, supports the communication between both of the proxy classes at the
provider side automatically.
As the analysis above, for the first step of asynchronous communication,
Generic Adaptation can fit very well in the same way by extracting the attributes
of input parameters of Proxy Consumer Class at the consumer side, creating the
field catalogs for the Generic UIBBs and consuming the Web Service, but no
result field catalog for the output values. For the second step of asynchronous
communication, Generic Adaptation can also extract the attributes of output
parameter of Proxy Provider Class at consumer side, and create the result field
catalog to contain the concrete value of the attributes. However the process of
Consumption via Generic Adaptation is not required to trigger the consumption,
it only requires to delivery the result field catalog into the Generic UIBBs. The
processes of checking the message of responding and filling the concrete value
are both guaranteed by the process in the backend, not relative to the Floor Plan
Manager Framework.
Figure 3.14 describes the diagram of consuming asynchronous Web Service via
Generic Adaptation. Because the proxy classes are different, the Generic
Adaptation provides one Generic Adaptation Classes for both steps separately.
In the step two, the message of responding can also be displayed in other
applications, compared with the Generic UIBBs.
72
Sender 1
(Feeder
Class 1)
Receiver 1
(Proxy
Consumer
Class 1)
Search field catalog 1
Input parameters 1
Generic Adaptation
1.Request for
Receiver 1
Processes of Acquisition
of Attributes &
Field catalog creationProcess of Consumption
via Generic Adaptation
Instance 1 of
Generic
Adaptation Class
2.Request for
Attributes
3.All Attributes
4.Input values
5.Trigger the
Consumptions with
concrete search
field catalog 1 and
input parameter 1
Processing when receiver
aliveSender 1
(Feeder Class 2 )
Receiver 1
(Proxy
Provier
Class 1)
Result field
catalog 1
Generic Adaptation
Processes of Acquisition
of Attributes &
Field catalog creation
1.All Attributes
Sender 1
(Other
applications)
2. Process in the backend fills the concrete values
Figure 3.14: Diagram of consuming asynchronous Web Services
Compared with Figure 3.12, Generic Adaptation can work for both synchronous
and asynchronous Web Services. For synchronous Web Services, one Generic
Adaptation Class is implemented to achieve the whole consumption of one
synchronous Web Service. However two Generic Adaptation Classes are
implemented to achieve the whole consumption of one asynchronous Web
Service. Therefore, Generic Adaptation Class is dependent on the proxy classes,
but Generic Adaptation Class is not dependent on the feeder classes. However
the Generic Adaptation Interface is dependent on neither of proxy classes nor
feeder classes.
In conclusion, Generic Adaptation provides a generic solution to consume all
kinds of SAP Web Services within Floor Plan Manager Framework.
73
3.6 Analysis of automation for the three processes
This section describes the analysis of automation for the three processes. As
discussed in the Table 2.3, the design of Generic Adaptation has no requirements
for the automation. However, the three processes can be semi-automation to
enhance the functionalities of Generic Adaptation.
For the process of Acquisition of attributes, as described in the section 3.3.1, it is
semi-automation. The Controller predefines the flatten parameter types with the
attributes, and then searches for the parameter types of Web Services at runtime
by comparing with the name of Web Services and methods. Moreover, the
Controller compares the attribute types within the predefined parameter types
with the attribute types from the searched parameter types at runtime one by one.
If it is the same, then the attributes are filled into the predefined flatten
parameter types. During this process, there is one problem, which is the
complicit for the attributes’ names. For instance, the deep parameter type in the
Figure 3.4 on the right, if the attribute B and attribute E have the same name
Student. Then the Controller fills AttributeB_Student and AttributeE_Student
into the predefined flatten parameter types.
For the process of Field catalog creation, all the field catalogs are defined with
the predefined flatten parameter types in the methods
CREATE_FIELD_CATALOG and CREATE_INPUT_PARAMETER at design
time. This process can be automation, in which all the field catalogs are defined
based on the predefined flatten parameter types at runtime automatically.
However, it is much easier to define the field catalogs with the predefined flatten
parameter types at design time.
For the process of Consumption via Generic Adaptation, the best way to support
automation is to provide a wizard with several steps. The steps are provided for
the users to insert the names of Web Services, Generic UIBBs, and also the
attributes of the parameter types and etc. And then the Generic Adaptation Class
for the specific Web Service is generated out. However, within this thesis, the
process of Consumption via Generic Adaptation is achieved by the method
GET_INPUT_VALUE and GET_OUTPUT_VALUE within the Generic
Adaptation Interface.
74
3.7 Summary
The conclusion from the above design is, Generic Adaptation can work as a
bridge between the Enterprise SOA and Floor Plan Manager Framework by
providing a generic solution for the consumption of all kinds of Web Services in
Web Dynpro applications with Floor Plan Manager Framework. The advantages
that
Generic Adaptation is a generic solution by encapsulating all the attributes of
input and output parameters of the Web Services with Generic UIBBs within
Floor Plan Manager Framework under the implementation of the Generic
Adaptation Interface with four methods. Figure 3.10 depicts an example of the
consumption for two different Web Services, and those two Web Services are
consumed in the same way by implementing the Generic Adaptation Interface to
improve the solution for multiple Web Services is generic. However, the Generic
Adaptation Classes is specific for each Web Service, but all the different Generic
UIBBs can consume one Web Service via the same Generic Adaptation Class.
From the examples of Figure 3.8 and Figure 3.9, all the three recent Generic
UIBBs can work with the Generic Adaptation based on the concepts above.
Even later, there might be some new Generic UIBBs are introduced by Floor
Plan Manager Framework, it is also possible to consume Web Services via
Generic Adaptation by analyzing the field catalog and input parameter of the
new Generic UIBBs.
It is a little bit different to consume asynchronous Web Services via Generic
Adaptation as to consume synchronous Web Services. For the consumption of
asynchronous Web Services, except the Web Dynpro application for the end user
to trigger the consumption, it is necessary to deal with the messages of
responding separately with another pair of proxy classes, and also display the
responses with another Generic UIBB or other applications.
There is one fact required to be enhanced is the way to differentiate the
mandatory attributes and optional attributes of input and output parameters of
Web Services. Although, the Configuration Editor can differentiate the
mandatory attributes with optional attributes by proving a warning message
during the configurations by the administrator. However, Generic UIBBs do not
provide the functions to check all the mandatory attributes included. Therefore,
the functionalities of Generic Adaptation is required improving the function to
guarantee the entire mandatory attributes assembly.
75
Chapter 4 Implementation
This chapter covers details about the implementation of Generic Adaptation.
First, the overview of the implementation environment is explained and second,
the important field catalog types are described in the subchapter. In the third part
of this chapter, the implementation of the four methods defined within Generic
Adaptation Interface is described. The fourth part of this chapter, the
implementation of specific Generic Adaptation Class is presented, which
contains the implementation for the processes within the concept of design for
Generic Adaptation based on the synchronous Web Services.
Since the existing architectures and technologies are described in chapter
Background, in this chapter, only the implementation related to the Generic
Adaptation is described. Table 4.1 includes the names of Generic Adaptation
entities and used feeder classes for the implementation.
Generic Adaptation Interface IF_GENERIC_ADAPTATION
Generic Adaptation Class CL_GENERIC_ADAPTATION
List Feeder Class ZHK_WS_TEST_FOR_NEWIF
Search Feeder Class ZHK_WS_TEST_FOR_NEWIF_SEARCH
Table 4.1: Table of entities for Generic Adaptation for implementation
Below describes the necessary steps to complete the implementation of Generic
Adaptation:
1. Searching the parameter types of Web Services at runtime;
2. Acquisition of attributes and define the field catalogs with the attributes at
design time;
3. Get the input values for the input parameter or search field catalogs at
runtime;
4. Trigger the consumption of Web Services, and return the output values and
fill into the result field catalogs for the Generic UIBBs.
76
4.1 Development environment Because of the requirements for Floor Plan Manager Framework, Generic
Adaptation is achieved based on the Web Dynpro ABAP, and all the classes are
implemented in ABAP OO language, which is a Object-Oriented programming
language used within SAP.
The prototype of the Generic Adaptation is implemented to prove the concept of
Generic Adaptation. The prototype is comprised with several use cases of the
usages for different Generic UIBBs and Web Services. All the successful use
cases can illustrate Generic Adaptation is a generic solution for Floor Plan
Manager Framework to consume all kinds of Web Services.
77
4.2 Important field catalog types
Field catalog types stand for the types of field catalog, which requires creating in
the process of Field catalog creation. Because the Generic UIBBs within Floor
Plan Manager Framework can work only for flat structure, it is necessary to
create these field catalogs in flat structure to achieve good compatibility with
Floor Plan Manager Framework.
Based on the different Generic UIBBs, the field catalogs are including three
different field catalog types. All the data types of field catalogs are defined with
structures below, and all the structures are provided by different Generic UIBBs.
1. Input parameter:
FPMGB_S_PARAM_DESCR:
NAME: STRING
TYPE: CHAR
2. Search field catalog:
FPMGB_S_SEARCHFIELD_DESCR:
NAME: CHAR
TEXT: STRING
3. Result field catalog:
FPMGB_S_LISTFIELD_DESCR:
NAME: CHAR
TEXT: STRING
Therefore, by defining the field catalog types with these structures, all the field
catalogs with the attributes from Web Services can be integrated into Generic
UIBBs and configured with Configuration Editor by the administrator.
78
4.3 Important methods within Generic Adaptation Interface
Generic Adaptation Interface, which is the main part of Generic Adaptation
solution, is totally generic for Floor Plan Manager Framework and Web
Services. The consumption of Web Service within Floor Plan Manager
Framework is achieved by implementing the Generic Adaptation Interface.
The four methods defined by Generic Adaptation Interface are responsible to
realize the three processes of Generic Adaptation, which are described in the
chapter 3 as the main extending part based on the existing architectures and
technologies. And also the four methods satisfy the basic requirements for the
design of Generic Adaptation. The methods of CREATE_FIELD_CATALOG
and CREATE_INPUT_PARAMETER take care of the processes of Acquisition
of attributes and Field catalog creation, and the methods of
GET_INPUT_VALUE and GET_OUTPUT_VALUE response for the process of
Consumption via Generic Adaptation. All the methods are defined with
importing and exporting parameter. All the parameters, which are used to
transmit the information in the runtime, are required to fit both Floor Plan
Manager Framework and Web Services.
1. CREATE_FIELD_CATALOG: is responsible to create field catalogs
with two exporting parameters: EO_FIELD_CATALOG_HK and
ET_FIELD_DESCRIPTION_HK. Table 4.2 includes the parameters of
method CREATE_FIELD_CATALOG.
Parameter Description
EO_FIELD_CATALOG_HK (type ref
to CL_ABAP_TABLEDESCR)
Exporting parameter, contain the
fields;
ET_FIELD_DESCRIPTION_HK (type
FPMGB_T_LISTFIELD_DESCR)
Exporting parameter, contain the
description of fields.
Table 4.2: Parameters of CREATE_FIELD_CATALOG
2. CREATE_INPUT_PARAMETER: is responsible to create input
parameters with one exporting parameter INPUT_PARAMETER. Table 4.3
depicts the parameter of method CREATE_INPUT_PARAMETER.
Parameter Description
INPUT_PARAMETER (type
FPMGB_T_PARAM_DESCR)
Exporting parameter, contain the pair
of name and type for input parameters.
Table 4.3: Parameter of CREATE_INPUT_PARAMETER
79
3. GET_INPUT_VALUE: is responsible to get the changed values of Input
parameter from Configuration Editor for List or Form Generic UIBBs or get
the input values for search criteria by communicating with the method
PROCESS_EVENT in the feeder class special for Search Generic UIBBs.
There is one importing parameter INPUT_PROXY_VALUE. Table 4.4
shows the parameter of method GET_INPUT_VALUE.
Parameter Description
INPUT_PROXY_VALUE (type ref to
DATA)
Importing parameter, receive the input
values.
Table 4.4: Parameter of method GET_INPUT_VALUE
4. GET_OUTPUT_VALUE: is responsible to trigger the consumption of
Web Service, get the returned output values and deliver to the feeder classes
of Generic UIBBs. A pair of importing and exporting parameters is defined
for the transmission of information. Table 4.5 shows the parameters of
method GET_OUTPUT_VALUE.
Parameter Description
INPUT_PROXY (type ANY) Importing parameter, contain the
inputs for the consumption of Web
Service;
OUTPUT_PROXY (type DATA) Exporting parameter, contain the
outputs after the consumption of Web
Service.
Table 4.5: Parameters of method GET_OUTPUT_VALUE
However, all the four methods defined within Generic Adaptation Interface work
as adapter for Floor Plan Manager Framework by providing the flatten field
catalogs to fit the requirements of Generic UIBBs, and fill the concrete values
into the field catalogs by communicating with the Web Services.
80
4.4 Implementation of Generic Adaptation Class
Based on the concept of the design, the implementation of Generic Adaptation
Interface is generic for all kinds of Web Services and also generic for different
Generic UIBBs with consumptions. However, the implementation of Generic
Adaptation Class is specific for the different Web Services. For each Web
Service, there is at least on instance of Generic Adaptation Class is instantiated.
Below Table 4.6 describes the specific Web Services:
Name Description
Business Partner By ID Query Response Name of the specific Web Service
Synchronous Web Service Communication type
ZBPHKCO_BUSINESS_PARTNER_BY_ID Name of Proxy Consumer Class
BUSINESS_PARTNER_BY_IDQUERY_RE Name of method
ID Name of attributes in the input
parameter
LASTNAME, FIRSTNAME,
COMPANY_NAME, PARTNER_ID &
LEGAL_FORM
Name of attributes in the output
parameter
Table 4.6: Description of the specific Web Service
81
4.4.1 Implementation of processes Acquisition of attributes &
Field catalog creation
Processes of Acquisition of attributes and Field catalog creation with methods
CREATE_FIELD_CATALOG and CREATE_INPUT_PARAMETER:
For List Generic UIBB:
Field of Input parameter: ID;
Fields of Result field catalog:
LASTNAME, FIRSTNAME, COMPANY_NAME, PARTNER_ID &
LEGAL_FORM;
For Search Generic UIBB:
Search criteria of Search field catalog: ID;
Fields of Result field catalog:
LASTNAME, FIRSTNAME, COMPANY_NAME, PARTNER_ID &
LEGAL_FORM;
Within this step, in the method of CREATE_FIELD_CATALOG, includes the
creation of field catalog and the acquisition of parameter types for the Web
Service.
DATA:
ls_descr_result type line of FPMGB_T_LISTFIELD_DESCR.
Ls_descr_result-name = 'LASTNAME'.
APPEND ls_descr_result TO et_field_description_hk.
Ls_descr_result-name = 'FIRSTNAME'.
APPEND ls_descr_result TO et_field_description_hk.
Ls_descr_result-name = 'COMPANY_NAME'.
APPEND ls_descr_result TO et_field_description_hk.
Ls_descr_result-name = 'PARTNER_ID'.
APPEND ls_descr_result TO et_field_description_hk.
Ls_descr_result-name = 'LEGAL_FORM'.
APPEND ls_descr_result TO et_field_description_hk.
eo_field_catalog_hk ?= cl_abap_tabledescr=>describe_by_data( lt_list_bp ).
Listing 4.1: Sample codes for creation of field catalog for List Generic UIBB
82
Creation of field catalog for List Generic UIBB is described in Listing 4.1
above, and below Listing 4.2 is the code for the acquisition of parameter types
for the Web Service of Business Partner By ID Query Response.
output = lo_class_rtti->GET_METHOD_PARAMETER_TYPE
( P_METHOD_NAME = 'BUSINESS_PARTNER_BY_IDQUERY_RE'
P_PARAMETER_NAME = 'output').
input = lo_class_rtti->GET_METHOD_PARAMETER_TYPE
( P_METHOD_NAME = 'BUSINESS_PARTNER_BY_IDQUERY_RE'
P_PARAMETER_NAME = 'input').
Listing 4.2: Sample codes of acquisition of parameter types
Figure 4.1 depicts the diagram of implementation for this specific Web Service
after the first step for List and Search Generic UIBBs.
+CREATE_FIELD_CATALOG()
+CREATE_INPUT_PARAMETER()
+GET_INPUT_VALUE()
+GET_OUTPUT_VALUE()
«interface»Generic Adaptation Interface
+CREATE_FIELD_CATALOG()
+CREATE_INPUT_PARAMETER()
Generic Adaptation Class
+BUSINESS_PARTNER_BY_IDQUERY_RE()
-ID
-LASTNAME
-FIRSTNAME
-COMPANY_NAME
-PARTNER_ID
-LEGAL_FORM
ZBPHKCO_BUSINESS_PARTNER_BY_ID
Input parameter, Output parameter
+GET_DEFINITION()
+GET_PARAMETER_LIST()
-Input parameter : <unspecified> = ID
-Result field catalog : <unspecified> = LASTNAME
-Result field catalog : <unspecified> = FIRSTNAME
-Result field catalog : <unspecified> = COMPANY_NAME
-Result field catalog : <unspecified> = PARTNER_ID
-Result field catalog : <unspecified> = LEGAL_FORM
List Feeder Class
1 1
+GET_DEFINITION()
-Search field catalog : <unspecified> = ID
-Result field catalog : <unspecified> = LASTNAME
-Result field catalog : <unspecified> = FIRSTNAME
-Result field catalog : <unspecified> = COMPANY_NAME
-Result field catalog : <unspecified> = PARTNER_ID
-Result field catalog : <unspecified> = LEGAL_FORM
Search Feeder Class
1
1 1
1
Figure 4.1 Diagram of implementation for the specific Web Service after the
first step for List and Search Generic UIBBs
83
Figure 4.1 shows that after the first step of Generic Adaptation, the Generic
Adaptation Class extracts all the attributes from input and output parameter from
Proxy Consumer Class of ZBPHKCO_BUSINESS_PARTNER_BY_ID. And
also creates field catalogs for both List and Search feeder classes by
implementing the method of CREATE_FIELD_CATALOG and the method of
CREATE_INPUT_PARAMETER via GET_DEFINITION and
GET_PARAMETER_LIST.
84
4.4.2 Implementation of process Consumption via Generic
Adaptation section one
Section one of process Consumption via Generic Adaptation with method
GET_INPUT_VALUE:
For List Generic UIBB, it communicates with the parameter of
IT_PARAMETER within the method INITIALIZE as showed in the Listing 4.3:
IF IT_PARAMETER IS NOT INITIAL.
LOOP AT IT_PARAMETER INTO ls_parameter.
mr_input_value = ls_parameter-value.
ENDLOOP.
ENDIF.
CALL METHOD lr_gac->IF_Generic_Adaptation~get_input_value (
EXPORTING
input_proxy_value = mr_input_value).
Listing 4.3: Sample codes of GET_INPUT_VALUE for List Generic
UIBB
IT_PARAMETER is the parameter within INITIALIZE, kept the input values
for the input parameter, and lr_gac is the instance of Generic Adaptation Class.
For Search Generic UIBB, it communicates with the method
PROCESS_EVENT via parameter of IT_FPM_SEARCH_CRITERIA as
described in the Listing 4.4:
cl_fpm_guibb_search_conversion=>to_abap_select_where_tab( EXPO
RTING it_fpm_search_criteria = it_fpm_search_criteria
IMPORTING et_abap_select_table = lt_result ).
CALL METHOD lr_gac->IF_Generic_Adaptation~get_input_value (
EXPORTING
input_proxy_value = ls_result-partner_id).
Listing 4.4: Sample codes of GET_INPUT_VALUE for Search Generic UIBB
85
After the end user inserts the input values for the search criteria of search field
catalog, the end user pushes the search button, then the codes above is triggered
to get the input value for Search Generic UIBB.
Figure 4.2 shows the diagram of implementation for the first section based on
the specific Web Service for List and Search Generic UIBBs.
+CREATE_FIELD_CATALOG()
+CREATE_INPUT_PARAMETER()
+GET_INPUT_VALUE()
+GET_OUTPUT_VALUE()
«interface»Generic Adaptation Interface
+GET_INPUT_VALUE()
Generic Adaptation Class
INPUT_PROXY_VALUE
+INITIALIZE()
-Input parameter value : <unspecified> = 0000000008
List Feeder Class
IT_PARAMETER
+PROCESS_EVENT()
-Search field catalog value : <unspecified> = 0000000008
Search Feeder Class
IT_FPM_SEARCH_CRITERIA
1
1 1
1
Figure 4.2: Diagram of implementation for the method GET_INPUT_VALUE
based on the specific Web Service for List and Search Generic UIBBs
Figure 4.2 shows that the implementation of GET_INPUT_VALUE of the
specific Web Service for both List and Search Generic UIBBs. The importing
parameter INPUT_PROXY_VALUE gets input values from parameter
IT_PARAMETER from List feeder class, and also gets input values for search
criteria from parameter IT_FPM_SEARCH_CRITERIA from Search feeder
class.
86
4.4.3 Implementation of process Consumption via Generic
Adaptation section two
Section two of process Consumption via Generic Adaptation with method
GET_OUTPUT_VALUE. For all kinds of Generic UIBBs, the method
GET_OUTPUT_VALUE triggers the consumption of Web Service and sends
the output values to the method GET_DATA to create the concrete result field
catalog for Generic UIBBs.
CALL METHOD lr_bp_proxy_class->
BUSINESS_PARTNER_BY_IDQUERY_RE(
EXPORTING
input = input_proxy_value
IMPORTING
output = ls_bp ).
APPEND ls_bp TO lt_bp.
LOOP AT lt_bp INTO ls_bp.
le_bp-firstname = ls_bp-business_partner_by_idreponse-business_partner-
person-firstname.
le_bp-lastname = ls_bp-business_partner_by_idreponse-business_partner-
person-lastname.
le_bp-company_name = ls_bp-business_partner_by_idreponse-
business_partner-organization-company_name.
le_bp-legal_form = ls_bp-business_partner_by_idreponse-business_partner-
organization-legal_form.
le_bp-partner_id = ls_bp-business_partner_by_idreponse-business_partner-id.
ENDLOOP.
APPEND le_bp TO OUTPUT_PROXY
Listing 4.5: Sample codes of GET_OUTPUT_VALUE method
Above, Listing 4.5 are the codes within method GET_OUTPUT_VALUE,
lr_bp_proxy_class is instance of ZBPHKCO_BUSINESS_PARTNER_BY_ID.
The parameter OUTPUT_PROXY value contains the result values and is sent to
GET_DATA to fill the result catalog and displayed in the Generic UIBBs.
CALL METHOD lr_gac->IF_Generic_Adaptation~get_output_value(
EXPORTING
INPUT_PROXY = input_proxy_value
IMPORTING
OUTPUT_PROXY = CT_DATA).
Listing 4.6: Sample codes of GET_DATA method
87
Above, Listing 4.6 is the code within the GET_DATA method, which calls the
method GET_OUTPUT_VALUE to get the concrete output values to the
parameter CT_DATA. This parameter belonged to GET_DATA is responsible to
delivery the concrete output values for the result field catalog in the Generic
UIBBs at runtime automatically by Floor Plan Manager Framework.
Figure 4.3 displays the diagram of implementation of GET_OUTPUT_VALUE
based on the specific Web Service in the process of Consumption via Generic
Adaptation for both List and Search Generic UIBBs.
+CREATE_FIELD_CATALOG()
+CREATE_INPUT_PARAMETER()
+GET_INPUT_VALUE()
+GET_OUTPUT_VALUE()
«interface»Generic Adaptation Interface
+GET_OUTPUT_VALUE()
Generic Adaptation Class
INPUT_PROXY, OUTPUT_PROXY
+BUSINESS_PARTNER_BY_IDQUERY_RE()
-LASTNAME : <unspecified> = Brown
-FIRSTNAME : <unspecified> = Maria
-COMPANY_NAME : <unspecified> = DelBont Industries
-PARTNER_ID : <unspecified> = 0000000008
-LEGAL_FORM : <unspecified> = Ltd.
ZBPHKCO_BUSINESS_PARTNER_BY_ID
+GET_DATA()
-Result field catalog : <unspecified> = Brown
-Result field catalog : <unspecified> = Maria
-Result field catalog : <unspecified> = DelBont Industries
-Result field catalog : <unspecified> = 0000000008
-Result field catalog : <unspecified> = Ltd.
List Feeder Class
CT_DATA
11
+GET_DATA()
-Result field catalog : <unspecified> = Brown
-Result field catalog : <unspecified> = Maria
-Result field catalog : <unspecified> = DelBont Industries
-Result field catalog : <unspecified> = 0000000008
-Result field catalog : <unspecified> = Ltd.
Search Feeder Class
CT_DATA
1
1 1
1
Figure 4.3: Diagram of implementation of GET_OUTPUT_VALUE based on
the specific Web Service for both List and Search Generic UIBBs.
In the Figure 4.3, during the process of Consumption via Generic Adaptation,
the Generic Adaptation Class triggers the Proxy Consumer Class via parameter
INPUT_PROXY provided by the method GET_OUTPUT_VALUE and the
parameter INPUT_PROXY_VALUE provided by the GET_INPUT_VALUE
method. And then the output values are returned and stored in the parameter
OUTPUT_PROXY. At last, by communicating with the parameter of
CT_DATA in the GET_DATA methods for both feeder classes, the output
values are filled into the result field catalogs for both of List and Search Generic
UIBBs.
88
4.5 Summary
In conclusion, based on the implementation examples above, the Generic
Adaptation Interface is generic, and the Generic Adaptation Class is specific for
the specific Web Service, but is also generic for different Generic UIBBs.
Therefore, the implementation proves the concept of design, and also
implements the concept of the Generic Adaptation. The next chapter Evaluation
displays several use cases of consumption Web Services via Generic Adaptation
within Floor Plan Manager Framework.
89
Chapter 5 Evaluation
In this chapter, it is focusing on the evaluations when consuming Web Services
via Generic Adaptation within Floor Plan Manager Framework. All of the
evaluations for synchronous and asynchronous Web Services are described in
this chapter. However, it puts emphasis on the synchronous Web Service.
For the evaluation of synchronous Web Service, this chapter depicts the
consumption from two different Generic UIBBs, one is List Generic UIBB and
the other is Search Generic UIBB. All the three processes during the solution of
Generic Adaptation are evaluated, and also compared with the solution of
consuming Web Services with Web Dynpro ABAP described in the chapter
2.2.1.
For the evaluation of asynchronous Web Service, a Form Generic UIBB within
Floor Plan Manager Framework consumes one asynchronous Web Service to
show the evaluations of Generic Adaptation for asynchronous Web Services.
90
5.1 Synchronous Web Service via Generic Adaptation
In this section, the evaluation of consumption for synchronous Web Service via
Generic Adaptation will be evaluated as introduced in the chapter 3.4. The
performance is according to two use cases of consumptions separately from List
Generic UIBB and Search Generic UIBB within Floor Plan Manager
Framework. And then another use case is that two synchronous Web Services
are consumed via Generic Adaptation together within two Generic UIBBs in one
floorplan. The processes, which are used within this evaluation, are described in
the chapter 3.3. The synchronous Web Service is introduced in the chapter 4.4,
called Business Partner By ID Query Response. Another synchronous Web
Service is introduced in the chapter 5.1.3. The floorplan used for this evaluation
is OVP, as showed in the Figure 2.11.
5.1.1 Synchronous Web Service for List Generic UIBB
This section shows the evaluation of the synchronous Web Service, named
Business Partner By ID Query Response for List Generic UIBB. The processes
are introduced in the chapter 3.3. After the processes of Acquisition of attributes
and Field catalog creation, the input parameter and result field catalog are
created. The administrator now can insert values for the input parameter and also
choose the fields to display in the List Generic UIBB via Configuration Editor.
Figure 5.1 and Figure 5.2 show that the administrator is inserting values for
input parameter and choosing the fields to display later.
Figure 5.1: Inserting value for input parameter
As the input parameter includes only one attribute, called ID, for the method of
BUSINESS_PARTNER_BY_IDQUERY_RE in the Web Service of Business
Partner By ID Query Response, therefore, only one input parameter is created,
named ZBPHKPARTY_PARTY_ID. Figure 5.1 displays the popup from the
91
Configuration Editor, and then the administrator inserts “0000000008” as the
value for the input parameter.
Figure 5.2: Choosing fields for result field catalog
As described in the section 4.4, the output parameter of method
BUSINESS_PARTNER_BY_IDQUERY_RE includes five attributes, called
LASTNAME, FIRSTNAME, COMPANY_NAME, PARTNER_ID &
LEGAL_FORM, in the Web Service Business Partner By ID Query Response,
therefore the created result field catalog contain all the five attributes as fields.
Figure 5.2 displays the popup from the Configuration Editor, and then the
administrator decides to display all the five fields in the List Generic UIBB via
Configuration Editor.
Compared with the solution introduced in the chapter 2.2.1, named consuming
Web Service via Web Dynpro ABAP, during the creation of the service call the
user needs to manually configure the attributes as inputs or outputs. And also
after the service call is created as Web Dynpro component, the user requires
drawing the layout, writing codes to insert value for the inputs manually and
mapping the layout with the input values. However, by reusing the framework of
Floor Plan Manager Framework, Generic Adaptation provides a much easier
solution for users to handle the preparation of consumption Web Services
obviously.
Subsequently, the method of GET_INPUT_VALUE within process of
Consumption via Generic Adaptation gets the input value “0000000008” for the
input parameter, and sends to the method of GET_OUTPUT_VALUE as inputs
to call the Web Service.
92
Afterward, the output values are received and filled in the result field catalog in
the List Generic UIBB. Figure 5.3 describes the List Generic UIBB after the
consumption of the Web Service.
Figure 5.3: List Generic UIBB with output values
Figure 5.3 shows that the List Generic UIBB is displayed in the OVP floorplan
with the output values. Based on the input value of “0000000008”, the
consumption is triggered, and the concrete values for the attributes in the output
parameter are filled in the result field catalog.
The advantages of Generic Adaptation for synchronous Web Service with List
Generic UIBBs:
With Generic Adaptation, all the attributes with the parameters of Web
Service are all mapped in the field catalogs and input parameters. Then it is
much more convenient for the user to communicate with all the attributes.
With Generic Adaptation, compared with the solution of consumption via
Web Dynpro ABAP, it is much more meaningful. As in the solution of
consumption via Web Dynpro ABAP, all the attributes in the output
parameter are displayed in the screen after consumption. For example, one
Web Service includes the output parameter with 1000 attributes, most of the
values of attributes in the output parameter are blank or not relative the
usages. However, with Generic Adaptation, the user can work with the
Generic UIBBs as interface to choose the attributes displayed in the screen.
93
5.1.2 Synchronous Web Service for Search Generic UIBB
This section shows the evaluation of the synchronous Web Service, named
Business Partner By ID Query Response for Search Generic UIBB. The
processes are introduced in the chapter 3.3. After the processes of Acquisition of
attributes and Field catalog creation, the search field catalog and result field
catalog are created with the attributes from input and output parameters of the
Web Service. Then the administrator can choose the fields of both field catalogs
to display as search criteria or result field catalog in the Search Generic UIBB.
Figure 5.4 and Figure 5.5 show that the administrator is choosing fields for both
field catalogs.
Figure 5.4: Choosing field for search criteria
In the Figure 5.4, only one field, named PARTNER_ID is chosen as search
criteria as there is only one attribute in the input parameter of Web Service
Business Partner By ID Query Response.
Below, Figure 5.5 shows that all the fields displayed in the result field catalog
for the Search Generic UIBB.
94
Figure 5.5: Choosing fields for result field catalog
However, the method GET_INPUT_VALUE gets the input value at runtime
from the end user by communicating with the IT_FPM_SEARCH_CRITERIA
parameter in the method PROCESS_EVENT in the feeder class. This parameter
contains the input value from the end user for the search criteria. Then the input
value is stored in the parameter INPUT_PROXY_VALUE of method
GET_INPUT_VALUE.
After that, within the process of Consumption via Generic Adaptation, the
method GET_OUTPUT_VALUE triggers the consumption of Web Service with
the search criteria value. Then the output values are returned and stored within
parameter OUTPUT_VALUE. Finally, the output values are filled in the result
field catalog and displayed as showed in the Figure 5.6.
Figure 5.6: Search Generic UIBB with result list catalog
In the Figure 5.6, the Search Generic UIBB with the search criteria and result
field catalog are displayed, also with the successful messages in the Message
Region in the OVP floorplan. Moreover, the successful message is displayed to
depict that the consumption of Web Service is successful.
95
The advantages of Generic Adaptation for synchronous Web Service with
Search Generic UIBBs:
With Generic Adaptation, all the attributes with the parameters of Web
Service are all mapped in the search field catalogs and result field catalog.
The user can easily work on the search criteria and see the result in the result
field catalog. All the attributes are visible to the user via the field catalogs as
interfaces in the Search Generic UIBB. The user can choose the relevant
attributes, and delete the non-relevant attributes in the search criteria and also
in the final result field catalog.
With Generic Adaptation, compared with the solution of consumption via
Web Dynpro ABAP, it is much more meaningful. As in the solution of
consumption via Web Dynpro ABAP, all the attributes in the parameters
require to be manually mapped in the Web Dynpro context. And the user can
only work on the attributes while coding.
By reusing the feather of Message Region, the user can be informed whether
the consumption is successful or not via the messages displayed in the
Message Region.
96
5.1.3 Two synchronous Web Services for two Generic UIBBs
This section introduces another use case, which includes two synchronous Web
Services, and two Generic UIBBs. Both of the Web Services are consumed
within one OIF floorplan in the separate Generic UIBB.
This evaluation shows that with Generic Adaptation, the user of Floor Plan
Manager Framework can consume more than one Web Service in the same
floorplan at same time. For example, if the user wants to search for the
information of a business partner and also display the information of a product.
Then he might need to consume two synchronous Web Services in the same
floorplan at same time. Generic Adaptation can also work for this use case by
create two local instances of Generic Adaptation Class for each synchronous
Web Services.
Table 5.1 depicts the description of the second synchronous Web Service with
the name of method, attributes of input parameter and also output parameter.
Name Description
Product By ID Query Response Name of the second Web
Service
Synchronous Web Service Communication type
ZPOHKCO_PRODUCT_BY_IDQUERY_RES Name of Proxy Consumer Class
PRODUCT_BY_IDQUERY_RESPONSE_IN Name of method
PRODUCT_ID Name of attributes in the input
parameter
PRODUCT_ID, CATEGORY_ID,
TYPE_CODE, MEASURE_UNIT_CODE &
PRODUCT_PRICE
Name of attributes in the output
parameter
Table 5.1: Description of the second synchronous Web Service
Based on the design concept of chapter 3.4, the Figure 3.12 shows the diagram
of this use case with two senders and two receivers, which stand for these two
synchronous Web Services and two Generic UIBBs.
After the processes of Acquisition of attributes and Field catalog creation,
attributes from both synchronous Web Services are used to create the input
parameter and result field catalog for one List Generic UIBB, and search field
catalog and result field catalog for one Search List Generic UIBB. Figure 5.7
shows the input value for input parameter for the List Generic UIBB is insert as
“HT-1001” for the Web Service Product By ID Query Response.
97
Figure 5.7: Inserting input value of input parameter for Web Service Product By
ID Query Response
In the meantime, the administrator can choose the fields in the field catalogs for
both Generic UBBs in the Configuration Editor. After the end user choose
“0000000021” as the input value for the search criteria for Search Generic
UIBB, and then method of GET_OUTPUT_VALUE handles the consumptions
of both Web Services with separate instances of Generic Adaptation Class.
Figure 5.8 describes the OIF floorplan with concrete values for the result field
catalogs of two Generic UIBBs.
Figure 5.8: OIF floorplan with concrete values for both Generic UIBBs
In the Figure 5.8, the result field catalog includes the output values based on the
Partner ID “0000000021” got from the search criteria at runtime for the Search
Generic UIBB on the top. And the result field catalog displays the output values
based on the Product ID “HT-1001” got from the input parameter in the List
Generic UIBB on the bottom. It proves that the consumptions of both
synchronous Web Services for separate Generic UIBBs in one OIF floorplan are
successful. In additional, all the three kinds of floorplans provided by Floor Plan
98
Manager Framework are all possible. And, the successful message is displayed
to depict that both of the consumptions of Web Service is successful.
Therefore, based on all the three different use cases in the chapter 5.1, Generic
Adaptation successfully provides a generic solution to enhance Floor Plan
Manager Framework with the consumption of synchronous Web Service. The
user of Floor Plan Manager Framework can not only consume one synchronous
Web Service in one Generic UIBB, but also ability to consume more than one
synchronous Web Services in separate Generic UIBBs in the same floorplan at
same time.
99
5.2 Asynchronous Web Service via Generic Adaptation
This chapter briefly describes the evaluation of consumption asynchronous Web
Services via Generic Adaptation within Floor Plan Manager Framework based
on the design concept in the chapter 3.5.
From the design concept, for asynchronous Web Services, the user requires
generating two proxy classes, because the mechanism of asynchronous Web
Services in ESR includes a Proxy Provider Class at inbound service interface,
and a Proxy Consumer Class at outbound service interface. Therefore the user
has to generate one Proxy Consumer Class based on the Proxy Provider Class,
provided at inbound service interface, to handle the sending of requests. And in
additional, one Proxy Provider Class based on the Proxy Consumer Class,
provided at outbound service interface, to handle the receiving of returned
messages.
This use case includes one asynchronous Web Service, and the description is
described in the Table 5.2. And two generated proxy classes, one Form Generic
UIBB is created in the floorplan displaying all the attributes of input parameter
for choosing. And one Report, which is pure ABAP programming, is created to
communicate with the generated Proxy Provider Class for the receiving of
returned messages. This use case is focusing on the request of message with
Form Generic UIBB, the response of message is handled in the backend by a
pure ABAP programming.
Name Description
Send Single Flight Booking Name of Web Service
Asynchronous Web Service Communication type
ZHKCO_SINGLE_FLIGHT_REQ Name of Proxy Consumer Class
ZHKCO_SINGLE_FLIGHT_RES Name of Proxy Provider Class
SINGLE_FLIGHT_REQUEST_IN Name of method (Consumer)
SINGLE_FLIGHT_RESPONSE_OUT Name of method (Provider)
FLIGHTDATA, FLIGHT_CLASS,
FIRSTNAME, LASTNAME &
DATEBIRTH
Name of attributes in the input
parameter
AGENCY_NUMBER,
ORDER_NUMBER
Name of attributes in the output
parameter
Table 5.2: Description of asynchronous Web Service
After the processes of Acquisition of attributes and Field catalog creation are
finished, the search field catalog is created with the attributes in the input
parameter, and the attributes of output parameter are extracted to create result
field catalog in the Form Generic UIBB, which is totally the same as the
processes for synchronous Web Services. Then the method
100
GET_INPUT_VALUE gets the input values from the end user at runtime, which
is also the same as it is worked for Search Generic UIBBs. After all, the method
GET_OUTPUT_VALUE triggers the consumption of asynchronous Web
Service with the input values and all the processes are done for the Proxy
Consumer Class and Form Generic UIBB. Figure 5.9 describes the runtime
when the end user fills the input values for the search field catalog in Form
Generic UIBB.
Figure 5.9: Filling the input values for the Form Generic UIBB
When the receiver is alive, the consumption will be processed in the backend,
and the output values are returned to the sender by the pure ABAP
programming. Figure 5.10 depicts the output values by the ABAP programming
in the backend.
101
Figure 5.10: Returned output values in the backend
The use case of asynchronous Web Service shows that Generic Adaptation can
also work for asynchronous Web Services by also mapping the attributes in the
input and output parameter of Web Services with the field catalogs and input
parameters. Then the user can directly work with these attributes via the Generic
UIBBs. However, Floor Plan Manager Framework is standard for UI framework,
and the responses of asynchronous Web Services are always taking a long time.
Therefore, the responses of messages for asynchronous Web Services are always
handled in the backend with the pure ABAP programming.
All in all, Generic Adaptation can work for Floor Plan Manager Framework to
consume all kinds of Web Services by mapping the attributes of input and output
parameter in the Web Services into the field catalogs and input parameters, and
handling all the interactions during the consumptions at runtime.
102
Chapter 6 Summary and Outlook
Nowadays, Floor Plan Manager Framework is more and more used as standard
UI framework for Business Suite applications within SAP and around all the
SAP’s customers. Moreover, the Web Services are more and more consumed
within the Business Suite applications as well, along with the worldwide used
Enterprise SOA. The existing solutions within SAP are consumption Web
Services via SAP Web Dynpro ABAP and consumption via SAP NetWeaver
Composition Environment. Neither of them is based on the Floor Plan Manager
Framework.
Therefore, the idea of the solution based on the Floor Plan Manager Framework,
achieves the consumption of Web Services within Business Suite applications
via reusing the benefits of Floor Plan Manager Framework and also other
existing architectures and technologies within SAP. The new solution is not only
generic for different Web Services, but also for all the three Generic UIBBs
within Floor Plan Manager Framework.
103
6.1 Summary of the thesis
The First chapter depicts the introduction, which gives an overview with the
outline diagram of Generic Adaptation. And also the motivation of the thesis is
mentioned in the first chapter with the main problems to solve.
The second chapter describes all the existing architectures and technologies
within SAP, which are reused within this thesis. And also the related solutions
and products are described at the end of this chapter with a table, which
compares with the requirements of Generic Adaptation and other existing
solution, then points out a proposal for the design of Generic Adaptation.
The third chapter, which is also the concept of design, is based on the proposal.
Within this chapter, the design of Generic Adaptation is described in details with
mainly three processes and also the applicability for both synchronous and
asynchronous Web Services is analyzed here. Based on the proposal, Generic
Adaptation includes a Generic Adaptation Interface, which is totally generic for
all kinds of Web Services. And four methods provided by the Generic
Adaptation Interface take care of the adaptations between Floor Plan Manager
Framework and Web Services under the help of Enterprise SOA and Generic
UIBBs. Generic Adaptation also provides the Generic Adaptation Class, which
implements the Generic Adaptation Interface. During the consumption of Web
Services, an instance of Generic Adaptation Class is instantiated for the specific
Web Service. Therefore, the Generic Adaptation Class is specific for Web
Services. This chapter also gives an example to demonstrate the possibility of
consuming multiple Web Services at same time within one floorplan of Floor
Plan Manager Framework.
The fourth chapter is the implementation part, which provides the prototypes to
demonstrate that the design of Generic Adaptation is working. This chapter is
focusing on the details of the implementation of the prototypes of Generic
Adaptation. It mainly includes the implementation of Generic Adaptation
Interface with the four methods, and also the important signatures of the
methods, and also the implementation of the Generic Adaptation Class with a
concrete example, along with the UML diagrams for technique details.
The fifth chapter is the evaluation part of Generic Adaptation based on the
prototypes for both synchronous Web Services and asynchronous Web Services.
As in conclusion, Generic Adaptation provides a generic solution for the
consumption of Web Services within Floor Plan Manager Framework by
implementing the Generic Adaptation Interface, and also it can work for multiple
Web Services by providing an instance of Generic Adaptation Class for each
Web Service. The prototypes are basically satisfied all the requirements and
104
enhance the functionality of Floor Plan Manager Framework with the
consumption of Web Services.
The sixth chapter gives the summary and outlook for the thesis. Within the
summary, the main aspects of each chapter are described here. And the outlook
is focusing on the future plan and also the short points.
During the work on the research questions for this thesis the two problems
described in the first chapter have been achieved.
1. The solution should be generic. Generic solution would be more
meaningful for users to consume Web Services within Floor Plan Manager
Framework. The users can consume any Web Services in the same way.
This Generic Adaptation provides the Generic Adaptation Interface as the
mainly generic part for all kinds of Web Services. And all the four methods
within the Generic Adaptation Interface achieve the function of adaptation
between Floor Plan Manager Framework and Web Services.
2. Secondly, the question is how to integrate the consumption of Web
Services into Floor Plan Manager Framework. The idea is to provide a
mechanism to map the attributes of input and output parameters in the
Web Services to Floor Plan Manager Framework and easily for users to
achieve their Business Suite applications.
This Generic Adaptation analyzes the structures of Web Services and extracts all
the attributes into the field catalogs in flatten. And all the field catalogs are used
as the interfaces for the Generic UIBBs within Floor Plan Manager Framework
to communicate with the Web Services. Therefore, the users of Floor Plan
Manager Framework can consume the Web Services as the same of consumption
of business data as before.
105
6.2 Outlook
During the work on the research questions for this thesis a number of new
questions have been raised that are worth exploring in future work.
Q1. Generic Adaptation Interface is generic, but the Generic Adaptation
Class is still specific for the Web Service. Is there any other way to achieve a
full generic solution?
The original idea is to achieve the generic by providing an interface directly
during the generation of all the Proxy Consumer Classes. However, the
generation is fixed, and also the Proxy Consumer Classes are required to be
stable, non-editable.
Q2. Secondly, how is the possibility of automation for the process of
Acquisition of attributes?
The process of Acquisition of attributes is semi-automation. The Controller
predefines the flatten parameter types with the attributes, and then searches for
the parameter types of Web Services at runtime by comparing with the name of
Web Services and methods. Moreover, the Controller compares the attribute
types within the predefined parameter types with the attribute types from the
searched parameter types at runtime one by one. If it is the same, then the
attributes are filled into the predefined flatten parameter types. However, this is
not a full automation solution. It is better to provide a solution to extract all the
attributes with the name of Web Services and methods.
Q3. Thirdly, how is the possibility of automation for the process of Field
catalog creation?
The design of the process of Field catalog creation is those fields catalogs are
defined with the predefined flatten parameter types in the methods
CREATE_FIELD_CATALOG and CREATE_INPUT_PARAMETER at design
time. This process can be automation in the way that all the field catalogs are
defined based on the predefined flatten parameter types at runtime automatically.
Q4. Fourthly, how is the possibility of automation for the implementation of
Generic Adaptation Class?
The best way to support automation of the implementation of Generic
Adaptation Class is to provide a wizard with several steps. The steps are
provided for the users to insert the names of Web Services, Generic UIBBs, and
also the attributes of the parameter types and etc. And then the instance of
Generic Adaptation Class for the specific Web Service is generated out.
106
Q5. Fifthly, how should the entire mandatory attributes is included for the
consumption of Web Services?
For the mandatory attributes, either the Floor Plan Manager Framework should
enhance the feature for it or the improved Generic Adaptation should include the
ability to select all the mandatory attributes for the consumption of Web
Services.
This thesis has described that the solution of Generic Adaptation can bridge the
gap between the Web Services and Floor Plan Manager Framework, and
provides a generic solution with the Generic Adaptation Interface. All the
problems for the solutions are solved, and all the basic requirements are
satisfied. However, this solution still has some shorts points described in the
outlook. Therefore, it still has some open questions for the future work, and the
functionality of Generic Adaptation can be enhanced to meet more requirements
which will lead more and more wide use of it.
107
Bibliography
[1]: SAP homepage. URL: www.sap.com. Accessed on 05/04/2010
[2]: Fundamentals of Web Dynpro For ABAP. SAP AG. URL:
https://websmp106.sap-
ag.de/~form/sapnet?_SHORTKEY=01100035870000441461&_SCENARIO=01
100035870000000112&_OBJECT=011000358700006256352006E . Accessed
on 05/04/2010
[3]: Daniel Stollenwerk. Enterprise SOA Development Handbook. SAP AG, 30
April 2008. URL: http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/40db47
35-02f9-2a10-b198-a888a056bb67. Accessed on 08/04/2010
[4]: Floor Plan Manager for Web Dynpro ABAP. SAP AG. URL: https://websmp101.sap-
ag.de/~form/sapnet?_SHORTKEY=01100035870000441461&_SCENARIO=0
1100035870000000112&_OBJECT=011000358700000847392009E.
Accessed on 10/04/2010
[5]: Wikipedia, 2010a. Wikipedia: SAP GUI. URL:
http://en.wikipedia.org/wiki/SAPgui. Accessed on 15/04/2010
[6]: SAP Library, 2010a. SAP Library: Creating Web Applications with BSPs.
URL: http://help.sap.com/saphelp_470/helpdata/en/c8/101c3a1cf1c54be1000000
0a114084/content.htm. Accessed on 16/04/2010
[7]: SAP Library, 2010b. SAP Library: ABAP Workbench. URL: http://help.sap.com/saphelp_glossary/en/35/26b1a7afab52b9e10000009b3
8f974/content.htm. Accessed on 16/04/2010
[8]: SAP Library, 2010c. SAP Library: Web Dynpro for Java. URL: http://help.sap.com/saphelp_tm60/helpdata/en/15/0d4f21c17c8044af48681
30e9fea07/content.htm. Accessed on 17/04/2010
[9]: Neha Thukral. SAP Wiki: Introduction to controller. 22 April 2009. URL: http://wiki.sdn.sap.com/wiki/display/WDABAP/Introduction+to+controllers
[10]: Services Registry: Classification Services. SAP AG. April 2009. URL:
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/102c7743-
c904-2c10-bfa1-fef093e786ec?QuickLink=index&overridelayout=true
[11]: Peter Gutsche. SAP Process Integration Handbook. SAP AG. 30 June
2009. URL:
108
http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/8078cff3-
e045-2c10-9bae-abf0ca5040c5?QuickLink=index&overridelayout=true
[12]: SAP Library 2010e. SAP Exchange Infrastructure. URL:
http://help.sap.com/saphelp_nw04/helpdata/en/0f/80243b4a66ae0ce10000000a1
1402f/content.htm. Accessed on 22/04/2010
[13]: Peter Markus. SAP Wiki: Why point-to-point support requires extending
implementations. SAP AG. March 2010. URL:
https://wiki.wdf.sap.corp/wiki/display/PTGSOA/Why+point-to-
point+support+requires+extending+implementations. Accessed on 23/04/2010
[14]: Floor Plan Manager Developer’s Guide. SAP AG Internal Document.
URL:
https://portal.wdf.sap.corp/irj/go/km/docs/room_project/cm_stores/documents/w
orkspaces/e1f2879b-3584-2c10-0ca9-
bc6e2c47815c/FPM%20Developer's%20Guide%20702e.pdf. Accessed on
06/05/2010
[15]: Getting Started with Service Bus-Based Integration. SAP SDN. URL:
http://www.sdn.sap.com/irj/sdn/soa-servicebus?rid=/webcontent/uuid/40984052-
9449-2a10-6da5-a2457efc7194. Accessed on 08/05/2010
[16]: Saundattikar, Rohan. SAP WiKi: FPM Phase Model. SAP AG. June 2009.
URL:
https://wiki.wdf.sap.corp/wiki/download/attachments/626624202/FPM+Phase+
Model.pdf?version=1. Accessed on 07/07/2010
[17]: Saundattikar, Rohan. SAP WiKi: GUIBB. SAP AG. June 2009. URL:
https://wiki.wdf.sap.corp/wiki/display/FPM/GUIBB. Accessed on 09/07/2010
[18]: Stiehl, Volker. SAP insider: A How-To Guide for Consuming Services
with SAP NetWeaver Composition Environment. SAP insider. Apr/May/Jun
2008. URL:
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/b0d4aa08-
beed-2a10-fab2-ad975cead04a?QuickLink=index&overridelayout=true.
Accessed on 21/07/2010
[19]: Ganz, Bertram. SAP Wiki: FAQ – Models – Adaptive Web Service. SAP
AG. 20th
Jan 2009. URL: http://wiki.sdn.sap.com/wiki/display/WDJava/FAQ+-
+Models+-+Adaptive+Web+Service. Accessed on 21/07/2010
[20]: Using the Adaptive Web Service Model for Java Web Dynpro. SAP AG
Article. 14th
August 2006. URL:
http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/b2bc0932-
0d01-0010-6d8e-cff1b2f22bc7. Accessed on 21/07/2010
[21]: Joshi, Dhawal. SAP AG Article. Web Dynpro Java – Highlights of
Adaptive Web Service Model. SAP AG Article. 2nd
April 2007. URL:
109
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/b04308ed-
62d5-2910-b3a6-c26771b1c78e?language=zh. Accessed on 22/07/2010
[22]: JD Edwards EnterpriseOne. Oracle Products and Services. URL:
http://www.oracle.com/us/products/applications/jd-edwards-
enterpriseone/index.html. Accessed on 22/07/2010
[23]: Harrison Dave. DWS. JDE EnterpriseOne Business Services – Consuming
External Web Services Tutorial. DWS. July 2009. URL:
http://www.oracle.com/technology/tech/fmw4apps/jde/pdf/consuming-external-
web-services-using-business-services.pdf. Accessed on 22/07/2010
[24]: Oracle. JD Edwards EnterpriseOne Tools 8.98 Business Services
Development Guide. Oracle. September 2008. URL:
http://download.oracle.com/docs/cd/E13780_01/jded/acrobat/E1_TOOLS898TD
E-B0908.pdf. Accessed on 01/08/2010. Accessed on 01/08/2010
[25]: Josef Spillner, Marius Feldmann, Iris Braun, Thomas Springer, and
Alexander Schill. Ad-Hoc Usage of Web Services with Dynvoker. Dresden
University of Technology, Dept. of Computer Science, Chair for Computer
Networks, Dresden, Germany, 2008
[26]: Josef Spillner. GUI Development Descriptor. 20th March 2007. URL:
http://wsgui.berlios.de/guidd/. Accessed on 02/08/2010
