I think getting the claims will improve the message formatting when sending
the message, and based on the discussion with Johann they cannot determine
what claims the message formatting will need. if IS need to send the claims
it has to also read the message to understand the necessary claims.

Any suggestions ?

Regards
Suho

On Thu, Aug 11, 2016 at 4:42 PM, Mohanadarshan Vivekanandalingam <
mo...@wso2.com> wrote:

>
>
> On Thu, Aug 11, 2016 at 11:32 AM, Indunil Upeksha Rathnayake <
> indu...@wso2.com> wrote:
>
>> 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*
>>
>
> Above [1] and [2] are already implemented in Event Publisher level and can
> be usable for above usecase.. But [2] (which is mentioned as an improvement
> for Analytics side) is not valid IMO.. That is not something that we need
> to handle in analytics or Event Publisher side, it is architecturally
> incorrect to handle in that level.. What need to be done is, we need to get
> those claims from identity level and send those relevant claims in the
> event itself..
>
> What is the reason for defining [3] as an improvement for analytics ?
>
> Thanks,
> Mohan
>
>
>>
>>
>> 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.c
>>>>> ore/src/main/java/org/wso2/carbon/event/publisher/core/inter
>>>>> nal/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.c
>>>>>>>>>>> ore/src/main/java/org/wso2/carbon/event/publisher/core/inter
>>>>>>>>>>> nal/type/text/TextOutputMapper.java#L108
>>>>>>>>>>>
>>>>>>>>>>> [3] https://github.com/wso2/carbon-analytics-common/blob/master/
>>>>>>>>>>> components/event-publisher/org.wso2.carbon.event.publisher.c
>>>>>>>>>>> ore/src/main/java/org/wso2/carbon/event/publisher/core/inter
>>>>>>>>>>> nal/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
>>>>> Dev@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
>>
>
>
>
> --
> *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 | 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>*
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to