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.
Normally when monitoring process chains I used to execute the transaction code RSPCM. The overview which this t-code generates does not always show the most accurate information regarding the state of the process chains.
Many organisations have therefore implemented the program /SSA/BWT. Sometimes this program is assigned transaction code ZMONITOR. This program, which can also be executed via SE38, has various options available.
The first option, process chain analysis, lets you analyse all the scheduled and nonscheduled process chains in BW. In order to do this, execute the program in SE38, fill in the variables (if applicable) and hit F8. You also have the possibility to filter out certain statuses immediately. Once executed it will display an overview as shown below.
One of the great features of using this program, is the ability to compare the runtimes . This can be done easily by requesting a larger timeframe for a given process chain and sorting the result based on the columns CHAIN, Day Date and Time.
A BW blog without mentioning some of SAP’s most important tables is useless. These tables can be quite handy when analyzing issues or coding ABAP. Use the read more button to view the complete list, or download the attachment.
At one of my projects most of the end-users are still used to the old 3.x Bex Analyzer. Whereas the 3.x version works primarily with workbooks the new 7.x analyzer one is able to open queries as well. When a query is opened in the new 7.x Analyzer a standard template is being used to display the data. This template, supplied by SAP, contains alot of custom visual basic code to make interaction in the report possible (like showing a graph). This custom Visual Basic code raises a lot of performance issues, especially when users are working on a Citrix environment.
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:
|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.