Skip to Content

Web Services – Defining the basics

logical view

There has been much written and documented about the subject of web services. but for those customers who are just starting out on the path to SOA project delivery it can appear very daunting.

The sheer volume of information can be viewed from two perspectives.. 

1. Business user – prinrilay an interaction or process view

2. Technologist – a technical & implementation focussed view

 These two perspectives are often contradictory in terms of language and topics covered. In this quick posting i will focus on giving the technologist a view on the netweaver platform and what is deployed when we discuss ‘Enterprise Services’, while also describing how business requirements can be gathered and understood.

1. Business User

A. Structured discussions: 

To simplify the discussion it is always easietr to start with a natural language description of what a user wants to achieve. We can gain access to various templates that help us descstructure the discussion, the best starting place i have found is to search for ‘Use Case template’ on a search engine to find a template you can quickly adopt. The Object Management Group ( has lots of collateral to help in this area.

As a start point you may wish to include the following information as a minimum:

  • user description,
  • description of the goal of the user (the outcome),
  • description of the major systems,
  • list of any pre-conditions before starting the task,
  • list of the main steps taken to achieve the goal,
  • the required outcomes,
  • list of any errors that may be seen in addition to the positive execution of the tasks.

This may seem like an onerous task but it the basis for a sound understanding of requirements, it also becomes quicker once the user and interviewer become familiar with what is required.

B. Linking a Use case to a business process view:

Once you have populated your basic use case template that describes the process and major steps, you will need to identify what systems, tools and applications support this process. This is where swimlanes and interaction diagrams ( will assist. I will not describe these here as i want to quickly move onto the technologist view of the world.

Once a description of the user  goals, processes and major systems has been agreed, we can then begin to map the main tasks and the links between the tasks together. in short, any link between a task should be evaluated against the basic question: is this suitable for being a technical (e.g a web) service or is it suitable for a business user to continue providing the solution manually (e.g rekeying data)

The best way i can describe the technology approach (when we have idetinitifed a web service) is to start with an overview picture of how we technically provide a web service from the netweaver application server (Java or ABAP):


In the diagram I have commented on each major ‘layer’ that provides the web service implementation on neweaver. As you will see from the diagram a web service is not limited to the content already provided by SAP as an enterprise Service. If you are interested in how the tooling allows you to create a web service based your requirements not what SAP content is available (contract first modelling) you will find an excellent blog from Joachim von Goetz here:

So to summarise the overview: irrespective if the business application you are implementing, you will start from an understanding of what the user requirements are.

You can then move on to modelling the service implementation, assuming you have identified the need for a service based on your swimlane diagram and your interaction diagrams.

You will need to create the service definition, for this you will need to review Joachims blog on creating a new service endpoint based on the data content and tools from SAP.

Finally you will need to couple any extensions needed on SAP (Data, security, processes) to ensure interoperability with your existing consuming application to meet your specific requirements.

These extensions can be implemented using the Enterprise Services Builder tool, you will see from the following diagram the next level of detail that follows from the diagram above.



It is worth bearing in mind that this blog is designed to give you an entry point into the technology side of implementing web services. for more details on the tooling and sap content already available there are some usefule links below.

Some useful links to provide a starting point for your SOA project are:

SAP Core & Global Data Types: 

SAP Global Data Types (GDTs) are SAP-wide unified data types representing business-related content built according to the UN/CEFACT CTTS. All elements of eSOA services are described (typed) by GDTs They are the basis for the harmonization of the SAP eSOA services.


Enterprise Services Builder:

Enterprise Services Builder allows you to provide your own Enterprise Service Definitions in alignment with SAP’s Service Modeling and Development Methodology

Publish services from PI 7.1 to the Service Registry

Be the first to leave a comment
You must be Logged on to comment or reply to a post.