- UNIFYBroker Forum
- UNIFYBroker/Plus
-
Questions
Configuration guidance required
In a UNIFYConnect ABAC solution we use appointment information (i.e. a user's Employee ID, Position, Department, Team, Location and Start Date) along with customer-managed rules in order to determine which access packages the user should be automatically assign to.
My customer has two sources of appointment information: one is directly on the employee, and the other is via a separate feed of secondary appointments. Each employee has one primary appointment and zero or more secondary appointments.
In order to combine the appointments into one data source, I use the following paths into the Appointment locker:
Employee connector/adapter -> link -> Appointment locker
Secondary appointment connector/adapter -> link -> Appointment locker
The employee connector is keyed solely on Employee ID, but the Secondary appointment connector is keyed on Employee ID, Position, Department, Team, Location and Start Date, to guarantee uniqueness.
On the outgoing side the following path writes the combined Appointments to a CSV file for processing outside of UNIFYBroker:
Appointment locker -> link -> Appointments CSV connector/adapter
The Appointments CSV connector is keyed on Employee ID, Position, Department, Team, Location and Start Date, to guarantee uniqueness.
All links use connection-oriented join resolution.
When an existing Employee connector entity changes Department, Team (etc) the existing Appointment locker record is updated with new values for those fields. For the export to the Appointments CSV connector, this causes a problem because that update is processed as an anchor modification, which is not supported for CSV connector types.
This problem doesn't occur on the Secondary appointments connector, because the multi-part key ensures that changes to any key field results in a delete/add operation instead of an update.
How can I configure UNIFYBroker to make this scenario work correctly?
Answer
Hi Adrian
Creating a derived key generated from adapter transformations might help.
For the secondary appointment entities, use a PowerShell transformation to generate a unique value based on the Position, Department, Team, Location and Start Date fields that persists their uniqueness quality, but reduces them to a single field. A hash of some kind of their combined values should be sufficient. I'd also add a static prefix for a further uniqueness guarantee. The resulting value may look something like like sec_c9uQNFGLgC.
On the primary adapter, use a constant value transformation to add a derived key field to differentiate primary appointments from secondary ones. The value set can by anything, but shouldn't be anything that could be generated by the transformation on the secondary appointment adapter, ie: primary_appointment.
Use the derived key in conjunction with the EmployeeId field for link joins and as key fields on the Appointments CSV connector. This should provide a stable, two-field anchor based on the immutable secondary appointment properties, but not the mutable properties of the primary appointment.
Thanks Beau, I tried a simplified version of what you suggested and it has worked great.
On each adapter I generate a single 'AppointmentID' for each entity, based solely on the Employee ID for the primary appointment but on all attributes on the secondary ones.
Thank you very much! This is awesome.
Customer support service by UserEcho
Hi Adrian
Creating a derived key generated from adapter transformations might help.
For the secondary appointment entities, use a PowerShell transformation to generate a unique value based on the Position, Department, Team, Location and Start Date fields that persists their uniqueness quality, but reduces them to a single field. A hash of some kind of their combined values should be sufficient. I'd also add a static prefix for a further uniqueness guarantee. The resulting value may look something like like
sec_c9uQNFGLgC.On the primary adapter, use a constant value transformation to add a derived key field to differentiate primary appointments from secondary ones. The value set can by anything, but shouldn't be anything that could be generated by the transformation on the secondary appointment adapter, ie:
primary_appointment.Use the derived key in conjunction with the EmployeeId field for link joins and as key fields on the Appointments CSV connector. This should provide a stable, two-field anchor based on the immutable secondary appointment properties, but not the mutable properties of the primary appointment.