Information Technology Reference
In-Depth Information
In rare cases, a user event may require a response. An example is when a
new user is to be provisioned on a mainframe, but (1) IAM cannot
authoritatively generate the user ID on the mainframe, and (2) the
mainframe cannot store a reference to the User UUID locally. The
mainframe has to generate an appropriate user ID, then notify IAM of this
user ID so that IAM can update its “User-Associated System” table. In such
cases,
the
downstream
system's
event
listener
must
place
an
acknowledgement message on the bus, which IAM subscribes to.
This model is illustrated below:
Fig 50: User event bus
Tip 5
: Separate error-handling out into a different mechanism and don't
overload the User Event Bus with error messages
We have noticed that in most cases, errors in processing user events are
because of (transient) problems in the local system and not because of
errors in the actual message. In rare cases, they may be because of errors in
systems upstream of IAM, such as the HR system. It is simplest for such
processing errors to be recorded and reported on locally. The administrators
of downstream systems are usually best placed to understand why
processing failed and to fix it.
Handle these errors using a separate mechanism altogether rather than
clutter the User Event Bus with error messages. Define a suitable error
message format (Error UUID, User Event UUID, Status Code, Description,
Timestamp, Original Message, etc.)
All listeners should log errors to a separate error queue. An administration
interface to this queue should be able to provide alerts and reports as well
as a query view into the contents of the queue. Sending such error messages
back to IAM is usually not of much use, although in practice, the same users
who administer the IAM module may also monitor the error queue. In any
case, it's not a good idea to tightly couple these two roles through the
