Third-Party Tools As Destinations for OHD

http://help.sap.com/saphelp_nw70/helpdata/en/43/7a69d9f3897103e10000000a1553f7/content.htm

Use
You can use the open hub destination to extract data to non-SAP systems. Various APIs allow
you to connect a third-party tool to the BI system and to use this third-party tool to distribute data
to other non-SAP systems.

Features
First you extract the data from BI InfoProviders or DataSources into a database table in the BI
system. The third-party tool receives a message when the extraction process is complete. You can
define parameters for the third-party tool. You can also use the monitor to oversee the process.
You can connect one or more data transfer processes to an open hub destination of type ThirdParty Tool.
You can use a process chain to start the extraction process not only in the BI system itself, but
also using the third-party tool.
The following APIs are available:

RSB_API_OHS_DEST_SETPARAMS: You use this API to transfer the parameters of the thirdparty tool that are required for the extraction to the BI system. These parameters are saved in a
parameter table within the BI system in the metadata for the open hub destination.
RSB_API_OHS_3RDPARTY_NOTIFY: This API sends a message to the third-party tool after
extraction. It transfers the open hub destination, the request ID, the name of the database table,
the number of extracted data records and the time stamp. In addition, you can add another
parameter table that contains the parameters that are only relevant for the third-party tool.
RSB_API_OHS_REQUEST_SETSTATUS: This API sets the status of extraction to the thirdparty tool in the monitor. Red means that the existing table is not overwritten. If the status is
green, the request is processed further. Normally the user can change the status manually in the
monitor or in the maintenance screen for the data transfer process. However, these manual
functions are deactivated with open hub destinations of type Third-Party Tool.
RSB_API_OHS_DEST_GETLIST: This API delivers a list of all open hub destinations.
RSB_API_OHS_DEST_GETDETAIL: This API gets the details of an open hub destination.
RSB_API_OHS_DEST_READ_DATA: This API reads data from the database table in the BI
system.

For information on the parameters of the APIs, see:

API: RSB_API_OHS_DEST_SETPARAMS
API: RSB_API_OHS_3RDPARTY_NOTIFY
API: RSB_API_OHS_REQUEST_SETSTATUS
API: RSB_API_OHS_DEST_GETLIST
API: RSB_API_OHS_DEST_GETDETAIL
API: RSB_API_OHS_DEST_READ_DATA
Process Flow:

Extraction to the third-party tool can be executed as follows:

...
1. You define an open hub destination with Third-Party Tool as the destination type.
2. You create an RFC destination for your third-party tool and enter it in the definition of the open hub
destination.
3. You use API RSB_API_OHS_DEST_SETPARAMS to define the parameters for the third-party tool
that are required for the extraction.
4. You either start extraction immediately or include it in a process chain. You can also start this process
chain from the third-party tool using process chain API RSPC_API_CHAIN_START. The extraction
process then writes the data to a database table in the BI system.
5. When the extraction process is finished, the system sends a notification to the third-party tool using
API RSB_API_OHS_3RDPARTY_NOTIFY.
6. The extracted data is read by API RSB_API_OHS_DEST_READ_DATA.
7. The status of the extraction is transferred to the monitor by API
RSB_API_OHS_REQUEST_SETSTATUS.

See also:
For detailed information about certification and the scenario, see the SDN at www.sdn.sap.com
Partners and ISVs SAP Integration and Certification Center Integration Scenarios
Business Intelligence Interface: BW-OHS.

Using SQL Server 2008 Integration Services with SAP BI 7.0

http://msdn.microsoft.com/en-us/library/dd299430.aspx

SQL Server 2008

SQL Server Technical Article

Writer: Chunhui Zhu
Technical Reviewer: Hermann Dubler
Published: December 2008
Applies to: SQL Server 2008
Summary: This white paper demonstrates the use of the Microsoft Connector 1.0
for SAP BI in Microsoft SQL Server 2008 Integration Services packages. It shows how
to load data into SAP BI by using the SAP BI destination, how to extract data from
SAP BI by using the SAP BI source, and how to prepare extracted data for analysis in
SQL Server Analysis Services.
Microsoft Connector 1.0 for SAP BI is delivered in the Microsoft SQL Server 2008
Feature Pack. It enables data extraction from and to SAP NetWeaver BI in both Full
and Delta modes via standard interfaces, within the Microsoft SQL Server
Integration Services environment. The SAP datasets supported by the connector
include SAP BI InfoProviders like InfoCubes, Data Store Objects (DSO), and
InfoObjects.
The Microsoft Connector 1.0 for SAP BI has three main components:

SAP BI Source, to extract data from SAP BI

SAP BI Destination, to load data into SAP BI

SAP BI Connection Manager, to manage the RFC connection between the

Integration Services package and SAP BI

Microsoft Connector 1.0 for SAP BI is an add-in for SQL Server Integration Services.
It provides an efficient and streamlined solution for integrating non-SAP data

sources with SAP BI. It also enables the construction of data warehouse solutions for
SAP data in SQL Server 2008, where SAP BI is exposed as a data source of SQL
Server.
Microsoft Connector 1.0 for SAP BI has the following requirements:

Windows Server 2003 and later, Windows Vista, or Microsoft Windows XP

Professional with Service Pack 2.

SQL Server 2008 Integration Services. Microsoft Connector 1.0 for SAP BI
needs to be installed on the same computer where Integration Services is
installed.

Windows Installer 4.5 and later.

Extracting data using Microsoft Connector 1.0 for SAP BI from SAP BI system
requires the SAP Open Hub license. For more information about SAP licensing,
consult your SAP representative.

On the SAP BI system, SAP_BW component support package level 16 (as part
of SAP NetWeaver Support Pack Stack 14) is required. SAP_BW component
support package level 17 or higher is strongly recommended.

To use Microsoft Connector 1.0 for SAP BI in 32-bit (64-bit) mode on any 32bit (64-bit) operating system, The 32-bit (64-bit) version of librfc32.dll needs
to copied to the following location: %windir%\system32.

To use Microsoft Connector 1.0 for SAP BI in 32-bit mode on a 64-bit operating
system, the 32-bit librfc32.dll needs to be copied to the following location:
%windir%\SysWow64.

Notes

Microsoft Connector 1.0 for SAP BI can only be used with SQL Server 2008
Integration Services. However, you can load data from or extract data to SQL
Server 2008, SQL Server 2005, or SQL Server 2000 databases.

Librfc32.dll is a component owned by SAP. Microsoft does not support this

SAP component and assumes no liability for its use.

Microsoft Connector 1.0 for SAP BI does not support SAP BW 3.5 and earlier
versions.

Extracting data from an SAP BI system by using Microsoft Connector 1.0 for
SAP BI only supports Open Hub Destinations. It does not support InfoSpokes,
because InfoSpokes are obsolete in SAP NetWeaver BI.

With Microsoft Connector 1.0 for SAP BI, it is now possible use components of the
SQL Server platform to move data in and out of SAP BI.

Figure 1: Overview of the solution architecture

This scenario uses an Integration Services package that leverages the SAP BI
Source component. It treats SAP BI as a data source for a SQL Server database.
Behind the scenes, SAPs Open Hub Services interface is used to fetch data from
SAP BI InfoProviders.
To configure SAP BI to extract data into a non-SAP destination such as SQL Server,
you need to follow these steps:
1. Set up the RFC Destination.
2. Configure and create the Open Hub Destination.
3. Create the Data Transfer Process (DTP) and transformation.
4. Define parallel processing.
5. Define the size of the data package.
6. Configure the process chain.
In transaction code SM59 on SAP BI, create a new HTTP connection with type T
(TCP/IP Connection), as shown in Figure 2. Under Activation Type, select Registered
Server Program. Then, fill in an appropriate Program ID, which can be any
descriptive short text. The RFC Destination and Program ID will be used later to set
up the connection manager in Integration Services.

Figure 2: Configuring the RFC Destination in SAP BI

There are two Open Hub implementation options in SAP BI: the legacy InfoSpoke,
and the new Open Hub Destination via Data Transfer Process (DTP). The InfoSpoke is
marked as obsolete in SAP NetWeaver BI. Therefore the Microsoft Connector 1.0 for
SAP BI officially supports only the Open Hub Destination.
In Admin Workbench on SAP BI (transaction code RSA1), create a new Open Hub
Destination with Destination Type Third-Party Tool, and specify the previously
created RFC Destination name (Figure 3). Save and activate the new destination.

Figure 3: Creating the Open Hub Destination in SAP BI

Create a Data Transfer Process under the Open Hub Destination. Specify Full or
Delta for Extraction Mode. Activate the DTP. Check and activate the Transformation.

Figure 4: Creating the Data Transfer Process in SAP BI

By default, SAP BI sets the number of parallel DTP processes as a value greater than
1 for performance reasons. This is configurable through SAP transaction code
RSBATCH (SAP BI Background Management).

Figure 5: Configuring Parallel Processing in SAP BI

We want to keep the number of parallel processes to a reasonable value for the
overall DTP process type DTP_LOAD, but this parallelism can lead to a timeout error
during the Open Hub DTP extraction through Microsoft Connector for SAP BI. To get
around this issue, the number of processes for the Open Hub DTP should be set to 1
by following the steps below:
1. In the Open Hub DTP screen, select Goto from the menu, then Setting for
Batch Manager:

Figure 6: Opening Batch Manager in SAP BI to configure the number of parallel

processes
2. Change the Number of Processes to 1.

Figure 7: Configuring the number of parallel processes in SAP BI

3. Save the changed settings.
The default setting for the DTP data package is 50,000. Depending on the actual
hardware infrastructure, adjusting the package size may improve the extract,
transform, and load (ETL) performance. Note that the Microsoft SAP BI source will
read the DTP package size to determine the actual data packet size in the
Integration Services package. It is highly recommended to reach an agreement on
the size that balances the concerns of the SAP Basis team and the SQL Server DBA.
In reality, a value between 50,000 and 200,000 should satisfy most needs.

Figure 8: Defining the data package size in SAP BI

A process chain is required to work with the Microsoft Connector (Figure 9).

Figure 9: The two nodes that are the minimum requirement for a process chain in
SAP BI
The process chain must contain at least these two nodes:

Start node with the scheduling option Start Using Meta Chain or API (Figure
10)

Data Transfer Process node

Figure 10: Configuring scheduling options for a process chain in SAP BI

After you activate the process chain, it is ready to be called from the Integration
Services package.
Configuring the Integration Services package in Business Intelligence Development
Studio involves three main steps:
1. Add the SAP BI Source as a source in the data flow.

2. Set up the connection manager for SAP BI.

3. Define the workflow of the package.
After you install the Microsoft Connector from the SQL Server 2008 Feature Pack, go
to Business Intelligence Development Studio and create a new Integration Services
project. The Microsoft Connector components are not available in the Toolbox until
you add them manually. To add them, right click Data Flow Sources in the Toolbox,
click ChooseItems, and then on the SSIS Data Flow Items tab, select the SAP BI
Source check box, as shown in Figure 11.

Figure 11: Adding the SAP BI source to the Toolbox in Business Intelligence
Development Studio
Now SAP BI Source is available in Data Flow Sources (Figure 12).

Figure 12: The list of Data Flow Sources in the Toolbox in Business Intelligence
Development Studio after adding the SAP BI source

Setting Up the Connection Manager for SAP BI

In the Integration Services package, add a new connection and choose SAPBI (Figure
13).

Figure 13: Adding a new SAP BI connection to an Integration Services package

After the connection is created, in the SAP BI connection manager dialog box,
edit the connection and fill out the system and logon information. Click Test
Connection to verify successful configuration (Figure 14).

Figure 14: Configuring the SAP BI connection manager

Adding and Configuring the SAP BI Source
In Business Intelligence Development Studio, drag the SAP BI source to the data
flow of the package (Figure 15).

Figure 15: The representation of the SAP BI source in the data flow of a package
Edit the source by choosing the appropriate SAP BI connection manager, specifying
the RFC destination, and choosing the previously-created process chain (Figure 16).

Figure 16: Configuring the SAP BI source on the Connection Manager page of the
SAP BI Source Editor
Note the different execution modes that are available:

P Trigger Process Chain: The specified process chain is started, the

extraction is made, and after ending the extraction, data is extracted in
packets.

W Wait for Notify: No process chain is started; instead the tool only waits
until it is notified of that the extraction is complete. Someone else is
responsible for starting up the extraction (for example, SAPs own scheduler).

E Extract Only: A process chain is not started, and the source does not wait
for notification. Instead, the Request ID entered in the field Request ID is
used to retrieve data that is hidden behind the respective request.

If the Integration Services package will initiate the ETL process from SAP BI, then
the mode P should be chosen to trigger the SAP BI process chain for data
movement through Open Hub. This is the most suitable option for a pull pattern.

The mode W is the best for a push pattern. In this mode, SAP BI schedules its
own internal ETL, and then it starts the Open Hub DTP to push data to SQL Server.
The mode E is used when there is an error during the ETL and a particular request
needs to be reprocessed. This is mostly useful during testing, or in production
during a data recovery process.
Note that the Extract-Only mode will fail if there are multiple packages within one
request. This failure occurs because the SAP BI system does not provide the number
of packets correctly when the Read function of the Open Hub API is called. To work
around this limitation and support Extract-Only mode, increase the package size in
the DTP of the Open Hub Destination to a value greater than the number of rows
that will be extracted. As a result, only one package is created.
Configuring the Advanced Settings
There are three main options available on the Advanced page of the SAP BI Source
Editor:

String conversion options

Timeout setting

Request ID reset

Figure 17: Configuring advanced options for the SAP BI source on the Advanced
page of the SAP BI Source Editor
Timeout and Request ID are very important.
Timeout specifies the valid period that the Integration Services destination should
wait for the SAP BI source, before the package fails due to a timeout error. If an

Open Hub DTP is expected to run for a long time, as in a full initial extraction,
increase the timeout to a large enough number to avoid the timeout error. However,
for routine delta loads, where the duration is not so long, enter a realistic timeout
value. Any value between 300 and 3600 should be acceptable under normal delta
circumstances.
Request ID can be used to reset a DTP that encountered a problem. If a DTP load is
stuck in Yellow status in SAP BI, the request can be reset to Green. After a request is
successfully reset, it can be deleted in SAP BI in Admin Workbench Monitor. For
more information about DTP request status, check the SAP system table
RSBKREQUEST table on SAP BI, and look under the columns USTATE (User-Defined
Processing Status for a DTP Request) and TSTATE (Technical Processing Status for a
DTP Request). The overall DTP status will be successful when both USTATE and
TSTATE of a DTP request indicate success (value 2). Figure 18 shows all available
values of USTATE and TSTATE.

Figure 18: The available values for the status of a DTP request in SAP BI
Adding and Configuring the Destination
After you set up the SAP BI source, define the destination in the package. An OLE
DB destination is commonly used for this purpose. Based upon the metadata from
the SAP BI source, the system may propose a table creation script if the target table
is not available in the database. After the column mapping is done, the Integration
Services package is ready to run (Figure 19).

Figure 19: A data flow for extracting from an SAP BI source to a non-SAP
destination

Figure 20: Overview of the solution architecture

Sometimes non-SAP data needs to be moved into SAP BI, but it can be challenging
to load some data sources into SAP BI. This challenge can be solved by using the
SAP BI Destination component in Integration Services. Because Integration Services
is versatile in supporting various types of data sources, like XML and flat files, it is
now possible to have a unified ETL platform to move data into SAP BI. This
versatility can be particularly useful in a heterogeneous environment for ad-hoc
reporting or for data analysis and processing purposes. The SAP BI destination
component greatly expands SAP BIs capability in extracting data from non-SAP
environments.
To configure SAP BI to load non-SAP data, you set up the data source and the ETL.
A new External System source system needs to be set up in SAP BI to be able to
communicate with the SAP BI Destination component in Integration Services. This
can be achieved in Admin Workbench (transaction code RSA1), by selecting Source
Systems from the left panel. This selection leads to the RFC Destination setup
screen.

Figure 21: Configuring a source system on the RFC Destination screen in SAP BI
The InfoSource and InfoPackage can either be set up within SAP BIs Admin
Workbench, or in Integration Services from within the SAP BI Destination Editor
dialog box.

Figure 22: Creating SAP BI objects directly from the SAP BI Destination Editor
dialog box
Note that the objects created from the SAP BI Destination Editor dialog box are
put under the Unassigned node application area in SAP workbench. If you prefer a
dedicated application area, consider creating the objects in SAP BI Admin
Workbench.
Configuring the Integration Services package in Business Intelligence Development
Studio involves three main steps:
1. Add the SAP BI Destination as a destination in the data flow.
2. Set up the connection manager for SAP BI.

3. Define the workflow of the package.

Figure 23: Adding the SAP BI destination to the Toolbox in Business Intelligence
Development Studio
Create a new connection manager for SAP BI first. The details can be found in the
setup steps for Application Scenario 1. For more information, see Setting Up the
Connection Manager for SAP BI earlier in this white paper.
After the InfoPackage and InfoSource are available, add the SAP BI destination to
the data flow of the package. Then configure the destination in the SAP BI
Destination Editor dialog box.

Figure 24: Configuring the SAP BI destination on the Connection Manager page
of the SAP BI Destination Editor dialog box
The data flow of the package now looks like this.

Figure 25: A data flow for loading from a non-SAP source to an SAP BI destination
A compelling use case is to leverage Microsoft Connector 1.0 for SAP BI to move the
multidimensional data in SAP BIs InfoCubes to SQL Server Analysis Services cubes,

with all the dimensional structures and content intact. The main objective is to
migrate SAP BI InfoCubes to SQL Server cubes efficiently, in order to construct an
Analysis Services based enterprise data warehouse. This use case demonstrates
that this objective can be achieved with stability, quality, and performance, and
with a relatively small amount of effort.
When SAP BI Open Hub processes InfoCube data, it flattens the multidimensional
structure into a relational structure. So the design idea is to mirror the same flat
structure first in a staging table, then reconstruct the dimensions in the Analysis
Services cube.

Figure 26: Overview of the solution architecture

The standard SAP InfoCube 0FIAP_C03 is used. Its dimensions and fact table
metadata are shown in Figure 27:

Figure 27: Metadata for the dimensions and fact tables in standard SAP BI
InfoCube 0FIAP_C03
The flattened Open Hub structure is shown in Figure 28.

Figure 28: The flattened Open Hub structure in SAP BI

The SAP BI process chain and Integration Services package are shown in Figure 29.

Figure 29: The configuration of the process chain in SAP BI, and of the data flow in
the SQL Server Integration Services package
The column mappings in the Integration Services package are shown in Figure 30.

Figure 30: The column mappings between the SAP BI source and the destination
on the Mappings page of the OLE DB Destination Editor dialog box
The matching structure of the data in SQL Server Analysis Services is shown in
Figure 31.

Figure 31: The structure of the SQL Server Analysis Services cube based on the
data extracted from SAP BI to SQL Server
After the Analysis Services cube is set up, it needs be deployed. Then, each
dimension and the cube itself can be processed to dispatch data from the staging
table to each dimension respectively.
An easy way to validate the data quality after the cube migration is to run and
compare reports on SAP BI and Analysis Services.
Here is the result of an SAP BI BEx query against the SAP BI InfoCube.

Figure 32: Viewing the data in the InfoCube in SAP BI

Here is a Microsoft Excel PivotTable report against the Analysis Services cube.

Figure 33: Viewing the data from the SQL Server Analysis Services cube in an Excel
PivotTable report
Here is a SQL Server Reporting Services report against the Analysis Services cube.

Figure 34: Viewing the data from the Analysis Services cube in a Reporting
Services report
The query results on SAP BI and in the Analysis Services cube match precisely.
This paper has described the functionality of the Microsoft Connector 1.0 for SAP BI,
and provided detailed step-by-step instructions on how to use the connector in SQL
Server Integration Services. A realistic use case is presented with the design
highlights and rationale. Overall, the connector bridges the gap to support building
an enterprise data warehouse solution centered on Microsoft SQL Server 2008 in a
heterogeneous environment with heavy presence of SAP BI. It offers great flexibility
and efficiency for extracting non-SAP data into SAP BI, and for extracting SAP BI
data into a SQL Server data warehouse.
By utilizing the Microsoft Connector 1.0 for SAP BI effectively, it is now possible to
construct a streamlined end-to-end data warehouse and business intelligence
solution based upon Microsoft technologies for enterprises running SAP, with lower
TCO, better design, and more flexibility.
For more information:
http://www.microsoft.com/sqlserver/: SQL Server Web site
http://technet.microsoft.com/en-us/sqlserver/: SQL Server TechCenter
http://msdn.microsoft.com/en-us/sqlserver/: SQL Server DevCenter
http://www.microsoft.com/sqlserver/2008/en/us/integration.aspx: SQL
Server Integration Services Web site
http://technet.microsoft.com/en-us/sqlserver/cc510302.aspx: SQL Server
Integration Services TechCenter
http://msdn.microsoft.com/en-us/sqlserver/cc511477.aspx: SQL Server
Integration Services DevCenter

Did this paper help you? Please give us your feedback. Tell us on a scale of 1 (poor)
to 5 (excellent), how would you rate this paper and why have you given it this
rating? For example:

Are you rating it high due to having good examples, excellent screen shots,
clear writing, or another reason?

Are you rating it low due to poor examples, fuzzy screen shots, or unclear
writing?

This feedback will help us improve the quality of white papers we release.