Now let's write a test class to verify the chaining of handlers:

fun main(args: Array<String>) {

        val personAuditHandler = PersonAuditHandler()
        val organizationAuditHandler = OrganizationAuditHandler()
        val groupAuditHandler = GroupAuditHandler()
        val deviceAuditHandler = DeviceAuditHandler()

        organizationAuditHandler.addHandler(groupAuditHandler)
        groupAuditHandler.addHandler(deviceAuditHandler)
        deviceAuditHandler.addHandler(personAuditHandler)

        organizationAuditHandler.handleRequest(creaeSamplePersonRequest())
    }

In this class, we created instances of handler implementations and chained them using the addHandler() function. We also created a sample Person identity that we pass to the handleRequest() function.

The function to generate the sample identity of a person is as follows:

fun creaeSamplePersonRequest(): Person{
        val identity = Person()
        identity.id = "person123"
        identity.description = "Person identity"
        identity.identityType = IdentityType.PERSON
        identity.name = "Name"
        identity.organizationId = "orgId123"
        identity.requestMethod = HttpMethod.POST
        return identity
    }

Note that the handlers will be executed in the order that we mention here when chaining them. So, the request is first sent to OrganizationAuditHandler. From there, since the identity type is Person, it goes to the next handler in the chain, which is GroupAuditHandler – this handler is for the Group identity type. It then goes to DeviceAuditHandler, which is not a match either. The request now goes to PersonAuditHandler, which prepares the audit message specific to the  Person identity and will be sent to AuditService. With AuditService, we print the audit message contents.

For the purpose of this demo, we have added println() messages in each handler's handleRequest() function to show the execution order. After that, we print the audit message to the console. Let's run this test class and see the output:

As expected, the control went through the chain of handlers for request processing until it found a handler, processed the request, generated the audit message, and printed it to the console.

There may be a situation in which a request may come with an unknown identity type or a type that is not yet supported in the system. In that case, we need a default handler to handle such requests and we may also choose to audit it. Let's take a look at our test class where we add the default handler to the chain:

organizationAuditHandler.addHandler(groupAuditHandler)
groupAuditHandler.addHandler(deviceAuditHandler)
deviceAuditHandler.addHandler(personAuditHandler)
personAuditHandler.addHandler(defaultAuditHandler)

Now let's invoke the handleRequest() function by changing the IdentityType to TEST. This is shown as follows:

As we can see, since the identity type in unknown, the request has finally reached DefaultAuditHandler and created an audit message with some values that the handler can recognize.

With these patterns, it is easy to add a new Identity to the system, and adding a request handler for the type is also easy. We just have to create a new handler and chain it to the other handlers.