AMAG Symmetry SMS
AMAG Technology·AE_HSc_AMAGConnectorGuide
Overview
The AMAG connector integrates AlertEnterprise Guardian with AMAG Symmetry Security Management System (SMS) — AMAG Technology's on-prem enterprise PACS suite. AMAG Symmetry is one of the most widely deployed enterprise PACS in financial services, federal, and critical infrastructure verticals.
This connector uses a hybrid transport architecture. Provisioning and most reconciliation operations go through the AMAG SMS XML API — a SOAP/ASMX web service typically reachable at http://<sms-host>/smsXMLWebService/smsXMLWebService.asmx. For cardholder reconciliation (which the SMS XML API does not support) the connector falls back to read-only JDBC directly against the AMAG SQL Server database, querying the multiMAX and multiMaxExport schemas. Initial cutover / bulk sync also flows over the JDBC path.
The connector ships as ALNTAMAGConnector-5.0-SNAPSHOT.jar and registers the com.alnt.amag.provisioning.services.AmagConnectionInterface extractor class. This is the current AMAG connector (direct-SOAP, no .NET intermediary) — for the older architecture that routed SOAP through an Alert SMS Web Service Client on IIS, see amag-legacy. For Symmetry Mobile credentials (a separate AMAG product), see amag-symmetry-mobile.
Architecture
Composed from this connector's actors + edges. Trust zones are color-coded; trust crossings render as thicker lines.
Authentication
2 methods supported
The AMAG SMS XML API authenticates callers via WSSE/basic auth — a username + password configured in the AE connector. Incorrect credentials produce org.apache.cxf.binding.soap.SoapFault: Unknown Username or Incorrect Password.
For cardholder reconciliation, the connector requires a separate database user with read access to the multiMAX and multiMaxExport schemas on AMAG's SQL Server backend. Driver Name + Database URL + Database User Name + Database Password are configured as System Parameters. See Chapter 6 of the connector guide for the minimum-privilege grant set.
Endpoints
1 endpoint exercised by the connector
| Method | Path | Description | Category |
|---|---|---|---|
| POST | /smsXMLWebService/smsXMLWebService.asmx | AMAG SMS XML API endpoint (SOAP). All provisioning + most reconciliation operations target this single ASMX endpoint with SOAP envelope payloads. | provisioning |
Prerequisites
Everything that must be in place for this connector to work, with the owner who's responsible.
AMAG SMS deployed and reachable
customerAn AMAG Symmetry SMS deployment (version 8.0-9.6) with the XML Open Integration Module installed and configured. The SMS XML API must be reachable from the AE application server.
Data Connector Module license on AMAG
customerThe AMAG system must have a Data Connector Module license for the SMS application to write changes into the export database (multiMaxExport). Without this license, cardholder reconciliation (the JDBC path) will not see changes.
Read-only JDBC user on AMAG SQL Server
customerA dedicated read-only database user with SELECT privileges on the multiMAX.dbo and multiMaxExport.dbo schemas — specifically tables CardHolderTable, CardInfoTable, CardHolderFaceTable, AccessGroupTable, CardHolderAccessGroupXrTable, CardHolderAccessXrTable, ReaderTable, IntrusionZoneTable, AccessGroupReaderXrTable, AccessGroupReaderGroupXrTable, ReaderGroupXrTable, FloorGroupTable, AccessGroupFloorGroupXrTable, IntrusionAreaZoneXrTable, AccessGroupAreaXrTable, and DataExportTable.
SSL certificate trust (if HTTPS)
aeWhen the SMS XML API is served over HTTPS, the AMAG SMS server's certificate must be imported into the AE host's JVM cacerts keystore. The connector raises javax.net.ssl.SSLHandshakeException / "Unable to find valid certification path to requested target" when the cert isn't trusted.
Known limitations
Documented constraints to set customer expectations before deployment.
Cardholder reconciliation requires direct DB access
importantThe AMAG SMS XML API does not expose cardholder reconciliation operations. AE works around this by issuing read-only JDBC queries directly against the AMAG SQL Server backend. Customers with strict policies against third-party direct-DB access must understand this is a hard architectural requirement, not a configurable behavior — Symmetry simply does not provide an API alternative for this operation.
CardFormat is mandatory for every provisioning operation
importantEvery user and badge provisioning operation must include a CardFormat value from the closed set (SeiwgV1, SeiwgGSC2_1, SRSeries_10And12Digit, SRSeries_15Digit, Standard). Provisioning without CardFormat will fail at AMAG-side validation.
Provisioning error codes returned via DB table, not API
informationalProvisioning errors from AMAG are surfaced via the multimaximport.dbo.messagetable table — not in the SOAP response. Codes include 2 (mandatory fields not specified), 4 (record not found), 8 (card already exists), 9 (issue level out of range), 10 (PIN out of range), 14 (expiry before active), 16/17 (face/signature image not found). Operators must monitor this table separately to surface async errors.
Data fields
23 fields mapped between AE Guardian and the vendor system.
| AE field | Vendor field | Description | Direction | Required |
|---|---|---|---|---|
| UserId | EmpReference | Maps to `CardHolderTable.EmployeeNumber` (alias EmpReference in queries). | bidirectional | yes |
| FirstName | FirstName | — | bidirectional | yes |
| LastName | LastName | — | bidirectional | yes |
| Midname | MiddleName | — | bidirectional | no |
| CompanyID | CompanyID | — | bidirectional | yes |
| BadgeId | CardNumber | Maps to `CardInfoTable.CardNumberDisplay`. | bidirectional | yes |
| BadgeValidFrom | ActiveDate | ISO datetime → AMAG `ActiveDateTime`. | bidirectional | yes |
| BadgeValidTo | ExpiryDate | ISO datetime → AMAG `InactiveDateTime`. | bidirectional | yes |
| BadgeStatus | CardStatus | "Yes" = active card, "No" = inactive (sourced from `CardInfoTable.Inactive`). | bidirectional | yes |
| UserStatus | CardHolderStatus | "Yes" = active user, "No" = inactive (sourced from `CardInfoTable.ForcedInactive`). | bidirectional | yes |
| CardFormat | CardFormat | AMAG card-format identifier. Possible values: `SeiwgV1`, `SeiwgGSC2_1`, `SRSeries_10And12Digit`, `SRSeries_15Digit`, `Standard`. Mandatory for all user and badge provisioning operations. | bidirectional | yes |
| CustomerCode | CustomerCode | Maps to `CustomerCodeNumber` in AMAG. | bidirectional | yes |
| PIN | PIN | — | outbound | no |
| AgencyCode | AgencyCode | — | bidirectional | no |
| CardIssueLevel | CardIssueLevel | — | bidirectional | no |
| IDSCode | IDSCode | — | bidirectional | no |
| ImageUpload | FaceImage | Cardholder face image — maps to `CardHolderFaceTable.Face`. | outbound | no |
| SignatureUpload | SignatureImage | — | outbound | no |
| PersonalData1 | PersonalData1 | AMAG supports PersonalData1 through PersonalData50 — site-defined custom attributes. Each maps directly with the same name. | bidirectional | no |
| RoleName | AccessGroupName | Maps to `AccessGroupTable.AccessGroupName`. AMAG calls access levels "Access Groups." | bidirectional | yes |
| RoleType | RoleType | — | bidirectional | yes |
| Timecode | TimeCode | Schedule constraint that gates an access group. | bidirectional | no |
| BadgeDesign | BadgeDesign | — | outbound | no |
PACS specifics
AMAG models cardholders in multiMAX.dbo.CardHolderTable (CardID, EmployeeNumber, FirstName, LastName, MiddleName, ForcedInactive status). Cards live in CardInfoTable (CardNumberDisplay, Inactive, Lost, ActiveDateTime, InactiveDateTime, CustomerCodeNumber). Each cardholder may have one or more cards. Photos in CardHolderFaceTable. PersonalData1-50 are site-defined custom attributes.
Access is granted by assigning a cardholder to one or more Access Groups (AMAG's term for access levels). Access Groups are composed of Readers (AccessGroupReaderXrTable), Reader Groups (AccessGroupReaderGroupXrTable), Floor Groups for elevator readers (AccessGroupFloorGroupXrTable), and Intrusion Areas (AccessGroupAreaXrTable → IntrusionAreaZoneXrTable → IntrusionZoneTable). Each access group can be gated by a TimeCode (schedule).
A single AMAG SMS instance is typically a single tenant. Multi-site customers running federated SMS instances require one AE→AMAG connector per SMS instance.
- Topology
- on-prem
- Event model
- polling
- Anti-passback
- unknown
- Holiday schedules
- unknown
- src/connectors/amag/source.pdf — Full connector guide — 28 pages, revision 3.0 dated 2025-12-24
- src/connectors/amag/source.pdf — p6 — Supported Version
- src/connectors/amag/source.pdf — p8 — Connector Architecture