We’ve implemented a custom BAdI for duplicate contact checking in our SAP CX 2105 instance. The BAdI works perfectly when contacts are created through the UI extension, but it’s not being triggered during bulk imports via OData service.
Our implementation extends the standard contact validation BAdI:
METHOD if_badi_contact_validation~check_duplicate.
DATA: lv_email TYPE string.
lv_email = contact->get_email( ).
SELECT COUNT(*) FROM contact_table WHERE email = lv_email.
The BAdI fires correctly for UI operations but completely bypasses during OData imports. We’ve verified the BAdI is active and the filter criteria are set correctly. Has anyone encountered similar behavior where custom extensions work in UI but not through OData service calls?
I encountered exactly this scenario last year. The issue is that OData batch operations in SAP CX use a different execution context. Your BAdI needs to be registered with a broader scope. Check the BAdI definition and ensure the ‘Multiple Use’ flag is set, and the filter value includes ‘ODATA_IMPORT’ or similar. Also, the OData service might need explicit configuration to enable custom validations during import operations.
The root cause is that your BAdI implementation is only registered for UI-triggered events. For OData service usage, you need a multi-layered approach:
1. Custom UI Extension Registration:
Your current BAdI works for UI because it’s hooked into the UI event chain. Keep this as-is for interactive scenarios.
2. OData Service Extension:
Implement a custom operation in your OData service definition. In the service metadata XML, add a pre-processing hook:
<Action Name="ValidateContact" IsBound="true">
<Parameter Name="contact" Type="Contact"/>
</Action>
3. BAdI Implementation Enhancement:
Modify your BAdI to handle both contexts. Add a check for the calling context:
METHOD if_badi_contact_validation~check_duplicate.
DATA: lv_context TYPE string.
lv_context = get_calling_context( ).
IF lv_context = 'ODATA' OR lv_context = 'UI'.
DATA: lv_email TYPE string.
lv_email = contact->get_email( ).
SELECT COUNT(*) FROM contact_table
WHERE email = lv_email AND id <> contact->get_id( ).
4. Service Configuration:
In your OData service implementation class (usually extending CL_ODATA_SERVICE), override the CREATE_ENTITY method and explicitly call your validation:
CALL METHOD me->validate_duplicate
EXPORTING iv_entity = er_entity.
5. Filter Criteria Update:
In transaction BADI_DEF, update your BAdI filter to include: ‘UI,ODATA,BATCH’ in the valid contexts.
The key issue is that OData service usage bypasses the standard UI validation chain. By implementing validation at both the BAdI level (for UI) and the OData service level (for imports), you ensure duplicate checking works across all channels. Test thoroughly with both single imports and batch operations to verify the solution works consistently.
This is a common issue with BAdI scope. The standard contact validation BAdI is designed for interactive scenarios. For OData operations, you need to hook into the service implementation layer. Check the OData service definition and see if there’s a corresponding extension point for pre-processing hooks. In scx-2105, these are usually defined in the service metadata as custom operations.
Have you checked the BAdI filter settings? Sometimes the filter criteria need to include the import channel or source type. Also, verify that the OData service is actually calling the contact creation method that triggers your BAdI. It might be using a batch processing method that has different hooks.
We had a similar problem and found that the OData service was configured to skip validations for performance reasons during bulk imports. Check your service implementation class - there might be a flag like ‘skip_custom_validations’ set to true for batch operations. You’ll need to either modify that flag or implement your duplicate check as a pre-processing step in the OData service extension.
I’ve seen this before. OData imports often use a different processing path that bypasses certain UI-level validations. Check if your BAdI is registered for the OData service endpoint specifically. You might need to implement the validation at the service layer rather than the UI layer.