rapid direct access to transactional data in db2 for z/os

Rapid Direct Access to Transactional Data in DB2 for z/OS by SAP NetWeaver Business Warehouse

Leveraging VirtualProviders and the IBM DB2 Analytics Accelerator

Document version 1.00 – 2014-05-15


2

TABLE OF CONTENTS

INTRODUCTION ............................................................................................................................... 3 1

CONFIGURING THE SOURCE SYSTEM ......................................................................................... 4 2

IMPLEMENTING VIRTUALPROVIDERS IN SAP BW ..................................................................... 4 3 VirtualProvider Based on DTP for Direct Access ......................................................................... 6 3.1

3.1.1 Creating a Source System ................................................................................................................. 6 3.1.2 Creating a DataSource ...................................................................................................................... 6 3.1.3 Creating the Transformation .............................................................................................................. 7

VirtualProvider Based on BAPI ...................................................................................................... 9 3.23.2.1 Example ............................................................................................................................................. 9

VirtualProvider Based on Function Module ................................................................................ 11 3.33.3.1 Example ........................................................................................................................................... 12

REPORTING ON VIRTUALPROVIDERS ....................................................................................... 15 4

REFERENCES ................................................................................................................................ 16 5


3

The IBM DB2 Analytics Accelerator (DB2 Accelerator) is a workload optimized appliance add-on to DB2 for z/OS that accelerates SQL queries with unprecedented response time. The DB2 Accelerator can dramatically speed-up access to data that resides in a transactional system for reporting in SAP NetWeaver Business Warehouse (SAP BW) without extracting, transferring and loading the data to the SAP BW system. The approach shown in this documentation allows near real-time operational business intelligence and snap shot reporting with minimal impact on resource consumption in the transactional system.

INTRODUCTION 1

In order to prepare data for reporting in SAP BW, it is extracted from a source system which is usually a transactional system, often SAP ERP. Then the data is transferred to SAP BW and loaded into Data Store Objects and InfoCubes. This staging procedure is time consuming. Also, twice the storage is needed to hold two copies of the same data in the source system and SAP BW. Furthermore, near real-time reporting is not possible due to data latency caused by the staging procedure.

SAP BW VirtualProviders provide capability to access data in a source system without loading it into SAP BW. However, this feature is not utilized to an appreciable extent because it has some serious drawbacks. In particular, data representation in the source system is optimized for transactional workload and therefore is not well suited to business reporting. And, reporting queries tent to be complex and resource consuming which can lead to unpredictable workload peaks in the business critical transactional system.

The approach introduced here provides the following benefits:

Elimination of time and resource consuming extract, transfer and load procedures

Near real-time reporting

Alternatively: Snap shot reporting

Rapid access to transactional data

Minimal resource consumption in the transactional system

The concept is not restricted to SAP applications but works with any data that resides in DB2 for z/OS. The SAP BW system can run on DB2 for z/OS or any other database platform. Figure 1 shows the conceptual design.

Figure 1: Conceptual Design

Application table data is replicated to the DB2 Accelerator which is connected to the transactional source system. Utilizing DB2 Accelerator’s Incremental Update capability, data latency can be as low as 1 minute

DB2 10 DB2 Accelerator

Transactional application

Source System SAP BW

VirtualProvider

Query Acceleration

Reporting

Replication


4

which allows near real-time reporting. As an alternative, data can be loaded to the DB2 Accelerator at a selected point in time to implement reporting on a well-defined snap shot.

VirtualProviders for direct access to source system data are implemented in SAP BW. When reporting is performed on a VirtualProvider, the SAP BW data manager executes an SQL query on a secondary database connection to the source system. Attribute Query Acceleration is set for that secondary connection accordingly so that the source DB2 optimizer redirects the query to the DB2 Accelerator. The transactional application running on the source system does not set attribute Query Acceleration and thus still operates on native DB2 data. This approach guaranties transaction consistency where it is needed and accelerated data access where it is beneficial.

CONFIGURING THE SOURCE SYSTEM 2

All tables that contain data which is needed for reporting need to be added and loaded to the DB2 Accelerator. If the source system runs on SAP NetWeaver, it is highly recommended to add those tables and schedule replication within the DB2 Accelerator Control Center (transaction DB2ACCEL). SAP BW support packages and patches as documented in SAP Note 1649284 must have been applied.

If the source system does not run on SAP NetWeaver, utilize the IBM Data Studio to setup table replication to the DB2 Accelerator.

In order to ease access to relevant transaction data or for security purposes you can create a database view that filters relevant fields, define joins between multiple tables, if necessary, and implements appropriate access permission.

IMPLEMENTING VIRTUALPROVIDERS IN SAP BW 3

A VirtualProvider is an InfoCube without physical data store in SAP BW. When creating an InfoCube in SAP BW Data Warehousing Workbench the following three options for a VirtualProvider are available:

Based on Data Transfer Process for Direct Access

Based on BAPI

Based on Function Module

The appropriate type depends on the complexity of required data transformation from source system to target VirtualProvider.

A VirtualProvider based on DTP for direct access is the preferred option in most use cases. It can be implemented by means of standard SAP BW modelling. However, it supports only mapping between source table fields and InfoObjects in the VirtualProvider using standard functions. For more information about

modelling a VirtualProvider based in DTP for direct access, see section ‎3.1.

A VirtualProvider based on BAPI (Business Application Programming Interface) supports theoretically any data conversion but requires individual ABAP code programming. It allows only SAP systems as a source. A BAPI is a function module that runs on the source system and is called via remote function call (RFC). The BAPI provides the data that is requested by the OLAP processor. For more information about implementing a

VirtualProvider based on a BAPI, see section ‎3.2.

A VirtualProvider based on a function module is the most flexible option. It supports SAP and non-SAP source systems. A function module must be implemented that provides the requested data. In contrast to the BAPI, this function module runs on the SAP BW system and connects to the source system via secondary

database connection. For more information, see Section ‎3.3.


5

Figure 2: VirtualProvider Types

Table 1 is an overview of VirtualProvider types and their properties. Use the table as a reference to decide which type of VirtualProvider is most appropriate for your individual implementation.

Property of VirtualProvider

… based on DTP for Direct Access

… based on BAPI … based on Function Module

Source system type

SAP and non-SAP SAP SAP and non-SAP

Connectivity DB Connect Remote Function Call Any, usually secondary DB

connection

Transformation Standard BW transformation capability

Any transformation that can be coded in ABAP

Any transformation that can be coded in ABAP

Implementation Standard SAP BW modelling SAP BW modelling + custom ABAP code in source system

SAP BW modelling + custom ABAP code in SAP BW system

Decision criterion Use when standard transformation features are sufficient

Use when transformation must be performed in source system

Use for complex transformation

Table 1: Properties of VirtualProviders


6

VirtualProvider Based on DTP for Direct Access 3.1

To implement a VirtualProvider based on a data transfer process (DTP) for direct access to a remote DB2 Accelerator, three entities need to be modelled for the data flow: a source system, a DataSource and the transformation, see Figure 3.

Figure 3: Data Flow

The following sections provide step-by-step guidelines for creating the required objects.

3.1.1 Creating a Source System

The source system defines the connection parameters to the remote database. The source system has a logical system name assigned that maps to a secondary DB connection in table DBCON. In order to allow access to a DB2 Accelerator that is connected to the remote DB2 database, parameter QUERY_ACCELERATION must be specified in the connection info string. To do so, proceed as follows:

1. Click Modeling → Source Systems in the navigation pane of the Data Warehousing Workbench. 2. Right click on DB Connect and select Create from the context menu.

3. Enter a Logical System Name (e.g. TRANSACT) and a Source System Name.

4. Leave Type and Release blank and click Continue (Enter).

5. SAP BW 7.40 and higher: For Connection Type select Source System = DB Connection and

click icon Change to edit the DB connection.

6. Enter DB2 for DBMS, User Name (e.g. R3USER) and DB Password.

7. Specify Conn. info to the remote DB2 database as follows: QUERY_ACCELERATION=ENABLE;

SSID=<DB2 subsystem id>;

LOCATION=<DDF location>;

SAPDBHOST=<db host>;

PORT=<port>;

PS=<plan name, (e.g SAP1001U)>;

SCHEMA=<Schema name (e.g. SAPR3)>

8. Check option Permanent and click Save (Ctrl+S). 9. SAP BW 7.40 and higher: Click the icon Back (F3) (green arrow) twice and click the icon Apply (F8).

3.1.2 Creating a DataSource

To create a DataSource that allows direct access to the source system, proceed as follows:

1. Click Modeling → DataSources in the navigation pane of the Data Warehousing Workbench. 2. Right click on an appropriate application component and select Create DataSource from the context

menu. Alternatively: Click the toolbar icon DataSource (CTRL+F8) and the click icon Create Datasource (F5).

3. Enter the DataSource name (e.g. DS_TRANSACT) and the Source system (e.g. TRANSACT).

4. Specify DataSource Data Type Transaction Data and click Transfer (Enter).

5. On the tab General Info enter a description.

6. On the tab Extraction set Direct Access to Allowed.

Select Adapter Database Table and specify Table/View of the source system.

7. On the tab Proposal, check Copy to Field List for all fields that are accessed by the VirtualProvider. 8. On the tab Fields, verify that the field list has been compiled correctly.

Remote DB2 DataSource Source System Transformation VirtualProvider

SAP BW


7

9. Click Activate (Ctrl+F3) to activate the DataSource. 10. On the tab Preview verify that the data can be read from the remote transaction system.

3.1.3 Creating the Transformation

Finally the transformation must be modelled that maps the DataSource fields (i.e. fields of the source system table) to characteristics and keyfigures of the VirtualProvider. To do so, proceed as follows:

1. Click Modeling → InfoProviders in the navigation pane of the Data Warehousing Workbench. 2. Right-click on the VirtualProvider and select Create Transformation from the context menu.

3. Specify Object Type DataSource, DataSource (e.g. DS_TRANSACT) and Source System (e.g.

TRANSACT). Click Create Transformation (Enter).

4. Define the transformation. The network display shows the fields of the source table on the left and the InfoObjects of the VirtualProvider on the right. The transformation assigns a rule to every InfoObject. A rule associates zero, one or many source fields with a target InfoObject, see Figure 4. Rules are defined by dragging lines from the source fields to the target InfoObject. Double-click on the InfoObject to specify the rule details. A rule can have various types, for instance constant, direct assignment, formula, ABAP report, etc, see Figure 5.

5. When the transformation has been defined completely, click Activate (CTRL + F3).

Figure 4: Transformation


8

Figure 5: Rule Details


9

VirtualProvider Based on BAPI 3.2

A VirtualProvider based on BAPI does not perform a standard transformation. Instead, BAPI function module BAPI_INFOCUBE_READ_REMOTE_DATA is executed in the remote source system via Remote Function Call

(RFC).

Creation and modelling of a VirtualProvider based on BAPI is the same as with a regular InfoCube. However, on the InfoCube type panel, you need to select VirtualProvider → Based on BAPI and enter a logical system

name (e.g. SIDCLNT001) for the input field With Source System. A RFC destination of type 3 (ABAP

connection) must exist or be created for the logical system name (transaction SM59) and it must be maintained in tables TBDLS and TBDLST using transaction BD54.

Function module BAPI_INFOCUBE_READ_REMOTE_DATA gets a list of required output fields and the

restrictions as input parameters and returns the data as output parameter in an internal table.

This function module always exists in the source system but its body is empty initially. The function module must evaluate the restrictions and return the requested data in the correct format. Class

CL_RSDRV_REMOTE_IPROV_SRV provides services that help to implement such functionality.

Special register CURRENT QUERY ACCELERATION must be set within the function module before data is

accessed. This can either be done by means of ADBC or EXEC SQL, for example such as:

EXEC SQL.

SET CURRENT QUERY ACCELERATION = ENABLE

ENDEXEC.

Alternatively method CL_RSDB2A=>SET_QUERY_ACCELERATION( ) can be called.

Possible values for the special register are

ENABLE Query runs on DB2 Accelerator if beneficial according to cost considerations

ENABLE WITH FAILBACK same as ENABLE, but in case of an error the query runs on DB2 natively

ELIGIBLE Query runs on DB2 Accelerator, if possible

It is not recommended to use value ALL, because the SAP work process will fail if any SQL SELECT is

executed on a table that has not been replicated to the DB2 Accelerator.

It must be ensured that special register CURRENT QUERY ACCELERATION is unset before function module

BAPI_INFOCUBE_READ_REMOTE_DATA finishes or terminates due to an error. Otherwise, the work process

continues running with CURRENT QUERY ACCELERATION set and might execute a workload that does not

suit the DB2 Accelerator, for example because it does not tolerate data latency. Unsetting the special register can be done via ADBC or EXEC SQL, for example:

EXEC SQL

SET CURRENT QUERY ACCELERATION = NONE

ENDEXEC.

Or by calling method CL_RSDB2A=>SET_QUERY_ACCELERATION( 'NONE' ).

3.2.1 Example

The following code snippet is a simple implementation of function module

BAPI_INFOCUBE_READ_REMOTE_DATA that reads table GLFUNCA.

function bapi_infocube_read_remote_data.

*"----------------------------------------------------------------------

*"*"Local Interface:

*" IMPORTING

*" VALUE(INFOCUBE) LIKE BAPI6200-INFOCUBE

*" VALUE(KEYDATE) LIKE BAPI6200-KEYDATE OPTIONAL

*" EXPORTING

*" VALUE(RETURN) LIKE BAPIRET2 STRUCTURE BAPIRET2

*" TABLES


10

*" SELECTION STRUCTURE BAPI6200SL

*" CHARACTERISTICS STRUCTURE BAPI6200FD

*" KEYFIGURES STRUCTURE BAPI6200FD

*" DATA STRUCTURE BAPI6100DA

*"----------------------------------------------------------------------

data:

l_r_service type ref to cl_rsdrv_remote_iprov_srv,

l_s_iobj_fld_map type cl_rsdrv_remote_iprov_srv=>tn_s_iobj_fld_mapping,

l_t_iobj_fld_map type cl_rsdrv_remote_iprov_srv=>tn_th_iobj_fld_mapping,

l_t_iobj type standard table of rsiobjnm,

l_t_fld type standard table of rsalias.

" build mapping table

split

'0CALYEAR|0DOC_NUMBER|0COMP_CODE|0ACCOUNT|0CURKEY_TC|0CURKEY_LC|'

&'0CURKEY_GC|0CS_TRN_TC|0CS_TRN_LC|0CS_TRN_GC' at '|' into table l_t_iobj.

split

'RYEAR |DOCNR |RBUKRS |RACCT |RTCUR |RTCUR |'

&'RTCUR |TSL |HSL |KSL' at '|' into table l_t_fld.

loop at l_t_iobj into l_s_iobj_fld_map-iobjnm.

read table l_t_fld into l_s_iobj_fld_map-fldnm index sy-tabix.

insert l_s_iobj_fld_map into table l_t_iobj_fld_map.

endloop.

" set special register CURRENT QUERY ACCELERATION

cl_rsdb2a=>set_query_acceleration( ).

" create service class instance

create object l_r_service

exporting

i_th_iobj_fld_mapping = l_t_iobj_fld_map

i_tablnm = 'GLFUNCA'.

" open cursor

l_r_service->open_cursor(

i_t_characteristics = characteristics[]

i_t_keyfigures = keyfigures[]

i_t_selection = selection[] ).

" fetch data

l_r_service->fetch_pack_data(

importing

e_t_data = data[] ).

" unset special register CURRENT QUERY ACCELERATION

cl_rsdb2a=>set_query_acceleration( 'NONE' ).

return-type = 'S'. " msg type "success"

endfunction.


11

VirtualProvider Based on Function Module 3.3

A VirtualProvider based on function module provides the highest level of flexibility for data access and transformation. This flexibility comes with the price of higher implementation effort. Utilize VirtualProviders based on function module if a functionality is required that is not supported by standard transformation rules, for example if the transformation is to a high extent generic.

Creation and modelling of a VirtualProvider based on function is the same as with a regular InfoCube. However, on the InfoCube type panel, you need to select VirtualProvider → Based on Function Module and click the button Details to specify properties of the VirtualProvider, see Figure 6. The SAP Help Portal

provides a description of the individual properties, see section ‎4 for a link. As a minimum, you must specify a

function module name.

Figure 6: Properties of a VirtualProvider Based on Function Module

The function module for the VirtualProvider must comply with an interface specification that depends on the specified properties. For example, if Pack RFC and SID Support are both switched off, the function module

must have the same interface as template function module RSDRI_VPROV_READ_TEMPLATE. (It might be a

good idea to start the implementation of a new function module on a copy of the template.)


12

The function module gets the result set layout and the restrictions as defined by the query as input parameter and returns the result in an internal table. If used with the DB2 Accelerator, the function module must retrieve

the data from a remote DB2 for z/OS database. It also must set the special register CURRENT QUERY

ACCELERATION, unless it utilizes a secondary database connection that has QUERY_ACCELERATION

defined in the connection string. For an implementation example, see Section ‎3.3.1.

3.3.1 Example

The following code example is a function module for a VirtualProvider that has the time-characteristic

0CALDAY, characteristic ZTABNAME and keyfigure ZVALUE. The implementation is generic since the source

table name is not static but specified by the query as single value restriction on characteristic ZTABNAME.

The source table’s first field of data type DATS is mapped to time-characteristic 0CALDAY. The source

table’s first field of data type DECIMAL is mapped to keyfigure ZVALUE.

function zdemo_sum_values.

*"----------------------------------------------------------------------

*"*"Local Interface:

*" IMPORTING

*" REFERENCE(I_INFOPROV) TYPE RSINFOPROV

*" REFERENCE(I_TH_SFC) TYPE RSDRI_TH_SFC

*" REFERENCE(I_TH_SFK) TYPE RSDRI_TH_SFK

*" REFERENCE(I_T_RANGE) TYPE RSDRI_T_RANGE OPTIONAL

*" REFERENCE(I_TX_RANGETAB) TYPE RSDRI_TX_RANGETAB OPTIONAL

*" REFERENCE(I_FIRST_CALL) TYPE RS_BOOL OPTIONAL

*" REFERENCE(I_PACKAGESIZE) TYPE I DEFAULT 100000

*" REFERENCE(I_KEYDATE) TYPE RRSRDATE DEFAULT SY-DATUM

*" REFERENCE(I_MAXROWS) TYPE I OPTIONAL

*" REFERENCE(I_USE_AGGREGATION) TYPE RS_BOOL DEFAULT RS_C_TRUE

*" REFERENCE(I_SHOW_STATEMENT) TYPE RS_BOOL DEFAULT RS_C_FALSE

*" EXPORTING

*" REFERENCE(E_T_DATA) TYPE STANDARD TABLE

*" REFERENCE(E_END_OF_DATA) TYPE RS_BOOL

*" REFERENCE(E_T_MSG) TYPE RS_T_MSG

*" EXCEPTIONS

*" REMOTE_READ_FAILED

*" X_MESSAGE

*"----------------------------------------------------------------------

* Function module for a VirtualProvider

* - Derives table name from first single value restriction on char ZTABNAME

* - Returns first DATS field of that table as characteristic 0CALDAY

* - Sums up first DECIMAL field of that table as keyfigure ZVALUE

" Connection to remote system defined in table DBCON

constants:

lc_dbcon_name type dbcon_name value 'TRANSACT'.

data:

l_tabname type tabname,

l_t_tabname type standard table of tabname,

l_tabname_alias type rsalias,

l_s_iobj_fld_map type cl_rsdrv_external_iprov_srv=>tn_s_iobj_fld_mapping,

l_t_iobj_fld_map type cl_rsdrv_external_iprov_srv=>tn_th_iobj_fld_mapping,

l_t_fld type standard table of fieldname,

l_db_fld type fieldname,

l_datatype type dd03l-datatype,

l_r_service type ref to cl_rsdrv_external_iprov_srv,


13

l_s_sfc type rsdri_s_sfc,

l_s_range type rsdri_s_range,

l_t_range type rsdri_t_range,

l_t_orderby type rsdr0_t_abapsource,

l_t_groupby type rsdr0_t_abapsource,

l_t_sel_list type rsdr0_t_abapsource,

l_t_where type rsdr0_t_abapsource,

l_cursor type cursor value is initial,

l_r_connection type ref to cl_sql_connection,

l_r_statement type ref to cl_sql_statement.

field-symbols:

<l_tabname> type tabname,

<l_s_data> type any.

" Function module must be called only once per query

e_end_of_data = rs_c_true.

" Get field alias for ZTABNAME

read table i_th_sfc with key chanm = 'ZTABNAME' into l_s_sfc.

if sy-subrc = 0.

l_tabname_alias = l_s_sfc-chaalias.

endif.

" Determine table names

append lines of i_t_range to l_t_range.

loop at l_t_range into l_s_range where chanm eq 'ZTABNAME'.

if l_s_range-compop = 'EQ'.

append l_s_range-low to l_t_tabname.

endif.

delete table l_t_range from l_s_range.

endloop.

check not l_t_tabname is initial.

read table l_t_tabname into l_tabname index 1.

" Build field mapping table

do 2 times.

case sy-index.

when 1.

" map first DATS field in table to InfoObject 0CALDAY

l_datatype = 'DATS'.

l_s_iobj_fld_map-iobjnm = '0CALDAY'.

when 2.

" map first DECIMAL field in table to InfoObject ZVALUE

l_datatype = 'DEC'.

l_s_iobj_fld_map-iobjnm = 'ZVALUE'.

when others.

exit.

endcase.

select fieldname

into table l_t_fld

from dd03l connection (lc_dbcon_name)

where tabname = l_tabname and datatype = l_datatype

order by position.

check sy-subrc = 0.

read table l_t_fld into l_db_fld index 1.

l_s_iobj_fld_map-fldnm = l_db_fld.

insert l_s_iobj_fld_map into table l_t_iobj_fld_map.

enddo.


14

" Create instance of service class

create object l_r_service

exporting

i_th_iobj_fld_mapping = l_t_iobj_fld_map

i_tablnm = l_tabname.

" Get field lists for select, group by and order by clauses

l_r_service->build_select_list(

exporting

i_th_sfc = i_th_sfc

i_th_sfk = i_th_sfk

i_use_aggregation = i_use_aggregation

importing

e_t_sel_list = l_t_sel_list

e_t_groupby = l_t_groupby

e_t_orderby = l_t_orderby ).

" Compile where condition

l_r_service->build_where_conditions(

exporting

i_t_range = l_t_range

importing

e_t_where = l_t_where ).

try.

" Set special register CURRENT QUERY ACCELERATION

" It is not necessary to set the special register explicitly

" if setting is defined in DBCON connection string

l_r_connection = cl_sql_connection=>get_connection(

con_name = lc_dbcon_name

sharable = 'X' ). " ADBC connection must be shared with OpenSQL

create object l_r_statement

exporting

con_ref = l_r_connection.

" Set special register CURRENT QUERY ACCELERATION to ENABLE

" Alternatively, values ENABLE or ENABLE WITH FAILBACK might be used

call method l_r_statement->execute_ddl

exporting

statement = 'SET CURRENT QUERY ACCELERATION = ELIGIBLE'.

" Error handling

catch cx_sql_exception.

raise remote_read_failed.

endtry.

" WITH HOLD cursor not allowed with remote connection,

" therefore everything must be read at once

" (parameter i_packagesize is ignorred)

" OPEN CURSOR

open cursor l_cursor for

select (l_t_sel_list)

from (l_tabname) connection (lc_dbcon_name)

where (l_t_where)

group by (l_t_groupby)

order by (l_t_orderby).


15

" FETCH

fetch next cursor l_cursor

into corresponding fields of table e_t_data.

" CLOSE CURSOR

close cursor l_cursor.

" Correct field ZTABNAME

if not l_tabname_alias is initial.

loop at e_t_data assigning <l_s_data>.

assign component l_tabname_alias of structure <l_s_data> to <l_tabname>.

<l_tabname> = l_tabname.

endloop.

endif.

endfunction.

REPORTING ON VIRTUALPROVIDERS 4

Reporting on a VirtualProvider does not differ from reporting on a regular InfoCube. Special register

CURRENT QUERY ACCELERATION is set transparently within the data retrieval functionality of the

VirtualProvider. Therefore standard SAP BW reports can access the DB2 Accelerator without any report specific setting for query acceleration.

When reporting is performed on a VirtualProvider, corresponding master data must be available. For simple modelling and best reporting performance, master data should be extracted and loaded to the SAP BW system. However, sometimes it is requested to read the master data directly from the source system. In this case, the underlying characteristic InfoObject must be implemented as an InfoProvider or an own

implementation of interface IF_RSMD_RS_ACCESS must be created. Utilize similar techniques as with

VirtualProvider based on DTP for direct access and VirtualProvider based on function module respectively to exploit the DB2 Accelerator for fast master data access.


16

REFERENCES 5

SAP Note 1649284: SAP support for IBM DB2 Analytics Accelerator https://service.sap.com/sap/support/notes/0001649284?nlang=E

SAP Note 1755992: DB2 z/OS: lib_dbsl support for IDAA query https://service.sap.com/sap/support/notes/0001755992?nlang=E

SAP Note 1801132: DB2-z/OS: DB2 Accelerator support, latest FixPack https://service.sap.com/sap/support/notes/0001801132?nlang=E

SAP Note 1861115: IBM DB2 Analytics Accelerator support with SAP BW https://service.sap.com/sap/support/notes/0001861115?nlang=E

SAP Help Portal: Creating VirtualProviders with Function Modules https://help.sap.com/saphelp_nw73/helpdata/en/4a/40c49f97ea1d0fe10000000a42189c/frameset.htm

SAP Help Portal: Master Data Access http://help.sap.com/saphelp_nw73/helpdata/en/4a/40815bacb51cece10000000a42189b/frameset.htm

https://service.sap.com/sap/support/notes/0001649284?nlang=E




https://help.sap.com/saphelp_nw73/helpdata/en/4a/40c49f97ea1d0fe10000000a42189c/frameset.htm

https://help.sap.com/saphelp_nw73/helpdata/en/4a/40c49f97ea1d0fe10000000a42189c/frameset.htm

http://help.sap.com/saphelp_nw73/helpdata/en/4a/40815bacb51cece10000000a42189b/frameset.htm

http://help.sap.com/saphelp_nw73/helpdata/en/4a/40815bacb51cece10000000a42189b/frameset.htm

© 2014 SAP AG. All rights reserved.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP

BusinessObjects Explorer, StreamWork, SAP HANA, and other SAP

products and services mentioned herein as well as their respective

logos are trademarks or registered trademarks of SAP AG in Germany

and other countries.

Business Objects and the Business Objects logo, BusinessObjects,

Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and

other Business Objects products and services mentioned herein as

well as their respective logos are trademarks or registered trademarks

of Business Objects Software Ltd. Business Objects is an SAP

company.

Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL

Anywhere, and other Sybase products and services mentioned herein

as well as their respective logos are trademarks or registered

trademarks of Sybase Inc. Sybase is an SAP company.

Crossgate, m@gic EDDY, B2B 360°, and B2B 360° Services are

registered trademarks of Crossgate AG in Germany and other

countries. Crossgate is an SAP company.

All other product and service names mentioned are the trademarks of

their respective companies. Data contained in this document serves

informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials

are provided by SAP AG and its affiliated companies ("SAP Group")

for informational purposes only, without representation or warranty of

any kind, and SAP Group shall not be liable for errors or omissions

with respect to the materials. The only warranties for SAP Group

products and services are those that are set forth in the express

warranty statements accompanying such products and services, if

any. Nothing herein should be construed as constituting an additional

warranty.

www.sap.com

rapid direct access to transactional data in db2 for z/os

Documents