Generating events from a BPMN process (Old)

Transcription

1 Generating events from a BPMN process (Old) Before a Process Application can generate events for Monitor, it must be instructed that it can communicate with Monitor. This is achieved through the Process Application settings in a process application: Once this change has been made, when either a new snapshot is deployed or an update of the tracking definitions is performed, the generated Monitor Model EAR will be deployed to the Process Server.

2 The name of the generated application will be: bmon_<processappsynonym>_main A BPD in a Process Application can emit events. It does this by building and sending event messages to a JMS queue. The identity and details of the queue can be found in JNDI at: jms/com.ibm.lombardi/eventemissionqueue An instance of this resource is created when a Process Server profile is built. It's default WAS resource name is LombardiEventEmissionQueue which resolves to an SIBus queue name of LombardiEventEmitterInputQueue.

3 There must also be a a JMS Queue Connection factory found at JNDI: jms/com.ibm.lombardi/eventemissionqueuefactory An instance of this resource is created when a Process Server profile is built. Its default resource name is LombardiEventEmissionQCF. This points to an SI Bus called " MONITOR.<cellname>.Bus " By default, Process Center does not have the event emission resources defined to it. However, if the JNDI resources are defined, it will start using them. In summary, these resources are needed: jms/com.ibm.lombardi/eventemissionqueuefactory jms/com.ibm.lombardi/eventemissionqueue A Queue Connection Factory A Queue Resource Type Value LombardiEventEmissionQCF JMS Queue Connection Factory jms/com.ibm.lombardi/eventemissionqueuefactory LombardiEventEmissionQueue JMS Queue jms/com.ibm.lombardi/eventemissionqueue It is important to take a pause here and fully understand the story so far. In my experience, it is important to understand the architecture in order to be fully successful. What we have is that IBM BPM generates messages that are written to an SI Bus queue. The content of these messages are XML documents. It is here that IBM BPM ends its part of the Monitor interaction. At this point, the events have not made their way to monitor and merely reside in a queue. In the next part we will see how the messages are consumed by Monitor but before going there we have one more thought. What if Monitor is not installed on the same cell or machine as IBM BPM? We will shortly see that Monitor has to be able to read the messages from the queue and if Monitor is remote we seem to have a problem as a remote machine can't read a queue that is local to IBM BPM. The solution to this comes from the IBM WAS SI Bus technology. SI Bus has the concept of "Foreign Connections". This means that we can define a network link from the WAS server hosting IBM BPM to the remote WAS server hosting Monitor. From BPM's perspective, it continues to think that it is writing messages to a named queue and

4 from Monitor's perspective, it thinks it is reading from a named queue but WAS is managing the movement of messages from WAS 1 to WAS 2. Mechanically, the way we achieve this is through the SI Bus notion called the "foreign bus connection". The IBM_BPM_EMITTER_SERVICE application The messages sent to the JMS queue by BPM are (obviously) written to the target queue and are also not in a format that Monitor can directly consume. IBM has supplied an application called " IBM_BPM_EMITTER_SERVICE " that watches a JMS queue for such messages and, when they arrive, formats them for Monitor and delivers them to Monitor. This application should be installed on a machine which is part of the Monitor environment and which can also read from the BPM written queue. Since 8.5 of BPM can't co-exist on the same cell as Monitor, we normally set up a cross cell queuing environment where BPM writes the message to a queue which is actually remote from BPM. The message then ends up on the machine hosting Monitor which is where the IBM_BPM_EMITTER_SERVICE will be installed. The application uses three WAS level JMS resource definitions: jms/com.ibm.lombardi/jmsemitterinputqueuefactory WAS Resource Name LombardiEventEmitterInputQCF Points to MONITOR..Bus jms/com.ibm.lombardi/jmsemitterinput WAS Resource Name LombardiEventEmitterInputQueue Points to SIBus Queue: LombardiEventEmitterInputQueue jms/com.ibm.lombardi/jmsemitterinputactivationspec WAS Resource Name LombardiEventEmitterInputAS To install the IBM_BPM_EMITTER_SERVICE application, a wsadmin command has been supplied called "wbmdeploybpmemitterservice": AdminTask.wbmDeployBPMEmitterService(['-cluster', '<clustername>']) AdminConfig.save() eg.

5 AdminTask.wbmDeployBPMEmitterService(['-cluster', 'SingleCluster']) AdminConfig.save() Diagnosing problems If when you run a process and the data from that process does not show as instance data within a model, obviously, data is not moving from the process to monitor. Here is a check-list of items that can be checked. BPM side definitions Within the IBM BPM side of the house we have the following JMS definitions: jms/com.ibm.lombardi/eventemissionqueuefactory jms/com.ibm.lombardi/eventemissionqueue A Queue Connection Factory A Queue Monitor side definitions The following JMS definitions: jms/com.ibm.lombardi/jmsemitterinputqueuefactory WAS Resource Name LombardiEventEmitterInputQCF Points to MONITOR..Bus jms/com.ibm.lombardi/jmsemitterinput WAS Resource Name LombardiEventEmitterInputQueue Points to SIBus Queue: LombardiEventEmitterInputQueue jms/com.ibm.lombardi/jmsemitterinputactivationspec WAS Resource Name LombardiEventEmitterInputAS Configuring CEI on BPM AdminTask.wbmDeployCEIEventService('[-busMember [-cluster <clustername> -datasourcejndiname \<jndiname\> -datasourceauthalias \<authalias\> -databaseschema \<schemaname\> -createtables true] -eventservice [-cluster \<clustername\>] -jmsauthalias [-user \<username\> -password

6 \<password\>]]') for example AdminTask.wbmDeployCEIEventService('[-busMember [-cluster SingleCluster -datasourcejndiname jdbc/cei -datasourceauthalias BPM\_DB\_ALIAS -databaseschema db2admin -createtables true] eventservice [-cluster SingleCluster] -jmsauthalias [-user admin -password admin]]') AdminConfig.save() Notes: It may be that the datasourcejndiname has to be a new unique entry Configuring for remote Monitor BPM In many cases, the Process Servers running IBM BPM will be separate from the server running Monitor. Because of this, the monitoring events in the form of JMS messages will have to be remotely "shipped" from a queue on IBM BPM to a queue on the Monitor server. Collect the following: Property BPM Monitor Host Name localhost localhost SOAP Port WAS Admin Userid cadmin admin WAS Admin Password password admin Link Userid monlink monlink Link Password password password Cluster Name SingleCluster WBM provides scripts and sample properties files to assist in setting this up.

7 Create a userid called admin (if it doesn't already exist) on both servers. A properties file was created that contained the following (a template for such can be found at <Root>/scripts.wbm/crossCell/configRemoteMonitorBus.props ): SECURE\_CONFIGURATION=true LOCAL\_WAS\_HOST=localhost LOCAL\_WAS\_PORT=8882 LOCAL\_WAS\_USERID=admin LOCAL\_WAS\_PASSWORD=adminLOCAL\_WAS\_MESSAGING\_ENGINE=win7-x64Node03.server1-MONITOR.win7x64Node03Cell.Bus REMOTE\_WAS\_HOST=localhost REMOTE\_WAS\_PORT=8880 REMOTE\_WAS\_USERID=admin REMOTE\_WAS\_PASSWORD=admin REMOTE\_WAS\_BUS\_USERID=admin REMOTE\_WAS\_BUS\_PASSWORD=admin LINK\_USERID=admin LINK\_USERID\_REMOTE\_PASSWORD=adminLINK\_USERID\_LOCAL\_PASSWORD=admin REMOTE\_WAS\_ME\_NODE=win7-x64Node01REMOTE\_WAS\_ME\_SERVER=server1 \#REMOTE\_WAS\_ME\_CLUSTER= REMOTE\_WAS\_ME\_STORE=default Next, the command " configremotemonitorbus.bat -props <filename> " was executed. The servers were then restarted. At this point I gave up not because it was broken but because I opted instead for augmenting my BPM server with WBM. New instructions Configure Server to Server SSL Start both BPM and CEI Login to WAS Admin Console Go to

8 Security > SSL certificate and key management > (Related Items) Key stores and certificates Select NodeDefaultTrustStore > (Additional Properties) Signer Certificates Click Retrieve from port Enter details Click OK to add the new entry Go to Security > SSL certificate and key management > manage endpoint security configurations Realm defaultwimfilebasedrealm Results after execution:

9 C:\IBM\WebSphere80\AppServer\scripts.wbm\crossCell>configRemoteMonitorBus.bat -props configremotemonitorbus.props BM WebSphere Application Server, Release 8.0 ava EE Application Client Tool opyright IBM Corp., SCL0012I: Processing command line arguments. SCL0013I: Initializing the Java EE Application Client Environment. 12/29/13 10:09:54:570 CST] W UOW=null source=com.ibm.ws.ssl.config.sslconfig org=ibm prod=websphere component=application Server thread=[p=394289:o=0:ct] CWPKI0041W: One or more key stores are using the default password. SCL0035I: Initialization of the Java EE Application Client Environment has completed. SCL0014I: Invoking the Application Client class com.ibm.wbimonitor.sib.configassist.launcher This utility will create a foreign bus link between the Monitor bus and a remote cell Reading properties from file configremotemonitorbus.props Creating remote Bus MONITOR.PCCell1.Bus Adding application server Node1 : SingleClusterMember1 to the bus Creating the foreign buses Creating the foreign bus links Saving the configuration changes Saved You must restart both application servers for this change to take effect C:\IBM\WebSphere80\AppServer\scripts.wbm\crossCell> After execution, the following resource changes will be found: On BPM Resource Name Resource Type Example MonitorBusAuth J2C authentication data cadmin MonitorBusAuthLink J2C authentication data monlink MONITOR.<Cell>.Bus SI Bus MONITOR.PCell1.Bus MONITOR.<MonCell>.Bus Foreign SI Bus Link MONITOR.win7x64Node01Cell.bus On Monitor Resource Name Resource Type See also: Event data format The format of the event data written to the JMS queue by IBPM's BPDs is an XML document. This data is well documented in a number of detailed articles in the IBM BPM InfoCenter. Here is an example of an event message: <?xml version="1.0" encoding="utf-8"?> <mon:monitorevent mon:id="r7aa8b5a191e "

10 xmlns:bpmn=" xmlns:bpmnx=" xmlns:ibm=" xmlns:mon=" xmlns:wle=" xmlns:xs=" <mon:eventpointdata> <mon:kind mon:version=" ">bpmnx:PROCESS_STARTED</mon:kind> <mon:time mon:of="occurrence"> T12:21: :00</mon:time> <ibm:sequenceid> </ibm:sequenceid> <mon:model mon:id="f4396aed-63c7-4da9- b66d-bcc051c7dd41" mon:type="bpmn:process"mon:version="2064.a3ac4487-a8f3-47ee-9bfd51491d944d6t"> <mon:name>sale</mon:name> <mon:instance mon:id="653"> <mon:state>active</mon:state> </mon:instance> </mon:model> df27cbed7706" <mon:model mon:id="68c2430a-bc e1amon:type="wle:processapplication" mon:version="2064.a3ac4487-a8f3-47ee-9bfd d944d6t"> <mon:name>mon1</mon:name> <mon:documentation/> </mon:model> <mon:correlation> <mon:ancestor mon:id="f4396aed-63c7-4da9-b66d- bcc051c7dd a3ac4487-a8f3-47ee-9bfd d944d6t.653"/> <wle:starting- process-instance>f4396aed-63c7-4da9-b66d-bcc051c7dd a3ac4487-a8f3-47ee-9bfd251491d944d6t.653</wle:starting-process-instance> </mon:correlation> </mon:eventpointdata> </mon:monitorevent> At a high level, it is composed of: mon:monitorevent The root element of the event. mon:eventpointdata The details of the event. There is only one of these per event.

11 mon:kind Defines the kind of event mon:time The time the event was generated ibm:sequenceid -?? mon:model An executable model element mon:instance mon:correlation mon:applicationdata wle:tracking-point wle:kpi-data wle:tracked-field The monitoringevent/eventpointdata/kind is a critical entry. It defines the kind of the event that is received. The options include: An instance of a process has been started. The models bpmnx:process_started supplied include: type=bpmnprocess type=wle:processapplication bpmnx:process_completed An instance of a process has completed bpmnx:process_terminated An instance of a process has terminated bpmnx:process_deleted An instance of a process has been deleted bpmnx:process_failed An instance of a process has failed An activity is ready. The models supplied include: bpmnx:activity_ready type="bpmn:usertask" type="bpmn:process" type="wle:processapplication" An activity is active. The models supplied include: type = bpmnx:activity_active "bpmn:usertask" type = "bpmn:process" type = "wle:processapplication" bpmnx:activity_completed An activity has completed bpmnx:activity_terminated An activity has terminated bpmnx:activity_failed An activity has failed ACTIVITY_LOOP_CONDITION_TRUE

12 ACTIVITY_LOOP_CONDITION_FALSE ACTIVITY_PARALLEL_INSTANCES_STARTED The models supplied include: The models supplied bpmn:event_caught include: mon:type = "bpmn:startevent" mon:type = "bpmn:process" mon:type = "wle:processapplication" bpmn:event_expected bpmn:event_thrown bpmn:gateway_activated bpmn:gateway_completed The model type can be: bpmn:process bpmn:intermediatethrowevent wle:processapplication A common pattern will be to create a Monitoring Context when a bpmnx:process_started event is detected and close the Monitoring Context when a bpmnx:process_completed event is detected. The XML Schema files that represent these events can be found in the InfoCenter at: /rmon_eventschemaext.html These three files should be built, saved and added to the Monitor projects. Common patterns A Process has started mon:monitorevent/mon:eventpointdata/mon:kind = bpmx:process_started Examining events issued from BPM When a BPM process runs, it generates events that are sent to Business Monitor. From time to

13 time, we may wish to examine these events and ensure that the data we expected to be sent arrived. Alternatively, we may simply be interested in seeing what is passing. One way to achieve this is to switch on Event Recording. This can be done through the IBM WAS Admin Console in the Applications > Monitor Services > Recorded Event Management > Event Recording section. Within there we can enable or disable event recording: Once enabled and new events generated, we can review those events from Applications > Monitor Services > Recorded Event Management > Event Management Clicking on an event will show its XML content:

14 Capturing additional data from BPM The IBM generated monitor models are a great start but there are times when we might wish to capture additional information. Here we will document some recipes for additional items that may be of interest. Capturing the Task ID of a task When a task is created in the process, we may wish to know the Task ID for the task in the monitor data. This can be achieved by adding a new metric called "Task ID" in the "Steps" monitoring context. The data type of the metric should be "String" and the expression used to populate it should be: if (fn:exists(activity_resource_assigned_event/eventpointdata/mon:model[1]/mon:instance/wle:taskinsta then ACTIVITY_RESOURCE_ASSIGNED_Event/EventPointData/mon:model[1]/mon:instance/wle:taskInstanceId else Task_ID Capturing the Process ID of a process

15 When a process instance is created, we may wish to know the Process ID of that process in the monitor data. This can be achieved by adding a new metric called "Process ID" in the top of the monitoring context for the generated model. The data type of the metric should be "String" and the expression used to populate it should be: PROCESS_STARTED_Event/EventPointData/mon:model[1]/mon:instance/@mon:id Capturing the Process Name of a process When a process instance is created, we may wish to know the Process Name of that process in the monitor data. This can be achieved by adding a new metric called "Process Name" in the top of the monitoring context for the generated model. The data type of the metric should be "String" and the expression used to populate it should be: PROCESS_STARTED_Event/EventPointData/mon:model[1]/mon:name Page 10 Revision #2 Created 6 months ago by Admin Updated 5 months ago by Neil Kolban