WSDL URL and WebServiceSettingBean

Invoke Web Service Icon

I recently discovered an issue in two concurrent projects that presented an interesting problem. The reason I have never seen this before is probably because I have never tried to use the Invoke Web Service activity in Livecycle before for a production system. It’s a simple enough activity with all of the usual parts to it and on the outside seems to work fairly well especially during development. The issue doesn’t present itself until you try to prepare it for deployment to multiple environments. I will try to explain (stick with me here)


In a typical environment you will configure system values that change via configuration parameters. This allows you to package an LCA up for deployment to another system and set the configuration parameters after deployment for that system. In any normal business you usually find a number of environments, for example, Development, Test (or SIT – system integration testing), UAT (user acceptance testing) and Production – all quite typical.

Getting back to the Web Service activity, you notice that in the first page that a number of the useful items like username, password, targetUrl, etc are all configurable via XPath which in turn allows for a configuration variable to be used here. But strangely, Adobe have left out XPath for WSDL URL.

WebService Settings Dialog

WebService Settings Dialog

Why is this a problem?

If WSDL URL is hard-coded and you try to migrate the application to another server, every time your InvokeWebService activity is called, it will try to call the original hard-coded WSDL URL for that activity during execution. So if your web services follow the same deployment pattern as your Livecycle applications i.e. DEV > SIT > UAT > PRD, when you execute the activity in your SIT environment, the DEV WSDL will be loaded by Livecycle before it is invoked. Which if it is unavailable, causes the whole activity to fail. So you can see that once it hits PROD and someone brings down the DEV web services for whatever reason, the PROD instance will fail.

Why is this built like this? Who knows. How do we work around it? Read on…

The hack (sorry – undocumented workaround)

Inside the activity, if you change the InvokeWebService activity Options parameter to a variable type you will notice that it accepts a WebServiceSettingBean as input.


InvokeWebService Options

A quick Google of the bean name and you get a few scattered posts on Adobe forums asking for help on parameters but no complete guide on how to use it or what all of the parameters are. It’s because no public API exists for this bean. You can use the object inspector after creating a bean variable and see what the bean parameters are but it crucially won’t tell you what the variable types are. Below is a full list of the variables it accepts and their types:


  • String wsdl
  • String username
  • String password
  • String port
  • String portBindingLocalName
  • String targetUrl
  • String operationName
  • String timeOut
  • String inputRequest (or org.w3c.dom.document – haven’t tried this)
  • String inputRequestTest
  • List (com.adobe.idp.Document) attachments
  • Map<String, String> wsdlMap
  • boolean enableMTOM
  • boolean authenticatePreemptively

Most of the above parameters can be figured out from the InvokeWebService activity component, but some I had to play with to get it to work properly.

  • portportBindingLocalName must be set to the actual web service portBindingLocalName otherwise you will get the following error:
2013-07-16 13:51:26,214 ERROR [com.adobe.workflow.AWS] (http- An exception was thrown with name com.adobe.idp.dsc.webservice.exception.WebServiceConfigurationException message:Configuration error - port specified is unavaliable:  while invoking service WebService and operation invoke and no fault routes were found to be configured.

note: The portBindingLocalName is never shown in the WebServiceSettingBean editor. There are two ways to find it:

1. Look into the WSDL xml and you will see:

 <wsdl:binding name="[portBindingLocalName]" type="...">

2. Use a soap tester like SoapUI that shows the binding name when it sets up the WSDL.

How to find the portBindingLocalName


The steps

1. Create a WebServiceSettingBean variable and assign it as the input Options for the InvokeWebService activity.

Create WebServiceSettingBean

Create WebServiceSettingBean

Select WebServiceSettingBean type

Select WebServiceSettingBean variable type


Set Activity Options

2. Create a simple process that maps all of the bean parameters from input variables to create the bean. This also allows you to use template parameters for the inputRequest that use embedded XPath.

CreateWebServiceSettingBean process

CreateWebServiceSettingBean process

3. In your process, call the Create Settings Bean process where you set all of the Bean variables, then call the InvokeWebService activity using the Bean created in #2 as input.

Main Process

Main Process


I have provided an example application so you can see the workaround in action. It creates an example WSDL that it calls itself to show how the settings are applied to the bean and then invoked. Adjust the server name and port and administrator account details as necessary. They are all default for a turnkey ES4 install.



SoapUI example

SoapUI example

Easily the best way to create your inputRequest and get the portBindingLocalName is using SoapUI. Using the Generate button in the activity doesn’t give you all of the input variables for the WSDL you are accessing. Plug the WSDL URL into SoapUI and you will get a proper view of the WSDL request query so you can XPath it as necessary.

Beware of the ?blob=base64 bug in later version though. I will do a post to highlight this issue in the future. For now I use version 3.6.1 for most of my work.


About Darren
I am a Senior Consultant and for BizTECH Enterprise Services (Australia) specialising in AEM Forms and Adobe LiveCycle, Document Services and Adobe Experience Manager.

5 Responses to WSDL URL and WebServiceSettingBean

  1. Keith says:

    Hey Darren this is awesome and I implemented it in my development environment as a test. I am running into a problem and I am wondering if you are experiencing an issue with it as well. This works flawlessly until I restart jboss for any reason on my server. The moment I restart jboss I start getting a failed to find certified path error for the invoke web service process step that uses the webservicesettingbean variable. The weird thing is if I run a completely different web service that isn’t using a webservicesettingbean variable it fixes this error for the web service that is using a webservicesettingbean variable. I can also fix the problem by going in to the recording of the failed process and opening the populated webservicesettingbean variable and hitting load on in the webservice dialog that pops up. Doing either of the fixes will cause the invoke web service to function properly again until jboss is restarted. Have you experienced issues like this doing the method described in this article? Thank you!

    • Darren says:

      Hi Keith – no I haven’t seen this behaviour before. It makes me think that somehow on a restart the actual Bean isn’t fully available to the J2EE server and will fail. Using a normal WebService call somehow instantiates this and allows the WebServiceSettingBean to operate normally.

      One workaround I can think of is to set a dummy process up that you call via a WebService invoke internally just before using the WebServiceSettingBean object. This should then make sure the Bean is instantiated before you try to use it. You might find that this is a catch-22 situation, however. Move environments and you no longer have a dummy process to call on the environment you are on. Use localhost as your server name in the WSDL URL, and you should be good.

      Failing that, I am wondering how easy it is to hack the Adobe WebServices DSC to change the activity dialog so we can have an XPath value for the WSDL URL…

  2. Kim Christensen says:

    Hi again Darren,

    Very nice post you have created here. This information is very helpful ot me. I have had a look at your LCA, and I would like to ask you if you could elborate on the use of Attachments and the WSDL Map. What are they used for and how?

  3. Steve says:

    Thanks for writing this article, it was really helpful.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


Everything AEM aka CQ5 based on my experience listed here.

Adobe AEM The Right Way

Best practices, tips, and tricks for your Adobe AEM project


A WCM journey with Day/Adobe CQ

Technoracle (a.k.a. "Duane's World")

A multi-purpose toolkit for the Adobe LiveCycle and AEM Forms developer.

Adobe LiveCycle Blog

A multi-purpose toolkit for the Adobe LiveCycle and AEM Forms developer.

A multi-purpose toolkit for the Adobe LiveCycle and AEM Forms developer.


A multi-purpose toolkit for the Adobe LiveCycle and AEM Forms developer.

Code Monkey

Ramblings of a Developer

%d bloggers like this: