Mediating Task Events to Integrate Dashboards with Existing SOA Tasks

Taskflow

Mediating Task Events to Integrate Dashboards with Existing SOA Tasks

By: John Schleicher | Sr. Technical Architect

Business Activity Monitoring (BAM) services are typically licensed with SOA implementations.  Their incorporation into SOA orchestrations and BPM workflows are not that prevalent; however, the incorporation of dashboards for BPM task visibility should not be considered as problematic as they may easily be integrated with SOA mediation in a loosely coupled fashion such that the existing sources are essentially unaware of the additional capability that is engaged.

Within this article, we will walk through the steps necessary to take an established BPM task (whether BPEL based or BPMN based) and with minimal invasive activity add the components necessary to integrate with BPEL sensors for presentation in BAM dashboard.

Of course, the business knowledge associated with the tasks and internal payload as well as BAM objects are typically highly sophisticated and we are going to abstract that sophistication for the purpose of this article.  We will employ an existing application, but the details of such are irrelevant and the steps followed would be the same no matter what the application type.

Also, it is assumed that the BAM data objects are in place and the sensors to engage BAM are externalized to a BPEL web service.  This externalization is recommended as it facilitates the integrations with multiple tasks or allows for additional projects to leverage the BAM objects and their sensor integration points.

 The steps required for after the fact BAM dashboard integration are:

  • (Assumed in place) BAM objects in place with sensor engaged BPEL service updating the BAM data objects
  • Add the BPEL service to the targeted task composite as an external reference
  • Add an event mediator to the targeted task composite
  • Add data transforms for task events (Assignment, Update, Completion)
  • Configure the mediator filters
  • Configure mediator transforms to route business data to the defined BPEL service

For this exercise, the BPEL service to engage the sensors is ‘activityReporting’ and we will be adding task event mediation to the Rescan task.

Step 1: (this one is pre-requisite and assumed in place)

Step 2:  Add the sensor BPEL service to the targeted task composite.

pic-1-bam

pic-2-bam

Step 3:  Add an event mediator.

For this step we need to get the EDL for task events.  This file (HumanTaskEvent.edl) is located in the jdeveloper integrations directory along with other workflow schemas and wsdls.  Copy it to the local task project directory.

Drag a mediator component into the target task composite:

pic-3-bam

pic-4-bam

Double click on the mediator and subscribe to the Human Task events by hitting the ‘+’ sign and identifying the event file.

pic-5-bam

Elect the events required, normally OnTaskAssigned, OnTaskCompleted, and OnTaskUpdated to support standard dashboard activity.

pic-6-bam

Now to populate the mediator’s routing rules for the event subscriptions (here we will focus on OnTaskAssigned but the same technique applies to all).

pic-7-bam

Select the green ‘+’ sign and chose permanent routing rule and select service for the invoked target.

pic-8-bam

Pick your target service that manages the sensors.

pic-9-task

Step 4:  Apply filters for the transform and map the task data to the data expected by the BPEL service managing the sensors.

Here we will filter on task data ensuring that the task event is associated with the Rescan task.  On systems will multiple task deployments the task event will fire for all tasks and must be filtered.

Depressing the funnel icon gives the filter dialog. Probe the task data so you can filter on sca/task:compositeName and ensure it matches the task’s composite name.

pic-10-task

Step 5:  Create/assign transforms to route your task data to the BPEL service.

Select the transform icon on the right and select ‘Create New Mapper File’ and map the appropriate elements for your business case (this will be specific to your business case and implementation strategy):

pic-11-task

When the mapping is completed your task assigned mediation event appears as:

pic-12-task

You are finished with the OnTaskAssigned event and can extend these activities to OnTaskCompleted and OnTaskUpdated.

Once deployed, you may apply a task assignment the em trace will show the activities in the process trail as such:

pic-13

This particular invocation didn’t pass the mediator filtration (i.e. it wasn’t a Rescan task event that fired) and it ended at the mediator.  If it was a Rescan assignment event you would see the callout to the static routing task.

All of the above was added to an existing task process without engaging any of the previously developed sources (i.e. it is truly loosely coupled).  Once you get a handle on the technique and can apply existing processes, it is a quick and easy task to add human task event mediation to existing processes and extend this information to a sensor based process to see your data on a BAM dashboard.

Contact John Schleicher about this Integration Technique Today

We're here to help!

Application Development Framework (ADF) – An Overview

office computer

Application Development Framework (ADF) – An Overview

By: Tanveer Mohammed | Senior Developer

Application Development Framework (ADF) is a framework built on Java J2ee technology. Application Development Framework is utilized for rapid application development. The core premise of ADF’s introduction is to ensure that developer teams can rapidly build applications in visual declarative ways (drag and drop) instead of writing large segments of time-intensive code.

A typical ADF application layout is depicted below:
adf1

Figure: A Typical ADF Application Overlay

Application Development Framework (ADF) follows a Model-View-Controller (MVC) pattern, where it completely isolates business logic from the View layer. In a standard Application Development Framework application, all the business logic resides inside the Model layer. The Model layer carries business objects for CRUD operations on database, web-service calls, POJO datacontrols from other backend systems, etc. Business objects are further broken down into application module, entity objects and view objects.

Entity objects resemble a row in a database table. We can further override the default DML operations by simply extending entity implementation classes provided by the entity object. Validations can be added at entity level, doing so will make such a validation available to all consumer interfaces. View objects are nothing but your SQL query result sets. Additionally, View objects can be derived from either entity object, SQL query and programmatically. View objects can be tuned to improve the performance of the ADF application. Some tips around tuning View objects are to have separate View objects for read-only queries and updatable queries. Using such an approach one may appropriately specify batch size to fetch rows from database tables. The Application module handles transactions and defines what business functionalities are exposed to the View layer.

Application Development Framework (ADF) possesses a smart way to maintain its established connection pool. It passivates “least recently used” connection and allocates the resources to another request ensuring optimal use of resources in the pool. Data control palette contains all the operations, data that are exposed through application module. Anything from the data control palette can be dragged and dropped on the View layer as field, table, tree, operation etc. In View layer ADF provides a rich set of components (it has more than 150 UI components). ADF components repository have several layout components like panel stretch layout, panel form layout, and panel group layout to name a few. It has basic components such as button, table, radio, checkbox, select one choice, input text, output text, calendar, carousel, date chooser, tree and many more.

adf2

Figure: UI Components of Application Development Framework

The View layer is comprised of bounded taskflow, unbounded taskflow, JSPX page and JSFF fragments. Usually, there is one unbounded taskflow in a framework application which acts as entry point/navigation model of the ADF application. JSPX pages are pages which can be directly called from URL and usually are part of unbounded taskflow. Bounded taskflow is self-contained reusable functionality which once developed can be easily shared and used in any ADF application. Bounded taskflow has a single entry point and can have multiple exits/returns. Bounded taskflow usually possesses multiple page fragments (JSFF) and routing activities. JSFF fragments are the actual place where the functionality is implemented by dragging and dropping business objects from the data control pallet as UI components.

adf3

Figure: Bounded Taskflow

ADF applications provide authentication and authorization support using file based security model (i.e. JAZN or using database model like OPSS). During the development phase, JAZN.xml file can be used to define the authorization to resources. Resources such as pages, bounded task flows, and more can be fully secured. Application roles can also be created and mapped to enterprise roles. The JAZN.xml file upon deployment gets merged with system-jazn.xml file on WebLogic application server. The ADF application is authenticated against the LDAP provider registered on WebLogic server.

The deployment of the ADF application is executed by preparing and deploying the EAR file.

Application Development Framework was designed with reusability in mind. The entire Application Development Framework application can be deployed as a shared library that may expose its entire taskflow to be consumed by another consumer application.

Learn more about TekStream’s ability to help with Application Development today.

 

Contact Tanveer Mohammed about ADF Today

We're here to help!