We all know this feeling when you use an application, and a specific feature isn’t there. Or the default behavior of a part isn’t fully to your liking. Is there anything we can do to change this, so it will suit our business process better?
With the SAP Commerce product our answer in most of the cases is “Yes, we can. But first let’s look at the possibilities within the defaults of the application”.
To change the behavior of the application there are 3 options:
Changing behavior using configuration is the most common way. With this the application let you change specific parts without the need to write any code. In most cases these changes will be managed in a properties file or XML file.
When extending on the application you add functionality but keep the original application as is. This can be done using plug-ins or modules if the developers of the application intended to make extension possible.
Overriding is the most complex and requires a solid knowledge of the application. This gives you a lot of possibilities but also a potential risk. In most cases Overriding code can be done by hooking into a piece of code and from that point run your own code. This will work just fine as long as the original code where you hook into doesn’t change. But what happens when you upgrade the application to a newer version? Is the behavior of your code still required? Doesn’t it break something?
I will give you some examples, in an SAP Commerce project, of the options above and discuss the possible risks.
Configuring your application to meet your needs is in almost all cases inevitable. In SAP Commerce there are several files to configure the application, but some so called properties can also be maintained from within the application. As an example, you can easily change your database connection setting in property files. Configuration of constraints, user rights and Backoffice components can be maintained from within the application itself.
In SAP commerce you have the freedom to change the configuration to suit your needs without the need of a single line of java code. But if your business requires flexibility then the configuration gives, there is the option to add “add-ons” or “extensions” to the product.
In SAP Commerce we can change to number of items in cache. Therefore, we have to add a property in our property file:
It is also possible to change the visible attributes in a listview. In this example we’ve added the user status to the listview. This configuration can be done using configuration files or directly from within the application.
We’ve implemented the product Backoffice. Therefore, we’ve created an extension based on the template given by SAP. In this extensions we’ve added all our custom configuration and custom code. For some specific text field, we wanted it to be read-only and also not look like an editor.
Overriding is going one step further then extending. With this you change the original behavior of the application with your own. Because of this you need a great understanding of the part you are overriding. This can have a big impact on the rest of the application if done wrong.
The most common way is by hooking into a part of the application and insert custom code. For this you need a great understanding of the original application because these changes can have negative side effects on other process.
In our product we have some date-driven attributes. They have a start-date from which this value becomes valid. In this example we look into our date-driven field for product-status. The customer wants these fields to be sorted by date descending. Custom sorting isn’t possible by default in the application. Therefore, we had to override the existing editor, sort by the date field and display them.
Customizing an application like SAP Commerce is inevitable. But be aware that not all changes are without risk. With all changes you should ask yourselves: “Was it the vendor’s intention to have this changed?”. How easy it is to make the change gives you a great indication of the vendor’s intention. Therefore, we can also say that the harder it is to make the change, the bigger the risk. But why is there a risk?
There are several risks when customizing an application.
Does your change effect parts of the application that you did not intended to?
What happens when you upgrade your application?
What if you run into issues? Is this due to your change or is there something else?
Based on the examples for each customization option I will walk you through issues we had with these changes.
With the configuration we changed the cache size. We first changed it to a size that was too big for the amount of memory we have on our application server. This resulted in performance issues. After changing it to a more suited size we had no issues. This also seemed to be no issue after upgrading our application.
We didn’t have any issue at first with our extensions. But after upgrading we discovered that due to some library updates in the application, we needed to make some changes in our code.
With the override we had to most issues. This is all due to changes that has been made on the parts that we extended. In the example of sorting elements on a date, we did an override on a method that had the collection of elements. From there we sorted the collection and ran the original code from that point. But after the upgrade of the SAP Commerce application this class changed. The method got replaced by another method. Therefore, our code for sorting the elements didn’t work anymore. Because of this we needed to look into the code and find out what the changes were and find a solution.
So, if you think about customizing your application: Yes, it is possible, but make sure the benefits outweigh the risks.