Hi All, If the attached images are not visible use the following links.
1) Notification Sending Architecture IS-5.7 and IS-5.8 -> https://drive.google.com/file/d/1Fmj1CfK4FHSvJWoA4EoaEZdekBnYSJNU/view?usp=sharing 2) The architecture of IS-5.9 when it comes to notification handling. -> <goog_797941172> https://drive.google.com/file/d/13MOL9Kl0XWkbcULTb5a4mKNw9MspHYjy/view?usp=sharing 3) The flow diagram in the tenant loading process. -> https://drive.google.com/file/d/15KrLFvbTAY7dB89dsEm68hLN2Aa-B4Fy/view?usp=sharing 4) The final architecture after this fix -> https://drive.google.com/file/d/1chbTdKlT67lIi01y_0qel82HyJGZrmM3/view?usp=sharing Thanks and Regards *Buddhima Udaranga*|Software Engineer| WSO2 Inc. <http://wso2.com/> (M)+94 714742094 | (E) buddhi...@wso2.com <https://wso2.com/signature> On Tue, Sep 10, 2019 at 9:19 PM Buddhima Udaranga <buddhi...@wso2.com> wrote: > 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) buddhi...@wso2.com > <https://wso2.com/signature> >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
