Hello,
We try to use controlled access to S/4 HANA data using CDS views.
Some of Standard CDS Views (like I_MATERIAL oder I_BUSINESSPARTNER) use @ClientHandling.algorithm: #SESSION_VARIABLE to determine which set of data is to be returned.
We tried to set Client session variable using JDBC connection String, "jdbc:sap://ourHANAhost:31044?sessionVariable:CLIENT=200" but it didn't help.
The result to the query SELECT * FROM SAPABAP1.IMATERIAL is empty result set.
Are we doing something wrong?
Thanks in advance for any hint.
Sincerely
I. Lastric
The result to the query SELECT * FROM SAPABAP1.IMATERIAL performed on the JDBC connection is an empty result set.
Are we doing something wrong?
We also tried setting default session client on HANA user, but it didn't helped either.
Thanks in advance for any hint.
Sincerely
I. Lastric
Try with what the documentation says: CDS_CLIENT is the session context variable you need to set. See https://help.sap.com/doc/abapdocu_752_index_htm/7.52/en-US/abenamdp_client_handling.htm.
CDS_CLIENT session variable helps within AMDP but also on JDBC connection, but only if connection is done directly to S/4 HANA tenant.
We are using separate HANA tenant as our application database.
To connect our data with ERP data, we use Smart Data Access to provide S/4 ERP data as virtual table within our tenant. We off-course do not access S/4 tables but standard CDS views instead.
It looks like Smart Data Access is not propagating this session (client) information to the S/4 tenant.
We tried this: https://launchpad.support.sap.com/#/notes/2463361 but id didn't help either.
Why would SDA propagate the session variable? There's no documentation that says it would.
Anyhow, how about you explain your complete scenario instead of letting out important information (like that this is via SDA) bit by bit? What's the overall setup? Why the indirect access?
Well I suppose I deserved the rude criticism, sorry if my question was not clear enough or you felt mislead by my explanation.
We just try to use recommended method to get the data from S/4 system and believe CDS is what SAP recommends.
If the SDA gives the possibility to define this CDS view as a virtual table in another tenant (over SDA), than I expect to get the data without having to be an expert and understand the SDA in depth. If the target system needs some information (like session client) than there has to be some possibility either to propagate the information or to define it in any other way. There is also no documentation that says that CDS views that use client information do not work over SDA.
We have a java application that is used for communication with partners. It is an EAI application that is performant and stable and stands in front of currently used ERP system.
Es we are changing our ERP system to SAP S/4 HANA, we also are switching the DB system for our java application to HANA, but we want to keep the application.
It maintains it's own data and we do not want to mix this with SAP system. Also we do not want to come in conflict with SAP licenses when we write data directly into DB without going through ABAP stack. So we bought a HANA license and use separate tenant for the application.
The java application does reporting based on own data in connection with ERP data and there is the point where we use SDA to access CDS views on the S/4 HANA system - this way a simple SQL join helps to get the data together.
By the way, SAP TQM has valuated the scenario and they said it was the state of the art.
A couple of comments here:
- the documentation states what's possible - not what does not work
- if a functionality (like integrating ABAP CDS views via SDA to another HANA system) is not explicitly listed, then this functionality should not be expected.
- the SDA option has a scope that is independent of ABAP CDS views.
The option to access SQL/CDS views by SDA overlaps in this case with the ABAP CDS view functionality. That does not mean that every possible scenario, mentioned or not, has to be supported. - I really cannot comment on the TQMs ability to evaluate this approach; the TQM role is a service management role - not a database development role.
If I were in your place, I'd probably focus on how the missing CDS_CLIENT context variable could be provided.
One thing that pops into my mind would be to include it in the ODBC connection properties used by the SDA connection.
Another option could be to encapsulate the views you're interested in into TUDFs (in which you set the context) and create access views based on those TUDFs.
That's what I would be looking into if I were trying to develop this kind of integration.
Thanks for the comments.
I'd like to focus on how to provide missing CDS_CLIENT context variable, but have found nothing we could try.
The ODBC connection properties are set once for the connection between tenants and there would be a problem if we need to switch the client - which is often needed in DEV and QUA environment. But we'll look into it.
The last point - TUDF seems interesting.
I found some documentation in SQL Script reference, but found nothing about setting the context there.
Would you place TUDFs on a S/4 tenant or within the application tenant?