SOA Server (12c) not startable from script-created domain.

If you're a regular reader of this blog, you've noticed that I've been busy with creating soasuite/osb installations with weblogic domains in a scripted way.

I also optimized my start and stop scripts, that I'll post soon. All this work keeps me from writing on my BPEL book, so for those who are interested in my next episode, I hope you're patient.

But to get to that, it would be nice to have a running SOA Server in my automatically created domain. And unfortunately, that doesn't get up in running mode. Somewhere in the process it fails to start services and switches over to ADMIN mode.

I did some investigation and ran in to the following exception in the server log:

####<Jul 4, 2016 3:30:49 AM EDT> <Error> <Deployer> <darlin-vce-db.darwin-it.local> <SoaServer1> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <f2c434e6-7b67-4a8c-9e2f-8b886152cced-0000000a> <1467617449212> <[severity-value: 8] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-149205> <Failed to initialize the application "OracleBPMBACServerApp" due to error weblogic.management.DeploymentException: Could not find OSGi framework with name bac-svnserver-osgi-framework
weblogic.management.DeploymentException: Could not find OSGi framework with name bac-svnserver-osgi-framework
 at weblogic.osgi.internal.OSGiAppDeploymentExtension.deployBundlesIntoFramework(OSGiAppDeploymentExtension.java:126)
 at weblogic.osgi.internal.OSGiAppDeploymentExtension.prepare(OSGiAppDeploymentExtension.java:245)
 at weblogic.application.internal.flow.AppDeploymentExtensionFlow.prepare(AppDeploymentExtensionFlow.java:25)
 at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:730)
 at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:45)
 at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:242)
 at weblogic.application.internal.EarDeployment.prepare(EarDeployment.java:67)
...

Apparently there was a problem with the OSGi Framework with the name 'bac-svnserver-osgi-framework' that couldn't be found.

OSGi in a domain with both OSB and BPM was a problem in 12cR1. Several blogs are written about that (like this and this one). However, the problem in those blogs is solved soon after the release of 12cR1. In my case something different is happening.

I took a look and it turns out that the 'bac-svnserver-osgi-framework' was not targetted to the SOAServer, although it was targetted to the AdminServer. To check that, navigate to Services->OSGi Frameworks in the Domain Structure:

Here you see the result of my retargetting. If it does not show the SoaCluster or SOA Server, then click on 'bac-svnserver-osgi-framework' and click on the Targets  tab:

At least check the SoaCluster or, if no cluster the SoaServer1. I unchecked the AdminServer because in the earlier posts unchecking the AdminServer was one proposed solution to resolve the OSB-BPM SharedDomain URL issue. But I'm not sure it's needed.

Click Save and activate the changes and, in my case at least, the SoaServer should be startable.