On Tue, Aug 6, 2013 at 12:10 PM, Balakrishnan Gokulakrishnan <[email protected] > wrote:
> Hi all, > > Currently in the activity data agent used to publish activity data to BAM, > the ID associated with an activity is propagated through the SOAP header. > An Axis2 handler is responsible to check if the incoming message already > has a header property set, and if not it will add a new ID. The message > context is used to track responses to requests and an out handler checks if > the activity ID set in the request is present or not. > > While we were testing the activity data publisher in the ESB we noticed > that in situations where multiple ESB instances are used in sequence, the > activity ID is not being maintained per single activity. The reason for > this is that the PTT used in the ESB by default only builds the message for > predefined handlers, an thus the activity ID set by a previous node is not > being seen. This results in more than one activity ID being used per > activity in multiple nodes. For KPI monitoring, it will be necessary to > uniquely identify an activity through its ID and will need to use others > IDs such as parentID etc. as well in the future. > > We discussed the following options to go ahead with improving this > behaviour: > > 1. Keep the activity ID in the SOAP header - This will require having the > messages to be built. We could add properties to the handler to achieve > this. > > Pros - Easier to implement, maintains transport independence > Cons - Will need to mandate message building. Will need to look for other > options in situations such as servicing REST calls etc. > > > 2. Use the transport-level (HTTP) header - the activity ID is moved from > the SOAP header to the HTTP header. > > Pros - No need to build the message (i.e. can cater to ESB passthru > scenarios). More extensible in terms of supporting different message types > Cons - Transport-dependent (e.g. when JMS etc. are used will need to > manually copy over the ID as a JMS property or similar) > > > 3. Keep the activity ID in both - HTTP header as well as SOAP header > > Pros - can address transport switches without user intervention > Cons - Unwieldy to work with. May be edge cases which will restrict use > > This approach is better as we can maintain activity ID at least in one header (transport header or SOAP header). In each of our data agent we should try to check both headers if applicable. (This may not applicable in cases like pure PTT and JMS) If both headers are applicable and only one contains the activity ID that means the other was lost in a previous node. So the missing header should be updated with the existing header. In the worst cases where both HTTP headers and SOAP headers are unavailable still the activity related data can be included in the payload. So I think better to provide that option as well. > > We are aiming to proceed with option 2 (moving it to the HTTP header). > Please add your comments/suggestions. > > Thanks, > Gokul. > > -- > *Balakrishnan Gokulakrishnan* > Software Engineer, > WSO2, Inc.; http://wso2.com > > Twitter: http://twitter.com/gokulbs > Mobile: +94775935789 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
