Honeywell Pro-Watch (HSDK)
Honeywell·AE_HSc_HoneywellProwatchConnectorGuide
Overview
The Honeywell Pro-Watch connector integrates AlertEnterprise Guardian with Honeywell Pro-Watch — Honeywell's enterprise PACS platform, widely deployed in industrial, utility, and federal-adjacent environments. This connector covers the HSDK-based integration path; see honeywell-pro-watch-dtu for the DTU SOAP path and pro-watch-dtu-rest for the modern REST path on Pro-Watch 6.x.
The connector ships as ALNTProWatchConnector-5.0-SNAPSHOT.jar and registers com.alnt.connector.prowatch.provisioning.services.ProWatchConnectorInterface. It uses a hybrid transport architecture: provisioning + command execution flows through the Honeywell HSDK (Honeywell Software Development Kit) hosted on a designated HSDK server, while reconciliation queries pull directly from the Pro-Watch SQL Server database via JNDI-bound JDBC. Pro-Watch's data model exposes badge attributes (BADGE_ALL, BADGE_CARD_ALL, BADGE_CLEARANCE, BADGE_TIME_CLEARANCE, BADGE_TEMPORARY_CLEARANCE) that the connector queries directly.
Notable capabilities vs other PACS: Pro-Watch exposes explicit Lock User Account and Unlock User Account operations as first-class provisioning verbs — most PACS connectors implement equivalent behavior by toggling badge status. The connector exposes these as discrete operations with configurable Lock Action / Unlock Action system parameters mapping to badge status values.
Architecture
Composed from this connector's actors + edges. Trust zones are color-coded; trust crossings render as thicker lines.
Authentication
2 methods supported
Authentication to the Honeywell HSDK server uses a username + password configured as UserId and Password system parameters. The connector also requires the HSDK server Host (IP), Port, and URI (e.g., HSDKPNLApplicationModule).
Reconciliation operations execute SQL queries directly against the Pro-Watch SQL Server backend, accessed through a JNDI-bound DataSource configured in the AE application server. The Jndi Name system parameter identifies the bound DataSource.
Prerequisites
Everything that must be in place for this connector to work, with the owner who's responsible.
HSDK server deployed and reachable
customerA Honeywell HSDK server (the SDK's web service host) must be deployed and reachable from the AE application server. The HSDK application module name (e.g., HSDKPNLApplicationModule) must be known and configured.
Read access to Pro-Watch SQL Server via JNDI DataSource
customerThe AE application server must have a JNDI DataSource bound to the Pro-Watch SQL Server database, with read access to the cardholder, badge, and clearance tables (BADGE_ALL, BADGE_CARD_ALL, BADGE_CLEARANCE, BADGE_TIME_CLEARANCE, BADGE_TEMPORARY_CLEARANCE, CLEAR, BLOBS, BADGE_TYP, BADGE_STATUS, HSDK_CHANGELIST).
HSDK_CHANGELIST table populated for incremental reconciliation
customerIncremental user reconciliation queries HSDK_CHANGELIST filtered by BACNET_TYPE='ACCESSUSER' and LAST_MODIFIED_TIME >= $LAST_RUN_DATE. The Pro-Watch system must be configured to populate this change-log table for incremental sync to work; full reconciliation works without it.
Lock / Unlock action mapping defined
aeOperators must specify Lock Action (e.g., INACTIVE) and Unlock Action (e.g., ACTIVE) system parameters — these define which badge status values the connector sets when locking or unlocking a user.
Known limitations
Documented constraints to set customer expectations before deployment.
Roles assigned at badge level (not user level)
importantUnlike most PACS, Pro-Watch assigns access levels to badges, not to users directly. Multi-badge cardholders may have different role sets per badge. Implementations that assume user-level role assignment must accommodate this — typically by enforcing one-active-badge-per-user or mapping AE-side role grants to the cardholder's "primary" badge.
Data fields
16 fields mapped between AE Guardian and the vendor system.
| AE field | Vendor field | Description | Direction | Required |
|---|---|---|---|---|
| userId | UserId | Hex-encoded Pro-Watch user ID — queries use `(`0x`+CONVERT(varchar(max),A.ID,2))` to expose the GUID-like internal ID as a hex string. | bidirectional | yes |
| firstName | FNAME | — | bidirectional | no |
| lastName | LNAME | — | bidirectional | no |
| middleName | MI | — | bidirectional | no |
| badgeId / cardnumber | CARDNO | Pro-Watch card number. Bound to the `Prowatch BadgeId Attribute Name = cardnumber` system parameter. | bidirectional | yes |
| PIN | PINCODE | — | outbound | no |
| validFrom | ISSUE_DATE / Activation_Time | — | bidirectional | no |
| validTo | EXPIRE_DATE / Expiry_Time | — | bidirectional | no |
| assetStatus | Credential_Status (CARDSTATUS_DESCRP) | — | bidirectional | no |
| BADGE_STATUS | BADGE_STATUS (joined to BADGE_STATUS table for STAT code) | `A` is treated as Active when the column is null. | inbound | no |
| BADGE_TYPE | BADGE_TYPE (joined to BADGE_TYP for DESCRP) | — | inbound | no |
| roleType (Permanent / Timed / Temporary) | ROLE_TYPE | Pro-Watch supports three role validity types — Permanent (no expiry), Timed (range-bound by EXPIRE/TEMPACCESS flags), and Temporary (range-bound by TEMPACCESS_START_TIME / TEMPACCESS_END_TIME). | bidirectional | no |
| text | ROLE_NAME (BADGE_CLEARANCE.DESCRP) | — | bidirectional | no |
| companyname | Company | — | bidirectional | no |
| BADGE_IMAGE | BLOBS.BLOB | Cardholder image stored as SQL BLOB, joined from the BLOBS table on user ID. | inbound | no |
| validity | BADGE_BIRTHDATE / BADGE_EMPLOYER / BADGE_SUPERVISOR / BADGE_HAIRCOLOR / BADGE_EYECOLOR / BADGE_AGE / BADGE_HEIGHT / BADGE_WEIGHT / BADGE_SSN / BADGE_TITLE / BADGE_DEPARTMENT / BADGE_BUILDING / BADGE_FLOOR / BADGE_HOMEPHONE / BADGE_OFFICEPHONE / BADGE_ADDRESS1 / BADGE_ADDRESS2 / BADGE_CITY / BADGE_STATE / BADGE_ZIP / BADGE_COUNTRY | Pro-Watch exposes a wide cardholder-profile column set on `BADGE_ALL`. The connector reads all of these during reconciliation; mapping to AE-side attributes is site-configured. | inbound | no |
PACS specifics
Pro-Watch models a cardholder as a BADGE_ALL row keyed by an internal binary ID (exposed as hex '0x'+CONVERT(varchar(max),A.ID,2)). Each cardholder can have one or more cards in BADGE_CARD_ALL (CARDNO, PINCODE, ISSUE_DATE, EXPIRE_DATE, CARDSTATUS_DESCRP). Photo data is in BLOBS.BLOB. The cardholder profile is unusually rich (employer, supervisor, hair color, eye color, height, weight, SSN, address) — reflecting Pro-Watch's industrial / government-adjacent heritage.
Pro-Watch assigns access at badge level, not user level. Access is granted by inserting rows into BADGE_CLEARANCE (permanent), BADGE_TIME_CLEARANCE (timed), or BADGE_TEMPORARY_CLEARANCE (temporary) — joined on CARDNO. The CLEAR table holds the master clearance definitions. Each clearance has an EXPIRE flag and a TEMPACCESS flag that derive the role-type discriminator.
Single Pro-Watch instance is typically a single tenant. Multi-instance federation requires one connector per Pro-Watch server.
- Topology
- on-prem
- Event model
- polling
- Anti-passback
- unknown
- Holiday schedules
- unknown
- src/connectors/honeywell-prowatch/source.pdf — Full connector guide — 25 pages, updated 2023-04-11
- src/connectors/honeywell-prowatch/source.pdf — p5 — Supported Version
- src/connectors/honeywell-prowatch/source.pdf — p7 — Connector Architecture