Custom BAdI implementation in document management fails to trigger on archive

PLM SAP PLM
, , , , , , , ,
1

We’ve implemented a custom BAdI for document archiving in SAP PLM 2020 to add compliance metadata before documents are moved to the archive. The BAdI implementation class is active and the filter configuration looks correct in transaction SE19, but the enhancement point is never triggered during the archiving process.

The BAdI should handle PDF and TIFF MIME types specifically, adding regulatory classification tags. Here’s our filter configuration:

FILTER_TYPE = 'MIME_TYPE'
FILTER_VALUE = 'application/pdf'
IMPL_CLASS = 'ZCL_DOC_ARCHIVE_BADI'

When we archive documents through CV01N, the standard archiving completes successfully, but our custom logic never executes. The implementation class has the IF_EX_DOC_ARCHIVE_BADI interface properly implemented. We’ve verified the BAdI definition is enhancement spot DMS_ARCHIVE_ENHANCEMENT, but something in the filter configuration or enhancement implementation chain seems broken. Has anyone encountered similar issues with document management BAdI filters not being evaluated?

2

The enhancement spot DMS_ARCHIVE_ENHANCEMENT might not be the right one for CV01N archiving. That enhancement point is typically for content server archiving, not the standard SAP archiving object. For document archiving through CV01N, you need to check if you’re using the correct BAdI definition. Look at BADI_ARCHIVE_DOCUMENT instead. Also, document MIME type handling in the filter needs to match the internal representation - SAP sometimes stores MIME types in uppercase or with different delimiters.

3

Adding to what others mentioned - I had a similar case where the BAdI wasn’t triggering because the archiving scenario wasn’t configured to check for enhancements. In SPRO under Document Management System, there’s a configuration node for archiving scenarios where you need to explicitly enable BAdI processing. Without this flag set, the system bypasses all enhancement points for performance reasons during mass archiving operations. Check table TOASP for your archiving scenario and verify the BADI_ACTIVE flag.

4

Check if the BAdI is actually registered for the document class you’re archiving. In SE19, verify the filter criteria matches not just MIME type but also the document type (DOCTYPE) being processed. Sometimes the filter chain requires multiple conditions to be met before the implementation is called.

5

I’ve dealt with this exact problem multiple times. The issue is almost certainly in your BAdI filter configuration and enhancement implementation approach. Let me walk through all three focus areas systematically:

BAdI Filter Configuration: The filter you’ve defined is incomplete. For document management BAdIs in SAP PLM 2020, you need a compound filter that includes both MIME type and document type. The system evaluates filters using AND logic, so a partial match causes the implementation to be skipped:

* Correct filter definition in SE19
FILTER_TYPE = 'MIME_TYPE'
FILTER_VALUE = 'application/pdf;image/tiff'
FILTER_TYPE2 = 'DOKAR'
FILTER_VALUE2 = 'DRW;CAD;DOC'

Document MIME Type Handling: The MIME type comparison in the BAdI framework is case-sensitive and uses exact string matching. SAP stores MIME types in lowercase internally, but the archiving API sometimes passes them in mixed case. Your implementation needs defensive MIME type checking:

METHOD if_ex_doc_archive_badi~before_archive.
  DATA: lv_mime TYPE string.
  lv_mime = to_lower( iv_mime_type ).
  IF lv_mime = 'application/pdf' OR lv_mime = 'image/tiff'.
    " Add compliance metadata
    ev_classification = 'REGULATORY_DOC'.
  ENDIF.
ENDMETHOD.

Enhancement Implementation: The critical issue is that DMS_ARCHIVE_ENHANCEMENT is for content repository archiving, not CV01N archiving objects. You need to implement the correct BAdI definition. For CV01N-based archiving, use DOCUMENT_ARCHIVE01 with the ARCHIVE_PROCESS enhancement spot. This is the proper hook point for document archiving workflows.

Additionally, verify in transaction SE18 that your implementation is assigned to the correct enhancement spot. The implementation class must be explicitly activated (not just the BAdI definition). In SE19, use the “Where-Used” function to confirm the enhancement spot is actually called by the archiving program RSARCH01 or your custom archiving variant.

One more critical point: if you’re using a custom archiving object (defined in AOBJ transaction), you need to register the BAdI in the archiving object’s preprocessing exit. Standard SAP archiving objects have predefined enhancement points, but custom objects require explicit BAdI registration in the ABAP archiving program.

Finally, enable BAdI trace in transaction SADT to see if the filter evaluation is even being attempted. This will show you exactly where the filter matching fails. In most cases I’ve debugged, the issue was either wrong enhancement spot selection or missing compound filter criteria. Fix these three areas and your compliance metadata injection should work correctly.

6

Thanks for the suggestions. I checked V_ENHBADI and the implementation is marked as active. The filter value is stored as ‘application/pdf’ exactly. I tried removing the filter temporarily to see if the BAdI gets called at all, but even without filters, the implementation method isn’t being triggered. This makes me think the issue is with how the enhancement spot is connected to the archiving process rather than the filter configuration itself.

7

I’ve seen this exact behavior when the BAdI filter is too specific. The document management archiving process in SAP PLM evaluates filters in a specific sequence. If your filter only checks MIME_TYPE without considering the document status or archiving scenario, it might be skipped. Try broadening the filter to catch all documents first, then add your MIME type logic inside the implementation method. Also verify in table V_ENHBADI that your implementation is active and the filter values are stored correctly. The filter framework can be tricky with special characters in MIME type strings.