Hi, We have a very large SAP footprint at work and I was involved in setting up SAS connectivity at our site. Basically you have 4 to 5 options. I have used each one for both testing and production scenarios. SAS/ACCESS to R/3. It works for both ECC and SAP BW SAS ODBO Connection to InfoCubes using ODBC / Enterprise Guide Cube Interface Open Hub / Infospoke either to database or flat file Classic Badi / Remote RFC via Proc RFC SOAP Calls via Proc SOAP SAS/ACCESS to R/3 By far the simplest in terms of usability. It works like all other access engines in that it will translate SAS code to its source system language equivalent or federate where it can't. Whether it processes on the SAP or SAS side depends on your query / datastep and procs used. Generally most SAS/STAT procedures force federation. You need to install some transports on the BW side which implements a custom package called "SAS/COMMON", the SAP GUI to expose the rfc.dll file to sas, create some RFC connections and also a background user account and your generally ok. Sometimes you will need to alter your .hosts file also if you use an F5 or something similar to a clustered gateway. Data Surveyor is awesome for the most part. It is an add-in to SMC or DI. It uses the Access engine at its core and it will read BW metadata also. Using the access engine alone gives the physical db table definition. This is a problem as most SAP systems have upwards of 70k tables. Data Surveyor relies on having at least three libnames defined; 1. for SAP BW metadata (Base /v9 etc.) 2. for extracted data (Base/v9 etc.). 3. the SAP libname Metadata is a separate extract job you run when needed. It provides the C Struct view in the application. It will for example combine your BW M and P tables as required and Text and SID tables etc.The tool will translate SAP InfoCubes to a classic Kimball style star schema with; A central fact table Dimensions which combine SID,Master Data and InfoObjects. A view which is a select * of every dimension and fact. Deltas are supported from BW change logs and you can extract DSO's or InfoCubes. Masterdata will also export as part of a cube job. The big gotchas not clear in documentation are that masterdata will be extracted multiple times when extracting from multiple InfoCubes and will not be extracted for DSO's. This means you have to manually alter cube jobs in DI if you only want to extract once. E.G: Cube ZBP_C01 uses master data object 0BPARTNER and cube ZBP_C02 also uses it. The job in DI will create two jobs for extracting data from 0BPARTNER DSO ZBP_D01 uses 0COMP_CODE 01. In BW via SE16 or 11 you will see 01 being ACME.inc. In SAS it will simply be 01. I have found that is very confusing for end users as they validate data through the SAP application which provides lookups to the master data. In DI it will create a separate job for every InfoObject, Dimension, Fact, View and merge performed. The manual intervention becomes time consuming and confusing if you are extracting from a large number of cubes (I did 80 separate cubes initially and it was hell on earth). ODBO Connection Dragons reside here. Tread carefully. The engine supporting it does very weird typecasting and performance is horrible on large cubes. The main advantage is that in E-Guide you can use the awesome OLAP connection functionality. The only problem is that you will probably force your pc to page memory because it is trying to typecast SAP datatypes on the fly. Open Hub Two options here; Flat file and then read the file into SAS Open hub / bulk load a database which SAS can interface via libname. We have started using this at work for some use cases. You need open hub licensing of course. The nice thing here is that it allows very fine grained control on the SAP side. It does force replication of data though. You will force your BASIS staff to have more input with this option as DTP's have to be manually set for Delta / full loads etc. The basic process is your BW dev team create the open hub in RSA1 and then SAS picks up the output. Very simple and clean. Bapi / Remote RFC Numerous Badi's exist which allow remote communication. These can be accessed in SAS either by Proc RFC (which is part of the SAS/ACCESS to R/3 product) or x / systask command. You will end up doing A LOT of scripting to get this working. The standard Bapis require multiple calls to get cube or dso data. Generally you have separate calls for authentication, discovery, selection and then translation. The two BAPI's to look at are MDDataProviderBW and MDDataSetBW SOAP Calls If you activate ICF services in BW you can call OLAP data via Web Service. This then allows SAS to call the service via Proc SOAP. help.sas has heaps of info on the service defintions and wsdl addresses. This is basically the same as using Bapi's as it is a service wrapper over the top of the same procedures. Methods are normally all the same. Apologies for the long answer. It is pretty complex but getting BASIS on board and being able to talk SAP speak will help you greatly. Cam
... View more
