Quantcast
Channel: SCN : All Content - All Communities
Viewing all articles
Browse latest Browse all 2136

IFBC and the Characterstic Attributes

$
0
0

Motivation

 

From time to time the question arises how the Characterstic Attributes are (automatically) determined during IFBC import. In this document i want to shed some light on it.

 

What are Characterstic Attributes

 

The Characteristics - also known as Marks - have three special Attributes (don't mix them up with the static attributes of a template or the attributes of a channel model from PBT!) which are called Characterstic Attributes. These Attributes control the appearance and behaviour of the Characterstic on the User Interface. These Atributes are:

  1. Field Modifier (Mandatory Field, Recommended Field, Optional Field, Display, Hidden)
  2. Initial Value allowed (yes/no)
  3. Field is Used (yes/no)

 

These attributes do not have a counterpart in msg.PM resulting in the fact that they can not be imported. In principle, the settings have to be made after import in IFBC-UI for each and every template. You need to review and rework new templates (all Characteristics are new) and existing templates (if there are new Characteristics) after each IFBC import.

 

The screen shot below shows where the Characteristic Attributes can be maintained.

Capture001.PNG

 

In order to reduce this manual effort after import, the system performs some rules and determines initial settings for the Characteristic Attributes.

 

How are the Characteristic Attributes defaulted

 

Since msg.PM does not provide Characteristic Attributes which simply could be imported to IFBC, the system performs some guessing based on data from PBT and other properties of current Characteristic.

 

The Field Modifier

 

The Field Modifier is defaulted with the content of the Field "Default" in the section "In-Force Business Configurator Information" on the "Attributes"-tab of an Attribute of a Channel Model in PBT (that's the tab where you also define "IFBC-Relevant" or "Persistence"). If the "Default" field is empty, which happens quite frequently, the system reads the content of the field "Field Modifier" on the same tab. This field usually is filled. The result is one ouf the following list:

  • Mandatory
  • Recommended
  • Optionald
  • Display
  • Hidden

 

If you want to have a look inside the coding, just go to method DETERMINE_CLASSIFIC_CD_REG in class /PM0/CL_ABU_IBC_DST_IMPORT. CLASSIFIC_CD is the internal name of what we call Field Modifier on the UI. This method is the implementation of the logic explained above.

 

The flag Initial Value Allowed

 

Initial Value Allowed is relevant for Display and Hidden fields. In case no default value is configured (Default Settings), the Flag needs to be set to true because entering non initial values is not possible for Display or Hidden fields. This logic makes sense because it makes sure that such a Characteristic (display or hidden, no default value) will not be the cause not to be able to leave a screen and advance to the next screen.

 

The logic is implemented in method DETERMINE_ALLOW_INITIAL_FG_REG in the same class.

 

The flag Field is Used

 

The third Characterstic Attribute, Field is Used, is derived from a couple of properties of current Characterstic. The flag equals true if one out of the following conditions applies:

  • There is a non initial ID of Value Range (List-ID) for the Characterstic
  • It is a non hidden Characterstic
  • There is a non initial Default Settings (Default Value)
  • Ther is at least one Value Range enty with non initial Lower Limit value

 

In other words: if the Characterstic is supplied with some non initial values (Lists, Defaults, Ranges), the product developer wants to make the Characterstic somehow relevant for the template.

 

The logic is implemented in method DETERMINE_RELEVANT_FG_REG in the same class.

 

What is the idea behind the logic

 

Basically it is about presetting the Characteristic Attributes with reasonable values after import of new Characteristics. Keep in mind that the alternative is: setting no Characterstic Attributes at all.

 

The driving use case is the follwing: Imagine you have aready a couple of products in force and you are developing a new product. The new product requires a new Characterstic. You have already maintained the Channelmodel and added the Attribute in PBT. The channel model is used in the other products too. Now you do not want the new Characterstic to 'disturb' the existing products. In other words: by default the new Characterstic shall not show up on screens of old products - you want the Characterstic to be hidden for the majority of your products. Then you chose 'Hidden' for the field "Default" in PBT (see above) and you don't populate the properties "Default Settings", "Value Range ID", "Value Range" for the old products (as you can see you have no effort for the old products!). Then the new Characterstic will be set to 'not used' and you don't have any trouble with the old existing templates (at least from IFBC point of view). For the new template you need, of course, to adjust the Characteristic Attributes. In general the automatic algorithm won't find what you need. So manually overwrite the Characteristic Attributes according to your needs and protect them agains automatic overwriting by explicitly setting the checkbox "Char. Attrib. Import Lock".

 

As you can see, the behaviour is optimzied for the use case after initial setup of products. Keep the existing products and templates as stable as possible and cocentrate on the new development or extension of products.


Viewing all articles
Browse latest Browse all 2136

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>