Where outbound Idoc's are concerned: the CDM (customer distribution model) is very powerful. More power could be added by introducing filter control
Description
When working with Idocs the CDM (Customer Distribution Model) can be used to distribute outgoing Idoc messages. Using filtering (all standard SAP so far) certain segments (parts of an Idoc message) or whole Idoc messages can suppressed per message recieving partner. This messaging system is very strong, but we've found the need to enhance it with a bolt-on solution that controls the fields that are used for filtering Idocs. So in effect, the field that standard SAP uses to allow or hold back Idoc messages (or parts of Idoc message) - is populated via "Filter control" - "Controlling what is filtered".
Goal and objectives
The setup allows clear and easy control over outbound Idoc messages, which can be visualized in a report and which can be changed/controlled without development changed being applied. It enhances the overall ease of use of Idocs and will enable your customer to get full control over outgoing Idoc traffic.
The blue print
The objective of the functionality described in this technical design is to facilitate message routing based on the Customer Distribution Model, where standard filter object functionality is not sufficient. This blue print describes a mechanism that uses this filtering on a predefined segment with predefined values. This additional segment is called "Filter control segment". The filter control segment is used to allow more elaborated filtering of which the result is reflected in the filter control segment per receiving system.
CDM filtering can be used to filter out irrelevant data from an Idoc, being single segments, segment groups (a segment with all it's underlying segments) or whole Idocs. Actual filtering is done on "filter objects" to which a set of values can be assigned.
Bold statements
The following set-up is worked out: the CDM determines receivers, and per receiver filtering is used to determine which data should be allowed (out of the box, standard SAP). An additional layer-of-logic can be added, by filling in a special segment with information that can be filtered on: the filter control segment. A few bold statements (as a way of explaining the set-up):
- If a segment is added to another segment of an Idoc, and both minimum number and maximum number are set to 1 (flag: mandatory segment must also be switched on), filtering out the segment will filter out the linked segment along with all it's siblings;
- all Idocs that require the "filter control" approach will have (at least one) filter control segment added in their extension;
- The filter control segment will (only) hold 5 fields that each may contain a logical system name which may receive the Idoc (assumption: Idocs should never go to more than 5 destinations);
- This set-up can be activated/used per receiver/message type/basic type/extension/parent segment combination;
- The receiving system (e.g. MQSI) should ignore the filter control segment, it has no meaning outside of SAP (as it is set up as control mechanism for filtering itself);
- Filtering out the filter control segment (as it is obsolete data to the outside world) is not possible;
- Functionality will be set up to build (fill) the filter control segment, in the form of a function module;
- Function module Z_UX_IDOC_FILTER_CONTROL will enrich internal table IDOC_DATA, with relevant filter control segments (all filled in with allowed receivers);
- The FM will determine where the filter control segments should be added
- The FM will determine which fields (from the Idoc) need to be checked
- The FM will determine which system should receive the Idoc by holding the selection values against a customisable table, the result will be a list of systems that should not be filtered out via Filter control;
- The receiving systems that are determined above will be placed in the filter control segment;
- This set-up is possible for more than 1 filter control segments per Idoc (checking different filter control fields and values);
- Actual values to filter against will be set up in a transparent table with full maintenance capabilities;
- The possible values for any field that can be checked (read: any field in the Idoc on-hand) against RANGE variables (OPTION, SIGN, LOW, HIGH), which allows ranges, negative ranges, patterns, or any other selection possibilities as can be found on SAP's reports;
- A maintenance transaction is build to maintain the above filter control values
- Where different value ranges are given, the selection works with AND;
- Value ranges are set up per group, for different groups the selection works with OR;
Pro's and cons
|
|
Success story
IBM has implemented this solution on their internal Parts system.