Hi Suhothayan, You can refer [1] for the current approach we have taken in IS side when improving notification sending with siddhi streams. As per the discussion we had previously, this approach has been taken in order to avoid the performance degradation due to the redundant loading of email template in IS and analytics. The main reason for the redundant loading is that only in IS side, the user claims can be loaded which needs for filling out the placeholders in email template.
As per the current implementation you are having, we can provide the registry path and let the email template get loaded in analytics side. For that there has to be some improvement in analytics side to get the user claims from user store and filling out the template with those claim values. So that without loading the email template from IS side, we can do it in analytics side. So the suggested improvements as follows. *IS side:* *1) Modified the publisher definition to include registry path of the email template, specifying the notification type and locale as placeholders2) When an email notification need to be send, an arbitrary map (including the data needs to load the email template from registry) will be published to the streamAnalytics side:1) Load the email template from the registry (use the arbitrary data values we have provided)2) Extract the placeholders in email template3) Get the user claims from user store and fill out the placeholders in the template with the necessary claim values* We have used two prefixes in placeholders of email templates as "user.claim.identity" and "user.claim", in order to specify that the placeholders has to be filled with an identity claim and other wso2 claim respectively. The claim URIs which we are using when retrieving necessary user claims for the email templates, will be generated appending necessary prefix to the "http://wso2.org/claims/";. As an example if the placeholder is "user.claim.givenname", the claim URI should be "http://wso2.org/claims/ givenname". So that placeholder has to be filled with the user claim value corresponding to the above mentioned claim URI. You can refer [2] for the implementation done in IS side, we can move that logic to analytics side. [1] https://github.com/wso2-extensions/identity-event-handler-notification/pull/26/files [2] https://github.com/wso2-extensions/identity-event-handler-notification/pull/26/files#diff-2200b351eeef81ebbb5ea7f0d1f1ecb7R119 Thanks and Regards On Tue, Aug 9, 2016 at 9:50 PM, Sriskandarajah Suhothayan <s...@wso2.com> wrote: > Based on the chat with Johann he suggested to support claims at event > publisher. > @Indunil, can you get the full requirements and update the thread. > > Regards > Suho > > On Mon, Aug 1, 2016 at 11:24 PM, Mohanadarshan Vivekanandalingam < > mo...@wso2.com> wrote: > >> >> >> On Mon, Aug 1, 2016 at 8:38 PM, Indunil Upeksha Rathnayake < >> indu...@wso2.com> wrote: >> >>> Hi Suhothayan, >>> >>> Hi Indunil, >> >> I like to add some comments on this.. Please find them below.. >> >> >>> There was an issue in EventPublisherServiceDS where >>> setConfigurationContextService() method get invoked after the bundle >>> get activated. Due to that, when we are trying to invoke >>> deployEventPublisherConfiguration() of EventPublisherService from the >>> activate method of an osgi bundle in IS side, it's receiving a null >>> pointer(Since it refers the ConfigurationContextService object in >>> EventPublisherServiceValueHolder). I think you can resolve it by >>> changing the osgi reference cardinality in [1] as "1..1"(Mandatory), if >>> there is no specific reason for making it optional. >>> >> >> There is a valid reason for this.. >> I believe, as you know we cannot guarantee about OSGI bundle loading in >> carbon environment.. In this case, there is a possibility where axis2 >> deployment can start before bundle activation of a OSGI component. To avoid >> this we'll follow a similar approach like below, >> >> <Axis2RequiredServices> >> >> org.wso2.carbon.event.publisher.core.EventPublisherService >> >> </Axis2RequiredServices> >> >> Here, we are adding the reference of the corresponding OSGI service which >> is exposed by relevant OSGI module.. If you want to use above approach >> (Axis2RequiredServices), we cannot have 1..1 mapping for >> ConfigurationContextService since it causes cyclic dependency and affects >> bundle loading.. >> >> In IS side we were able to get rid of the null pointer by adding an osgi >>> reference for ConfigurationContextService in the service component and >>> invoked the deployEventPublisherConfiguration() in activate() method. >>> >> >> No, above solution is not correct and will not work all the time.. There >> is a possibility where you'll encounter same issue when >> ConfigurationContextService is bind to you component first and takes >> sometime to resolve for Event Publisher.. >> >> What is the usecase for creating an Event Publisher in server restart ? >> Can you ship the pack with an Event Publisher or deploy an event publisher >> for first event if it is not there.. >> >> >>> And also there was an issue in filling out dynamic properties of an >>> output adapter from the arbitrary data values, and sent a PR for that. >>> Please review and merge the PR in [2]. >>> >> >> Thanks, Merged it.. >> >> Regards, >> Mohan >> >> >>> >>> [1] https://github.com/wso2/carbon-analytics-common/blob/master/ >>> components/event-publisher/org.wso2.carbon.event. >>> publisher.core/src/main/java/org/wso2/carbon/event/publishe >>> r/core/internal/ds/EventPublisherServiceDS.java#L56 >>> [2] https://github.com/wso2/carbon-analytics-common/pull/306/files >>> >>> Thanks and Regards >>> >>> On Mon, Aug 1, 2016 at 3:06 PM, Sriskandarajah Suhothayan <s...@wso2.com >>> > wrote: >>> >>>> HI Indunil >>>> >>>> Any update on this? Was the provided solution working? >>>> >>>> We released CEP 4.2-RC1. If we need new features/improvements for this >>>> effort, we can incorporate them in the next component release. >>>> >>>> Regards >>>> Suho >>>> >>>> On Fri, Jul 22, 2016 at 3:10 PM, Sriskandarajah Suhothayan < >>>> s...@wso2.com> wrote: >>>> >>>>> >>>>> >>>>> On Fri, Jul 22, 2016 at 3:00 PM, Johann Nallathamby <joh...@wso2.com> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Jul 22, 2016 at 8:33 AM, Indunil Upeksha Rathnayake < >>>>>> indu...@wso2.com> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On Fri, Jul 22, 2016 at 12:28 PM, Sriskandarajah Suhothayan < >>>>>>> s...@wso2.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jul 22, 2016 at 12:00 PM, Indunil Upeksha Rathnayake < >>>>>>>> indu...@wso2.com> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please find the meeting notes in [1]. I have following >>>>>>>>> considerations regarding the improvements we have discussed. >>>>>>>>> >>>>>>>>> (1) Even though we have configured to load the email template from >>>>>>>>> EventPublisher(analytics side), the placeholder values has to be sent >>>>>>>>> as >>>>>>>>> meta data/correlation data/payload data/arbitrary data, since in >>>>>>>>> analytics >>>>>>>>> side, the user claim values are not getting from the user store. >>>>>>>>> In order to send the placeholder values from IS side, anyway we >>>>>>>>> have to load the email template and retrieve the placeholders. So as >>>>>>>>> I have >>>>>>>>> understood, for email notifications, it's not needed to use the email >>>>>>>>> template loading part in analytics, since it'll be a redundant task. >>>>>>>>> (Refer >>>>>>>>> [2]) >>>>>>>>> >>>>>>>> >>>>>>>> Here we can set the claim values as arbitrary data, and the >>>>>>>> notification specific details as the meta, correlation & payload data. >>>>>>>> Then we can use the template loading only at the analytics side. >>>>>>>> >>>>>>> In this case, from IS side, without parsing only the user claims >>>>>>> needed for a particular email template(i.e.user claim values for the >>>>>>> placeholders in email template), we have to pass all the user claims as >>>>>>> arbitrary data values. In that case there's no need for loading the >>>>>>> template from the registry in IS side. So that in analytics side, all >>>>>>> the >>>>>>> values needed for filling out the template will be there. Will check on >>>>>>> that. >>>>>>> >>>>>> >>>>>> I don't think it will be a good solution. There can be sensitive >>>>>> information in the claims which we can't send. So for this release it's >>>>>> OK >>>>>> if we read the template in both sides - security is more important than >>>>>> performance; or read it only in IS side - but additionally send all those >>>>>> claims as arbitrary data as well, so if some one wants can use them in >>>>>> CEP >>>>>> side by their output adaptors. >>>>>> >>>>> >>>>> I think then we can have a common configuration in IS side to specify >>>>> what are the claims that should be added to notifications. >>>>> >>>>> Regards >>>>> Suho >>>>> >>>>> >>>>>> >>>>>> >>>>>>>> >>>>>>>>> (2) The email templates has to be changed as follows. >>>>>>>>> i) if the value will be provided in an arbitrary data map, the >>>>>>>>> placeholder should be with a prefix "arbitrary_" >>>>>>>>> (ex:{{arbitrary_givenname}}) >>>>>>>>> >>>>>>>> ii) if the value will be provided in an meta data map, the >>>>>>>>> placeholder should be changed as {{...}} (ex:{{givenname}}) >>>>>>>>> >>>>>>>>> No we should not use "arbitrary_" for any cases, its internal >>>>>>>> information and the names should not have "arbitrary_" even if its in >>>>>>>> arbitrary data map or otherwise. >>>>>>>> >>>>>>>> (3) Only Text OutputMapping Content can be filled from a value in >>>>>>>>> an arbitrary data map using prefix "arbitrary_" . It's not possible >>>>>>>>> to use >>>>>>>>> a value of an arbitrary data map, in a Dynamic adapter properties, >>>>>>>>> only a >>>>>>>>> value from a meta data/correlation data/payload data map can be used. >>>>>>>>> I >>>>>>>>> think that need to be extended to use even an arbitrary value as a >>>>>>>>> dynamic >>>>>>>>> adapter property.(Refer [3]) >>>>>>>>> >>>>>>>> >>>>>>>> @Gobi can you please fix this if that's the case. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> (4) The default stream definitions and publisher definitions has >>>>>>>>> to be deployed on super tenant as well as other tenants as well. And >>>>>>>>> when a >>>>>>>>> new tenant is added, those streams and publishers has to be deployed >>>>>>>>> for >>>>>>>>> that particular tenant as well. >>>>>>>>> >>>>>>>>> We can have a tenant creation handler to do this copying during >>>>>>>> that tenant creation time. WDYT? >>>>>>>> >>>>>>>> Really appreciate your ideas/suggestions regarding the above >>>>>>>>> mentioned concerns. >>>>>>>>> >>>>>>>>> [1] Invitation: [Architecture] [Discussion] Improvement to use >>>>>>>>> Siddhi str... @ Wed Jul 20, 2016 4:30pm - 5:30pm (IST) ( >>>>>>>>> indu...@wso2.com) >>>>>>>>> >>>>>>>>> [2] https://github.com/wso2/carbon-analytics-common/blob/master/ >>>>>>>>> components/event-publisher/org.wso2.carbon.event. >>>>>>>>> publisher.core/src/main/java/org/wso2/carbon/event/publishe >>>>>>>>> r/core/internal/type/text/TextOutputMapper.java#L108 >>>>>>>>> >>>>>>>>> [3] https://github.com/wso2/carbon-analytics-common/blob/master/ >>>>>>>>> components/event-publisher/org.wso2.carbon.event. >>>>>>>>> publisher.core/src/main/java/org/wso2/carbon/event/publishe >>>>>>>>> r/core/internal/EventPublisher.java#L311 >>>>>>>>> >>>>>>>>> Thanks and Regards >>>>>>>>> -- >>>>>>>>> Indunil Upeksha Rathnayake >>>>>>>>> Software Engineer | WSO2 Inc >>>>>>>>> Email indu...@wso2.com >>>>>>>>> Mobile 0772182255 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> *S. Suhothayan* >>>>>>>> Associate Director / Architect & Team Lead of WSO2 Complex Event >>>>>>>> Processor >>>>>>>> *WSO2 Inc. *http://wso2.com >>>>>>>> * <http://wso2.com/>* >>>>>>>> lean . enterprise . middleware >>>>>>>> >>>>>>>> >>>>>>>> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: >>>>>>>> http://suhothayan.blogspot.com/ >>>>>>>> <http://suhothayan.blogspot.com/>twitter: >>>>>>>> http://twitter.com/suhothayan <http://twitter.com/suhothayan> | >>>>>>>> linked-in: >>>>>>>> http://lk.linkedin.com/in/suhothayan >>>>>>>> <http://lk.linkedin.com/in/suhothayan>* >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Indunil Upeksha Rathnayake >>>>>>> Software Engineer | WSO2 Inc >>>>>>> Email indu...@wso2.com >>>>>>> Mobile 0772182255 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Thanks & Regards, >>>>>> >>>>>> *Johann Dilantha Nallathamby* >>>>>> Technical Lead & Product Lead of WSO2 Identity Server >>>>>> Governance Technologies Team >>>>>> WSO2, Inc. >>>>>> lean.enterprise.middleware >>>>>> >>>>>> Mobile - *+94777776950* >>>>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *S. Suhothayan* >>>>> Associate Director / Architect & Team Lead of WSO2 Complex Event >>>>> Processor >>>>> *WSO2 Inc. *http://wso2.com >>>>> * <http://wso2.com/>* >>>>> lean . enterprise . middleware >>>>> >>>>> >>>>> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: >>>>> http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter: >>>>> http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: >>>>> http://lk.linkedin.com/in/suhothayan >>>>> <http://lk.linkedin.com/in/suhothayan>* >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> *S. Suhothayan* >>>> Associate Director / Architect & Team Lead of WSO2 Complex Event >>>> Processor >>>> *WSO2 Inc. *http://wso2.com >>>> * <http://wso2.com/>* >>>> lean . enterprise . middleware >>>> >>>> >>>> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: >>>> http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter: >>>> http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: >>>> http://lk.linkedin.com/in/suhothayan >>>> <http://lk.linkedin.com/in/suhothayan>* >>>> >>> >>> >>> >>> -- >>> Indunil Upeksha Rathnayake >>> Software Engineer | WSO2 Inc >>> Email indu...@wso2.com >>> Mobile 0772182255 >>> >>> _______________________________________________ >>> Dev mailing list >>> d...@wso2.org >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> *V. Mohanadarshan* >> *Associate Tech Lead,* >> *Data Technologies Team,* >> *WSO2, Inc. http://wso2.com <http://wso2.com> * >> *lean.enterprise.middleware.* >> >> email: mo...@wso2.com >> phone:(+94) 771117673 >> > > > > -- > > *S. Suhothayan* > Associate Director / Architect & Team Lead of WSO2 Complex Event Processor > *WSO2 Inc. *http://wso2.com > * <http://wso2.com/>* > lean . enterprise . middleware > > > *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: > http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter: > http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: > http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>* > -- Indunil Upeksha Rathnayake Software Engineer | WSO2 Inc Email indu...@wso2.com Mobile 0772182255
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
