3. COMPOSITE PROVIDER :
OVERVIEW
COMPOSITEPROVIDER NOW PROVIDES THE
CENTRAL MEANS FOR JOINING DATA AND
PRESENTING IT TO THE REPORTING LAYER.
IT IS AN INFOPROVIDER THAT COMBINES DATA
FROM BW/4HANA INFOPROVIDERS AND
OBJECTS OF EXTERNAL SAP HANA SCHEMAS BY
JOIN OR UNION.
IT MAKES THIS DATA AVAILABLE FOR
REPORTING AND ANALYSIS AND FULLY
REPLACES MULTIPROVIDERS AND BW
INFOSETS OF THE PAST
6. COMPOSITE PROVIDER – FEATURES
SUPPORTED PROVIDERS
DEPENDING ON THE SQL ROOT OPERATION, YOU CAN INTEGRATE FOLLOWING INFOPROVIDER TYPES INTO A
COMPOSITEPROVIDER:
UNION:
ADSO, INFOOBJECT, AGGREGATION LEVEL, OPEN ODS VIEW, COMPOSITEPROVIDER, HANA CALCULATION VIEW
JOIN:
ADSO, INFOOBJECT, COMPOSITEPROVIDER, SAP HANA CALCULATION VIEW
JOIN AND UNION:
ADSO, INFOOBJECT, COMPOSITEPROVIDER, SAP HANA CALCULATION VIEW
THINGS TO CONSIDER:
ADSOS SHOULD HAVE PROPERTIES THAT ARE RELEVANT FOR REPORTING.
IN OTHER WORDS, THEY SHOULD HAVE ONE OF THE FOLLOWING COMBINATIONS OF PROPERTIES:
1. STANDARD DATASTORE OBJECT WITH CHANGE LOG
2. STAGING DATASTORE OBJECT, REPORTING ENABLED
3. DATA MART DATASTORE OBJECT
4. DIRECT UPDATE DATASTORE OBJECT
EXTERNAL SAP HANA VIEWS GENERATED FOR SAP BW INFOPROVIDERS ARE GENERALLY NOT AVAILABLE AS INPUT OBJECTS FOR
COMPOSITEPROVIDER
OPEN ODS VIEWS THAT YOU WANT TO USE IN COMPOSITEPROVIDER CAN ONLY CONTAIN FIELDS WITH INFOOBJECT-COMPATIBLE
DATA TYPES. THESE ARE THE FOLLOWING DATA TYPES: CHAR, CUKY, CURR, DEC, DATS, FLTP, INT4, NUMC, TIMS, QUAN, UNIT. DATA
TYPE STRG IS ALSO SUPPORTED FOR PARTICULARLY LONG CHARACTERISTIC-TYPE FIELD VALUES.
WHEN A FIELD IS ASSIGNED, THE SYSTEM CHECKS WHETHER THE TARGET FIELD IS SUITABLE FOR THE ASSIGNMENT BEING
PERFORMED. A TARGET FIELD IS SUITABLE IF IT HAS NOT ALREADY BEEN ASSIGNED TO ANOTHER FIELD IN THE SOURCE
STRUCTURE.
IN ADDITION, THE SYSTEM VERIFIES WHETHER IT HAS A COMPATIBLE DATA TYPE. REFER TO SAP NOTE 2228967
(UNDERSTANDING AUTOMATIC FIELD ASSIGNMENT IN THE COMPOSITE PROVIDER) FOR ALL DETAILS.
7. COMPOSITE PROVIDER – NESTING
SUPPORTED PROVIDERS
YOU CAN USE A COMPOSITEPROVIDER AS
PARTPROVIDER IN ANOTHER
COMPOSITEPROVIDER
HOWEVER, ONLY TWO LEVELS OF CONSUMPTION
ARE SUPPORTED BY SAP. THAT IS, A
COMPOSITEPROVIDER THAT CONSUMES
ANOTHER ONE CANNOT BE PART OF ANOTHER
COMPOSITEPROVIDER ON TOP.
TO ENABLE THIS CONSUMPTION, RELEASE THE
COMPOSITEPROVIDER FOR THIS FUNCTION
FIRST. IN THE GENERAL TAB OF THE
COMPOSITEPROVIDER MODELER UI, CHOOSE
THIS COMPOSITEPROVIDER CAN BE ADDED TO
ANOTHER COMPOSITEPROVIDER .
IN ADDITION, THERE ARE LIMITATIONS ON THE
SUPPORTED SCENARIOS IN TERMS OF SQL ROOT
OPERATION AND TYPE OF PART PROVIDERS., SAP
HANA CALCULATION VIEW
8. COMPOSITE PROVIDER – TEMPORAL JOINS
COMPOSITE PROVIDERS ALSO SUPPORT MODELING TEMPORAL JOINS TO DEPICT TIME FLOWS.
IN SAP BW/4HANA, ONLY MASTER DATA INFOOBJECTS CAN BE DEFINED AS A TIME-DEPENDENT DATA
SOURCE.
TWO ADDITIONAL FIELDS OR ATTRIBUTES, 0DATEFROM AND 0DATETO , ARE THEN ADDED TO THE
CHARACTERISTIC.
ADSOS HOWEVER, CANNOT BE DEFINED AS TIME-DEPENDENT.
NONETHELESS, THEY OFTEN CONTAIN TIME CHARACTERISTICS (FROM WHICH A TIME INTERVAL CAN BE
DERIVED) OR A MINIMUM OF TWO INFOOBJECTS THAT REFER TO 0DATE (WHICH YOU CAN USE TO DEFINE A
TIME INTERVAL FOR). THIS ALLOWS THE ADVANCED DSO IN THE COMPOSITEPROVIDER TO BE CONSIDERED
AS TIME-DEPENDENT.
AS SOON AS AN INFOPROVIDER THAT IS CONTAINED IN THE COMPOSITEPROVIDER IS MADE PSEUDO TIME
DEPENDENT, IT IS HANDLED AS A TIME-DEPENDENT DATA SOURCE.
AN IMPORTANT DIFFERENCE BETWEEN PSEUDO TIME-DEPENDENT INFOPROVIDERS AND TIME-DEPENDENT
INFOPROVIDERS LIKE INFOOBJECTS IS THAT THE SYSTEM CANNOT PREVENT GAPS OR OVERLAPS FROM
OCCURRING IN THE TIME STREAM. THIS ALWAYS DEPENDS ON THE DATA SET OF THE PSEUDO TIME-
DEPENDENT INFOPROVIDER.
9. COMPOSITE PROVIDER – TEMPORAL JOINS
THE FOLLOWING RESTRICTIONS APPLY FOR COMPOSITE PROVIDERS BASED ON TEMPORAL JOINS:
SUPPORTED SAP BW INFOPROVIDERS: INFOOBJECTS, ADSOS
NO UNION NODES ARE ALLOWED IN TEMPORAL JOINS.
THE RESULTING COMPOSITEPROVIDER CANNOT CONTAIN ANY FIELDS THAT ARE NOT ASSIGNED.
COMPOSITE PROVIDER – SOURCE OF TRANSFORMATIONS
JUST LIKE MULTIPROVIDERS IN THE PAST, THE NEW COMPOSITEPROVIDER CAN SERVE AS SOURCE FOR A
TRANSFORMATION AS WELL.
THIS MIGHT BE USEFUL FOR SPECIAL REQUIREMENTS, WHEN THE SQL JOIN/ UNION SHOULD BE PERSISTED IN
AN ADSO, FOR INSTANCE.
EXTRACTION OF TYPE FULL IS ALWAYS AVAILABLE.
A DELTA TYPE EXTRACTION IS AVAILABLE IF FOLLOWING CONDITIONS ARE MET:
1. THE COMPOSITE PROVIDER'S ROOT OPERATION IS UNION .
2. THE COMPOSITEPROVIDER CONSISTS OF ADSOS ONLY.
3. ALL ADSOS ARE OF TYPE DATA MART DATASTORE OBJECT (AND AS SUCH BEHAVE LIKE AN INFOCUBE).
10. COMPOSITE PROVIDER – WAYS TO ACTIVATE NAVIGATIONAL ATTRIBUTES
MODELING
NAVIGATION
ATTRIBUTES IN
THE COMPOSITE
PROVIDER
12. COMPOSITE PROVIDER – MAPPING FOR NAVIGATIONAL ATTRIBUTES
THERE IS A SLIGHT DIFFERENCE BETWEEN THE MULTIPROVIDERS OF THE PAST AND THE
COMPOSITEPROVIDER IN SAP BW/4HANA.
IN THE PAST, YOU COULD MODEL DIFFERENT SOURCES FOR NAVIGATION ATTRIBUTES, WHICH COULD BE
CONFUSING FOR OTHER USERS.
FOR EXAMPLE, CUSTOMER__COUNTRY COULD BE ASSIGNED TO ANY OTHER COUNTRY AVAILABLE IN THE
DATA MODEL AND IT WAS NOT GUARANTEED THAT THIS FIELD REALLY REPRESENTED THE COUNTRY
INFORMATION OF THE CUSTOMER OBJECT.
SAP HAS CHANGED THIS FOR THE COMPOSITEPROVIDER AND NO LONGER ALLOWS THESE ASYNCHRONOUS
MAPPINGS FOR NAVIGATION ATTRIBUTES.
NAVIGATION ATTRIBUTES ARE ONLY SWITCHED ON IN THE RELEVANT INFOOBJECT AND THEY ARE NO
LONGER AVAILABLE FOR MODELING DIFFERENT MAPPINGS.
13. CONSISTENT NAVIGATION ATTRIBUTE MAPPING IN A HCPR
IN CONTRAST TO A MULTIPROVIDER, THE BW SYSTEM DOES NOT ALLOW ALLKINDS OF NAVIGATION ATTRIBUTE MAPPINGS
ANY LONGER IN A HCPR:
IN A HCPR, IT IS ALWAYS ASSURED THAT NAVIGATION ATTRIBUTES ARE MAPPED CONSISTENTLY. THAT IS, THE NAVIGATION
ATTRIBUTE RELATIONSHIP TO THE MAIN CHARACTERISTIC(AS STORED IN THE MASTER DATA TABLES) IS ALWAYS KEPT IN THE
OUTPUT. INCONSISTENT NAVIGATION ATTRIBUTE MAPPING IS NOT ALLOWED.
SIMPLE EXAMPLE
IN A MULTIPROVIDER IT WAS POSSIBLE TO MAP A CHARACTERISTIC C
OF A PARTPROVIDER TO A NAVIGATION ATTRIBUTE A__C ON THE MULTIPROVIDER LEVEL.
IN THIS CASE, THE RELATIONSHIP BETWEEN A CHARACTERISTIC VALUE OF A
AND ITS NAVIGATION ATTRIBUTE C (STORED IN THE P OR Q MASTER DATA TABLES
OF THE CHARACTERISTIC A) IS NOT KEPT ANY LONGER. HENCE, A QUERY MIGHT
DISPLAY DIFFERENT ATTRIBUTES IN COMPARISON TO QUERIES WHERE THE RESULT IS
BASED ON THE CORRESPONDING MASTER DATA TABLES.
IN ADDITION, IN THIS CASE IT MIGHT HAPPEN THAT THE ASSIGNMENT FROM A TO C IS NOT UNIQUE ANY LONGER! THAT IS WHY
THIS KIND OF MAPPING IS NOT POSSIBLE WHEN CREATING AN HCPR.
WHEN A NAVIGATION ATTRIBUTE (A__C IN OUR EXAMPLE) IS ACTIVATED ON THE HCPR LEVEL, NO MAPPING IS
POSSIBLE/OFFERED SINCE THIS MEANS (AUTOMATICALLY) THAT THE MASTER DATA TABLES ARE JOINED WITH THE BASIS
CHARACTERISTIC IN ORDER TO GET THE ATTRIBUTE VALUES.
14. CONSISTENT NAVIGATION ATTRIBUTE MAPPING IN A HCPR
EXAMPLES OF CONSISTENT AND INCONSISTENT NAVIGATION ATTRIBUTE MAPPINGS
CHARACTERISTIC A HAS B AS REFERENCE CHARACTERISTIC. THAT IS, A AND B HAVE THE SAME MASTER DATA TABLES. E.G.:
0DEBITOR HAS 0CUSTOMER AS REFERENCE CHARACTERISTIC.
CHARACTERISTIC C HAS D AS REFERENCE CHARACTERISTIC.
HCPR IS UNION OF PARTPROVIDERS.
THE FOLLOWING MAPPINGS ARE CONSISTENT
EXAMPLE 1
PARTPROV HCPR
A ----------- A
B ----------- B
A__C ----------- A__C
B__C ----------- B__C
EXAMPLE 2
PARTPROV HCPR
A ----------- B
B ----------- A
A__C ----------- B__C
B__C ----------- A__C
THE RELATIONSHIP BETWEEN A AND A__C IS KEPT.
THE RELATIONSHIP BETWEEN B AND B__C IS KEPT.
15. CONSISTENT NAVIGATION ATTRIBUTE MAPPING IN A HCPR
EXAMPLES OF CONSISTENT AND INCONSISTENT NAVIGATION ATTRIBUTE MAPPINGS
THE FOLLOWING MAPPINGS ARE CONSISTENT
EXAMPLE 3
PARTPROV HCPR
A ----------- A
A__C ----------- C OR D
C OR D IS A 'STANDALONE' CHARACTERISTIC, THERE IS NO RELATIONSHIP BETWEEN A AND C/D IN THE OUTPUT.
THE FOLLOWING MAPPINGS ARE INCONSISTENT, THUS NOT POSSIBLE IN A HCPR
EXAMPLE 4
A ----------- A
B ----------- B
A__C ----------- B__C
B__C ----------- A__C
THE RELATIONSHIP BETWEEN A AND A__C IS BROKEN.
THE RELATIONSHIP BETWEEN B AND B__C IS BROKEN.
16. FIELD MAPPING IN HCPR (HANA COMPOSITE PROVIDER)
IN THE COMPOSITEPROVIDER SCENARIO EDITOR, THE USER CAN CREATE AND MODIFY ASSIGNMENTS BETWEEN THE FIELDS
(COLUMNS) OF A SOURCE STRUCTURE AND THE FIELDS (COLUMNS) OF A TARGET VIEW NODE. THE SOURCE STRUCTURE
CONTAINS THE FIELDS OF EITHER A PHYSICAL INFOPROVIDER OR OF ANOTHER VIEW NODE IN THE SAME COMPOSITEPROVIDER
MODEL. A TARGET NODE IN THE MAPPING CONTEXT IS ALWAYS A VIEW NODE. THIS IS EITHER THE OUTPUT (DEFAULT) NODE OR
ANY OTHER INTERMEDIATE VIEW NODE.
A COMPOSITEPROVIDER SUPPORTS TWO TYPES OF VIEW NODES: THE UNION TYPE AND THE JOIN (INNER, LEFT AND RIGHT
OUTER) TYPE.
THE OUTPUT VIEW NODE (DEFAULT NODE) IS A DEDICATED VIEW NODE IN THE SET OF ALL VIEW NODES IN A
COMPOSITEPROVIDER. THIS VIEW NODE DEFINES THE SEMANTICS OF THE COMPOSITEPROVIDER WHEN CONSUMED AS A
REPORTING VIEW. ONLY THE FIELDS IN THE OUTPUT NODE ARE VISIBLE FOR THE SAP BW/4HANA REPORTING TOOLS.
DURING MODELING OF THE COMPOSITEPROVIDER, THE FIELDS OF THE SOURCE STRUCTURES ARE MAPPED TO THE FINAL
TARGET STRUCTURE. DURING THE ASSIGNMENT, TWO ESSENTIAL THINGS HAPPEN.
FIRST, THE EDITOR TRIES TO IDENTIFY A POTENTIAL TARGET FIELD IN THE TARGET VIEW NODE STRUCTURE.
SECOND, IT CHECKS WHETHER THE CHOSEN TARGET FIELD IS SUITABLE FOR ASSIGNMENT.
AN EXISTING TARGET FIELD IS SUITABLE IF IT MEETS THE FOLLOWING CRITERIA:
IT IS NOT ALREADY ASSIGNED TO ANOTHER FIELD IN THE SAME SOURCE STRUCTURE THAT THE SOURCE FIELD COMES FROM.
IT HAS A BINARY-COMPATIBLE DATA TYPE.
IF NO SUITABLE EXISTING TARGET FIELD CAN BE FOUND, A NEW TARGET FIELD WITH APPROPRIATED INFOOBJECT TYPE AND
DATA TYPE IS CREATED, AND THEN ASSIGNED TO THE SOURCE FIELD.
A COMPLETED ASSIGNMENT IS DENOTED BY A SOLID LINE CONNECTING THE SOURCE FIELD ON THE LEFT SIDE TO THE TARGET
FIELD ON THE RIGHT SIDE.
DATA TYPE COMPATIBILITY IS ENSURED BY EVALUATING THE COMPATIBILITY RULES. FOR DETAILS REGARDING THESE RULES, SEE
SAP NOTE 2228967 (UNDERSTANDING AUTOMATIC FIELD ASSIGNMENT IN THE BW
17. COMPOSITE PROVIDER – SUPPORT FUNCTIONS
TRANSACTION RSOHCPR PROVIDES THE FOLLOWING BASIC TOOLS IN THE DATA WAREHOUSING WORKBENCH TO WORK WITH
COMPOSITEPROVIDER:
WHERE-USED LIST
OBJECT CATALOG ENTRY
TRANSPORT CONNECTION
DISPLAY DATA
DISPLAY METADATA
DISPLAY DATA MODEL
RECREATE COLUMNVIEW
IN OLDER BW VERSIONS, MULTIPROVIDERS PROVIDED THE INTERFACE TO REPORTS. NOW THEY ARE REPLACED WITH COMPOSITE
PROVIDERS. INFOSETS WERE RARELY USED DUE TO VERY SLOW PERFORMANCE. BUT COMPOSITE PROVIDER ALSO COVERS THE JOIN
FUNCTIONALITY AND THUS BOTH JOINS AND UNIONS CAN BE DONE ON THE FLY WITH COMPOSITE PROVIDERS.
IN SAP BW/4HANA, THE COMPOSITEPROVIDER ADDS VALUE TO YOUR ARCHITECTURE. A COMPOSITEPROVIDER COMBINES DATA
FROM SAP BW/4HANA INFOPROVIDERS WITH SAP HANA INFORMATION VIEWS BY JOIN AND UNION. THIS MAKES THIS DATA
AVAILABLE FOR REPORTING AND ANALYSIS
18. COMPOSITE PROVIDER – SUPPORT FUNCTIONS
COMPOSITE PROVIDERS:
VIRTUALIZATION OR PERSISTENT JOIN
19. DESIGN CONSIDERATIONS FOR COMPOSITE PROVIDER
NUMBER OF PARTPROVIDERS
FROM QUERY RUNTIME PERSPECTIVE, IT IS NOT RECOMMENDED TO BUILD A COMPOSITEPROVIDER WITH MANY
PARTPROVIDERS. EACH INVOLVED PARTPROVIDER INCREASES THE QUERY RUNTIME, EVEN IF NO DATA FROM THE PARTPROVIDER
IS REQUESTED, AS MORE PROCESSING FOR THE METADATA HANDLING IS NECESSARY. THEREFOR IT IS RECOMMENDED FROM
QUERY RUNTIME PERSPECTIVE TO CREATE A COMPOSITEPROVIDER, WHICH CONTAINS ONLY THE DATA, WHICH IS NECESSARY
FOR THE QUERY.
NULL VALUES
THE ABAP APPLICATION SERVER DOES NOT DISTINGUISH BETWEEN AN INITIAL VALUE AND A NULL VALUE.
NULL VALUES CAN OCCUR IN COMPOSITE PROVIDERS WITH LEFT OUTER JOIN OR IN COMPOSITE PROVIDERS THAT CONSUME
HANA MODELS. THE BW RUNTIME IS NOT AWARE OF THE SEMANTICS IN A HANA MODEL. THEREFORE IT MUST HANDLE A
COMPOSITEPROVIDER BASED ON A HANA MODEL IN THAT WAY THAT ALL COLUMNS MIGHT RETURN NULL VALUES.
SEVERAL RESTRICTIONS APPLY IF A COMPOSITEPROVIDER MIGHT RETURN NULL VALUES:
1. WHEN NULL VALUES CAN OCCUR FOR ONE INVOLVED INFOOBJECT, THE PUSHDOWN OF EXCEPTION AGGREGATION IS NOT
POSSIBLE ANYMORE.
2. SINCE BW HANDLES NULL VALUES AS INITIAL VALUES. THEREFORE A FILTER ON THE INITIAL VALUE IN BW
IMPLICITLY INCLUDES A FILTER ON NULL WHEN READING DATA FROM A SOURCE WHICH MAY RETURN NULL VALUES. DUE TO
THIS FACT ANY FILTER MUST BE ANALYZED TO DETERMINE IF IT CONTAINS THE INITIAL VALUE OR NOT.
3. FURTHERMORE IT IS NOT POSSIBLE TO PUSH DOWN ANY HIERARCHY FILTER IF NULL VALUES CAN OCCUR. THIS IS ALSO
THE CASE IF NO INFOOBJECT WITH NULL VALUES IS INVOLVED IN THE QUERY.
THE RESTRICTIONS MENTIONED ABOVE MAY HAVE AN IMPACT ON PERFORMANCE. THE DEGREE OF THE PERFORMANCE PENALTY
DEPENDS ON THE SCENARIO AND RANGES FROM NOT NOTICEABLE TO SIGNIFICANT.
20. DESIGN CONSIDERATIONS FOR COMPOSITE PROVIDER
NUMBER OF PARTPROVIDERS
TO AVOID NULL VALUE SPECIAL HANDLING IN CASE OF HANA MODELS IS TO GUARANTEE THAT MASTER DATA VALUES EXIST IN
BW FOR ANY TRANSACTIONAL RECORD RETURNED BY THE COMPOSITEPROVIDER. IN THAT CASE THE FLAG 'USER CONFIRMED
REFERENTIAL INTEGRITY' CAN – AND SHOULD – BE SET IN THE CHARACTERISTIC-SPECIFIC PROPERTIES FOR THE OUTPUT FIELDS
OF A COMPOSITEPROVIDER.
EXAMPLE:
PARTPROVIDER 1
PARTPROVIDER 2
Characteristic A Characteristic B Key Figure K
A1 B1 2
A2 B2 3
A3 B3 1
A4 B1 5
Characteristic A Characteristic B
A1 C1
A2
A3 C2
21. DESIGN CONSIDERATIONS FOR COMPOSITE PROVIDER
RESULT OF LEFT OUTER JOIN BETWEEN PARTPROVIDER 1 AND PARTPROVIDER 2 ON CHARACTERISTIC A
Characteristic A Characteristic B Characteristic C Key Figure K
A1 B1 C1 2
A2 B2 3
A3 B3 C2 1
A4 B1 Null 5
IN THE RESULT FOR CHARACTERISTIC C, THERE ARE FOUR DIFFERENT VALUES AFTER THE LEFT OUTER JOIN.
THE VALUES C1, C2, THE INITIAL VALUE AND THE NULL VALUE.
IN BW THE INITIAL VALUE AND THE NULL VALUE ARE THE SAME AND ONLY3 DIFFERENT VALUES ARE VISIBLE THERE.
22. DESIGN CONSIDERATIONS FOR COMPOSITE PROVIDER
USER CONFIRMED REFERENTIAL INTEGRITY
THE FLAG 'USER CONFIRMED REFERENTIAL INTEGRITY' ALLOWS THE COMPOSITEPROVIDER TO DO A JOIN TO THE MASTER DATA SID
TABLE – EVEN FOR PARTPROVIDERS THAT DO NOT STORE SID VALUES BUT KEYS. IN THAT CASE THE KEY COLUMN OF THE MASTER DATA
SID TABLE IS USED AS JOIN COLUMN. BY JOINING THE MASTER DATA SID TABLE IT IS POSSIBLE TO BENEFIT FROM SID-BASED PROCESSING
LIKE HANA PUSHDOWN OF EXCEPTION AGGREGATION.
THE FLAG 'USER CONFIRMED REFERENTIAL INTEGRITY' MUST ONLY BE SET IF MASTER DATA VALUES EXIST IN BW FOR ANY
TRANSACTIONAL RECORD RETURNED BY THE COMPOSITEPROVIDER. OTHERWISE THE RESULT SET OF A QUERY MIGHT BE FILTERED BY
THE EXISTING VALUES IN THE BW MASTER DATA TABLES.
THE FLAG 'USER CONFIRMED REFERENTIAL INTEGRITY' IS MAINLY INTENDED FOR HANA MODELS AS PARTPROVIDERS. FOR BW
INFOPROVIDERS USED IN COMPOSITEPROVIDERS IT CAN BE DERIVED FROM THE PROPERTIES OF THE INFOPROVIDER WHETHER
REFERENTIAL INTEGRITY IS GIVEN OR NOT – FOR EXAMPLE, CLASSIC DATASTORES WITH SID GENERATION DURING ACTIVATION ENSURE
REFERENTIAL INTEGRITY. IN THAT CASE IT IS NOT NECESSARY TO SET THE FLAG IN THE COMPOSITEPROVIDER.
CONFIRMING THE REFERENTIAL INTEGRITY IN A COMPOSITEPROVIDER WITH HANA MODEL MAY BE BENEFICIAL TO AVOID THE SPECIAL
HANDLING OF NULL VALUES AS DESCRIBED ABOVE. HOWEVER THE REFERENTIAL INTEGRITY IS ONLY CONSIDERED IF THE RELATED
PARTPROVIDER IS NOT CONNECTED WITH A LEFT OUTER JOIN IN THE COMPOSITEPROVIDER. IN OTHER WORDS THE SPECIAL HANDLING
OF NULL VALUES IS ALWAYS REQUIRED FOR PARTPROVIDER CONNECTED WITH A LEFT OUTER JOIN IN THE COMPOSITEPROVIDER.
CONFIRMING THE REFERENTIAL INTEGRITY MAY ALSO BE USEFUL IF SEVERAL SOURCE INFOOBJECTS ARE MAPPED TO THE SAME TARGET
FIELD AND THOSE SOURCE INFOOBJECTS HAVE DIFFERENT BASE CHARACTERISTICS. IN THIS CASE IT IS NOT CLEAR IF ANY OF THE MASTER
DATA SID TABLES CAN BE JOINED AND THEREFORE, NO MASTER DATA SID TABLE IS JOINED BY DEFAULT. BY ASSOCIATING AN INFOOBJECT
TO THE TARGET AND CONFIRMING THE REFERENTIAL INTEGRITY, IT IS AGAIN POSSIBLE TO USE A JOIN TO THE MASTER DATA SID TABLE OF
THE ASSOCIATED INFOOBJECT. THE REFERENTIAL INTEGRITY MUST ONLY BE CONFIRMED IF THE ASSOCIATED INFOOBJECT CONTAINS
MASTER DATA RECORDS FOR ANY VALUE THAT MIGHT BE RETURNED BY THE DIFFERENT SOURCE INFOOBJECTS.
IF THE REFERENTIAL INTEGRITY IS CONFIRMED FOR THE INFOOBJECTS BASED ON HANA MODEL IT IS AUTOMATICALLY CONFIRMED FOR
THE NAVIGATION ATTRIBUTES.
23. CONVERSION OPTION FROM MULTIPROVIDERS TO COMPOSITEPROVIDERS ON SAP BW 7.4/.7.5 ON HANA
IN AN SAP BW ON HANA
ENVIRONMENT, YOU CAN CREATE A
COMPOSITEPROVIDER BASED ON A
MULTIPROVIDER OR BW INFOSET.
SINCE BW 7.40, SP10, REPORT
RSO_CONVERT_IPRO_TO_HCPR
ENABLES THIS.
FOR INSTANCE, YOU CAN LEVERAGE
THIS TOOL TO PREPARE A
CONVERSION TO SAP BW/4HANA.
THIS TOOL IS DELIVERED AND
FULLY DOCUMENTED IN SAP NOTE
2080851.
24. CONVERSION OPTION FROM MULTIPROVIDERS TO COMPOSITEPROVIDERS ON SAP BW 7.4/.7.5 ON HANA
THE FOLLOWING ACTIONS ARE POSSIBLE:
CONVERSION OF A MULTIPROVIDER TO A COMPOSITEPROVIDER.
CONVERSION OF A MULTIPROVIDER TO A COMPOSITEPROVIDER WITH THE SAME NAME
COPYING OF QUERIES TO THE NEW COMPOSITEPROVIDER, CONSIDERING THE INFOOBJECT MAPPING.
TRANSFER OF QUERIES TO THE NEW COMPOSITEPROVIDER, KEEPING THEIR NAMES (REQUIRES SAP BW 7.5).
CONVERSION OF AN OLD COMPOSITEPROVIDER TO A NEW COMPOSITEPROVIDER
CREATION OF A BACKUP FOR A MULTIPROVIDER.
RECOVERY OF A MULTIPROVIDER FROM THE BACKUP.
DELETION OF THE BACKUP (REQUIRES SAP BW 7.5)
SUMMARY
THE ROLE OF THE COMPOSITEPROVIDER IS TO PROVIDE A METADATA OBJECT THAT FORMS THE DATA MART LAYER WITHIN SAP
BW/4HANA.
IT PROVIDES THE DATA FOR REPORTING AND ANALYSIS IN THE FORM OF AN OUTBOUND STRUCTURE THAT IS SEMANTICALLY RICH.
IT MAKES THE UNDERLYING SAP BW/4HANA OBJECTS ABSTRACT AND PROVIDES AN OUTBOUND INTERFACE THAT CAN BE CONSUMED BY
ANY KIND OF QUERY BY OFFERING THE OPTION TO GENERATE AN SAP HANA VIEW.
THEREFORE, SAP BW QUERIES SHOULD ALWAYS BE DEFINED ON THE NEW COMPOSITEPROVIDER ONLY, BECAUSE THIS OPTION OFFERS YOU
GREATEST FLEXIBILITY TO REACT TO CHANGES IN YOUR REPORTING REQUIREMENTS.
