SAP Hybris E-Commerce Training

Upon the completion of this course trainee will be able to:

• Gain fundamental knowledge of hybris software.
• Understand the procedure to develop and customize various areas of Hybris
• Master the Hybris offerings and configuration process
• Understand Hybris platform and Data hub.

To learn this technology you need to have a basic knowledge of e-commerce and wen technologies. You should also have working experience in gap analysis and requirement gathering.

According to indeed.com the average salary received by a Hybris professional ranges between $55,786 to $148,829 based on the roles. In India the compensation ranges between Rs 405,470 - Rs 2,154,609.

Below mentioned are the few job roles available for an SAP Hybris professional.

• SAP Hybris Analyst
• SAP Hybris Consultant
• SAP Hybris Developer
• SAP Hybris Marketing Consultant

Following are the professionals who get benefited from learning this course.

• Business stakeholders
• Functional consultants
• Project managers
• QA managers
• Business analysts
• Testers

At the end of the training you will be awarded with the SAP Hybris course completion certification from SK Trainings’s.

• Basic Configuration
• Hybris Building Blocks
• Hybris Logical Architecture
• Final Architecture Diagram

• Java Setup
• Installing hybris Multichannel Suite
• Inside Hybris Software
• Hybris Server
• Folder Structures
• Default Tables/Users
• Eclipse Integration

• Java Setup
• Hybris Administration Console
• Back office

• Commerce Introduction
• Installing & Upgrading Accelerator
• Core Accelerator
• B2B Accelerator
• B2C Accelerator

• Cockpit Basics
• Product Cockpit
• WCMS Cockpit
• Smart Edit
• Customer Service Cockpit
• Import Cockpit

• hybris Catalog Basics
• Catalog Management Tools
• Catalog Version
• Catalog implementation

• Introducing hybris Type System (Data Modeling)
• Relations
• Extension Internals
• Extgen
• Modulegen

• End – End Workout

• Promotions
• Vouchers
• Product Reviews
• Promotions Groups

• Architecture of the Service Layer
• Services,
• Spring Integration
• Facades, DTO & DAO
• Models
• Interceptors
• Events

• ImpEx functional overview
• ImpEx syntax overview
• Performing imports and exports (hAC, Backoffice, API)
• hotfolder

• Understanding
• Different Tabs
• End-End Workout

• Introducing CronJob
• Implementation with Jalo Layer

• Dynamic Attribute Overview
• What is Converter and Populators
• Applicability of Converters and Populators
• Introducing Interceptors

• Key Benefits WCMS
• What’s part of this module
• CMS cockpit

• SamrtEdit Features
• SmartEditArchitecture
• personalization

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.

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 Product Model class.
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 extension.

Yes, if you have used APIs, flexi search in a right way. If you have used pagination in your flexi search and converter caches than it will not matter how much SKUs you have.

Mostly configuration until you has not done your own customizations. Even you can expose your custom elements to hmc and from there you can also change your configuration on the fly.

Spring security is integrated OOB.

Yes, recently introduced as an offering

Very soon Hybris will be on top of these because of its simplicity.

Lot many promotions are available out of the box and you can extend their framework very easily to introduce your custom promotion.

Whatever you want….pre-integrated ActiveMQ on tomcat is available for messaging. Restful web services frameworks are available OOB.

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,
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.
NOTE: 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.

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.
These can be accessed directly in JSPs or even tag files. like

Current Language : ${current Language}
Model service create method vs new operator
When we try to create a new instances of an item type programmatically, we have two options, using the java way, using new operator or the hybris way, using the model service.
ProductModel product1 = new ProductModel();
ProductModel product2 = modelService.create(ProductModel.class);

• The model service create method will generate and assign the pk for product object.
• The create method will initialize the default values, defined in items.xml for mandatory attributes.
• While calling save all method, the object is already attached to context, and will be saved. While product1 needs to attach explicitly.

While fulfilling an order, some time it is necessary for business to split the order into multiple orders.
For instance, a customer orders two items A and B, now A has delivery window of 2 days, while B can be delivered in minimum 5 days. Now business has the option to either ship both items in 5 days. But what if item A is fresh, and will get destroyed in 5 days. There may be a case, where customer wants a mandatory delivery of item A within 2 days. In such situations, if business house doesn’t want to loose customer, it has no choice but to split order and ship it multiple times. This is the case of split consignment.
Now there may be various conditions, which may call for splitting the order into multiple consignments. Above example is just one of them. For example, we may want to split consignment, based on warehouse from where item will be picked up. We may want to split consignment, based on product type (fresh or ambient) etc. These situations which decides the business logic to be a case for splitting the consignments, are known as splitting strategies. We can have as many as strategy to split, as we want.
By default, hybris creates only one consignment for an order. This is done by following service.
As you can see, that the order Splitting Service accepts a list of strategies, we can create many strategies, and split our order. The actual business logic for splitting will go into strategy class.

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 catalog ItemType.
• Choose attribute from item, which will qualify the catalog associated using custom property catalog Version Attribute Qualifier.
• 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 unique Key Attribute Qualifier.

        
            java.lang.Boolean.TRUE
            ”catalogVersion”
            ”code”
        
        
            
                
                
            
 

It will depend but highly feasible. Their data import process is very much flexible. Once data mapping is done it is easy to migrate.

Actually if you know spring and has concept of basic ecommerce than not much effort required to learn Hybris platform. You need to be familiar with impex and flexi search syntax but plenty of examples are available to learn this

Yes, their PIM module is meant for this.

• No, if your site is very much specific to content management and you want to manage specific version of -individual content than wcms is not the right solution for you.
• Otherwise it has all features that are required for an ecommerce application.