Web service integration returns null for custom regulatory fields after WSDL update

Our external compliance system integrates with Agile via web services to pull regulatory data. After updating field mappings for custom compliance attributes, the web service calls return null for these fields even though the data is visible in the Agile UI.

Field mapping configuration:

<field name="RegulatoryStatus" apiName="PAGE_THREE.REGULATORY_STATUS"/>
<field name="ComplianceDate" apiName="PAGE_THREE.COMPLIANCE_DATE"/>
<field name="CertificationBody" apiName="PAGE_THREE.CERT_BODY"/>

The web service response shows null for all three custom fields, but standard fields populate correctly. We’ve verified the field API names are correct and match the Agile schema. The integration worked fine before we added these custom fields to the regulatory items subclass last month.

Do we need to regenerate the WSDL after adding custom fields? Is there a web service cache that needs refreshing?

Check your web service client cache as well. If you’re using a Java client with JAX-WS, it caches the service definition locally. Even after regenerating the WSDL on the server, your client might still be using the old schema. Delete the client-side generated stubs and regenerate them from the new WSDL URL.

Beyond WSDL regeneration, check if your custom fields are marked as web service accessible in the field configuration. In Agile 9.3.5, custom fields need the “Include in Web Services” flag enabled. Also verify that the user account your web service uses has read permissions for PAGE_THREE attributes on the regulatory items subclass. Permission issues often manifest as null values rather than explicit access denied errors in web service responses.

Another thing to verify: are these fields populated for the specific items you’re querying via the web service? I’ve seen cases where the web service returns null if the field value is empty in the database, even though the UI shows a default value. The UI applies default values client-side, but web services return the raw database value. Try querying an item where you’ve explicitly set values for these regulatory fields to rule out empty data versus mapping issues.

I’ll walk through the complete solution addressing all three key areas: web service cache refresh, custom field mapping in XML, and WSDL regeneration.

1. Web Service Cache Refresh (Server and Client Side)

Server-side cache clearing is essential after schema changes:


// Pseudocode - Server cache refresh steps:
1. Navigate to Admin > Services > Web Services in Agile UI
2. Select "Item Service" from the service list
3. Click "Regenerate WSDL" button
4. Stop Agile application server (all nodes if clustered)
5. Clear application server work directory: {AGILE_HOME}/agileDomain/servers/AgileServer/cache
6. Restart application server and verify WSDL URL accessibility
// See: Agile PLM Administrator Guide Section 12.4

Client-side cache must also be cleared:

// Delete old generated stubs
rm -rf src/generated/webservice/*

// Regenerate from new WSDL
wsimport -keep -p com.company.agile.ws \
  http://agile-server:7001/CoreService/Item?WSDL

2. Custom Field Mapping in XML (Correct Syntax for Flex Pages)

The field mapping syntax for PAGE_THREE attributes requires the internal attribute ID, not the display name:

<!-- INCORRECT - Using display names -->
<field name="RegulatoryStatus" apiName="PAGE_THREE.REGULATORY_STATUS"/>

<!-- CORRECT - Using attribute IDs -->
<field name="RegulatoryStatus" apiName="PAGE_THREE.1007"/>
<field name="ComplianceDate" apiName="PAGE_THREE.1008"/>
<field name="CertificationBody" apiName="PAGE_THREE.1009"/>

To find the correct attribute IDs:

SELECT id, attrib_name, visible_name
FROM attribute
WHERE attrib_name IN ('REGULATORY_STATUS', 'COMPLIANCE_DATE', 'CERT_BODY')
AND page_id = (SELECT id FROM page WHERE api_name = 'PAGE_THREE');

3. WSDL Regeneration Process (Complete Workflow)

Proper WSDL regeneration requires multiple steps:

a) Enable Web Service Access for Custom Fields

  • Admin > Data Settings > Classes & Attributes
  • Select Regulatory Items subclass
  • For each custom field: Properties > “Include in Web Services” = checked
  • Verify “Searchable via Web Services” is also enabled if needed for queries

b) Verify Subclass Configuration

  • Custom fields must be defined at the subclass level, not just page level
  • Check that PAGE_THREE is properly associated with Regulatory Items subclass
  • Ensure no field name conflicts with base class attributes

c) Regenerate and Validate WSDL


// Pseudocode - WSDL validation steps:
1. Access regenerated WSDL URL in browser
2. Search for custom field definitions in XSD schema section
3. Verify element names match your attribute IDs (e.g., "1007", "1008", "1009")
4. Check that fields appear under correct complex type for subclass
5. Test with SOAP UI before updating production client
// Expected: Custom fields visible in schema with correct data types

4. Web Service Client Configuration

Update your client code to use attribute IDs:

// Get custom regulatory fields using attribute IDs
IItem item = itemService.getItem(itemNumber);
String regulatoryStatus = item.getValue("1007"); // PAGE_THREE.1007
Date complianceDate = item.getDateValue("1008"); // PAGE_THREE.1008
String certBody = item.getValue("1009"); // PAGE_THREE.1009

Common Pitfalls:

  • Permission Inheritance: Even with admin privileges, the web service user needs explicit READ_MODIFY_DELETE on the specific subclass. Check role-based access for Regulatory Items, not just base Items.

  • Field Population: Web services return database values without UI defaults. Verify fields have actual data: `SELECT COUNT(*) FROM item WHERE item_number = ‘TEST-001’ AND c_1007 IS NOT NULL;

  • Clustered Environments: In clustered deployments, regenerate WSDL once but restart ALL application server nodes. Cache inconsistency across nodes causes intermittent null returns.

  • Client Timeout: After regeneration, the first web service call may timeout while the server rebuilds internal metadata. Implement retry logic with exponential backoff.

After implementing these changes, test with a simple SOAP request to verify the custom fields now return values before updating your full integration. The combination of correct attribute ID mapping, complete cache refresh, and proper WSDL regeneration should resolve the null value issue.

I regenerated the WSDL and restarted the app server, but still getting nulls. Checked the field configuration and “Include in Web Services” is enabled for all three fields. The service account has full admin privileges, so permissions shouldn’t be the issue. Could there be a problem with the XML field mapping syntax? The custom fields are on a flex page (PAGE_THREE) rather than the base titleblock. Does that require different mapping notation?