Introduction
Until Focused Build (ST-OST) SP13 release, we were able to configure the extension fields only for the Requirement (S1BR) process type. Starting SP13 release, we can also configure the customer extension fields for all the supported Focused Build application process types.
From SP13 release, we have also made certain changes to the customer field metadata configuration view. In this blog-post, we will explain in detail the functionality of each column in the metadata configuration view and also throw light on the new columns that have been added to the configuration view.
Additionally we will also explain how to generate the text fields that are mapped to the key extension fields and how to perform client side validation for the extension fields.
The below extension fields are supported in the following Fiori Applications:- Requirement Management Application, Generic Application, Mass Change Application, ITSM Application, Project Management Application (Risk), My Test Execution Application.
Configure Extension Fields for all the supported Focused Build application Process Types
From SP13 release, we can configure the extension fields for all the supported Focused Build application process type.
As illustrated below, the Produce Lead extension field has been configured now for all the Focused Build application process type.
We will support the extension field for the following process types along with any custom process types that has been copied from the standard process type.
Customer Field Metadata Configuration View
We have introduced few new columns in the customer field metadata configuration view and also added few validations to certain columns which will be explained below.
- Customer Extension Field Name: This column is used to configure the extension field that is generated using the AET framework. Only the extension fields configured here are displayed in the Fiori applications.
- Field Description: This column is used to display the customer extension field description.
- Filterable: This column is used to enable the extension fields as a searchable property in the worklist application filterbar like Requirement Management and Mass Change application.
- Until SP13 release, we did not have any validation on the filterable property. We could enable any extension field as filterable. However, the search on these filterable properties from the worklist applications would only work if they were search enabled while being generated from AET. This would otherwise cause inconsistency in the worklist filter bar.
- Starting SP13, the filterable property can only be activated for extension fields that are search enabled while they are generated using AET framework.
In the above example, the IT Comment extension field is not Search enabled. Hence, if the user tries to activate the filterable property in the configuration, an error message as shown above is prompted.
- Value Help Type: Currently we only support ABAP elementary search help created for the extension field from SE11 transaction or domain fixed values of the underlying extension field as value help for the extension field. Kindly refer to the blog-post for more details on how to create and configure value help for the extension fields.
- ABAP Elementary search help option – is used to display the supported extension field values in a search help window. This option is preferred when we need to display large set of records as value help for the extension field. Let us illustrate this functionality using the Product Lead extension field.
-
- The Value help as drop down box ( fixed values ) option – is used when we need to display limited set of records as value help for the extension field. This is generally the preferred value help type, when the extension field has an underlying domain with fixed values that needs to be displayed. Let us illustrate this functionality using the Enhancement Type extension field.
- Value Help: This column is used to configure the elementary search help name that is used to render the value help for the extension field. If we are going to use the domain fixed values, we can leave this column blank.
- As illustrated above, the BUPAP elementary search help is used as the value help for the Product Lead Extension field.
- If the Value Help column is left as blank in the configuration and the underlying extension field domain has fixed values, then the domain fixed values are rendered without a need to create an elementary search help. This is illustrated above for the Enhancement Type field.
- Note: Until SP13 release, it was necessary to create an ABAP search help for every extension field to display the value help. Although, the extension field had an underlying domain with fixed values, an elementary search help had to be created. However from SP13 release, we are now able to bind the domain fixed values and display the value help for the extension field without a need to create an elementary search help.
- Note: If a Value Help is assigned for an extension field that has an underlying domain with fixed values, the Value Help takes precedence over the domain fixed values and the values from the Value Help are displayed for the extension field.
- Value Help Field Mapping: This column is used to map the value help key field against the corresponding extension field.
-
- As illustrated above, the Partner field from the BUPAP search help is mapped to the Product Lead extension field. This would thereby, map the Partner value from the BUPAP search help to the Product Lead extension field on making a selection from the value help. For more details on how to create Value Help for extension fields, kindly refer to the blog-post
- Value Help Field mapping column should be left blank if we want to display the underlying domain fixed values as in the case of Enhancement Type extension field that has been illustrated above.
- Value Help Text Field Mapping: This column is used to map the value help text field against the corresponding extension field. Let us illustrate it using the Product Lead and Enhancement Type extension fields.
-
- Assuming we use the elementary search help BUPAP, to display the business partner name for a Product Lead extension field. We would then map the MC_NAME1 field (Last Name field from BUPAP search Help) as the value help text field mapping property. This would thereby, map the Partner Last Name from the BUPAP search help to the Product Lead extension field on making a selection from the value help. If we want to display the Partner First Name as the description for the Product Lead extension field, then we would map MC_NAME2 from BUPAP search help as the Value Help Text Field. In the below example, Engagement Architect (Last Name) for the Partner 133 will be displayed as we have mapped the Last Name of search help as the Value Help Text Field.
Name 1/Last Name from BUPAP Search Help is read to display the text for the Product Lead extension field
-
- In the case of extension fields that use the domain fixed values, the text is automatically retrieved from the underlying domain which is illustrated below for the Enhancement Type extension field. In this case we can leave the Value Help Text field as blank as the description for the extension field is retrieved from the underlying domain fixed values short description.
- Generate Text Field Mapping: This option is used to generate transient text fields that are added only to the OData structure without extending the CRMD_CUSTOMER_H table with text extension fields. The checkbox is used to determine if a text field needs to be generated programatically as a placeholder field to display the description of the underlying extension key field.
There are two ways to generate the Text field. One way is by generating the Text field using the transaction /SALM/CFLD_UXFC_GEN which is the recommended approach from SP13 release and the other approach is by creating a Text field as an extension field. We will discuss both the options below.
-
- Until SP13, we had to create separate Text extension field using AET and bind it as the Text extension field for the underlying Key extension field to display the description.
- This approach is complicated due to additional field that needs to be created for the required extension key field and additional effort required to implement the BAdI to populate the Text extension field value. We have explained what needs to be implemented in the BAdI with a sample code later in the blog-post.
- Further, the creation of a separate Text extension field for every Key extension field would unnecessarily add read only fields in CRMD_CUSTOMER_H table. Hence this is not the preferred approach for creating the Text fields that serve as transition fields (placeholder fields) used to display the extension Key field description.
- Note: The Generate Text Field Mapping checkbox can be left blank if we want to use the AET field as the text field for the underlying extension Key field.
- Generation of Text field has now been simplified from SP13 release.
- We now, no longer need to generate text extension field using AET for the underlying Key extension field.
- We will generate the text properties by activating the “Generate Text Field Mapping” checkbox and by executing the transaction /SALM/CFLD_UXFC_GEN which would only add the required text property field in the underlying OData structure without having the need to extend the CRMD_CUSTOMER_H table with additional extension fields.
- Until SP13, we had to create separate Text extension field using AET and bind it as the Text extension field for the underlying Key extension field to display the description.
- Text Field Mapping: This column is used to bind the text property to the underlying extension Key field and to perform client-side validations on the extension Key field which will be explained later in the blog-post.
We will explain below, how to configure the Text Field Mapping column using two options; one option using the generated text property as the Text Field Mapping and the second option using the AET field as the text field.
-
- Option 1: If we have activated the generate text mapping checkbox for the extension Key field and generated the text property using the transaction /SALM/CFLD_UXFC_GEN, then we enter the generated text field name in the Text Field Mapping column. More details about the program is provided later in the blog-post. We also offer a value help in the customization to select the generated text property for the underlying extension Key field. When the generate text mapping checkbox has been activated, it will not be possible to enter AET generated text extension field as the Text Field Mapping. Let us illustrate this approach for the Enhancement Type key extension field.
The description from the underlying domain fixed value is read (in this case ABAP for AB Key value) and mapped to the generated text property (ZTXT_ZENH_TYPE) which serves as the placeholder text field used to display the key field description. Under the Value Help Text Field Mapping section, we have already shown the list of domain fixed values for the Enhancement Type key extension field which helps to understand the above illustration.
Note: We will explain how the text field is generated using the program in the section “Generate Text Mapping Attributes”.
-
- Option 2: If we have created a text extension field using AET for the underlying key extension field, then the created text extension field is entered in the Text Field Mapping column. Note that this is not the recommended approach to map text fields to the extension fields. The right approach would be to follow the option 1.Let us illustrate the option 2, using the Product Lead key extension field.
As you can see above, the Generate Text Field Mapping checkbox is not activated for the Product Lead (ZZPRODUCT_LEAD) extension field, as we are using an AET generated extension field Product Lead Name (ZZPRODLEADNAM) as the Text Field Mapping. Kindly note that, the AET generated text field (Product Lead Name) also needs to be configured as the extension field. Hence it is necessary to configure both the key extension field and the text field in the Customer Extension field name if we are using the Option 2.
The description (MC_NAME1) from the underlying BUPAP Search Help (in this case Engagement Architect) is mapped to the Product Lead Name (ZZPRODLEADNAM) which serves as the placeholder field to display the key field description. Under the Value Help Text Field Mapping section, we have shown the search help value for the Product Lead extension field.
Additionally, the BAdI – CRM_CUSTOMER_H_BADI needs to be implemented to map the Business Partner last name to the Product Lead Name which is illustrated below. If the BAdI is not implemented, the description for the key field will not be displayed.
Note: The BAdI needs to be implemented only for option 2 and not for option 1.
METHOD if_ex_crm_customer_h_badi~crm_customer_h_merge.
IF cs_customer_h_badi-zzproduct_lead IS NOT INITIAL.
CLEAR cs_customer_h_badi-zzprodleadnam.
SELECT SINGLE *
FROM zproduct_lead
INTO @DATA(ls_product_lead)
WHERE zzproduct_lead = @cs_customer_h_badi-zzproduct_lead.
IF sy-subrc = 0.
cs_customer_h_badi-zzprodleadnam = ls_product_lead-zzprodleadnam.
ENDIF.
ENDIF.
IF cs_customer_h_badi-zzproduct_lead IS INITIAL.
CLEAR cs_customer_h_badi-zzprodleadnam.
ENDIF.
ENDMETHOD.
Generate Text Mapping Attributes
As explained earlier in the blog-post, We can now create placeholder text fields to display the description for the extension key fields without generating separate AET extension fields to display the description. The generation of the Text properties is supported only from SP13 release. Prior to SP13 release, we had to create separate extension fields as Text fields for the respective key extension fields that required description to be displayed. Follow the below steps to generate the text field property.
- We should first activate the “Generate Text Mapping” checkbox for the respective extension field.
- Run the transaction /SALM/CFLD_UXFC_GEN to generate the Text property for the extension key field.
- Note: The above program has to be run each time a new extension field has been added and if a text field needs to be introduced to display the description for the newly created extension field.
- Provide a suitable structure name, package and transport request to generate the Text property for extension fields. The structure is added to the include /SALM/UX_CUSTFLD_TXTMAP_INCL.
- In this example we have entered $tmp as the package just for illustration. You can enter the development package that was used while generating the AET extension fields or the development package used to generate the field control properties. Refer to the blog-post to understand how field control properties for the extension field are generated. On similar lines, we generate the text properties for the extension field.
Note: The above program will only generate the text properties for extension fields that have the “Generate Text Mapping” checkbox activated in the extension field configuration.
Note: If the program text property generation fails, open the include /SALM/UX_CUSTFLD_TXTMAP_INCL, check and fix the errors. Then, manually activate the append structure.
Once the program has been executed, the append structure is added to the include /SALM/UX_CUSTFLD_TXTMAP_INCL which is present in Focused Build Application OData structures that support customer fields. We illustrate this using the Focused Build Generic Application OData Structure.
Note: After the successful generation of the text property, the field control properties for the generated text property also needs to be generated. Hence run the transaction /SALM/CFLD_UXFC_GEN to generate the field control properties for the text properties. Kindly refer to the blog-post on how to generate the field control properties. The field control properties needs to be regenerated each time a new text property has been generated.
Note: We need to clear the OData Model cache so that the Text properties reflect in the OData metadata. Run the Cache Clean up program using the transaction /IWFND/CACHE_CLEANUP. Alternatively, we can run the /IWFND/GW_CLIENT transaction for the respective OData service to clear the model cache. Choose the menu option – Metadata->Cleanup Cache->On both systems to clear the cache.
After clearing the cache, check the metadata. Check if the generated Text properties fields and the field control properties for the text fields are appearing in the metadata. Example ZTXT_ZENH_TYPE is the generated text property and ZFC_TXT_ZENH_TYPE is the generated field control property for the text field.
Client Side (front end) Extension Field Validation
To enable the client side validation, we need to have text fields mapped to the key extension fields. The text fields can be generated using option 1 or 2 as mentioned above, although Option 1 is the recommended approach to generate the text properties for the extension fields.
The client side validation can be performed on all the extension fields that have ABAP Elementary Search Help enabled and text field mapped. Let us illustrate this functionality using the Product Lead Extension field.
Note: If no text field is mapped to the extension field and an incorrect value that is not supported by the value help is entered, the validation is then performed at the server end (backend) and an error message is returned in most cases. In the presence of text field, the client side validation is performed.
if an incorrect value is entered for the extension fields with Value help enabled as drop down box, the extension field value is not saved. No error message is returned in this case.
With that, we have explained the supported process types for the extension field, the new changes introduced in the extension field configuration view and how to generate the text fields, perform client side validations on the extension fields. Also from SP13 release, we do not have to create elementary search help explicitly to display the domain fixed values of the underlying extension field.
Kindly refer to the blog-post on how to enable the Extension Field for Focused Build Fiori Application.
Kindly refer to the blog-post on how to enable value help for the Extension Field from the Fiori Application.
We can also control which extension fields should be editable/ read-only at process type / field level using both the customization and BAdI which will be explained later in a new blog-post. I will see you there again!!
Until then, thanks for taking time to explore the new features that have been delivered in Focused Build SP13 release. If you have questions or suggestions on how this feature could be improved, please provide those in the comments section. Additionally, you can post your questions here
Related Links
Focused Build for Solution Manager
Agile Project Delivery with Focused Build for SAP Solution Manager
SAP CRM Enhancement with Application Enhancement Tool (AET)
Search and Maintain Customer Extension Fields from Focused Build Fiori Application
Configure Search Help for Customer Extension Fields in Focused Build Fiori Application
New Features introduced in Focused Build R2D Fiori Apps in SP13 release
Be the first to comment