Hi,

I recently upgraded UAT environment from 7.6.1.2 to 7.6.1.3 but having a few issues. However, the customized MaxRole class is no longer working. I have verified the class mapping is correct for MAXROLE object in database configuration and the class file is present in deployed .ear.

Other custom classes are working fine because we can see debugging messages printed out in systemout.log except for the custom MaxRole class. This class is working fine in previous UAT 7.6.1.2 and also currently working in production 7.6.1.2.

Anyone have any suggestions on what might be causing the custom MaxRole class to fail specifically after the 7.6.1.3 upgrade, given that all other custom classes are fine?

Many thanks!

UPDATED: I have found what caused this issue. The ootb 7.6.1.3 WFAssignment has new changes in how it call the resolveRole(), so need to update the MaxRole class accordingly.

------------------------------
Tung Duong
------------------------------

Great catch, Tung - you're right: in 7.6.1.3 the workflow engine changed how WFAssignment calls MaxRole.resolveRole(...). If your custom class expected the business MBO (e.g., WO/TICKET) and 7.6.1.3 now passes a WFAssignment (or a different context), older overrides silently miss or blow up.

What to do (checklist):

1. Recompile against 7.6.1.3 jars
   Make sure you compile your custom MaxRoleExt with the 7.6.1.3 businessobjects.jar/maximo.jar. Add @Override to catch any signature drift at compile time.

2. Be context-safe inside resolveRole
   Defensive pattern: if the incoming MBO is a WFAssignment, get the real target/owner MBO before applying your logic.

   
   
   
   
   
   
   @Override
   public PersonSetRemote resolveRole(MboRemote mbo) throws MXException, RemoteException {
       MboRemote target = mbo;
   
       // 7.6.1.3: call may arrive from WFAssignment
       if (mbo != null && "WFASSIGNMENT".equalsIgnoreCase(mbo.getName())) {
           try {
               // Prefer a typed call if available in your build:
               // target = ((WFAssignmentRemote)mbo).getOwner();
               // Generic fallback:
               MboSetRemote ownerSet = mbo.getMboSet("OWNER"); // relationship exists in WF
               if (ownerSet != null && ownerSet.count() > 0) {
                   target = ownerSet.getMbo(0);
               }
           } catch (Exception e) {
               // log and continue with original mbo
           }
       }
   
       // now run your original logic against 'target' (not the WF row)
       return resolveAgainstBusinessMbo(target);
   }
   
   private PersonSetRemote resolveAgainstBusinessMbo(MboRemote businessMbo)
           throws MXException, RemoteException {
       // your existing code (read VALUE/WHERE, build SqlFormat, return GETPERSON1, etc.)
   }
   
   
   

3. Avoid brittle assumptions in the override
   In 7.6.1.2 many custom roles did paramMboRemote.getString(getString("VALUE")). After 7.6.1.3, that fails if paramMboRemote is a WF row (no such field). Always null/instance check and read attributes from the business owner.

4. Use MXLogger instead of System.out.println

   
   
   
   
   
   
   private static final MXLogger LOGGER = MXLoggerFactory.getLogger("maximo.custom.role");
   if (LOGGER.isDebugEnabled()) LOGGER.debug("Resolving role for " + (mbo!=null?mbo.getName():"null"));
   
   
   

   It's easier to trace classloading and avoids noisy stdout.

5. Deployment + cache hygiene

   • Put the class in a separate custom JAR (e.g., applications/maximo/lib/custom-xyz.jar) and bump the JAR version.

   • Rebuild/redeploy the EAR, then clear caches (turn Admin Mode on/off) or restart the JVM so the new class is picked up.

   • Double-check Database Configuration → MAXROLE class mapping still points to your class after the upgrade.

6. (If your build shows an overloaded API)
   Some clients see an overload (e.g., resolveRole(MboRemote owner, MboRemote ctx) or similar). If present in your 7.6.1.3 libraries, override that one as well and delegate to your common method-prevents the framework from bypassing your logic.