Weave Code
Engine Laravel Package
php-soap/engine
A modern SOAP engine for PHP, offering a robust foundation for building SOAP clients and servers with WSDL handling, type mapping, and reliable interoperability for enterprise and legacy web services.
SOAP engine design
Frequently asked questions about Engine
- How do I install and configure php-soap/engine in a Laravel application?
- Install it with composer require php-soap/engine, along with a PSR-18 transport adapter and a PSR-18 client; Laravel already ships guzzlehttp/guzzle, which implements Psr\Http\Client\ClientInterface. Then create a service provider that binds a configured engine instance (WSDL location, endpoint, transport, cache store) as a singleton, and wrap it in one small gateway class per external service. Typed DTO generation is optional and adds a build step, so many teams hand-write DTOs and map them inside the gateway adapter.
- Is php-soap/engine a drop-in replacement for PHP's ext-soap extension?
- No, it is a pure-PHP reimplementation of the SOAP runtime rather than a wrapper around the C extension, so the API is entirely different and you will not get SoapClient method signatures or class mapping for free. The value is that envelope building, encoding and transport are separate, pluggable seams, which makes the integration testable and lets you add middleware such as WS-Security headers or correlation IDs. The trade-off is that WSDL edge cases ext-soap tolerates may surface here, so prove a WSDL against the engine before committing and keep an ext-soap fallback path for stubborn services.
- Which PHP and Laravel versions does php-soap/engine support?
- The package is framework-agnostic and does not depend on Laravel's request lifecycle, container or ORM, so it is not tied to a specific Laravel release. In practice it needs a modern PHP runtime and a PSR-18 HTTP client, which Laravel's bundled Guzzle provides on all currently supported versions. Always read the composer.json constraints in the repository for the exact PHP requirement before adopting it, because the package is maintained independently of Laravel's support window.
- How do I cache WSDL parsing in Laravel so it does not run on every request?
- Treat WSDL caching as mandatory at production scale, because parsing a large document on every outbound call adds noticeable latency to cold requests. Back the engine's parsed WSDL with Laravel's cache repository or the maintainers' cached-engine companion, keyed by WSDL URL plus a hash of the document, and give it a TTL that matches how often your providers actually change schemas. Measure cold and warm boot times in your proof of concept, and add a refresh command so schema changes can be pulled in deliberately rather than by expiry surprise.
- Does php-soap/engine support SOAP 1.1, SOAP 1.2, WS-Security and MTOM attachments?
- SOAP 1.1 and 1.2 envelope handling is built in, covering SOAPAction and the differing content types and header conventions between the two versions. WS-Security and similar WS-* concerns belong in the encoder/decoder pipeline, so security headers and WSU timestamps are pluggable middleware rather than baked-in behaviour. MTOM and binary attachments, along with more advanced WS-Security profiles, should be verified against your actual requirements before you commit, so enumerate the WS-* features each contract demands up front.
- How do I test a Laravel SOAP client built on php-soap/engine without hitting a real endpoint?
- Because the engine is transport-agnostic and speaks PSR-18, you can bind a fake PSR-18 client in the container that returns recorded SOAP envelopes instead of making a network call. That means feature tests assert on the outgoing XML and on how your gateway maps faults to domain exceptions, with no live network and none of the pain of mocking ext-soap. Keep recorded WSDL snapshots in the repository and run contract tests against them in CI to catch provider schema drift early.
- How do I wire the engine's transport to Laravel's HTTP client and Guzzle?
- Bind a PSR-18 adapter around Guzzle in your service provider and resolve the engine with that transport, so SOAP calls ride the same outbound HTTP stack as the rest of the application. That inheritance is the main benefit: Laravel HTTP client middleware, timeouts, retries, logging and proxy configuration all apply without a second outbound path to reason about. Configure endpoint, timeout and transport per service in config/soap.php, keyed by environment.
- How do I manage multiple SOAP services and per-environment endpoints in Laravel?
- Define one entry per external service in config/soap.php holding the WSDL path, environment-specific endpoint, timeout, cache store and cache TTL. Register each engine as a named singleton and expose it behind a domain-level interface such as App\Soap\Contracts\{Service}Gateway so the rest of the app never sees SOAP types. Putting that interface boundary in place from day one is the highest-leverage decision, because it keeps the engine replaceable if the upstream project stalls or a particular WSDL forces a fallback.
- Is php-soap/engine mature enough for production, and what are the alternatives?
- The technical design is sound and MIT-licensed, but the adoption signal is low, so treat it as a build-versus-buy bet rather than an established standard. The realistic alternatives are ext-soap, which is battle-tested but hard to test and middleware-hostile, or a higher-level client package that may itself sit on top of this engine. Mitigate the risk by isolating it behind your own interfaces, budgeting an internal owner for the integration glue, and keeping the ext-soap fallback available for services whose WSDLs do not parse cleanly.
- How do I log SOAP envelopes and inject correlation IDs in a Laravel integration?
- Add middleware around the transport layer that injects a correlation ID header into the outgoing envelope and logs the request and response XML with PII redacted. Keep the redaction list explicit and tested, because SOAP payloads in enterprise integrations routinely carry names, account numbers and addresses. Also emit timing metrics around the engine call so slow providers and cold WSDL parses show up in the same dashboards as your other outbound HTTP traffic.
Weaver
How can I help you explore Laravel packages today?