WSDL artifact errors while deploying

You'll already know that the Oracle JDeveloper contains a nice tool to create the base-mapping (XSL Transformation), unfortunately advanced logic within the mapping get screwed up by this JDeveloper pretty often. Therefor use an advanced text-editor with xml highlighting instead after you finish the base-mapping in JDeveloper. Or stick to the Source-view, no more Design-view.

This leads me to write about a more serious issue with JDeveloper: during development of the integrations all the developers working with ESB components need to have identical workspaces in their JDeveloper. If not, you might run into unwanted errors when deploying. This is known by Oracle and described in a note [ref: note ID 875558.1]:

Applies to: Oracle ESB - Version: 10.1.3.4 to 10.1.3.4.9. This problem can occur on any platform.
Symptoms: When an ESB project is registered using JDeveloper and then moved to a new JDEV Workspace with a different Workspace name, re-registration of the ESB project and its related artifacts (XSL Stylesheets, XML Schemas, WSDL files) might fail.
Cause: ESB artifacts designed with JDeveloper were moved to a different JDeveloper workspace with a new name.
Solution: DO NOT move ESB projects to a different JDEV workspace name. This is not supported by Oracle ESB in the current version.
Explanation: The way ESB identifies a file update in a project at runtime is by using the convention <workspacename>_<projectname>/<filename>. If the user is changing the workspace name, but keeps the project name and file name the same, it will not be possible for JDev to update the related artifacts in the slide repository because the identifier has changed - external references in form of esb:// were created. This is a known limitation.

You might also run into an error while deploying BPEL components that contain a referral to an ESB component, for example in the transformation the target is the ESB component WSDL. This url in the xsl contains the <workspace>, if in development this <workspace> differs from the actual deployed ESB component you might end up seeing the BPEL component in the BPELConsole, but not in the ESB console in BPELSystem. The advice here is: use always the same <workspace> in the JDeveloper, for example let the whole development team develop all ESB components (Projects) under Application AIASystem.

Talking about deployments, there is also a known bug in a jar-file, which is often used by automated deployments, see the note [ref: note ID 1308408.1] which describes the following error:
java.lang.Exception: Programming Error : Adapter Service <WriteData> does not have an associated WSDL artifact
at oracle.tip.esb.jdev.artifacts.model.ESBAdapterServiceArtifactContent.getDeploymentProperties(ESBAdapterServiceArtifactContent.java:159)
For example if you use osbs - Oracle Soa Build Server by Marc Kelderman [ref: http://orasoa.blogspot.com/2009/04/new-oracle-soa-build-server-osbs.html], you'll might receive the error as described in the note above. The solution here is to get from Oracle patch 11871410, extract the file ESBMetadataMigration.jar from the deployments.zip file in this patch and put this jar file in the location mentioned in the obbuild.sh script.