1. BEx query discontinued features:-
If we run the program SAP_QUERY_CHECKER_740 and we will get all the queries which are not supporting in BW 7.4 version.
Run the report SAP_QUERY_CHECKER_740. Better to Run it in background as it might run very long. The spool output shows the queries that will not run correctly in 740 any longer. We will get output somewhat like this…
The following features are discontinued in 740:
- Constant Selection with Append (CSA) is no longer supported and cannot be modeled any longer in the 700 BEX Query Designers. Some business scenarios use the feature to model an outer join.
- The business requirement can be met by modelling an Info set. Using an Info Set is highly recommended, especially if a selection condition that was evaluated via virtual Info Objects in the CSA approach, can be directly handed down to the SQL statement.
- In a BW Info Set, the join operation LEFT OUTER JOIN was not permitted up to now with a BW Info Cube. The reason is that, in this case, SQL statements with poor performance may be created.
- Formulas before Aggregation are no longer supported. The report SAP_QUERY_CHECKER_740 analyzes both, the calculated Key figure definitions, and the query definitions that use the calculated key figures.
Exception Aggregation can be defined for a basic key figure, calculated key figures and formulas in the Query Designer. It determines how the key figure is aggregated in the query in relation to the ‘exception’ characteristic. There is always only one Reference Characteristic for a certain Exception Aggregation.
If we use Exception Aggregation, the following two points are important to know:
The Reference Characteristic is added to the ‘Drilldown Characteristics’ and aggregation is carried out by the OLAP processor for these ‘Drilldown Characteristics’.
The Exception Aggregation is always carried out last after all other necessary aggregations.
- If the calculation operation commutates with the aggregation, the flag “calculation after aggregation” can be set. The option ‘Calculate before Aggregation’ are obsolete now and shouldn’t be used any longer. Calculating before aggregation results in poor performance because the database reads the data at the most detailed level and the formula is calculated for every record.
- Aggregation and calculation occurs at different points in time. By default, the data is first aggregated to the display level and afterwards the formulas are calculated.
The Exception Aggregation setting allows the formula to be calculated before aggregation over a chosen Reference Characteristic. The remaining aggregation is then executed using the defined Exception Aggregation for example ‘average’ or ‘ last value’.
Calculate after Aggregation: This field is only displayed for Calculated Key Figures; it is not displayed for formulas.
If the operation has to be calculated on a certain granularity, use formula exception aggregation to specify the granularity on which the formula is calculated.
Thereby, you can create Calculated Key Figures by using a formula that uses exception aggregation itself (this is a nested exception aggregation).
2. Call Function not found post Upgrade:-
Process chain steps loading hierarchies will failed. After upgrading to 740, when we load hierarchies using info packages, the loads fail when the info object doesn’t have a conversion exit defined. This is due to a Program error.
To resolve the issues we need to implement a SAP note 1912874 – CALL_FUNCTION_NOT_FOUND.
On further Analysing.it is showing ABAP dumps.
Activation of SICF services in BW:-
During Upgrade, The Software Update Manager disables services of the Internet Communication Framework (ICF) for security reasons. Post upgrade SAP BW 7.4; Internet Communication Framework (ICF) services will be inactivated due to security reasons. The services needs to be activated on application-related basis only, and it can be done manually (Right click then Activate), They can be done manually by following the URL given in the error screen through transaction SICF.
In SICF Tcode…You can get most of the services needs to be activated post BW 7.4 upgrade under default host/sap/public and the tree will open.
If, for example, you want to activate services for the /SAP/public/icman URL, you have to activate the “default host” service tree in transaction SICF. After that, you must activate the individual “sap”, “public”, and “icman” services.
You can activate an ICF service as follows:
1. Select the ICF service in the ICF tree in transaction SICF.
2. You can then activate the service in one of the following ways:
a) Choose “Service/Virt. Host” -> “Activate” from the menu.
b) Right-click to open the context menu and choose “Activate service”.
If the “default host” node is inactive in transaction SICF, the HTTP request produces a “RAISE_EXCEPTION” ABAP runtime error stating that the HOST_INACTIVE exception condition was triggered. If a service is inactive in the SICF transaction, the error text “Forbidden” is displayed when you access this service.
Some services that must be activate in the system . Depending on the operational scenario:
Support for the Internet protocol (HTTP, HTTPS and SMTP) in the SAP Web Application Server /default_host /sap/public/ icman.
After you have installed SAP Web Application Server, you must ensure that this service is activated in transaction SICF.
We are going to face the issues in Metadata Repository, Maintain Master data etc. For this we need to active the services in BW. For example
Post upgrade BW 7.4:-
Post upgrade we will find a lot of services which will be in inactive state .we need to activate them.
In case of Metadata Repository we need to activate the services.
Some of the important services need to be activated as part of Post upgrade Checks.
With the message server
With the Web Dispatcher
Using Business Server Pages (BSP)
If we are using the reporting authorizations concept and upgraded to SAP Net Weaver 7.3, We have to migrate these authorizations to the new Analysis authorization concept or redefine authorizations from scratch.
In SAP BW 7.3 Analysis Authorization is optional because the Reporting authorization will also work. But in 7.4 there is no Reporting authorization .Analysis authorization is mandatory. All the BW roles should be migrated to Analysis authorization.
The authorization objects S_RS_ICUBE, S_RS_MPRO, S_RS_ISET and S_RS_ODSO were checked during reporting authorization But this objects will no longer be checked during query processing in BW 7.4. Instead, the check is performed using special characteristics 0TCAIPROV (Authorizations for Info Provider), 0TCAACTVT (Activity in Analysis Authorizations) and 0TCAVALID (Validity of an Authorization). These are standard info Objects in BW.
These authorization objects are offered during migration configuration as a migration option. If you select these authorization objects, authorization for these special characteristics are generated according to the entries in the Activity and the associated field for the corresponding Info Provider and then assigned to the users.
By this Authorization we will not able to access any queries output. It will be showing You Don’t have sufficient Authorization for the Info provider.Until unless we will be adding 0BI_ALL object,We cannt access any query output . But it will not be given to any user as per Security.So we need to implement Analysis Authorization to get the output of the queries.
The info object which are Authorization relevant:
When we check Authorization Value Status table, In Older Version we have 0BI_ALL Authorization in Name of an Authorization Field.
But in SAP BW 7.4 upgraded Version We have.
0BI_All: Assign all Analysis Authorizations to a user. Which are equivalent to SAP_All in BI. It can be assigned directly via RSU01.
We can check (Characteristic Catalog) Table RSDCHA about the info object which are checked as Authorization Relevant.Whenever these info object are called in query output.User will not get the output if he is not authorized.
The Custom Authorization objects can be created and assigned to users.
Exceptions are validity (0TCAVALID), Info Provider (0INFOPROV) and Activity (0TCAACTVT), which cannot be removed and always have to be authorization relevant.
Some of the Authorization issues faced after upgrade is with Semantic Partition and Writing ABAP Routines.
The available role with users should be modified with the object S_RS_LPOA to give required access. This is the Authorization object for working with semantically partitioned objects and their sub objects.
In case of writing Routines we will not Authorized.
Authorization Objects for Working with Data Warehousing Workbench
We should have the authorization for authorization object ABAP Workbench (S_DEVELOP) with the following field assignment:
- DEVCLASS: You can choose from the following program classes, depending on the routine type:
- “BWROUT_UPDR”: Routines for update rules
- “BWROUT_ISTS”: Routines for transfer rules
- “BWROUT_IOBJ”: Routines for Info Objects
- “BWROUT_TRFN”: Routines for transformations
- “BWROUT_ISIP”: Routines for Info Packages
- “BWROUT_DTPA”: Routines for DTPs
- OBJTYPE: “PROG”
- OBJNAME: “GP*”
- P_GROUP: “$BWROUT”
- ACTIVITY: “23”