Hi ANR,
Hope the following might help you in resolving errors.
Read "How to … Schedule Query Extracts using RSCRM_BAPI" for a general overview about the RSCRM_BAPI.
Check OSS 605208 which describes RSCRM_BAPI restrictions .
The number of packets defined is global and not per query. This has change in BW3.0B SP14. It's now local and can be set on the extract dialog right under the chosen characteristic.
Texts are not extracted into a file or a table.
The extracted data of characteristics is in internal format.
For key figures country settings and special format settings of the query or key-figures InfoObjects are ignored. The value is absolute and not shifted as it's internally used on BW for currencies which have more or less than 2 decimals. That means for table extract that the value is rounded to 2 decimals. For file extracts more decimals are written if available.
The extracted values are not compounded.
The total and the subtotals are not extracted.
Queries on InfoSets and InfoObjects are not yet supported even though this has been documented in the HowTo paper.
The extracted currency keys are in ISO code format.
The extracted units are in SAP internal format.
The OLAP processor delivers the RSCRM the SAP currency code. The RSCRM has to convert this code to the ISO code. Therefore the table TCURC has to be maintained correctly. If an ISO code appears several time in the ISOCD column, exactly one line should have set the XPRIMARY flag to 'X' for this ISO code. Otherwise a warning is thrown. But it should work also with this warning. The warning is just annoying.
There are only 16 characteristics allowed for table extract because of the restriction of only 16 key fields of a transparent table. That the characteristics are used as keys is necessary for the update functionality. So new key figure values for a certain combination of characteristics automatically overwrite the old entry.
In general ODBO only allows 20 characteristics (more might be possible with BW3.x and higher) . With each characteritic the dimension of the result increases by 1. So for very usual queries this should be OK. With high dimension the complexity increases and the performance will slow down considerably.
Variables of type SelectOption must only be used with option EQ, NE and BT, even the VariablePopup offers also GT, GE, LT and LE. The later ones will not work.
Display hierarchies are not supported. If you use them you might get some result but the correctness is not guaranteed. This is because of the fact that nodes which are of a different type than the hierarchy make it difficult to write the data to tables. This doesn't affect variables on hierarchy nodes.
Variables in exceptions are displayed in the VariablePopup but are ignored because exceptions are not supported.
Variables in conditions are currently not supported.
Variables in calculated key figures should work.
Variables must not be 'dynamicaly changeable', otherwise they might be ignored. It might be possible the error RSCRM018 is raised.
Variables should not have a default value. It will be applied even it's deleted in the popup. (might be changed in futur)
If you select a variable value in the popup for a compound characteristic only the last part of the compound will be considered. You will have to create and use a separate variable on the first part(s)of the compound. E.G. 0REGION, which is compounded to 0COUNTRY. For region 'US IDA' you have to create a variable value for 0REGION 'IDA' and a separate value for 0COUNTRY 'US'. The impression of the variable popup that you select 'US IDA' for 0REGION is wrong. Only the last part ('IDA') is considered. If there's another country with region 'IDA' it would be present in the result too.
Same goes for hard filters on compound characteristics set in the query designer. Even the text specifies a certain 0REGION only the last part is considered. So a separate hard filter for the requested country is requirred.
The above two issues lead too a further issue. If you request the two regions 'AU 1' and 'DE 2' applying 'AU' and 'DE' on 0COUNTRY and '1' and'2' on 0REGION you also will get 'AU 2' and 'DE 1'. This can't be avoided.
Extracts with RSCRM require the creation of a structure in the DDIC. Some customers have set the used namespace /BIC/ to not changeable which causes an error in the RSCRM. The current workaround is to ignore this prohibition with note 526173. We will check if we can avoid the creation of the structure, but we think this will not be possible without reworking almost everything within the RSCRM.
The DDIC structure and the transparent tables are created in the $TMP development class. That means it can't be transported. The whole meta data of the extract is also not connected to the transport system. This would additionally prevent a rerun of the extrakt in the target system.
For setting the type of the structure fields we use the data element of the InfoObject. This means for calculated and restricted key figures that we use the data element of one of the involved key figures. If that key figure is involved in two or more complex key figures the corresponding fields/columns will have the same description as it's automatically taken over from the data element.
UniCode is currently not supported. Please also have a look at the generals notes 588480 and 79991
Important: If you use compounded characteristics (eg 0REGION), all characteristics of the compound (0COUNTRY) have to be active too. Reason is that we deliver only uncompounded values which are not aggregate if they match by chance. So you get 2 or more entries in a file or just the last of them in the table.
The RSCRM interface is not yet tested with virtual InfoObjects and virtual InfoProviders. So please don't use them with the RSCRM as problem might occur.
Filter values provided should be values available in the InfoProvider. Filter values like "contains pattern" cannot be used.
Only internal format is returned for the key-figures. The system settings are not considered. Example: the decimal symbol could be , or . in the system settings. This is not considered. The value returned is in the format stored in BW.
RSCRM uses the ODBO interface. This interface has a restriction of 20 dimensions. ( Characteristis and structure used in the query are considered as dimensions ).
The ODBO interface has problems with special characters in key values. So don't allow any extra characters in TA RSKC.
Certain settings like "Suppression of Zeros" set in BEX are ignored.
The units and currencies for the formulas or calculated key figures are not extracted.
Conditions on key figures of the 2nd structure are not supported.
Using only the 2nd structure and putting a basic key figure on the filter area is not supported.
General Troubleshooting
If you modify the query or you do changes on the infoprovider or infoobjects it might be possible that the meta data of the query gets inconsistent. Than the query needs to get regenerated. Therefore go to TA RSRT and fill in the Queryname. Note: the RSCRM puts an own prefix (generally I_, but also N_ and S_ are possible) before the name of the query. This prefix has to be removed. After that press the 'generate report' button in the tool bar and restart RSCRM_BAPI.
If the data in the infoprovider is inconsistent it might cause that BEx and RSCRM/ODBO return different results. To check inconsistencies use TA RSRV. Possible inconsistencies are e.g. SID with no master data and vice versa.
There might be problems if you just upgraded from BW2.xx to BW3.xx. Sympton is that some SQL statements refere to tables /BIC/V<Infocube>F which don't exist. Please read more about the solution in note 499820.
Vijay
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.