MuleSoft中REST调用SOAP服务返回空值问题排查求助

Let’s walk through the key areas to investigate based on your scenario, configuration, and the empty response issue you’re facing:

1. Fix Inconsistent Namespace Declarations in DataWeave #

Looking at your DataWeave scripts, there’s a critical mismatch in the SOAP operation namespace:

• In the getCustomerByLastName flow’s Web Service Consumer, you declare:

  output application/xml ns ns0 http://www.example.org/us12
  

• But in the getCustomerDB:\soapkit-config flow’s transform, you use:

  output application/java ns ns0 http://www.example.org/us12/
  

Notice the trailing slash in the second namespace. SOAP/WSDL namespaces are fully character-sensitive—this mismatch will break your data mapping entirely, leading to null values across all fields. Ensure the namespace exactly matches what’s defined in your SOAPUS12.wsdl file.

2. Handle Database Query Results Correctly #

The Mule DB select component returns a List<Map> by default, even if only one row matches your query. In your getCustomerDB:\soapkit-config flow’s transform, you’re accessing payload.id directly—this will return null because payload is an array, not a single object.

Update the transform to handle the array properly:

output application/java ns ns0 http://www.example.org/us12/ --- 
{ 
  body: { 
    ns0#getCustomerDBResponse: (payload default []) match {
      case [] -> { id: 0, first_name: "", last_name: "", birth_date: "", street: "", city: "", country: "", phone: "" } // Handle no results
      case [item] -> { 
        id: item.id, 
        first_name: item.first_name, 
        last_name: item.last_name, 
        birth_date: item.age, // Double-check if your DB uses 'age' or 'birth_date' here!
        street: item.street, 
        city: item.city, 
        country: item.country, 
        phone: item.phone 
      }
    } 
  } 
}

Also, verify the field mapping for birth_date: you’re mapping it to payload.age—if your customer_aux table has a birth_date column instead of age, this will leave that field empty.

3. Validate Parameter Passing to the Database #

Add a Logger component right before the DB select in getCustomerDB:\soapkit-config to confirm the input parameter is correctly populated:

<logger level="INFO" message="DB Input Parameters: #[db:input-parameters]" />

If the last_name parameter is null or empty, your DB query will return no results. Double-check that the SOAP request’s last_name element is correctly extracted from payload.body.ns0#getCustomerDB.last_name—this depends entirely on the structure defined in your WSDL.

4. Debug the Full SOAP Request/Response Flow #

• Add a Logger after the wsc:consume in getCustomerByLastName to inspect the raw SOAP response:

  <logger level="INFO" message="SOAP Response: #[payload]" />
  

  If this response is already empty, the issue lies in the SOAP service flow (getCustomerDB:\soapkit-config). If it has data, the problem is in the final DataWeave transform.
• Enable DEBUG logging for org.apache.cxf in your log4j2.xml to capture full SOAP request/response XMLs:

  <Logger name="org.apache.cxf" level="DEBUG" additivity="false">
    <AppenderRef ref="Console"/>
  </Logger>
  

  This will show you exactly what’s sent to the SOAP service and what’s returned, making mapping issues easy to spot.

5. Verify Minor Variable/Field Name Differences #

Even small differences in names can break mappings:

• Confirm the SOAP operation name (getCustomerDB) exactly matches what’s in the WSDL.
• Check that all field names (last_name, first_name, etc.) are consistent across:
  • The SOAP request/response schema
  • The customer_aux database table
  • Your DataWeave scripts

Final Quick Check #

Ensure your Web Service Consumer points to the correct SOAP endpoint: your Web_Service_Consumer_Config uses address="http://localhost:8087/us12/us12SOAP/", which matches the listener in api-main—that part looks correct, but double-check the endpoint is reachable and the SOAP service is deployed properly.

内容的提问来源于stack exchange，提问作者Gerardo Lopez