Totvs Rm Soap Laravel Package

Product Decisions This Supports

• Whether to integrate with TOTVS RM at all — and how. RM is a system of record for HR/payroll, education, and financial data in many Brazilian enterprises. This package makes the technical half of that decision cheap: it removes hand-written SOAP envelopes and client bootstrapping from the estimate. The PM decision that remains is scoping — which RM data do we need, in which direction, at what freshness?
• Build vs. buy vs. vendor → "adopt + fork." The wrapper is thin, MIT-licensed, and small. That supports a decision to adopt rather than build a bespoke client, with the explicit caveat that owning a fork is the fallback plan (see risks). Compared to a TOTVS-certified middleware or iPaaS license, this is a near-zero-cost option for a single integration; compared to building in-house, it saves the XML/transport plumbing and the test scaffolding.
• Feature fit — first release scope. Good targets: read-only lookups and request-scoped writes (employee/headcount sync, enrollment or academic records, financial movement queries, HR self-service data), where the call can be synchronous and cached. Poor targets for v1: bulk migrations, payroll closing, anything requiring high throughput or guaranteed ordering.
• Roadmap sequencing. v4.5.0 is a hardening release — docs, mocked happy-path tests, XML generator tests, provider transient/shared tests, Pint/PHPStan/Dependabot. No breaking changes. That makes this a safe pilot slot on the roadmap rather than a release that itself needs a product decision. Recommend one integration behind a feature flag, one endpoint family, before committing roadmap capacity.
• Delivery-confidence inputs. 57 tests / 158 assertions, static analysis, and lint gates give a citable quality signal in go/no-go reviews — offset by community signals that are effectively zero (1 star, 0 dependents). That combination means "technically credible, commercially unvalidated."
• Risk register entry, not just a dependency choice. The dominant risk is not the package; it is the upstream WSDL contract owned by TOTVS and a single-maintainer bus factor. Both need a named owner and an exit plan before this reaches a customer-facing commitment.

When to Consider This Package

Consider adoption when:

• TOTVS RM is already the system of record and a REST/JSON path does not exist or is gated behind a commercial license you have not bought.
• The stack is Laravel/PHP and you want native config, service-container bindings (transient/shared), and a mockable client instead of ad-hoc SoapClient code scattered across the app.
• The integration is request-scoped and moderate-volume — user-triggered lookups, scheduled syncs, back-office workflows — where synchronous SOAP latency is acceptable.
• Caching and fail-fast matter because RM or the network in front of it is slow or intermittently unavailable; you want stale-tolerant reads and typed failures rather than silent corruption.
• You can test without a live endpoint — the mocked SoapClient tests indicate integration code can be unit-tested in CI, which is a real cost saver in regulated or slow-change environments.
• You have a homologation/sandbox RM environment and someone who can chase credentials and WSDL versions with the TOTVS reseller or internal ERP team.
• You are comfortable vendoring. MIT license plus zero dependents means you should assume you may need to fork and maintain. That is acceptable for an internal integration; it is a harder sell for a product commitment.

Look elsewhere when:

• A TOTVS-certified middleware, ESB, or iPaaS is already licensed in the organization — reuse the platform and avoid a second integration path.
• You need vendor-backed SLAs, support contracts, or indemnification. There is no commercial support here, and one maintainer.
• The workload is high-throughput, async, or queue-driven. SOAP request/response is synchronous; throughput will be bounded by upstream latency. Use an event/queue architecture with a durable adapter instead.
• You need advanced WS-Security, SOAP 1.2 profiles, or fine-grained contract governance — nothing in the evidence suggests those are covered.
• The team is not PHP/Laravel, or cannot own PHP-level SOAP/XML debugging. Troubleshooting a malformed envelope without PHP fluency is an expensive on-call experience.
• Community validation is a hard gate in your dependency policy. 1 star and 0 dependents will fail a standard third-party risk review; plan the exception or the fork up front.
• You need schema-first contract tooling (OpenAPI-style governance, generated clients, contract tests) — WSDL is not that.

How to Pitch It (Stakeholders)

For executives: We have an unavoidable integration with TOTVS RM, a Brazilian ERP that exposes SOAP rather than modern REST APIs. This package is a small, MIT-licensed Laravel library that removes most of the custom plumbing for that integration and ships with an automated test suite and CI quality gates. The latest version is purely a hardening release — documentation, expanded tests, static analysis, dependency automation — with no breaking changes, so adopting it carries low technical risk and does not lock us into a contract. The commercial caveat is that it is a single-maintainer open-source project with no paid support, so the recommendation is a time-boxed pilot on one integration behind a feature flag, with the source vendored into our repository as an insurance policy. Expected outcome: shorter time-to-integration and lower long-term maintenance cost than a bespoke adapter, at the price of us owning the fork if the maintainer stops.

For engineering: Laravel-native service provider with transient/shared bindings, XML generators, and a WebService abstraction providing fail-fast behavior and caching, plus a mockable SoapClient so integration tests do not need a live RM endpoint. v4.5.0 adds docs/SERVICES.md and docs/TROUBLESHOOTING.md, happy-path tests across XML generation, WebService (fail-fast, cache), and provider lifecycle, plus CI linting of examples and Dependabot. Current CI: Pint + PHPStan + 57 tests / 158 assertions passing. Two things to settle before we build: (1) confirm ext-soap and the PHP/Laravel version floor across all environments, and (2) decide deliberately whether we hold shared bindings in queue workers or Octane — that is the state-safety trap. Assume upstream WSDL drift is our risk, not the package's; we need an internal runbook for credential expiry, schema mismatch, and cache invalidation, because fail-fast shifts retry and degradation logic onto the caller.