Delta Procedure for Master Data DataSources (CNS) 
This delta procedure uses the Change Notification Service (CNS) It enables the parallel extraction of large volumes of initial and delta data through bucket selection and an increased number of InfoPackaes. The following DataSources use the procedure:
DataSources that extract contract element data:
Composite DataSources
DataSources that Extract Contract Relationships:
The implementation of BCA_CN_BW_4_CNS BAdI definition BCA_CN_BW must be active.
You must have made the following settings in Customizing:
Settings for the Change Notification Service (CNS)
The application and recipient must be activated. Choose.
ViewV_TCNS_MAPP_CUST The assignment of the relevant export object types of the FSAM application to the recipient must be activated.
Settings for data transfer:
You must create object types for the extraction in views V_TBCA_CNS_BCT_C and V_TBCA_CNS_BCT_O.
You must assign contract part functions to the export object types in viewV_TBCA_CNS_EXP (assignment of BDT application BCLM to export object type00205 (contract element: limits, for example).
The following Custominzing settings already exist in the system delivered:
Settings for the Change Notification Service:
ViewV_TCNS_RECEIVER BI is defined as recipient for the changed data.
ViewV_TCNS_APPL The CNS application defined here FSAM is relevant for the extraction into BI.
ViewV_TCNS_MAPP_CUST Recipients are assigned to the relevant expport object types.
Settings for data transfer:
ViewV_TBCA_CNS_EXP
Contract part functions are assigned to the export object types (such as assignment of BDT application BCLM to export object type 00205 (contract element: limits))
Under you have assigned export object types and product categories to extractors.
Under you have defined the export mode for the extraction.
The system loads attributes for contracts. When you create contracts in Account Management (FS-AM)(accounts and cards) and inMaster Contract Management (FS-MCM) (master contracts), the system draws the internal keys for these contracts from the GUID intervall [0... 0, F.... F]. Before extraction you can define partial GUID intervals (buckets) from which the contract data can be extracted in parallel. The following selection parameters are important for this:
NOF_PACKAGES (NOF_BUCKETS): Number of selected GUID intervals
INTERVAL_NR (BUCKET_NO): Sequential number of the GUID interval
NOF_INTERVALS (NOF_BUCKETS_SUBS): Number of data packages that are extracted within the selected GUID interval (corresponds to the usual BI package size)
Parameters | IP1 | IP2 | IP3 | IP4 | IP5 |
NOF_BUCKETS | 5 | 5 | 5 | 5 | 5 |
BUCKET_NO | 1 | 2 | 3 | 4 | 5 |
NOF_BUCKETS_SUBS | 10 | 10 | 10 | 10 | 10 |
In the case of deltal initialization (mode C), the system reads the data for all contracts of the bucket selection from the database tables. In the case of delta extraction (mode or F), the system reads the changed data in accordance with the change pointers generated by the Change Notification Service.
Depending on the settings in IMG activity Define Snapshot Extraction, the DataSource can output the following time-dependent data:
The data valid (from a business perspective) at the time of the extraction (export mode Snapshot)
The entire history of the attributes that are assigned to the DataSource (from a database status perspective) at the time of the extraction (export mode History)
The entire history of the attributes that are assigned to the DataSource (from a database status perspective) at the time of the extraction (export mode History Repeated) If the validity begins in the future, the data is extracted repeatedly until the time of the validity has been reached.
Example
From today’s perspective, account contract 4711 had general ledger group HGR01 from 1901 –2203 and since 2004 has had general ledger group HGR02. The "future" general ledger group is already stored in the first period. The snapshot extraction run supplies the result (4711 HGR01) for 2002, and for 2004 the result (4711 HGR02). The history extraction run supplies {(4711; 1901-2003 ; HGR01) (4711 ; 2004-9999 ; HGR02)) as result in both years.
Processing the change pointers:
For a snapshopt extraction in 2002, the system sets the change pointer that refers to the general ledger change in 2004 to Processed (P). The system neither sets the change pointer to Extracted, nor deletes it at the time of extraction in 2002. This data record is transferred to the BI system in 2004.
For a history extraction, the system also sets the change pointer in question to Processed
For an extraction in the History Repeated mode in 2002, the system does not set the change pointer in question to Processed (P); the status of the change pointer remains Created (C). The system does not set it to Processed (P) until the extraction in 2004.
In the BI system, model as follows:
Model the data of a history extractor on a time-dependent basis, so that contract attributes that become valid in the future (from a business-related perspective) (valid-from date or valid-to date ) are also updated in BI
Model the data of a snapshot extractor on a non-time-dependent basis.
Note
Both for a history extraction and a snapshot extraction, before a new history or a new snapshot is updated, the old one must be deleted. To do this, create a corresponding update routine in BI.
If you wish to repeat a delta extraction because it was incorrect, for example, you need to reset the status of the change pointers so that BI can select the data again. Report RBCA_BCT_CNS_REQUEST_INIT (Reset Request Number and Status of Change Pointers) is available to you for this.
On the SAP Easy Access screen you can choose and display or delete the generated change pointers for each CNS application. For more information, see the documentation for the reports in the system.
For more information about migration, see Extraction of the Master Data During (CNS)