We discussed the STATUS interface and its impact on the IDoc and work flow item databases in part 1 of this current series about the STATUS IDoc. My basic point is that because the STATUS IDoc is triggered by process code STA1, which calls work flow task TS30000206, it generates a large number of records in the work flow database.

I also pointed out that once the STATUS IDoc posts and updates its outbound IDoc with the current processing status in the EDI system, its job is done and it has no more function in SAP. The same is true for all the work flow items the STATUS IDoc generates. Once the STATUS IDoc updates the outbound IDoc, all these records are just dead weight in the database.

The STATUS interface is very useful when you're using an external EDI system such as Sterling Integrator (SI, formerly GIS). It's used to update the control and status records of outbound IDocs with the status of processing milestones in the EDI system, such as successful or failed translation and/or 997 acknowledgement received.

Standard Work Item Deletion Programs

We also looked at three standard programs that can be used to delete the STATUS IDoc and its associated work flow. These included:

 

• SWWL, which can delete STATUS IDoc work itemes by date range and task TS30000206 (for object type IDOCSTATUS), as illustrated in the screen shot below.
• SWWH, which deletes the work item log. We don't need to run this when we run SWWL.
• WE11, which deletes IDocs by Message Type and date range.

 

 

I pointed out that transaction SWWL, which deletes work flow items, for our purposes can only be run by task. And there are other tasks consumed by the STATUS IDoc that are also used by application IDocs that we may not want to sweep up when we delete the STATUS IDoc.

The only way that you can guarantee that you've deleted all work flow items and history associated exclusively with a STATUS IDoc is by running SWWL by work item ID. But you can only get a work item ID linked to a STATUS IDoc by reading a table, which means custom ABAP code.

We can cut down on the number of IDoc and work flow item records by consolidating all of our status updates into a single STATUS IDoc in the EDI system. The STATUS IDoc is composed of only one data record that can be repeated up to 6,500 times.

But EDI systems don't always allow for such bundling right out of the box. Sterling's SI, for example, ships with a set of standard STATUS IDoc maps that generate one unique STATUS IDoc per outbound IDoc tracked.

Can't Escape Custom Development

But to actually use any of these maps you need to develop a custom Business Process (BP) to translate the control segment of the outbound IDoc to a STATUS IDoc and then send it into SAP through the SAPSuite IDoc adapter. If you want to consolidate your EDI statuses into a single STATUS IDoc, you need to add a custom consolidation map to this status interface BP.

However you cut it, in many external EDI systems such as SI, you can't escape custom development both to use the STATUS interface and to minimize the number of IDoc and work flow records that it generates.

And even if you consolidate your statuses and cut down the number of STATUS IDocs flowing into SAP, if your EDI traffic is heavy and you're recording more than one processing milestone, you can still get a very large number of STATUS IDocs clogging up the database.

But it's easy to write a simple ABAP that uses standard SAP functionality to keep the database clean of the dead weight data generated by the STATUS IDocs. I'll outline the logic and show how you can use three standard function modules to take care of this little house-keeping chore. The functions are:

 

• SWW_WI_DELETE: Deletes all work items by work item ID
• SWW_WI_LOG_DELETE: Deletes work flow history by work item ID
• EDI_DOCUMENT_DELETE: Deletes single IDoc by IDoc number

The key to all three functions is knowing the ID of the object you're trying to delete. You can only get that key from tables. Playing with this logic in a safe development or sandbox system is a great way to learn about the tables behind the work flow database and about how SAP maintains it.

So this is how I would write my utility using pseudo-code:

 

1. Select DOCNUM from table EDIDC into internal table IDOC where MESTYPE equals STATUS and UPDAT between your dates.
2. Select WI_ID from table SWIWIOBJCT into itab IWI_ID where OBJKEY equals IDOC-DOCNUM. Don't forget the leading zeroes in DOCNUM.
3. Loop on IWI_ID. Call function SWW_WI_DELETE by current WI_ID to delete all work item records with for current WI_ID.
4. Call function SWW_WI_LOG_DELETE by current WI_ID to delete remaining log items in history table SWWLOGHIST.
5. When all work items and logs are deleted, loop on itab IDOC. Call function EDI_DOCUMENT_DELETE by current IDOC-DOCNUM to delete each STATUS IDoc.

The beauty of this program is that it deletes all objects by their object ID. You identify all work items related to a particular STATUS IDoc by the IDoc number, which is stored as an object key in the work item database linked to the work item ID. You can then delete all linked work items by work item ID, even picking up records that are not associated with task TS30000206. This would include, for example, task TS30200090 for object type IDOC, which is also called for application IDocs.

SWW_WI_DELETE deletes all previous log records from history table SWWLOGHIST. But the log is updated with two records that record the deletion steps. Function SWW_WI_LOG_DELETE purges these last two records. You don't need to do this step with SWWL because it takes care of it for you by calling this function. But when you run SWWL you don't know the work item ID in advance.

So this is the kind of coding I like to do. Useful little programs that strictly follow the KISS principle: simple and stupid, making my life a little bit easier and my system a little bit cleaner and leaner. Now if only I could apply the same principles to my life. But that's another story for another day.