When working with system integration, we often receive business requirements where customer do not want to replicate all their information from one system to the other, so there is when filtering becomes necessary.
Systems such as C4C, ERP and CRM should hold business logic and not Middleware (in order to minimize dependencies), however we should analyze where to apply each filter, depending on each particular case.
The aim of this document is to explain an overview of the ways to filter data exchange for specific objects from ERP into C4C and, vice versa. This document should help consultants to define whether they can solve their business requirements through this method or, to research for other alternatives.
When requirement is to filter objects to flow from C4C into other systems, this has to be managed through Scoping under Business Configuration workcenter. A common example for this is when customer requires not to replicate Prospects from C4C into ERP. As said before, this is being done through Scoping questions:
When requirement is to prevent objects (such as Accounts or Materials) from being replicated into C4C, SAP provides some standard filters which can be accessed and configured through BD64 transaction.
When requirements is to filter Accounts, the filter will be put over DEBMAS_CFS message type and the available filters are the following: Account Group, Country Key, Postal Code, Region, Global Code, Credit Control Area, Function, Division, Sales Organization and, Distribution Channel.
When requirements is to filter Materials, the filter will be put over MATMAS_CFS message type and the available filters are the following: Language Key, Material Group, Material is configurable, Competitor, Material Type, Division, Plant, Storage Location, Valuation Area, Warehouse Number, Sales Organization and, Distribution Channel.
In the following screenshot, you can see an example where Acconts are being filter through Acconut Group and, Materials by Material Group:
Something which is very important to highlight is that consultants should include those values of filters which want to be taken into account which means that values which are not mentioned under this filters, will be ignored and not replicated into C4C. Filters are inclusive and not exclusive.
In case it is required to filter with other criteria, it is possible to implement BAdI IDOC_CREATION_CHECK but be aware that code should be very specific and restrict any other scenario as this could affect normal behavior of the system. Also, there is a second BAdI for preventing Change Pointers from being written which is BDCP_BEFORE_WRITE. For sure, it is highly recommended to use delivered filters, when possible, instead of using BAdIs.
As mentioned in the Introduction, it is a good practice to avoid including business logic on Middleware. In addition to this, imagine system has a huge amount of records which will be passed into PI/HCI (as IDOCs) and will be filtered out there consuming resources; this should have been done definitely on the source system and not in the Middleware.
I would only recommend to apply filters in Middleware if delivered filters and BADIs do not satisfy business requirements.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
3 | |
3 | |
1 | |
1 | |
1 | |
1 |