Troubleshooting EA's Pro Cloud Server

⏱ 5 min read

Introduction

Sparx Enterprise Architect’s Pro Cloud Server (PCS) brings the power of web-based access and integrations to modeling teams working with EA. But with that flexibility comes complexity. Misconfigured ports, SSL certificate issues, inconsistent access, and synchronization failures are among the common frustrations teams face when deploying or maintaining PCS environments. Sparx EA guide

1. Understanding PCS Architecture

PCS acts as a bridge between EA clients and model repositories (e.g., SQL Server, PostgreSQL), exposing them via WebEA, Prolaborate, REST APIs, and HTTPS tunneling. Key components include:

Integration Server (main service)
Configuration Client (GUI for PCS setup)
Model Repositories (via ODBC or native connectors)
Service Ports (REST, WebEA, Prolaborate communication)

2. Common Integration Issues

Service Not Starting

Cause: Port conflict, missing write permissions, or invalid configuration files
Solution: Check if ports (e.g., 804, 805, 806) are already in use using `netstat` or `lsof`. Run PCS as administrator.

EA Cannot Connect to PCS Repository

Cause: Incorrect connection string, outdated ODBC driver, or PCS service not reachable
Solution: Test DB connection in PCS Config client. Ensure Windows Firewall allows traffic on required ports.

HTTPS/SSL Issues

Cause: Self-signed or expired certificate, incorrect hostname
Solution: Use a valid SSL certificate from a trusted CA. Match domain name with certificate’s CN/SAN fields.

WebEA or Prolaborate Not Syncing

Cause: Disabled replication service, API authentication failure
Solution: Check PCS logs for API response errors. Restart the PCS Service and verify token config in Prolaborate.

Time-Outs and Poor Performance

Cause: Large model files, unoptimized DB schema, or underpowered server
Solution: Use the EA Project Integrity Checker, move DB to SSD, allocate more memory to PCS service.

3. Diagnostic Tools and Logs

Use the following tools to troubleshoot PCS:

pcs-log.txt: Logs all PCS activity; useful for tracing failures and timeouts
Windows Event Viewer: Captures service crashes and permission issues
PCS Admin Client: Check DB connections, service status, and license usage

4. Best Practices for PCS Stability

Run PCS as a dedicated Windows service under a user with full file and DB permissions
Use SSL certificates from trusted CAs for external access
Limit number of concurrent Prolaborate dashboards or auto-refresh queries
Monitor CPU/memory usage on PCS host and database server

5. Preparing for Support

If you need to escalate to Sparx support, be sure to collect: Sparx EA best practices

Version numbers of EA, PCS, Prolaborate, and DB
pcs-log.txt for the relevant timeframe
Screenshots of PCS Config and connection settings
Network logs or firewall rules showing traffic flow

The Five Incidents You Will Actually Meet

Generic diagnostics are above; here are the five specific incidents that account for most PCS support traffic in our experience, each with its telltale and its fix, because pattern-matching a known incident beats first-principles debugging at nine in the morning.

Everyone disconnected at once. Telltale: all clients drop within a minute, the PCS service is running, the database is fine. Almost always the firewall or load balancer between clients and PCS has recycled idle connections with an aggressive timeout. Fix the idle timeout at the network layer, not in EA. One user cannot connect, everyone else can. Telltale: works from a colleague's machine with the same account. Local proxy settings or a stale connection string in that client's recent-models list; clear and re-add the connection before touching the server. Slowness that grows through the week. Telltale: fine Monday, treacle Friday, service restart cures it — the classic connection or memory leak profile; schedule a weekly service recycle in the maintenance window while pursuing the underlying version fix, and say so in the change record rather than letting the restart become folklore. Sudden authentication failures after a quiet weekend. Telltale: nothing changed on the PCS box — which is the point; the change was elsewhere. Expired service-account password, rotated database credential, or a certificate that reached its date; check the three expiries before reading a single log. Works internally, fails for remote users. Telltale: VPN population only; the TLS termination or SNI configuration on the edge differs from what the client expects — compare the certificate chain the client actually receives inside and outside before blaming EA.

Monitoring That Prevents the Ticket

Every incident above announces itself before users notice, if anything is listening. PCS deployments rarely get monitoring because they arrive through the architecture budget rather than the operations budget — which is an org-chart accident, not a technical judgement, and it is worth fixing with four probes that take an afternoon to wire into whatever monitoring the organisation already runs.

A synthetic connection check: a scheduled probe that opens a repository connection through PCS and runs one trivial query, alerting on failure or on latency above a threshold — this catches the network-timeout and credential classes while the office is still empty. Certificate expiry watched at thirty and seven days, because certificate incidents are calendar events pretending to be outages. Service memory and connection counts trended, so the Friday-treacle profile is a graph, not a complaint. And the licence-usage curve, because "no floating licences free" presents to users as a connection failure and to the practice as a procurement conversation that should have started a quarter earlier. None of this is sophisticated; it is the difference between the architecture platform being operated and being hoped about, and a regulated deployment review will ask for exactly this list.

Upgrading PCS Without Drama

A disproportionate share of PCS incidents are self-inflicted during upgrades, and the pattern that avoids them is boring and specific. Read the version compatibility matrix first — PCS version, EA client versions, and database schema version move together, and the supported combinations are documented; most upgrade outages are unsupported-combination outages. Upgrade a staging instance against a restored copy of the production repository, and run the real workload against it: the publication pipeline's extraction, the heaviest Prolaborate dashboards, one of every client version the estate actually runs — the ten-minute smoke test that vendors imagine does not represent an estate with three EA versions in the field.

Then sequence production deliberately: database backup verified, PCS upgraded in the maintenance window, clients upgraded in waves afterwards rather than the same morning — because when four hundred users get a new client and a new server simultaneously, every ticket is ambiguous, and ambiguity is what turns an incident into a bad week. Keep the previous PCS installer and the pre-upgrade backup within arm's reach for a fortnight; the rollback you can execute in an hour is the rollback you will never be pressured into botching. Estates that follow this shape describe PCS upgrades the way one wants all infrastructure described: as non-events, noticed only in the release notes.

Reading the Logs Like the Vendor Does

Half of every support exchange is spent establishing facts the logs already held, so it pays to read them the way Sparx's own engineers will. Know the geography first: PCS writes its server logs to its installation's log folder with rotation, the database layer keeps its own slow-query and error logs, and the EA client can be coaxed into connection-level logging when a single workstation misbehaves — three vantage points on every incident, and the diagnosis usually lives in the disagreement between them. A client timeout that appears in the client log but not in the PCS log is a network-path problem; one that appears in both but shows no database entry is PCS-internal; one visible in all three with a long query attached is a repository content or indexing question.

Two habits multiply the logs' value. Turn the verbosity up before reproducing an intermittent issue, and back down after — permanently chatty logs rotate away the evidence precisely when the fortnightly ghost returns. And timestamp-correlate deliberately: note the wall-clock second of a reproduced failure, then read all three logs at that second, because scrolling logs without a timestamp anchor is how afternoons disappear. The five incident patterns described earlier all leave distinct three-log signatures, and a practice that has read its logs during healthy weeks — twenty minutes, once, to learn what normal looks like — diagnoses the unhealthy ones in a fraction of the time, because anomaly detection requires having seen the baseline.

When the issue does go to Sparx support, the same discipline compresses the exchange: the three logs for the incident window, the exact versions of client, PCS and database, the connection path including any TLS termination, and the one-paragraph reproduction. Tickets opened with that package skip the two-round-trip fact-gathering phase that otherwise starts every case — which, given time zones, is routinely a week of calendar time bought with fifteen minutes of preparation.

Conclusion

PCS is a powerful enabler for modern EA collaboration, but like any server platform, it requires careful setup and monitoring. Understanding the most common integration points—and their failure modes—helps architecture teams ensure high availability and seamless stakeholder access across WebEA, Prolaborate, and mobile dashboards.

Enterprise Architect, Pro Cloud Server, PCS Troubleshooting, Sparx EA, EA Integration Server, WebEA, Prolaborate, HTTPS Tunneling, EA API, PCS Configuration, EA Performance, EA Connectivity, PCS Logs, Firewall Settings EA, EA Web Deployment free Sparx EA maturity assessment

If you’d like hands-on training tailored to your team — Sparx Enterprise Architect, BPMN, SysML or the Archi tool — or modelling coaching in ArchiMate and TOGAF-aligned governance, you can reach us via our contact page.

Cloud architecture decisions that matter

Cloud architecture decisions are difficult to reverse once workloads are deployed. Three decisions have outsized impact: multi-cloud vs single-cloud strategy, managed services vs self-managed infrastructure, and network topology (hub-and-spoke, mesh, or transit gateway). Make these decisions explicitly in the architecture review board, document the rationale in Architecture Decision Records, and model the chosen pattern in the ArchiMate Technology Layer before implementation begins. ArchiMate modeling best practices

Model cloud services as Technology Services (not Application Components) because they are infrastructure provided by a vendor, not applications built by the organization. Model the application workloads deployed on cloud services as Application Components with Realization relationships to the underlying Technology Nodes. This separation enables the architecture team to assess cloud dependency: if every application component realizes on a single cloud provider's services, the model reveals the concentration risk visually.

Frequently Asked Questions

How is ArchiMate used in cloud architecture?

ArchiMate models cloud architecture using the Technology layer — cloud platforms appear as Technology Services, virtual machines and containers as Technology Nodes, and networks as Communication Networks. The Application layer shows how workloads depend on cloud infrastructure, enabling migration impact analysis.

What is the difference between hybrid cloud and multi-cloud architecture?

Hybrid cloud combines private on-premises infrastructure with public cloud services, typically connected through dedicated networking. Multi-cloud uses services from multiple public cloud providers (AWS, Azure, GCP) to avoid vendor lock-in and optimise workload placement.

How do you model microservices in enterprise architecture?

Microservices are modeled in ArchiMate as Application Components in the Application layer, each exposing Application Services through interfaces. Dependencies between services are shown as Serving relationships, and deployment to containers or cloud platforms is modeled through Assignment to Technology Nodes.

The One-Page Runbook to Write Today

Everything in this article compresses into a single page that should exist next to every PCS deployment, written on a calm day: the five incident signatures with their first checks, the three log locations with an example healthy line from each, the four expiry dates (service account, database credential, TLS certificate, licence renewal) with their owners, the connection path diagram including every proxy and terminator, and the version triple currently deployed. Add the support package checklist at the bottom and laminate it, literally or culturally.

The page costs an hour and repays it on the first bad morning, when the person on duty is not the person who read this article. PCS itself is dependable infrastructure with a modest operational surface; nearly every "PCS problem" in the field is an environment problem — network, credential, certificate, version skew — wearing PCS's error messages. The runbook is how that insight survives staff turnover, and it is the difference between a platform with an operations story and a platform with a hero. Choose the story; heroes take holidays.

Treat every incident that does occur as a runbook edit waiting to happen — the signature that was missing, the check that would have shortened it — and the page improves at exactly the rate the platform misbehaves, which is the only documentation maintenance schedule that has ever actually been followed.

That closes the loop this article opened with: PCS troubleshooting is nine parts environment knowledge and one part product knowledge, which means the fastest fix was always the one prepared before the failure — the monitoring that saw it coming, the runbook that named it, and the calm upgrade practice that prevented half of it from ever occurring.