Old class dependency in running workflows

Hi,

We have just upgraded our IDM container installation to 4.8.7. One change that we have found is that log4j seems to have been upgraded.

Until now we have used the following Global script function to log from workflows to catalina.out:
Packages.org.apache.log4j.Logger.getLogger();

After the upgrade, this function no longer works and produces this error:

Caused by: com.novell.soa.script.ScriptException: Error Evaluating Script Error Evaluating Script com.novell.soa.script.mozilla.javascript.EcmaError: TypeErr
or: Cannot call property getLogger in object [JavaPackage org.apache.log4j.Logger]. It is not a function, it is "object". (unnamed script#1)
at com.novell.soa.script.impl.lang.es.impl.EcmaScriptEngine.evalToObject(EcmaScriptEngine.java:509) ~[classes/:1.7.0]
at com.novell.soa.af.impl.core.DataItemEvaluator.evaluateSource(DataItemEvaluator.java:933) ~[classes/:1.7.0]
at com.novell.soa.af.impl.core.DataItemEvaluator.evaluate(DataItemEvaluator.java:790) ~[classes/:1.7.0]
at com.novell.soa.af.impl.core.DataItemEvaluator.evaluate(DataItemEvaluator.java:732) ~[classes/:1.7.0]
at com.novell.soa.af.impl.worklist.WorkImpl.getDataItems(WorkImpl.java:452) ~[classes/:1.7.0]
at com.novell.soa.af.rest.controller.WfRestController.performTaskAction(WfRestController.java:707) ~[classes/:1.7.0]
... 45 more


We can solve this for new workflow processes by exchanging the function with the following:
Packages.org.apache.logging.log4j.LogManager.getLogger()


However...! It is still a problem for workflow processes that were running during the upgrade as they still have the old function.

We were thinking along the lines of adding the old function back to the system, but since it is a container installation, that is not ideal.

Perhaps we could manipulate the xmldata in the database?

How could we resolve this?

Thanks!

  • However...! It is still a problem for workflow processes that were running during the upgrade as they still have the old function.

    How many still running workflows exist? In some environments, we've found it easier to declare a "ground zero" approach with still running workflows and upgrades.

    So anyone who was unlucky enough to have a still running workflow at the point of the upgrade had to re-submit a new request. (case any existing workflows were terminated)

    Perhaps we could manipulate the xmldata in the database?

    That is very much unsupported, don't expect any help from OpenText if you go down that path. It does sound very tempting though. A find/replace and it should be fixed.

    However, I seem to recall though that things rapidly got more complex than one might expect.

    Do test this very thoroughly. Also test deploying new updates/changes to the same PRD. I seem to recall there was some sort of internal revision number for each workflow that got out of sync in a customer's environment after a disaster recovery/upgrade.

  • Thanks for weighing in.

    There are probably hundreds of running workflows, depending on the day. 

    That is very much unsupported, don't expect any help from OpenText if you go down that path. It does sound very tempting though. A find/replace and it should be fixed.

    You are certainly right about this. They were not interested and we were not able to get the expected results by changing stuff in the database ourselves. Even though we figured out the revisions that were running and changed those specifically... theres more to it.

    We are still stuck on this and altough we can mitigate the damage with "ground zero" or changing the log function for a period ahead of upgrading, it is not ideal.