Monday, August 19, 2013

A Very Simple ODM Events Project (Part 4)

Today we're going to write, as simply as possible, an events project that takes a customerID and a value, runs a rule against them, and if the rule fires it will trigger an action, writing a file to a folder on the hard drive.

So go ahead and start Event Designer.  I've created a new Event Project called DeveloperHat01, and then right clicked in and selected create new Event.  I'm going to click next and name my event CustomerValueEvent and then click finish.  I am not going to assign a connector to this event.



Next I'm going to create an event object.  This will represent the incoming data elements.  I will call it CustomerValueEO.  Right there in the Event definition click Add.  Make it a blank Event Object.  Name it.


And as I drill down into it this event object, I'll add a customerID <string> and value <Integer>  That takes care of defining an Event.


Next I'm going to create a Business Object that contains the same information as the Event Object.  The Business Object will have verbalizations so that we can write rules against it. So right click in the project, select New... Business Object.  Name it CustomerValueBO.  Click Next.  Select Create Business Object with the same fields as an event object.   Click next, and then select the CustomerEventEO as shown below and click Finish.


Now let's create an Action so that when a rule triggers something will happen.  Right click in the project and select New... Action.

Create a blank action.  Click next.  Name it CustomerValueAction.  Click next. and select the File System connector so that it will write to the file system when our rule gets triggered.  And then just as we did when creating the Event Object we'll create a new Action Object.  Call it CustomerValueAO and give it two fields just like before called CustomerID and Value.

Here's where action objects are different than event objects.  We have to tell Action Objects where to get their data from.   So for each of the fields, go ahead and map them to the fields in the Business Object.



Now, because we've defined a file system connector for this Action, we'll need to tell it where to write to.  We do that by selecting the Connector Tab, and setting the file path and filename pattern.  In this case c:/temp and *.xml will work for us.


Next we're going to define a Event Rule.  Right Click in the project and select New... Event Rule.  Name it CustomerValueRule01, click Next.  Have it trigger when the customerValueEvent is detected, click next.  Have it use the System Context.  The context is what holds the event correlation information. Click Next.  And let's have it correlate against the CustomerID.

The content of the rule will say:

if the value of the customerValueBO is more than 10 then customerValueAction ;

So quite simply, if any events come in that have a customer value > 10 we will trigger our output Action.  There is a lot more we could do with events that would make them more meaningful, but for now let's just test this one just to show how they work.

So now we want to deploy this project to the Events Server.  Right Click on the project.  Select Deploy... All Assets... and provide the server information.  For a default ODM / Sample Server install this might be localhost, 9080, admin, admin and http protocol.  Click Finish.  You might have to enter another password at this point.

In a minute you'll see a dialog that says, Successful Deployment to Runtime.

Now we can open a Web Browser to our test widgets.  http://localhost:9080/EventWidgets  Log in as your test user, which might be admin / admin if you did the default install of SamplesServer.    You should see a screen similar to this one.  If you do not, then you might want to review Part 3 of this Lab.  You've either logged in as a user that does not have test privileges or you do not have the one or more of the Test Widget Ear files installed or some combination of these:


Click on the Event Tester Widget.   And from there click on Select Event Template.  Select the CustomerValueEvent and click OK.  Enter a customerID of 1 and a value of 1.  Go ahead and click Send Event.  Then look at the filters tab.  You'll see that we received a CustomerValue Event.  But if you check the actions tab, nothing will have fired.  Go back to the first tab. Do this again with a customerID of 2 and a value of 20 and you should see different results in the actions tab.


And in fact if we open a file browser to the c:\temp folder we will find an xml file with a long name and the following content, which shows that we've written a WBE version 6.2 Connector Bundle, showing the customer value and customer ID.

<?xml version="1.1" encoding="UTF-8"?>
<connector xmlns="http://wbe.ibm.com/6.2/Action/CustomerValueAction" name="WBE" version="6.2">
<connector-bundle id="357B93DB17A280095B11E3C602377689" name="CustomerValueAction" stream="2" type="Action" workflow="FACE">
<CustomerValueAO>
<Value type="Integer">20</Value>
<CustomerID type="String">2</CustomerID>
</CustomerValueAO>
</connector-bundle>
<system>Base-Win2k8x64</system>
<timestamp>2013-08-20T01:46:27.368-04:00</timestamp>
<loginfo>This is an action from Decision Server</loginfo>
</connector>


In the next lab we will write an event packet directly to the JMS bus in the ODM Events Server and get a similar result.















IBM ODM Events from Sun JDK (Part 3)

Configuring a Test Environment 


Today I have to configure IBM ODM Events so that the SunJDK can send messages to it.  There's a few steps.  I'll be working mainly in the Rules Designer.  Review the Part 1 of this Blog Post, which just shows how to get a JMS client talking to ODM in with the IBMJDK and part 2 which shows how to get the SunJDK configured properly.
I want to take a bit of a sidetrack, because in part 1 we assumed that you had ODM installed.  If you installed the SamplesServer, then you're all set, you can ignore this part of the lab.  In fact, if you didn't have something set up you never could have gotten the first lab to work, so this all might be moot.

Anyway, if you are developer I recommend that you install just the ODM SamplesServer and avoid the following steps only because they are unnecessarily complicated compared to just installing SamplesServer.

I installed ODM Events in a stand-alone server, by itself, without Rule Execution Server or Decision Center and without SamplesServer.  I did that by choosing a custom install from the launchpad.

There are a few things that are not entirely clear the first time through a custom install. I tend to miss some important steps that are actually in the InfoCenter, but that's just me.

I installed with DB2 instead of Derby.  The custom installer assumes that you already have DB2 installed and that you've created a database.  I called mine ODMEVDB.  A limited license DB2 comes with the product at the time of this writing.

You'll need to install WAS ND, eXtrme Scale, and optionally JDK 7.4.  Install these into a package group called C:\IBM\WAS. Then install Events and Profile Templates into a new package group called 
C:\IBM\ODM.  You can optionally install Decision Center DC and Decision Server DS at this point too.

Once that's done, go into the profile creation tool at C:\IBM\WAS\bin\profilemanagment\pmt. and create your IBM Decision Server Events profile.  You might also optionally create a deployment manager, which you will have to augment with 
IBM Decision Server Events.  But creating a cell and a cluster is beyond the scope of this series of labs.

Start the server and go into the admin console (http://localhost:9060 by default).  Go into the websphere enterprise applications and check to make sure you have both the WBETesterEAR and EventWidgetsEar applications deployed.  If they are not there you'll have to find them in the product binaries and deploy them as you would any other application.  The installableApps should be located in the<ODM Install>\runtime folder.

To make these test widgets work you will need to add a testuser, a group, and set an administrative role.  So go into the admin console / users and groups.  Add a group, call it EventOperators.  Add a user, call it testuser.  Add the user to the group.  Then under Administrative Group Roles, add the Operator Role to the EventAdministrator role.  And make sure you click OK and Save your changes at each step.

Next, go into the WebSphere Enterprise Applications and map this user to the roles  WBEAdmin, WBERestApiUser and EventWidget Users which are found in the two applications, wbetesterear and eventwidgetsear.  Click OK and save, and restart those two apps.
At this point if you open a browser to http://localhost:9080/EventWidgets, it will ask you to log in.  Go ahead and log in as the testuser and you should see three widgets, like these.  If you don't see them, or if they have little yellow "caution signs" next to them, go back and review the authenticated users steps, making sure the test user is assigned to the proper role.



In part 4 we'll develop a simple Event Application and test it using these widgets.







Friday, August 16, 2013

IBM ODM Events from Sun JDK (Part 2)

Configuring a Sun JMS client to talk to WAS ...

Today I have to configure IBM ODM Events so that the SunJDK can send messages to it.  There's a few steps.  I'll be working mainly in the Rules Designer.  Review the Part 1 of this Blog Post, which just shows how to get a JMS client talking to ODM in with the IBMJDK.

Sun works with the JKS formatted trust and store files, although you can probably get it to work with the p12 formatted files, I find that converting them over to JKS is the simplest.

Go to your <ODM INSTALL>/bin directory and start ikeyman.  From there open the trust.p12 file.  The default password is WebAS.  And then just save it as trust.jks in the jks format with the same password.  And also do the same for your key.p12 file saving it as key.jks in the jks format.


Now, in Eclipse, copy the security configuration folder that we created in Part 1 and name it SunJDKSecurity.

Edit the ssl.client.props file and change the user.root to point to your current project/SunJDKSecurity folder. To do this right click on the project security folder that you created and select properties.  This will give you the full path to the folder.  Highlight the path and use ctrl-c to copy.  Then ctrl-s to save the file.

In addition you will have to replace some of the IBMJSSE settings with SunJSSE settings in this file. make the following edits.  The big change is modifying the certifcates from .p12 to .jks format.  We'll do that in the next step.

SettingIBMJDK ValueSunJDK Value
com.ibm.ssl.aliasDefaultSSLSettingsDefaultSSLSettings
com.ibm.ssl.protocolSSL_TLSSSL
com.ibm.ssl.securityLevelHIGHHIGH
com.ibm.ssl.trustManagerIbmPKIXPKIX
com.ibm.ssl.keyManagerIbmX509SunX509
com.ibm.ssl.contextProviderIBMJSSE2SunJSSE
com.ibm.ssl.enableSignerExchangePrompguigui
#com.ibm.ssl.keyStoreClientAliasdefault
#com.ibm.ssl.customTrustManagers
#com.ibm.ssl.customKeyManager
#com.ibm.ssl.dynamicSelectionInfo
#com.ibm.ssl.enabledCipherSuites
# KeyStore information
com.ibm.ssl.keyStoreNameClientDefaultKeyStoreClientDefaultKeyStore
com.ibm.ssl.keyStore${user.root}/etc/key.p12${user.root}/etc/key.jks
com.ibm.ssl.keyStorePasswordWebASWebAS
#com.ibm.ssl.keyStorePassword{xor}CDo9Hgw{xor}CDo9Hgw
com.ibm.ssl.keyStoreTypePKCS12JKS
com.ibm.ssl.keyStoreProviderIBMJCESUN
com.ibm.ssl.keyStoreFileBasedTRUETRUE
# TrustStore information
com.ibm.ssl.trustStoreNameClientDefaultTrustStoreClientDefaultTrustStore
com.ibm.ssl.trustStore${user.root}/etc/trust.p12${user.root}/etc/trust.jks
com.ibm.ssl.trustStorePasswordWebASWebAS
#com.ibm.ssl.trustStorePassword{xor}CDo9Hgw{xor}CDo9Hgw
com.ibm.ssl.trustStoreTypePKCS12JKS
com.ibm.ssl.trustStoreProviderIBMJCESUN
com.ibm.ssl.trustStoreFileBasedTRUETRUE
com.ibm.ssl.trustStoreReadOnlyFALSEFALSE




Check that you edited the sas.client.props file and set the following, which you would have done in the part 1 of this Blog)
com.ibm.CORBA.securityServerPort to your correct port, by default it is 2809.
com.ibm.CORBA.loginSource=properties
com.ibm.CORBA.loginUserid=admin and set
com.ibm.CORBA.loginPassword=admin
(Assuming admin/admin for authentication to the SamplesServer)

In project properties, (right click on project, find properties in the menu), go to the Java Builder tab.  Add the j2ee.jar as an External Jars from the <ODM Install Dir>/lib folder.

Now change the the runtime properties that you set in the first part of this exercise so they point to the SunJDKSecurity folder.  In the VM Arguments modify the following:
-Dcom.ibm.SSL.ConfigURL=file:///${project_loc}/SunJDKSecurity/properties/ssl.client.props
-Dcom.ibm.CORBA.ConfigURL=file:///${project_loc}/SunJDKSecurity/properties/sas.client.props


At this point, you should be able to run this app without errors using just the SunJDK.  Next we're going to add an ODM Events Project to the workspace.



IBM ODM Events from Sun JDK (Part 1)

Configuring an IBM JMS client to talk to WAS ...

Today I have to configure IBM ODM Events so that the SunJDK can send messages to it.  There's a few steps.  I'll be working mainly in the Rules Designer.  And this first part just shows how to get a JMS client talking to ODM in with the IBMJDK.

Let's assume that you have ODM with the Events components installed on C:\IBM\ODM85.  And that you have created an ODM profile in the folder <ODM Install>/profiles/ODMSamples8500. I am using version 8.5, but this should work with previous versions of ODM / WODM with some obvious changes to pathnames, filenames, etc.  Likewise, it doesn't have to be SamplesServer.

Even though I'm not going to use it yet, I'll need to install the SunJDK as an alternate JRE in Eclipse.  So I downloaded the SunJDK only and installed that in C:\Java.  Then in Eclipse Windows/Preferences menu, filter on Installed JRE. and from there add the new Java install dir.

Then I'll need a client JMS project in Eclipse, so change to the Java perspective and create a new Java project.  Call it JMSClientExample.

Create some security configuration folders.  In the Eclipse project create a new folder.  Call it security.  Under it create two more folders, one called properties and one called etc.

Copy the trust.p12 and key.p12 files from your <ODM Profile>/etc folder in to the new etc folder.
To do this, from the project inspector, right click on the etc folder and select Import... File System and then browse to the <ODM profile>/etc folder and select those files.

Likewise, copy the ssl.client.props and sas.client.props files from your <ODM Profile>/properties folder in to the new properties folder.  To do this, right click on the properties folder and select Import... File System and then browse to the <ODM profile>/properties folder and select those files.

Edit the ssl.client.props file and change the user.root to point to your current project/security folder. To do this right click on the project security folder that you created and select properties.  This will give you the full path to the folder.  Highlight the path and use ctrl-c to copy.  Then ctrl-s to save the file.

Edit the sas.client.props file and set the following:
com.ibm.CORBA.securityServerPort to your correct port, by default it is 2809.
com.ibm.CORBA.loginSource=properties
com.ibm.CORBA.loginUserid=admin and set
com.ibm.CORBA.loginPassword=admin
(Assuming admin/admin for authentication to the SamplesServer)



In project properties, (right click on project, find properties in the menu), go to the Java Builder tab.  Add the j2ee.jar as an External Jars from the <ODM Install Dir>/lib folder.

Create a new class in the project.  Call it JMSClientExample.java and add the following source code:

import java.util.Hashtable;
import java.util.Properties;

import javax.jms.Connection;
import javax.jms.ConnectionFactory;
import javax.jms.Destination;
import javax.jms.MessageProducer;
import javax.jms.Session;
import javax.jms.TextMessage;
import javax.naming.Context;
import javax.naming.InitialContext;


public class JMSClientExample {

/**
* @param args
*/
public static void main(String[] args) {
// TODO Auto-generated method stub

   String  messageID                 = null;
   String  outString                 = null;
     
String  cfName                   = "jms/WbeConnectionFactory";
   String  qnameIn                  = "jms/actionTopic";
   String  qnameOut                 = "jms/actionTopic";
   
   boolean verbose                   = false;

   Session                session    = null;
   Connection             connection = null;
   ConnectionFactory      cf         = null;
   MessageProducer        mp         = null;
   Destination            destination = null;
   
   try {  

   
    Hashtable env = new Properties();
    env.put(Context.PROVIDER_URL, "corbaloc:iiop:localhost:2811");  // change your port as appropriate, default is 2809    
    env.put(Context.INITIAL_CONTEXT_FACTORY,
        "com.ibm.websphere.naming.WsnInitialContextFactory");
   
    Context initialContext = new InitialContext(env);
       
System.out.println("Getting Connection Factory");

cf= (ConnectionFactory)initialContext.lookup( cfName );

System.out.println("Getting Queue");
destination =(Destination)initialContext.lookup(qnameOut);

       System.out.println("Getting Connection for Queue");
connection = cf.createConnection("admin","admin");  // use the createConnection method that takes auth params

       System.out.println("staring the connection");
connection.start();

       System.out.println("creating session");
session = connection.createSession(false, 1);

       System.out.println("creating messageProducer");
mp = session.createProducer(destination);

       System.out.println("creating TextMessage");
TextMessage outMessage = session.createTextMessage("this is test application");

       System.out.println("sending Message");
mp.send(outMessage);

mp.close();
session.close();
connection.close();
   }
   catch (Exception je)    {je.printStackTrace();}

}

}

Now set the runtime debug properties.
Create a debug configuration for JMSClientExample.  In the VM Arguments add the following:
-Dcom.ibm.CORBA.Debug=true 
-Dcom.ibm.CORBA.CommTrace=true 
-Dcom.ibm.CORBA.Debug.Output=c:/temp/client.log 
-Dcom.ibm.ejs.ras.lite.traceSpecification=*=all
-Dcom.ibm.SSL.ConfigURL=file:///${project_loc}/security/properties/ssl.client.props
-Dcom.ibm.CORBA.ConfigURL=file:///${project_loc}/security/properties/sas.client.props
-Dcom.ibm.ejs.ras.lite.traceSpecification=SIB*=all
-Dcom.ibm.ejs.ras.lite.traceFileName=c:/temp/trace.log


Add the following to the classpath from the <ODM Install Dir>/runtimes folder.
com.ibm.ws.ejb.thinclient_8.5.0.jar,
com.ibm.ws.orb_8.5.0.jar,
com.ibm.ws.sib.client.thin.jms_8.5.0.jar.
And from the <ODM Install Dir>/runtimes/properties folder add the
orb.properties file.

orb.properties is not a jar file so you'll have to change the file selector to *.* in order to add it.  These files provide the runtime elements you need to talk to the WAS JMS provider in IBM ODM.


At this point, you should be able to run this app without errors using just the IBM JDK.  Next we're going to switch over to the SunJDK.