Skip to end of metadata
Go to start of metadata

This document was originally created by Thomas Alexander Ritter during the creation of the SAPlink for ABAP in Eclipse plugin. To make this information available for everyone interested in ABAP AiE SDK development this page was moved to this space.

Aim of this document

This document should give you an overview on how SAPlink could be integrated into ABAP in Eclipse. It shows the big picture and features all major components which have to be built on the backend server. However, it is not a complete description of the solution. We deliberately left out the client implementation.

Quick introduction of the ABAP in Eclipse architecture

ABAP in Eclipse follows the classic client/server architecture. The communication between the server and the client is done by using the http protocol over an RFC connection. The backend services follow the REST architecture. The backend services are client independent which means that the backend has no knowledge that the requests come from an Eclipse based client. It could also be a client based on the Visual Studio. This is an important aspect. Client technologies (especially UI technologies) change all the time; we want to build services which stand the test of time.

Overview of a possible design for the SAPlink integration

The use case for this design is the import of a slinkee into the system.
The integration consists of three major steps. First the client has to check whether the backend supports the ABAP in Eclipse integration. Second, the client starts the import by sending the slinkee data to the backend where it gets stored. Third, the import gets started by the client. In the following paragraphs we look at each step in more detail.

1) Resource discovery

The first step the client has to complete is to check whether the backend supports the ABAP in Eclipse SAPLink integration. The client has to check whether the backend offers the necessary services and has to obtain their URLs. This is being done by sending a request to the discovery service. The discovery service has been built to solve two problems. First, it allows the client to check what services the backend offers. Second, it gives the client access to the service URLs. This is important because it removes the need to hard code URLs on the client. Hard-coded URLs should be always avoided since a change of the URL requires the installation of a new client which features the new URL.
The discovery service is based on the atom service document standard ( It gets called via:

GET /sap/bc/adt/discovery HTTP/1.1

And returns a document similar like this

<?xml version="1.0" encoding="utf-8"?>
  <app:service xmlns:app="" xmlns:atom="">
      <app:collection href="/sap/bc/saplink/import/slinkee">
      <atom:title>Import Slinkee</atom:title><atom:category term="import-slinkee" scheme=""/>
      <app:collection href="/sap/bc/saplink/import/nugget">
      <atom:title>Import Nugget</atom:title><atom:category term="import-nugget" scheme=""/>

This document features two services: import slinkee and import nugget. Both can be accessed via their respective category term: import-slinkee and import-nugget. These terms are being used by the client to get the service URLs.

The integration into the discovery service is being done by implementing an ABAP class which implements a special interface and registering it via a BADI implementation. More technical detals will be provided soon.

2) Send slinkee data to the backend and store it in an import queue

After step one the client knows the URLs for the import services offered by the backend. Now, the client would read the slinkee file which is stored on the client. Afterwards the client sends the file content via the following http request to the backend server.

POST /sap/bc/saplink/import/slinkee HTTP/1.1
Request Body: Slinkee ABAP XML

The backend service takes the data stored in the request body and creates a new entry in a database table which serves as an import queue. Each entry in the import queue gets a unique id (GUID). If the creation of the import queue entry was successful the backend sends the following response.

Status code: 201 CREATED
Location header: /sap/bc/saplink/import/slinkee/{guid of import queue entry}

This signals the client that the import queue entry was created successfully and also gives it an URL which can be used to access it.

3) Start import via starting SAP GUI in client

In the last step we have to solve a fundamental problem. Currently, not all Workbench APIs can be called in so called “dark mode” which means in a way that no interaction with an UI is necessary. Certain APIs open UI dialogs while they are running. If no UI is attached to the session which triggered the API a shortdump is raised. In order to solve this problem we could use a special ABAP report which gets started by the client. We would use the SAP GUI integration to

a) Open the report
b) Fill a special UI field with the GUID which the import service returned to us
c) Execute the report
d) If technically possible, close the SAP GUI session (this should do the trick:

Flow diagrams

In a flow diagram, the 'import slinkee' scenario might look like this:

In contrast, the inverse 'export slinkee' scenario might look this way:

  • No labels