Sample Output of a Free Oracle eCommerce Assessment

Introduction

Our CLIENT has tasked another SI with development of their new eCommerce application that would be supporting orders by customer, B2B companies and B2B sales representatives.

This application has to be developed on top of the Oracle Commerce platform which a unified B2B + B2C platform is supporting various capabilities needed by the client.

The CLIENT has got their back-end implemented with their ERP provider and it seems they are in the version 9.1 . Since the ERP should be managing the products, SKUs, Categories, Pricing, inventory and Orders at the minimum.

The ATG application should be integrated with the ERP provider for getting the data for the catalog, pricing, inventory etc., and should be able to send the order details back to the ERP provider when the customer places the order.

Issues identified with the current codebase

Non-conformity to the ATG Versions and re-inventing OOTB functionality

Issues with Profile Handling

ATG 11.x provides many excellent OOTB features and functionality that help in streamlining the application development as well as ensuring that the application would be upgradeable to future versions.

The ATG 10.2 itself introduced the concept of LocationRepository to store and manage the various Store locations for an eCommerce Retailer. But, the current application is not found to be using that OOTB repository and extend it, but uses a custom Repository called as StoresRepository, created from scratch, thereby losing out on the important OOTB functionalities.

Note: The later parts of the code, it seems that were developed also uses the LocationRepository. So, there are two repositories for storing the same kind of data. This is bound to give data synchronization issues and inconsistent behaviour

For managing the user Profiles, ATG provides a component by name, ProfileFormHandler OOTB and this component has been there from the ATG versions for the last 15 years and it provides well-meaning extension points for adding custom Logic. The java class hierarchy is shown in the image above.

When we are creating our own custom logic for developing commerce applications, we need to extend the CommerceProfileFormHandler. Also, this component is capable of handling the user registration, login, logout, update etc.,

The current code base does not follow this best practice. Any application should be properly granular, but in this application, there are so many components that are there to handle micro-logic. For example, there are components like UpdateProfileFormHandler, LoginProfileFormHandler etc., and each of them are extending from the ProfileFormHandler OOTB class, thereby totally eliminating all the OOTB Commerce logic that would be executed when a user logs in or updates their profile.

Not only that, it also totally cuts off the OOTB ATG Scenario logic that is needed for internal event-driven components.

So, to compensate for this loss of OOTB logic, there is a lot of custom code to once again provide that logic.

Issues with Package naming Conventions

One of the basic premise of any java programming is to have a proper package naming convention and the convention must reflect the modularity of our codebase. The ATG OOTB classes will be using the package name, starting with ‘atg’ and it is kind of a reserved word, but there are many classes that does not follow any convention at all. See for example the package names are:

Note: I have given a sample of only two classes in this document, but there are close to 150+ classes that don’t follow proper naming convention

Invalid TransactionDemarcation Levels being used in the code

ATG OOTB provides various TransactionDemarcation levels to properly handle the database updates and the safest level of demarcation to be used is “REQUIRED”. The codebase is using “REQUIRES_NEW” in many places and in critical logic. This demarcation would be used only when the logic being executed as part of a whole transaction should be committed or rolled back separately and independently from the larger transaction demarcation block.

For example, when setting Profile’s ShippingAddress on Cart, the item is being repriced independently using a NEW transaction. So, this can lead to inconsistent behaviour.

During the repricing operations too, this kind of inconsistent TransactionDemarcation is being used and this may lead to data integrity issues.

Hard-coded Currency Code setting

The ATG Commerce OOTB code has got the ability to take the priceLists being used for pricing and from the pricelist get the Locale that is applicable to and from that, will automatically get the currencyCode and will store it as part of the order. But, the current codebase, contains a hard-coded snippet to set the price currency always as USD without understanding the capabilities of the OOTB platform.

Invalid Scope for Droplets

In ATG, droplets are created to do some business logic without storing any state information and hence these droplets would be normally defined in the global scope to optimize their usage.

But in the current codebase, there are around 25 droplets that have been defined in the request scope. These droplets are invoked again and again and hence there would be many instances of these objects created in the request scope thereby increasing the usage of memory till the GC cycle cleans the expired instances.

Out of this, many of them can be changed to global scope straightaway without any code change. It seems, the people who have configured the scope of this component are not aware of the repercussions. For most other droplets, some minor code fixes need to be carried out to enable them to be configured in global scope.

Also, there is so much of business logic that has been coded in the droplets, which is again not the right coding practice. This will prevent reusability of the code, when invoked from other channels and hence would lead to duplication of the code.

Outdated Deprecated Code being used

ATG platform has grown in strengths for the last 20 years and during this time there have been many code artefacts that have been deprecated because of either performance issues or a better alternative has been brought in. The current codebase is found to use some of the deprecated components which suffer from deadlocks when used in a heavy load. One such example is the SoftgoodFormHandler class that is used for the checkout process.

Rewriting entire OOTB Code Logic with Custom Code

The codebase attempts to rewrite most of the core functionality with custom functionality by totally ignoring the proper extension points that the OOTB code normally provides.

For example, the AssemblerPipelineServlet, is a total rewrite of the OOTB logic.

The CartModifierFormHandler extension rewrites most of the OOTB functionality using custom code when only a few lines of extension was actually needed and the same could have been achieved using the defined extension points.

SMTPEmail is an OOTB component and that has been extended and the OOTB logic has been stripped off and custom logic has been done in that place.

It seems, not many OOTB classes have been left to have their own code.

Unwanted Former SI Modules

There are so many former SI modules that have been provided as part of the codebase that contains conflicting classes to the ones available in the CLIENT modules. Also, there are many former SI modules that are not needed at all and are simply cluttering the namespace unnecessarily.

The VOPS module has got components that are actually monitoring the ATG Instances by pinging them every 2 minutes unnecessarily. We believe that our client has already got APM tools like dynatrace to do that more effectively and efficiently rather than executing a request on every server every 2 minutes.

Also the former SI modules are too fine-grained thereby adding so many module cross-dependencies.

Critical Issues in Request Handling & SEO

We have seen with other certain former SI clients that, the codebase contains inherent coding deficiencies that would create either cross-site redirects in case we have multi-sites or cross-product redirects within the same sites. That is, when a user clicks on a particular product from the listing page, the user could be taken to a totally unrelated product which the user is not expecting.

This behaviour won’t be seen when one user is just testing the website using one browser, but in a heavy load conditions when there are so many users browsing or when the search engine bots crawl the website. The search engines would then penalise the website for wrong linkages and can reduce the rankings.

Also, when the user is hitting a page URL which is currently not available. The correct SEO technique is to serve a page with a 404 statusCode. But the codebase serves a page with a 200 statusCode. This will be again penalised by the search engines.

Integrations that need to be evaluated carefully

There are so many fine-grained integrations to the ERP layer for fetching the users, userAddress, orders, Statement, inventory, Invoice, MaterialTestReport, OnHoldAccount, OrderStatus, Pricing, PackingSlip etc.,

Most of these are web service calls into the ERP environment and hence these needs to be validated based on the actual requirements.

There are many fine grained calls in these integrations as well. The error handling in these integrations also leave a lot to be desired.

Our Client must provide details of these requirements to understand how best these can be optimized.

Code Integrations that are not available still

No shipping methods are defined in the ShippingPricingEngine. Our Client has to clarify whether there are no such options available for the customer to choose from other than selecting “Instore pickup.

There are no payment integrations available at all. Can our Client clarify whether handling payments when the order is being placed is not part of the requirement at all?

We find that the code is still using the DummyCreditCardProcessor only. Is that the plan for GO-Live?

Also there are not code pieces linked to tax Calculations at all. Does not our Client need tax calculations at all? Are they going to come up from backend during order checkout flow?

There is no real-time synchronization of orders placed to the ERP. How are the eCommerce orders being sent to the ERP?

Issues with the UI

There are so different versions of JavaScript libraries and this may conflict with each other.

The CSS and JavaScript are not being minified and hence may lead to negative SEO rankings.

There are many JSP pages that are redundant or contain duplicate logic and these needs to be cleaned up.

There are so many Endeca Cartridge JSP pages in the codebase from old Endeca versions and these are not being used at all.

There is no code available to generate SiteMaps for SEO.

Further things that have to be looked into deeper

We have not been provided access to any of the environments or the build environments to assess the correctness of them.

We have not analysed the Endeca Cartridges or the Endeca deployment template to provide our findings on that.

We have not analysed any System Integration, since we don’t have access to any working environment, yet.

The entire build process of using ANT seems to be outdated with multiple references to different versions of ATG starting from 10.1.1 to 11.2. The ANT does not manage dependencies and it would be better to migrate to a more flexible tool like GRADLE.

This is a sample of the level of visibility you get with our Free eCommerce assessment.

Contact us today for a Free assessment of your existing Oracle Commerce implementation with NO OBLIGATION