UNIFYBroker/Aurion Design Considerations

Connecting to hosted Aurion systems

Provided the same APIs and web services are made available, connectivity with hosted solutions may be achieved in the same way as with an on-premises solution, with some conditions. This includes, but is not limited to:

• Due to the increased overhead in connecting and retrieving data from an outside source, Identity Broker for Aurion should be configured to retrieve data from Aurion less frequently than in-house systems.
• The total elapsed time for each operation will likely be longer due to additional network overheads, and the appropriate timeout limits must be configured accordingly.
• Under some circumstances it is possible for Aurion API operations, particularly the generation of report data, to take longer than the maximum possible operation time out configurable in in the host. Please contact Aurion support for advice if this situation occurs.
• Security is an important consideration, particularly as most information retrieved from Aurion will be private employee data. The use of SSL is strongly recommended, as is risk mitigation and a risk management plan surrounding the credentials.
• As the amount of data exchanged can be quite large, profiling the solution in order to perform proper capacity planning on networks is suggested.

Aurion sources with multiple employee records per person

Should the connected Aurion solution contain multiple employee records per person (i.e. multiple employee IDs per person ID), a number of special considerations will have to be with regards to the overall solution. As most queries are designed by default to include employee and person details, multiple records pertaining to the same person may be retrieved in a single query.

Precise designs to accommodate this problem must be made on a per-site basis, but some possibilities for solutions include:

• Use queries that guarantee only one person will be retrieved per query, regardless of how many employment records they have.
• Use a combination of Identity Broker transformations and/or solution logic to filter out certain records so that only one identity per person is retrieved.

Writing person details back to Aurion

Due to the designs of the Aurion EMP_UPDATE_PERS, SEC_USER_ADD and SEC_USER_UPDATE API functions, an employee number must always be supplied when writing these details back to Aurion. As such, the solution must ensure that a total of one valid employee ID is always supplied when performing exports to a person or Security User record.