Powered By

Free XML Skins for Blogger

Powered by Blogger

Showing posts with label BI Modeling. Show all posts
Showing posts with label BI Modeling. Show all posts

Saturday, August 2, 2008

Namespaces for SAP BI Objects

Use

The following namespaces are generally available for BI objects:

SAP-delivery (Business Content) namespace:

· Objects beginning with 0

· Generated objects in the DDIC beginning with /BI0/

InfoCube 0SALES, fact table /BI0/FSALES

Customer namespace:

· Objects beginning with A-Z

· Generated objects in the DDIC beginning with /BIC/

InfoCube SALES, fact table /BIC/FSALES

Partner-specific namespace and customer-specific namespace:

· Object begins with /XYZ/ (example)

Special SAP namespaces for generated objects:

· The prefixes 1, 2, 3, 4, 6, 7, 8 are required in BW for DataSources and InfoSources in special SAP applications.

· The prefix 9A is required for the SAP APO application.

When you create your own objects, therefore, give them technical names that start with a letter. The maximum permitted length for a name varies from object to object. Typically, 9 to 11 letters can be used.

You can transfer from the Business Content version any Business Content objects that start with 0 and modify them to meet your requirements. If you change an InfoObject in the SAP namespace, your modified InfoObject is not overwritten immediately when you install a new release, and your changes remain in place for the time being.

You also have the option of enhancing the SAP Business Content. There is a partner namespace and a customer namespace available for you to do this. You have to request these namespaces specially. Once you have prepared the partner namespace and the customer namespace (for example, /XYZ/) you are able to create BI objects that start with the prefix /XYZ/. You use a forward slash (/) to avoid overlaps with SAP Business Content and customer-specific objects. For more information on this, see Using Namespace for Developing BW Objects.

See also:

InfoObject Naming Conventions

Generating the Master Data Export DataSource

Naming Conventions for Background Jobs

SAP BI Modeling Data Flow Display

Use

In the Modeling functional area of the Data Warehousing Workbench, you can use a graphic to display the dataflow of objects in BI. This illustrates the connections and dependencies between individual objects. You can call this graphic for InfoProviders and InfoSources.

Integration

From the object tree, you can call this graphic for an object by choosing Display Dataflow in the context menu (right mouse click) of the object. The graphic is displayed in the right-hand screen area of the Data Warehousing Workbench. All related objects and rules are displayed which precede this object in the data flow. For InfoSources with flexible update, all related objects are displayed up to and including the InfoProviders.

Features

The objects themselves represent nodes in the graphic. The rules that describe the dependencies between objects are displayed using arrows. An icon tells you what type of rule it is. The nodes contain the object symbol and the descriptive text. Which rule joins two objects and whether this is active or inactive is displayed using quick info if you select the corresponding arrow with the mouse. By choosing the appropriate pushbutton on the data flow graphic, you can display the technical name of the objects, print, enlarge, reduce, turn, refresh, and save the graphic in jpg form.

By double clicking on a node or arrow you branch to the display of an object or a rule.

SAP BI Modeling DataSource

Definition

Set of fields that provide the data for a business unit for data transfer into BI. From a technical viewpoint, the DataSource is a set of logically-related fields that are provided to transfer data into BI in a flat structure (the extraction structure), or in multiple flat structures (for hierarchies).

There are four types of DataSource:

● DataSource for transaction data

● DataSource for master data

○ DataSource for attributes

○ DataSource for texts

○ DataSource for hierarchies

Use

DataSources supply the metadata description of source data. They are used for extracting data from a source system and for transferring data into BI.

The following image illustrates the role of the DataSource in the BI data flow:

This graphic is explained in the accompanying text

The data is loaded into BI from any source in the DataSource structure. An InfoPackage is used for this purpose. You determine the target into which data from the DataSource is to be updated during the transformation. You also assign DataSource fields to target object InfoObjects in BI.

Scope of DataSource Versus 3.x DataSource

3.x DataSource

DataSources were previously known as DataSource replicates (object type R3TR ISFS) in the BI system. The transfer of data from this type of DataSource (referred to as 3.x DataSources below) is only possible if the 3.x DataSource is assigned to a 3.x InfoSource and the fields of the 3.x DataSource are assigned to 3.x InfoSource InfoObjects in transfer structure maintenance. A PSA table is generated when the 3.x transfer rules are activated, thus activating the 3.x transfer structure. Data can be loaded into this PSA table.

If your dataflow is modeled using objects that are based on the old concept (3.x InfoSource, 3.x transfer rules, 3.x update rules) and the process design is built on these objects, you can continue to work with 3.x DataSources when transferring data into BI from a source system.

DataSource

As of SAP NetWeaver 2004s, a new object concept is available for DataSources. It is used in conjunction with the changed objects concepts in data flow and process design (transformation, InfoPackage for loading to the PSA, data transfer process for data distribution within BI). The object type for a DataSource in the new concept - called DataSource in the following - is R3TR RSDS.

In DataSource maintenance in BI, you specify which DataSource fields contain the decision-relevant information for a business process and should therefore be transferred. When you activate the DataSource, the system generates a PSA table in the entry layer of BI. You can then load data into the PSA. You use an InfoPackage to specify the selection parameters for loading data into the PSA. In the transformation, you determine how the fields of the are assigned to the BI InfoObjects. Data transfer processes facilitate the further distribution of data from the PSA to other targets. The rules that you set in the transformation are applied here.

Overview of Object Types

A DataSource cannot exist simultaneously in both object types in the same system. The following table provides an overview of the (transport-relevant) metadata object types. The table also includes the object types for DataSources in SAP source systems:

DataSource Type

BI:

Object Type of A or M Version

BI:

Object Type of Shadow Version (Source System Independent)

SAP Source System:

Object Type of A Version

SAP Source System:

Object Type of D Version

DataSource

R3TR RSDS

R3TR SHDS
(Shadow object delivered in its own table with release and version)

R3TR OSOD

R3TR OSOA

3.x DataSource

R3TR ISFS

R3TR SHFS for non-replicating source systems

SHMP for replicating source systems, that is SAP source systems
(shadow object delivered in its own table with source system key)

R3TR OSOD

R3TR OSOA

Restrictions

The new DataSource concept cannot yet be used for transferring data from external systems (metadata and data transfer using staging BAPIs) or for transferring hierarchies.

Recommendation

We recommend that you adapt the data flow for the DataSource and the process design to the new concepts. If you want to migrate an existing data flow, first use an emulated 3.x DataSource and create a transformation for it. You can then migrate the 3.x DataSource to a DataSource and benefit from the new concepts in your scenario.

SAP BI Modeling Functions for DataSources

Use

You can execute the following DataSource functions in the object tree of the Data Warehousing Workbench. The functions available differ depending on the object type (DataSource – RSDS, DataSource 3.x – ISFS) and source system:

● In the context menu of an application component, you can execute the following functions:

○ For both object types: Replicate metadata for all DataSources that are assigned to this application component.

○ For object type RSDS: Create DataSource.

● In the context menu of a DataSource, you can execute the following functions:

○ For both object types: Display, delete, manage, create transformation, create data transfer process, create InfoPackage.

○ For object type RSDS: Change, copy (however, not with an SAP source system as the target).

○ For object type ISFS: Create transfer rules, migrate.

○ Only for DataSources from SAP source systems (both object types): Display DataSource in source system, replicate metadata.

In the DataSource repository (transaction RSDS), you can execute the following functions. Here too, the functions available depend on the object type:

○ For both object types: Display, delete, replicate.

○ For object type RSDS: Change, create, copy (however, not with an SAP source system as the target), restore DataSource 3.x (if the DataSource is the result of migration and the migration was performed using the With Export option).

○ For object type ISFS: Migrate.

Features

The following table provides an overview of the functions available in the Data Warehousing Workbench and DataSource repository for DataSources and DataSources 3.x:

Function

Description

More Information

Create

If you want to create a new DataSource for transferring data using UD Connect, DB Connect or from flat files, you first specify the name of the DataSource, the source system, where appropriate, and the data type of the DataSource.

DataSource maintenance appears and you can enter the required data on the tab pages there.

DataSource Maintenance in BI

Display

The display mode of DataSource maintenance appears.

You can display a DataSource 3.x or a DataSource (emulation). You cannot switch from the display mode to the change.

DataSource Maintenance in BI

Emulation, Migration and Restoring DataSources

Change

The change mode of DataSource maintenance appears.

For transfer of data from SAP source systems, you use this interface to select the fields from the DataSource to be transferred and to make specifications for format and conversion of field contents from the DataSource.

DataSource Maintenance in BI

Copy

You can use a DataSource as a template for creating a new DataSource. This function is not available if you want to use an SAP source system as the target. For SAP source systems, you can create DataSources in the source system in generic DataSource maintenance (RS02).

-

Delete

When you delete a DataSource, the dependent objects (such as a transformation or InfoPackage) are also deleted.

-

Administration

The overview screen for requests in the PSA appears. Here you can select the requests that contain the data you want to call in PSA maintenance.

Structure linkPersistent Staging Area

For SAP source systems: Display DataSource in source system

The DataSource display in the SAP source system appears.

-

For SAP source systems: Replicate metadata

The BI-relevant metadata for DataSources in SAP source systems is transferred into BI from the source system by means of replication.

Structure linkReplicating DataSources

Create transformations

In the transformation, you determine how you want to assign the DataSource fields to InfoObjects in BI.

Structure linkCreating Transformations

Create data transfer processes

In the data transfer process, you determine how you want to distribute the data from the PSA to additional targets in BI.

Structure linkCreating Data Transfer Processes

Create InfoPackage

In the InfoPackage, you determine selections for transferring data into BI.


For DataSources 3.x: Create transfer rules

If the DataSource 3.x is assigned to an InfoSource, determine how the DataSource fields are assigned to the InfoObjects of the InfoSource and how the data is to be transferred to the InfoObjects.

Structure linkProcessing Transfer Rules

For DataSources 3.x: Migrate

You can migrate a DataSource 3.x to a DataSource, that is, you can convert the metadata on the database. The DataSource 3.x can be restored to its status before the migration if the associated objects of DataSource 3.x (DataSource ISFS, mapping ISMP, transfer structure ISTS) are exported during migration. Before you perform migration, we recommend that you create the data flow with a transformation based on a DataSource 3.x. You also have the option of using an emulated DataSource 3.x.

Emulation, Migration and Restoring DataSources

DataSource Maintenance in SAP BI Modeling

In DataSource maintenance in BI you can display DataSources and 3.x DataSources.

You can create or change DataSources for file source systems, UD Connect, DB Connect and Web services on this BI interface.

In DataSource maintenance, you can edit DataSources from SAP source systems. In particular, you can specify which fields you want to transfer into BI. In addition, you can determine properties for extracting data from the DataSource and properties for the DataSource fields. You can also change these properties.

You call DataSource maintenance from the context menu of a DataSource (Display, Change) or, if you are in the Data Warehousing Workbench, from the context menu of an application component in an object tree (Create DataSource). Alternatively you can call DataSource maintenance from the DataSource repository. In the Data Warehousing Workbench toolbar, choose DataSource to access the DataSource repository.

Creating DataSources for File Source Systems SAP BI Modeling

Use

Before you can transfer data from a file source system, the metadata (the file and field information) must be available in BI in the form of a DataSource.

Prerequisites

Note the following with regard to CSV files:

● Fields that are not filled in a CSV file are filled with a blank space if they are character fields and with a zero (0) if they are numerical fields.

● If separators are used inconsistently in a CSV file, the incorrect separator (which is not defined in the DataSource) is read as a character and both fields are merged into one field and may be shortened. Subsequent fields are no longer in the correct order.

Note the following with regard to CSV files and ASCII files:

● The conversion routine that are used determine whether you have to specify leading zeros. See Conversion Routines in BI Systems.

● For dates, you usually use the format YYYYMMDD, without internal separators. Depending on the conversion routine that is used, you can also use other formats.

Notes on Loading

When you load external data, you can load the data into BI from any workstation. For performance reasons, however, you should store the data on an application server and load it into BI from there. This means that you can also load the data in the background.

If you want to load a large amount of transaction data into BI from a flat file and you can specify the file type of the flat file, you should create the flat file as an ASCII file. From a performance point of view, loading data from an ASCII file is the most cost-effective method. Loading from a CSV file takes longer because in this case, the separator characters and escape characters have to be sent and interpreted. In some circumstances, generating an ASCII file may involve more effort.

Procedure

You are in the Data Warehousing Workbench in the DataSource tree.

...

1. Select the application components in which you want to create the DataSource and choose Create DataSource.

2. On the next screen, enter a technical name for the DataSource, select the type of DataSource and choose Copy.

The DataSource maintenance screen appears.

3. Go to the General tab page.

a. Enter descriptions for the DataSource (short, medium, long).

b. As required, specify whether the DataSource builds an initial non-cumulative and can return duplicate data records within a request.

Specify whether you want to generate the PSA for the DataSource in untyped format: If the PSA is not typed it is not generated in a typed structure but is generated with character-like fields of type CHAR only.

Use this option if conversion during loading causes problems, for example, because there is no appropriate conversion routine, or if the source cannot guarantee that data is loaded with the correct data type.

In this case, after you have activated the DataSource you can load data into the PSA and correct it there.

4. Go to the Extraction tab page.

a. Define the delta method for the DataSource.

b. Specify whether you want the DataSource to support direct access to data.

c. Real-time data acquisition is not supported for data transfer from files.

d. Select the adapter for the data transfer. You can load text files or binary files from your local work station or from the application server.

Text-type files only contain characters that can be displayed and read as text. CSV and ASCII files are examples of text files. For CSV files you have to specify a character that separates the individual field values. In BI you have to specify this separator character and an escape character which specifies this character as a component of the value, as required. After you have specified these characters you have to use them in the file. ASCII files contain data in a specified length. The defined field length in the file must be the same as the length of the assigned field in BI.

Binary files contain data in the form of Bytes. A file of this type can contain any type of Byte value, including Bytes that cannot be displayed or read as text. In this case, the field values in the file have to be the same as the internal format of the assigned field in BI.

Choose Properties if you want to display the general adapter properties.

e. Select the path to the file that you want to load or enter the name of the file directly, for example C:/Daten/US/Kosten97.csv.

You can also create a routine that determines the name of your file. If you do not create a routine to determine the name of the file, the system reads the file name directly from the File Name field.

f. Depending on the adapter and the file to be loaded, make further settings.

■ For binary files:

Specify the character record settings for the data that you want to transfer.

■ Text-type files:

Specify how many rows in your file are header rows and can therefore be ignored when the data is transferred.

Specify the character record settings for the data that you want to transfer.

For ASCII files:

If you are loading data from an ASCII file, the data is requested with a fixed data record length.

For CSV files:

If you are loading data from an Excel CSV file, specify the data separator and the escape character.

Specify the separator that your file uses to divide the fields in the Data Separator field.

If the data separator character is a part of the value, the file indicates this by enclosing the value in particular start and end characters. You enter these start and end characters in the Escape Characteristics field.

You chose the ; character as data separator. However, your file contains the value 12;45 for a field. If you set “ as the escape character, the value in the file must be 12;45“ so that 12;45 is loaded into BI. The complete value that you want to transfer has to be enclosed by the escape characters.

If the escape characters do not enclose the value but are used within the value, the system interprets the escape characters as a normal part of the value. If you have specified “ as the escape character, the value 12”45 is transferred as 12”45 and 12”45” is transferred as 12”45”.

In a text editor (for example, note pad) check the escape character and separator currently being used in the file. These depend on the country version of the file you used.

Note that if you do not specify an escape character, the space character is interpreted as the escape character. We recommend that you use a different character as the escape character.

If you select the Hex indicator, you can specify the data separator and the escape character in hexadecimal format. When you enter a character for the data separator and the escape character, these are displayed as hexadecimal code after the entries have been checked. A two character entry for a data separator or an escape sign is always interpreted as a hexadecimal entry.

g. Make the settings for the number format (thousand separator and character used to represent a decimal point), as required.

h. Make the settings for currency conversion, as required.

i. Make any further settings that are dependent on your selection, as required.

5. Go to the Proposal tab page.

This tab page is only relevant for CSV files. For files in different formats, define the field list on the Fields tab page.

Here you create a proposal for the field list of the DataSource based on the sample data from your CSV file.

a. Specify the number of data records that you want to load and choose Upload Sample Data.

The data is displayed in the upper area of the tab page in the format of your file.

The system displays the proposal for the field list in the lower area of the tab page.

b. Choose Copy to Field List to select the fields that you want to transfer to the field list for the DataSource. All fields are selected by default.

6. Go to the Fields tab page.

Here you edit the fields that you transferred to the field list of the DataSource from the Proposal tab page. If you did not transfer the field list from a proposal, you can define the fields of the DataSource here.

a. To define a field, choose Insert Row and specify a field name.

b. Under Transfer, specify the decision-relevant DataSource fields that you want to be available for extraction and transferred to BI.

c. Instead of generating a proposal for the field list, you can enter InfoObjects to define the fields of the DataSource. Under Template InfoObject, specify InfoObjects for the fields in BI. This allows you to transfer the technical properties of the InfoObjects into the DataSource field.

Entering InfoObjects here does not equate to assigning them to DataSource fields. Assignments are made in the transformation. When you define the transformation, the system proposes the InfoObjects you entered here as InfoObjects that you might want to assign to a field.

d. Change the data type of the field as required.

e. Specify the key fields of the DataSource.

These fields are generated as a secondary index in the PSA. This is important in ensuring good performance for data transfer process selections, in particular with semantic grouping.

f. Specify whether lowercase is supported.

g. Specify whether the source provides the data in the internal or external format.

h. If you choose the external format, ensure that the output length of the field (external length) is correct. Change the entries, as required.

i. If required, specify a conversion routine that converts data from an external format into an internal format.

j. Select the fields for which you want to be able to set selection criteria when you schedule a data request using an InfoPackage. Data for this type of field is transferred in accordance with the selection criteria specified in the InfoPackage.

k. Choose the selection options (such as EQ, BT) that you want to be available for selection in the InfoPackage.

l. If required, in the field type, specify whether the data to be selected is language-dependent or time-dependent.

7. Check, save and activate the DataSource.

8. Go to the Preview tab page.

If you select Read Preview Data, the number of data records you specified in your field selection is displayed in a preview.

This function allows you to check whether the data formats and data are correct.

Result

The DataSource is created and is visible in the Data Warehousing Workbench in the DataSource overview for the file source system in the application component. When you activate the DataSource, the system generates a PSA table and a transfer program.

You can now create an InfoPackage. You define the selections for the data request in the InfoPackage. The data can be loaded into the inbound layer of the BI system, the PSA. Alternatively you can access the data directly if the DataSource supports direct access and you have defined a VirtualProvider in the data flow.

Creating DataSources for UD Connect SAP BI Modeling

Use

To transfer data from UD Connect sources into BI, metadata (the information about the source object and source object elements) has to be available in BI in the form of a DataSource.

Prerequisites

You have connected a UD Connect source system.

Note the following background information:

Using InfoObjects with UD Connect

Data Types and Their Conversion

Using SAP Namespace for Generated Objects

Procedure

You are in the DataSource tree in the Data Warehousing Workbench.

...

1. Select the application components in which the DataSource is to be created and choose Create DataSource.

2. In the next screen, enter a technical name for the DataSource, select the type of the DataSource and choose Copy.

The DataSource maintenance screen appears.

3. Go to the General tab page.

a. Enter descriptions for the DataSource (short, medium, long).

b. If necessary, specify if the DataSource builds an initial non-cumulative and supplies potentially duplicate data records within a request.

4. Go to the Extraction tab page.

a. Define the delta method for the DataSource.

b. Specify whether you want the DataSource to support direct access to data.

c. UD Connect does not support real-time data acquisition.

d. The system displays Universal Data Connect (Binary Transfer) as the adapter for the DataSource.

Choose Properties if you want to display the general adapter properties.

e. Select the UD Connect source object.

The connection to the UD Connect source is established. All source objects that are available in the selected UD Connect source can be selected using input help. Source objects can be multi-dimensional storage or relational objects.

5. Go to the Proposal tab page.

The system displays the elements of the source object (for JDBC for example fields, or for XMLA and ODBO characteristics and key figures) and creates a mapping proposal for DataSource fields. The mapping proposal is based on the similarity of the names of the source object element and DataSource field and the compatibility of the respective data types.

Note that source object elements can have a maximum of 90 characters. Both upper and lower case are supported.

a. Check the mapping and change the proposed mapping as required. Assign the non-assigned source object elements to free DataSource fields.

You cannot map elements to fields if the types are incompatible. The system produces an error message in this case.

b. Under Copy to Field List, select the fields that you want to transfer to the field list for the DataSource. All fields are selected by default.

6. Maintain the Fields tab page.

Here you edit the fields that you transferred to the field list of the DataSource from the Proposal tab page.

a. Under Transfer, specify the decision-relevant DataSource fields that should be available for extraction and transferred to BI.

b. If required, change the values for the key fields of the source.

These fields are generated as a secondary index in the PSA. This is important in ensuring good performance for data transfer process selections, in particular with semantic grouping.

c. If required, change the data type for a field.

d. Specify whether the source provides the data in the internal or external format.

e. If you choose an External Format, ensure that the output length of the field (external length) is correct. Change the entries, as required.

f. If required, specify a conversion routine that converts data from an external format into an internal format.

g. Select the fields for which you want to be able to set selection criteria when you schedule a data request using an InfoPackage. Data for this type of field is transferred in accordance with the selection criteria specified in the InfoPackage.

h. Choose the selection options (such as EQ, BT) that you want to be available for selection in the InfoPackage.

i. Under Field Type, specify whether the data to be selected is language-dependent or time-dependent, as required.

If you did not transfer the field list from a proposal, you can define the fields of the DataSource directly. Choose Insert Row and enter a field name. You can specify InfoObjects in order to define the DataSource fields. Under Template InfoObject, specify InfoObjects for the fields of the DataSource. This allows you to transfer the technical properties of the InfoObjects into the DataSource field.

Entering InfoObjects here does not equate to assigning them to DataSource fields. Assignments are made in the transformation. When you define the transformation, the system proposes the InfoObjects you entered here as InfoObjects that you might want to assign to a field.

7. Check, save and activate the DataSource.

8. Go to the Preview tab page.

If you select Read Preview Data, the number of data records you specified in your field selection is displayed in a preview.

This function allows you to check whether the data formats and data are correct.

Result

The DataSource is created and added to the DataSource overview for the UD Connect source system in the application component in the Data Warehousing Workbench. When you activate the DataSource, the system generates a PSA table and a transfer program.

You can now create an InfoPackage. You define the selections for the data request in the InfoPackage. The data can be loaded into the entry layer of the BI system, the PSA. Alternatively you can access the data directly if the DataSource allows direct access and you have a VirtualProvider in the definition of the data flow.

SAP BI Modeling Creating DataSources for DB Connect

Use

Before you can transfer data from a database source system, the metadata (the table, view and field information) must be available in BI in the form of a DataSource.

Prerequisites

See Requirements for Database Tables or Views

You have connected a DB Connect source system.

Procedure

You are in the Data Warehousing Workbench in the DataSource tree.

...

1. Select the application components in which you want to create the DataSource and choose Create DataSource.

2. On the next screen, enter a technical name for the DataSource, select the type of DataSource and choose Copy.

The DataSource maintenance screen appears.

3. Go to the General tab page.

a. Enter descriptions for the DataSource (short, medium, long).

b. As required, specify whether the DataSource builds an initial non-cumulative and can return duplicate data records within a request.

4. Go to the Extraction tab page.

a. Define the delta process for the DataSource.

b. Specify whether you want the DataSource to support direct access to data.

c. The system displays Database Table as the adapter for the DataSource.

Choose Properties if you want to display the general adapter properties.

d. Select the source from which you want to transfer data.

■ Application data is assigned to a database user in the Database Management System (DBMS). You can specify a database user here. In this way you can select a table or view that is in the schema of this database user. To perform an extraction, the database user used for the connection to BI (also called BI user) needs read permission in the schema of the database user.

If you do not specify the database user, the tables and views of the BI user are offered for selection.

■ Call the value help for field Table/View.

In the next screen, select whether tables and/or views should be displayed for selection and enter the necessary data for the selection under Table/View. Choose Execute.

■ The database connection is established and the database tables are read. The Select DB Object Names screen appears. The tables and views belonging to the specified database user that correspond to your selections are displayed on this screen. The technical name, type and database schema for a table or view are displayed.

Only use tables and views in the extraction whose technical names consist solely of upper case letters, numbers, and underscores (_). Problems may arise if you use other characters.

Extraction and preview are only possible if the database user used in the connection (BI user) has read permission for the selected table or view.

Some of the tables and views belonging to a database user might not lie in the schema of the user. If the responsible database user for the selected table or view does not match the schema, you cannot extract any data or call up a preview. In this case, make sure that the extraction is possible by using a suitable view. For more information, see Database Users and Database Schemas.

5. Go to the Proposal tab page.

The fields of the table or view are displayed here. The overview of the database fields tells you which fields are key fields, the length of the field in the database compared with the length of the field in the ABAP data dictionary, and the field type in the database and the field type in the ABAP dictionary. It also gives you additional information to help you check the consistency of your data.

A proposal for creating the DataSource field list is also created. Based on the field properties in the database, a field name and properties are proposed for the DataSource. Conversions such as from lowercase to uppercase or from “ “ (space) to “_“ (underlining) are carried out. You can also change names and other properties of the DataSource field. Type changes are necessary, for example, if a suitable data type is not proposed. Changes to the name could be necessary if the first 16 places of field names on the database are identical. The field name in the DataSource is truncated after 16 places, so that a field name could occur more than once in proposals for the DataSource.

When you use data types, be aware of database-specific features. For more information, see Requirements for Database Tables and Views.

6. Choose Copy to Field List to select the fields that you want to transfer to the field list for the DataSource. All fields are selected by default.

7. Go to the Fields tab page.

Here you edit the fields that you transferred to the field list of the DataSource from the Proposal tab page.

a. Under Transfer, specify the decision-relevant DataSource fields that should be available for extraction and transferred to BI.

b. If required, change the values for the key fields of the source.

These fields are generated as a secondary index in the PSA. This is important in ensuring good performance for data transfer process selections, in particular with semantic grouping.

c. Specify whether the source provides the data in the internal or external format.

d. If you choose an External Format, ensure that the output length of the field (external length) is correct. Change the entries, as required.

e. If required, specify a conversion routine that converts data from an external format into an internal format.

f. Select the fields for which you want to be able to set selection criteria when you schedule a data request using an InfoPackage. Data for this type of field is transferred in accordance with the selection criteria specified in the InfoPackage.

g. Choose the selection options (such as EQ, BT) that you want to be available for selection in the InfoPackage.

h. Under Field Type, specify whether the data to be selected is language-dependent or time-dependent, as required.

8. Check the DataSource.

The field names are checked for upper and lower case letters, special characters, and field length. The system also checks whether an assignment to an ABAP data type is available for the fields.

9. Save and activate the DataSource.

10. Go to the Preview tab page.

If you choose Read Preview Data, the specified number of data records, corresponding to your field selection, is displayed in a preview.

This function allows you to check whether the data formats and data are correct. If you can see in the preview that the data is incorrect, try to localize the error.

See also: Localizing Errors

Result

The DataSource is created and is visible in the Data Warehousing Workbench in the DataSource overview for the database source system under the application component. When you activate the DataSource, the system generates a PSA table and a transfer program.

You can now create an InfoPackage. You define the selections for the data request in the InfoPackage. The data can be loaded into the entry layer of the BI system, the PSA. Alternatively you can access the data directly if the DataSource supports direct access and you have a VirtualProvider in the definition of the data flow.

Creating DataSources for Web Services SAP BI Modeling

Use

In order to transfer data into BI using a Web service, the metadata first has to be available in BI in the form of a DataSource.

Procedure

You are in the DataSource tree in the Data Warehousing Workbench.

...

1. Select the application components in which the DataSource is to be created and choose Create DataSource.

2. In the next screen, enter a technical name for the DataSource, select the type of the DataSource and choose Copy.

The DataSource maintenance screen appears.

3. Go to the General tab page.

a. Enter descriptions for the DataSource (short, medium, long).

b. If necessary, specify whether the DataSource may potentially deliver duplicate data records within a request.

4. Go to the Extraction tab page.

Define the delta method for the DataSource.

DataSources for Web services support real-time data acquisition. Direct access to data is not supported.

5. Go to the Fields tab page.

Here you determine the structure of the DataSource either by defining the fields and field properties directly, or by selecting an InfoObject as a Template InfoObject and transferring its technical properties for the field in the DataSource. You can modify the properties that you have transferred from the InfoObject further to suit your requirements by changing the entries in the field list.

Entering InfoObjects here does not equate to assigning them to DataSource fields. Assignments are made in the transformation. When you define the transformation, the system proposes the InfoObjects you entered here as InfoObjects that you might want to assign to a field.

6. Save and activate the DataSource.

7. Go to the Extraction tab page.

The system has generated a function module and a Web service with the DataSource. They are displayed on the Extraction tab page. The Web service is released for the SOAP runtime.

8. Copy the technical name of the Web service and choose Web Service Administration.

The administration screen for SOAP runtime appears. You can use the search function to find the Web service. The Web service is displayed in the tree of the SOAP Application for RFC-Compliant FMs. Select the Web service and choose Web Service ® WSDL (Web Service Description Language) to display the WSDL description.

Result

The DataSource is created and is visible in the Data Warehousing Workbench in the application component in the DataSource overview for the Web service source system. When you activate the DataSource, the system generates a PSA table and a transfer program.

Before you can use a Web service to transfer data into BI for the DataSource, create a corresponding InfoPackage (push package). If an InfoPackage is already available for the DataSource, you can test the Web service push in Web service administration.

See also:

Web Services

Emulation, Migration and Restoring DataSources SAP BI Modeling

Emulation

3.x DataSources (object type R3TR ISFS) exist in the BI database in the metadata tables that were available in releases prior to SAP NetWeaver 2004s.

The emulation permits you to display and use the DataSource 3.x using the interfaces of the new DataSource concept. The DataSource (R3TR RSDS) is instantiated from the metadata tables of the DataSource 3.x.

You can display a 3.x DataSource as an emulated DataSource in DataSource maintenance in BI. You can also model the data flow with transformations for an emulated DataSource if there are already active transfer rules and a transfer structure and a PSA for the 3.x DataSource. Once you have defined the objects of the data flow, you can set the processes for data transfer (loading process using InfoPackage and data transfer process), along with other data processing processes in BI. We recommend that you use process chains.

Emulation and definition of the objects and processes of the data flow that are based on the emulation in accordance with the new concept are a preparatory step in migrating the DataSource.

If you use an emulated DataSource 3.x, note that the InfoPackage does not use all of the settings defined in the 3.x data flow because in the new data flow it only loads the data into the PSA. To prevent problems arising from misunderstandings about using the InfoPackage, we recommend that you only use the emulation in development and test systems.

More Information:

Using Emulated 3.x DataSources

Migration

You can migrate a 3.x DataSource that transfers data into BI from an SAP source system or a file or uses DB Connect to transfer data into a DataSource. 3.x XML DataSources and 3.x DataSources that use UD Connect to transfer data cannot be migrated directly. However, you can use the 3.x versions as a copy template for a Web service or UD Connect DataSource.


You cannot migrate hierarchy DataSources, DataSources that use the IDoc transfer method, export DataSources (namespace 8* or /*/8*) or DataSources from BAPI source systems.

Migration (SAP Source Systems, File, DB Connect)

If the 3.x DataSource already exists in a data flow based on the old concept, you use emulation first to model the data flow with transformations and data transfer processes and then test it. During migration you can delete the data flow you were using before, along with the metadata objects.

If you are using real-time data acquisition or want to access data directly using the data transfer process, we recommend migration. Emulation does not support this.

This graphic is explained in the accompanying text

When you migrate a 3.x DataSource (R3TR ISFS) in an original system, the system generates a DataSource (R3TR RSDS) with a transport connection. The 3.x DataSource is deleted, along with the 3.x metadata object mapping (R3TR ISMP) and transfer structure (R3TR ISTS), which are dependent on it. If a PSA and InfoPackages (R3TR ISIP) already exist for the 3.x DataSource, they are transferred to the migrated DataSource, along with the requests that have already been loaded. After migration, only the specifications about how data is loaded into the PSA are used in the InfoPackage.

You can export the 3.x objects, 3.x DataSource, mapping and transfer structure during the migration so that these objects can be restored. The collected and serialized objects are stored in a local table (RSDSEXPORT).

You can now transport the migration into the target system.

When you import the transport into the target system in the after import, the system migrates the 3.x DataSource (R3TR ISFS) (as long as it is available in the target system) to a local DataSource (R3TR RSDS), without exporting the objects that are to be deleted. The 3.x DataSource, mapping (R3TR ISMP) and transfer structure (R3TR ISTS) objects are deleted and the related InfoPackages are migrated. The data in the DataSource (R3TR RSDS) is transferred to the PSA.

More Information:

Migrating 3.x DataSources

Migrating by Copying

You cannot migrate in the way described above

● If you are transferring data into BI using a Web service and have previously used XML DataSources that were created on the basis of a file DataSource.

● If you are transferring data into BI using UD Connect and have previously used a UD Connect DataSource that was generated using an InfoSource.

3.x XML DataSource à Web Service DataSource

You can make a copy of a generated 3.x XML DataSource in a source system of type Web Service. When you activate the DataSource, the system generates a function module and a Web service. On your interface, these are different to the 3.x objects. The 3.x objects (3.x DataSource, mapping, transfer rules and generated function module and Web service) are therefore obsolete and can be deleted manually.

3.x UD Connect DataSource à UD Connect DataSource

For a 3.x UD Connect DataSource, you can make a copy in a source system of type UD Connect. The 3.x objects (3.x DataSources, mapping, transfer rules and the generated function module) are obsolete after they have been copied and can be deleted manually.

More Information:

Migrating 3.x DataSources (UD Connect, Web Service)

Restoring

For SAP source systems, files and DB Connect, you can restore a 3.x DataSource from a DataSource (R3TR RSDS) as long as you exported the 3.x metadata objects when the 3.x DataSource was migrated in the original system and in so doing, archived them. The system reproduces the 3.x DataSource (R3TR ISFS), mapping (R3TR ISMP), and transfer structure (R3TR ISTS) objects with their pre-migration status.

Only use this function if unexpected problems occur with the new data flow after migration and these problems can only be solved by restoring the data flow used previously.

This graphic is explained in the accompanying text

When you restore, the 3.x DataSource (R3TR ISFS), mapping (R3TR ISMP) and transfer structure (R3TR ISTS) objects that were exported are generated with a transport connection in the original system. The DataSource (R3TR RSDS) is deleted. The system tries to retain the PSA. This is only possible if a PSA existed for the 3.x DataSource before migration. This may not be the case if an active transfer structure did not exist for the 3.x DataSource or if the data for the DataSource was loaded using an IDoc. The InfoPackage (R3TR ISIP) for the DataSource is retained in the system. Available targets are displayed in the InfoPackage (this also applies to InfoPackages that were created after migration). However, in InfoPackage maintenance, you have to reselect the targets into which you want to update data.

The transformation (R3TR TRFN) and data transfer process (R3TR DTPA) objects that are dependent on the DataSource (R3TR RSDS) are retained and can be deleted manually, as required. You can no longer use data transfer processes for direct access or real-time data acquisition.

You can now transport the restored 3.x DataSource and the dependent transfer structure and mapping objects into the target system.

When you transport the restored 3.x DataSource into the target system, the DataSource (R3TR RSDS) is deleted in the after image. The PSA and InfoPackages are retained. If a transfer structure (R3TR ISTS) is transported with the restore process, the system tries to transfer the PSA for this transfer structure. This is not possible if no transfer structure exists when you restore the 3.x DataSource or if IDoc is specified as the transfer method for the 3.x DataSource. The PSA is retained in the target system but is not assigned to a DataSource/3.x DataSource or to a transfer structure.

Archives