Please give me some cons (and pros if you have them) to allowing ODBC access to SAP tables. I can think of a few but want some advice from you Basis gurus.
I'm the SAP development lead at my company where I've been for the last 2 years. This company has had SAP for 5-6 years but is relatively inexperienced at doing things the 'SAP way', simply because the IT department is comprised of bright individuals who get by without consultants for the most part.
We have been using the .Net connector and RFC
calls to hit SAP for information for web apps, but now, our main IT analyst
and our Basis admin have set up ODBC access to our R/3 and CRM environments.
At first, I thought it was just for playing around and some limited reading
of tables. Now they're talking about updating Z-tables, and I wonder how
long it will be before they want to update SAP tables. Please give me some
concrete cons so I can discuss them with my boss.
=== I am totally against using any third party program to access the Database directly. They should use mechanism that used RFC on SAP.
If they want to upload stuff, they can simply
create flat files and have an ABAP program that will fetch this info.
Avoid direct access to DB at all costs.
=== I agree. That's why I want to discuss it with my boss. I guess my question is what's the best way to approach it? Encapsulation, security, lack of audit trail, possible performance implications of queries created by less SAP experienced web developers who don't have access to ST05/SE30 and to SE11 to create/analyze indexes, etc?
Will any of the Basis admin transactions inside
of SAP show stats or track the ODBC activity?
=== Yes, through ST04...
Anyway, try to force them to use RFC, IDocs etc,
or any SAP method instead of direct DB updates.
=== Well, since everybody is vehemently anti external
database read with anything other than SAP products, this might make me
unpopular. Aw, heck, when did I ever care about that?
When you install SAPGui, and you install everything
you can, you get a R3 Add-on entry under your Windows Group for SAP Front
End. This R3 Add-on consists of ECCS and FILC Data Entry code examples
that allows access tables in the SAP database from your workstation without
going through SAP. I think they are written in VB. Not sure what the do,
but SAP seems to accept the concept since they give you examples on how
to do it.
That being said, I don't believe in giving update
access to anything outside of SAP. I don't have a problem with read-only
access on a controlled basis but it must be monitoring and logged to trace
files in order to monitor what is being accessed. This access should be
forced to use views or a limited copy of the database so that HR and mission-critical
data can not be read outside of SAP. More work for IT but it can be done
and done successfully if carefully planned.
=== Oss note 581312 says that direct ODBC access
to Oracle(even for selects) is a violation of the license in most circumstances.
=== Lot has been said about direct access to SAP
database is good/bad/ugly. Main reason why you don't want to allow direct
access to SAP database and by pass SAP completley is that on top of DB
Data Dictionary there is SAP Data Dictionary. If you by pass SAP then your
will by pass SAP DD when you post any updates. Thus you would end up with
inconsistencies. Also, when you by pass SAP, you are by passing SAP autorizations
also so in affect you are violating all yours established
security rules.
This is what you can tell who is asking for ODBC access and I am sure after hearing this, they will back off.
Back to Basis Menu:
SAP BC (Basis Components) Hints
and Tips
Return to :-
SAP ABAP/4 Programming, Basis
Administration, Configuration Hints and Tips
(c) www.sap-basis-abap.com All material on this site is
Copyright.
Every effort is made to ensure the content integrity.
Information used on this site is at your own risk.
All product names are trademarks of their respective
companies. The site www.sap-basis-abap.com is in no way affiliated
with SAP AG.
Any unauthorised copying or mirroring is prohibited.