Event Monitoring in WMB

Auditing vs Logging

From what I have worked on, there is a difference between them based on their nature. A log is(may be) perishable while an audit trail is secure and non-perishable. As a result ou will never log sensitive information or information which you will need later. An audit trail on the other hand is secure. It is something that should not be perished easily.

For example : in a bank software you will audit the transactions;: credit-debit, failed transactions etc. This audit will be in to the database. THe log file may save the transaction that crashed when the softare failed and did not enter the system.

Difference between Audit log and normal log

An audit log contains all the information necessary to follow a user's interaction with a system. It will usually contain more information and detail than what is necessary to have in day-to-day operations.

You can think of it in terms of a phone system. You can record every call that passes through the phone system to be able to go back in time and prove exactly what a person said, but it wouldn't be feasible to use a log containing all of that information for taking care of phone system operations.

An audit log usually contains more sensitive information than other system logs so access to it should be more restricted.

Example scenario:

i use audit to trace the users actions, and to reconstruct current values.

for instance, we have a table with giftcardvalues, and we can see in that table that the current value is $100 and the original value $200.

Is that correct, we don't know....

for that question to be answered we have to know what happened in between.

so we have a audit table in which we save all actions for that table, like this:

jan. 1 init $200

jan. 3 add $300

jan. 5 subtract $350

jan. 7 check value (returned 150)

jan. 8 subtract $50

now i know what to say if a user calls and says: hey, where did my $100 go?

'normal' logging is used to log errors, process info etc. wo we can debug the app when, for instance, the audit info and the actual values for the giftcard don't match, so we can see what is going wrong in the code.

Statistics vs Event Monitoring

Statistics : Gives the statistical information about Broker,Execution Group,Message Flow.This will also  collect metrics information about the broker,EG,Message flow ,Resources such as JMS,JDBC,FTP,etc.

Event Monitoring:

Message broker emits a monitoring event (an XML document) when something interesting happens. Events are typically emitted to support transaction monitoring, transaction auditing, and business process monitoring. The event XML conforms to the monitoring event schema WMBEvent.xsd.

Event types

You can configure a message flow to emit two types of events: transaction events and terminal events. There are three types of transaction events: start, end, and rollback. The transaction events are emitted only from input nodes such as MQInput and HTTPInput. Terminal events are emitted from any terminal of any node.

Event Monitoring works on the basis of Pub-Sub feature of message broker.The events emitted from terminals or transaction in a flow are XML messages and they are published to specific topics.

Eg:  Topic name here is  BROKER_EVENTS_DEFAULT

       

The form of the Topic String is :

$SYS/Broker/<brokerName>/Monitoring/<executionGroupName>/<flowName>

Topic String in the example is $SYS/Broker/RadBroker1/Monitoring/default/MonitoringFlow

As per the above specification,the events emitted in the flow “MonitoringFlow” deployed in the ExecutionGroup “default” are published to the topic “BROKER_EVENTS_DEFAULT”.

To subscribe to the

This event data includes the payload and transaction data (i.e. what message flow, execution group, timestamp, and other useful transaction information).

1)Setup the Topic and Topic String

Subcription for this topic  will be done as below

 Without even enabling the monitoring in the toolkit and the need to redeploy the flow,we can enable

mqsichangeflowmonitoring BRK1 -e default -f MonitoringEvents_MF -s 

"QIN.transaction.start,QIN.transaction.end,QIN.transaction.rollback" -i enable

Activating Monitoring on the broker as ,

mqsichangeflowmonitoring RadBroker1 -c active -e default  –f MonitoringFlow 

To check the status of the monitoring,

mqsireportflowmonitoring RadBroker1 -e default -f MonitoringFlow  -a

Enabling statistics:

mqsichangeflowstats RadBroker1  -s -e default -f MonitoringFlow -c active -o xml

$SYS/Broker/RadBroker1/StatisticsAccounting/SnapShot/default/MonitoringFlow

Useful Links –  Event Monitoring

http://www.youtube.com/watch?v=VRDTA9syeZ4

http://webspheremb.blogspot.in/2011/09/flow-monitoring-business-monitoring-on.html

http://webspherestories.blogspot.in/2012/08/extending-value-of-wmb-with-websphere.html

http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/index.jsp?topic=/com.ibm.etools.mft.doc/ac19100_.htm

Setting up Event Monitoring in Message Broker version 8

http://transformatech.wordpress.com/2012/06/13/websphere-message-broker-wmb-how-to-setup-wmb-v8-event-monitoring/

Using Shared Variables in Message Broker

Variables

The types of variables varies with Scope,Lifetime,Shared characteristics

Scope – Range (node level,flow level..)

Lifetime – Time (Lifetime for one thread)

Shared Variable:

Shared

Shared variables can be used to implement an in-memory cache in the message flow, see Optimizing message flow response times. Shared variables have a long lifetime and are visible to multiple messages passing through a flow, see Long-lived variables. Shared variables exist for the lifetime of the execution group process, the lifetime of the flow or node, or the lifetime of the node SQL that declares the variable (whichever is the shortest). Shared variables are initialized when the first message passes through the flow or node after each broker startup.

ATOMIC option of the BEGIN ... END statement. The BEGIN ATOMIC construct is useful when a number of changes must be made to a shared variable and it is important to prevent other instances seeing the intermediate states of the data.

As Shared variables can be used under one execution group for multiple instances,if we are using counter,then there is a possibility that one thread tries to overwrite the other thread.This will produce unexpected results.To avoid this,we need to make it Atomic.

For LongLived variables –We can use database.But Write access will be slow.But persistence and Transaction is good.

you cannot share variables across execution groups.

Shared variables advantages:

Hence we go for in-memory cache.R/W access is fast in the expense of shorted persistence and no transaction.

Access is direct; that is, there is no need to use a special function (SELECT) to get data, or special statements (INSERT, UPDATE, or DELETE) to modify data. You can refer to the data directly in expressions.

Long-lived data types have an extended lifetime beyond that of a single message passing through a node. Long-lived data types are shared between threads and exist for the life of a message flow

ESQL ROW Datatype

The ROW data type holds a tree structure. 

To store a message tree in a shared variable, use the ROW data type.

Shared Variable usage code:

Without Atomicity

DECLARE CountSHARED INTEGER0;

 DECLARE mySharedRowSHARED ROW;

CREATE COMPUTEMODULE SharedVariables_test_Compute

      CREATE FUNCTIONMain() RETURNS BOOLEAN

      BEGIN

            -- CALL CopyMessageHeaders();

             

       SET OutputRoot.XMLNSC.SHARE.COUNT  = Count;

     

     SET mySharedRow= THE

   (SELECT ITEM Name FROM InputRoot.XMLNSC.Student.Name[] );

  

   SET OutputRoot.XMLNSC.SHARE.Result = mySharedRow;

   SET Count=Count+1;

            RETURN TRUE;

      END;

With Atomicity

If we want to use Atomic block only in the counter increment part (Write part) but not the Read part of some Shared variable,then only the Write portion can be given as Atomic.

DECLARE CountSHARED INTEGER0;

 DECLARE mySharedRowSHARED ROW;

CREATE COMPUTEMODULE SharedVariables_test_Compute

      CREATE FUNCTIONMain() RETURNS BOOLEAN

      BEGIN ATOMIC

            -- CALL CopyMessageHeaders();

             

       SET OutputRoot.XMLNSC.SHARE.COUNT  = Count;

     

     SET mySharedRow= THE

   (SELECT ITEM Name FROM InputRoot.XMLNSC.Student.Name[] );

  

   SET OutputRoot.XMLNSC.SHARE.Result = mySharedRow;

   SET Count=Count+1;

            RETURN TRUE;

      END;