Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member


Well, when you read the headline, you must assume that currently Document Management (CA-DMS) of the ERP system can produce inconsistent states and unfortunately you are right. Recently SAP published a bug fix. This blog is about to explain details, since the correction is not well communicated by the SAP support.

Quick Action


 

If you run Document Management (CA-DMS) of the ERP and PLM system and use the Knowledge Provider (BC-SRV-KPR) to store your files (originals) on a Content Server, I recommend to execute the following steps:

 

  • Implement Note 1403231

  • Implement BAdI DOCUMENT_MAIN01. In the method      SET_KPRO_UPDATE_MODE add the following source line: set_update_mode = ‘X'.

  • Schedule daily or weekly a job that runs      the program RSIR_CONTENT_UNMARK_PRELIM


 

Background


 

When SAP corrects something after the product is on the market, the change is often poorly documented. This blog shall help you to bring some light into the darkness.

 

When you save a document with a file in the SAP system the data are actually stored in three different layers and two different systems:

 

  1. DMS layer, data are stored in the main SAP      database.

  2. KPRO layer, which carries the metadata of      the file, data are stored in the main SAP database.

  3. Content Server stores the file itself, it      is a new system.


 

When you hit the save button you expect that all data are stored consistent according to the ACID principle. In this Wikipedia article it is mentioned:

 

"It is difficult to guarantee ACID properties in a distributed transaction across a distributed database where no single node is responsible for all data affecting a transaction. Network connections might fail, or one node might successfully complete its part of the transaction and then be required to roll back its changes because of a failure on another node".

 

In 2005 SAP managed to make the KPRO layer in combination with Content Server transactions consistent:Note 810391 - Update capability of the KPro-DMS

 

However like it is mentioned in this note the new update mode only comes into effect when it is explicitly activated by the application utilizing the KPRO layer. One application is Records Management where quickly a correction was provided which changed completely to the new mode: Note 869198.

 

It took four more years until the DMS support provided a proper solution to utilize the new consistent update mode with Note 1403231. And there is a difference: The new update mode has to be switched on explicitly by the customer. Since the SAP support does not deliver new customizing switches after the product was ramped up, the switch is realized by providing a new BAdI method. How to turn on the switch is described above.

 

SAP itself provides info what happens, if you don't change the mode:

 

Note 1302899 - DIR has files which have multiple active content version

 

There is another part that is not properly documented after the new update mode is turned on: When the user deletes a file, due to transactional reasons the file is not deleted directly from the content server but only marked for deletion in the KPRO layer. In the database table SDOK_PRELIM_CONT you can find these documents. Since you don't want uncontrolled growth of your Content Server data, these documents have to be cleared. This can be done by calling the program RSIR_CONTENT_UNMARK_PRELIM which removes all files that are deleted prior seven days.

 

 

 

That's it; I hope I brought some light in this improperly documented topic.

8 Comments
Labels in this area