Wednesday, June 26, 2013

Listing of commonly used tables in SAP BI

Listing of commonly used tables in SAP BI and to understand the way data is stored in the back end of SAP BI


ODS Object
RSDODSO
Directory of all ODS Objects
RSDODSOT
Texts of all ODS Objects
RSDODSOIOBJ
InfoObjects of ODS Objects
RSDODSOATRNAV
Navigation Attributes for ODS Object
RSDODSOTABL
Directory of all ODS Object Tables

Latest SAPBI interview questions from Top MNC

Q) What are the five ASAP Methodologies?
A: Project plan, Business Blue print, Realization, Final preparation & Go-Live - support.
1. Project Preparation: In this phase, decision makers define clear project objectives and an efficient decision making process (i.e. Discussions with the client, like what are his needs and requirements etc.). Project managers will be involved in this phase (I guess). A Project Charter is issued and an implementation strategyis outlined in this phase.
2. Business Blueprint: It is a detailed documentation of your company's requirements. (i.e. what are theobjects we need to develop are modified depending on the client's requirements).
3. Realization: In this only, the implementation of the project takes place (development of objects etc) and we are involved in the project from here only.
4. Final Preparation: Final preparation before going live i.e. testing, conducting pre-go-live, end user training etc. End user training is given that is in the client site you train them how to work with the new environment, as they are new to the technology.
5. Go-Live & support: The project has gone live and it is into production. The Project team will be supporting the end users.

Q) What is landscape of R/3 & what is landscape of BW. Landscape of R/3
A) Landscape of b/w: u have the development system, testing system, production system Development system: All the implementation part is done in this sys. (I.e., Analysis of objects developing, modification etc) and from here the objects are transported to the testing system, but before transporting an initial test known as Unit testing (testing of objects) is done in the development sys. Testing/Quality system: quality check is done in this system and integration testing is done.
Production system: All the extraction part takes place in this sys.

Q). Difference between infocube and ODS?
A: Infocube is structured as star schema (extended) where a fact table is surrounded by different dim table that are linked with DIM'ids. And the data wise, you will have aggregated data in the cubes. No overwrite functionality. ODS is a flat structure (flat table) with no star schema concept and which will have granular data (detailed level). Overwrite functionality.
Q) What is InfoSet?
A) An InfoSet is a special view of a dataset, such as logical database, table join, table, and sequential file, and is used by SAP Query as a source data. InfoSets determine the tables or fields in these tables that can be referenced by a report. In most cases, InfoSets are based on logical databases. SAP Query includes a component for maintaining InfoSets. When you create an InfoSet, a DataSource in an application system is selected. Navigating in a BW to an InfoSet Query, using one or more ODS objects or InfoObjects. You can also drill-through to BEx queries and InfoSet Queries from a second BW system that is connected as a data mart. _The InfoSet Query functions allow you to report using flat data tables (master data reporting). Choose InfoObjects or ODS objects as data sources. These can be connected using joins. You define the data sources in an InfoSet. An InfoSet can contain data from one or more tables that are connected to one another by key fields. The data sources specified in the InfoSet form the basis of the InfoSet Query.


Q) What does InfoCube contains?
A) Each InfoCube has one FactTable & a maximum of 16 (13+3 system defined, time, unit & data packet) dimensions.

Q). Differences between STAR Schema & Extended Schema?
A) In STAR SCHEMA, A FACT Table in center, surrounded by dimensional tables and the dimension tables contains of master data. In Extended Schema the dimension tables does not contain master data, instead they are stored in Masterdata tables divided into attributes, text & hierarchy. These Masterdata & dimensional tables are linked with each other with SID keys. Masterdata tables are independent of Infocube & reusability in other InfoCubes.

Q) What does FACT Table contain?
A FactTable consists of KeyFigures. Each Fact Table can contain a maximum of 233 key figures. Dimension can contain up to 248 freely available characteristics.

Q) How many dimensions are in a CUBE?
A) 16 dimensions. (13 user defined & 3 system pre-defined [time, unit & data packet])

Q) What does SID Table contain?
SID keys linked with dimension table & master data tables (attributes, texts, hierarchies)

Q) What does ATTRIBUTE Table contain?
Master attribute data
Q) What does TEXT Table contain?
Master text data, short text, long text, medium text & language key if it is language dependent

Q) What does Hierarchy table contain?
Master hierarchy data

Q) How would we delete the data in ODS?
A) By request IDs, Selective deletion & change log entry deletion.

Q) How would we delete the data in change log table of ODS?
A) Context menu of ODS → Manage → Environment → change log entries.

Q) Difference between display attributes and navigational attributes?
A: Display attribute is one, which is used only for display purpose in the report. Where as navigational attribute is used for drilling down in the report. We don't need to maintain Navigational attribute in the cube as a characteristic (that is the advantage) to drill down.

Q) What are the extra fields does PSA contain?
A) (4) Record id, Data packet …

Q) Partitioning possible for ODS?
A) No, It's possible only for Cube.

Q) Why partitioning?
A) For performance tuning.

Q) Different types of Attributes?
A) Navigational attribute, Display attributes, Time dependent attributes, Compounding attributes, Transitive attributes, Currency attributes.



Q. CAN U ADD A NEW FIELD AT THE ODS LEVEL?
Sure you can. ODS is nothing but a table.

Q) Why we delete the setup tables (LBWG) & fill them (OLI*BW)?
A) Initially we don't delete the setup tables but when we do change in extract structure we go for it. We r changing the extract structure right, that means there are some newly added fields in that which r not before. So to get the required data (i.e.; the data which is required is taken and to avoid redundancy) we delete n then fill the setup tables. To refresh the statistical data. The extraction set up reads the dataset that you want to process such as, customers orders with the tables like VBAK, VBAP) & fills the relevant communication structure with the data. The data is stored in cluster tables from where it is read when the initialization is run. It is important that during initialization phase, no one generates or modifies application data, at least until the tables can be set up.

Q) WHAT ARE THE DIFFERENT VARIABLES USED IN BEX?
A ) Different Variable's are Texts, Formulas, Hierarchies, Hierarchy nodes & Characteristic values. Variable Types are Manual entry /default value Replacement path SAP exit Customer exit Authorization

Q) WHAT ARE INDEXES?
Indexes are data base indexes, which help in retrieving data fastly.

Q) CAN CHARECTERSTIC INFOOBJECT CAN BE INFOPROVIDER.
Of course

Q) What types of partitioning are there for BW?
There are two Partitioning Performance aspects for BW (Cube & PSA) Query Data Retrieval Performance Improvement: Partitioning by (say) Date Range improves data retrieval by making best use of database [data range] execution plans and indexes (of say Oracle database engine). B) Transactional Load Partitioning Improvement: Partitioning based on expected load volumes and data element sizes. Improves data loading into PSA and Cubes by infopackages (Eg. without timeouts).

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.

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.

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.

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.

Wednesday, February 27, 2013

BW SD MM FI DATASOURCES


MM 

Data Sources Tables
Purchasing
2LIS_02_SCL EKKO, EKBE, T001, T001W, EKET, EKPA.
2LIS_02_HDR EKKO, EKBE, T001, EKPA.
2LIS_02_ITM EKKO, EKBE, T001, T001W, EKPO, TMCLVBW, T027C, ESSR, T147K, T147
2LIS_02_SCN EKET, EKES, EKPO.
2LIS_02_CGR EKBE, EKES, EKPO.
2LIS_02_SGR EKET, EKBE, KKPO

Inventory
2LIS_03_BX stock tables, MCHA, MARA, T001, T001W, CALCULATED FROM MBEW, EBEW, QBEW.
2LIS_03_BF MSEG, MBEW, MKPF.
2LIS_03_UM BKPF, MBEW, QBEW, EBEW, BSEG.
MM   
Purchasing   Datasources
ODS  
 0PUR_O01  2LIS_02_ITM, 2LIS_02_SGR, 2LIS_02_CGR, 2LIS_02_SCN.
 0PUR_O02  2LIS_02_HDR, 0PUR_O01
 0PUR_DS03  2LIS_02_SCL and 2LIS_02_SGR.
CUBE  
 0PUR_C10  2LIS_02_SCL and 2LIS_02_SGR.
 0PUR_C07  
 0PUR_C08  
 0PUR_C09  0PUR_O02, 80PUR_O01, 2LIS_02_HDR
 0SRV_C01  2LIS_02_S174
 0PUR_C04  2LIS_02_S011, 2LIS_02_SCL, 2LIS_02_ITM, 2LIS_02_HDR
 0PUR_C01  2LIS_02_S012, 2LIS_02_ITM, 2LIS_02_SCL
 0PUR_C02  2LIS_02_S013
 0PUR_C05  0MM_PUR_VE_01
 0PUR_C06  0MM_PUR_VE_02
 0PUR_C03  2LIS_02_S015
Inventory Management  
CUBE  
 0IC_C03  2LIS_03_BX, 2LIS_03_BF, 2LIS_03_UM
 0IC_C02  2LIS_03_S195, 2LIS_03_S197
 0IC_C01  2LIS_03_S196, 2LIS_03_S198
SD 
 Data sources Tables
 2LIS_11_VAKON VBUK, VBUP, VBAK, VBAP, VBKD, KOMV, T001.
 2LIS_11_VAHDR VBAK, VBUK, T001
 2LIS_11_VAITM VBAP, VBUP, VBAK, VBKD, VBAJP, T001, VBUK, PRPS.
 2LIS_11_VASCL VBAP, VBUP, VBAK, VBEP, VBKD, T001, PRPS
 2LIS_11_VASTH VBUK
 2LIS_11_VASTI VBUP, VBUK
 2LIS_11_V_ITM VBAP, VBAK, VBKD, VBUP, T001, PRPS, VBUK.
 2LIS_11_V_SCL VBUP, VBEP, VBKD, VBAP, VBAK, T001, PRPS.
 2LIS_11_V_SSL VBAP, VBEP, LIPS, WVBEP, VBUP
 2LIS_13_VDKON VBUK, VBRP, KOMV, T001, VBRK.
FI 
 DATASOURCES Tables
Cost Center Accounting 
 0CO_OM_CCA_1 COSP, COSS
 0CO_OM_CCA_2 COSP, COSS
 0CO_OM_CCA_3 COSL, COKL.
 0CO_OM_CCA_4 COSR
 0CO_OM_CCA_5 COSB
 0CO_OM_CCA_6 COOMCO
 0CO_OM_CCA_7 BPJA, BPPE.
 0CO_OM_CCA_8 COST, TKA07,COOMCO, CSLA, COST, COKL.
 0CO_OM_CCA_9 COVP (COEP& COBK), COSP, COST, COEJ, COEP, T001.
 0CO_OM_CCA_10 COOI, COSP_VTYPE.
Product Cost Controlling 
 0CO_PC_PCP_01 KEKO, TCKH3, TCKH8.
 0CO_PC_PCP_02 KEKO, TCKH3.
 0CO_PC_PCP_03 CKIS, T001K, TKA02, KEKO, MARA, MBEW.
 0CO_PC_PCP_04 CKIS, T001K, TKA02, KEKO, MBEW, MARA
 0CO_PC_01 AUFK, AFPO, COSS, COSP, COSB, COSL, COKEY, TKA09, TKV09
 0CO_PC_02 AUFK, AFPO, COSS, COSP, COSB, COSL, COKEY, TKA09, TKV09

Wednesday, February 13, 2013

V1 and V2 Update Modules


V1 and V2 Update Modules Locate the document in its SAP Library structure
An update is divided into different modules (see also Update Request). Each module corresponds to an update function module.
There are two types of module.
The SAP System makes a distinction between primary, time-critical (V1) and secondary, non-time-critical (V2) update modules. The system also supports collective runs for function modules that are used on a regular basis.
This distinction allows the system to process critical database changes before less critical changes.
  • V1 modules describe critical or primary changes; these affect objects that have a controlling function in the SAP System, for example order creation or changes to material stock.
  • V2 modules describe less critical secondary changes. These are pure statistical updates, for example, such as result calculations.
The V1 modules are processed consecutively in a single update work process on the same application server. This means that they belong to the same database LUW and can be reversed. Furthermore, V1 updates are carried out under the SAP locks of the transaction that creates the update (see  The SAP Lock Concept). This ensures that the data remains consistent; simultaneous changes to the objects to be updated are not possible.
All V2 updates are carried out in a separate LUW and not under the locks of the transaction that creates them. If your SAP System contains a work process for V2 updates, these are only carried out in this work process. If this is not the case, the V2 components are processed by a V1 update process.
All V1 modules of an update must be processed before the V2 modules.
Example
Let us assume that a transaction makes planning changes to a material and balance sheet, and updates two sets of statistics.
Each of these changes is represented by means of an update module (call update function module) in the update request - the two planning changes by a V1 update module (time critical), and the statistical changes by a V2 update module (less critical). (The V1 modules have priority, although the V2 modules are usually also processed straight away).
This is described in greater detail in the section entitled The Update Process.

Friday, February 1, 2013

What is tickets? Ticketing examples



The typical tickets in a production Support work could be:
1. Loading any of the missing master data attributes/texts.
2. Create ADHOC hierarchies.
3. Validating the data in Cubes/ODS.
4. If any of the loads runs into errors then resolve it.
5. Add/remove fields in any of the master data/ODS/Cube.
6. Data source Enhancement.
7. Create ADHOC reports.
1. Loading any of the missing master data attributes/texts - This would be done by scheduling the info packages for the attributes/texts mentioned by the client.
2. Create ADHOC hierarchies. - Create hierarchies in RSA1 for the info-object.
3. Validating the data in Cubes/ODS. - By using the Validation reports or by comparing BW data with R/3.
4. If any of the loads runs into errors then resolve it. - Analyze the error and take suitable action.
5. Add/remove fields in any of the master data/ODS/Cube. - Depends upon the requirement
6. Data source Enhancement.
7. Create ADHOC reports. - Create some new reports based on the requirement of client.
Tickets are the tracking tool by which the user will track the work which we do. It can be a change requests or data loads or whatever. They will of types critical or moderate. Critical can be (Need to solve in 1 day or half a day) depends on the client. After solving the ticket will be closed by informing the client that the issue is solved. Tickets are raised at the time of support project these may be any issues, problems.....etc. If the support person faces any issues then he will ask/request to operator to raise a ticket. Operator will raise a ticket and assign it to the respective person. Critical means it is most complicated issues ....depends how you measure this...hope it helps. The concept of Ticket varies from contract to contract in between companies. Generally Ticket raised by the client can be considered based on the priority. Like High Priority, Low priority and so on. If a ticket is of high priority it has to be resolved ASAP. If the ticket is of low priority it must be considered only after attending to high priority tickets.
Checklists for a support project of BPS - To start the checklist:
1) Info Cubes / ODS / data targets 2) planning areas 3) planning levels 4) planning packages 5) planning functions 6) planning layouts 7) global planning sequences 8) profiles 9) list of reports 10) process chains 11) enhancements in update routines 12) any ABAP programs to be run and their logic 13) major bps dev issues 14) major bps production support issues and resolution .

What are the tools to download tickets from client? Are there any standard tools or it depends upon company or client...?
Yes there are some tools for that. We use Hpopenview. Depends on client what they use. You are right. There are so many tools available and as you said some clients will develop their own tools using JAVA, ASP and other software. Some clients use just Lotus Notes. Generally 'Vantive' is used for tracking user requests and tickets.
It has a vantive ticket ID, field for description of problem, severity for the business, priority for the user, group assigned etc.
Different technical groups will have different group ID's.
User talks to Level 1 helpdesk and they raise ticket.
If they can solve issue for the issue, fine...else helpdesk assigns ticket to the Level 2 technical group.
Ticket status keeps changing from open, working, resolved, on hold, back from hold, closed etc. The way we handle the tickets vary depending on the client. Some companies use SAP CS to handle the tickets; we have been using Vantage to handle the tickets. The ticket is handled with a change request, when you get the ticket you will have the priority level with which it is to be handled. It comes with a ticket id and all. It's totally a client specific tool. The common features here can be - A ticket Id, - Priority, - Consultant ID/Name, - User ID/Name, - Date of Post, - Resolving Time etc.
There ideally is also a knowledge repository to search for a similar problem and solutions given if it had occurred earlier. You can also have training manuals (with screen shots) for simple transactions like viewing a query, saving a workbook etc so that such queried can be addressed by using them.
When the problem is logged on to you as a consultant, you need to analyze the problem, check if you have a similar problem occurred earlier and use ready solutions, find out the exact server on which this has occurred etc.
You have to solve the problem (assuming you will have access to the dev system) and post the solution and ask the user to test after the preliminary testing from your side. Get it transported to production once tested and posts it as closed i.e. the ticket has to be closed.

Tuesday, December 25, 2012

Transport Process Chains to Test System




Q.What is the best way to transport process chains to test system?
I got many other additional and unwanted objects got collected when I tried for collection of process chains from transport connection.

To transport a process chain the best is to transport only objects created for the process chain. On my system I created specific obejcts for PC : Infopackages, jobs, variant. those objects are only use for PC. By this way I avoid errors when users restart load or job manually. 
So when I want to transport a process chain I go in the monitor and select the PC make a grouping on only necessary objects, and I go through the tree generated to select only what I need. Then I go in SE10 to check if the transport contains not other objects which can impact my target system. 
You can avoid some uncessary objects by clicking in Grouping > Data flow before & Data Flow After . For example you already have infopackages in your target system but not process chains & you only want to transport only process chain without any other objects like transfer structure or infopackages . You can choose before or after option .
 
You can also choose hierachries or display option from the Display tab too if you have objects in bulk but make sure all object are selected ( in case when different-2 process chain having different kind of object then better use Hierarchy, not list ) 
While Creating these TR some objects may be in use or locked in other TR so first release them by Tcode Se03 ,using unclock object ( Expert Tool ). 
These options can reduce your effort while collecting your objects , even after so much effort you get some warning or Error like :- objects are already in system then ask basis to use overwrite mode.

Transport a specific infoobject........

Q.How to transport a specific info object? I tried to change it and then save but the transport request won't appear. How to manually transport that object?

1. Administrator Workbench (RSA1), then Transport Connection
2. Object Types, then from the list of objects put the requested one on the right side of the screen (drag & drop)
3. Click "Transport Objects", put the development class name and specify the transport (or create the new one)
4. Transaction SE01, check transport and release it
5. Move the transport up to the another system.
 
If you change and reactivate the infoobject, but get no transport request, this means that your infoobject is still in $tmp class.
go in to the maintenance of the infoobject, menu extras, object directory entry and change the development class. at this point you should have a pop-up requesting a transport request
 
If you're not getting a transport request when you change and activate, it could also be that the InfoObject is already on an open transport. 
When you collect the object in the transport connection as described above, you will see in the right hand pane an entry called Transport Request. If there is an entry here, the object is already on a transport and this gives you the transport number. 
You can then use SE01 or SE10 to delete the object from the existing transport if that is what you want to do then, when you change and activate the object again, you should be prompted for a transport request. Alternatively, you can use the existing transport depending on what else is on it.

Q.How To Do Transports in BW?

Step by step procedure for transporting in BW:
1. In RSA1 go to Transport Connection
2. Select Object Types Your Object that you want to transfer.
3. Choose grouping method (in data flow before and after)
4. Drag and drop your object.
5. Click the Truck button to transfer
6. In Source System (e.g Dev SE09).
    a. Expand to choose your child request
    b. Click on the release button (truck)
    c. Choose the parent request and click the Truck button release.
7. In Target System (e.g QA) go to STMS
    a. Click on Truck button (Import Overview)
    b. Dbl click on your QA system queue
    c. Clck on Refresh
    d. Clk on adjust import queue
    e. Select ur request and click on F11.
                            
Q.Is it possible to copy a process chain in BW 3.1? If so, how?

In RSPC, double click the process chain so that you can see it in the left hand pane. In the box where you type in the transaction code, type COPY and hit Enter.

Q.Infocube Compression.

I was dealing with the tab "compression" while managing the infocube, was able to compress the infocube and send in the E- table but was unable to find the concrete answer on the following isssues:

1. What is the exact scenario when we use compression?

Compression creates a new cube that has consolidated and summed duplicate information.



2. What actually happens in the practical scenario when we do compression?

When you compress, BW does a group by on dimensions and a sum on measures... this eliminates redundent
information.

3. What are the advantages of compressing a infocube?

Compressed infocubes require less storage space and are faster for retrieval of information.

4. What are the disadvantages of compressing a infocube?

Once a cube is compressed, you cannot alter the information in it. This can be a big problem if there
is an error in some of the data that has been compressed.

Q.I understand the advantage to compressed the infocube is the performance.  But I have a doubt.  If I compressed one or more request ID of my infocube the data it will continue to appear in my reports (Analyzer)?

The data will always be there in the Infocube. The only thing that would be missing is the request id's.. you can take a look in to your packet dimension and see that it would be empty after you compress.
Compression yeap its for performance. But before doing this compression you should keep in mind one thing very carefully.
1) If your cube is loading data with custom defined deltas you should check whether delta is happening properly or not, procedure is compress some req and schedule the delta.
2) If your system having outbounds from cube and this happening with request ids then you need to follow some other procedure because request ids wont be available after compression.
These two things are very important when you go for compression.