I've been wading through the documentation and the usual vendor-provided "quick starts" for Claw, and I'm starting to suspect their entire "universal API integration" pitch was written by someone whose entire experience with legacy systems is a Postman collection hitting a JSON REST endpoint. The promise is compelling: a single, clean GraphQL interface sitting in front of our zoo of internal and external services. The reality, as I'm discovering with a particularly byzantine SOAP-based inventory system from the mid-2000s, is a swamp of XML namespaces and SOAP actions that seems to make Claw's WSDL importer choke and then quietly give up.
I've managed to get the WSDL ingested, but the generated GraphQL schema is... nonsensical. It's creating types like `GetStockLevelResponseGetStockLevelResultArrayOfStockItemStockItem`, which is less a usable API and more a parody of Java class names. The resolver it builds seems to ignore the SOAPAction header requirement entirely, and the raw XML-to-JSON transformation is dropping attributes critical for understanding which element is actually the return value.
Before I write this off as another case of "legacy-support" being a checkbox on a marketing slide, I wanted to see if anyone has actually fought this battle and won. Specifically, I'm looking for concrete configuration snippets that go beyond the basic `claw.yaml` `source` directive. I need the ugly, procedural stuff: custom XPath mappings, envelope templates, and namespace handling.
What does your Claw configuration look like when you had to tell it, explicitly, how to talk to a real-world SOAP service? For example, how did you override the default SOAP envelope generation? My current, failing attempt looks something like this, but the `transform` and `soap_action` directives don't seem to be having the intended effect:
```yaml
sources:
- name: legacy_inventory
type: soap
wsdl: http://internal/InventoryService?wsdl
endpoint: http://internal/InventoryService
operations:
GetStockLevel:
soap_action: urn:core.inventory.services/InventoryService/GetStockLevel
transform:
response:
body_to_json:
namespaces:
ns1: "urn:core.inventory.services"
xpath: /ns1:Envelope/ns1:Body/ns1:GetStockLevelResponse/ns1:GetStockLevelResult
```
The logs show the request going out, but the response is either a parsing error or an empty object. I'm half-convinced the issue is in the HTTP headers or the namespace-qualification of the body elements. Any proven recipes, especially those involving the lower-level `request_template` or custom `pre_hook` scripting to massage the payload, would be invaluable. I'm less interested in "it works for me" and more in the specific, reproducible YAML or code that made it work.
-- Cam
Trust but verify.