ROA_general_gerneric_Template.png

Check your email or visit Credly to claim and share this badge

View on Credly

Go to My Home

Congratulations

Certificate_icon.png

By completing this SAP Learning Journey, you are now prepared to book your certification exam.

Congratulations!

Mountain_White_background.png

Exploring the Technical Essentials of SAP Commerce Cloud

Congratulations Modal

cleanFiles/bookmap_SAP_Commerce_Cloud_Essentials_for_Develope_en-US_learning-sap-com_lsc-prod.zip (MMCP-DROPZONE) - 2023-10-23T13:02:50.000Z

Data Conversion Process

<div id="content"><p tabindex="0">Now that you understand how DTOs are managed, it’s time to look into how to customize the data object conversion process before they reach the frontend layer?</p><p tabindex="0">Let’s look at just that in the following video:</p><div class="kalturaVideoLessonWrapper"><div id="1_hfrbfyf0" data-testid="video" class="kalturaVideoLessonContainer"></div></div></div>

The Façade design pattern relies on a conversion framework  to move data from models retrieved by services  into Data Transfer Objects containing just the data needed by the view being rendered Here, MyFaçade’s Spring configuration includes a reference  to an implementation of the Converter interface,  which uses Java generics to specify SOURCE and TARGET classes.  The converter’s primary callback method, convert,  first instantiates a new, empty instance of its configured target class,  typically a DTO.  It then passes both model and DTO as arguments to the populate method  of one or more populator beans, also typed to SOURCE and TARGET,  which carry out the work of moving relevant data from the model to the DTO.   In the process, populators may obtain additional model objects  by calling services themselves. When all the populators in the list have been invoked in their assigned order,  the populated DTO is returned to the calling controller,  which provides it to the view being rendered. While you might choose to create a custom converter, that happens very rarely.  Instead, you’ll most likely  use Spring to define new converter instances  using existing classes, or assign new populators to existing converters. More on that coming up. Here is a simplified use-case for the conversion framework.  We need to add a property to the Product item type,  say a Boolean property named Eureka.  Our current setup has the façade passing the ProductModel it receives  from MyService to an instance of ProductConverter.  That converter is configured to call one or more populators.  In this example, let’s say it calls a populator named OOTBProductPopulator.   That populator takes care of copying the ProductModel properties needed  for our page to the ProductData DTO. We want to modify this to handle an extra product property, Eureka.  First, we redefine the Product item type.  Assuming we’re working on the Megacorp Accelerator-based website,  we modify the megacorpcore-items.xml file  to add an attribute to Product. Since we’re editing an existing item type,  we set autocreate and generate to false. Adding an attribute tag then does the trick. The ProductModel returned to MyFacade will now include the Eureka property. If the model has a new property, then so should the DTO.  We edit the megacorpcore-beans.xml file  to add to the ProductData DTO a Boolean property named Eureka.  Now the ProductData object returned by the Product Converter, and used by the view, will have a Eureka property.  Now all we need is to have that property propagated from model to DTO.  That’s done by adding a populator to the ProductConverter,  here called EurekaPopulator. The class for that populator implements the Populator interface,  its source defined as ProductModel, and its target as ProductData.  The nuts and bolts of getters, setters, and private attributes aren’t shown.  Instead, let’s focus on the populate method,  which is responsible for moving data from model to DTO. In this case, it’s a simple String-to-String copy. To be linked to the converter,  the populator needs to be visible in Spring, so we configure it in megacorpcore-spring.xml. Following our Spring naming conventions,  the eurekaPopulator as an alias to the defaultEurekaPopulator bean,  an instance of the class above.  Let’s consider a scenario  where we’ve extended the Product Item type to create a Gadget,  which has an additional enumerated property, named feature.  Echoing the type system side of things, we’ll have an equivalent setup on the DTO side, with GadgetData extending ProductData. But wait, there’s more!  The front-end developers want to know if the gadget is considered fancy,  which we’ve decided means a gadget that costs over a thousand dollars.  So we add a second property to the GadgetData DTO  that will be filled in by the conversion framework.  That’s right, the ItemType and DTO attributes don’t have to match exactly. This scenario has MyFacade configured to call GadgetConverter  to convert the Model it receives from MyService.  That model is an instance of GadgetModel,  which is defined in our items.xml file as extending Product.  Since this is the first mention of the Gadget itemtype,  autocreate and generate are both set to true. In addition to Product’s attributes, I want an enumerated attribute named feature.  The definition of FeatureEnum is left to your imagination. Over on the DTO side,  we’ll add to megacorpcore-beans.xml  the definition of a GadgetData bean that extends the out-of-the-box ProductData bean. In addition to the ProductData properties,  we also want it to have the String and Boolean properties ‘feature’ and ‘fancy’.   When the façade passes GadgetModel to the converter,  we need it to call the out-of-the-box Product populators,  represented here by the OOTProductPopulator.  Now, to handle Gadget’s property, feature, we configure the converter to also invoke the GadgetPopulator  before we send GadgetData on to the view. But hold on. The converter is handed a GadgetModel object by the façade,  but the populators’ populate method also expects a GadgetData object. The GadgetConverter’s configuration tells it what class to create.  So, in megacorpfacades-spring.xml,  we define first an alias for the gadgetConverter, then the bean. Notice that we don’t provide a class, since we’re not going to write one.  Instead, we’ll just use the out-of-the-box class  defined for the abstractPopulatingConverter bean. Our converter will instantiate an instance of the class given as the targetClass property.  Once it has done so, it will pass it,  along with the GadgetModel object, to the populators listed in the populators list.  After looking them up in the ProductConverter’s Spring definition,  we include both the out-of-the-box Product populators and our GadgetPopulator.  Hmm… That’s not ideal.  What if another custom extension has added to the list of Product’s populators? For example, the EurekaPopulator we saw earlier.  We can avoid issues by changing the bean tag’s parent argument to productConverter. That way, we get all the existing Product populators,  and we can just add the GadgetPopulator by merging the populators lists. Okay, so what does the code for the GadgetPopulator look like?   The populator class implements the Populator interface  and expects to work on the GadgetModel and GadgetData classes.  To avoid unexpected errors, we specify that GadgetModel has to be a subclass of ProductModel.  Then we provide the populate method, where we do a simple Enum-to-String copy for the feature attribute.  But remember, the Fancy attribute doesn’t exist in the model.  We’ll compute it right here by querying the price of the Gadget,  using an injected service, priceService.  If the value is over a thousand dollars, then it’s fancy. When we configure the populator in Spring, we’ll want to link its priceService property to a bean offering pricing services. Now, what about the façade? The code for that is simple, involving first a call to the injected service,  followed by a call to the converter.  The façade returns the GadgetData object populated by the converter. Links to the service and converter are defined in Spring. But what happens in a situation where there is the possibility  the service might return either a ProductModel or a GadgetModel object?  In that case, the façade tests the model object and calls the appropriate converter.  The Spring configuration is altered to provide a reference to both converters.  However, in a situation where we might need to frequently handle both Products and Gadgets,  it might be simpler to take a different approach. Instead of distinct DTOs for both types,  we can add the Gadget attributes to the ProductData DTO.  When the DTO represents a Product,  the two Gadget attributes can be ignored and won’t be set. Using this approach, the configuration is simpler: Instead of defining a new DTO in the beans.xml file,  we simply extend the out-of-the-box ProductData bean  with the two properties we need for Gadget. Since ProductConverter is already defined, all we need to do is add the gadgetPopulator to its list of populators.  We can do that with the very handy modifyPopulatorList bean,  a specialized bean intended specifically for this purpose.  Notice that I don’t need a bean ID, since I’ll never be referring to it.  I just need it for its side-effect, which is to add the linked populator  to the list of populators in the linked converter. I could also have passed a ‘remove’ property to do the opposite. The out-of-the-box productConverter will call GadgetPopulator every time it is invoked,  not just when it’s converting a Gadget model. That’s why our GadgetPopulator has  to make sure it was called on a Gadget model before doing anything.  If it wasn’t, it doesn’t modify the DTO and returns without complaint. Finally, here’s an overview of the controller’s code, which initiates the call to the façade. Controller classes are generally not instantiated as Spring beans,  so it’s a good idea to wire in the façade using an annotation. The controller passes the value of a path variable to the façade,  and expects in return a DTO it can pass on to the view.  Thanks to the SAP Commerce data conversion process,  the façade can provide one.

Share feedback

Follow guided learning and develop the skills you need at your own pace

Join a moderated learning group to engage with our experts and peers

Find the right learning resources to drive your career as a developer

Sign up to access exclusive student learning journeys

Discover the SAP product knowledge you need to help you progress in your career

Develop your skills

Learn.png

Want to learn more about the value of learning with SAP?

View available SAP Certifications on SAP Learning 

Purchase a subscription and book your exam

Validate your SAP expertise

SAP Certification validates your skills, sets you apart from the crowd, and demonstrates you have the knowledge you need to succeed.

Certify.png

Accelerate your career 

Upskill in key innovation topics through openSAP's free, expert-led online courses, microlearning, and podcasts.

Join SAP Community and connect with a global network of experts and peers to ask and answer questions.

Search for SAP product documentation or browse all SAP Learning Journeys to become competent in the SAP solutions you need.

Log in to SAP Learning Hub and access the entire SAP Learning portfolio, live practice systems, and social learning opportunities.

Find free tutorials, trials, downloads, and technical product information in the SAP Developer Center.

Book live classes (online and in person) and purchase SAP Certification and SAP Learning Hub subscriptions.