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

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, ArchiMate, TOGAF, BPMN, SysML, or the Archi tool), 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.