'Error DTP'

With this blog I am trying to explain the new concept of handling data records with errors using ‘Error DTP’.

Check this link for types of possible data record errors.

In this blog I am considering simple case of data records that contains invalid characters. Scenario could be any this is just for the explanation of concept.

While loading data records using DTP, error records get updated into Error Stack of DTP. Error Stack is physically a type of PSA table, we correct errors in Error Stack, and then we create Error DTP to load changed data from Error Stack to Data Target.

Below are the steps that need to perform to handle data records with errors:

• 
  
  
  Failed status of DTP in DTP Process Monitor because of invalid character in records.
  
• By clicking on Error Stack we can check error records.
  
  
  Total of 3 records with error in source data.
• Correcting erroneous records in Error Stack by clicking edit button on top left.
  
  
  
• Creating Error DTP from the update tab of standard DTP.
  
  
  
  
  
  
  
  Once Error DTP gets created, we can check the status of Standard DTP which is changed from create to display, and can also check the Error DTP under the Object for which we created the standard DTP.
  
  
  
  
  
  
  
  Here is Error DTP:
  
  
• Schedule the Error DTP from Execute tab.
  
  
  
• In the Error DTP process monitor it’s showing 3 records that we corrected in Error Stack in earlier steps.
  
  
  
• We can also check the status of Standard DTP, it’s also Green now (without errors).
  
  
  
• You can also check the records updated status of Standard and Error DTP in the manage tab of data target.
  
  
  
  
  

Error DTP concept is more useful when source of DTP is some InfoProvider (DSO, InfoCube). Try to explore more on Error DTP, and see how it works for you. 

Copying Querys from One Target to Another

Generally we have some times a requirement of the cube name to be changed and as we know that the technical
name cannnot be changed so we prefer to copy all the querys which exist on that cube to the new cube with'
the specified name.and some times we also need to copy queries on cube to cube, or cube to Multiprovider, DSO to
Info  Set.

Here we have two methods of copying queries from one InfoProvider to another (Target Info provider).

1. RSZC: Only rule is that all the characteristics contained in the source infoprovider should also be contained in the target infoprovider (i.e. both the cubes should have same Structure).

2. Using FM: RSZ_I_COPY_QRY_TO_CUBE,  With this you can copy the query even though the characteristics contained in the source infoprovider are not present in the target infoprovider. 

 Note:
1. You cannot copy reports on Infosets. You have to create the reports again on new infosets. The infoset will create new technical names to infoobjects. For example if you have the ZABC info object and your infoset name is ZIS_ABC.your infoobject name will be ZIS_ABC1.

2. You can only Copy the queries from one cube to another but not the workbooks existing upon one cube to another. We need to manually create them. 

Steps While Using Functional Module to Copy the Queries 

--> Display
  

Step:2

Now click on Execute or F8, then will find the below screen

  

Enter the Source cube and the Target Cube, next you need to click on Debugging 

Step: 3See the code and set the break point at   IF l_subrc <> 0 OR l_is_compliant = rs_c_false. (Generally this is 42^nd Line in the code)

Break point is set by double clicking on that 

*Step4:* Now in the same line see l_is_compliant and double click on that and at the right side that can be seen in the below screen

    

Now Click on pencil mark and Enter the value X

Step 5Now after entering x.. get the cursor and click on the break point (Single click)

Simply click on F5 (Key) and It takes you to the code at line 32 ( PERFORM check_infocube_compliance) 

Hope this  content will give the Understanding on how we copy queries from one target to another. 

process chains-A Replacement for RSPCM - Process Chain monitoring from ST13 (/SSA/BWT program)

Before Starting this blog, let us first look at the benefits of monitoring the process chains from ST13 (or /SSA/BWT program) compared to RSPCM transaction. 

Process Chain Monitoring from RSPCM	Process Chain Monitoring from /SSA/BWT
Need to add every Process chain MANUALLY to be monitored in RSPCM	Whenever a Process chain is created it is automatically included on the chain's first run.
Only the LATEST INSTANCE of the process chain will be displayed even if it had run multiple times in a day.	All the instances will be displayed in the given time interval.
Details like whether the Process chain is a Main chain or a Sub chain, End Date/Time, Number of sub-chains, Number of steps in each chain, Number of Failed/In-Progress steps, Total number of errors in the chain will NOT be displayed.	All these details can be viewed here.
The Refresh time will be VERY SLOW if the number of process chains included in RSPCM increases.	The time taken for Refresh is very much faster compared to RSPCM.
Added/Transferred number records will NOT be displayed in the detail view	The number of Added/Transferred records will be displayed against each LOADING/DTP_LOAD step in the first detail view.
The Runtime CANNOT be compared for each step in the process chain.	The Runtime for each step in the process chain can be compared.

In many systems, ST13 authorization will not be given. But don’t worry, follow the below steps.

1) In SE38 (or SA38) transaction, enter the Program “/SSA/BWT” and execute (F8)

2) Select “Process Chain Analysis” Radio button and execute (F8)

 

3) Select “Process Chains” button

 

4) Enter “*” in Chain ID field (or leave it blank). Enter Start Date and End Date.

 

5) The “Process chain Run time Analysis” screen will be displayed. The Log REFRESH is much faster compared to RSPCM. A one stop shop for all the monitoring activities.

 

The “STATUS” shows the overall status of the process chain.

The “STEPS” shows the status of the process steps (Sub-chains, data load step, activation step, Rollup, etc.).

For example, a Process chain has failed in a data load step and then it was repeated and the issue got fixed. The process chain got completed successfully. Then the “STEPS” would be in RED as the data load had failed and the “STATUS” will be in GREEN showing that the overall chain got completed successfully.

By this we can easily track all the chains that got failed and we can know if a chain needs to be corrected or not.
If both “STATUS” and “STEPS” are in RED then the Process chain needs to be corrected.
If “STATUS” is in “YELLOW” and “STEPS” is in RED then still there are chances that there might be some failure in the Process chain and that needs to be looked into.

6) Click the individual process chain under “CHAIN” column. It will take you to the below screen.

7) Now it will show at which step the chain had failed. Click the chain again. It will take you to the Process chain Log, from where the failure can be corrected.

Also, we can get additional information like,
• Start Date / Time
• End Date / Time
• Run time (in Seconds & Minutes)
• Whether the Process chain is a Main Chain or Sub chain
• Number of Sub-chains within the Main chain
• Number of Process steps within each chain
• Number of “Failed” steps (Red)
• Number of “In-progress” steps (Yellow)
• Total Number of errors in each chain

Additional Parameters:

We can even compare the Runtime of each process types in a process chain. To do this, select a process chain and click on "Compare Runtimes" button.

The Runtime for each step in the process chain will be displayed as shown below.

process chains-How To- Trigger subsequent processes in a Process Chain based on the Success or Failure of ABAP program

Sometimes we may have a requirement in a Process chain wherein we need to trigger a process subsequent to the ABAP program, based on whether the ABAP program has status - completed or failed.

The Standard ABAP process type does not offer this option. This can be achieved by creating a custom process type.

Steps:

1)  Goto transaction RSPC and from the Menu, choose Settings --> Maintain Process Types

"

2) The “Possible Process Types” will be in “Display mode”. Switch to “Change Mode”

 

3) Now the “New Entries” button will be displayed. Click the “New Entries” button.

 

4) Create a new custom ABAP process type, say ZABAP – “ABAP Program (Custom Process Type)”.

 Enter the following details.

  

 

For Standard “ABAP Program” process type, the “Possible Events” will be “Process ends “non-specifically””.  

 

 To trigger the subsequent processes in a Process Chain based on the Success or Failure of the ABAP program, we need to change it to “Process ends “successful” or “incorrect””

 

All other parameters will be the same as that of standard “ABAP Program” process type.

 

6) After entering the above parameters, SAVE the process type.

                                  

7) The new Process Type “ABAP Program (Custom Process Type)” will be displayed in the “General Services”.

 

8) Use this Process type instead of the standard “ABAP Program” process type in the Process chain. Now the prompt will be displayed to choose between the following three options.

 A Sample Process chain with the custom process type - “ABAP Program (Custom Process Type)”.

As you can see, if the Test Program is successful, 0MAT_PLANT_ATTR will be loaded.

If the Test Program fails, 0MATL_GROUP_TEXT will be loaded.

RSA3-Extract Checker

RSA3 is a simple extractor checker program that allows you to recognize the problems at source system i.e SAP R/3. It tells you if the extractor works. Since records that get updated into InfoCubes and ODS structures are controlled by Update Rules, you will not be able to determine what is in the InfoCube compared to what is in the R/3 environment. You are not modifying anything, so what you do in RSA3 has no effect on data quality afterwards. The extract checker can test extracted data at the source, allowing you to find data errors/inconsistencies at an early stage, before uploading into BW . If there is something wrong with data in enhanced fields we can check it in RSA3 and correct the User Exit logic there itself, also we can debug the User Exit in RSA3 .


Extract Checker can be utilized in the following ways, i.e

I. Checking the Records
II. Checking the data in R/3
III. Changing the Layout
IV. Setting Filter
V. Selecting the Fields
VI. Selection of Range
VII. Exporting the data from Spreadsheet 
VIII. Exporting the Data through Mail
IX. Debugging the extractor function module

I. Checking the records

1. Goto Transaction RSA3.

2. Enter the technical name of the extractor i.e give the Datasource Name and click on Execute(F8)



DataSource:

A DataSource is an object for retrieving data. The DataSource is localized in the OLTP (R/3).

It has

• an extract structure,
• an extraction type, and
• an extraction method.

The extract structure describes the fields of the internal table that contain the extracted data. The extraction type describes which type of extractor the DataSource uses. The extraction method extracts the data and transfers it into an internal table with the same type as the extract structure.

The DataSource also contains information on the type of data that it stages, for example, attributes, transactional data, hierachies, or texts. It can also support different types of data update.

Request ID: 

Request number for the data transfer
Key number for a quantity of data and control information, that belongs together and has been requested in BW at the same time.
A request consists of data (sometimes split up into several data packets) and additional information about this data.

Data Records / Calls:

Maximum number of table entries in extraction API interface

Update Mode:

Mode of data update (Full, Delta, etc.)
This data element describes the mode, in which an extractor is called from a BW. Depending on the mode, the BW expects the data request to be processed in the extractor in various ways:

Update Mode Types

Mode -> Description 

F -> Transfer all requested data 
D -> Transfer delta since last request 
I -> Transfer initial status for non-cumulative values 
R -> Repeat the last delta transfer 
C -> Initialize the delta transfer 
S -> Simulate the initialization of the delta transfer 

Mode 'R'
This mode must no longer be supported by the extractor under the following conditions:
1. The system has an R/3 Release >= 4.0B
2. The extractor is completely roll back-capable within an extraction process, meaning that no database-commit takes place in the extractor.

Mode 'S'
If an extractor is called in this mode, it is not permitted to deliver any data. Its only job is to make sure that for this request, the delta mode ('D') is possible for any following requests.
Example The extractor uses a time stamp stored in an administration table to determine the delta. In the delta mode, only those records that have been changed or generated since the last extraction are actually transferred. In mode 'S', the current time stamp is included in the administration table, but no data is transferred into BW.


Target System:

Source system of the receiver
System, in which applications run, integrated on a joint databasis.
In the SAP sense, a client corresponds to a logical system. In the definition of a client, you can enter which logical system is a client.
The logical system is relevant for the following SAP areas:
• ALE, in general: Communication takes place between one or more logical systems.
• ALE, distribution scenarios (e.g. cost center accounting): Definition of the system in which a certain application is running. Master data changes, for example, can only be carried out in this system.
• Workflow objects: The logical system is always contained in the key of an object
When maintaining the logical system, please note:
• The logical system must be unique across the group. It may not be used by any other system in the ALE system group.
• The logical system may no longer be changed in the productive system if a non-initial has been entered once. If a non-initial logical system is changed retrospectively then the system's own documents may no longer be found. If the logical system of a document reference does not agree with it's own then the system assumes that the document is in another system.



3. Enter the technical name and execute(F8)



4. Click on Display List

Once you click on Display list, it will show you how many records are there in each data packet

 


5. Double Click on the DataPacket / Records

Once you double click on any particular record, it will show the data it contains.




6. Data is displayed

 


II. Checking the data in R/3


7. Goto Transaction SE11

8. Give the name of the base table and then click on Display

To check the data in RSA3 with data of base table to see whether extraction is happening correctly or not



9. Click on Contents




10. Check for the Number of entries that are extracted depending on the selection criteria eg. Sales document, Document date etc and Execute, the selected entries will be displayed

III. Changing the layout


11. Goto Settings -> Display Variant -> Current




12. You can change the layout by transferring Hidden fields which you require to Column content

Here you can modify your column content and select which fields which you want to be displayed, the fields which are required can be selected from hidden fields and moved to column content




IV. Setting Filter 


13. Goto Edit -> Set Filter




V. Selecting the Fields 


14. Move the fields you want to filter, from field list to filter list

The required fields are selected and moved from field list to filter criteria, so that you can see the fields which you are want to be displayed

 


VI. Selection of Range


15. Select the range you want to display and execute(F8)



VII. Exporting the Data to Spreadsheet


16. Goto List -> Export -> Spreadsheet 




17. Select Table

You will get three radiobuttons, out of which you select Table




18. Select the Microsoft Excel Radiobutton




19. The Data is displayed in Excel Sheet 




VIII. Exporting the Data through Mail


20. Goto List -> Mail recipient 




21. We can load a file in the Document content, click on Load local file

Here we load the file which we want to transport and send the required data to the recipient




22. We can send attachments depending on the recipient type and click on send

Once the file is been loaded we can send the file as an attachment to the recipient intended




IX. Debugging the extractor function module

23. Click the Debug Mode check box

This will take you to ABAP Debugger screen



24. When we select the debug mode check box, we can check the execution of function module on which the datasource is based

Here we can make the changes required on the exit written and check whether the data is correctly populated or not