[Tutorial] Connecting and Publishing Stats and Notification to WSO2 BAM from WSO2 GREG
By Shazni Nazeer
- 12 Nov, 2014
WSO2 Governance Registry (GREG) is a service-oriented architecture (SOA) integrated registry repository for governing metadata of various artifacts. It’s a fully open-source product licensed under Apache License version 2.0. It’s also a very flexible and extensible product of WSO2 stack of products, which can be used for many tasks typically needed for governance of various types of resources, be it a text document, XML file, Microsoft office document, etc. Furthermore, it can be integrated with other WSO2 products like WSO2 API Manager and WSO2 Business Activity Monitor (BAM) and external products like Oracle Service Bus and Microsoft Sharepoint.
In this tutorial, we’ll be looking at how we can integrate WSO2 GREG with WSO2 BAM. WSO2 BAM addresses a wide range of monitoring requirements in business activities and processes. It is a flexible framework to model your own key performance indicators to suit different stakeholders and it is designed to be significantly scalable to sustain large amounts of corporate data loads when aggregating, analyzing, and presenting data.The need to integrate GREG and BAM is to have some stats and notification to be delivered to BAM from GREG. Integrating GREG with BAM also enables runtime governance in GREG to some extent. In this article, we’ll be subscribing to notifications from GREG’s end and will publish those notifications to BAM.
Here’s a step-by-step guide to a very simple usage of GREG and BAM integration. We are using the latest GREG release to date (version 4.6.0) and the latest BAM release to date (version 2.4.1) in this guide.
- Extract WSO2 BAM and WSO2 GREG. Let’s refer the extracted directories to be BAM_HOME and GREG_HOME, respectively, from here onwards. Make WSO2 BAM’s offset to 1 in carbon.xml. To do that, navigate to BAM_HOME/repository/conf/carbon.xml and find the tag
and do the change. Also make the port in BAM_HOME/repository/conf/etc/hector-config.xml to 9161, since the offset is 1. Say the offset is k, then make this port to 9160 + k. We make the BAM offset to 1, since we are going to run both GREG and BAM in the same server. If they are to be run in two different servers, the offset need not be set, but setting it isn’t an issue either.
Start the WSO2 BAM by navigating into the bin directory of the BAM_HOME and issuing the following command
./wso2server.sh (In Linux)
wso2server.bat (In Windows)
Once started, you should be able to access the BAM management console by navigating to the https://localhost:9444/carbon/ from your favourite browser. Here, the 9444 is the port, which is after the port offset of 1. If you have not done a port offset, you need to use the port of 9443.
Next, we need to deploy the KPI_Registry_Activity.tbox BAM Toolbox to WSO2 BAM. A BAM Toolbox is an installable archive that contains stream definitions, dashboard components, and analytics for WSO2 BAM. The KPI_Registry_Activity.tbox is a pre-built BAM Toolbox based on the KPI Monitoring Sample example of WSO2 BAM, which is specifically designed for this sample. Read the KPI Monitoring Sample example of WSO2 BAM to learn how to make changes to this BAM Toolbox or create your own.
To deploy the tool box, navigate to Home -> Manage -> BAM Tool Box -> Add. Select the toolbox downloaded from the file system and install it.
- Add following dependency in GREG_HOME/samples/handler/src/pom.xml
org.apache.axis2.wso2 axis2 org.wso2.carbon org.wso2.carbon.databridge.agent.thrift 4.0.1 org.wso2.carbon org.wso2.carbon.databridge.commons 4.0.0
Comment out the following
Fragment-Host>org.wso2.carbon.registry.core→ org.wso2.carbon org.wso2.carbon.context
The reason we need to do this is because if the org.wso2.carbon.registry.core is a fragment bundle then this sample bundle would become an extension to the Registry kernel. But since this is an axis2 service bundle, it shouldn’t become active until the Axis2 bundle becomes active. In WSO2 products’ OSGi startup order, the Registry Kernel bundle gets activated before the Axis2 runtime. Therefore, having this sample an extension to kernel, this has to start before Axis2 runtime. Thus, this sample bundle needs Axis2 runtime, and Axis2 runtime waits until the Registry kernel bundle get activated, eventually resulting in a deadlock.
Add the following content to a file named services.xml in
Add the SampleMessageReceiver.java and build it using ‘mvn clean install’ on samples/handler/src/
You can find the SampleMessageReceiver.java at
Copy the GREG_HOME/ samples/handler/src/target/
GREG_HOME/repository/components/dropins and start the GREG by executing the following in the bin directory.
./wso2server.sh (In Linux)
wso2server.bat (In Windows)
After the server has started, log into the Management Console and add a notification to the root collection with the following settings:
Event - Update
Notification - SOAP
Endpoint - http://localhost:9763/services/Subscriber
Hierarchical Subscription Method - Collection, Children and Grand Children
To add a notification subscription, navigate to Home -> Configure -> Notifications -> Add Subscription to Resource/Collection. Add a subscription for an interested collection with the above details.
- Perform some operations like creating/updating resources in the collection you subscribed for. This should publish events to the WSO2 BAM. You can also see the graphs showing the details about the operations performed in the WSO2 BAM by navigating to the BAM Management console and clicking the “View Portal”. Following is a screenshot of the stats captured of sample operations performed.