Hybris Mobile and Desktop Site

Most people face problem in understanding the difference between Desktop site and Mobile site in Hybris and how do we setup the Mobile site and what parameters control the switching of Desktop and Mobile site. Also, how does a responsive site differ from both Desktop and Mobile site?

Technical Difference in terms of UI

First of all, the mobile site differs from the desktop site generally in terms of the UI. The back end code mostly remains the same for both the mobile and desktop sites.

The UI change is controlled by CSS, JS and images.

Also, the UI, which is defined using Hybris WCMS, need to define different Page Template, ContentSlot, ContentPage, ProductPage and the relationship between them for Mobile site and Desktop site.

Technical Difference in terms of Java code

For accessing the UI of either the Mobile site or the Desktop site, we need set the UiExperienceLevel to corresponding device type for which we need to first of all detect the device from which request is coming. This is done using an interceptor i.e. DeviceDetectionBeforeControllerHandler using class DefaultDeviceDetectionFacade and more specifically in SpringMobileRequestDeviceDataPopulator.

After device detection, the detected device needs to be mapped to a UiExperienceLevel (i.e whether it is desktop, tablet, mobile), which is done in class DeviceDataUiExperiencePopulator.

After this the detected UiExperienceLevel is compared with the supported UiExperienceLevel and if matched then DetectedUiExperienceLevel is set to this value.

Parameters controling switching of Desktop and Mobile site

UiExperienceLevel is configured in your properties file using the property “uiexperience.level.supported”.

Please note the correct format of specifying the value for “uiexperience.level.supported” is comma separated Camel Case names like Mobile,Desktop or Desktop,Mobile for the functionality to work correctly.

There is one more interceptor SetUiExperienceBeforeControllerHandler called before the request reaches the controller. This interceptor checks for the parameter “uiel” (like ?uiel=Mobile) in the request and if set its value is used to override all previous UiExperienceLevel.

Based on the UiExperienceLevel set, the corresponding CSS, JS and images are set and we see either the Mobile site or the Desktop site.

Responsive

When we have constructed our website for Responsive UI then the UI automatically adjusts itself according to the device type and this is done because of the responsive JS used. Hybris has made the desktop site responsive hence eliminating the need for separate Desktop and Mobile sites.

Different Views for Electronics Site:

MobileSite
Mobile Site – Non Responsive
ResponsiveSite-MobileView
Mobile Site – Responsive

 

 

 

 

 

 

 

 

 

ResponsiveSite-DesktopView

Desktop Site – Responsive

ResponsiveSite-TabView

Tab Site – Responsive

 

Understanding Cronjobs

A Cronjob is a scheduler where we can schedule a particular Job to be performed at a specified time or over a period of time.

The 3 parts of a Cronjob are:

  1. CronJob
  2. Job
  3. Trigger

For understanding each of these clearly I would take an example:

1. CronJob:

First of all you need to identify what task you CronJob need to do.

In this case lets say that your cronjob needs to send NewsletterEmail periodically with a personalized message.

You would create a NewsletterEmailCronJob item in your items.xml file having attributes for storing a personalizedMessage

<itemtype code=”NewsletterEmailCronJob” autocreate=”true” generate=”true” extends=”CronJob”
jaloclass=”com.email.jalo.NewsletterEmailCronJob”>
<description>Cronjob for sending Newsletter Email</description>
<attribute qualifier=”personalizedMessage” type=”java.lang.String”>
<persistence type=”property”/>
</attribute>
</itemtype>

Now the above code would create the required Model class when you save it and run Ant Build script.

2. Job:

Job is where your business logic goes and it uses the CronJob Model you created as part of CronJob above.

Here you would create a class say NewsletterEmailJob which would extend AbstractJobPerformable and would work on NewsletterEmailCronJobModel.

You would override the perform method to write the business logic in it.

Code Snippet:

public class NewsletterEmailJob extends AbstractJobPerformable<NewsletterEmailCronJobModel>
{

@Override
public PerformResult perform(final NewsletterEmailCronJobModel cronJob)
{

….. Logic for sending News letter Email with Personalized Message ….

}

}

Also, you would define a bean for the above class in your spring.xml file as follows:

<bean id=”newsletterEmailJob” class=”com.email.NewsletterEmailJob”
parent=”abstractJobPerformable” >
</bean>

3. Trigger

Trigger defines the time event when the Job would be executed.

The trigger is linked to the Job via CronJob. You would first create a CronJob item and associate the bean id of the Job to it. Then you would create a Trigger item which contains the CronJob item reference and the time schedule for execution. The time schedule expression is written using Quartz Job Scheduler which can found at http://www.quartz-scheduler.org/documentation/quartz-1.x/tutorials/crontrigger

INSERT_UPDATE NewsletterEmailCronJob; code[unique=true];job(code);
 ;newsletterEmailCronJob;newsletterEmailJob;
INSERT_UPDATE Trigger;cronJob(code)[unique=true];active;year;month;day;hour;minute;second;maxAcceptableDelay;relative;weekInterval;daysOfWeek
 ;newsletterEmailCronJob;true;-1;-1;-1;-1;10;-1;1;true;

What is role of jalosession?

The Jalo layer in hybris is depreacted, not the jalosession.

Whenever a request is made to hybris server, it may need current user details, currency, language, timezone etc to serve that request efficiently. Since HttpSession does not hold all these details, hybris came up with the concept of JaloSession.

Whenever a request comes to Hybris, the filter HybrisInitFilter creates an object of JaloSession. Every JaloSession object is associated with a SessionContext object, which has current user, language, currency etc and the current httpSession object.

  • Cron jobs also run in a JaloSession.
  • Each JaloSession is bound to a tenant. This cannot be changed, after the instance of JaloSession is created.
  • JaloSession is never made persistent in database.

What are ModelAttributes?

Some time it is necessary to get few data in many JSPs, and we don’t want to pass them as a part of DTO (data objects). For example, the titles (Mr and Mrs etc). They can be used in many JSPs and tags file, like registration, delivery address etc.

In such cases, what we do is, create a convenient method in Abstract controllers, and use model attribute annotation for them. In this way they are available from all JSPs directly  using model attribute.

modelAttributes

These can be accessed directly in JSPs or even tag files. like

Current Language : ${currentLanguage}

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