Hi All, I have been working on a feature that can provide tenant wise email configurations. In IS-5.7 and 5.8, The notification sending architecture is as follows.
There will be tenant wise adapters and publishers. When IS notification handler wants to publish it will publish to a stream in the tenant flow. This stream is bind with the publisher. Analytics-common will find the relevant publisher for the stream in the tenant and then it will publish the notification. In this process, we have identified four main components. *1)Streams - Streams are what IS is publishing. They receive events. * *2)Adapters - They handle the connections. They decide where to connect.* *3) Output Mappers - They handle content that should include in the output message. They are defined for different types that support. * *4)Publishers - Publishers are bind with the streams they publish by using the connection provided by the adapter and the content provided by output mapper* But in IS-5.9 due to deprecating file-based artifacts this mechanism is changed as follows. There will be no tenant wise publishers or adapters. The only super tenant will have publishers and adapters. When notification handler publishes it will publish using a super tenant flow. Hence it will use the publisher and adapter of the super tenant. Therefore, in IS 5.9.0 we won’t be able to let configuring adapter configurations tenant wise, with the way analytics common is designed right now. The following depicts the architecture of IS-5.9 when it comes to notification handling. In order to solve this, we looked at two approaches. When we consider an ideal situation IS is not receiving any events. It publishes the events to streams. Hence streams are server defined not tenant defined. What should be tenant defined is the content and the where to connect. These two are handled in the Output Mapper and the Adapter. Using that concept we have considered Approach 1 as our first solution Approach 1 - TextOutputMapper will be extended - It will use the output mapping in the tenant wise resource configuration. - If it is not there it will use the super tenant configurations. - EmailEventAdapter also will be extended and its connect method will be overridden. - It will use the tenant wise configuration for connections if it is not there it will use the global configuration. PR for the POC can be found in [1]. We have identified the following limitations when considering the first approach. 1) In the current implementation of analytics-common streams are bind with tenants. Tenant specific streams get populated when the server starts when e. As in the IS-5.9, there are no EmailPublishers getting deployed per tenant there will be no tenant-specific streams populated per tenant.[2] As we are starting a tenant flow at the notification handler this will create issues. 2) Event adapter map also created per tenant. [3] 3) The adapter should be responsible for handling the connections. But in 5.9 there is only one adapter and OutputAdapterRuntime. This adapter is specified to different notification sending mechanisms but OutputAdapterRuntime is common to all of them. In the current implementation, OutputAdapterRuntime is handling the connection and if the connection fails it handles the reconnection[4]. In the adapter, it manages a session with the specific notification mechanism ex: email.[5] For this fix to work we need to handle tenant wise connections and sessions centrally using a session and connection manager. Addressing the challenge 3 will be complex. And it will involve lots of changes in analytics. Hence we have decided to use virtual Publisher Configuration per tenant. Which is the approach 2. Due to this new process will be added to the tenant loading. Approach 2 - Using virtual Publisher Configuration per tenant. This will be loaded and unloaded when tenant loading and unloading. - Also, tenant wise event adapters will be created in the tenant loading process. - Hence when the notification is getting published it will use the event adapters that are dedicated per tenant. - These adapters will handle the connections. - When creating the connections it will consider the tenant wise configurations stored in the configuration store. - If they exist, the global configuration will be overridden by them. - These connections will be automatically dropped after a certain period of time hence if there is an update in the configuration they will be reflected from the adapter after that time period. Following is the flow diagram in the tenant loading process. After the fix, the final architecture will be as follows. Although currently, we are proceeding with this fix if we removed the Axis2 deployer in the future we can consider Approach 1 with proper centralized connection handling. Please let us know your thoughts on this. [1]. https://github.com/wso2/carbon-analytics-common/pull/706/files [2]. https://github.com/wso2/carbon-analytics-common/blob/1af0b97507f156ceaf173b421bad4001bee8e486/components/event-stream/org.wso2.carbon.event.stream.core/src/main/java/org/wso2/carbon/event/stream/core/internal/EventStreamRuntime.java#L89 [3]. https://github.com/wso2/carbon-analytics-common/blob/1af0b97507f156ceaf173b421bad4001bee8e486/components/event-publisher/org.wso2.carbon.event.output.adapter.core/src/main/java/org/wso2/carbon/event/output/adapter/core/internal/CarbonOutputEventAdapterService.java#L83 [4]. https://github.com/wso2/carbon-analytics-common/blob/1af0b97507f156ceaf173b421bad4001bee8e486/components/event-publisher/org.wso2.carbon.event.output.adapter.core/src/main/java/org/wso2/carbon/event/output/adapter/core/internal/OutputAdapterRuntime.java#L61 [5]. https://github.com/wso2/carbon-analytics-common/blob/1af0b97507f156ceaf173b421bad4001bee8e486/components/event-publisher/event-output-adapters/org.wso2.carbon.event.output.adapter.email/src/main/java/org/wso2/carbon/event/output/adapter/email/EmailEventAdapter.java#L145 [6]. https://github.com/wso2-extensions/identity-event-handler-notification/pull/94/files Thanks and Regards *Buddhima Udaranga*|Software Engineer| WSO2 Inc. <http://wso2.com/> (M)+94 714742094 | (E) [email protected] <https://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
