Pcvue Bridge Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for SCADA/HMI integration: If the roadmap includes exposing or automating PcVue supervisory data (alarms, users, tags) inside a web application, this bundle answers the "do we write our own PcVue client or consume one?" question. It is a thin OAuth2-authenticated bridge, so the decision becomes "do we accept a community-maintained dependency for a single-vendor integration?"
• Internal tooling and back-office features: The example ($ps->user->getUser('4665') returning an email) points to identity/user-lookup use cases — operator directories, notification routing, access reviews. These are plausible low-risk first features to validate value before any production-critical path.
• Framework strategy correction: The package is a Symfony bundle, not a Laravel package. Any roadmap item assuming Laravel compatibility needs re-scoping: this is only usable in Symfony applications (or via a custom adapter), which directly affects which products can consume it.
• Configuration and secrets handling: Adoption forces a decision on where PcVue credentials (client_id, client_secret, username, password) live. That is a security/ops decision, not just an integration detail — it belongs in the platform standards backlog.
• Not a candidate for customer-facing or high-availability surfaces at 1.0 with a single maintainer; treat as an enabler for internal prototypes and proofs of concept.

When to Consider This Package

Consider it when all of the following hold:

• The application is built on Symfony (the bundle registers PcvueService via services.yaml and reads a pcvue: config block in framework.yaml). Laravel or framework-agnostic codebases should look elsewhere or expect to write an adapter.
• You need a narrow, read-oriented slice of PcVue — user lookup and similar OAuth2-protected endpoints — rather than full tag/alarm/historian access.
• Your team can own the credential lifecycle: OAuth2 client ID/secret plus a service username/password must be provisioned, rotated, and kept out of VCS. The root_dir option implies filesystem assumptions worth validating in your environment.
• You accept 1.0-level maturity: no published versioning history, no stated SLA, no visible test or compatibility matrix. Pin the version and wrap it behind your own interface so it can be swapped.

Look elsewhere when:

• The target application is Laravel — there is no Laravel service provider or facade here; the integration is Symfony DI only.
• You require supported/commercial PcVue connectivity, guaranteed API coverage, or vendor-backed security review (OAuth2 credentials brokered by a maintained connector, audit logging, rate-limit handling).
• You need write operations, event streaming, or real-time alarming — nothing in the release notes suggests those surfaces exist.
• You cannot tolerate a single-maintainer, community dependency in a regulated or safety-adjacent path.

How to Pitch It (Stakeholders)

For executives: A community Symfony bundle has been released that lets our web applications talk to PcVue, the SCADA platform our operations teams already run. It handles the authentication handshake and basic data lookups — for example, resolving a PcVue user to their email address — in a few lines of code instead of a bespoke integration project. It is a cheap experiment, not a platform commitment: version 1.0, one maintainer, no vendor support. Recommendation is to fund a short timeboxed spike against a non-production PcVue instance to confirm it covers the specific calls we need, and only then decide whether to build on it or wrap it.

For engineering: This is a Symfony bundle (maillotf/pcvue-bridge-bundle), not Laravel — please correct any assumptions in the current backlog. Integration is config-only: a pcvue: block with protocol/host/port and OAuth2 client credentials plus a service account, and one service alias in services.yaml. Usage is constructor injection of PcvueService. Known gaps to close before production: secrets management for the client secret and service password, error and token-expiry handling (undocumented), test coverage, and an anti-corruption layer so the bundle's API doesn't leak into domain code. Treat the root_dir option and the FAQ as required reading during the spike.