Name: Applying Dynamic Attributes in SAP Commerce Cloud
Uploaded: 2024-4-2
Duration: 643 s
Description: In this video, you will learn about dynamic attributes in an SAP Commerce Cloud type system, how to declare them, and how they are persisted or stored in the database.

Share feedback

<p><u><strong>Planned maintenance of Practice Systems</strong></u></p>

Planned maintenance of Practice Systems

Why create an SAP account?

Enhance your learning experience

SAP Learning

Choose your subscription

Manage your subscription

Live Sessions

Hands-on Practice

Certification

My Learning

Ready to start learning?

<div><div><div>In this video, you will learn about dynamic attributes in an SAP Commerce Cloud type system, how to declare them, and how they are persisted or stored in the database.</div></div></div>

Applying Dynamic Attributes in SAP Commerce Cloud

Hello Everyone, this video is about dynamic attributes.  Normally, we declare attributes to  have property persistence.   In this code example, you see  all of the attributes, id, level, trainerTitle,  startYear, all of them have the persistence type specified as property.   These attributes are hence persisted or stored  in the database, using standard mappings and automatic conversions.  If we examine the model classes,  the attributes’ getter and setter methods are autogenerated with no custom logic.   But, when we need the attribute’s value to be computed or derived at runtime and for the  persistence layer to not handle it, we must specify the persistence type as “dynamic”.   By doing so, automatic persistence in the database does not happen.   Instead, we need to specify an attribute handler,  which references the id  of a specific Spring bean.   This handler bean’s class must implement  the Java interface, DynamicAttributeHandler.   Let’s check the dynamic attribute  example here:   The attribute, “yearsOfExperience” has its  persistence type specified as dynamic.   This setting requires us to specify an attribute  handler, which we specify as the Spring bean,  trainerDefaultYearsOfExperienceHandler,  whose implementation class provides custom logic for handling the attribute value.   Let us look at the steps of implementing a  DynamicAttributeHandler implementation class.   First of all, the class is required to implement the DynamicAttributeHandler Java interface.   This interface allows us to specify  two Java generic types:  VALUE refers to the declared type of the  dynamic attribute, whereas MODEL is the enclosing type containing the dynamic attribute.  The interface also forces our implementation class to implement two methods.  The get() method returns the calculated value of the dynamic attribute, whereas the set()  method takes an incoming value to be used for applying a new value to the dynamic attribute.   For both methods, the model object parameter provides access to all the other attributes  of the enclosing item, on which  the value calculation is based.   Let’s check out an example here.  In Backoffice, I’ll go to Types  and search for Trainer, then click on it to open it in the editor pane.  In the editor pane, I’ll click on the “search by type” icon. In the result-list pane (which displays all Trainer  items), I can create a new Trainer.   Because no Backoffice configuration was  provided for this new type, its Create Wizard not configured to prompt for the newly declared  attributes – only the attributes inherited from its parent type.   I’ll have to just click on Finish, then provide the trainer object’s other values afterwards.  For the new Trainer object, I’ll provide a trainer ID, and set the trainer level to 10.   I’ll set the default English trainer title, and  expand the localized attribute values icon, and (just for fun) also provide a title value for Hindi.   Lastly, I’ll set startYear to 2013.   Let’s check the yearsOfExperience  attribute next.   It is defined to be a dynamic attribute,  with the attribute modifier write set to false,  making it a read-only attribute.   This means, there will be no setter generated  for the model class, as the value is not meant to be specified explicitly.  This is done on purpose, so that its value is always calculated, but not stored.  The calculation logic is contained  in the attributeHandler Spring bean here, so let’s take a look at its Java  implementation class.  We see that the handler class implements the DynamicAttributeHandler interface mentioned earlier, with the get() method  taking the enclosing TrainerModel  object as parameter.   Then, based on the trainer’s startYear  and the current year, a calculated yearsOfExperience value is returned.  As you see, we have Integer as the return type,  which must correspond with this dynamic attribute’s declared type.  Let me change the start year to 2015 and hit Save.   The value of the yearsOfExperience is re-calculated accordingly,  as Backoffice re-reads the attribute  from the underlying object.   After we finish implementing our attribute  handler class, don’t forget to register  an instance of this class as a Spring bean with the correct bean id, as you should have noticed in our demo code.   Let’s look at an example of implementing a  Localized Dynamic Attribute, which is slightly different from normal dynamic attributes.   The xml declaration is almost the same as  before, except that a localized attribute’s type is prefixed with “localized:”.   Here, it is “localized: java.lang.String”.  The reference to the handler Spring bean,  looks the same as before.  The difference, however, lies  in the implementation of the handler class,  as now the class must implement the  DynamicLocalizedAttributeHandler interface.  Here, we must implement two get() methods (having different signatures), which utilize  the internationalization service.   One method assumes the default locale,  whereas the other allows the locale  to be specified.   We recommend some Best Practices  concerning dynamic attributes.  First, we need to pay attention to naming conventions.  Here the recommended format starts with the Type Name, followed by a descriptor for  the implementation class, (“Default”, as it is  the first, standard implementation),  then the attribute name, and finally, the word “Handler”.  You might have noticed that in our earlier demo  code, we defined a class named  TrainerDefaultYearsOfExperienceHandler.  Furthermore, it is recommended to set the id of  the bean instance to match the name  of the handler class except with an initial  lower–case letter.   Another best practice is to avoid redundant  calls of the dynamic attributes’ get()  and set() methods.  This is also a standard Java best practice.  Here, instead of calling the handler’s get() method inside the for loop, move it outside, call  it once, then use only the return value inside.   This approach minimizes overhead.   Yet another best practice addresses how to  handle complex logic.    If your custom logic is very complicated, placing it in the handler’s get() method  forces the overhead of this complex logic  to be unavoidable.   Instead, encapsulate this complex logic into a new, custom service method, which can  be judiciously invoked or bypassed.  As you can see in the green code,  the complicated logic has been migrated  to a service–class method.   This is preferable to the red code below, which  implements the complicated logic inside the get() method of the Dynamic Attribute handler  class, thus making it impossible to circumvent.   The next Best Practice concerns the proper way  to implement read-only dynamic attributes.  Here, we set the attribute’s write modifier  to false.   This prevents a setter method from  being auto-generated in this type’s model class,  but our handle class is still required to  have a set() method, because of implementing the interface.   Therefore, this set() method should be  non-functional and be treated  as “incorrect to call”.  The proper way to accomplish this is to have  this method do nothing and throw an  UnsupportedOperationException in case it is somehow called.   Conversely, it is possible to define a Write-Only dynamic attribute.   But why would we even want a Write-Only Dynamic Attribute?   To improve your API.  E.g., to make co-ordinated changes in related  attributes when one attribute is changing, which  would otherwise be cumbersome or error-prone.  In our previous example, we would have to  manage these two fields independently, in the  absence of a read-only dynamic attribute.  You can observe that, when the startYear  attribute is modified, the read-only  yearsOfExperience attribute is updated  accordingly, eliminating the possibility of errors.   Our final Best Practice involves properly  implementing write-only dynamic attributes.  Here, we can see that the attribute declaration’s “read” modifier is set to false.  Our handler’s get()  method should also throw  an UnsupportedOperationException.   But again, why would we even want to define a write-only Dynamic Attribute?  Let me show you another example of how this could be useful.  In this trainer object, we have these two  boolean attributes: showLevel and showTitle.   The dynamic attribute displayText derives its  value from trainerTitle and level, depending on  whether or not the booleans showTitle  and showLevel are true.  We can set showLevel and showTitle  individually to true, as in this example  in the HAC Scripting Languages console.   After verifying the changes in Backoffice,  displayText derives a corresponding value.  Alternately, a write-only dynamic attribute can  be defined, to allow us to modify  these booleans as a group.  We can define a write-only dynamic attribute,  disableAllShowing.  Here the modifier read is set to false while write is set to true.   Of course, our handler implements the set()  method accordingly and has a get() method that throws an UnsupportedOperationException.  Let me set this attribute as false here and execute the scripts.   We can check the handler implementation here.  As you see, set() takes the inverse of the  parameter value, false in our scripts example,  and assigns it to both showLevel  and showTitle.   Hence, they will be set to true.   So again, back to the original question, why  would we want write-only dynamic attributes?  In our example we only had a group of two  attributes, but what if it was a lot more?   The whole group could be set via  a single method call.  Secondly, we can also add our own custom  logic into a model class.   As you know, model classes in  SAP Commerce Cloud are only generated  automatically via items.xml.   Hence, no custom logic can be implemented.   However, with write-only dynamic attributes  (and their corresponding set() methods),  this becomes possible.   Those are some essentials about how to define  and implement dynamic attributes!  Thanks for watching!