Chapter 8 : Architecture
This chapter explores the technologies that form the Hybris Platform, the extensions and addons often utilized, localization, security, installation, and recipes.
SAP Commerce comes with a set of extensions that provide standard functionality. A library of extensions can be added as needed, and existing can be removed as needed. In fact, new extensions can be created.
- Extensions can be migrated from one SAP Commerce version to the next.
- Maintenance is only provided for SAP Commerce cloud extensions.
- Even OOTB extensions might need configuration to work properly.
Addons are regular extensions but are installed in a different way. They allow you to extend the SAP Commerce Accelerator front-end functionality. While much of the used technologies are open source, the addons themselves are not.
- Addons commonly used to extend Accelerator frontend functionality
- Addon frontend files are separate from the rest of the frontend files
- Addons are self-contained and don’t depend on other extensions
- Use any combination of addons in different projects
- Essential step for Hybris Extend
- Upgrading Accelerator won’t overwrite your files
- Addons are easily removable
SAP Commerce cloud installer & recipes
Recipes simplify the installation of SAP Commerce Cloud. They utilize automated scripts that take care of all technical details defined therein. Each recipe is used for installing a flavor of SAP Commerce Cloud including the desired applications and accelerators (e.g. B2C, B2B, Telco, and many others).
- A recipe contains all necessary information, including config files, extensions, database, and server information.
- You only need to execute 3 simple but mandatory tasks in console (setup, initialize, start)
- There are many recipes available. Some commonly used ones are b2c_acc (Electronics and Apparel Storefronts), b2b_acc (powertools storefront), b2c_acc_ymkt (Marketing integration), b2c_b2b_acc_oms (All storefronts + order management), and b2c_c4c (Cloud for customer integration).
Products, prices, users, employees and more in SAP Commerce are considered items. All items must have a type.
Navigating to the “types” menu on the navigation pane in back office will open a view that allows you to see the attributes (called properties) of any item. Attributes are divided into those inherited and those belonging to the item.
The Service layer provides support for internationalization (i18n), which can be leveraged to localize. To localize something means to conform the language displayed to that selected by the user or values presented by the browser.
- Type names and their attribute names
- Visible in Backoffice
- Defined in properties files and saved to DB
- Your data values (Itemtype properties)
- Visible in Storefront based on browser-locale
- Defined in *.items.xml
- Values set in Backoffice / product cockpit perspective
Language-specific labels are used for displaying type-names and attribute names
- Used in Backoffice and other cockpits, based on session language (using ISO code value)
Role-Based user management
- System access is controlled by role-based security principles.
- Define different degrees of access and responsibility for each role and assign users to one or more roles.
- Restrict Backoffice access to corresponding manager role.
- Define and target marketing target groups.
- Use LDAP integration for single sign-on and to import accounts & roles.
- Use backoffice to manage users & groups.
System Accounts are created during initialization. They are essential and therefore protected. These are the only three groups created out of the box and they cannot be deleted.
- Anonymous user used for customers who want to perform a guest checkout
- Admin User is a member of admingroup
- Admingroup is granted access to hAC, Backoffice, and all cockpits. They are not subject to rules and search restrictions
Type-Based Access Rights
Users are created with a type, which grants and denies access by the standards of that type. The permissions of the type can be modified, as can the permissions of the users. Access rights are very granular. User management can modify the Read, Change, Create, and Remove access rights of contexts, such as product, employee, or catalog. But they can also modify each at the level of attribute, fine tuning the access rights for each variable of the context. Changes can be imported via impex files.
There are three access statuses. Granted and denied are obvious. Inherited implies that it is the value inherited from the user’s type. Attribute permissions override type permissions.
One limitation is that access changes cannot be fine tuned to the individual items, only item types. Another is that access changes are not effective everywhere, the Service Layer for example.
A special set of factory predefined restrictions and type-based access rights allow easy rights management for common use cases and can be used as a starting point for further customization. But they are not very generic.
- Category – Visibility for certain user groups (such as customergroup), in order to display the categories in the web frontend
- Catalog – Made readable and writeable for certain user groups (such as catalogmanagergroup)
- Language – Made readable and writeable for certain user groups that can have read and write access to several languages.
The SAP Commerce Cloud Platform allows fine control of password handling via password security policies. OOTB regex and blacklist security policies are included. You can also implement your own.
- Password policies can be set in the project.properties file using regex
- Password is required to be between 8 and 128 characters long
- Password cannot be 12345678
- Password changes can be audited. Password changes are items types and are therefore traceable in the Backoffice.
Securing HAC in Backoffice Console
- Configure particular user access to different areas in the SAP Commerce Administration Console.
- Based on assigned riles, users have access to specific HAC tabs or actions
- The HAC provides multiple predefined roles OOTB. You can configure your own roles using Spring Security.
- Roles are represented by userGroup entries in the database.
Other security tools used in Commerce
- Oauth 2.0
- Transparent Attribute Encryption (TAE)
- XSS Filter
- CSRF Protection
- And more…
Cronjobs allow you to schedule and automate myriad tasks in Commerce. Cronjobs are objects that can be run with Backoffice, API, Ant, ImpEx, Webservices, and Scripted CronJob. They contain the Cronjob runtime information, the program logic, and the datatime trigger.
SAP Commerce Cloud provides a Data Validation Framework based on the JSR 303 java validation specification. Data validation ensures that only valid and consistent data reaches the persistence layer.
- It offers an easy and extensible way to validate data.
- Constraints can be created in Backoffice to limit the acceptable value of an attribute. The Error severity and even the error message displayed can be customized at creation.
- Error severity: Error, Warning, Info
- Group constraints, for example the Core Attribute display on a product shows a percent value of attributes completed. A threshold can be set here.
- Only validated data is passed on to the persistence.
- In contrast to the JSR 303 specification, constraints can be created and modified at runtime.
- Data Validation consists of three components
- Backoffice (or Administration Cockpit in older versions) for management constraints
- Data Validation Service for performing validation
- Backoffice/Cockpit Integration For providing feedback to the user
OOTB (out of the box) Constraints
All in the JSR 303 specification (https://beanvalidation.org/1.0/spec/) plus the following
- PastConstraint, FutureConstraint
- MinConstraint, MaxConstraint
- AssertTrueConstraint, AssertFalseConstraint
- IsNullConstraint, IsNotNullConstraint
- NotEmpty, NotBlank
- Dynamic Annotation
Workflow and Collaboration
The collaboration center allows you to collaborate by dividing tasks in the product cockpit based on user roles. It is defined in workflows based on workflow templates. Workflows can be triggered automatically once their trigger condition is activated. For example, creating a product triggers the product approval workflow.
Process Workflow Modeling Comparison
Business Process Engine
Workflow and Collaboration
More on workflow
Once created, the workflow can be viewed in an overview. Those assigned a workflow task will receive notification in backoffice that links to their expected action area. They can complete the task and mark it as such in the workflow panel. This will change the workflow overview display. Only workflow managers can see the entire process. Those assigned tasks can only see the tasks they were assigned.
- Workflows can be created manually but can also be created with CronJobs.
- Tasks can be assigned to users and user groups
- May get real-time notifications via email
- You can comment on the tasks
- Workflow my consist of automated and/or human-based steps
- Templated can be edited at runtime
- Custom templates can be created
- OOTB Ad hoc template
- Complex processes in a company environment (e.g. handling customer complaints)
- Easy tasks in a company environment (e.g. change an image of a product)