In 188.8.131.52.305 verified on multiple client environments the scheduler in Taskflows does not work in an EPM installation that includes SOA. There are additional bugs to work through which will get written up as time permits. Furthermore, once the problem is identified using SQL Server trace files a solution creates downstream issues that are interesting to diagnose and resolve.
The source of the issue is a conflict in the version of quartz used by HFM and FCM. An EPM system that includes SOA will create [
D:\Oracle\Middleware\Oracle_SOA1\soa\modules\quartz-all-1.6.5.jar] in the Windows Registry FoundationServices classpath during installation.
Manually changing the value in -Djava.class.path [
D:\Oracle\Middleware\Oracle_SOA1\soa\modules\quartz-all-1.6.5.jar] replacing it with [
D:\Oracle\Middleware\EPMSystem11R1\common\SharedServices\184.108.40.206\lib\quartz.jar] Windows Registry for Foundation Services will cause deployed automated integrations to fail.
using script or starting from command line made no difference
After restart all SysInt*composites in SOA went to a conflicted state, started throwing null pointer exceptions and could not be undeployed, redeployed or retired. Cound not import any of the Integration Types that are automated via Workspace. These issues are related.
work through undeploy in Enterprise Manager, ignoring errors, for all SysInt* composites
Restart the EPMSystem (using the usual script)
Not all SysInt*composites had been removed, however, import HFM integration types succeeded. Null pointer errors in logs stopped.
The integration of so many EPM System products + SOA creates interesting challenges. This one is listed as an unpublished bug on Oracle Support.