Composite with dependency not working after soa server restart

Question

Hello,
I have composite application that invokes another composite application. After deploying those work fine. But after restarting soa server the one having dependency does not work any more. To soa server log I get following:
<Jul 1, 2010 11:45:29 AM EEST> <Error> <oracle.integration.platform> <SOA-20003> <Unable to register service.
oracle.fabric.common.FabricException: Error in getting XML input stream: http://Yacico:8001/soa-infra/services/default/validationForCC/getStatusByCC?WSDL: Response: '503: Service Unavailable' for url: 'http://Yacico:8001/soa-infra/services/default/validationForCC/getStatusByCC?WSDL'
at oracle.fabric.common.metadata.MetadataManagerImpl.getInputStreamFromAbsoluteURL(MetadataManagerImpl.java:276)
Caused By: java.io.FileNotFoundException: Response: '503: Service Unavailable' for url: 'http://Yacico:8001/soa-infra/services/default/validationForCC/getStatusByCC?WSDL'
<Jul 1, 2010 11:45:30 AM EEST> <Error> <oracle.integration.platform> <SOA-20020> <Deployment of composite "POProcessing" failed: Unable to find a WSDL that has a definition for service {http://oracle.com/sca/soapservice/POProcessing/POProcessing/receivePO}receivePO and port execute_pt. Please make sure that the port attribute for the binding defined in the composite file is correct by checking the namespace, service name, and port name. In addition, check that the WSDL associated with the binding namespace is imported and currently reachable (check the import nodes at the top of the composite file). Finally, validate the HTTP proxy settings for the server..>
So POProcessing does not work any more after server restart. validationForCC works fine also after server restart. Url http://...validationForCC/getStatusByCC?WSDL points to wsdl file and is visible by browser.
I use soa suite 11g patch set 2 (11.1.1.3) running on redhat enterprise linux 5.
Any idea what is the problem?
Is it somehow possible to configure which composites are started first during server startup?
regards, Matti
Edited by: user10197965 on Jul 1, 2010 2:28 AM

Answer 1

Yes, I did that. I'm not all that happy about this as a solution either, but it's better than making multiple copies.
We have since found out that his is a known bug and that it is fixed in some, but not all, deployments.
-------- see below -------------
Composites With WSDL Dependencies Fail To Deploy Following SOA Server Restart [ID 1272070.1]          
Modified:Jul 19, 2012 Type:PROBLEM Status:MODERATED Priority:3                         
In this Document
     Symptoms
     Cause
     Solution
     References
This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) process and therefore has not been subject to an independent technical review.
Applies to:
Oracle SOA Platform - Version 11.1.1.3.0 and later
Information in this document applies to any platform.
Symptoms
A SOA Project has an external reference to a Web Service or a reference to another Composite.
When the SOA Server is started, the Composite is trying to access the WSDL of it's referenced Web Service in order to load data structures. If SOA can not find the WSDL then the Composite fails to load/deploy.
Once this happens the Composite can not be started, or shutdown, from Enterprise Manager Fusion Middleware Control Application.
Related Error Messages:
[ERROR] [SOA-20020] ... Unable to find a WSDL that has a definition for service ... Please make sure that the port attribute for the binding defined in the composite file is correct by checking the namespace, service name, and port name. In addition, check that the WSDL associated with the binding namespace is imported and currently reachable (check the import nodes at the top of the composite file). Finally, validate the HTTP proxy settings for the server.]
javax.wsdl.WSDLException: WSDLException: faultCode=INVALID_WSDL: Error reading import of oramds
Cause
When SOA Server is restarting the Composite can not access the WSDL of it's referenced Web Service (it is not available).
In the first scenario there are two Composites on the same server: CompositeA and CompositeB.
In SOA Suite 11g there is no possibility to specify the load order for the composites. If CompositeA references CompositeB and if CompositeA is firstly loaded then it can not access the WSDL from CompositeB and the issue occurs.
In the second situation there is one Composite on the server (CompositeA) which references an external WebService (ExternalWS). If the ExternalWS is not available when the SOA Server is starting then this issue occurs.
Solution
Solution 1
Redeploy the affected Composite into the SOA Server.
You can do that but it is not advisable in a production environment and in a development environment it will take a lot of time to redeploy the composite manually
Solution 2
Copy the abstract WSDL locally into the project.
This is documented in these articles in our Knowledge base:
•     Document:1155033.1 Node Restart Cause Composites To Become Unavailable. Response: '503: Service Unavailable'
•     Document:1151973.1 Boot Order Of The Composites Upon Soa Suite Restart
Steps:
o     a. Copy and use the WSDL file in the Project
o     b. Edit the WebService Adapter
o     c. Change the "WSDL URL" to point to the WSDL copied into the project
o     d. Redeploy the Project
o     e. Make this configuration with all the Projects that have a references with other Web Services
Solution 3
Use shared artifacts in Metadata Service (MDS). A WSDL used by more than one composite is a shared artifact per definition. If the WSDL structure is changed (that is not happening frequently in a production environment), you will normally deploy a composite with a new version because overwriting it will break your production environment. Moreover, in a development environment you will need a proper process in place where different developers access the same artifacts within MDS. In addition, when you use external WSDLs (owned by third parties), you will have a proper process/agreement in place to be notified about modifications affecting your applications.
1.     In order to use shared artifacts a MDS connection must be configured in jDeveloper:
http://download.oracle.com/docs/cd/E14571_01/integration.1111/e10224/sca_lifecycle.htm#SOASE85488
2.     Deploy the shared artifacts:
o     a. Create a JAR profile and include the artifacts to share
o     b. Create a SOA bundle that includes the JAR profile
o     c. Deploy the SOA bundle to the application server
http://download.oracle.com/docs/cd/E14571_01/integration.1111/e10224/sca_lifecycle.htm#SOASE85472
If the shared artifacts (WSDLs) needed are from other composites this step can be skipped
3.     Create a new WebService
o     a. When completing the "WSDL URL" click on "Find existing WSDL's"
o     b. Select "Resource Palette"
o     c. Go to the SOA-MDS
o     d. Select a WSDL from a Composite or the one deployed at step 2.
Known Restriction 1
The port and the location for the WSDL reference is not completed automatically by jDeveloper in the composite.xml file. This information must be inserted manually. In Bug:10287325 is raised this issue and it is available for SOA 11gPS2+.
Known Restriction 2
Another issue regarding MDS caching is raised in Bug:10218147 - the MDS cache is not refreshed when an artifact is deployed or deleted.
In order to refresh this cache the server must be restarted. This Bug resolves the issue but in a production environment the server restart will be the preferred option. The reason for that is because in a production environment you never deploy single composites under the same version after artifacts (WSDLs) have been modified.
The fix for the Bug:10218147 can be an acceptable solution in development environment where redeployment would be quicker than restarting the server.
Bug:10218147 is available for SOA 11gPS2+.
To find out more information about how to use Shared Metadata check the following documentation:
Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite 11g
41 Deploying SOA Composite Applications
41.7.3 Deploying and Using Shared Metadata Across SOA Composite Applications in Oracle JDeveloper
URL:
http://download.oracle.com/docs/cd/E14571_01/integration.1111/e10224/sca_lifecycle.htm#CACFEAJJ
Solution 4
The last solution is to use an UDDI (Universal Description Discovery and Integration).
Oracle recommends Oracle Service Registry 11g (OSR). The advantage is that you can use OSR and SOA Suite in a Shared WebLogic Domain.
http://www.oracle.com/technetwork/middleware/registry/overview/index.html
http://blogs.oracle.com/governance/2010/05/oracle_service_registry_11gr1.html
To find out more information about Oracle Service Registry check the following documentation:
Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite 11g
33 Configuring Service and Reference Binding Components
33.1.3 Changing the Endpoint Reference and Service Key for Oracle Service Registry Integration
http://download.oracle.com/docs/cd/E15523_01/integration.1111/e10226/bc_config.htm#SOAAG37248
Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite 11g
A BPEL Process Activities and Services
A.4 Publishing and Browsing the Oracle Service Registry
http://download.oracle.com/docs/cd/E15523_01/integration.1111/e10224/bp_appx_ref.htm#SOASE85561
Oracle Fusion Middleware Service Registry 11g
http://download.oracle.com/otndocs/tech/soa/OSR11gR1ProductDocumentation.pdf
Solution 5
In case you have BPM Components in the Composites deployed check the following note:
Document 1317803.1 Soa Suite Composite Fails To Deploy Upon Restart Of Managed Server
The issue is caused by the Bug:11822470 SOA SUITE COMPOSITE FAILS TO DEPLOY UPON RESTART OF MANAGED SERVER
References
BUG:10218147 - WSDL CHANGES NEED SOA SUITE SERVER RESTART
BUG:10278478 - WHEN SOA SERVER IS RESTARTED, SOME SOA COMPOSITES COULD NOT LOAD/BE DEPLOYED
BUG:10287325 - ABSTRACT WSDL NOT AVAILABLE WHEN COMPOSITE STARTED
BUG:10311698 - WHEN SOA SERVER IS RESTARTED, SOME SOA COMPOSITES CAN NOT BE STARTUP / SHUTDOWN
BUG:11822470 - SOA SUITE COMPOSITE FAILS TO DEPLOY UPON RESTART OF MANAGED SERVER
@ BUG:9267312 - MDS ARTIFACTS ARE STILL CACHED AFTER DELETING
@ BUG:9708488 - AFTER SOA RESTART, ALL PROCESSES HAVE TO BE REDEPLOYED
@ BUG:9749845 - SCHEMA CACHE STARTS EMPTY AFTER RE-START, BUT NOT AFTER DEPLOYMENT
NOTE:1151973.1 - Boot Order Of The Composites Upon Soa Suite Restart
NOTE:1155033.1 - Node Restart Cause Composites To Become Unavailable. Response: '503: Service Unavailable'
NOTE:1317803.1 - Soa Suite Composite Fails To Deploy Upon Restart Of Managed Server
Bug 11822470 : SOA SUITE COMPOSITE FAILS TO DEPLOY UPON RESTART OF MANAGED SERVER                    
               Bug Attributes     
Type     B - Defect     Fixed in Product Version     11.1.1.6
Severity     2 - Severe Loss of Service     Product Version     11.1.1.4
Status     80 - Development to QA/Fix Delivered Internal     Platform     912 - Microsoft Windows (32-bit)
Created     Mar 1, 2011     Platform Version     2003
Updated     Oct 12, 2012     Base Bug     N/A
Database Version     N/A     Affects Platforms     Generic
Product Source     Oracle          
Abstract: SOA SUITE COMPOSITE FAILS TO DEPLOY UPON RESTART OF MANAGED SERVER
*** 03/01/11 08:07 am ***
Customer has a project consists of two services for interaction with the
process and one reference to an external service.
On deployment of the process to an Enterprise Environment, the process works
as expected. However, upon a restart of the managed server, the process will
then fail to deploy.
Workaround used is to redeploy the project again.
Bug 10278478 : WHEN SOA SERVER IS RESTARTED, SOME SOA COMPOSITES COULD NOT LOAD/BE DEPLOYED                    
               Bug Attributes     
Type     B - Defect     Fixed in Product Version     
Severity     2 - Severe Loss of Service     Product Version     11.1.1.3.0
Status     92 - Closed, Not a Bug     Platform     226 - Linux x86-64
Created     Nov 10, 2010     Platform Version     RED HAT ENTERPRISE LINUX 5
Updated     Dec 10, 2010     Base Bug     N/A
Database Version     N/A     Affects Platforms     Generic
Product Source     Oracle          
Abstract: WHEN SOA SERVER IS RESTARTED, SOME SOA COMPOSITES COULD NOT LOAD/BE DEPLOYED
Detailed Problem Description
====================
When a SOA composite get dependencies with other SOA composites located on the same server, if the dependency is still not loaded, the SOA composite will not be loaded, and there is no possibilities for Entreprise Manager console to restart it (EM crash). The only way to make it working is to redeployed the SOA composite from jDeveloper that is not acceptable in a production environment.
The composite that has the issue cannot be start-up or shut-down, although the Enterprise Manager do not show any errors with it.