C·CURE 9000 (via Victor Web Service)
Software House (Johnson Controls)·AE_HSc_CCURE9000VictorConnectorGuide
Overview
The C·CURE 9000 connector integrates AlertEnterprise Guardian with Software House C·CURE 9000 — Johnson Controls' flagship enterprise PACS, deeply entrenched in financial services, federal, and Fortune 500 corporate environments. C·CURE 9000 is one of the two PACS (the other being lenel OnGuard) that virtually every large enterprise RFP for PACS-adjacent technology expects to see supported.
Integration is via the Victor Web Service — Software House's REST API surface for C·CURE. The connector ships as ALNTCCure9000VictorConnector-5.0-SNAPSHOT.jar and registers com.alnt.connector.ccure9000.provisioning.services.CCure9000ConnectionInterface as the extractor class. Both PIAM (Cardholder, Cardholder Badge, Cardholder Access) and VIM (Visitor, Visitor Badge, Visitor Access) PACS object families are supported — a meaningful differentiator from connectors that handle PIAM only.
This connector is explicitly designed for AE's SaaS Guardian topology: the cloud-hosted Guardian application communicates over outbound HTTPS to an Alert Enterprise Agent running on-prem in the customer environment; the Agent hosts the C·CURE 9000 Connector and translates Guardian requests into Victor Web Service REST calls without exposing the C·CURE server to the cloud. For HA/DR, Software House recommends pointing the connector at a stable DNS hostname or VIP fronting a load-balanced C·CURE Victor pool.
A hard prerequisite frequently missed in project planning: the customer must obtain an updated CCURE license with the Alert Enterprise integration option (CC9000-ALERTENT) before the connector can function. License procurement involves the CCURE licensing team and has lead time.
Architecture
Composed from this connector's actors + edges. Trust zones are color-coded; trust crossings render as thicker lines.
Authentication
2 methods supported
The Victor Web Service uses OAuth 2.0 as the primary authentication mechanism. The Alert C·CURE Connector posts a CCURE operator username + password (configured as userId and password system parameters) to the Victor authentication endpoint and receives a scoped, time-bound bearer token. Subsequent API calls include Authorization: Bearer <token>. The connector caches the token, reuses it until expiry, and refreshes on expiration. If the CCURE operator's authentication type is Windows, the userId must be in <DomainName>\<UserName> format. All traffic, including the token exchange, is encrypted over TLS 1.2 or later.
Role reconciliation (Clearances → AE Roles) and access-activity reconciliation (cardholder events: CardAdmitted, CardRejected, ObjectChangedState, JournalStateChange) use direct read-only JDBC against the C·CURE 9000 SQL Server backend (ACVSCore database — Access schema tables: Clearance, ClearanceItem, Door, Reader, Personnel, doorudf; plus the ACVSUJournal* event log databases). Driver Name, JDBC URL, database username, and password are configured as system parameters.
Endpoints
1 endpoint exercised by the connector
| Method | Path | Description | Category |
|---|---|---|---|
| POST | https://<ccureserver>/CCUREWebService/victor/auth/token | Victor OAuth 2.0 token endpoint. Exchanges CCURE operator credentials for a bearer token. | auth |
Prerequisites
Everything that must be in place for this connector to work, with the owner who's responsible.
Updated CCURE License with AlertEnterprise integration option
customerThe customer must work with the CCURE licensing team to obtain an updated license including the CC9000-ALERTENT option. The license must then be applied to the CCURE Victor server using the InsertLicenseOption tool with the AlertEnterprise vendor GUID a43a3d60-da8d-4ad6-8cdb-4ca792d865df. This is a hard prerequisite — without it, the Victor Web Service rejects the AE integration's API calls. Plan license procurement well in advance.
Alert Enterprise Agent deployed on-prem
aeFor SaaS Guardian deployments, the Alert Enterprise Agent must be deployed in the customer environment with network reachability to the CCURE Victor server. The Agent hosts the C·CURE 9000 Connector and provides the cloud-to-on-prem bridge — CCURE is never exposed to the cloud.
CCURE operator account for API access
customerA dedicated CCURE operator account with sufficient privileges for the AE integration operations (create/update users, manage badges, modify clearances). Windows-auth operators require <DomainName>\<UserName> formatting in the AE config.
Read-only JDBC user for role + activity reconciliation
customerA SQL Server user with SELECT privileges on the ACVSCore database (Access schema: Clearance, ClearanceItem, Door, Reader, Personnel, doorudf) and on the per-day ACVSUJournal* event log databases. JDBC driver name + URL + credentials configured as system parameters.
TLS 1.2 or later end-to-end
customerAll traffic to the Victor Web Service must use TLS 1.2 or later. Customers running CCURE servers on older OS / framework versions must update before integration.
Stable CCURE endpoint (DNS/VIP) for HA/DR
customerSoftware House recommends a customer-managed DNS hostname or virtual IP fronting CCURE Victor servers behind a load balancer or traffic manager. The AE connector talks to a single endpoint and the customer's load-balancer fabric handles failover without integration changes.
Known limitations
Documented constraints to set customer expectations before deployment.
Card number ceiling at 4,294,967,295
importantThe CCURE 9000 Victor API rejects card numbers ≥ 4294967295 (32-bit unsigned int ceiling). Customers using larger card numbers (e.g., FASC-N derivative encodings, full 128-bit CHUIDs as integers) must use the CHUID + FacilityCode credential-unique fields path instead.
Multi-image cardholders — only primary image reconciled
informationalDuring user reconciliation, only the primary image is supported. Cardholders with multiple stored images (e.g., a secondary visa or contractor photo) lose the non-primary images during reconciliation back into AE.
License procurement is the long-pole prerequisite
importantThe CC9000-ALERTENT license must be obtained from Software House / Johnson Controls' licensing team — not via AE. Lead time of 2-6 weeks is typical. AE Sales / SE should surface this very early in the deal cycle to avoid project-start surprises.
PIN field is double-named (`PIN` vs `DecodePIN`)
informationalBoth Pin → PIN and pin → DecodePIN mappings appear in the field mapping table. DecodePIN is the post-decryption value used for badge provisioning; PIN is the cardholder-facing PIN field for keypad readers. Confusion between the two is a common implementation pitfall — verify with the project's CCURE administrator which slot the site uses.
Data fields
22 fields mapped between AE Guardian and the vendor system.
| AE field | Vendor field | Description | Direction | Required |
|---|---|---|---|---|
| userId | ObjectID | CCURE Personnel object identifier (GUID). | bidirectional | yes |
| firstName | FirstName | — | bidirectional | no |
| lastName | LastName | — | bidirectional | no |
| middleName | MiddleName | — | bidirectional | no |
| status | Active | CCURE Personnel `Active` boolean. | bidirectional | no |
| type | PersonnelTypeID | Personnel type discriminator. AE maps via formula: '1' → Employee, '2' → Contractor, '3' → Visitor, otherwise 'Permanent'. | bidirectional | no |
| employmentStatus | Text5 | CCURE generic-text slot 5 — site-defined for employment status. | bidirectional | no |
| Text1 | CCURE generic-text slot 1 — site-defined for email. | bidirectional | no | |
| photo | Image / PrimaryPortrait | Cardholder photo. From 2.6+ image provisioning uses APIs (not Data Import jobs). Only the primary image is supported during reconciliation. | outbound | no |
| pin | DecodePIN / PIN | — | outbound | no |
| badgeId | Badge.CardNumber | Card number must be less than 4294967295 (32-bit unsigned int ceiling). Values ≥ 4294967295 cause provisioning failure. | bidirectional | yes |
| CHUID | Badge.CHUID | Cardholder Unique Identifier — typically formatted as '000000$BadgeId' via formula. | bidirectional | no |
| BadgeFormatID | Badge.CHUIDFormatID | CCURE card format identifier — must align with the credential format provisioned at the reader. | bidirectional | no |
| validFrom | Badge.ActivationDateTime | — | outbound | no |
| validTo | Badge.ExpirationDateTime | — | outbound | no |
| badgedisabled | Badge.Disabled | — | bidirectional | no |
| assetStatus | status | Badge status mapping via formula: badgestolen=true → 'STOLEN'; badgedisabled=true → 'DISABLED'; badgelost=true → 'LOST'; else 'OPEN'. | bidirectional | no |
| Location_id | Badge.FacilityCode | Facility code on the badge — part of the (CardNumber, FacilityCode) credential-uniqueness key when configured. | bidirectional | no |
| sourceId | TechnicalRoleName | Clearance ObjectID — links UserRoleData entries to CCURE Clearances. | bidirectional | yes |
| text | ROLE_NAME | Clearance display name. | bidirectional | no |
| Description | ROLE_DESCRIPTION | — | bidirectional | no |
| PartitionID | PartitionID | CCURE 9000 partition — supports multi-tenant deployments where partitions isolate cardholder pools. | bidirectional | no |
PACS specifics
CCURE 9000 models a cardholder as a Personnel object in the ACVSCore.Access.Personnel table — keyed by ObjectID (GUID). Personnel objects carry FirstName, LastName, MiddleName, Active flag, PersonnelTypeID (Employee/Contractor/Visitor/Permanent), and 25+ generic-text slots (Text1-Text25) plus 7+ generic-int slots (Int6, Int7, ...) used for site-defined custom attributes. Each Personnel can have one or more Badges, identified by CardNumber, FacilityCode, CHUID, CHUIDFormatID, ActivationDateTime, ExpirationDateTime, and status flags (Disabled, Stolen, Lost). PrimaryPortrait holds the canonical photo; secondary images are not roundtripped. Visitors are a parallel object family used by VIM (Visitor Identity Management).
Access is granted by assigning a Personnel/Badge to one or more Clearances (Software House's term for an access level), modeled in ACVSCore.Access.Clearance and linked to Doors via ClearanceItem join records. Each Clearance is composed of a set of (Door, Reader) pairs — doors have an InReaderID and OutReaderID distinguishing entry vs exit readers. Group memberships via GroupMember and door groups extend clearance scope.
C·CURE 9000 supports Partitions — first-class cardholder/clearance scoping units that isolate access pools within a single C·CURE deployment. Each Personnel and Clearance carries a PartitionID. Multi-business-unit customers running a shared C·CURE deployment can isolate by partition without multiple connector instances.
- Topology
- on-prem
- Event model
- both
- Anti-passback
- unknown
- Holiday schedules
- unknown
- src/connectors/ccure9000-victor/source.pdf — Full connector guide — 38 pages, revision 4.0 dated 2026-04-29
- src/connectors/ccure9000-victor/source.pdf — p7 — Supported Versions & Features
- src/connectors/ccure9000-victor/source.pdf — p10 — Guardian (SaaS) Architecture
- src/connectors/ccure9000-victor/source.pdf — p7 — Supported PACS Objects