SAP BW/4HANA write interface-enabled ADSO connected to a 3rd Party Tool

[FrankRiesner]

Dear SAP BW/4HANA enthusiasts!

As opposed to SAP NetWeaver BW in the past, BW/4HANA provides a new write interface which was introduced in Gordon Witzel´s earlier blog about Data Integration with SAP BW/4HANA 2.0 .
This new interface provides the possibility to integrate data into the ADSO inbound table (SAP BW/4HANA 2.0 SP00) or InfoObject Characteristics (SAP BW/4HANA 2021 SP04) without the need of the normal standard SAP BW/4HANA objects like Source System, DataSource, Transformation and Data Transfer Process which pull the data into SAP BW. Instead data can be pushed into these BW/4HANA objects from outside by tools such as SAP Data Services, SAP NetWeaver Process Integration, SAP Data Intelligence, SAP BTP Integration Suite, or similar 3rd party solutions. For this reason, the whole scenario is sometimes referred to as Push ADSO (e.g. in SAP notes).See also more details in the SAP BW/4HANA application help.

The new write interface can also serve as interface for SAP and non-SAP cloud sources, more details in my follow-up blog post https://blogs.sap.com/2021/09/22/sap-cloud-integration-into-sap-bw-4hana/.

This SAP BW/4HANA feature provides a clear successor interface for the former source systems of SAP BW 7.5 called “Web Service”, “Data Services”, and “External System”:

SAP recommends leveraging the new write interface during conversion projects for sources which are connected to SAP BW 7.x on these obsolete source system types. There is no automated conversion path, but the manual steps are well documented in following SAP notes:

• 2441826 - BW4SL - Web Service Source Systems
• 2441836 - BW4SL - SAP Data Services and External System Source Systems
• New features SAP BW/4HANA conversion: Q1.2021 - Transfer WebService DataSource to a Placeholder ADSO

 **** UPDATE 06/2023 ****
During a customer conversion project, we ran into challenges replacing a BW 7.5 Web Service providing mass tracking data. We discussed the matter with the SAP development team and in the end, RSPM processing (i.e. the new BW/4HANA TSN-based request mgmt) can now be adjusted for this Push scenario by setting of RSADMIN parameter PUSH_ADSO_PROCESS_TRACE = N which suppresses the creation of RSPMLOG entries. So if the standard push scenario does not meet your performance expectations, consider following notes:

• 3283799 - Push ADSO: Messaging Request enablement
• 3290288 - Failure in function module RSDRI_INFOPROV_READ
• 3339770 - BW4:RSPM:DATA_PUSH:Performance Issue:Frequent Checks:Traces
• 3340847 - Push ADSO: Performance issues with internal RSPM Access (parallel loading)

**** end of update ****

 A fact not very widely known is, that the write interface is not limited to SAP solutions but can also be addressed by 3rd party tools (although stated differently in some sources in the past). In the following scenario we will describe how this can be accomplished based on the SEEBURGER Business Integration Suite (BIS):

In our recent project, the customer uses SEEBURGER BIS as its general strategic platform for integration requirements in its IT landscape. During a shell conversion project of their SAP BW 7.5 to SAP BW/4HANA 2.0, the former SEEBURGER BIS connection via the “Web Service” source system had to be redesigned in a way that it is able to address the new ADSO write interface of SAP BW/4HANA.
The following is a step-by-step guide to how this was achieved:

Step 1: In the SAP BW/4HANA Modeling Tools, create a new ADSO (here: technical name ZADSO) as “Standard DataStore Object” (or “Staging DataStore Object”). For these two types the modeling parameter “Write Interface-Enabled” is available to be switched on.
Step 2: After activation of this new ADSO, template URIs (Uniform Resource Identifiers) are generated in the Properties window.
These URIs have the following purpose:

Get Structure:	https://server:8443/sap/bw4/v1/push/dataStores/zadso --> Get the JSON schema and get CSRF token
Get Sample Data:	https://server:8443/sap/bw4/v1/push/dataStores/zadso/sampleData{?records,seed} --> Get sample data generated by the server
Send Data:	https://server:8443/sap/bw4/v1/push/dataStores/zadso/dataSend{?request,datapid} --> Send data using the CSRF token
Open Request:	https://server:8443/sap/bw4/v1/push/dataStores/zadso/requests --> Open request (TSN) and get CSRF token
Close Request:	https://server:8443/sap/bw4/v1/push/dataStores/zadso/requests/{request}/close{?error} --> Close request (TSN)

Step 3: For sending data a CSRF token is needed, otherwise an error 403 HTTP Forbidden with message “CSRF token validation failed” will be returned. To get this token, an HTTP GET needs to be done on the Open-Request-URL with key “x-csrf-token” in the HTTP header. In the response, this key will be filled with the token. In the HTTP GET request, basic authentication needs to be set with a valid user and password.

 Step 4: Data can be sent to the inbound table of DataStore object ZADSO doing an HTTP POST on the Send-Data-URL with the JSON data as raw body and the CSRF token in the HTTP header. Basic authentication needs to be set as well. If the data is sent from another IP than the open request, the cookie from the Open-Request response needs to be in the HTTP Header,
e. g. Cookie =
sap-usercontext=sapclient=001;path=/;SAP_SESSIONID_BWP_001=Ui3914ArIMefp4pXhIjg9Z;path=/;

The response from SAP is empty.

Final Step: After the data is sent successfully, a new request TSN is listed in the SAP BW/4HANA Cockpit app "Manage DataStore". From this point onward, this request TSN and the related data behaves like any other request TSN in an ADSO inbound table. For example, you can activate it to provision it to other InfoProviders or consume it with a BW query.

If SEEBURGER BIS detects an error (e.g. wrong syntax in a DATE field), no request TSN is created until the error is corrected in the source system.
Explicit Request Handling
By following the above steps no explicit request TSN is used in SAP BW/4HANA. This means, every Data-Send creates its own implicit request TSN. If there is the need to control the request TSN from outside, it needs to be opened explicitly to be able to obtain the request TSN.

To do so, after step 3 the Open-request-URL needs to be called again, this time with HTTP POST to receive the request TSN e. g. 20200721105757000003000.


This request TSN and the corresponding data package IDs have then to be added to the Data-Send call as a parameter, e. g. …/zadso/dataSend?request=20200721105757000003000&datapid=1. This way several Data-Send calls can be done using the same request TSN.

 At the end, the request TSN needs to be closed explicitly by calling HTTP POST on the Close-request-URL with the related CSRF token and request TSN, e. g. …/zadso/requests/20200721105757000003000/close.

So in summary, the steps are:

1. GET   …/zadso/requests [Obtain CSRF token]
2. POST …/zadso/requests [Open request and get TSN]
3. POST …/dataSend?request=<TSN>&datapid=1 [Send the data several times, based on  increasing data package ID (x+1)]
4. POST …/zadso/requests/<TSN>/close [Close request with TSN]

Additional technical details

• To retrieve the JSON schema a plain HTTP GET can be performed on the Get-Structure-URL.
• To generate sample data the Get-Sample-Data-URL can be called:
  GET …/zadso/sampleData?records=<number of records>&seed=<seed>
• If the sent data is not correct, it is possible to close the request and mark it as Error. Use the CLOSE-Request-URL with parameter error=true to achieve this. The data is then excluded from the ADSO activation queue.
• The data activation in the target ADSO can be triggered automatically by means of a Process Chain in ‘Streaming’ mode, which is executed when a Request in the inbound queue is closed and if the “streaming” Process Chain contains a Process Variant ‘Activate DSO Data’ specifying the DataStore name.“ See more details in my separate blog covering BW process chains in streaming mode.

Conclusion
In SAP BW/4HANA, the write interface-enabled DataStore object / InfoObject Characteristic provides the interface of choice for sources of data which were connected to SAP BW 7.x via source system types “Web Service”, “Data Services”, and “External System”. As these types have been decommissioned in SAP BW/4HANA, a manual conversion is required as documented in the two SAP notes mentioned at the beginning.

The example described in this blog showed, that also 3rd party tools like SEEBURGER BIS can be leveraged to provision data to SAP BW/4HANA this way. In our customer project this resulted in following benefits:

• The SEEBURGER platform was already connected and integrated to several source systems, and it manages and secures access to a broad range of SAP and non-SAP data sources. No changes were required in this infrastructure.
• This relieved SAP BW/4HANA developers from tasks that are not explicitly in their focus, such as managing and maintaining source systems of different types, managing the data quality and data transfer processing and monitoring.
• Based on the new write interface, integration of SAP BW/4HANA into the customer environment is fast and easy. Existing connections could be reused in one-step, reducing integration time and cost.
• Thanks to the new ADSO write interface and the capabilities of the SEEBURGER platform, the customer was able to execute and to achieve these objectives.