Integrating a legacy ERP over SOAP: the bug was never in my code
When you integrate against a system you don't control, attributing the error is half the work.
When you integrate against a system you don't control, writing the call is the easy part. The hard part is figuring out who's at fault when it fails — and for a long time I assumed the fault was mine.
The generic error
The traceability system talks to the Nodum ERP over SOAP. Early on, a failed operation surfaced the same way every time: Error al grabar — "save failed". No code, no field, no reason. My first instinct was to debug my own request: the payload, the envelope, the types.
TODO: describe a concrete case where the request was correct and the failure came from the ERP anyway.
Where the error actually lived
The failures weren't in my code. They were in the ERP's state at the moment of the call: an accounting period that was already closed, an item with no stock, a record locked by another process. From the outside, all of them looked identical — the same Error al grabar.
TODO: list the real ERP-side conditions I hit, and how each one manifested.
Logging as the only instrumentation
I couldn't attach a debugger to the ERP, and I couldn't change how it reported errors. The only lever I had was on my side of the wire: log every request and every raw response to a file, before parsing.
TODO: show the shape of the logging (what I captured, where, why to a file), without any production data.
Once the raw responses were on disk, the "generic" error stopped being generic. The ERP was telling me the cause all along — I just hadn't been listening on the right channel.
The takeaway
TODO: close with the general principle — integrating against a system you don't own means building the instrumentation that makes its failures legible, because you can't fix what you can't attribute.