In the following sections we work through some illustrative tutorials demonstrating some functional areas of the product.

Transcription

1 Tutorials In the following sections we work through some illustrative tutorials demonstrating some functional areas of the product. Starting a business process on a schedule There are times when we want a Business Process to be started on a repeatable schedule. Perhaps we want to run a process to start re-stocking at the end of each day. Fortunately, IBPM provides an elegant solution for just this capability. UCAs can be triggered to start at defined intervals and using a Start Message Event activity in a BPD allows a BPD to be associated with a UCA such that when the UCA is fired, the process instance can run. Create a new General System service called Scheduled Start. Define an output variable called " correlid " of type string. Define a Server Script node to set the value of the output variable to be " XXX ". This will be the General Service that is started by the Scheduled UCA. a new Under Cover Agent (UCA) called Scheduled Start and associate this with the General Add Service that we just created (also called Scheduled Start) In the UCA implementation, selected all the entries in the right column that says that the start time for the UCA will be every 5 minutes: Create a new BPD called Scheduled BPD. Build an wire the BPD as follows: Add a private variable called " correlid " of type String. For the implementation of the Log activity, define it to be a piece of in-line JavaScript that logs that the BPD was started: For the Start Message Event, associate it with the Scheduled Start UCA. For the UCA output

2 mapping, map to the " correlid " variable. In the Pre & Post settings of the Start Message Event, give the correlid variable an initial value of " XXX ": Create a snap shot of the Process App and deploy to a Process Server (not the Process Center). If we now start a Process Admin session and visit Event Manager Monitor, we will see a scheduled entry for our new Process App: This shows the next time it will fire. BUG!!! It seems that I have to create a new snapshot and deploy twice before it works. Building a Monitor Model for BPMN events In this tutorial we are going to walk through the construction of a Monitor Model from scratch to handle the processing of incoming Tracking Group events. This techniques does not start with a generated monitor model. It is assumed that you have skills in: This is not a tutorial for newbies to either IBPM or Business Monitor. Inour story, we want to generate tracking events. To start we assume a new process application. Into this we create a new Tracking Group that, in this story is called " sale ": The fields that we want to monitor when the process instances run are: After having constructed this Tracking Group, we next build a BPD that includes an Intermediate Tracking Event to externalize the event for monitor consumption: The fields of the tracking group are populated from a variable (not shown in this diagram). construction of the Monitoring Model is performed in Integration Developer. Start a copy of The that and open the Business Monitoring Perspective. This perspective owns all the editors and views needed to build the model.

3 We start by creating a Business Monitoring Project to hold all our artifacts. We choose to call the project " OrdersMon ". incoming events that arrive from IBPM are in an XML data format. In order for Monitor to be The able to work with these events, we need to describe the format of the events through XSD descriptions. The XSD descriptions are surprisingly not supplied with the products. Instead they are found in the InfoCenter here: These three XSD files should be added into the Event Definitions section. individual Monitor Project can contain multiple Monitor Models. We have now created our An project and now need to build our model. In the Monitor project, we create a new Monitor Model. We call our new model " OrdersMM ". Although we have added our event descriptions to our project, we have not yet said that they are to be associated with the model. In the model editor, select the Event Model tab and add each of the XSDs to the model. It appears that order of addition is important so add them in the order shown: Aswe build out the XPath entries later on in the model, we will refer to some namespaces that need to be explicitly defined with their own prefixes. Prefix Namespaces wle the model was created, it was given a default key and name. We want the key of this When monitoring context to be the Process ID instance. We rename the ID of the key to be " processid " And then rename the Name field to be " Process ID ". are now at the point where we start to add the core artifacts into the model. We start with an We inbound event that signifies a new instance of a BPD process has started. We add a new inbound event. And call it " PROCESS_STARTED ". The input data is an " eventpointdata " object

4 and we need to take care to explicitly say where this eventpointobject can be found within the incoming event. Notice the addition of the " mon:monitorevent " part as shown in the following figure. The final event types definition looks as follows: Next comes the Filter Condition. It is the Filter Condition which specifies whether or not the incoming message is an instance of this kind of event. We look at the mon:kind field of the EventPointData and check to see if it is a PROCESS_STARTED event. If it is, we have a match. xs:string(process_started/eventpointdata/mon:kind) = '{ Next comes the correlation. Here we ask if we have seen this event before for an instance of a process. If all is well, we will NOT have an existing instance and we create a new monitoring context as a result. PROCESS_STARTED/EventPointData/mon:correlation/wle:starting-process-instance = processid Inthe preceding definition, we added a new inbound event type. Now we update the key metric to when an instance of this event is found. The expression used to source the process instance will be: PROCESS_STARTED/EventPointData/mon:correlation/wle:starting-process-instance have previously defined what constitutes a start process event and seen how this creates a We new monitoring context when seen. Each creation of a monitoring context should have a mechanism to complete that context. Now we define an inbound event that will be an indication that the process has completed. We call this event PROCESS_COMPLETED. We define the event type details the same as we defined for the PROCESS_STARTED event. The filter condition which indicates that this is a Completion event is shown next. xs:string(process_completed/eventpointdata/mon:kind) = '{ Finally, we need to correlate to the correct monitoring context. PROCESS_COMPLETED/EventPointData/mon:correlation/wle:starting-process-instance = processid Now when a process completes, the monitor model will see it as a PROCESS_COMPLETED event.

5 way we terminate a monitoring context is through a trigger. We create a new trigger The definition. we call the new trigger " Terminate Context ". We next say that the trigger is fired when a PROCESS_COMPLETED event is detected. Finally, in the definition of the trigger, we flag it as causing the termination of the monitoring context. we are able to detect the start and end of the process in a monitoring model. It is possible Now that the recipe we have followed up until now will be repeated in many monitor models. Now we build out more definitions specific for our sample. If we think back we have an intermediate tracking event in our process. We want to be able to catch this type of event so once again, we create a new inbound event definition. We will call this new inbound event "TRACKING GROUP SALE" Just as before, we add an Event Part for the EventPointData but this time we add a second Event Part for the tracking point definitions. We call this event "TrackingPoint". The path to this entry will be: cbe:commonbaseevent/mon:monitorevent/mon:applicationdata/wle:tracking-point The final result for the events parts looks as follows: The filter condition that should be applied to an incoming event to see if this is an instance of our tracking event is more superficially complex but at a high level, it is true when: xs:string(tracking_group_sale/eventpointdata/mon:kind) = '{ and xs:string(tracking_group_sale/eventpointdata/mon:model[1]/@mon:type) = '{ and TRACKING_GROUP_SALE/TrackingPoint/@wle:groupName = 'sale' As before, we want to determine which of the possible process instances and hence monitoring contexts the event should be associated with. TRACKING_GROUP_SALE/EventPointData/mon:correlation/wle:starting-process-instance = processid Now we are at the point where we can detect our tracking group event. This is the last of the

6 inbound events we need to work with. Inour model, we wish to create a metric to hold the " orderamount ". We create a new metric. and give the metric the name " orderamount " and set its type to be " Decimal ". The metric's value will be taken from the following expression. Note that it names the Tracking Group event as the source and hence will only be evaluated when a Tracking Group event is detected. xs:decimal(tracking_group_sale/trackingpoint/wle:tracked-field[@wle:name='orderamount']) create a second metric to hold the US state in which the sale occurred. We TRACKING_GROUP_SALE/TrackingPoint/wle:tracked-field[@wle:name = 'usstate'] Having completed all the steps in our model's development, what remains for us to do is generate the JEE artifacts and deploy them to a Monitor server. At the completion of this step, the JEE projects will have been built and will be ready for deployment. We then deploy the project to a Monitor server through the Servers view. After deployment we will see the application representing the monitor model deployed to the server. construction is finished and now what remains is for us to run an instance of the BPD process. Our having run an instance of the process, we can bring up Business Space and an a monitoring After instances widget to a page. In the configuration of the widget, select the metrics that we build in the model for display. If all has gone as planned, we will see the following in the widget populated with data. And this concludes the tutorial. At this point we have a Business Monitor model that is as clean as can possibly be and contains no superfluous processing. The construction of KPIs, diagrams, cube views and the other powerful capabilities of monitor usage are now as standard with the product with no involvement in its linking to IBPM. Page 11 Revision #1 Created 8 months ago by Admin Updated 8 months ago by Admin