Oracle Fusion Middleware (OFM) is a leading business innovation platform that enables enterprises to create and run agile intelligent business applications while providing a wide range of features. These allow operational efficiency and agility during process development time, in doing so organizations can reach process quality in a faster and improved way.

OFM platform includes a wide range of tools and technologies in order to satisfy different needs. In our case we have made use of two important technologies BPM, to streamline customers’ business processes, and ADF, that simplifies development by providing out-of-the-box infrastructure services and visual and declarative development experience.

In what concerns BPM technology, human tasks activities are an important player regarding efficiency and effectiveness since it enables to model an easy interaction with the end user in a BPM process.

The visual and declarative experience of ADF allows us to create these human tasks in two ways. The first approach is to use the out-of-the-box option to auto-generate the Human Task form. Secondly by manually creating UI pages as the number of human task forms designed.

The first approach will generate as many, separate, projects as human tasks, the latter will create as many user interface pages as human task forms. Based on these assumptions we have developed an ADF custom library that generates, at runtime, the human tasks interface. We have achieved this by using only one task flow, decreasing our development time significantly.

Complementarily to this task flow we implemented a java library that creates an abstraction layer of the BPM interactions. In this library we added some processing of the human task payloads, and provide basic caching of services and user contexts. This mechanism has proved us that having one single interface can really decrease development time of new processes at least 85.7% as well having cost-effectiveness in hours. In this article, understand how we implemented our human task interface generator in major customers on main business areas such as Retail, Finance and Energy.


The projects that we have developed in Oracle BPM have plenty of interaction with the use of human tasks and the options we have for its development can bring a huge complexity by having several projects, or several user interface pages, to manage.

Develop once reuse often has always been our motto when developing with Oracle ADF, and based on these assumptions and in our knowledge in BPM’s middleware we focused our efforts on centralizing in a single interface, Human Task Generator (HTG), all human tasks that we would generate. On this single interface we are able to display whichever ADF faces components offer, with dependencies between them, process the human task with custom or system actions, enable or disable user interaction based on permissions, and display process information as well as help topics so the user can be provided with context.

In order to achieve this goal we developed our HTG based on a custom made library (BpmLib) that abstracts BPM’s middleware java classes. In our BpmLib we expose all the needed methods to get human tasks’ payload, replying actions, and so on.

In the next chapters of this article, we will provide in more detail how we have implemented our HTG as well as the BPM library.


Our HTG was engineered based on the convention that it should be reusable and extensible interchangeably of the aplication, project or even customer who will use it, so that if our clients requirements change as well as the application target we could easily adjust to new requests.

We divided our implementation in three layers, (1) Data layer, (2) Business Layer and (2) View Layer, as shown in Figure 1.

Figure 1 – HTG Architecture

ADF1The 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.

Custom BPM Library – BpmLib

Looking in more detail to the BpmLib component, it is a java library that is responsible for all the calls to the BPM API, and returning our custom data types, creating an abstraction layer over the BPM API. It also has other functions like caching and preprocessing data for the ADF interface generation.

Creating an abstraction layer has all the normal advantages, and in our case have helped us to expose custom methods in the way we needed them in order to achieve our final goal. The API is very powerful, allowing all kinds of interactions with the underlying engines. But since we only needed a subset of those functionalities that meant that there were many options in the API that we didn’t need. We used the BpmLib to hide those options, for instance when querying processes and tasks the API allows us to define which columns we want to be returned. This library "hides" that functionality and always returns the same columns. Another example is the use of flex fields on human tasks. Since we return our own custom made classes we already include in them the business data that’s stored in the flex fields so that the upper layers don’t have to be concerned with the origin of the data. Using our own classes also allows us to flatten the class structure, simplifying access to the other fields.

Instantiating the service objects of the API is a heavy operation and as such we cache those objects. However this raises a problem, this library is running on a different managed server than the SOA and BPM Suite. When the SOA managed server is restarted, the connection becomes invalid, and all calls to the API throw a javax.ejb.EJBException. We had to include a mechanism to catch those exceptions and invalidate the service cache. On the other hand, since all managed servers are clustered, we did not need to account for unavailability of the SOA managed server. Given that in the case of unavailability of the SOA managed server most of the functionality would be unavailable anyway, that was not a requirement.

Other cached data is the security contexts of the users. Users are authenticated by the ADF infrastructure, but with that information we then need to create the security contexts that the BPM API uses. Since this creation is also a heavy operation we cache these contexts. However we had to be careful to not create vulnerabilities that would allow a user to use the cached context of another. We also had to invalidate each entry regularly to allow new security definitions, like group and role membership changes, to be picked up.

Regarding the automatic generation of human tasks interface, this library is responsible for fetching and preprocessing the payload of the tasks so that ADF layers can generate the interface.

On the BPM side we define the task payload using not only the base XSD types like string and date, but also other custom types, ranging from generic types like text to indicate to the interface generator that the field should be rendered has a text area, to other, more business specific types, like account, which the generator knows how they have to be rendered. This also includes types that have to be rendered as several controls. These type definitions are deployed to MDS allowing us to share them across processes. So, as we implement more and more processes, the number of new types for each new process rapidly decreases allowing us to reduce implementation complexity and times.

Then on the BpmLib we created our own java class representing a payload item, containing the name of the item (a key to a resource file), its value, type, if it is editable or read only, and if it is visible. Lastly we expose two methods:

  • getTaskPayload: for a given tasknumber returns a list of payload items;
  • updateTaskPayload: for a tasknumber and a Map<String, Object> updates the task payload of the task.
    • The ‘getHumanTaskPayload’ method is exposed in the application module and therefore can be invoked independently of the targeted platform (ADF, ADF Mobile Browser or Mobile Application Framework);
    • Deployed as shared library to any Weblogic Server;
    • Any change made in this module doesn’t affect the upper layer and can be deploy as demand since the contract doesn’t get broken;
    • Proximity with BpmLib.
  • name – internal attribute name. If the attribute is a complex type the name is the concatenation of human task’s attribute name plus the name of the element inside the XSD.
  • value – the value the attribute is to be set.
  • type – contains the type of the attribute, i.e. STRING for string attributes, INTEGER for integer attributes, and so on. For complex types the type is similar to XSD name in order to be easily recognized, i.e. ADDRESS for attributes based on address XSD.
  • isReadOnly – true if the attribute is not editable, otherwise false.
  • isRequired – true if the attribute is mandatory, otherwise false.
  • isHidden – true if the attribute must not be displayed on the interface, otherwise false. This type of attributes behaves like auxiliary variables.
  • isVisible – true if the attribute should be visible, otherwise false. This variable is useful for setting conditional visibility of the attributes on the interface.
  • type – contains the same value as the attribute type in HumanTaskAttribute java class. This variable exists only for code simplicity reasons on later data access.
  • attributes – represents the list of HumanTaskAttributes (List<HumanTaskAttribute>).
  • getValue – get human task’s attribute value based on attributes internal name. If internal name doesn’t exist a NULL is returned.
  • setValue – set the new value for attribute’s internal name.
  • hasKey – returns true if human task’s internal name exists, otherwise returns false.
  • getValues – get all human task payload attributes. The returning value is a java.util.Map where the Key contains the attribute internal name and the Value the value of the attribute.
  • humanTaskPayloadItems – gathers all data of human task payload attributes.
  • getValues – get all human task payload attributes. The returning value is a java.util.Map where the Key contains the attribute internal name and the Value the value of the attribute.
  • getValue – get human task’s attribute value based on attributes internal name. If internal name doesn’t exist a NULL is returned.
  • setValue – set the new value for attribute’s internal name.
  • isComplexType – true if the attribute is complex, i.e. attribute based on a XSD, otherwise false.
  • typeHasDropDownValues – true if the attribute is based on a XSD and one of its elements’ name is prefixed with “ddl”, otherwise false.
  • addSimpleTypeAttribute – If the attribute is simple or primitive then this method is called. In this method the variables of HumanTaskAttribute and HumanTaskAttributeFacade java classes are set, and then added to the top level class HumanTaskPayload.
  • addComplexTypeAttribute – If the attribute is complex then this method is called. In this method we perform the strip of human task attribute’s XSDs in order to get its elements, set HumanTaskAttribute and HumanTaskAttributeFacade java classes variables and add them to the top level class HumanTaskPayload.
  • addDropDownValuesToAttribute – If the attribute is complex and the current XSD element being parsed has the prefix “ddl” then this method is called. In this method an extra HumanTaskAttribute entry on the overall structure (Figure 3) is created in order to store the list of items for the control.
    • Make use of the primitive ADF Faces components;
    • Define custom behavior logic for each new declarative component, for example during value change events, etc., of the primitive ADF Faces components;
    • New declarative components can be created as needed without interfering with the others.
    • Deployed as shared library to any Weblogic Server.
    • Simple Component level. For example: input fields for numeric types only.
    • Custom Component level. For example, dependent fields in a custom component.
    • Task submission level. For example, submission of the task form with validation rules for individual components that cannot be filled.

GetTaskPayload Method

The getTaskPayload method starts by calling the following code:


It returns a list of MessageAttributeType. Each MessageAttributeType represents one entry of the task payload that we see on the .task file. While this gives us some information (name, type, and if it is updatable) it is not enough, so we need to also get the actual schema of the payload. This schema is available on the MDS, and there are several ways to access it. We chose to use the URL


We can feed this url to the XSDBuilder like

XMLSchema schema = new XSDBuilder().build(url);

and get an object representing the payload. From here is just a matter of iterating MessageAttributeType list and for each item get the corresponding XMLElement of the payload and build our own PayloadItem object to return.



The updateTaskPayload method receives the values to update in a Map<String, Object> where the String (key) is the name of the payload item, and the Object (value) is its value. The actual class of the Object is dependent on the type of the payload item. For simple types it's the closest equivalent in java to the type, for example a String, an Integer, or a Date. For complex types it's a String with the XML value that needs to be stored. It starts by calling the Task.getPayloadAsElement() method to get an XMLElement with the current payload. Then it also gets the XMLSchema in the same way as the getTaskPayload. This is needed to know the type of each payload item. It then updates the XMLElement with the values passed in the parameter and calls the ITaskService().updateTask(context, task) method to save the changes.

Human Task Generator

The Human Task Generator (HTG) is implemented on the basis of the previous layers, Data and Business Layer, and centralizes in a single interface all the possible human tasks forms from all feasible BPM Processes to be implemented.

In order to achieve our goal we divided our HTG Task Generator into smaller and self-contained modules, each one with their own specific contribution. The modules are: (1) HTG Transformation Model Engine, the core of the engine where human task’s payload are transformed so that can be recognized by the interface’s page, (2) HTG Declarative Components, ADF declarative components to be reused and show data in a particular manner, (3) HTG Generic Task Attributes Bindings, the binding of the human tasks attributes to the page, (4) HTG Generic Task Attributes Validations, definition of attributes validations, such as conditional required fields and data validation on fields, and finally (5) HTG Generic Task Attributes Conditional Visibility, fields visibility based on value changes of specific attributes during user processing the task.

HTG Transformation Model Engine

The core of the engine where human task’s payload are transformed are located at the Application Module in the Business Layer, as depicted in Figure 1. Here we expose the ‘getHumanTaskPayload’ method as a class available for clients.

We established our core engine here due to the following reasons:

During human task’s payload transformation we are able to support two types of fields: Simple and Complex. Simple types are single ADF components such as input text, select one choice, or input date as well as many others. Complex types are custom created components that encapsulate two or more ADF components. For instance, search field that is the combination of an input text and a button, or a custom address component as depicted in Figure 2, where we have an arrangement of several components into a single custom Address component.

ADF2Figure 2 - Address Complex Type

Our HTG transformation model Engine is structured on java classes to represent human tasks attributes. The java classes we have created for that purpose are: HumanTaskAttribute, HumanTaskAttributeFacade, HumanTaskPayload. Their relationship can be viewed in Figure 3.

ADF3Figure 3 - HTG transformation model Engine Java Classes

HumanTaskAttribute java class represent each attribute of the human task payload regardless of being based on a primitive type, simple type or even complex type. In those cases in which the attribute is a complex type, each XSD element is represented as a HumanTaskAttribute. The variables we have defined for this java class are:


HumanTaskAttributeFacade java class encloses all attributes of each human task payload’s attribute, regardless of the type (primitive, simple or complex). In those cases where the attribute is based on a complex type this java class has as many HumanTaskAttributes as elements in the XSD. In the other cases, primitive and simple attributes, this class has only one HumanTaskAttribute attribute. This situation can be viewed in Figure 3. The variables we have defined for this java class are:

For this same java class we have defined four methods:

Regarding HumanTaskPayload, this java class encloses all human task payloads’ attributes regardless of its attributes complexity (primitive, simple or complex type). This java class has the following variable:

For this same java class we have defined three methods that are based on HumanTaskAttribute’s methods:

In addition to previous java classes we have two more with no less importance HumanTaskUtilities and HumanTaskGeneratorAMImpl. The first one is a utility class that helps parsing the XSDs’ complex types while the second one is the implementation class of the “HumanTaskGenerator” application module where the method “getHumanTaskPayload” is exposed and returns all human task payload attributes after transformation.

The java class HumanTaskUtilities has the following methods to perform the transformation:

During iteration over human task payload attributes returned by BpmLib the type for the current attribute is determined. Depending on its type one of the following methods is called:

HTG Declarative Components

Declarative components play a major role in showing the same type of data in a desirable layout. Regarding HTG the declarative components are important for Complex type’s fields available in human tasks’ payload. By creating this type of components we have gained the following advantages:

The universe of declarative components already developed for a generic target audience is depicted in Error! Reference source not found..

Table 1 – HTG Declarative Components

Declarative Component








Our experience tell us that many other declarative components are able to be developed with different levels of complexity depending on each customer needs to display data.

HTG Generic Task Attributes Binding

The HTG is implemented with a single taskflow that encapsulates all logic defined for the human tasks and is responsible for generation of the components at runtime.

The following diagram represents the execution flow that is performed in our HTG taskflow.

Our HTG module is defined by a set of input parameters. These input parameters are used to determine which human task to show. Then a preprocessing is done in order to: (1) get the human task payload based on our custom made BpmLib library and (2) determine if the user that is trying to acquire the task has permissions to interact with. After this two previous steps are completed each human task attribute is rendered according to its type.

The generated human tasks have system and custom actions. System actions are equal for all tasks and are those available in BPM Workspace, the latter are defined for each task during process development.

Regarding the last step of our execution flow, Runtime Component Design, we have developed a task flow for rendering the human task attributes. The task flow is implemented as depicted in Figure 4.

ADF5Figure 4 - HTG Payload Task Flow

All starts by getting human task’s payload attributes with previous transformations already done. Then it’s time to set attributes visibility. This kind of visibility is related to attributes conditional visibility, i.e. if there is any attribute that its visibility is based on another attribute’s value then it is defined at this moment. The next step is about getting the values to populate the selectOneChoice ADF Faces component. Last but not least, the HTGPayload fragment is responsible for rendering all human task attributes from any possible Human Task, as shown in Attachment 1.

Note: This task flow may and can be enhanced for those cases you have an ADF faces control where you need to search information in modal in order to set human tasks attributes values.

In HTGPayload fragment an iteration over all human task payload attributes is performed and depending on its type it will be rendered by one of the underlying components available from the set of components inside the “af:foreach” ADF faces component. Any new component needed should be putted here.

Each component is populated based on the data structure previously presented to represent all human task payloads’ attributes regardless of its complexity. For more detail about how to assign components properties you can find an example here.

HTG Generic Task Attributes Validations

In regard of task validation we have three types of validations:

In what concerns the first type of validation, Simple Components, it is defined in “validator” components’ property, as depicted in Figure .

Figure 5 - HTG Component Validation

In order to centralize all of this type of validations we have created “ValidatorsHTG” java class. This class is instantiated with session scope in “Managed Beans” tab of faces-config.xml file. In Figure 5 are shown two component validations of two different types in “ValidatorsHTG” java class.

ADF6Figure 5 - Validators HTG Java Class


Regarding validation for Custom Components, this can be done in two ways: (1) in the “validator” components’ property of the declarative component, basic validation, or (2) in custom classes for more complex validation, for example, imagine that Address declarative component is only valid if “Country” field is filled as well as “Address” and “Postal Code”, otherwise an error message is raised to the frontend. For this kind of behavior we have developed “HTGComplexTypesValidation” java class where all generic validations will be available for future reuse. In Figure 6 is shown the Address complex type validation.

ADF7Figure 6 - Address Complex Type Validation

This approach encloses components behavior and complexity in one single place and therefore promotes more and better reuse.

Finally, validation at task submission reuses complex types’ validations as well as any other validation. The developer has full freedom and control to do any validation for any human task of any BPM process. Validations engine is structured as depicted in Figure 7, where “ProcessToValidateA” and “ProcessToValidateB” are java classes of real future BPM processes.

ADF8Figure 7 - HTG Validation Java Classes Architecture


HTGValidations (Figure 8) is the top level java class called by the user just before replying to the human task. The human task is replied if and only if all attributes (simple or complex attributes) and overall dependencies between attributes are valid. The method “validateHumanTask” is the main method called to perform the validation of processes human tasks.





ADF9Figure 8 - HTGValidations Java Class

Human tasks’ validation is made inside of each process java class created for the purpose as shown in Figure 8. For example, inside of “ProcessToValidateA” java class, Figure 9, human tasks’ for this process will be validated.






ADF10Figure 9 - ProcessToValidateA Java Class

HTG Generic Task Attributes Conditional Visibility

There may be cases in which certain human task attributes visibility is based on another attribute’s value. Conditional visibility has two setting points: (1) one on entering the “htg-payload-flow.xml” task flow (Figure 4), and (2) other in any value change listener of any ADF Faces component or declarative component.

Regarding the first setting point, before human task is displayed is needed to check attributes conditional visibility, and why? Imagine the human task has already been edited before and there is a dependency between attributes. In this case when reentering in the human task is necessary to gather the value of the attribute that causes the other attribute to change its visibility.

Human task conditional visibility is developed so that each human task of each process has its own conditional rules of visibility. This approach promotes flexibility to define attributes visibility.

Real World Benefits

In this chapter we pretend to answer some basic questions: (1) how useful our approach can be in the development process of a new application, (2) how reusable can it be? There are dependencies on customer and his business area, and (3) if there is a real world benefit spending more time at the beginning implementing a generic methodology in spite of following the regular way Oracle developed its product.

  1. How useful our approach can be in the development process of a new application?
  2. How reusable can it be? There are dependencies on customer and his business area?
  3. Is there a real world benefit spending more time at the beginning implementing a generic methodology in spite of following the regular way Oracle developed its product?

Since we developed our HTG in well-defined building layers (Data Layer, Business Layer and View Layer) where each one communicates with the nearest layer, they can be developed independently of the others. Even more, if there isn’t broken contract on methods of above layers.

Each project inside of each layer is available as a “Shared Library” and therefore deployed independently to the Weblogic server. This approach takes the same advantage, as described before, along with not being necessary to deploy all the projects to the server if only one has really changed.

When a new application is ready to be developed, independently of the business area, and needs to provide Human Tasks interfaces, the developer just imports the library into the application and easily drag-and-drop the HTG wherever is needed. It behaves as a regular ADF Faces component.

The user will be facing a standardized interface for all human tasks independently of the process. Nevertheless, the developer will have fewer interventions regarding layouts, forgotten fields, etc.., and therefore lower error-prone probability.

Here we do a study on the implementation of the HTG in the three different customers of different business areas provided us with insight of the level of reusability of our engineered solution. The next table (Table 2) agglomerates the data by customer’s business area, as well as the total number of processes and human tasks created using HTG versus human tasks created from scratch.

Table 2 - HTG Percentage of Reusability






Nº Processes





Nº Human Tasks





Human Task Generator (HTG)





Custom Human Tasks





Percentage of Reusability





Another overall perspective of the previous results can also be seen in the next graphic, Figure 10.

ADF11Figure 10 - HTG Percentage of Reusability

The previous table depicts the success of using our solution, in the banking industry the HTG, satisfies all customer needs. In the retail sector there is a great percentage of satisfaction, and finally in the last case the customer needs are satisfied but only a few small processes were implemented.

One of the leading reasons for these results was our capability to be able to evolve Complex Component Types as the customer needed them, with the underlying validations for each component and the overall human task. The modularization of our HTG in different layers was another advantage since we never mixed business logic inside viewing data and vice-versa.

All our customers wanted their own custom made Workspace, integrated within a single application, with customized look-and-feel, and custom business rules associated both in the process and interface. Based on this starting point, in any situation we needed to develop a library to interact with the BPM’s middleware, the BpmLib. Once we developed our own library, and after some experiments regarding developing human tasks interfaces, we saw that developing a custom hand-made interface to generate human tasks was not so far away.

After understanding all these facts we tried to realize the impact of a HTG would have. Therefore we made some tests to compare our HTG with generating human tasks interfaces using Oracle’s out-of-the-box approach. The results are based on our customers’ requirements and level of customization needed to achieve the same final results in both cases. The following results regard the development of each new human task interface (Table 3).

Table 3 - Spent time setting a human task interface using HTG versus without using


Spent time setting a human task interface without using HTG

(In Hours)

Spent time setting a human task interface using HTG

(In Hours)

Generate Interface (ADF Taskflow based on human task)



Customize Interface (Create a new taskflow for each human task with clients customizations)



Implement Validations



Integration of the human task with the main application



Data submission






As Table 3 depicts, using HTG takes less 6 hours developing each new human task interface, independently of the process.

Another important conclusion is the cost-effectiveness that we took by using HTG instead of the regular approach. In the next table we present these results:

Table 4 - Cost-Effective using HTG


Using HTG

Without using HTG

Total human tasks which used HTG


Total time spent to develop each human task interface

(In Hours)



Total time spent to develop all human tasks interfaces



Cost-Effective (In Hours)


As you can see by using our engineered solution we were able to have a cost-effectiveness of 85.7% hours during our developments fewer interventions and therefore lowering probability of development errors.


Based on our experience in major projects in different industries, we engineered an accelerator to automatically generate the interfaces for the processes human tasks. This mechanism has proved to decrease implementation time at least 85.7%, and thus increasing productivity.

In order to achieve our main goal we developed the HTG (Human Task Generator) based on a custom library, BpmLib, that abstracts the interactions with the BPM’s middleware. We followed the convention that HTG should be reusable and extensible interchangeably of the application, project or even customer.

We structured our HTG in three layers: Data layer, Business layer and View layer, each one with a well define scope and purpose so that future changes or enhancements could be easily overcome.

The entire module BpmLib, Model, Application Module and HTG is decoupled from the application business logic, and thus can be used in other BPM applications. Not only can the entire module be reused, but also its components independently (BPMLib, Model-AppModule).

We have answered some important questions in detail, such as: (1) how useful our approach can be in the development process of a new application, (2) how reusable can it be depending on the customer and his business area, and (3) if there is a real world benefit spending more time at the beginning developing a generic methodology in spite of following the regular use of the product.

In conclusion, this approach of developing a reusable module for human task generation is only feasible if at starting point we have the knowledge that there is a significant amount of processes/human tasks to be developed. Having in regard that after the module is developed every change is centralized allowing time saving in development achieving a better return of investment.

Pedro Gabriel


Pedro Gabriel is an ADF and BPM developer at Link Consulting, a Portuguese Oracle Platinum Partner. He is responsible for developing and architecturing ADF solutions for the retail and finance sector. He is also involved in BPM projects where he implemented well accepted solutions. Pedro Gabriel interests continue to focus on these technologies and spread his knowledge to different Oracle technologies. Before, he worked with Microsoft Technologies.

Danilo Manmohanlal


Danilo works at Link Consulting since 2010 and is one of the leading ADF architects. He is involved in enterprise-level BPM/ADF projects and has implemented solutions for the retail and finance sector.

Diogo Henriques

Diogo Henriques is the BPM Technical Leader at Link Consulting, a Portuguese Oracle Platinum Partner. He has worked with Oracle BPM for almost 5 years, since Beta, including a few large scale projects. Before, he worked with Oracle Workflow for 3 years.

Receive our SOA Magazine

Events Calendar