In addition of one of my previous blogs I adjusted the function module RSZ_I_BASIC_KEYFIG_WHERE_USED and saved it to a new version.
The problem with the standard function module is that is requires to fill in a MultiProvider or CompositeProvider in order to get a result set.
Because I had the requirement to get a complete overview without any restrictions I used and changed the ABAP code. The new function module will only ask for a InfoObject name and will show you a list of all relevant queries.
Tags: function module
Delete overlapping requests DataStore Object using ABAP
Do you want to snapshot on a daily basis but only want to keep one request per calendar week? The attached ABAP makes this possible! You can use it the start routine of a transformation.
The logic uses the current calendar week (based on the system date) to retrieve a list of requests which are loaded in the same calendar week. This list is then sorted descending based on the loading date. Then one by one the loads are being removed from the DataStore Object (DSO), leaving only the current request active. When this load is executed on a daily basis only one request per calendar week will remain in the DSO.
Quickly find queries which use specific InfoObjects
When it comes to deleting InfoObjects from SAP BW it is necessary that these are not used anymore by other objects in the system. The standard where-used functionality could supply sufficient insight. However the standard where-used functionality is not always accurate when a person wants to know in which SAP BW queries an InfoObject is used. For this specific case you have the ability to use one of the following two function modules.
| Technical name | Type |
|---|---|
| RSZ_I_BASIC_CHA_WHERE_USED | Characteristics |
| RSZ_I_BASIC_KEYFIG_WHERE_USED | Key figures |
By filling in the right parameters the function module delivers a table of queries using the specified characteristic or key figure.
Execute process chain with function module
For today just a handy trick: instead of executing a process chain by adjusting the starter and rescheduling it, use function module RSPC_API_START_CHAIN in transaction SE37. In this way you do not have to reschedule the process chain after it has finished loading.
ECC source systems appearing in BI folder
Today a colleague noticed that our ECC systems appeared not under the SAP folder, but under the BI folder. This is strange, since ECC is not a BI system. In order to fix this SAP has publishes (of course) an SAP note. (1087980).
This note describes the following steps in order to fix this issue:
| Step | Action |
|---|---|
| 1. | Check that an entry with SRCTYPE ‘M’ exists in table RSBASIDOC table of ECC source system. |
| 2. | Note the values for SLOGSYS and RLOGSYS. It should be same. |
| 3. | Run the function module RSAP_BIW_DISCONNECT in the ECC system. NOTE: Never run that function module in a BI system! |
| 4. | Enter the following values: I_BIW_LOGSYS <RLOGSYS> as noted in step 2 I_OLTP_LOGSYS <SLOGSYS> as noted in step 2 I_FORCE_DELETE <X> DO NOT ENTER ANY VALUE IN THE FIELD – RFC target sys !!!!! |
| 5. | Go to RSA1-> Source systems. |
| 6. | Select the ECC source system and select RESTORE in the right click menu. |
After step 6 has been performed be sure to reactivate all of your transfer structures. If you do not do this the system will not appear under the SAP folder. After you have done this the ECC system should appear in the SAP folder.
