Showing posts with label SAP BW/BI. Show all posts
Showing posts with label SAP BW/BI. Show all posts

Monday, January 20, 2014

SAP Production Support-Ticket Resolving

What is SAP Production Support - Ticket Resolving
1. How the tickets in production support are resolved?
2. Give some examples with solutions?
What are the types of ticket and its importance?
This depends on the SLA. It can be like:
  1. Critical.
  2. Urgent.
  3. High.
  4. Medium
  5. Low.
The response times and resolution times again are defined in the SLA based on the clients requirement and the charges.
This is probably from the viewpoint of Criticality of the problem faced by the client as defined by SAP.
  1)      First Level Ticketing:
Not severe problem. Routine errors. Mostly handled by Service desk arrangement of the company (if have one).
Eg: a) Say Credit limit block in working on certain documents?
      b) Pricing Condition Record not found even though conditions are maintained?
      c) Unable to print a delivery document or Packing list?
PS: In the 4th phase of ASAP Implementation Methodology( i.e Final Preparations for GO-LIVE) SAP has clearly specified that a Service desk needs to be arranged for any sort of Implementation for better handling of Production errors.
Service desk lies with in the client.
2)      Second Level Ticketing:
Some sort of serious problems. Those Could not be solved by Service Desk. Should be referred to the Service Company (or may be company as prescribed in SLA).
Eg: a) Credit Exposure (especially open values) doesn't update perfectly to KNKK Table.
      b) Inter company Billing is taking a wrong value of the Bill.
      c) Need a new order type to handle reservation process
      d) New product has been added to our selling range. Need to include this into SAP. (Material Masters, Division attachements, Stock Handling etc.)
3)      Third Level Ticketing:
Problems could not be solved by both of the above, are referred to Online Service Support (OSS) of SAP Itself. SAP tries to solve the Problem, sometimes by providing the perfect OSS Notes, fits to the error and rarely SAP logs into our Servers (via remote log-on)for post mortem the problem. (The Medical check-up client, connections, Login id and Passwords stuff are to be provided to SAP whenever they need or at the time of opening OSS Message.)
There are lots of OSS Notes on each issue, SAP Top Notes and Notes explaining about the process of raising a OSS Message.
Sometimes SAP Charges to the client / Service company depending on the Agreement made at the time of buying License from SAP.
Eg: 1) Business Transation for the Currency 'EUR' is not possible. Check OSS Note  - This comes at the time of making Billing.
      2) Transaction MMPI- Periods cannot be opened – See OSS Note.
      There are many other examples on the issue.
4)      Fourth Level Ticketing:
Where rarely, problems reach this level.
Those problem needs may be re-engineering of the business process due to change in the Business strategy. Upgradation to new Version.  More or less this leads to extinction of the SAP Implementation.

SAP BW Production Support Issues



SAP BW Production Support Issues
Production Support Errors :1) Invalid characters while loading: When you are loading data then you may get some special characters like @#$%...e.t.c.then BW will throw an error like Invalid characters then you need to go through this RSKC transaction and enter all the Invalid chars and execute. It will store this data in RSALLOWEDCHAR table. Then reload the data. You won't get any error because now these are eligible chars done by RSKC.

2) IDOC Or TRFC Error: We can see the following error at “Status” Screen:Sending packages from OLTP to BW lead to errorsDiagnosisNo IDocs could be sent to the SAP BW using RFC.System responseThere are IDocs in the source system ALE outbox that did not arrive in the ALE inbox of the SAP BW.Further analysis:Check the TRFC log.You can get to this log using the wizard or the menu path "Environment -> Transact. RFC -> In source system".Removing errors:If the TRFC is incorrect, check whether the source system is completely connected to the SAP BW. Check especially the authorizations of the background user in the source system.Action to be taken:If Source System connection is OK Reload the Data.

3)PROCESSING IS OVERDUE FOR PROCESSED IDOCsDiagnosis IDocs were found in the ALE inbox for Source System that is not updated. Processing is overdue. Error correction: Attempt to process the IDocs manually. You can process the IDocs manually using the Wizard or by selecting the IDocs with incorrect status and processing them manually. Analysis:After looking at all the above error messages we find that the IDocs are found in the ALE inbox for Source System that are not Updated.Action to be taken:We can process the IDocs manually via RSMO -> Header Tab -> Click on Process manually.

4) LOCK NOT SET FOR LOADING MASTER DATA ( TEXT / ATTRIBUE / HIERARCHY )Diagnosis User ALEREMOTE is preventing you from loading texts to characteristic 0COSTCENTER . The lock was set by a master data loading process with therequest number. System response For reasons of consistency, the system cannot allow the update to continue, and it has terminated the process. Procedure Wait until the process that is causing the lock is complete. You can call transaction SM12 to display a list of the locks. If a process terminates, the locks that have been set by this process are reset automatically. Analysis:After looking at all the above error messages we find that the user is “Locked”. Action to be taken:Wait for sometime & try reloading the Master Data manually from Info-package at RSA1.

5) Flat File Loading ErrorDetail Error MessageDiagnosis Data records were marked as incorrect in the PSA. System response The data package was not updated.Procedure Correct the incorrect data records in the data package (for example by manually editing them in PSA maintenance). You can find the error message for each record in the PSA by double-clicking on the record status.Analysis:After looking at all the above error messages we find that the PSA contains incorrect record.Action to be taken:To resolve this issue there are two methods:-i) We can rectify the data at the source system & then load the data.ii) We can correct the incorrect record in the PSA & then upload the data into the data target from here.

6) Object requested is currently locked by user ALEREMOTEDetail Error Message.DiagnosisAn error occurred in BI while processing the data. The error is documented in an error message.Object requested is currently locked by user ALEREMOTEProcedureLook in the lock table to establish which user or transaction is using the requested lock (Tools -> Administration -> Monitor -> Lock entries). Analysis:After looking at all the above error messages we find that the Object is “Locked. This must have happened since there might be some other back ground process runningAction to Be taken : Delete the error request. Wait for some time and Repeat the chain.

Idocs between R3 and BW while extraction
1)When BW executes an infopackage for data extraction the BW system sends a Request IDoc ( RSRQST ) to the ALE inbox of the source system.Information bundled in Request IDoc (RSRQST) is :
Request Id ( REQUEST )
Request Date ( REQDATE )
Request Time (REQTIME)
Info-source (ISOURCE)
Update mode (UPDMODE )
2)The source system acknowledges the receipt of this IDoc by sending an Info IDoc (RSINFO) back to BW system.The status is 0 if it is ok or 5 for a failure.
3)Once the source system receives the request IDoc successfully, it processes it according to the information in the request. This request starts the extraction process in the source system (typically a batch job with a naming convention that begins with BI_REQ). The request IDoc status now becomes 53 (application document posted). This status means the system cannot process the IDoc further.
4)The source system confirms the start of the extraction job by the source system to BW by sending another info IDoc (RSINFO) with status = 1
5)Transactional Remote Function Calls (tRFCs) extract and transfer the data to BW in data packages. Another info IDoc (RSINFO) with status = 2 sends information to BW about the data package number and number of records transferred
6)At the conclusion of the data extraction process (i.e., when all the data records are extracted and transferred to BW), an info IDoc (RSINFO) with status = 9 is sent to BW, which confirms the extraction process.

When is reconstruction allowed?

1. When a request is deleted in a ODS/Cube, will it be available under reconstruction.
Ans :Yes it will be available under reconstruction tab, only if the processing is through PSA Note: This function is particularly useful if you are loading deltas, that is, data that you cannot request again from the source system
2. Should the request be turned red before it is deleted from the target so as to enable reconstruction
Ans :To enable reconstruction you may not need to make the request red, but to enable repeat of last delta you have to make the request red before you delete it.
3. If the request is deleted with its status green, does the request get deleted from reconstruction tab too
Ans :No, it wont get deleted from reconstruction tab
4. Does the behaviour of reconstruction and deletion differ when the target is differnet. ODS and Cube
Ans :Yes


How to Debugg Update and transfer Rules
1.Go to the Monitor.
2. Select 'Details' tab.
3. Click the 'Processing'
4. Right click any Data Package.
5. select 'simulate update'
6. Tick the check boxes ' Activate debugging in transfer rules' and 'Activate debugging in update rules'.
7. Click 'Perform simulation'.


Error loading master data - Data record 1 ('AB031005823') : Version 'AB031005823' is not valid
ProblemCreated a flat file datasource for uploading master data.Data loaded fine upto PSA.Once the DTP which runs the transformation is scheduled, its ends up in error as below:


SolutionAfter refering to many links on sdn, i found that since the data is from an external file,the data will not be matching the SAP internal format. So it shud be followed that we mark "External" format option in the datasource ( in this case for Material ) and apply the conversion routine MATN1 as shown in the picture below

:Once the above changes are done, the load was successful.Knowledge from SDN forumsConversion takes place when converting the contents of a screen field from display format to SAP-internal format and vice versa and when outputting with the ABAP statement WRITE, depending on the data type of the field.

Check the info :http://help.sap.com/saphelp_nw04/helpdata/en/2b/e9a20d3347b340946c32331c96a64e/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/07/6de91f463a9b47b1fedb5be18699e7/content.htmThis fm ( MATN1) will add leading ZEROS to the material number because when u query on MAKT with MATNR as just 123 you wll not be getting any values, so u should use this conversion exit to add leading zeros.’

Function module to make yellow request to RED
Use SE37, to execute the function module RSBM_GUI_CHANGE_USTATE.From the next screen, for I_REQUID enter that request ID and execute.From the next screen, select 'Status Erroneous' radiobutton and continue.This Function Module, change the status of request from Green / Yellow to RED.

What will happend if a request in Green is deleted?
Deleting green request is no harm. if you are loading via psa, you can go to tab 'reconstruction' and select the request and 'insert/reconstruct' to have them back.But,For example you will need to repeat this delta load from the source system. If you delete the green request then you will not get these delta records from the source system.Explanation :when the request is green, the source system gets the message that the data sent was loaded successfully, so the next time the load (delta) is triggered, new records are sent.If for some reason you need to repeat the same delta load from the source, then making the request red sends the message that the load was not successful, so do not discard these delta records.Delta queue in r/3 will keep until the next upload successfully performed in bw. The same records are then extracted into BW in the next requested delta load.

Appearence of Values for charecterstic input help screen
Which settings can I make for the input help and where can I maintain these settings?In general, the following settings are relevant and can be made for the input help for characteristics:Display: Determines the display of the characteristic values with the following options "Key", "Text", "Key and text" and "Text and key".Text type: If there are different text types (short, medium and long text), this determines which text type is to be used to display the text.Attributes: You can determine for the input help which attributes of the characteristic are displayed initially. When you have a large number of attributes for the characteristic, it makes sense to display only a selected number of attributes. You can also determine the display sequence of the attributes.F4 read mode: Determines in which mode the input help obtains its characteristic values. This includes the modes "Values from the master data table (M)", "Values from the InfoProvider (D)" and "Values from the Query Navigation (Q)".

Note that you can set a read mode, on the one hand, for the input help for query execution (for example, in the BEx Analyzer or in the BEX Web) and, on the other hand, for the input help for the query definition (in the BEx Query Designer). You can make these settings in InfoObject maintenance using transaction RSD1 in the context of the characteristic itself, in the InfoProvider-specific characteristic settings using transaction RSDCUBE in the context of the characteristic within an InfoProvider or in the BEx Query Designer in the context of the characteristic within a query. Note that not all the settings can be maintained in all the contexts. The following table shows where certain 

settings can be made:

Setting RSD1 RSDCUBE BExQueryDesigner
Display X X X
Text type X X X
Attributes X - -
Read mode -
Query execution X X X -
Query definition X - -
Note that the respective input helps in the BEx Web as well as in the BEx Tools enable you to make these settings again after executing the input help.


When do I use the settings from InfoObject maintenance (transaction RSD1) for the characteristic for the input help?

The settings that are made in InfoObject maintenance are active in the context of the characteristic and may be overwritten at higher levels if required. At present, the InfoProvider-specific settings and the BEx Query Designer belong to the higher levels. If the characteristic settings are not explicitly overwritten in the higher levels, the characteristic settings from InfoObject maintenance are active.When do I use the settings from the InfoProvider-specific characteristic settings (transaction RSDCUBE) for the input help?You can make InfoProvider-specific characteristic settings in transaction RSDCUBE -> context menu for a characteristic -> InfoProvider-specific properties.These settings for the characteristic are active in the context of the characteristic within an InfoProvider and may be overwritten in higher levels if required. At present, only the BEx Query Designer belongs to the higher levels. If the characteristic settings are not explicitly overwritten in the higher levels and settings are made in the InfoProvider-specific settings, these are then active. Note that the settings are thus overwritten in InfoObject maintenance.When do I use the settings in the BEx Query Designer for characteristics for the input help?In the BEx Query Designer, you can make the input help-relevant settings when you go to the tab pages "Display" and "Advanced" in the "Properties" area for the characteristic if this is selected.These settings for the characteristic are active in the context of the characteristic within a query and cannot be overwritten in higher levels at present. If the settings are not made explicitly, the settings that are made in the lower levels take effect.

How to supress messages generated by BW Queries
Standard Solution :
You might be aware of a standard solution. In transaction RSRT, select your query and click on the "message" button. Now you can determine which messages for the chosen query are not to be shown to the user in the front-end.

Custom Solution:
Only selected messages can be suppressed using the standard solution. However, there's a clever way you can implement your own solution... and you don't need to modify the system for it!All messages are collected using function RRMS_MESSAGE_HANDLING. So all you have to do is implement an enhancement at the start of this function module. Now it's easy. Code your own logic to check the input parameters like the message class and number and skip the remainder of the processing logic if you don't want this message to show up in the front-end.

FUNCTION rrms_message_handling.
StartENHANCEMENT 1 Z_CHECK_BIA.
* Filter BIA Message
if i_class = 'RSD_TREX' and i_type = 'W' and i_number = '136'*
just testing it.*
exitend if.
ENHANCEMENT
End
IMPORTING
------------
----------
----
EXCEPTIONS
Dummy ..

How can I display attributes for the characteristic in the input help?
Attributes for the characteristic can be displayed in the respective filter dialogs in the BEx Java Web or in the BEx Tools using the settings dialogs for the characteristic. Refer to the related application documentation for more details.In addition, you can determine the initial visibility and the display sequence of the attributes in InfoObject maintenance on the tab page "Attributes" -> "Detail" -> column "Sequence F4". Attributes marked with "0" are not displayed initially in the input help.



Finance  economy  finance & insurance money derivatives wall street young money  got money cash money  get money 
 
Why do the settings for the input help from the BEx Query Designer and from the InfoProvider-specific characteristic settings not take effect on the variable screen?
On the variable screen, you use input helps for selecting characteristic values for variables that are based on characteristics. Since variables from different queries and from potentially different InfoProviders can be merged on the variable screen, you cannot clearly determine which settings should be used from the different queries or InfoProviders. For this reason, you can use only the settings on the variable screen that were made in InfoObject maintenance.

Thursday, December 12, 2013

SAP BW/BI Interview Questions and Answers - 8



Question: How we are going to decide which schema we are going to implement in the data warehouse? Answer: One way is what is mentioned in Question above. If you ask me to blindly create schemas for the warehouse without knowing any requirements, I will simply first divide the schemas on the basis of functional areas of an Organisation which are similar to the modules in an ERP like sales, finance, purchase, inventory, production, HR etc. I will broadly describe the expected analysis an organisation would like to do in every module. I think this way you would be able to complete at least 40-50 % of the requirements. To move ahead, study the data and business and you can create few more schemas.
 Question: What are the Challenges You Faced while making of Reports? Answer: Making of an report has never been a difficult task. But problem comes when users are reluctant to adopt a new system. I have experienced that if you are not able to create the report in exactly the way they used to see, they will keep asking for the changes. Your approach should be to first show them what they want to see and then add more information in the report.
Question: What you will do when your Report is not Fetching Right Data? Answer: this is the biggest problem in report creation and verification. There could be two reasons for report not fetching the right data. 1. Mostly clients do not have correct data in their database and on top of that to correct the results they make some changes at the report level to bring the desired result which you may not e aware of while creating the reports. Clients try to match the data with their existing reports and you never get the correct results. you try to discover the things and at later stage come to know of all these problems and you are held responsible for this delay. Hence always consult the SPOC(Single Point of Contact) and try to understand the logic they have used to generate their reports. 2. If the database values are correct, there there could be a problem with the joins and relations in the schema. You need to discover that analysing and digging deep into the matter. There are more questions which I will try to answer later. The questions are very specific to OBIEE and I dont have much experience in that. Hence you may not agree to my answers, but wherever please post a comment and let me know too.
Question: How analytics Process Your Request When you Create your Requests. Answer: If the Question means how does Oracle BI Analytics Server processes the user requests, the answer is- Oracle BI server converts the logical SQL submitted by the client into optimised physical SQL which is then sent to the backend database. Also in between it performs various tasks like converting the user operations like user selections to form a logical SQL, checking and verifying credentials, breaking the request into threads(as Oracle BI is a multi threaded server), processes the requests, manages the cached results, again
converting the results received from the database into user presentable form etc.
 Question: From where u Get the Logical Query of your Request? Answer: The logical SQL generated by the server can be viewed in BI Answers. If I have not understood the question, Please raise your voice.
Question: Major Challenges You Faced While Creating the RPD?????? Answer: Every now and then there are problems with the database connections but the problem while creating the repository RPD files comes with complex schemas made on OLTP systems consisting of lot of joins and checking the results. Th type of join made need to be checked. By default it is inner join but sometimes the requirement demands other types of joins. There are lot of problems with the date formats also.
Question: What are Global Filter and how thery differ From Column Filter? Answer: Column filter- simply a filter applied on a column which we can use to restrict our column values while pulling the data or in charts to see the related content. Global filter- Not sure. I understand this filter will have impact on across the application but I really dont understand where and how it can be user. I heard of global variables but not global filters.
 How to make the Delivery Profilers Work? When we are Use SA System how Does SA Server understand that It needs to use it For Getting the User Profile information?
Where to Configure the Scheduler? Answer: I am not sure if Iam correct but we configure the OBIEE schedular in database.
Question: How to hide Certain Columns From a User? Answer: Application access level security- Do not add the column in the report, Do not add the column in the presentation layer. Question:How can we Enable Drills in a Given Column Data? Answer: To enable Drill down for a column, it should be included in the hirarchy in OBIEE. Hyperion IR has a drill anywhere feature where dont have to define and can drill to any available column.
 Question: Is Drill Down Possible without the attribute being a Part of a Hierarchical Dimension? Answer: No
Question: How do u Conditional Format.? Answer: while creating a chat in BI Answers, you can define the conditions and can apply colour formatting
. Question: What is Guided Navigation? Answer: I think it is just the arrangement of hyperlinks to guide the user to navigate between the reports to do the analysis.
How is Webcat File Deployed Across Environment? Question: How the users Created Differs From RPD/Answers/Dashboards Level?????
Answer: RPD users can do administrator tasks like adding new data source, create hirarchies, change column names where as Answers users may create new charts, edit those charts and Dashboard users may only view and analyse the dashboard or can edit dashboard by adding/removing charts objects.
Question: Online/Offline Mode how it Impact in Dev and Delpoyment???? Answer: Online Mode- You can make changes in the RPD file and push in changes which will be immediately visible to the users who are already connected. This feature we may use in production environment. Offline mode- can be useful in test or development environment.

Wednesday, December 11, 2013

SAP BW/BI Interview Questions and Answers - 7

Q) Despite of the delta request being started after completion of the collective run (V3 update), it does not contain all documents. Only another delta request loads the missing documents into BW. What is the cause for this "splitting"?
A) The collective run submits the open V2 documents for processing to the task handler, which processes them in one or several parallel update processes in an asynchronous way. For this reason, plan a sufficiently large "safety time window" between the end of the collective run in the source system and the start of the delta request in BW. An alternative solution where this problem does not occur is described in Note 505700.
Q) In SMQ1 (qRFC Monitor) I have status 'NOSEND'. In the table TRFCQOUT, some entries have the status 'READY', others 'RECORDED'. ARFCSSTATE is 'READ'. What do these statuses mean? Which values in the field 'Status' mean what and which values are correct and which are alarming? Are the statuses BW-specific or generally valid in qRFC?
A) Table TRFCQOUT and ARFCSSTATE: Status READ means that the record was read once either in a delta request or in a repetition of the delta request. However, this does not mean that the record has successfully reached the BW yet. The status READY in the TRFCQOUT and RECORDED in the ARFCSSTATE means that the record has been written into the DeltaQueue and will be loaded into the BW with the next delta request or a repetition of a delta. In any case only the statuses READ, READY and RECORDED in both tables are considered to be valid. The status EXECUTED in TRFCQOUT can occur temporarily. It is set before starting a DeltaExtraction for all records with status READ present at that time. The records with status EXECUTED are usually deleted from the queue in packages within a delta request directly after setting the status before extracting a new delta. If you see such records, it means that either a process which is confirming and deleting records which have been loaded into the BW is successfully running at the moment, or, if the records remain in the table for a longer period of time with status EXECUTED, it is likely that there are problems with deleting the records which have already been successfully been loaded into the BW. In this state, no more deltas are loaded into the BW. Every other status is an indicator for an error or an inconsistency. NOSEND in SMQ1 means nothing (see note 378903). The value 'U' in field 'NOSEND' of table TRFCQOUT is discomforting.
Q) How and where can I control whether a repeat delta is requested?
A) Via the status of the last delta in the BW Request Monitor. If the request is RED, the next load will be of type 'Repeat'. If you need to repeat the last load for certain reasons, set the
request in the monitor to red manually. For the contents of the repeat see Question 14. Delta requests set to red despite of data being already updated lead to duplicate records in a subsequent repeat, if they have not been deleted from the data targets concerned before.
Q) THERE is one ODS AND 4 INFOCUBES. WE SEND DATA AT TIME TO ALL CUBES IF ONE CUBE GOT LOCK ERROR. HOW CAN U RECTIFY THE ERROR?
A) Go to TCode sm66 then see which one is locked select that pid from there and goto sm12 TCode then unlock it this is happened when lock errors are occurred when u scheduled.
Q) In BW we need to write abap routines. I wish to know when and what type of abap routines we got to write. Also, are these routines written in update rules? I will be glad, if this is clarified with real-time scenarios and few examples?
A) Over here we write our routines in the start routines in the update rules or in the transfer structure (you can choose between writing them in the start routines or directly behind the different characteristics. In the transfer structure you just click on the yellow triangle behind a characteristic and choose "routine". In the update rules you can choose "start routine" or click on the triangle with the green square behind an individual characteristic. Usually we only use start routine when it does not concern one single characteristic (for example when you have to read the same table for 4 characteristics). I hope this helps. We used ABAP Routines for example: To convert to Uppercase (transfer structure) To convert Values out of a third party tool with different keys into the same keys as our SAP System uses (transfer structure) To select only a part of the data for from an infosource updating the InfoCube (Start Routine) etc.
Q) Difference between Calculated KeyFigure & Formula? A)
Q) Variables in Reporting?
A) Characteristics values, Text, Hierarchies, Hierarchy nodes & Formula elements,
Q) Variable processing types in Reporting?
A) Manual, Replacement path, SAP Exit, Authorizations, Customer Exit


Q) Why we use this RSRP0001 Enhancement?
A) For enhancing the Customer Exit in reporting.
Q) We need to find the table in which query and variable assignments are stored. We must read this table in a user-exit to get which variables are used in a query.
A) Check out tables RSZELTDIR and RSZCOMPDIR for query BEx elements. I found this info on one of the previous posting, variable table, RSZGLOBV, query table - get query id from table RSRREPDIR (field RSRREPDIR-COMPUID), use this id for table start with RSZEL* When 'ZFISPER1' name of the variable when VNAM = 'ZVC_FY1' - characteristics. Step 1 - before selection Step 2 - after selection Step 3 - processed all variable at the same time
Q) What is an aggregate?
A) Aggregates are small or baby cubes. A subset of InfoCube. Flat Aggregate --when u have more than 15 characteristics for aggregate system will generate that aggregate as flat aggregate to increase performance. Roll-up--when the data is loaded for second time into cube, we have to roll-up to make that data available in aggregate.



Finance  economy  finance & insurance money derivatives wall street young money  got money cash money  get money

Q) How can we stop loading data into infocube?
A) First you have to find out what is the job name from the monitor screen for this load monitor screen lo Header Tabstrip lo untadhi. SM37 (job monitoring) in r/3 select this job and from the menu u can delete the job. There are some options, just check them out in sm37 and also u have to delete the request in BW. Cancellation is not suggestible for delta load.

Tuesday, December 10, 2013

SAP BW/BI Interview Questions and Answers - 6

Q) What are Process Chains?
A) TCode is RSPC, is a sequence of processes scheduled in the background & waiting to be triggered by a specific event. Process chains nothing but grouping processes. Process variant (start variant) is the place the process chain knows where to start. There should be
min and max one start variant in each process chain, here we specify when should the process chain start by giving date and time or if you want to start immediately Some of theses processes trigger an event of their own that in-turn triggers other processes. Ex: - Start chain ¨ Delete BCube indexes ¨ Load data from the source system to PSA ¨ Load data from PSA to DataTarget ODS ¨ Load data from ODS to BCube ¨ Create Indexes for BCube after loading data ¨ Create database statistics ¨ Roll-Up data into the aggregate ¨ Restart chain from beginning.
Q) What are Process Types & Process variant?
A) Process types are General services, Load Process & subsequent processing, Data Target Administration, Reporting agent & Other BW services. Process variant (start variant) is the place the process type knows when & where to start.
Q) Types of Updates?
A) Full Update, Init Delta Update & Delta Update.
Q) For what we use HIDE fields, SELECT fields & CANCELLATION fields?
A) Selection fields-- The only purpose is when we check this column, the field will appear in InfoPackage Data selection tab. Hide fields -- These fields are not transferred to BW transfer structure. Cancellation - It will reverse the posted documents of keyfigures of customer defined by multiplying it with -1...and nullifying the value. I think this is reverse posting
Q) How can I compare data in R/3 with data in a BW Cube after the daily delta loads?
Are there any standard procedures for checking them or matching the number of records?
A) You can go to R/3 TCode RSA3 and run the extractor. It will give you the number of records extracted. Then go to BW Monitor to check the number of records in the PSA and check to see if it is the same & also in the monitor header tab. A) RSA3 is a simple extractor checker program that allows you to rule out extracts problems in R/3. It is simple to use, but only really tells you if the extractor works. Since records that get updated into Cubes/ODS structures are controlled by Update Rules, you will not be able to determine what is in the Cube compared to what is in the R/3 environment. You will need to compare records on a 1:1 basis against records in R/3 transactions for the functional area in question. I would recommend enlisting the help of the end user community to assist since they presumably know the data. To use RSA3, go to it and enter the extractor ex: 2LIS_02_HDR. Click execute and you will see the record count, you can also go to display that data. You are not modifying anything so what you do in RSA3 has no effect on data quality afterwards. However, it will not tell you how many records should be expected in BW for a given load. You have that information in the monitor RSMO during and after data loads. From RSMO for a given load you can determine how many records were passed through the transfer rules from R/3, how many targets were updated, and how many records passed through the Update Rules. It also gives you error messages from the PSA.
Q) X & Y Tables? X-table = A table to link material SIDs with SIDs for time-independent navigation attributes. Y-table = A table to link material SIDs with SIDS for time-dependent navigation attributes. There are four types of sid tables X time independent navigational
attributes sid tables Y time dependent navigational attributes sid tables H hierarchy sid tables I hierarchy structure sid tables


Q) How to know in which table (SAP BW) contains Technical Name / Description and creation data of a particular Reports. Reports that are created using BEx Analyzer.
A) There is no such table in BW if you want to know such details while you are opening a particular query press properties button you will come to know all the details that you wanted. You will find your information about technical names and description about queries in the following tables. Directory of all reports (Table RSRREPDIR) and Directory of the reporting component elements (Table RSZELTDIR) for workbooks and the connections to queries check Where- used list for reports in workbooks (Table RSRWORKBOOK) Titles of Excel Workbooks in InfoCatalog (Table RSRWBINDEXT)
Q) What is a LUW in the delta queue?
A) A LUW from the point of view of the delta queue can be an individual document, a group of documents from a collective run or a whole data packet of an application extractor.
Q) Why does the number in the 'Total' column in the overview screen of Transaction RSA7 differ from the number of data records that is displayed when you call the detail view?
A) The number on the overview screen corresponds to the total of LUWs (see also first question) that were written to the qRFC queue and that have not yet been confirmed. The detail screen displays the records contained in the LUWs. Both, the records belonging to the previous delta request and the records that do not meet the selection conditions of the preceding delta init requests are filtered out. Thus, only the records that are ready for the next delta request are displayed on the detail screen. In the detail screen of Transaction RSA7, a possibly existing customer exit is not taken into account.
Q) Why does Transaction RSA7 still display LUWs on the overview screen after successful delta loading?
A) Only when a new delta has been requested does the source system learn that the previous delta was successfully loaded to the BW System. Then, the LUWs of the previous delta may be confirmed (and also deleted). In the meantime, the LUWs must be kept for a possible delta request repetition. In particular, the number on the overview screen does not change when the first delta was loaded to the BW System.
Q) Why is there a DataSource with '0' records in RSA7 if delta exists and has also been loaded successfully?
It is most likely that this is a DataSource that does not send delta data to the BW System via the delta queue but directly via the extractor (delta for master data using ALE change pointers). Such a DataSource should not be displayed in RSA7. This error is corrected with BW 2.0B Support Package 11.
Q) Do the entries in table ROIDOCPRMS have an impact on the performance of the loading procedure from the delta queue?
A) The impact is limited. If performance problems are related to the loading process from the delta queue, then refer to the application-specific notes (for example in the CO-PA area, in the logistics cockpit area and so on). Caution: As of Plug In 2000.2 patch 3 the entries in table ROIDOCPRMS are as effective for the delta queue as for a full update. Please note, however, that LUWs are not split during data loading for consistency reasons. This means that when very large LUWs are written to the DeltaQueue, the actual package size may differ considerably from the MAXSIZE and MAXLINES parameters.
Q) What is the purpose of function 'Delete data and meta data in a queue' in RSA7? What exactly is deleted?
A) You should act with extreme caution when you use the deletion function in the delta queue. It is comparable to deleting an InitDelta in the BW System and should preferably be executed there. You do not only delete all data of this DataSource for the affected BW System, but also lose the entire information concerning the delta initialization. Then you can only request new deltas after another delta initialization. When you delete the data, the LUWs kept in the qRFC queue for the corresponding target system are confirmed. Physical deletion only takes place in the qRFC outbound queue if there are no more references to the LUWs. The deletion function is for example intended for a case where the BW System, from which the delta initialization was originally executed, no longer exists or can no longer be accessed.
Q) What is the relationship between RSA7 and the qRFC monitor (Transaction SMQ1)?
A) The qRFC monitor basically displays the same data as RSA7. The internal queue name must be used for selection on the initial screen of the qRFC monitor. This is made up of the prefix 'BW, the client and the short name of the DataSource. For DataSources whose name are 19 characters long or shorter, the short name corresponds to the name of the DataSource. For DataSources whose name is longer than 19 characters (for delta-capable DataSources only possible as of PlugIn 2001.1) the short name is assigned in table ROOSSHORTN. In the qRFC monitor you cannot distinguish between repeatable and new LUWs. Moreover, the data of a LUW is displayed in an unstructured manner there.
Q) I loaded several delta inits with various selections. For which one is the delta loaded?
A) For delta, all selections made via delta inits are summed up. This means, a delta for the 'total' of all delta initializations is loaded.
Q) How many selections for delta inits are possible in the system?
A) With simple selections (intervals without complicated join conditions or single values), you can make up to about 100 delta inits. It should not be more. With complicated selection conditions, it should be only up to 10-20 delta inits. Reason: With many selection conditions that are joined in a complicated way, too many 'where' lines are generated in the generated ABAP source code that may exceed the memory limit.



Finance  economy  finance & insurance money derivatives wall street young money  got money cash money  get money

Q) I intend to copy the source system, i.e. make a client copy. What will happen with delta? Should I initialize again after that?
A) Before you copy a source client or source system, make sure that your deltas have been fetched from the DeltaQueue into BW and that no delta is pending. After the client copy, an inconsistency might occur between BW delta tables and the OLTP delta tables as described in Note 405943. After the client copy, Table ROOSPRMSC will probably be empty in the OLTP since this table is client-independent. After the system copy, the table will contain the entries with the old logical system name that are no longer useful for further delta loading from the new logical system. The delta must be initialized in any case since delta depends on both the BW system and the source system. Even if no dump 'MESSAGE_TYPE_X' occurs in BW when editing or creating an InfoPackage, you should expect that the delta have to be initialized after the copy.