Error calling an external service from composite: oracle.fabric.common.FabricInvocationException: Unable to find the WSDL service defined for service name

I want to share an error that has kept me busy for a bit. I could not find the cause of the error easily, but as always with troubleshooting: afterwards it all made sense.

So I had an SOA composite calling an external service. Invoking this service resulted in the error below. This happened after deploying the service in my test environment.

      <bpelFault>
        <faultType>0</faultType>
         <remoteFault xmlns="http://schemas.oracle.com/bpel/extension">
           <part name="summary">
              <summary>oracle.fabric.common.FabricInvocationException: Unable to find the WSDL service defined for service name {http://www.stellent.com/GetCaseNumberWCC/}GetCaseNumberWCC.  Please make sure that the port attribute for the binding defined in the composite file is correct by checking the namespace and service name in the #wsdl.endpoint element. 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 any HTTP proxy settings for the server.</summary>
           </part>
            <part name="code">
              <code>null</code>
            </part>
           <part name="detail">
              <detail>Unable to find the WSDL service defined for service name {http://www.stellent.com/GetCaseNumberWCC/}GetCaseNumberWCC.  Please make sure that the port attribute for the binding defined in the composite file is correct by checking the namespace and service name in the #wsdl.endpoint element. 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 any HTTP proxy settings for the server.</detail>
           </part>
         </remoteFault>
       </bpelFault>

It didn’t make sense to me as the external service was up and running and I could call it from SoapUI. The endpoint looked good and I could view the WSDL in my browser. I checked my composite as the text in the exception suggested, but it looked fine and in accordance with my WSDL:

The SOA service worked fine in my development environment but failed in my test environment. It lead me to the configuration plan I generated using jDeveloper. In the reference part I changed the location to my test environment, the rest I had left untouched.

When I viewed the WSDL in my browser (http://tstenvironment:80/default/WCC/Services/GetCaseNumberWcc/V1?wsdl) I saw the following:

Apparently the service and port names were different in OSB, so it made sense that the port attribute wasn’t updated correctly in the configuration plan. This caused the invocation of the service to throw an error about the service name. I corrected the configuration plan (see yellow underlined text), redeployed the composite and it resolved my problem!

In my case the error was caused by a wrong service name and port generated in the configuration file. But while looking for a solution I saw that this error could also be caused by using version specific abstract WSDL’s or the WSDL location in your composite.xml pointing to the wrong destination (for example your local machine). If you’re using an MDS make sure it is in sync with the target MDS.

Deploying composite from jDeveloper throws error: oracle.ide.ceditor.CodeEditorScrollableSectionView cannot be cast to oracle.tip.tools.ide.fabric.gui.components.DiagramEditor

I want to bet this is one of the first errors a developer runs into when working with BPEL. When you try to build a .jar file or deploy your composite from jDeveloper to the application server it suddenly pops up in your deployment log and your deployment is cancelled. To rule out randomness you try again, but BOOM! Alas, there it is again:

[11:54:05 AM] Deployment cancelled.

[11:54:06 AM] ----  Deployment incomplete  ----.

[11:54:06 AM] Unable to package module

[11:54:06 AM] oracle.ide.ceditor.CodeEditorScrollableSectionView cannot be cast to oracle.tip.tools.ide.fabric.gui.components.DiagramEditor

This has to do with your composite.xml not being in Design mode at the time of the build. Also, if you closed the composite.xml while it was in Source mode it will stay in Source mode. Put it back in Design mode, try again and you will see that deployment will now be successful.

The reason seems to be that after the build, jDeveloper will view the diagram from Design mode. If Source mode is the active tab, it will fail to do so.

How to pass a SOAP header in BPEL

A while back I had to do some research to find out how I could pass a username and password dynamically to an external service in BPEL through the SOAP header using the wss_username_token_policy. Turns out it’s quite easy so let me share a simple implementation with you.
 

This is what we are aiming for, a simple BPEL process that calls an external service to return some data to the client. Both require authentication through the UsernameToken. The security header which will contain the UsernameToken consisting of a username and password and will be received as input and passed on to the target service. 

The composite looks as follows. The client and target are both secured with the wss_username_token_policy.

To achieve this we will:
1-Create a schema that contains the definition of the security header
2-Update our WSDL so it will contain the header element
3-Create a variable in BPEL for the header and use it to pass it on

1. Create the XSD schema
Create an XSD schema that specifies the UsernameToken profile in accordance with the OASIS standard. It’s not necessary to create a separate XSD schema. You could also add it to the existing XSD schema that was already generated with your project.

2. Update the WSDL
In the WSDL we will have to add the namespace, import the XSD schema and add the message type of our security header. Lastly, we add the header to the binding. See the four snippets of code I put together below:

3. BPEL
Add the namespace (here it has xmlns:ns1) and import the XSD schema. Next, create a variable that will hold the security header. I named the variable SecurityHeader. Now you can use the 'Assign' or 'Transform' activity to assign values to the elements of the header.

Now, when you edit the receive, invoke and reply constructs, you can add your header variable via the ‘Headers’ tab.

When the security header has been added for all three constructs your code should look similar like the following. The highlighted parts are the references to our security header.

Now this is how you retrieve the header passed by the client service and use it to invoke a target service. If your target service returns a header, it will be returned to the client service.

That’s all! Hope this helped :)