Saturday, September 17, 2016

SAP BW Issues

Home

Connection:

1) When attempting to connect to an SAP BW data source, Tableau displays an “SAP client version x is not supported” error message.

To resolve this issue, ensure that you are using SAP 7.20 or later GUI for Windows. SAP 7.10 GUI and earlier are no longer supported by SAP. Refer to the SAP Support Matrix for more information.


2) Your SAP Logon connections either do not display or display the incorrect connections in the drop-down list of the SAP NetWeaver Business Warehouse Connection dialog box.

This issue can occur when Tableau is unable to determine the correct location of the saplogon.ini file. To resolve this issue, add or verify a system environment variable on the machine running Tableau called SAPLOGON_INI_FILE that points to the correct location of the file. Alternatively, you can copy the saplogon.ini file to the C:\Windows directory.

After entering your credentials to connect to SAP BW, you see an error message like the

example below:



Ensure that you are using the correct Client ID, username, and password. To verify your information is correct, try connecting to SAP BW from another tool such as BEx Analyzer or the SAP Logon GUI. If this issue continues to occur, talk to your SAP administrator.


3) Despite having the correct information in the SAP NetWeaver Business Warehouse Connection dialog box, you must click the Connect button a second time to connect to SAP BW.

To resolve this issue so that you only have to click the Connect button once, add a system environment variable on the machine running Tableau called SAPLOGON_INI_FILE. This environment variable must point to the location of the saplogon.ini file, which is typically found at: C:\Users\<USERNAME>\AppData\Roaming\SAP\Common\saplogon.ini.

When sharing a workbook with another user or publishing a workbook to Tableau Server, you receive an error about an invalid username or password when connecting to the SAP BW server.

This situation can occur when the SAP Logon connection name is different between the two machines. In this case, you will need to edit the connection properties to specify the correct SAP Logon connection defined on the other machine.


4) The workbook you just published to Tableau Server does not load, and instead displays a spinner in the Publish Workbook Results or browser window.

This issue can occur if the Tableau Server Run As User account is not the account that was used to establish the initial SAP connection from the SAP Logon application on the Tableau Server machine. To resolve this issue, log in to the Tableau Server machine using the Run As User account that Tableau Server uses to run its services, and connect to SAP BW using the SAP Logon application. Validate that the connection is successfully, and republish the workbook.


5) When trying to connect to SAP BW, you have selected InfoProvider from Step 4 of the SAP NetWeaver Business Warehouse Connection dialog box, but then you are unable to select or find a BEx Query in Step 5.

To resolve this issue, ensure that the BEx Query has the check box “Allow External Access to this Query” selected in the Properties tab of the Query Designer. Additionally, also verify the Query does not have a mandatory variable defined in it. Tableau does not support Queries with mandatory variables. You can also refer to this forum post on the Simba website to help resolve your issue.


6) You want to connect to a MultiProvider or ODS object, but are unable find it when connecting to SAP BW from Tableau.

Tableau supports connections to a BEx Query or InfoCube. To connect to another object such as a MultiProvider or an ODS object, you must first create a BEx Query on it, and then connect to the BEx Query. Ensure that the check the box “Allow External Access to this Query” in the Properties tab in the BEx Query Designer application.


7) In some of your analyses, you may notice that certain dimension hierarchies have a value called “Not Assigned” on Level 0 of a hierarchy, with the other values not appearing until the bottom level.

This issue occurs when there are characteristic values that do not appear in a hierarchy. By default, a Not Assigned node is added to the hierarchy. For example, suppose there are 1000 characteristic values for the characteristic “Material”. A hierarchy with material groups from a total of 100 materials is defined for it. The remaining 900 (1000-100) characteristic values, are positioned under node Not Assigned. This is a data modeling issue that you should work with your SAP BW administrator to resolve.

When attempting to use a dimension hierarchy, you may see an error message similar to the
example below:



To resolve this issue, ensure that all the special SAP business content, such as date hierarchies, have been activated properly and characteristics have been assigned to the proper hierarchies. If you continue to see this error message, you may have a data modeling issue that you should work with your SAP administrator to resolve.

Performance
If your Query performance is poor, some contributing factors may include the following:

The size and power of the hardware supporting the BW instance is insufficient.
The system is not well-tuned. For example, the right indexes are not defined.
The data model is not optimal. For example, are you connecting to a very large InfoCube with 100+ million records, or a smaller object?
There other operations happening on the system. For example, are there frequent data loads/refreshes happening?
Is your company leveraging the BW Accelerator or SAP HANA? Those products are known to significantly improve system performance.
The performance you experience in Tableau should not be significantly different from other tools. Tableau recommends working with your SAP BW administrator to identify potential improvements that can be made to benefit your overall experience.


Other Tips

Tableau suggests the following tasks that may help you narrow down the sources of the issue you may be experiencing:

For additional troubleshooting tips, you may need to narrow down the sources of the issue.

Tableau communicates with the SAP BW server using the MDX query language through the OLE DB for OLAP provider. The MDX queries that Tableau submits are logged in a file called log.txt, usually located in the Tableau Logs folder. By default, this folder is located in C:\Users\<user_name>\Documents\My Tableau Repository.
While connected, if Tableau receives an error message back from the SAP BW server, it will also be logged in the log file.
If you experience issues that are not covered in this article, consider a few tools listed below that may be useful to help you and your SAP administrator isolate the cause of any errors or issues.
Use transaction MDXTEST.

The MDXTEST transaction is a useful tool for debugging MDX issues, syntax errors, server errors, and performance concerns. Since the transaction runs natively
in SAP BW, this helps narrow the source of the problem to the SAP BW server because it removes Tableau and the OLE DB for OLAP provider out of the equation.
If you notice an error in the Tableau log file for a particular MDX query, or would like to test the performance of an MDX query that appears slow,
 or validate the output of an MDX query issued from Tableau, you can copy and paste it from the Tableau log file into the
MDXTEST transaction and determine if the SAP BW server is the source of the issue.



Reproduce the issue in a different tool.

Sometimes it is useful to see if the issue also occurs using another tool, such as BEx Analyzer. Using another tool like BEx Analyzer helps eliminate Tableau or the OLE DB for OLAP provider as the source of the problem. If you need to investigate issues such as determining if accessing a particular InfoProvider is slow or understanding an error message you receive when attempting to use a BEx Query, you may consider reproducing the issue in another tool to help narrow down the source of the issue.

Reproduce the issue in another tool that uses the OLE DB for OLAP provider.

If you believe you have eliminated the SAP BW server as the source of an issue, you can try to reproduce it in another tool that uses the OLE DB for OLAP provider. This can help further narrow down the issue to the OLE DB for OLAP provider or to Tableau. .

BW Issues:

1. DTP Failure

Select the step-> right click and select “Display Message”-> there we will get the message which gives the reason for ABEND.

A DTP can failure due to following reasons, in such case we can go for restarting the job.
  • System Exception Error
  • Request Locked
  • ABAP Run time error.
  • Duplicate records
  • Erroneous Records from PSA.
Duplicate records:
            In case of duplication in the records, we can find it in the error message along with the Info Provider’s name. Before restarting the job after deleting the bad DTP request, we have to handle the duplicate records. Go to the info provider -> DTP step -> Update tab -> check handle duplicate records -> activate -> Execute DTP. After successful competition of the job uncheck the Handle Duplicate records option and activate.

DTP Log Run:

  • If a DTP is taking log time than the regular run time without having the back ground job, then we have to turn the status of the DTP into Red and then delete the DTP bad request (If any), repeat the step or restart the job.

  • Before restarting the Job/ repeating the DTP step, make sure about the reason for failure.
  • If the failure is due to “Space Issue” in the F fact table, engage the DBA team and also BASIS team and explain them the issue. Table size needs to be increased before performing any action in BW. It’ll be done by DBA Team. After increasing the space in the F fact table we can restart the job.
  
  
Erroneous Records from PSA:
  
     When ever a DTP fails because of erroneous records while fetching the data from PSA to Data Target, in such cases data needs to be changed in the ECC. If it is not possible, then after getting the approval from the business, we can edit the Erroneous records in PSA and then we have to run the DTP.

Go to PSA -> select request -> select error records -> edit the records and save.
Then run the DTP.
  
2.      INFO PACKAGE FAILURE:
  
The following are the reasons for Info Pack failure.
  • Source System Connection failure
  • tRFC/IDOC failure
  • Communication Issues
  • Processing the IDOC Manually in BI

  • Check the source system connection with the help of SAP BASIS, if it is not fine ask them to rebuild the connection. After that restart the job (Info Pack).
Go to RSA1 -> select source system -> System -> Connection check.

  • In case of any failed tRFC’s/IDOC’s, the error message will be like “Error in writing the partition number DP2” or “Caller 01, 02 errors”. In such case reprocess the tRFC/IDOC with the help of SAP BASIS, and then job will finish successfully.
   
  • If the data is loading from the source system to DSO directly, then delete the bad request in the PSA table, then restart the job

  • Info Pack Long Run: If an info pack is running long, then check whether the job is finished at source system or not. If it is finished, then check whether any tRFC/IDOC struck/Failed with the help of SAP BASIS. Even after reprocessing the tRFC, if the job is in yellow status then turn the status into “Red”. Now restart / repeat the step. After completion of the job force complete.

  • Before turning the status to Red/Green, make sure whether the load is of Full/Delta and also the time stamp is properly verified.

  • Time Stamp Verification:

Select Info Package-> Process Monitor -> Header -> Select Request -> Go to source System (Header->Source System) -> Sm37-> give the request and check the status of the request in the source system -> If it is in active, then we have to check whether there any struck/failed tRFC’s/IDOC’s
If the request is in Cancelled status in Source system -> Check the Info Pack status in BW system -> If IP status is also in failed state/cancelled state -> Check the data load type (FULL or DELTA) -> if the status is full then we can turn the Info Package status red and then we can repeat/restart the Info package/job. -> If the load is of Delta type then we have to go RSA7 in source system-> (Compare the last updated time in Source System SM37 back ground job)) Check the time stamp -> If the time stamp in RSA7 is matching then turn the Info Package status to Red -> Restart the job. It’ll fetch the data in the next iteration
If the time stamp is not updated in RSA7 -> Turn the status into Green -> Restart the job. It’ll fetch the data in the next iteration.

Source System
BW System
Source System RSA7
Source System SM37
Action
I/P Status RED(Cancelled)
I/P Status (Active)
Time stamp matching with SM37 last updated time
Time stamp matching with RSA7 time stamp
Turn the I/P Status into Red and Restart the Job
I/P Status RED(Cancelled)
I/P Status (Cancelled)
Time stamp matching with SM37 last updated time
Time stamp matching with RSA7 time stamp
Turn the I/P Status into Red and Restart the Job
I/P Status RED(Cancelled)
I/P Status (Active)
Time stamp is not  matching with SM37 last updated time
Time stamp is not matching with RSA7 time stamp
Turn the I/P status into Green and Restart the job
I/P Status RED(Cancelled)
I/P Status (Cancelled)
Time stamp is not  matching with SM37 last updated time
Time stamp is not matching with RSA7 time stamp
Turn the I/P status into Green and Restart the job



  • Processing the IDOC Manually in BI:
  
When there is an IDOC which is stuck in the BW and successfully completed the background job in the source system, in such cases we can process the IDOC manually in the BW.

Go to Info Package -> Process Monitor -> Details -> select the IDOC which is in yellow status(stuck) -> Right click -> Process the IDOC manually -> it’ll take some time to get processed.
******Make sure that we can process the IDOC in BW only when the back ground job is completed in the source system and stuck in the BW only.



3.      DSO Activation Failure:

When there is a failure in DSO activation step, check whether the data is loading to DSO from PSA or from the source system directly. If the data is loading to DSO from PSA, then activate the DSO manually as follows

  • Right click DSO Activation Step -> Target Administration -> Select the latest request in DSO -> select Activate -> after request turned to green status, Restart the job.

  • If the data is loading directly from the source system to DSO, then delete the bad request in the PSA table, then restart the job

4.      Failure in Drop Index/ Compression step:

When there is a failure in Drop Index/ compression step, check the Error Message. If it is failed due to “Lock Issue”, it means job failed because of the parallel process or action which we have performed on that particular cube or object. Before restarting the job, make sure whether the object is unlocked or not.

There is a chance of failure in Index step in case of TREX server issues. In such cases engage BASIS team and get the info reg TREX server and repeat/ Restart the job once the server is fixed.

Compression Job may fail when there is any other job which is trying to load the data or accessing from the Cube. In such case job fails with the error message as “Locked by ......” Before restarting the job, make sure whether the object is unlocked or not.


5. Roll Up failure:

“Roll Up” fails due to Contention Issue. When there is Master Data load is in progress, there is a chance of Roll up failure due to resource contention. In such case before restarting the job/ step, make sure whether the master data load is completed or not. Once the master data load finishes restart the job.


6. Change Run – Job finishes with error RSM 756
      
When there is a failure in the attribute change run due to Contention, we have to wait for the other job (Attribute change run) completion. Only one ACR can run in BW at a time. Once the other ACR job is completed, then we can restart/repeat the job.

We can also run the ACR manually in case of nay failures.
Go to RSA1-> Tool -> Apply Hierarchy/Change Run -> select the appropriate Request in the list for which we have to run ACR -> Execute.

7. Transformation In-active:

In case of any changes in the production/moved to the production without saving properly or any modification done in the transformation without changing, in such cases there is a possibility of Load failure with the error message as “ Failure due to Transformation In active”.

In such cases, we will have to activate the Transformation which is inactive.
Go to RSA1 -> select the transformation -> Activate

In case of no authorization for activating the transformation in production system, we can do it by using the program - RSDG_TRFN_ACTIVATE

Try the following steps to use the program "RSDG_TRFN_ACTIVATE” here you will need to enter certain details:
Transformation ID: Transformation’s Tech Name (ID)
Object Status: ACT
Type of Source: “Source Name”
Source name: “Source Tech Name”
Type of Target: Target Name
Target name: “Target Tech Name”
  1. Execute. The Transformation status will be turned into Active.
Then we can restart the job. Job will be completed successfully.


   8. Process Chain Started from the yesterday’s failed step:

In few instances, process chain starts from the step which was failed in the previous iteration instead of starting from the “Start” step.
In such cases we will have to delete the previous day’s process chain log, to start the chain form the beginning (from Start variant).
Go To ST13-> Select the Process Chain -> Log -> Delete.
Or we can use Function Module for Process Chain Log Deletion: RSPROCESS_LOG_DELETE.
Give the log id of the process chain, which we can get from the ST13 screen.
Then we can restart the chain.

Turning the Process Chain Status using Function Module:

At times, when there is no progress in any of the process chains which is running for a long time without any progress, we will have to turn the status of the entire chain/Particular step by using the Function Module.

Function ModuleRSPC_PROCESS_FINISH
  
The program "RSPC_PROCESS_FINISH" for making the status of a particular process as finished.
To turn any DTP load which was running long, so please try the following steps to use the program "RSPC_PROCESS_FINISH" here you need to enter the following details:

LOG ID: this id will be the id of the parent chain.
CHAIN: here you will need to enter the chain name which has failed process.
TYPE: Type of failed step can be found out by checking the table "RSPCPROCESSLOG" via "SE16" or "ZSE16" by entering the Variant & Instance of the failed step. The table "RSPCPROCESSLOG" can be used to find out various details regarding a particular process.
INSTANCE & VARIANT: Instance & Variant name can be found out by right clicking on the failed step and then by checking the "Displaying Messages Options" of the failed step & then checking the chain tab.
STATE: State is used to identify the overall state of the process. Below given are the various states for a step.
R Ended with errors
G Successfully completed
F Completed
A Active
X Canceled
P Planned
S Skipped at restart
Q Released
Y Ready
Undefined
J Framework Error upon Completion (e.g. follow-on job missing)

9. Hierarchy save Failure:
When there a failure in Hierarchy Save, then we have to follow the below process...
If there is an issue with Hierarchy save, we will have to schedule the Info packages associated with the Hierarchies manually. Then we have to run Attribute Change Run to update the changes to the associated Targets. Please find the below mentioned the step by step process...
ST13-> Select Failed Process Chain -> Select Hierarchy Save Step -> Rt click Display Variant -> Select the info package in the hierarchy -> Go to RSA! -> Run the Info Package Manually -> Tools -> Run Hierarchy/Attribute Change Run -> Select Hierarchy List (Here you can find the List of Hierarchies) -> Execute.

2 comments:

  1. Thank you for your guide to with upgrade information about Tableau
    Tableau Online Training

    ReplyDelete
  2. Excellent guide. Thank you very much!

    ReplyDelete