Failed to lookup BaseSite for BusinessProcess.Unable to setup site in session.Could not resolve the content catalog version, cannot generate email content - Issue with 6.7

[harshakaruturi]

Recently, we have migrated from 6.3 to 6.7. We have some business process models that stopped working suddenly after the migration with the following warning.

Failed to lookup BaseSite for BusinessProcess [portalReportEmailProcess-810000-1544506604790]. Unable to setup site in session.WARN [TaskExecutor-master-8450-ProcessTask [9374677828534]] [: , , , , ] [HybrisLogger] Could not resolve the content catalog version, cannot generate email content

We were in an impression initially that it was node issue since this happens intermittently.But after investigation, we found this is an issue with picking up the right strategy at runtime. Until 6.3, we do not have strategies in place and we used to get the cmsSite and catalogversions from DefaultProcessContextResolutionStrategy with an instanceof check.

     if (businessProcess instanceof StoreFrontProcessModel)
     {
         return ((StoreFrontProcessModel) businessProcess).getSite();
     }

     else if (businessProcess instanceof OrderProcessModel)
     {
         return ((OrderProcessModel) businessProcess).getOrder().getSite();
     }

     else if (businessProcess instanceof ConsignmentProcessModel)
     {
         return ((ConsignmentProcessModel) businessProcess).getConsignment().getOrder().getSite();
     }

     else if (businessProcess instanceof ReturnProcessModel)
     {
         return ((ReturnProcessModel) businessProcess).getReturnRequest().getOrder().getSite();
     }

In between 6.4 to 6.7, the approach has been changed to pick the cmsSite and catalog version where a Map is being used to fetch the site and catalog version.Here key is the Class and value is the target strategy. The idea is to pick the strategy based on runtime class match from the Map. The parent bean is in accelerationservices-spring.xml where we have 6 entries in Map. In specific extensions, based on their requirement , this map is merged with additional entries...for example stocknotificationservices,warehousing etc.As long as the business process model in the extension specific entry is not a super type, we do not see any issues.But in warehousing extension, the key is the super type BusinessProcessModel. Here is the problem with this entry.

key = de.hybris.platform.processengine.model.BusinessProcessModel" value-ref="consolidatedPickSlipBusinessProcessContextStrategy"

Since the key used here is super class of all business process models, it surpasses all the child class entries if it comes first in processStrategyMap as per the revised logic in DefaultProcessContextResolutionStrategy.For example in my case, the StoreFrontProcessModel type (child classes that extends StoreFrontCustomerProcessModel and StoreFrontProcessModel) always comes after BusinessProcessModel in the map and after that i will never get the storefrontProcessContextStrategy in back with the below logic.

     final ProcessContextResolutionStrategy<BaseSiteModel> strategy = getProcessStrategyMap().get(businessProcessModel.getClass());
     return (strategy != null) ? Optional.of(strategy) :
             getProcessStrategyMap().entrySet()
                     .stream()
                     .filter(e -> e.getKey().isAssignableFrom(businessProcessModel.getClass()))
                     .findFirst()
                     .map(Map.Entry::getValue);

final ProcessContextResolutionStrategy strategy = getProcessStrategyMap().get(businessProcessModel.getClass()) - This will return null since it may not match if you are using your own/custom BusinessProcessModel that is child of StoreFrontProcessModel,OrderProcessModel,ReturnProcessModel etc e.getKey().isAssignableFrom(businessProcessModel.getClass()).This condition will be satisfied first for BusinessProcessModel as it is coming first in the map entries and returns consolidatedPickSlipBusinessProcessContextStrategy with findFirst() method, thereby surpassing all child types.

In order to resolve this issue, we will have to either override getStrategy(BusinessProcessModel) in DefaultProcessContextResolutionStrategy or add your custom businessprocessmodels in the map (use map merge approach) within your extension so that your custom processmodel will be picked up based on match with this below line. final ProcessContextResolutionStrategy strategy = getProcessStrategyMap().get(businessProcessModel.getClass());

Advantages with overriding DefaultProcessContextResolutionStrategy : No overhead merging your custom business process model to the map everytime when you create a new process model.Just put an instanceof check to your super type in overridden method so that it will handle all the subtypes of StoreFrontProcessModels. if (businessProcessModel instanceof StoreFrontProcessModel) { strategy = getProcessStrategyMap().get(StoreFrontProcessModel.class); }

Disadvantages with overriding DefaultProcessContextResolutionStrategy : No disadvantages, only to consider making changes at java class level if any new BusinessProcessModel type is introduced. Example: CouponNotificationProcessModel,ProductInterestsProcessModel etc.

Advantages with merge map approach : xml configurations.so no need to modify any java class.

Disadvantages with merge map approach : The map entries size may become huge down the line if you keep on adding the new entries, thus reduces the readability of the code.If you create 5 custom process models of type strontfrontprocessmodel, all the 5 have to be added to the map with the same target strategy.

 <entry value-ref="storeFrontProcessContextStrategy">
     <key>
         <value type="java.lang.Class">de.hybris.platform.commerceservices.model.process.ABCProcessModel</value>
     </key>
 </entry>
 <entry value-ref="storeFrontProcessContextStrategy">
     <key>
         <value type="java.lang.Class">de.hybris.platform.commerceservices.model.process.JKLProcessModel</value>
     </key>
 </entry>
 <entry value-ref="storeFrontProcessContextStrategy">
     <key>
         <value type="java.lang.Class">de.hybris.platform.commerceservices.model.process.XYZProcessModel</value>
     </key>
 </entry>

Even the OOTB StoreFrontCustomerProcessModel has to be included in the map.Otherwise it is supressed with warehousing extension entry.

I believe hybris has not suggested any recommended approach.At the end, it is your call to go with any approach of the two after assessing the pros and cons.

Note : If you are not using warehousing extension, commenting it out would be the simplest solution of all so that the super type BusinessProcessModel will not be part of the Map.In this case, it will pick the right strategies without any customization.

[arthurjs2]

Super useful information, thanks a lot!

[former_member670512]

Yeah i am facing the same issue... Please let me know if you find the solution

[devdixit]

Thanks for detailed explanation !!

[Former Member]

You can use this implementation in order to find the most specific/suitable class:

 @Override
 protected Optional<ProcessContextResolutionStrategy<BaseSiteModel>> getStrategy(BusinessProcessModel businessProcessModel)
 {
     Class<?> processClass = businessProcessModel.getClass();
     ProcessContextResolutionStrategy<BaseSiteModel> strategy = getProcessStrategyMap().get(processClass);
     if (strategy == null)
     {
         Class<?> bestClass = findMostSpecificClass(processClass);
         strategy = getProcessStrategyMap().get(bestClass);
     }
     return Optional.of(strategy);    
 }
     
 private Class<?> findMostSpecificClass(Class<?> processClass)
 {
     Class<?> mostSpecific = null;
     Set<Class<?>> supportedClasses = getProcessStrategyMap().keySet();
     for (Class<?> supportedClass : supportedClasses)
     {
         if (!supportedClass.isAssignableFrom(processClass))
         {
             continue;
         }
     
         if (mostSpecific == null || mostSpecific.isAssignableFrom(supportedClass))
         {
             mostSpecific = supportedClass;
         }
     }
     return mostSpecific;
 }

[Former Member]

Sriharsha, I really appreciate you for posting the details of the issue and it's resolution. We are having same issue on 6.7. Thanks!!