Reference does not exist as wire target

This error normally comes when we try to comment out some existing references from composite.xml

Normally to disable a particular invocation we comment out the respective reference section in the composite.xml

But at the sametime we need to ensure that

In the composite.xml we comment out the import statement for that reference

Open the .componentType file and comment out the corresponding reference section there as well.

If there is a mismatch between composite.xml and .componentType file, the above error occurs

could not resolve xpath function "getServiceProperty", because missing xpath function meta-data

getServiceProperty method is one of the xpath functions available in aia.jar

If you are getting the above error during project compilation , it means the aia.jar is not attached to your project.

You may get the AIAServiceConstructor using the jdev updates and restart jdev  or explicitly attach aia,jar using the project preferences as shown below

Dynamic PartnerLink in BPEL 2.0

Often we may want to call the target endpoints dynamically. In such cases WS Addressing comes for our help.

In BPEL 1.1 we can assign the following snippet to the partner link and it will try to hit the endpoint mentioned in the snippet.

<wsa:EndpointReference xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing">
    <wsa:Address>http://localhost:8001/soa-infra/services/default/TargetService</wsa:Address>
</wsa:EndpointReference>

But in BPEL 2.0 the above approach was not working for me.

I have achieved the dynamic partner link requirement achieved in BPEL 2.0 as follows

Download the ws-bpel_serviceref.xsd  and add it to your project

Create a variable of element type service-ref , which is defined in the above xsd

<variable name="partnerlink-reference" element="sref:service-ref"/>

For the example purpose I am storing my target endpoint in a variable. (You may use DVM or AIAServiceConfigurationProperty file to store your target endpoint at real time.)

<copy>
        <from>'http://localhost:8001/soa-infra/services/default/TargetService'</from>
        <to>$TargetService</to>
      </copy>


Using append xml fragment option the following xml snippet to the above variable  partnerlink-reference

 <wsa:EndpointReference xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing">
    <wsa:Address/>
</wsa:EndpointReference>

Now enrich the   partnerlink-reference xml with the actual endpoint you need
     <copy>
        <from>$TargetService</from>
        <to>$partnerlink-reference/wsa:EndpointReference/wsa:Address</to>
      </copy>

Finally copy partnerlink-reference variable  to the target partner link

 <copy>
        <from>$partnerlink-reference</from>
        <to partnerLink="TargetServicePartnerLink"/>
      </copy>

The entire Assign activity will look like as follows

<assign name="Assign1">
      <copy>
        <from>'http://localhost:8001/soa-infra/services/default/TargetService'</from>
        <to>$TargetService</to>
      </copy>
      <extensionAssignOperation>
        <bpelx:append>
          <bpelx:from><bpelx:literal><wsa:EndpointReference xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing">
    <wsa:Address/>
</wsa:EndpointReference></bpelx:literal></bpelx:from>
          <bpelx:to>$partnerlink-reference</bpelx:to>
        </bpelx:append>
      </extensionAssignOperation>
      <copy>
        <from>$TargetService</from>
        <to>$partnerlink-reference/wsa:EndpointReference/wsa:Address</to>
      </copy>
      <copy>
        <from>$partnerlink-reference</from>
        <to partnerLink="TargetServicePartnerLink"/>
      </copy>
    </assign>

Save and deploy your project. Test your flow, you can see your partnerlink's target address is changed to the one you updated from your BPELprocess

WS Security Error while trying to invoke a BPEL Component

In case of any WS Security error while trying to invoke a BPEL service, verify whether any security policies are attached to that service.

To override the security requirement you can attach the no-authentication policy to the reference exposed to the client . i.e client_ep

This can be done either from emconsole after deployment of the service or in jdev before deploying

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

There was an error deploying the composite Deployment Failed: 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..

This is a common error while deploying the composite from JDEV

One of the major reason for this error is due to invalid imports. Sometimes local MDS reference might have used during development time, but at deployment time it will be referring the target environment's MDS. In such cases ensure that your local MDS and target MDS are in sync.

Check all the import statements in the composite.xml. Ensure that each and every import statement is valid and the corresponding target resource is available.

Try to open the composite.xml in design view to see any wsdl loading errors happening.

Other reason could be because of the wrong config plan file used or
Wrong values for binding.ws port attribute in the composite.xml or
Wrong value for interface.wsdl interface in the composite.xml


If  there is a change in the reference/service/import sections in the composite.xml ensure you regenerate the config plan file.

Checking binding.ws port attribute in composite.xml
===============================
Follow the below rule to verify the correctness of binding.ws port attribute

<NAME_SPACE>#wsdl.endpoint(<SERVICE>/<PORT>)

For e.g

  <binding.ws port="http://xmlns.oracle.com/POCApplication/ApprovalService/ApprovalProcess#wsdl.endpoint(approvalprocess_client_ep/ApprovalProcess_pt)"/>

Where
Namespace is  - http://xmlns.oracle.com/POCApplication/ApprovalService/ApprovalProcess
Service is -  approvalprocess_client_ep
Port is -  ApprovalProcess_pt

Checking  interface.wsdl interface attribute in composite.xml
===============================
Follow the below rule to verify the correctness of  interface.wsdl interface port attribute

<NAME_SPACE>#wsdl.interface(<COMPONENTNAME>)

For e.g

http://xmlns.oracle.com/POCApplication/ApprovalService/ApprovalProcess#wsdl.interface(ApprovalProcess)

Where
namespace is - http://xmlns.oracle.com/POCApplication/ApprovalService/ApprovalProcess
component name is  - ApprovalProcess

The process domain is encountering the following errors while loading the process : Validation of BPEL2.0 process failed.. This error contained an exception thrown by the underlying process loader module.

The process domain is encountering the following errors while loading the process : Validation of BPEL2.0 process failed..
This error contained an exception thrown by the underlying process loader module.
Check the exception trace in the log (with logging level set to debug mode). If there is a patch installed on the server, verify that the bpelcClasspath domain property includes the patch classes.

Even though our BPEL project is compiled in jdev, during deployment it can throw the above error.

From the error message we cant make out anything.


But one of the reasons for this compilation failure could be the java embedding used inside the BPEL process. If the java code refers some external classes and if that jar files are not set in the project in the SCA/lib folder this error can happen


To resolve the error at run time the same custom jar files must be made avaiable to the BPEL Process Manager at run time .

This can be achieved by following the below process

Navigate to Oracle_Home\soa\soa\modules\oracle.soa.ext_11.1.1 directory.

Copy your custom jar files under the classes directory

Open the command prompt and navigate to \Oracle_Home\soa\soa\modules\oracle.soa.ext_11.1.1

Run the ant command


\Oracle_Home\soa\soa\modules\oracle.soa.ext_11.1.1>ant
Buildfile: C:\installed\Oracle\Middleware12C\Oracle_Home\soa\soa\modules\oracle.
soa.ext_11.1.1\build.xml
  [taskdef] Could not load definitions from resource net/sf/antcontrib/antlib.xm
l. It could not be found.

create-manifest-jar:
   [delete] Deleting: \Oracle_Home\soa\soa\modu
les\oracle.soa.ext_11.1.1\oracle.soa.ext.jar
      [jar] Building MANIFEST-only jar: \Oracle
_Home\soa\soa\modules\oracle.soa.ext_11.1.1\oracle.soa.ext.jar

BUILD SUCCESSFUL
Total time: 0 seconds

Restart the Server

Importantly ensure that your .BPEL file uses the import statements for such referred classes

e.g

     <import location="oracle.xml.parser.v2.XMLElement" importType="http://schemas.oracle.com/bpel/extension/java"/>
  <import location="java.io.BufferedReader" importType="http://schemas.oracle.com/bpel/extension/java"/>
  <import location="java.io.ByteArrayOutputStream" importType="http://schemas.oracle.com/bpel/extension/java"/>
  <import location="java.io.InputStream" importType="http://schemas.oracle.com/bpel/extension/java"/>
  <import location="java.io.InputStreamReader" importType="http://schemas.oracle.com/bpel/extension/java"/>

After adding all  the  required import statements , redeploy the process

BINDING.JCA-11975 AQ_INVALID_QUEUE Unable to obtain queue table name

The invocation resulted in an error: Invoke JCA outbound service failed with connection error, exception: com.bea.wli.sb.transports.jca.JCATransportException: oracle.tip.adapter.sa.api.JCABindingException: oracle.tip.adapter.sa.impl.fw.ext.org.collaxa.thirdparty.apache.wsif.WSIFException: WSIF JCA Execute of operation 'Enqueue' failed due to: AQ_INVALID_QUEUE.
Unable to obtain queue table name.
Queue does not exist or not defined correctly.
; nested exception is:
BINDING.JCA-11975
AQ_INVALID_QUEUE.
Unable to obtain queue table name.
Queue does not exist or not defined correctly.
Drop and re-create queue.

This issue normally happens when the underlying schema changes.

For eg. while migrating AQAdapter from one ENV to another ENV normally only the following parameters might need to change

database name
hostname
port
service/sid

Usually we change these values in the datasource configuration in weblogic console

But in some situations if the target schema name is different than the one configured in the .jca file, this issue could happen

In such cases you may need to verify your .jca file and see the following property value reflect the correct schema name

<property name="DatabaseSchema" value="AQ_USER"/>

Redeploy the service after updating the jca file