Exposing SAP data with a Note 3255746 in mind

In a nutshell with an update of the Note 3255746 SAP stops customers and 3^rd party applications from using RFC modules in the ODP Data Replication API to access and extract SAP data from ABAP sources. As these APIs are only for SAP’s internal use. This is an SAP's ban of RFC usage.

This means it is not possible to use ODP to access ABAP CDS views directly. Instead, the ODP component with OData API provided by SAP for data extraction should be used. This API is stable and recommended for all customer and third-party applications. Furthermore, SAP advises customers “to use SAP Datasphere for realizing data replication scenarios to move data from various SAP sources (such as SAP S/4HANA, SAP BW, SAP ECC sources etc.) into third-party applications & tools.”

Restriction was introduced on February 2nd, 2024, when SAP updated the Note mentioned. Note originated sometime around year 2022 when it stated that “ODP RFC method were unsupported”. But 2024 Feb update of the Note made unsupported -> unpermitted.

Impact on 3rd party tools / Target platforms

SNP/DataVard Glue - no impact as the tool uses an technology that is independent of any third-party (SAP's in this case). More info.

TheoBald Xtract – impacted, Theobald claims it will enhance its tool to use OData API (as well as it is currently utilizing the RFC modules) sometime around 2024.Q4. More info.

Init Software – Init ODP Source Connector is impacted. Use Init OData v2 Source / Sink Connector More info.

Databricks – impacted, as their lakehouse ingests data from many sources More info.

Azure Data Factory (ADF) / Azure Synapse Analytics - data ingestion platforms of MS Azure is impacted by this as Azure Data Factory SAP CDC connector is using the ODP framework. Use OData API based connector instead that is available in Azure. More info.

Qlik Replica – impacted, More info.

Google Cloud Data Fusion – As there are many GCP connectors for SAP (e.g. BigQuery, SAP BW Open Hub Batch Source, SAP OData, SAP ODP, SAP SLT Replication, SAP Table Batch Source) some of them are impacted. Specific case needs to be reviewed and a new integration needs to be built based on OData API if impacted. More info.

AWS Appflow – There may be a several connectors available in AWS Appflow. In case of “Amazon AppFlow SAP OData connector” usage there is no impact as it leverages OData API.

HVR/Fivetran - Fivetran's SAP NetWeaver connector uses RFC calls thus it is impacted. Most likely there will be a new Fivetran ODP connector released soon to be based on ODP OData API. More info.

Snowflake – depends on which tool is used to replicate the data to the snowflake.

Notice that there are many other tools used to expose SAP data that are not listed in here.

Also, the big question if this action done by SAP is legally binding its customers. Well, it is a big topic actually. What is driving it is the SAP Software Use Rights signed. There is a standard version of it (but also notice that the document is a subject to evolution and depends on the SAP version, etc.) that clearly says that asynchronous indirect access to SAP data is not licensed without SAP Digital Access, BW or OpenHub. Thus, one can believe that even SAP puts auditing/tracking mechanisms in place and they prove by that that particular customer is violating the Note 3255746 they can’t do much about it. But again, a disclaimer – this is not a legal advice at all! Always consult with your SAP account manager also reach out for professional help of e.g. companies providing SAP licenses consulting.

 

More information:

3255746 - Unpermitted usage of ODP Data Replication APIs

ODP-Based Data Extraction via OData

Guidance for Partners on certifying their data integration offerings with SAP Solutions

Simple SAP related flow in MuleSoft application – IDOC based

Similarly as in my previous post I’m sharing a little about my experience while working with MuleSoft Mule ESB platform.

In next text I depict simple flow in the mule which listens for incoming data coming into the mule’s app from an IDoc generated in SAP. Once the IDoc of certain type is created in the SAP it is displayed in the app’s console. Needless to say that the IDoc gets generated in the SAP when some business data gets modified (created/changed/deleted). There is quite extensive configuration to be done at SAP side with regards to ALE customizing in order to setup the IDoc generation. On the mule side there is just an SAP Connector configured which acts as the IDoc listener. The IDoc Basic Type needs to be specified in its Object Name field. All parameters for connection form the mule app to the SAP are taken via parameters form mule-app.properties file.

Here’s the mule app’s console output looks like:

Related post:

Simple SAP related flow in MuleSoft application – BAPI based 

Simple SAP related flow in MuleSoft application – BAPI based

Recently I worked for one integration focused assignment. We used integration platform from MuleSoft called Mule ESB (Enterprise Service Bus). The Mule ESB is a lightweight integration platform based in Java used to integrate different systems. As my background is mostly SAP and in this space the SAP has its own integration platform called SAP PI it was whole new world to me to work with the mule.

In next paragraphs I depict simple flow in the mule which calls a BAPI at the SAP side and shows the data returning by the BAPI. The application is started by triggering URL (http://localhost:8081/) on which HTTP Listener element listens. After that a call of the BAPI in the SAP is executed and returned data is written by Logger into the app’s web page where it was triggered from.

From configuration point of view there must be whole setup of ALE customizing done at the SAP side. At the mule’s side there is SAP Connector used in the flow. It is acting as trigger of the BAPI call. The BAPI name is specified in Object Name of the SAP Connector element’s properties. Along the Object Name also XML Definition (see below) needs to be provided. 

Here’s how the XML definition for BAPI looks like:

Here’s the mule app output:

Related post:
Simple SAP related flow in MuleSoft application – IDOC based

Few words on table RSPOR_T_PORTAL – Portals connected to BW

This blog is originally posted on SCN:

Few words on table RSPOR_T_PORTAL – Portals connectedto BW

This table is very important from portal access to BW system point of view. It stores the configuration information about connected portals. There may be several portals connected into one BW system. One of them must be marked as default one. There is information about logical destination of portal, its system name, prefixes of URL/Metadata Repository, etc. Table has other information when it comes to configuration of Report to report interface (RRI), Adobe Document Services (ADS), SAP Export Library, fonts and portal platform.

Customizing of the table is available via IMG path: SAP Reference IMG -> SAP NetWeaver -> SAP Business Information Warehouse -> Reporting-relevant Settings -> BEx Web -> Integration into the SAP Enterprise Portal -> Maintaining Portal-Server Settings for EP 6.0. In newer versions of BW 7.x this customizing entry is disabled and directly ABAP report RSPOR_SETUP shall be used as specified in customizing note “Settings for Integration with SAP EP 6.0” in TA SPRO.

Important Fields:

RFCDEST                    Logical Destination - RFC Destination to connect the portal from BW and vice versa. It is maintained in TA SM59. Format of the field can look like e.g.: __

SYSTEM_NAME         System Name in Portal System Landscape – Value for BW is usually „SAP_BW“

DEFAULT_PORTAL   Indicates Whether Entry Points to Standard Portal. Only one of several connected portals can be default. This is important for RRI functionality. Parameter RSPOR_DEFAULT_PORTAL needs to be added to user master record. See SAP Note 1818322 - RSPOR_T_PORTAL configuration in the context RRI

URL_PREFIX                         URL Prefix for Portal URLs – it is needed for the input help in BEx Information Broadcasting. BEx report uses URL prefix for iViews. Value usually is: http(s)://hostname:

KM_RM_PREFIX                   Prefix for BW Metadata Repository Manager (RM) – so called RM prefix for BW metadata.  It determines path in Knowledge Management (KM) used by BW metadata while accessing repository manager. Usage of the field is used e.g. when broadcasting: links to BEx objects in the portal are generated. Value usually is: /bw_metadata

CM_RM_PREF_META           Prefix for BI CM Repository for Metadata – IF documents for metadata are migrated to the portal KM (to a BI CM repository) the prefix is used. By this prefix BW checks if whether/where the documents were migrated. Value usually is: /bi_documents.

CM_RM_PREF_MAST           Prefix for BI CM Repository for Master Data – Same as above. But prefix is for master data.

CM_RM_PREF_TRAN           Prefix of BI CM Repository InfoProv. Data - Same as above. But prefix is for transactional data – data stored in InfoProviders.

SAP_EXPORT_LIB               Use SAP Export Library (PDF) – If you want to use BI Export Library for exporting of BW report’s output into the different format like PDF. In that case put X as value.

FONT_PATH                          Directory of Fonts – path to fonts if you are using BI Export Library. See field above. Also see SAP Note 1166921 - Default font not used when font path empty

ADS_HTTPS                          Use HTTPS for Adobe Document Services (PDF). In case of issues see SAP Note 1112378 - USE_HTTPS_FOR_ADS=X is not evaluated.

PORTFOLIO_PATH   Directory for "My Portfolio" - in BEx Web, value must include string "" -> see Note 1830507 - Directory of My portfolio field in rspor_t_portal table

DEFAULT_FONT        Standard Font –While using the BI Export Library this specifies default font to be used by the library.

PLATFORM              Runtime Platform – Either your portal is based on NetWeaver or BusinessObjects Enterprise. Values NW for NetWeaver or BOE for the other one.