https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doc...

A Detailed Approach To Purging Oracle Workflow Runtime Data [ID 144806.1] Modified 21-MAY-2011 Type WHITE PAPER Status PUBLISHED

Checked for relevance 21-MAY-2011 PURPOSE _________ This document discusses some important considerations when using the Workflow Purge. It also addresses what to expect and what not to expect from using the available Purge APIs and the Purge Obsolete Workflow Runtime Data concurrent request (FNDWFPR.) SCOPE & APPLICATION ______________________ The approach taken below of purging Workflow data is intended for experienced Applications DBAs. Readers are expected to be familiar with Workflow and the purge process as documented in the Oracle Workflow documentation. Caution may be necessary for some steps. In this case, it is recommended that backups are taken. Overview of Purging Oracle Workflow Data _________________________________________ Introduction _____________ The number of functional modules that make use of Workflow are large, as is the corresponding amount of information retained in certain Workflow tables. Therefore, one of the essential administrative tasks concerning Oracle Workflow is to purge of runtime data that is no longer required without affecting active Workflow processes. This task is performed via Purge APIs and the Purge Concurrent Request. Purge APIs are contained in WF_PURGE PL/SQL package. These offer flexibility to experienced Applications System Administrators to purge obsolete runtime data for completed items and processes, and to purge information for obsolete activity versions that are no longer in use. The use of the APIs requires some knowledge about exactly what tables and Workflow data is involved. The recommended method is to submit the Purge Obsolete Workflow Runtime Data concurrent request. This is performed via the standard reqest submission procedure from within Oracle Applications. The benefit of using this concurrent request is that it does not require as much knowledge about the Workflow tables involved, however, the disadvantage is that the purge request may not purge all expected data. Using a combination of both methodologies is a good option for sites that are heavily using Workflow. There have been cases where a specific functional process, for example, a PO approval notification did not use the correct method for terminating itself. This could caused by not end-dating the Workflow properly, or not setting the correct flag in the Workflow table(s). For whatever reason, the process appears to have run to completion, all users involved received notifications, yet the process remains. This is just one example where Workflow cannot account for the actions of the underlying functional process. Approach to purging Workflow Runtime data __________________________________________ The following steps combined to form one approach that has been used with a fairly good success rate. It is by no means the only method. Since the original writing of this note, the script bde_wf_data.sql has also become available in Note:165316.1. This queries all data that is considered to be eligible for purging. This is a useful and highly recommended script.

1 of 3

04/02/2012 03:44 p.m.

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doc...

1. Submit the Purge Obsolete Workflow Runtime Data concurrent request (FNDWFPR) ------------------------------------------------------------------------------You can do this at any time. This is the first thing to do, as it will purge any and all data related to Worflow processes that have terminated normally. If process data does not get purged using this method, then move on to the next step. Use the standard concurrent program FNDWFPR Purge Obsolete Workflow Runtime Data to purge old data from the Oracle Workflow runtime tables regularly. You can supply the following parameters for the Purge Obsolete Workflow Runtime Data concurrent program: Item Type The item type to purge. Leaving this field blank defaults to purging the runtime data for all item types. Item Key The item key to purge. Leaving this field blank defaults to purging the runtime data for all item keys. Minimum age of data to purge, in days.

Age

2. Run wfstat.sql -----------------From within SQL, run the wfstat.sql script to list any particular process item type that is not being purged. If it returns a status of 'ACTIVE' in the WF_ITEM_ACTIVITY_STATUSES table, yet the WF_NOTIFICATIONS table shows the status for this item as being 'CLOSED', then there may be a problem with how the process was executed. The process may have never run to completion for whatever reason, or it may have terminated abnormally. If only a few are not being purged, try updating the table status, or move on to the next step. 3. Manually update the affected table -------------------------------------Updating the table manually is usually not usually recommended. It is also advisable that you backup the table concerned beforehand. This method should only be used if you know for a fact that all Workflow processes that you know of, have run to completion. It is also a good idea not to launch any new processes prior to this. The scenario might be this - you have a number of processes out there that are not getting purged. One table shows the process as having completed, while another table still shows it as active. The process may or may not have already end-dated as well. You can use the AbortProcess() API to essentially tell the system that this process has finished. It will not check to see if a process has actually finished. It will just stop it right then and there. See the Workflow Guide for specific information about this API. 4. Run wfrmitms.sql and wfrmtype.sql ------------------------------------You can also use two provided SQL scripts to assist in the purge process: $FND_TOP/sql/wfrmitms.sql $FND_TOP/sql/wfrmtype.sql Again, please use these scripts with caution. Any process notifications that the scripts purge by accident will need to be resumbmitted. 5. Final option: manually delete the item -----------------------------------------If all else fails, you can use the following steps to purge even further. Again, this is only to be used when normal purge processes have failed to remove old runtime data:

2 of 3

04/02/2012 03:44 p.m.

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doc...

a) Login to Sqlplus as the Apps user and run the following query: select notification_id, end_date from wf_notifications; This will return all the rows still remaining in the table after having gone through a normal purge process. b) Select one of the remaining ones that have an old end_date and run this query: select item_type, item_key from wf_item_activity_statuses where notification_id = <#> ;this corresponds to the notification_id you picked. This will more than likely return a row. c) Run the next query for your item type: select * from wf_items where item_type = 'item_type' ;this corresponds to the item_type you have That will also have an entry. d) Execute the following procedure to remove all entries related to the item: SQL> execute wf_purge.total('item_type','item_key') e) Run $FND_TOP/sqlwfstat.sql script Specify the item_type, and item_key from step 5.(d). It should return no rows.

f) If the item still shows in table wf_notifications, run the following procedure from SQL: SQL> execute wf_purge.notifications(null,'end_date') Here, either specify an end_date if you have a large number of old remaining notifications, or specify an item_type or item_key. Related Documents __________________ Note.132254.1 Speeding up and Purging Workflow 2.5 and 2.6 Note:165316.1 bde_wf_data.sql - Query Workflow Runtime Data That Is Eligible For Purging Oracle Work

Related Products Oracle E-Business Suite > Applications Technology > Integration > Oracle Workflow Cartridge

Back to top Copyright (c) 2007, 2010, Oracle. All rights reserved. Legal Notices and Terms of Use | Privacy Statement

3 of 3

04/02/2012 03:44 p.m.