When to create a generic datasource?
● When BI Content does not include a DataSource for your application.
● When BI Content requires additional enhancements that need data that is not supplied by BI.
● When the application does not feature its own generic data extraction method.
● When you use your own programs to fill your tables in the SAP system.
Go to transaction RSO2 to create or maintain generic datasources.
You can release Generic DataSources in your SAP source system by implementing SAP Note 223584 in your source system and then executing the program BS_ANLY_DS_RELEASE_ODP.
Creating Data Sources without Delta
When you create a generic DataSource, you first have to enter the application component and descriptions for describing the DataSource. Definition of the application component determines where the DataSource metadata is stored in ECC.
You can then select the data source for the generic DataSource. Here you can choose both transparent tables and database views. You can also use SAP Query or InfoSet Query to extract data.
Choose Extraction from View if you want to extract the data from a transparent table or database view, and enter the name of the table or view. The extraction structure of the generated DataSource is then identical to that of the view or table.
Choose Extraction from Query if you want to use an SAP query InfoSet as a data source. Then select the required InfoSet from the InfoSet catalog. You can go to the screen for maintaining an existing InfoSet by double-clicking its name.
Generic Extraction with View
You create views with transaction SE11 (ABAP Workbench Dictionary). The view type Database View must be selected when creating the view. The tables must be joined by identical fields in the join conditions. All of the key fields in the tables must be defined as view
fields, otherwise some data records may overlap, and the data will not be transferred to SAP Business Warehouse.
Characteristics can be ignored if you are certain that they are not used in the table keys.
The sequence of fields for defining a database view for extracting texts is fixed as follows:
● Language with the domain SPRAS, if the defined texts are language dependent.
● Key field: if compounding is used, all of the relevant characteristics have to be listed.
● If the data is time dependent, the DATETO and DATEFROM fields.
● Short, medium, and long texts If one of the text fields is not required, it must not be checked. If there is no medium length
text, the last two fields are the short text and long text fields.
Generic Extraction with InfoSet
SAP Query or InfoSet Query is a powerful tool for defining reports in SAP source systems and supports different forms of reporting. It allows users to define and execute their own reports on data in the SAP system without any knowledge of the ABAP.
Reports are structured by entering texts and selecting fields and options in SAP Query.
InfoSets are viewed as DataSources. These data sources can be used for extracting into SAP BW.
The process for creating an InfoSet from the DataSource definition is as follows:
1. Fill out all of the required entry fields (application component, descriptions).
2. Choose Extraction from Query .
3. Choose Save . A new screen is displayed.
4. Assign a name for your InfoSet and choose InfoSet Maintenance .
5. In the screen that follows, choose Create again.
6. Select the data source (DB tables/views, joins, logical DB).
7. Define the field groups and assign the fields.
When you create an InfoSet, a data source in an application system is selected. SAP Query is relevant for the Business Information Warehouse because it allows you to define the extract structure by selecting fields in a logical database, table join, or other datasets in the form of an InfoSet. In this way, you can use the generic data extraction function for master or transaction data from
any InfoSet. When you do so, a query is created for an InfoSet that retrieves data and transfers it to the generic extractor.
Generic Extraction with Function Module
A template is provided with which you can extract data with a function module. The data has
to be copied from the function module to an interface table, E_T_DATA.
Delta Process with Generic DataSources
In order to integrate a delta process with a generic DataSource, certain prerequisites need to be fulfilled. There must be a way of identifying the data records that have already been transferred to determine the delta.
To determine the delta, generic delta management converts the update mode into a selection criterion. The selections for the request are expanded by one interval for the delta-relevant field. The lower limit of the interval is known from the last extraction, the upper limit is
determined by the current value, for example, the time stamp at the time of extraction. You can use safety intervals to ensure that all the data is included in the extractions.
Safety Interval Limits
Safety Interval Upper Limit of a Delta Selection
It includes the gap between the current highest level at the time of the delta extraction and the data that was actually read.
For example: A time stamp is used to specify the delta. The time stamp that was last read was 12:00:00. The next delta extraction starts at 12:30:00. The selection interval is thus 12:00:00 to 12:30:00. At the end of the extraction, the counter is set to 12:30:00.
A record – such as a document – is created at 12:25 and saved at 12:35. It is not included in the extracted data, but is not extracted the next time due to its time stamp.
For this reason, the safety interval between read and transferred data should always be larger than the maximum time range that is needed to create a record for this DataSource (for time stamp delta), or should be a sufficiently large data interval (with delta specification using a sequential number).
Safety interval lower limit
The value in this field is the value that will be subtracted from the highest level of the last delta extraction to determine the lowest value of the time stamp or sequence number for the following delta extraction.
For example, if today you sent seq number 10 to BW, normally tomorrow you would start with Seq No 11 and never get numbers lower than 11 again. However if you put a value (let’s say 3) into this safety Interval lower limit the system would actually fetch records with a seq number of 8 or above. This means that you will get 8,9, and 10 twice. Therefore in the transformation, the key figures should be set to overwrite. With this type of data, a record can be extracted into SAP BW twice without causing problems.
As mentioned earlier, A safety interval should only be specified for the lower limit with the delta process new status for changed records (when the status in SAP BW is overwritten). In this case, duplicate data records, which can occur with such a safety interval, have no effect in SAP BW.