Accessing SOAP service from the WorkLight app

In the Using JQuery Mobile in WorkLight application entry i built a WorkLight application that takes contact last name as input and uses it to search for contact by using WorkLight SQL adapter, i wanted to check if i can achieve same functionality by using SOAP service so these are the steps that i used
  1. First i did build a simple JAXWS service that takes last name of the contact as input parameter and returns list of contacts with matching last name, you can download the service that i used from here
  2. Next i used the WorkLight studio to create a HTTP Adapter, i used ContactWSService as name for that adapter
  3. After creating the adapter i change the ContactWSService-impl.js that was generated to look like this
    function searchContact(lastName) {
     var searchContactRequest = '<soapenv:Envelope '+  
       'xmlns:q0="" '+  
       'xmlns:soapenv="" '+  
       'xmlns:xsd="" '+  
       'xmlns:xsi=""> '+  
       '<soapenv:Header> '+  
       '</soapenv:Header> '+  
      '<soapenv:Body> '+ 
      '<q0:searchContact> '+
       '<arg0>'+lastName+'</arg0> '+
       '</q0:searchContact> '+
       '</soapenv:Body> '+  
     '</soapenv:Envelope> ';
     WL.Logger.debug("SOAP Request " + searchContactRequest);
     var input = {
         method : 'post',
         returnedContentType : 'xml',
         path : '/ManageContactWS/contactws',
          content: searchContactRequest.toString(),
          contentType: 'text/xml; charset=utf-8'
     return WL.Server.invokeHttp(input);
    In order to make a SOAP request call you will have to create the SOAP message first, i used the Eclipse Web Services Explorer tool to first test my SOAP service and then copied the XML SOAP message that it used for request into my JavaScript file. Once i have the SOAP message in String format i used it to make HTTP POST call
  4. Next i had to change the ContactWSService.xml the deployment descriptor for my adapter to declare searchContact procedure, after changes the file looks like this
    <?xml version="1.0" encoding="UTF-8"?>
    <wl:adapter name="ContactWSService"
        <connectionPolicy xsi:type="http:HTTPConnectionPolicyType">
        <loadConstraints maxConcurrentConnectionsPerNode="2" />
      <procedure name="searchContact"/>
  5. The last change was in the WorkLight application code where i make the adapter call and parse the returned results so that i can display them, This is how my .js file looks like
    function getContact(){
     console.log("Entering getContact() REST service based version");
     var contactName = $('contactName').getValue();
     var invocationData = {
     var options ={
     WL.Client.invokeProcedure(invocationData, options);
    function loadContactSuccess(result){
     console.log("Inside loadContactSuccess " + result);
     var html = '';
     if(result.status == 200){
      var contactList = result.invocationResult.Envelope.Body.searchContactResponse.contactList;
      var i = 0;
      for(i =0 ; i < contactList.length ; i++){
       var currentContact = contactList[i];
       html =  html + '
  6. '+currentContact.firstName +' ' +currentContact.lastName +'
  7. '; } } jq("#displayContact").html(html); jq("#displayContact").listview('refresh'); } function loadContactFailure(result){ console.log("Inside loadContactError " + result); }
    Important Note: By default the JAXWS wraps the return value in XML element named return and the WorkLight server simply uses the same name while converting the XML result into JSON object, but that makes accessing the return element difficult in the client javascript because return is the JavaScript keyword and you can not use it in your code. So to get around this problem i had to change my sample web service and use JAXWS annotation to customize name of the return element to contactList


Anonymous said...


I am try the same code with ASP.NET Web service. The client application is not parsing the result.Envelop.Body....

Web Service:

Dmitry said...


When it comes to parsing of the result, I bumped into the same problem. But then I found out that it was necessary to use result.invocationResult.Envelop.Body

It worked for me afterwards.