We’re running Agile 9.3.6 and experiencing consistent failures when updating project tasks through SOAP API from our external project management tool. The integration worked fine for weeks, but now we’re getting XML parse errors on every task update attempt.
The error occurs specifically during the export mapping phase when our external tool sends task status updates. Here’s the error we’re seeing:
SOAPFaultException: XML validation failed
at com.agile.api.SOAPClient.updateTask(SOAPClient.java:445)
Caused by: org.xml.sax.SAXParseException: Invalid content
We haven’t changed our XML schema or the SOAP request structure. The task creation works perfectly, but updates fail consistently. Our middleware validates the XML against the schema before sending, so we’re confused about what’s triggering the validation failure. Has anyone encountered similar SOAP API XML schema validation issues with project task integration?
I’m dealing with something similar in our environment. The XML schema validation between external tools and Agile SOAP services can be finicky, especially around project task integration. One thing that helped us was implementing a transformation layer in our middleware that normalizes all datetime fields before sending to Agile. We strip timezones and format everything as ‘yyyy-MM-dd HH:mm:ss’. We also added explicit null handling - if a field is null or empty in the source system, we completely omit that XML element from the SOAP request rather than sending empty tags. This approach has made our integration much more stable across Agile patches.
The datetime format issue makes sense now. In update operations, Agile’s SOAP API can be more restrictive about field formats than in create operations, especially after patches. For project task updates specifically, you need to use Agile’s specific datetime format: ‘yyyy-MM-dd HH:mm:ss’ without timezone indicators. ISO 8601 with timezone suffixes often fails on updates even though creates accept them. Also verify your export mapping in the external tool isn’t adding milliseconds to the timestamp. The SOAP endpoint for updates validates more strictly against the internal field definitions, while creates have more lenient parsing. This is a known quirk in the project management module’s SOAP implementation.
Quick question - are you sending null values for optional fields? We had a similar problem where our integration was explicitly sending null values in the XML payload for optional task attributes. Agile’s SOAP parser got stricter about this in some versions. Instead of sending <taskStatus>null</taskStatus>, try omitting the element entirely if there’s no value. This fixed our parse errors immediately.
I’ve seen this before with SOAP integrations. The issue often comes down to schema version mismatches between what your external tool expects and what Agile is actually enforcing. Even if you haven’t changed anything on your side, Agile patches can sometimes tighten XML validation rules. Check if there was a recent patch applied to your 9.3.6 instance. Also, enable detailed SOAP logging in Agile to see exactly which element is failing validation.
Perfect! That solved it. Here’s what I did to fix the XML parse errors:
Root Cause: The 9.3.6.5 patch tightened XML schema validation for SOAP task updates, specifically around datetime formatting and null value handling.
Solution - Three-part fix addressing all the key integration points:
1. SOAP API XML Schema Validation Fix:
Modified our middleware transformation to enforce strict datetime formatting:
SimpleDateFormat agileFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
agileFormat.setTimeZone(TimeZone.getDefault());
String formattedDate = agileFormat.format(taskDate);
taskElement.setEstimatedFinishDate(formattedDate);
This ensures all datetime fields match Agile’s expected format without timezone indicators or milliseconds.
2. External Tool Export Mapping Configuration:
Updated our project management tool’s export mapping to handle optional fields properly:
- Changed mapping rules to completely omit XML elements when source fields are null/empty
- Added validation step before export to verify datetime fields don’t include ISO 8601 timezone suffixes
- Implemented field-level transformation rules that strip milliseconds from timestamps
The key was configuring the export to NOT send <field>null</field> or <field></field> tags - just omit them entirely.
3. Project Task Integration Error Handling:
Enhanced our integration layer with:
- Pre-validation against Agile’s WSDL schema before sending SOAP requests
- Detailed logging of XML payload structure for failed requests
- Automatic retry logic that reformats datetime fields if initial validation fails
- Schema version checking to detect when Agile patches modify validation rules
Additional Configuration:
In Agile Java Client, updated SOAP endpoint configuration:
com.agile.api.soap.validation.strict=false
com.agile.api.soap.datetime.format=yyyy-MM-dd HH:mm:ss
This provides more lenient validation while still enforcing core schema requirements.
Testing Results:
- Task updates now process successfully with 100% success rate
- Average processing time reduced from 3.2s to 1.8s (validation overhead eliminated)
- No more XML parse errors in logs
- Integration handles both create and update operations consistently
The critical lesson: SOAP update operations enforce stricter XML schema validation than create operations, especially after patches. Always implement middleware transformation layers that normalize data formats to Agile’s specific requirements, and omit optional fields entirely rather than sending null values. Project task integration specifically requires careful datetime handling and proper null value management in the export mapping configuration.