1) How do you know the version of Hybris that you have in your
machine?
2) What is default username and password for Hybris Solr?
3)
What is Extension?
ITEMS.XML (TYPE SYSTEM):
4)
Define items.xml?
5)
Is it necessarily to follow the specific order in items.xml?
6)
How items.xml works?
7)
Explain about items.xml generated class?
8)
How to add an attribute to the existing types?
9)
Why to set the autocreate to false and
why adding attributes to a Type Directly is discouraged by SAP?
10)
What is Redeclaring the attributes in Hybris?
11)
What is Null decorator?
12) What do know about
Configured Types and Runtime Types?
13) What types of relations
are required a deployment table?
14) When it is not recommended
to use a deployment table?
15) Why do you need to use a
deployment table?
We can check the version in the Hybris administration console.
- Log in with the Hybris administration console.
- Click on Platform.
- Click on Configurations.
- Search for version and the value of build version
2) What is default username and password for
Hybris Solr?
- In Hybris, all authentication and authorization
configuration is stored in the security.json file.
- Below
are the default username and passwords for Solr:
|
User name |
Password |
Description |
|
solradmin |
admin123 |
Admin
user can perform any operation |
|
solrserver |
server123 |
For
communication between server nodes |
|
solrclient |
client123 |
Can
perform search queries |
3)
What is Extension?
- SAP
Commerce has a modular architecture, where new business logic is developed
in separate, function-specific modules called extensions.
- An
extension is an encapsulated piece of the SAP Commerce Suite
ITEMS.XML (TYPE SYSTEM):
4) Define items.xml?
- Items.xml
specifies types of an extension.
- It
contains the type definition in SAP Commerce.
- It is
located in the resources directory of an extension.
- Items.xml files
are prefixed with the name of their respective extension in the form
of extension name-items.xml.
- Example:
- For the core extension, the file name is
core-items.xml.
- For the catalog extension, the file is
called catalog-items.xml.
5) Is it necessarily to follow the specific order
in items.xml?
- Yes,
the order of type definitions must conform to the order as given below, As
it is validated against an XSD file (items.xsd)
- The items.xml defines the types for an extension
in XML format.
- A
type definition order that doesn’t conform to
the items.xsd causes SAP Commerce to fail the
extension build.
- The
basic structure of an items.xml file is as follows:
<items xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:noNamespaceSchemaLocation="items.xsd">
<atomictypes>
...
</atomictypes>
<collectiontypes>
...
</collectiontypes>
<enumtypes>
...
</enumtypes>
<maptypes>
...
</maptypes>
<relations>
...
</relations>
<itemtypes>
...
</itemtypes>
</items>
6) How items.xml works?
- The items.xml file
is parsed and evaluated in running order in one single pass.
- More
abstract types need to be defined more to the beginning of the items.xml file
and more concrete types need to be defined more to the end.
- SAP
Commerce doesn’t allow multipass processing of
the items.xml file (for example, like the ImpEx framework does),
which would allow defining types in any order.
- This means that you need to define types in order of
inheritance.
- Example:
<itemtype
code="ParentType"
extends="Product"
autocreate="true"
generate="true"
>
</itemtype>
<itemtype
code="ChildType"
extends="
ParentType "
autocreate="true"
generate="true"
>
</itemtype>
7) Explain about
items.xml generated class?
The following classes
is generated after the build:
- Jalo Layer: Generates Generated*.java source
files (item classes) for all item types of your extension to
the gensrc directory of your extension.
- ServiceLayer: Generates *Model.java source
files (model classes) for all item types of configured extensions to
the bootstrap/gensrc directory
where * has
to be replaced with item type code.
- For Example: For
item
type FirstType, GeneratedFirstType.java and FirstTypeModel.java files
are generated once the build is done.
- Note: After build, only java changes will reflect but DB changes in Hybris for the new item type will be reflected only after Initialization or Update.
8) How to add an attribute to
the existing types?
There are two methods to add an attribute to existing types.
1. Creating and adding the attributes to the subtype
- Recommended by SAP as it keeps SAP Commerce's
core types untouched.
- You also have an individual Java class available on
Jalo Layer, where you can implement your business logic.
- In this case, you need to set the value of the autocreate element
to true, which lets SAP Commerce create a new database
entry for this type at initialization/update process.
- Setting the autocreate modifier
to false causes a build failure; the first definition of a type
has to enable this flag.
- Example:
<itemtype code="MyProduct" autocreate="true"
generate="true" extends="Product"
jaloclass="org.training.jalo.MyProduct">
<attributes>
<attribute qualifier="oldSize"
type="java.lang.Double"
generate="true">
<persistence type="property"/>
<modifiers read="true" write="true"
optional="true"/>
</attribute>
</attributes>
</itemtype>
2. Adding the attribute to the type directly
- Not recommended by SAP unless you know the
implications and side effects well.
- Where extending a type and using the subtype is
complex or not feasible, it’s possible to extend the SAP
Commerce type directly, such as Product or Customer:
- Setting the autocreate modifier to true results in a
build failure. The value of the generate modifier is ignored.
- Example: <itemtype code="Product" autocreate="false" generate="true">
9) Why to set the autocreate to false and
why adding attributes to a Type Directly is discouraged by SAP?
There are following important
reason:
- As
the type basically exists already, you need to set the autocreate modifier
for the type definition to false:
- Setting
the autocreate modifier to true results in a build failure.
- You
create a direct dependency to an SAP Commerce type.
- Jalo
Layer: The generated methods for the attributes are written into your
extension's manager, but not into the corresponding type class.
- In essence, this means that you have to address your extension's manager class to set values for these attributes.
10) What is Redeclaring the
attributes in Hybris?
You can do redeclare an
attribute for the following reason:
- Change
its behavior.
- Example: you can add a “unique” flag,
or disallow writing.
- Make
the type of the attribute more specific for subtypes.
11) What is Null decorator?
- Null
decorator expression is a ServiceLayer feature
- It
allows to customize the behavior of a getter method.
- Using ‘Null
Decorator’ you can specify a code fragment in an item definition
(items.xml) that computes a result instead of returning null.
- This
assures that the method never returns a null value.
- Example:
<attribute
autocreate="true" qualifier="attr"
type="java.lang.Boolean" generate="true">
<defaultvalue>default_value_for_attribute</defaultvalue>
<persistence type="property"/>
<modifiers read="true" write="true"
search="true" optional="true"/>
<model>
<getter default="true" name="calculated">
<nullDecorator>Boolean.valueOf(false)</nullDecorator>
</getter>
</model>
</attribute>
Generated Method Code:
public Boolean
getAttr ()
{
final Boolean value =
getPersistenceContext().getPropertyValue(ATTR);
return value != null ? value : Boolean.valueOf(false);
}
12) What do know about Configured Types and Runtime Types?
- In terms of persistence, there are two
kinds of types:
- Configured Types - Types that are
defined in an items.xml file.
- Runtime Types - with no
definition in items.xml ; they are only defined in
runtime in Backoffice/hMC.
NOTE:
Hybris
discourages using runtime types for production Envs:
- Persistence aspects
- Runtime Types are as persistent as
all other items, since type definitions are stored in the database as
well. However, when the hybris Commerce Suite is initialized, the entire
type system is discarded and recreated from the contents of the items.xml files
of all extensions.
- As Runtime Types are not backed by a
file, they will be removed and and not be recreated during a system
initialization. In other words: whenever you initialize a hybris Commerce
Suite, all Runtime Types will be gone.
- Lack of Java sources
- As the build process for extensions
relies on the items.xml to generate Java source files, there
will be no Java source files for Runtime Types. By consequence, this
means that you cannot adapt Runtime Types programmatically.
- Since Runtime Types have these
technical limitations, hybris strongly recommends exporting Runtime
Type definitions into an items.xml file.
13) What types of relations are required a deployment table?
- Many-to-Many relation: If a many-to-many relation does not have a deployment table, it's data stores in the links table along with the data from all the other many-to-many relations that don't have a deployment table.
- Of course, you will get serious performance problems.
14) When
it is not recommended to use a deployment table?
- When Item Types already has a deployment inherited from a supertype.
- Technically it's possible but is not recommended because you will get performance issues because the supertype requires a UNION clause with a new table.
15) Why
do you need to use a deployment table?
- All items that don't have a deployment table are stored in the genericitems table.
- It makes the genericitems table extremely large. This makes the database work inefficiently causing performance issues.
- Need to define a deployment table for all item types that extend GenericItem except abstract item type.
Well explained!
ReplyDeletePlease post some questions for CCV2
ReplyDelete