One crucial part of the SAP Application Interface Framework is the Interface Determination which allows you to configure what interface should be used for message processing based on the content of a message.
In the SAP Application Interface Framework (AIF) you can use standard types like proxy class, IDoc or XML but you can also define interface determinations for customer-specific engines.
In order to configure the interface determination you will first have to use the transaction transaction /AIF/CUST. Following SAP Application Interface Framework –> System Configuration –> Interface Determination in SAP menu, you will find the following options:
- Define Interface Determination for Proxy Interfaces
- Define Interface Determination for IDoc Interfaces
- Define Interface Determination for XML Interfaces
- Define Interface Determination for Customer-Specific Engines
The main focus of this post is the Interface Determination for IDoc Interfaces. At first, you will define one or more determination keys for the designated IDoc Basic Type – Message Type, which specify an AIF interface. In AIF 3.0 SP02 you can define up to five determination keys. For each key there are three categories available: IDoc Control Record (C), IDoc Data Record (D) and System fields (SY-<name>).
After selecting the fields, you can assign the value to determine the interfaces.
There are various operators to define the value for the interface determination:
- CA - Contains Any Character: Is true if the key contains at least one character from the value for interface determination. The comparison is case-sensitive.
- CP - Contains Pattern: Is true if the key matches the pattern of the value for interface determination. For values of type C, you can use the following wildcards in the value for interface determination:
- for any character string: *
- for any single character: +
- EQ - Equal: Is true if the key equals the value for interface determination.
- MT - Matches (regular expression): Is true if the key contains the regular expression pattern defined by value for interface determination.
Extended information on regular expression you will find here:
In the picture above you can see that the special character “|” was used, which stands for the logical operation “or”. This means that if the IDoc is an inbound one (DIRECT equals 2) and if RCVPRN equals one of the values separated by “|” then the interface ORDUS13_IN, version 1 in the namespace ORDERS will process the corresponding message.
- NA - Not contains any character: Is true if the key does not contain any character from the value for interface determination. The comparison is case-sensitive.
- NE - Not Equal: Is true if the key is not equal the value for interface determination.
- NP No Pattern: Is true if the key does not match the pattern of the value for interface determination. The wildcards and escape characters for the operator CP can also be used. Trailing spaces are ignored and the comparison is not case-sensitive.
All these operators offer a broad range of possibilities and are working well but let’s the take the following business scenario.
One company wants to use the sales organization as criteria for deciding which interface reflects a certain message. The corresponding qualifier for the sales organization in E1EDK14 segment is e.g. “008” and as we can see in following picture the qualifier “008” occupies the third row of E1EDK14 segments.
With AIF standard you will always get the value of the first row of the E1EDK14 segments. In our example with E1EDK14-ORGID as key and “AT11” as value for interface determination AIF will select “AT14” as value. This means that the interface will not process the message in accordance to business requirements.
One existing solution to fulfil the business requirement to split IDocs to different reveivers is described in OSS note 1909791: There you will have to implement the BADI /AIF/RECEIVER_DETERMINATION method SELECT_FROM_MULTI_VALUES:
“In order to determine the correct recipient you have to implement the new BAdI /AIF/RECEIVER_DETERMINATION Method SELECT_FROM_MULTI_VALUES. The BAdI receives the namespace, interface, interface version and the current line of the table as parameter. If the current line contains the required information for the receiver determination parameter RECEIVER_FOUND is required to be set to 'X'. If the current line did not contain the required information the parameter RECEIVER_FOUND is required to be set to blank.
If the BAdI is not implemented the solution works as before. In this case the first entry of the corresponding table is used to determine the receiver.”
This solution was implemented by SAP to be able to handle table elements in IDocs, but works only to select a recipient together with single index tables. So it is a very powerful method, but does not help you in the process step of Interface Determination (where this functionality is missing at the moment).
Since SAP AIF is an ABAP-based framework, it enables us to bring our own extensions. So one way of solving this issue is to find and modify the method responsible for the IDoc interface determination. The name of the method is “/AIF/IF_INF_DET_ENGINE~GET_INF_DET_VAL” and can be found in class “/AIF/CL_INF_DET_ENGINE_IDOC”. Here you can define an Overwrite-Exit which will replace the original method. So you can design your method as you wish - but it is important to keep in mind that the variables or methods could be changed with the next releases, so you might need to adapt your code to the new SAP design. This will be handled via SPAU in the update procedure.
Below there is a quick solution for the described business case. You can use the standard SAP code but add the following variable of type C and change the section for IDoc data record with the code below.
DATA: lv_qualforgid TYPE c length 8.
IF lv_fieldcategory = 'D'.
ASSIGN COMPONENT 'IDOC_DATA' OF STRUCTURE is_input_struct TO <lt_idoc_data>.
ASSIGN lv_psgnum TO <lv_psgnum>.
SPLIT lv_fieldname AT '-' INTO TABLE lt_fname.
lv_lines = LINES( lt_fname ).
lv_check = lv_lines - 1.
LOOP AT lt_fname ASSIGNING <fname>.
lv_tabix = sy-tabix.
IF <fname> = 'E1EDK14'.
LOOP AT <lt_idoc_data> ASSIGNING <ls_idoc_data>.
IF <ls_idoc_data>-sdata(3) = '008'.
lv_qualforgid = <ls_idoc_data>-sdata(8).
EXIT.
ENDIF.
ENDLOOP.
READ TABLE <lt_idoc_data> WITH KEY ('SEGNAM') = <fname> ('PSGNUM') = <lv_psgnum>
('SDATA') = lv_qualforgid ASSIGNING <ls_idoc_data>.
IF sy-subrc = 0.
ASSIGN COMPONENT 'SEGNUM' OF STRUCTURE <ls_idoc_data> TO <lv_psgnum>.
IF lv_tabix = lv_check.
TRY.
CREATE DATA cr_aif_structure TYPE (<fname>).
CATCH cx_sy_create_data_error.
RAISE EXCEPTION TYPE /aif/cx_inf_det_base
EXPORTING
textid = /aif/cx_inf_det_base=>type_not_found
typename = <fname>.
ENDTRY.
ASSIGN cr_aif_structure->* TO <ls_struc_data>.
CHECK sy-subrc = 0.
<ls_struc_data> = <ls_idoc_data>-sdata.
READ TABLE lt_fname INDEX lv_lines ASSIGNING <lv_fname>.
ASSIGN COMPONENT <lv_fname> OF STRUCTURE <ls_struc_data> TO <lv_field>.
<lv_value> = <lv_field>.
EXIT.
ENDIF.
ENDIF.
ELSE.
READ TABLE <lt_idoc_data> WITH KEY ('SEGNAM') = <fname> ('PSGNUM') = <lv_psgnum>
ASSIGNING <ls_idoc_data>.
IF sy-subrc = 0.
ASSIGN COMPONENT 'SEGNUM' OF STRUCTURE <ls_idoc_data> TO <lv_psgnum>.
IF lv_tabix = lv_check.
TRY.
CREATE DATA cr_aif_structure TYPE (<fname>).
CATCH cx_sy_create_data_error.
RAISE EXCEPTION TYPE /aif/cx_inf_det_base
EXPORTING
textid = /aif/cx_inf_det_base=>type_not_found
typename = <fname>.
ENDTRY.
ASSIGN cr_aif_structure->* TO <ls_struc_data>.
CHECK sy-subrc = 0.
<ls_struc_data> = <ls_idoc_data>-sdata.
READ TABLE lt_fname INDEX lv_lines ASSIGNING <lv_fname>.
ASSIGN COMPONENT <lv_fname> OF STRUCTURE <ls_struc_data> TO <lv_field>.
<lv_value> = <lv_field>.
EXIT.
ENDIF.
ENDIF.
ENDIF.
ENDLOOP.
The code above represents a specific solution. This means that the data for ORGID will be selected from the position corresponding to the qualifier “008”, so that the criteria will be fulfilled and the message will be processed by the right interface.
This is one way to quickly solve the problem. A more general approach would be to use a combination qualifier-organization id as value for interface determination. In this way the flexibility will increase significantly without the need to change the code each time you use a different qualifier as the qualifier from which the organization id will be selected is defined by the user through a customizing step.
So based on the proposed solution a more standard and general code can be implemented in order to extend the possibilities of the IDoc interface determination even further.
Please send me updates or comments with your requirements in Interface Determination in order to make the monitoring in SAP AIF more powerful and add significantly great features in comparison to standard transactions like we02 or bd87.
- SAP Managed Tags:
