What are component type group in Hybris?

Not everything is for everyone. This simple law of nature binds everything together. A polar beer is best kept away tropical area. Your business may want to keep only coordinated banners in rotating image banners. The content slots are bounded to have only few type of components to achieve these restrictions.

Components are grouped on basis of their types. These groups are termed as ComponentTypeGroup. There is one to many relations between this group and the components. They are persisted in database. In earlier versions, the valid component list was used just as macro in impex.

This approach is more optimal than the previous one which had a slow many to many relationship between ContentSlotName and Cms Component type.

<relation code="ComponentTypeGroups2ComponentType" generate="true" localized="false" autocreate="true">
			<deployment table="CompTypeGrp2CompType" typecode="1097" />
			<sourceElement qualifier="componentTypeGroups" type="ComponentTypeGroup" cardinality="many" collectiontype="set"/>
			<targetElement qualifier="cmsComponentTypes" type="CMSComponentType" cardinality="many" collectiontype="set"/>
</relation>

There are few groups which are defined in OOB Hybris. We can also define our custom groups.



INSERT_UPDATE ComponentTypeGroup;code[unique=true]
;logo
;headerlinks
;searchbox
;minicart
;wide
;narrow
;footer
;navigation
;mobile

Each valid component type is added to the group.

INSERT_UPDATE ComponentTypeGroups2ComponentType;source(code)[unique=true];target(code)[unique=true]
;narrow;ProductFeatureComponent
;narrow;CategoryFeatureComponent

When a component type is checked against its validity for a given content slot, the system checks if it is contained in the component type group.

INSERT_UPDATE ContentSlotName;name[unique=true];template(uid,$contentCV)[unique=true][default='LandingPage4Template'];validComponentTypes(code);compTypeGroup(code)

;SiteLogo;;;logo
;HeaderLinks;;;headerlinks
;SearchBox;;;searchbox
;MiniCart;;;minicart
;NavigationBar;;;navigation
;Section1;;;wide
;Section2A;;;narrow
;Section2B;;;narrow
;Section2C;;;wide
;Section3;;;wide
;Section4;;;narrow
;Section5;;;wide
;Footer;;;footer
;TopHeaderSlot;;;wide
;BottomHeaderSlot;;;wide
;PlaceholderContentSlot;;;

Why order is important in items.xml?

We need to follow an order in items.xml, when we declare item types in items.xml. Below are the reasons for it.

  • Each items.xml is parsed in single pass. This means, more specific types are dependent on general types. In such case they should have been defined before we use them. For example,

items

Here we see that, item type product is using other item types, like catalog. To make this file successfully, it is mandatory that catalog exist before product is declared. We must defines types in order of inheritance.

Please note that impex files are parsed in multiple pass, so order is not important there.

  • Each xml file is validated against a items.xsd during build. If the xml file does not conforms to xsd file, build will fail.

Data model of Hybris

The hybris data model is made up of type systems.

A type system is defined as a collection of different itemtypes declared in items.xml. Each item type is consist of a Java class which gives access to different members through getter methods and set the values in them through setter methods. In addition to that, each item type has a database entity (table) associated with it.

Item type = Table + Java class

Like any other data model defining entity, item types gives us the flexibility of defining various data structures including primitive one. An data model may consist of integers, Strings or an complex data structure, with a mixture of everything.

For example, let’s take the example of a Student table, having name and roll number.

Student
Roll number Name
123 Ram
456 Shyam

The above data structure of Student can be simply defined as a Java class called Student and two member variable roll number and name.

Student

The above class will give us utility method to access Student object. This class also defines the data types of its member variables. The same is also necessary to define, while creating the database table Student.

So essentially, we can say that a java class and a database entity is something very basic, to create a world, where a java program interacts with a database entity.

Hybris data model collaborated these two and made us write a single xml file declaratively. This gives us freedom from writing create statements in database and also keeps us free from writing monotonous pojo classes.

In real world, the data structures are not as simple, as depicted in above example, rather they are very complex involving floats, double, integers, Strings, collections, enums and nested objects to name a few.

Hybris data model also support each one of them, and we can define every possible data structure in our items.xml.

Atomic types: The item types which are primitive in java, are called atomic itemtypes. For example, integer, float, double, boolean, Strings etc. They are defined in items.xml as follows.

<atomictype class=“java.lang.String” extends=“java.lang.Object” autocreate=“true” generate=“false”/>

Collection type: They are analogue of generic types in Java. A collection is a group of similiar type item types. Like a group of language used for a particular application could be stored as LanguageList.

<collectiontype code=”LanguageSet” elementtype=”Language” autocreate=”true” generate=”true” type=”set”/>

 

 

Enum types: The group of fixed constants are defined as enums, like any other language.

<enumtype code=“ExportStatus” autocreate=“true” generate=“true”>

<value code=“NOTEXPORTED”/>

<value code=“EXPORTED”/>

</enumtype>

To define a general data structure, like that of Student from above example, we need to define a new item type.

<itemtype code=“Student” extends=“GenericItem”

autocreate=“true” generate=“true”                                      jaloclass=“com.blog.hybrisdiary.core.jalo.Student”>

<attributes>

<attribute qualifier=“name” type=“localized:java.lang.String”>                                                                                                            <modifiers/>

<persistence type=“property”/>

</attribute>

</attributes>

</itemtype>

Here we defined an new item type extending Generic item, which is parent of all item type. This item type has only one attribute, name.

The jalo class, is the class which creates the item Student. This class is auto generated.

Each of the characteristics of an item type is defined as attribute of item type. The attibute itself could be of any type, i.e an atomic type like here (String) or another item type.

Suppose, we have to handle student’s address as well. Now it is not advisable to keep addresses as simple Strings. Since address itself, may consist of house number, street number, town, city, country, and mobile number etc. So we should have a separate entity managing the addresses.

<itemtype code=“Address” extends=“GenericItem”

autocreate=“true” generate=“true”

jaloclass=“com.blog.hybrisdiary.core.jalo.Address”>

<attributes>

<attribute qualifier=“town” type=“localized:java.lang.String”

>

<persistence type=“property”/>

</attribute>

<attribute qualifier=“country” type=“Counry”

>

<persistence type=“property”/>

</attribute>

</attributes>

</itemtype>

Here the attribute country of Address is again of type Country. Since Country can have name, isocodes and regions etc. So we used type as Country for qualifier country.

Now we can modify our Student itemtype to accommodate address as well.

<itemtype code=“Student” extends=“GenericItem”

autocreate=“true” generate=“true”                                      jaloclass=“com.blog.hybrisdiary.core.jalo.Student”>

<attributes>

<attribute qualifier=“name” type=“localized:java.lang.String”>                                                                                                            <modifiers/>

<persistence type=“property”/>

</attribute>

<attribute qualifier=“address” type=“Address”>                                                                                                        <modifiers/>

<persistence type=“property”/>

</attribute>

</attributes>

</itemtype>

Items.xml

The data model of hybris is defined declaratively in items.xml. This file is like the nervous system of Hybris project. Every data definition starts from here. This file can be used to define any data structure used in project.

Below are few important points about items.xml

  • The item type in itself, is of type Item.
  • The instance of item type are stored is item type table, but the item type defination is stored in composedType. For example,for the Student item type, the instances of Student will be stored in Student table, but the definition of Student will be stored in composedType table.
  • Any extension can have a items.xml file to define data model used in extension. But this file is not mandatory to have.
  • The order in which the types are declared is very important. The order in which types are defined must conform to below
  • Atomic types
  • collection types
  • enum types
  • map types
  • relation types
  • item types
  • GenericItem is the default parent of each item type.
  • We can extend one item type using keyword

 

      <itemtype code=”ApparelProduct” extends=”Product”>

                          

                           ********

</itemtype>

 

Here ApparalProduct is extending the Product. This is similar to java inheritance concept. The subclass will have all properties of super class. In our case, all the attribute of super class are available for sub class.

  • Ideally we can define an our custom item type, in any extension. But we should define it in relevant extension only.
  • During build of hybris, the extensions are build with taking care of dependency, it makes sure that the parent item type is available.
  • We can control the access to an attribute using modifiers.

<attribute autocreate=“true” qualifier=“code”                     type=“java.lang.String”>

<persistence type=“cmp”             qualifier=“internalCode”/>

<modifiers read=“true” write=“false”   search=“true” initial=“true” optional=“false”            unique=“true”/>

</attribute>

Here the code attribute, is readable, but not writable. It means it’s value cannot be changed, after it is set once.

read – If false, we cannot access it from our java program.

write – If false, we cannot modify the value.

optional– if false, it is mandatory to initialize this attribute. Since it is not optional.

unique– if true, the attribute must hold a unique value. Similar to unique constraints in DBMS.

search – if true, the attribute is searchable through queries.

  • We can control, how the tables are created for an item type. The default table for each item type is genericitem. The table is called as deployment in hybris. So GenericItem is the default deployment.

<deployment table=“UserRights” typecode=“29”/>

Here the table name will be UserRights. The type code is used internally by hybris to generate primary keys. We can give any positive integer for typecode, barring few reserved integers.

  • If we do not give a deployment tag for a item type, the instances of that item type will get start to store in Generic item table. This will cause generic item table to expand drastically, which is a not good for database performance. So we should always give deployment, if our item type is extending generic item directly.
  • Persistence is one of the property of item type attribute. if this property is set to property, it means that attribute will be stored in database. If it is set to dynamic, the attribute will not be part of database table. It is just calculated at run time. This is similar to calculated column in DBMS.

Extensions in Hybris

Hybris suite is a package of number of business functionalities, like a storefront to checkout products, a platform to provide spring features, a service layer to provide persistence and lot others.

Each of these functionality is available as an isolated java project, which has it’s own data model (if required), its own spring configurations ans properties etc. This grouping of similar functionality into one java project is termed as extension. Below is a snapshot for commerceservices extension from hybris.

ext1

An extension may or may not have a web interface. It may depend on other extensions to fulfill it’s purpose. This information is defined in extensioninfo.xml

The data model of extension is defined in <extension-name>-items.xml file.

The spring configuration for an extension is defined in <extension-name>-springs.xml. It has all bean definitions, dependency injections etc.

Each active extension of your hybris project must find a place in localextension.xml

What is an attribute?

While defining the various properties for an item type, we need to define many things about the property itself.

For example, for customer, mobile number is a property. Now mobile number itself could have many properties. Like whether it is mandatory property? How many digits it will have? Is customer is allowed to change the mobile number?

So basically we need a data structure again for the properties. In hybris the properties or characteristics of an item type are known as attributes. The attribute itself could be of primitive type (like string, or integer) or it could be of type like that of any other item type.

It is defined within the definition of item type in items.xml

it corresponds to column of database.

What is an item type?

Be it a desktop or web application. Be it java or any other technology. Be it small or big size application. Any application works on some kind of data. The data here could be real time exact data like customers, products, promotions etc, or meta data (data about data).

We need to define a data structure for any application. These definitions of data structure contains the meta data about real data. For example, if Ram is a customer. Then name, email, mobile number could be Ram’s actual data, but some where we need to define, what properties of Ram (Customer) , we are likely to keep or interested in our application scope.

Such definitions of anything in application is defined as item type in Hybris. Possible examples are Customer, Product, Promotions, vendors, Categories, Stores etc.

In hybris, the item types, are basically the XML declaration of various data structures used. They are defined in items.xml.

The item type is not just about defining data structure. Hybris also generates POJO classes for each defined item type. They are known as model classes. This class provides getter and setter method for attributes. instanceThe above table shows the approximate analog of item type with Java and DBMS sysem.

Why models are generated in platform extensions?

Hybris is build over the concepts of extensions. Each extension has it’s own data model. Any extension can use an item type from other extension and extend it as per requirement.

For example, the itemtype  product defined in core extension. The catalog extension has extended the product itemtype, and added vendor to it.

While building the hybris, the frameworks builds according to dependencies. Since core is build before catalog extension, it is not aware of the vendor attribute defined in catalog extension. If we keep model class in extensions, then there will e chance of build failures. Like in our case, vendor attribute will not find a place in ProductModel class.

blog1

Hybris build framework, creates model classes, even before, building any extension. The platform is the best place to keep them, as every extension is built upon it only. So it is not logical to create model classes in particular extensions, when we can define same data model in various extensions.

What are Catalog aware item types?

While creating a data model for your project, you might come across situations, where you might want some of your item types to be part of catalog. This means, you want them to synchronize, you want them to be associated with a catalog, content or product. Such item types are known as catalog aware. It’s not just CMS item types or products, that needs synchronization. All OOB CMS items and products are catalog aware.

To explicitly make an item type to be catalog aware, follow below steps:

  • Mark your item as catalog item type, using custom property catalogItemType.
  • Choose attribute from item, which will qualify the  catalog associated using custom property catalogVersionAttributeQualifier.
  • Since each item in a catalog must be unique, we need to choose an attribute from item which is unique. This can be done using custom property uniqueKeyAttributeQualifier.

<itemtype code=”MyItemType” autocreate=”false” generate=”false”>

        <custom-properties>

            <property name=”catalogItemType”><value>java.lang.Boolean.TRUE</value></property>

            <property name=”catalogVersionAttributeQualifier”><value>”catalogVersion”</value></property>

            <property name=”uniqueKeyAttributeQualifier”><value>”code”</value></property>

        </custom-properties>

        <attributes>

            <attribute qualifier=”catalogVersion” type=”CatalogVersion”>

                <modifiers read=”true” write=”true” search=”true” optional=”false” unique=”true”/>

                <persistence type=”property”/>

            </attribute>

Once updating your item type, you should update your platform, using system update.

And you should see something like below in HMC > System > item types > MyItemType > Extended

1

Now, instances of this itemtype will be catalog aware, and would be part of synchronization.

What does partOf modifier means?

In my school, IT department had 5 professors, who taught different subjects of  computer science. School used to manage departments, and professor used to teach. They had their own work life cycles. Everything was so good. But then, school decided to close the department. The professors were bound to loose their jobs. Since they were part of the department. That’s how life is.

When your object is bound to loose it’s existence, when the parent object cease to exist, we say that, child object must have an partOf modifier attached.

For example, An address object is useless, until it is bound to some User object.

Have you heard of cascade-delete in SQL. It describe the same phenomenon.

<attributes>

            ...

            <attribute autocreate="true" qualifier="addresses" type="AddressCollection">

               <modifiers read="true" write="true" search="false" optional="true" partof="true"/>

               <persistence type="jalo"/>

            </attribute>

How to modify attributes of an item type without system update/initialization?

Often we come across the situation, when it is difficult to run a system update, like in production. But still we need to apply some modification at an attribute level.

Hybris has provided Hybirs management console (HMC) , as a graphical tool, which mirrors database in a user friendly way.

Go to HMC > system > type > Search for your item type > Properties.

Here you can apply all sort of modifications you want to do. You can set default values, initial values, mandatory nature etc.

 

23