Using BO Data Federator Tool As A Source For The External Application

Using BO Data Federator Tool as a Source for the External Application
Applies to:
Business Objects report Developers/Consultants. For more information, visit the EDW homepage
Summary
This document gives the Business Objects developers as overview regarding how to work with the Business objects data federator and use it as the source in designing the universe and build a WEBI report on top of it. Author: Vinay Kumar H.S
Company: Infosys Created on: 14 April 2011
Author Bio
Vinay is having a 2.2 years of experience in SAP BI/BO and is working with Infosys from beginning of his carrier in IT as System Engineer.
SAP COMMUNITY NETWORK 2011 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 1
Table of Contents
Background ......................................................................................................................................................... 3 Introduction ......................................................................................................................................................... 4 Case study using BO Data Federator Prototype for new BI solutions................................................................ 5 Development of a BO data federator project is defined in following steps: .................................................... 6
Starting/creation of a Data Federator Project ............................................................................................................... 6 Defining the Data Sources ........................................................................................................................................... 7 Define the target tables .............................................................................................................................................. 11 Mapping datasources to targets process ................................................................................................................... 12 Deploy the project ...................................................................................................................................................... 16
Establishing the connectivity between the BO federator at the Universe Builder ......................................... 17 Creating a Universe using Data Federator as a data source ........................................................................ 18 Developiong the WEBI report on top of the BO federator Universe ............................................................. 22 Advantages of the BO Data federator .............................................................................................................. 24 Limitations of Data Federator ........................................................................................................................... 24 Applications of BO federator ............................................................................................................................. 24 Related Content ................................................................................................................................................ 25 Disclaimer and Liability Notice .......................................................................................................................... 26
Background
Usually most of the businesses maintains several data sources that are spread across different departments or sites. This results in often duplication of the same data in various other data sources and it makes it difficult to use the data to make the strategic decision or perform statistical analysis with minimum efforts and cost. The following diagram illustrates the classic approach to consolidating data.
Following are the common challenges involved in consolidating if it distributed across as defined above: Simplicity and productivity wants to develop a single and simple solution Quality control Wants to ensure that the data is correct and optimized Performance Less number of external joins are there results in retrieving the data at very high rates or good speed Maintenance wants to develop a solution that requires little or no maintenance as new source of data are added or as existing sources systems are changed
How data federator gives the solution for the above issues? Data Federator operates between the sources of data and end report applications. The communication between the data sources and the Data Federator Query Server takes place by means of "connectors." In turn, external applications query data from Data Federator Query Server by using SQL but indeed need to establish the connection between them. The following diagrams illustrate how Data Federator addresses the above needs.
Data Federator uses virtual tables and mappings to present the data from the input sources of data in single/multiple virtual forms which is optimized by default in-terms as target tables to the external application. (Outcome of the BO federator may be a single or many target tables depending on the need of the requirements.)
Introduction
Data federation integrates data from multiple data sources of the organization. It offers a simple and single platform which makes the business users or application developers a single easy to use interface to access n heterogeneous data sources. When a SQL query is thrown on the data federator, the application decides the optimal way of running the desired functionality and thus avoids exposure of its complexity to the end users/developers. Data federation is an ideal way to enhance existing business intelligence (BI) environments. It provides a robust abstraction layer that accelerates deployment and minimizes the impact of changes. Following are ideal four use cases for BI implementations: 1. Accelerate the deployment of BI solutions 2. Prototype new BI solutions 3. Create analytic sandboxes 4. Consolidate BI tool sets/data
Case study using BO Data Federator Prototype for new BI solutions

Objective of this project demo is to integrate the data from 1 flatfile (organization master data), 1 SQL table (Credit/Debit details), 1 Oracle table (material data) into one target table (which integrates the data from all the above mentioned sources) and make use of the target table in the development of the universe and build a WEBI report on top of it. Flatfile data snapshot (Organization Master Data):
Oracle table data snapshot (Material Shipment data):
SQL table data snapshot (Sales related data):
Final report snapshot (expected consolidates the data from all the relevant data sources):
Development of a BO data federator project is defined in following steps: 1. Starting/creation of a Data Federator Project 2. Defining the input data sources 3. Development of target tables a. Defining mappings and the constraints b. Defining Lookup tables/Domain tables (if required) 4. Deploying the Project Starting/creation of a Data Federator Project Creation of the project is the first step which will be followed by defining data sources, targets, mappings etc. Project is a workspace which contains all the components used by Data Federator such as: Targets, Datasources, Mappings, Lookup tables, Domain tables and, Constraint checks.
One can work on a project when it is in development. When it is ready to move into production, move the project to deploy state. Again if further enhancement required for the deployed projects, different ver4sion of the same can be created and deployed when it is ready. Ex: Create a project called ProjectDemo to define 1 Flatfile, 1SQL server and 1 Oracle system as the data sources and to create a target table to take the resultant data among the source systems once the relation between the sources are established as depicted in the earlier sections Below screen shot shows the steps how to create a BO federator project?
Once the project is saved, all the target tables, data sources, domain tables and lookup tables sections among will be available as ready for the further use.
Defining the Data Sources Data is accessed by the federator in terms of the defined data sources, by default federator supports 20 types of predefined types like My-SQL, Oracle, File system, Generic JDBC/ODBC etc, but this number can be enhanced further by using the generic JDBC and ODBC connections like for establishing the connectivity between the SAP R3/BW system to use them as source systems. Once the datasource is defined, it can be connected to the project, and populate target tables with the available (its) data. Example: In this document we have considered two relational data bases such as SQL server and Oracle data base along with one simple flatfile Once the project is saved, create the datasources1 called Flatfile as depicted below of type Textfile which has the organization master data as considered in the earlier section.
After the creation of the datasource, extract the schema of the file (source system1). Make use of the automatic extaction of the schema to avoid cumbersome process where one needs to define manually. Once you extract the schema using the available automatic extraction option, it will extract all the defined columns of the file (save the file in CSV format to use it as source system), the screen looks as depicted below:
By defualt is will be created as the draft version, this draft version of the Sourcetable should made as final to use them in the further target table, mappings creation sections etc.
With out making the source file as Final, one cant use that source further under any sections for example mappings section. If required, many draft versions of the existing file can be created and used in the further process with the required modifications.
In the same way create other datasource of type SQLserver and Oracle as shown below (required). To create the connections to the respective SQL server or Oracle system, the connection parameters are required, these will be provider by the BO data federator administartor.
Steps for the creation of the Oracle system source table:
Check the connectivity between the systems:
Select the required table:
Make the draft version of this as final. In the same steps, create the SQL server connection and select the required table. And make thedraft version of it as final.
Screen shot: Final screen shot indicating all the required data sources available as final in the considered project.
Once the datasources are made final, its draft version can be created through the available options if further enhancements are required. Define the target tables Target tables of the Data Federator tables are created to present data in the correct format to external applications such as BO universe builder etc. Once the target tables created and deployed along with the project, the Data Federator server (Data Federator Query Server) exposes target tables to the other external applications. Below screen shot indicates how to create a target table whose source systems/files are 3 independent ones considered and created in the above sections.
Once the target table is created, add the number of coulmns required.
In our case we need 7 columns (for refernce refer the aforementioned sections) and hence are added as shown below:
Do the required settings at this level like whether you require fields to be defined as not null/key/describe description for each etc., Mapping datasources to targets process The process lists the steps in mapping a single/multiple datasources table to a single target table. (1) Add a mapping rule for a target table. (2) Select the data source tables that map the key of the target table. (3) Write the mapping formulas to map the columns of the target table. Before this process make sure the source tables are defined and made final and also the target tables are ready for the mappings. Mapping rules are created as depicted below:
After creating the new mapping rules, select the required data sources from the available options as shown below:
Here we need to select all the required datasources created. Define the relationship between the selected datasources.
Next, define the formulas between the input datasources and the target table fields. Below screen shot indicates the steps to define the target table fields.
Once the target fields are defined correctly, do the quick cross check of the rules defined to ensure the fields are mapped correctly as shown below.
Then press on viewdata to do the sample dataload to cross check as shown below:
If any corrections are required, those will be corrected at this step to avoid any cumbersome process in the final steps.If any errors are there in the development, those will be indicated in real time through the status message/s, which define the cause of the error and give the predefined solution. Do the final check at the defined target table level, which is same as the data pulled by the external application which uses the data federator deployed project.
Deploy the project Once the federator project is developed completely and is ready to move into the production, it will be deployed on to the local server or on the shared servers depending on the available architecture. Data Federator Projects can be deployed on the servers in the following ways: Deploy the federator project on the same machine that runs the federator designer and also the end applications. Deploy the federator on multiple servers; here the deployments on each server are independent of each other. [There arefew more methods which are not listed here] In this demo we have deployed the project using single Data federation installation process i.e., both the BO federator and the universe builder are installed on the same machine. The project developed is deployed as shown below on the local machine with defualt port address as 3055 (all these port settings can be monitored and if required changed from the BO federator designer Admin window):
If the deployement is successful, you will get the success message as indicated below.
To cross check whether the project is deployed correctly or not, one can verify using the BO Federator administrator. Below screen shot indicates that the deveoped project is deployed correctly:
Establishing the connectivity between the BO federator at the Universe Builder Data federator creates a virtual database which can be accessed through the JDBC/ODBC connectors by the external application like universe designer. If requirement is to create a universe that connects to the Data Federators virtual database and access the deployed projects of data federator, one need to modify the jdbc.sbo file of universe builder to point it to the BO federator, by default this will not be configured. One such method to establish the connection is illustrated below: Update the data access driver configuration file jdbc.sbo of universe builder.
Update JDBC.SBO file of Universe builder

1.
Edit jdbc.sbo with a text editor like Notepad of universe designer. One can find jdbc.sbo in C:\Program Files\Business Objects\Businessobjects Enterprise 12.0\win32_x86\dataAccess\connectionServer\jdbc, if the installation is done on some other directories, it will differ. Search for the word "federator".
2.
3. Right below <JDBCDriver>, add the following line: <CLASSPATH><Path>C:/Program Files\Business Objects\BusinessObjects Data Federator 12\JdbcDriver\lib\thindriver.jar</Path></CLASSPATH> 4. Save and close jdbc.sbo. Creating a Universe using Data Federator as a data source The Data Federator works like a classical JDBC data warehouse. In order to create business objects on top of the virtual tables, define a new universe that will use the previously defined data source/sources through the deployed project of the data federator. After login to the universe designer, create the new JDBC connection to the required catalog (deployed in the earlier case) as shown below: Create a new Universe:
Add/define a new connection of type JDBC:
Enter the Connection Details previously provided during Data Federator Deployment and test the connection to ensure the server is responding properly.
After this, start the table browser. Insert the desired table from the list of tables (TT_ProjectDemo in our case):
Save the universe created and export this to the required repository to use them in further reporting sections like WEBI builder etc. Finally the universe is created in the below format and is exported to the defined target universe domain to make of it in the report development like WEBI/Crystal/Xcelsius etc.,
Developiong the WEBI report on top of the BO federator Universe Once the universe is successfully created and exported to the repository directory, one can access it through the WEBI rich client report builder and develop the report in the required layout by maintaining the required constraints. Select the created and saved universe from the available browser options
And define the query in therequired format and execute it.
Below is the query result screen shot which is desired one (combines the data from the two independent data sources wich is the basic fucntionality of the BO federator)
Advantages of the BO Data federator

Reduces Time, Cost, and Risk: Data federator software is developed for query based application that pulls the data from multiple independent datasources whose implementation consume comparatively less time and gives the efficient solution through the establishment of the joins between various source systems Simplicity: Simple web based application tool, user-friendly application. And also hides the real complexity of the system from the application developer and the end user. Faster Deployment: It doesnt require complex coding method as in other conventional query engines; by default it has all the required functionalities available as ready. Rapid Prototyping: many views of the query can be created with little efforts in case the end user wants to look at all the available options facilitating indirectly for rapid deployment/development.
Limitations of Data Federator

Data federator is good for integrating different data sources with little efforts but it may not be ideal for every type of query based application. There are few technical constraints in using this virtual architecture. Ideal Scenario: Data federator doesnt store the data physically as in conventional ones, it retrieves the data from the respective source systems during the query execution, as a result it demands for the robust continuous connectivity between the sources and itself. Volume of data: Not suitable if the query retrieves huge number of data records or try to make the logical report by analyzing huge volume of data. Also it is best if the source data doesnt require significant cleansing or transformation of data and the end users consumes mostly the current data. Unreliable/ Overloaded Systems and Networks: Since it doesnt store the physical data on its own database, it is not ideal for source systems which are frequently offline or overload with the existing workloads. Complex Transformations: Not advised if data requires multiple transformations.
Applications of BO federator
Data federation can be applied in a many situations for speed deployment, reduce costs, or both. Following are some common applications of data federation: 360-Degree View: Application which requires/have multiple source systems whose data is required to make the business decisions without much cost overhead on fly Real-Time Data: Data federator can augment historical data in a data warehouse with real-time data from an operational application. (And many more)
Related Content
www.help.sap.com www.sdn.sap.com For more information, visit the EDW homepage
Disclaimer and Liability Notice

This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade. SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document, and anyone using these methods does so at his/her own risk. SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this document.

Using BO Data Federator Tool As A Source For The External Application

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Using BO Data Federator Tool As A Source For The External Application

Hochgeladen von

Copyright:

Verfügbare Formate

Using BO Data Federator Tool as a Source for the External Application

Company: Infosys Created on: 14 April 2011

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 1