SOA Magazine IV 01.2015

Figure 1 – HTG Architecture
The Data Layer encloses two levels of information: BPM’s data in which BPM Suite resides on, and the
custom made data model which supports the customers’ business logic. In this last case the amount and
type of information depends on each customer. For instance, in one of our clients we did not have the
necessity to implement any type of data logic, while in other we had a fairly complex database model.
The Business Layer clusters and abstracts the features and requirements of the Human Task Generator.
Our BpmLib Library collects the data for each process and their related human tasks through BPM’s
middleware API and exposes it to be consumed by the Model and/or Application Module applications’
as showed in Figure 1. In no case do we bypass BPM’s middleware API to directly access BPM’s data in
the data base. By following this rule we protect our code of any change that may occur in BPM’s data
structure in following releases of oracle’s BPM product. The Model application exposes data through
View Objects. The Application Module application clusters it and exposes them. Here single methods
are also made available to the View Layer.
The View Layer consumes the methods and View Objects exposed by the Business Layer and display data
through the Human Task Generator application. The HTG has the capability to be reused by different
types of environments, for example: (1) ADF applications, (2) ADF Mobile Browser applications, and (3)
MAF applications. Depending on the application target, you may choose the HTG interface to use. Each
one is an application deployed as a Shared Library to allow isolation and reusability providing two
immediately advantages: (1) is available to be deployed as a shared library to any Weblogic Server, and
(2) can be incorporated in any final ADF application.
Copyright © 2015 | All Rights Reserved SOA Magazine IV 23