Skip to Content

Overview

The tags concept is an extension to the Business Rule Framework in CRM. In transaction SPRO, see SAP Implementation Guide -> Customer Relationship Management -> Financial Services -> Basic Functions -> Business Rule Framework and the various customizing tasks underneath there.

This article aims to give you a brief overview of the tags concept, as well as show you how to apply the concept if you have created your own order item component extensions for a business transaction in the Easy Enhancement Workbench (EEWB). By default, custom components are not catered for, and this article will briefly show you how you can create tags for yours.

Prerequisites

In order to properly understand this article, it will be useful to have a background of the Business Rule Framework, which I unfortunately do not cover here.

Note that we are on CRM 5.0, so you may find that not everything looks or works the same on your system.

Explanation of the tag concept

Tags represent single attributes that are arranged in a hierarchical format, starting with, for example, the order header, cascading down to items, item components and then attributes of components. Each tag is backed by a class that knows how to read data from its parent tag, and returns the value of the attribute it represents.

The classes backing tags each implement interface IF_CRM_BRF_TAG_STACK, which prescribes the necessary methods for implementing a tag’s functionality. (The stack refers to the hierarchy of tags).

The standard CRM delivery provides an implementing class that is used in the predefined application classes for reading information from the tag hierarchy. See for example implementing class 0CRM_TAG_EXP in application class CRM_FS_ORIGINATION in a standard CRM system. The details are as follows:

Class Type F Expression
Implementn Class CL_CRM_BRF_TAG_EXP
Maintenance Class CL_CRM_BRF_TAG_EXP_MNT

Using the tag concept

Steps:

  1. Define a tag in customizing (see path above)
  2. Assign the tag to a parent
  3. Define tag criteria
  4. Create an expression in BRF to read information from the tag

Defining tags

In the customizing step Define Tags, a tag is specified. The runtime attribute is used by the specified class to determine what to read, as it has some meaning that the class will know about.

For example:
a) One order objects are represented by the class CL_CRM_BRF_TAG_STACK_1O_OBJ. The runtime attribute specifies the name of the object as defined in table CRMC_OBJECTS.
b) Attributes of one order objects are represented by class CL_CRM_BRF_TAG_STACK_1O_ATTR. In this case, the runtime attribute specifies the name of the field in the object.

Assigning tags to parents

In the customizing step Define Tag Hierarchies, you assign a tag to a parent. As part of the key, you specify the application class for which the hierarchy is relevant. In the expression (below), you will see only elements from the hierarchy defined for the application class you are editing.

For example, scoring value (tag SCORE) is a component attribute (field) that is a child of the pricing component, represented by tag PRICING. This in turn, is a child of CURRENTDOCUMENT, which represents header and is backed by class CL_CRM_BRF_TAG_STACK_CURRDOC, which implements the logic for reading the order header. (Order item is backed by CL_CRM_BRF_TAG_STACK_ITEM).

Defining tag criteria

Criteria further refine the selection of data tags from the hierarchy. In the case of one-order objects, they represent the key value of fields in the components. They are maintained in customizing step Define Tag Criteria.

For example, tag APPOINTMENT, which can be a child of CURRENTDOCUMENT (order header) or ITEM (order item), is maintained with several values each representing the value of the date type and therefore the key of that entry.

Note: The standard delivery caters for standard one order object components only. See below for information on extending the functionality to cover additional components generated with EEWB.

Creating the expression

Once tags have been defined in customizing and assigned a parent in the tag hierarchy, an expression can be created in an application class using an implementing class for reading tags (see above).

In the expression editor, the tag hierarchy is shown as a tree on the left. You can drag an element from the tree to the right. The relevant branches of the tree, from the root to the relevant expression

Extending the tag concept

Now we get to the real meat of the matter: If you have created your own item components for a business transaction in the Easy Enhancement Workbench, you may want to use tags in the BRF to access the values.

Although the standard classes for One-order object attribute tags do not cater for custom components created via EEWB, the functionality can be extended by copying the class and slightly modifying its functionality.

Note: The class CL_CRM_BRF_TAG_STACK_1O_OBJ cannot be inherited from, as some members are declared private instead of protected, and thus cannot be accessed in descendant classes. As a result, a copy of the class must be made.

In this case, the change we make accomodates custom one order objects by looking for the key field of the object. This will therefore only work for custom objects that have a single field as the key. The name of the key field is then passed to cl_crm_brf_tag_stack_tools=>evaluate, which reads the relevant record based on the key value (which, if you remember, we specified in the tag criteria earlier).

In a copy of the class, change method EVALUATE as follows:
Before

... if sy-subrc eq 0. lv_ref_kind = gc_object_kind-orderadm_h. elseif sy-subrc eq 2. lv_ref_kind = gc_object_kind-orderadm_i. endif. call method cl_crm_brf_tag_stack_tools=>evaluate exporting iv_object_name = lv_object_name iv_object_guid = lv_guid iv_object_kind = lv_ref_kind iv_criteria = if_crm_brf_tag_stack~gv_criteria importing ...

After

... if sy-subrc eq 0. lv_ref_kind = gc_object_kind-orderadm_h. elseif sy-subrc eq 2. lv_ref_kind = gc_object_kind-orderadm_i. endif. * Get the fieldname as key that needs to be checked data: ls_component_info type crmt_component_info, iv_fieldname type crmt_tablename, keyfield type fieldname, records type i. if cl_crm_component_service=>is_generated( lv_object_name ) = 'X'. * get component info cl_crm_component_service=>get_detail( exporting iv_object_name = lv_object_name importing es_component_info = ls_component_info ). * This will only work for custom one-order objects that have a single field * as a key - otherwise, it will just return nothing describe table ls_component_info-keyfields lines records. if records = 1. read table ls_component_info-keyfields index 1 into keyfield. iv_fieldname = keyfield. else. clear iv_fieldname. endif. endif. call method cl_crm_brf_tag_stack_tools=>evaluate exporting iv_object_name = lv_object_name iv_object_guid = lv_guid iv_object_kind = lv_ref_kind iv_criteria = if_crm_brf_tag_stack~gv_criteria iv_fieldname = iv_fieldname importing ...

After making these changes, you use the name of your copied class in the definition of your tag. Then you follow the instructions above to incorporate your tags into a hierarchy and make it accessible in your BRF application class.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply