Avoid Pitfalls When DeletingRequests from a BW 3.0B ODSby Andy Slater, Freelance BW ConsultantFebruary 15, 2003

SAPexperts/BISAP has made it much easier to delete individual requestsfrom the ODS in Release 3.0B. The process, however, isnot always straightforward and requires someforethought. The author provides advice for avoidingtrouble based on his own experience.

SAP has restructured the ODS for BW 3.0B. It now providesmuch more functionality for deleting individual data loadrequests from the ODS, while maintaining consistency with thesubsequent data targets. However, the process is notstraightforward or fully automated. You must take care tounderstand and properly follow the sequence of actions tocorrectly perform this task.

I recently had to learn about deleting requests from the ODSusing this new functionality. Now, I'd like to share what Ilearned and make you aware of complications that might arisewhen the data has been activated, and when the data hassubsequently been updated into further data targets. First, letme give you a little background on the relevant changes inBW 3.0B.

In BW 3.0B, the “new data” ODS table of 2.1C(/BIC/Aodsname10 or /BI0/Aodsname10) no longer exists; ithas been replaced by an “activation queue table.” (In theAdministration Workbench monitor, the system actually readsfrom this new activation queue table, /BIC/Aodsname40 or/BI0/Aodsname40, when displaying new data for ODSobjects.) The subtle difference between the two is that thenew table is in the same format as the change log table (itcontains the request ID and is, in fact, a PSA table), whereasthe 2.1C new data table is in the format of the active data (itdoes not contain the request ID). Hence, it was not possible todelete by request prior to Release 3.0B since the requestswere already compressed.

Figure 1 shows the three tables that make up the BW 3.0BODS. Initially, requests are loaded into the activation queue(new data). When those requests are activated, they aredeleted from the activation queue and simultaneously loadedinto the active data table and the change log.

Figure 1

The three tables that make up the ODS inBW 3.0B

Different Scenarios, Different DeletionProcessesBefore you can delete a request from the ODS, you need toconsider its state and location. Three possible scenarios existonce the request is in the ODS:

1. The request has not been activated or updated tothe data targets. This is the simplest case. Therequest exists only in the activation queue, where youcan simply select and delete it.

2. The request has been activated but not updated todata targets. The request now exists in the active datatable as well as the change log. Since the active datatable does not contain the request number, it is notpossible for the system to simply delete the request.Requests activated after the one you now wish todelete present an additional complication.

Deleting an active request that has not yet beenupdated into subsequent data targets is a relativelysimple task from the administrator's point of view: Therequest is selected and deleted. BW then deletes theselected request plus all subsequently issued requests(this deletion is termed “roll back”). It then reloads thesubsequent requests (“roll forward”). This is achievedvia another hidden ODS table (the “roll-back” table,/BIC/Aodsname50 or /BI0/Aodsname50).

3. The request has been activated and updated to datatargets. This scenario is the most difficult casebecause it has the roll-back/roll-forward complicationsplus the issue of maintaining consistency with thesubsequent data targets. Deleting the request from theODS in this case does no good, since it merely deletesthe entries from the active data and change log tables.

It does not put a reversal entry in the change log forbacking out the request from the subsequent datatargets.

In this case, you must first manually delete the requestfrom the subsequent data targets to maintainconsistency with them. In fact, you must also delete therequest that updated the subsequent data target as wellas any subsequent requests in the data target from thissource ODS. Once you have deleted the request andsubsequent requests from the data target, only then canyou reset the data mart status of the requests in thesource ODS (starting with the latest request), and thenfinally delete the required request from the ODS. Theprocess for deleting updated requests follows.

Deleting Updated RequestsYou can see on the Requests tab of the ODS Manage DataTargets screen (Figure 2) whether the request has beenupdated in subsequent data targets. If it has, a green checkmark will be in the Data Mart Status of the Request column.Clicking on one of the green check marks brings you to thescreen shown in Figure 3, which provides details about theselected request.

Figure 2

The Manage Data Targets screen indicateswhich requests have been updated

Figure 3

Details about a specific request

From here, you can click on the monitor button in the fourth

Figure 4

Go to the Monitor screen to see if a requesthas been updated

column from the left. The Monitor screen (Figure 4) showsthat the request has been updated in a further data target.Clicking on the Manage button takes you to the data target,from where you can delete this specific request. Click theManage (data targets) button and then in the next screenselect the Requests tab. Now select the request and click thedelete button.

Once you've deleted the request from the data target, you canthen reset the data mart status in the ODS. Remember, youmust start with the latest request in the ODS first. If you clickon the Data Mart Status of the request in the Requests tabof the ODS Manage Data Targets screen (Figure 2), and ifthis request has been deleted from the data target, you willthen be presented with the option to reset the status so thatthe ODS thinks the request has not yet been updated in thedata target (Figure 5). You should do this working back fromthe latest request in the ODS, up to and including the actualrequest you want to delete from the ODS. Once you havereset the status, the green check mark disappears from theData Mart Status column of the Manage Data Targets screen,as shown in Figure 6 (you might need to refresh the screen).You can now safely delete the request from the ODS.

Figure 6

The green check mark disappears, indicatingthat the request is no longer updated

Note that a number of requests might have been loaded intothe ODS and then together have been loaded as one requestinto the subsequent data targets. The ODS might then containmany requests relating to one request in the subsequent datatargets. If you delete this request from the data target, youmust delete all related requests from the ODS (not just theone you wanted to delete) to maintain consistency.

You can see if requests in an ODS have been loaded tosubsequent data targets as one request by looking at theReconstruct tab on the Manage Data Targets screen andscrolling to the right of the list of requests. You'll see threerequest IDs. Request ID is the number for the load into theODS (and is the same as the first column on the Requeststab in Figure 6). Change log ID is the id of the ODSactivation (and is the same as the fourth column on Requests

Figure 7

An example of how you can see whichrequests were activated or loaded tosubsequent data targets as one

called PSA ID of Request is Generated with Activation).Update ID is the ID of the load into subsequent data targets(and uses the same number shown in the first column of theRequests tab on the Manage Data Targets screen).

For example, Figure 7 shows that request 1032 was firstloaded into the ODS, then activated as request 1033, andfinally uploaded to data targets as request 1034. Requests1036 and 1037 were loaded to the ODS and then activatedtogether in one activation request 1038. Then request 1039was loaded to the ODS and activated in request 1040. Thelast three requests (1036, 1037, 1039) were then uploadedfrom the ODS to subsequent data targets in request 1041.

As well as being aware of the need to delete requests fromthe subsequent data target that have been loaded as onerequest, you also need to bear in mind that the deletion ofrequests is based on the ODS activation request.Consequently, if the request you want to delete from the ODSwas activated in the ODS with other requests, you must alsodelete those other requests. You can see if a request was

Figure 8

Requests that have the same PSA ID wereactivated together

activated with other requests by looking at the PSA ID ofRequest Is Generated with Activation column on theManage Data Targets screen. For example, Figure 8 showsthat requests 771, 774, 775, and 778 have the same PSA IDof 811, indicating that they were all activated together. If youtry to delete request 771 from the ODS, BW 3.0B would insistthat you also delete requests 774, 775, and 778 (Figure 9).

Figure 9

You must delete all requests with the samePSA ID

Figure 10

The sequence of events in which multiplerequests from the ODS were loaded to thedata targets as one

I will now explain the various situations that can arise whenyou might want to delete multiple requests from an ODS thathave been loaded as one to the data targets. Figure 10shows examples of multiple requests that were loaded as asingle request.

In this example, you have a number of different scenarios toillustrate what steps you must take to delete a request fromthe ODS and maintain consistency with the data targets. I'vepresented them below in ascending order of complexity.

1. Deleting request 10 from the source ODS isstraightforward since no data targets have beenupdated.

2. If you want to delete request 7, you must first delete itfrom the InfoCube data target before deleting it from theODS. Since request 7 was loaded into the InfoCubewith request 9, you must manually delete request 9

Figure 11

Message displayed when you try topematurely delete an updated request

from the data target. However, this delta request 9 alsocontains the data loaded into the source ODS inrequest 8. Therefore, after deleting request 9 from theInfoCube, you must delete both request 7 and request8 from the source ODS. (Remember that whenselecting requests 7 and 8 for deletion from the sourceODS, BW also deletes the subsequent request 10 andthen reloads it.)

Warning!If a request has been updated into a data target and you tryto delete it from the ODS before removing it from thesubsequent data target, you will receive the cryptic messageshown in Figure 11. It is an important warning not toproceed. If you continue, BW will deactivate the deltaloading of requests from the ODS to the data targets, andyou will no longer be able to update them! The only way torecover will be to delete all data from the data targets andreinitialize from the ODS. This is a time-consuming task inproduction, so make sure that you delete the request fromthe data targets first.

1. To delete request 2 from the ODS, you must first deleteit from the target ODS and InfoCube. You also need todelete all later updates—requests 3, 5, 6, and 9—to thesubsequent data targets. Once the requests are deletedfrom the data targets, reset the Data Mart Status inthe ODS in the reverse order of the requests: 8, 7, 4,and then 2. Once this is done, it is possible to deleterequest 2 from the ODS. The system will actuallydelete requests 10, 8, 7, 4, 2, and then, if possible, rollforward requests 4, 7, 8, and 10.

Sometimes roll forward is not possible, and you will see thepop-up window shown in Figure 12. It shows that where MIN,MAX, or MOVE aggregation is used in an ODS object, it iseven harder to delete requests. In fact, the only way to do sois to delete the request you want plus all later requests. It isnot possible to roll forward later requests and re-add them. Ifyou have not used MIN or MAX, click on OK and then re-add

Figure 12

This pop-up window appears when the ODSobject uses MIN, MAX or MOVE aggregation

the requests you want to keep.

It is very important to understand the significance of thisrestriction. You might assume that the restriction only appliesto key figures, since characteristics are not accumulated anddo not have MIN or MAX aggregation. However, the restrictionalso includes characteristics. If you have a characteristic aseven one of your ODS data fields, then the update rule for thecharacteristic is only allowed to be set to “overwrite” (MOVE).In Figure 12, you will see that MOVE prevents automatic rollforward. Since most ODS tables contain characteristics in thedata fields, this severely reduces the usefulness of 3.0B'sability to delete requests.

NoteThe Update type in the update rules for key figures inODS objects can be set to Addition, Overwrite, or Noupdate. It is a little-known fact that Addition can mean oneof the following three types of aggregation: summation,minimum, or maximum, depending on the aggregationbehavior defined in the key figure InfoObject definition. It isoften assumed that the aggregation behavior defined in theInfoObject maintenance only affects the reporting behaviorand not the data staging. This misunderstanding may becaused by the F1 help text for aggregation in the InfoObjectmaintenance screen, which states “This field determineshow the key figure is aggregated in the Business Explorer.”However, the F1 help text for update type of the ODSupdate rules clearly describes how the setting in theInfoObject maintenance also affects the update within theODS in the special case of minimum and maximum.

Of course, it is possible to manually set the status of therequest you deleted to red and then manually re-addsubsequent requests. This circumvents the restriction butinvolves more work.

Alternative Method of Removing

Requests from the ODSI've shown you how to delete a request from the ODS in BW3.0B, but it is still possible to use the earlier method ofRelease 2.1C. With previous releases of BW, you had to backout data from an ODS that had been incorrectly loaded. Manypeople created a “reversal” flat file, which contained the sameloaded data but with the key figures multiplied by -1 (wherekey figures are set to “addition” in the update rules), or withthe key figures set to zero (where the update rules are set to“overwrite”). The flat file was then loaded as “normal” to theODS. This set the key figures in the ODS to zero, and theload automatically generated the necessary changes in thechange log to keep the subsequent data targets consistent.

Depending on your situation, it might still be easier to followthis path than to use the new features to delete individualrequests. For example, various local companies might submitflat files for loading to a global system. One company thenrealizes it submitted the wrong figures, and so you have toback out the loaded file. However, several other companies'files might have subsequently been loaded. You could use thenew method in BW 3.0B to delete the incorrect file, butbecause of the roll-forward restriction (not automaticallyperformed when you have a characteristic as a data field inyour ODS), you will probably have to manually reconstruct thelater files. An easier and quicker solution is to just load areversal file for the company that submitted the wrong dataand then load the correct submission.

You might assume that reloading a correct submission willoverwrite the previous file, and generally this is correct.However, the wrong file might contain records not on thecorrected file, and these records would not be overwritten bythe corrected file. For this reason, you must set all values inthe ODS from the wrong file to zero (using the reverse file)before loading the corrected file.

Obviously, the type of aggregation is also important here,since this method works with the SUM aggregation method. Ifthe aggregation is MAX, the update of the key figures in anysubsequent InfoCube is affected. For instance, if the wrong filecontained a record with value 999, and this was the highestvalue for a particular characteristic combination, then theInfoCube will contain the value 999. Any other records with avalue lower than 999 will not affect the value in the InfoCube(since it stores the maximum of all values). In this case,loading a reverse file will not work since it will contain either a0 or -999 value. Because these values are lower than 999, theInfoCube ignores them and keeps the 999. Consequently, youhave not backed out the incorrect data.