For just over a month the SAP community has fiercely been debating the UK court ruling on SAP indirect access licensing. Diageo, the world’s largest distiller, lost a case against SAP that resulted in a hefty claim for license fees and backdated maintenance charges which included accumulated interest being awarded to the software giant.

SAP customers that have interfaced, or wish to interface their SAP ERP with third party applications (this means 99.9% of SAP clients) are now potentially exposed to similar license compliance risks. One example of interaction from third party systems is a call for data directly from SAP ERP to non-SAP databases and analytics and BI tools for reporting purposes. These data extractions are logged by ERP, which later, during an audit procedure, can be constituted as Indirect Access usage leading to unforeseen costs.

The questions every prudent SAP technology related IT manager should be asking now: “Is my organisation at risk of unlicensed Indirect Access? What is my responsibility, obligation to ensure compliance? What is the best way to protect our business operations?”

So how can organizations potentially mitigate the risk of Indirect Access usage?

1. Companies could start with an internal audit to qualify and quantify the level of Indirect Access, review their existing SAP licence agreement terms and put together a negotiating strategy for meeting additional SAP licensing requirements. There are 3rd party SAP license auditor technologies and services available on the internet to help out – or if confident enough, query your SAP account executive directly (It would be no surprise if the resolution is to buy additional licenses, that is sales). Nevertheless, the audit procedure is likely unavoidable, it will be time consuming and could potentially inhibit your business operations by restricting or capping the number of SAP users.

2, Remove and replace SAP from your landscape. ERPs are in most cases considered as your IT backbone – this will hurt. Not a solution in the short-term.

3, Change the way you interact with SAP ERP and the way you use SAP data with 3rd party (BI/analytics) tools. Also not a short-term solution and likely to cause some user unrest!

VirtDB can help you with the third option. To find out where you may have to change the SAP data utilization to become compliant, let’s look into the justification clauses of the UK court’s ruling in favour of SAP against Diageo:

77. It is common ground that the test is whether the Connect customers “use” or “access” the mySAP ERP software “directly” or “indirectly”. The Agreement does not contain a definition of these terms. The plain and obvious meaning of “use” in the context of the Agreement is application or manipulation of the mySAP ERP software. The plain and obvious meaning of “access” in the context of the Agreement is acquiring visibility of, or connection to, the mySAP ERP software.

Another interesting part:

79. In my judgment, the interactions identified above between the Connect customer and mySAP ERP constitute use of, or access to, the mySAP ERP software. As set out in Issue (ii) above, the login process triggers a connection with mySAP ERP via SAP PI. Each stage of the order process requires the customer to initiate the transmission of a message from Connect to mySAP ERP and a corresponding response to be received from mySAP ERP. A customer’s order can’t be completed in Connect; submission of the order initiates transmission of the same to mySAP ERP where the final processing and completion is carried out. At each stage of the order process, the customer is accessing or using mySAP ERP indirectly through SAP PI. The example in the Named User definition in clause 1.1 of the Agreement includes use or access “via … a … third party … system”. This would include use or access via SAP PI (a software engine and adaptors that could be provided by SAP or another provider).

It seems to conclude that the most risky part concerning indirect access is direct interaction with SAP functionalities, in either read or write manner. This is what most of the SAP data access middlewares and ETL tools do, log into SAP with a technical user, invoke SAP capabilities (eg. request data through RFC-s) and query data to be passed to 3rd party BI or analytics tools.

What organizations need in order to breakdown these obstacles is avoid pulling the data out. Rather, implement a push solution for licensed SAP users, working from within SAP ERP itself.

Here at VirtDB we believe we have that solution.

SAP data access architecture

VirtDB’s Data Unfolder is an ABAP add-on solution that sits within your SAP ERP and pushes the requested data to target BI tools and databases. The following high level description will provide insight how the Data Unfolder does this:


  1. Only authorized, licensed SAP users can invoke VirtDB (required to interface through SAP) capabilities. VirtDB has a unique end-user interface embedded into SAP GUI. If you are able to login to SAP (you are licensed SAP user) you can use the VirtDB Data Unfolder.
  2. The SAP user, who is authorized to use VirtDB and has access granted to a particular data set (a standard or custom report, view, query, table, etc) should define what destination and format they want VirtDB to push the data.
  3. based on the user’s selection, an SAP Application Server process will send the data out to an external system (to Tableau, Spotfire, Excel, MS SQL, Oracle, Hadoop, Azure, Amazon, etc.)

The above process is executed immediately (on-demand use-case) or can be scheduled as an SAP batch job to be executed regularly.

Licensing agreements, country jurisdictions differ and need to be taken into consideration – but VirtDB can considerably mitigate the SAP indirect access licensing risks in most cases.