Wsdl Reader Laravel Package

Getting Started

php-soap/wsdl-reader sits at the bottom of the php-soap stack — it turns a WSDL document into a typed object graph you can navigate in PHP. You rarely install it directly; it arrives as a transitive dependency of php-soap/wsdl-driver, php-soap/wsdl, or php-soap/engine. Install it standalone only when your only job is reading a contract (validation, codegen, diffing, docs).

# Typical: pulled in via a driver
composer require php-soap/wsdl-driver

# Standalone introspection only
composer require php-soap/wsdl-reader

Where to look first. Open the package source (src/) rather than hunting for a docs site — the public surface is small and readable. Start at the loader/reader entry point, then follow into the model classes: Definitions, Service, Port, Binding, PortType, Operation, Message, Schema, Type. That class tree is the API documentation.

First use case — list the operations a WSDL exposes:

use PhpSoap\WsdlReader\WsdlReader;
use PhpSoap\WsdlReader\Model\Definitions\Definitions;

$definitions = (new WsdlReader())->readFromFile(storage_path('wsdl/billing.wsdl'));

foreach ($definitions->services as $service) {
    foreach ($service->ports as $port) {
        // $port->binding, $port->location ...
    }
}

The exact loader signature has moved across 0.x releases; a quick grep -r "function read" src/ on the installed tag will confirm the entry point for your pinned version.

First sanity check: dump a parsed model with symfony/var-dumper (dump($definitions)) — the package already depends on it, and reading the object graph once will teach you the API faster than any tutorial.

Implementation Patterns

1. Bootstrap-time introspection, cached. Parsing happens at client construction or cache-warm, never per request. Wrap it:

$definitions = Cache::rememberForever(
    "wsdl:{$name}:".md5_file($path),
    fn () => (new WsdlReader())->readFromFile($path),
);

Keying on the WSDL file hash invalidates automatically when a vendor updates their contract.

2. Operation discovery for a dynamic client. Use the model to look up an operation by name, resolve its input message and part types, and feed those into your transport layer instead of hand-building envelopes:

foreach ($definitions->portTypes as $portType) {
    foreach ($portType->operations as $operation) {
        // build a name => Operation map for routing
    }
}

3. WSDL-to-DTO / stub generation. Walk Schema types recursively and emit PHP classes. Namespaces and xsd:complexType nesting make this the most valuable pattern — the parser handles the import/ref edge cases you'd otherwise get wrong. Keep your generator in app/Console/Commands and treat output as build artefacts, not source.

4. Contract-change detection. Parse both WSDLs into the model and diff semantically (operations, message parts, attribute qualification) rather than textually. A wsdl:diff artisan command that runs in CI against a captured vendor WSDL catches upstream changes before they break integrations.

5. Integration with the SOAP client. When using php-soap/engine + a driver, you're working one level up — the driver consumes this reader internally. Reach for the reader model directly only when you need metadata the client doesn't expose (service endpoints, target namespaces, schema attribute details).

6. Fixture-driven tests. Commit a handful of real WSDLs (including attribute ref and no-namespace schema cases) under tests/Fixtures/wsdl/ and assert on the parsed model. This is your safety net against 0.x behaviour changes.

Gotchas and Tips

0.x semantics, not just signatures. Version 0.x means minor bumps can silently change model behaviour. 0.34.0 is a case in point: two fixes changed whether attribute ref declarations are reported as qualified or unqualified. Pin tightly (~0.34.0) and read every changelog.

Attribute qualification affects the wire. Those namespace fixes flow through to serialized requests. If a consuming .NET/JAX-WS service uses attribute ref, your request bodies may differ post-upgrade. If it worked before and now fails with schema validation, this is the first suspect.

Stale cached models are a silent failure mode. Upgrading the library without clearing cached Definitions or generated proxies leaves old (incorrect) interpretation in place. Bump your cache key on any package upgrade, and invalidate generated stubs as part of deploy.

Failures surface as boot-time errors, not parse errors. A malformed or unsupported WSDL throws during client construction — a 500 at deploy or after cache clear. Warm caches in a deploy step and assert against a real endpoint in health checks.

symfony/var-dumper is likely dev-oriented. It's a dependency for model debugging. Confirm whether it's require or require-dev in your resolved graph before worrying about it in production.

Extension points are thin by design. There's no service provider, no config, no DI bindings. Extension happens by consuming the model — subclass nothing, compose everything. If you need behaviour the model doesn't expose, parse the raw DOMDocument alongside it rather than fighting the abstraction.

Enable ext-dom and ext-libxml. Obvious, but CI containers with minimal PHP builds trip here. Add both to your composer.json require to fail fast.

Debugging tip. When a model field looks wrong, dump the corresponding XML fragment. Nearly every issue is namespace resolution (default namespace, targetNamespace, unqualified attributes) — comparing the DOM against the model localises it immediately.

Don't adopt it alone for a single static call. If you need one SOAP call against a stable WSDL, generated code from wsdl2php or a hand-written SoapClient is less surface area. This package pays off for introspection, tooling, and contract management across multiple services.